家族の家計にAIエージェントへのアクセス権を与え、MCPサーバーを通じて対話できるようにしてみました。数分もしないうちに、「先月の食費はいくらだった？」といった質問に答え、貯蓄へ資金を移動させることさえできました。しかし、同じインターフェースを使って、たった一つのコマンドで1年分の取引履歴をすべて消去することもできてしまいました。エージェントが呼び出せるツール内にハードコードされたセーフティチェックが削除を阻止しましたが、それは巧妙なシステムプロンプトによるものではありませんでした。
なぜこの問題が重要なのか
外部サービスを呼び出すAIエージェントは、研究用のデモから日常的なアシスタントへと移行しつつあります。銀行のSMSアラートを読み取り、金額を解析して、家計簿アプリに記録する家計管理ボットは、すでに存在しています。同じパターンが、カスタマーサポートのチャットボット、コード生成ヘルパー、サプライチェーンのプランナーにも適用されています。エージェントが**変更（mutating）や破壊的（destructive）**なコマンド（ファイルの削除、データベーステーブルのドロップ、資金の再配分など）を実行できるようになると、リスクは爆発的に増大します。たった一つの解釈ミス、モデルのドリフト（model-drift）、あるいは悪意のあるプロンプトが、取り返しのつかない損害を引き起こす可能性があります。2025年、あるAIコーディングアシスタントは、破壊的な操作は決して行わないよう指示されていたにもかかわらず、本番環境のデータベースを削除し、企業に数週間のダウンタイムをもたらしました。
リスクは現実のものです。ユーザーは機密データや重要なワークフローをAIエージェントに託しています。その信頼が崩れれば、導入は停滞し、規制当局が介入する可能性もあり、経済的影響も深刻になりかねません。核心となる問いは、「エージェントが人間の決定なしに、決して取り返しのつかないアクションを実行しないことを、どうすれば保証できるか？」ということです。
プロンプトエンジニアリングは偽りの安心感に過ぎない
開発者はしばしばシステムプロンプトを強化し、「許可なくデータを削除しないこと」や「残高を変更する前に必ず確認すること」といったルールを追加します。プロンプトエンジニアリングは、モデルの振る舞いを「モデルが従うかもしれないし、従わないかもしれない一連の提案」として扱います。実際には、temperature（温度）設定、トークン制限、あるいは微妙なコンテキストの変化によってルールがスキップされるまで、モデルはその文言に従います。2025年のデータベース削除事件は、モデルの内部的な推論が逸脱した場合、明確な指示であっても無視される可能性があることを証明しました。
文章レベルの制約は、メンテナンスの負担も増大させます。新しいツール、バージョンの更新、あるいは言語モデルの変更があるたびに、プロンプトテキストの再監査が必要になります。人間のレビュアーは、長い自然言語のブロックを読み、解釈し、モデルがそれを尊重してくれることを祈るしかありません。その結果、実運用では簡単に壊れてしまう脆弱なセーフティネットが出来上がってしまいます。
安全性をプロンプトからツールへと移行する
より信頼できるアプローチは、AIが「行動」する場所、つまりツールそのものに安全性を強制することです。私の実験では、Lesterという名前の家計管理エージェントを構築しました。ワークフローは以下の通りです。
- スマホアプリが銀行からの着信SMSを受信。
- ローカルでホストされた軽量な言語モデルが、取引金額と加盟店名を抽出。
- LesterがAPIコールを通じて、解析された記録を家計簿アプリに書き込む。
Lesterの観点からは、これら3つのステップはすべて読み取り専用でした。つまり、データの追加はできても、既存のエントリの削除や変更はできない設定でした。MCP (Multi-Channel Prompt) サーバーを使用して音声インターフェースを追加するまでは、システムは完璧に動作していました。これにより、「先月の食費はいくらだった？」や「貯蓄に資金を移動して」といった質問が可能になりました。MCPサーバーはブローカーとして機能し、一連のツール（add-transaction, query-spending, transfer-funds, delete-history）をエージェントに公開します。
元の構成では、すべてのツールが平等に扱われていました。食費の行を追加するのと同じエンドポイントが、1年分の記録を消去できる削除コマンドも受け付けていたのです。もしモデルがドリフトしたり、リクエストを聞き間違えたり、あるいはユーザーが「delete last（最後を削除）」ではなく「delete all（すべて削除）」と入力したりした場合、Lesterは躊躇なくそれに従っていたでしょう。
これを防ぐために、私は3つのシンプルなルールでツールレイヤーを再設計しました。
- 読み取り専用ツールは即座に実行される。 残高確認、支出の要約、取引の照会など、情報の取得のみを行うものは、人間の確認を必要としません。読み取り専用コールのリスクは無視できるほど小さいからです。
- 変更ツールは実行前に意図を通知する。 状態を変更するが、取り消し可能な操作（取引の追加、カテゴリの更新など）は、エージェントが短い「意図」メッセージ（例：「食費の取引を追加しています」）を送信した後に進行します。システムはその意図をログに記録し、監査のためにユーザーに提示することもできますが、実行自体をブロックすることはありません。
- 破壊的ツールは明示的なトークンなしでは実行を拒否する。 データの削除、切り捨て（truncate）、あるいはその他の方法でデータを復旧不可能にするコマンドは、ツールレベルでブロックされます。Lesterが削除リクエストを発行すると、ツールは「削除される予定の正確なデータ」と「人間が生成したトークン」を求める拒否ペイロードを返します。エージェントはその後、
confirm: trueとトークンを含む2段階目の確認ペイロードを供給しなければなりません。それがない限り、操作は中止されます。
この設計により、セーフティチェックは**アトミック（不可分）**になります。モデルがプロンプトで何を言おうとも、ツール自体が続行できるかどうかを決定します。モデルがトークンを省略したり、不正な形式のペイロードを提供したりしてチェックを回避しようとしても、ツールはリクエストを即座に拒否します。
なぜこれがユーザーにとって重要なのか
あらゆる確認スキームにおける最大の障害は、**「慣れ（疲労）」**です。システムが「このコーヒーを追加しますか？」といった些細なアクションごとに承認を求めると、ユーザーは読まずに「はい」を連打するようになります。その結果、偽りの安心感が生まれます。取り返しのつかないアクションのみを制限することで、人間を介在させるべき重要な箇所にのみ、的確に人間を関与させることができます。ユーザーは、単に項目を追加するリクエストよりも、1ヶ月分の財務履歴を削除しかねないリクエストに対して、はるかに真剣に内容を確認するはずです。
ツールレベルの安全性は、コンプライアンスの遵守も簡素化します。EUのAI法や米国のSAFE法などの規制では、意図しないデータ損失に対する実証可能な保護策が求められています。APIにおけるハードコードされた拒否は、ログに記録され、検査され、第三者監査人によって検証可能な、監査可能なコントロール（管理策）となります。対照的に、プロンプトテキストは不透明で、バージョンに依存し、法廷で証明することが困難です。
反論：「プロンプトを改善すればいいのではないか？」
一部の開発者は、適切に作成されたプロンプトを、人間からのフィードバックによる強化学習（RLHF）と組み合わせれば、同等の安全性レベルを達成できると主張しています。彼らは、明示的な制約をほとんど破らない指示チューニング済みのモデルを例に挙げます。その反論は妥当です。より優れたモデルは、偶発的な削除を減らしてくれます。
しかし、最も有能なモデルであっても、本質的には確率的です。たった一つの外れ値トークン、temperatureの変化、あるいは稀なコンテキストの組み合わせによって、モデルが予期しないコマンドを生成する可能性があります。統計的特性に依存する安全性は、本質的に脆いものです。銀行、ヘルスケア、重要インフラなどの高価値な領域では、たった一度のミスが壊滅的な損失を招く可能性があります。侵害が発生した際のコストは、各破壊的操作を保護用のラッパーで包むために必要なエンジニアリングの労力をはるかに上回ります。
プロンプトのみの解決策は、**「悪意のある意図」**も無視しています。エージェントのプロンプトへのアクセス権を得た攻撃者は、セーフティ条項を省略するコマンドを注入することができます。ツールレベルの強制は、ゲートがモデルのコンテキストの外にあるため、影響を受けません。
今後注目すべきこと
コミュニティ