https://chatgpt.com

要望きた！→即実装！をするとクソアプリになる その機能がユーザーが望まれていて、自分も欲しいと思っていたとしても、すぐに機能として組み込まない方が良い当初ここに「これは詭弁だけど〜」と書いていたけど、実際には本気でそう思っていますshokai.iconリモートワークでは焦りがオーバーワークを産み、判断を誤らせる いつでもどこでも無限に仕事できてしまうし、深夜でも何でも対応できてしまう 速度が上がっていくとハイになりすぎて、わからなくなる ただの思いつきなのか 本当に必要な機能なのか 以前/remoteというイベントで話した事の中から、ブレーキをかける事に自分で自分を納得させる為の考えをまとめる リモートワークについての知見を話してきた機能をどんどん追加しちゃだめ

@wolphtype: Cosenseのフォントを自分のやつにしようと思ったけどそもそもCosenseのフォントの読み込みはGoogle FontsとかCloudflareしか対応してないらしい！解散！わかる。自由なフォント使えたほうがいいshokai.icon現状 helmetを使ってCSP font-srcに制限をかけている src/server/controllers/middlewares/helmet.jsにて fontSrc: ["'self'", 'cdnjs.cloudflare.com', 'fonts.gstatic.com']scrapbox.ioとcdnjs.cloudflare.comとGoogle Fonts、以外にホストされたfontも読み込んで良いのではないか？ なんせ画像は制限してないわけだし JavaScriptの読み込み先を解除するのはXSSの原因になるからまずいだろうけど フォントは解放しても大丈夫なんじゃないかなと思って調べたのだが、解除するのは危険だったshokai.icon フォントを読み込むだけで任意コード実行できそうな脆弱性がある為 フォント関係は、ブラウザ内のXSSとかよりももっと深い層で危険な事が起こるようだ

文脈：CSP font-srcの厳格な制限は解除してはいけないCosenseのコードを対象にCodex CLI.iconと議論した そもそもCSP img-srcが全開放されているのだからCSP font-srcも解放していいんじゃないか？ と思って、Codex CLI.iconにChatGPT.icon用のプロンプトを作ってもらって調べたshokai.iconhttps://chatgpt.com/c/6960f0d3-1dbc-8323-a42e-b34d559b7ae6code:prompt あなたはセキュリティ調査担当です。CSPのfont-srcを無制限にした場合のリスク説明のために、フォントパーサ脆弱性の具体例を時系列で整理してください。 要件: - 対象: ブラウザ/OSのフォント解析（GDI/DirectWrite/CoreText/FreeType/ブラウザ内フォント処理など） - 形式: リスト（年→CVE→影響→影響範囲→簡潔な説明→参照元URL） - 範囲: できるだけ主要な事例（Windows/macOS/iOS/Android/Linux/Chrome/Firefox/Safari） - 目的: font-srcを無制限にしたときに、攻撃者が細工フォントを配布できるリスクの根拠として使える情報 - 注意: 画像系の脆弱性ではなく「フォントパーサ」に限定する - 参照: 一次情報（CVE, 公式アドバイザリ, ベンダーセキュリティノート）を優先

前回のGeminiとChatGPT使い比べ (2025/8時点)と同じような観点で使い比べますshokai.icon8月からの変化 ChatGPTがgpt-5.1になった こっちはGPT-5と比べて、shokai.iconの用途である調査・設計の相談では差は感じないshokai.icon Gemini 3が登場し、Thinkingが使えるようになった たぶんより賢くなったのだろう でも元から、渡したドキュメントの内容 + Geminiが事前学習済みの知識を使った回答に関しては、十分賢かった気がするCloudflare outage on November 18, 2025をGeminiとChatGPTそれぞれでshokaiが重視する観点でのportmortemとして出力した どちらも最初のプロンプトで渡したURLを読んでくれる これはGeminiとChatGPT使い比べ (2025/8時点)と変化なし この用途では優劣はつかなかったGemini 3は、やはりまだThinking中にインターネット検索をしてくれないshokai.icon 調べろと言っても調べてくれない

