カテゴリ「Microsoft 365 - SharePoint」の392件の投稿 Feed

2026年9月26日 (土)

SharePoint サイトはサイト単位でメタデータの総量が1TBまでという制限が設けられています。ただ通常はこのサイズに達することはまれであると Microsoft の資料にも書かれています。

SharePoint の制限 - Service Descriptions | Microsoft Learn

仮に、サイトのメタデータが1TBを超えてしまった場合は、新たな列などのメタデータを追加できなくなるとのことです。

SharePoint site metadata is at or near limit error message - SharePoint | Microsoft Learn

サイトのメタデータとは?

サイトのメタデータには何が含まれるのか確認してみると、次の情報が含まれるようです。ただ、あまり詳細なことはどのドキュメントにも書かれていません。

  • ファイルサイズ
  • 作成者
  • 作成日
  • ファイルのバージョン
  • リストの作成に関する情報など

書かれている内容から推測すると、ファイルごとに保持するファイルサイズや作成者、バージョン数などのシステムが持っているプロパティ値のことのようです。リストに関しては大雑把にしか書かれておらず、こちらも詳細はわかりません。ただ、そもそもこの上限は本来意識されるものではないが、ドキュメント数が相当に多いような状況で発生する課題であるということは間違いさそうでリストに関してはさほど影響をうけないため詳細に書かれていない可能性か高いのではないかと思います。

実際に上記のリンク先には一般的にはメタデータ容量を増やす主因は列の数ではなく、バージョンやコピーの増加にあると書かれています。

2026年記憶域メトリックスにもライブラリのメタデータのサイズが含まれるようになる

2026年9月にメッセージセンターにアナウンスされた内容によれば、サイトの記憶域メトリックス(Storage Metrics)ページのメタデータ計算にドキュメント ライブラリの列データも含まれるように改善されるようになるとのことです。

ロールアウト: 2026年10月20日~

20260926_000402

つまりは、ライブラリの列のデータは実際には計算には含まれていなかったということでしょう。そのためサイトによってはメタデータが急に増加することになる可能性があるとも言えます。

そもそも「記憶域メトリックス」にはサイトのメタデータが含まれていたということはこれまで意識したことがなかったので、今後は意識して確認する必要がありそうです。

ただ、それでも現在のサイトのメタデータが現在何GBであるかを常時確認できる仕組みはなく、1TBの制限の80%に近づくとサイトの記憶域メトリックスにメタデータサイズの内訳を表示する方針になっているようです。ですから、80%を超えない限りは現状のサイズはわからないということです。

ちなみに、まれではあるとはいえ、もし超えてしまった場合は、次のようにメタデータ利用率を確認して減らす必要があると書かれています。

  • 不要なアイテムをリストやドキュメント ライブラリから削除する
  • ドキュメント ライブラリの古いバージョンを削除する
  • リストやライブラリで重複するファイルは削除する
  • 警告メッセージが提供する内容に従って処理する
  • 変更したら再び記憶域メトリックスを確認する

80%に近づくもしくは達した場合、SharePointは警告やエラーメッセージをサイトの所有者やユーザーが受け取ることになるということですが、サイトの上部などに表示されるのかはスクリーンショットもないため不明です。

なんらかの方法で警告やエラーに遭遇したら記憶域メトリックスを確認して、無駄に重複しているファイルがあれば削除したり、ファイルのバージョン数が多いところなどはバージョン履歴の一部を削除するなど対応をとり、再び記憶域メトリックスを確認して、減り具合を見るようにしてほしいということですが。それでも気になるのはこのメトリックスに表示される数は本来リアルタイムではないので、案外時間をかけて対応することになるのではないかということです。80%を超えたら、割と即座に容量情報に反映されるのか、そのあたりも気のなるところですが詳細は不明です。

記憶域メトリックスに関するおさらい

さて、ここで記憶域メトリックスに関しておさらいします。ちなみに、記憶域メトリックスは英語では Storage Metrics です。

