こんにちは。組織内の情報システムやセキュリティ、AI活用を担当しているエンジニアです。
皆さんは「Microsoft Copilot Studio」を使って社内のドキュメント(就業規則など)をデータソースとしたチャットボット(エージェント)を構築した際、**「同じGPTシリーズを使っているはずなのに、通常のMicrosoft 365 Copilot Chatと比べて回答の精度が著しく低い」「自社のドキュメント内容を無視して、一般的な就業規則の解釈を回答してくる」**という現象に悩まされたことはありませんか?
本記事では、私が実際に経験した「Wordの就業規則が全く読めなかった問題」から始まり、Power AutomateでのPDF自動変換の苦闘、さらにAIエンジンの変更(OpenAI GPT ⇄ Anthropic Claude)によって世界が一変した体験をベースに、公式の公開情報から紐解いた技術的な背景と、現時点でのベタープラクティスを共有します。
論文のような硬い理論解説ではなく、現場で泥をすすりながら掴み取った「実体験ストーリー」として読んでいただければ幸いです。
1. 遭遇した課題:Copilot Studioで就業規則が「読めない」
組織向けAIエージェントを迅速に構築・デプロイするため、Copilot Studioを導入しました。
SharePointのドキュメントライブラリ内にある「就業規則フォルダ」を指定し、中にあるWord(.docx)形式の就業規則をナレッジとして接続したのですが、ここで最初の壁にぶつかりました。
実際の挙動
- ユーザーの質問: 「当社の所定労働時間と休憩時間を教えてください」
- Copilot Studioの回答: 「一般的な企業の就業規則では、労働時間は8時間、休憩は1時間と定められていることが多いです…(自社の規則を無視した一般論の出力)」
自社の就業規則には全く異なる時間が明記されているにもかかわらず、中身を正確に読み解かず、ハルシネーション(もっともらしい嘘)や一般論を出力してしまったのです。
Microsoft 365 Copilot Chatとの謎のギャップ
不思議だったのは、Microsoft 365 Copilot Chat(Teams内やM365アプリの標準チャット機能)に同じWordファイルを直接アップロードして質問すると、完璧に正しい回答が返ってくるという点です。同じOpenAIのGPTシリーズをベースにしているはずなのに、なぜCopilot StudioのRAG(検索拡張生成)ではこれほどまでに挙動が異なるのか、強い疑問を抱しました。
2. 泥沼の回避策:WordからPDFへの変換自動化とその限界
「Word(.docx)の構造がうまくパース(解析)されていないのではないか?」という仮説を立て、ファイルをPDF形式に手動で変換してアップロードしたところ、あっさりと内容を認識しました。
「原因はファイル形式か!」と考えた私は、運用の自動化を目指して以下の構成を試みました。
【当初計画した自動化フロー】
ユーザーがSharePointにWordをアップロード/更新 ➔ Power Automateフローが起動 ➔ OneDriveの「ファイルの変換」アクション等を駆使してWordをPDFに自動変換 ➔ 変換後のPDFを別フォルダに格納し、それをCopilot Studioのナレッジとして再読み込みさせる
しかし、このPower AutomateによるOffice文書のPDF自動変換フローは、大容量ファイルや複雑なレイアウトにおけるエラーハンドリング、コネクタの制限(実行時間や制限事項)などがあり、安定稼働する最終形に至るまでには非常に多くの開発工数がかかる「泥沼」の状態でした。1〜2ヶ月の間、ひたすらフローの調整(ガチャガチャと試行錯誤)を繰り返す日々が続きました。
3. 転機:Anthropicモデルの統合と驚くべき検証結果
そんな中、Copilot StudioをはじめとするMicrosoftプラットフォームにおいてマルチモデル戦略が正式にサポートされ、外部AIエンジンとしてAnthropicのClaudeシリーズが公式に選択可能(※Microsoft 365 管理センターの「Microsoft サブプロセッサとして動作する AI プロバイダー」で管理者が有効化可能)になったことを知ります。
「Power Automateのフローをこれ以上作り込む前に、一度AIエンジンを変えてみよう」と思い、エージェントの基本モデルを切り替えたところ、驚くべき結果が得られました。
劇的な変化
Power AutomateによるPDF変換を行わず、元のWord(.docx)形式のままであったにもかかわらず、詳細すぎるほど正確に就業規則の中身を読み解き、完璧な回答を出力したのです。
これによって、それまで1〜2ヶ月かけて構築していた「Office ➔ PDF自動変換フロー」自体が完全に不要になりました。高度な前処理フローの実装に頭を抱えるよりも、インフラ(AIエンジン)側のモデルアップデートを適切に選択する方が、遥かにスマートに課題を解決できるという、現代のAI開発ならではのパラダイムシフトを体験した瞬間でした。
4. 技术적背景の分析:なぜこれほどの差が出るのか?
Microsoft、OpenAI、Anthropicの公開情報および技術的特性から、この挙動の差(傾向)を分析します。
① Microsoft 365 Copilot Chat と Copilot Studio のRAGアーキテクチャの違い
同じOpenAI系モデルを使用していても回答が異なる理由は、裏側のRAGの仕組みとガバナンスの厳密さにあります。
-
Microsoft 365 Copilot Chat:
Microsoft Graphを介して、ユーザー個人の権限に紐づく広範なコンテキスト(セマンティックインデックス)に動的にアクセスします。個人アシスタントとしての柔軟な要約能力や、コンテキストの動的補正に長けています。 -
Copilot Studio:
特定の業務プロセスや組織全体のカスタムエージェントを構築するプラットフォームです。セキュアで厳格なデータソース統合(インデックス構造)が重視されるため、ドキュメントのパース(解析)ルールや、安全性のためのフィルターがより厳しく働きます。結果として、Wordの構造データがうまくインデックス化(チャンク分割)されていない場合の「すり抜け(一般論への逃げ)」が起きやすい傾向があります。
② OpenAI (GPT) と Anthropic (Claude) のテキスト処理傾向の差
無暗にスペック表を並べても、読者はその数字しか見なくなってしまいます。ここでは、両者を実務で叩き続けたからこそ見えてきた**「リアルな手触り感」**をベースに比較します。
-
OpenAI (GPTシリーズ)
- 手触り: 非常にスマートで、要点を手短に、簡潔にまとめる能力(サマライズ重視)に優れています。特定のキーワード周辺のコンテキストをピンポイントで拾うのが得意です。
- Copilot Studioでの体感: パース(抽出)が甘いと、カチッとしたセキュリティフィルターや厳格なインデックス構造の裏で、一般論に逃げやすい傾向があります。
-
Anthropic (Claudeシリーズ)
- 手触り: 網羅的、詳細、かつ構造的に出力する論理展開重視の姿勢を感じます。コンテキストウィンドウが広く、文書全体の緻密な関係性を捉えるのが得意です。
- Copilot Studioでの体感: Wordのまま構造を深く読み解き、数十ページの就業規則を丸ごと投げても、前後の矛盾や細かい例外規定を網羅的に見落とさずに詳細に回答します。
GPTはスマートな要約に強みがある一方、就業規則のような「一言一句が重要な複雑な規程文書」をRAGで参照する場合、Anthropicモデルの方が**「コンテキスト(関連情報)を余さず詳細に表示する」**という特性が有利に働いたと考えられます。
5. まとめとエンジニアへのアドバイス(ベタープラクティス)
今回の経験から、Copilot Studioで社内ドキュメント特化型ボットを作るエンジニアの皆さんへ、以下の**「ベタープラクティス」**を提案します。
💡 1. データの「パース(Parsing:構文解析)」に悩んだら「Anthropicモデルの活用」を強力な選択肢に
Office文書からPDFへの変換フローをPower Automate等で実装するなどの「泥臭い前処理」に貴重な開発工数を奪われるくらいなら、AIエンジンをAnthropic製に切り替える方が、圧倒的に低コストで高精度なボットが完成します。エンジニアがデータ構造の問題で悩む時間を劇的に減らえるアプローチです。
💡 2. 「ベスト」ではなく「ベター」の思想を持つ
これは「GPTよりAnthropicが絶対的に優れている」という意味ではありません。GPTにはGPTの良さ(簡潔な要約、特定タスクの高速性、エコシステムとの親和性など)があります。
ビジネス要件、対象となるドキュメントの性質に合わせて**「今のシステム、今のドキュメントにおいてどちらがよりベターか」**を戦略的に選択する姿勢が重要です。
💡 3. プロンプトによる「回答の制御(文字制限・形式指示)」は必須
Anthropicモデル(特にClaude)を起用する場合、**「関連情報を詳細に出しすぎる(回答が長くなりすぎる)」**という贅沢な悩みが裏返しで発生します。
そのため、Copilot Studio内のシステムプロンプト(指示事項)に、以下のような細かい制御をあらかじめ組み込んでおくことを強くお勧めします。
【プロンプト指示の例】
- 「回答は必ず提供されたナレッジ(就業規則)の範囲内のみから抽出し、一般的な推測や外部の知識を含めないでください。」
- 「ユーザーが読みやすいよう、結論を先頭に書き、詳細は300文字以内の箇条書きで出力してください。」
補足情報・参考リンク
本記事の考察にあたりベースとした、各社のAIエンジンおよびCopilotのアーキテクチャに関する公開情報は以下の通りです。詳細な仕様変更やバージョンごとの正確な比較、最新のリージョン対応状況については、各公式ドキュメントをご確認ください。
-
Microsoft Copilot Studio 公式ドキュメント
https://learn.microsoft.com/ja-jp/microsoft-copilot-studio/ -
Microsoft 365 Copilot の管理・AIプロバイダー設定(Microsoft Learn)
https://learn.microsoft.com/ja-jp/microsoft-365/copilot/connect-to-ai-subprocessor -
OpenAI API 公式ドキュメント(GPTモデルの特性)
https://platform.openai.com/docs/models -
Anthropic / Claude 公式ドキュメント(モデルリファレンス)
https://docs.anthropic.com/claude/docs
※注:本記事に記載した検証結果は、特定のファイル構成および当時の検証環境における挙動に基づくものです。各AIモデルの最新バージョンにおける詳細な比較検討は、ご自身のテナント環境にて実施されることを推奨いたします。