リビングルームで使うテレビ等に表示するUI 約10フィート（3メートルぐらい）離れて操作する事から命名された特徴 文字は大きめ ポインティングデバイスが適していない環境ディスプレイの中に限った話は、このへんを見ると雰囲気わかる Xbox およびテレビ向けの設計 - Windows apps | Microsoft Learn なるべく十字カーソル + 決定キャンセルの2ボタン程度で全て制御する 画面中央付近のアイテムが1つだけ選択されている 選択対象を上下左右に移動すると、画面も自動的にスクロールされる フルスクリーンアプリ ウィンドウとかは無い。マウスポインタが無いから 文字入力しない キーボードも無いから 家庭用ゲーム機やスマートTVのホーム画面を想像するとイメージ付く PlaystationやNintendo Switch

2025/9時点のGPT-5と、Gemini 2.5 Proを比べるshokai.icon GeminiとChatGPT使い比べ (2025/8時点)に続けた、使用感の報告です 特にDeep Researchを絡めた調査・学習を重点的に検討しましたDeep ResearchはChatGPTよりもGeminiの方が圧倒的に良いshokai.icon*10 Deep Research結果からさらなるDeep Researchをしたくなるような、知的な広がりがあるレポートが出てくるGeminiなら、ただこんな感じで調査依頼するだけで code:prompt ポインティングデバイスを使わず、画面スクロールによって、画面中央にあるボタンやリンクが、自動的に1つだけフォーカスされる。 フォーカス対象の詳細情報が常にpopupや、サイドバーに表示される そういう感じのUIの例を幅広く調査してほしい 10フィートUIとかDirect Manipulationとか空間コンピューティングのような、さらなる調査のとっかかりになる学術用語を使いながらサーベイ結果をまとめてくれる 認知負荷や、運動機能障害を持つユーザー向けのアクセシビリティ等の論点も、最初の1発目のレポートで紹介してくれる同じプロンプトをChatGPTで試した

麺や維新(維新商店)と似たラーメンを中央区・港区で探したshokai.icon https://gemini.google.com/share/89e6835aff79 どこがどう好きなのか、似てるとは何か？を、Geminiが考えている 1. 構成部品が似てるラーメン屋 2. ラーメンに対する哲学が似ているラーメン屋 こっちをやって、レポートに入れてくる思考力がすごい 勉強になったshokai.icon たしかに、例えば同じ魚介のラーメンを食べたとして 「ホタテの味がして好き、ホタテが好きだから」というのと 「素材を繊細に色々やってる技巧派が好き」みたいなのは違う Geminiは両方のパターンを考慮してリサーチしている 2つの軸で推薦されるとすごく良く考えてくれてると感じるのかもしれないshokai.iconみなさんも、昔好きだったあの店、に似てる近所の店を探してみてくださいshokai.icon Gemini Deep Researchに頼むと面白いレポートが出てきます

Helpfeelを開発している

同一のタスクを両方でいろいろやってみている。わかってきたのでChatGPT Business導入検討のための感想としてまとめるshokai.icon いや、色々ではない。インターネット上の調べ物に偏ってた 文書生成とかはあまりやってない結論：もしGeminiがGoogle workspaceに付属してて無料じゃなかったら、今すぐChatGPTに切り替えるべきshokai.icon ただしGeminiのDeep Researchは素晴らしい これだけはChatGPTに大差をつけて勝ってる GeminiのDeepResearchは知的な広がりがあるレポートが生成される Deep Research有効化してない素のGeminiには、ChatGPT o3-proと比べるとだいぶ不満を感じる まず、何を相談しても出典を明らかにせず返事するので、全てが信用できない 出典を明らかにさせると、ほぼ架空のURLを返してくる。ヤバイ。 ほぼDeep Research有効化しないと役に立たないと言って良い でもなんだかんだ、Node 16ぐらいからある機能の話とかはできるので、使える場面はあるんだよな ちょっと知ってて当たりをつけれる分野なら使える つまり自力でググっても解決できてしまう分野 Geminiに質問して役に立つのは、AIがなくてもどうにかなる場面だけだ

AIで能力拡張されて色々やれるせいで、手を広げすぎて散漫になったり、やり切れた箇所は体力が足りなくて大変になった年だった気がする年初からAIコーディングエージェント触り始めて、サービスを作りながら、作り方も作る状態になった 作り方は、随時Cosenseで共有していたのだが 人々の現状を知った上で共有していこうと、（2024年よりは）色々なミーティングに顔を出し始めた とかやっていたら、今はセキュリティもやらないとまずくないか？と考えて心が分裂してしまい、それぞれが過剰にがんばって大変な事になった サプライチェーン攻撃を学ぶ会2025秋の振り返り プロダクト・チーム・作り方・社内知識、のマネジメントSmart Contextとかもリリースできた当初想像してなかった方向のビジネスユーザーが増えてきた感じがする 2023, 2024年に増えたのは、建設・金融などの研究寄りの部門が多かった 2025年は⋯広い意味でインフラ？ いつか https://scrapbox.io/case に掲載されたら見てくれ