記憶域メトリックスにアクセスできるのはサイトの管理者(旧サイトコレクションの管理者)です。サイトの設定ページから「サイトコレクションの管理」セクションにある「記憶域メトリックス」にアクセスします。

URLは次の通りです。

https://<サイトのURL>/_layouts/15/storman.aspx

記憶域メトリックスにはごみ箱のコンテンツは含まれません。

2026年9月 8日 (火)

2016年にクラウドから生まれたユーザーエクスペリエンスであるモダンなSharePointと開発者の拡張性フレームワークであるSharePoint Frameworkが初めて導入されました。その際にこれまでの発行機能やUXの拡張性は “クラシック” と名前を変えました。

それから10年後の今年、クラシック機能は毎月のアクティブ テナントをベースにすると利用状況を見ると5パーセントを下回る利用状況になっているそうです。またクラシックページではMicrosoft 365 Copilot の性能を十分には発揮できない状況にあります。

こうした背景からMicrosoft は今後2年をかけて、クラシックな SharePoint ページとカスタムスクリプトの追加や更新機能を Microsoft 365 の SharePointから廃止することになったようです。

対象となるページは次の通りです。

  • Wikiページ
  • Webパーツページ
  • ブログページ
  • 発行ページ
  • カスタムのASPXページ

これらは最終的には新規の作成できなくなるだけでなく、既存のページは読み取り専用になります。ただ、Microsoft がコンテンツを削除するといったことはありません。

🎯2段階のフェーズによる廃止

廃止は2段階で行われます。

📅第1フェーズ: 2027年3月1日~

すべてのテナントで新規にクラシックな発行サイトを作成したりクラシックな発行機能をアクティブ化することができなくなります。

2027年3月1日以降に作成される新規テナントについて

2027年3月1日以降に作成される新規テナントでは、最初から新規にクラシックページを作成することはできなくなります。カスタムスクリプトの追加や更新機能は既定で無効化されています。ただし、この設定はモダンな SharePoint ページやSPFx ベースのカスタムソリューションには影響しません。これらは既存の組織のガバナンスかで引き続き動作します。

📅第2フェーズ: 2028年10月1日~

すべてのテナントに変更が拡大適用されます。

  • クラシックなユーザー作成ページ(Wikiページ, Webパーツページ, ブログページ, 発行ページ, カスタムのASPXページ)は読み取り専用になります。
  • 新規作成および編集はできなくなります。
  • カスタムスクリプトの追加や更新は無効化されます。

まとめ&関連情報

モダンサイトが投入されてもう10年もたつのですね。その間にパンデミックが起きたり、生成AIが登場したりと目まぐるしい環境の変化がありました。

そんな中、クラシックサイトの利用はかなり少なくなっているようですね。とはいえ、まだクラシックページを利用している組織は、クラシックページの新規作成は控えてSharePointサイトページ(モダンページ)を利用するようにしておく必要があるでしょう。モダンページでは柔軟なセクションも導入され、テキストWebパーツも使い勝手が上がっていたり、クラシックページにはなかった機能が豊富に用意されています。必要があればモダンページで新規にコンテンツを作りなおすというのも考え方の一つだと思います。

クラシックページとサブサイト構成をいまだに利用しているのであれば、モダンサイトベースで社内ポータルを再設計する好機だともとらえられるかもしれません。 Microsfot 365 Copilot の利活用においてはデータ整備が重要であり、ガバナンスも見直す必要がありますが、この時サブサイトがあると設計の難易度は上がります。

ただ、既存の クラシックなSharePointページをベースに作り込みをしている場合は、対応に追われてしまう可能性が高く、きちんと情報収集の上、早めの対応が大切ですね。案外、2年はあっという間です。既存ページをツールを使ってモダンエクスペリエンスへの変換するアプローチもあります。詳しくは下記のリンク先を参照してください。

2026年7月31日 (金)

Copilot in SharePoint の2026年7月のアップデート情報が公開されています。

What’s New in Copilot in SharePoint: July 2026 | Microsoft Community Hub

