【Power Automate】SharePoint「項目の更新」のID設定を完全解説――トリガー別の取得先と無限ループ対策まで

Power Automateで SharePoint の「項目の更新」アクションを使うとき、「IDには何を設定すればいいのか？」 と迷う方は多いです。

この記事では、IDの意味・設定方法・トリガー別の取得先・よくある注意点までを体系的に解説します。

IDとは何か

SharePoint のリストに行（アイテム）が追加されるたびに、SharePoint は自動で 「1」「2」「3」… と重複しない番号を割り振ります。これが ID です。

「項目の更新」アクションは、「リストの中の どの行を書き換えるか」を特定するためにこの ID を必要とします。ID がなければ、Power Automate はどの1件を更新すればよいか判断できません。

基本の考え方

ID は 固定値を手入力するのではなく、前のステップの動的コンテンツから取得する のが基本です。

やりたいこと ID の取得元
トリガーになった同じ項目を更新する トリガーの ID
ID が分かっている項目を取得して更新する 「項目の取得」の ID
条件で対象を探して更新する 「複数の項目の取得」の各アイテムの ID
Forms・Outlook・Teams 経由で更新する 「複数の項目の取得」で検索した結果の ID

トリガー別のID取得先一覧

トリガー／アクション ID の取得先 使い方のイメージ
SharePoint「項目が作成されたとき」 トリガーの ID 作成されたその1件をそのまま更新する
SharePoint「項目が変更されたとき」 トリガーの ID 変更された同じ1件を更新する
SharePoint「項目が作成または変更されたとき」 トリガーの ID きっかけになった同じ1件を更新する
SharePoint「項目の取得」 取得した1件の ID ID 指定で取得した1件を更新する
SharePoint「複数の項目の取得」 各アイテムの ID 条件に合う複数件を順番に更新する
Microsoft Forms「新しい応答が送信されるとき」 後続の検索アクションで取得した ID 回答内容をキーに対象行を探して更新する
Outlook「新しいメールが届いたとき」 後続の検索アクションで取得した ID メール内容をキーに対象行を探して更新する
Teams「メッセージが投稿されたとき」 後続の検索アクションで取得した ID Teams の情報をもとに対象行を特定する
手動トリガー 入力パラメータとして渡した ID 実行時に更新対象を手動で指定する
スケジュール「繰り返し」 後続の検索アクションで取得した ID 定期実行で対象行を探して更新する

ポイント： SharePoint 以外のトリガーでは、SharePoint の ID は直接取得できません。「複数の項目の取得」アクションで対象行を検索してから ID を取得するステップが必要です。

「項目の取得」と「複数の項目の取得」の違い

名前が似ているため混同しやすいですが、役割はまったく異なります。

アクション 何を指定するか 使う場面
項目の取得（Get item） ID を指定して1件取得する すでに ID が分かっているとき
複数の項目の取得（Get items） 条件（Filter Query など）で検索する 条件に合う行を探したいとき

「条件で検索して1件見つけて更新したい」場合は、「複数の項目の取得」→「項目の更新」 の順に組みます。「複数の項目の取得」は名前に「複数」とありますが、検索結果が1件でも問題なく使えます。

Microsoft Lists × Power Automate × Teams で見積通知を自動化する完全ガイド【設計から構築まで】

はじめに：設計で混乱しやすいポイント

Power Automateのフロー設計でよく起きる混乱の原因は、次の2つを混同することです。

  • トリガー：いつフローが動くか
  • 条件（アクション）：どのように処理するか

この記事では両者を明確に分けた上で、Microsoft Lists のデータ更新をきっかけに Teams へ自動でメンション通知を送る仕組みを、設計から実装まで一通りまとめます。

Microsoft Lists の列構成

フローを作成する前に、対象リストへ以下の列を作成しておきます。Power Automate はこの列情報を参照するため、フロー作成より先に Lists を完成させることが手戻りを防ぐポイントです。

列名 種類 用途
案件番号 1行テキスト 案件識別コード
見積依頼先 1行テキスト 依頼先企業名
実施伺い先 ユーザー 通知先①
見積回答内容 複数行テキスト 回答テキスト
見積回答確認先 ユーザー 通知先②
通知種別 選択肢 (Choice) 何を送るか
通知状態 選択肢 (Choice) 送信ステータス
通知日時 日付と時刻 監査証跡
エラー理由 複数行テキスト 障害ログ
最終更新者 ユーザー 操作者記録