2025年12月にPixel 6aから乗り換えたすごく5Gの電波が入る充電 バッテリー58%から USB-Cで10分間充電すると、72%になった

突然少量のステーキが食べたくなった時にすぐ焼けて便利アヒージョも作れる

見た目に反して簡単に作れてよい。しかもうまい材料 丸鶏 イオン系スーパーでたまに値引きされて1000円ぐらいで売ってる事がある。即確保 S&B等のスパイスミックス 「鶏の香草焼き」みたいなやつ 150円ぐらい 1パッケージに2回ぶん入っている オリーブオイル ビニール手袋 タコ糸 縛れてヘルシオで燃えなければ何でも良い手順 丸鶏にスパイスミックスとオリーブオイルを塗り込む

コードレビューは早くやってほしいという気持ちは数ヶ月前まではあったが、最近は無い 数ヶ月前は結構大規模なリファクタリングをする事が多かったので、1箇所のレビュー詰まりがボトルネックになって次の修正ができないという事があった 最近はうまくモジュールが分割されているのと、色々な部分をいじりたいのとで、10個ぐらいレビュー待ちでリリースできないけどまだまだ他にやる事あるから別にいいやという感じになっている暇になった時に周りを見渡して改善点に気づくというのもあるので、あまりテンポよくレビューが進んでやることだけやっていくと当たり前の物になってしまって面白くならない。 これは普通にそういう時間を取ればいいとかではなくて、気分の問題みたいなのがある 完全に今やれる事が無いからボーッとしてて何か思いつくのと、やる事は積み上がっているけど手を止めて考える時間を作れというのは違う 前者の方が色々面白い事を思いつく気がする 気のせいかもしれないが 時間に追われる中でアイディア練るのは健康に悪そうまとめ 暇が創造性を産む 暇を作り出すために定期的にコードレビューが詰まると良いのでは#2017年1月 #memo

/help-jp/Smart Context蓄積したドキュメントをサービス外の自由なAIで扱う為の機能 蓄積したプレーンテキストを効率的にLLMやAIエージェントに渡したい ドキュメントを書きまくっていると、そのうちファイル数が万を超える その全ドキュメントをAIに渡すと、AIがバカになってしまう 単純なコンテキストのサイズの問題 日本語すら出力できなくなる 変なコードばかり出てくる 古いドキュメントに矛盾した記述が含まれている 仕様を誤解したコードが出てくる 有料プランの機能だって言ってるのに無料全開にしたりAIに渡すドキュメントを選ばなければならない

AIを開発に使ってうまくいったパターンを語る会2025 開催レポートをどうやって作ったかマテリアル Nota-aiを開発に使ってうまくいったパターンを語る会2025-search_-_dev_sprint_.2hop.txt 当日の発表内容のSmart Context 20251225-文字起こし.txt Google meetsから得られる文字起こしテキストGemini 3 Proを使う Gemini 3 Thinkingだと論理性が足りなくてかなりダメだった。普通に事実関係が間違ってるせいで説得力が薄い文が出てくる 多少時間かかってもGemini 3 Proを使うべきshokai.iconhttps://gemini.google.com/u/2/app/d99eadd5e71537bf code:prompt 社内イベントの文字起こしテキストと、発表資料です 参加していないソフトウェア開発者向けの振り返りレポートを作ってほしい - まず何らかの結論、あるいは全体像の理解を助ける、新たな切り口を提示する

