2025年11月

2025年11月16日 (日)

2025年11月13日付で、Microsoft 365 Copilot が Data Loss Prevention(DLP)ポリシーをサポートするようになりました。

Learn about the Microsoft 365 Copilot location | Microsoft Learn

概要

Microsoft Purview のDLPによって秘密度ラベルが適用されているアイテムを Microsoft 365 Copilot のプロンプトに対する応答要約内で使うことを防止できるようになりました。

これをセットアップするには、DLPポリシーを作成して処理したくない秘密度ラベルを含むファイルなどを除外するよう、 Microsoft 365 Copilot ポリシーのローションにある「コンテンツを含む」>「秘密度ラベル」を追加します。

結果の引用元には引き続き情報が表示さますが、実際には当該コンテンツは使われません。

Copilot の処理に使われると問題となる情報の主な例は次の通りです。こうした情報は秘密度ラベルを適切に適用して保護する必要があります。

説明
個人情報 社員名簿、住所、電話番号、給与情報など。個人情報保護法やGDPRに抵触する可能性がある。
契約・取引情報 顧客との契約書、価格表、見積書。競合に知られると価格戦略が崩れるリスクがある。
内部方針・計画 来期の事業計画、マーケティング戦略。公開されると競争優位性を失う。
認証情報やシステム構成 サーバー設定、APIキー、パスワード。これが漏れるとセキュリティ事故に直結する

ポリシー構成上の注意

  • Microsoft 365 Copilto ポリシーの場所はカスタム ポリシーテンプレート内でしか利用できません。
  • Microsoft 365 Copilot ポリシーの場所を選択すると、他のポリシーはすべて無効化されます
  • DLPアラート、DLP通知とポリシーシミュレーションモードはサポートされます
  • DLPポリシーに対する更新は Microsoft 365 Copoilot 内に反映するまで、最大4時間かかります。

カバー範囲

Microsoft 365 Copilot ポリシー場所は Copilotが複数のエクスペリエンス間で処理する特定のコンテンツをサポートします。

  • 保存されているファイルおよびアクティブに開いているファイル
  • 2025年1月以降に送信されたEmail
  • カレンダー招待はサポートされない。またローカルファイルもサポートされない
  • Word, Excel, PowerPoint のようなMicrosoft 365 アプリ内のCopilot 用のDLPはファイルをサポートされるが、Emailはサポートされない

Word, Excel, PowerPoint 内でファイルが開いていて、DLPポリシーでMicrosoft 365 Copilotによって処理されないように指定している秘密度ラベルが適用されているとき、これにのアプリ内のスキルは無効化されます。

20251116_202804

管理単位のサポート

Microsoft 365 Copilot ポリシーの場所では管理単位はサポートされません。

サポートされる条件とアクション

Microsoft 365 Copilot ポリシーの場所はでは次の条件とアクションをサポートします。

  • 条件: コンテンツを含む>秘密度ラベル
    選択した秘密度ラベルがファイルや Exchange 内のE-mail で内で検出された時
  • ポリシーアクション: Copilot がコンテンツをしよりするのを防止する
    アイテムのコンテンツが Copilot によって処理されず、応答サマリでも利用できないようにする。ただし、応答の引用元としては当該アイテムが使われる可能性がある

ポリシーの作成結果

Microsoft Purview でカスタムのDLPポリシーを作成してみました。まず場所として “ Microsoft 365 Copilot および Copilot Chat” を選択します。

20251116_144303

ポリシー設定でまず条件として「コンテンツに含まれている」で「秘密度ラベル」を指定します。また、操作では、「 Copilot によるコンテンツの処理を制御する」を選択しています。

20251116_172809

以上の設定内容で DLPポリシーを新規に作成しました。

20251116_173513

ポリシーを作成してからしばらく経ったあと、実際に Microsoft 365 Copilot Chat で当該の秘密度ラベルが適用されているファイルを使った実験をします。今回は “花 - Demo.pptx” を使います。