Choice 列の設定値

通知種別（空欄のまま保存できるよう、既定値なしを推奨）

  • 見積実施伺い
  • 見積回答確認伺い

通知状態（既定値：未送信）

  • 未送信
  • 処理中
  • 送信済み
  • エラー

注意：Choice 列の選択肢は全角・半角スペースが混入しないよう正確に入力してください。表記ゆれがあると、後述するトリガー条件の式が一致せずフローが起動しません。

実際の運用イメージ

パターン① 見積実施伺い

Lists に以下を入力して保存すると、Power Automate が起動し Teams へ通知されます。

項目 入力値
案件番号 A001
見積依頼先 ○○商事
実施伺い先 山田（ユーザー選択）
通知種別 見積実施伺い
通知状態 未送信

パターン② 見積回答確認伺い

同じレコードを編集・保存すると、2回目の通知が自動送信されます。

項目 入力値
見積回答内容 100万円
見積回答確認先 佐藤（ユーザー選択）
通知種別 見積回答確認伺い
通知状態 未送信

Power Automate フローの作成手順

Power Automate ポータル を開き、「独自のフローを一から作成」→「自動化したクラウドフロー」を選択してください。

ステップ 1：トリガーの設定と無限ループ防止

1.トリガーとして 「アイテムが作成または変更されたとき（SharePoint）」 を選択し、対象のサイトとリスト名を設定します。

Microsoft Listsのアドレスを設定する場合、URLの中から「サイトのURLに該当する部分」だけを抜き出して手動で入力する。具体的には/Lists/ の直前までを貼り付ける。

フロー末尾で「送信済み」に更新するとトリガーが再発火し、無限ループになります。これを防ぐため、トリガー条件を設定します。

トリガーカード右上の「・・・」→「設定」→「トリガー条件」の「＋追加」をクリックし、以下の式を入力してください。

@equals(triggerBody()?['通知状態']?['Value'], '未送信')

ポイント：Choice 列は .Value プロパティで参照します。これを忘れると条件が正しく評価されません。

ステップ 2：通知状態を「処理中」に変更する

フロー起動直後に他のトリガー発火を防ぐため、即座にステータスをロックします。

「新しいステップ」→ 「項目の更新（SharePoint）」 を追加し、以下のように設定します。

  • サイトのアドレス・リスト名：トリガーと同じ
  • ID：動的コンテンツから「ID」を指定
  • 通知状態 Value：処理中

⚠️ データ消失に注意：「項目の更新」は、空欄のまま設定した列を上書きして空にしてしまいます。「案件番号」「見積依頼先」など更新対象以外の列にも、必ず動的コンテンツから元の値を指定してください。

ステップ 3：Switch で通知種別を分岐する

「新しいステップ」→ 「Switch（切り替え）」 を追加します。

  • 「オン」の入力欄：動的コンテンツから 通知種別 Value を指定
  • ケース 1：見積実施伺い
  • ケース 2：見積回答確認伺い

ステップ 4：メンショントークンの取得と Teams への投稿

ケース 1・ケース 2 それぞれに、以下の 3 つのアクションを配置します（通知先ユーザー列だけ変えます）。

① メンショントークンを取得する

「ユーザーのメンション トークンを作成する (V2)（Microsoft Teams）」 を追加します。

ケース ユーザー欄に指定する動的コンテンツ
ケース 1（見積実施伺い） 実施伺い先 Email
ケース 2（見積回答確認伺い） 見積回答確認先 Email

注意：本文に @山田 と直接入力しても Teams の正式なメンションにはなりません。必ずこのアクションで取得した Message Mention を使用してください。

② Teams にメッセージを投稿する

「チャットまたはチャネルにメッセージを投稿する（Microsoft Teams）」 を追加します。

  • 投稿先：Channel
  • チーム・チャネル：事前に作成済みのものを選択
  • メッセージ：文頭に動的コンテンツの Message Mention を挿入し、案件情報を続けて記述する

