※現在はこの問題は解消されています。
たまに質問される事があって以前何かの記事のオマケにサラっと記載した記憶があったけどなかなか見つからないので二重になっても良いから記事にします。
“Microsoft Teams :タブに SharePoint のリストを表示する方法がわかりづらい” の続きを読むArt-Break .log : Taichi Nakamura
Microsoft 365 Copilot ( Office 365 ) ・ Power Platform ・その他の情報発信ブログ
※現在はこの問題は解消されています。
たまに質問される事があって以前何かの記事のオマケにサラっと記載した記憶があったけどなかなか見つからないので二重になっても良いから記事にします。
“Microsoft Teams :タブに SharePoint のリストを表示する方法がわかりづらい” の続きを読む年末年始の休みの間に追加されたようですが、少しゴチャゴチャしてきました。
▼「リンクをコピー」が追加

個人的にはリンクをコピーは利用頻度としてはあまり高くないです。メールなどで「ここにあるから見ておいて!」みたいなやりとりをするには便利ですけどね。
で、普通にアイテムページを開いてブラウザのアドレスバーからURLをコピーすれば良い話ではあるのですが、クラシックUIならダイアログ表示だとアイテムページに遷移しないし、モダンUIなら右パネルでアイテムが表示されるのでアイテムページに遷移しないので、URLをアドレスバーから取得できませんね(モダンページのリストWebパーツの場合は、なぜかクリックすると右パネルじゃなくアイテムページに遷移しますが)。結果的にアイテムページを開いてURLを取得すると、URLにパラメーターが色々ついてるので長いんですよね。過去にこんな記事を書きました。
しかし、この「リンクをコピー」で取得するURLは結構短くなっています。そういう意味でも使い勝手は良いかもしれません。
で、モダンページはレスポンシブWebデザインなので、
▼横幅狭めると…メニューで省略されます

ただし、以前から記事で書いている通り、横幅次第ではクチャクチャになる事があります。
▼クチャクチャ…

英語サイトだと見かけない現象なので、英語で最適化されているので2バイト言語の残念仕様というところでしょうか。そのうち直ってくれるとうれしいです。
ほぼ毎日チェックしてるので、たぶんここ数日の変更だと思いますが。
これまで、モダンページでWebパーツを追加する際に、「リスト」と「ドキュメント ライブラリ」には、後ろに「(プレビュー)」が付いていたんですよね。
僕の過去の記事のスクショを漁ってみると、10/30の記事にありました。
(下のスクショはその記事から抜粋しているので矢印は Bing 地図を示していますが)
▼上から3段目に「リスト(プレビュー)」と「ドキュメント ライブラリ(プレビュー)」

それが今確認すると
およそ1年以上前から(プレビュー)が付いていたので長いプレビュー期間でしたが、ようやくこれで正式版という事でしょうか。
ちなみに、およそ1年前ではようやくWebパーツ内にコマンドバーが追加されたようです。
SharePoint :モダンページのリスト・ドキュメント ライブラリ Webパーツに新規ボタンなどのコマンド バーが追加された!
という事で、プレビューが外れた事で勝手に正式版と解釈しているのですが、とはいえ、プレビューが外れたタイミングで何か更に設定項目が増えたかというとなさそうです。
また…
▼2カラムのセクションにドキュメントライブラリWebパーツを入れるとコマンドバーが重なってしまい

▼この「…」が日本語サイトだと上に「すべてのドキュメント」が重なっているようです。

これは日本語の問題ですけどね。気になりますね。
そして、Webパーツの編集では…
だったりもしますが、とりあえず SharePoint のサイト内の2つの大きな主役のWebパーツがプレビューが外れた?のはうれしい事ですね。
これから SharePoint を利用されるユーザーにとっては逆に「クラシックってなに?」になるのかもしれませんが、特に今までクラシックサイトで慣れ親しんだユーザーはまだまだモダンサイトに抵抗感があるかもしれません。しかし、すでに流れはモダンサイトなので是非どんどん使ってみましょう。
当ブログの免責事項に個人的見解である旨は記載しているけど、あらためて記載しますが、この記事もあくまでも僕の個人的見解です。特にこの記事を読まれている方が企業の SharePoint 管理者やサイトコレクションの管理者の場合は、最終的な判断はご自身で調査した結果で判断してください。
SharePoint はサイト内に配置できるコンテンツは大別すると「リスト」「ライブラリ」「ページ」の3つかと思います。で、ページはちょっと別として SharePoint を知らない方に説明する場合は「リスト」と「ライブラリ」を重点的に説明するのですが、説明後によく質問されるのが以下の質問。
「リストもアイテムにファイルを添付できますよね?ライブラリと何が違うの?」
僕の説明が悪い事に反省しつつ、その回答としてリストの添付ファイルでファイル管理をする事をお勧めしない理由を挙げています。
リスト自体にバージョン管理の機能はあります。しかし、添付ファイルはバージョン管理の対象外です。
▼そもそも添付ファイルに同じファイル名のファイルは上書きアップロードできません。

