IAMを置き換えずにAIエージェントの統制を導入する方法

概要

AIエージェントは、実際のシステムにプログラムによる操作を行う、人間以外のIDです。そのため、人のID向けに作られた従来のIAM・PAMツールでは管理できません。
第1段階は、エージェントのIDを既存のIdPに連携し、SSOとRBACを通じて人の役割の権限に対応付けることです。認証情報が別の場所に孤立するのを避けます。
第2段階は、許可・拒否の強制をLLMから決定論的なルールベースのワークフローへ移すことです。LLMは分類、抽出、振り分けだけを担います。
第3段階は、機密の内容を送信せず、署名付きの調整メタデータを記録する、監査に対応した証拠の履歴を作ることです。隔離環境と規制の要件を満たします。
Jinba Flowは、SSO/RBAC、80%が決定論的なワークフロー、オンプレミス・プライベートクラウドの監査ログ、SOC II準拠、確率的エージェントの15〜60分の1の運用費用により、このモデルを実運用に落とし込みます。

どのAIガバナンス基盤のベンダーも、円滑な統合を約束します。しかし、セキュリティの設計担当者やデジタル変革の責任者は、AIエージェントには、既存のIAM・PAMツールが提供する設計になっていないID、アクセス、監査のインフラが必要だと一貫して気付いています。ベンダーのデモと、規制対象の本番運用の要件との隔たりが、本記事で扱う中心的な問題です。

根本の問題は構成にあります。従来のIAM・PAMツールは人のIDを管理します。AIエージェントは、実際のシステムとデータに対してプログラムによる操作を行う、人間以外のIDです。規制環境のAIエージェント統制基盤は、既存ツールが答えるようには作られていない問いに直面します。社員証も雇用記録もなく、判断に責任を負う自然人もいない実体を、どう管理するのでしょうか。

銀行では、これは具体的な運用要件です。取引記録、顧客データ、制裁対象の確認に関わるすべてのAIは、厳格で実証可能な統制の下で動く必要があります。隔離環境では、これらの統制をクラウド型のガバナンス層に依存させられません。IAM基盤を意図的かつ段階的に拡張する方式が必要です。

以下の3段階モデルは、具体的な道筋を示します。エージェントの権限を既存のID枠組みに対応付け、確率的な推論ではなく決定論的な実行で方針を強制し、社内のコンプライアンス部門と外部の規制当局の両方を満たす証拠の履歴を構築します。

第1段階：ワークフローの権限をエージェントのIDに対応付ける

よくある実装の誤りは、エージェント向けの別のID保管場所を作ることです。AIエージェントのための独立した未管理の認証情報ストアは、長年のIAM投資で強制してきたセキュリティ統制の外に置かれます。エージェントがActive Directory、PAMによる保管、役割に基づく権限を回避する認証情報で動けば、ガバナンスモデルは破綻します。

MicrosoftのAIエージェント向けセキュリティ指針は、ID、アクセス、ツールへの結び付けという3つの連動する統制を、同時に適用しなければならないとしています。ディレクトリへの所属だけでは不十分です。Active Directoryに登録されていても、ツールの権限が別管理であるエージェントは、個々の制御面では検知できない形で、意図した権限を超えることがあります。

これを避ける実装パターンは、フェデレーションです。エージェントのIDプロバイダーを、OIDCまたはSAMLを使い、Active Directory、Okta、または同等の既存IdPに連携します。OktaのAIエージェント向け最小権限の指針は、実務上の意味を明示しています。新しい権限構造を並行して作るのではなく、エージェントを既存のID、役割、権限に対応付けます。

多くの導入が停滞するのは、技術作業に先立つ業務上の対応付けです。連携を設定する前に、エージェントがどのワークフローを実行し、どのデータストアにアクセスし、現時点でどの人の役割が同等の権限を持つかを、組織は文書化する必要があります。KYC分析エージェントは、KYC担当者の権限を引き継ぎ、その役割の人がアクセスできるのと同じシステムとデータの範囲に制限されるべきです。

Jinba Flowは、これを直接支援する設計です。標準のSSO・RBAC連携が、ワークフロー実行の権限を既存ディレクトリで定義された役割に結び付けます。Jinba Flowで作ったワークフローの実行時の権限は、企業の境界の外で管理する独自の認証情報ではなく、確立した役割割り当てに結び付きます。融資処理のワークフローを実行するエージェントは、Loan Underwriterグループの権限だけで動き、それを超えません。これにより、別のインフラ構築プロジェクトを必要とせず、ガバナンスモデルのIDとアクセスの柱を実装します。

第2段階：エージェントの操作を決定論的なワークフローで包む

ID連携はエージェントの身元を確立します。しかし、ある状況でエージェントに何が許されるかという強制の問題で、多くのエージェント型AI導入はガバナンス審査に失敗します。

