Codex・Claude Codeに全部任せると、なぜ開発は迷走するのか？AI開発を安定させる工程設計

CodexやClaude Codeを使い始めると、開発速度が一気に上がります。

コードベースを調べ、複数ファイルを編集し、コマンドを実行し、テストまで回してくれる。少し前なら数日かかっていた変更が、数時間で形になることも珍しくありません。

ところが、開発規模が少し大きくなると、別の問題が起きます。

「Planを作らせたのに、途中から違う設計になっている」

「大量のコードは増えたが、肝心の機能が完成していない」

「修正するたびに別の場所が壊れる」

「CodexとClaude Codeのどちらへ任せるべきか分からない」

こうした失敗を見ると、より賢いモデルへ替えれば解決するようにも思えます。

ただ、私は少し違うと考えています。

AI開発の品質を決めるのは、CodexとClaude Codeのどちらが上かではありません。要件、計画、実装、検証、レビュー、権限をどう分離し、接続するかです。

AIへコードを書かせる技術だけでは足りません。

間違った方向へ進んだときに早く止まり、必要なら上流へ戻り、最後に本当に目的を達成したか確認できる「開発工程」が必要です。

AIがコードを書けることと、全部任せてよいことは違う

CodexもClaude Codeも、単なるコード補完ツールではありません。

Codexは、コードベースを探索し、Planを作り、ファイルを変更し、テストやレビューを実行できるエージェント型の開発環境です。Claude Codeも、ファイルの読み取り、編集、コマンド実行、開発ツールとの連携を行うエージェント型コーディング環境として提供されています。

能力が高まったからこそ、任せられる範囲も広がりました。

ただし、任せられることと、全部を一つの連続タスクとして任せてよいことは同じではありません。

例えば、一つのAIへ次の仕事をまとめて任せたとします。

• 曖昧な要求を解釈する

• 既存コードを調査する

• アーキテクチャを決める

• タスクを分解する

• コードを書く

• テストを書く

• 統合する

• 自分の実装をレビューする

• 完成したか判定する

この構造では、最初の要件解釈が間違っていた場合、後続工程も同じ誤解を引き継ぎます。

しかも、実装者とレビュアーが同じ会話履歴や前提を共有していれば、最初の見落としを最後まで発見できない可能性があります。

AIが無能だからではありません。

一人の担当者に、要件定義、設計、実装、QA、監査、承認をすべて担当させている構造が危険なのです。

なぜ長いセッションほど迷走しやすくなるのか

Claude Codeの公式ベストプラクティスでは、コンテキストウィンドウが埋まるにつれて、以前の指示を忘れたり、誤りが増えたりする可能性があると説明されています。

会話だけでなく、読み込んだファイルやコマンド出力もコンテキストを消費します。長時間のデバッグや大規模なコード探索では、それだけで大量の情報が蓄積します。

これはClaude Codeだけの特殊な問題というより、有限のコンテキストで動くAIエージェント全般に関係する設計上の制約です。

長い開発では、次の問題が重なります。

• 最初の要件が会話の奥へ追いやられる

• 実装途中の暫定判断が事実のように残る

• 大量のログや調査結果が重要情報を埋もれさせる

• 途中で変わった前提が整理されない

• 失敗した方針へ投じた作業量が増え、撤回しにくくなる

したがって、長いタスクを単に「高い推論強度で長時間走らせる」だけでは不十分です。

節目ごとに情報を整理し、検証し、必要なら新しいコンテキストへ引き継ぐ必要があります。

「Planを作れば安全」は、半分だけ正しい

複雑な開発では、いきなりコードを書かせず、Planを先に作る。これは有効な方向です。

OpenAIは、複雑、曖昧、説明しにくいタスクでは、CodexのPlanモードを使い、実装前にコンテキストを集め、必要な質問を行い、計画を作ることを推奨しています。

Anthropicも「探索し、計画し、その後コードを書く」という順序や、変更がディスクへ反映される前にPlanを確認するワークフローを公式に示しています。

ただし、すべての変更に重いPlanが必要なわけではありません。

誤字修正や局所的な設定変更まで、長大な要件書と複数段階の承認を要求すれば、AIによる速度向上を打ち消します。

Planが特に有効なのは、次のような場合です。

• 要求が曖昧

• 複数ファイルや複数機能へ影響する

• 既存設計の理解が必要

• 認証、決済、個人情報などの高リスク変更

