Agent時代の安全設計 ― AIを「暴走する実行体」から「制御可能な意思決定システム」へ ―

近年、Anthropic をはじめとするAI企業によって、
エージェント技術は大きく進化しました。

AIはもはや、

・答える存在

ではなく、

動く存在（Agent）

になっています。

  • ツールを呼び出す
  • 外部データにアクセスする
  • コードを実行する
  • タスクを自律的に進める

この進化は、AIを「実用段階」へと引き上げました。

しかし、この変化は同時に、
これまで顕在化していなかった新しい課題を生み出します。

Agentをどう安全に制御するか

従来のAIは、

・出力の精度
・応答の自然さ

が主な評価軸でした。

しかし、Agentの時代では違います。

「何を出すか」ではなく
「何を実行するか」が問題になる

そして、その瞬間からAIは、

安全設計の対象（Safety-Critical System）

になります。

問題：なぜAgentは止まらないのか

Agentの導入が進む中で、現場では次のような問題が顕在化しています。

  • 不要な操作を実行してしまう
  • 本来は確認が必要な処理を自動で進める
  • 同じ入力でも判断が変わる
  • なぜその行動を選んだか説明できない

これらは一見すると、

  • 精度の問題
  • モデルの問題
  • 実装のバグ

のように見えます。

しかし実際には違います。

これは安全設計の問題です

より正確に言えば、

「停止と判断の構造が設計されていない」ことが原因です

従来のAIでは、

  • 出力の品質
  • 応答の正確さ

が主な関心事でした。

しかしAgentは違います。

AIが「行動する」ようになった瞬間、
それは安全設計の対象になります

そしてここで、最も重要な前提が現れます。

本質：Signal ≠ Decision

AnthropicのようなAgentが扱っているのは、

  • 検索結果
  • 推論結果
  • 生成された文章
  • 行動候補

つまり、

Signal（判断の材料）

です。

しかし、実際の業務で必要なのは、

Decision（最終判断）

です。

なぜこれが安全設計の問題になるのか

問題は、ここにあります。

Agentは、

Signalを生成することには非常に優れている

しかし、

そのSignalを採択する責任を持たない

この状態では、

  • 何を実行するか
  • どこで止めるか
  • いつ人に戻すか

が、すべて曖昧になります。

つまり、

「安全に止まる」ための設計が存在していない

これが、

Agentが止まらない理由です

Agentの内部構造

典型的なAgentの動作は、次のようなループ構造になっています。

State → 推論 → Action → State → 推論 → Action ...

このループは非常に強力です。

環境を観測し、
次の行動を推論し、
それを実行し、
再び状態を更新する。

この繰り返しによって、Agentは複雑なタスクを自律的に進めることができます。

しかし、安全設計の観点から見ると、ここには決定的な欠落があります。

この構造には、

  • 判断の採択（Decision）
  • 停止条件（Boundary）
  • 人間への委譲（Human）

が明示的に存在していません。

つまり、

「何を実行するか」は生成されるが、
「それを実行してよいか」は決まっていない

この状態では、

  • 行動は連続的に生成される
  • 停止は暗黙的にしか起きない
  • 人間への切り戻しも不確定になる

だからAgentは止まらない

誤ったアプローチ

この問題に対して、多くの設計では次のような対処が行われます。

たとえば、AIエージェントに対して：

  • 危険な場合は止まってください
  • 実行前に確認してください
  • 不確実な場合は人間に確認してください

一見すると、これで安全性が担保されるように見えます。

しかし実際には、こうした指示だけでは不十分です。

なぜなら、Agentは

「停止条件を厳密に判定するシステム」ではなく、
「その場でもっとも妥当そうな次の行動」を生成するシステム

だからです。

これらの指示は、

  • 明確なルールではなく
  • 曖昧な方針として解釈され

その結果、

状況ごとに異なる判断が生成されてしまう

つまり、

安全性が構造として保証されていない

その結果として、次のような問題が発生します。

例1：問い合わせ対応で勝手にクローズする

カスタマーサポートのAgentに、

「不確実な場合は人間に確認してください」

と書いていたとします。

しかしユーザーの問い合わせが、

  • 返金要求なのか
  • 単なる質問なのか
  • クレームなのか

微妙なケースだった場合、Agentはそれを厳密に“危険”と判定できません。

その結果、

  • FAQからもっとも近い回答を生成する
  • 「解決済み」とみなして処理を閉じる
  • 本来は人に渡すべきケースを自動処理する

といったことが起きます。

ここで問題なのは、Agentが命令違反をしたわけではないことです。
Agentはむしろ、「確認が必要なほど危険ではない」と解釈して、それっぽく処理を続けたのです。

例2：コード修正Agentが意図せず広範囲に変更する

開発支援Agentに、

  • 危険な変更はしないでください
  • 大きな変更の前には確認してください

と書いたとします。

しかし、あるバグ修正のために関連ファイルを複数見た結果、Agentが

  • この関数も修正した方が整合的
  • こちらの設定ファイルも更新すべき
  • テストも自動で書き換えるべき

と判断してしまうことがあります。