from /Nota/AIを開発に使ってうまくいったパターンを語る会2025 開催レポート2025年12月25日に開催されたAIを開発に使ってうまくいったパターンを語る会2025の振り返りレポートですshokai.iconがCosense開発で実践し、確かな成果を上げた「AI活用の成功パターン」をまとめました 最近、準備・開催・事後レポートをそれぞれ1〜2時間ずつで素早くやる形式を模索しています1. 序論：なぜ「速さ」ではなく「信頼性」に挑んだのかshokai.iconはAIコーディングエージェントの普及により全世界的に開発速度が劇的向上し、それに伴い「粗製濫造されたコードによる品質低下」と「障害対応の難易度爆増」という副作用が伴うと予測しました。この流れはオープンソースのライブラリを使ったり他社のAPIと連結したサービスを構築している以上、影響を避ける事はできないので、特にAIをレビューやドキュメントの読み解きに使う方法を模索しました。開発においては 社内には個人開発者が多くいるから、プロトタイピングのような「失敗してもよい」場面での活用は個々人に任せれば十分に切り開いてくれるだろう 一方Helpfeel社は2023年からAIをプロダクトに組み込んできた為、こういう時にこうハルシネーションが起こるという話も頻繁に行われていた為、AIの出力に懐疑的な慎重派も少なからずいる 長期運用するプロダクト開発の本流においては、shokai.iconは「いかにAIの出力ブレを抑え、人間が責任を持てる信頼性の高い成果物を生み出すか」という点に注力すると、全社的なバランスが取れるだろう と考え、実証実験を重ねてきました。という位置づけの話をする会だったので、もはや社内では当たり前のとなっている開発技法については、一切触れませんでしたshokai.icon

だいたいどれも、社内Cosenseに書いたページを2,3ヶ月遅れでコピペで公開projectに持ってきていますshokai.icontable:cosense やり方手順 効果このパターンが解決する問題

#AIエージェントにプログラミングさせる時のパターン途中まで自分で作って、続きはAIエージェントに作ってもらうパターンを実現するプロンプトの1つ 特に既存プロダクトのbug修正やリファクタリングで有用フロー 1. まず、とにかく何らかの作業を完了させる 普通に手書きでプログラミングしても良い 2. AIコーディングエージェントに作業内容の意図を理解させる ここまで全てAIに作業させてきた場合 特にやる事はない そうでない場合 作業内容を認識する手順を指示する 「HEADのcommitを見て」「git diff main」など あるいはpull requestのURLを渡す 3. 「他に同じような変更するべき箇所はあるか？」とか質問すると 見つけてくれる そして、同じ様に修正してくれる

2025年6月ごろの感想いつ質問していいのかわからない Devinが調査中にshokai.iconが追加の質問をしてしまう いつまで調査してるのかわからない非同期にchat入力できるなら、もっと高速に動作してほしい 動作速度とUIのコンセプトが合っていない インタラクティブシステムは、描画をロックしてでも強制的に同期を取ったほうが使いやすい場合もあるコンテキスト汚染の原因になってるのではないか？ 的はずれな調査や作業を中断させてもそこで得たコンテキストを忘れてくれない 汚染されたまま作業継続してる気がする 私が「Devinはボンヤリしている」と言っている理由の1つはたぶんこれshokai.icon裏でダラダラ関係ない内職している大学生って感じ しっかり明確に「やれ」と言うまで作業しない事がある

mongoose 7からmongoose 8への変更点 2025年6月に書いたページを/Nota/Migrating to Mongoose 8からコピペしたshokai.iconMongoose v8.15.1: Migrating to Mongoose 8 書かれている全項目を調査したshokai.icon Cosenseのmongooseを8.x系最新版に上げるのため20250616-012050.txt by Claude Code.iconshokai.icon Cosenseの実装と読み合わせする、ドキュメントとコードの読み合わせ機になってもらった https://mongoosejs.com/docs/migrating_to_8.html を読んで、上から順に1つずつmigration内容を確認し このリポジトリ内の実装と照らし合わせて1つずつレポートしてください。 migration内容を私に説明しつつ、現在の実装に問題が無いか調査してくれ、という事です。 コードの変更は最後にまとめて行うので、まだやらなくていいですhttps://app.devin.ai/sessions/b12f8aa362424daca439a7136c5f191a by Devin.iconshokai.icon Deep Agent modeで開始 既にnpm自体はmongoose 8に更新してしまったのですが、migration guideの内容について改めて確認したい

