GitHub Replicaとは？料金・使い方・デザインシステムを使うAIプロトタイピングの始め方

GitHub Replica（レプリカ）は、チームのデザインシステム、コンポーネント、UIパターン、ドキュメントをガイダンスとして使い、自然言語から操作可能なプロトタイプを作るオープンソースツールです。GitHub Designが開発し、2026年10月28日に公開されました。GitHubは、デザイナー、PM、エンジニアがGitHub Copilotアプリ上で試作・修正を進める用途として案内しています。GitHub公式の発表

一般的な「プロンプトから画面を作る」ツールとの違いは、見た目を似せることだけではなく、チームが承認したコンポーネント、パターン、ドキュメントを生成時の判断材料にできる点です。Replicaは、各チームの設計・開発の進め方に合わせてツールとガイダンスを調整できる構成として公開されています。Replica公式リポジトリ

結論：Replicaが向く場面・向かない場面

Replicaは、完成した本番コードを無確認で出荷するための製品としてではなく、既存プロダクトの制約を踏まえて、仕様の認識合わせ、画面遷移の検討、ユーザーテスト、チームレビューを早めるためのプロトタイピング環境として捉えると使いどころを判断しやすくなります。

この表はMojiによる一般的な設計上の目安です。実際の適合性は、デザインシステムの整備度、入力資料の鮮度、利用するモデル、テスト対象の画面・操作、許容できない誤りによって変わります。

GitHub Replicaでできること

公式リポジトリでは、Replicaはローカルでの試作を起点に、必要に応じてチーム共有用のHubを追加できる構成として説明されています。ローカル試作だけならHubは不要です。Replica公式リポジトリの構成説明

公式リポジトリでは、MinimalとCoreAI Sandboxという2種類のStarterが案内されています。Starterは出発点であり、既存プロダクトに同じ構成を採用することや、特定のフレームワークを必須とすることを意味しません。自社リポジトリへ組み込む場合は、既存の依存関係、開発手順、レビュー方法を優先して確認してください。

料金：Replica本体はMITライセンス、利用費は周辺サービスで分けて考える

ReplicaのリポジトリはMITライセンスです。したがって、Replica本体についてGitHubへ支払うソフトウェアライセンス料は案内されていません。一方で、「無料でチーム運用できる」とは限りません。AIモデル、GitHub Copilot、Hubを動かすインフラ、ドメイン・DNS・HTTPS、保守の費用は別に確認する必要があります。ライセンスと利用要件が記載された公式リポジトリ

料金を比較するときは「月額だけ」で決めず、1プロトタイプあたりのモデル利用量、レビュー参加者数、Hub運用の固定費、変更時の保守工数を分けて見積もってください。自前プロバイダー接続はpublic previewであり、一般提供済みの固定仕様として扱わないことが重要です。Copilot要件とHub要件の公式説明

最短で始める手順：まずはローカルだけで1画面を作る

チーム共有基盤まで一度に構築しようとすると、サーバー・DNS・権限設計が先行します。初回は、既存のデザインシステムを使った1つの画面または短い導線をローカルで試し、再現性を評価してからHubを検討する進め方をMojiでは提案します。

1. 対象を「意思決定したい仮説」へ限定する
   例：「架空の例：検索条件の追加で、初回利用者が目的の案件を絞り込めるか」。画面を増やす前に、誰が何を判断するための試作かを一文で決めます。
2. プロトタイプ専用リポジトリを用意する
   公式のStarterを使う場合も、既存のアプリを使う場合も、プロダクト本体へ直接変更を加える前に、試作の範囲と変更の扱いを決めます。公式ガイドは、ローカルで始める場合にHubやGitHubリポジトリが必須ではないこと、既存リポジトリを使う場合は既存のファイルと履歴を保持することを案内しています。Replica公式リポジトリ
3. 既存資料を「参照可能なガイダンス」に整える
   トークン、コンポーネント、画面パターン、文言、禁止事項、状態別の振る舞いを渡します。公式ガイドでは、承認済みのプロダクト資料、デザインシステム資料、コンポーネントやトークンの情報を参照し、生成されたガイダンス案をレビューしてから適用する流れが案内されています。
4. 自然言語で「目的・対象者・操作・非変更条件」を伝える
   画面名だけでなく、利用者、達成したい操作、既存ルール、変更してはいけない部分を指定します。
5. 起動・操作・ビルドで確認する
   利用するStarterまたは既存リポジトリのREADMEに従ってローカルで起動し、対象の操作を試します。型検査、テスト、ビルド、静的解析などの確認項目は、採用した構成と変更内容に合わせて決めてください。
6. レビュー観点を固定して、比較可能にする
   見た目の印象だけで決めず、後述するチェックリストで「ガイド逸脱」「操作不能」「仮説に答えられない」を記録します。

プロンプトのテンプレート

次はMojiによる提案テンプレートです。実在のプロダクト名、顧客情報、未公開の仕様を外部モデルへ渡してよいかは、契約・設定・社内ルールを確認してから判断してください。

目的：［検証したい仮説］
対象ユーザー：［役割・利用状況］
作りたい導線：［開始画面 → 操作 → 成功状態］
使う既存要素：［コンポーネント名、トークン、画面パターン、参照文書］
必ず守ること：［文言、権限、アクセシビリティ、変更禁止の領域］
プロトタイプ上で表現してよい仮の挙動：［ダミーデータ、疑似成功状態など］
確認したいこと：［ユーザーテストまたはレビューで答えたい問い］
完了条件：［どの画面・状態・操作が確認できればよいか］

「きれいな管理画面を作って」のように目的だけを渡すよりも、利用者、操作、参照資料、制約、完了条件を分ける方が、修正時に何を維持すべきかをチームで確認しやすくなります。AIへ渡す情報の選び方自体は、コンテキストエンジニアリングとは｜プロンプトエンジニアリングとの違いと実務での設計対象も参考にしてください。