• データモデルやAPI契約に触れる可能性がある

• 実装方法が複数あり、選択が必要

• 失敗時の手戻りが大きい

そして、Planには粒度の違う二つのものがあります。

危険な巨大Plan

危険なのは、まだ確認できていない上流判断まで一度に決めるPlanです。

• 顧客要求の解釈

• 製品仕様

• UX

• API

• データモデル

• アーキテクチャ

• セキュリティ

• 実装手順

• リリース方法

これらを一つの長いPlanへ詰め込み、そのまま長時間実行させると、途中で前提が変わっても、既存Planを延命する方向へ進みやすくなります。

コードは増えているのに、目的へ近づいているか分からない状態です。

安全な局所Plan

一方、安全な局所Planは、すでに承認された上流判断を、今回の実装単位へ変換します。

• 今回変更する範囲

• 変更しない範囲

• 読むべきファイル

• 変更候補のファイル

• 既存実装との関係

• 実装順序

• 各段階の検証方法

• ロールバック方法

• 実装を停止する条件

つまり、Planは要件定義や製品設計の代わりではありません。

承認済みの実装契約を、検証可能な作業手順へ落とすものです。

コードを書く前に「実装契約」を決める

中規模以上の開発では、Planモードへ入る前に、最低限の上流設計が必要です。

ここでいう上流設計は、分厚い仕様書を大量に作ることではありません。

AIが勝手に埋めてはいけない判断を、人間とAIで先に確定することです。

最低限、次を明確にします。

何を達成するのか

機能名だけでなく、誰の何が変われば成功なのかを決めます。

「プロフィール画像を追加する」だけでは足りません。

誰がアップロードできるのか、どこへ表示するのか、未設定時はどうするのか、既存認証や保存期間との関係は何かまで確認します。

何を扱わないのか

AI開発では、非スコープが特に重要です。

プロフィール画像の追加を依頼したのに、認証基盤、ユーザーテーブル、画像処理基盤まで再設計されれば、作業は急速に膨らみます。

何をもって完了とするのか

「コードを書いた」は完了ではありません。

• 受入条件を満たした

• 必要なテストが通った

• 型検査、Lint、Buildが通った

• 既存機能が壊れていない

• 必要な手動確認が終わった

• ロールバック方法がある

• 必要な文書が更新された

まで決めます。

OpenAIも、Codexへの依頼にはGoal、Context、Constraints、Done whenを含めることを推奨しています。

Anthropicも、AI自身が実行できるテスト、Build、Lint、画面比較などの検証手段を与えることが、自律的な修正ループの鍵だと説明しています。

何を変更してはいけないのか

API、データモデル、セキュリティ方針、使用ライブラリ、既存画面の挙動など、今回の実装で勝手に変更してはいけない契約を明示します。

この境界があるからこそ、局所Planが妥当か、実装が逸脱していないかを判定できます。

永続ルール、上流設計、局所Planを混ぜない

CodexにはAGENTS.md、Claude CodeにはCLAUDE.mdがあります。

どちらも、毎回繰り返したくないプロジェクト固有の指示を保持するための仕組みです。

OpenAIは、AGENTS.mdへリポジトリ構造、実行方法、Build・Test・Lintコマンド、コーディング規約、禁止事項、完了確認方法などを置くことを推奨しています。

また、短く正確に保ち、タスク固有のPlanやレビュー方法は別文書へ分ける考え方を示しています。

Anthropicも、CLAUDE.mdをセッションを越えて読み込むプロジェクト指示として位置づけています。

一方で、CLAUDE.mdは強制設定ではなくコンテキストであり、特定の操作を確実に禁止したい場合はHookなどを使うよう説明しています。

私は、次の3層を分けるべきだと考えています。

1. プロジェクト契約

比較的変わりにくい内容です。

• リポジトリ構造

• コーディング規約

• テストコマンド

• セキュリティ原則

• 禁止事項

• PR・レビューの要件

• 完了確認方法

2. 上流設計

今回の機能や変更について、人間が承認する内容です。

• Goal

• スコープ

• 非スコープ

• UX

• API

• データ

• セキュリティ条件

• 受入条件

• リリース・ロールバック条件

3. 局所Plan

承認済みの上流設計を、実際の作業へ変換します。

• 読むファイル

• 変更するファイル

• 実装順序

• 検証方法

• 停止条件

これらを一つの巨大な指示ファイルへ詰め込むと、何が恒久ルールで、何が今回だけの判断か分からなくなります。

