この記事で扱うこと
- AIエージェントが複数部門で同時に動き始めたときに起きる「統治の欠落」を、アーキテクチャではなく運用モデルの視点で整理する
- 権限境界、所有権、エスカレーションパス、動作モード、評価指標、人間の役割再設計という6つの設計要素を、システム設計・API・監査・運用に落とし込む
- 経営論に終始せず、実際にエンタープライズでエージェントをスケールさせるためのガバナンス構造と警告サインを提示する
なぜ「アーキテクチャだけ」では不十分なのか
あなたの組織で、以下のようなエージェントが動いていませんか？
- 経理チーム：請求書の自動照合エージェント
- カスタマーサポート：住所変更処理エージェント
- IT運用：インシデントトリアージエージェント
それぞれ単体では生産性が上がっているように見える。しかし、ある日「エージェントが重要請求書を誤分類した。誰の責任か？」という問いが飛び出す。
この問いに、技術アーキテクチャは答えを持たない。アーキテクチャは「エージェントがどうツールを呼び出すか」「どう推論するか」を定義するが、「誰がそのエージェントを所有するか」「どの程度の自律性を認めるか」「失敗したときのエスカレーション先は誰か」は定義しない。
そこで必要になるのが、Agentic Operating Model（エージェント運用モデル） だ。ソフトウェアが「支援」から「実行」にシフトしたとき、企業全体としてどう統治するかを設計する枠組みである。
旧来の運用モデルに現れた3つのヒビ
1. サイロ化した自動化
各部門が独立してエージェントツールを導入する。経理は経理用、カスタマーサポートはカスタマーサポート用。それぞれ単体では機能するが、横断的な所有権モデルがない。結果として「野生の自動化」が社内に乱立する。
2. 責任の曖昧さ
エージェントが誤った処理をしたとき、誰が責任を取るのか？
- データサイエンスチーム？
- 業務プロセスオーナー？
- プラットフォームベンダー？
これらが定義されていないと、インシデント発生のたびに部門間の責任論争が起きる。
3. スケールで顕在化するリスク
小規模PoCではプロジェクトチームが密に監視しているため問題が見えにくい。しかし、複数部門・複数国に展開した瞬間に、承認閾値の不統一、リスク許容度のばらつき、評価指標の非互換が表面化する。
AIエージェントは技術プロジェクトではない。新しい実行レイヤーであり、新しい運用規律を要求する。
6つの設計要素：システム設計・API・権限・監査に落とし込む
1. 権限境界（Authority Boundaries）
エージェントが「読む」「推奨する」「下書きする」「実行する」のうち、どこまで許可するかを明示する。
# 権限境界の定義例（YAML）
agent:
name: invoice_reconciliation
permissions:
read: [invoice_db, vendor_master]
recommend: [payment_approval]
draft: [adjustment_journal]
execute: []
escalation:
confidence_threshold: 0.85
amount_threshold: 1000000 # 100万円以上は人間承認
設計観点：
- APIゲートウェイレベルで権限を強制する（エージェントが直接DBを更新できないようにする）
- 各権限は最小特権の原則に従う
- 権限の変更は変更管理プロセスを経由する
2. 3つの所有権（Three Ownership Roles）
| 役割 | 担当 | 責務 |
|---|---|---|
| ビジネスオーナー | 業務部門長 | アウトカムの達成責任 |
| テクニカルオーナー | エンジニアリングリード | エージェントの品質・可用性 |
| リスクオーナー | コントロール/監査担当 | ガードレールと監査証跡 |
実務ポイント：
- 1つのエージェントに3人を指名し、エスカレーションマトリクスに記載する
- 週次の運用レビューに3者全員が参加する
3. エスカレーションパス（Escalation Paths）
「人間がループに入る」だけでは不十分。どの人間が、どのチャネルで、どの時間帯に対応するかを定義する。
escalation:
level1:
role: "operations_lead"
channel: "slack_ops_channel"
sla: "15min during business hours"
level2:
role: "business_owner"
channel: "pagerduty"
sla: "1h 24/7"
level3:
role: "risk_owner"
channel: "incident_management_tool"
sla: "4h"
API設計との接続：
- エージェントのツール呼び出しにエスカレーションフックを組み込む
- エスカレーション発生時は監査ログに自動記録する
4. 動作モード（Operating Mode）
ワークフローごとに3つのモードを選択する：
| モード | 説明 | 適したユースケース |
|---|---|---|
| 推奨のみ | エージェントは提案を出す。人間が承認して初めて実行 | 高リスクな財務処理 |
| 人間インザループ | エージェントが実行。ただし特定条件で人間にエスカレーション | カスタマーサポートの住所変更 |
| 限定自律 | エージェントが完全実行。ただし事後監査あり | 低リスクなITトリアージ |
実装上の注意：
- モードは動的に変更可能にする（API経由で設定変更）
- モード変更は監査ログに記録する
5. アウトカム測定（Outcome Measurement）
「エージェントがどれだけ動いたか」ではなく「ビジネス成果にどう貢献したか」を測る。
| 指標 | 測定方法 |
|---|---|
| 処理精度 | 人間レビューとの一致率（サンプリング監査） |
| エスカレーション率 | 全トランザクション中の人間エスカレーション割合 |
| エンドツーエンド処理時間 | エージェント起動から完了までの時間 |
| エラーコスト | 誤処理による金銭的影響額 |
API連携のポイント：
- エージェントの全アクションをイベントとして監査ログに流す
- 監査ログをデータレイクに集約し、定期的に分析する
6. 人間の役割再設計
エージェント導入後、人間は「タスク実行」から「監視・例外処理・ポリシー改善」にシフトする。
- 週次の運用レビューでエージェントのパフォーマンスを評価
- 月次でポリシー（承認閾値、エスカレーション条件）を更新
- 四半期でエージェントポートフォリオ全体のリスク評価を実施
ガバナンス構造：誰が何を決めるか
エージェントが本番で動き始めたら、以下のガバナンス体制を構築する：
クロスファンクショナルフォーラム
- メンバー：事業、技術、リスク、セキュリティ、法務、人事
- 議題：ユースケース優先順位、自律性レベル、最低限のコントロール基準、パフォーマンス指標、インシデント、人員影響
トランスフォーメーションオフィス（AIオフィス）
- エージェントユースケースを「パイロットの集合」ではなく「運用プロダクトポートフォリオ」として管理
- ロードマップ、長期所有権、目標アウトカム、撤退判断基準を策定
経営層の関与
- COO：プロセス設計と運用経済性の変更が主
- CHRO：ジョブ設計、スキル、パフォーマンス管理への影響
- CFO/リスク責任者：コントロール、監査可能性、説明責任
Agentic Operating Modelは技術アジェンダではない。経営アジェンダである。
警告サイン：あなたの組織はスケール準備ができているか？
以下の症状が複数当てはまる場合、新規ユースケース追加より先に運用規律の強化を優先すべき：
- 各部門がバラバラにエージェントを構築し、所有権基準がない
- 本番稼働中のエージェントの公式レジストリが存在しない
- ビジネスオーナーが不明確
- 承認閾値がリスクベースでなくバラバラ
- 運用チームがエージェントの動作を把握していない
- 成功指標が「ツール導入率」だけ
- 人事部門が役割変更を把握していない
- エージェント起因のインシデントが正式なガバナンス機構に入っていない
まとめ：アーキテクチャと運用モデルの両輪
Agentic Operating Modelの本質は、AIをもっと活発に動かすことではない。ソフトウェアが人間と共に働き始めたとき、誰が決断し、誰が責任を持ち、リスクをどうコントロールし、人間とエージェントがどう協働してアウトカムを生み出すかを明確にすることだ。
印象的なデモと、実際にスケールする変革を分けるのは、この運用モデルの有無である。
参考