GitHubアカウント統合 計画書

案A: info-mnml に統一 — 個人アカウントを組織アカウント (Org) に変換し、すべてのリポと連携をひとつにまとめる
関連 Issue: info-mnml/issues#464 方針: 案A 採用 (CEO 既決) 本番影響: なし (前提) 作成: 2026-05-12

1. 概要

現在、GitHub 上に info-mnml (個人アカウント)、The-botch (組織アカウント / アーカイブ済)、補助的な個人アカウント the-botch-admin・YKFROST が並立しています。リポ (ソースコードの置き場) や Vercel / Railway 連携、claude-code-action の Token (パスワード代わりの鍵) もこれらに分散しています。

本計画では、info-mnml を 個人アカウントから組織アカウント (Org) に変換し、ここにすべてのリポ・メンバー・自動化を集約します。新規メアドは不要、本番 (shift / the-botch) には影響を出しません。

現状 (Before) info-mnml 個人アカ / 19 リポ所有 The-botch (Org) Archived / リポ 2 件休眠 the-botch-admin 個人 / 4ヶ月休止 YKFROST Token 専用 外部開発者 (4名) mori0804 等 Vercel Railway claude-code-action 連携が個人アカウント (info-mnml) に紐付いている → メンバー追加・権限管理・Secret 共有がやりにくい 案A 統合 移行後 (After) info-mnml (組織アカウント / Org) すべてのリポ・自動化・Secret の集約点 Members (社内) info-mnml (Owner) the-botch-admin (Member) Outside Collaborators mori0804 / keeeeesk1114 sinnet6201-oss / takaraik The-botch Org (廃止 or 休眠) リポ 2 件は info-mnml Org に移管 YKFROST (整理対象) Token は Org Secret に移行 Vercel Railway claude-code-action 連携・権限・Token がすべて info-mnml Org に集約
図1: 現状 (Before) と移行後 (After) の構造比較

用語: 個人アカウント (User) = 1名の人が使うアカウント。組織アカウント (Org) = 会社・チーム用のアカウント。複数メンバーが所属でき、リポ・権限・Secret を一元管理できる。Outside Collaborator = Org のメンバーではないが、特定リポにアクセス権を持つ外部協力者。

2. 前提条件

  • shift (シフト管理) / the-botch (イベント精算) が 本番稼働中。利用ユーザーへのサービスを止めない。
  • Vercel / Railway / claude-code-action の 自動デプロイの仕組み (CI/CD) は維持する。
  • 新規メアドは作らない。info-mnml は CEO 兼用で運用継続。
  • 外部開発者 (mori0804 / keeeeesk1114 / sinnet6201-oss / takaraik) との協業は継続。アクセス権を切らない。
  • すべての作業対象リポに CLAUDE_CODE_OAUTH_TOKEN が設定済み (2026-05-08 一括設定済) なので、Token は Org 単位の Secret に集約可能。

3. 制約

  • 禁止 本番サービスのダウンタイム発生
  • 禁止 Vercel の自動デプロイ停止
  • 禁止 Railway の本番 DB 接続切断 (the-botch / shift の DB)
  • 禁止 既存 OAuth Token の意図しない失効
  • 禁止 外部開発者の GitHub アクセス断 (告知なしでの権限削除)
  • 注意 info-mnml が個人アカウントとして所有している private リポ・gist は Org 変換時にすべて Org に移る (個人 namespace は別途で復元しない)

4. プロセス

全体を 6 フェーズに分けて段階的に実施します。本番に触れるのはフェーズ B (Org 変換) の瞬間のみで、その他は事前準備と検証です。各フェーズで「CEO の手動操作」と「自動化される箇所」を分けて記載します。

Phase A 準備 Phase B 変換 Phase C Vercel 再接続 Phase D Railway 再接続 Phase E 検証 Phase F クリーンアップ CEO GitHub Vercel Railway 外部開発者 A1. 移行アナウンス Slack 全員 / 外部開発者 バックアップ確認 A2. リポ一覧取得 Secret / Settings の スナップショット A3. 告知受信 作業時間帯の周知 アクセス影響なし B1. Org 変換実行 GitHub 設定画面で 「Transform」操作 B2. User → Org リポは全件自動で Org 配下に移動 C1. 再接続承認 Vercel ダッシュ画面で Org をインストール C2. Org 再連携 3 プロジェクト分の GitHub URL 更新 D1. 再接続承認 Railway ダッシュ画面で Org を許可 D2. GitHub 再連携 DB は触らず デプロイトリガのみ更新 E1. 動作確認 shift / the-botch を ブラウザで開く E2. デプロイ成功 テスト push で 自動ビルドを確認 E3. DB 接続確認 shift backend が DB 応答できるか F1. クリーンアップ 論点で決定した 廃止対象を整理 F2. 旧 Org / 旧 User The-botch Org 廃止 YKFROST 整理
図2: 移行プロセスのスイムレーン (Phase A 準備 → F クリーンアップ)。橙=CEO 操作、青=システム自動、灰=外部開発者