AI開発を7段階へ分ける

AI開発を安定させる中心は、工程の分離です。

ここから示す「Goal監査」は、CodexやClaude Codeの公式機能名ではありません。

公式ドキュメントが推奨するPlan、検証、diffレビュー、権限管理などを、開発目的との整合まで含めて整理した本記事上の工程概念です。

1. 上流設計を確定する

何を作るか、何を作らないか、どう検証するかを決めます。

2. コードベースを探索する

既存の構造、類似機能、依存関係、テスト方法を調べます。

Claude Codeには読み取り専用のExploreサブエージェントがあり、探索をメイン会話から分離できます。Codexも、複雑な調査を専門的なサブエージェントへ分割できます。

3. 局所Planを作る

上流設計とコードの現状を、具体的な変更手順へ変換します。

4. Planをレビューする

実装前に、要件漏れ、過剰な変更、既存機能の見落とし、検証不足がないか確認します。

ここでは「よく書けたPlanか」ではなく、このPlanで実装を開始してよいかを判定します。

5. 実装し、節目ごとに検証する

最後にまとめて確認するのではなく、意味のある節目ごとにテスト、Lint、型検査、Build、画面確認などを行います。

AIへ自己検証させるには、成功・失敗を判定できる信号が必要です。テストやBuild結果がなければ、AIは「見たところ完成している」という曖昧な基準で止まります。

6. 実際のdiffをレビューする

レビューでは、実装担当の説明よりも、元要件、承認済みPlan、Git diff、実ファイル、テスト、実行結果を確認します。

Codex CLIのレビュー機能は、未コミット変更、コミット、基準ブランチとの差分を、作業ツリーを書き換えずにレビューできます。GitHub上のCodexレビューも、PRのdiffとAGENTS.mdのレビュー指針を読み、重大度の高い問題に絞って指摘します。

7. Goalを達成したか監査する

diffが正しくても、目的を達成していない場合があります。

例えば、要求された画面は表示されても、実際の利用フローでは使えない。テストは通るが、権限条件が間違っている。機能は動くが、障害時に復旧できない。

最後に確認するのは「コードが正しいか」だけではありません。

• 利用者の問題は解決したか

• 受入条件を満たしたか

• 非機能要件を満たしたか

• 本番投入の準備ができているか

• ロールバックできるか

• 人間承認が必要な事項は残っていないか

まで確認します。

完了報告は、証拠ではなく主張として扱う

AIは、かなり自然な文章で完了報告を書きます。

「すべての要件を実装しました」

「テストは正常に通過しました」

「既存機能への影響はありません」

しかし、この文章自体は証拠ではありません。

確認すべきなのは、

• 実際にどのファイルが変わったか

• 要件と差分が対応しているか

• テストは何を検証しているか

• 実行結果が存在するか

• 未確認事項が隠れていないか

です。

これは人間の開発でも同じです。

ただ、AIは短時間で大量のコードと説明を生成できるため、自己申告をそのまま受け入れたときの影響が大きくなります。

実装担当の報告は、レビュー開始時の主張として扱う。承認の根拠にはしない。

独立レビューは「別モデル」でなくても成立する

同じAIへ、

1. Planを作らせる

2. 実装させる

3. レビューさせる

4. 自分で修正させる

5. 完成を承認させる

という流れを任せると、最初の誤解を最後まで共有する可能性があります。

Planで見落とした要件を、実装でも見落とし、レビューでも問題なしと判定する。自分が書いたテストを十分だと評価する。捨てるべき設計を部分修正で延命する。

だからといって、必ずCodexとClaude Codeを組み合わせなければならないわけではありません。

独立性は、次の方法でも高められます。

• 別モデル

• 同じモデルの別セッション

• 別のサブエージェント

• CodexのDetached review

• 実装履歴を持たない新規コンテキスト

• 人間のコードレビュー

• CIや静的解析による機械的検証

Codexでは、レビューを別チャットへ分離したり、レビュー専用モデルを設定したりできます。Claude Codeでも、サブエージェントに専用の指示とツール制限を与え、探索や専門レビューをメイン会話から切り離せます。

ただし、別セッションにしただけで完全に独立するわけではありません。

同じ誤った要件、同じ不十分なテスト、同じ自己説明だけを渡せば、別AIでも同じ結論へ到達する可能性があります。

