複数の生成AIを併用する企業にとって、ベンダーごとにガイドラインを分けると管理コストが跳ね上がり、従業員は読まなくなる。一つのガイドラインで複数ベンダーを縛るには、ベンダー固有の差異を条文の外に追い出し、共通の禁止事項と判断基準だけを本文に残す設計が必要になる。この記事では、AI利用ガイドラインを複数ベンダーに適用できる形で書く方法を、条文構造と運用の境界線から整理する。

AI利用ガイドラインを複数ベンダー対応にする理由

企業がCopilot・Gemini・ChatGPT・Claudeを併用している場合、ベンダーごとにガイドラインを分けると次の問題が起きる。第一に、従業員は複数の文書を読み分けられない。「このツールはどのガイドラインに従うのか」という判断を毎回求めると、ガイドライン自体が読まれなくなる。第二に、改定の工数が倍増する。法令や社内制度が変わるたびに、ベンダーの数だけ文書を修正し、承認を取り直すことになる。第三に、ベンダーごとに禁止事項が微妙にずれると、従業員は緩い方へ流れる。結果として統制が効かなくなる。

一つのガイドラインで複数ベンダーを縛るとは、ベンダー固有の技術仕様や設定手順を条文から切り離し、共通の禁止事項と判断基準だけを本文に残すことを意味する。技術仕様は別表や設定ガイドへ分離し、ガイドライン本文は「何をしてはいけないか」「誰が判断するか」の原則だけを定める。この構造にすることで、ベンダーが増えても本文を改定せずに済み、従業員は一つの文書を読むだけで全ツールの使い方を理解できる。

ベンダー固有の差異を条文の外に追い出す設計

複数ベンダー対応のガイドラインは、本文と別表の二層構造で設計する。本文には「入力禁止データ」「公開範囲の制約」「承認プロセス」といった、全ベンダーに共通する原則を書く。ベンダーごとに異なる設定手順や管理画面の操作方法は、別表または技術補足資料へ分離する。この分離によって、新しいベンダーを追加する際も、本文の原則は変えずに別表だけを追加すればよい状態を作る。

具体的には、次の項目を本文から切り離す。第一に、データ保存場所やログ保持期間といった技術仕様。これらはベンダーごとに異なるが、ガイドライン本文で定めるべきは「ログを取得できること」という要件であり、保存先のリージョンやAPIエンドポイントは別表で管理する。第二に、管理者権限の付与手順や監査ログの取得方法。操作画面のスクリーンショットや設定パスは、別表に載せた技術ガイドへ委ねる。第三に、ベンダーが提供する約款や利用規約のURL。これらは頻繁に更新されるため、ガイドライン本文に直接埋め込むと改定の工数が増える。別表にリンク集として載せ、本文では「ベンダーの利用規約を遵守すること」と一文で済ませる。

この設計により、ガイドライン本文は5〜10ページ程度の短い文書に収まる。技術仕様や設定手順を別表へ分離することで、本文の可読性が上がり、従業員が読み通せる分量になる。別表は管理者向けの参照資料として位置づけ、一般従業員は本文だけを読めばよい状態を保つ。

共通の禁止事項を書く4つの軸

複数ベンダーに適用できる禁止事項は、次の4つの軸で整理する。第一に、入力禁止データの定義。「個人情報」「機密情報」「取引先の情報」といったデータ分類を、ベンダーに依存しない形で定義する。「Copilotでは入力可だがChatGPTでは禁止」という条件分岐を書くのではなく、「機密情報に該当するデータは、全ての生成AIへ入力してはならない」と一文で書く。データ分類の基準は社内の情報管理規程に合わせ、ガイドライン内で再定義しない。

第二に、公開範囲の制約。作成したチャットボットやエージェントを「誰に公開してよいか」を定める。全社公開・部署内公開・個人利用の三段階で分け、それぞれに必要な承認プロセスを示す。ベンダーごとに共有機能の名称は異なるが、ガイドライン本文では「公開範囲」という抽象概念で書き、別表で「Copilot Studioのギャラリー掲載」「ChatGPTのGPT公開設定」といった対応表を載せる。

