2025年2月

2025年2月25日 (火)

205年4月10日~2025年9月末にかけて、OneDrive for Business ごとのルートサイトと既定のドキュメント ライブラリから「外部ユーザー以外のすべてのユーザー」のアクセス許可が見つかれば削除される機能がロールアウトされる機能がロールアウトされます。過剰共有を防ぐための施策の一環です。

20250225_071925

外部ユーザー以外のすべてのユーザーという特殊グループ以外にも、もともとはEveryone, All Authenticated Users, All Users グループに関しても利用はできるものの、現在利用は推奨しておらず、Entra ID 側でユーザー定義グループをキチンと作成してロールベースのアクセス管理をするように勧められています。詳しくは次のリンク先を参照してください。

Microsoft 365 で Everyone 要求を外部ユーザーに付与する - Microsoft 365 | Microsoft Learn

ちなみに、Everyone, All Authenticated Users に関しては、以前は外部ユーザーが含まれていましたが、2018年3月23日以降、既定では外部ユーザーが含まれなくなっています。ただし、必要に応じて管理者が PowerShellコマンドにより再び、これらのグループにアクセス権を付与することもできます。詳しくは次のリンク先を参照してください。

Microsoft 365 で Everyone 要求を外部ユーザーに付与する - Microsoft 365 | Microsoft Learn

さて、用語について少し補足説明しておきましょう。ルートサイト既定のドキュメント ライブラリという2つについてです。

ルートサイト

OneDrive for Businessは個人ごとに割り当てられる特殊な SharePoint サイトとなっており、以前はこのサイトを起点に、入れ子の階層構造としてサブサイトを作成することもできました。古くはブログのサイトテンプレートがあり、これをサブサイトとして作成したりもしていました。

現在、ほとんどはサブサイトを作成しないでしょう。ということで既定で用意されている OneDrive for Business自体はルートサイトとなるわけです。ところで、OneDrive for Busines のルートサイトを共有しようと思えば、例えば、次のクラシックな管理画面から SharePoint サイトと同じく設定できます。

https://<onedriveのURL>/_layouts/15/user.aspx

20250225_205020

ですから、たとえば、ここに「外部ユーザー以外のすべてのユーザー」特殊グループが追加されていたら、検知して削除するよという話です。

ただし、OneDriveは個人の領域なので、OneDrive for Businessという個人のサイト全体を組織の全員に対して丸ごと共有する運用は個人的にはお勧めしません。ですから確かにこれは過剰共有といえるため納得の措置です。そもそも既定では所有者のユーザーのみがサイト管理者およびフルコントロール権限を持ちます。王道的な使い方なら、フォルダーやファイル単位で共有リンクを使って共有するのが一般的です。しかも昨年から、社内向けの共有リンクにも有効期限が指定できるようになったので、こうしたものを活用して極力過剰共有しないようにすべきです。

既定のドキュメント ライブラリ

さて、もう一つについて。既定のドキュメント ライブラリと書かれていますが、これも OneDrive の「マイファイル」からアクセスしているもののことで、ここが既定のドキュメント ライブラリです。既定のドキュメント ライブラリ以外も、やろうと思えば新規にライブラリを追加できます。単なる SharePoint サイトだからです。ただ、使い勝手も悪いので通常は行いません。参考までに追加のライブラリは、たとえば、次のURLから「サイトのライブラリとリスト」にアクセスすることで新規に作成できます。

https://<onedriveのurl>/_layouts/15/settings.aspx

20250225_203638

20250225_203739

つまり、このように独自に追加したライブラリは対象外だということです。

ということで、あくまでも既定のライブラリ自体にアクセス権限を「外部ユーザー以外のすべてのユーザー」に対して付与していると、これも検知して削除するということ。

