GitHub 複数 アカウントの分け方｜無料は1つまでという前提

github 複数 アカウントで検索する人が本当に知りたいことは、たいてい3つに分かれる。規約上まずくないのか、ブラウザで行き来する方法があるのか、そして手元のGitがどちらのアカウントで押すのかをどう制御するのか。この3つは別の問題で、答えも別の場所にある。

先に結論を置くと、いちばん見落とされやすいのは1つめだ。GitHubの利用条件には無料アカウントの数について明確な条文がある。ここを読まずに2つ作ってしまうと、あとから片方を有料にするか統合するかの判断を迫られる。順番に確かめていく。

無料アカウントは1人1つ。条文はそこまで明確

GitHubの利用条件にはアカウントの要件という節があり、そこに数の制限が書かれている。

1 人の個人または 1 法人が維持できる無料アカウントは 1 つのみです (マシン アカウントを管理することを選択することもできますが、アカウントはマシンを実行するためにのみ使用できます)。 出典: docs.github.com

読み方は素直だ。無料のアカウントを2つ持つことは条文に反する。ただし制限がかかっているのは無料のアカウントの数であって、アカウントの数そのものではない。片方を有料にしていれば、その組み合わせは条文の文言と衝突しない。同じ節には、自動化のためのマシンアカウントについても、無料の個人アカウントのほかに無料のマシンアカウントを1つだけ維持できると書かれている。こちらは自動化タスクを実行するためだけに使うものとされているので、人が使う2つめの居場所にはならない。

開発者の間でも、この条文の解釈は論点になってきた。

しかし実際には、会社のアカウントで個人的なOSS活動をすると漏洩リスクなども伴う。会社用と個人用で別のアカウントを使用するのは容認されているという記事もある。 出典: zenn.dev

現実の必要と条文が噛み合いにくいのは、GitHubが想定している分け方が「アカウントを増やす」ではなく「1つの個人アカウントが複数の組織に所属する」形だからだ。利用条件では、個人アカウントはいくつでも組織のメンバーになれると定義されている。会社の仕事は会社の組織の中で、個人の活動は自分のリポジトリで、という構成なら、アカウントは1つで足りる。

それでも分けたい理由があるときは、企業側が管理するアカウントの仕組みを使う形が本筋になる。会社がEnterpriseの契約でマネージドユーザーアカウントを配っているなら、それは会社が用意したアカウントであり、個人の無料アカウントとは別枠で存在する。この場合は2つ持っていても条文の話にならない。自分の状況がどの型に当てはまるかを先に確かめるほうが、解釈で悩むより早い。

ブラウザ側の切り替えは公式に用意されている

2つのアカウントを行き来する部分は、GitHubが機能として提供している。アカウントスイッチャーと呼ばれるもので、毎回ログアウトして入り直す必要はない。

手順は短い。プロフィール写真をクリックしてメニューを開き、アカウントを切り替えるを選び、アカウントを追加を選ぶ。そこで追加したいアカウントにサインインすると、以後は同じメニューから選べるようになる。

GitHub で複数のアカウントを使用する必要がある場合は、アカウントにサインインし、アカウントを切り替えることができます。常に再認証する必要はありません。 アカウント切り替えは、個人用アカウントとサービス アカウント (マシン ユーザーとも呼ばれることもあります) がある場合、または マネージド ユーザー アカウント を使用する企業で個人用アカウントと Enterprise Managed Users を切り替える必要がある場合に使用できます。 出典: docs.github.com

想定されている使い方が引用の後半にそのまま書かれている点に注目したい。個人アカウントとサービスアカウントの組み合わせ、あるいは個人アカウントと会社が管理するアカウントの組み合わせだ。前の節の条文と読み合わせると、公式が想定しているのはこの2つの型だと分かる。

外すときの手順も3通り用意されている。いま使っているアカウントから出るならユーザー名の横のサインアウト、特定のアカウントを一覧から消すならその横の削除、全部まとめて出るなら全アカウントからサインアウトを選ぶ。切り替えの一覧に残ったままのアカウントは、そのブラウザで誰でも切り替えられる状態になるので、共用のPCでは使い終わったら外しておくほうがよい。反対に自分専用の機械なら、一覧に残しておくほうが再認証の手間がかからず、切り替えの操作もクリック数回で済む。

本当に詰まるのは、手元のGitがどちらで押すか

ブラウザの切り替えが済んでも、作業が止まる場所はもうひとつある。ターミナルから押すときのアカウントだ。ブラウザで仕事のアカウントを表に出していても、Gitが使う認証情報は別に保存されている。ここが揃っていないと、個人のアカウントで会社のリポジトリへ押す、あるいはその逆が起きる。

GitHubの公式ドキュメントは、1台の作業機から複数のアカウントへ貢献する場合の設定方法を用意していて、やり方は大きく2系統ある。HTTPSとトークンで分ける方法と、SSHの鍵で分ける方法だ。

HTTPSで分ける場合の要になるのは、認証情報をリポジトリごとに覚えさせる設定になる。公式ドキュメントが指定しているのはuseHttpPathという設定項目で、git config --global credential.GITHUB_URL.useHttpPath trueの形で書き込む。GITHUB_URLと書いた部分には、httpsから始まるGitHubのアドレスをそのまま入れる。

