AIツールの導入が進むにつれ、「特定ベンダーの仕様にガバナンスが縛られている」状態が課題になる。Copilotで作った統制ルールがClaudeでは使えない、ツールごとに別の管理体制が生まれてポリシーが矛盾する、こうした事態を避けるには、ベンダー非依存の骨格を先に設計する必要がある。本記事では、統制思想とツール固有の実装を分離し、前提が変わっても組み替えで対応できるAIガバナンスの構造を示す。

ベンダー非依存のAIガバナンスとは 統制思想と実装の分離

ベンダー非依存のAIガバナンスとは、統制の思想をツールの仕様から切り離し、共通の骨格として定義する設計を指す。統制思想とは「誰が何を承認するか」「どの段階で何を検証するか」「どこで出口を締めるか」といった判断の枠組みであり、これはツールが変わっても変わらない。一方、実装はツール固有の機能に依存する。環境分離、コネクタDLP、セキュリティグループ、権限ラベルなどの技術的な装置は、ツールごとに異なる仕組みで実現される。

多くの組織では、最初に導入したツールの機能に合わせてルールを作るため、統制思想と実装が混在する。その結果、ツールを追加するたびに別の管理体制が生まれ、統制の一貫性が失われる。ベンダー非依存の設計では、統制思想を先に固め、その実現手段としてツールの機能を選ぶ順序を踏む。

統制思想の骨格 共通レイヤーで定義する3要素

ベンダー非依存の骨格として、以下の3要素をツールより上位のレイヤーで定義する。

入口と出口の統制モデル

AIツールの統制には「入口で止める」と「出口で締める」の2つの考え方がある。入口統制は利用開始前に審査と承認を要求する方式であり、厳格だが利用拡大の速度が遅い。出口統制は利用開始を許可し、データ接続や外部公開の段階で制限をかける方式であり、利用拡大と統制を両立できる。

どちらを選ぶかは組織の方針だが、統制思想として先に決めておけば、ツールごとに方針が揺れることを防げる。例えば出口統制を採用する場合、Copilotではコネクタポリシーで外部接続を制限し、Claudeでは共有範囲の設定で出口を絞る。装置は異なるが、思想は一貫している。

段階検証の設計

AIツールの利用は、個人の検証、部署内の展開、全社公開という段階を経る。この段階ごとに「誰が承認するか」「どの基準で次に進めるか」を定義することが、統制思想の2つ目の要素となる。

段階検証の設計は、ツールの機能ではなく組織の意思決定構造に基づく。全社公開の承認者を情報システム部門とするか、事業部門の責任者とするか、あるいは専任のガバナンス委員会を置くかは、ツールの仕様とは無関係に決まる。統制思想として段階と承認者を定義しておけば、ツールが変わっても承認フローの主体は変わらない。

監査ログの範囲と保持期間

何を記録し、どこまで遡れるようにするかも、統制思想として定義する。操作ログ、共有履歴、データアクセス履歴のうち、どれを必須とするかは組織のリスク許容度で決まる。

ツールによって取得できるログの粒度は異なるが、「取得できるから全部記録する」ではなく、「何を記録すべきか」を先に決めることで、ツール選定時の評価基準が明確になる。また、監査権限の付与が社内承認されるかどうかも、技術的な実現可能性とは別に確認する必要がある。Copilot Studio環境の監査ログ取得にPurviewの監査ロールを使う設計を組んだが、メール等まで閲覧範囲が及ぶことを理由に社内承認が得られず、代替手段を探す事例があった。監査設計は技術的に取得できるかではなく、その権限が社内で承認されるかで決まる。

実装レイヤー ツールごとに統制装置を置く場所を決める

統制思想を固めた後、各ツールの機能を使って実装する。このとき重要なのは、統制装置をどこに置くかである。ツールごとに置き場所の選択肢が異なるため、思想を実現できる装置の組み合わせを選ぶ。

環境による分離

開発環境と本番環境を分け、段階検証を環境の移動で強制する方式である。Copilot Studioでは環境という概念があり、環境ごとにコネクタDLPやクレジット割当を設定できる。開発環境では外部接続を許可し、本番環境では承認済みのコネクタのみ許可するという統制が成立する。