なのでファイルを更新して最新版を添付する場合は、すでに添付済のファイルを削除し、最新版を添付しなおします。その後にアイテムのバージョン履歴から復元をしても、添付ファイルは元に戻りません。
ライブラリなら持っている機能がリストの添付ファイルにはありません。例えば…
など。
ファイルの中身はクロールされるのでこれはあまり大きな問題ではないとは思いますが、大事なのは次かもしれないです。
上述の通り添付ファイルの中身はクロールの対象ですが、検索結果に表示されるのは添付ファイルではなく添付されている本体のアイテムです。なので、アイテムに例えば20ファイルほど添付していたとしたら、検索結果からアイテムに行っても、その中の20ファイルからどれが目的のファイルかはわかりません。ファイル名で判断がつけば良いけど、判断付かない場合は20ファイルを上から順に中を開いて探すしかないです。
これらの理由から「ファイルを管理する」という用途の場合は、リストの添付ファイルはお勧めしていません。
ファイル管理に不向きなだけで、ファイルを添付しない方が良いとは言っていません。管理する必要のないファイルであればアイテムの表現を豊かにする方法としてファイルを添付する使い方は問題ないと思います。例えば画像を添付とか。
それぞれの特徴や機能を考慮して有効に利用できると良いですね。
※本題の前に回りくどくなりますが前段の説明から入ります。色々知ってる人は飛ばしてください。
Office 365 のライセンスのみでは CDS ( Common Data Service )は利用できないので、PowerApps のアプリのデータの保存場所は OneDrive や SharePoint などを使う事になると思います。
PowerApps は SharePoint のフォームのカスタマイズをする用途もありますが、今回は SharePoint のカスタムリストを保存場所にしてアプリを作成した場合の話です。
SharePoint で組織の通達・連絡をお知らせリストなどリストを利用している場合、中には画像を本文内に表示させたい場合もよく出てくると思います。その場合、通常の方法ならリッチテキストエディタ内で画像の挿入を行うのですが、場合によってそれができない環境もあります。その場合のもう一つの方法の紹介をします。
まずは通常の画像の挿入方法のおさらい。
▼リッチテキストエディタのリボンタブ「挿入」→「画像」→「コンピューターから」

参考までに、宛先ライブラリはデフォルトで「サイトのリソース ファイル」が選択されていますが、ここは変更が可能です。 過去記事を以下に紹介します。
SharePoint : サイトの開発・カスタマイズ用ファイルを「サイトのリソース ファイル」ライブラリに保管するのは微妙かも
▼リッチテキストエディタの編集を終えるとアイテム編集パネルへ。表示されています。

このようにしてリストのアイテムの本文に画像を表示することができますが、この挿入方法は(ユーザーは意識をせずに)内部的には以下の操作がされています。
▼なのでこのように「サイトのリソース ライブラリ」に画像がアップロードされています。

過去、SharePoint 2007 ではリッチテキストエディタからこのように画像をアップロードできなかったので、わざわざ先にライブラリに画像をアップロードした後に、画像ファイルのURLをコピーして、リッチテキストエディタに貼り付けたものです。 SharePoint 2010 からは、このようにそれを意識せずにリストのリッチテキストエディタ内で操作が完結できるようになって便利だなと思ったものです。
ただし、上述の通り宛先ライブラリに画像をアップロードするという操作が内部的にあるが故に、この方法では画像を挿入できない場合があります。その原因はライブラリのアクセス権限です。
特に社内ポータルサイトとなるとアクセス権限が厳しく設定されている場合が多いです。サイト管理者以外は基本的に閲覧のみで、投稿が必要なリストのみ必要なユーザーに投稿権限を付与する、など。
その場合、サイト全体は閲覧権限で、通達・連絡用リストのみ投稿権限が付与されたユーザーで、上述の通常の画像挿入方法を試してみると、できない事がわかります。
▼リッチテキストエディタのリボンタブ「挿入」→「画像」→「コンピューターから」をクリックすると、このようにダイアログ内でエラーが。

