Same.new

Same.newを選ぶ理由

Same.newが最も真価を発揮するのは、白紙の状態からではなく、既存のものを出発点にする場合です。既存のWebサイトのURL、スクリーンショット、モックアップ、あるいは大まかな製品アイデアから始めて、すぐに編集可能なアプリケーションへと移行できます。そのため、「ゼロからデザインを考案する」よりも「構造的にこれに近いものを作り、そこから変更を加えたい」という要件がある場合に特に威力を発揮します。

このリファレンス優先のアプローチは、AI支援開発において意外とコストのかかる「既存のビジュアルシステムを精密なプロンプトに翻訳する」というステップを省略してくれます。余白、階層、ナビゲーションパターン、コンポーネント間の関係、レスポンシブ動作を個別に説明する代わりに、参照元そのものが仕様の一部となります。

ただし、URLクローニングを「他人の製品をそのまま複製してよいライセンス」と捉えるべきではありません。サードパーティのブランディング、著作権のあるアセット、独自のコピー、その他の保護された素材は、チームで適切に置き換える必要があります。一般的な開発パターンとしては、構造やインタラクションのアイデアを取り込み、生成された実装をオリジナルの製品へと適応させていくのが有効です。

主なワークフロー

Same.newを効果的に活用するには、まず何を初期仕様にするかを決めます。リデザインや移行の場合は既存のURL、Figmaなどのデザイン工程から進める場合はスクリーンショットやモックアップがビジュアルの基準となります。新規製品であれば、テキストによる説明から直接開始することも可能です。

初期アプリケーションが生成された後は、エージェントに無関係なビジネスロジックをいくつも追加させる前に、まずインターフェースを安定させることが効率的です。Same自体のガイドでも、小さく連続した指示を与えることが推奨されています。「1つのコンポーネントを変更し、認証を接続し、データベースを追加する」といった一連のリクエストは、プロジェクト全体を一度に変更する大きなリクエストよりも、検証や差し戻しが容易です。

ここで重要なのが、組み込みの履歴システムです。AIによるコード生成は、一度のアクションで大量のファイルを変更することがあるため、チェックポイントが実験の境界線として機能します。リスクの高い変更を加える場合は、大きな反復作業の前に「リミックス（複製）」を作成しておくことで、元のプロジェクトを巻き戻すことなく別の復旧経路を確保できます。

長期的なプロジェクトでは、チャットのコンテキストも無制限に蓄積するのではなく、リソースとして管理すべきです。タスクごとに焦点を絞ったチャットを開始し、現在の作業に関連するファイルや以前のコンテキストのみを添付することで、不要なコンテキスト処理を減らし、エージェントの目的を明確にできます。

向いている用途

Same.newは、リファレンス駆動のプロトタイピングに最適です。例えば、理想とする情報設計を体現しているインターフェースパターンを読み込み、基本構造を再現してから、コンテンツ、ブランディング、データモデル、インタラクションを新しい製品のものに置き換えることができます。これは、馴染みのないインターフェースをすべて言葉で説明しようとするよりもはるかに簡単です。

また、静的なデザイン案をすぐにテスト可能な実装へと変換するのにも役立ちます。「スクリーンショットからコードへ」をゴールにするのではなく、生成されたフロントエンドから、アプリケーションロジック、認証、永続データ、デプロイへと開発を継続できます。

既存の小規模なWebサイトを最新のJavaScriptスタックへ移行・再構築する際にも実用的です。SameはデフォルトでNext.jsを採用しており、生成されたファイルにアクセスできるため、ビジュアルビルダー内に閉じ込めるのではなく、通常のコードリポジトリの起点として活用できます。

実験的なプロジェクト、ランディングページ、SaaSのプロトタイプ、社内ツール、ダッシュボードなど、ブラウザベースの製品であれば、リファレンスから実用的なソフトウェアへの最短経路となります。なお、ネイティブモバイルアプリは対象外です。レスポンシブサイトやPWAはWebワークフローの範囲内ですが、iOSやAndroidのネイティブプロジェクトは主なターゲットではありません。

他製品との比較