第三に、外部連携の禁止または制限。プラグインやAPIを使って外部サービスへデータを送る行為を、どこまで許可するかを定める。「全面禁止」か「承認制」かを本文で決め、承認権限者と申請手順を明記する。ベンダーごとに連携可能なサービスは異なるが、ガイドライン本文では「外部連携には事前承認が必要」とだけ書き、承認対象の具体例は別表へ載せる。

第四に、出力データの取り扱い。生成AIが出力した文章やコードを、そのまま製品や顧客向け資料へ転用してよいかを定める。「事実確認なしに外部公開してはならない」「著作権侵害のリスクを確認すること」といった原則を書く。これらの原則は、どのベンダーでも共通して適用できる。

判断基準を一元化する承認フロー設計

複数ベンダーを縛るガイドラインでは、承認フローを一元化する。「Copilotの場合はA部署が承認し、ChatGPTの場合はB部署が承認する」という分岐を作ると、従業員は申請先を迷い、承認者は判断基準がずれる。承認フローは次の三段階で統一する。

第一段階は、個人利用の範囲内で使う場合。この場合は承認不要とし、ガイドラインの禁止事項を守る限り自由に使える状態にする。個人利用とは、作成したチャットボットやプロンプトを他人と共有せず、業務の下書きや情報収集にのみ使う状態を指す。

第二段階は、部署内で共有する場合。この場合は所属長の承認を必須とし、共有範囲と使用目的を申請させる。所属長は「入力禁止データが含まれていないか」「外部連携を使っていないか」をチェックし、問題なければ承認する。ベンダーごとに共有機能の実装は異なるが、承認基準は統一する。

第三段階は、全社へ公開する場合。この場合は情報システム部門またはガバナンス担当部署の承認を必須とし、セキュリティチェックと利用規約の確認を経てから公開を許可する。全社公開の承認基準を別表に載せ、チェックリスト形式で示す。このチェックリストは、どのベンダーでも同じ項目を使う。

承認フローを一元化することで、従業員は「どのツールでも申請先は同じ」という認識を持てる。承認者も、ベンダーごとに判断基準を変える必要がなくなる。

別表で吸収するベンダー固有の設定項目

ガイドライン本文から切り離した技術仕様は、別表として管理する。別表は次の4つの項目を載せる。第一に、データ保存場所とログ保持期間。Copilotではテナント内、ChatGPT Enterpriseでは履歴オプトアウト設定時の動作といった、ベンダーごとの仕様を一覧表にする。この表は、監査時に「どのベンダーがどこにデータを残すか」を確認する資料として使う。

第二に、管理者権限の種類と付与手順。Copilotの環境管理者、ChatGPTの管理コンソール権限、Claudeの組織管理者といった、ベンダーごとの権限体系を対応表にする。この表により、「全社管理者」「部署管理者」「利用者」という社内の役割と、ベンダーが提供する権限を紐づける。

第三に、外部連携機能の一覧。各ベンダーが提供するプラグイン・API・コネクタの名称と、それぞれの承認要否を載せる。例えば「Copilot StudioのカスタムコネクタはDLP設定を通過したもののみ許可」「ChatGPTのカスタムGPTは全面禁止」といった、ベンダーごとの方針を明記する。

第四に、ベンダーが提供する利用規約やプライバシーポリシーのリンク集。Microsoft 365 Copilot 導入とオンボード ガイド（IT管理者向け）やAnthropic Privacy Center（プライバシーセンター）など、公式の情報源を別表に載せる。これにより、本文では「ベンダーの利用規約を遵守すること」と一文で済ませられる。

別表は、ベンダーが増えるたびに行を追加する形で更新する。本文の改定は不要であり、別表の追加だけで新しいベンダーへ対応できる。この構造により、ガイドラインの改定頻度を下げ、承認プロセスの負担を減らせる。

実効性を保つための運用設計

複数ベンダー対応のガイドラインは、書いて終わりではなく運用で実効性を保つ。運用設計は次の3つの要素で構成する。第一に、定期的な遵守状況の確認。四半期ごとに、各部署の管理者へ「ガイドラインに違反した利用がないか」を報告させる。報告内容は「全社公開したエージェントの一覧」「外部連携の承認申請件数」「入力禁止データのインシデント件数」の3項目に絞る。全ベンダーで同じ報告フォーマットを使い、集計の手間を減らす。