よく読みこみ、これまでの経緯なども知らないと読み取れないところもあるため、補足しながら説明していきます。

量が多く、長くなるので、お手すきの時に読み進めてください。

自然言語を使ってコンテンツを作成する

Copilot に依頼することでSharePoint 内のコンテンツから Word ドキュメント、Excel ワークブック、PowerPoint スライドを直接作成できるようになりました。

これによりサイト内にあるナレッジをコピー&ペーストすることなく数分で共有できる状態に仕上げられます。たとえば、プログラムマネージャーはプロジェクトサイトのメモをリーダーシップレビュー前に最初のトラフト状態のスライドとして作成できるようになりました。

実際に手元の環境で再現しました。次のようなプロジェクト情報をまとめたサイトを作成しています。

このサイトの情報をもとに経営層向けのスライドを作成するようにプロンプトで指示します。

次のビデオでわかるようにCopilot はプロンプトの指示に従い、サイト内の情報からスライドを作成します。スライド内ではタスク数が "11" となっていますが、タスク一覧にある完了件数である “4” と、SharePoint ページに記載しているマイルストーン表の完了件数の “7” を加えて集計していることがわかります。またWordファイルの議事録内容からもきちんと情報が取得できています。

インタラクティブなHTMLレポートを作成する

SharePoint に格納されているコンテンツからインタラクティブなHTMLレポートを生成できます。ちょっとしたものであれば Power BI を使わなくても ExcelまたはSharePointリスト と SharePoint のHTMLレポート作成機能で対応できそうです。ちなみに、これまでも HTMLファイルは SharePoint のドキュメント ライブラリにアップロードはできましたが、ブラウザー上で直接見ることはできず、ブラウザーで見るようにするためにはカスタムスクリプトの実行の有効化が必要でしたが、今回の機能はそういった設定は不要で SharePoint にビルトインのビューアーで表示できます。

20260730_000914

ここでも実際に試しています。次のようなExcelファイルを用意し SharePoint サイトに格納しました。

20260731_212937

このファイルをもとに次のプロンプトでHTMLページを作成します。

このファイル内の今四半期の売上実績データ [ 売上サンプルデータ.xlsx ] を使って、インタラクティブなダッシュボードを作成してください。
含める内容:
・総売上
・目標達成率
・実績が最も高い地域/最も低い地域
・売上の時系列推移(月別トレンド)
地域・製品で絞り込めるフィルターを追加し、経営層向けのレビューに使える見た目・構成にしてください。

これでドキュメントライブラリにインタラクティブなHTMLが生成できます。実際の操作ビデオはX(旧Twitter)で共有しているので、下記に貼っておきます。

ファイルやフォルダーの整理

ドキュメント ライブラリ内のファイルをチャットのやり取りから整理できるようになります。もともと、OneDrive に投入予定の機能でしたが、SharePoint のドキュメント ライブラリに実装されたようです。

フォルダー構造の功罪

弊社ではSharePoint サイトのドキュメントライブラリは、"なるべくなら" フォルダーのみでのファイル整理は避けた方がいいというアドバイスを常々しています。フォルダーを作る前に複数のライブラリに分けること。そのうえで、メタデータを設定して、グループ化表示で対応できるかどうか。うまくいかないようなら、フォルダーを作成するが1階層から2階層程度までといった具合です。

とはいえ、Teamsに接続されている SharePoint のチームサイトなどは既定では1つのドキュメントライブラリのみがTeams のチームに紐づくようになっているため、ファイルの仕分けはどうしても1ライブラリ内でフォルダーを使うことになりがちです。そうした場合に、ファイルを整理するのにはこの機能は使えそうです。

ただ、すでに大量にファイルが格納されている場合は、これらを新しいフォルダー構成に移動することになるため、決まった格納場所を覚えているユーザーにとっては探しにくくなる可能性が高くなります。むろん、検索機能などを使えば見つけられはしますが、こうした整理はちらかり始めた初期の段階で取り組んでいくのがよさそうです。

