Replica Hubとは？セルフホストでプロトタイプを共有・コメントする方法と運用チェックリスト

Replica Hubは、GitHub Designが公開したオープンソースのAIプロトタイピングツール「Replica」で作成したプロトタイプを、組織が運用する環境で公開し、チームが試用・コメントするための任意コンポーネントです。GitHubは2026年10月28日、Replicaを公開し、任意のセルフホスト型Replica Hubでプロトタイプを共有して、チームがコメントできると案内しました。GitHub Changelog：Introducing Replica

Replica本体はローカルで試作できます。Hubを使う場合に追加されるのは、公開済みプロトタイプのホスティング、チームによる閲覧、画面上のコメント、GitHubリポジトリと連携したレビューです。GitHubがHubをSaaSとして運用するのではなく、組織が自らサーバーを用意・管理する構成である点を、導入前に押さえてください。Replica公式：共有ホスティングとチームフィードバック

本記事の仕様確認日は2026年10月28日です。公式仕様と、以降で示すMojiによる実務上の提案を分けて説明します。Replicaは公開直後であり、提供条件、設定画面、運用手順は変更される可能性があります。導入時には、公式リポジトリと自組織で固定した導入バージョンを再確認してください。

Replica Hubとは：Replica本体との役割分担

公式リポジトリでは、Hubは任意コンポーネントとして扱われています。ローカルでのプロトタイピングにHubは必要ありません。一方、Hubを使う場合は、公開したプロトタイプをチームが試用し、コメントを残す流れを作れます。Replica公式リポジトリ（固定コミット）

Replicaでの試作、デザインシステムの渡し方、ローカル利用の始め方は、GitHub Replicaとは？料金・使い方・デザインシステムを使うAIプロトタイピングの始め方で解説しています。

導入前に判断する：Hubが必要なチーム・まだ不要なチーム

公式ガイドは、Hub導入前にLinux、Docker、Docker Compose、永続データ領域とバックアップ、専用ドメイン、ワイルドカードDNS、HTTPS、GitHub側の権限・承認を確認するよう案内しています。また、プロトタイプにはパスワード、アクセスキー、実顧客データを含めず、サンプルデータを使うよう明記しています。Replica公式：導入前の確認事項

セルフホスト構成：最小限に分けて考える

Hubを単なるコメント機能付きサイトとして捉えると、運用責任を見落としやすくなります。Mojiでは、少なくとも次の5領域に分けて担当と復旧手順を決めることを提案します。

1. Hubサーバー：Linux上でDockerとDocker Composeを利用し、Hubコンテナと永続データを運用します。
2. ドメインとTLS：Hub本体のホスト名に加え、プレビュー向けのワイルドカードDNSとHTTPSを準備します。Hubとプレビューには、他用途のアプリと共有しない専用ドメインを用意する前提です。
3. GitHub App：組織所有の非公開GitHub Appを作成し、対象リポジトリへインストールします。
4. GitHub Actions：プロトタイプのブランチをビルドし、Hubが取り込む成果物を作ります。
5. バックアップと秘密情報：Hubデータと、復元に必要な鍵・デプロイ秘密情報を分けて管理します。

固定コミット時点のデプロイスクリプトには、設定作成、起動・停止、状態確認、ログ確認、対応リリースへの更新のコマンドが用意されています。ただし、コマンドを実行できることと、監視・バックアップ・障害復旧まで含む運用が成立することは別です。Replica Hubデプロイスクリプト（固定コミット）

共有からコメントまでの標準フロー

チームレビューでは、「作る」「公開する」「見る」「直す」を分けると、試作の変更と正式プロダクトの変更を混同しにくくなります。以下は公式の公開・コメント機能を前提にした、Mojiの運用例です。

1. 基準となるリポジトリを用意する：デザインシステムのガイダンス、コンポーネント、開始ページをレビュー済みのデフォルトブランチへ置きます。
2. 試作は専用ブランチで行う：プロトタイプごとにブランチを分け、デフォルトブランチを直接変更しない運用にします。
3. ローカルCanvasで動作を確認する：公開前に遷移、空状態、主要な操作を確認します。利用データは架空の例または承認済みのサンプルデータにします。
4. PublishでBuildを作成する：公開操作後にworkflowがビルドし、HubがそのBuildを取り込みます。GitHub workflowの成功だけではなく、HubがBuildを取り込んだことを確認します。
5. Internal prototype linkを共有する：通常の社内レビューでは内部リンクを使います。閲覧者にはGitHubへのサインインと対象リポジトリのread権限が必要です。
6. 画面上でコメントする：レビュアーは要素または領域を指定してコメントし、返信、解決、再オープンを行えます。
7. 修正の優先度を決める：コメントを「要件の誤解」「操作不能」「文言・視認性」「将来検討」に分け、採用する変更だけを次のBuildへ反映します。