ただし、全社へのライセンス配布が進むと、環境分離による統制が主経路を外れる場合がある。Copilotの有償ライセンスが対象組織のほぼ全員に配布された結果、全社展開の主経路は「Copilot Studioへ昇格」ではなく「Agent Builderのままギャラリーへ掲載」へ転換した事例がある。Agent Builderは環境の概念を持たず、コネクタDLPの対象外である。そのため、Copilot Studio環境側に置いた統制装置の上を、全社展開の主経路が通らなくなった。具体的には、開発から本番への段階検証、コネクタDLPによる出口統制、環境別クレジット割当と上限到達時の自動停止、公開承認フロー、この4つが主経路に対して効かなくなった。

人とデータによる統制

環境分離が使えない場合、統制装置の置き場所を「人（セキュリティグループ）とデータ（権限・ラベル）」へ移す。セキュリティグループで利用者を区分し、データに権限ラベルを付けて接続可能な範囲を制限する方式である。

例えばClaudeでは、Projectsの共有範囲を「組織全体」「特定のグループ」「自分のみ」から選べる。全社公開を許可する基準を定め、承認を経たProjectsのみ組織全体への共有を認める設計が可能である。環境という概念はないが、人とデータの組み合わせで段階検証を実現できる。

統制の思想（入口は止めず出口で締めるガードレール型）は変えず、装置の置き場所を「環境」から「人とデータ」へ再配置する方針で組み替えた事例がある。統制設計はライセンスの配布範囲という前提に依存している。前提が変われば、統制の思想ではなく装置の置き場所を組み替える。

複数ツール併用時の統制構造 共通レイヤーで方針を統一する

CopilotとClaudeを併用する場合、それぞれのツールで実装は異なるが、統制思想は共通にする。入口統制か出口統制か、段階検証の承認者は誰か、監査ログの保持期間は何日か、これらの方針をツールより上位で定義し、実装はツールごとに選ぶ。

複数ツール併用時に発生しやすい問題は、ツールごとに別の管理者が統制ルールを作り、方針が矛盾することである。これを防ぐには、統制思想を定義する主体を組織内で一本化する必要がある。情報システム部門、セキュリティ委員会、DX推進室など、呼称は問わないが、ツールを横断して統制思想を決定する権限を持つ部署を明確にすることが前提となる。

前提が変わったときの組み替え 統制装置の配置を見直す

ベンダー非依存の設計が機能するのは、前提が変わったときである。ライセンス配布範囲の拡大、新しいツールの追加、規制の強化など、前提が変われば統制装置の置き場所を組み替える。

検証・決定・手順書の順序を守る

組み替えの手順は、検証、決定、手順書の順に進める。まず新しい前提で統制装置が機能するかを検証し、その結果を材料として決定を行い、決定内容を手順書に落とす。この順序を崩すと手戻りが発生する。検証、決定、手順書の順序を崩すと手戻りが発生する。決定を急がせる前に、検証結果を材料として先に出す。

一律削除基準の撤回

90日間未使用のAIエージェントを一律で削除する基準を設けたが、半年に1回など低頻度で稼働するエージェントが存在するため、未使用期間による一律削除は成立しなかった事例がある。統制基準は、技術的な実現可能性だけでなく、実際の運用パターンと照らし合わせて検証する必要がある。

残存リスクの記録 代替手段がない場合の対応

統制思想を実装する過程で、技術的または組織的な制約により実現できない部分が残る場合がある。この場合、残存リスクとして明示的に記録することが、ベンダー非依存のガバナンス設計において重要となる。

監査目的の大半はエージェント管理基盤へ載せ替えたが、「誰が誰に共有したか」の操作記録だけは代替手段がなく、残存リスクとして記録した事例がある。残存リスクを記録する意義は、リスクの存在を可視化し、将来的に代替手段が出現したときに速やかに対応できる状態を作ることである。

政府ガイドラインとの関係 国内制度を基準にする

AI事業者ガイドライン（第1.2版）（総務省・経済産業省（2026年3月31日公表））では、AI利活用における透明性、公平性、アカウンタビリティの確保が指針として示されている。これらの原則は、ツールの仕様ではなく組織の統制思想として定義すべき要素である。

国内制度を基準にすることで、複数ツールを併用する場合でも、統制の方向性が揺れることを防げる。ツールごとに海外の規格や基準を参照すると、方針が分散するリスクがある。ベンダー非依存のガバナンスは、国内の実務と制度を軸にして設計する。