失敗の原因は構成です。許可・拒否の判断をLLM自体が行うと、ガバナンスは確率的になります。モデルが文脈から推論し、操作を生成します。その操作が方針の範囲内だったかどうかは推論となり、モデルの更新、微調整、プロンプトの変更に伴って変わります。Antoine Buteauによる企業LLM構成の分析が記録するように、LLMを企業の実行基盤に使うと、実際のデータに対して行使される権限が過大または無制限に付与されます。個々の判断がコンプライアンスに適合していたと証明する決定論的な根拠はありません。

実用的なガバナンスモデルは、LLMを実行基盤ではなく窓口として扱います。その役割は抽出、分類、振り分けです。取引を承認するか、文書がコンプライアンスの基準を満たすか、現在の方針で操作が許可されるかといった、結果に影響する判断は、入力、ロジック、出力を完全に検査できる決定論的なワークフローエンジンで実行する必要があります。

規制業界は、モデルリスク管理ですでにこの原則を適用しています。FINRAおよびFederal ReserveのSR 11-7指針は、モデルに基づくすべての判断が検証され、監視され、説明可能であることを求めています。確率的な実行基盤は、この基準を満たせません。決定論的なワークフローエンジンは、構造上満たします。

実装では、結果に影響するすべてのエージェント操作を、明示的なルールベースの手順で包む必要があります。実行前に方針の制約を確認します。業務ルールは定義された順序で適用します。出力は、実行の瞬間のモデルの文脈内推論ではなく、それらのルールから導かれます。

Jinba Flowは、この構成上の分離を直接実装します。チームが自然言語で自動化を説明すると、Jinbaがワークフローの草案を生成します。出力は、明示的なルールベースのステップからなる決定論的なワークフローです。Jinbaの構成は80%がルールベースで、方針は実行時にモデルが推論するのではなく、ワークフローエンジンが強制します。LLMは、文書からのフィールド抽出、要求の種類の分類、構造化出力の生成といった言語処理を担当します。ワークフローエンジンは、条件確認、ルール適用、方針確認による操作の制限といった判断を担当します。

この設計には、規制業界のCFOが現在注目している直接的な費用の影響があります。企業規模でワークフローを実行するたびに確率的なLLMエージェントを動かすと、正当化が難しいAPI費用が発生します。Jinbaの決定論的な構成は、月額$5〜$20で大規模運用できます。同等の確率的エージェントでは$300以上です。この15〜60倍の費用差は、プロンプト最適化の成果ではなく構造に由来し、AI API支出に対するCFOの反対に直接答えます。

第3段階：監査に対応した証拠の履歴を確立する

第3段階で、エージェントのガバナンスが法的な説明に耐えるものになります。ID連携はエージェントが誰かを確立します。決定論的な実行は、何をなぜ行ったかを確立します。証拠の履歴は、この両方の事実を検査官に証明できることを確立します。

銀行では、規制要件は明確です。SR 11-7とGLBAは、モデルに基づく判断が検証され、監視され、完全な検査の対象になることを求めます。検査官は、自動化された判断の背後の推論の連鎖について提出を命じられます。確率的なシステムは、その命令に信頼できる回答を持ちません。決定論的なワークフローは、構造上、受け取った各入力、適用した各ルール、確認した各条件、生成した各出力を、ステップごとの実行記録として生成します。

隔離環境での技術的な課題は、ガバナンス層が見る必要のあるものと、取り込んではいけないものを分けることです。機密の顧客データ、取引の内容、PIIは、中央のガバナンス基盤に送信できません。一方、どのエージェントが動き、どのワークフローを実行し、どのステップが完了し、時刻はいつだったかという調整メタデータは、記録して監査に提供する必要があります。

両方の要件を満たす構成は、暗号学的に署名された信頼境界を使います。通常はEd25519で署名したWebSocketチャネルとして実装し、ibl.aiの銀行向け隔離AIの分析で説明されています。ガバナンス層は、データ内容そのものを受け取らず、特定のエージェントが特定の時刻に特定のワークフローを実行したと確認できる、署名付きメタデータを受け取ります。この構造は、データ所在の義務に違反せず、証拠の管理連鎖の要件を満たします。

Jinba Flowは、オンプレミスとプライベートクラウドの導入方法を通じて、このパターンをサポートします。基盤全体が企業の境界内で動きます。機密データは銀行の環境を出ません。すべてのワークフロー実行は、Jinba内蔵の監査ログに記録され、最初の要求から最終出力まで、決定論的な実行の連鎖の各ステップを保存します。業務ユーザーがJinba Appからワークフローを実行する場合、RBACで制御されたアクセスと、セッション全体の追跡可能性の下で、ユーザーの入力から管理された操作まで、やり取り全体が記録されます。

JinbaはSOC IIに準拠し、基盤自体を管理するセキュリティ統制について第三者の検証を提供します。規制対象企業にとって、この認定は、Jinbaのセキュリティ、可用性、機密性の統制が独立評価の基準を満たすという、第三者に検証された証明です。銀行のCISOやリスク委員会に提示する際、セキュリティ審査の期間を短縮する種類の証拠となります。

設計図から導入へ

この3段階モデルは、既存システムを置き換えるのではなく拡張するため、繰り返し適用できるパターンとして機能します。