デザインシステムを渡すときの入力設計

Replicaで既存デザインシステムとの整合を高めたい場合、資料を大量に渡すこと自体が目的ではありません。「何が正で、どの条件で使い分け、何をしてはいけないか」を、実装・レビューに利用できる単位へ整理する必要があります。

入力の品質と量は別問題です。情報が古い、矛盾している、正本が不明である場合、より多くの資料を渡しても整合は保証できません。まず正本・責任者・更新日を決め、試作で守るルールを優先順位付きで渡してください。

品質をどう評価するか：生成物の「見た目」だけで採否を決めない

GitHubの公開情報だけから、Replicaの生成品質を「高品質」または「本番利用可能」と判定することはできません。評価結果は、使うモデル、ガイダンスの品質、対象画面、求める操作、許容誤差で変わります。そこで、同じ入力・同じ評価ケースを使って、候補となる設定や運用を比べます。

以下はMojiによるプロトタイプ評価表です。合格ラインは、対象業務の重要度と人による修正・確認の余地に応じて設定してください。

生成AIを含む仕組みの評価設計は、モデルだけでなく入力、検索・参照、ツール、最終成果物まで分けて見る必要があります。評価ケースの作り方は、LLM評価の進め方｜モデル選定を導入判断につなげる比較基準・手順・チェックリストも参照してください。

共有用のReplica Hubを導入する前のチェックリスト

Replica Hubは任意の自己ホスト型コンポーネントです。組織がHubを運用し、GitHubがHubをホストしない構成のため、単なるプレビュー共有サービスではなく、運用対象として評価します。公式リポジトリでは、Hubが公開・レビュー活動を自身のデータベースへ記録し、その活動イベントを90日間保持すると案内されています。また、自己ホストHubを使っても、GitHubサービスや選択したAIプロバイダーにはそれぞれのデータ処理・利用条件がある点に注意が必要です。ReplicaのData and privacyに関する公式説明

• 公開対象のプロトタイプに、顧客情報、秘密情報、実在の認証情報、未公開の画面キャプチャが含まれないか。
• 誰が公開、閲覧、コメント、設定変更、ログ出力先の設定をできるか。
• Hubのサーバー、ドメイン、ワイルドカードDNS、HTTPS証明書、バックアップを誰が管理するか。
• レビュー活動の保持期間、削除方法、エクスポート先を社内規程と照合したか。
• AIモデル提供者へ渡るプロンプト、コード、添付資料の範囲と、契約・設定を確認したか。
• 脆弱性報告、アップデート、障害時の停止・復旧を担当する責任者が決まっているか。

生成AIに入力する情報、接続先、ログ、権限を業務単位で確認する考え方は、生成AIの情報漏洩対策｜入力・権限・契約・検証で決める実務チェックリストで詳しく解説しています。

プロトタイプから本番実装へ移すときの境界

Replicaで確認しやすいのは、主に「この画面・導線なら意図が伝わるか」「操作の流れに無理がないか」という仮説です。本番実装へ移す際は、プロトタイプのソースを採用するかとは別に、次の項目を実装・レビュー対象として起票してください。

本番化の判断では、「画面が動く」だけでなく、誰が変更をレビューし、どのテストを通し、どの失敗で停止するかを決めます。AIが関与する開発作業のレビュー設計については、AIエージェントで開発速度が上がるほど増えるレビュー・運用負荷の設計も参考にしてください。

よくある質問

GitHub Replicaは無料ですか？

Replica本体はMITライセンスのオープンソースです。ただし、GitHubホストモデルを使う場合のCopilot契約、自分のモデルプロバイダーを接続する場合のモデル利用料、Hubを共有運用する場合のサーバー・ドメイン・保守などは別に発生し得ます。自前プロバイダー接続はpublic previewとして案内されています。Replica公式リポジトリ

GitHub Copilotは必須ですか？

公式に案内されているcanvasワークフローでは、GitHub CopilotアプリとGitHubサインインを使います。モデルはCopilotプランのGitHubホストモデル、またはpublic previewの自前プロバイダー接続を選べるとされています。一方、完成したプロトタイプの閲覧やHub上のレビューにはCopilotサブスクリプションは不要と案内されています。Copilot requirementsの公式説明

Windowsで使えますか？

2026年10月28日時点の公式リポジトリでは、ローカルプロトタイピングの要件としてmacOSまたはLinux、Git、Node.jsとnpmが記載されています。Windows対応を公式仕様として確認できないため、本番導入の前提にはせず、チームの対象環境で公式ドキュメントと実機検証を確認してください。What you needの公式説明

生成したプロトタイプをそのまま本番コードにできますか？

そのまま採用できるかは、プロダクトのアーキテクチャ、セキュリティ要件、テスト、依存関係、ライセンス、保守責任によって変わります。GitHubはReplicaを、アイデアをインタラクティブなプロトタイプへ変え、チームで試し改善するツールとして説明しています。本番採用前には、通常のコードレビューと品質・セキュリティ確認を別途行ってください。GitHub公式発表

まとめ：最初に検証すべきは「生成能力」ではなく「既存ルールを守って議論を速められるか」

GitHub Replicaの価値は、自然言語で画面を生成できることだけではありません。既存のデザインシステムとドキュメントを、試作のガイダンスとして扱える点にあります。

導入の最初の一歩は、Hubを全社展開することではなく、1つの導線に対象を絞り、正本のデザイン資料を渡し、同じ評価表で「整合・操作・仮説検証・修正可能性」を確認することです。その結果をもとに、ローカル試作を継続するか、Hubを含む共有環境へ投資するか、本番開発フローとどこで接続するかを判断してください。