この設定を入れると、Gitは認証情報をホスト単位ではなくリポジトリの完全なURL単位で保存するようになる。そのうえで、アカウントごとに専用のパーソナルアクセストークンを作る。classicならrepoスコープを付け、細粒度のトークンなら対象のリポジトリにアクセスでき、リポジトリのコンテンツに読み書きの権限を持つものを作る。細粒度のトークンは、自分のアカウントの分だけでなく、所属しているそれぞれの組織の分も作ることになる。最初にクローンするときや既存のリポジトリにアクセスするときに認証情報を求められるので、そのリポジトリに権限のあるアカウントのトークンを渡す。以後はURL単位で覚えているため、取り違えが起きない。

この設定を入れる前に、既に保存されている認証情報を消しておく必要がある。git config --get credential.helperを実行して、出力を見るのが最初の一歩だ。何も出なければ認証情報を保管する仕組みが設定されていないので、そのまま次に進んでよい。osxkeychainと出たならmacOSのキーチェーンを使っているので、git credential-osxkeychain eraseにホスト名とプロトコルを渡して該当のものを消す。managerまたはmanager-coreと出たならGit Credential Managerなので、そちらの消去コマンドを使う。この掃除を飛ばすと、古い認証情報が使われ続けて原因の見えない失敗になる。押せない理由が権限に見えて、実はキーチェーンに残った別アカウントの情報だった、という形で時間を取られやすい場所だ。

SSHで分けるなら、鍵とホスト名を対で用意する

SSHで両方を扱う場合は、アカウントごとに別の鍵を用意する。公式ドキュメントには2通りの案が書かれている。

ひとつは環境変数で鍵を指定する方法だ。リポジトリのオーナーとリポジトリ名をgit config --get remote.origin.urlで判定し、適切な鍵を選び、GIT_SSH_COMMANDを書き換えるシェルの関数を書く、という考え方になる。単発ならGIT_SSH_COMMAND='ssh -i 鍵のパス -o IdentitiesOnly=yes' git cloneの形で直接指定できる。

もうひとつは設定ファイルで分ける方法で、こちらのほうが日常の作業には向く。~/.ssh/configに2つのホストを書き、同じgithub.comへ別の鍵で繋がる入口を作る。片方はそのままgithub.com、もう片方はgithub-emu.comのような別名にしてHostnameにgithub.comを指定し、それぞれのIdentityFileに別の鍵を書く。IdentitiesOnly yesを入れておくのが肝心で、これが無いとエージェントに読み込まれた複数の鍵のうち意図しないものが使われる。

ここでひとつ強い制約がある。公式ドキュメントには、マネージドユーザーを使う組織の中のリポジトリと、企業の外のリポジトリの両方に、同じSSHの鍵を使うことはできないと明記されている。会社がEnterpriseのマネージドユーザーを配っていて、同時に個人でも活動するなら、鍵を分けること自体が必須条件になる。分けるかどうかを選ぶ話ではない。

鍵を分けたあとは、リポジトリをクローンするときのURLでどちらの入口を使うかが決まる。会社用のリポジトリは別名のホストでクローンし、個人用はgithub.comでクローンする。この方式にすると、どのアカウントで押すかがリポジトリの設定として固定されるので、作業中に意識する必要がなくなる。設定を1回で終わらせたい人にはこちらが向く。

二重になっているのはGitHubだけではない

ここまでを実行するとGitHubの中と手元のGitは整う。それでも1日の切り替え回数があまり減らない場合、原因はGitHubの外にある。

会社と個人という2つの立場を持っていれば、GitHubが2つになるのと同じ理由でGmailが2つ、Slackが2つ、Notionが2つ、ChatGPTが2つになる。ブラウザは1つのプロファイルにつき1サービス1セッションしか保持できないため、同じサービスに2つのアカウントで同時にサインインしておくことができない。GitHubのアカウントスイッチャーが解いたのはGitHubの分だけで、他のサービスでは解かれていない。

この構造に効く打ち手は、サービス単位ではなく場所単位で分けることになる。Webアプリをそれぞれ独立した窓として置き、アプリごとに独立したワークスペースとして束ねてしまえば、サービスが増えても扱いは変わらない。どのサービスがこの形で使えるかは使えるアプリに一覧があり、窓の束を所属ごとに切り替える考え方はワークスペースにまとまっている。ターミナルを同じ場所に置いて作業を完結させたい場合はターミナルが該当する。

同じ考え方の道具は複数あり、無料で使える範囲も料金も違う。1対1で並べたほうが軸を作りやすいため、Waveboxとの比較やFerdiumとの比較が材料になる。費用が判断に関わる場合は料金を先に確かめておくと、機能の比較がぶれにくくなる。

判断の目安は1つでよい。1日のうちにアカウントを切り替えた回数を数え、その内訳を「作業のために切り替えた分」と「何か来ていないか確かめるために切り替えた分」に分ける。後者が多いなら、足りないのは切り替えの速さではなく、開かずに分かる見せ方のほうになる。