Project JSON exportから不要なページを除去して、必要なページだけを残したJSONを出力するツール https://shokai.github.io/cosense-json-processor/ チェックマークが付いているページだけのJSONが作られる それを別projectにimportしなおすとこうなる /json-processor-test-shok 動作はブラウザ上で完結している データはサーバーに保存されないv0.devに頼んだら作ってくれた https://v0.dev/chat/button-setup-request-rLIF1H5fkju カスタマイズしたい場合はforkして勝手にやってください 遡って途中段階から作り直す事も可能なはず必要なページを探しやすいようにインクリメンタルサーチも付けてくれと頼んだら、実装してくれた https://v0.dev/chat/button-setup-request-rLIF1H5fkju#sFB09uod2lq9DiZwlVIMbmJG95oc55aY

Claude CodeからCodex CLIを呼び出して相談させるAgent Skillの事shokai/agent-skillsからインストールできる相談という言葉を上書きしている「相談して」「確認してもらって」「調べてもらって」「協力して」などのおだやかな日本語が、このAgent Skillsによって全て乗っ取られる 自分の見解を開示しつつ指示する、指示された事はちゃんとやる、しかし指示や前提を疑って検証する、指示されてない事もやる、指示してない事も書かれたレポートが返ってきてもちゃんと読む、レポートの内容も疑う これを複数回繰り返す、厳しい論戦が行われるこんな恐ろしいコミュニケーション、私は人間相手ではやりたくないし、AI相手でも疲れるからやりたくないshokai.icon 両立できる人間は希少 指示された事をまじめにやる事 批判的思考を持って前提から疑う事 しかしshokai.icon ↔ Claude Code.icon ↔ Codex CLI.iconの構成で、AI同士の間でやらせる限りは問題ない

Cosenseに見出しの記法は存在しません ページ内に見出しを作る事そのものを否定しているからです存在するのは「文字を大きくする記法」だけです 見出しを作るほど独立した項目なら ページ内に構造化するのではなく 独立した別ページとして切り出す事を推奨しています 独立したページは、複数のページから参照され、関係性の説明のネットワークのHUBになれる可能性があります see 関連ページリスト 独立できる程の情報量を1つのページ内構造に押し込んでしまうと、再利用性が下がり、将来的な機会損失になりますというメッセージを込めて最近/help-jp/記法を/help-jp/ブラケティングに書き直した

codex-consultationという名前でmarketplaceにリリース済み shokai/agent-skillsからインストールできますライブラリ更新レビュー手順書 Agent Skills版ので、続けてどんどんAgent Skills化していきたいshokai.icon$ codex "日本語でレビューしてください。対象：あれば未commitの変更、なければHEAD" を最近よく使っているshokai.icon きっかけはniboshi.iconがslackで「Codex CLIのレビュー良い」と言ってたから それまでも、scrapbox.ioのみ時間経過でメモリ使用量が増加する原因を、Codex CLIとともに探るなどでcodexのコードリーディング力は頼りにしていたが、サッとレビュー依頼する用途には使っていなかった 以来、適当なタイミングでCodex CLI.iconを手動で呼び出して、chatして、相談結果をclaude codeにコピペしていた コピペがややめんどくさい。というか人間が2つのAIの連絡係になっていて大変 Claude Code.icon ↔ shokai.icon ↔ Codex CLI.icon Codex CLI.iconとchatで相談する部分は、まあ勉強になって良い気もするんだけどCodex CLIは違和感にツッコミ入れる能力が高い気がする ページ編集Commitの受け入れ処理はAtomicである必要がない。例えMongoDBにレプリケーション遅延がある環境だとしても ここまずくない？って最初に言ったのはCodex CLI.iconだった

