- Microsoft Teamsには、チーム・チャネル・チャット・会議・ファイル共有全般にわたって運用上の制限が細かく設定されており、チャネル名には
CON、PRN、AUX、NUL、COM1～COM9、LPT1～LPT9 のような MS-DOSデバイス名を使用できない
- 1チームあたりのメンバー数は25,000人、1ユーザーあたりのチーム メンバーシップは1,000件、1チームあたりのチャネル数は1,000件が上限で、削除済みチャネルも30日間の復元期間中は引き続き上限に含まれる
- チャットはプライベート チャット250人、チャット起点の音声・ビデオ通話20人、添付10件、ファイル100MBが基準で、20人を超えると通話・入力インジケーター・既読通知などの機能が無効になる
- 会議はプランに応じて最大300人または1,000人まで開催でき、Teams会議・ウェビナー・タウンホールには30時間制限があり、ブレイクアウト ルームは300人未満の会議でのみ作成できる
- ファイル共有はSharePointとOneDrive for Businessに依存するため、SharePointが無効化されたテナントでは制約が生じ、Teamsファイルはサイトまたはグループあたり25TB、ファイル アップロードは1ファイルあたり250GBまで可能
チームとチャネルの上限
- ユーザーが作成できるチーム数は、Microsoft Entra IDの250オブジェクト制限に従い、グローバル管理者はこの制限の対象外
- ユーザーがメンバーとして参加できるチームは1,000件までで、アーカイブ済みチームも含まれる
- チーム単位の主な上限は以下のとおり
- メンバー: 25,000人
- 所有者: 100人
- 組織全体チーム: テナントあたり5件
- 組織全体チームのメンバー: 10,000人
- Microsoft 365 または Office 365 組織のチーム数: 500,000件
- グローバル管理者が作成できるチーム数: 500,000件
- 1チームあたりのチャネルは最大1,000件で、標準チャネルと共有チャネルの組み合わせに、最大30件のプライベート チャネルを含む
- 削除済みチャネルは30日間復元でき、この期間中はチームあたりのチャネル上限およびプライベート チャネル上限に引き続き計上される
- チャネル会話の投稿は、投稿1件あたり約100KBまでで、本文、画像リンク、@メンション、コネクタ数、リアクションを含む
- base64エンコード画像は100KB制限に含まれない
共有チャネルの制約
- 共有チャネルは1チームあたり最大1,000件まで可能で、削除済みチャネルは30日間の復元期間中も含まれる
- 1つの共有チャネルは、親チームを除いて最大50チームと共有できる
- 共有チャネルのメンバーは直接メンバー5,000人まで可能で、共有されたチームは上限計算で1チームあたり1人として数えられる
- リアルタイム更新は一度に25,000人にのみ提供される
- チャネル一覧には25,000人のみ表示される
- 外部参加者はMicrosoft Entraの職場または学校アカウントのみサポート
- 共有チャネルはタブをサポートするが、Stream、Planner、Formsは除外される
- ボット、コネクタ、メッセージ拡張機能は共有チャネルでサポートされない
- 組織全体チームは共有チャネルのメンバーとして追加できない
- 既存チームから新しいチームを作成する場合、既存チームの共有チャネルはコピーされない
- 共有チャネルの通知は、見逃したアクティビティのメールに含まれない
- 共有チャネルはクラス チームではサポートされない
チャネル名の禁止ルール
- チャネル名には次の文字を使用できない
~ # % & * { } + / \\ : < > ? | ' " , ..
- 次の文字範囲も使用できない
- 次の単語はチャネル名に使用できない
formsCON, CONIN$, CONOUT$PRN, AUX, NULCOM1～COM9LPT1～LPT9desktop.ini_vti_
- チャネル名はアンダースコア
_ またはピリオド . で始めることはできず、ピリオド . で終えることもできない
メッセージングとチャット
- Teamsチャット一覧に含まれる会話は、参加者のExchange Onlineメールボックスに保存される
- 管理者がチャット会話を検索または保持するには、参加者にクラウドベースのExchange Onlineメールボックスが必要
- Exchangeハイブリッド展開でオンプレミス メールボックスのユーザーがTeamsチャットに参加することは可能
- この場合、その会話コンテンツは検索または保持できない
- プライベート チャットの主な上限は以下のとおり
- 人数: 250人
- 1回でグループ チャットに追加できるメンバー: 200人
- チャットから開始した音声・ビデオ通話: 20人
- 添付ファイル: 10件
- ファイル サイズ: 100MB
- チャット投稿サイズ: 約100KB
- チャット人数が20人を超えると、次の機能が無効になる
- Outlook自動返信とTeams状態メッセージ
- 入力インジケーター
- 音声・ビデオ通話
- 共有
- 既読通知
Set Delivery Options ボタン
- メッセージ配信成功率を高めるには、メッセージ自体のサイズを80KB以内に保つことが推奨される
- 試用版サブスクリプション テナントでは悪用防止のため、より厳しいメッセージング制限が適用される場合があり、制限は予告なく調整されることがある
- 外部アクセスで信頼済みドメインのみを許可する管理者は、最大4,000件の信頼済みドメインを追加できる
チャネルメール
- チャネルのメール アドレスに送信されたメールはチャネルの一部となり、誰でも返信して会話を開始できる
- チャネルにメールを送る際の上限は以下のとおり
- メッセージ サイズ: 24KB
- 添付ファイル: 20件
- 添付ファイルあたりのサイズ: 10MB未満
- インライン画像: 50件
- 上限を超えると動作が変わる
- メッセージが24KBを超えるとプレビュー メッセージが生成され、ユーザーは提供されたリンクから元のメールをダウンロードして確認する必要がある
- 添付ファイルや画像の数が上限を超えるとエラー メッセージが表示される
- チャネルメールにはレート制限が適用される
- チャネルあたりユーザーごとに10秒間で6通のメール
- テナントあたりユーザーごとに10秒間で8通のメール
- チャネルメールは、Office GCC/GCCH/DOD 組織向け Teams では使用できない
会議と通話
- Microsoft 365 Business Basic、Business Standard、Business Premium、Microsoft Teams Essentials、Microsoft 365 A1 プランでは、Teamsオンライン会議とビデオ通話を最大300人までホストできる
- Microsoft 365 F1/F3/E3/E5/A3/A5/G3/G5、Office 365 E1/E3/E5/A3/A5/G1/G3/G5、Microsoft Teams EEA プランでは、上限が最大1,000人まで拡張される
- 会議関連の主な上限は以下のとおり
- チャットから開始した音声・ビデオ通話: 20人
- PowerPointファイルの最大サイズ: 2GB
- Microsoft Streamにアップロードされていない会議録画のローカル ダウンロード可能期間: 20日
- 会議録画の最大長: 4時間または1.5GB
- 録画が最大長または容量に達すると、録画は終了し自動的に再開される
- ブレイクアウト ルームは、参加者が300人未満の会議でのみ作成できる
- ブレイクアウト ルームを作成すると、会議参加者数は自動的に300人に制限される
- Teams会議、ウェビナー、タウンホールには30時間の時間制限がある
会議の有効期限
- 会議の有効期限は、PSTNダイヤルイン番号、CVI座標、既定の会議ポリシーと設定に適用される
- 有効期限前に会議に参加するか会議が更新されると、Meet now 会議を除いて有効期限上限に60日が追加される
- パブリック プレビュー時点では、新しいリンクと会議は条件に応じて有効期限が設定され、有効期限後はリンクから参加できない
- 予定された単発会議: 予定された会議時刻の60日後
- カレンダーまたはチャネルで予定された Meet now: リンク作成の60日後
- グループ チャットで予定された Meet now: 該当なし
- 終了日がある定期会議: 終了日から60日、または最後の発生日から60日のいずれか長い方
- 終了日がない定期会議: 最後のアクセス、参加、会議更新から1年
ライブ イベント
- Teamsライブ イベントは2026年7月に終了予定
- すでに予定済みのイベントは2027年2月28日までサポートされる
- Microsoftは大規模なデジタル・ハイブリッド イベントにTeamsタウンホールを使用することを推奨している
- 基本のライブ イベント上限は以下のとおり
- 参加者: 最大10,000人
- イベント時間: 4時間
- Microsoft 365 または Office 365 組織で同時実行できるライブ イベント: 15件
- プロデューサーがライブ イベントに参加した時点で、そのイベントは実行中と見なされる
- 16件目のライブ イベントに参加しようとするプロデューサーはエラーを受け取る
- 一時的な上限引き上げは追加告知まで延長される
- 参加者最大20,000人
- テナント全体の同時イベント50件
- 配信あたり16時間
- Microsoft 365 assistance program を通じて、最大100,000人参加のライブ イベントを計画でき、チームが各リクエストを評価して利用可能なオプションを決定する
ストレージとファイル共有
- 各TeamsチームにはSharePointチーム サイトがあり、各チャネルには既定のチーム サイトのドキュメント ライブラリ内にフォルダーが作成される
- 会話で共有されたファイルは自動的にドキュメント ライブラリに追加され、SharePointで設定した権限とファイル セキュリティ オプションがTeamsに反映される
- 各プライベート チャネルには個別のSharePointサイトがある
- テナントでSharePointが有効化されていない場合、Teamsユーザーはチームで常にファイル共有できるとは限らない
- プライベート チャットでファイルを共有するには、SharePointライセンスに紐づいたOneDrive for Businessが必要
- Teamsファイル共有はSharePointバックエンドで動作するため、TeamsのFilesセクションにはSharePointの制限が適用される
- 表示されたプランのストレージ上限は以下のとおり
- 組織あたり1TB + 購入したライセンスごとに10GB
- Office 365 Enterprise F1 は組織あたり1TB
- Teams Files はサイトまたはグループあたり最大25TB
- ファイル アップロード上限は1ファイルあたり250GB
- チャネルはチーム用SharePointサイト内のフォルダーで支えられているため、チャネルのファイル タブは所属チームのストレージ上限を共有する
教育向けクラス チームとタグ
- Microsoft Teams for Education は、教室授業のような教育シナリオ向けテンプレートを提供する
- クラス チームの利用にはOffice 365 Educationライセンスが必要
- クラス チームは通常のチーム メンバー上限に従うが、特定アプリには別個の制限がある
- Assignments アプリの使用: メンバー1,000人
- OneNote Class Notebook アプリの使用: メンバー300人
- クラス チームはより多くのメンバーをサポートできるが、Assignments または Class Notebook を使う予定があるなら、上記上限未満に保つ必要がある
- タグの上限は以下のとおり
- 1チームあたりのタグ: 200件
- 1チームあたりの推奨既定タグ: 25件
- タグに割り当て可能なチーム メンバー: 200人
- ユーザーあたりチーム内で割り当て可能なタグ: 25件
連絡先とブラウザー サポート
- Teamsは組織のActive Directory連絡先と、ユーザーのOutlook既定フォルダーに追加された連絡先を使用する
- Teamsユーザーは組織のActive Directoryにいる誰とでも通信でき、
Chat > Contacts または Calls > Contacts から連絡先一覧に追加できる
- 組織のActive Directoryにいない人も
Calls > Contacts から連絡先として追加できる
- OutlookのTeams presence は Outlook 2013 デスクトップ アプリ以降でサポートされる
- ブラウザー サポートは機能ごとに異なる
- Internet Explorer 11 は通話をサポートせず、PSTN座標がある会議のみ限定的にサポートする
- 最新の Microsoft Edge Chromium と Google Chrome は通話と会議を完全にサポートする
- Firefox は通話をサポートしないが会議はサポートし、完全サポートには OpenH264 プラグインが必要
- Safari はバージョンに応じて1:1通話、ビデオ、共有のサポート範囲が異なる
- ブラウザーでのTeams会議は単一ストリームに制限され、現在の発言者の受信映像または画面共有のいずれか1つのみが表示される
- 共有中に制御権を受け渡しするには、双方ともTeamsデスクトップ クライアントを使用する必要があり、ブラウザーではサポートされない
2件のコメント
Windows との下位互換性のためにこうしたのだと思います。
でも最近の開発者は、COM、LPT、PRN みたいなものを知らないのではないかと思います（笑）
「なぜハードディスクは C から始まるんですか？」みたいな質問も時々見かけますし……
Hacker News の意見
1998年ごろ、10代の Linux 狂信者として LAN パーティーに Linux ボックスを持ち歩いていたが、実際かなりうまく動いていた。
当時の WINE はほぼ StarCraft 対応のために存在していて、Quake 2 はネイティブで動き、その2つでみんなが遊んでいたゲームの95%はカバーできていた。
あるとき、ネットワーク上のすべての Windows 共有を巡回して
CON/CONを開いてみるシェルスクリプトを実行したら面白いだろうと思ったのだが、各マシンが即座に ブルースクリーンを出し、友人たちは不思議なことに面白がってくれなかった。私の BSD 仲間みたいにネットワークのトラブルシュートがうまく、予備の CAT-5 ケーブルをいつも持ってきていたなら、十分に埋め合わせできたと思う。
Wine で StarCraft を動かすくらい Linux を使っていた時期には、もう IP をサポートしていた気がする。
昔、友人たちと StarCraft をやった思い出はとても良いもので、あのゲームは中学のころにハマって、大学のころにまたハマれるほど息の長いゲームだった。
古き良き思い出だ。
これは Windows ファイルシステムで、そのような名前をファイルやフォルダに使えないからである可能性が高い。
MS Teams チャネルは、ファイル添付が保存される SharePoint 内に対応するフォルダを作成する。
あるトレーダーがブック名を LPT1 にしたときに問題が起きた。
%と..もブラックリストに入れているようだ。ユーザーがサポートチケットを開かなくてもリソースへのアクセス権を管理できる、とても簡単な方法なので、使うのはかなり悪くない。
最初は「これは内部にひどい何かがあることを事実上漏らしているのではないか。公にこんなことを言うのは恥じるべきだ。
%sや$PS1が使えないと言っているのと似ているが、なぜダメなのか？ ユーザー入力でいったい何をしているのか？」と言おうとしていた。しかし、チャネル名を他の場所でどう扱うかに関する問題なのかもしれない。人々はどこにでもコピー＆ペーストできるし、Windows ユーザーが
cmd、PowerShell、WSL に貼り付けるときに自分の文字列を自分でエスケープするとは期待していないようだ。Teams のコード自体はおそらくうまく処理できるだろうが、チャネル名を扱える外部のあらゆる正体不明で粗雑なツールが問題になり得る。
他の人たちはチャネルに紐づく SharePoint フォルダを指摘していたが、ディレクトリ用の安全なバージョンを作るためにエスケープしたり変形したりエンコードしたりするのは簡単なので、個人的には免罪符を与えにくい。ただし、どこかではチャネル名とディレクトリ名が同一でなければならないことが重要なのかもしれない。
アプリ内だけで使うなら、チャネル名とディレクトリ名を同じ方法でエンコード/デコードし、ユーザーには完全に隠せばよいが、ディレクトリをアプリの外でも使うなら、URL エンコードのような形がそのまま表示されて見栄えが悪くなる。
結局、ディレクトリ名は他のすべてに対して安全でなければならず、だからチャネル名も同じでなければならない。たまに不格好なディレクトリ名を置くよりも、こうした制限を選んだというわけで、最終的には安全性や故障の問題というより 見た目の問題に近い。エンコードが必要だった文字をそもそも許可しないので、すべてのディレクトリが常に自然で見栄えよく見える。
名前サービス同士を変換するときにこういうことが起きる。名前サービスには通常スコープがあり、ある文脈の名前が別の文脈では違って解釈される。
Bobby Tables はよく知られているが、特殊なファイル名
-rfはどうだろう？ かつて Active Directory の通常のパスは、ファイル共有のような場所で DNS ドメイン名をほぼ暗黙に信頼していた。その「ドライブ」に実行ファイルがあり得ると気づくまでは、問題なさそうに見える。正直、その文書で
MS-DOSという文字列は見つけられなかった。追記:CON、LPT1のような参照は見つけた。SQS メッセージ本文にも、どの空白文字を使えるかについて制限がある。
なぜほとんどのチャット／会議アプリは、結局ひどいものになってしまうのだろう？ Teams がまともなアプリだった頃も覚えている。Linux デスクトップクライアントもあった
Slack が実際に速かった時期も覚えているし、Skype out が自分の携帯電話での通話より安定していた時期も覚えている
今の Slack は、組織をいくつか追加しただけで極端に遅くなる。それでも複数追加することはできる
Teams は Linux デスクトップクライアントを廃止し、Linux で使うには Chrome を経由しなければならない。ところが Office365/SharePoint の一部として使うと、「一部の」SharePoint リンクには Firefox が必要になる
結局、常にブラウザが2つ必要になる。Teams の画面共有とビデオには Chrome、一部の SharePoint リンクには Firefox を使わなければならない
結局、チャット／会議アプリはインターネットの縮図なのだ
チャットアプリは素晴らしいが、オーディオクリップも送れて共有できたらどうか、ビデオクリップも、リアルタイム映像も、お金も、会議も、カレンダー招待も、フードデリバリーの依頼も、ゲームセッションも、X も共有できたらどうか、という流れになる
X に限界はない。インターネットは X を共有するもので、チャットアプリも X を共有するものなので、実際にどこまで大きくなるかに境界はない
チャットとビデオはできる、では背景ぼかしも入れたらどうか？ くそ、Zoom には投票機能があるから、こちらにも投票を入れなければ。こうやって機能を大量に投入し、素早く反復するなら Electron を使ってもいいよね、という流れだ
そうなると、その人たちにやらせる仕事を探さなければならないからだ
これ、すごくいい。この新しいものが、90年代のごく初期、086 や 286 で動いていたMS-DOS 初期の時代を思い起こさせるところが気に入っている
Microsoft の後方互換性への執着は尊重すべきだ。まるで MS Teams のネイティブ移植版が MS-DOS 3.1 向けに作られるかのような、ありえない想像だ。もっとありそうなのは、MS Teams サーバーが古代の奇妙な独自仕様の MS-DOS 3.1 メインフレームで動いているという想像かもしれないが、やはり筋は通らない
このデバイス名の制限が Windows のファイル名にも適用されることは知っていたので、面白さをあまり求めない性格なら、それほど驚くことではない。だが面白いことが好きなら、先ほどの想像をしてみることができる
関連リンク: https://learn.microsoft.com/en-us/microsoftteams/limits-spec...
MS-DOS は80年代初頭には 8086 で動いていた
Windows 10 や 11 にはもはや DOS レイヤーもなく、Microsoft がこうした問題を直す気がない、ということに近い
ただし、パスワードをばかげて短い長さや、ひどく制限された文字セットに制限することまでは含めないでほしい
「Windows 7」「8」の次に「9」を飛ばして「10」になった理由は、コードベースのどこかにこんなコードがあるのを恐れたからだ、という噂を思い出す
if(version.StartsWith(“Windows 9”)) { /* 95 and 98 */ ... }Windows の経験はないが、少し奇妙に感じる。一方では Microsoft が後方互換性のためにやりそうなことでもあり、他方では提供するには変な API に見える
GetVersion[1] を見つけたが、これはバージョンを2つの数値で返す
[1] https://learn.microsoft.com/en-us/windows/win32/api/sysinfoa...
禁止語:
forms,CON,CONIN$,CONOUT$,PRN,AUX,NUL,COM1からCOM9,LPT1からLPT9,desktop.ini,_vti_%sや$PS1が使えないと言うのと似ているが、なぜだめなのか？ ユーザー入力でいったい何をしているのか？」と言おうとしていたただ、チャンネル名を別の場所でどう扱うかに関する問題かもしれない。人々はどこにでもコピー＆ペーストできるし、Windows ユーザーが
cmd、PowerShell、WSL に貼り付けるときに自分の文字列を自分でエスケープしてくれるとは期待していないようだそして
LPT1のような名前にも平気で書き込んでしまい、当然そのデータは受信者のプリンタへ直接流れていったユーザーデータを構造化するときの一般的なコツは、可能なら不透明な塊として扱うこと
暗号化されていて、出力することも人間が読むこともできないと想像すればよい
forms,CON,CONIN$,CONOUT$,PRN,AUX,NUL,COM1からCOM9、LPT1からLPT9、desktop.ini,_vti_ユーザー入力がそのままファイルシステムに入るためにこうしたものを制限しなければならないなら、それは失敗している。ユーザー入力を直接使うのではなく、安全なIDを与えるべきだった。
uuid4かもしれないし、チャンネル名のダイジェストのようなものかもしれない誰かが「この文字は使えません」と言ったら、怪しい匂いがすると見る。自動的に「なぜダメなのか？ これをエンコードしていない平文として使っているわけではないよな？」と考える。パスワード、ユーザー名、コメントのようにWebページに表示される内容がその例だ
ただし、これらすべてが失敗したイースターエッグという可能性もある。単に少し遊びを入れようとして、事がこじれたのかもしれない
悪いことではあるが、正直なところ目標は何なのか？ チャンネル名を含め、人々がどんな名前でも付けられるようにすることなのか？ 例えば
"rm -rf /*"のような名前だもっと良いものもある。その
rm -rfをRLOの左右方向上書き文字でfr- mrのように見えるように書くことだ本当にそれを目標にすべきなのか？ 何の問題も起きないと信じながら？
幸いLinuxでは、https://example.orgという名前のファイルは作れない。Windowsもそうではないのか？
真面目に聞くが、これは本当に問題なのか？ 問題だとしたら、どこに線を引くべきなのか？
コードポイント0は？ ハングル埋め字とRLO文字は？ こうしたものを拒否するアプリケーションはひどいと見るのか？
幸い、ファイル名に入れられるものには制限がある。そして現在の制限は十分に厳格ですらないと思う。ユーザー名も、チャンネルも、本当に多くのものも同じだ
例えばTwitterが表示可能な英数字とアンダースコアだけを許可し、最大15文字に制限していることを本当に問題だと見る人がいるのか？
これは非常に賢いやり方に見える。ユーザー名やチャンネル名にうんち絵文字を使えるようにしたいと渇望するより、はるかに良いと思う
内部の重複スラッシュは無視され、
https:というディレクトリとexample.orgというファイルを作れるためだrfよりddを使うほうがよいと思うチャンネルのタイトルがSharePointフォルダとして使われる場合なら、こうした文字列のための標準的なエスケープ方式がないのは驚きだ
このような魔法のようなデバイスファイルに依存するアプリケーションとの互換性は壊れるだろうが、SharePointが実際に
COM1と通信したいことなど絶対にないはずだすでにSharePoint側で処理されていないのが不思議だ