2026年2月時点のコーディングエージェント活用状況とワークフロー比較
(calv.info)- コーディングエージェント選定の中核基準は、モデル性能そのものではなく、ユーザーの可処分時間と自律実行時間へと移りつつあり、Claude CodeとCodexを状況に応じて併用している
- Opusはコンテキストウィンドウ管理とツール利用に強みがあり、サブエージェントを同時に複数実行して高速な探索と計画立案に有利
- Codexはコードの正確性でOpusを上回るが、コンテキストウィンドウ間の作業委譲が不足しており、処理速度が遅い欠点がある
- skill自動化によって計画 → 実装 → レビュー → バグ修正のループを段階的に構築しており、最初から設計するよりも繰り返される手作業を徐々に自動化するアプローチが効果的
- 最終的にはエージェントが24/7で自律的に働く未来を目指しているが、コンテキストウィンドウの限界とプロンプトインジェクション耐性が主要な障壁
背景
- CodexのWeb版に関する仕事をしており、2025年7月にOpenAIを退職
- YC Lightcone Podcast を受けて、コーディングエージェント活用の詳細な戦略を整理する目的で本稿をまとめた
- エージェント選定基準は、モデル性能よりも自律実行時間と業務の重要度を中心に移行している
- Claude Max、ChatGPT Pro、Cursor Pro+をすべて契約しており、生産性に対する費用対効果は高い
基本原則: コンテキストを理解する
- コーディングエージェントをうまく使うには、コンテキスト(context) を必ず理解する必要がある
- エージェントがどれだけ優秀でも、結局はnext token predictionを行っており、すべてのトークンはコンテキストウィンドウ内に入っていなければならない
- ここから導かれる主要な原則:
- 問題をコンテキストウィンドウに合うよう適切な大きさに分割する必要があり、問題が大きすぎると時間がかかり、結果も悪くなる
- Compactionは損失のある手法であり、どの情報を含め何を省くかをエージェントが判断するため、compactionが増えるほど性能は低下しがち
- 計画文書などを使ってコンテキストをファイルシステムへ外部化すると、エージェントは会話全体のコンテキストを埋めずに選択的に読み込み、記憶できる
- コンテキストウィンドウの「賢い半分」に留まることが重要であり、短いコンテキストデータのほうが学習がうまくいくため、ウィンドウが埋まり切っていない状態のほうがよい結果が出る — Dex Horthyはこれを**「dumb zone」の外に留まる**と表現している
- エージェントが関連ファイルやパッケージを見落とすと予想外の方向へ進むことがあり、コードベース構造とアーキテクチャの**「段階的開示(progressive disclosure)」**が助けになる — OpenAIが複数のMarkdownファイルを構造化する方法についてのブログ投稿もある
- モデルの性能と速度は、モデル自体の純粋な性能だけでなく、複数コンテキストウィンドウの管理やサブエージェント/チームへの委譲能力にも左右される
Opus: コンテキスト管理、ツール利用、人間らしさ
- Claude Codeを計画立案、ターミナルのオーケストレーション、git/GitHub作業管理の主力ツールとして使っている
- Opusは複数のコンテキストウィンドウをまたいで非常に効率的に動作するよう訓練されており、Claude CodeではCodexより体感速度が速い
- Opusが
ExploreやTask呼び出しなどで複数のサブエージェントを同時に実行する様子がよく見られる- ExploreツールはHaikuを使うため、大量のトークンを高速に処理し、関連コンテキストをOpusへ渡す
gh、git、さまざまなMCPサーバーなどのローカルツール利用についてもよく訓練されている/chrome拡張機能でバグ検証も可能だが、遅く不安定なことがある
- Claude Codeの権限モデルはCodexより理解しやすい — Codexモデルはbashでコマンドをスクリプト化しがちで、個別CLIツールのホワイトリスト化が難しい
- Claude Codeの細かなUX上の利点: ターミナルタイトルを作業内容に合わせて更新し、ステータスバーに現在のPRを表示し、小さな状態メッセージも出す
- OpusはCodexよりも人間にわかりやすいPR説明や詳細なアーキテクチャ図の生成に優れている
- コード構造の説明を頼むときは主にClaude Codeを使う
- Opusは**計画立案時により「創造的」**で、ユーザーが言及していない部分を提案したり、曖昧な領域を指摘したりする傾向がある
Codex: 圧倒的なコードの正確性
- Codexが真価を発揮する領域は**コードの正確性(correctness)**であり、モデルを多用する他の開発者たちもこれに同意している
- GPT-5.3-Codex-xhighまたはhighで実行すると、Codexのコードは明らかにバグが少ない
- Opusでよくあるミスの例:
- Reactコンポーネントがユニットテストには通るが、最上位の
<App>へ追加するのを忘れる - 明白なoff-by-oneエラーを見逃す
- 微妙なダングリング参照(dangling references) やレースコンディション
- Reactコンポーネントがユニットテストには通るが、最上位の
- 長い間、両モデルの差は無視できる程度だと思っていたが、CodexとCursor Bugbotの自動レビューで十分な数のPRを見た結果、OpenAIモデルのコード品質は優れていると判断した
- 自分でA/Bテストするなら、ブランチをチェックアウトしてからClaude Codeの
/code-reviewとCodexの/reviewを比較すればよい
- 自分でA/Bテストするなら、ブランチをチェックアウトしてからClaude Codeの
- ただしCodexは遅い — 主な理由はコンテキストウィンドウ間の作業委譲が不足しているためで、トークン間レイテンシも高いと感じる
- 実験的なサブエージェント対応（
/experimentalトグル）を使えば動くが、Claudeほど滑らかではなく、並列性もまだ不足している
- 実験的なサブエージェント対応（
- 結果として、Claude Codeで始めてウィンドウを開いたままにし、実際のコーディング段階でCodexへ切り替えるパターンになっている
便利なツールと設定
- 現在はグリーンフィールドのコードベースに取り組んでおり、本番コードベースよりずっと小さく、トークン効率がよい
- リポジトリ構造: すべてのリポジトリに
plans/フォルダを置いて番号付きの計画書を管理し、apps/フォルダでサービスを分離し、turborepoでTypeScriptモノレポを管理し、bunで高速インストールを行う - Ghostty: Mitchellhのターミナルで、高速かつネイティブで、継続的に改善されている — 以前はtmuxで複数のClaude/Codexインスタンスを動かしていたが、今は同じターミナルタブ内の複数paneを使っている
- Vercel上のNext.js、APIはCloudflare Durable Objects: データベースを事前にパーティショニングし、オンデマンドで起動し、同時書き込みの心配が少ない構成 — エージェントが小さなデータ断片を扱う時代に、インフラの観点で適している
- Cloudflareはcloudflare/actorsライブラリにより、コンピュートと小規模なコロケートストレージを束ねる方向へ拡張している
- Worktrees: コードが軽量なので並列worktreeを活用し、それぞれで
bun install→bun run devとしてローカル検証する — 関連する計画・環境変数・更新をコピーし、新しいブランチを始めるworktreeskillを使っている- コーディングエージェント以前は主にブランチだけを使っていたが、worktreeとClaude Codeの組み合わせは非常に有用
- Plan, Implement, Review: ほぼ常にモデルにまず計画から始めさせる — 1) 単一のコンテキストウィンドウを超えてコンテキストを外部化できる 2) 何をしたかをレビューしたり質問したりできる — エージェントが停止しても、新しいコンテキストウィンドウで計画を再開できる
- Preview deploys: すべてのブランチが新しいWeb + APIデプロイを受け取れるため、並列実行と高速テストに有利 — この機能なしでは作業しづらい
- Cursor BugbotとCodex Code Review: アーキテクチャレベルでコードを理解しつつスポットチェックを行っており、徐々にすべてのPRの全行を読むことはしなくなっている — 微妙なバグを見つけるのはエージェントのほうが得意
- 以前はClaude Code、Cursor Bugbot、Codexの3つをすべて使っていたが、Claude Codeは実質的な問題を捉えられなかったため、Cursorを既定の選択肢としており、Codexの結果も良いと評価している
Skills: 自動化の鍵
- 複数のskillと共有のAGENTS.md/CLAUDE.mdをclaudefilesというリポジトリに定義している
- skill追加のルール: 早まって追加せず、何度か繰り返してワークフローが安定してから追加する
- AGENTS/CLAUDE.mdはモデル全体の方向付けに有用で、skillには2つの目的がある:
- ワークフローの連結と自動化 — 計画 → 段階的な実装 → レビューをそれぞれskill化し、順番に実行するメタskillを構成する
- コンテキストウィンドウの分割 — Claude Codeでskill呼び出し時に
context: forkを設定すると、新しいコンテキストウィンドウで実行でき、「マスターオーケストレーター」とサブエージェントを分離できる
- skillは非常にコンテキスト効率が高く、MCP呼び出し（数千トークン）とは違って通常は約50〜100トークン
Skill自動化の進化過程
- 当初はskillマーケットプレイスのアイデア（フロントエンドデザイン、セキュリティ点検、アーキテクチャレビューなどをインストール）に関心があったが、作業を進めるうちに他人が書いたskillはほとんど使わなくなった
- その代わり、まず手作業を行い、どう自動化するかを考える方式へ切り替えた
- skillの進化過程:
/commit: モデルにコミット・プッシュをさまざまな形で指示する代わりに、1つのskillへ統合 — Claude Codeから直接取り入れた/worktree: エージェントが別のworktreeで作業できるように、計画番号ベース（例: 00034-add-user-auth）で新しいworktreeを作成/implement: 計画のステップを実行したあと/commitを行う反復作業を1つのskillへ統合/implement-all: 現在のworktreeパスを計画番号に結び付けて全ステップを自動実装 — 夜間実行では/ralph-loopで全ステップ完了まで回し続け、ローカル/codex-reviewでcodex --reviewプロセスを生成する/address-bugs: GitHub APIから最後のコミット以降のCursor + Codexコメントを検索し、バグを検証して修正を試みる/pr-pass:/implement-all終了時に実行され、1) リモートへプッシュ 2) すべてのCI通過を待機 3)/address-bugsを実行して必要なら手順1を繰り返す/focus:plansディレクトリ、未完了PR、worktreeを参照して記憶を更新し、作業追跡を支援する
- このプロセスを最初から作ろうとしていたら成功しなかっただろうし、時間をかけて自動化できる小さな領域を見つけながら段階的に構築したことが重要だった
その他のツール
- 最近Codex Appを使ってみて、細部や小さな作り込みに好印象を持った — ただしCLIツールの柔軟性を好むため、完全には移行していない
- Coworkも試したが、うまく動かすのが難しく、どちらの場合もサンドボックス化モデルが大きな違いを生んだ
- 非同期作業にはWebインターフェースをときどき使うが、次第にCLIへの依存が強まっている — 6か月前には主にCursorと組み込みエージェント/拡張機能を使っていたのと対照的
- フロントエンドUI作業にはpencil.devを使っており、ローカルのClaude Codeへシェルアウトして既存サブスクリプションを再利用するデプロイモデルが興味深い
- より定型的な課題トラッカーの必要性を感じており、David CramerのDexやSteve Yeggeのbeadsが有望だが、まだ必要以上に複雑に感じる
- Playwrightなどの自動e2e MCPは現時点では使っていない
研究所への助言
-
Anthropicへのフィードバック
- モデル: Opusは人間らしさ、エンジニアリングツール活用、コンテキスト分割、「ユーザーが忘れているかもしれないこと」の提案に優れる一方、コードの正確性が不足している — 「Opus Strict」モードとして、基本モデルにRLをさらに強化して性能改善してほしい
- Opusで始めるが、コードはCodexが書く。予算制約があるならCodexを選ぶだろう
- 製品ハーネス: ほぼ指摘する点はなく、BorisとCatのアイデアは素晴らしい
- agent skills標準の採用を求める — 複数CLI間でのディレクトリシンボリックリンク作業は不便
--stream-jsonの出力フォーマット公開を求める — ユーザーの代わりにClaude Codeをサンドボックスで実行することに関心があるが、フォーマット変更への不安があり、パス設定も他のCLIツール（Codex、Cursor、Gemini）より面倒
- モデル: Opusは人間らしさ、エンジニアリングツール活用、コンテキスト分割、「ユーザーが忘れているかもしれないこと」の提案に優れる一方、コードの正確性が不足している — 「Opus Strict」モードとして、基本モデルにRLをさらに強化して性能改善してほしい
-
OpenAIへのフィードバック
- モデル: 最優先の改善課題はコンテキストウィンドウ間の分割とサブエージェント委譲 — Opusが計画立案で実現している「要求以上のことをする」という概念も有用だろう
- 製品ハーネスに関する詳細フィードバック:
- サンドボックス化モデルがClaude Codeと比べて理解しにくい — モデルがスクリプト化を試みるため承認要求が増え、
--yoloモード実行には懸念がある - Claude CodeのようにCLI内蔵のユーザーガイド追加を求める — skillの場所、対応フィールド、サンドボックス化モデル設定などを質問できるようにしてほしい
/reviewをパッケージ化されたコマンドではなく一般的なskillへ変換してほしい — モデルが動的に呼び出せるように- 実行時にターミナルタブのタイトルを作業内容に変更してほしい — 数十個の
codexタブがあると混乱する - PR説明やコミット説明に特化した訓練が必要 — Codexの簡潔な性格は良いが、説明はもっと充実してほしい
- skill定義で**
context: fork対応**を求める - pane内でリンクが改行をまたいでもクリック可能にしてほしい
- ステータスバー下部に現在のworktree/PR/ブランチ名表示を求める
- サンドボックス化モデルがClaude Codeと比べて理解しにくい — モデルがスクリプト化を試みるため承認要求が増え、
今後の見通し
- Steve Yeggeの**Gas Town** 投稿を引用 — 常にトークンを最大限使い、ワーカープールが24/7で回り、多くの計画を立てては捨てることを前提にすべきだという主張
- その抽象化が正確かどうかは別として、方向性としては完全に正しいと評価している
- 理想的な未来: ノートPCやクラウドサンドボックスがバックグラウンドで継続的にアイデアを処理し、ユーザーは方向修正やリサーチ、結果レビューを担う
- コーディングエージェントとの仕事はエンジニアリングマネージャーの役割に似ているが、エージェントの動機づけや性格を気にする必要はない
- 現在はこの未来にかなり近づいている — Xでは誇張されがちだが、実際に就寝前にCodexで3〜4件の作業を開始し、朝にレビューするルーティンを行っている
- ただし、まだエージェントを24/7で稼働させられる段階ではない
- より大きな進展を妨げる2つの障壁:
- コンテキストウィンドウのサイズ/調整 — エージェントは同じコンテキストウィンドウ内で際限なく圧縮・再利用できず、より賢いハーネスや委譲メカニズムが必要
- プロンプトインジェクション耐性 — エージェントは数分で承認要求を出してきて、
--yoloモードは信頼できないが、許容可能な権限/ドメインの部分集合は存在する
- 1つ目の問題については、Cursorが多数のコンテキストウィンドウにまたがるエージェントスウォームの限界を押し広げており、2つ目は活発な研究分野だ
- サンドボックス実行が現時点で最善の回避策だが、設定はなお面倒で、エージェントがオープンインターネットへのアクセスと特権データを同時に持つと、Simon Willisonのいう**「Lethal Trifecta」**に脆弱になる
- ソロエンジニアとしては、すでに正しいアイデアこそがボトルネックになっており、今後はますますアイデア、アーキテクチャ、プロジェクトのシーケンシングが優れた製品を作るうえでの制約要因になるだろう
4件のコメント
アーキテクチャ図もですか..?
Codexにサブエージェント機能さえあれば移行すると思いますね。
でも、まあ興味がないのか…。
https://developers.openai.com/codex/multi-agent
実験的な段階ですが、進めてはいるようですね。
codex cliでは/experimentalコマンドを入力すると、実験機能として Multi-agents が提供されています。› [x] Multi-agents Ask Codex to spawn multiple agents to parallelize the work and win in efficiency.
おっしゃっていたサブエージェントと同じ系統かは分かりませんが、一度確認してみてください。