エージェントを乗り換えて、何が変わり、何が変わらなかったか

第8回の最後に、こう書きました。

より賢いモデルが出れば不要になる工夫は、この中に一つも無い。

連載を書き終えたあと、実装エージェント側のプロバイダを切り替えました。 TAKT の runtime.yaml で、provider.profiles の既定を Claude から Codex（gpt-5.6-luna）へ変更し、対話AI側は Claude Code のまま残しました。

その後6日間・11セッションを回した結果を、この番外編で書きます。 期せずして、連載の主張を著者自身が検証する形になりました。

0. 先に断っておくこと

これは「Claude Code と Codex のどちらが優れているか」という記事ではありません。

比較には対照実験が要ります。しかし切り替えの前後では、扱っている課題も、文書の規模も、開発のフェーズも違います。同じ作業を両方でやって比べたわけではないので、優劣は書けません。 連載で「実測してから書く」と繰り返しておきながら、ここで印象論を書くわけにはいきません。

書けるのは「切り替えたときに、何が影響を受け、何が影響を受けなかったか」だけです。 それでも、そこには一つはっきりした結果が出ました。

1. 変わらなかったもの——工程のすべて

結論から書くと、第1回から第8回までに書いた工程は、一つも書き換えていません。

R0調査 → 仕様書 → build-step → 独立検証 → コミット
→ デプロイ → 実機確認 → 課題管理表の更新

この流れも、三層構造（人・対話AI・実装エージェント）も、仕様書を条件で書くことも、完了確認で止めることも、そのまま通用しました。

それどころか、連載で書いた原則が必要になる場面が、切り替え後も同じ頻度で発生しています。

連載で書いたこと	切り替え後に起きたこと
第3回：報告値をそのまま転記しない	「フェンス行数364で不変」という報告に対し、実測は前後とも356だった
第3回：報告の状態表示を信じない	ステータスが「実装未着手」でも、実測すると正しく反映されていた（複数回）
第8回：発見は広く、是正は狭く	対象を2課題に限定した依頼で、指示していない別課題の食い違いまで4文書すべてで自主的に是正された
第5回：既存の失敗と自分の変更を切り分ける	変更を退避した状態でも同じ5スイート29件が失敗することを確認し、無関係と実証した

プロバイダが変わっても、報告値と実測値は食い違います。ステータス表示は実態とずれます。指示範囲を超えた自主是正は起きます。 これらは特定のモデルの癖ではなく、「エージェントに作業させて報告を受け取る」という構図そのものに付随する性質であると考えるほうが、実測に合っています。

2. 変わったもの①——トークン上限という物理的な壁

一方で、切り替えによって新しく必要になった工夫が2つあります。1つ目は、依頼の分割です。

まず、対象の規模を示しておきます。実装ファイルのみ（テストを除く）で161ファイル・54,678行・2.21MBです。内訳の主なものは次のとおり。

領域	ファイル数	行数
`frontend/src/pages`	19	12,035
`backend/src/routes`	22	11,735
`backend/src/services`	25	6,161
`frontend/src/components`	16	3,731
`backend/src/lib`	24	2,214
（ほか）	55	18,802
合計	161	54,678

画面1本あたり、エンドポイント1本あたりのファイルが厚いのです。 frontend/src/pages は1ファイル平均633行、backend/src/routes は同533行です。第1回で書いた設計文書4本（約84万字）と合わせると、「関連しそうなものをまとめて読ませる」という依頼の出し方が、そもそも成立しない規模になっています。

その前提で、設計文書4本を横断して自己矛盾を洗い出すラウンドを依頼したところ、2回連続で異常終了しました。

Request too large for gpt-5.6-luna ... tokens per min (TPM): Limit 200000

詳細設計書1本だけで6,700行を超えるため、全文読み込みを前提とした依頼が分あたりのトークン上限に抵触していました。

対処は、依頼を「1回1観点」まで絞ることでした。 全文を読ませるのをやめ、確認したい観点ごとに該当する章・節番号を明示し、部分的に読ませる形へ分割しました。これで解消しました。

この経験から得た一般則は、意外と単純です。4文書を横断する走査ラウンドは、最初から観点ごとに分割して依頼するほうが、手戻りが少ない。「まとめて1回で」を優先すると、かえってやり直しの回数が増えます。そして「やり直しの回数」は、第7回で書いたとおり、人の実行回数として跳ね返ります。

3. 変わったもの②——プロンプトの問題に見えて、設定の問題だった

2つ目のほうが、教訓としては大きいものです。

切り替え後、依頼文に禁止の文言を一切含めていないにもかかわらず、エージェントが「ツール使用が禁止されている」という趣旨の報告だけを返し、調査も実装も一切せずに終了するという事象が、複数回発生しました。

当初の対処は、運用での回避でした。依頼文の冒頭に、次の一文を足します。

本タスクではファイルの読み取り・調査・編集にツールを使用してください。ツール使用は禁止されていません。

これで実際に解消しました。 解消したのだから、原因は依頼文にあると考えたくなります。

しかし、原因は依頼文ではありませんでした。 後日、TAKT のワークフロー設定4ファイルを見直したところ、runtime.yaml の provider.profiles.*.options.allowed_tools——エージェントに許可するツール（Read・Glob・Grep・Edit・Write・Bash）を列挙する箇所——に不足があった可能性が浮上しました。

許可リストに Bash や Edit が無ければ、エージェントの側からは「一部の操作を禁止されている」ように見えます。 依頼文に何の制約も書かれていなくても、です。設定を見直したあとのセッションでは、この事象は再発していません。

この一件から、運用の目安を一つ加えました。

依頼文の書式を2回調整して改善しなければ、3回目を試す前に、ワークフロー・ランタイム設定の側を点検する。

「プロンプトを工夫すれば直る」ように見える不具合が、実は実行環境の設定に由来していることがあります。 そして回避策が効いてしまうと、根本原因は見つからないまま残り続けます。回避策が効いたことは、原因が特定できたことを意味しません。

4. 導入時の前提条件

実務的な注意点を一つ。TAKT から Codex を使うには、ChatGPT の契約とは別に、エージェント向けの契約が必要になります。

runtime.yaml の provider.profiles はプロファイル単位で構成されており、既定プロファイルを Codex に、別プロファイルを Claude に割り当てて併存させることもできます。切り替えは設定ファイル1本の変更で済みますが、その手前に契約の確認が要ります。 試す前に把握しておくと、段取りが変わります。