フェーズ詳細

Phase主作業CEO 手動操作自動 / 影響
A 準備
~30分		 移行アナウンス、リポ一覧と Secret のスナップショット取得、Token 再発行手順の確認 Slack 全員告知、外部開発者への作業時間帯通知 本番影響: なし
B 変換
~10分		 info-mnml を個人 → 組織アカウントに変換 (GitHub 公式機能) info-mnml の Settings → "Transform account into an organization" リポは全件そのまま Org 配下に移動。URL は github.com/info-mnml/... のまま不変。本番ダウンタイムなし
C Vercel 再接続
~20分		 Org 化で Vercel の GitHub App 連携が一旦解除される。Org として再インストール Vercel ダッシュボードで GitHub App を Org に許可 3 プロジェクト (the-botch / shift-scheduler-ai / liff) の連携先 URL が Org に更新される
D Railway 再接続
~10分		 Railway も同じく GitHub App を Org として再許可。DB 接続文字列は変えない Railway ダッシュボードで GitHub App を Org に許可 DB は無停止。デプロイトリガのみ Org に切り替わる
E 検証
~30分		 本番動作確認 + テスト push で自動デプロイが動くか確認 + claude-code-action 動作確認 shift / the-botch をブラウザで開いて動作確認 失敗時は当該フェーズに戻ってやり直し (DB は不変なのでロールバック容易)
F クリーンアップ
後日		 論点 2・3 で決定した廃止対象 (The-botch Org / the-botch-admin / YKFROST) の整理 不要アカウントの削除実行 急がない。1〜2 週間運用してから判断してもよい
ポイント: Phase B の User → Org 変換 は GitHub が公式に提供する 1 操作 (リポ・Issue・PR 履歴・URL は全部そのまま残る)。コミット履歴・Issue 番号・URL リンクは全て生き続けます。

5. 論点

移行方針の中で CEO 判断を仰ぐ点を 6 つに整理します。各論点について 推奨 を明示しています。

論点 1: User → Org 変換 vs 新規 Org 作成して移管

選択肢メリットデメリット推奨
A. info-mnml User を Org に変換 URL・Issue 番号・履歴がすべてそのまま残る。リダイレクト不要 info-mnml は個人アカウントとしては消滅 (= CEO 個人の GitHub アカウントが別途必要になる) 推奨
B. 新規 Org を作って全リポ移管 info-mnml 個人アカウントを残せる 移管対象 19 リポ × 手動。Issue 番号は維持されるが URL ホスト名変更で外部リンクが切れる可能性 —

選択肢 A の場合、CEO 個人の GitHub アカウントが必要になるなら新規取得を別途検討 (任意)。新規メアド不要との既決を踏まえると、CEO は既存メアド (the-botch-admin or 私用) で個人アカウントを別に持つだけで足ります。

論点 2: The-botch Org をどうするか

選択肢メリットデメリット推奨
A. 廃止 (削除) 管理対象が減る。混乱の元を断つ 削除は不可逆。再現したくなった時に復元できない —
B. 中身を info-mnml Org に移管後、空 Org として残置 名前が将来必要になっても再利用できる。リポ 2 件はもともと Archive なので影響軽微 不要な Org が残る (ただし無料) 推奨

論点 3: the-botch-admin / YKFROST の扱い

対象選択肢メリットデメリット推奨
the-botch-admin info-mnml Org の Member として残す 過去 159 コミットの実績アカウントを維持できる 休止アカウントが残る (低リスク) 推奨
削除 管理対象が減る コミット履歴の表示が "ghost user" になる —
YKFROST Token を Org Secret に移行後、削除 CEO 既決 (「意識しなくていい」)。整理可 削除前に Token 移管を必ず先に 推奨
残置 (Org Member にも入れない) 作業ゼロ 不要アカウントの放置リスク —

論点 4: 外部開発者を Org Member にするか Outside Collaborator にするか

選択肢メリットデメリット推奨
A. Member として招待 Org 全リポにデフォルトでアクセス可能。権限管理がシンプル 意図しないリポにアクセスされうる。GitHub の課金が Member 数で増える可能性 (Team プラン以上) —
B. Outside Collaborator として個別リポに招待 必要なリポにだけアクセス権を渡せる。最小権限の原則 リポ毎の招待操作が必要 推奨

論点 5: Vercel / Railway 再接続のタイミング