内部リンクでのレビューにはGitHubサインインとリポジトリread権限が必要です。コメントは要素または領域に紐付けて追加でき、会話は返信・解決・再オープンできます。Replica公式：共有とコメントの手順

権限設計：閲覧・公開・運用管理を分ける

公式ガイドでは、プロトタイプ作者には公開に必要なリポジトリwrite権限、内部リンクのレビュー担当者にはread権限が案内されています。Hubは各リポジトリページで利用者の現在のGitHubアクセスを確認し、GitHubがアクセスを確認できない場合は、そのリポジトリへのリクエストを拒否します。Replica Hub security（固定コミット）

ただし、この確認を退職・停止・失効への継続的なアクセス遮断と同一視してはいけません。固定コミット時点の公式security.mdは、Hubが継続的なアカウント停止を現時点で強制しないこと、OAuth受け入れ後に一時的なGitHubユーザートークンを破棄し、ユーザートークンを再検証せずにブラウザセッションを復元することがあると説明しています。また、停止アカウントに対する本番実験は行われておらず、当該提案のセキュリティ受け入れも保留中です。したがって、GitHubのアカウント停止・リポジトリ権限削除だけをもって、既存のHubブラウザセッションやCanvas接続が自動的に無効化されるとは扱わないでください。Replica Hub security：Account suspension proposal

注意：組織所有の非公開GitHub Appで公開リポジトリを接続する場合、組織メンバーがHub上のレビューを読める構成になり得ます。リポジトリの可視性を変更する前には、レビューの可視性も合わせて確認してください。Replica Hub security：公開リポジトリのレビュー可視性

コメントを「直せるフィードバック」にするテンプレート

「ここを改善してほしい」だけでは、作者が再現条件や完了基準を判断しにくくなります。次のテンプレートは、Mojiによる提案です。

【種別】要件の誤解／操作不能／表示・文言／確認したい仮説
【対象】画面名・状態・操作手順
【観測したこと】例：「検索語を入力しても、0件状態になる条件が分からない」
【期待すること】例：「一致しない場合は、0件であることと検索解除の操作を表示する」
【優先度】今回のレビューで修正／次回候補／判断保留
【確認方法】例：「『zzzz』で検索し、空状態と解除ボタンが表示されること」

コメント数を増やすことより、作者が「何を変え、どの状態で確認するか」を判断できる粒度にそろえることを優先します。

データ管理とセキュリティ：セルフホストでも確認が必要なこと

セルフホストは、すべてのデータが外部へ出ないことを自動的に意味しません。公式リポジトリでは、Hubのアクティビティ記録は自動的にGitHubへ送信されない一方、GitHubサービスや選択したAIプロバイダーには別のデータ取り扱い・利用条件があると説明されています。生成に使うモデル、GitHub Actions、リポジトリ、Hubの各経路を分けて確認してください。Replica公式：Data and privacy

• プロトタイプの入力：本番のパスワード、アクセスキー、実顧客データは使わず、承認済みのサンプルデータに置き換えます。
• レビュー内容：コメントに顧客名、契約条件、未公開の脆弱性情報を記載する必要があるなら、保管・閲覧範囲を情報セキュリティ担当と確認します。
• 公開リンク：Public share linksは既定で無効です。有効化した場合、アクティブな公開リンクを知る人は、サインインなしで対象Buildを閲覧できます。公開リンクにはチームのレビュー会話は含まれず、匿名閲覧者はコメントできません。Replica公式：Public share links
• 分析送信：Hubはプロトタイプ登録、Build公開、レビュー会話の変更に関するイベントを90日保持します。Segment、Mixpanel、独自の公開HTTPSエンドポイントへの送信は、リポジトリ管理者が設定した場合に行われます。Replica Hub analytics（固定コミット）
• バックアップ：公式の完全バックアップ対象はSQLiteデータベース、Buildファイルとスクリーンショット、learning stores、暗号化済みGitHub App設定です。データベース暗号鍵とデプロイ秘密情報は別に保管する構成が示されています。Replica Hub backups and restore（固定コミット）

