権限マトリクス

1. 概要

本ドキュメントでは、全 API エンドポイントに対するロール別のアクセス制御、およびリポジトリレベル・委託者間の情報隔離ルールを定義する。

凡例:

O = アクセス許可
- = アクセス不許可
△ = 条件付き許可（条件は備考欄に記載）

2. API エンドポイント別アクセス制御

2.1 認証 API

Method	Endpoint	PM/マネージャー	レビュワー	エンジニア	認証不要	備考
GET	`/auth/gitlab`	-	-	-	O	OAuth 認証開始
GET	`/auth/callback`	-	-	-	O	OAuth コールバック
POST	`/auth/refresh`	O	O	O	-	トークンリフレッシュ
POST	`/auth/logout`	O	O	O	-	ログアウト

2.2 ユーザー管理 API

Method	Endpoint	PM/マネージャー	レビュワー	エンジニア	備考
GET	`/users`	O	△	-	レビュワーは担当PJ内のユーザーのみ
GET	`/users/:id`	O	△	△	レビュワー: 担当PJ内 / エンジニア: 自分のみ
PUT	`/users/me/profile`	O	O	O	自分のプロフィールのみ
POST	`/users/invite`	O	-	-	ユーザー招待
DELETE	`/users/invite/:id`	O	-	-	招待キャンセル
PUT	`/users/:id/role`	O	-	-	ロール変更
PUT	`/users/:id/status`	O	-	-	アカウント有効化/無効化

2.3 プロジェクト管理 API

Method	Endpoint	PM/マネージャー	レビュワー	エンジニア	備考
POST	`/projects`	O	-	-	プロジェクト作成
GET	`/projects`	O	△	△	レビュワー: 担当PJ / エンジニア: 参加PJ
GET	`/projects/:id`	O	△	△	レビュワー: 担当PJ / エンジニア: 参加PJ
PUT	`/projects/:id`	O	-	-	プロジェクト設定変更
DELETE	`/projects/:id`	O	-	-	プロジェクトアーカイブ
POST	`/projects/:id/members`	O	-	-	メンバー追加
DELETE	`/projects/:id/members/:uid`	O	-	-	メンバー削除
GET	`/projects/:id/members`	O	△	-	レビュワー: 担当PJのみ

2.4 Issue 管理 API

Method	Endpoint	PM/マネージャー	レビュワー	エンジニア	備考
POST	`/projects/:id/issues`	O	-	-	Issue 作成
GET	`/projects/:id/issues`	O	△	△	レビュワー: 担当PJ / エンジニア: 着手可能のみ
GET	`/issues`	O	△	△	横断一覧。レビュワー: 担当PJ / エンジニア: 着手可能
GET	`/issues/:id`	O	△	△	レビュワー: 担当PJ / エンジニア: 着手可能+自分着手中
PUT	`/issues/:id`	O	-	-	Issue 編集
DELETE	`/issues/:id`	O	-	-	Issue 削除
PUT	`/issues/:id/reward`	O	-	-	報酬金額設定・変更
POST	`/issues/:id/assign`	-	-	O	Issue 取得（自分にアサイン）
DELETE	`/issues/:id/assign`	△	-	△	PM: 任意 / エンジニア: 自分のもの

2.5 MR（Merge Request）管理 API

Method	Endpoint	PM/マネージャー	レビュワー	エンジニア	備考
POST	`/issues/:id/merge-requests`	-	-	O	MR 提出
GET	`/merge-requests`	O	△	△	レビュワー: 担当PJ / エンジニア: 自分のもの
GET	`/merge-requests/:id`	O	△	△	レビュワー: 担当PJ / エンジニア: 自分のもの
POST	`/merge-requests/:id/review`	-	O	-	レビューコメント投稿
PUT	`/merge-requests/:id/approve`	-	O	-	MR 承認
PUT	`/merge-requests/:id/request-changes`	-	O	-	修正リクエスト
POST	`/merge-requests/:id/comments`	O	O	△	エンジニア: 自分のMRのみ
POST	`/merge-requests/:id/merge`	O	O	-	マージ実行

2.6 報酬・予算管理 API