選択肢メリットデメリット推奨
A. 一括 (Phase C+D を同日に) 移行が短時間で完了。コンテキストが切れない 同時に問題が起きた時に切り分けにくい 推奨 (Phase B 直後に C→D→E を続けて実施)
B. 段階的 (Vercel → 様子見 → Railway) 1 サービスずつ検証できる 移行期間が伸びる。並立状態が長引く —

論点 6: 移行作業の実行者

選択肢メリットデメリット推奨
A. CEO 単独で全フェーズ実施 意思決定と実行が同一人物。判断が早い 所要時間が長く、確認モレのリスク —
B. CEO が手動操作 + M層 (chief) が手順案内と検証スクリプト実行 CEO は GUI 操作だけ。検証は自動化できる 事前に M層 と段取り合わせが必要 推奨

6. メリット / デメリット

メリット

  • 権限管理が一元化: メンバー追加・削除が Org 単位の 1 画面で完結。外部開発者の管理が楽になる
  • Secret の集約: CLAUDE_CODE_OAUTH_TOKEN 等を Org Secret に置けば、リポを増やしても自動で配布される
  • 会社らしい体裁: 個人アカウントではなく組織として情報発信できる (将来オープン化する場合の信頼性)
  • 運用負債の解消: the-botch-admin / YKFROST 等の補助アカウントを整理する根拠ができる
  • Vercel / Railway の Team プラン適用が自然に: 将来チーム単位の課金にも対応しやすい

デメリット / リスク

  • Vercel / Railway の再接続が必須: 移行当日に手動操作が発生 (Phase C・D)
  • info-mnml は個人アカウントとして消滅: CEO が個人で GitHub を使う場合は別アカウントが必要
  • GitHub プランによっては課金が上がる可能性: 現状 Free プラン継続なら影響なし。Member 数が増えると Team プラン (有料) に上げる必要が出る
  • 外部開発者の招待操作: Outside Collaborator として再招待が必要 (一度きり)

7. リスクと対応

影響度 → 発生確率 → 低 高 低 高 [警戒] 影響大・確率低 [最優先] 影響大・確率高 [許容] 影響小・確率低 [監視] 影響小・確率高 R1. Vercel デプロイ失敗 → Phase E で push テスト R2. Railway DB 切断 → DATABASE_URL は不変、デプロイトリガのみ更新 R3. OAuth Token 失効 → Org Secret に事前移行 + 1 リポで動作確認 R4. 外部開発者アクセス断 → Phase A で告知 + Phase F で個別招待 R5. コミット履歴の混乱 → User→Org 変換は履歴を保持するので低リスク
図3: 主要リスクの発生確率 × 影響度マトリックス
IDリスク確率影響度対応
R1Vercel の自動デプロイが Org 化後に失敗中高Phase E で空コミット push してビルドが走るかを確認。失敗時は GitHub App を一旦削除して再インストール
R2Railway の DB 接続が切れて本番サービス停止低高DATABASE_URL は環境変数として独立しており、GitHub 連携の再接続では変更されない。Phase D は DB に触らない原則を守る
R3OAuth Token (claude-code-action) が失効してエージェント停止中中Phase A で Token を Org Secret に事前登録し、1 リポで動作確認してから全展開
R4外部開発者のリポアクセスが切れる中中Phase A で事前告知。Phase F で Outside Collaborator として個別招待 (再招待のメール 1 通で復帰)
R5コミット履歴の表示崩れ・URL リダイレクト失敗低低GitHub 公式の User→Org 変換は履歴・URL を保持する。事後確認のみで足りる

8. 完了条件

  • info-mnml が組織アカウント (Org) として稼働している (URL: github.com/info-mnml)
  • shift 本番が利用ユーザー側から正常稼働している (ブラウザ表示確認 + 1 件操作)
  • the-botch 本番が利用ユーザー側から正常稼働している (ブラウザ表示確認 + 1 件操作)
  • Vercel の 3 プロジェクト (the-botch / shift-scheduler-ai / liff) が新 Org に再接続され、テスト push で自動デプロイが成功する
  • Railway の shift-scheduler-ai backend が新 Org に再接続され、DB 接続が維持されている
  • claude-code-action が新 Org の Secret で動作する (主要 3 リポで Issue → PR が走ることを確認)
  • 外部開発者 4 名が引き続き対象リポにアクセスできる (Outside Collaborator として再招待済)
  • The-botch Org のリポ 2 件が info-mnml Org に移管済 (または Archive のまま残置決定)
  • 論点で決定した廃止対象 (YKFROST 等) の整理が完了している
次のステップ: 本計画書を CEO 確認 → 論点 1〜6 の判断を確定 → Phase A の段取り (告知文・作業日時) を chief で起票 → 実施。Phase B 以降は CEO 手動操作 + chief 並走で進めます。