「予期しないエラーが発生しました。」と記載がありますが、つまりこれはこのサイト内でアップロードできる権限のあるライブラリが一つもないという事です。
過去にこのような事例は経験してきました。「サイトのリソース ライブラリ」にも投稿権限を付与してあげれば良いのですが、環境によってはルールでNGとしている場合もあります。 画像の挿入はあきらめてもらっているか、なんと別途イントラサイト内にサーバーを立てて、その中に画像をアップしているケースも!
そんな場合に、もう一つの画像表示方法があります。特に目新しい方法でもなくカスタマイズも必要ないです。「添付ファイル」を利用する方法です。
▼まず添付ファイルに表示させたい画像を追加して、投稿してしまいます。

※この時点で本文は画像挿入以外の文章入力などを済ませ、その他の列の設定も済ませた状態がベストです。
▼対象のアイテムを編集し、リッチテキストエディタの「挿入」タブ→「画像」→「アドレスから」

▼リッチテキストエディタを閉じてもこの通り、本文に表示されます。

つまり、画像のアップロード先を宛先ライブラリではなく自らの添付ファイルにしただけです。
注意点としては、リストのアイテムは下書きができず投稿したら即公開です。添付ファイルは一度投稿をしないとURLは取得できないので、投稿してから編集して画像を貼る間は、画像がない状態で公開されてしまいます。そういう意味で上述の※の通り他の入力は済ませた方がベストという事です。
このようにサイトに対して投稿したいリスト以外に投稿権限以上のアクセス権限が付与されていない場合には、画像を表示する時は添付ファイルを利用すると良いですよ、という話でした。 また、事情があってそのような仕様にしなければいけないサイト管理者は、投稿者に添付ファイルを利用する方法を案内すると良いですね。
オマケ
このスクショを撮っている時に気が付いた小さな事です。
▼クラシックUIでリストのビューで本文を表示すると、2通りの方法で表示した画像は同じように表示されます。

▼しかし、モダンUIの場合は、通常挿入方法の画像はグラデがかかって省略表示されるのに対して、添付ファイルの方法で表示させた方は、グラデがかからず省略表示されます。

特に操作に違和感はないから表示上での相違点だけなのですが、不思議ですね。
リストに対して閲覧権限を付与されたユーザーは、他人の投稿したアイテムを編集しようと思っても、ボタンがグレーアウトされてクリックできません。わかりやすいし罠の臭いも感じません。

次にリストに対して投稿権限はあるけど、リストの詳細設定の「アイテムごとの権限」の設定を変更した場合。ここにイジワルとも言うべき罠が潜んでいるんです。
初期設定では「読み取りアクセス権」「作成/編集のアクセス権」が共に「すべてのアイテム」になっています。

ここで問題なのは「作成/編集のアクセス権」を「ユーザー本人のアイテム」にした場合。

つまり自分以外のアイテムは編集できないという事です。
この設定がなぜ罠かというのは実際にやってみるとわかります。
▼この設定にして他人のアイテムをまずは開きます。ん?リボンの「アイテムの編集」ボタンはクリックできる?? …とりあえずクリックします。

▼内容を編集して「保存」ボタンをクリックすると…このタイミングでNG!?