事前確認：Power Automate でチャネルはドロップダウン選択のため、フロー作成前にチャネルが存在している必要があります。通知先ユーザーがそのチャネルのメンバーであることも確認しておきましょう。

③ 通知状態を「送信済み」に更新し、通知日時を記録する

再度「項目の更新（SharePoint）」を追加します。

  • 通知状態 Value：送信済み
  • 通知日時： 詳細パラメータから「通知日時」を選択し、「式」タブで以下を入力 
convertFromUtc(utcNow(), 'Tokyo Standard Time')

Power Automate の標準時刻は UTC のため、そのままだと 9 時間ずれます。上記の式で日本時間に変換して記録してください。

ステップ 5：エラーハンドリングの設定

Teams 送信などが失敗した際に、Lists 側でエラー内容を把握できるようにします。

Switch アクションの下に「項目の更新（SharePoint）」を追加し、次のように設定します。

  • 通知状態 Value：エラー
  • エラー理由：前ステップのエラー情報（動的コンテンツ）を入力

このアクションの「・・・」→ 「実行条件の構成」 を開き、以下のように変更します。

  • 「成功時」：チェックを外す
  • 「失敗しました」「スキップされました」「タイムアウトしました」：チェックを入れる

動作確認の手順

  1. Lists に新しい行を追加し、通知状態を 未送信、通知種別を 見積実施伺い にして保存する
  2. 数分以内にフローが起動し、通知状態が 未送信 → 処理中 → 送信済み と変化することを確認する
  3. Teams の指定チャネルに、対象者へのメンション付き投稿があれば完成

実装でハマりやすい 4 つのポイント まとめ

ポイント 対処法
無限ループ トリガー条件に @equals(..., '未送信') を設定し、処理中ステータスで二重起動も防ぐ
Teams メンションが飛ばない 「メンション トークンを作成する (V2)」で取得した Message Mention を本文に埋め込む
通知日時が 9 時間ずれる convertFromUtc(utcNow(), 'Tokyo Standard Time') で JST 変換
データが消える 「項目の更新」では更新対象以外の列にも元の値を動的コンテンツから必ず設定する

将来の拡張ポイント

案件状態と通知状態の分離

現在の設計では 1 つのステータス列が複数の役割を担っています。業務が複雑になってきたら、次の 2 列に分けると管理しやすくなります。

列名 役割
案件状態 業務プロセスの現在地（検討中・承認済みなど）
通知状態 通知の送信ステータス（未送信・送信済みなど）

「1案件＝1レコード」の限界への対応

同一案件での再通知や ISO 監査での通知履歴遡及が必要になった場合は、通知履歴リストを別途作成する構成への移行を検討してください。

まとめ：最初から入れておくべき設計要素

要素 優先度 理由
トリガー条件（通知状態 = 未送信） 必須 無限ループ防止
「処理中」ステータス 推奨 二重起動防止
メンション トークン (V2) 必須 確実な Teams 通知
通知日時の JST 変換 推奨 監査証跡の可読性
エラー理由列 推奨 保守・監査対応
最終更新者列 推奨 ISO 監査対応

フローは 1 本、Teams への投稿パターンは 2 種類、これで十分に実用レベルの業務システムになります。ISO 14001 の監査対応を見据えるなら、「通知日時」「処理中ステータス」「エラー理由」の 3 点は最初から設計に組み込んでおくことをおすすめします。

Power AutomateのTeams投稿アクションはV2？V3？UIとコードビューで確認する方法まとめ

Power Automateでよく使われるTeams投稿アクションについて、「V2なのかV3なのか」というAIとのやり取りの中で疑問を持ちました。この記事では、UIとコードビューそれぞれの観点から確認方法を整理し、実務上どう判断すればよいかをまとめます。

アクション名に「V3」が表示されないのは仕様

現在のPower Automate（特にモダンデザイナー）では、アクション名に「V2」「V3」といったバージョン番号が画面上に表示されない仕様になっています。

「Post message in a chat or channel」と表示されていても、それだけではバージョンは判別できません。Microsoftはユーザーがバージョンを意識しなくて済む設計へ移行しています。

UIの見た目だけで判別できるか？

よく言われる「UIで見分ける方法」として、以下のような観点が挙げられます。