とまぁ、ここまでの内容を確認するとそれはそうだなという感じですね。ユーザーが日頃から利用する OneDrive の中身が全社員に丸見えだということになりますから。有償版の Microsoft 365 Copilot など使うと、共有しているつもりはなくても実は組織内全体から丸見えになっているコンテンツは当然、生成AI によっても再利用されることになるため、過剰共有対策は急務といえます。

ということでOneDriveのルートWebと既定のドキュメントライブラリに存在する「外部ユーザー以外のすべてのユーザー」の許可が削除されると、アプリ、プロセス、ユーザーは影響を受けるOneDriveアカウントのコンテンツにアクセスできなくなってしまうわけです。こうしたユーザーのコンテンツが組織全体に丸見えになっているようなケースがどれほど多いかわかりませんが、ユーザーに知らせて該当しそうなものがあれば、早急に見直しをしておくに越したことはありません。

ただし、特定のファイルやフォルダーに直接許可が与えられているユーザー、プロセス、アプリは影響を受けません。これまで通り、ファイルやフォルダー単位で共有リンクを作っているような場合はもんだなく使えるということです。ただ、やはり「外部ユーザー以外のすべてのユーザー」は使わないようにするのが望ましいといえます。

EEEU って何? 

ちなみに、「外部ユーザー以外のすべてのユーザー」とは長い名前のグループ名ですね。英語でも "Everyone Except External Users" と長いので、英語では略して EEEU となっています。 

2025年2月13日 (木)

Adobestock_53318819

クラウドフローのトリガーにはプッシュトリガーとポーリングトリガーがあることをご存じの方も多いと思います。今回はこのポーリングトリガーがモダンデザイナーとクラシックデザイナーを使う場合とで違いがあるという話です。

が、トリガーの種類を知らない方もいるでしょうから、少し整理しておきましょう。

軽くおさらい

プッシュトリガーは、人の手で直接フローを開始するのでフローの開始のタイミングがはっきりしています。こうしたフローは即時実行されます。Forms コネクターのトリガはブッシュトリガーです。

一方のポーリングトリガーは、「ファイルが更新されたとき」や「アイテムが追加されたとき」など、人の手で直接はフローを開始しないタイプのトリガーです。Power Automate のフローは、これらのトリガーが利用されている場合、指定されたライブラリやリストを定期的にチェックし、変更が見つかったときにフローを開始します。

ポーリングトリガーはもともと実行間隔がライセンスによって違っていました。

プラン 実行間隔
無料 15分
Office 365 用フロー / Dynamics 365 用フロー 5分
プレミアムプラン 1分

クラシックデザイナーとモダンデザイナーでの挙動の違い

モダンデザイナーで自動開始のトリガーを利用する場合は、ポーリングトリガータイプのものはユーザーのライセンスに関わらず、既定では実行間隔が1分になっています。たとえば、SharePoint コネクターの「項目が作成されたとき」のトリガーを確認してみると、次の通り1分です。

20250213_183628

ですが、クラシックデザイナーの場合は最初からクラシックデザイナーに切り替えて、同じトリガーを配置してみるとコードビュー上では interval が5分となっているのがわかります。ちなみに、プレミアムプランを持っているユーザーが作成するとクラシックでも1分です。

20250213_183852

つまり、プレミアムライセンスを持たないユーザーは、モダンデザイナーを使ってフローを作った方が実行が早まるということです。

ということで実験してみました。同じリストに対して2つのフローを作成します。どちらも「項目が作成されたら」フローが動作するようにトリガーをしかけて、メールを送信します。違うのは最初からモダンデザイナーで作成しているのか、クラシックデザイナーで作成しているのかです。

アイテムを新規に追加してみます。すると、先に動いたのはやはりモダンデザイナーで作成した方で、アイテム作成日時とメールの受信日時を比較してみると確かに1分ほどになっています。20250213_213605

しばらくするとクラッシクデザイナーで作成したフローが動きメールが送信されます。メールの受信日時を見るとおよそ5分違います。

20250213_213842

