ウェブのバイブ コーディングを超えて

1. はじめに

コーディング エージェントが日常的なソフトウェア開発に不可欠なものになるにつれて、ベテラン エンジニアも初めてアプリをリリースしようとしている新しいビルダーも、構築方法と構築対象が根本的に変化しています。コーディング エージェントの使用を開始するときは、通常、「ゼロショット」プロンプトから始めます。これは、必要なことを人間の言葉で簡潔に伝える単一の指示です。この方法はすぐに問題に直面します。

  • 人当たりの良いバイアス: モデルは、リクエストをできるだけ早く完了しようとして、欠陥のある制約や前提を受け入れることがよくあります。また、作成したものが実際に意図したとおりに機能するかどうかを確認しません。
  • 検証のギャップ: エージェントはテストを作成しても、通常はテストが機能することを確認しません。ライブブラウザでウェブサイトを使用すると、隠れたバグ、レイアウトの崩れ、アクセスできないコントロールが表面化します。
  • 技術的負債: モデルのトレーニング方法と動作方法により、モデルが記述するコードは古いパターンや時代遅れのパターンに偏り、技術的負債が増加します。この技術的負債を管理するには、より多くのトークンと、より多くの人間とマシンの時間と労力がかかります。技術的負債は、ユーザー エクスペリエンスに悪影響を及ぼす可能性もあります。

4 ステップのゲームプラン

コーディング エージェントが要件に沿った優れたコードを生成できるように、次の 4 段階のプロダクト開発ライフサイクルを検討してください。

  1. 計画と設計: エージェントと共同でプロダクト要件ドキュメント(PRD)を作成し、本番環境の実装を開始する前に、ブラウザ内で PRD のプロトタイプを作成して設計してもらいます。次に、コーディングを開始する前に、PRD と設計からアーキテクチャ設計ドキュメント(仕様)のドラフトを作成します。
  2. コードとビルド: ゼロショット プロンプトではなく、PRD、設計、仕様に基づいてビルドするようエージェントに指示し、別のエージェントに作業の確認を依頼します。
  3. 繰り返す: 追加する新機能ごとに、手順 1 と 2 を繰り返します。
  4. デプロイ: 本番環境にリリースします。

このドキュメントでは、AI エージェントをアクティブなコラボレーション パートナーとして使用する方法について説明します。この方法は、技術的負債を削減し、出力コードの品質を向上させることを目的としています。AntigravityModern Web Guidance および DevTools for Agents と組み合わせて使用して、カジュアルな単語ゲームを構築し、AI 機能で強化します。次に、Firebase を使用して Google Cloud にデプロイし、友だちや家族と共有します。

学習内容

  • AI コーディング タスクをミニ プロダクト開発ライフサイクルとして扱う方法。
  • プロダクト要件とアーキテクチャ仕様を分離すべき理由。
  • マルチエージェント ワークフローをオーケストレートして、ブラウザで直接プロトタイプを作成し、コードを確認する方法。
  • サードパーティのスキルとツールを活用して、開発とユーザーの両方のエクスペリエンスを向上させる方法。
  • Firebase MCP を使用してウェブ アプリケーションを本番環境に直接デプロイする方法。

前提条件

  • 個人の Google アカウントと Google Cloud または Firebase プロジェクト(プロジェクトの設定の手順を参照)
  • HTML、CSS、JavaScript の基本的な知識があること。
  • ウェブブラウザ(Chrome など)。
  • Node.js がインストールされている(LTS を推奨)。

2. プロジェクトの設定

Google アカウント

個人の Google アカウントをまだお持ちでない場合は、Google アカウントを作成できます。

Google Cloud コンソールにログインする

個人の Google アカウントを使用して Google Cloud コンソールにログインします。

課金を有効にする

個人用の請求先アカウントを設定するには、Cloud コンソールで課金を有効にするに移動します。

Firebase プロジェクトを作成する

  1. Firebase コンソールに移動し、個人の Google アカウントでログインします。
  2. [プロジェクトを追加](または [プロジェクトを作成])をクリックします。
  3. プロジェクト作成ウィザードで、次の操作を行います。
    • プロジェクト名(wordup-web-app など)を入力するか、プロジェクトの設定時に設定した Google Cloud プロジェクトを再利用します。
  4. 請求先アカウントを接続する
    • Firebase コンソールのサイドバーの下部にあるプラン バッジ(「Spark」と表示されています)を見つけます。[Upgrade] をクリックします。
    • [従量課金制] プランを選択します。
    • [プロジェクトの設定] 手順で設定した請求先アカウントを選択します。
    • 選択を確認して、請求先アカウントをプロジェクトに関連付けます。(Firebase Hosting には十分な無料枠が用意されています。通常、このチュートリアルを完了しても費用は発生しません)。