20251116_193546

このファイルをCopilot Chat のコンテキストIQから参照して、プロンプトを作成します。すると、「組織のセキュリティポリシーにより取得できませんでした。そのためファイルの要約を行うことができません」というメッセージが表示されます。ちなみに、ソースとして利用しようとしたファイルは表示されていますが、処理はされていません。

20251116_193524

弊社関連コースのご案内

弊社では Microsoft Purview によるMicrosoft 365 内ファイルおよびメールに特化した、機密情報保護やコンテンツのライフサイクル管理機能についてじっくり学べる研修をご用意しています。

Photo

2025年11月12日に GPT-5 シリーズのアップグレードバージョンがリリースされました。

GPT-5.1: A smarter, more conversational ChatGPT | OpenAI

具体的には次の2つです。

  • GPT-5.1 Instant …最もよく使うモデルであり、より親しみやすく、賢く、指示にもより的確に応えるようになった

  • GPT-5.1 Thinking…高度な推論モデル。単純なタスクであれば素早く理解し応答する。複雑なものについてはより深く根気強く考え続ける

GPT-5.1 は賢さとコミュニケーションスタイルについて実質的な改善に取り組んおり、これに伴いChatGPTの口調を、会話や好みに応じて手軽に調整できるようになりました。

GPT-5.1 Instant の特徴

これが一般的には最も利用されるモデルであり、既定では、より親しみやすい口調でより会話調になっています。初期テストでは、明快さと有用性はそのままに、思わず笑顔になるような親しみやすさに驚く人も多かったとのこと。

GPT-5.1 Thinking の特徴

GPT-5の Thinking をアップグレードし、毎日利用することを考えてより効果的に素早く考えられるようにしました。また質問に対する思考時間をより正確に調整できるようになりました。簡単な質問には素早くこたえ、複雑な課題にはじっくりと時間をかけられるようになっています。

GPT-5.1 Thinking の応答はより明快で、専門用語や定義されていない言葉の利用は少なくなっています。

GPT-5.1 Auto 

GPT-5 で導入された Auto も引き続き利用できます。ちなみに、GPT-5 を利用する Copilot では To-brain approadch (2つの頭脳アプローチ)が提供されています。

  • 高速処理モデル: Hight-throuput model
  • 深い推論モデル: Deep reasoning model

この2つを自動的に切り替えられるオプションが Autoです。これが GPT-5.1でも継続されるとのことで、Auto しておくと、処理に適したモデルを自動的に選択するので、どちらのモデルを選択すればよいか悩む必要はありません。ただ、必要に応じて特定のモデルを明示することも可能です。

20251116_122809

口調や文体などの調整オプション

ユーザーの好みに応じて口調や文体を細かく調整できるようになっています。

20251115_193631

リリースについて

GPT-5.1 Instant と Thinking は 2025年11月25日よりロールアウトが開始され、まずは有料プラン(Pro, Plus, Go, Business) のユーザーからスタートし、その後はフリーまたはサインインしていないユーザーでも利用できるようになります。最終的には GPT-5.1 が単独の既定のモデルとなる予定です。

ちなみに、現在、米国顧客限定ですが、早くもCopilot Studio でエージェントのモデルとして GPT-5.1 も選択できるようになっています。

Available now: GPT-5.1 in Microsoft Copilot Studio | Microsoft Copilot Blog

51final11024x913

2025年11月14日 (金)

Adobestock_1515892969

Microsoft の SharePoint ショーケースとして「メタデータとナレッジ エージェントとが Microsoft 365 Copilot の応答精度をいかに高めるか」に関する記事が公開されています。ここでは主要な点について考察を交えながら解説します。

SharePoint Showcase: How Metadata and the Knowledge Agent Elevate Microsoft 365 Copilot Responses | Microsoft Community Hub

メタデータの重要性

