🔐

AIエージェントを本番に出せない本当の理由

に公開
Security
llm
生成 AI
ナレッジグラフ
AIエージェント
tech

AIエージェントを本番に出せない本当の理由

この記事は独立して読めます（約8分）

問題：「動く」と「出せる」の間にある壁

「技術的には動くのに、セキュリティレビューで止まった」

日本のエンジニアと話すと、この話が繰り返し出てきます。PoC環境では問題なく動作する。デモも成功した。しかし本番投入の承認プロセスに入ると、CISO（最高情報セキュリティ責任者）やセキュリティ部門から矢継ぎ早に質問が来て、答えられないものが出てくる。

日本固有の事情もあります。個人情報保護法の改正対応・社内セキュリティポリシーへのAI適用基準未整備が重なり、「技術的には動く」エージェントが承認プロセスで止まる構造的な課題があります。セキュリティ部門が「生成AIは使うな」と方針を出しているまま議論が前に進まないケースも少なくありません。

その場で止められる質問は、だいたいこの3つに集約されます。

  1. 権限の問い：「このエージェントは誰の権限で動くのか。見てはいけないデータにアクセスしないと保証できるか」
  2. 追跡可能性の問い：「何をしたか全部トレースできるか。なぜその判断をしたか説明できるか」
  3. ロールバックの問い：「間違えたとき、元に戻せるか」

これらの問いに「はい」と答えられないエンジニアが多いのは、能力の問題ではありません。安全設計が後付けになっているからです。

動いてから安全を考える設計では、この3つの問いに答える仕組みが最初から存在しません。動いているコードを後から改修してセキュリティ要件を満たそうとすると、アーキテクチャの根幹から変えなければならない事態が発生します。

ナレッジグラフはどう貢献するか

KGの貢献：権限構造の表現と監査証跡の記録

ナレッジグラフ（以下KG）がエージェントの安全設計の土台として機能できる理由は、「誰が何にアクセスできるか」という関係性を、グラフ構造として表現・走査できるからです。

権限構造をグラフで表現する

RDBのロールテーブルは「誰にどの権限があるか」を記録できますが、「誰がどのエージェントを介してどのリソースに触れるか」という多段の委任関係は、テーブルJOINが深くなるにつれて複雑になります。

KGであれば、この委任関係をエッジとして直接表現できます。

エージェントに委任されたアクセス権限は、委任元のユーザーの権限範囲を超えません。KGのクエリ自体がアクセス制御として機能します。見えないノードには辿り着けない構造です。

変更履歴をイベントとして記録する

KGの変更をイベントとして記録することで、「何をしたか」の監査証跡が構造化されたデータとして残ります。誰が、いつ、どのエンティティにどの変更を加えたかがグラフの中に刻まれます。

「なぜそう判断したか」を残す

エージェントが意思決定を下した際、その時点でKGから参照したコンテキスト（どのノードを見たか、どのエッジを辿ったか）を記録します。これにより「何をしたか」だけでなく「なぜそう判断したか」が後から追跡できます。これが「追跡可能性の問い」への設計回答です。同じ権限・同じ入力なら常に同じパスを辿るため、再現性を持って説明できます。

グラフのバージョン管理によるロールバック

KGのノードとエッジの変更を時系列で保持する設計にすると、特定の時点の状態への復元が可能になります。「エージェントが誤った変更を加えた」場合でも、KG上の変更をそのコミットごと巻き戻せます。これが「ロールバックの問い」への設計的な答えです。

設計上の帰結: 権限がグラフ構造で制御されていると、同じ権限を持つユーザーは同じパスを辿り、同じ回答を得ます。見る人によってアクセスできるノードが変わるため回答は異なり得ますが、その差は権限に基づく正当な差分であり、LLMの気まぐれではありません。同じ権限・同じ質問なら常に同じパスを辿る。この一貫性が「説明可能な回答」を可能にします。

KGだけでは不十分な領域

ここまで読んで「KGを入れれば解決する」と思った方に、正直に補足します。KGはこの問題の土台にはなりますが、KG単体では以下の領域を解決できません。

権限継承のランタイムチェック

KGは「誰が何にアクセスできるか」という権限構造を記録できます。しかしエージェントが動作する各ステップで、リアルタイムに権限を検証する仕組みはKGの責務ではありません。ステップAで適正だった権限が、ステップBでは越権になっているケースを検知するには、ランタイムの権限チェック機構が別途必要です。

特権昇格の防止

「エージェントAがエージェントBに処理を委任した結果、エージェントBが元のユーザー権限より広い範囲にアクセスした」という特権昇格のリスクがあります。KGは委任関係の記録はできますが、実行時に権限が委任元を超えないことを保証する仕組みはKGの外にあります。

HITL（Human-in-the-loop）

