---

title: "Which tools do Claude, Codex and Cursor choose?: AIコーディングで変わる開発ワークフロー"

description: "17,000回の実行ログを分析した調査から、Claude・Codex・CursorがどのAIコーディングツールを選択するかを解説。ツール選択の傾向、実装上の注意点、プロダクト適用時の判断材料を整理します。"

meta_description: "Claude・Codex・Cursorが17,000回の実行で選択したツールの傾向を分析。AIコーディングエージェントのツール選択ロジック、実装上の注意点、開発ワークフローへの影響を解説します。"

date: 2026-09-04

category: AIコーディング

tags: [AIコーディング, AI開発支援, コード生成, 開発ワークフロー]

---

Which tools do Claude, Codex and Cursor choose?: AIコーディングで変わる開発ワークフロー

何が出たのか

2026年9月初旬、AIコーディングエージェントのツール選択行動を大規模に計測した調査レポートが公開され、Hacker NewsやRedditのr/MachineLearning、r/programmingで活発に議論されています。調査の核心は「Claude・Codex・Cursorという3つの主要AIコーディング環境が、実際のコーディングタスクでどのツール（ファイル操作、シェル実行、Web検索、コード実行サンドボックスなど）をどの頻度で呼び出すか」を17,000回の実行ログから定量的に明らかにした点です。

これまでAIコーディングエージェントのツール選択は「モデルが適切に判断する」という前提で語られることが多く、実際の選択分布が公開データとして存在しませんでした。今回の調査はその空白を埋めるもので、エージェントをプロダクトや業務システムに組み込む際の設計判断に直結する情報を提供しています。

調査で明らかになった主な事実を先に整理します。

• ファイル読み取りの偏重3エージェント共通で、全ツール呼び出しの40〜55%がファイル読み取り系（read_file、list_directory相当）に集中しています。
• シェル実行の頻度差Codexはシェルコマンド実行を積極的に選択する傾向があり、Claudeと比較して約2.3倍の呼び出し頻度が観測されています。
• Web検索の利用率Cursorはデフォルト設定でWeb検索ツールを有効化しており、3エージェント中で最も高い検索呼び出し率（全呼び出しの約18%）を示しています。
• エラー後のリトライ挙動ツール呼び出しが失敗した際のフォールバック戦略がエージェントごとに異なり、Claudeは別ツールへの切り替えを試みる一方、Codexは同一ツールの再実行を優先する傾向があります。

技術的に面白い点

この調査が技術的に価値を持つのは、単なる使用頻度の集計ではなく「タスクの種類とツール選択の相関」まで掘り下げている点です。

ツール選択はプロンプトの表層ではなくタスク構造に依存する

調査では、同一の自然言語プロンプトを3エージェントに与えた場合でも、タスクが「既存コードの修正」か「新規機能の追加」かによってツール選択パターンが変化することが示されています。既存コード修正タスクではファイル読み取りが先行し、新規追加タスクではコード生成→書き込みの順序が多いという構造的な差異が確認されています。これはエージェントが暗黙的にタスクを分類していることを示唆しており、プロンプトエンジニアリングだけでは制御しきれない挙動が存在することを意味します。

ツール呼び出しのレイテンシ分布

17,000回の実行ログにはレイテンシデータも含まれており、ツール種別ごとの応答時間の中央値が公開されています。ファイル操作系は数十ミリ秒台で安定している一方、シェル実行は長尾分布（ロングテール、つまり稀に極端に時間がかかるケースが存在する分布）を示し、p95（上位5%の遅いケース）で10秒を超えるケースが報告されています。Codexがシェル実行を多用する特性と組み合わせると、Codexを使ったエージェントパイプラインはレイテンシの予測可能性が低くなるリスクがあります。

コンテキストウィンドウの消費パターン

ツール呼び出しの結果はエージェントのコンテキスト（会話履歴や作業状態を保持するメモリ領域）に積み上がります。調査では、ファイル読み取りを多用するタスクでコンテキストが急速に消費され、長いタスクの後半でツール選択の精度が低下する現象が観測されています。特にCursorはWeb検索結果をそのままコンテキストに追加する実装になっているため、検索結果が長文の場合にコンテキスト圧迫が加速します。

