PromptOps編（”指示資産”）、ナレッジ運用編（”参照資産”）と続けてきた、エージェントの可変資産を運用対象として扱うシリーズ。その3本目にして最終回である本稿のテーマは、エージェントが「何を使えるか」——すなわち能力資産としてのツール（MCPサーバー／Function）の運用だ。多くの現場では、外部APIやMCPサーバーをエージェントに”つないだ瞬間”がゴールになっている。だが実際にトラブルを生むのは、つないだ後に道具が静かに劣化し、誰も気づかないまま壊れた道具を叩き続ける状態である。本稿は、ツールをプロンプトやナレッジと同じく版・品質・評価の対象として運用するための設計を、実務目線で整理する。
目次
- 1. 本稿の位置づけ——”能力資産”が可変資産トリロジーを完結させる
- 2. なぜツールは静かに壊れるのか
- 3. ツールレジストリ——能力資産の台帳をつくる
- 4. 契約テストと回帰——ゴールデンテストで”壊れ”を検知する
- 5. ツール選択の可観測性——「なぜそのツールを呼んだか」を残す
- 6. ツール評価——タスク成功率への寄与度を測る
- 7. 廃止・移行——deprecationと野良ツールの棚卸し
- 8. まとめ
- よくある質問（FAQ）
- 参考リンク
1. 本稿の位置づけ——”能力資産”が可変資産トリロジーを完結させる
エージェントの振る舞いを左右する要素は、大きく3つに分けられる。どう指示されるか（プロンプト）、何を参照するか（ナレッジ）、そして何を使えるか（ツール）だ。これらはいずれもコードのリリースとは独立に変化しうる”可変資産”であり、放置すればいつの間にかエージェントの挙動を変えてしまう。
シリーズの見取り図
- PromptOps編（指示資産）：プロンプトを「設定」ではなく「ソースコード」として版管理する運用規律。
- ナレッジ運用編（参照資産）：エージェントが参照する知識をいつ・何で更新し、どう鮮度を担保するかの運用規律。
- 本稿＝ツール運用編（能力資産）：エージェントが呼ぶツール（MCP／Function）を、版・品質・評価の対象として統制する運用規律。
本稿を、隣接する既存記事と混同しないよう、あらかじめ軸を切り分けておく。フリート編はエージェントの”個体群”の運用であり、本稿はエージェントが”使う道具”側の運用だ——両者は直交する。⑦デプロイ編はリリース資産の一つとしてツール定義に触れたが、本稿はツール単体のライフサイクルに特化した続編である。MCPツールポイズニング編はツール定義への”攻撃”に対する防御だが、本稿は平時の品質・版・廃止という信頼性運用を扱う。そして被起動最適化編が自社を”呼ばれる側”として設計する話だったのに対し、本稿は自社エージェントが”呼ぶ側”としてツール群を統制する、いわば鏡像の関係にある。
2. なぜツールは静かに壊れるのか
ツール運用の出発点は、「ツールは壊れるものだ」という前提に立つことだ。しかもその壊れ方は、多くの場合静かで、遅れて表面化する。エージェントは呼び出しがエラーで返らない限り、道具が期待どおり働いていると信じ込む。壊れ方には、大きく次のパターンがある。
| 壊れ方 | 何が起きるか | エージェント側の見え方 |
|---|---|---|
| 仕様変更 | 提供元がAPIのパラメータ名・必須項目・エンドポイントを変更 | エラーで返れば気づけるが、後方互換のつもりの変更が”微妙にズレた結果”を返すことがある |
| サイレント破壊 | 戻り値のフォーマットや意味が変わったのに、ステータスは200のまま | 正常応答に見えるため検知できず、誤った出力を下流へ流し続ける |
| 品質劣化 | レイテンシ増大、レート制限の強化、精度の低下 | タイムアウトやリトライが増え、タスク成功率がじわじわ落ちる |
| 権限の陳腐化 | トークン失効、スコープ変更、課金停止 | ある日突然、一部の呼び出しだけが失敗し始める |
API仕様変更とサイレント破壊
最も厄介なのはサイレント破壊だ。呼び出しは成功しているのに、返ってくる値の意味がいつの間にか変わっている——たとえば金額フィールドの単位が円から千円になった、日付の並びが変わった、といったケースである。ステータスコードは正常なので監視には引っかからず、エージェントは疑うことなくその値を使う。結果として、「正しく呼べているのに、答えが間違っている」という、最も発見の遅れる不具合が生まれる。
野良MCPの増殖
MCPの普及で、ツールを追加する敷居は劇的に下がった。これは利点であると同時に、統制上のリスクでもある。誰がいつ追加したか分からないMCPサーバー、検証されていない外部ツール、同じ機能を持つツールの重複——こうした野良ツールが積み上がると、エージェントは「似た道具のどれを使えばいいか」を毎回迷い、選択の一貫性が失われる。ツールが増えること自体が、それを管理する台帳とルールを持たない限り、静かな劣化の温床になる。
3. ツールレジストリ——能力資産の台帳をつくる
ツール運用の背骨になるのがツールレジストリだ。これは、エージェントが呼びうるすべてのツールを一元管理する台帳であり、「今このエージェントには何ができるのか」を正確に答えられる唯一の情報源（Single Source of Truth）になる。個別のエージェント定義やコードにツールが散らばっている状態では、棚卸しも廃止も評価もできない。まずツールを一箇所に集めて名寄せすることが、あらゆる運用の前提になる。
レジストリに最低限もたせたい属性は次のとおりだ。
| 属性 | 意味・なぜ必要か |
|---|---|
| 版（version） | ツール定義とスキーマのバージョン。どの版が本番に載っているかを固定し、変更を追跡する |
| 提供者（provider） | 社内チーム／外部ベンダー／MCPサーバーの出所。障害時の連絡先と責任範囲を明確にする |
| 権限（scope） | そのツールが持つ権限（読み取りのみ／書き込みあり／課金発生など）。最小権限を担保する根拠になる |
| SLA | 期待レイテンシ・可用性・レート制限。品質劣化を「基準からの逸脱」として検知するための物差し |
| 所有者（owner） | そのツールの運用に責任を持つ人・チーム。所有者のないツールは統制の対象外になり野良化する |
| 廃止予定（deprecation） | いつ廃止・置換されるか。移行計画を前もって回すためのフラグ |
運用のコツ：レジストリは「作って終わり」の資料ではなく、エージェントが実行時に参照する生きた設定にする。レジストリに載っていないツールは呼べない、というゲート（許可リスト方式）を敷くと、野良ツールの混入を構造的に防げる。
4. 契約テストと回帰——ゴールデンテストで”壊れ”を検知する
サイレント破壊を捕まえるには、ツールとの「契約」をテストとして固定するしかない。ここでいう契約とは、「この入力を渡せば、この形・この意味の値が返る」という約束のことだ。契約テスト（contract test）は、その約束が守られ続けているかを定期的に検証する。プロンプトやナレッジの回帰テストと同じ発想を、ツールにも適用するわけである。
ツールの契約テストで固定すべき観点は3つある。
- 入力スキーマ：どんなパラメータを、どの型・必須条件で受け付けるか。提供元がパラメータを変えたら即座に落ちるようにする。
- 戻り値：返却されるフィールドの構造・型・意味。ステータス200でも中身がズレたら検知できるよう、値の意味まで含めて検証する（金額の単位、日付形式、列挙値の集合など）。
- 副作用：書き込みや課金など、外部状態を変える動作。テスト時に実際の副作用を起こさないよう、サンドボックスやモックを併用する。
これらを代表的な入出力ペア（ゴールデンテスト）として保存し、CIやスケジュール実行で定期的に回す。外部APIに対しては、本番を叩かない「合成トラフィック」で契約だけを軽く確認する運用が現実的だ。ツールの版を上げるとき、廃止版と新版の両方に同じゴールデンテストを通すことで、移行時の後方互換性も同じ仕組みで担保できる。
5. ツール選択の可観測性——「なぜそのツールを呼んだか」を残す
エージェントは、複数の候補から自律的にツールを選ぶ。だからこそ運用側は、どのツールを・なぜ・どんな引数で呼び、成功したか／失敗してリトライしたかを後から追えなければならない。可観測性がなければ、「答えが間違っている」原因がプロンプトなのか、ナレッジなのか、ツールなのかを切り分けられない。
ツール呼び出しごとに、最低限、次を記録しておきたい。
| 記録項目 | それで何が分かるか |
|---|---|
| 呼び出したツール名と版 | どの道具の、どの版で起きた事象かを特定できる |
| 選択理由（候補と決め手） | 似たツールが複数あるとき、選択が一貫しているかを点検できる |
| 入力引数 | 誤った引数生成なのか、ツール側の不具合なのかを切り分けられる |
| 結果（成功／失敗）・レイテンシ | 品質劣化やSLA逸脱を数値で捉えられる |
| リトライ・フォールバックの有無 | 表面上は成功でも、内部で何度も失敗している”隠れ劣化”を見つけられる |
特に見落としがちなのが最後のリトライ・フォールバックだ。最終的にタスクが成功していても、その裏で毎回2回失敗してから3回目で通っているとしたら、そのツールは実質的に壊れかけている。成功率だけでなく、成功に至るまでのコスト（試行回数・レイテンシ）を見ることで、静かな劣化を早期に捉えられる。
6. ツール評価——タスク成功率への寄与度を測る
ツールは「動くかどうか」だけでなく、「タスクの成功にちゃんと効いているか」で評価すべきだ。契約テストが”壊れていないか”を見るのに対し、ツール評価は”役に立っているか”を見る。この視点がないと、レジストリはいつまでも増える一方で、実は誰も使っていない・むしろ精度を下げているツールが居座り続ける。
寄与度を測る代表的なアプローチは次のとおり。
- アブレーション（あり／なし比較）：そのツールを外した状態で同じタスク集合を流し、成功率がどれだけ落ちるかを見る。落ちなければ、そのツールは実質的に不要かもしれない。
- 対照実験：似た機能の重複ツールを、同じタスクで比較し、成功率・レイテンシ・コストで優劣をつける。勝った方に一本化する。
- 失敗の帰属分析：タスク失敗のうち、どれだけがそのツールの誤り・遅延・不在に起因するかを分類する。
評価はゴールデンなタスク集合（正解が分かっている代表シナリオ）に対して定期的に回すのが基本だ。「このツールはタスク成功率を◯ポイント押し上げている／下げている」という数字を持てて初めて、増やす・一本化する・廃止するという判断が感覚論から抜け出す。
7. 廃止・移行——deprecationと野良ツールの棚卸し
運用の最後のピースが廃止（deprecation）だ。ツールは追加されるばかりで、意図的に減らす仕組みを持つ組織は少ない。だが、使われないツール・重複するツール・劣化したツールを残すことは、選択の迷い・攻撃面の拡大・保守コストという形で確実に負債になる。増やす規律と同じ強さで、減らす規律を持つべきだ。
安全な廃止・移行は、段階を踏む。
| 段階 | やること |
|---|---|
| ①廃止予告 | レジストリに廃止予定日と後継ツールを記載。所有者と利用エージェントに通知する |
| ②並行運用 | 新旧を一時的に併存させ、同じゴールデンテスト・評価タスクで新版が旧版以上であることを確認する |
| ③切り替え | 許可リストで新版に寄せ、旧版の呼び出し量が実際にゼロになったことを可観測性で確認する |
| ④撤去 | 呼び出しがゼロになったことを確かめてからレジストリと権限を削除する。トークン・スコープも忘れず失効させる |
そして定期的に必要なのが野良ツールの棚卸しだ。レジストリと実際の呼び出しログを突き合わせ、「台帳にないのに呼ばれているツール」「台帳にあるのに誰にも呼ばれていないツール」を洗い出す。前者は統制外の混入として即座に精査し、後者は廃止候補に回す。この棚卸しを四半期などの定期作業として回すことで、能力資産は”増える一方”から”手入れされ続ける”状態へ変わる。
8. まとめ
ツールは「つないで終わり」ではない。プロンプト（指示資産）・ナレッジ（参照資産）と並ぶ能力資産として、版・品質・評価・廃止のライフサイクルで運用してはじめて、”いつの間にか壊れた道具を叩き続ける”事態を防げる。本稿の要点は次の3つに集約される。
- 台帳で束ねる——ツールレジストリを唯一の情報源にし、許可リストで野良ツールを構造的に締め出す。
- 契約と可観測性で”壊れ”を捕まえる——ゴールデンな契約テストでサイレント破壊を検知し、呼び出しログでリトライまで含めた実態を可視化する。
- 評価と廃止で”手入れ”する——寄与度を数値で測り、増やす規律と同じ強さで減らす規律を回す。
これで、PromptOps編・ナレッジ運用編・本稿（ツール運用編）による可変資産トリロジーが完結する。指示・参照・能力の3つをそれぞれ独立した運用ディシプリンとして扱えるようになれば、エージェントの挙動は「なんとなく変わってしまうもの」から「意図をもって管理できるもの」へと変わるはずだ。
よくある質問（FAQ）
Q1. ツールが少数（数個）なら、レジストリまで作らなくてもよいのでは？
数が少ないうちは台帳の恩恵が見えにくいのは事実です。ただし、レジストリの本質は「数を管理すること」ではなく「所有者・版・廃止予定を明示すること」にあります。ツールが3個でも、それぞれに所有者と版が紐づいていない状態は、いざ壊れたときに誰も対応できないという同じリスクを抱えます。むしろ少数のうちに枠組みを作っておくほうが、増えたときに慌てずに済みます。
Q2. 外部APIやMCPは提供元の都合で変わります。契約テストで本当に防げますか？
契約テストは変更そのものを防ぐものではなく、変更に気づくための仕組みです。提供元が仕様を変えたその瞬間にテストが落ちれば、下流に誤った結果が流れる前に対処できます。「防げないから測らない」のではなく、「防げないからこそ早く気づく」という発想の転換が要点です。
Q3. MCPツールポイズニング対策（セキュリティ）と、本稿の運用は何が違うのですか？
両者は補完関係にあります。ポイズニング対策は、ツール定義に悪意が仕込まれる”攻撃”への防御です。本稿の運用は、悪意がなくても起きる平時の劣化・陳腐化に対する信頼性の担保です。攻撃されていなくてもツールは壊れます。セキュリティと信頼性運用は、どちらか一方では不十分です。
Q4. ツール評価のアブレーション（あり／なし比較）は、本番で回すと危険では？
評価は本番トラフィックではなく、正解が分かっているゴールデンなタスク集合に対してオフラインで回すのが基本です。書き込みや課金を伴うツールは、サンドボックスやモックを使って副作用を起こさずに評価します。本番影響を切り離した評価環境を用意することが前提になります。
参考リンク
- Model Context Protocol（MCP）公式サイト
- OpenAI｜Function calling ドキュメント
- OWASP｜GenAI Security Project（LLMアプリのリスク一覧）
※本記事は運用設計の考え方を一般化して解説したものであり、特定の製品・サービスの動作や安全性を保証するものではありません。各ツール・APIの利用にあたっては、提供元の最新の仕様・利用規約をご確認ください。
コメント