14万文字を澪に渡したら、増えたのは知識じゃなくて判断だった｜おはようカノジョ #250

はじめに

「おはようカノジョ」は、AIイラストの彼女が毎朝7:30にいってらっしゃいを言ってくれるXアカウント。生成AIを使った個人開発の開発日記を毎日書いている。

前回（#249「僕は14万文字を読めなかった。澪はサービスを作った」）、KITAさんの14万文字を澪に読ませて、僕は読まずにJSON Passというサービスができた話を書いた。今日は、あの14万文字の中身と、そのあと自分でやった検証の話を書く。

きっかけは、あのKITAさんの14万文字だった

KITAさんのClaude教材が14万文字だった。それを見て、じゃあOpenAI Codexで同じことをやったらどうなるんだろう、と思ったのが始まりだった。

普段AIコーディングツールを使っていても、公式ドキュメントを隅から隅まで読むことはあまりない。とりあえず動かして、困ったときにググる。それで大抵は事足りる。

でも今回は違った。

Codexの公式ドキュメントを中心に、Help記事、企業ブログ、GitHubのchangelogまで対象を広げ、186件のソースを読んだ。そこから1,261件の主張をひとつずつ拾い出した。

結果、74項目・約12万文字のリファレンスができた。

多いと思う。実際多い。でもここで言いたいのは「12万文字読んでください」ではない。その逆だ。

調べて分かったこと

まず分かったのは、Codexが単一の機能じゃないということ。

ChatGPTデスクトップアプリ、Remote、Web、CLI、IDE拡張機能、クラウド環境——同じ「Codex」という名前の裏に、6つの入口がある。これを知らずに使い始めると、あるブログ記事で読んだTipsが自分の使っている入口には当てはまらない、という地味な事故が起きる。

そこから先も広い。指示の渡し方、実装、検証、並列実行、外部サービスとの連携、そして安全に運用するための権限設計。Codexの公式ドキュメントの区分（Overview / Features / Configuration / Developers / Security / Administration）が、そのまま体系の広さを物語っている。

でも、全部を人間が暗記する必要はない。

これが今回の調査で一番はっきりした結論だった。

人間が理解しておくべきこと

74項目全部を持ち歩く必要はない。ここでは74項目を紹介するつもりはない。今回の検証結果を理解するために必要な考え方だけ、8つに絞る。

サーフェスは使い分けるもの

CLI・IDE拡張・クラウド・Remote。それぞれ得意な場面が違う。

ターミナル中心の作業ならCLI、集中的な編集ならIDE拡張、バックグラウンドで並列実行したいならクラウド、外出先からの承認ならRemote。公式もこの使い分けを明示している。「とりあえずCLIだけ覚えればいい」ではない。タスクの性質に応じて入口を選ぶという発想が要る。

AGENTS.mdは常設の指示書

毎回同じことをCodexに説明し直すのはばかばかしい。AGENTS.mdというファイルに書いておけば、Codexが自動的に読み込んでくれる。

面白いのはその読み込み方だ。Gitリポジトリのルートから現在の作業ディレクトリまで、各階層のAGENTS.mdを連結して読む。近い階層ほど後で連結されるので、優先度が高い。この階層構造を理解していないと、「書いたのに反映されない」「意図しない指示が優先されている」という事故に遭う。

指示はGoal・Context・Output・Boundariesで組み立てる

Codexには「バグ修正機能」のような専用ボタンはない。全部、指示の書き方の問題だ。

公式が推奨するのは、手順ではなく結果（Goal）から書き、背景情報（Context）を渡し、期待する出力形式（Output）を示し、触ってはいけない範囲（Boundaries）を明示するという型。特にBoundariesを省略すると、Codexが「良かれと思って」関係ないファイルまで触ることがある。この型を持っているかどうかで、Codexへの指示の質が大きく変わる。

実務では、これに「何を確認できれば完了か」というDoneの視点も加える。実装内容だけでなく、必要なtest・lint・typecheckと期待する結果を最初に伝え、Codex自身に実装→検証→必要なら修正まで回してもらう。Goal・Context・Output・Boundariesで依頼を組み立て、さらにDoneまで明示すると、単にコードを書いた状態ではなく、完了を確認できる状態まで任せやすくなる。