OneDrive 内でのフォルダー整理機能が未実装な理由を考察する

現在、OneDrive 内ではCopilot を使ったフォルダーの整理はできません。未サポートです。
それでも実際にOneDrive内で Copilot によるフォルダー整理を無理やり試すと、フォルダーの構成案を考えて作成までできますが、肝心な移動は日本語フォルダー名だとうまくいかなかったり大量のファイルがあると少しずつしか移動できないなど、問題が見つかります。もちろん、もともと未サポートですから運用環境では試さないようにしてください。

しかし、そもそもOneDrive に先に追加される予定の機能が未実装なのはなぜか? という疑問が残ります。

ここからは憶測です。OneDrive の場合は様々なアプリやPower Automate フローなどが決まったフォルダーを作成してそこに成果物を作成するようになっています。Loop, Whiteboard, Copilot Cowork のスキルなどもそうです。そのため、チャットによりフォルダー階層を変更する場合、これらのアプリが影響を受ける可能性があるため、そこが課題になっているのではないかと考えています。

ファイル共有

Copilot チャットから特定のファイルを特定のユーザーと共有できます。

作成するリンクは共有リンクではなく、固有のアクセス権を付与してURLを共有します。

承認の構成

Copilot にライブラリに対して承認を構成するよう依頼できます。ビューの作成も依頼できるので、レビュー段階に応じたトラッキング用のビューなども手軽に作成できます。また、承認期限の切れたコンテンツや次の対処に関する提案なども依頼できます。

次のビデオでは、承認の構成を行った後、ビデオ内では省略していますが、承認や却下をいくつかのファイルに対して行っています。その後、次のプロンプトを指定しています。

承認期限を過ぎた案件や、レビュー・承認が途中で止まっている案件を強調表示し、対応策を提案してください。

ルールやクイックステップの作成

Copilot に指示することで、コンテンツやメタデータが変更された際にシンプルなメールを送信するルールを作成できます。

ただし、あくまでも指定できるのは SharePoint のビルトインの機能を使える範囲です。

例えば、ルールの場合、「レビュー日の5日前にファイルの所有者にリマンドメールを送信して」とは指示できますが「5営業日前」までに送る指定はできません。また、送信先は「ルール」ではファイルの「登録者」や「更新者」などのシステム列は指定できないため、基本的には固定のメールアドレスを利用するか、別途、「ユーザーとグループ」列を使って新規に「ドキュメントの所有者」列などを指定しておき、この列をメール送信先に使う必要があります。

Copilot in SharePoint を使ってルールを作成する

Copilot in SharePoint を使ってクイックステップ列を追加する

スキルの作成と利用

現在、SharePoint には複数のビルトインのスキルが用意されています。カスタムスキルを作る create-skills や SharePoint.md を作る init 、ルールやクイックステップ及び承認の構成などをする automateなどいくつかあります。複数のスキルを組み合わせた Plan をすれば、複数のスキルを連続的に呼び出して複雑な処理を行うオーケストレーションも可能になっています。

ここで、サイトのビルトインのスキルについて補足しておきましょう。

SharePoint には次のビルトインのスキルが用意されています。これは /Skills コマンドを実行すると確認できます。

20260731_162348

各ビルトインのスキルは次の通りです。

 Built-in Skills

Skill 説明
automation

Quick Steps、Approvals、Workflows、Rules、Audits に関する要求を処理します。

自動化の検討、適切な仕組みの選択、通知、承認、ワンクリック操作、定期実行やイベントを契機とした処理、ルールやワークフローのレビューに利用します。

自動処理には Workflows を優先して使用し、Rules の利用は最後の選択肢としてください。

check-skills

スキル管理と品質評価を担当するスキルです。

サイト内のスキルを分析し、スキル選択の適切性、プロンプトや説明文によるトークン使用量、リンク切れや無効な参照、ツール名の不整合、重複スキル、類似した目的を持つスキルを検出してレポートします。

