AIにコードを書かせる作業を自動で分担させるには？

監督役のAIから、実装役のAIへコードを書く作業だけを渡す形にする。設計・レビューは監督、コード生成は実装役、と役割を固定するのがコツ。

AIのサブエージェントとは？

メインのAIから呼び出される「分身」のAI。特定の作業（ここではコード実装）だけを任せて、結果をメイン側が受け取る仕組み。

AIが書いたコードはそのまま使っていい？

だめ。必ず自分（か監督役）が実物を確認してから受け入れる。自動で書かせても、鵜呑みにしない線引きが要る。

ClaudeとChatGPTを連携させる第2回: 監督はClaude、実装はSol。コードを書く作業だけを自動で委譲するリレーの作り方

目次 / INDEX

前回は「ClaudeとChatGPTは選ぶものじゃなくて役割分担させるもの」という話をした。今回が連載の核で、その分担を自動で回す仕組みを作る。結論から言うと、僕は今こういう体制で開発している。監督はClaude、実装はChatGPT側のGPT-5.6、通称「Sol」。そしてコードを書く作業だけが、僕が何もしなくても自動でSolに委譲される。2つのアプリを行き来してコピペする作業は一切ない。この記事では、そのリレーの作り方を最初から最後まで書く。作り方といっても、組んだあとに実装を丸ごとやるのはAIの方で、僕らが掴むのは役割の分け方と指示の出し方の型だけだ。

正直な動機も明かしておくと、コスト面も大きい。Claudeはトークン（一度に使える文章量の上限）が厳しくて、重い実装まで全部Claudeにやらせると、すぐ上限に当たって止まる。一番トークンを食うのはコードを書く作業だから、そこをSol側に逃がす。これが実は、僕にとって最強の節約術になっている。監督のClaudeは考える仕事に集中させて、量をこなす実装は別のAIに回す、という分担だ。

結論第2回は自動化。監督役のAIから、コードを書く作業だけを「サブエージェント」という分身に自動で委譲するリレーの作り方。役割を固定し、鵜呑みにせず実物を検証するのが鉄則。

基本形: Claude Codeを監督にする

土台はClaude Code。ターミナルで動くClaudeの開発ツールで、ファイルを読み書きして、コマンドを実行して、外部のツールを呼び出せる。これをオーケストレーター、つまり現場監督にする。

もう一人の登場人物がCodex CLI。ChatGPT側のコーディング用CLIで、これを通すとSolにコードを書かせられる。前回書いたとおり、僕の体感では実装のスピードとコード生成の速さはSolに分がある。だったら、コードを書く工程だけSolにやらせればいい。

前提として要るのは、Claude Codeが動くこと、Codex CLIが入っていてChatGPT側のアカウントでログインできていること、この2つだけ。それぞれのセットアップは公式の手順どおりで特別なことはないので省くけど、先にターミナルから単体でCodex CLIを叩いてみて、Solがコードを返してくるのを確認しておくとあとが楽だ。リレーが動かないとき、原因がCodex側なのか連携側なのか切り分けられる。

ここで大事なのは、Codex CLIを呼ぶのが人間じゃなくてClaudeだということ。僕はClaudeに「これ作って」と言うだけで、Claudeが設計を固めて、実装が要る部分をCodex CLIに投げて、返ってきたコードを検証して統合する。人間の窓口はClaude一つ。ChatGPT側の画面は開きすらしない。

仕組み: サブエージェントという分身

これを実現しているのがClaude Codeの「サブエージェント」という仕組みだ。サブエージェントは、特定のタスク用に切り出したAIの分身のこと。名前と役割を書いた設定ファイルを所定の場所に置いておくと、本体のClaudeが「この仕事はあの分身の担当だな」と判断した場面で、勝手にその分身を起動して仕事を渡す。

手でコピペすればいいじゃん、と思うかもしれない。Claudeの設計をChatGPTの画面に貼って、返ってきたコードを貼り戻す運用でも、できるにはできる。でもこれ、貼り忘れや貼り間違いが起きるし、何より設計の文脈がコピペした分しか渡らない。プロジェクトの前提を毎回書き直すのは地味にしんどい。サブエージェント化すると、タスクの受け渡しがClaudeの中で完結して、人間は運搬係を降りられる。

僕はここに「codex-coder」という実装専用のサブエージェントを用意している。役割はただ一つで、渡された実装タスクをCodex CLI経由でSolに書かせて、できたコードを本体に返すこと。Claudeに「この機能実装して」と頼むと、裏でcodex-coderが起動して、Codex CLIを叩いて、Solがコードを書いて、成果だけがClaudeの手元に戻ってくる。表から見ると「Claudeに頼んだらコードができた」なんだけど、書いたのはSolという構図だ。

分身とか委譲とか、仕組みの話が続いて難しそうに感じたかもしれない。でも身構えなくていい。実はこの後出てくる設定ファイルも、Claudeに「こういう役割のサブエージェントを作って」と頼めば書いてくれる。人間が仕組みの中身を暗記する必要はどこにもない。

設定の骨組み

codex-coderの設定は、骨だけ抜き出すとこういう形をしている(実物はもう少し細かいけど、幹はこれで全部だ)。

