GitHubの障害や買収以降の方針に不安を感じるたびに名前が挙がる選択肢のひとつが、GitベースのP2PコードフォージRadicleだ。中央サーバーを持たず、リポジトリはピア同士で複製される。今回はRadicle 1.9.1を、互いに独立した2つのノード（別ID・別環境のコンテナ）で実際に動かし、リポジトリ公開→clone→Issue→Patch→レビュー→マージという「GitHubで日常的にやっている一連の流れ」がどこまで再現できるかを検証した。
結論から言うと、この一連のフローはすべて動いた。個人や小規模チームが公開リポジトリを共有する用途なら、今日から現実的に試せる完成度だ。ただしGitHubの置き換えとして考えると、レビュー機能の簡素さ・アカウントモデルの違い・CIが別立てである点など、前提の違いをいくつか飲み込む必要がある。
Radicleは何ができるツールか
Radicleは、オープンソース（MIT/Apache-2.0）のP2Pコードコラボレーションスタックで、リポジトリのホスティング・Issue・Patch（Pull Requestに相当）・コードレビューをGitの上に直接実装している。GitHubとの根本的な違いは、単一の運営主体がいないことだ。
- IDはメールアドレスでなく鍵。
rad authで生成される暗号鍵ペアがそのままユーザーIDになる。登録もアカウント作成もない - IssueやPatchもGitオブジェクト。COB（Collaborative Objects）という仕組みで、ソーシャルな情報もリポジトリと一緒にP2P複製される
- local-first。ネットワークに繋がっていなくてもすべての操作がローカルで完結し、接続時に同期される
構成はCLI（rad）・ノードデーモン・Git remote helper（git-remote-rad）・Web UI・Desktopアプリからなり、今回はCLIとノードだけを使った。
検証環境
インターネットへ出られないDocker内部ネットワーク上に、alice（リポジトリの委任者=メンテナ役）とbob（貢献者役）という完全に独立した2つのノードを立てた。Radicle 1.9.1のバイナリはSHA256を固定して導入している。docx-cliの検証と同じく、各手順の結果はスクリプト内でアサーションし、1つでも失敗すれば非ゼロ終了する形にした。
2ノードにしたのは、「同じマシンでコマンドが動いた」ではなく「別のID・別の環境との間でP2P共有が成立した」ことを確認するためだ。
実際に動かした結果
導入とID作成
インストールは公式のワンライナーで、rad・radicle-node・git-remote-radの3バイナリが入る。IDは対話なしでも作れる。
curl -sSLf https://radicle.dev/install | sh
rad auth --alias alice # 鍵ペア生成。これがそのままID
rad node start # ノードをバックグラウンド起動リポジトリ公開とP2P clone
既存のGitリポジトリで rad init を実行するとRID（Repository ID）が発行され、rad という名前のGit remoteが作られる。
✓ Repository hello-radicle created.
Your Repository ID (RID) is rad:z2eDu2uHc6Kv1drwWPfsUYexu7uNi.このときピアと未接続だと announce は「接続でき次第行う」と表示されて保留になる。エラーではなく、local-firstの設計どおりの挙動だ。
bob側からはRIDだけでcloneできた。
$ rad clone rad:z2eDu2uHc6Kv1drwWPfsUYexu7uNi
Fetching rad:z2eDu2uHc6Kv1drwWPfsUYexu7uNi from the network, found 1 potential seed(s).
✓ Repository successfully cloned under /home/rad/src/hello-radicle/cloneしたREADMEの中身がalice側のコミットと一致することもスクリプトで確認している。
IssueとPatch
IssueはGitHubとほぼ同じ感覚で作れる。作成するとP2Pで同期され、alice側の rad issue list にbobが作ったIssueがそのまま現れた。
rad issue open --title "READMEにインストール手順を追記してほしい" \
--description "cloneして最初に読む人向けの手順が欲しい"Pull Requestに相当するPatchは、refs/patches という「マジックref」へのpushで作る。
git checkout -b add-install-steps
# （変更をコミット）
git push rad HEAD:refs/patches✓ Patch 65e0170c224d22ed9db5de73c7d64b1d96dc0f9f opened
✓ Synced with 1 seed(s)レビューとマージ
公式ユーザーガイドには「Patchの高度なコードレビュー機能はまだなく、近いリリースで来る」という記述があるが、accept/rejectとコメントのレベルなら現バージョンで既に動く。alice側で実行:
rad patch review 65e0170 --accept --message "LGTM (verified locally)"✓ Patch 65e0170 acceptedマージはRadicle専用コマンドではなく、普通のGit操作だ。マージしてpushすると、Radicleが「Patchのrevisionがデフォルトブランチに入った」ことを検出してPatchをmerged扱いにする。
rad patch checkout 65e0170 # patch/65e0170 ブランチが作られる
git checkout main
git merge patch/65e0170
git push rad main✓ Patch 65e0170c224d22ed9db5de73c7d64b1d96dc0f9f merged
✓ Canonical reference refs/heads/main updated to target commit b8cfae88...このマージ結果がP2P経由でbob側の git pull に返ってくるところまで確認して、一連のフローが閉じた。
うまくいったこと
- 導入→公開→clone→Issue→Patch→レビュー→マージ→変更の還流という主要フローが、独立2ノード間ですべて動いた（アサーション付きスクリプトの終了コード0で裏付け）
- Patch作成が
git push rad HEAD:refs/patchesというGitの操作体系の中に自然に収まっている。専用UIを覚え直す量が少ない --titleや--messageなどのフラグで主要操作が非対話でも完結する。スクリプト化・自動化がしやすい- 完全オフラインのネットワーク内でも全機能が動いた。local-firstは宣伝文句でなく実装として本物だった
うまくいかなかったこと・制約
- レビューは簡素。accept/rejectと全体コメントはできるが、GitHubのような行単位コメント・レビュースレッド・approveの強制はない（公式も「高度なレビュー機能はこれから」と明言している）
- 公開seedノード経由の共有は今回未検証。今回の検証はノード同士を直接接続したため、実運用で使う公開seed（
iris.radicle.network等）経由の同期・可用性は確認していない。検証でき次第この記事に追記する - 同期の状態を見る習慣が要る。デフォルトの購読範囲（scope）は
rad initした側がall、cloneした側がfollowedで、誰の変更が自分に届くかはこの設定に依存する。GitHubのように「サーバーを見れば全部ある」という単一の正解場所はない - CIは本体に含まれず、Radicle CI Broker＋アダプターという別コンポーネントの構成になる（今回は対象外）。GitHub Actions感覚での移行はできない
- 検証はLinuxコンテナで行った。Windowsネイティブビルド・Desktopアプリは試していない
公式説明との差
公式サイトの説明（P2P複製・local-first・IssueとPatchのGitオブジェクト化）は、試した範囲では宣言どおりに動いた。むしろ公式ガイドが「まだない」と書いているレビュー機能が部分的に動いた分、実装がドキュメントより先行している印象だ。一方で「ネットワークの実際の可用性」——自分のノードを落としても公開seedからcloneできるか——は公式が最も推している性質なのに、今回の閉じた環境では検証できていない。ここは追試が必要で、現時点では公式説明の引き写しをしないでおく。
向いている人・向いていない人
向いている人: GitHubが止まったら仕事が止まる状況を減らしたい個人開発者。OSSの配布先を一社に依存させたくない人。鍵ベースのIDと分散モデルという考え方自体に価値を感じる人。既存のGit習慣（branch/push/merge）のままP2P共有を試したい人。
向いていない人: 行単位レビューやCI/CD統合を含むGitHubの開発体験を丸ごと置き換えたい人・チーム。IssueやPRを非エンジニアも触るプロジェクト。「とりあえず全部ここにあれば安心」という中央の管理画面が必要な人。
まとめ
「GitHub代替になるか」への現時点の答えは、コードの共有とレビューの基本フローに限れば、個人・小規模の公開リポジトリでは既に成立している。2ノード間で試した主要フローは全部動き、Gitの操作体系から大きくはみ出さない設計も好印象だった。一方、レビューの表現力・CI・エコシステム連携はGitHubの水準にはなく、「全部の置き換え」ではなく「依存を減らすための並行運用先」として捉えるのが現実的だ。まずは自分の公開リポジトリをひとつ rad init してミラーとして流しておく、という使い方から入るのが良さそうだ。