ちなみに、このブログではモダンデザイナーと呼んでいますが、Microsoft Learn をもとにすると単に「クラウドフロー デザイナー」と呼んでいて、古いデザイナーを「クラッシク デザイナー」と呼んで区別しています。※新しいデザイナー画面になったときには、最新のものを便宜的にモダンデザイナーと呼んでいたようです。

将来的にはこのモダンデザイナーのみになる予定で、クラシックデザイナーは廃止される予定ですが、現時点(2024年2月13日に確認している時点)ではすべての機能が移管しきれていないので、もうしばらくはクラシックデザイナーが残りそうです。

2025年2月10日 (月)

今回は四方山話。日頃、思っていることを書き留めておこうと思っただけで。テクニカルな話ではないので、何かスキルが身につくわけではないのですけれど、長くなりましたし、お暇なときにでも。

数年前に SharePoint ホームサイトが登場した。いつだったかは記憶が定かではないが拙書の「ひと目でわかる Microsoft 365 運用管理編」でも取り上げているので、2020年あたりだったと思う。この SharePoint のホームサイトというのは、組織内のユーザーが日々、最初にアクセスすることを想定したランディングサイト(Landing site)である。従来は SharePoint スタートページが SharePoint ホームと呼ばれていた(ホームサイトではなくホームページ)。Microsoft 365 アプリ起動メニューから SharePoint をクリックするとたどり着くページのことだ。ユーザーはこのページに最初にアクセスし、自分が関わるサイト全体を俯瞰し、自分が関わるニュースを一覧する。そういう場所であった。ただ、このページはカスタマイズすることができず、長年ユーザーからは組織ごとにカスタマイズさせてほしいという要望が出ていた。そこで登場したのが SharePoint ホームサイトだった。これは別途、コミュニケーションサイトのテンプレートをベースに組織ごとに好きなように従来通りサイトを作成し、これをユーザーのランディングサイトとして使うというもの。このサイトが登場することで、従来の SharePoint ホームは SharePoint スタートページへと名前を変えることになった。

さて、この SharePoint ホームサイトだが、組織ごとに自由に作っていいといわれても何かしらの指針は欲しいものだ。そこで Microsoft が当初、デモンストレーションしながら盛んに説明していたのが、パーソナライズされたサイトだ。ユーザーごとに必要な情報のニーズが異なるため、主にAI を使って、TeamsやYammer (現在の Viva Engage) に散らばる情報も含めて情報を拾い集めて、そのユーザーにかかわりが強い情報を集約表示するというものだった。ポータルのホーム画面にはViva Connections Webパーツや マイフィード Webパーツを配置。ニュースWebパーツもソースを「現在のユーザーへのおすすめ」に設定するなどして、とにかく、従来の最小公倍数的な情報の見せ方ではなく、「あなたにとって重要な情報を素早く提供しよう」というコンシェルジュ的なサービス提供を考えていたわけだ。

余談だが SharePoint ホームサイトから検索すると SharePoint スタートページと同様にサイトコレクションを横断する検索となる。また、ハブサイトや単独サイト間を行ったり来たりするための橋渡しとなる「グローバルナビゲーション」も構成できるし、Viva Connnections との密接な関係があるため Viva Connections ダッシュボードも利用できようになる。Viva Connections を使うと Teams アプリとして実装でき、Teams 内から素早く SharePointサイトにアクセスできる。"Connections" とああるのは文字通り "情報の間をつなぐ" という意味合いである。

そもそも SharePoint ホームはこの機能を発表した当初は英語では SharePoint Homes となっていて、複数形だった。日本語の言語体系では複数形の概念が希薄なため、翻訳するとこの言葉の意味が薄れてしまって本質に気づきにくなる。つまり、もともとは組織内では複数のホームサイトを作成できるようにする予定だったのだが、GA当初はテナント内で1つしか設定できなかった。これが時を経て、Viva スイートなどの追加ライセンスを持っている組織だと組織内で複数のホームサイトが持てるようになり、設定画面も Microsoft 365 管理センターの Viva Connections に移管された。それまでは、SharePoint 管理センターから設定できていた。

