AI エージェントの境界はどこに置くべきか――利用目的別の構成層と委任・承認・監査

第 2 本「システム境界と組織境界をどう揃えるか」では、システム境界と組織境界を同時に設計する必要があると整理しました。ドメインサービスは正式なデータと業務上の判断規則を所有し、利用目的別の構成層は複数のドメインサービスを業務目的に合わせて組み合わせます。共通プラットフォームは、認証、イベント、実行基盤、監視などの能力を提供します。

AI エージェントを業務システムへ組み込む場合も、この境界を崩してはいけません。AI エージェントは複数の情報源を横断し、分析し、提案し、場合によっては実行まで支援します。しかし、横断して利用できることと、正式な所有者になることは別です。本稿では、AI エージェントの境界をどこへ置くべきか、また委任、承認、実行、監査をどのように分けて記録すべきかを考えます。

第 3 本である本記事は、AI エージェントをどの境界に置くべきかを扱います。第 1 本「責務を固定し、統合を固定しない」で定義した利用目的別の構成層と、第 2 本で整理した組織上の所有者を前提に、AI エージェントをドメイン所有者にせず、利用目的、ツール、権限、品質、承認条件によって境界を定義します。

エージェント境界は利用目的別の構成層に置く

第 1 本では、ドメインサービスの境界を、正式なデータの所有者と業務上の判断規則によって定義しました。一方、本稿で扱う AI エージェントの境界は、基本的に利用目的別の構成層の境界に従います。障害調査エージェント、構成変更支援エージェント、顧客問い合わせ対応エージェント、経営分析エージェント、プラットフォーム運用エージェントといった分け方です。

障害調査エージェントは、顧客、契約、構成、監視、変更履歴を横断して利用しますが、それらの正式な所有者にはなりません。構成変更支援エージェントは、変更案を作成しても、装置設定の正当性や変更状態を独自に所有するわけではありません。エージェント境界は、何のデータを所有するかではなく、どの利用目的について、どのツールと権限を使い、どの品質に責任を持つかによって定義します。

このシステム境界は、第 2 本で扱った組織境界とも対応します。障害調査エージェントであれば、障害対応という利用目的に責任を持つプロダクトチームまたは業務チームが、そのエージェントの振る舞い、利用可能なツール、品質基準、承認条件を所有します。ドメインチームは、エージェントから利用される API、データ、操作、業務ルールを所有します。AI・プラットフォームチームは、モデル接続、エージェント実行、状態管理、トレースなどの共通基盤を提供します。

対象	主な所有者
エージェントの利用目的、品質、ツール構成	プロダクトチーム・業務チーム
正式なデータ、業務ルール、ドメイン操作	ドメインチーム
モデル接続、実行基盤、状態管理、トレース	AI・プラットフォームチーム
委任、認可、監査の共通機構	セキュリティー・プラットフォームチーム

プラットフォームチームが実行基盤を所有することと、エージェントの業務上の振る舞いを所有することは別です。エージェントの利用目的や判断基準までプラットフォームチームへ集めると、すべての AI 活用が中央チームを経由する構造になります。これは、第 1 本で扱った統合層の中央モノリス化を、AI エージェントによって再現することになります。

ドメイン内部の AI は存在し得る

一方、ドメインサービスの内部へ AI を組み込むことはあり得ます。たとえば契約管理サービスが、契約文書から条件を抽出する AI 機能を内部に持つことは考えられます。監視サービスが、メトリクスから異常候補を検出するモデルを持つこともあります。この場合、AI はドメインサービスの内部実装です。

外部から見た正式な契約状態やアラーム状態は、引き続きドメインサービスが所有します。「契約管理エージェント」という独立したシステムが、契約管理サービスとは別に契約の正しさを判断し始めると、正式な所有者が二つになります。したがって、ドメイン内部の AI は存在し得ますが、外部へ提供する責務境界は、AI ではなくドメインサービスに置く必要があります。

本稿で扱う AI エージェントは、主に複数ドメインを利用目的に合わせて組み合わせる構成主体を指します。ドメインサービスの内部で使われる AI と、複数ドメインを横断して業務目的を遂行する AI エージェントを混同すると、正式なデータ、判断規則、操作権限の所有者が曖昧になります。

参照、提案、実行を主体の記録と組み合わせる

AI エージェントの権限を、単純に許可または不許可だけで考えると、利用範囲が極端になります。安全を優先して参照だけに限定すれば、有用性が下がります。一方、すべての操作を自動実行させれば、誤判断の影響が大きくなります。そこで、操作を段階に分けます。

段階	AI エージェントが行うこと
参照	情報を取得して整理する
分析	原因候補や影響を推定する
提案	実行候補と理由を提示する
準備	設定差分や変更チケットを作成する
承認付き実行	人間の確認後に操作する
自動実行	定義済みの低リスク条件内で操作する
検証	操作結果を確認する

