こんにちは！開発現場を渡り歩く、君の専属アジャイルコーチだ。
突然だけど、こんな悩みを抱えていないかい？
「Confluenceを導入したはいいものの、どこまで情報をオープンにしていいか分からず、結局みんなが隠し部屋（プライベートスペース）にこもって情報のサイロ化が起きている……」
「外部のパートナー企業や業務委託メンバーが入ってきた途端、見せてはいけない設計書まで見えてしまいそうになり、慌ててアクセス権をガチガチに固めた結果、社内の誰もドキュメントを書かなくなった……」
わかるよ。セキュリティと情報共有のオープンさは、常にトレードオフのジレンマだ。ガチガチに縛ればナレッジ共有は死に、オープンにしすぎればコンプライアンスの地雷を踏む。
でも、安心してほしい。Confluenceの権限管理の「構造」さえ理解してしまえば、「安全なのに、誰もが自由に知識を持ち寄れる黄金のナレッジ空間」は簡単に作れるんだ。
今回は、Confluenceの権限管理で絶対に失敗しないための完全ガイドを、初心者にも分かりやすく、しかし現場で即役立つプロの知見をたっぷり詰め込んで伝授しよう。これをマスターすれば、明日のチームの働き方が劇的に変わるはずだ！
—
1. そもそもConfluenceの権限管理とは？（ツールの役割と基本思想）
まず、Confluenceというツールの本質を思い出そう。Confluenceは単なる「ファイルの置き場所」じゃない。「組織の脳みそ（ナレッジベース）」だ。
脳みその一部だけをラップでグルグル巻きにして隠したら、人間はどうなる？ そう、思考停止するか、全体最適ができなくなるよね。だから、Confluenceの基本思想は「デフォルトで全社公開、例外的に制限する」のがアジャイル開発の鉄則だ。
Confluenceの権限管理は、大きく分けて3つの階層で成り立っている。この階層を混同するから、管理者が発狂するハメになるんだ。
1. グローバル権限（Global Permissions）: Confluence全体に対する権限（「誰がログインできるか」「誰が新しいスペースを作れるか」）
2. スペース権限（Space Permissions）: スペース（プロジェクトや部署ごとの部屋）単位の権限（「誰がこのプロジェクトの部屋に入り、読める・書けるか」）
3. ページ制限（Page Restrictions）: 個別ページ単位の鍵（「この特定の議事録だけ、マネージャー層だけに隠す」）
この3つのレイヤーを「ロシア人形（マトリョーシカ）」のようにイメージしてほしい。外側をしっかり設計すれば、内側で無駄に悩む必要がなくなるんだ。
—
2. 基礎セットアップ：絶対に守るべき「3つのレイヤー」の使い分け
それでは、実際に手を動かして（あるいは設定画面をイメージして）、最も美しく、破綻しない権限のセットアップ手順を見ていこう。
レイヤー1：グローバル権限は「少数精鋭」でガチガチに
まず、Confluence全体の門番の設定だ。ここはシステム管理者（Jira/Confluence管理者）が厳重に管理する。
- 「Confluence 使用 (Use Confluence)」: ライセンスを持っている社内メンバー全員に付与する。
- 「スペースの作成 (Create Spaces)」: ここが最初の罠だ！ 全員に許可すると、カオスな重複スペースが乱立する。基本的には「チームリード」や「スクラムマスター」など、一定の権限を持ったロールだけに絞るのが、荒らされないための極意だ。
レイヤー2：スペース権限は「グループ単位」で制御する（個別ユーザー禁止の原則！）
現場で一番やってはいけないアンチパターンがこれだ。
❌「Aさん、Bさん、Cさんに個別にスペースの閲覧・編集権限をポチポチ付与する」
これをやると、メンバーの異動や退職が発生した瞬間に、権限のメンテ漏れという名の「セキュリティホールの温床」が完成する。
【正解のセットアップ手順】
1. Atlassian管理（または組織のディレクトリ）側で、適切なグループを作る。
- 例：`dev-team-backend`（バックエンド開発者グループ）
- 例：`all-employees`（全社社員グループ）
- 例：`external-partners`（外部パートナー企業グループ）
2. Confluenceのスペース設定の「権限（Permissions）」画面を開く。
3. 個別ユーザーではなく、必ず「グループ」に対して権限を付与する。
| グループ名 | 閲覧 (View) | 作成 (Create) | 削除 (Delete) | コメント (Comment) |
| :— | :—: | :—: | :—: | :—: |
| `all-employees` | 🟢 (社内公開スペースの場合) | ❌ | ❌ | 🟢 |
| `dev-team-backend` | 🟢 | 🟢 (ページ作成) | 🟡 (自分のもののみ) | 🟢 |
| `external-partners` | 🟢 (一部制限) | 🟡 (下書きのみ) | ❌ | 🟢 |
※こうすることで、メンバーの出入りは「グループへの所属変更」だけで完結し、Confluence側の設定をいじる必要がなくなる。これがプロの管理術だ。
レイヤー3：ページ制限は「最後の麻酔」として慎重に使う
スペースの中にある特定のページだけ隠したいとき、ページの右上の「鍵アイコン（Page Restrictions）」を押したくなるよね。
- 全員 (Everyone)
- 特定のユーザーやグループ (Select users and groups)
- 編集のみ制限 / 閲覧・編集ともに制限
この機能は非常に強力だけど、「乱用するとドキュメント迷宮への片道切符」になる。
なぜなら、管理者が「どこに何を隠したか」を数ヶ月後に完全に忘れてしまい、誰もアクセスできない「幽霊ページ」が量産されるからだ。
【黄金律】
- 原則：ページ制限は使わない（スペース単位の権限でコントロールする）。
- 例外的に使うケース：人事評価、給与関連、経営陣のストックオプションに関する議事録など、法的・倫理的にどうしても隠さなければならないものだけに限定する。
—
3. 実践！外部パートナーを含めた安全な運用ルール設計のHelloWorld
理論が分かったところで、今日からすぐに使える「外部パートナー（協力会社）がプロジェクトに参加するシナリオ」を想定した、精度の高い実践レシピ（HelloWorld）を作ってみよう。
🎯 シナリオ
- 自社開発チーム（A社）に、外部の受託開発パートナー（B社）が参画する。
- B社のメンバーには、自分たちのプロジェクトスペースの「仕様書」を見せたいし、議論（コメント）もさせたい。
- しかし、B社に「社内の他のプロジェクトの極秘情報」や「全社人事情報」は見せたくない。
🛠️ ステップ・バイ・ステップの設定手順
ステップ1：外部パートナー専用の「グループ」を作成する
Atlassian Administration（または利用しているID管理基盤）で、新しいグループを作る。
- グループ名：`partner-b-vendors`
- B社所属のメンバーのメールアドレスをこのグループに登録する。
ステップ2：プロジェクト専用スペースを新設する
- スペース名：「次世代ECプラットフォーム開発」
- スペースキー：`NGEP`
ステップ3：スペース権限のカスタマイズ（ここがキモ！）
`NGEP`スペースの「スペースの設定」＞「権限」を開き、以下のように設定を流し込む。
1. `all-employees`（全社グループ）の権限設定
- 閲覧：🟢 チェック（社内ニートや他部署のメンバーも、好奇心から見に来れるようにする＝知のオープン化）
- 編集：❌ チェックなし（勝手に仕様を変えられたら困るため）
2. `dev-team-backend`（自社開発チーム）の権限設定
- 閲覧：🟢
- 編集：🟢
- ページ・コメント削除：🟢
3. `partner-b-vendors`（外部パートナーグループ）の権限設定
- 閲覧：🟢（仕様書やタスクボードは見られる）
- 編集：🟢（詳細設計の追記や、アイデアのページ作成は許可する）
- コメント：🟢（活発な議論を促進する）
- スペースの削除・管理：❌（絶対に外すこと！）
ステップ4：【重要】見せたくない「隣の部屋」の鍵をかける
外部パートナー（`partner-b-vendors`）は、グローバル権限で「Confluenceの使用」が許可されているため、他の公開スペースのタイトルが見えてしまうことがある。
もし「他プロジェクトの存在すら隠したい機密案件」がある場合は、その別のスペースの「スペース権限」において、`partner-b-vendors` グループの「閲覧（View）」のチェックを完全に外す（あるいは含めない）こと。
これで、彼らの視界には「自分たちが許可された部屋」しか映らなくなる。
—
4. 先輩エンジニアからの現場の知恵（アンチパターンと回避策）
最後に、数々の現場で崩壊したConfluenceを見てきた私が、失敗しないための「生きた教訓」をいくつか授けておこう。
- アンチパターン1：個人のプライベートスペースに重要ドキュメントを溜め込む
- 回避策：「個人スペースでの業務ドキュメント作成禁止」をチームの合意（チームワーキング・アグリーメント）にしよう。情報はすべてパブリック（チームスペース）に置くのがアジャイルの鉄則だ。
- アンチパターン2：退職者の個別権限が残り続ける
- 回避策：前述した通り、個別ユーザーへの権限付与を禁止し、IdP（OktaやGoogle Workspaceなど）とAtlassian Cloudを連携させて、退職と同時にグループから自動脱退する仕組みを必ず作ろう。
- アンチパターン3：鍵をかけすぎて誰も編集できない「要塞」ができる
- 回避策：「迷ったらオープンにする」文化を育てること。ドキュメントは不完全でも公開し、みんなで育てていく（Wikiの精神）方が、結果的に品質が上がる。
—
まとめ
Confluenceの権限管理は、難しく考える必要はない。
1. グローバル権限で門番をしっかり置く
2. スペース権限は「グループ単位」で美しく設計する
3. 個別ページの制限は「最後の麻酔」として極力使わない
この3つを守るだけで、セキュリティの担保と、心理的安全性のあるオープンなナレッジ共有が両立できる。
これをマスターすれば、あなたのチームの情報の流れは見違えるようにスムーズになり、毎日の開発作業やドキュメント作成が劇的に楽になるはずだ。
さあ、今すぐチームのスペースの権限設定を見直して、最高の「組織の脳みそ」を作り上げよう！