本文へ移動
BenriWorks Lab

開発記事公開日

Claude Code と Codex の分業を、1枚の仕様書で回す

会議机に広げた印刷物を挟んで、2台のノートPCの前に座りこちらを向いている男女の開発者

コードを書くAIとブラウザを操作するAIに、1つの仕事を分けて任せました。両者が読む仕様書をどう書いたか、仕様書の前提が間違っていたときに何が起きたか、人が決める場所をどこに残したかを記録します

AIに仕事を任せると、任せた仕事の外側で困ります。書いてもらったコードは動くのか。本番で届いているのか。届いていないとして、原因はコードなのか設定なのか。この「外側」を誰が見るかを決めないまま任せると、確認の仕事がそっくり人に戻ってきます。

BenriWorksでは、この外側をもう1つのAIに任せる形を試しました。コードを書くのは Claude Code の Fable 5.1、ブラウザで設定と確認を行うのは Codex の GPT-6 Astra です。2つのAIは互いに会話しません。両方が読むのは、リポジトリに置いた1枚の仕様書だけです。

なぜ2つに分けたか

分けた理由は、それぞれの公式ドキュメントに書いてある得意分野が、私たちの仕事の分かれ目と重なっていたからです。

Anthropicのドキュメントは Fable 5.1 を、100万トークンのコンテキストで長いセッションのコーディングと大きなリファクタリングに向くモデルだと説明しています。13のリポジトリを1つのセッションに置いたまま、同じ変更を入れて回る仕事は、この説明のとおりの形をしています。

OpenAIの発表は GPT-6 Astra について、Codex の実行基盤の更新と合わせてブラウザ操作の課題を前モデルより1.9倍速く終えたとしています。GA4の管理画面で設定を変え、16のサイトを開き、リアルタイムの画面を読む仕事は、こちらの形です。

どちらか一方に両方をやらせることもできます。Claude Code にもブラウザを操作する手段はありますし、Codex もコードを書きます。分けたのは能力の問題ではなく、書いた側に確かめさせないためです。コードを書いたAIは、書いたコードを信じます。届いているかを見るのは、書いていない側であるべきでした。

仕様書に書いたこと

仕様書は1つのMarkdownファイルで、topsite のリポジトリに置いています。書いたのは Claude Code で、人が読んで直しました。構造は4つです。

1つ目は担当の明示です。手順ごとに見出しに担当を付けました。「手順3【コード / Claude】」「手順4【ブラウザ / Codex】」という具合です。どちらのAIも、自分の担当でない手順は読むだけで手を出しません。

2つ目は決定事項の表です。プロパティは1つにする、ストリームも1本にする、測定IDは環境変数でなくコードに直書きする、既存3アプリのコードは触らない。それぞれに理由を1行添えました。理由がないと、AIは「より良い」と判断した方へ勝手に寄せます。

3つ目は確認項目です。16サイトのURLを表にして、確認欄を空けておきました。疎通確認の手順には、タグの存在確認と、データ到達の確認と、二重計上の確認を分けて書き、それぞれの見方を指定しました。

4つ目は、AIが判断してはいけない場所です。マージは人が行う、GA4で新しいストリームを作らない、アカウントの権限に関わる操作は承認を求める。この項目は、後で効きました。

仕様書を中心に置いた分業の流れ図。Claude Codeがコードを書いてプルリクエストを出し、人がマージし、Codexがブラウザで疎通確認をして報告書を書き、その報告書をもとにClaude Codeが修正のプルリクエストを出し、仕様書を更新する。人はマージと承認の位置に立つ
2つのAIは会話しない。仕様書と報告書を介して、人を挟んで回る

仕様書が間違っていたとき

仕様書には、調査結果として「CSPはどのリポジトリにも設定なし」と書いてありました。インラインのスクリプトを足しても問題が起きない、という根拠に使った一文です。

これは間違いでした。2つのリポジトリが本番でCSPを適用していて、計測タグの配信元と送信先を許可していませんでした。調べたときにソースの中の文字列を検索し、見つからなかったので「なし」と書いた。実際には、1つは純関数の中で組み立てられ、もう1つはミドルウェアの文字列の中にありました。検索の仕方が甘かったのです。

