ツール実行が失敗する（API がエラーを返す等）ことを想定したエージェント設計として、最も適切なものはどれか。

正解はDです。ツール実行は失敗しうるため、エラー内容を観察として取り込み、再試行の回数に上限を設けたり、別の手段に切り替えたりして制御する設計が適切です。失敗を前提に「どう立て直すか」をあらかじめ決めておくことで、止まらず、かつ暴走もせずに進められます。

エラー設計の肝は「想定する」ことと「上限を切る」ことの両立です。失敗を観察として活かしつつ、リトライ上限や代替経路を決めておけば、無限リトライにも全停止にも陥りません。

ツール連携を組むときは、成功パスだけでなく「失敗したら何回まで試すか」「だめなら何に切り替えるか」を先に決めておきましょう。エラー文をそのままモデルに渡して状況判断させると、立て直しの精度が上がります。

なぜDが正解か

現実のツールは、ネットワーク障害や入力不備でエラーを返すことがあります。堅牢なエージェントは、エラーを観察として受け取り、原因に応じてリトライしたり、上限に達したら別手段やユーザーへのエスカレーションに切り替えたりします。リトライ回数の上限を切ることで無限リトライも防げます。Dはこのエラーハンドリングを正しく示しています。

なぜ他の選択肢が誤りか

Aの「エラーは起きない前提」は現実的でなく、失敗時に挙動が未定義のまま止まります。Bの無条件・無制限リトライは、回復しないエラーで無限ループとコスト膨張を招きます。Cの「即座に全破棄・再試行しない」は、一時的な障害でも作業全体を捨ててしまい過剰です。いずれも「失敗を観察し上限付きで制御する」というバランスを欠いています。