さて、話を戻そう。コロナ禍になる直前の2019年ごろ、 SharePoint の開発チームがSharePoint の目標として掲げていたのが、「業務に必要な情報が SharePoint サイトに行けば入手できる」ということ。業務を遂行する上で「次に何をしよう?」と思ったら SharePoint にアクセスして情報を得てもらおうということ。そのうえで、先ほど述べたように組織全員の最小公倍数的に発信される情報から自分に必要な情報を見つけ出していくのではなく、 SharePoint ホームサイトの構想はサイトに行けばすぐログインしているユーザーに特化した情報が見つかるような仕掛けづくりをしようとしていたというのは合点がいく。しかし、ChatGPTの登場で、いろいろと大きな変化が起こる。

2024年以降、ChatGPTを取り入れたMicrosoft 365 Copilot (有償版)を様々な規模の組織で導入できるようになった。自然言語をプロンプト入力するだけで欲しい情報が手に入るというのは驚異的だった。この仕組みが登場することによって SharePoint ベースの仕組みは大きく様変わりしていく。

まず、ナレッジマネージメントの面である。組織内のファイルや会話をもとに独自のAI技術を用いて自動的に社内版の Wikipedia のようなページを自動生成し、かつ自動メンテナンスするための仕掛けとして投入されたのが Viva Topics だった。Viva 自体が市場に投入されたのは、パンデミックの翌年の2021年である。ハイブリットな働き方をシステマティックに支援する仕組みが Viva ソリューションで、この一つに Viva Topics があった。しかし、この仕組みも2025年2月22日に廃止となる。Wikipedia 的なページ作成ではなく、Webおよび組織内の情報をもとにプロンプト入力するたびに必要な情報を生成するという方向に切り替わったのである。たとえば、組織内で交わされる不明な略語があったとしてもWikipedia 的なページを見に行くのではなく、Copilot に自分の知りたい切り口で聞けばいい。

2025年1月15日にMicrosoftは Microsoft 365 Copilot Chatが利用できるというアナウンスをした。従来の Microsoft 365 Copilotを有償版と位置づけ、無償版の Microsoft 365 Copilot を強調することで誰もがCopilotの機能を気軽に享受でき、ユーザーの心理的なハードルを下げることにした。それと同時に、Pages の機能を使って生成した結果をページにまとめて他のユーザーと共有できる仕掛けを用意した。Pages は Microsoft Loop の技術がベースとなっており、さらにその土台はSharePointがベースとなっている。

さて、このアナウンスにより有償版の Microsoft 365 Copilotを持っていなくてもすべての商用サイトではWebの情報もしくは直接アップロードしたファイルをもとに回答を生成してくれることになった。有償版のライセンスがあれば、さらに組織内の情報としてOutlookやSharePoint, Teams などの情報も利用して情報を生成してくれる。「今日の予定は?」と聞けば教えてくれるし、重要なメールの要約も行ってくれる。誰かとの打ち合わせもプロンプトをうまく使えば、予定をセッティングしてもくれる。ファイルの探し方も大きく変わる。ファイル名や含まれるキーワードを想像して検索するのではなく、欲しい情報を具体的にプロンプトに入力することで情報を生成してくれ、また関連するファイルも提示してくれる。考えがまとまらなかったり、わからないことがあればまず、Copilot に聞く。すると嫌な顔一つせず、延々とやり取りに付き合ってくれる、そういう相棒が Copilot である。

つまり、当初 SharePoint サイトで描いてきた方向性が Copilot で実現してきているということである。一時期、SharePoint ホームで実現しようとしていた近未来的な仕組みが、あっという間に Microsoft 365 Copilot で実現できてきている。