Microsoft は2025年11月から SharePoint ナレッジエージェントだけでなく Microsoft 365 Copilot にもメタデータを理解・活用できる機能を追加します。つまり、Microsoft 365 Copilot Chat などでファイルやフォルダー、ライブラリ参照時するときに、メタデータを含めた文脈でAIが推論できるようになるということです。

メタデータはファイル本文以外の次のような情報のこと言います。

  • ファイル名
  • ファイルの拡張子
  • ファイルの作成者・更新者
  • ファイルの作成微・更新日
  • ドキュメント ライブラリ内の列の値

ここでの注目点はドキュメント ライブラリ内に追加する任意の列の値も生成AI(microsoft 365 Copilot や SharePoint ナレッジエージェント)が利用できるようなったということです。

SharePoint の場合は、ファイルの仕分け方はファイルの要件ごとにライブラリを複数に分け、ライブラリ内で共通する列を追加することです。そのうえで必要があればさらにフォルダーで物理的に仕分けていくという流れです。ここがファイルサーバー的な発想でのバイアスに縛られていると、ついライブラリ自体はフォルダーと表現されないのでルートフォルダー的なとらえ方をしてしまい、単一のライブラリ内に異なる種類・性質のファイルをフォルダーで仕訳けていくという使い方をしてしまいがちです。しかし、そもそも SharePoint での考え方はサイトやライブラリという粒度でまずは情報を仕分け、フォルダーにあまり依存せずにりようできるようになっています。

SharePoint エージェントによるメタデータ管理機能の強化

さて、現在、SharePoint ナレッジエージェント(プレビュー)ではライブラリ内のファイルをもとに列を提案し、Autofillまで設定できる仕組みとして「ライブラリの整理」という機能がありますが、従来からさらにメタデータ管理を強化していこうとしているわけです。

SharePoint が取り組んできたこれまでのメタデータ管理の経緯

SharePoint でメタデータ管理というと、最近急にそんなことを言い出したように感じる方もいらっしゃるようですが、メタデータは SharePoint Server 2007から利用できるものであり、この機能強化はその後も継続しています。急に出てきた機能ではありませんし、そもそも SharePoint の根幹機能の一つはドキュメント管理システムです。世の中のドキュメント管理システムは、メタデータを使ってナレッジ管理をしていく製品がほとんどであり、ずいぶん昔からメタデータ管理に取り組んでいるのです。決して付け焼刃的なものではなく、長年にわたり Microsoft も試行錯誤してきた経緯があります。メタデータ管理で最も厄介なのが、だれが妥当なタグ付けをしていくのかということです。ドキュメントアップロードと同時に関連付けたCSVファイルから属性情報を付加するような機能を持つ製品もあります。要は、人が手動で設定していくというのが基本です。ただ、昨今のように組織が抱えるコンテンツ量が膨大になると、もはや人海戦術的なアプローチだけでは不十分であり、そこにきて AIによってメタデータを付加していこうという流れが生まれるのは必然的なことです。ただ、Microsoft が開発してきたAI機能はたとえば、SharePoint Syntex などでのモデル生成機能などがありましたが、定型的な請求書フォームなどのデータはある程度は対応できたものの、非定型な(非構造化)契約書などのフォーマットの場合、モデル作成するためのメタデータ抽出の学習はなかなか骨の折れる作業であり、しかも英語のみが対応している状況が続き、日本語対応はできないままでした。ですが、ここに生成AIの登場です。生成AIの場合は、非定型的なデータ(非構造化データ)から文脈を読み取るのが得意であり、言語の壁も比較的簡単にクリアしてきています。SharePoint ナレッジエージェントが持つ「ドキュメントの整理」機能で列を自動生成し、かつ値もAIにより本文から抽出してくれますが、日本語でも動作します。つまり、自動的にメタデータを抽出して適切に設定することができるようになったわけです。

