組織とチームで権限を設計する：Gitea の権限モデルと、無理のない割り当て方

リポジトリが数個のうちは、権限のことをあまり意識せずに運用できます。ところが、メンバーが増え、リポジトリが十数個になるころから、「このリポジトリに誰が書き込めるのか」「退職した人のアクセスは消えているのか」といった疑問が、現実の問題として表れます。

権限の設計は、あとから整理するのが特に大変な領域です。人の出入りのたびに、リポジトリごとの設定を一つずつ見直すことになるからです。Gitea には、これを避けるために、組織とチームという仕組みが備わっています。この記事では、その考え方と、無理のない割り当て方を説明します。確認した時点は2026年11月15日で、ドキュメントの最新の安定版は 28.3.0 です。

個人に権限を付ける運用が、行き詰まる理由

権限を、個人とリポジトリの組み合わせで管理する方法は、最初は分かりやすく見えます。ところが、規模が大きくなると、次のような問題が出ます。

• 変更の手間が掛け算で増えます。 10人のメンバーと10個のリポジトリがあれば、権限の組み合わせは最大で100通りです。人が一人加わるたびに、複数のリポジトリで設定を確認することになります。
• 消し忘れが見つかりにくくなります。 異動や退職で不要になった権限が、どこかに残ります。気づかないまま、古い権限が使われ続けることになります。
• 現状を説明できなくなります。 「このプロジェクトに関われる人は誰か」と聞かれても、リポジトリを一つずつ開いて確認しなければ答えられません。

個人単位の設定は、人数が少ないうちは便利でも、組織が成長する過程で、管理の負担と、見落としのリスクを増やします。これを避けるには、個人ではなく、役割の単位で権限を決める考え方が必要です。

組織とは、リポジトリとメンバーをまとめる器

Gitea の組織は、複数のリポジトリと、その関係者をまとめて管理する単位です。個人のアカウントの下ではなく、組織の下にリポジトリを置くことで、持ち主が特定の個人に偏らなくなります。担当者が代わっても、リポジトリが組織に属したままなので、引き継ぎが容易です。

ドキュメントによると、組織のリポジトリでは、オーナーチームのメンバーが所有者にあたり、ほかのメンバーの権限は、チームの設定に従います。個人が持つリポジトリでは、作成者だけが所有者で、削除や譲渡を含む、制限のない権限を持ちます。協力者は、読む、書く、管理するのいずれかの水準を与えられます。

チームの種類と役割

組織の中には、役割に応じたチームを作ります。ドキュメントには、次の三つが説明されています。

新しいチームを作れるのは、オーナーチームか管理者チームのメンバーです。一人のユーザーが、複数のチームに所属することもできます。

オーナーチームについては、運用上の工夫が必要です。メンバーが1人もいない状態を作れない設計なので、たとえば担当者が一人だけだと、その人が退職した際に困ります。オーナーは、最低でも複数人にしておくのが安全です。ただし、オーナーは強い権限を持つため、むやみに増やすのも避けたほうがよいでしょう。

機能ごとに、権限の水準を決める

一般チームでは、リポジトリの機能ごとに権限を設定できます。ドキュメントでは、リポジトリの機能は、次の単位に分けて説明されています。

このほかに、外部の Wiki や、外部の課題管理のサービスへのリンクを示す機能もあります。

それぞれの機能には、「読む」「書く」「管理する」の水準があります。主な違いは、次のとおりです。

機能ごとに分けられることの意味は、実務で大きく現れます。たとえば、文書の担当者には Wiki の「書く」だけを与える、外部の協力者には Code の「読む」と Issues の「書く」だけを与える、といった細かい設計ができます。コードを書き換える必要のない人に、コードの書き込み権限を与えずに済みます。

メンバーの増減に強いチーム設計

では、実際にどのようにチームを設計すればよいのでしょうか。基本の考え方は、「個人ではなく、役割にチームを対応させる」ことです。

役割ごとのチームを作る

たとえば、小規模なチームなら、次のような分け方が考えられます。

これはあくまで例です。組織の実情に応じて、自由に組み替えられます。大切なのは、人が増えたときに、チームに所属を追加するだけで済む状態にすることです。

人の出入りは、チームの所属で対応する

メンバーが加わるときは、役割に合うチームに追加します。離れるときは、チームから外し、必要なら組織からも外します。リポジトリごとの設定を触る必要がありません。

異動の場合も、同じです。所属するチームを入れ替えれば、権限が丸ごと切り替わります。消し忘れが起きにくく、「この人が、いま何を触れるのか」も、チームの所属を見れば分かります。

新しいリポジトリへの対応を決める

一般チームは、対象を「全リポジトリ」にするか、「選んだリポジトリ」にするかを決められます。全リポジトリを対象にしたチームは、新しいリポジトリが作られても、自動で対象に含まれます。便利な反面、意図しないリポジトリにも権限が及びます。機密性の高いリポジトリがあるなら、そのリポジトリは、対象を選んだチームの管理にして、一般のチームから切り離しておくのが無難です。

また、チームに「新しいリポジトリを作る権限」を与えるかどうかも、決めておきます。誰でも自由にリポジトリを作れる状態は、手軽な反面、整理されないリポジトリが増える原因になります。

規模に応じた設計の例

ここまでの仕組みを、規模の違う二つの想像上の組織に当てはめてみます。実在の組織の話ではなく、考え方を示すための例です。

5人ほどの小さな開発チーム