すると、

  • 本来は1ファイル修正で済むはずが
  • 複数ファイルに変更が広がり
  • レビューしにくい差分ができる

ということが起きます。

ここでもAgentは「暴走した」のではなく、
成功確率を上げるために、それっぽく最適化しただけです。

例3：業務Agentが削除や送信を進めてしまう

社内業務Agentに、

  • 重要な操作は確認してください
  • リスクがある場合は停止してください

と書いていたとします。

しかしAgentがメール送信、レコード更新、予約変更、削除APIの呼び出しなどを行える場合、
「どこからが重要か」は曖昧です。

たとえば、

  • 古い候補データの整理
  • 重複レコードの削除
  • 下書きメールの送信準備

のような処理は、Agentには“通常業務の延長”に見えるかもしれません。

その結果、

  • 消してはいけないデータを消す
  • 送ってはいけない相手に送る
  • 本来承認が必要な更新をそのまま実行する

という問題が起こります。

ここで見えてくる本質

これらに共通しているのは、

「止まる条件」が構造として存在していない

ことです。

プロンプトの中に

  • 危険なら止まる
  • 確認する
  • 慎重に進める

と書いても、それは単なる方針にすぎません。

Agentはその方針を、

厳密なルールとしてではなく、
文脈の中で解釈される曖昧な指示として扱います

だから、

  • 何が危険か
  • どこで止まるか
  • 誰に戻すか

が毎回ぶれてしまうのです。

なぜこれは原理的に解決できないのか

ここでさらに重要なのは、

これは実装の問題ではなく、原理的な制約である

という点です。

現在のLLMおよびプロンプトベースのAgentは、”なめらかな計算では、判断は表現できない ──AIと不連続性の問題“で述べている様に

入力された文脈に対して、次にもっとも尤もらしい出力を生成するシステム

です。

つまり内部では、

  • ルールを検証しているわけではなく
  • 条件を厳密に評価しているわけでもなく

「それっぽい次のトークン」を連続的に生成している

に過ぎません。

この構造では、

「判断（Decision）」という概念そのものが存在しない

あるのは、

  • 推論
  • 補完
  • 生成

すなわち、

Signalの連鎖

だけしかないのです。

なぜ判断が入れられないのか

本来「判断（Decision）」とは、

  • 条件を評価し
  • 採択／非採択を決定し
  • 実行責任を持つ

という行為です。

このとき重要なのは、

判断は本質的に“不連続”である

という点です。

つまり、

  • 実行するか／しないか
  • 通すか／止めるか
  • 人に戻すか／自動処理するか

といった、

離散的な分岐（discrete choice）

が存在します。

一方でLLMは何をしているのか

LLMは、

連続的な生成プロセス

です。

内部では、

  • 次にもっとも尤もらしいトークンを選び
  • それを連続的につなげていく

という処理が行われています。

つまり、

出力は連続的な確率分布の延長線上にある

ここには、

  • 明確な分岐
  • 採択の確定
  • 実行責任

といったものは存在しません。

決定的なギャップ

ここに本質的なギャップがあります。

LLMは連続的に生成する
Decisionは不連続に確定する

この2つは、構造的に異なります。

なぜ判断が成立しないのか

LLMの出力はすべて、

「生成された候補」

です。

しかしDecisionは、

「採択された結果」

でなければなりません。

このとき必要なのは、

候補の中から一つを“確定的に選び取る”主体

です。

しかしLLMは、

その採択主体を持たない

すべての出力は、

  • 文脈依存で
  • 確率的に生成され
  • 状況ごとに変化する

そのため、

  • 「止まるべきかどうか」を確定できない
  • 「この条件なら必ず止まる」という保証を持てない

連続的な生成プロセスからは、
不連続なDecisionは生まれない

これが、

プロンプトだけでは安全設計が成立しない理由です

だから必要なのは、プロンプトではなくBoundaryである

この問題を解決するには、

「危険なら止まってください」

と頼むのではなく、

  • この条件なら必ず停止
  • この条件なら必ず人間承認
  • この条件なら別Agentへ委譲

という形で、

停止条件そのものを構造として外に持つ必要があります

ここで初めて、Agentは

「止まる可能性のある存在」ではなく、
「止められる存在」になります

問題の再定義

ここまでで見えてきた本質は、非常にシンプルです。

Agentは止まらない

これは挙動の問題ではなく、

構造の問題です

では、どうすればよいのでしょうか。

正しい問い

問題はこうです：

どうやってAgentを止めるか？

ではなく

どこでDecisionを確定させるか？

あるいは、さらに踏み込むと：

どこで「通す／止める」を決めるか？

この問いに答えるためには、

Decisionを生成の中ではなく、構造として持つ必要があります

つまり、

判断を「外」に置く必要がある

そして、その構造を定義するのが、

Decision Trace Model（DTM）です

解決：Decision Trace Model（DTM）

この問題に対する解決はシンプルです。

Decisionを構造として定義すること

Decision Trace Model（DTM）は、
意思決定を次のような構造に分解します。

Event → Signal → Decision → Boundary → Human → Log