スキル ライブラリの棚卸し、重複排除、統合候補の検討、運用品質や信頼性の評価に利用できます。

分析結果の報告のみを行い、スキルの変更や削除は実施しません。

create-skill ユーザーが、手順、フォーマット、または定型的な作業パターンを新しいスキルとして登録したい場合に使用します。
init

SHAREPOINT.md の作成・更新を支援するスキルです。

サイト内のライブラリ、リスト、ページ、およびサイトの用途を分析し、エージェントが利用するサイト コンテキスト ファイル (SHAREPOINT.md) を生成または更新します。サイトの初期導入時や情報構造の変更後に利用できます。

SharePoint.md ファイルの作成と更新 (init)

対話によってサイトのスキル(SharePoint.md)を作成する際に、利用されます。サイトのエージェント アセットライブラリに既存の SharePoint.md があれば更新し、なければ新規に作成します。

20260731_160155

SharePoint.md は、サイトごとに用意する「Copilot 向けの説明書」です。Copilot がこのサイトで回答したり、ページや資料の作成を手伝ったりするときに、サイトの目的・用語・判断基準を理解するために参照します。

ポイントは、人が知っている前提や運用ルールを書くことです。なるべくフォルダーは使わわず、メタデータを利用することとか、どういうファイルをどのライブラリにしまうのかといったルールも書けます。これに従って Copilotはライブラリ構成やファイル管理の仕組みを考えてくれます。また、コーポレートカラーの指定しておけば、インタラクティブHTMLなどを生成するときのペースカラーとして使ってくれます。

Skill.md との違い

SharePoint.md は「このサイトについて知っておくべきこと」を書く場所で、Skill.md は「特定の作業をどう進めるか」を書く場所です。

両方がある場合は、まず SharePoint.md でサイト全体の前提を理解し、そのうえで必要な作業に対応する Skill.md を読み込む、という順番で考えると自然です。つまり、SharePoint.md が「このサイトでは何を大切にするか」を先に決め、Skill.md が「その前提でどう作業するか」を具体化します。

SharePoint.md は基本的にサイトに1つです。一方で Skill.md はタスクごとに複数作成できます。たとえば、提案書作成用、FAQ作成用、レビュー用、ページ作成用のように、作業の種類ごとに分けておくと使いやすくなります。

項目 SharePoint.md Skill.md
役割 サイトの前提・目的・用語・判断基準を伝える 作業手順や振る舞いを定義する
対象 サイト全体 特定のタスクや業務フロー
例 正式情報の場所、命名規則、コーポレートカラーの使いどころ 提案書を作る手順、レビュー観点、出力形式
更新タイミング サイトの目的や運用ルールが変わったとき 作業プロセスや成果物の作り方が変わったとき

迷ったときは、知識なら SharePoint.md、手順なら Skill.md と考えるとわかりやすいでしょう。

Designer_17

サイトのエージェント アセットライブラリ

SharePoint.md を作成するには、最初にサイトコレクションの機能の「エージェントのアセットライブラリ」のアクティブ化が必要です。これを行っていないと、カスタムスキルを格納するエージェント アセットライブラリが作られません。

20260731_215533

エージェント アセットライブラリは次のように Skills と Plans フォルダーか用意されています。SharePoint.mdは既定では作成されませんが、作成するとエージェント アセット ライブラリの直下に SharePoint.mdは作成されます。

20260731_161601

フォルダーの内容は次の通りです。

フォルダー 格納される内容 役割
Skills SKILL.md 個別の再利用可能な処理単位(1つのタスクの手順)
Plans オーケストレーション定義 複数の Skill やステップを組み合わせたワークフロー定義

スキルの作成 (create-skills)

スキル作成を依頼すると create-skills によってカスタム スキル(Skill.md) が作成されます。

20260731_162918

スキルの品質を監視する (check-skills)

公式ドキュメントにはまだ情報がないのですが、直接、Copilot in SharePoint で確認すると以下の通りだそう。

check-skills は、サイト内のスキル品質を監査するためのビルトインスキルです。

