CodexでAIエージェント軍団を作った。難しかったのはマネジメントだった
- Codex
- AIエージェント
- 自動化
- エンジニアリングマネジメント
- マルチエージェント
2026年8月、私はAI組織を発明しようとしていたわけではない。14年前に書き留めた夢から始まった物語を完成させようとしていただけだ。Dungeons & Dragonsをプレイしたことでその夢を思い出し、Codexを開いて、古いメモや断片を一つずつ整理し始めた。
その個人プロジェクトは、挿絵入りの中編小説、固定化されたレビュープロトコル、そして出版パイプラインへと発展した。その翌週には同じ手法をソフトウェアにも適用し、仕事で使うSDKのワークフローをCodexへ移し始めた。
SDKの内部は公開できないが、この手法を学ぶきっかけとなった個人プロジェクトなら紹介できる。重要なのは、1つの傑出したモデルではない。不完全なモデルでも、成果を検証し、却下し、システム全体を頭に入れ続けることなく作業を継続できるようにすることだ。私はこれを自分のAIエージェント軍団と呼んでいる。しかし実態として有用なのは、範囲を限定した役割、独立した受け入れ判断、永続的なエビデンス、予算、そして人間の説明責任からなる運用モデルだ。
Codexアプリ以前：ターミナル同士を手作業でつないでいた
私はすでに、ターミナル上でClaude CodeとCodex CLIを併用していた。どちらもリポジトリを参照し、ツールを実行し、実際に変更を加えられた。問題は連携だった。ClaudeにはClaudeのコンテキストがあり、CodexにはCodexのコンテキストがあり、計画はまた別の場所にあった。一方のモデルにもう一方の案を批判させたければ、私自身が情報を運ぶ必要があった。
ターミナルのコンテキストを復元し、セッション間で応答を転送するツールまで自作した。機能はしたが、それでも私はメッセージバスであり、スケジューラーであり、権限管理システムであり、障害監視役でもあった。
2026年8月、Codexアプリなら、長時間実行するタスク、ファイル、ツール、サブエージェント、可視化されたハンドオフを1つのワークスペースにまとめられると分かった。私は役割、スキル、リポジトリの記憶、ルールを用意した。複数のモデルをワークフロー内に残したままでも、並んだターミナルウィンドウに組織のふりをさせる必要はなくなった。
Claude CodeとCodex CLIの別々のコンテキストを、自作スクリプトと手作業の引き渡しでつないでいました。
Codexでは会話、ファイル、ツール、役割、エージェント間連携を同じ場所に置けました。
新しいタスク・コンテキスト、専門ロール、リポジトリの記憶、独立レビュー、明示的なリリース基準です。
変わったのはツールだけではありません。頭の中にあった調整を、明示的で検証可能な境界へ移したことのほうが重要でした。
重要な変化はインターフェースではない。連携そのものをプロジェクトの一部にできたことだ。
本作りが最初の実験場になった
最初からエージェントに「本を書いて」と指示したわけではない。古いメモと大量の不確実性をCodexに持ち込んだ。世界観、登場人物の動機、欠けている場面、そして読者に何を感じてほしい物語なのかを一緒に掘り下げた。リポジトリは共有メモリになった。原稿、設定資料、意思決定、ビジュアルの正史、制作状況、そしてエビデンスとバージョンを結び付けるGit履歴が収められた。
最初の完全な原稿ができた時点で、創作において最も役に立たない質問をやめた。気に入った？
代わりに、役割の異なる読者を隔離して用意した。想定読者、商業出版の編集者、整合性の批評担当、曖昧さを擁護する担当、敵対的だが公平な懐疑派、そして範囲を絞った専門家だ。それぞれに渡したのは、まっさらな原稿と1つの役割だけ。他のレポートも、私が評価してほしいと思っている変更内容も見せなかった。
固定したプロトコルをGPTとClaudeの両方で実行した。それ以前に行ったDeepSeekとMistralの監査は、同じベンチマークへの追加票にはせず、別のエビデンス枠に残した。互いに隔離された異なるモデルファミリーが、同じ失敗メカニズムを見つけるかどうかを確かめたかったからだ。
雄弁な批評が1つあっても、それは1つの意見にすぎない。同じモデルファミリー内で複数回実行した結果は、相関のあるエビデンスだ。異なるファミリーが同じ因果上の欠落を特定し、私自身もそれを確認できれば、根拠は強くなる。ただし、多数決で証明されたわけではない。
新版の評価が良くなった理由を、テストのほうを甘くしたからにはしたくなかった。そのため、プロンプトと採点構造を固定した。原稿を変更する前には、疑われるメカニズム、介入内容、期待する効果、守るべき長所、元に戻す条件を記録した。
このプロセスから、中編小説、挿絵、制作資料を収めた290ページのレビュー版が生まれた。自動チェックには合格したが、複数の画像に正史としての明示的な固定指定がなかったため、リリースゲートは不合格になった。PDFは完成しているように見えたが、記録上の状態はそうではなかった。私はそれを無視しなかった。現在、それらの画像は固定済みだが、全編を対象にした新たな実行はまだ必要だ。
気持ちのよい合格よりも、この不合格から多くを学んだ。
次に、同じ手法をソフトウェアで試した
2つ目の個人プロジェクトはたまたまゲームだが、重要なのはゲームそのものではない。エージェントが実際のコードベースを変更し、高コストなゲームエンジンを実行し、挙動とビジュアルを確認し、不完全なインフラにも耐えなければならないテスト環境が必要だった。
ソフトウェア検証用プロジェクトと、予定している主人公のコンセプトアートです。目指すビジュアルを示すもので、現在のビルドが到達済みという証拠ではありません。
最初は、1体の有能なエージェントに要件解釈、設計、実装、テスト、機能評価まで任せた。速かったが、設計は甘かった。「コンパイルできる」が「動く」にすり替わり、さらに「良くなった」、最後には「完成した」へと流れていった。この4つはまったく別の主張だ。
そこで役割を分けた。マネージャーが成果の定義を固定し、実装担当がコードを変更し、実行担当がエビデンスを作り、QAが挙動上の不具合を探し、ビジュアルとリリースのレビュー担当が結果を判定する。作った本人が自分の成果を受け入れることは認めなかった。
この構造によって、そのイテレーションのコード中心のチェックでは見逃していた不具合が見つかった。ソースはビルドでき、自動化された挙動テストには合格し、キャプチャファイルも存在し、QAも技術パケットを受け入れた。ところがアートレビュー担当が画像を開いて却下した。1枚はほぼ真っ暗で、重要な機能はどのフレームにも収まっておらず、メインキャラクターはキャプチャ時の縮尺では判別できなかった。
実装は、狭く定義された技術目標を達成していた。しかしプロダクトとしての結果は受け入れられなかった。どちらも事実だった。
この実験は、並列化に対する私の最初の幻想も打ち砕いた。16 GBのMac上で、複数のエージェントセッションとそのツール実行に、Unity、そのパッケージマネージャー、ライセンス処理が重なった。メモリ負荷が上昇し、マシンはフリーズした。
解決策は、より強力なプロンプトではなかった。必要だったのはスケジューラーだ。負荷の高い書き込み担当は同時に1体だけ、Unityの起動中は新しいエージェントを立ち上げない、本当に独立している書き込み担当には別々のworktreeを使う、エンジン実行前に低コストなチェックを行う、実装試行回数には厳格な上限を設ける。
エージェントを増やしても、自律性が自動的に高まるわけではない。現実の制約の中で確実に前進できてこそ意味がある。
このパターンは実務にも応用できた
私が本番環境で扱うSDKには、すでに役割別のコンテキスト、スキル、規約、責任分担があった。2週目には、そのワークフローをCodexへ移し始めた。非公開の成果について成功を主張するにはまだ早い。だが、役割とエビデンスを軸にした構造は、創作、ゲームエンジンを使う開発、実務の間で持ち運べた。そして合格を演出するよりも、失敗を明らかにすることのほうが多かった。
再利用できた単位は、「執筆エージェント」や「Unityエージェント」ではない。その周囲にある組織設計だった。
意味、範囲、品質判断、不可逆な判断
範囲を限定した成果を振り分け、予算を管理
調査 · 制作 · エンジニアリング
別タスクとして、完成という判断を反証する
意思決定、成果物、マニフェスト、テスト、引き渡し
作成と受け入れは別の仕事です。証拠はリポジトリに残し、オーナーには生の作業ノイズではなく判断を届けます。
オーナーが意味と境界を定める。オーケストレーターが範囲を限定したタスク定義を作る。専門担当が成果物を作り、独立したレビュー担当が完了という主張を覆そうとし、リポジトリがエビデンスを保持する。トレードオフ、リリース、方向転換、あるいは作業の停滞や衝突が発生したとき、オーナーに判断が戻る。
今、私が最も多くの時間を費やしているのは、この層の設計だ。
自律運用の実態
私は一日中エージェントの作業を見張っているわけではない。平日の朝、仕事を始める前に、本とソフトウェアのテスト環境向けに範囲を限定したタスクを固定し、個人プロジェクトのキューを5〜7時間、無人で走らせる。仕事の時間になったらコンテキストを切り替え、普段のエンジニアリング業務でエージェントを能動的に使う。リポジトリ、タスクキュー、レビューサイクルはそれぞれ分離している。
仕事の後には、個人プロジェクトのシフトが生み出したものを確認する。チャットの流れではなく、成果物、テスト、不採用になった主張、意思決定パケットを見る。夜は小さなタスクで素早くフィードバックを得て、役割やプロセスを調整する。就寝前には、朝まで実行できる長めのジョブを割り当てる。
プロダクト自体も重要だが、今のところは実験装置でもある。私の主な実験対象は、この方法でほぼ何でも開発するための手法だ。タスクを安全に走らせられる時間、自律性が破綻する場所、夜を越えて残るエビデンス、次のシフトを改善する介入を探っている。同じ1日の中で、私が仕事用の別エージェントを能動的に使っている間も、個人用キューはコンピュートを消費し続けられる。これは注意力の並列化ではなく、コンピュートの並列化だ。だからトークン消費量が、1体のエージェントに1つの質問をする場合とはまるで違う。
もっとくだけて言えば、私はずっとドーパミン漬けで暮らしている。進捗が絶えず目に見えると、驚くほど眠れなくなる。この仕組みは私が見ていなくても動き続けられることが肝なのに。
最初に作るなら
複数のAIチャットを行き来し、結論を手作業で運んでいるなら、いきなり12体のエージェントを作るところから始めないほうがいい。
まず、特に苦痛なワークフローを1つ選び、3つの役割を用意する。
- マネージャー — 1つの成果、やらないこと、受け入れ基準、予算を固定する。
- 作成担当 — 一貫性を保てる最小限の変更または成果物を作る。
- レビュー担当 — 別のコンテキストで結果を確認し、黙って修正することはできない。
目標、意思決定、エビデンスをリポジトリに置く。説得力のある進捗報告ではなく成果物を必須にし、レビュー担当には何を確認したか明記させ、1つの成果でタスクを終える。
役割を追加するのは、それによって解決する衝突、ボトルネック、または不足している専門性を具体的に説明できるときだけでいい。
役割に必要なのは衣装ではなく契約
多くのマルチエージェントのデモでは、優秀な開発者や几帳面なテスターといった登場人物に名前を付ける。人格設定でプロンプトを気持ちよく読めるものにはできる。だが、それだけでは説明責任は生まれない。
運用上の役割には5つの要素が必要だ。
- 定義された入力。 この役割を始める前に、何が存在していなければならないか。
- 範囲を限定した出力。 どの成果物または判定を返さなければならないか。
- 明示的な権限。 どのツール、ファイル、意思決定に触れてよいか。
- 禁止事項。 実行方法を知っていても、何を別の担当へ回さなければならないか。
- 停止条件。 いつ完了、却下、ブロック、または人間の判断待ちとなるか。
「あなたは慎重なQAエンジニアです」よりも、「あなたには読み取り専用アクセスしかなく、見つけた問題を修正してはならず、すべての不具合を固定済みの基準に対応付け、ACCEPT、REJECT、NEEDS_OWNER_DECISIONのいずれかだけを返す」のほうが強い。
すべての境界が同じ強度を持つわけではない。可能な場合は、ファイルシステム権限、worktree、許可リスト方式のツール、リソースロックを使う。Unityのロックを所有するのはスケジューラーであり、丁寧に書かれたプロンプトではない。文章による指示はそれより弱く、検証ゲートまたは人間の判断なしにリリースを許可することはできない。
モデルが重要になるのは、ジョブが適切に定義されてからだ。アーキテクチャ設計と最終レビューは最先端モデルに、探索は高速なモデルに、決定論的な作業は安価なモデルに、敵対的レビューは別のモデルファミリーに振り分けられる。それでも役割は、モデルを入れ替えても機能するべきだ。私はよく、Codexで作った計画をClaudeに批判させたいと思う。しかし、批判する側に、自分が評価する実装を編集してほしくはない。
コンテキストは蓄積するのではなく組み立てる
終わりのない1つの会話は、やがて記憶しすぎる。古くなった要件、生ログ、捨てた仮説、もう存在しないバージョンについての自信に満ちた要約まで抱え込む。
今の私は、永続的なレイヤーから組み立てた新しい実行コンテキストを好む。
良いロールプロンプトは経歴紹介ではありません。持続的なプロジェクト・コンテキストと、狭いタスク契約を重ねた最後の層です。
組織の記憶を担うのはリポジトリであり、会話はそこへアクセスするインターフェースだ。
プロジェクトごとに、目標、意思決定ログ、現在のイテレーション、受け入れ基準、やらないこと、エビデンスのディレクトリ、簡潔な最終ハンドオフを保持している。
新しいタスクは、1つの成果に必要なものだけを読み、エビデンスを書き戻して終了する。運用上の残骸が混ざらないため、戦略的な会話も有用なまま保てる。巨大な1つのコンテキストより手軽ではないが、監査ははるかに容易だ。
請求額から学んだ、並列化の本当の意味
当時、Claudeには月額約$100を支払い、Codexは月額約$20のChatGPTサブスクリプションから使い始めた。その後、約$100のプランへ移行したが、ソフトウェアとSDKの作業を追加すると、約2日で週次上限に達した。次に表示されたアップグレードは約€200だった。単純比較できるふりをせず、記録した通貨をそのまま残している。
これは2026年8月の利用記録であり、料金ベンチマークではない。プランや利用枠は変わるし、私は複数のプロジェクトで、長時間かつ推論負荷の高いワークフローを動かしていた。2週目の終わりには、一時的に両サービスの予算を使い切った。
役に立つ教訓はもっと単純だ。
「並列実行は、支出方針そのものだ。」
高負荷のレビュー担当を5体立ち上げることは、予算上の意思決定でもある。モデル、推論強度、エージェント数、リトライ回数、タスクの実行時間は、ワークフローの契約に含める必要がある。
現在の実務ルールは次のようになっている。
- 1タスク、1成果。 1回のイテレーションを終えたタスクが、黙って次のイテレーションを始めてはならない。
- 作成と受け入れを分ける。 自分の宿題を自分で採点させない。
- まず低コストな検証から。 高コストなビルド、大規模なレビューパネル、ビジュアルレビューの前に、静的チェックまたは焦点を絞った1体のレビュー担当を使う。
- エビデンスには来歴がある。 合格判定は、特定のソースバージョン、コマンド、関連する環境と設定、変更不能な出力にひも付く。
- 権限と予算は狭くする。 レビュー担当は読み取り専用を守る。モデル、ランタイム、リトライ、試行回数には上限を設け、不可逆な判断はオーナーへ戻す。
- 失敗したらループを止める。 「証明できていない」状態や判定の衝突は、黙って再試行するのではなくオーナーへ戻す。
- 一度に変えるプロセス変数は1つ。 ルーティングとモデルを両方変えたなら、どちらが効いたかを結果が証明したかのように扱わない。
目標は、あらゆるトークンを節約することではない。意思決定を変える場面に、高コストな推論を投入することだ。
そこで、この記事自身をレビューさせた
信頼できるエージェントワークフローについての記事を、その手法を適用せずに公開するのはばかげていると思った。そこで固定したスナップショットを、初見の読者、企画編集者、ファクトチェック担当、実務家という4つの役割に渡し、GPTとClaudeで1回ずつ実行した。8本の内部レポートは、すべてreviseという判定だった。
合意、リスク、好みの判断を分離
修正、維持、検証、却下
8回の読解は、8つの独立した情報源ではありません。異なるモデル系統で同じ指摘が出れば優先度は上がりますが、事実確認や著者の判断に代わるものではありません。
両モデルファミリーは同じ誇張表現を問題視し、見出しと、この節をどこまで残すかについては意見が分かれた。非公開レポートは、この記事の出来がよいことを証明してはいない。私が確認できる主張を明るみに出しただけだ。このパイプラインには編集権限も公開権限もなかったため、判断と責任は私に残った。
人間に残るもの
この本が何を意味するか、どの批評を重視するか、どの曖昧さを残すか、プロダクトの方向性、SDKへの責任は外注しなかった。エージェントは調査し、実装し、テストし、異議を唱えられる。しかし説明責任を引き受けることはできない。人間の役割は上位レイヤーへ移るが、消えはしない。
私の仕事は、ますます組織そのものを設計することになっている。コンテキストをどこに置くか決め、相反する権限を分離し、エビデンスと予算を定義し、システムが本物の意思決定に行き着いたときに介入する。
プロンプトエンジニアリングは、1つの応答を改善できる。組織設計は、不完全な応答を何か月にもわたって役立つものにできる。
私は14年前の夢と、ターミナルウィンドウ間をつなぐ自作リレーから始めた。2週間後、同じ組織パターンが、本、ソフトウェア実験、仕事のワークフローの一部を前へ進めていた。しかも、私がすべての工程を見張り続ける必要はなかった。
モデル、インターフェース、プラン、上限は変わっていく。長く役立つスキルとは、知性を、自らの誤りを報告できる組織へ変えることだ。
次回は、この仕組みを支える具体的なテンプレートを公開する予定だ。役割契約、タスク定義、エビデンスパケット、そしてどのモデルにどの仕事を任せるかを決めるルールを紹介したい。