第二に、ガイドライン違反時の対応手順。違反を発見した場合、どの部署が調査し、誰が是正を指示するかを定める。対応手順はベンダーに依存せず、「違反内容の特定」「影響範囲の確認」「是正措置の実施」「再発防止策の策定」という4ステップで統一する。是正措置の内容だけは、ベンダーごとに異なる。例えば、Copilotなら環境の利用停止、ChatGPTならアカウントの無効化といった形で、別表に載せた技術ガイドを参照して実施する。

第三に、ガイドラインの改定プロセス。法令や社内制度が変わった場合、本文と別表のどちらを改定すべきかを判断する基準を定める。原則として、禁止事項や承認フローの変更は本文を改定し、技術仕様の更新は別表だけを改定する。本文の改定には経営層の承認を必須とし、別表の改定は情報システム部門の判断で実施できるようにする。この役割分担により、改定の速度と統制のバランスを保つ。

ガイドライン本文に書くべきでない項目

複数ベンダー対応のガイドラインでは、次の項目を本文に書かない。第一に、ベンダー固有の機能名。「Copilot Studioのギャラリー」「ChatGPTのカスタムGPT」といった名称を本文に書くと、ベンダーが増えるたびに本文を改定する必要が生じる。本文では「全社公開機能」「カスタマイズ機能」といった抽象概念で書き、別表で機能名を対応させる。

第二に、具体的な設定手順。「管理画面の〇〇タブから××を選択し」といった操作手順は、ベンダーが画面を変更するたびにガイドラインが古くなる。設定手順は別表の技術ガイドへ分離し、本文では「管理者権限を持つ者が設定する」とだけ書く。

第三に、ベンダーの利用規約や約款の引用。これらは頻繁に更新されるため、ガイドライン本文へ引用すると改定の工数が増える。本文では「ベンダーの利用規約を遵守すること」と一文で済ませ、別表にリンク集を載せる。

第四に、将来の予定や検討中の事項。「今後〇〇を導入予定」「△△については検討中」といった記述は、ガイドラインの確定性を損なう。検討中の事項は、確定してから別表へ追加する形で対応する。

国内制度との整合を保つ参照設計

複数ベンダー対応のガイドラインでは、国内の法令やガイドラインへの参照を一元化する。AI事業者ガイドライン（第1.2版）や個人情報保護委員会（生成AIと個人情報の取扱いに関する情報）が示す考え方を、ガイドライン本文の禁止事項へ反映させる。ただし、政府ガイドラインの条文をそのまま転記するのではなく、自社の業務に即した禁止事項として書き直す。

例えば、個人情報の取り扱いについては「個人を特定できる情報は、全ての生成AIへ入力してはならない。ただし、個人情報保護法上の匿名加工情報へ変換した場合は例外とする」と書く。この原則は、どのベンダーでも共通して適用できる。匿名加工の手順や基準は、別表へ載せた個人情報管理ガイドを参照させる形にする。

また、国内制度への参照は別表に集約し、本文では「関連法令を遵守すること」と一文で済ませる方法もある。この場合、別表に「参照すべき法令・ガイドライン一覧」を載せ、それぞれの要点を数行で要約する。この設計により、法令が改正されても別表だけを更新すればよい状態を作る。

別表の更新頻度と管理責任

複数ベンダー対応のガイドラインでは、本文と別表で更新頻度が異なる。本文は年1回の定期見直しを基本とし、法令改正や重大インシデントがない限り改定しない。別表は四半期ごとに見直し、ベンダーの仕様変更や新機能の追加に対応する。この更新頻度の違いを、ガイドライン本文の冒頭に明記する。

別表の管理責任は、情報システム部門またはガバナンス担当部署へ明確に割り当てる。別表の更新には経営層の承認を不要とし、担当部署の判断で実施できるようにする。ただし、更新内容は全社へ通知し、変更履歴を残す。変更履歴には「更新日」「更新箇所」「更新理由」を記録し、監査時に更新の経緯を説明できるようにする。

別表の版管理は、ガイドライン本文とは独立して行う。本文が第2版の状態で、別表だけが第2.3版へ更新される状態を許容する。この版管理により、本文の承認プロセスを経ずに技術仕様を更新できる柔軟性を保つ。