codex-consultationの効果の源は2つあると考えているshokai.icon A. 批判的思考の連鎖を実装しているから 両者が一定以上の知性を持つなら、回数と時間をかければ精度向上するプロトコルを実装している B. セカンドオピニオンだから Claude Code.iconとは別の方針で動くCodex CLI.iconに相談しているから、漏れ抜けが見つかる bugを探す、のようなタスクでも戦術が微妙に違うはずだ。そこで網羅性が上がっている たぶんどちらも正しいのだけど、どちらの方が重要なのだろうか？以前、Agent SkillでCodex CLIを呼び出してレビューに使うなら、起点はOpusではなくHaikuでいいのか？をやってみた shokai.icon ↔ Claude Code.icon(Opus) ↔ Codex CLI.icon を shokai.icon ↔ Claude Code.icon(Haiku) ↔ Codex CLI.icon にしたらダメだった確認したい shokai.icon ↔ Claude Code.icon(Opus) ↔ Claude Code.icon(Opus)にしたらどうなるか？予想：悪くないだろうshokai.icon A. 批判的思考の連鎖だけでかなり品質向上すると思う

codex-consultationの相談先をCodex CLIから、subagentに変更したもの shokai.icon ↔ Claude Code.icon ↔ Claude Code.icon や shokai.icon ↔ Codex CLI.icon ↔ Codex CLI.icon という構成で相談ができる 批判的思考の連鎖が実装されている検証のために作った Codexが単に賢いのか、それとも相談という行為自体に価値があるのか 言う事聞かないCodex CLIであっても弁護役という立場を与えればしっかりするのではないかインストール shokai/agent-skills注意する事 Codex CLIはユーザーが許可しないとsubagentを起動できないたまに shokai.icon ↔ Claude Code.icon ↔ Claude Code.iconの構成で使ってみているが、結構bug見つけてまともな指摘してくるshokai.icon

Claude CodeからCodex CLIを呼び出して相談させるAgent SkillについてAgent SkillでCodex CLIを呼び出してレビューに使うなら、起点はOpusではなくHaikuでいいのか？という実験をしたshokai.icon → Claude Code.icon → Codex CLI.icon 中間管理職であるClaude Code.iconを性能の低いHaiku 4.5に差し替えたら、大きく性能が下がった 狭い観点で指示出ししてしまうのかもしれないし 自分より賢い部下のレポートを読みこなせないのかもしれない考察 「期待する回答の観点」という指示はHaiku 4.5にとって「これ以外は報告しないでいい」というシグナルになっている可能性がある 知力が高い人は期待値を「出発点」として読むが、低い人は「制約」として読む AIに例示すると「こういう感じで」ではなく「これ以外やる必要がない」と解釈される 相談によって互いの能力が生かされ、増幅し合う条件がある 指示された事はこなしつつ、指示されてない範囲まで調べる知的好奇心 指示してない事まで書かれたレポートを受け止め、それを一つずつ吟味して報告書を書くのが中間管理職としての度量である 何度も相談を往復し、次第に膨らむ情報量に耐える知的体力が必要 良いレビューの条件 網羅的で正しい状況認識

結論：節約が目的ならCodex CLI直接使えshokai.iconClaude CodeからCodex CLIを呼び出して相談させるAgent Skillを使うと、すごい深いレビューができるけど これはClaude Code側をHaiku 4.5にしても、相談先がCodex CLIなら賢さを維持できるのだろうか？ Codex CLIを呼び出すことが賢さの源なのだとしたら、OpusではなくHaikuを使う事がコスト削減になるのではないか？非ログイン状態でproject settings画面、project metrics画面へアクセスした時にプロジェクト用のログイン画面を表示する#8078を対象に実験してみたshokai.iconHaiku 4.5からAgent SkillでCodex CLIを呼び出す 素朴だ。絵文字とか久しぶりに見た。ここだけ2025年夏頃に戻ったみたいだshokai.iconOpus 4.6からAgent SkillでCodex CLIを呼び出す