第1段階の、ワークフローの権限をエージェントのIDに対応付ける作業は、フェデレーション、SSO、RBACを使い、エージェントを既存のIAM基盤の管理下に置きます。別の監査が必要になる、独立した保管場所や新しい認証情報インフラを避けます。

第2段階の、決定論的なワークフローで方針を強制する作業は、強制層から確率的な推論を取り除きます。LLMは分類と振り分けを行い、ワークフローエンジンは判断し、実行します。結果に影響するすべての操作は、明示的で検査可能なルールの産物です。

第3段階の、証拠の履歴を確立する作業は、機密データを隔離境界の外に送信せず、企業の境界内のすべての実行について、規制当局に対応できる監査記録を生成します。

これらを組み合わせると、IAMを全面的に撤去・置換するプロジェクトの費用、リスク、期間を伴わず、機能するAIエージェント統制基盤を実現します。導入モデルが既存インフラの設計上の限界内で動くため、ベンダーの約束と本番の現実の隔たりが狭まります。

この構成を支援付きで進めたい銀行、保険会社、信用組合、その他の規制対象企業に、Jinbaのコンサルティング部門は戦略助言以上の支援を提供します。MUFGとMitsubishi Bankを含む約70件の企業導入実績に裏付けられ、Jinba Consultingは、Big Fourの支援で一般的な6〜12か月ではなく、数週間で評価から動くワークフローへ進みます。入口は無料のAI戦略評価です。AIへの準備状況と自動化の機会を無料で評価し、CIOがそのまま取締役会に提示できる報告書を作成します。

開始はこちら：jinba.io/consulting。

よくある質問

銀行のAIエージェントガバナンスとは何ですか？

銀行のAIエージェントガバナンスとは、AIエージェントが安全に、コンプライアンスに適合し、最小権限で動くことを保証する、ID、アクセス、方針、監査統制の枠組みです。従来のIAM・PAMを、実際のシステムとデータにプログラムによる操作を行う人間以外のIDへ拡張します。フェデレーション、決定論的な実行、証拠の履歴を使い、SR 11-7のような規制基準を満たします。

従来のIAM・PAMツールがAIエージェントへの対応に苦労するのはなぜですか？

従来のIAM・PAMツールは、プログラムで動く人間以外のエージェントではなく、人のIDを管理するために作られています。AIエージェントには、細かなツールへの結び付け、方針に基づく実行時の強制、すべての操作の監査証跡が必要です。従来のIDシステムに欠けるこれらの機能が、ガバナンスの隙間とコンプライアンスリスクにつながります。

銀行はAIエージェントのIDとアクセスをどう扱うべきですか？

銀行は、OIDCまたはSAMLでエージェントのIDを既存のIdP（Active Directory、Okta）に連携し、同等の人の役割に対応付け、RBACで最小権限を強制すべきです。これにより、認証情報の別の保管場所を作らず、エージェントを人の従業員と同じアクセス統制の下に保ちます。

AIエージェントガバナンスにおける決定論的なワークフローの役割は何ですか？

決定論的なワークフローは、LLMの推論ではなく、明示的なルールベースのステップで方針を強制します。LLMは言語タスク（抽出、分類）を担当し、ワークフローエンジンは検査可能なルールに基づいて許可・拒否を判断します。これにより、コンプライアンスを証明でき、モデル更新やプロンプト変更のリスクを減らします。

AIエージェントの判断で、確率的な推論がコンプライアンスリスクとなるのはなぜですか？

確率的な推論は、許可・拒否の判断が、モデル更新、微調整、プロンプトによって変わる推論になるため、リスクがあります。規制当局は、検証済みで説明可能な判断を求めます。LLMを実行基盤にすると、コンプライアンスの決定論的な証明がなく、無制限の権限付与が生じます。

銀行は隔離環境で、エージェント型AIの監査証跡をどう構築できますか？

銀行は、調整メタデータと機密データを分離することで、監査証跡を構築できます。暗号学的に署名された信頼境界（例：Ed25519 WebSocket）が、顧客データやPIIを送信せず、誰が何をいつ実行したかを含むエージェントのIDとワークフロー実行の詳細を送ります。証拠の管理連鎖とデータ所在の要件を満たします。

AIエージェントガバナンス導入の3段階とは何ですか？

3段階は、（1）フェデレーションとRBACでワークフローの権限をエージェントのIDに対応付ける、（2）エージェントの操作を決定論的なワークフローで包み、方針を強制する、（3）監査に対応した証拠の履歴を確立する、です。既存のIAMを置き換えるのではなく拡張します。

Jinba Flowは、規制業界で管理されたAIエージェントをどう支援しますか？

Jinba Flowは、SSOとRBACを標準で統合し、自然言語から決定論的なワークフローを生成し、監査ログを内蔵したオンプレミスまたはプライベートクラウドで動くことで、管理されたAIエージェントを支援します。SOC IIに準拠し、費用効率に優れ（月額$5〜20に対して$300以上）、MUFGやMitsubishi Bankなどの企業導入実績に裏付けられています。