③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）の変化のウォッチを誰が担うのか、決まっているか？