Power Platform の管理者と System Customizer のセキュリティロールを持つユーザーはアプリアクセスチェッカーを使って特定のユーザーがモデル駆動型アプリに対して適切なライセンスをもっているかどうかを確認できます。

アクセス チェッカーのURLは次の通りです。

https://environmentURL/WebResources/msdyn_AppAccessChecker.html

environmentURLは Power Apps のセッション詳細に表示される Instance url です。

このツールは、モデル駆動型アプリの実行時に発生する可能性がある策定のユーザーで見つかった一般的な問題を特定できるツールです。

• アプリがユーザーに表示されるかどうか。
• アプリがユーザーに表示される/されない理由。
• ユーザーが必要なライセンスを持っているかどうか。

アクセスチェッカーページにアクセスしたら、対象のユーザーのUPNを入力して検索します。

ユーザーがアプリ モジュールテーブルに対する読みとり権限を持っていない場合はNoと表示されます。一方、読み取りまたは書き込み権限があれば Yes と表示されます。

ユーザーがアプリを再生するための適切なライセンスを持っている場合は Yes と表示されます。details リンクをクリックすると、ユーザーがどのようにアクセスできるか、またアクセスできないかについての情報を得られます。

ユーザーがアプリ モジュールテーブルに対する作成または書き込み権限を持っている場合は、Yes と表示されます。ユーザーがアプリに割り当てられた1つ以上にセキュリティロールに関連付けられていない場合は、ユーザーがチームのメンバーであるかどうか、またチームがそのセキュリティロールに関連付けら似られているかどうか確認します。 

参考

モデル駆動型アプリのアクセス チェッカー - Power Apps | Microsoft Learn

Microsoft Purviewでは、データ損失防止(DLP) の制御を Microsoft 365 Copilot と Copilot チャットに広げ、AIが生成した応答に影響を与える外部ソースのコンテンツがもたらす可能性のあるプロンプトインジェクションのリスクを低減させます。

今回ロールアウトされる新機能ではCopilot がプロンプト処理中に外部送信者からの電子メールをグラウンディングデータとして利用できないよう管理者が除外できるようになります。

この機能を有効化すると、Copilot は既存のライセンスおよびポリシー管理に従って、信頼できる Microsoft 365 内部のデータソースだけを用いて応答を続けるようになります。

📅ロールアウト

• パブリックプレビュー:2026年6月初旬～下旬
• GA: 2027年1月下旬から12月下旬

適用対象

Microsoft 365 Copilot (プレミアム)または Chopilot チャットを使っている組織

構成

Microsoft Purview 管理ポータルから、データ損失ポリシーを作成する際に場所として「Microsoft 365 Copilot および Copilot Chat」を選択します。既定ではすべてのユーザーとグループが対象となるため、必要に応じて適用範囲を変更します。

ルールを作成する際に、条件としては「電子メールの受信元」選択すると「組織外のユーザーが項目として表示されます。操作で「処理の追加」を選択すると、"Copilot によるコンテンツの処理を制限する" が選択肢に表示されるためこれを選びます。「ナレッジソースにアクセスしています」を選択します。これでブロックされるようになります。

これで組織の許可ドメイン外の送信者からメールを受信したことをポリシーが検知すると Copilot はそのメールをグラウンディング・要約・引用から除外するようになります。なお、このポリシーで評価するのは電子メールのメタデータだけです。送信者のドメインをテナントで許可しているドメインと比較します。メールの本文が調査されるわけではありません。

ちなみに許可されたドメインとは、Exchagne 管理センターの「メールフロー」>「承認済みドメイン」に表示されるドメインです。

参考

Microsoft Purview DLP for Microsoft 365 Copilot and Copilot Chat | Microsoft Learn

SharePoint の B2B統合 とは SharePointおよび OneDrive の外部共有を Microsoft Entra B2B (旧 Azure AD B2B) に統合する仕組みです。

これにより従来は外部ユーザーとコラボレーションするためにSharePoint 独自のメール認証やワンタイムパスコードを使ってユーザー認証を行っていましたが、B2B統合を行うことで外部ユーザーは Microsoft Entra ID のゲストユーザーとしてディレクトリ登録されるようになります。そのため多要素認証(MFA)や条件付きアクセスなどのポリシーも適用できるようになります。

外部共有の際に対象となるのは次の相手です。

• 他の Microsoft 365 テナントのユーザー
• Microsoft アカウントを持つユーザー
• 上記を持たない電子メールアドレスのみのユーザー (Gmailなど)

B2B 統合が登場した背景