観点 旧来アクション（V2寄り）の傾向 現行アクション（V3寄り）の傾向
アクション名 個別機能ごとの名前が残る 「チャットまたはチャネルでメッセージを投稿する」のように統合的
投稿者 選択肢が限定的 「フロー ボット」「ユーザー」などを選択可能
投稿先 チャネル専用など機能が分かれる チャット・チャネル・グループチャットをまとめて扱える
画面の統一感 項目が分散・古い印象 投稿先に応じて入力欄が整理されている

ただし、この判別方法には限界があります。

  • UIはMicrosoftによって随時更新される
  • テナントやデザイナー（クラシック/モダン）によって見え方が異なる
  • V2でもUIだけ新しくなっているケースがある

UIの見た目はあくまで参考程度であり、バージョンを確定する根拠にはなりません。

コードビュー（JSONの定義）で確認する

「コードの表示（Peek code）」からフロー定義のJSONを確認する方法が、より信頼性が高い確認方法です。

{
  "type": "OpenApiConnection",
  "inputs": {
    "parameters": {
      "poster": "Flow bot",
      "location": "Channel",
      "body/recipient/groupId": "xxxx",
      "body/recipient/channelId": "xxxx",
      "body/messageBody": "..."
    },
    "host": {
      "apiId": "/providers/Microsoft.PowerApps/apis/shared_teams",
      "connection": "shared_teams",
      "operationId": "PostMessageToConversation"
    }
  }
}

JSONから読み取れること

  • operationId: PostMessageToConversation：Teams投稿アクションであることを示す
  • apiId: shared_teams：Microsoft Teamsコネクタを使用していることを確認できる
  • poster / location / groupId / channelId：現行の統合投稿アクションのパラメータ構成と一致する

それでもV3と断定できない理由

operationId が PostMessageToConversation であり、PostMessageToConversationV3 のようにバージョン番号を含んでいません。Microsoftはコネクタ更新時に内部実装を変更しても operationId を変更しないことがあり、JSONだけでV2/V3を公式に判別する方法は存在しません。

判別方法の確実性まとめ

確認方法 確実性
フロー定義（JSON）の内部名を確認 ★★★★★
コードの表示（Peek code）で確認 ★★★★★
UIの画面構成で判断 ★☆☆☆☆

実務上の結論

  • 「チャットまたはチャネルでメッセージを投稿する」という名前で、投稿者・投稿先・チーム・チャネルを1画面で設定できるなら、現行の統合投稿アクションとして扱って問題ありません
  • バージョンを厳密に確認したい場合は、コードビューやエクスポートしたJSONで operationId を確認する
  • ただし、JSONレベルでも「V3」と断定できるケースは限られており、Microsoft自身がバージョン番号を意識させない設計を採用しています

フローの保守・引き継ぎなどで確認が必要な場面では、「V2か V3か」よりも「現在サポートされているアクションか」を基準に判断するのが実用的なアプローチです。

Power Automateでアクションが検索できない時の対処法【Teams連携フロー向け】

Power Automateでフロー内に存在するアクションを再検索しようとしたのに、検索に引っかからない――そんな経験はありませんか？この記事では、アクション検索がうまくいかない原因と、確実に見つけるための方法を整理します。

アクション検索がうまくいかない主な原因

まず「なぜ見つからないのか」を知っておくことが大切です。単なる検索の問題ではなく、以下のような構造的な原因があります。

原因 内容
コネクタのバージョン違い Microsoft Teams と Microsoft Teams (Preview)、さらに V2・V3 の違いにより表示されるアクションが異なる
アクション名の変更 Power Automate のアップデートにより、以前と名前が変わっていることがある
テナント・環境の差異 組織の設定によって利用可能なアクションが異なる場合がある
表示言語と検索の不一致 日本語環境でも英語でヒットしやすい場合があり、逆もある

確実にアクションを見つける方法

① コネクタから絞り込む（最もおすすめ）

検索窓より先に、コネクタで絞り込む方法が最も安定します。

  1. 「＋」→「アクションの追加」をクリック

  2. 一覧から「Microsoft Teams」を選択

  3. 「ctrl + F」キーでブラウザでアクションを検索し選択

② 短いキーワードで検索する