ツール定義のスキーマ差異

3エージェントはそれぞれ独自のツール定義形式（JSONスキーマ）を使用しており、同じ機能でもパラメータ名や必須フィールドが異なります。たとえばファイル書き込みツールの場合、Claudeはpathとcontentを分離したスキーマを採用し、Codexはfile_pathとnew_contentという命名を使用しています。マルチエージェント構成（複数のエージェントが協調して動作する構成）でツールを共有しようとすると、このスキーマ差異が統合の障壁になります。

既存の流れとの違い

AIコーディングエージェントのツール利用に関する議論は、これまで主に「どのツールを提供するか」という設計側の視点で行われてきました。LangChainやLlamaIndexなどのエージェントフレームワーク（AIエージェントを構築するためのライブラリ群）のドキュメントも、ツールの定義方法や登録方法を中心に解説しており、エージェントが実際にどのツールをどの頻度で選ぶかという実行側の実態はブラックボックスのままでした。

今回の調査が既存の議論と異なる点は3つあります。

第一に、観測対象が実際のプロダクション相当のタスクである点です。合成ベンチマーク（人工的に作られたテスト問題）ではなく、実際のコーディングタスクに近い設定で計測されており、現場での挙動との乖離が小さいとされています。

第二に、失敗ケースのログが含まれている点です。ツール呼び出しが失敗した際のエージェントの回復行動（リトライ、別ツールへの切り替え、ユーザーへの確認要求）が記録されており、エラーハンドリングの設計に使える情報が得られます。従来の評価研究は成功ケースに偏りがちでしたが、この調査はフォールバック挙動まで含めた全体像を提供しています。

第三に、3エージェントを同一条件で比較している点です。Claude APIを直接呼び出す場合、OpenAI Codex API経由の場合、Cursorのエディタ統合環境の場合という異なる利用形態を横断的に比較しており、「どの環境を選ぶか」という意思決定に使える比較軸が整理されています。

SWE-bench（ソフトウェアエンジニアリングタスクの標準ベンチマーク）などの既存評価指標はタスク完了率を主軸にしていますが、今回の調査はツール選択の効率性（無駄な呼び出しの多さ）やコンテキスト消費量という別の軸を提供しており、プロダクション導入時のコスト試算に直接使える情報になっています。

実装・運用で気になる点

調査結果をプロダクトや業務システムへの実装に結びつける際、いくつかの論点が浮かび上がります。

ツール呼び出し数とAPIコストの関係

AIコーディングエージェントのAPIコストはトークン消費量で決まりますが、ツール呼び出しの結果がコンテキストに積み上がることで、タスクが長くなるほどコストが非線形に増加します。調査データから推算すると、ファイル読み取りを多用する修正タスクでは、単純なコード生成タスクと比較して3〜5倍のトークンを消費するケースがあります。コスト上限（バジェット）を設定する場合、ツール呼び出し回数の上限とコンテキスト長の上限を組み合わせた制御が必要です。

シェル実行の権限設計

Codexがシェル実行を多用する特性は、サンドボックス（隔離された実行環境）の設計に直接影響します。シェル実行ツールに与える権限を最小化しないと、エージェントが意図しないシステム操作を実行するリスクがあります。具体的には、ファイルシステムのアクセス範囲をプロジェクトディレクトリに限定すること、ネットワーク接続を制限すること、実行時間の上限を設定することが最低限の対策として挙げられます。

ログとモニタリングの設計

17,000回の実行ログを収集できた背景には、ツール呼び出しのすべてをログに記録する仕組みがあります。プロダクションでエージェントを運用する場合、ツール名・入力パラメータ・実行結果・レイテンシ・成否をセットで記録する構造化ログが必須です。これがないと、エージェントの挙動が期待と乖離した際の原因調査が困難になります。OpenTelemetry（分散システムの観測性を標準化するフレームワーク）のスパン（処理の単位）としてツール呼び出しを記録する実装パターンが、現時点では最も汎用性が高い選択肢です。

マルチエージェント構成でのツールスキーマ統一

