# 並列ツール呼び出しはコーディングエージェントの信頼性をどう変えますか？ > 並列ツール呼び出しは独立した読み取りの待ち時間を短縮しますが、状態共有、順序依存、書き込みがあると信頼性を下げます。モデルが出したすべての呼び出しを並列化せず、明示的な依存グラフ、リソースロック、冪等性キー、決定的な結果統合を使用してください。 並列ツール呼び出しはスケジューリングの提案であり、すべてを一度に開始する許可ではありません。2つのリポジトリ検索は通常重ねられますが、ファイル編集とフォーマッターは重ねられない場合があります。依存関係のインストールとテスト実行を、同じインストール前状態から開始してはいけません。 並行処理がリソースと依存関係のモデルに従うと信頼性は向上します。実行機構が呼び出し配列を独立性の証明として扱うと低下します。 ## 呼び出しを効果別に分類する レジストリ内の各ツールに、スケジューラーが強制できる挙動を付けます。 | 効果クラス | 例 | 既定ポリシー | |---|---|---| | 純粋な読み取り | 2つのソースファイルを読む | 並列可 | | 外部読み取り | 2つのAPIを照会 | 制限付き並列 | | ローカル書き込み | ファイルを編集 | リソース単位で直列化 | | グローバル書き込み | 依存関係をインストール | 全体で直列化 | | 不可逆操作 | 公開または送信 | 明示的ゲートが必要 | ツール名だけに依存してはいけません。`inspect` というコマンドがキャッシュを作ることがあり、テストがスナップショットやデータベースを書き込むこともあります。副作用をレジストリへ記録してください。 ## 実行前に依存グラフを作る 呼び出しをノード、必要な順序をエッジとして表します。先行処理が成功し、リソースが利用可能な場合だけ開始できます。 ```text read_config ----+ +--> build --> test read_source ----+ search_docs ---------> summarize ``` 最初の2つの読み取りは同時に実行できます。ビルドは両方を待ち、テストはビルドを待ちます。文書検索がビルド入力に影響しないなら、リポジトリ側の処理と重ねられます。 モデルが依存関係を示さない場合は、ツールのメタデータと引数から保守的に推測します。曖昧な書き込みは直列実行してください。 ## エージェント全体ではなくリソースをロックする 単一呼び出しのグローバルロックは信頼できますが遅くなります。リソース単位のロックなら安全な並行性を保てます。 比較前にパスを正規化します。`src/a.ts` の編集は `src` のフォーマットと衝突し、ロックファイル生成はコマンドが違っても別のパッケージ操作と衝突します。データベース、ブラウザセッション、ターミナル、リモートレコードもリソースモデルに含めてください。 | リソース | ロック範囲 | |---|---| | ソースファイル | 正規化済みパス | | ディレクトリフォーマッター | ディレクトリのサブツリー | | パッケージマネージャー | ワークスペースとロックファイル | | ブラウザセッション | タブまたは認証済みワークフロー | | デプロイ | 環境とサービス | ## ストリーム全体で呼び出し識別子を保持する 複数呼び出しの引数断片は交互に届くことがあります。呼び出しID別にバッファし、各呼び出しが完了イベントを受けた後だけ実行します。出力位置だけを永続的な識別子にしてはいけません。 同じ不透明な呼び出しIDとともに結果を返します。完了順が変わっても、元の呼び出し順など決定的な順序で表示します。これによりトレースと再試行が再現可能になります。 Atlas Cloudは、OpenAI Chat Completionsでツール機能を公開するモデル向けに `tools`、`tool_choice`、`parallel_tool_calls` を渡します。すべての経路が並列呼び出しに対応すると仮定せず、[LLMプロトコルガイド](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-parallel-tool-calls-change-coding-agent-reliability)で選択モデルとプロトコルを確認してください。 ## 部分失敗のポリシーを定義する 並列バッチには成功と失敗だけでなく、1件完了、1件検証失敗、1件実行中という状態があります。 効果に応じたポリシーを選びます。 * 成功した独立読み取りを保持し、失敗した読み取りを報告する。 * 前提条件の失敗後、待機中の依存処理をキャンセルする。 * 冪等性キーなしで完了済み書き込みを再試行しない。 * ツールが明示的に対応する場合だけ補償を使う。 * 構造化したバッチ結果をモデルへ返す。 再試行は失敗ノードだけを対象とし、バッチ全体を無条件に再生しません。 ## 並行数とバックプレッシャーを制限する 独立した呼び出しでも、ファイルシステム、API、テストランナー、レート制限を圧迫します。ツール別・リソース別の並行上限を設定し、超過分はキューへ入れてキャンセル可能にします。 最も遅い呼び出し、キュー時間、再試行数、重複抑制、最終タスク成功を測定します。結果が正しく、追加ターンで埋め合わせない場合だけ、実時間の短縮に価値があります。 ## 出力だけでなくスケジュールをテストする 競合バグは1つの完了順では消える場合があります。遅延を使い、異なる順序で同じフィクスチャを実行してください。 | テスト | 強制順序 | 期待結果 | |---|---|---| | 2つの読み取り | A→B、B→A | 同じ統合証拠 | | 読み取りと書き込み | 書き込みが待機 | 読み取りは定義済み版を見る | | 同一ファイルへの2書き込み | どちらの提案順でも | 直列化された1つの計画 | | 失敗と遅い呼び出し | 失敗を先に | 依存呼び出しをキャンセル | | 書き込み後の切断 | レスポンスを喪失 | 書き込みを重複しない | CIが偶然のタイミングに頼らず順序を再現できるよう、偽の実行機構を使います。 ## 直列実行が適切な場合を判断する 移行、パッケージインストール、共有ファイル編集、公開手順、ロールバックが不明な操作には直列実行が適しています。並列処理はリポジトリ探索、独立した文書読み取り、分離したlintチェック、重ならないテストシャードで有効です。 [Atlas Cloud LLMカタログ](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-parallel-tool-calls-change-coding-agent-reliability)のモデルが複数呼び出しを提案しても、同時実行の可否を決める責任は実行機構にあります。 ## 結論 並列呼び出しは、作業が独立し読み取り中心ならコーディングエージェントを高速化します。副作用、隠れたリソース、順序を無視すると信頼性を下げます。ツールを分類し、依存グラフを作り、共有リソースをロックし、呼び出しIDを保持し、冪等な個別ノードだけを再試行し、複数のスケジュールをテストしてください。モデルが並行処理を提案しても、安全性は実行機構が強制します。 ## FAQ ### どのツール呼び出しなら安全に並列実行できますか？ 異なるリソースを対象にした独立した読み取り専用呼び出しが最も安全です。キャッシュ、一時ファイル、共有セッションを変更しないことも確認してください。 ### ファイル編集を並列実行してよい場合はありますか？ 所有範囲が重ならず、統合が決定的な場合だけです。同じファイル、生成成果物、ロックファイル、共有ビルド状態に触れるなら直列実行が安全です。 ### 並列呼び出しの1つが失敗するとどうなりますか？ オーケストレーターには、兄弟処理のキャンセル、成功した読み取り結果の保持、完了書き込みの補償、冪等な呼び出しだけの再試行など、定義済みポリシーが必要です。 ### 結果はモデルへどう返すべきですか？ 各呼び出しIDを保持し、成功、エラー、キャンセルの状態を明示して、決定的な順序で結果を統合します。 ### 並列呼び出しでエージェントのコストは下がりますか？ 経過時間は短くなる可能性がありますが、トークン使用量、重複作業、再試行が増えることもあります。完了タスクのコストと正確性をレイテンシーとは別に測定してください。 ### すべてのモデルが並列ツール呼び出しに対応しますか？ いいえ。選択したモデルとプロトコルを確認してください。ツールには対応しても、同じターン内の複数呼び出しに対応しない経路があります。