正式名称をそのまま入力すると、スペースや表記の微妙な差でヒットしないことがあります。特徴的な単語だけで試してみましょう。

試してみるキーワード（日本語）

  • メッセージ
  • チャネル
  • チャット
  • 投稿

試してみるキーワード（英語）

  • Post
  • message
  • channel

日本語環境だから日本語のみ、というわけではありません。環境によってどちらが見つかりやすいかは異なります。両方試してみてください。

③ アクション名が変更されていないか確認する

Power Automate は定期的なアップデートでアクション名が変わることがあります。たとえば以下のように変更されるケースがあります。

旧名称 新名称（例）
Post message in a chat or channel Post card in a chat or channel
（同上） Post message in chat or channel

古い記事やスクリーンショットを参考にしている場合、名称が一致しないことがあります。

④ 「もっと見る」や詳細表示を開く

初期表示では一部のアクションが隠れていることがあります。アクション一覧画面の「詳しく見る」や「もっと見る」を展開して確認してみましょう。

今回のケース：「Post message in a chat or channel」が見つからない場合

この状況では、以下の順で試すのが近道です。

  1. Microsoft Teams コネクタを開く
  2. 投稿 → チャット → チャネル → メッセージ の順にキーワード検索
  3. 見つからなければ一覧をスクロールして目視確認
  4. それでも見つからない場合は、コネクタのバージョン（Teams / Teams Preview / V2・V3）を確認する

まとめ

  • アクション検索はコネクタで絞ってから探すのが最も確実
  • キーワードは短く、日本語・英語の両方を試す
  • 見つからない原因が「検索の問題」ではなく「コネクタのバージョン差」や「アクション名の変更」の場合もある
  • アクション一覧を目視スクロールする方が、検索より早いこともある

【Power Automate × Teams】投稿先の種類と権限・接続設計のポイントを整理する

Power AutomateからTeamsへメッセージを投稿する際、「誰の権限で、どこに投稿するか」という設計が運用品質を大きく左右します。本記事では、投稿先の種類・権限の考え方・接続設計のベストプラクティスを整理します。

投稿先はチャネルだけではない

Power Automateの「チャットまたはチャネルでメッセージを投稿する」アクションでは、以下の3種類を投稿先として指定できます。

投稿先 概要
チャネル 標準・プライベート・共有チャネルへの投稿
1対1チャット 特定ユーザーへの個人チャット
グループチャット 既存のグループチャットへの投稿

実務での利用頻度はチャネルが圧倒的多数です。グループチャットは設定難易度が高く、業務フローの通知先としてはほとんど使われません。

投稿に必要な権限はOwnerではなくメンバー資格

チームやチャネルの「所有者（Owner）」である必要はありません。投稿可否は次の条件で決まります。

  • 通常チャネル → そのチームのメンバーであれば投稿可能
  • 投稿制限チャネル（アナウンス用など） → Owner等、投稿が許可されたロールのみ
  • プライベートチャネル → チームのメンバーであるだけでは不十分。そのプライベートチャネル自体のメンバーである必要がある

ポイント：「チームに所属している」だけでは投稿できないケースがあります。特にプライベートチャネルは注意が必要です。

投稿者の選択：Flow bot vs ユーザー

アクション設定で「誰として投稿するか」を選択します。それぞれの特徴は以下の通りです。

投稿者 見え方 特徴
Flow bot ボット名で表示 自動化であることが明確。個人名に依存しない
User（ユーザー） 個人名・アイコンで表示 自動化と気づかれにくいが、退職・異動でフローが停止するリスクあり

プライベートチャネルへの投稿はFlow botでは制限される

標準機能では、Flow botはプライベートチャネルに投稿できないケースが多いです。プライベートチャネルへ確実に投稿したい場合は、投稿者を「User」に設定し、かつそのユーザーがチャネルメンバーである必要があります。

接続（コネクション）設計が最重要

投稿者の表示設定（Flow bot / User）はあくまで「見た目」です。実際の権限はフローに紐づく接続アカウントが持ちます。

投稿者表示（User / Bot）= 見た目
実際の権限            = 接続に使っているアカウント ← これがすべて