ファイルの数が少なければ、フォルダーの階層構造で仕訳けていくのが比較的容易ですが、コンテンツ量が膨大になっていくと階層は複雑化し、かつ分類も複数のフォルダー分類にまたがる可能性があるものもでてくる。そうなると、どの階層をたどればよいかが判別しにくい。しかも、ファイルを探すのに、手がかりはフォルダー構造とファイル名頼みで、人は「暗記」に頼るしかなくなる。それでも覚えきれず、フォルダーなどのショートカットを作成して、決まった場所を使い続けていくことになります。ユーザーがアクセスする範囲は局所的になってしまう。ファイルサーバーだと検索なども十分にできませんし、しかもバージョン管理機能がないので似たファイル名でバックアップを山ほど作成して、どれが正規版かわからない。適切に削除もされないので、古い情報もたまっていくばかり。日の目を見ないコンテンツもあるでしょうし、似たようなファイルが複数作成されているかもしれない。組織のナレッジがうまく蓄積・整理・共有できないという状況になってしまいます。

組織に蓄積されているコンテンツは本来は、各従業員が蓄積してきたノウハウや知恵・知識の宝の山です。これを生かしてよりよい仕事の仕方ができるよう工夫する糧になるはずで、ひいては人材を大切に育成することにもつながっていくはず。

こうした情報を埋もれさせず、捨てるべきは捨て、秘匿するものは秘匿するという仕組みを作ってくために必要な情報の一つがメタデータです。ようはファイルにタグ付けを必要な数だけ行えばファイルの格納場所に依存せずに、いろいろな切り口で情報を見つけることができるようになる。このようにまずは組織が抱えるコンテンツを把握できるような見通し確保できないと、組織の宝となるナレッジを十分に利用できません。ちなみに、SharePointは最初のバージョンから検索エンジンを持っており、蓄積+検索を視野に入れています。ファイルサーバーに不足している「大量コンテンツをいかに再利用しやすくするのか」という点にフォーカスを当てて、製品が進化してきています。

検索がうまくいかないという声をX.comでも時々目にしますが、まったくヒットしないということはないはずで、たぶん、検索範囲というものがあることを知らないだけではないかと思います。その点は以前の記事で取り上げているのでよかったらどうぞ。

SharePoint Technical Notes : SharePointの検索は検索を開始する場所によって検索範囲が異なる

メタデータによりMicrosoft 365 Copilot による組織内のデータを高精度で取得できる

さて、冒頭でも述べましたが2025年9月には SharePoint ナレッジエージェントはライブラリの列をメタデータとして利用できる機能がロールアウトされました。2025年11月には、さらに Microsoft 365 Copilot にも拡大されるということです。

メタデータのある SharePoint コンテンツをグラウンディングするエージェントは、メタデータがあることで、本文だけでなく、タグや分類、業務的背景も含めて、推論できるようになるのでより精度の高い回答が導けます。これはMicrosoft エコシステム内で構築されたAIだからこそ実現できる独自の強みと言えます。

LLMs は確率論的である。これをメタデータを組み合わせて決定論的なものに変容させる

そもそも、LLMというものは性質上、確率論的です。LLMsが生成するものは、データのパターンに基づくものにすぎません。

しかし、法務や財務、エンジニアリングやヘルスケアなどの特定の産業では決定論的な回答が求められます。つまり、生成AIから得られる回答は常に一定である必要があるわけです。常に同じ条件なら同じ答えが返ってくる。さらに言えば事実に基づいて再現性があり、曖昧さや揺らぎがないことを求められるわけです。

しかし、AIを完全に決定論的に追及していくことは、LLMの持ち味である創造性や微妙なニュアンスが犠牲になることにつながりる。となれば、解決策の一つは、AIが安全に動作できるような決定論的な環境を整えることです。

SharePoint のコンテンツに対してメタデータによって情報を付け加えることでAIの創造性をしっかりと維持したまま情報の境界線を明確にできる。メタデータは “アンカー(錨)” のような役割を果たし、Copilot やエージェントが創造性を保ちつつ、信頼性の高いビジネス向けの回答を提供する一助となります。

LLMs は本質は常に確率論的ですが、構造化されメタデータが豊富な環境では、ビジネス上のニーズに応じて、AIはよりはるかに高い精度での応答が可能になるのです。

