アカウント役割マトリックス
Issue #464 — 平時運用における誰が何をするか の整理 / 2026-05-13
1. 全体像（開発体制の俯瞰図）
中央の「GitHub Issue（作業発注書）」を軸に、情報がどう流れるかを示します。
図1: 開発体制全体図。GitHub Issue を軸に「CEO の要望」→「M層 が要件整理・起票」→「自動実装・PR」→「レビュー・マージ」→「本番反映」の流れを示す。
2. アカウント一覧（全アクター）
※ アクター = 開発作業に関与する人間・AIエージェント・Bot の総称
| アカウント名 | 種別 | 主な責務 | 認証方法 |
|---|---|---|---|
| info-mnml (Yuki Uchiyama) | 人間 | 最終意思決定、Org admin、要件定義、本番デプロイ承認 | GitHub SSO + 2FA + SSH キー |
| mori0804 (森屋 穣) | 人間 | PR レビュー、コードコメント、approve / request changes | 個人 GitHub アカウント |
| keeeeesk1114 | 人間 | 外部開発者：コード実装・PR 提出 | 個人 GitHub アカウント (Outside Collaborator) |
| sinnet6201-oss | 人間 | 外部開発者：コード実装・PR 提出 | 個人 GitHub アカウント (Outside Collaborator) |
| takaraik | 人間 | 外部開発者：コード実装・PR 提出 | 個人 GitHub アカウント (Outside Collaborator) |
| chief (M層) | AI-M層 | 参謀・全社横断課題管理・M層ルーティングハブ。mnml-agents / issues リポ管轄 | Claude CLI OAuth (Mac mini ローカル) |
| ba (M層) | AI-M層 | 経理・法務・調達・mnml ブランド担当。mnml-tools リポ管轄 | Claude CLI OAuth (Mac mini ローカル) |
| consulting (M層) | AI-M層 | IT コンサル業務支援。consulting リポ管轄 | Claude CLI OAuth (Mac mini ローカル) |
| thebotch (M層) | AI-M層 | イベント精算アプリ開発支援。the-botch リポ管轄 | Claude CLI OAuth (Mac mini ローカル) |
| shift (M層) | AI-M層 | シフト管理システム（LIFF 含む）。shift-scheduler-ai リポ管轄 | Claude CLI OAuth (Mac mini ローカル) |
| web (M層) | AI-M層 | コーポレートサイト。mnml-web リポ管轄 | Claude CLI OAuth (Mac mini ローカル) |
| events (M層) | AI-M層 | イベント告知静的HTML。events リポ管轄 | Claude CLI OAuth (Mac mini ローカル) |
| sns (M層) | AI-M層 | SNS 投稿運用。sns_manage / postiz-app リポ管轄 | Claude CLI OAuth (Mac mini ローカル) |
| spotify (M層) | AI-M層 | Spotify プレイリスト整理。spotify-playlist-organizer リポ管轄 | Claude CLI OAuth (Mac mini ローカル) |
| researcher / architect / docs / coder / reviewer / tester / tax / legal-reviewer / github_claude (W層 9種) | AI-W層 | 単発スキル実行：調査・設計・実装・レビュー・テスト・法務 等。M層から DELEGATE タグで起動 | M層プロセス内で動作（独自認証なし） |
| claude-code-action | Bot | GitHub Issue の @claude を検知 → branch 作成・実装・commit・push・PR 作成・auto-merge | CLAUDE_CODE_OAUTH_TOKEN (GitHub Secret / YKFROST 発行) |
| YKFROST | Token 保持専用 | claude-code-action 用 OAuth Token を発行するためだけに存在。コミット実績 0、人間操作なし | 個人 GitHub アカウント（OAuth Token 発行のみ） |
| the-botch-admin | 廃止候補 | 159 コミット実績あり、2026-01-20 以降休止。The-botch Org admin 権限のみ残存 | 個人 GitHub アカウント（現在未使用） |
3. ロール定義（権限階層）
※ ロール = 開発作業における役割と権限の定義
| ロール名 | 該当アカウント | 主な権限・行動 | 権限境界（できないこと） |
|---|---|---|---|
| Owner | info-mnml (CEO) |
最終判断・全承認 Org admin（メンバー追加・削除） 本番デプロイ権限（Vercel / Railway） コスト管理・契約 |
なし（最上位権限） |
| Reviewer | mori0804（森屋） |
PR レビュー・コメント Approve / Request changes コードの品質確認 |
マージ実行は CEO 判断 Org 設定変更不可 本番デプロイ不可 |
| Implementer | 外部開発者 3名 / W層 / claude-code-action |
コード実装・コミット・PR 作成 ブランチ作成・push テスト実行 |
マージ権限なし Org 設定変更不可 本番直接デプロイ不可 |
| Orchestrator | M層 全 9 エージェント |
要件整理・確認（Slack thread） GitHub Issue 起票（gh CLI） W層への DELEGATE 委譲 PR レビュー・CEO への報告 |
最終マージは CEO 判断 （auto-merge ラベル付き除く） 本番デプロイ不可 Org admin 操作不可 |
| Skill | W層 9 種（researcher 等） |
単発タスク実行（調査・設計・実装等） M層への結果報告 ローカルファイル作成・編集 |
M層指示範囲のみ git push 不可（ローカル DELEGATE 時） Issue 起票不可（M層の責務） |
| Bot | claude-code-action |
Issue 本文を読んで自動実装 branch 作成・commit・push PR 自動作成・auto-merge 実行 |
Issue 起票不可 Org 設定変更不可 本番直接デプロイ不可（PR 経由のみ） |
| Inactive | the-botch-admin / YKFROST |
YKFROST: OAuth Token 保持のみ the-botch-admin: 現在操作なし |
通常の開発業務に関与しない |
4. 業務フロー × 担当（スイムレーン図）
開発のフェーズごとに「誰が何をするか」を示します。
図2: 業務フロースイムレーン。縦軸=アクター層、横軸=開発フェーズ。破線は「必要時のみ」の経路。
5. 責任マトリックス（RACI）
※ RACI = 業務分担の整理方式。R=実行者 / A=最終責任者 / C=相談先 / I=報告を受ける人 / —=関与なし
凡例:
R = Responsible（実際に作業する）
A = Accountable（最終責任を負う）
C = Consulted（意見を求められる）
I = Informed（結果の報告を受ける）
— = 関与なし
| 主要業務 | Owner CEO |
Reviewer 森屋 |
Implementer 外部開発者 |
Orchestrator M層 AI |
Skill W層 AI |
Bot Web Claude |
|---|---|---|---|---|---|---|
| 要件確定 | A | — | — | R | — | — |
| GitHub Issue 起票 | I | — | — | R/A | — | — |
| コード実装 | — | — | R | I | R | R |
| PR 作成 | — | — | R | I | — | R |
| PR コードレビュー | C | R/A | — | R | — | — |
| マージ判断 | A | C | — | C | — | R (auto-merge 時) |
| 本番デプロイ | A | — | — | I | — | R (CI/CD 経由) |
| 稼働監視 | A | — | — | I | — | — |
| インシデント対応 | A | C | R | R | R | — |
| 外部開発者管理（招待・削除） | A | — | — | C | — | — |
| 新規 M層・W層 立上げ | A | — | — | R | R (architect等) |
— |
| コスト管理（GitHub/Anthropic/Vercel等） | A | — | — | I | — | — |
| セキュリティ運用（Token 管理・2FA） | A | — | — | C | — | — |
| 法務対応（契約・規約） | A | — | — | R (ba M層) |
R (legal-reviewer) |
— |
| 採用・協業者判断 | A | C | — | — | — | — |
6. 認証・権限の物理的構造
| アクター | 認証方式 | 備考 |
|---|---|---|
| CEO (info-mnml) | GitHub SSO + 2FA + SSH キー | Org Admin。全権限保持 |
| M層 (Mac mini 常駐) | Claude CLI OAuth Long Token | ~/.claude-accounts/<account>/.oauth-long-token に格納。1年有効 |
| claude-code-action | OAuth Token (GitHub Secret) | YKFROST が発行 → CLAUDE_CODE_OAUTH_TOKEN として各リポの Secret に登録 |
| W層ワーカー | なし（M層プロセス内で動作） | 独自の認証情報を持たない |
| 外部開発者 | 個人 GitHub アカウント | Outside Collaborator (Write 権限)。リポ単位で付与 |
| YKFROST | 個人 GitHub アカウント | Token 発行専用。通常操作なし |
7. 連絡経路
| 送信者 → 受信者 | 手段・チャネル | 補足 |
|---|---|---|
| CEO ↔ M層 | Slack thread (Bolt Socket Mode) | 要件のやりとりはすべてここ。Slack thread = 議論の SoT |
| CEO ↔ 森屋 / 外部開発者 | Slack DM / チャンネル / メール | 業務依頼・進捗確認 |
| M層 → W層 | DELEGATE タグ (Claude CLI stdin/stdout) | M層が <<DELEGATE>> タグで起動。結果はM層に返る |
| M層 → GitHub Issue | gh CLI | Issue 起票・コメント追加 |
| claude-code-action → GitHub | GitHub API (Token 認証) | branch 作成・commit・push・PR 作成・Issue close |
| M層 → CEO（完了報告） | Slack thread（元スレッドに返信） | PR URL・結果サマリを投稿 |
| 外部開発者 ↔ 内部 | GitHub PR コメント / Slack チャンネル | コードレビューは PR コメント。業務連絡は Slack |
| bot / 監視 → CEO | Slack alert_channel | エラー・障害アラート。Slack Bot 経由で通知 |
8. 案A: 移行後の体制（CEO 承認待ち）
現状（Before）: The-botch Org と info-mnml Org が並立。外部開発者は The-botch Org member。the-botch-admin アカウントが休眠状態。
案A 移行後（After）: The-botch Org を廃止 → すべてのリポを info-mnml Org に統合。外部開発者は info-mnml Org の Outside Collaborator に変更。the-botch-admin アカウントは削除。YKFROST は OAuth Token 保持専用として残置（または将来的に Org Service Account へ移行）。
| 項目 | Before（現状） | After（案A） |
|---|---|---|
| Org 構造 | The-botch Org + info-mnml Org（2つ並立） | info-mnml Org 1つに統合 |
| 外部開発者の所属 | The-botch Org member | info-mnml Org の Outside Collaborator |
| the-botch-admin | 休眠中（The-botch Org admin 権限あり） | アカウント削除 |
| YKFROST | OAuth Token 保持専用（現状維持） | 残置 or Org Service Account へ移行（論点9.1 参照） |
| claude-code-action | 各リポに個別設定 | 変更なし（14リポに展開済み） |
詳細な移行手順は account_unification_plan_464.html（既存）を参照してください。
9. CEO 判断が必要な論点
論点1: YKFROST アカウントをどう扱うか
| 選択肢 | メリット | デメリット |
|---|---|---|
| A: YKFROST 残置（現状維持） | 作業不要。Token 更新時も YKFROST でログインして再発行するだけ | 目的専用アカウントが1つ残り続ける。管理する GitHub アカウントが増える |
| B: CEO 個人で Token 発行に切替え | アカウント数が減る。CEO が Token を一元管理 | Token 失効時に CEO が手動で再発行する必要がある。CEO 個人アカウントへの依存が増す |
| C: Org Service Account に移行 | Org として管理・監査しやすい | GitHub Enterprise が必要（現状は個人/Team プランの可能性あり）。費用増 |
推奨: A（残置） — Token 管理の手間が最小。YKFROST は実質的に「Token 専用の鍵束」として機能しており、現運用を変える理由がない。
論点2: 外部開発者を Org member にするか Outside Collaborator にするか
| 選択肢 | メリット | デメリット |
|---|---|---|
| A: Outside Collaborator（現状） | リポ単位で権限付与できる。Org 内部情報を見せない | リポが増えると招待が煩雑 |
| B: Org member（full member） | Org 全体のリポにアクセスしやすい。管理が一元化 | Org の内部情報（メンバー一覧・チーム・設定）が見える。機密リポへのアクセス制御が必要 |
推奨: A（Outside Collaborator 維持） — 外部開発者は特定プロジェクト専任であり、Org 全体へのアクセスは不要。セキュリティ上もリポ単位の権限制御が望ましい。
論点3: M層をサーバ移行する場合の認証方式
| 選択肢 | メリット | デメリット |
|---|---|---|
| A: Mac mini 継続 | 現状維持で作業不要。OAuth Long Token がそのまま使える | Mac mini 障害時にM層が止まる。スペック上限あり |
| B: クラウドサーバ（VPS等）に移行 | Mac mini 依存を排除。高可用性 | OAuth Long Token をどう安全に管理するか設計が必要（秘密管理サービス必須）。移行コスト大 |
推奨: A（当面 Mac mini 継続） — 現時点では Mac mini で十分稼働している。移行は M層の台数・負荷が増えてから検討でよい。
論点4: claude-code-action の Token 失効時（2027年5月頃）の対応
| 選択肢 | メリット | デメリット |
|---|---|---|
| A: YKFROST で再発行（手動） | 最もシンプル。特別な仕組み不要 | 忘れると全 claude-code-action が止まる。14リポの Secret 更新が必要 |
| B: M層がリマインドし、CEOまたはYKFROSTが更新 | 失効の見落とし防止 | M層からのアラート設定が必要 |
推奨: B — 失効3ヶ月前（2027年2月頃）に M層（chief）から Slack でリマインドするよう設定する。更新作業自体は YKFROST ログイン → 新 Token 発行 → 14リポの Secret 一括更新（スクリプト化推奨）。
Token 失効カレンダー: 現 YKFROST OAuth Token の有効期限は約2027年5月頃。chief M層への期限リマインド設定を推奨。