レビュー側には、元要件、承認済みPlan、diff、実ファイル、テスト結果を渡し、実装者の長い自己弁護へ引っ張られないようにします。

複数AIは「多数決」ではなく、役割分担に使う

Codex、Claude Code、別のAIへ同じ質問を投げ、二対一で決める。

これは一見すると安全に見えます。

しかし、複数モデルが同じ不足情報、同じ誤った前提を読めば、同じような間違いへ到達する可能性があります。

複数AIを使う価値は、多数決ではなく、責任を分けられることです。

• 探索担当：既存コード、類似機能、依存関係を調べる

• 計画担当：上流契約を局所Planへ変換する

• 実装担当：承認済みPlanの範囲だけを変更する

• 仕様反証担当：要求を満たしていない証拠を探す

• 簡素化担当：重複、不要な抽象化、肥大化を探す

• セキュリティ担当：認証、認可、入力、秘密情報、依存関係を見る

• 最終監査担当：Goalと受入条件を確認する

Codexの公式サブエージェント例でも、セキュリティ、コード品質、バグ、競合、テスト不安定性、保守性を別エージェントへ分ける使い方が示されています。

ただし、エージェントを増やせば自動的に品質が上がるわけではありません。

調整コスト、トークン消費、重複調査、結果の矛盾、統合作業も増えます。

小さな変更に多数のAIレビュアーを付ければ、品質向上より運用コストの方が大きくなります。

並列作業では、編集環境も分ける

複数エージェントを並列で動かすときは、会話だけを分けても十分ではありません。

同じ作業ツリーで複数エージェントが同時にファイルを変更すると、上書き、競合、未完成コードの参照が起こります。

Codexのworktree機能は、同じGitリポジトリ内に独立した作業コピーを作り、複数チャットの編集が互いに干渉しないようにします。Claude Codeも、各セッションやサブエージェントを別worktreeへ隔離できます。

ただし、worktreeが防ぐのは主にファイル編集の衝突です。

次までは自動的に解決しません。

• 二つの実装が異なる設計思想を採用する

• 同じAPI契約を別々に変更する

• 統合後に機能同士が矛盾する

• 共通依存の更新で片方が壊れる

• マイグレーション順序が競合する

したがって、並列化するときは次も決めます。

• 各エージェントの担当範囲

• 編集してよいディレクトリ

• 共通契約

• 依存する成果物

• 完了条件

• 統合順序

• 競合時の判断者

• 最終統合の責任者

「複数AIを起動すること」と「並列開発を設計すること」は別です。

通常レビューと敵対的レビューは違う

通常レビューは、コードを読み、問題があれば指摘します。

敵対的レビューは、最初から次の前提を置きます。

敵対的という言葉は、攻撃的な文章を書くことではありません。

反証、レッドチーム、ネガティブテストに近い考え方です。

Anthropicの公式ベストプラクティスにも、複数セッションを使った敵対的レビュー工程が明示されています。

仕様反証

• 表面上動くが、要求と違わないか

• 要件の一部だけを満たしていないか

• 勝手に仕様を追加していないか

• 例外条件を落としていないか

セキュリティ

• 認証と認可を混同していないか

• 入力検証は十分か

• 秘密情報がログやコードへ残っていないか

• ファイルパスや外部通信に危険がないか

• 依存パッケージへ問題がないか

簡素化

• 既存機能と重複していないか

• 不要な抽象化を増やしていないか

• 将来用途を理由に過剰設計していないか

• 同じ原因へ複数の局所修正を重ねていないか

テスト反証

• テストが実装を追認しているだけではないか

• 本来の仕様を検証しているか

• 異常系、境界値、権限違反が含まれるか

• モックの中だけで成功していないか

運用破壊

• 再実行しても壊れないか

• 途中失敗から復旧できるか

• 外部API障害でどうなるか

• 同時実行で競合しないか

• ロールバックできるか

• ログから原因を追えるか

すべての変更で全巡回を行う必要はありません。

認証、決済、個人情報、データ移行、権限変更、基幹業務など、失敗時の損失が大きい変更で選択的に使うべきです。

行数ではなく「承認済み境界からの逸脱」を監視する

AI開発の肥大化対策として、

• 300行以下

• 5ファイル以下

• 小さなPRだけにする

といったルールが提案されることがあります。

小さい差分は一般にレビューしやすく、ロールバックもしやすいので、有効な方向です。

ただし、行数やファイル数だけを絶対基準にすると、本質を外す場合があります。