実際に原文の記事では、メタデータとして列を追加している場合と追加していない場合とでCopilotの解答の精度の違いを実験しています。メタデータの有無によりかなり結果が変わってきます。

フォルダー構造と「複数のライブラリ+メタデータ」

従来通りファイルサーバーと同様にフォルダー構造を使うほうが良いのか、メタデータを使うほうが良いのかという議論は、よく話題に上がります。私としては、これまでもこのブログ、拙筆の書籍、弊社の研修、コミュニティ勉強会などでも一貫してメタデータを組み合わせることの重要性は説明してきています。

ただ、このようにメタデータの重要性を説明すると「愛さんは、フォルダーは嫌いなんでしょう?」と声をかけられることがあります。これは単に個人的な好みで好きとか嫌いという話ではなく、いかに業務を合理化するかという話にすぎません。どうしても新しい概念が登場すると大抵の人は「とっつきにくさ」があるため、あまり考えずに今まで慣れている「フォルダー」作成をしがちなです。そのためフォルダーを作らなくても済むように一度よく考えてみて欲しい、という啓蒙的な観点でフォルダーはなるべく持たせないようにしましょうと言っているだけなのです。

いくつか現場を拝見する際に、業務の内容によっては従来通りフォルダー構造にして "場所" で格納場所を覚えてそこから必要な情報を掘り起こしていく方が向いているケースももちろんあります。こうしたケースでは、コンテンツを格納するスピード感が優先され、整理整頓する時間が十分に取れないことがよくあります。それでも、精度が多少低くともある程度は生成AIが情報を検索してくれるでしょうから、人の手で探すよりは Microsoft 365 Copilot の有償版をうまく活用するのが吉と出ると思います。

ただ、多くの人が「探す」ことに時間を費やすことが多い、手順書や手続き、仕様書、社内規程、法定保存文書(契約書、見積書、請求書など)、教材などは、探す時間を短縮しかつより正確な情報を取得できるようメタデータを活用できるのが望ましいと思っています。

適材適所でうまく使い分け、業務によっては従来通りのフォルダー構造が良ければそれを使えばいいし、それでも「探す時間」がかかることが業務効率の低下につながっているようなケースではサイトやライブラリの分け方を再考して、メタデータを活用する方向で舵を切りたいところです。

機密情報保護とコンテンツのライフサイクル

最後に付け加えておくのが、機密情報保護とコンテンツのライフサイクル管理です。

Copilot が組織の重要情報をもとに不用意に回答を作成しないようにMicrosoft 365 ではファイル単位で「秘密度ラベル」というのもを付加できます。この秘密度ラベルもファイルに対するメタデータの一種です。ラベルの設定によってはファイルを暗号化でき、社外にデータが持ち出されても正規のユーザーでないとファイルを開けないようにできます。また、機密情報が含まれているメールを外部に共有できないようにするといったことも可能です。

ライブラリ単位で既定の秘密度ラベルを設定しておくことも可能で、新規に格納したファイルは既定で常にライブラリに指定した秘密度ラベルが自動適用される。そのため、このライブラリは機密情報を格納する場所にしよう! というように決めておけます。フォルダーではなくライブラリ単位であることに注意してください。

またこの秘密度ラベルは SharePointサイトに適用することも可能です。ラベルによっては共有リンクのオプションを自動的に変更したり、コンテンツのダウンロードを禁止するような設定が可能です。

また、コンテンツのライフサイクル管理は重要です。ようは、寿命を決めてしかるべきタイミングできちんとコンテンツを削除するという話です。ファイルサーバーだけでは、これが適切にはできなかったのですが、SharePointではこうしたライフサイクル管理が可能です。一定期間は削除できないとか、期限が来たら削除できるようになる、もしくは自動的に削除する、Power Automate のフローで削除の判断をするなどできます。

