AIエージェント×SOX内部統制：民主化する設計と民主化してはいけない権限の境界線
前編からの接続——設計レイヤーへ降りる
前編では、AIエージェントが内部統制に持ち込む5つの監査論点（SoD崩壊・変更管理の境界曖昧化・証跡不足・プロンプトインジェクション・継続監視）を整理し、海外金融機関の実装例と技術ハーネス（Bedrock Guardrails、Human-in-the-Loop、変更管理）の「何を使うか」を示した。
本稿はその一つ下、設計レイヤーに降りる。責任をどう分解するか、権限をどう絞るか、承認をどう類型化するか、アーキテクチャをどう構成するか、そして社内規程をどう書くか。日本企業が実際に直面する「AIを業務に使いたいが、J-SOX対応ができているか自信がない」という問いに、設計の言葉で答えることを目的とする。
核心命題——民主化する部分と、民主化してはいけない部分
AIエージェントは民主化する。しかし、権限・本番接続・ログ・承認・証跡・変更管理は民主化してはいけない。
業務部門の担当者が自分のユースケースに合わせてエージェントを作り、改善するという流れは止められないし、止める必要もない。問題は「民主化」の範囲を曖昧にしたまま、本番システムへの接続権限や承認プロセスまで現場に委ねてしまうことだ。この境界線を設計に明示することが、2026年以降のAI内部統制の核心である。
責任分界の6主体——AIは責任主体になれない
AIエージェントが業務プロセスに組み込まれると、「誰が責任を負うのか」という問いが必ず浮上する。答えは明確だ。AIエージェントは責任主体にはなれない。「設計通りに動いたかどうか」を問われる対象であり、判断の責任は常に人間が担う。
責任は以下の6主体に分解される。
| 主体 | 役割 | 監査時に示す証拠 |
|---|---|---|
| AIエージェント | 承認済み範囲の実行・分析・起案 | Agent台帳・Permission Manifest・実行ログ |
| 承認者 | 取引・変更の妥当性判断、例外承認 | 承認画面スナップショット・承認ログ |
| 業務責任者 | プロセス全体の統制設計・運用 | 業務フロー文書・RCM・受入記録 |
| IT/AIオーナー | 権限・ログ・変更管理・接続の技術的制御 | 変更管理記録・権限レビュー・ログ保存 |
| SOX/J-SOX責任者 | 統制設計・RCM・評価・監査対応 | RCM・評価調書・是正記録 |
| 経営者（CEO/CFO） | 内部統制全体の整備・運用・評価責任 | 内部統制報告書・経営者確認書 |
監査で「AIが判断したので承認済みです」という説明は通用しない。承認者は、AIが提示した処理内容・対象・影響範囲・例外情報を確認した上で、業務上の妥当性に対する責任を個人として負う。この構造を明示することが、J-SOX評価において統制整備の第一歩となる。
権限は「積集合」で設計する
AIエージェントに与える権限の設計で最も陥りやすい罠は、共通サービスアカウントによる広範囲参照だ。「どのエージェントからも同じ認証情報でSalesforceに接続する」という構成は、運用は楽だが統制上は致命的になりえる。承認者が参照できない情報をAIが参照し、その要約を承認者に提示すれば、アクセス統制が実質的に迂回される。
AIエージェントの実効権限は次の積集合で定義されなければならない。
AIエージェントの実効権限
= 人間ユーザー / 承認者の権限
∩ Ticketで承認された対象範囲
∩ 業務プロセス上許可された操作
∩ データ分類上許可された範囲
∩ Tool Gatewayで許可されたAPI
∩ 時間・件数・金額などの実行条件
この公式が示すのは、AIエージェントは「人間権限以上の情報を持てない」という原則だ。望ましい実装は3点に集約される。On-Behalf-Of（delegated access）で承認者本人の権限を委譲する、Ticketの対象レコードだけに接続スコープを絞る、Tool Gatewayで実行時に権限条件を強制する——この3点がそろって初めて積集合の設計が機能する。前編で触れた Permission Mode（Claude Agent SDK の plan モード）や MCPスコープは、この Policy Engine 層と Tool Gateway 層に対応する技術実装にあたる。
さらに、エージェントは役割に応じて2種類に分離する必要がある。承認者の判断を支援する「承認者Copilot」は、承認者本人の参照権限の範囲で要約・差分・リスクを提示するにとどめ、本番更新や承認の代行は行わない。承認済み処理を実行する「業務実行Agent」は、サービスアカウントを使うが操作を承認済み対象のみに限定し、before/after差分を保存して承認内容と実行内容を自動照合する。両者を同じ権限で動かすことは避けなければならない。これは前編で示した Two-Agent Rule を設計レイヤーに翻訳したものだ。
承認は「4類型」を組み合わせる
全件承認を徹底しようとすると、AIエージェント導入の効率化効果が失われる。かといって承認をすべて省略すれば内部統制が崩れる。この対立を解消するのが、リスク階層に対応した4類型の承認設計だ。経産省「財務報告に係るIT統制ガイダンス 追補版」（2024年）も、統制効率化においてリスクに応じた承認設計を求めており、全件承認の一律適用は推奨されていない。
リスク階層は処理の影響度で6段階に区分される。
- L0: 情報参照のみ（検索・閲覧）
- L1: 社内向け下書き生成（要約・草稿）
- L2: 提案・差分提示（本番に書き込まない）
- L3: 限定的な本番読み取りや可逆的更新
- L4: 財務・契約・マスタへの提案や実行計画作成
- L5: 本番更新・支払・権限変更など不可逆処理
4類型は次のように整理される。
- 事前包括承認（Pre-blanket）: 定型・低リスク処理についてルール自体を事前承認する（L0–L2相当）。検索・要約・下書き生成など、本番データを書き換えない処理が対象だ。
- 例外承認（Exception-only）: 通常はAIが自動実行し、閾値超過・初回取引・データ不整合が発生した場合のみ人間に承認を求める（L2–L3相当）。効率化の主戦場となる類型だ。
- バッチ承認（Batch）: 同種・同条件の処理をまとめて一括承認する（L3相当）。承認者には差分・対象・影響額・サンプル一覧が自動提示される。
- 高リスク個別承認（Per-item, dual）: 財務報告・契約・マスタデータ影響を持つ処理は個別承認を維持し、高リスク処理は二重承認（dual control）を要求する（L4–L5相当）。AIは差分・根拠・リスク・証跡を承認者へ自動提示するにとどまる。
リスクL0–L1は原則承認不要でログと利用ルールで運用し、L5は二重承認・PAM（特権アクセス管理）・JIT（ジャストインタイム権限）・強ログを組み合わせて慎重に限定導入する。「承認の重さをリスクの大きさに揃える」という一貫した原則を持つことが、監査人への説明の軸となる。
統制アーキテクチャ——5ステップとTool Gateway
AIエージェントによる処理が内部統制として機能するためには、処理の流れ全体にわたって制御ポイントが配置されていなければならない。5ステップの統制アーキテクチャは次のように構成される。
- Intake（Request/Ticket）: 依頼・対象・目的・承認者・SOX影響を記録する。処理の「意図」をシステムに刻む起点だ。
- Decide（Policy Engine）: 権限・SoD・閾値・データ分類・環境（本番か検証か）を判定する。このステップで実行可否が自動決定される。
- Plan（Agent Orchestrator）: AIが計画・起案・実行要求を作成する。承認者への提示資料もここで生成される。前編の Plan-Then-Execute パターン がここに対応する。
- Execute（Tool Gateway）: 承認済み操作だけをAPI実行し、全tool callを記録する。この層がアクセス統制の技術的な最終砦となる。
- Record（Evidence Store）: 承認・実行・差分・検証・例外をすべて保存する。監査人が求めるEvidence Packageはここから取り出される。
AIにSalesforce売上計上、会計システム、支払マスタ、Google Workspaceの広い認証情報を直接持たせてはならない。 Tool Gatewayを経由させることで、承認された操作のみが実行可能になり、実行の全記録が自動的に蓄積される。「AIに認証を渡したら何でもできる状態」は、内部統制の設計として許容できない。
民主化の作法——登録制・審査制・昇格制
業務部門がAIエージェントを自由に作成・改善できる環境は必要だ。しかし、すべてのエージェントが本番システムに接続できるわけではない。民主化を機能させながら統制を保つ仕組みが、3層のポートフォリオ管理と登録・審査・昇格の制度設計だ。
Layer 1（Personal/Draft）は個人の下書き・要約・調査・メモ整理を担う。原則として本番接続はなく、利用ルール・DLP・機密入力制限のみで運用される。
Layer 2（Managed Workflow Agent）は問い合わせ分類・承認資料作成・差分抽出・候補提示を担う。読み取り中心で限定的な提案を行い、台帳・manifest・ログ・UATが必要になる。ここがITAC（IT業務処理統制）と近接する領域でもあり、台帳とログ整備の負荷感はITGCの延長として捉えるとよい。
Layer 3（Production/SOX Agent）は本番更新・売上・請求・支払・権限・決算関連処理を担う。Tool Gateway経由の最小権限が必須であり、変更管理・RCM・監査証跡・定期評価が求められる。
この3層を Hub & Spoke 運用で回す。Spoke（業務部門） はユースケース発案・業務要件・判断基準・承認観点・UAT・継続改善を担う。Hub（中央統制） はAI Platform/IT・Security・SOX/内部統制CoEが認証認可・Tool Gateway・ログ・証跡・変更管理・標準テンプレートを管理する。IT部門に完全集約すると現場の改善が止まる。現場に完全委譲すると統制が機能しなくなる。標準基盤の上で設定と改善を現場に開く、というバランスが民主化の作法だ。
エージェントがLayerを昇格するには、Sandbox検証・Permission Manifest審査・Security/SOXレビューを経なければならない。本番接続はゲート通過後にのみ許可される。この昇格制が「誰でも本番に繋げられる状態」を防ぐ構造的な歯止めになる。
規程化の論点——5原則と3条の規程文例
設計がどれだけ優れていても、規程に落とし込まれていなければ監査評価では「整備なし」と判断される。AIエージェントに関して職務権限規程・情報システム管理規程・IT統制規程に盛り込むべき5原則を以下に示す。
- AIは承認者になれない（自動化システムである）
- 参照権限は人間権限と業務目的に制限する（人間権限を超える情報を判断材料として提示してはならない）
- 本番接続Agentは登録制とする（Owner・用途・権限・SOX影響・ログ保存・承認条件を台帳化）
- Agent設定は変更管理対象とする（Prompt・workflow・tool・model・RAG・permission manifestの変更を管理）
- 高リスク操作はTool Gatewayで制御する（本番更新・外部送信・権限変更・財務影響処理は承認・権限・SoDを実行時検証）
規程の文言は抽象的になりがちだが、以下の3条で輪郭を作ることができる。中小企業にとっても、この3条を既存の職務権限規程に追加することで、「AIエージェントに関する統制設計がある」という監査対応の最低限の基盤が整う。
①AIエージェントの定義:
AIエージェントとは、組織が承認した業務目的、利用範囲、権限、実行条件に基づき、業務データの参照、分析、起案、または承認済み処理の実行を行う自動化システムをいう。AIエージェントは、職務権限規程上の承認者とはならない。
②承認責任:
AIエージェントによる処理が、取引、契約、売上、費用、支払、権限、マスタデータ、または財務報告に影響を及ぼす場合、所定の職務権限を有する者の承認を要する。承認者は、提示された処理内容、対象、影響範囲、例外情報および必要な証跡を確認し、当該処理の業務上の妥当性について責任を負う。
③システム責任:
AIエージェントの権限、接続先システム、実行可能な操作、ログ保存、変更管理、およびガードレールの整備・運用については、当該AIエージェントのシステムオーナーが責任を負う。システムオーナーは、Permission Manifestを定め、Tool Gateway、認証・認可、変更管理プロセスをもってこれを担保する。
①でAIの法的・制度的な位置づけを確定し、②で承認者の責任範囲を明示し、③でIT/AIオーナーの技術的義務を規定する。この3条が揃うことで、6主体の責任分界が規程の言葉として組織に定着し、ITGC・ITACの両領域に対する評価上の応答もこの規程を出発点にできる。
まとめ——効率化と統制は設計次第で両立する
AIエージェントの民主化は、設計の言葉で制御できる。責任の6主体を明確にし、権限を積集合で絞り、承認をリスクに応じた4類型で設計し、5ステップのアーキテクチャでTool Gatewayを通した実行記録を自動蓄積し、3層のAgent Portfolioを登録・審査・昇格の制度で管理する。これらが噛み合ったとき、監査証跡は業務の副産物として自動的に積み上がる。
前編でWhat（何を使うか）を示し、本稿でHow（どう設計するか）を示した。次に問われるのは規程の言葉だ。「AIエージェントは承認者にはなれない」という一文を職務権限規程に書いた瞬間、設計思想が組織の制度として定着する。その一歩を踏み出すことが、2026年以降のJ-SOX対応において経営者と監査人の双方に対して最も明快な回答となる。
参考リンク
規制・基準
- 金融庁 内部統制の評価及び監査の基準改訂（2023年）
- 経産省「財務報告に係るIT統制ガイダンス 追補版」（2024年）
- FRC「AI in Audit Guidance」（2026, UK）
- NIST AI RMF / Generative AI Profile
技術・実装
- OWASP Agentic Skills Top 10 - Excessive Permissions
- OpenAI Agents SDK Guardrails and Human-in-the-loop approvals
前編
本記事は生成AIによって作成された内容を含みます。情報の正確性や最新性について保証はできかねますので、ご利用の際はご自身でご確認ください。内容に起因する損害について、当サイトは一切の責任を負いません。
