③Azure OpenAI を用いた社内 Copilot 導入事例
- 山崎行政書士事務所
- 2025年12月8日
- 読了時間: 9分
1. 企業・プロジェクトの前提
1-1. 想定する企業像
業種：日系グローバル製造業（B2B・技術文書多め）
従業員：2〜3万人規模（うち EU 在籍 3〜4千人）
クラウド基盤：
Azure / M365 は既に全社標準
Entra ID による ID 統合済み
課題：
英文メール・技術資料・仕様書が多く、ナレッジ検索と文書作成負荷が高い
EU の GDPR / AI Act、NIS2 も意識せざるを得ない立場
1-2. プロジェクトの目的
「社内ナレッジ＋生成 AI」で従業員の生産性を 20〜30% 向上
メールドラフト、議事録要約、Q&A、規程検索など
ただし、
機密情報漏えい
GDPR・AI Act 違反を避けるため、「なんでも ChatGPT に投げる」状態は止める
その解として、**Azure OpenAI を用いた「社内限定 Copilot」**を構築する。
2. 技術・法務の前提確認
2-1. Azure OpenAI のデータ保護前提
まず、CISO・法務・DPO が確認したポイント：
Azure OpenAI / Foundry Models（Azure Direct Models）は、プロンプトや出力などの顧客データをモデル提供者の学習に利用しない
顧客データは他テナントと分離されており、他社に共有されない。
Azure は各ジオ・リージョンごとにデータレジデンシを定めており、EU 内データ residency を選択可能。
さらに 2025 年時点では、Sweden Central / Germany West Central などの Data Zone SKU を使うことで、「処理も含めた EU 限定レジデンシ」を契約上保証できる。
→ 結論：「Azure OpenAI（Data Zone）」を使えば、EU データを EU 内に閉じた Copilot が設計できるという前提が固まる。
2-2. EU AI Act の観点整理
EU AI Act は 2024/8/1 に発効し、
禁止 AI と AI リテラシー義務：2025/2/2 から適用
GPAI（汎用 AI モデル）への義務とガバナンス：2025/8/2 から段階的に適用
高リスク AI：多くの分野で 2026/8/2〜2027/8/2 にかけて適用
リスク分類としては、
禁止（Unacceptable）
高リスク（High）
限定／最小リスク（Limited / Minimal）などの層で規制が変わる。
この社内 Copilot は、
「従業員の作業支援ツール」であり
人事評価の自動決定やクレジットスコアなどは行わない
ため、原則として “限定リスク〜最小リスク” 領域（＝主に透明性・説明義務）と位置付ける方針で進める。
3. ユースケース選定と“やらないこと”の定義
3-1. フェーズ1で採用したユースケース
PoC〜フェーズ1では、あえて“守り寄り”に絞り込む。
文書生成・翻訳系
日本語⇔英語のメール草稿作成
仕様書・提案書の下書き
会議録の要約（M365 の会議録＋手書きメモをテキスト化したもの）
社内規程・手順書 Q&A
労務規程・情報セキュリティポリシー・IT 手順書などのPDF / Word を RAG で読み込み、「社内ルールに沿った回答」を生成
開発・設計支援（ノンコア部分）
コードのリファクタリング提案
単体テストのサンプル生成
ただし「製品の安全性に直結する制御ロジック」には使わせない
3-2. フェーズ1で明確に NG とした領域
採用選考・人事評価への直接利用
医療的判断や安全クリティカルな設計決定
顧客への“自動回答”の完全自動化（必ず人間レビューを挟む）
個人の健康情報・機微情報・労働組合活動などをプロンプトに含めること（原則禁止）
→ これにより、AI Act の高リスク・禁止領域に踏み込まないことを明確化し、DPIA のリスク評価も抑えめのゾーンからスタート。
4. アーキテクチャ設計（ざっくり図解イメージ）
4-1. 全体構成（論理）
フロントエンド
Teams のボット
社内ポータルの Web チャット UI
バックエンド（社内 Copilot コア）
Azure Functions / App Service 上の API
Azure API Management で入口統一
LLM 層
Azure OpenAI / Azure Direct Models
デプロイ：Data Zone SKU（Sweden Central or Germany West Central）
モデル：GPT-4.x クラス + embedding
社内ナレッジ検索（RAG）
データソース：
SharePoint Online
内部 wiki
一部ファイルサーバを Azure Files / Blob に移行したもの
インデックス：
Azure AI Search または Elastic on Azure
ベクトルインデックスに embedding を格納し、RAG 構成
ログ・監査
プロンプト・レスポンスのメタデータ（誰が・いつ・どのユースケース）をEU 内の Log Analytics / Event Hub へ送信し、利用状況分析とコンプライアンス監査に活用。
5. データ分類と入力制限
5-1. データ分類ポリシーの再定義
もともと社内には「機密」「社外秘」「部内限定」程度の分類はあったが、生成 AI 時代に対応するため、次のように改訂：
レベル 0：公開情報
Web 公開済みのパンフレットなど
レベル 1：社外秘（通常の業務情報）
レベル 2：社外秘・高機密
M&A、戦略、価格戦略 等
レベル 3：特別機微情報（個人の健康・労組情報等）
Copilot に投入してよいデータを以下のように定義：
レベル 0〜1：→ 通常利用可（ただし社外情報との混在に注意）
レベル 2：→ 原則禁止、個別承認を要する PoC でのみ限定利用
レベル 3：→ いかなる形でも Copilot への投入禁止（規程に明記）
5-2. プロンプト側での制御
UX として：
チャット入力欄の上に「個人番号・健康情報・機微情報は入力しないでください」を常時表示
実験的に、正規表現＋簡易 NER で「明らかな個人番号・健康項目」は警告を出す
「社内規程 Q&A」ボットは、
そもそも個人名を含む質問をしない前提で設計（「Aさんの勤怠…」などが来たら汎用指針だけ返す）
6. ログ・監査・説明責任
6-1. 何をログに残したか
誰が（Entra ID の userId）
いつ
どのユースケース（メール草稿／規程Q&A／コード支援 etc）
プロンプトのハッシュ値（生テキストはフル保存しない方針）
トークン数／応答の長さ／モデルバージョン
→ 「中身のテキスト」まで全部残すかは議論があり、結果として：
本番環境では原則フルテキストは保持しない
トラブル調査が必要な場合に限り、デバッグログ（別環境・短期保存）を参照できるように設計
Azure OpenAI Data Zone では「Zero Data Retention（ZDR）」構成も可能であり、LLM 側ではプロンプトがログとして保持されないことを前提に、アプリケーション側で必要な範囲のメタデータのみ保持する方針にした。
6-2. 監査・説明用のダッシュボード
Kusto / Log Analytics を用い、
部門別・ユースケース別の利用量
利用の急増・異常パターンを可視化。
内部監査からの典型質問：
「誰がこの規程 Q&A ボットの内容をレビューしているか」
「AI の回答をそのまま顧客に送っていないか」
これに答えるため、
回答テンプレのレビュー履歴
ユーザ向けガイダンス（“必ず最終チェックすること”）を Knowledge ベース＋教育資料に残し、証跡化。
7. 法務・コンプライアンスの具体的アウトプット
7-1. AI 利用ポリシー（社内規程）
短めの「AI 利用に関する行動規範」と、長めの「AI 利用ガイドライン」の二階建てで整備。
禁止事項
機微情報の入力
AI の回答を、そのまま契約書・顧客提案書として外部提出すること
利用者の責任
内容確認義務
出典・根拠の確認義務（特に規程・法令に関する回答）
開発者・運用者の責任
ログ・監査・品質評価の実施
モデル更新・プロンプト変更時の影響評価
7-2. DPIA / AI リスクアセスメント
GDPR DPIA では：
対象データ：従業員の業務コンテンツ（メール・文書）、顧客情報の一部
リスク：
誤回答による誤った意思決定
機微情報の誤入力
EU 外へのデータ移転（Data Zone 採用により限定）
対策：
データ分類ポリシー＋教育
Azure OpenAI Data Zone による EU 内処理
ログ・監査・利用制限
AI Act に関しては、
高リスクに該当しないことの根拠を整理（Annex III 該当性の検証）
将来、「高リスクユースケース（例：安全関連の自動検査判定）」をCopilot に統合する場合の追加要件もメモ。
8. PoC〜本番展開のプロセス
8-1. PoC フェーズ
対象部門の選定
グローバル HR（規程 Q&A）
技術文書部門（マニュアル作成支援）
IT サポート（ユーザ Q&A ドラフト）
成功指標（KPI）を定義
文書作成時間の削減 %
一人当たりの検索時間の削減
ユーザ満足度アンケート
安全性・品質評価
ランダムに 100 件の回答をサンプリングし、人間レビューで
正確性
コンテキストの適合性
ハルシネーションの有無をスコアリング。
ユーザ体験からのフィードバック
「回答は長すぎる」「敬語がかたい」「日本語がおかしい」などUX 起点の改善も実施。
8-2. 本番ロールアウト
段階的展開：
Phase 1：PoC 部門＋その周辺
Phase 2：全社（ただし利用できるユースケースは限定）
教育：
e-learning + ライブ研修
「AI にしてはいけない 10 のこと」という短いハンドブック
ガバナンス：
AI ガバナンス委員会（法務・セキュリティ・DX・人事）を設置し、
新ユースケース申請
リスク評価
ロールアウト承認を行うプロセスを整備。
9. 導入の効果と“現実的な悩み”
9-1. 効果（定量・定性）
文書作成時間：
HR・PMO 部門で「初稿作成にかかる時間が平均 30〜40% 減った」という自己申告
規程 Q&A：
過去はメールで法務・人事に飛んでいた質問の 30〜50% をCopilot でセルフ解決できるようになった
社内の“シャドー AI 利用”の減少：
社外無料ツールへの入力が減り、「安心して使える公式ツール」があることが浸透
9-2. 現実的な悩み・課題
「期待値過剰」との戦い
「AI があれば人いらないでしょ？」という雑な期待に対し、“あくまでアシスト”であることを経営層にも説明し続ける必要。
ナレッジの鮮度維持
RAG の元データが古いと、AI も古い回答を出す。
結局「元データのライフサイクル管理」が重要なボトルネックに。
ユースケースの“増やし方”
各部門から「これもやりたい」という要望が来るが、AI Act・GDPR 的にグレーなものも多く、ガバナンス委員会が“断る勇気”を求められる。
10. この事例を自社に当てはめるためのチェック
最後に、自社で社内 Copilot を検討する際の「問い」を並べます。
どのユースケースから始めるか？
メール草稿・規程 Q&A・議事録要約など、**“高リスクではないが効果が見えやすい”**ものを選べているか？
どこにデプロイするか？
EU にユーザがいる場合、Azure OpenAI / Data Zone（Sweden Central / Germany West Central）のようなEU 内レジデンシを積極的に検討しているか？
データ分類と入力制限は整理されているか？
「これだけは絶対にプロンプトに入れてはいけない」というリストを規程と UX の両方で示せているか？
AI Act / GDPR の観点での立ち位置は明確か？
高リスク／禁止領域に踏み込んでいない根拠を整理し、DPIA・メモとして残しているか？
ログ・監査・説明責任の設計はあるか？
「誰がどんな用途で使っているか」を示すダッシュボードを持ち、内部監査・顧客からの問い合わせに答えられるか？
“AI ガバナンス委員会”のような場はあるか？
新ユースケースの審査
ポリシーのアップデート
規制（AI Act / GDPR）の変化のウォッチを誰が担うのか、決まっているか？
コメント