接続アカウントが無効になる（退職・異動・ライセンス失効）と、フローはエラーで停止します。Flow botに設定していても、裏側の接続は個人アカウントのままであるため、注意が必要です。

フロー共有時の注意点

フローを他のユーザーと共有しても、接続はデフォルトでは共有されません。共有された側のユーザーが実行するとエラーになるため、各自が接続を作り直す必要があります。

異動・組織変更に備えたベストプラクティス

対策A：引き継ぎ時に接続アカウントを切り替える

異動の際に後任メンバーを共同所有者に追加し、Teamsアクションの「接続の変更」で後任アカウントに紐付け直します。最低限の対応として有効です。

対策B：サービスアカウントを使う（最も安定）

構成要素 内容
接続アカウント 部門用共有アカウント（例: dept-system@example.com）
投稿者 Flow bot
フロー所有者 複数人で共同所有

この構成なら、誰が異動しても接続が切れず、表示も個人名に依存しないため最も安定した運用が可能です。

投稿先ごとのアクション設定の違い

基本的には「チャットまたはチャネルでメッセージを投稿する（V3）」の1アクションで大半に対応できますが、投稿先によって入力項目が変わります。URLを貼り付ける方式ではなく、内部的にTeam ID・Channel ID・Chat IDで管理されている点に注意してください。

チャネルへの投稿

投稿者：Flow bot
投稿先：Channel
Team  ：▼ 営業部
Channel：▼ 一般
メッセージ：…

TeamとChannelをドロップダウンで選択するだけです。URLの入力は不要です。

1対1チャットへの投稿

投稿者  ：Flow bot
投稿先  ：Chat
Recipient：tanaka@example.com
メッセージ：…

Team / Channelの選択欄は表示されません。「どこに送るか」ではなく「誰に送るか」の設計になります。

グループチャットへの投稿

投稿者  ：Flow bot
投稿先  ：Group chat
Chat ID ：xxxxxxxx
メッセージ：…

チャネルのような一覧選択ができないケースが多く、Chat IDを別途取得する必要があります。3種類の中で最も設定難易度が高いため、業務フローでは極力避けるのが無難です。

Microsoft Lists × Power Automateフローでの推奨設計

業務フロー（見積依頼・承認・回答通知など）における通知先の使い分けは以下が基本です。

通知内容 投稿先 理由
新規登録・進捗更新 チャネル 関係者全員で状況を共有できる
承認依頼・確認依頼 個人チャット 担当者・承認者が見逃しにくい
グループチャット 原則使わない 運用が不安定・設定難易度が高い

部門全体に知らせる情報はチャネルへ、担当者だけに知らせる情報は個人チャットへという使い分けが、通知の整理と運用のしやすさを両立する基本設計です。

まとめ

  • 投稿先はチャネル・個人チャット・グループチャットの3種類
  • 投稿に必要な権限はOwnerではなくメンバー資格（ただしプライベートチャネルはチャネルメンバーであることが必須）
  • 投稿者の表示（Flow bot / User）は見た目の設定。実際の権限は接続アカウントが持つ
  • 異動リスクに備えるならサービスアカウント＋Flow bot＋共同所有の構成が最も安定
  • 投稿先ごとに入力項目が変わる。URLではなくドロップダウン選択またはID指定で設定する

Microsoft Teams チャネル作成時の「おすすめ表示」設定を徹底解説｜見落とし防止に使える機能と注意点

はじめに

Microsoft Teams でチャネルを作成する際、「ユーザーがこのチャネルを自分のチャネル リストに表示することをお勧めします」というオプションにチェックを入れると、どのような挙動になるのかをまとめました。

この設定でできること

チームメンバーの画面に自動で表示される

チャネル作成時にチェックを入れると、チームに参加している全メンバーのチャネル一覧に、そのチャネルが 最初から表示された状態 で追加されます。通常は折りたたまれて非表示になりがちなチャネルも、メンバーがすぐに目にできる状態になります。

下記のように「非表示にする」が選択できる状態(表示された状態)になります。

重要チャネルの見落とし防止に有効

全員に必ず確認してほしい連絡用チャネルや、プロジェクト開始時の共有スペースとして活用する際に特に効果的です。

注意点・仕様まとめ

⚠️ 強制的に固定し続けるわけではない

