はじめに：あなたのAIエージェントは本番で動いているか
PoCは動いた。精度も出た。しかし本番環境に上げた途端、誰も使わなくなった。あるいは現場が勝手にAIを使い始めて、管理できない「野良AIエージェント」が社内に増殖している。
こういった状況に心当たりがある技術者は少なくないはずだ。
問題はモデルの精度でも、プロンプトの書き方でも、使ったフレームワークでもない。統制の設計がされていないことが原因だ。
この記事では、AIエージェントを組織に定着させるために技術者が理解しておくべき「統制ゲート」「型と使い捨て」「リスクレベル別統制マトリクス」という設計概念を解説する。
なぜLLM単体では組織に使えないのか
LLMは確率的に次のトークンを予測する。これは「最もらしい答えを生成する」ということであり、「正しい答えを保証する」ということではない。
組織の業務には「後戻りできない確定行為」が存在する。
- 顧客への発注確定
- 外部への契約締結
- 財務データの確定処理
- 規制当局への申請・届出
これらは一度実行したら取り消せない。あるいは取り消すコストが非常に大きい。LLMが「最もらしい判断」で自律的にこれらを実行した場合、誤りが発生したときのリカバリーコストは甚大だ。
これがAIエージェントを「全部自律化」できない根本的な理由だ。技術の問題ではなく、業務の性質の問題だ。
統制ゲートとは何か
統制ゲートとは「後戻りできない確定行為の手前に設ける人間の承認・確認ポイント」だ。
情報システムの構造を整理すると、業務プロセスには必ず以下の3要素が存在する。
データの器（DB）
↓
確定点（統制ゲート）← ここを越えると事実が消えない
↓
組織活動の証跡（決算・監査ログ・契約記録）
ゲートを越えた後は、技術的な修正は可能でも「その行為があった」という事実は消えない。修正の履歴もデータとして残り続ける。
ゲートを定義するための3つの判断軸
①事実の不消去性
行為の事実が記録として残り、監査・法的証跡になるか
②ボトルネック保護
TOCの制約理論でいう「スループットを決める希少リソース」を不完全なインプットから守るか
③外部影響
顧客・取引先・規制当局など外部に影響が及ぶか
この3軸のいずれかに該当する業務は統制ゲートの候補だ。
HITL（Human-in-the-Loop）の設計原則
AIエージェントの設計でよく議論されるHITL（人間が介在するループ）は、統制ゲートの概念と直結する。
HITLを置くべき場所
AIエージェントの処理
↓
【HITL：人間の確認・承認】← 統制ゲート
↓
確定行為の実行
重要なのは、HITLを「AIの精度が低いから念のため確認する」という発想で設計しないことだ。AIの精度が上がってもゲートは消えない。ゲートは精度の問題ではなく業務の性質に基づいて定義する。
「AIが十分賢くなればHITLは不要になる」という発想は誤りだ。どれだけ精度が上がっても、後戻りできない確定行為の手前には人間の判断が必要だ。これはAIの限界ではなく、組織の説明責任の問題だ。
形式的承認のリスク
AIの導入が進むと、むしろ承認行為の重みが増す。AIが大量の処理をこなす中で、人間の承認が「スタンプを押すだけ」の形式的行為になると、ゲートが機能しなくなる。
技術者はHITLを設計するとき、「この承認者は何を確認すべきか」「確認に必要な情報が揃っているか」まで設計する必要がある。
型と使い捨ての分離
AIエージェントの設計でもう一つ重要な概念が「型」と「使い捨て」の分離だ。
型（組織管理の再利用可能テンプレート）
特徴：
- 組織として共有・管理するAgentのベースライン
- セキュリティ要件・ゲート設計が組み込み済み
- 変更には組織としての承認が必要
- バージョン管理・監査ログの対象
例：
- 顧客対応Agentの基本型
- 社内申請処理Agentの基本型
- データ収集・レポート生成Agentの基本型
使い捨てAgent（現場が自由に作って捨てるもの）
特徴：
- 型をコピーして現場が改変する
- 用が済んだら廃棄する
- ゲートの外側の処理のみ担当
- 個人・チーム単位で管理
例：
- 特定のプロジェクトの議事録要約Agent
- 一時的なデータ変換・整形Agent
- 特定キャンペーン期間限定のAgent
この分離が機能すると何が起きるか
- 現場は「型をコピーして使い捨てを作る」という最速・最安全なルートを選べる
- 組織はゲートを含む重要な部分だけを統制すればよい
- 野良AIエージェントが「型なし・ゲートなし」で作られることを構造的に防げる
実装上の判断基準として、以下のフローで分類できる。
この Agent は組織の複数メンバーが継続的に使うか？
Yes → 型として管理する
No → 使い捨てとして扱う（ただしゲートを越える処理は含めない）
この Agent はゲートを越える処理を含むか？
Yes → 型として管理し、HITL設計を必須とする
No → 使い捨てでよい
リスクレベル別統制マトリクス
AIエージェントが担う業務を以下の3レベルに分類し、それぞれの統制設計の基準を示す。
| レベル | 業務の例 | ゲート | HITL | 型管理 | 監査ログ |
|---|---|---|---|---|---|
| Lv1 | 議事録要約・個人効率化・情報収集 | 不要 | 任意 | 任意 | 任意 |
| Lv2 | 部門横断の業務支援・社内申請補助・外部送信前準備 | 推奨 | 必須 | 推奨 | 推奨 |
| Lv3 | 財務データ処理・契約関連・顧客への確定送信・規制対応 | 必須 | 必須 | 必須 | 必須 |
レベル判定の基準
以下のいずれかに該当する場合、レベルを1つ上げる。
□ 外部（顧客・取引先・規制当局）に影響が及ぶ
□ 財務・法務・個人情報に関わる
□ 一度実行したら取り消しコストが大きい
□ 監査・説明責任の対象になる
□ 複数部門・複数システムをまたぐ
Shadow AIをどう扱うか
現場が組織の管理外でAIツールを使い始める「Shadow AI」は、型と使い捨ての分離ができていない組織で必然的に発生する。
Shadow AIが危険な理由は、使っているAIサービスの利用規約によっては、入力した業務データが学習に使われる可能性があることだ。また、ゲートを越える処理をShadow AIで行っている場合、監査ログが残らない。
技術者として対策できることは3つだ。
①型を整備して「安全に使える選択肢」を提供する
Shadow AIが生まれる原因の多くは「公式の手段が遅い・使いにくい」ことだ。型として整備された使いやすいAgentがあれば、現場はそちらを選ぶ。
②利用申請・利用ログの仕組みを作る
完全に禁止するのではなく、Lv1相当の業務については申請ベースで許可し、利用ログを取る体制を作る。
③定期的な棚卸しを制度化する
現場がどんなAIツール・Agentを使っているかを定期的に棚卸しする仕組みを組織として持つ。
技術者がRFP・要件定義で発注側に伝えるべきこと
ベンダーとして、あるいは社内の技術リードとして要件定義に関わる場合、発注側に以下を明示するよう求める必要がある。
発注側が定義すべきこと（技術者が代わりに決められないこと）
- どの業務がLv1・Lv2・Lv3に該当するか
- どこが統制ゲートか
- HITLの承認者は誰か・何を確認するか
- 型として管理するAgentの範囲はどこか
「全部お任せします」という発注は、これらの判断を外注していることと同義だ。ゲートの定義は業務の性質に基づくものであり、技術者が業務を知らずに定義することはできない。
逆に言えば、これらを発注側が定義できない状態でプロジェクトを開始すると、技術者がゲートを決めることになる。その結果、統制の責任の所在が曖昧になる。
まとめ
AIエージェントを組織に定着させるために技術者が設計すべき3つの概念を整理した。
| 概念 | 内容 | 技術的な実装との接続 |
|---|---|---|
| 統制ゲート | 後戻りできない確定行為の手前のHITL | ワークフロー設計・承認フロー |
| 型と使い捨て | 組織管理のテンプレートと現場の自由な改変 | バージョン管理・テンプレート基盤 |
| リスクレベル | Lv1〜3の業務分類と統制設計の基準 | 監査ログ・アクセス制御・HITL要否 |
これらは特定のフレームワーク・ライブラリ・クラウドサービスに依存しない設計原則だ。LangChain・AutoGen・Semantic Kernelなどツールが変わっても、この原則は変わらない。
本記事で解説した概念を体系的に学びたい方は、拙著『AIの核心 AI時代の自動化技術とAIエージェント 理論編』をご覧いただきたい。付録テンプレート（統制ゲート判定チェックリスト・リスクレベル別統制マトリクス・型の判断基準など）は特設ページより無償配布している。
👉 https://jf-sol.com/aiagent_theory/
風呂井 仁｜株式会社JFソリューションズ 代表取締役
ITストラテジスト・システム監査技術者・E資格（JDLA）
『AIの核心』シリーズ著者