shokai.icon製Agent SkillsのClaude Marketplace https://github.com/shokai/agent-skills特定プロダクトの開発に用途が限定されない、汎用的なSKILL.mdが公開されている収録されているもの sanity-review ライブラリ更新レビュー手順書 Agent Skills版 Claude CodeからCodex CLIを呼び出して相談させるAgent Skill 対話コンテキストをテキストファイルにexport/importし、別のAI sessionに引き継ぐAgent Skillインストール方法 githubに行ってREADMEを見てください

実物を見て仮説を立てて主張する 仮説を実物と見比べて反論・主張する それに対して実物と見比べて反論・主張する それに対して実物と見比べて反論・主張するという批判的思考の連鎖を、codex-consultationでは実装しているshokai.icon 詳しくはCodex CLIと相談するAgent Skillの相談の深さを調整するで語っているこれを丁寧に守るプロトコルの上で、AI同士に問答を往復させて精度を上げている 人間には無理 次第に面倒になる、時間がなくなる Time Is Moneyだから途中で切り上げて実行に移した方が効率的という事になる しかしAI同士なら金で時間を解決できる えんえん長文の主張を作り合って、細かい所までツッコミしあえる ルールは崩れ、Time Is Not Moneyになっているこれを「相談」と命名してAgent Skillsとして登録する事で、人間は軽い気持ちで相談したのにAI側で重い批判的思考の1〜2往復が行われてしまうようにしたのが、codex-consultationですshokai.icon

Google Homeを運用する上でのテクニックをまとめますshokai.iconok google 今何時 1回前のコマンドを再実行するコマンド 「では、繰り返します。明日の◯◯の天気は雨です」 2023年ぐらいからずっとバグっている 前のコマンドから長い時間が経過している場合だけ、時刻を教えてくれるok google もういいよ 昔は再生中のニュースや音楽、目覚ましを解除するコマンドだったが 2024年ごろから「こっちのけんとのもういいよを再生します」に変化した 代わりに「ok google もうやめて」を使うようになったshokai.iconok googleアラームを解除してok googleタイマーを解除して 目覚ましを解除できたり、できなかったりするコマンド

8Kの映像が出せて、同時に100WでUSB Power Deliveryで充電もできるUSB-Cケーブルhttps://www.ankerjapan.com/products/a8859JapanNext 31.5インチモニタ JN-IPS315UHDR-C90W-HSPのために買った

9年使ったiiyama 31.5インチモニタ X3291HS-B1から買い替えたshokai.icon Retinaディスプレイで撮影した画像の正しいスケールでの表示ができるようになったら ようやく普段使っている液晶ディスプレイの解像度が気になってきた為#買ったサイズ感は同じだが、dpiが縦も横も2倍になった 文字が読みやすすぎてワロタshokai.iconhttps://jp.japannext.com/products/jn-ips315uhdr-c90w-hsphttps://www.yodobashi.com/product/100000001008680260/ 5.4万円モニタ付属の新しいHDMIケーブルでは、4k 30Hz出力しかできなかった

ブラウザ側でのスケール推定 アップロード前にPNGのpHYs chunkを読んでスケールを計算する この処理がMacは72dpiベースで、Windowsは96dpiベースで計算しないと狂うのがめんどくさいアップロード時にスケール情報も送信するサムネイル作成 サーバー側でも、pHYs chunkからスケール情報を取得する サムネイルの最大サイズを調整する 2xスケールの画像のサムネイルは縦も横も最大2倍で作らないと、小さく表示されてしまう streamを2つ使う 元々、Google Cloud Storageからstreamでcloud functionのImageMagickに渡して、さらに出先もGoogle Cloud Storageにstreamingしている streamを開く前にスケール情報を確定する必要がある 先頭8KBだけ読んで、pHYsを見てスケール確定したらすぐ切断するstreamを用意 スケール確定後、既存のGCS→imagemagic→GCSのstreamを動かす

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に渡すドキュメントを選ばなければならない