間違いを見つけたのは Codex でした。報告書には、公開URLのHTTPレスポンスから取ったCSPヘッダーがそのまま転記され、「仕様書の前提は本番のHTTPレスポンスと一致しない」と書いてありました。仕様書を信じず、本番の応答を見たわけです。詳しくは「GPT-6 Astra の Codex に、16サイトの疎通確認を任せた記録」にあります。

ここで分業が効きました。書いた側の Claude Code は、自分が「なし」と書いた前提を疑う理由を持っていません。ブラウザ側の Codex は、仕様書がどう書いてあろうと、目の前のヘッダーを読みます。同じAIに両方をやらせていたら、自分の調査結果と矛盾する証拠を、自分で探しに行ったかどうか分かりません。

報告書を受け取った Claude Code は、修正のプルリクエストを出したうえで、仕様書の該当行を訂正しました。「なし」を消して、実際にあった2件と、なぜ見落としたかを書いています。次に同じ仕様書を読むAIが、同じ検索の仕方をしないためです。

人が立つ場所

仕様書で「AIが判断してはいけない」と書いた項目は、実際に人のところへ来ました。

Search Console との連携では、GA4の画面に「このリンクによってプロパティにアクセスできる全員が検索データを参照できる」と表示されました。Codex はここで止まり、閲覧範囲が広がることを運営者に提示し、承認を受けてから送信しています。押せるボタンと、押してよいボタンの区別は、仕様書の1行で付きました。

家族プランナーの修正では、Claude Code が「子どもの情報をURLへ書き戻すのをやめる」変更を提案しました。二重計上と、個人情報を含むクエリの送信を止める修正ですが、アドレスバーが入力に追従しなくなるという挙動の変更を含みます。これはプルリクエストの本文に「ご確認ください」として書かれ、マージの判断は人に残っています。

ブログの記事も同じ線引きです。この記事を含めて下書きはAIが書き、公開の判断は運営者が行います。事実の情報源はリポジトリと画面と報告書に限り、確認できないことは推測で埋めずにTODOとして残し、運営者が公開前に確かめます。

案内役の女性が仕様書を手に持って立っているバナー。「2つのAIに、1つの仕事を分けるなら」「両方が読む仕様書と、人が立つ場所」というコピーが入っている

仕様書に足したもの

今回の一巡で、仕様書に2つの欄を足しました。

ひとつは「実施記録」です。何を確認し、何が届き、何が届かなかったか。原因と修正のプルリクエストの対応表。そして担当別の残タスクです。次に読むAIが、どこまで終わっているかを仕様書だけで分かるようにしました。

もうひとつは、確認項目の各行に「何を証拠にしたか」を書く欄です。Codex の報告書が、届いたかどうかの判定に「リアルタイムにページタイトルが出た」という証拠を添えていたのを、そのまま形式にしました。判定だけが書かれた確認表は、次の人が信じるか疑うかを選ぶしかありません。証拠が添えてあれば、疑うべき行だけを疑えます。

仕事の外側に戻る

AIに任せた仕事の外側を、誰が見るか。

今回の答えは「書いていないほうのAIが見て、人は証拠を読んで決める」でした。2つのAIを使う費用は、それぞれの公式料金で入力100万トークンあたり10ドル、出力50ドルです。安くはありません。ただ、書く時間が減った分を確かめる時間に回せたかどうかは、費用とは別の帳簿に付いています。私たちの帳簿では、13サイト分の計測と3件の不具合の発見が、1週間の中に収まりました。

仕様書はまだ1枚です。次の仕事で2枚目が要るかどうかは、1枚で足りなくなったときに考えます。

参照した公式情報

  • Anthropic「What's new in Claude Fable 5.1」(platform.claude.com)
  • Claude Code ドキュメント「Overview」「Model configuration」(code.claude.com)
  • OpenAI「GPT-6 Astra: A new generation of intelligence」(openai.com、2026年9月3日)
  • OpenAI API「GPT-6 Astra」モデルページ(developers.openai.com)

こんな記事も読まれています