B2B統合が登場した背景にあるのがセキュリティ強化と統一管理です。これまでは SharePoint 独自の外部共有モデルを利用しておりID管理が分散してしまい結果的に条件付きアクセスポリシーの適用が困難でした。理由としては、SharePoint で外部共有する際に SharePoint 独自のOTP(メールによるワンタイム パスコード認証)を行っており、ゲストアカウントの作成が必須ではなかったことにあります。そのため外部ユーザーからアクセスされた場合も監査ログなどに残る情報は限定的で匿名性が高かったのです。

ですが、B2B 統合後は外部共有する際にはEntra IDを使った認証へと変わり、ゲストアカウントを必ずEntra ID にB2Bゲストとして登録することになります。そうすると条件付きアクセスも適用ができるようになり、監査ログも完全対応できるようになります。

B2B 統合を有効化したテナントでは旧OTPリンクは完全に使えなくなるため再共有が必須になります。また外部共有は Entra B2B Invitation Manager を通じて行われ、ゲストアカウントが必ず作成されます。 

参考

• SharePoint & OneDrive の B2B 統合のMicrosoft Entra - SharePoint in Microsoft 365 | Microsoft Learn
• Microsoft 365 で SharePoint と OneDrive の共有設定を管理する - SharePoint in Microsoft 365 | Microsoft Learn
• Microsoft 365 の SharePoint と OneDrive での外部共有の概要 - SharePoint in Microsoft 365 | Microsoft Learn
• SharePoint で外部共有をセキュリティで保護する - SharePoint in Microsoft 365 | Microsoft Learn
• 電子メール ワンタイム パスコード認証 - Microsoft Entra External ID | Microsoft Learn
• B2B ユーザーの認証と条件付きアクセス - Microsoft Entra External ID | Microsoft Learn
• Microsoft Entra B2B のベスト プラクティスと推奨事項 - Microsoft Entra External ID | Microsoft Learn
• SharePoint Online Dumps OTP Authentication for Sharing Links | Microsoft Community Hub

Microsoft の CEO のSatya Nadella氏が X(旧Twitter)に興味深い記事を投稿されているので、少し解釈の補足も加えながら翻訳したものを置いておきます。

[引用元] XユーザーのSatya Nadellaさん: 「A frontier without an ecosystem is not stable」 / X

エコシステムを伴わないフロンティアは持続しない

私は AIドリブンな経済の中で企業の将来について実に多くのことを考え続けてきました。

この変革はこれまでのあらゆるプラットフォームのシフトとは異なります。過去、我々はデジタルシステムを用いて人の能力や価値を高めてきました。しかし、人とデジタルシステムが互いに学習しあい、認知を循環的に高め続ける「真の認知ループ」が本当に実現したのは今回が初めてです。このことは非常に衝撃的なものです。私たちが組織内における"仕事"というものをどうとらえるのかという、その概念そのものが変わるからです。

この変化の中で、真に問われているのは、デジタルツールやシステムの使い方ではありません。重要なのは、AIモデルが人や組織の専門性を吸収しつづけコモディティ化する世界において、組織がどう学び、知識財産を築き、差別化し、生き残っていくかという点です。

あらゆる企業は、私が人的資本(human capital)とトークン資本(token capital)と呼んでいるその2つの資本を築いていく必要があります。人的資本はその人の持つ知識、判断力、関係性、創意工夫やパターン認識で構成されます。一方でトークン資本はその組織が構築し所有するAI能力(つまり、モデルが吸収した組織の専門性)そのものです。

重要なのは、人的資本はトークン資本のようにコモディティ化して価値が薄まることはないという点です。人的資本は積み上げるほどに、独自性と価値が高まり、より価値のあるものにしかなり得ません。私は、人のエージェンシー(agency: 主体的な判断や行動)こそがトークン資本を成長させるドライバー(原動力)だと信じています。人は、大きな目標を掲げ、領域をまたいで点と点をつなぎ、関係を築き、何が本質的なパターン(意味のある兆しや構造)なのかを見極めます。人による指示がなければ、計算は堂々巡りになってしまいます。

本当の価値は、最良のモデルを選ぶことではなく、モデル上に人的資本とトークン資本が複利的に積みあがる学習ループを構築することにあります。皆さんは、仕事から離れたり、仕事を辞めることができますが、学びをやめることはできません。企業の未来は、人とAIの双方で学びを循環させ、その学びを組織全体にわたって複利的に増大させていく能力にかかっています。

これからの企業に必要なのは、新しい「構造的なアプローチ」です。それは企業は自社の知的財産をしっかりと守りながら、人とAIとが主体的に学びあい、絶えず進化を続けるシステム(エージェンティックなシステム)を構築することです。企業は、汎用モデルを入れ替えてでも、自社の学習システムに組み込まれた"ベテラン社員のような"専門性を失わないようにするべきです。

これは、これからの時代において、企業がどれだけ自社の"制御力"と"主権(独立性)"を保てるかを試す重要な局面です。