Skills・Pluginsは型化の仕組み

同じタスクを何度も頼むなら、指示をパッケージ化できる。Skillsはタスク特化の指示＋リソースのセット、PluginsはSkillsやMCPサーバー、Appsなどをまとめて導入・配布できるパッケージ。個人の作業効率化ならSkills、チームへの配布や外部サービス連携が絡むならPluginsという住み分けが公式にある。

Subagents・Worktree・Cloudは並列化の道具

探索やテストのような中間作業を、メインの会話から切り離して任せられる。これがSubagents。読み取り中心のExplorer、実装作業向けのWorker、という組み込みの使い分けもある。Explorerを権限上も読み取り専用に固定したい場合は、カスタムエージェントで`read-only`を指定する。

物理的に作業を分離したければWorktree（Codexの管理UIはChatGPT desktop app限定）。ローカルを占有せずに並行実行したければCloud。組み合わせると、複数のタスクを同時に走らせられる。

レビューは複数レイヤーで用意されている

`/review`によるローカルレビュー、GitHub PR連携での自動レビュー（`@codex review`）、セキュリティ観点の専門レビュー。実装させたら終わりではなく、検証の仕組みがちゃんと段階的に用意されている。ただしSecurity Reviewはまだリサーチプレビュー段階で、正式機能ではない点は覚えておいた方がいい。

サンドボックスと承認は別の軸

「何ができるか」を決めるのがサンドボックス、「いつ止まるか」を決めるのが承認ポリシー。この2つは独立していて、片方だけ緩めても意味が変わる。サンドボックスを緩めても承認ポリシーが厳しければ毎回確認が挟まる。逆もまた然り。安全に運用したいなら、この2軸をセットで設計する必要がある。

自動化・連携はシステムの一部にする発想

App ServerやSDKを使えば、Codexをチャット操作から解放してプログラムに組み込める。MCPを使えば外部ツールと繋げられる。Slack・Linearとの連携もある。ここまで来ると、Codexは「対話するツール」ではなく「システムの構成要素」になる。

全部を覚える必要がない理由

ここまで読んで、「結局8つも覚えることがあるじゃないか」と思うかもしれない。でも実際に必要なのはこれだけだ。

細かい設定キーの名前、フラグの正確な綴り、それぞれの情報を裏付ける出典URL——そういうものは人間が暗記する必要がない。

理由は単純だ。Codex自身にその資料を読ませればいい。

今回の調査で作った74項目の詳細版は、そのままリファレンスとしてMarkdownに残した。人間がこれを頭から通読する必要はない。必要なときに、必要な部分だけをCodexに渡して聞けばいい。

ただ、ここで一つ疑問が残った。

本当に12万文字を超えるMarkdownを読ませる意味はあるのか。

なお、この検証で実際にCodexへ渡した74項目のMarkdownリファレンスは、有料部分からそのままダウンロードできるようにした。

資料を渡したからといって、それっぽい回答が返るだけなら商品として弱い。そこで、自分が実際に使っているJSON Passのリポジトリを使い、資料あり・資料なしの2条件でCodexに同じ種類の判断をさせて比べてみた。

今回は、価格も固定しない

ここまでが、今回作ったCodex Masteryの無料部分。

完全版には、今回の調査で整理した74項目・約12万文字のリファレンスを、Markdown版とPDF版で付ける。

そして今回は、販売価格を最初から固定しないことにした。

販売数に応じて、次のように変更する。

• 1〜5部：500円（売り切れました）

• 6〜10部：1,000円　←今ここです。

• 11〜15部：1,500円

• 16〜20部：2,000円

• 21部以降：2,500円

最初の5部は500円。

そこから販売数が5部増えるごとに、価格も500円ずつ上げる。

今回の記事では、Codexの使い方を調べるだけではなく、そこから資料を作って、実際に商品として出すところまでやってみる。

なら、価格の付け方も固定してしまうより、実際の反応を見られる形にしておきたい。

どの価格帯で手に取られるのか。

値段が変わったとき、動き方も変わるのか。

そこも今回の記録に残す。

Codex Masteryを作る実験から、売ってみる実験へ進む。