こうした流れを受けてSharePoint ホームサイトで使われていた Viva Connections Webパーツもプレビューのまますでに廃止(2024年9月~11月5日までに廃止)となり、次はマイフィード Webパーツも、2025年3月12日をもって廃止されることになった。とはいえ、実際のところ、マイフィードWebパーツは特段使いやすくなっかったし、最近は Teams の機能も充実しているので、そもそも使われていなかったのではないかと思う。ログインユーザーにかかわりのある情報の最新情報のリンクを自律的に収集してくるという、やりたかった方向性はわかる。ただ、欲しい情報が表示されていたかというと疑問で、独自に開発を進めていたAI の性能に限界があったともいえる。

ちなみに、散らばりがちな周知すべき情報に関しては、Teams 側にViva Connections アプリが追加されていれば、SharePoint に投稿したニュースもTeams内にアクティビティとして通知されるようになった。こうした連携機能が欲しいというのはユーザーから要望としてよく出ていたので朗報ともいえる。とはいえ、実際実装されると、自分にかかわりがないと思うニュースが通知されるのか、この通知が嫌だという人も出てきているよう。一元的にオフにできないかという相談を受けるが、必要だと思う人もいるのでTeams アプリからオフにできる以上、個人がそれぞれ要不要を決めればいいだけのことで、そこまで一律で管理する必要はないだろう。

だから会話やお知らせごとは Teams、ファイルを探したければまず OneDrive アプリ、それ以外の総合的な情報の入り口は Microsoft 365 Copilot Chat を使うといったところがエントリーポイントとなるだろう。

SharePoint ポータルサイトは従来通り、ファイルの共有および保管庫として利用したり、リストを使って定型データを蓄積して情報共有していくとよいし、お知らせごとをニュースとして発信する場として使うのは変わらずに行っていくことになる。

ちなみに、クラシックサイトを利用している組織では根強く「お知らせ」リストを使っているところも多いようだが、これはあまり感心しない。一番の理由は発信した情報がどのように伝達されたかを知る仕組みがないからだ。従来の考え方は現実世界の掲示板と一緒で、とりあえず貼っておけばだれか見るでしょう。見てくださいね。掲示しているんだから、見ていないのが悪い、、、というような理屈になりがちである。だが、本来はきちんとした方法論を検討すべきで、どの時間帯に閲覧しているのか、どのくらい滞在しているのかなどを計測して、より確実に情報を届けるアプローチを模索すべきである。古くはメールで既読通知などしていたし、回覧板などもあったが、あれもどれほどの効果があるのかは微妙で、よく読まずに面倒なので一括して既読にすることも少なくない。だからこそ、滞在時間なども重要になる。その点は、モダンサイトのSharePoint のニュースであれば、直接Webページを閲覧しても、メールで内容を送信しても、アクセス状況の分析ができるようになっている。さらに、Viva スイートなどの追加ライセンスを持っていれば、Viva Amplifyを使うことで、SharePointをベースに Teams, Outlook,SharePoint (将来的には Vvia Engage)に対しても一斉にニュースを配信できる。しかも、興味深いのがマーケティング手法を使っていることである。組織内のユーザーを対象にマーケティング手法を用いて情報を広く発信して、情報を収取して分析していく。もはや、ただ掲載しました、ではダメなわけである。

ページ作成に関しては言えば、Flexible セクションがいよいよ登場し、柔軟なレイアウトでの情報発信が可能になる。これに加えて今後は Copilot を使ったサイトやページ作成もできるようになる。私たちは、発信したい情報の本質をしっかり吟味したうえで、少し Copilot に手伝ってもらいながらより良い情報発信を行っていけることになる。またこれが蓄積されることで、組織の重要なナレッジとしての資産となっていく。

ということで、SharePoint 自体は膨大な組織のナレッジの宝庫である。これを有効活用するために、どうしたらよいかという試行錯誤は今後も続いていくが、Microsoft 365 Copilot はゲームチェンジャーであることは間違いない。