高リスクなアクション（データの大量削除、外部への送信、財務システムへの書き込みなど）を実行しようとしたとき、エージェントを一時停止させて人間の承認を待つ仕組みが必要です。これはKGではなく、ワークフロー・オーケストレーション層の責務です。

アンドゥ（元に戻す）

KGのバージョン管理は「特定の時点の状態を記録する」設計ですが、エージェントが実行した書き込み操作を「なかったことにする」には、トランザクション管理機構が別途必要です。特に外部システムへの副作用（メール送信、Slack通知、外部APIへの書き込み）は、KGのロールバックだけでは元に戻せません。

承認スコープの設計

エージェントへの権限委任は永続的に与えるべきではありません。「今回の操作だけ（Once）」か「このセッション中は許可（Session）」かのスコープ設計が必要です。このスコープ管理もKGの外の問題です。

これらの制約はトレードオフを伴います。権限チェックを各ステップで行うと性能コストが発生します。HITL設計はエージェントの自律性を制限します。監査ログの蓄積はストレージコストと検索性のバランス問題を生みます。「安全にする」ことと「使いやすくする」ことは、設計上の緊張関係にあります。

参照実装：DevRev Computer の安全設計

DevRev Computerは、上記のKGの貢献とKGの限界を組み合わせて本番スケールで実装しているシステムの一つです。

KGでカバーできる範囲

ComputerのMemory（KGベースのエージェント基盤）に権限構造を組み込み、クエリ時にアクセス制御を実現しています。ユーザーが持つ権限情報はKGのエッジとして表現されており、エージェントのクエリはそのエッジを参照して自動的にスコープが絞られます。

KGだけでは不十分な範囲を補完する設計

KGが解決できない4つの領域に対して、DevRevは独自の機構を持っています。

課題 DevRevの実装
権限継承のランタイムチェック Permission Inheritance: フィールドレベルまでのリアルタイム権限継承。各ワークフローステップで検証
特権昇格の防止 委任先エージェントが構造的に元エージェントの権限を超えられない設計
HITL 重大アクションの一時停止と承認スコープ（Once/Session）の実装
アンドゥ AIアクションのワンクリックロールバック機構

加えて、全決定・全アクションを推論コンテキスト込みで記録する「監査ネイティブ設計」を採用しています。「何をしたか」ではなく「なぜそう判断したか」まで記録することで、後から問題が発覚したときのトレースを可能にします。

Memory 3階層（Personal / Team / Organizational）

DevRevはKGの上に3階層の記憶構造を持っています。個人の作業履歴（Personal）、チームの共有知識（Team）、組織全体のナレッジ（Organizational）です。この3階層は権限設計とも連動しており、どの階層の情報にアクセスできるかがユーザーのロールに応じて制御されます。

今日から始める1ステップ

KGを持っていなくても、今日から始められることがあります。

次にやるべき1ステップ：自分のエージェントの権限チェックロジックを疑似コードで書く。

具体的にはこういう問いに答える関数のインターフェースを定義してください。

def can_access(user_id: str, resource_id: str, action: str) -> bool:
    """
    このユーザーは、このリソースに対して、このアクションを実行できるか？
    """
    pass

def log_decision(agent_id: str, action: str, context: dict) -> None:
    """
    エージェントが下した判断とその時点のコンテキストを記録する
    """
    pass

def create_checkpoint() -> str:
    """
    現在の状態のスナップショットを作成してIDを返す
    """
    pass

def rollback_to(checkpoint_id: str) -> bool:
    """
    指定したチェックポイントの状態に戻す
    """
    pass

KGの実装は後からで構いません。まず「どこで権限チェックが必要か」「何を記録すれば追跡可能になるか」「どこからロールバックできればよいか」を明確にすることが先です。この疑似コードがあれば、セキュリティレビューで「どう設計するつもりか」を伝えられます。

権限管理の外側のレイヤ設計に興味がある方はこちらの記事も参考になります。
LLM/RAGの曖昧性を抑える「形式レイヤ」の実装ガイド

CxO・CISOの方へ: AIエージェントの本番承認時に、以下の3つの問いをチェックリストとして使ってください。「このエージェントは誰の権限で動くか、明示できるか」「全アクションをトレースし、なぜその判断をしたか説明できるか」「間違えたとき、元に戻せるか」。YesとNoが言えない項目が、対処すべきギャップです。

このシリーズの記事

記事 テーマ
AIエージェントが毎回データを取りに行く設計の限界 scatter-gather問題の設計回答
ナレッジグラフをエージェントの「記憶」にする設計 スキーマ設計と名寄せ
ツールを100個並べてもAIエージェントは賢くならない Skillの先にあるデータ基盤の問題
AIエージェントを本番に出せない本当の理由 権限・監査・ロールバック（本記事）

更新履歴

  • 2026-05-24: 初版公開

フィードバック受け付け

本記事は AI を活用して執筆しています。内容に誤りや追加情報があれば、Zenn のコメントよりお知らせください。

GitHubで編集を提案

Discussion