この段階は、利用者、エージェント、対象サービスという主体の識別とは別の軸です。実際の認可と監査では、処理の段階と主体の記録を組み合わせます。どこまで処理が進んだのかだけでなく、誰の依頼に基づき、誰が承認し、どのエージェントが、どのツールで、どの対象へ操作したのかを分けて記録する必要があります。

BGP セッション再確立までの例

利用者 A が、障害調査エージェント B へ、顧客回線の遅延調査を依頼したとします。このエージェントは顧客、回線、アラーム、BGP 状態を参照し、経路変更と遅延発生の時刻を比較し、BGP セッション再確立を候補として提示します。ただし、提案した時点では実行権限を持ちません。

段階	実行内容	subject	actor	権限・承認	記録すべき内容
参照	顧客、回線、アラーム、BGP 状態を取得	利用者 A	エージェント B	対象回線の参照権限	参照したサービス、対象、時刻
分析	経路変更と遅延発生の時間を比較	利用者 A	エージェント B	外部操作なし	使用した証拠、分析結果
提案	BGP セッション再確立を候補として提示	利用者 A	エージェント B	実行権限なし	提案理由、影響、代替案
準備	変更チケットと実行対象を作成	利用者 A	エージェント B	チケット作成権限	対象 neighbor、手順、検証項目、変更案の版
承認	運用責任者 D が内容を承認	運用責任者 D	運用責任者 D	D 自身が持つ承認権限	承認者、時刻、承認対象の版、承認 ID
実行	対象ルーターの BGP セッションを再確立	利用者 A	エージェント B	D の承認を条件とする一時実行権限	ツール、対象、入力、結果、参照した承認 ID
検証	経路、通信、アラームを再確認	利用者 A	エージェント B	対象回線の参照権限	復旧状態、残存異常
完了	チケットへ結果を記録	利用者 A	エージェント B	チケット更新権限	操作全体、承認情報、最終判定

承認段階は、利用者 A からエージェント B への委任チェーンの一部ではありません。運用責任者 D が、自身に付与された承認権限に基づいて行う独立した意思決定です。そのため、承認時の subject と actor は、いずれも D になります。

一方、その後の実行は、利用者 A を subject、エージェント B を actor とする委任処理として再開します。ただし、実行権限が成立する条件として、D が発行した承認が追加されます。両者は subject の連続性によって結び付けるのではなく、タスク ID、変更チケット ID、AI が作成した変更案の版、承認 ID、承認対象のハッシュ、実行時に参照した承認 ID によって一つの実行系列として関連付けます。

これにより、承認後にエージェントが対象装置、neighbor、操作内容などを変更した場合、それまでの承認を流用できないようにできます。承認された変更案と実際の操作が一致しなければ、実行を拒否し、再承認を要求する必要があります。

subject、actor、承認を分けて記録する

三者区分は「誰の権限を、誰が行使したか」を示します。実行段階は「処理がどこまで進んだか」を示します。承認は、それらとは別に、独立した権限を持つ主体が特定の変更案へ与える実行条件です。この三つを分けて記録することで、誰の依頼に基づき、誰が承認し、どのエージェントが何を実行したのかを正確に追跡できます。

AI エージェントの監査では、単に「エージェントが実行した」と記録しても不十分です。利用者の依頼、エージェントの分析、エージェントが作成した変更案、人間の承認、実行時の入力、実行結果、検証結果を、それぞれ別の事実として記録する必要があります。そうしなければ、誤った操作が起きたときに、利用者の依頼が誤っていたのか、エージェントの分析が誤っていたのか、承認対象と実行内容がずれていたのか、ツール実行に問題があったのかを切り分けられません。

AI エージェントをドメイン所有者にしない

AI エージェントは、複数のドメインサービスを横断して状況を整理し、利用目的に沿った操作候補を作れます。その能力があるからといって、正式なデータや業務ルールの所有者にしてはいけません。顧客、契約、構成、監視、変更履歴、チケットの正式な状態は、それぞれのドメインサービスが所有します。エージェントは、それらを利用目的に合わせて構成し、分析し、提案し、承認済みの範囲で実行します。

エージェント境界を利用目的別の構成層に置くことは、エージェントの能力を低く見積もることではありません。むしろ、どの目的について、どのツールを使い、どの品質に責任を持ち、どの承認条件で実行できるのかを明確にするための設計です。AI エージェントを中央の万能主体にすると、ドメイン境界も組織境界も曖昧になります。AI エージェントは、責務境界を溶かすためではなく、既に定義された責務と契約を利用目的に合わせて扱うために配置すべきです。

参考情報

• 責務を固定し、統合を固定しない – マイクロサービスを再構成可能性から捉える
• システム境界と組織境界をどう揃えるか – Conway の法則と逆 Conway マヌーバー

関連する記事