主に確認する内容は次の4つです。

  • 選択されやすさ: 具体的な利用例・トリガー文があるか
  • サイズ: SKILL.md が大きすぎないか
  • リンク切れ: references/ などの参照ファイルが存在するか
  • ツール指定: 手順内で使うツール名が明確か

さらに、複数スキルの役割が重複していないかも確認します。要するに、スキルが「ちゃんと呼ばれる・壊れない・運用しやすい」状態かを点検するものです。

通常はCopilot が必要に応じて内部的に使うけれど、明示的に呼ぶのは、たとえば「このサイトのスキルを監査して」「check-skills を実行して」のように依頼したい時だけです。

よりクリアで信頼できるチャット エクスペリエンス

2026年7月の更新では、回答の読みやすさ・検証しやすさ・信頼性が向上しています。

  • 引用がより簡潔で、クリックして元情報を確認できます。
  • チャットに秘密度ラベルが表示され、過度な共有を防ぎます。
  • リンクが正しく整形され、すべてクリック可能になりました。
  • 推論モデルでは、回答に至る思考過程(チェーン・オブ・ソート)を表示できます。

信頼できるという意味では、これまでよりもより賢く振る舞うようになっています。たとえば、ファイルの本文まはたメタデータに「下書き」や「承認済み」が含まれていた場合でそれぞれに書かれている製品の価格が異なっていたとします。この時、優先するのは「承認済み」と書かれているドキュメントであり、単に金額を示すだけでなく、根拠として承認済みと書かれていたためという引用まで記載してくれます。

20260729_111603

そのためこうした情報の正確さを図れるようなステータスなど指標があれば、内容の異なる複数のファイルを一覧して、比較することもできます。

Copilot ボタンで素早く始める

1-click Q&A

SharePoint サイト内に表示される Copilot ボタンから素早く質問ができるようになっています。質問するのにフルペインを表示する必要がありません。

Helpful nudges

Agent Builder や Copilot Studio ではおなじみのスタータープロンプト(推奨プロンプト)がCopilot ボタンに表示されるようになったため、Copilot in SharePoint を初めて使う今アクセスしているページやリスト, ライブラリなどで行える操作をイメージしやすくなっています。

20260731_192610_2

--about コマンド

現在使っているAIモデルとそのバージョンを確認できます。

右のスクリーンショットでは、2026年7月31日時点では、AIモデルが GPT-5.5 reasoning モデルであることがわかります。

20260731_173758

管理者とサイト所有者のために

現在 Copilot in SharePoint は ワンモデル プロバイダー(One model provider) となっています。以前の AI in SharePoint は Claude ベースであり、Claude が利用できない組織では GPT にフォールバックすることもありました。ですが、現在は、最新の OpenAIモデル上で動作しており、モデルのフォールバックはありません。

これにより高品質な回答が得られ、また管理も容易になったということです。

またCopilot ボタンはサイトごとに表示・非表示できるようになっています。これはサイトの歯車アイコンから 「サイトAI」 にアクセスすることでトグルメニューから切り替えられます。

20260731_194810

最後に

以上が、2026年7月の Copilot in SharePoint に関する最新情報でした。

現在、SharePoint では以前から利用できているオートフィル列は非常に高速に処理できるようになっており、ドキュメントからメタデータを素早く抽出できるようになっています。またリストやライブラリも Copilot に作成してもらえます。

SharePoint のサイトの設計を効率よく行い、基本操作を知っていれば、自分で操作しなくても Copilot と相談しながら作業も依頼できますし、ドキュメントも生成してくれます。しかも、既存の SharePoint サイト内のコンテンツを使い Work IQの恩恵も受けつつです。

やりたいことはあるけど、操作は外注に依頼するというようなスタイルはもはや成り立たず、自分たちの業務にフィットする形を Copilot とともに自分たちで作り上げて時代になりました。とはいえ、Copilot も全知全能では当然なく、ときには適さない提案をしてくることもあります。そこは人が介入して、「そうではない、こうしたほうがいいと思う」というディスカッションを重ねていく必要があります。引き続き SharePoint の基本機能やよりよいサイト設計のありようをしっかりと把握したうえでデータ基盤を整えていく必要はあります。新機能をキャッチアップするといった「製品学習」は必要です。