人数が少ないので、組織を一つ作り、リポジトリをその下に置きます。オーナーチームには、責任者と、その代理の2人を入れます。そのほかの全員は、「開発者」という一般チームに所属させ、すべてのリポジトリに対して、Code、Issues、PullRequests を「書く」にします。チームは二つだけで始められ、管理の負担がほとんどありません。

人が増えたら、役割ごとにチームを分けます。それまでは、無理に細かくしないのが得策です。

20人ほどの、複数のプロジェクトを持つ組織

プロジェクトごとに、チームを作ります。各チームは、関わるリポジトリだけを対象にします。そのうえで、全プロジェクトに関わる「レビュー担当」や、設定を扱う「管理担当」のチームを、横断的に別に置きます。

この規模では、一人が複数のチームに所属することが、普通になります。ドキュメントでも、一人のユーザーが複数のチームに属せることが説明されています。所属するチームの数が増えると、「いま何ができるのか」が分かりにくくなるため、チームの名前を、役割と対象が読み取れるものにしておきます。

外部の協力者を迎えるとき

外部の協力者に、リポジトリの一部だけを見せたい場面があります。このときは、組織のメンバーとは別の扱いにします。たとえば、個別のリポジトリの協力者として加え、必要な水準（読む、書く、管理する）だけを与えます。

ドキュメントでは、リポジトリの協力者に対して、読む、書く、管理するの三つの水準を与えられると説明されています。外部の協力者には、まず「読む」から始め、必要になった段階で水準を上げます。作業が終わったら、協力者から外します。期限を決めておけば、外し忘れを防げます。

人が離れるときの手順

メンバーが離れるときは、手順を決めておくと、漏れを防げます。

1. 所属しているチームから、外します。
2. 個別に与えていた、リポジトリの協力者としての権限を確認します。
3. その人が、オーナーチームに入っていたなら、後任を先に決めてから外します。オーナーチームは、メンバーが一人もいない状態を作れません。
4. その人が作成した、個人のリポジトリがあれば、組織に譲渡するか、確認して整理します。
5. ランナーの登録など、その人の名前で行った設定があれば、引き継ぎます。

チームを経由して権限を管理していれば、1 だけで、ほとんどの権限が整理されます。この手順の短さが、チーム単位での設計の、実際の利点です。

定期的な見直しを習慣にする

権限は、設定したあとに放置すると、実態とずれていきます。数か月に一度、次の点を見直す習慣をつけておくと、安全な状態を保てます。

見直しにかかる時間は、チームの数が少なければ、わずかです。個人ごとの設定が散らばっていると、この見直しが、実質的にできなくなります。

権限の名前と、実際にできることを対応づける

画面に表示される権限の名前は、英語のままです。担当者が迷わないよう、チームの中で、意味を共有しておくと便利です。

• Code の「書く」は、push ができることです。 ブランチの保護の規則が設定されていれば、その規則の範囲内に限られます。
• Issues と PullRequests の「書く」は、ラベルの追加、担当者の割り当て、閉じる操作ができることです。 閲覧と作成は「読む」の範囲で行えます。つまり、課題やプルリクエストの作成だけなら、「読む」で足ります。
• Releases の「書く」は、リリースの作成と編集です。 配布物を公開する人を、絞りたいときに使います。
• Packages の「書く」は、アップロードと削除です。 成果物の登録を、自動化のための専用のチームに限る、といった使い方ができます。
• Actions の「書く」は、実行の承認、取り消し、再実行です。 ログを見るだけなら「読む」です。
• Settings は、管理者の水準だけがあります。 リポジトリの管理に関わるため、与える相手を慎重に選びます。

「読む」の中に、課題やプルリクエストの作成が含まれる点は、意外に感じるかもしれません。外部の協力者に、報告だけをしてもらいたいときには、この性質が便利です。コードを書き換える権限を与えず、課題の作成だけを許せるからです。必要な権限を、必要な範囲で与えるという考え方が、機能の分け方にも反映されています。

権限を変えたときの記録

誰に、いつ、どんな権限を与えたのかは、記録しておくと、あとで役立ちます。たとえば、外部の協力者を加えた日と理由、期限、担当者の名前を、簡単な表にまとめておきます。見直しのときに、その記録を見れば、権限が今も必要かどうかを、すぐに判断できます。記録は、凝ったものである必要はありません。続けられる形で、組織の中の共有の場所に置いておきます。

最初に決めておきたいこと

権限の設計は、導入の初期に、少し時間をかけて決めておくと、あとが楽です。最初に整理しておきたい項目を、次に挙げます。

1. オーナーを誰にするか。 複数人に任せ、連絡の取れる状態にします。
2. チームの区分をどうするか。 役割を基準に、最小限の数で始めます。
3. 対象のリポジトリの範囲をどうするか。 機密性に応じて、全体に及ぶものと、限定するものを分けます。
4. メンバーの出入りの手順をどうするか。 追加と削除の手順を、決めておきます。

最初から細かく作り込む必要はありません。小さく始めて、運用しながら、必要なチームを足していくやり方が現実的です。ただし、個人に直接権限を付ける運用だけは、早めにやめて、チームを経由する形に統一しておくと、規模が大きくなったときに困りません。

権限が整ったら、次は自動化です。リポジトリの Actions に関する権限もチームで管理できるので、組織の整備が終わった段階で、Gitea Actions で CI/CD を始めるへ進むと、安全に導入できます。この記事の内容は、2026年11月15日時点のドキュメントに基づいています。