ツールのインストール

  • Antigravity 2.0: 高速で最先端のコーディングを実現する最新の Gemini Flash モデルと組み合わせて使用する、主要なエージェント コーディング ハーネス。
  • Modern Web Guidance: 最新の CSS、HTML、JavaScript の記述を支援するエージェントをコーディングするスキル。Antigravity の [Settings] > [Customization] > [Build With Google Plugins] > [Modern Web Guidance] からインストールします。
  • エージェント向け DevTools: エージェントが Chrome を操作し、ライブ DOM を検査し、レイアウトをテストし、ランタイムでデバッグできるようにします。Antigravity の [Settings] > [Customization] > [Build With Google Plugins] > [Chrome DevTools] と Antigravity の [Settings] > [Customization] > [Add MCP Servers] > [エージェント向け Chrome DevTools] からインストールします。
  • Firebase MCP サーバー: プロジェクトのシームレスな設定と 1 回のプロンプトによるデプロイ。Antigravity の [設定] > [カスタマイズ] > [Google プラグインでビルド] > [Firebase と Antigravity の設定] > [カスタマイズ] > [MCP サーバーを追加] > [Firebase] からインストールします。

3. プランを立ててから開始する

エージェント コーディングでよくある誘惑は、ゼロショット プロンプト(「単語ゲームを作成して」)を送信して、あとは何とかなるだろうと期待することです。その結果、エッジケースがスキップされ、コードベースが肥大化し、バグ修正のサイクルが無限に続くことがほとんどです。

代わりに、各タスクをミニ プロダクト開発ライフサイクルとして扱います。コーディング エージェントには、コードを記述する前にアイデアを明確にするための共同パートナーとして機能する研究ツールと推論ツールが備わっています。アイデアを口に出すことで、問題が発生する前に質問を見つけて回答できることがよくあります。ソフトウェア エンジニアリングでは、これをラバーダック デバッグと呼びます。コーディング エージェントをラバーダックとして使用して、プロジェクトや機能を計画できます。

カジュアルな単語ゲームを開発しています。エージェントに、作りたいゲームの設計を依頼します。

I want to make a casual word guessing game. Go do deep research on those kinds
of games, then ask me questions to help me write a PRD for the game's features.

これがプロンプトの基本的な形です。ニーズに合わせてリミックスしてください。重要なのは、Deep Research を実行し、その調査に基づいて質問をすることで、作業の計画を立てるのに役立つことです。

コーディング エージェントの操作には多くのレビューが必要になるため、このプロンプトから始めます。完全な実装計画を小さな単位に分割すると、レビューがはるかに容易になり、エッジケースを早期に検出できるようになります。また、エージェントのトレーニング データ以外の知識を取り入れることができ、最も重要なこととして、レビューの合間に休憩を挟むことができます。

  • 「何」と「方法」を分離する: ユーザー エクスペリエンスとプロダクトの範囲を正式なプロダクト要件ドキュメント(PRD)で定義することで、を実現したいのかと、それをどのように実装するのかを分離できます。これにより、一度にすべてを処理するのではなく、プロダクト開発の 1 つの側面に集中できます。
  • エッジケースを早期に特定する: インタラクティブな Q&A セッションでは、設計や実装を開始する前に要件を明確にする必要があります。
  • アクティブなエージェント調査: エージェントのトレーニングは特定の日付で終了し、その情報が高度に要約されるため、ライブ調査から取得することで、見逃していた新しい情報を取得できます。

演習 1

次のアクティビティでは、プロジェクトを設定し、PRD を作成します。

  1. 出力を docs/plans/{{YYYY-MM-DD}}-{{description}}.md に保存するよう指示する命令を AGENTS.md ファイルに追加します。
  2. 上記の調査プロンプトを、必要に応じて調整して実行し、PRD を作成します。
  3. [ストレッチ ゴール] エージェントが実行していることで気に入らないことを見つけて AGENTS.md ファイルを更新し、プロンプトを再度実行します。