Same.newは、Bolt.new、Lovable、v0、Replit Agent、Base44といった「プロンプトからアプリを作成する」製品と比較検討されるカテゴリーに属します。これらの中での明確な差別化要因は、ライブURLや画像を初期仕様として使用し、そこからビジュアルを再構築した上で、編集可能な開発環境で継続開発できる点にあります。

そのため、初期生成のビジュアル再現性は重要な比較基準となりますが、それだけではありません。本格的なプロジェクトでは、多段階の変更をどれだけ確実に処理できるか、生成されたコードを開発者がどの程度制御できるか、外部データベースや認証との接続性、破壊的な編集後の履歴管理、そしてプラットフォーム外への持ち出しやすさを比較すべきです。

SameのGitHubワークフローやソースコードのダウンロードオプションは、明確な移行パスを確保できるという点で評価に値します。一方で、インラインのAI支援を備えた従来のデスクトップIDEを主に求めている場合は、プロンプトベースのビルダーではなくAIコードエディタを比較すべきであり、ワークフローや選定基準は根本的に異なります。

推奨される構成

使い捨てのプロトタイプ以外では、構築開始時にプロジェクトの公開設定を確認してください。Sameのドキュメントによれば、新規プロジェクトはデフォルトで「公開（Public）」設定になっています。独自のデザイン、機密性の高いビジネスロジック、未発表の製品コンセプトを含む場合は、機密情報を導入する前に「非公開（Private）」に切り替える必要があります。

早い段階でGitHubと連携させることも有益です。リポジトリがプロジェクトの外部記録となり、CI、コードレビュー、別のホスティング環境、またはローカル開発へのクリーンな道が開かれます。これは、将来的に開発プラットフォームを変更する際のコスト削減にもつながります。

バックエンドサービスは、アプリケーションのデータの境界が明確になってから導入するのがベストです。リレーショナルな永続化が必要な場合はデータベース連携を、認証は別途追加するという形をとります。インフラの変更を独立させておくことで、不具合が発生した際に、UIコード、ロジック、スキーマ変更、外部設定のどこに原因があるかを特定しやすくなります。

カスタムMCP（Model Context Protocol）のサポートは、無差別にツールを有効化するのではなく、拡張レイヤーとして扱うのが賢明です。現在のタスクに関連するサービスのみを接続し、特にリポジトリやデータベースを操作できるMCPサーバーについては、付与する権限を慎重に確認してください。

本番環境へのデプロイは、Sameに統合されたNetlifyへのワークフローが最も簡単です。より詳細なインフラ制御が必要な場合は、コードをGitHubにプッシュするか、プロジェクトをダウンロードして独自のデプロイパイプラインを構築することも可能です。

移行に関する注意点

Sameのプロジェクトは、ブラックボックス化された独自のページ形式ではなく、標準的なコードベースで構築されているため、閉鎖的なビジュアルビルダーよりも移行が現実的です。デフォルトのアーキテクチャはNext.jsベースで、JavaScript/TypeScriptのエコシステムを中心に、実行環境にはBunが使用されています。

有料プランのユーザーはプロジェクトのコードをダウンロードでき、GitHub連携を利用して開発をSameの外部へ移すこともできます。移行前には、最終的な動作状態をコミットし、環境変数を特定し、接続されているサービスをドキュメント化し、移行先で再作成が必要な認証やデータベース、MCPの認証情報を確認してください。

内蔵のターミナルを永続的なインフラと誤解しないよう注意が必要です。環境はコンテナ化されており、ページをリフレッシュするとターミナルの操作内容はリセットされます。永続的な変更は、一時的なシェル状態に依存させるのではなく、プロジェクトファイル、依存関係の設定、リポジトリ、または外部サービスに反映させる必要があります。

Next.js互換のワークフローへの移行は比較的スムーズですが、全く異なるプラットフォーム（例えばWordPressなど）への変換は、アーキテクチャが異なるため直接的な移行パスはありません。その場合、生成されたプロジェクトはリファレンス実装として扱い、必要なHTML、CSS、アセット、ロジックを抽出して適応させる形になります。