はじめに：あなたの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の核心』シリーズ著者