前述のスキーマ差異は、複数エージェントを組み合わせる構成では特に問題になります。ツール定義を抽象化するアダプター層を設けて、各エージェントのスキーマ差異を吸収する設計が現実的です。ただしアダプター層の追加はデバッグの複雑さを増すため、まずは単一エージェントで動作を確認してから多エージェント化する順序が推奨されます。

フォールバック戦略の明示的な設計

調査で観測されたエラー後のリトライ挙動は、エージェントが暗黙的に持つフォールバック戦略です。プロダクション環境では、この暗黙の戦略に依存するのではなく、ツール呼び出し失敗時の挙動を明示的に定義することが安定運用につながります。たとえば「シェル実行が失敗した場合はファイル操作ツールで代替する」「3回リトライして失敗した場合は人間にエスカレーションする」といったルールをシステムプロンプト（エージェントへの事前指示）またはオーケストレーター（エージェントの動作を制御する上位レイヤー）側で定義します。

Spectralの見解

1. 技術的な読み

今回の調査が示す最も重要な示唆は、「AIコーディングエージェントの挙動はモデルの能力だけでなく、ツール設計とコンテキスト管理の質に強く依存する」という点です。3エージェントの選択傾向の差異は、モデルの基礎能力の差というよりも、ツール定義の粒度やデフォルト設定の違いから生じている部分が大きいと読めます。これはエンジニアリング側の設計で挙動をコントロールできる余地が大きいことを意味しており、エージェントを「ブラックボックスとして使う」から「設計対象として扱う」への転換が求められています。

2. PoCで確認すべき点

PoCの段階では、対象タスクでのツール呼び出し回数とコンテキスト消費量を計測することを最初のマイルストーンに設定することを推奨します。具体的には、代表的なタスク10〜20件を実行してツール呼び出しログを収集し、コスト試算と失敗パターンの把握を行います。シェル実行を含むタスクについては、サンドボックスの権限設計を確定させてから本格的な評価に進む順序が安全です。また、使用するエージェント環境（Claude API直接、Codex API、Cursorなど）によってツール選択の傾向が異なるため、自社のタスク特性に合った環境を選ぶ比較検証をPoCに含めることが有効です。

3. 業務・プロダクト実装に移す時のリスク

本番移行時のリスクとして、コスト予測の困難さとセキュリティ境界の設計不足の2点が特に注意を要します。ツール呼び出しによるコンテキスト膨張はタスクの内容によって大きく変動するため、固定のコスト上限設定だけでは不十分です。タスク種別ごとのコスト上限と、上限到達時の挙動（タスク中断、人間への引き渡しなど）を設計に組み込む必要があります。シェル実行権限については、最小権限の原則を徹底し、プロジェクトスコープ外へのアクセスを技術的に遮断する実装を本番前に完成させることが前提条件です。ログ基盤が整っていない状態での本番稼働は、問題発生時の原因特定を著しく困難にするため、構造化ログの収集と可視化ダッシュボードの整備を本番稼働の条件として設定することを推奨します。

まとめ

17,000回の実行ログを分析した今回の調査は、AIコーディングエージェントのツール選択挙動を定量的に可視化した点で、プロダクション導入を検討するエンジニアにとって実用的な参照データを提供しています。

主要な論点を整理します。Claude・Codex・Cursorはそれぞれ異なるツール選択傾向を持ち、その差異はモデル能力よりもツール設計と環境設定に起因する部分が大きいです。シェル実行の多用はレイテンシの予測可能性を低下させ、ファイル読み取りの多用はコンテキスト消費とAPIコストを増加させます。エラー後のフォールバック挙動はエージェントごとに異なり、プロダクション環境では暗黙の挙動に依存せず明示的な設計が必要です。

AIコーディングエージェントを業務やプロダクトに組み込む際は、「どのエージェントが賢いか」という評価軸だけでなく、「どのツール選択パターンが自社のタスク特性とコスト制約に合っているか」という軸で選定することが、安定した運用への近道になります。

関連論点として Changes in the system prompt between Claude Opus 4.6 and 4.7 もあわせて読むと、この技術動向の背景を追いやすくなります。

Spectralでは、技術調査からPoC設計、プロダクト実装まで支援しています。実現性の確認や事業活用の相談は サービス詳細 と お問い合わせ をご覧ください。