MCP時代のエージェント設計：観測可能性とガードレール
完全自立エージェントを本番運用する際に必要な、観測・評価・制御の三要素について整理します。
by UNEEK AI Team
Model Context Protocol（MCP）の普及によって、エージェントが扱える「外部の手」は一気に増えました。社内DB、Slack、GitHub、デザインツール、ファイルストレージ──それぞれを個別に統合せずとも、共通のプロトコルで“道具”として渡せる時代です。一方で、エージェントが自律的に動くほど、運用上の悩みも変わってきます。「いつ・何を・なぜやったのか」を後から説明できるかどうか。私たちはこれを“観測可能性（Observability）”と呼び、ガードレールと評価とセットで設計しています。
1. なぜ“動くだけ”では足りないのか
デモまでは比較的すぐに作れます。LLM＋ツール呼び出しを並べれば、シナリオ通りには動いてくれる。しかし、本番に乗せた瞬間に出てくる質問はだいたい次の3つです。
- なぜ今回はこのツールを呼び出した？（再現性）
- 想定外の入力に対しても安全に止まる？（安全性）
- 改善のために何を直せばよいかを、データで言える？（評価可能性）
これらは“あとから足す”のがとても難しい性質を持っています。本番に乗ったあとは、ログのスキーマも、評価データも、人の判断も、後付けで揃えづらい。最初の設計段階で“観測・制御・評価”の3点を意識しておく必要があります。
2. 観測可能性：エージェントの「思考の足跡」
私たちが必ず残すようにしているのは、次の4種類のイベントです。
- ユーザー入力（生データと正規化後の双方）
- LLMへのプロンプト・モデル・温度・トークン使用量
- ツール呼び出しの引数・結果・所要時間
- 最終応答と、その応答に至った経路の要約
3. ガードレール：止めるべきところで、ちゃんと止まる
“自律”と“暴走”の境目はガードレールが握っています。私たちは、次のような階層で設計するのが現実的だと考えています。
入力側のガードレール
- プロンプトインジェクションの検出（指示書の上書きを試みる入力）
- PII（個人情報）の検出と必要に応じたマスキング
- 業務上の禁止トピックのスクリーニング
ツール側のガードレール
- 破壊的操作（削除・送信・課金）はヒューマン承認を必須に
- ツールごとのレート制限・タイムアウト
- 副作用のあるツールはドライラン → 実行のステップを分ける
出力側のガードレール
- 応答に含まれるPII・機密情報のチェック
- 業務ルールに対する整合性チェック（金額・期日・対象範囲など）
- “分からない時は分からないと言う”ためのフォールバック設計
4. 評価：定性的な手応えを、定量的な指標に
エージェントの良し悪しは、最終的にはユーザーの“納得感”で決まります。ですが、それだけでは改善のサイクルが回りません。私たちは、最低限以下の3つを揃えるところから始めます。
- 回帰用ゴールデンセット：壊してはいけない代表ケースを30〜100件用意する
- シナリオ評価：複数ターンのタスク達成率・ツール選択の妥当性をLLM-as-a-Judgeで採点
- 人手評価：週次サンプリングで、定量指標と人の感覚のズレを監視
完璧なエージェントを作るのではなく、壊れたことに気づける仕組みを作る。
— UNEEK AI Team
5. まとめ：MCPは前提、勝負はその先にある
MCPの登場でエージェントの“接続コスト”は劇的に下がりました。これからの差別化は、接続後の運用、つまり観測・ガードレール・評価のセットを、どれだけ自然に設計に組み込めるかにかかっています。UNEEKでは、PoC段階からこの3点を“あたりまえに”組み込むことを推奨し、伴走させていただいています。