4. ブラウザでデザインする

静的な UI デザインは、見栄えはよいものの、エッジケース、制約、実際のユーザー操作を考慮していないモックアップに依存しています。コードと同様に、エージェントにサイト アプリケーションの「デザイン」を依頼すると、汎用的な(紫色のことが多い)デザインに収束します。

ウェブアプリの場合、エージェントの エージェント用 DevTools を通じてウェブブラウザを制御する機能を使用して、ブラウザ内で設計できます。デザインの忠実度を高めようとしているデザイナー、プロジェクトの UI と UX を改善しようとしているコーダーやビルダー、またはその両方が協力して作業する場合でも、実際に構築するメディアで作業することで、より良い結果が得られます。

ブラウザで設計すると、複数のエージェントが連携して 1 つの出力を生成するように調整することもできます。これらのサブエージェントは、特定のペルソナと目標を持つエージェントであり、連携して単独で動作する単一のエージェントよりも優れた結果を生み出すことができます。デザインでは、ビジュアル デザイン エージェント、ユーザー エクスペリエンス エージェント、アクセシビリティ エージェントが連携してデザインを支援し、ブラウザで直接表示するようにリクエストできます。

PRD に基づいてデザインを選択するのに役立つデザイン エージェントのパネルを開始します。

Using the PRD, start a panel of expert agents: one UX design, one web
accessibility, and one for visual design, and have them work together to design
3 different UI mockups and show them to me in-browser.

静的な媒体ではなく、構築する媒体(この場合はウェブ)で設計することで、管理が難しいエッジケースや制約を把握し、本番環境に忠実な視覚的なフィードバックをすぐに得ることができます。

演習 2

次のアクティビティでは、プロジェクトを設計します。

  1. 上記の設計プロンプトを、必要に応じて調整して実行し、設計を構築します。希望するさまざまなデザインの方向性(モダン、遊び心のある、リアルなど)に関するアイデアを含めます。
  2. 気に入ったデザインを選び、エージェントと協力してそれを改良します。
  3. エージェントに PRD を更新してもらい、合意したデザインを参照するようにします。
  4. ストレッチ ゴール: 選択したデザインでアクセシビリティ テストとレスポンシブ デザイン テストを実行し、それらの監査に基づいてデザインを調整します。

5. 仕様を作成する

承認済みの PRD(「何を構築するか」)と選択済みのビジュアル デザイン(「どのように見えるか」)がある場合、アーキテクチャ(「どのように構築するか」)に関する技術的な調整が必要になります。

技術設計書または仕様(略して spec)には、ファイル構造、状態管理、コンポーネント インターフェース、イベント パイプライン、依存関係が詳しく記載されています。コードを記述する前に仕様を作成すると、不整合や望ましくないコーディング パターンを早期に検出できます。これにより、推論やリファクタリングが難しいコードに変わる前に、それらを修正できます。

Write a detailed technical design document on how to implement the game with
the chosen design.

この変更を行う理由

  • アーキテクチャの明確さ: コンポーネントの階層と状態遷移フロー(IdleInGameEvaluatingGuessGameOver など)を定義することで、競合状態や脆弱なスパゲッティ コードを防ぐことができます。
  • 最新の標準に準拠: Modern Web Guidance を有効にすると、エージェントは、以前の重いライブラリをプルするのではなく、最新の標準(CSS @container クエリ、モーダルやヘルプ オーバーレイ用の組み込み 要素、モジュラー ES モジュールなど)を参照します。
  • 段階的なレビュー: 機能 PRD のレビューと技術設計ドキュメントのレビューを分離することで、ユーザー エクスペリエンスとは別にアーキテクチャを評価できます。

演習 3

  1. AGENTS.md に、出力を現在のフォルダに保存するよう指示します。
    PRDs should _always_ be written to the current project's root in `docs/plans/{{YYYY-MM-DD}}-{{description}}.md` format
    
  2. 設計ドキュメントのプロンプトを実行して確認し、ディレクトリ構造、イベント処理、ストレージなどの側面が網羅されていることを確認します。
  3. ストレッチ ゴール: アプリケーションのステートフローを説明する Mermaid 図を含める(まだ含まれていない場合)。

6. 最後に、アプリをビルドします。

PRD、UI モックアップ、設計ドキュメントが確立されたら、構築を開始します。これら 3 つの項目は、エージェントが作成すべきものについて明確で曖昧さのないガイダンスです。