本当に止めるべきなのは、コードが一定行数を超えたときではありません。

承認済みの上流契約を越えて、AIが別の設計を始めたときです。

例えば、次の兆候が出たら止めます。

• 一画面の修正が共通コンポーネント全面再設計へ広がった

• API形式の変更が必要になった

• データモデルを変え始めた

• 新しい状態管理や基盤ライブラリを導入し始めた

• セキュリティ方針を変える必要が出た

• 同じ不具合へ局所修正を繰り返している

• 変更全体を一つの因果関係として説明できない

• Planにないサブシステムへ影響が広がった

このとき、AIへ「そのままうまく直して」と頼むのではなく、局所Planを停止し、上流設計へ戻ります。

• 要件が変わったのか

• 既存設計の理解が間違っていたのか

• API契約を更新する必要があるのか

• アーキテクチャ判断が必要なのか

• 人間承認が必要なのか

を確認してから再計画します。

指示ファイルと強制機構を使い分ける

「編集後は必ずフォーマットする」

「テストを実行する」

「秘密情報を読み込まない」

こうしたルールをAGENTS.mdやCLAUDE.mdへ書くことは有効です。

ただし、これらは基本的にAIへ与える指示です。必ず実行される強制機構ではありません。

確実に守る必要があるものは、次の仕組みへ移します。

• Formatter

• Linter

• 型検査

• テスト

• Git hooks

• CI

• Claude Code Hooks

• Sandbox

• 権限ルール

• 秘密情報スキャン

• Branch protection

Claude CodeのHooksは、ツール実行前後、セッション開始・終了、サブエージェント開始・終了などの時点で、コマンド、HTTPエンドポイント、LLM判定を自動実行できます。フォーマット、危険なコマンドの遮断、通知、別モデルによるレビューなどに利用できます。

ただし、Hook自体もコードです。

誤ったHookは正しい操作を止めたり、危険なコマンドを実行したりします。強制機構へ昇格する前に、入力、終了コード、対象パス、秘密情報、失敗時の挙動を確認する必要があります。

AI開発の品質は、権限設計でも決まる

高性能なAIへ広い権限を与えれば、速く作業できます。

同時に、間違った方向へ速く進むこともできます。

Claude Codeは、利用可能なツール、ファイル、ドメインを細かく制御する権限設定と、Bashのファイル・ネットワークアクセスをOSレベルで制約するSandboxを提供しています。

公式文書では、両者を防御層として組み合わせることが推奨されています。

Codexも、Sandboxと承認ポリシーを設定し、作業ごとに読み書き可能な範囲やコマンド承認条件を制御できます。OpenAIは、最初は権限を狭く保ち、信頼できるリポジトリや明確な必要性がある場合にだけ広げることを推奨しています。

権限設計では、次を決めます。

• どのディレクトリを読めるか

• どこへ書き込めるか

• どのコマンドを実行できるか

• ネットワークへ接続できるか

• 秘密情報へ触れられるか

• データ削除や移行を実行できるか

• Git pushや本番反映を許可するか

• どの操作で人間承認を要求するか

「AIを信頼するか」という精神論ではありません。

失敗しても被害を限定できる境界を作ることです。

コミュニティの実践は、答えではなく仮説として使う

Redditなどのコミュニティでは、次のような実践が繰り返し共有されています。

• 非自明な作業はPlanから始める

• フェーズを分けて一段階ずつ実行する

• 既存コードを読ませてから要件を詰める

• 長いセッションを適切な地点で区切る

• CLAUDE.mdなどへ繰り返すルールを保存する

• worktreeで並列作業を分離する

• 別セッションや別AIへレビューさせる

実際に、Planを重視し、問題が起きたらPlanモードへ戻る運用や、Plan・実装・レビューを分ける運用が複数の利用者から報告されています。

ただし、コミュニティ投稿は統制された比較実験ではありません。

投稿者ごとに、技術力、リポジトリ、モデル、設定、タスク、成功基準が異なります。高評価の投稿であっても、そのまま普遍的なベストプラクティスにはできません。

私は、次の順序で採用するのがよいと考えています。

1. 公式仕様と公式推奨を確認する

2. コミュニティから失敗例と運用候補を集める

3. 自分の案件で小さく試す

4. 手戻り率、レビュー指摘、検証時間、コストを記録する

5. 再現したものだけルールや自動化へ昇格する

CodexとClaude Codeは、どう使い分ければよいのか

