一つのAIエージェントを全社で共用できますか？
共通基盤を共用できる場合でも、参照資料、回答範囲、操作権限、承認者、引継ぎ先は部署ごとに分ける必要があります。部署間で情報や権限が混ざらない構成と、業務主管者による確認を行います。
USE CASES / ARTICLE 36
AIエージェントを複数部署へ展開する前の標準化｜共通化と個別設計
全社でそろえる統制と、部署ごとに変える業務設計を分け、横展開を安全に進める方法を解説します。
この記事の目次
SHORT ANSWER
まず、結論から。
結論全社共通にするのは、利用目的、禁止事項、本人確認、ログ、評価、事故対応などの統制です。部署別に設計するのは、承認済み資料、用語、回答範囲、操作権限、例外条件、担当者への引継ぎです。この二層を分け、変更責任者と検証条件を決めてから展開します。
複数部署への展開では、利用規程や記録方式は共通化できても、参照資料、回答範囲、承認者、引継ぎ先は部署ごとに異なります。共通基盤と個別設定を二層に分け、部署単位で小さく検証してから広げます。
主な対象
全社のAI・DX推進責任者各部門の業務主管者と情報システム担当者内部統制・法務・情報セキュリティの担当者
KEY POINTS
この記事の、4つの要点。
- 利用目的、禁止事項、記録、評価、事故対応は全社共通の基盤として管理する
- 参照資料、用語、回答範囲、操作権限、承認者、引継ぎ先は部署別に設計する
- 共通設定と部署別設定の変更責任者、承認手順、反映記録を分ける
- 一斉展開ではなく、部署単位の代表業務で試験し、合格条件を満たしてから広げる
TWO-LAYER DESIGN
全社共通と部署別を、二つの層に分ける。
営業部門で使えたAIエージェントを、そのまま総務や人事へコピーしても、同じようには働きません。扱う資料、質問の言葉、許可される操作、回答後の手続きが異なるからです。一方で、部署ごとにすべてを作り直すと、禁止事項や記録方法がばらばらになり、全社としての説明や改善が難しくなります。
そこで、設計を二つの層に分けます。全社共通の層には、利用目的、扱ってよい情報、本人確認、ログ、評価、停止条件、事故時の連絡などを置きます。部署別の層には、承認済み資料、専門用語、回答できる範囲、操作権限、承認者、担当者への引継ぎを置きます。
NISTのAI RMF Playbookは、組織の役割、責任、方針、リスク許容度を明確にし、Map、Measure、Manageの実務へつなげる考え方を示しています。共通の統制と個別業務の文脈を分けることで、全社方針を守りながら、現場に必要な違いを残せます。
- 全社共通
- 目的、禁止事項、情報区分、記録、評価、停止、事故対応
- 部署別
- 資料、用語、対象者、回答範囲、権限、承認、引継ぎ先
- 共通の型
- 設定項目、試験方法、変更記録、廃止手順
COMMON BASELINE
先にそろえるのは、利用の土台と記録です。
全社共通の基盤は、抽象的な理念だけでなく、運用時に確認できる項目へ落とします。誰が利用できるか、どの情報を入力してよいか、生成結果をどこへ転記できるか、どの操作に人の承認が必要かを決めます。権限外の依頼、根拠が確認できない回答、重大な影響がある判断では、回答や実行を止める条件も共通化します。
記録もそろえます。利用者、対象業務、参照した資料、実行した操作、承認者、訂正内容を、必要性と保存期間に応じて残します。部署ごとに項目名や保存場所が違っても、全社で確認すべき最小項目は共通にすると、問題発生時の追跡と横断的な改善がしやすくなります。
デジタル庁の生成AI調達・利活用ガイドライン第2.0版は、技術、利用場面、政策の変化を踏まえて継続的に見直す必要を示しています。最初に決めた基盤を固定せず、規程、契約、利用範囲、サービス仕様の変更に合わせて改訂日と責任者を記録します。
- 利用者と対象業務を登録し、目的外利用を区別する
- 入力できる情報区分と、外部送信・保存の条件を定める
- 回答保留、操作停止、人の承認が必要な条件を共通化する
- ログの最小項目、保存期間、閲覧者、削除手順を決める
- 変更日、承認者、対象部署、影響範囲を記録する
DEPARTMENT PROFILE
部署ごとに、仕事の境界を記述する。
部署別の設定では、AIに何を知識として渡すかだけでなく、どこまで答え、どこから人へ渡すかを記述します。たとえば営業支援なら商品資料と提案手順を参照できても、値引きや契約条件の確約は承認対象です。人事案内なら就業規則を説明できても、個別の処遇判断は担当者へ引き継ぎます。
各部署に一枚の業務プロファイルを用意すると整理しやすくなります。利用者、対象業務、承認済み資料、禁止情報、許可された操作、回答を止める条件、承認者、引継ぎ先、緊急時の連絡先、評価担当者を記載します。資料名だけでなく、版、更新日、所有者も残します。
Luminaの設計ガイドでも、業務、回答スタイル、参照資料、ルール、人の確認を利用目的に合わせる考え方を示しています。横展開では、この個別設計を省略せず、共通テンプレートへ部署の実情を記入し、業務主管者が確認します。
- 誰が、どの業務で、何のために利用するか
- 承認済み資料の名称、版、所有者、更新頻度
- 案内、下書き、実行のうち許可する範囲
- 承認が必要な操作と、例外時の停止条件
- 通常、緊急、苦情、事故それぞれの引継ぎ先
CHANGE OWNERSHIP
変更する人と、承認する人を分ける。
横展開後に起きやすいのは、ある部署の改善が共通設定を変え、別部署へ意図せず影響することです。共通基盤と部署別設定の所有者を分け、変更申請、影響確認、試験、承認、反映、周知の順序を決めます。緊急停止は通常の変更より短い経路にしつつ、誰が何を止めたかを後から確認できるようにします。
共通設定の変更では、すべての部署への影響を確認します。部署別設定の変更では、その部署の資料所有者と業務主管者が確認し、他部署の知識や権限を混ぜないようにします。AIサービスやモデルの更新も、回答の癖、参照方法、外部連携へ影響する可能性があるため、設定変更と同様に試験対象にします。
役割を決める際は、運用担当者だけへ責任を集めません。業務の正しさを確認する人、技術と権限を管理する人、情報管理を確認する人、最終的に利用継続を承認する人を区別します。判断が止まったときの代替者も先に決めます。
- 共通基盤の所有者
- 方針、記録、評価、事故対応を管理する
- 部署設定の所有者
- 資料、回答範囲、承認経路を管理する
- 技術管理者
- 接続、権限、モデル更新、停止を管理する
- 承認者
- 試験結果と残るリスクを確認し、利用開始を判断する
PILOT & SCALE
部署単位で試し、合格してから広げる。
展開は、全社員への一斉公開から始めません。各部署で答えを照合しやすく、誤りの影響を限定できる代表業務を選びます。通常の質問だけでなく、古い資料、曖昧な依頼、権限外の操作、部署をまたぐ相談、担当者不在の場面を含めて試します。
合格条件は事前に決めます。根拠を正しく示せた割合、止めるべき質問を止めた割合、正しい承認者へ渡せた割合、不要な保留、担当者の訂正時間、利用者が迷った箇所を確認します。全社共通の指標に加え、部署ごとの重要な失敗を一つ以上定めます。
問題が見つかったら、AIへの指示だけを変えるのではなく、共通基盤、部署資料、権限、承認経路、引継ぎ先のどこが原因かを分けて直します。修正後に同じ試験を通し、合格した設定を版として保存してから、次の部署へ進みます。
- 代表業務を一つ選び、対象者と利用範囲を限定する
- 通常、曖昧、古い情報、権限外、部署横断の試験を行う
- 正答だけでなく、保留、承認、引継ぎの成功を測る
- 合格した設定を版として保存し、次の部署へ再利用する
- 利用開始後も訂正、保留、事故、要望を定期的に見直す
FREQUENTLY ASKED QUESTIONS
この記事のよくある質問。
最初に共通化すべき項目は何ですか？
利用目的、禁止事項、情報区分、本人確認、ログの最小項目、回答・操作の停止条件、事故時の連絡、評価方法が候補です。個別業務の回答内容まで一律にせず、部署別設定と分けます。
部署ごとの設定は、誰が承認しますか？
業務内容と資料は業務主管者、接続と権限は技術管理者、情報管理は該当する統制担当者が確認し、利用開始の最終責任者を定めます。一人にすべての確認を集めないようにします。
既存部署の設定をコピーすれば早く展開できますか？
設定項目と試験方法は再利用できますが、資料、用語、権限、承認、引継ぎ先はコピー後に必ず見直します。他部署の情報が残っていないことも確認します。
部署をまたぐ質問は、どのように扱いますか？
一つのAIが推測して統合せず、担当範囲を示したうえで適切な部署へ引き継ぎます。複数部署の判断が必要なら、誰が最終回答をまとめるかを事前に決めます。
PRIMARY SOURCES
判断の基準にした、公式情報。
制度・製品・提供条件は変更されるため、リンク先の最新表示も併せて確認してください。
CONTACT LUMINA