AIに渡すツールをどう絞るか：入力と戻り値で担当範囲を決める

一次情報から

公式資料が示す、ツールの目的と処理の違い

Anthropicの2025年9月公開記事は、ツールに明確で異なる目的を持たせ、関連する機能を名前で区別し、判断に役立つ情報を返す考え方を説明しています。[1] ここではその設計原則を参照し、特定製品の性能向上を保証するものとして扱いません。

同社の2024年12月の設計記事は、コードで経路を決めるワークフローと、モデルが進め方を選ぶエージェントを区別しています。[2] これは以前からの設計指針です。以下の分割方法や記録項目は、その区別を業務へ適用する編集部の提案です。

出典：[1][2]

編集部の実務提案

検索・変更案・確定を一つの道具に詰め込まない

例えば、問い合わせ管理の補助を委託する場面を考えます。これは実在事例ではなく、仕様を検討するための例です。「顧客を処理する」という広いツール名では、履歴を探すのか、分類を変えるのか、返信を送るのかが分かりません。まず作業を、記録の検索、変更案の作成、承認済み内容の確定に分けます。

検索は対象期間と件数を絞り、変更案は保存先を下書きに限定します。確定には、担当者が認めた対象と案の識別子を要求します。分類だけが必要な業務なら、送信操作を接続する必要はありません。実装担当者には、できる操作に加えて、同じツールでは実行できない操作も列挙してもらいます。

編集部の実務提案

入力の曖昧さを、実装前の確認項目にする

入力仕様には、必須項目、許容値、対象となる組織、検索の上限、空欄の扱いを記載します。例えば顧客名が一致しないときに、全顧客へ対象を広げる設計は避けます。一致なしとして返すのか、人に候補選択を求めるのかを先に決めると、実行中の解釈が減ります。日付の境界やタイムゾーンも、自然言語だけで済ませない項目です。

委託先には、通常の入力だけでなく、別組織の識別子、空文字、上限を超える件数を使った結果を提出してもらいます。説明に「担当範囲だけ」と書くことと、サーバーが範囲外の要求を拒否することは別です。運用担当が見る資料には、拒否された要求と、実行された要求を区別できる記録を残します。

編集部の実務提案

戻り値を、次の判断ができる最小単位にする

戻り値は短さだけで評価しません。対象が見つかったか、何が変更されたか、まだ案なのかを人とAIが同じ意味で読めることが必要です。処理が途中なのに「成功」とだけ返す設計では、後続の担当者が確定済みと誤解するおそれがあります。長い内部ログをすべて返すより、判断用の結果と調査用の参照先を分ける方法を検討します。

次の表は編集部が提案する項目の例です。業務に不要な個人情報は追加せず、調査用の記録にも同じ方針を適用します。候補が複数ある場合は、その状態を隠さず、次に誰が何を選ぶかまで返すと、時差のあるチームでも依頼が止まりにくくなります。

編集部の実務提案

納品時は、許可されない操作も試す

納品確認では、同じ目的を違う言い方で依頼し、ツール選択が変わるかを見ます。加えて、検索しか認めていない役割で更新を要求し、操作が拒否されることを確認します。これはモデルの返答の丁寧さではなく、実行境界の確認です。拒否が表示されても更新が保存されていれば、受け入れ条件は満たしていません。

最初は一つの業務と少数のツールで運用し、誤った選択、不要な検索、確認待ちを記録します。新しいツールは、その記録から既存の操作では解決できない仕事が確認できたときに追加します。名称、入力仕様、戻り値の版をそろえて管理し、変更時には同じ依頼を再実行して比較できる状態を残します。