AIに頼む「粒度」が変わった
ChatGPT-5.5で注目すべきは、モデル名が増えたことではない。AIに「ひとまとまりの作業」を任せる前提が強くなった、という設計思想の変化だ。
従来のAIコーディングでは、こういう依頼が中心だった。
この関数を修正してください。
このテストを通してください。
このエラーの原因を教えてください。
1問1答に近い頼み方だ。それが、GPT-5.5の文脈では一段階大きい粒度が求められるようになった。元記事で示されている依頼例がわかりやすい。
このリポジトリで、記事生成フローの本文品質を改善したい。
まず関連ファイルを読んで、変更案を3つ出してください。
そのうえで、最小変更でできる案を1つ選び、テストで確認できる形にしてください。
実装後は、変更点・残課題・確認したコマンドを短くまとめてください。
この粒度で渡すと、Codexは「コードを書く係」ではなく「小さな開発タスクを進める係」として動く。依頼の単位が変われば、AIの機能する場所が変わる。
なぜ今、役割分担を考えるのか
ひとつ留保を入れておく。2026年4月24日時点では、GPT-5.5のAPI提供はまだ始まっていない。つまりこの話は、API組み込み前提ではなく、ChatGPTやCodex上での作業設計として読む必要がある。
それでも今考える意味があるのは、「誰に何を任せるか」を先に決めておかないと、AIをフル活用しているつもりで実は1つのツールに全部押しつけているだけ、という状況に陥りやすいからだ。ツールが増えるほど、設計なしでは混線する。
3つのAIに何を任せるか——具体的な分担表
元記事では、ChatGPT-5.5・Codex・Claude Codeの3者に役割を割り振る構造が提案されている。整理するとこうなる。
| 役割 | 任せる作業 | 主な成果物 |
|---|---|---|
| ChatGPT-5.5 | 検索意図と読者の疑問を整理、仕様言語化 | 記事コンセプト、読者への約束 |
| Codex | 出典管理、内部リンク、実装差分、テスト実行 | sources.json、editorial_brief.md、review_notes.md |
| Claude Code | 日本語として読みたくなる本文に仕上げる | article_draft.md、article.html |
**ChatGPT-5.5に向くのは「実装前の論点整理」**だ。目的・制約・リスクを言語化し、Codexへ渡す前に粒度を調整する。最初からCodexに実装させると、作業分解が甘いまま差分が出ることがある、と元記事は指摘している。先に「この変更の論点は何か」「確認すべき前提は何か」「実装案は何通りあるか」を整理しておくと、Codexへの指示が鋭くなる。
**Codexに向くのは「コードベースを読んで具体的な差分を作る作業」**だ。rgやテストを使って根拠を確認しながら、影響範囲の小さい実装を選んで差分を出す。成功・失敗がログで残るテスト実行も、Codexの得意領域になる。ポイントは「何を作るか」だけでなく、「どこまで確認すれば完了か」も一緒に渡すこと。完了条件が曖昧なまま渡すと、出力の品質が安定しない。
**Claude Codeに向くのは「長文の構成と日本語の読みやすさ」**だ。構造が正しくても、読み物として弱い記事はある。そこを磨く役割をClaude Codeに渡すと、品質が上がりやすいという。
AIおじさんの見方——「編集部モデル」という考え方
元記事の表現を借りると、「AIを万能ライターとして使うより、編集部のように役割を分けたほうが、薄い記事になったときの原因を切り分けやすくなる」。
これは開発でも同じことが言える。コードの品質が低いとき、それはCodexへの指示が悪かったのか、ChatGPTでの論点整理が甘かったのか、あるいはそもそもの要件定義の問題なのか。役割が分かれていれば、どこで詰まったかが見える。全部1つのAIに投げると、失敗したときに原因が霧の中になる。
AIを「チームの一員」として使う、というのはやや比喩的な表現だが、実態は「責務を分割してそれぞれに渡す」という、ごく普通のソフトウェア設計に近い。特別な話ではない。ただ、それをAIに対してもやる、ということを意識的にやっている人はまだ少ない。
実務的な示唆——今日から変えられること
元記事には公開前チェックリストも含まれている。GPT-5.5のように情報が動くテーマでは特に重要だとして、以下が挙げられている。
- API提供状況を本文中で明記したか
- 公式出典がある機能名だけを断定しているか
- 目立つ数字が本文・表・メタ情報で一致しているか
- 出典リンクが末尾だけでなく、主張の近くにも置かれているか
- 読者が今日試せる作業例があるか
このリストは記事制作に限らず、技術ドキュメント全般に使える視点だ。特に「APIで使える」と読める表現への注意は、2026年4月時点でのGPT-5.5に限らず、常に意識しておくべきことだと思う。
依頼の粒度という観点で言えば、今すぐできることは1つある。Codexや他のAIに作業を渡すとき、完了条件を一緒に書くことだ。「テストが通ること」「変更点と残課題を箇条書きでまとめること」など、成果物の形を先に決めておく。それだけで、出力の扱いやすさが変わる。
まとめ
ChatGPT-5.5×Codex×Claude Codeの分担論は、「どのAIが賢いか」という話ではない。どのAIにどの責務を持たせるかを先に決める、という設計の話だ。
AIに丸投げすることと、役割を分けて渡すことは、見た目は似ていても結果が全然違う。後者は、うまくいかなかったときに原因を特定できる。それが実務での再現性につながる。
元記事はZennに全文公開されているので、具体的な指示文の書き方や提供状況の詳細はそちらで確認してほしい。