生成AIへ入力する情報の分類、接続先、ログ、承認を含む運用設計は、生成AIの情報漏洩対策｜入力・権限・契約・検証で決める実務チェックリストも参考にしてください。

料金・利用条件：公開情報で確認できる範囲

2026年10月28日時点で、Replicaはオープンソースプロジェクトとして公開されています。固定コミット時点で確認した公式リポジトリには、Replica Hub固有の月額料金表は掲載されていません。Hubは組織が自らホストする構成のため、導入費用を一律には断定せず、少なくとも次を分けて見積もってください。Replica公式：利用要件とHubの位置付け

• Hubを動かすサーバー、ストレージ、バックアップ、ドメイン、証明書、ネットワークの費用
• GitHub Actionsの利用条件・実行時間・ストレージに関する費用
• GitHub Copilotの契約、または接続する外部モデルプロバイダーの料金
• 更新、障害対応、アクセス棚卸し、復旧訓練に必要な運用工数

公式リポジトリでは、完成したプロトタイプの閲覧・HubでのレビューにCopilotサブスクリプションは不要とされています。一方、文書化されたCanvasの作成フローにはGitHub CopilotアプリとGitHubサインインが必要です。外部モデルプロバイダー接続はpublic previewとされ、プロバイダー側の費用・条件が適用されます。Replica公式：Copilot requirements

導入チェックリスト

開始前

• □ Hubを使う目的を「社内レビュー」「社外デモ」など一つに絞った
• □ 対象リポジトリの所有組織、公開範囲、read/write権限を決めた
• □ Linux、Docker、Docker Compose、永続ストレージ、バックアップを用意できる
• □ Hub専用ドメイン、ワイルドカードDNS、HTTPSを準備できる
• □ GitHub AppとGitHub Actionsの利用を組織内で承認済みである
• □ 利用するCopilotプランまたは外部モデルプロバイダーのデータ条件を確認した
• □ 退職・アカウント停止時に、GitHubの権限削除だけでHubアクセスが自動的に失効すると扱わない方針を決めた
• □ オフボーディング時にHubブラウザセッションとCanvas接続をどう確認・失効・再承認させるかを、導入する版と自組織の手順で試験する担当者を決めた

最初のレビュー前

• □ デフォルトブランチにレビュー済みのガイダンスと開始ページがある
• □ プロトタイプを専用ブランチで作成している
• □ 実顧客データ、秘密情報、本番の認証情報をサンプルデータへ置換した
• □ 作者、レビュー担当者、リポジトリ管理者、Hub管理者を分けた
• □ 内部リンクで、read権限を持つ別の担当者が閲覧・コメントできることを確認した
• □ 公開リンクを使う場合は、対象Build、閲覧範囲、有効期限、削除担当者を記録した

継続運用

• □ 公開共有を有効にするか、誰が承認するか、有効期限をどうするかを決めた
• □ バックアップ対象と復旧責任者を明文化した
• □ Hub更新時に導入したイメージの版またはダイジェスト、設定、動作確認結果を記録する
• □ リポジトリ権限、Hub管理者、分析送信先を定期的に棚卸しする
• □ 退職・異動・アカウント停止時は、GitHub組織・リポジトリ権限、Hubの既存ブラウザセッション、Canvas接続、公開リンクを別々に確認し、確認結果を残す
• □ 公開共有を無効化した場合に、既存の公開リンクと公開プレビューへのアクセスが遮断されたことを確認する
• □ コメントを解決・保留・不採用に分類し、判断理由を残す

まとめ：Hubは「公開機能」ではなく、レビューの責任範囲を整える基盤

Replica Hubは、Replicaで作った試作品を単にURL化する仕組みではありません。GitHubリポジトリの権限、ブランチ、Build、画面上のコメント、サーバー運用、バックアップを組み合わせ、具体物を見ながらレビューを進めるための基盤です。

一方、現行の公式security.mdには、停止アカウントに対する継続的な失効検知を保証しない制約が明記されています。Hubのリポジトリアクセス確認を利用していても、退職・停止・失効時のHubブラウザセッションやCanvas接続は、GitHub権限削除だけで安全に処理されたとみなさず、自組織の導入版で確認・失効手順を検証してください。

最初から社外公開や本番データの利用を目指す必要はありません。Mojiでは、社内限定・サンプルデータ・内部リンク・小さな1プロトタイプで、公開からコメント解決、オフボーディング時のアクセス確認までを一巡させることを提案します。その結果をもとに、Hubの権限、公開範囲、失効対応、運用負荷がチームのレビュー頻度と釣り合うかを判断してください。