そうなんですよね。編集できそうに見せかけて最後の最後でやっぱできないんですよね。「編集できますよ!できますってば!ほら、やってみて!…うっそぴょ~ん!」というイジワルな声が聞こえそうな罠です。
このイジワル仕様による弊害は立場的には2点あります。
この仕様を知らないリスト作成者が、自分のアイテム以外を編集できない要件のあるリストを作成した際に、この設定を施します。その後、検証をしてみると編集ボタンはあるし編集画面に行けるから「あれ?うまく動作してない?」と勘違い。普通編集画面まで行けてしまった時点でうまく機能していないと思ってしまうから、そこから更に実際に「保存」までのアクションをテストせずに悩んだり調べたりしちゃいますよね。この仕様がわかった時に、無駄な時間をすごしてしまったと思っちゃいます。
実は実際に僕はこの罠に陥った一人です。ホント仕様を知った時に心の中で「orz」になりましたよ。
該当リストがそういう仕様だという事に気がつかずに、他人のアイテムを編集する機会があったとします。ボタンがグレーアウトしていたり事前にそういう仕様であると示唆するメッセージなどがないので、知らずにメッチャ気合い入れて編集し、保存ボタンをクリックしたら…。
俺の気合いを返せ!となります。
実は実際に経験談ですが、これで苦情を受けたこともあります。仕様なので仕方ないんですけど、苦情を入れたい気持ちもわかる。
アイテムごとの編集の設定を変更したら、リスト作成者はこの仕様を忘れずに。また、投稿者には何かしらの手段でしっかりアナウンスする必要がありそうです。
SharePointに限らずですが、社内の情報共有の場で情報発信をする立場の人は、自分が発信した情報が受信者に読まれ、理解され、活用されているかは気になるところですよね。その中から今回「読みやすさ」について考えたいと思います。まずは今まで自分が投稿してきた投稿物を思い出してみてください。以下のような事をしていませんですか?
これらは一例ですが、心当たりがある場合は、以下を読んで何かしら気付きになっていただければ幸いです。(一概に悪い例という事ではありません。)
人に読んでもらえる記事を書くヒントはネット上にたくさんあります。大手ニュースサイトを「読みやすさ」という観点で読み漁ってみてください。概ねこういう傾向がある事に気がつくと思います。
今までご自身が投稿してきたアイテムの内容と比べてみてどうでしょうか?結構、間逆な事をしているのではと思います。
以下は、この記事の文章に超テキトーに色々装飾を施してみたアイテムのスクリーンショットです。
黄色や薄い水色などの文字は読みづらいですね。緑のマーカーに赤字の部分はチカチカしますよね。重要な箇所に色々な装飾を施したとしても、結局重要箇所が多すぎて読む際に散漫になってしまいます。これは、以前テレビ番組でやっていたのですが、東大生が受験勉強をしていた頃の勉強方法の中で、「ノートの板書はカラフルにしない」「参考書にマーカーは引かない」などがありましたが、その理由と似ているのではと思います。また、Webの世界では未だに「下線の青文字はリンク」という印象があるので、リンクでないテキストに青文字で下線を装飾にすると、閲覧者がクリックしようとしてしまい「リンクじゃないんかい!」と心の中で突っ込みを入れつつストレスフルな文章になってしまいます。また、逆にこんなにカラフルにしていると、中にテキストリンクをつけても、ほとんどの閲覧者はそのリンクの存在に気がつきません。実はこの中で一箇所テキストリンクがあるんですが、視認できますでしょうか?SharePointのテキストリンクは、リンク色はサイトのテーマによって変わりますし、マウスホバー時に下線が現れますが、文章を読んでいるときに全文をマウスのカーソルを当てながら読む閲覧者はあまりいません。つまりテキストリンクが視認できない場合、リンク先のコンテンツはほとんど閲覧されない事になってしまいます。リッチテキストエディタ内に他コンテンツにリンクをつける場合は、リンクと視認できるかどうかを特に意識した方が良いです。
と、ツラツラと書いてみましたがいかがでしょうか?ちなみに過去の経験上、結構こういうコンテンツはありました。
大手ニュースサイトに共通している特徴はそれなりに根拠があっての特徴なので、自分なりに昇華してみて、ぜひ今後作成するコンテンツに試みてはいかがでしょうか。また、SharePoint運営者やサイト管理者の立場の場合は、読まれるコンテンツ作りの重要性とそのコツなどを投稿者向けに教育をしてみる事を検討してみてはいかがでしょうか。
SharePoint2007で運営に携わっていた頃はリストと言えばお知らせリストを使っていました。(カスタムリストはほとんど利用していませんでした。)リストを通達・連絡用として利用するケースが多く、パッと作成してすぐ使うにはお知らせリストが最適で、またSharePoint2007の頃は、リストで設定したメールアドレスにメールを送信すると、そのままリストに投稿される受信メール機能があり、これはお知らせリスト固有の機能で重宝していたからです。
ただし、お知らせリストには一点邪魔な存在がありました。それが「有効期限」列です。
こんな列があれば、普通は有効期限列に日付を入れたら、その日が過ぎるとアイテムは削除されると思いますよね。それが何も起きないんですよね。ただ日付の列があるだけで、有効期限列単体では何の機能もないんです。SharePointを運営していると、「有効期限が動作しません」という問い合わせを多く受けました。説明をすると「え?あるのに何も機能しない?なにそれ…」的な腑に落ちない感じに返されてしまいますが、腑に落ちないのもごもっともだと思います。
▼有効期限列を利用する場合の一例ですが、有効期限列を利用して情報管理ポリシーの保持を設定したり、