組織は自身のもつ業務フロー、組織に特化した知識、長年の経験から培ってきた判断力をAIシステムに置き換え、使うたびに性能が上がっていくAIシステムへと転換していく必要があります。企業内部の評価では、モデルが自社のビジネスにとっての重要な成果に対して、モデルが本当に改善しているのかを捉えるべきです(単なる外部のベンチマークではなく)。企業内部の強化学習環境は、社内の実際の業務データ(トレース)を使って、モデルを強化していくべきです。組織内に蓄積されてきた知見(institutional memory)がナレッジベース化されることで検索できるようになり、結果的にトークンの消費も節約できるようになります。

この学習ループは、企業にとって新しい知的財産になります。私はこれを「丘に登り続ける機械」のようなものだと考えています。そして、多くの資産とは異なり、このループは複利的に積みあがっていきます。業務フローが改善されるたびに、よりよいトレーニング信号が生まれ、それが企業固有の暗黙知の蓄積を加速します。これを早期に構築した企業は、どれほど新しいモデルが登場しても、他が簡単にはまねできないような優位性を持つことになります。

私たちが最も望まないのは、あらゆる業界の企業が、目にするすべてのものを飲み込む少数のモデルに価値を明け渡してしまうような世界です。もし、価値がほんの一握りのモデルに集中するなら、政治経済はそれを容認しません。産業全体を空洞化させるようなAIの未来に、社会的な許容は存在しないのです。

グローバル化の初期に何が起きたのかを思い出してみてください。アウトソーシングによって、産業経済が丸ごと空洞化しました。GDPの数字は表面上はよく見えても、雇用の喪失は現実であり、その影響はいまも続いています。私たちは、その構造をAI時代に持ち込むべきではありません。少数のAIシステムが経済的リターンを独占し、その一方で産業全体の知識が足元からコモディティ化されてしまうような未来を再び招いてはならないのです。

私の見解では、私たちが優先すべきなのは、単なるフロンティアモデルではなく、フロンティアエコシステムを構築することです。そうすることで価値があらゆる企業、産業、国へと広く行き渡るようになります。そこでは、すべての組織が自らの学習ループを持ち、その組織に蓄積された知見(institutional knowledge)をコード化し、人的資本とトークン資本が複利的に積みあがっていく仕組みを自分たちで所有できるようになるのです。

これは私の信条です。プラットフォームは内部で取り込む以上の価値を、その上に生み出せるものであるべきで、そしてすべての企業が継続的にイノベーションを起こし、自分たち自身で価値を築いていけるような世界であるべきだという考え方です。

それが実現すれば、企業は自社のためにも、周辺を取り巻く経済のためにも価値を生み出せるようになります。従業員は自らの専門性がAIによって拡張され、誰もが同じように判断できるようになり、その判断が組織全体に広がることを目にするでしょう。そしてその利益は企業や周辺のコミュニティに蓄積されていきます。

これこそが、企業が自社とより広い経済に価値をもたらす方法です。そしてそれが、私たちがともに築くべき安定した均衡状態なのです。

以下は、上記の内容をもとにChatGPTにインフォグラフィックを作ってもらいました。ご参考まで。

しばらくパブリック プレビューだった Microsoft 365 アーカイブ機能の「ファイル レベルのアーカイブ機能」がいよいよい GA です!

ここで改めてファイルレベルのアーカイブ機能について整理していきたいと思います。

📅ロールアウト

GA (World wide) は、2026年7月上旬からロールアウトが開始されます。ロールアウト完了見込みは 2026年7月下旬です。

概要

これまで Microsoft 365 アーカイブではサイト単位のアーカイブのみをサポートしていました。サイトのアーカイブは SharePoint 管理センターからテナントレベルの管理者が対応してきました。

今回のアップデートでは、新たにファイルレベルでのアーカイブができるようになりました。つまり、ユーザーによってドキュメントライブラリ内のファイルを個別に、低いコストのストレージに移動させることが可能になるのです。これにより「現状、まったく使っていないけれど、今後、使う可能性は否めないので削除はしたくない」といったファイルをアーカイブできるわけです。

Microsoft 365 Copilot (Premium) を持っている場合は、SharePoint 内のコンテンツをグラウンディングできますが、アーカイブされたファイルは グラウンディングから外れるため、古く間違った情報を誤ってCopilot が参照することがなくなります。

なお、引き続き検索は可能であり、検索結果の「ファイルの種類」でのフィルター項目から「アーカイブ済み」を選択することでアーカイブされているファイルも検索はできます。これはサイトをアーカイブしていても同様です。なお、検索結果からファイルを開こうとアーカイブされているため開くことはできず、再アクティブ化が必要になります。

ストレージコスト