Method	Endpoint	PM/マネージャー	レビュワー	エンジニア	備考
POST	`/projects/:id/budget`	O	-	-	予算枠設定
GET	`/projects/:id/budget`	O	-	-	予算消化状況
PUT	`/rewards/:id/confirm`	-	O	-	報酬確定承認
GET	`/rewards`	O	-	△	エンジニア: 自分の報酬のみ
GET	`/rewards/:id`	O	△	△	レビュワー: 担当PJ / エンジニア: 自分のもの
GET	`/payments`	O	-	△	エンジニア: 自分の支払いのみ
GET	`/payments/:id`	O	-	△	エンジニア: 自分のもの

2.7 ダッシュボード API

Method	Endpoint	PM/マネージャー	レビュワー	エンジニア	備考
GET	`/dashboard/overview`	O	-	-	全体ダッシュボード
GET	`/dashboard/projects/:id`	O	△	-	レビュワー: 担当PJのみ
GET	`/dashboard/me`	O	O	O	個人ダッシュボード

2.8 通知 API

Method	Endpoint	PM/マネージャー	レビュワー	エンジニア	備考
GET	`/notifications`	O	O	O	自分宛の通知のみ
PUT	`/notifications/:id/read`	O	O	O	自分宛の通知のみ
PUT	`/notifications/settings`	O	O	O	通知設定変更

3. リポジトリレベルの情報隔離ルール

3.1 基本原則

業務委託エンジニアは、着手中の Issue に関連するリポジトリ情報のみアクセス可能とする。他のエンジニアのブランチやコード、関係のないプロジェクトの情報には一切アクセスできない。

3.2 GitLab リポジトリアクセス制御

リソース	PM/マネージャー	レビュワー	エンジニア	備考
リポジトリ一覧	O（全件）	O（担当PJ）	O（参加PJ）
ブランチ一覧	O	O（担当PJ）	△	エンジニア: 自分のブランチ + main/develop のみ
コミット履歴	O	O（担当PJ）	△	エンジニア: 自分のブランチのみ
MR 差分	O	O（担当PJ）	△	エンジニア: 自分の MR のみ
CI/CD パイプライン	O	O（担当PJ）	△	エンジニア: 自分の MR に紐づくもののみ
環境変数・シークレット	O	-	-
デプロイ設定	O	-	-

3.3 ブランチ命名規則による隔離

エンジニアがブランチを作成する際は、以下の命名規則を強制する。

issue-<issue_id>/<gitlab_username>/<description>

例: issue-42/tanaka/add-payment-api

プラットフォーム側で MR 作成時にブランチ名をバリデーション
他のエンジニアのプレフィックスを持つブランチへの push は GitLab の Protected Branch ルールで禁止

3.4 ファイルレベルの制限

リソース	制限
`.env` / シークレットファイル	エンジニアからは不可視。CI/CD 変数として管理
`docker-compose.yml` (本番用)	エンジニアは閲覧のみ。変更は PM の承認が必要
インフラ設定ファイル	エンジニアからは不可視
ソースコード	Issue に関連するディレクトリのみ閲覧可能（将来実装）

4. 委託者間の情報隔離

4.1 基本原則

業務委託エンジニア同士は、互いの情報を一切参照できない。プラットフォームを通じた情報漏洩を防ぐ。

4.2 隔離対象

情報	隔離方針
他エンジニアの氏名・プロフィール	不可視 - エンジニア同士の個人情報は完全に隔離
他エンジニアの着手 Issue	不可視 - 誰がどの Issue に着手しているかは非表示
他エンジニアの MR / コード	不可視 - 他人のブランチ・MR・コード差分は閲覧不可
他エンジニアの報酬情報	不可視 - 報酬金額・支払い状況は完全に隔離
Issue の報酬金額	可視 - 着手前の Issue に設定された報酬額は全エンジニアが閲覧可能
Issue のステータス	部分可視 - 「着手可能」「着手済み（誰かは非表示）」「完了」

4.3 Issue ステータスの表示ルール

エンジニア視点での Issue ステータス表示:

内部ステータス	エンジニアへの表示	説明
`open`	着手可能	誰も着手していない
`assigned` (自分)	着手中	自分が着手中
`assigned` (他人)	着手済み	誰かが着手中（担当者名は非表示）
`in_review` (自分)	レビュー中	自分の MR がレビュー中
`in_review` (他人)	着手済み	他人のため詳細は非表示
`completed`	完了	完了済み（担当者名は非表示）

4.4 データベースレベルの隔離実装

sql

-- エンジニアが Issue 一覧を取得する際のクエリ条件（概念）
SELECT i.*
FROM issues i
WHERE i.project_id IN (
    SELECT project_id FROM project_members WHERE user_id = :current_user_id
)
AND (
    i.status = 'open'                                    -- 着手可能
    OR (i.assignee_id = :current_user_id)                -- 自分が着手中
)
AND i.deleted_at IS NULL;

4.5 API レスポンスのフィルタリング

エンジニア向けの API レスポンスでは、以下のフィールドをマスクする。

json

{
  "id": 42,
  "title": "決済API実装",
  "status": "assigned",
  "reward_amount": 50000,
  "assignee": null,
  "assignee_name": null,
  "created_at": "2026-03-01T10:00:00Z"
}

assignee と assignee_name は自分以外の場合 null を返す。

5. ミドルウェアによるアクセス制御実装方針

5.1 認証ミドルウェア

すべての保護されたエンドポイントに適用する。

リクエスト → [認証ミドルウェア] → [ロール検証ミドルウェア] → [リソースアクセス検証] → ハンドラー

ミドルウェア	役割
認証ミドルウェア	JWT の検証。無効な場合は 401 を返す
ロール検証ミドルウェア	エンドポイントに必要なロールを検証。不足の場合は 403 を返す
リソースアクセス検証	リソース（Issue、MR 等）への個別アクセス権を検証。不正の場合は 404 を返す

5.2 アクセス拒否時のレスポンス

ケース	HTTP Status	レスポンス
未認証	401	`{"error": "unauthorized", "message": "認証が必要です"}`
ロール不足	403	`{"error": "forbidden", "message": "権限がありません"}`
リソースアクセス不可	404	`{"error": "not_found", "message": "リソースが見つかりません"}`

リソースアクセス不可の場合は 404 を返す（403 を返すとリソースの存在が漏洩するため）。

6. 監査とコンプライアンス

6.1 アクセスログ

全 API リクエストについて以下を記録する。

フィールド	説明
timestamp	リクエスト日時
user_id	リクエスト元ユーザー ID
role	ロール
method	HTTP メソッド
endpoint	エンドポイントパス
resource_id	対象リソース ID
status_code	レスポンスステータスコード
ip_address	リクエスト元 IP

6.2 不正アクセス検知

以下のパターンを検知し、アラートを発する。

短時間の大量 403/404 エラー（権限昇格の試行）
異なる IP からの同一トークン使用
通常と異なる時間帯のアクセス
大量のデータ取得リクエスト

権限マトリクス ​

1. 概要 ​

2. API エンドポイント別アクセス制御 ​

2.1 認証 API ​

2.2 ユーザー管理 API ​

2.3 プロジェクト管理 API ​

2.4 Issue 管理 API ​

2.5 MR（Merge Request）管理 API ​

2.6 報酬・予算管理 API ​

2.7 ダッシュボード API ​

2.8 通知 API ​

3. リポジトリレベルの情報隔離ルール ​

3.1 基本原則 ​

3.2 GitLab リポジトリアクセス制御 ​

3.3 ブランチ命名規則による隔離 ​

3.4 ファイルレベルの制限 ​

4. 委託者間の情報隔離 ​

4.1 基本原則 ​

4.2 隔離対象 ​

4.3 Issue ステータスの表示ルール ​

4.4 データベースレベルの隔離実装 ​

4.5 API レスポンスのフィルタリング ​

5. ミドルウェアによるアクセス制御実装方針 ​

5.1 認証ミドルウェア ​

5.2 アクセス拒否時のレスポンス ​

6. 監査とコンプライアンス ​

6.1 アクセスログ ​

6.2 不正アクセス検知 ​