サブエージェントを活用するもう 1 つの機会をご紹介します。コードのビルド後に実行して、ビルドされたものが事前の設計にどれだけ忠実であるかを確認したり、ビルドされたもののコード品質をチェックしたりできます。

Use the PRD, design doc, and mockup to implement the site, then send out 2
agents, one to check how closely you followed the requirements, and one to
review the code.

この変更を行う理由

仕様主導の開発とファーストパス レビュー担当者により、エージェントは明確で事前に審査された要件に基づいて構築でき、あなたに届く前に計画に沿って進められていることを確認する新しい視点を得て、品質と忠実度を向上させることができます。

  • 要件の精査: エージェントは、お客様が何を求めているかを推測する必要はありません。コードが記述される前に、実装以外のすべての内容がすでに確認されています。
  • 新しい視点: 新しいコンテキストで生成されたレビュー エージェントは、コードベースの構築による確証バイアスがないため、未処理のエッジケース、実装要件の欠落、その他のコードやプロダクトの詳細を見つけるのに効果的です。

演習 4

  1. ビルド プロンプトを実行し、レビューするファイルを指定します。
  2. 実行時の出力を確認します。要件を推論しながら、構築を試みていることがわかります。何か問題が発生しそうになったら、停止して修正できます。
  3. 開発用サーバーを実行して最終的なサイトを表示し、動作を確認します。
  4. ストレッチ ゴール: このプロセスをもう一度実行して、自動テストを追加します。
  5. ストレッチ ゴール: サイトの構築に使用する特定のフレームワークまたはテクノロジー スタックを選択します。PRD、モックアップ、設計ドキュメントが分離されているため、さまざまなフレームワークやテクノロジー スタックに簡単に適応できます。

7. 本番環境にデプロイする

計画、設計、コーディングが完了している。残りの作業は?本番環境にデプロイする。

Deploy this site to my Firebase project [YOUR_PROJECT_ID] using Firebase
Hosting.

演習 5

  1. プロジェクト ID を置き換えて、デプロイ プロンプトを実行します。
  2. エージェントから提供されたライブ ホスティング URL をコピーします。
  3. 一般公開 URL を開いて、デプロイされて動作していることを確認します。
  4. ストレッチ ゴール: エージェント用の DevTools を使用して本番環境サイトの Lighthouse 監査を実行し、Lighthouse スコアを改善するための調整を行い、更新を公開します。

8. [省略可] AI 補正

これで、静的辞書を使用して単語ゲームが完全に機能するようになりました。静的辞書を動的単語に変更するには、Prompt API の小さなローカル言語モデルを使用して、毎回 1 つずつプロンプトを表示します。

この機能はすべてのデバイスで利用できるわけではないため、プログレッシブ エンハンスメントを使用して、API とモデルが利用可能かどうかを確認します。存在する場合はそれを使用し、存在しない場合は静的リストにフォールバックします。

演習 6

学んだことをすべて実践してみましょう。

  1. エージェントと協力して、Prompt API を使用して有効な隠し単語を生成する PRD を作成します。
  2. ブラウザでダウンロードの進行状況バーと AI 統合 UI を設計します。
  3. 実装の仕様を記述します。(ヒント: エージェントを実行して、正しい API 構文が使用されていることを確認します)。
  4. 新機能を開発します。
  5. 本番環境にデプロイします。

9. まとめ

これで操作は完了です。エージェント コーディングのベスト プラクティスを使用して、最新のアクセシビリティに配慮した AI 対応のウェブ アプリケーションを構築、改良、強化、デプロイできました。

学習した内容

  • プロダクト主導のエージェント ワークフロー: タスクをミニ プロダクト ライフサイクル(PRD → 設計 → 仕様 → 構築)として扱うことで、負債、レビューのオーバーヘッド、やり取りの摩擦を減らす方法。
  • マルチエージェントの専門家パネル: 複数の AI サブエージェントを実行することで、作業の品質と忠実度を向上させる方法。
  • PRD と設計ドキュメント: 機能スコープ(計画)と技術アーキテクチャ(仕様)を分離することが、ゼロショット機能プロンプトよりもスケーラブルで正確なプロセスである理由。
  • シームレスなデプロイ: MCP サーバー(Firebase MCP など)を使用して、サイトのデプロイなど、サードパーティ システムへのアクセスを効率化する方法。