ストレージ使用料はGB単位で月額で課金されますが、SharePoint のアクティブストレージとアーカイブストレージがテナントのストレージ容量の制限を超える場合にのみ課金されます。制限を超えない場合はアーカイブされたサイトおよびファイルに対しての追加のストレージコストは発生しません。再アクティブ化は無料です。

テナントの SharePoint のストレージ容量を超えた場合は、Microsoft 365 アーカイブでは、$0.05/GB/月 課金されます。アーカイブでない場合のテナントのクォータを超えたストレージ(Microsoft 365 SharePoint ストレージ)は、$0.20/GB/月となっています。つまり、GB単位で言えば単純に1/4のコストでストレージを利用できるということになります。

※教育機関はアーカイブされたデータに対して$0.02/GB/月で課金されます。

SharePoint で新しいストレージを追加購入してアクティブなまま使い続ける場合に比べるとアーカイブで使われるストレージコストは最大で75%まで抑えることができます。

Microsoft Purview のコンプライアンスとの関係

アーカイブされていても Microsoft Purview からは検索はできます。また、Microsoft Purview の保持や秘密度ラベルもそのまま利用できます。

Microsoft 365 アーカイブの設定

Microsoft 365 アーカイブの設定については次のリンク先を参照してください。

Microsoft 365 アーカイブを設定する - Microsoft 365 Archive | Microsoft Learn

操作

編集アクセス許可レベルを持つユーザーには SharePoint 上のコマンドバーなどに「アーカイブ」メニューが表示され、任意のファイルをアーカイブできます。ファイルはコールドストレージ層(Tier)にアーカイブされます。

編集アクセス許可レベルを持つユーザーには SharePoint 上のコマンドバーなどに「アーカイブ」メニューが表示され、任意のファイルをアーカイブできます。ファイルはコールドストレージ層(Tier)にアーカイブされます。

アーカイブされると、ファイルは表示できなくなります。

再びファイルにアクセスするには、再アクティブ化が必要であり、読み取りアクセス許可のあるユーザーは再アクティブ化が可能です。

再アクティブ化された場合、すべてのバージョンが復元されます。メタデータなどもそのまま維持されます。

先ほど述べた通り再アクティブ化には料金はかかりません。

[参考] 以前のブログにも Microsoft 365 アーカイブに関して触れています。ファイルレベルのアーカイブの挙動についてはビデオも公開しているのでご参考まで。

SharePoint Technical Notes : Microsoft 365 アーカイブ: ファイル レベルのアーカイブサポート

ファイルレベルのアーカイブ機能の制御

パブリックプレビュー時点では、ファイルレベルのアーカイブは PowerShellコマンドでテナントレベルのアーカイブを明示的に有効化する必要がありました。しかし、GA後はMicrosoft 365 アーカイブが有効になっている場合は、すべてのSharePoint サイトでファイルレベルのアーカイブは既定で有効になります。

ただし、GA後もSharePoint 管理者またはグローバル管理者は、SharePoint 管理シェルを使ってファイルレベルのアーカイブを有効または無効化にすることができます。SharePoint 管理シェルのバージョン16.0.26714.12000以降で利用できます。

サイトのアーカイブのみに限定する

ファイルレベルのアーカイブを無効化して、サイトアーカイブのみを利用できるようにしたい場合は、次のコマンドを使用します。 

Set-SPOTenant -AllowFileArchive $false

特定のサイトのみファイルレベルのアーカイブを許可する

サイト単位でファイルレベルのアーカイブを許可するかどうかは、Set-SOP-Siteコマンドの -AllowFileArchive プロパティを使って制御します。true だとファイルレベル アーカイブが利用できます。例えば、上記の Set-SPOTenant では-AllowFileArchive false にしておき、特定のサイトで true にします。

Set-SPOSite -Identity <site_url> -AllowFileArchive $true

新しいサイトの既定値を設定する

今後、新しく作成されるサイトでファイルレベルのアーカイブを制御する場合は Set-SPOTenant コマンドの -AllowFileArchiveOnNewSitesByDefault コマンドを使用します。これが true の場合は、ファイルレベルのアーカイブが有効になります。

Set-SPOTenant -AllowFileArchiveOnNewSitesByDefault $true

ファイル レベルのアーカイブのストレージの使用料を確認する

ファイルレベルのアーカイブの使用状況は Get-SPOSite コマンドの ArchivedFileDiskUsedプロパティで確認できます。バイト単位で示されます。

Get-SPOSite -Identity <site_url>

参考資料

• Microsoft 365 アーカイブを管理する - Microsoft 365 Archive | Microsoft Learn
• Microsoft 365 アーカイブについてよく寄せられる質問 - Microsoft 365 Archive | Microsoft Learn