有効期限列+他の機能の組み合わせで利用できます。
※ちなみにビューのフィルターを利用する方法に関しては落とし穴がありますが、話しが長くなってしまうので、それは別の機会にトラブル事例として紹介できればと思います。
一例として有効期限列を活用する方法を紹介しましたが、お知らせリストを運営する際に有効期限なんて不要な場合もあり、ではこの思わせぶりなこの列を削除してしまいたいですよね。でも…この列、削除できないんですよね。これ本当に厄介です。
▼よく見ると「OK」「キャンセル」はあっても、他の列設定のように「削除」ボタンがないんです。

ただ、ちょっと設定をする事で、削除ではないのですが非表示にする事は可能です。普段あまり使わないコンテンツタイプを利用します。
▼お知らせリストの詳細設定でコンテンツタイプの管理を「はい」

お知らせリストの設定の全般設定の下にコンテンツ タイプというセクションが表示されるので、「お知らせ」コンテンツ タイプをクリック。リスト コンテンツ タイプの設定の列セクションの「有効期限」をクリック。
最初からカスタムリストを使って通達・連絡用リストを作成すれば良いのですが、ワケあって有効期限は不要だがお知らせリストを使いたかったり、すでにお知らせリストで運営されていて有効期限列が邪魔だなぁと考えていた場合などは、この方法を検討してみてはいかがでしょうか。
SharePointのアプリは大別するとリストとライブラリの2種類ですね。で、色々な種類のリストやライブラリがあるわけですが、リストに関しては、いわゆる通達や連絡など掲示板的な利用目的の場合、カスタムリストを使うべきか?お知らせリストを使うべきか?というところで迷う事があると思います。
僕の場合はずっとお知らせリストを使っていました。理由は受信メール機能です。
オンプレのSharePoint2007を長いこと使っていたのですが、オンプレのSharePointにはメールでアイテムを投稿できる受信メール機能があり、これはお知らせリストだけの機能でカスタムリストには加えることのできない機能でした。
この機能、メールでアイテムを投稿できると知ると結構使う人が多かったんです。例えばメーリングリストのtoの中に受信メール用アドレスを突っ込めば、メールのバックナンバーが自然に作れるような使い方とか。
後で使いたいと言われた時に即対応できるようにお知らせリストばかりを使っていて、カスタムリストはほとんど使っていませんでした。
つい最近まで知らなかったのが、この受信メール機能はオンプレだけの機能で、SharePoint Onlineでは使えないようですね。お知らせリストにこだわる理由がなくなりました。
逆にお知らせリストが微妙なのが「有効期限」列の存在があります。カスタムリストはデフォルトでタイトル列のみですが(「更新者」列などは除いて)、お知らせリストには「本文」列と「有効期限」列がリスト作成時にすでに存在します。「本文」は大抵利用する列なので問題ないとして、「有効期限」列ですよ。
この「有効期限」列は、非常に微妙なんですよね。普通に考えたらここに日付を入れたら、期限が切れたアイテムは削除されるのかな?と思うじゃないですか。でもいつまで経っても削除されないんですよね。この列はただの日付を入力する列なんですよ。特別なにかアクションがあるわけじゃないんです。どこかで聞いた話では、有効期限列は、この列を利用して、例えばビューのフィルターで非表示にするなどご自由にお使いください的な意味だとか。もちろん情報管理ポリシーで設定すれば期限切れで削除したりもできますが。
「有効期限」列の厄介なのはこの列を削除できない事。

列の編集に削除ボタンがないんですよ。有効期限列があればユーザーは有効期限があると思うし、ここに日付を追加してしまうので、この列が機能していないのに存在するのは良くないですよね。
対処法はあります。リストの詳細設定でコンテンツタイプの管理を許可して、お知らせコンテンツタイプの設定から有効期限列を「非表示」にすれば、削除はされないけど、削除されたようなものにはなります。
▼お知らせコンテンツタイプの設定から有効期限を非表示に

▼有効期限列は削除はされないけど非表示になります。投稿画面で非表示になっているということは、利用されないので削除みたいなものかと思います。

とはいえ、いちいちこんな設定をするのは面倒ですよね。
なので、オンプレで受信メール機能が利用できる環境なら、上述のメリット・デメリットを考慮して使い分ける必要がありますが、SharePoint Onlineであれば、個人的には何も考えずにカスタムリストから作る事になるかな。