これはあくまで 「初期状態として表示を推奨する」 設定です。メンバー各自が後から「非表示」に変更することは可能であり、全員の表示状態を管理者が完全にコントロールするものではありません。

⚠️ チャネル作成時にしか設定できない

この設定が有効なのは、チャネルを作成するその瞬間のみ です。既存のチャネルに対して、後から管理者が全メンバーの画面に一括表示させることはできません。既存チャネルを全員に表示させたい場合は、各自に手動で「表示する」操作をしてもらう必要があります。

✅ 後からチームに参加したメンバーにも適用される

チャネル作成後に新しくチームへ加わったメンバーに対しても、そのチャネルが 最初から表示された状態 になります。新規参加者への案内コストを減らせる点もメリットです。

まとめ

項目 内容
設定のタイミング チャネル作成時のみ
効果 全メンバーの一覧に初期表示
後からの変更（メンバー側） 非表示に変更可能
後からの一括適用（管理者側） 不可
後参加メンバーへの適用 適用される

チャネルを新規作成する際は、メンバーに積極的に見てほしい場所かどうかを判断したうえで、このオプションを活用しましょう。

Microsoft Teams：共有チャネルとプライベートチャネルの違い

はじめに

Teams でチームの一部メンバーだけが使えるチャネルを作る方法として、共有チャネル（「チームの全員と共有する」のチェックなし） と プライベートチャネル の2種類があります。どちらも「限られたメンバーだけに見せる」点では似ていますが、招待できる相手の範囲と柔軟性に根本的な違いがあります。

決定的な3つの違い

1. 外部組織（他テナント）のユーザーを招待できるか

共有チャネル（チェックなし） プライベートチャネル
外部招待 直接招待できる（相手は組織の切り替え不要） 先に親チームへゲスト登録が必要

共有チャネルでは、他社のTeamsユーザーをチャネル単体に直接招待できます。相手は自分のTeams画面のままチャネルに参加できるため、利便性が高いです。一方、プライベートチャネルでは、外部ユーザーをチャネルに追加する前に、必ず親チームへ「ゲスト」として登録する手順が必要になります。

2. 社内の別チームをまるごと招待できるか

共有チャネル（チェックなし） プライベートチャネル
他チーム招待 チーム単位で招待できる 個人単位のみ

共有チャネルは、親チーム以外の社内チームをまるごと招待できます。部署横断プロジェクトなどで活躍します。プライベートチャネルは個人を1人ずつ追加する方式に限られます。

3. 親チームのメンバー・所有者との関係

共有チャネル（チェックなし） プライベートチャネル
参加できる人 招待された人なら誰でも（親チーム外・組織外も可） 親チームに所属する人の中から選ばれた人のみ
チーム所有者の扱い 未招待の所有者はコンテンツを閲覧不可 チャネルの存在を把握でき、自分をメンバーに追加することは可能

共有チャネルは「親チームに属しているかどうか」を問わず、招待された人が参加するスタイルです。プライベートチャネルは、あくまで親チーム内のメンバーに限定される閉じた空間です。

機能比較まとめ

機能・特徴 共有チャネル（チェックなし） プライベートチャネル
参加できる人 招待された人なら誰でも 親チームの所属メンバーのみ
外部組織の招待 直接招待可（相手の組織切り替え不要） 親チームへゲスト登録後に招待可
他チームの招待 チーム単位で可能 不可（個人単位のみ）
親チーム所有者の権限 未招待なら閲覧不可 管理権限で自己追加は可能
Teams上での表示 別チームとして表示されることがある 親チーム内にぶら下がる構造

どちらを選ぶべきか

共有チャネルが向いているケース

  • 社内の別部署（他チーム）や外部の取引先と直接やり取りしたいとき
  • そのためだけに新しいチームを作るのが手間なとき
  • 部署横断・プロジェクト型の連携に最適

プライベートチャネルが向いているケース

  • 同じチーム内でマネージャー層や人事関連など、一部メンバーだけのクローズドな場を作りたいとき
  • 親チームの外には情報を出したくない機密のやり取りに最適

一言まとめ

共有チャネル：境界を越えるためのチャネル
プライベートチャネル：境界の中で絞るためのチャネル