name: codex-coder
description: コード実装を Codex CLI(GPT-5.6 Sol)に委譲する担当
役割:
  - 渡された実装タスクを Codex CLI で gpt-5.6-sol に書かせる
  - できたコードと変更したファイルを報告して返す
  - 設計やレビューはしない(監督のClaudeがやる)
使えるツール: コマンド実行とファイル読み取りに絞る

ポイントは3つある。1つ目は「しないこと」を書くこと。実装担当に設計まで任せると、監督の方針と実装の方針が割れて、統合のときに揉める。分身は仕事を狭く持たせるほど安定する。

2つ目は、使えるツールを絞ること。codex-coderの仕事はCodex CLIを叩いてコードを受け取ることだけだから、それに要る最低限しか持たせない。分身に何でもできる権限を持たせる理由はないし、絞ってある方が想定外の動きをしたときの被害も小さい。

3つ目は、作業ルールを書く指示書の側に「コードを書くタスク(新規実装・リファクタ・バグ修正)はcodex-coderに委譲する」と一行入れておくこと。これがないと、毎回「Solにやらせて」と言わないといけない。この一行があるから、普通に開発を頼むだけでリレーが自動で発動する。自動化の肝は実はこっちだと思う。

ここで「自分に書けるかな」と思った人にこそ言いたいんだけど、この骨組みを自力で書ける必要はない。持っておくのは、しないことを決める、権限を絞る、委譲のルールを一行入れる、という3つの考え方だけ。それをそのままAIに指示すれば、設定はAIが書いてくれる。

リレーの流れ

実際に機能を一つ作るときの流れはこうなる。

Claudeと設計を固める。何を作るか、どうファイルを分けるか、何ができたら完成か。タスク分解までここでやる
実装が要る部分だけ、Claudeがcodex-coderに投げる。ここは自動で、僕は何もしない
SolがCodex CLI上でコードを書き、成果がClaudeに返ってくる
Claudeが返ってきたコードを必ず実物をReadして検証し、それからレビュー・テスト・統合・gitをやる

人間がやるのは1の壁打ちと、4の最後の承認だけ。真ん中の2と3は完全に無人だ。最初にこれが通しで動いたときは、正直ちょっと感動した!

役割分担を固定する

リレーが回り始めたら、分担をブレさせないのが大事になる。僕の分担はこう。

Claude(監督): 設計・タスク分解・レビュー・テスト・統合・git
Sol(実装):    コードを書く作業そのもの
例外:         1〜2行の自明な修正・設定ファイル・ドキュメントは
              Claudeが直接書く(いちいち委譲しない)

例外を作ってあるのは、委譲にもコストがあるからだ。分身を起動してタスクを説明して結果を受け取る往復は、それ自体に時間がかかる。タイポ修正みたいな一瞬で終わる変更まで律儀にリレーすると、かえって遅くなる。だから「自明なものは監督が直接直す」を最初からルールにしておく。

なぜ分けると効くのか

両方に全部やらせればいいじゃん、と思うかもしれない。でも分けた方が速いし、質も上がる。

Claudeが強いのは、長い文脈を保ったままの設計と、細かい指示に忠実な整形と、レビューの丁寧さ。プロジェクト全体の事情を頭に入れたまま「ここはこう直すべき」と言える。一方Solが強いのは、実装そのもののスピードとコード生成の勢い。書き始めてから形になるまでが速い。

つまり、工程ごとに得意なモデルが違う。片方だけで回すと、どこかの工程で不得意な方を我慢して使うことになる。分ければ全工程を得意な側が担当する。あと副次効果として、実装の試行錯誤が監督側の文脈を汚さないのも効く。Solが手元で試行錯誤しても、Claudeには結果だけが届くから、監督は設計の頭のまま居られる。

ちなみに別連載「自分専属のAI秘書を作る」で秘書を動かしている箱の改修も、全部このリレーでやっている。仕組みを一度作ると、どのプロジェクトでも同じ型で回せるのがいい。

鵜呑みにしない。これだけは絶対

最後に、一番大事な話。Solが返してきた成果は、必ずClaudeが実物のファイルをReadで開いて確認してから受け入れる。生成コードを見ずにマージしない、が鉄則だ。

サブエージェントから返ってくるのは「こう実装しました」という報告で、報告は要約であって証拠じゃない。動くように見えて、指示と微妙に違う実装が混ざることは普通にある。指定したのと違う書き方になっていたり、頼んでいない箇所まで気を利かせて書き換えられていたり、この手のズレは生成コードのあるあるだ。しかも報告の文面はいつも自信満々だから、文面だけ読むと通したくなる。

だから4の工程で、Claudeは報告じゃなくファイルの実物を読む。設計と合っているか、余計な変更が混ざっていないかを差分で見て、テストも監督側で流す。ここを省くとリレーは「速いけど信用できない仕組み」になって、結局あとで全部自分で読み直すはめになる。速さは検証込みでワンセット、と覚えてほしい。

次回

リレーの土台はこれで完成だ。第3回は実践編で、どんなタスクをどう投げると気持ちよく回るか、投げ方のコツ、途中で詰まったときの立て直し方みたいな使いこなしをやる。仕組みは今日できたので、次は乗りこなす番だ。

設定の回だったから細かい話が多くなったけど、覚えて帰ってほしいのは手順そのものじゃない。監督と実装を分けるという考え方と、それをAIに指示すれば組み上げまでやってくれるという事実の方だ。