<style>
.sc-hero{padding:clamp(24px,5vw,46px);border-radius:24px;background:linear-gradient(130deg,#1e1b4b,#5b21b6 55%,#0f766e);color:#fff}.sc-hero h2{color:#fff}.sc-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:22px 0}.sc-card{padding:18px;border:1px solid #ddd6fe;border-radius:16px;background:#f5f3ff}.sc-card strong{display:block;color:#6d28d9;font-size:1.35rem}.sc-flow{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:24px 0}.sc-step{padding:18px;border-radius:16px;border:1px solid #c4b5fd;background:#faf5ff;text-align:center}.sc-step b{display:block;color:#6d28d9}.sc-table{overflow-x:auto}.sc-table table{min-width:680px;width:100%;border-collapse:collapse}.sc-table th,.sc-table td{padding:11px;border:1px solid #cbd5e1;text-align:left;vertical-align:top}.sc-table th{background:#ede9fe}.sc-note{padding:18px;border-left:5px solid #f59e0b;border-radius:12px;background:#fffbeb;margin:20px 0}@media(max-width:720px){.sc-grid,.sc-flow{grid-template-columns:1fr}}
</style>
BUSINESS AUTOMATION / 実務ガイド
外部招待を「全部自動承認」にしない
Slack Connectの招待をAPIでさばくなら、信頼できる相手は許可、禁止対象は拒否、判断材料が足りない依頼は人手確認へ。まず適用範囲と例外を理解することが重要です。
許可契約済み企業など条件を満たす依頼
拒否明示的な禁止条件に該当する依頼
確認個人メールや用途が不明な依頼
3行要約
- Slack公式資料によると、Enterprise組織ではSlack Connectの外部招待に送信前の自動承認ルールを適用できます。
shared_channel_invite_requestedイベントを受け、conversations.requestSharedInvite.approveまたはdenyで処理する構成が案内されています。- 対象は自社所有チャンネルへの自社メンバー発の招待に限られ、管理者や一部Botの依頼はルールを通らないため、別の監査が必要です。
背景：外部との共同作業は招待が境界になる
Slack Connectは別組織の人とチャンネルで協働する機能です。取引先との連携に便利な一方、招待時に相手先や目的の確認が曖昧だと、機密情報を扱うチャンネルへ想定外の人を迎える可能性があります。件数が増えた場合、すべてを管理者の手作業で確認する方法も負担になります。
何ができるのか
Slackの管理者向け資料は、Enterprise組織で招待送信前の自動化ルールを有効にし、Slack Connect APIで承認・拒否を実装できると説明しています。Slack Developer Docsはメールドメインを例に、許可・拒否・追加情報要求へ振り分けるワークフローを示しています。この記事は2026年9月25日時点の実務ガイドであり、同日に新機能が発表されたという意味ではありません。
1 依頼メンバーが外部招待を要求
2 判定イベントと組織ルールで分類
3 結果許可・拒否・人手確認へ
| 分類 | ルール例（編集部案） | 注意点 |
|---|
| 自動承認 | 契約済み企業のドメイン、許可済み用途 | ドメインだけで本人や契約状態を保証しない |
| 自動拒否 | 禁止ドメインや明確なポリシー違反 | 誤拒否への再申請経路を用意 |
| 人手確認 | 個人メール、判断材料不足、例外申請 | 依頼理由と責任者を記録 |
この表は公式チュートリアルの考え方を基にした編集部の運用例です。ドメインを見て機械的に全件承認することをSlackが推奨しているわけではありません。
導入手順と実践例
- 組織管理者が、Slack Connect設定で「Apply automation rules before channel invitations are sent」を有効にします。招待依頼を許可するチャンネル側の設定も確認します。
- ワークフローアプリに
conversations.connect:manageスコープを付与し、管理者の承認を受けます。これは招待管理の強い権限なので、専用アプリと最小権限の運用が適切です。
shared_channel_invite_requestedを受け、許可条件・拒否条件・人手確認条件を評価します。- 条件が明確な場合のみ
conversations.requestSharedInvite.approveまたはconversations.requestSharedInvite.denyを呼びます。判断不能なら管理者の確認経路に残します。
- テスト用チャンネルで許可・拒否・保留・例外の4ケースを試し、結果と監査方法を記録します。
Slackの開発者ドキュメントには、Deno Slack SDKでアプリを作る具体例があります。実装前には、契約先の一覧と承認者、失敗時の手動処理を決めておくとよいでしょう。
技術的なポイント：2種類の承認を混同しない
招待を送信する前の依頼を処理するAPIはconversations.requestSharedInvite.approveとdenyです。一方、相手が招待を受けた後のチャンネル承認にはconversations.approveSharedInviteが使われます。タイミングの違う処理なので、イベントと招待IDの出所を混同しないでください。
企業への影響と限界
自動化の外側を残さない。公式チュートリアルでは、対象は自社メンバーが自社所有チャンネルへ送る外部招待です。管理者・承認権限者や`conversations.connect:manage`権限を持つBotの依頼は暗黙に通過し、ルールで保留されません。
- 複数人DMからプライベートチャンネルへの変換は招待として扱われず、このルールの対象外です。
- 無料プランではワークフローアプリの利用条件が異なります。プランと管理者権限を確認してください。
- 自動承認が正しくても、チャンネル内に何を共有してよいかという情報分類は別の課題です。
今後注目すべき点
運用開始後は、許可・拒否・人手確認の件数、誤判定、対象外の招待経路を定期的に見直すべきです。取引先の契約終了やドメイン変更に合わせてルールを更新しないと、古い許可条件が残ります。
最終確認日：2026年9月25日
参照元（一次情報）