#AIエージェントにプログラミングさせる時のパターン人間がやった作業をAIコーディングエージェントに後から見せて、「私は何をしましたか？」「ここにある思想や判断基準を言語化して」と問いかけ、暗黙知を形式知（ドキュメント、ルール、プロンプト）にする作業パターンAIを思考の分析者や言語化パートナーとして使う 途中まで自分で作って、続きはAIエージェントに作ってもらうパターンは、AIを自分の「分身」として単純作業をスケールさせたが 内省を促し、ルール・方針の完全な言語化を助けるパートナーになってもらう最終的なアウトプットは再利用可能なルール、ガイドライン コードそのものではなく、将来の自分や他のメンバー、あるいは別のAIも使用できる1回本気でレビューすると、そこから手順書が生成できて、別の機会でも使い回せる。これがうまくハマるとめちゃくちゃ気持ちいいshokai.icon 眼の前の作業が、さらにAIに食わせてスケールさせる事を前提とした、もう一つ新しい意味を持った作業になる手順 1. まず人間が何らかの作業を完了させる 例えば

Ewin bluetooth折りたたみキーボードを買った Pixel 4aに接続して使ってみているcontrolとcapslockの入れ替え https://play.google.com/store/apps/details?id=info.informationsea.apps.deletekeyasbackspace /uochan/AndroidでCtrlとCapsLock入れ換え Pixel 6aでは必要なかった。OS標準機能でcontrolとcapslock入れ替えできたshokai.icon英語・日本語の切り替え shift + space まだ慣れないshokai.icon 日本語変換の選択候補、今どれ選んでるのか見づらい 選択候補のフォントがほんの少し太くなるんだけど、ほとんど差がないので全然わからんalt + tabでアプリ切り替えできるの便利scrapbox

Node.js用のMongoDB clientライブラリ https://github.com/mongodb/node-mongodb-native https://www.npmjs.com/package/mongodbnpm名はmongodbだが、node-mongodb-nativeと呼んだ方が区別しやすいのでGitリポジトリ名からそう呼んでいますshokai.icon って書いてたのに最近は自分でもmongodb npmって呼んでたmongooseも内部ではこれを使ってmongodb serverと通信している

整理整頓は必要ない。整理するのは、この2つが目的だと思うが 1. 後で取り出す速度を上げる 2. 完成させる為に、欠損を見つける 整理整頓はあくまで手段のはずなのに、目的になりがちだと思う 整理とか無駄なのでやめましょう 別の方法でも、同じ目的は十分達成できるので後で取り出す速度を上げるみんなこれに極端に最適化しすぎだと思う 1 stepか2 stepで取り出せるようにしがち 1 step 完全な定位置を決める 2 step

ネオジウム磁石マグネットフック 机の裏に吊るす 電源タップもフックで吊るす クランプ クランプ型の電球ソケット クランプ型の電源タップ クランプで棚にフックを増やす ホームセンターで売ってるやつ

前提知識 mongooseのfind query cursorは色々な回し方があるけどどれ使えばいいの？_idを使ってもう一度読み出すようにした方がいい場合があるshokai.icon code:js let cursor try { cursor = model.find(condition).cursor(); for await (const { _id } of cursor) { const doc = await model.findOne({ _id }); // _idを使ってもう一度読み出す } } catch (err) { // 例外処理 } finally { cursor?.close(); }

MongoDB query cursorで使えるフラグ MongoDBサーバーには、アイドル状態のcursorをkillする仕組みがある 判定は、一定時間getMoreを発行しない事 cursorTimeoutMillisで設定されている これをやらなくなるオプションが、noCursorTimeout: true アプリケーション側から見ると cursorのタイムアウト（MongoServerError: Cursor id (id) not found）が ほぼ発生しなくなる 絶対に発生しないわけではない 詳しくはMongoDBのCursor not foundエラーやnoCursorTimeoutオプションとの向き合い方を読んでくれshokai.icon

1つのcursorを長時間回していると発生するMongoError batch処理などで発生する Mongoose 8やMongoDB 8ではMongoServerError: Cursor id (id) not foundという名前のエラーになっているaddCursorFlag('noCursorTimeout', true)である程度は解決できるが https://mongoosejs.com/docs/api/querycursor.html#querycursor_QueryCursor-addCursorFlag http://mongodb.github.io/node-mongodb-native/2.2/api/Cursor.html#addCursorFlag https://github.com/nota/scrapbox/pull/4175 安易に頼らない方がいいshokai.icon 特にbatch処理では、どうしても必要なケースもあるが そもそも、どう対策してもMongoDBのfail overやclusterの構成変更時などに発生するものなので、レジュームやリトライ等の戦略から練っておく必要がある 詳しくはMongoDBのCursor not foundエラーやnoCursorTimeoutオプションとの向き合い方にまとめたshokai.icon