この分解によって、これまで曖昧だったプロセスが明確になります。

  • 何が起きたのか（Event）
  • どう解釈したのか（Signal）
  • 何を採択したのか（Decision）
  • どの制約を通ったのか（Boundary）
  • 人が介入したのか（Human）
  • どう記録されたのか（Log）

ここで重要なのは、

SignalとDecisionが分離されていること

そして、さらに重要なのは、

Decisionがそのまま実行されないこと

本質：Decisionは必ずBoundaryを通る

DTMにおいて、Decisionは単独では意味を持ちません。

すべてのDecisionはBoundaryを通過する必要があります

ここで初めて、

  • 実行してよいのか
  • 止めるべきか
  • 人に戻すべきか

が決定されます。

最も重要なのは「Boundary」である

この構造の中で、最も重要なのは

Boundary

です。

Boundaryとは、

Decisionを通すか、止めるかを決定する層

です。

つまり、

  • Agentが何を考えたか（Signal）ではなく
  • 何を選んだか（Decision）でもなく

そのDecisionを「通すかどうか」を決める場所

これが存在することで初めて、

停止が設計可能になります

再定義：「止める」とは何か

ここで、「止める」という行為の意味が変わります。

止めるとは、Decisionを通さないことである

Agentは止まらない。

しかし、

Decisionは止められる

そしてそれを実現するのが、

Boundaryという構造です

DTMにおける停止は、3つのパターンに分類できます。

1. Hard Stop（強制停止）

  • 権限違反
  • リスク検知
  • 不正な操作

即停止（Decisionを棄却）

2. Soft Stop（人間への委譲）

  • 不確実
  • 高リスク
  • 判断が曖昧

Humanへ委譲（Decisionを保留）

3. Redirect（経路変更）

  • 別の処理へ
  • 別Agentへ

別経路へ（Decisionを再ルーティング）

ここで重要なのは、

「止める」という行為の意味です

従来の発想では、

Agentの行動を止めようとします

しかし、それは本質ではありません。

止めるとは、Decisionを通さないことである

AgentはSignalを生成し続けます。

しかし、

  • 採択しない（Hard Stop）
  • 保留する（Soft Stop）
  • 別に回す（Redirect）

ことで、

行動としての実行は発生しません

なぜこれが重要なのか

従来の設計では、次のようなアプローチが取られてきました。

  • 行動を止めようとする
  • プロンプトで抑制しようとする
  • AIの判断に委ねる

しかしこれらはすべて、

Signalレイヤーの制御

に過ぎません。

DTMが行うのは、

Decisionレイヤーの制御

です。

AgentとDecisionの関係

役割を整理すると、非常にシンプルになります。

  • Agent → Signalを生成する
  • DTM → Decisionを採択する

つまり、

Agentは止まらない

しかし、

Decisionは止められる

最良クラスの設計思想

Signal系Agentを安全に扱うためには、
単一の対策ではなく、

多層構造による制御

が必要です。

Layer 1：到達可能性の制御（権限）

  • 接続できるツールを制限
  • API権限を分離
  • 書き込みと読み込みを分離

できないことは起きないようにする

Layer 2：Decision / Boundary（DTM）

  • Signalをそのまま実行しない
  • 必ずDecisionを通す
  • Boundaryで停止判定を行う

通すかどうかを決める

Layer 3：Human-in-the-loop

  • 承認フロー
  • エスカレーション
  • 例外処理

責任を人間に戻す

Layer 4：Log（記録）

  • 判断履歴
  • 境界条件
  • 人間の介入

再現・検証・改善を可能にする

推奨アーキテクチャ

Event
 ↓
Agent（Signal生成）
 ↓
Decision（DTM）
 ↓
Boundary（停止判定）
 ├─ STOP
 ├─ HUMAN
 ├─ REDIRECT
 └─ EXECUTE
 ↓
Execution（Agent / Tool）
 ↓
Log（Ledger）

なぜDTMが有効なのか

DTMは、

  • 判断を外在化する
  • 停止条件を明示する
  • 人間の介入を設計する
  • ログとして蓄積する

ことを可能にします。

これは単なる改善ではありません。

パラダイムの転換です

Before / After

Before（Agentのみ）

  • 自律的に動く
  • 止まらない
  • 再現できない
  • 責任が曖昧

After（DTMあり）

  • 判断単位で制御される
  • Boundaryで確実に停止する
  • 人間へ戻すポイントが定義される
  • 判断が記録され、再現可能になる

結論

AnthropicのAgent技術は、

AIを「動く存在」に変えました

しかし、それだけでは不十分です。

必要なのは、

どこでDecisionを止めるかを定義すること

まとめ

Signal系Agentを安全に制御するための最良クラスの設計思想は、

DTMを中核とした多層制御構造である

そして本質はシンプルです。

Agentは止まらない。
Decisionが止める。

最終的に、Agentが自律的に動く主体となる以上、

私たちはそれを、
自動車の製造などで求められてきたような
安全クリティカルなシステムと同じレベルで設計する必要があります。

ファイブナイン（99.999%）の信頼性は、
もはや選択ではありません。

必須条件になります。

タイトルとURLをコピーしました