こうした機密情報保護やコンテンツのライフサイクル管理は SharePoint 単独ではなく Microsoft 365 に含まれる Microsoft Purview と共に管理していくことになります。こうした管理を組み合わせれば、SharePoint + Purview で電子帳簿保存法にもしっかりと対応できます。

さらに、Microsoft 365 Copilot 有償ライセンスを持つ組織であれば、SharePoint サイトのガバナンス管理機能が強化されます。サイトのライフサイクル管理も可能で、使わなくなったサイトは一定期間サイト管理者から応答がなければ、読み取り専用に変えるとか、アーカイブしてストレージコストを抑えるといったことも可能です。

こうした一連の管理タスクなども踏まえて Microsoft 365 Copilto を利活用を推進できるのが望ましいといえます。

弊社で用意しているオリジナル研修

弊社では、こうしたMicrosoft 365 および Microsoft 365 Copilot の利活用から運用管理を考えた研修コンテンツのラインナップを取り揃えています。

お問い合わせや研修のお申込みは次のリンク先からお願いいたします。

2025年11月13日 (木)

Copilot Studio 内にあるエージェントフローの実行速度を早くするために、「エクスプレス モード」が現在パブリックプレビューとなっています。これにより、エージェントフローを最適化し、2分以内にフローを終える可能性が高まります。

20251113_151528



もともとエージェントフローはエージェントやアプリから呼び出されると2分以内に応答がなければ失敗します。ですが、エクスプレスモードをうまく利用することで、エージェントやアプリが応答を待つ間にタイムアウトしてしまうことを防ぐことができます。

エージェントモードは、ロジックが複雑でありながらデータ量自体は少ないフローに最適です。100アクションを下回りかつより小さなペイロードであるフローに限定することで、全体の実行時間がより効率化できます。

大きなデータセットは移動させる必要がある場合や大きな配列で繰り返し処理するループが発生する場合は、フロー作成者はエクスプレスモードのあり・なしの両方でテストすることを Microsoft は推奨しています。

エクスプレスモードのオン・オフ

エクスプレスモードのオン・オフの切り替えは、まず "When an agent calls the flow" トリガーを追加するときに表示される「Enable faster flow execution」トグルをオン・オフにすることです(冒頭の画像)。

また、フローの編集画面からもオン・オフを切り替えられます。

20251113_154931

実験

早速エージェントフローを作成して動作実験をしてみました。結果は次の通りです。

エクスプレス モード フローの総実行時間
オフ 474ミリ秒
オン 190ミリ秒

オンにした場合は、約60%ほど処理時間が短くなりました。無論、あくまでも単発の実験結果であり、どういったフローになっているか複雑さなどによって結果は変わることになります。

20251113_182923

ライセンス

エクスプレスモードは、Copilot Studio プランのフローでのみ利用できます。このモードでフローを実行しても追加料金は発生しません。ただし、実行するフローにクレジットを消費するアクションが含まれていれば、その分は課金対象となります。

必要要件や制約について

エクスプレスモードを利用するための要件やフロー発行時の制限、フローサイズ、メッセージサイズなどの上限などが決まっています。最新情報は下記のリンク先を参照してください。

Speed up agent flow execution with express mode (preview) - Microsoft Copilot Studio | Microsoft Learn

宣伝

オフィスアイ株式会社では、Copilot Studio によるエージェント構築について生成AIの基礎から学べるハンズオン研修をご用意しております。

Copilot_studio

Power Automate の環境が新しいアーキテクチャーに自動的に移行されます。移行先の環境はSelfHost & Multitenantというもので、エクスプレスモードのような新機能も利用できるようになるとのこと。

Power Automate environments move to new architecture - Power Automate | Microsoft Learn

移行がされたかどうかを確認するには目的の環境にアクセスして、Ctrl+Alt+A を押下します。表示されるデバッグモードの画面からenvironmentFlowHostingType という値を探します。

この値が✅SelfHostMultiTenant だったら新しい環境で、✅LogicAppsだと従来の環境です。

20251113_155256