ここまで読むと、「では、計画はClaude Code、実装はCodexに固定すればよいのか」と考えるかもしれません。

私は、固定しない方がよいと考えています。

モデルと製品の性能は更新されます。コードベースや開発環境との相性もあります。

評価すべきなのは、名前ではなく次の能力です。

• 要件理解

• コードベース探索

• Planの具体性

• 指示遵守

• 実装精度

• デバッグ能力

• 簡素化能力

• テスト設計

• レビュー精度

• ツール・環境との統合

• コスト

• 完遂時間

例えば、ある案件ではClaude Codeで上流調査とPlanレビューを行い、Codexで実装し、別Codexでdiffレビューを行う構成が合うかもしれません。

別の案件では、CodexでPlanと実装を行い、Claude Codeの別セッションで仕様反証と簡素化レビューを行う方がよいかもしれません。

重要なのは、特定モデルを上司、別モデルを部下と固定することではありません。

案件ごとに責任を分け、各工程に適したモデルと実行環境を配置することです。

規模とリスクに応じて工程を変える

すべての変更に重い工程を適用すると、AIによる速度向上を失います。

軽微な変更

• 対象を確認する

• 実装する

• 自動検証を実行する

• diffを確認する

誤字修正、単純な表示変更、限定的な設定変更などです。

中規模変更

• Goal、スコープ、非スコープを確認する

• コードを探索する

• 局所Planを作る

• Planを別セッション等で確認する

• 実装する

• 節目ごとに検証する

• diffレビューを行う

• 受入条件を確認する

複数ファイルへまたがる機能追加、既存機能の変更、外部API連携などです。

大規模・高リスク変更

• 上流設計と安全条件を確定する

• 局所実装単位へ分ける

• Planを独立レビューする

• 権限と実行環境を限定する

• worktree等で編集を分離する

• マイルストーンごとに検証する

• 通常diffレビューを行う

• 必要な敵対的レビューを行う

• Goalを監査する

• 人間が最終承認する

認証、決済、個人情報、データ移行、権限管理、基幹システムなどです。

AI開発で人間が保持すべきもの

AIがコードを書く速度は、今後も上がるでしょう。

Plan、テスト、レビュー、修正も、さらに自動化されていくはずです。

それでも、人間の役割がなくなるわけではありません。

人間が保持すべきなのは、すべてのコードを手で書くことではなく、次の責任です。

• 何を作るか決める

• 何を作らないか決める

• 成功条件を決める

• どこまでAIへ権限を与えるか決める

• どの証拠で承認するか決める

• いつ止めるか決める

• 結果に責任を持つ

• 失敗を次のルールやテストへ変える

AIへ実装を委任しても、目的、評価、停止、回復、責任まで手放してはいけません。

まとめ

CodexとClaude Codeのどちらが優れているかは、もちろん無視できない論点です。

しかし、開発が迷走したとき、最初に疑うべきものはモデルだけではありません。

• 要件が曖昧なまま実装を始めていないか

• 巨大Planへ上流判断まで詰め込んでいないか

• 永続ルールと今回のPlanが混ざっていないか

• 実装者とレビュアーが同じ前提を共有しすぎていないか

• コンテキストが肥大化していないか

• 最後にまとめて検証していないか

• 完了報告を証拠として受け入れていないか

• 承認済みの範囲を越えたときに止められるか

• 権限と実行環境を限定できているか

• 並列化後の統合責任が曖昧ではないか

を確認するべきです。

AI開発エージェントに必要なのは、賢い一人へ全部任せることではありません。

上流設計、探索、局所Plan、実装、検証、独立レビュー、Goal監査を分け、間違ったときに上流へ戻れる工程を作ることです。

モデルは進化します。

だからこそ、特定モデルの性能だけへ依存する運用ではなく、モデルが変わっても機能する開発工程を持つことが、長期的には最も強いAI開発能力になると私は考えています。

出典・参考資料

• OpenAI「Codex Best practices」

• OpenAI「Codex CLI」

• OpenAI「Codex code review in GitHub」

• OpenAI「Codex Subagents」

• OpenAI「Codex Worktrees」

• Anthropic「Best practices for Claude Code」

• Anthropic「Common workflows」

• Anthropic「How Claude remembers your project」

• Anthropic「Create custom subagents」

• Anthropic「Run parallel sessions with worktrees」

• Anthropic「Automate actions with hooks」

• Anthropic「Configure permissions」