しかし、これらがそろえば、実現したいことに思考を集中できるというのは非常にありがたく、生産性は非常に向上するといえます。うまく活用したいですね。

2026年7月 3日 (金)

Microsoft_365_sharepoint_no3

2026年6月30日に Microsoft 365 SharePoint 勉強会を行いました。

Microsoft 365 SharePoint 勉強会 #3 - connpass

1時間ほどのセミナー形式であるため、デモを中心に SharePoint の最近のアップデートから厳選して興味深いものなどを選びました。特に Copilot in SharePoint は進化のスピードが目覚ましく、この部分に興味を持った方が多かった印象です。

あとは、管理面ではファイルレベルでのアーカイブ機能やファイルレベルでのバックアップからの復元なども比較的関心が高かったようです。

X(旧twitter)における「SharePoint はファイルサーバーではない」という議論について

当勉強会では冒頭付近で、これまでも常に同じ論調で話をしてきているんですが単に「SharePoint をファイルサーバーとはとらえないでほしい」という趣旨で「SharePoint はファイルサーバーではない」という話をしています。ただ、この部分のみが X で独り歩きして、一部においてはネガティブな意見に取られてしまったようです。ただ、録画を見ていただくとわかりますが、コンテンツ管理システムとして捉えてほしいし、そもそもコンテンツ管理システムってなんだろう?というところに興味を持ってほしいという趣旨で説明していますので、その点はご承知おきください。

次回以降について

不定期ですが、今のところ、また開催していこうとは思っておりますので、時間のご都合が合えば、ぜひリアルタイムでご参加ください。

録画


YouTube: 第3回 Microsoft 365 SharePoint 勉強会の録画公開: 25周年を迎えた SharePoint の最新情報を整理しよう

スライド

スライドにはいくらか情報を追記しています。

2026年7月 2日 (木)

組織における SharePoint ストレージの管理をより柔軟にし、過剰な容量確保を回避するために、Microsoft が SharePoint ストレージの超過分に対して従量課金(Pay-as-you-go)モデルを導入します。

このオプションによりテナントの容量を超えて使用したストレージ容量分のみを課金対象とし、事前に余分な容量を購入する必要がなくなります。 Microsoft 365 アーカイブと組み合わせることで柔軟なストレージ管理ができるようになります。

[参考]

SharePoint Technical Notes : Microsoft 365 アーカイブ: ファイルレベルアーカイブがGA

従来通り、追加ストレージを購入することも可能であり、従量課金ベースとどちらの方が適しているのか評価する必要があります。

有効化すると請求は自動的に行われます。この機能はオプトインであり、既定ではオフです。

ロールアウト

  • パブリックプレビュー: 2026年6月上旬~6月中旬
  • GA: 2026年9月~10月末まで

※現時点では教育機関向けテナントではこの機能は利用できません。

ストレージを追加するための条件

従量課金モデルを使用するには次の条件を満たす必要があります。

  • Azure サブスクリプションとリソースグループが必要
  • Azure サブスクリプションの所有者ロールまたは共同者ロールと、同じ Azure サブスクリプションにリンクされているリソースグループが必要

従量課金を有効化する

従量課金を有効化する場合は、最初に請求ポリシーを作成しておきます。

Microsoft 365 管理センターから[課金情報]>[従量課金制]にアクセスし、課金ポリシータブから請求ポリシーを追加します。

20260702_194712

20260702_194400

ポリシーが作成できたら、「サービス」タブをクリックします。

20260702_195025

「Microsfot 365 SharePoint ストレージ」の “ポリシーを接続する” をクリックし、設定を保存します。

20260702_195111

参考情報

OneDrive と SharePoint ストレージ容量をさらに購入する | Microsoft Learn