00:00:00コーディングエージェントを活用する際 フレームワークが必要だということは誰もが知っていますが
00:00:04シンプルで自分に馴染み 長期的に進化させられるものを持っている人は多くありません
00:00:09GitHubには過剰に設計されたフレームワークが溢れています 多人数エージェントシステムなど
00:00:15開発者の努力は尊重しますが 多くの場合 必要なのは
00:00:19タスクを確実にこなしてくれる極めてシンプルなものです 皆さんには実現したい素晴らしいアイデアがあり
00:00:24エージェントのワークフロー構築に 実際のコーディング以上の時間を
00:00:29費やしたくはないはずです そこで今回ご紹介するのが
00:00:35私がコーディングエージェントで新プロジェクトを始める際に 毎回使っている超シンプルなフレームワークです
00:00:40既存のコードベースを扱う「ブラウンフィールド開発」は少し勝手が違うので 別の動画で解説します
00:00:45今回は「グリーンフィールド開発」に焦点を当てます 新しいものを構築する際に 素早く軌道に乗るための
00:00:50シンプルなフレームワークを目指します ここで説明する内容はすべて普遍的なものです
00:00:56使用するコーディングエージェントに関わらず これらの原則は適用できます この動画は大きく2つのパートで構成されており
00:01:00内容を具体的に理解してもらうために 実際にライブで構築しながら解説していきます
00:01:05現在 私のコードベースには ほとんど何もありません
00:01:11AIレイヤーを除いては いくつかのコマンドやスキルを持ち込んでいますが
00:01:16これが私のすべてのプロジェクトの起点となります 今回はゼロから作成するので
00:01:21初期プランニングから始め PRD（製品要求仕様書）を作成する必要があります これはアプリケーションの
00:01:27最小実行可能製品（MVP）を作成するための初期の作業範囲となります
00:01:32実際のコーディングに入る前に 初期のAIレイヤーをセットアップするなど やるべきことは山ほどあります
00:01:37その後 PRDを各作業フェーズに分割し
00:01:43PIVループで片付けていきます その意味や具体例については後ほど説明します
00:01:47また 実装を進める過程で 常に守るべき「4つの黄金律」についても触れていきます
00:01:52これらの黄金律は PRD作成 AIレイヤー構築
00:01:57そしてPIVループの実行過程に自然に組み込まれます 例えば コンテキスト管理です
00:02:03コンテキストは AIコーディングアシスタントを使う上で最も貴重なリソースであり
00:02:08これが一貫したテーマとなります また すべてをコマンドやスキル化することや システムを進化させるマインドセットも重要です
00:02:14私たちが目指しているのは 信頼性と
00:02:18再現性のあるシステムを構築することだからです 全体を通して それについてお話しします
00:02:23核心的なテーマをいくつか網羅する 非常に価値のある動画になるでしょう
00:02:28まずは初期プランニング 私が「AIレイヤー」と呼んでいるものの作成から始めます
00:02:34それが何であるかを説明し 今から一緒に構築していきましょう AIレイヤーとは
00:02:39コーディングエージェントのコンテキストとなる コードベース内の全資産のことです 例えばPRD「何を構築するか」
00:02:45グローバルルール「どう構築するか」 コマンド「コーディングエージェント用の
00:02:50再利用可能なワークフロー」などです まずは主要なものに集中します そしてサブエージェント「調査の委譲」です
00:02:55一般的に 私がAIレイヤーをどのように扱っているかについては リソースを用意していますが
00:03:01新しいプロジェクトには 汎用的なコマンドセットを持ち込むようにしています
00:03:07重要なのは コードベースが成長し 構築が進むにつれて
00:03:13特定のユースケースに合わせて コマンドも進化させ より強力で具体的なものにしていくことです
00:03:18これが私のおすすめの手法です ぜひこれを起点にしてみてください
00:03:23概要欄にGitHubリポジトリへのリンクを貼っておきます これをシンプルに保つ理由は
00:03:27皆さんが自分のユースケースや作業スタイルに合わせて 簡単に進化させられるようにするためです
00:03:33BeemadやGitHub spec kitのような複雑なフレームワークよりも これを推奨するのはそのためです
00:03:38それらも強力ですが 自分のものにするのは難しいのです 皆さんにはこれを自分のものにしてほしいのです
00:03:42では今から PRD全体を作成する様子をお見せします
00:03:48コードベースの初期ルールを定義し 最初のコマンドを少しカスタマイズしてみます
00:03:52サブエージェントについても随時お話しします PIVループで実際のコードを書く前に
00:03:57かなりのプランニングを行いますが これは非常に重要です
00:04:03事前に計画を立てるのは 遠回りに見えるかもしれませんが 良い計画があれば
00:04:07つまり 優れたルールやPRDがあれば その後のすべての開発は
00:04:13格段に速く 信頼性の高いものになります ではPRDから始めましょう 「仕様書」と呼ぶ人もいますね
00:04:18要するに アプリケーションの初期バージョンを構築するための全作業範囲のことです
00:04:24しっかりとした土台ができれば その後はブラウンフィールド開発へと移行します
00:04:28それについては次の動画で解説しますので 楽しみにしていてください さて 私のClaude Codeですが
00:04:34AIレイヤー以外はほぼ空のプロジェクトです まずはカジュアルな会話から始めます
00:04:40自分のアイデアや 技術スタック アーキテクチャについての案を伝えるだけです
00:04:45まずは非構造的な状態で始めることで 着手が容易になります
00:04:50そして最終的に その会話をコンテキストとして利用し
00:04:55構造化された PRD を作成します それを実行するためのコマンドがありますが
00:05:01それは後ほど紹介するとして まずはアイデアから始めましょう
00:05:06この動画の面白い例として構築したいのは Linktreeのようなものです
00:05:12リンクを整理してまとめられる 自分専用のランディングページを作れるセルフホスト版です
00:05:16各リンクのクリック率などのアナリティクス機能も欲しいですね
00:05:20これは良い例です 単純すぎて何も考えずにコードが書けてしまうほど簡単ではなく
00:05:24面白い機能を追加できる余地がありつつ
00:05:29動画が終わるまでに何も完成しないほど 複雑すぎるわけでもないからです
00:05:33作業には音声入力ツールを使います Aqua Voiceのようなツールがおすすめです
00:05:39私はこれを使っていますが 無料やオープンソースの選択肢もたくさんあります
00:05:43Whisper flowやEpicenter Whisperingも素晴らしいツールです なぜ音声入力を使うかというと
00:05:48断言しますが 私は一生かかっても分速226単語でタイピングすることはできないからです
00:05:54このようなツールを使って まずは構築したい内容をすべて一気に吐き出します
00:05:59かなり粗削りな内容になりますが 今からライブでブレインストーミングを行うので
00:06:03私が Claude Code に何を依頼しているかに注目してください これは共有するアイデアと同じくらい重要です
00:06:09後で少し補足説明もします ちなみに これはどんなAIコーディングアシスタントでも可能です
00:06:13よし 行きましょう 「Linktreeのような『リンク・イン・バイオ』ページビルダーを作りたい」
00:06:20「ユーザーはアカウントを作成でき リンクを指定して
00:06:24自分専用のランディングページを作成できる リンクの順序変更も可能にしたい」
00:06:29「アナリティクスでクリック率を確認でき テーマのカスタマイズも可能にしたい」
00:06:33「技術スタックは Next.js データベースは Neon
00:06:37認証も Neon を想定しているので サブエージェントを起動して調査させてほしい」
00:06:43「アーキテクチャには特にこだわりはないので おすすめを提案してほしい」
00:06:48「テーマ管理やリンク構築をどう扱うかについても」
00:06:55「また エージェントを起動して この種のアプリケーションを作成する際のベストプラクティスを
00:07:00ウェブで詳しく調査してほしい そして調査が終わったら」
00:07:04「細かい詳細まで認識を合わせるために 私にたくさんの質問を投げ返してほしい」
00:07:10よし 完璧です これを送信します 数秒で文字起こしされます
00:07:14来ました 準備万端です さて 今やったことで最も重要なのは
00:07:20最後に「調査した後に質問をたくさんしてくれ」と言った部分です
00:07:25ここをしっかりと理解してください コーディングエージェントを使ったプランニングにおける
00:07:32最大の目標は エージェントが抱く『想定』の数を減らすことです
00:07:37エージェントがコードベースでミスを犯す場合 その半分はコードが悪いのではなく
00:07:42何を構築すべきかについて 認識が合っていなかったことが原因だからです
00:07:48よく言われる格言ですが 1行の悪いコードは単なる1行の悪いコードに過ぎません
00:07:54しかし 1行の悪い計画は 100行の悪いコードを生むかもしれません PRDの1行の誤りは
00:08:02認識のズレにより 1,000行の悪いコードにつながる可能性があるのです
00:08:08そのため 私は想定を減らす方法を 長い間試行錯誤してきました
00:08:13そして コーディングエージェントに 怒涛の質問攻めをさせるという方法が
00:08:17驚くほどうまくいきました 特に Claude Code の `ask_user_question` ツールは
00:08:23多肢選択式や自由回答での回答が可能で 非常に強力です 彼らは 私たちが思いつきもしないような
00:08:28エッジケースや細部について実によく考えてくれます 開発者自身が
00:08:33エージェントがどんな勘違いをするかを推測するのは困難ですから これは非常に有効です
00:08:38そして もう一つお気づきかもしれませんが 調査のために
00:08:42さまざまなサブエージェントが動いています プランニングやPRD作成
00:08:48あるいは後述するPIVループの計画段階において 私はサブエージェントを使うのが大好きです
00:08:53Claude Code の場合 探索や調査用のサブエージェントがツールに組み込まれているので
00:08:59自分で作成する必要はありません 他のエージェントを使う場合は
00:09:04自作が必要になることもあるので ここで強調しておきました しかし最近の優れた
00:09:08コーディングエージェントは ほぼすべてサブエージェントの概念をサポートしています 調査には最適です
00:09:14その理由は「コンテキストの分離」にあります ここでの重要なテーマの一つは
00:09:20メインエージェントのコンテキストを厳重に保護することです なぜ調査がサブエージェントに
00:09:26適しているかというと 探索の過程で彼らはあらゆるものに目を通すからです
00:09:32コードベースの探索やウェブ調査を行い 数万から数十万もの
00:09:36トークンを読み込みます しかし メインのコンテキストにとって本当に重要なのは
00:09:41最終的に返される調査結果の要約だけです こうすることで メインのコンテキストをクリーンに保てます
00:09:46実装にサブエージェントを使うことはおすすめしません 実装においては
00:09:51編集・作成したファイルのすべてのコンテキストが重要になるからです そうしないと 私の経験上
00:09:57多くのハルシネーション（もっともらしい嘘）を引き起こします Claude Code に実装用サブエージェントが
00:10:01組み込まれていないのもそのためです あくまで調査用です 今まさに画面で起きている通りですね
00:10:06すべて完了するまで待って 質問が出てきたら戻ってきます よし 調査が完了し
00:10:12最初の質問セットが届きました これから回答していきますが 皆さんも納得されるはずです
00:10:17膨大な事柄を明確にできるからです ここで一つ質問に答えるたびに
00:10:22コーディングエージェントの想定が一つ消えていきます 選択肢が示され
00:10:26大抵はその中に良い案があるので 非常にスピーディーに進められます
00:10:31これにより 詳細がすべて確定した状態で 自信を持って実装に入ることができます
00:10:36例えば 「公開ページのURL構造はどうすべきか？」
00:10:41選択肢1が良いですね 次に行きましょう 「各ユーザーは何ページ作成できるべきか？」
00:10:461ユーザー1ページにしておきましょう デフォルトのまま進めるものも多いですが
00:10:50根本的な誤解が生じている箇所も多々あります
00:10:54そういう時は 自分で回答を入力して明確にします 今ここでその例に当たるかは分かりませんが
00:10:59ひとまずすべての質問に回答してきます すべての質問をお見せする必要はないでしょう
00:11:0320問から25問くらい 徹底的に聞かれることもありますから
00:11:14少し根気が必要ですが 1つの回答が 何百行もの悪いコードを未然に防いでくれるのです
00:11:19おっと ここで提案とは全く違うことを伝えたい良い例が出てきました
00:11:24これはClaudeからの第2弾の質問ですね 「リンクエディタに」
00:11:30「ライブでのスマホ画面プレビューは必要か？」 Lovableやbolt.newのように
00:11:35作成中の画面を見ながら 左側にビルダーがある形式か
00:11:39あるいはインライン形式か という質問です 両方のオプションが欲しいですね
00:11:44チャットでこれについて話しましょう 他の質問は後回しにして
00:11:49この点について少し掘り下げます 「インラインエディタが基本だけど
00:11:53プレビューも見られるようにしたい エディタのみ 両方表示」
00:11:58「プレビューのみ の3つのボタンで切り替えられるようにしてほしい」
00:12:03これを送信すると また続きの質問が来るので 進めていきます
00:12:08さて Claudeからの大量の質問が終わりました 必要以上の量だったかもしれませんが
00:12:13好みに合わせて調整できます 最後に仕様の要約が出てきましたが
00:12:18何を作るべきか 非常に明確に理解してくれています いよいよPRDの作成です
00:12:28デプロイ先まで把握しています 構築後はVercelにデプロイする予定です
00:12:31素晴らしいですね もう『想定』に頼っている部分はなさそうです
00:12:36では PRD作成コマンドを実行します ファイルは `.claud/prd.md` に書き出します
00:12:43場所や名前は自由です 先ほど言及したコマンドを使います
00:12:474つの黄金律に立ち返ると そのうちの大きな一つが
00:12:53「すべてをコマンド化する」ことです 2回以上行う作業があれば
00:12:59私はすでに何度もプロジェクトを立ち上げていますが コマンド化すべきです
00:13:03「スキル」とも呼ばれますね Claude Codeでは最近 コマンドとスキルが統合されましたが
00:13:10私は今でも使い分けています コマンドは `/commit` のように自分で呼び出すもの
00:13:15スキルは エージェントが新しいことのやり方を理解するために コンテキストを読み込む判断をすることです
00:13:20今回はコマンドを作成します 会話のこの段階で
00:13:27構造化されたPRDを出力したいからです このコマンドの中で 正確な構造や
00:13:32PRDに含めるべきセクションをすべて指定しています これにより プロセス全体に再現性を持たせています
00:13:38このシステムの重要な点は 自分に合った仕組みを作り
00:13:42新しい機能やコードベースで 何度でも繰り返せるようにすることです
00:13:48では `/create_prd` を実行します PRDが完成するまで待ちましょう
00:13:53よし PRDが完成しました かなり網羅的ですが これで良いのです
00:14:00これをそのままエージェントに丸投げして実装させるわけではないからです
00:14:04PRDに記載されたフェーズごとに 段階的に構築していきます 今ここで
00:14:09細かく中身を検証するのは時間の無駄ですが 重要なのは
00:14:14内容を読み込み すべてにおいて認識が合っているか確認することです
00:14:18そうしないと 将来的に質の低いコードを量産することになります
00:14:22まず MVPの範囲を確認しましょう 先ほどの質問の答えが
00:14:29PRDに反映されています 非常に重要ですね さっきの会話は
00:14:34PRDを作成するための非構造的なコンテキストに過ぎませんでした 残るのはこのPRDだけです
00:14:40エージェントとの会話内容が すべてここに集約されている必要があります
00:14:44「スコープ外」の項目も 同様に重要です 現時点で何を作らないかを明確にします
00:14:49ディレクトリ構造も含まれています すでにコードベースの全体像を把握しています
00:14:53技術スタックとアーキテクチャが確定しているからです そして
00:14:58最も重要なのが「作業フェーズ」です 後ほど説明する
00:15:04メインコマンドを使う際に 「コードベースに何が実装済みで」
00:15:09「PRDに基づいて次に何を作るべきか」を確立できます MVPを構築していく上で
00:15:13すべての会話の起点となる 重要なコンテキストの一つになります
00:15:19フェーズ分けのセクションがこちらです 各項目は
00:15:24PIVループによる細かな実装単位になります 基礎構築 リンク管理
00:15:29テーマ設定といった具合に これらを個別に計画していきます
00:15:33エージェントに一度に多くのことをさせすぎないためです さて PRDができました
00:15:38これが最大の難関でした 最初の実装まであと少しです
00:15:43次に設定すべきは「ルール」です 最初は基本的な内容になります
00:15:48ルールは コードベースの進化に合わせて 最も頻繁に更新していくものだからです
00:15:53Claude Codeを使っているので `.agents` や `agents.md` を参照しています
00:15:58これはグローバルルールの命名における 普遍的なスタンダードになりつつあります
00:16:04重要なのは コーディングエージェントに常に守らせたい
00:16:10制約や規約を このグローバルルールファイルに記述することです
00:16:16アプリの実行コマンド テスト戦略 ログ出力の指針などです
00:16:20何を作るにせよ エージェントが常に目にする必要があります まずは開始するための初期バージョンを作成します
00:16:25もう一つの構成要素は `reference` フォルダです Claude Codeのスキルでも代用可能ですが
00:16:30こちらの方が汎用性が高いです 特定の箇所を触る時だけ
00:16:35エージェントに意識させたいコンテキストがある場合に使います
00:16:40フロントエンド作業中なら フロントエンドコンポーネントの構築ガイドなどです
00:16:44これらをすべて `agents.md` に詰め込まない理由は これがすべての会話において
00:16:49コンテキストに読み込まれるからです コンテキストは貴重であることを忘れないでください 簡潔に保ち
00:16:55各ファイルへのポインタ（参照）のみを置きます 「フロントエンドを触るなら このファイルを読んで」
00:17:00「新しいAPIエンドポイントを作るなら このファイルを」と指示します 段階的な情報開示です
00:17:04これは本質的に「段階的開示」です。コンテキストに複数の階層を持たせることで、
00:17:09AIエージェントが現在のタスクに基づいて、必要なものだけを徐々に読み込めるようにします。
00:17:14これについても、別のコマンドを用意しています。PRDのテンプレートと同様に、すべてをコマンド化するのです。
00:17:20グローバル・ルール作成用のお気に入りのテンプレートもあります。まず、
00:17:25既存のコードベースに何があるかを確認しましょう。既存のものにも新規のものにも対応できるように作ってあります。
00:17:30ここで探索するのは、主にPRDです。PRDから技術スタックや
00:17:35アーキテクチャを把握し、テストやロギング戦略についてウェブ検索を行い、
00:17:38それらすべてを私のガイダンスと統合して、グローバル・ルールを作成します。具体的な構造も決めてあります。
00:17:43この自作テンプレートに基づいて作成されます。これもすぐにお見せしましょう。
00:17:50これは私がすべてのグローバル・ルールで愛用しているテンプレートです。ご覧の通り、
00:17:55ここにある項目は、どんなプロジェクトでもエージェントに把握しておいてほしいことばかりです。
00:17:59技術スタック、実行・テスト用コマンド、プロジェクト構造などです。つまり、
00:18:04コードベースのインデックス、アーキテクチャ、コードパターン（命名規則など）、テストや
00:18:08バリデーション戦略が含まれます。全体としては非常に基本的ですが、まずはこれを作成します。
00:18:13その後に、オンデマンドで読み込む「リファレンス・ドキュメント」の例をいくつか紹介します。
00:18:17それではClaudeに戻り、PRDを作成したのと同じ会話内で、
00:18:22「create rules」を実行します。これまでの会話のすべてをコンテキストとして利用できるからです。
00:18:27エージェントは即座にPRDや技術スタックなどを把握します。さて、
00:18:33「create rules」コマンドが完了し、グローバル・ルールができあがりました。中身を見てみましょう。
00:18:38非常に標準的です。技術スタックには、例えばデータベースにDrizzle ORMを使用していること、
00:18:43プロジェクト構造、アーキテクチャ、コードパターンなどが記載されています。簡潔にするために、
00:18:47ここでは細かいカスタマイズや私個人の考えを深く反映させてはいませんが、
00:18:52皆さんの技術レベルに合わせて、制約や規約、パターンを
00:18:57理想のコードベースの形に合わせるための重要なステップです。ここにはいくら時間をかけても構いません。
00:19:03今回は、皆さんにハイレベルなコンセプトを伝えることに集中するため、省略しています。
00:19:07また、フロントエンドコンポーネントやAPIエンドポイント作成のベストプラクティスについて、
00:19:12ウェブ検索も行わせました。その結果に基づいて、
00:19:16オンデマンドのコンテキストも作成させました。これらはClaudeの「code skills」にしてもいいでしょう。
00:19:21グローバル・ルールに戻って、「オンデマンド・コンテキスト」のセクションまでスクロールすると、
00:19:24「フロントエンド作業時はこのファイルを読め」「APIルート作業時はこのファイルを読め」とあります。
00:19:29最初に読み込まれるのは「claud.md」のみで、必要に応じて他のファイルを読み込むか判断させます。
00:19:34私の経験上、グローバル・ルールが簡潔であれば、エージェントは適切にこれらを参照してくれます。
00:19:40このグローバル・ルールは240行もありません。233行です。一方で、
00:19:45api.mdやcomponents.mdはもっと容量が大きいです。特定のタスクに特化している場合は、
00:19:50エージェントが正確な指針を得られるよう、より多くの情報を読み込ませても問題ありません。
00:19:58改めて図解に戻ると、「ルール」は「どう作るか」であり、
00:20:03「PRD」は「具体的に何を何を作るか」です。これらを踏まえた上で、
00:20:08最後に「コマンド」、特に「prime」コマンドについてお話しします。
00:20:14その後、第1フェーズの計画立案とコーディングに入ります。現時点で、
00:20:19AIの土台は整いました。PRD、ルール、そして私が提供した汎用コマンドが揃っています。
00:20:23いよいよ実装に進みますが、ここで重要なことがあります。
00:20:29AIコーディング・アシスタントとの新しい会話を始めるたびに、
00:20:34現在のコードベースの状況や、次に何を作るべきかを把握させる必要があります。
00:20:39そこで「prime」コマンドの出番です。これはコマンドとして実行します。
00:20:44新しいセッションの開始時に「/prime」を実行します。これはエージェントがコードベースを探索し、
00:20:50次の機能実装に向けてメンタルモデルを構築するための、ガイド付きプロセスです。
00:20:56ドキュメントを読み、構造を探索させます。サブエージェントを使ってこれを行うことも可能です。
00:21:02また、gitログの確認も行います。後ほど詳しく説明しますが、
00:21:06gitログを「長期記憶」として利用します。コードベースがどのように進化してきたかを追うことで、
00:21:11次に何を構築すべきかの意思決定に役立てるのです。このコマンドを実行すると、
00:21:15エージェントはコードベースに対する理解を出力します。これにより、
00:21:21エージェントが正しく現状を把握しているかを確認し、次の構築ステップへ進めます。
00:21:26primeコマンドの詳細は割愛しますが、gitの履歴を活用するための操作を行い、
00:21:31アプリケーションの主要なエントリーポイントなど、特に注意を払うべき
00:21:36コアファイルを読み込ませます。そして出力されるレポートで、エージェントの理解度を検証します。
00:21:40これはプロジェクトに合わせて進化させていくことができます。小さな例を挙げると、
00:21:45コアなドキュメントの読み込みに関して、「Drizzleのマイグレーションファイルを読み、
00:21:49データベーススキーマを理解せよ」といった指示を追加できます。タブ補完でも出てきましたね、意図通りです。
00:21:55このように、エージェントに注視させたい核心的な部分（例えば
00:22:01リファレンス・フォルダ内の特定のドキュメントなど）を、ここに追加していくことができます。
00:22:08では、Claudeで全く新しい会話を始めましょう。ここから最初のPIVループに入ります。
00:22:12PIVループの全体像は後ほど説明しますが、まずはこれを見てください。ただ「Prime」と入力します。
00:22:16これが、何かを探索する前の、会話の始まりになります。するとエージェントは、
00:22:20「これは新規プロジェクトだな、PRDを確認しよう」と判断し、
00:22:25「まずは第1フェーズ、プロジェクトの土台作りから始めましょう」と提案してきます。
00:22:30Primeが完了しました。プロジェクトの概要は「リンク・イン・バイオ（プロフィール）作成ツール」です。
00:22:34現在の状態は、ドキュメントのみの空のレポジトリです。以前テストビルドをしたので、
00:22:39そう表示されていますが、今はすべてクリアしてあります。そしてPRDから第1フェーズの
00:22:44「土台（Foundation）」を抽出しました。これがエージェントの推奨する構築内容です。
00:22:49まさに私の意図通りです。PRDからフェーズを一つずつピックアップさせ、
00:22:54PIVループで細かく実装していきたいのです。その「PIVループ」について説明しましょう。
00:22:59PIVとは、Plan（計画）、Implement（実装）、Validate（検証）の略です。
00:23:04PRDの1フェーズのような、焦点を絞った作業単位をこのプロセスに通します。まず、
00:23:10取り組む内容について構造化された計画を立てます。このプロセス自体は、
00:23:14PRDの作成と非常によく似ています。次に実装に移りますが、
00:23:20ここでの目標は、コーディングのすべてをエージェントに委ねることです。そして最後に検証を行います。
00:23:29このプロセスの流れを簡単に説明してから、実際に動かしてみましょう。
00:23:34まず「計画（Planning）」には2つの階層があります。一つはトップレベルのプロジェクト計画で、
00:23:38これはPRDとルールの作成ですでに完了しています。もう一つは、タスク固有の計画です。
00:23:44先ほど言ったように、構造化された計画を作る作業は、
00:23:50構造化されたPRDを作るのと似ていますが、大きな違いは、この計画が
00:23:55個別の機能や、それに付随するすべてのタスクに特化しているという点です。
00:24:00ここからコードに深く踏み込んでいきます。ハイレベルな視点は維持しつつも、まずは
00:24:07あえて「構造化されていない」会話から始めます。私はこれを「バイブス・プランニング」と呼んでいますが、
00:24:13一般的なアイデアを探ります。具体的に何を構築するのか、アーキテクチャはどうするか、
00:24:19サブエージェントを動かしてコードベース分析やドキュメント調査を行い、
00:24:24この機能のために完了させるべき具体的なタスクを特定します。
00:24:30そうした会話を経て、PRDの時と同じように、それを構造化されたドキュメントに変換します。
00:24:35ここでの目標は、会話に基づいた、AIエージェントのための詳細な「攻撃計画」を作成することです。
00:24:40会話の内容もコンテキストの一部ですが、構造化された計画には特定のセクションを設けます。
00:24:44機能の目標と成功基準、サブエージェントが見つけてきた参照ドキュメント、
00:24:50そしてタスクリストです。これは作成・更新すべき個別のファイルレベルまで具体化します。
00:24:56そして、おそらくこの計画全体で最も重要なのが「検証戦略（Validation Strategy）」です。
00:25:02これはテスト駆動開発に似ており、1行もコードを書く前に、
00:25:09その機能をどう検証するかを極めて具体的に定義します。これにより、
00:25:13私たちとエージェントの両方が、成功基準を明確に意識せざるを得なくなります。
00:25:18こうして構造化された計画を私たちが主導して作り、コーディング作業だけを
00:25:23エージェントに委託します。ただし、これは単なる「バイブス・コーディング」ではありません。
00:25:27エージェントを信頼しつつも検証できる理由は、実装プロセスの前後に、
00:25:33自分が深く関与する「計画」と「検証」のステップを挟んでいる（サンドイッチしている）からです。
00:25:38ユニットテスト、統合テスト、E2Eテストを通じて、エージェント自身に自分の仕事をチェックさせます。
00:25:45その上で、私自身もコードレビューを行い、アプリケーションを実機でテストします。
00:25:51自分でアプリを動かし、ユーザーとして使い勝手を確認し、すべてが正常であることを
00:25:56確認してからコミットし、本番やステージング環境へ送ります。ここで重要なのは、
00:26:01「計画」と「実装」の間でコンテキストをリセットすることです。これは黄金律の一つです。
00:26:06「コンテキストは貴重である」ということです。機能の実装方法を検討する過程で、
00:26:11長く詳細な会話が交わされますが、その後に作成する「構造化された計画」こそが、
00:26:16コーディングエージェントが仕事を完遂するために必要なコンテキストのすべてであるべきです。
00:26:20そうすることで、計画のみを渡した「まっさらな会話」から始められます。
00:26:26計画には参照すべき全ドキュメントと詳細なタスクリストが含まれているので、
00:26:32何をすべきか、どう検証すべきかが明確です。余計な情報を遮断し、
00:26:38実行に集中できる環境を作るのです。実際にコードを書く段階で、
00:26:44会話がコンテキストで肥大化するのを防ぎたいわけです。さて、
00:26:50それでは最初のPIVループに入りましょう。事前の綿密な計画のおかげで、
00:26:55驚くほどシンプルに進むはずです。私たちはエージェントと同じ認識を共有しており、
00:27:00構築内容をエージェントが理解しているという確信があります。そのため、
00:27:06少なくとも最初のうちは、各フェーズの計画立案にそれほど時間はかかりません。
00:27:12さて、Primeが完了し、エージェントと意思疎通ができています。
00:27:16「第1フェーズでいいよ、構築内容を確定させてくれ」というシンプルな指示を出しました。
00:27:22通常、2回目以降のPIVループはより詳細になります。「コードベースを確認して、実装方法を詰めよう」となりますが、
00:27:27今回は最初なのでシンプルです。よし、ここで「すべてをコマンド化」しましょう。
00:27:31この会話と第1フェーズのアイデアを、タスクリストと検証項目を備えた
00:27:36構造化された計画に変換します。そのためのコマンドが「/plan feature」です。
00:27:40これを実行します。「plan feature」は、PRD作成と同様に、
00:27:44構造化された計画を作るという概念が組み込まれています。このコマンドも見てみましょう。
00:27:49「plan feature」を開きます。構築内容を指定するオプション引数がありますが、
00:27:53今回は会話履歴を使います。エージェントはすでに状況を把握していますが、段階的なプロセスを踏みます。
00:27:59機能の理解、コードベースへのダイブ（これは今後のループでより重要になります）、
00:28:04多くのリサーチ、関連ドキュメントの抽出などを行い、実行前に豊かなコンテキストを確保します。
00:28:10そして、これがテンプレートです。「問題定義」「コンテキストやリファレンス」を記述し、
00:28:17タスクリストを含む「実装計画」を作成します。そしてもちろん、
00:28:23「テスト戦略」もあります。バリデーションを事前に定義するのです。計画作成後は、
00:28:28当然それを検証します。ステップバイステップで、アプリをどう検証すべきか非常に具体的に指定します。
00:28:33ここではVercel Agentの「Browser CLI skill」を使用しています。これについては別途動画を出しています。
00:28:38フルブラウザ自動化を組み込みます。エージェントが自らバックエンドとフロントエンドを立ち上げ、
00:28:44DBマイグレーションを実行し、実際にリンクツリーを構築して、ユーザーが使うのと
00:28:49全く同じように動作確認を行います。非常にエキサイティングですね。
00:28:55検証プロセスを詳細に設定しておくことで、制御が自分に戻ってきたとき、
00:29:00実装の正確さに高い自信を持てます。自分で検証する手間も大幅に減ります。
00:29:05計画が作成されました。中身を確認しましょう。
00:29:11カメラの外で少し検証を済ませました。後ほどお見せします。通常は、
00:29:17第1フェーズの理解がPRDや自分の作りたいものと一致しているか確認するために、何度か反復（イテレーション）が必要です。
00:29:21各セクションをしっかり確認してください。これがタスクリストを含む実装計画です。
00:29:26一つの機能に集中しているので、非常に詳細ですね。良い傾向です。そして、
00:29:31私が「バリデーション・ピラミッド」と呼んでいる検証プランもあります。型チェック、リンター、ユニットテスト、
00:29:36そしてE2Eテストとして、エージェントに実行させたいユーザー動線を具体的に指定しています。
00:29:42これにより、戻ってきた実装に自信を持てます。最初はエージェントもうまくできませんでしたが、
00:29:47実装に回す前に計画を練り直し、洗練させるための追記プロンプトの例をここでお見せします。
00:29:52もう一つ、実装に入る前に大事な「秘訣」をお伝えします。
00:29:56一般的に、コーディングエージェントは環境変数の扱いがあまり得意ではありません。混乱しがちです。
00:30:01実装前に環境変数が設定されていないと、モックテストでお茶を濁して「検証完了」と言い出すことがあり、
00:30:05非常にストレスが溜まります。そこで、計画立案と並行して、
00:30:10「.env.example」を作成し、エージェントに見せておきます。これで必要な変数がエージェントに伝わります。
00:30:15その上で、自分でも環境変数をセットアップします。もちろん、
00:30:20データベースURLなどの機密情報が含まれるので、このファイルの中身はお見せしませんが、
00:30:24セットアップが済んでいれば、実装をノンストップで駆け抜けることができます。コードを書くだけでなく、
00:30:29DBマイグレーションの実行、サーバーの起動、Browser CLIによるテストまで、
00:30:34環境変数の設定で手を止めることなく、一気に完遂してくれます。
00:30:38舞台は整いました。計画にも満足しています。では「コンテキスト・リセット」です。
00:30:43新しいコンテキストウィンドウを開き、「/execute」コマンドを使い、
00:30:48唯一のパラメータとして「計画ファイル」を指定します。今のエージェントに必要なのはこれだけです。
00:30:53ここから一旦停止して、すべて完了したら戻ってきます。
00:30:57コーディングをすべてエージェントに任せ、これまでの計画の努力が報われる瞬間です。
00:31:03事前の準備があるからこそ、ここからのPIVループはどれも非常にスピーディーに進みます。
00:31:09さて、実装が完了しました。スクリーンショットから、フルE2Eテストが行われたことがわかります。
00:31:13エージェントがすでにすべてを処理してくれたので、かなり安心できますが、
00:31:19「信頼しつつも検証する」の精神で、人間による確認も欠かせません。
00:31:23コードレビューはかなり細かい話になるので、ここでは行いませんが、
00:31:29技術に詳しい方なら、必ず自分で行うべきステップです。代わりに、
00:31:34今ここで、アプリケーションのライブテストを一緒に行いましょう。
00:31:40カメラの外で行ったのは、認証が機能するか確認するためにアカウントを作成したことだけです。
00:31:45それ以外は何もしていません。見てください、これ。
00:31:51すごいですね。すでに見た目がかなり整っています。表示名を設定して、バイオには
00:31:56「イケてるAIビルダー」と。よし。アバターのURLも設定できます。Imgurに画像を上げたので、
00:32:01うん、いい感じです。リンクも追加しましょう。まずはYouTube。
00:32:06URLを入力して……よし。もう一つ追加、LinkedInを。
00:32:11自分のURLを覚えていないので、とりあえず適当に入れておきます。
00:32:16さらに、Xも追加しましょう。非常にスムーズです。
00:32:21ドラッグして順番を入れ替えることもでき、即座に反映されます。エディターのみの表示や、
00:32:26プレビューの調整も可能です。テーマはまだ真っ白で最高とは言えませんが、
00:32:30これは後のフェーズで構築する予定のものです。今は土台を作っている段階ですから。
00:32:35現時点でも、スタート地点としては極めてクオリティが高いです。「Save」をクリックします。
00:32:39APIエンドポイントを読み込んで……はい、「保存成功」です。
00:32:43リフレッシュしても、データはすべて保持されています。素晴らしいですね。
00:32:49完璧な土台ができました。次に話しておきたいのは、
00:32:55コミットメッセージについて、手短に。
00:32:59「/commit」という、非常に基本的なコマンドを作ってあります。もっと詳細にしてもいいですが、
00:33:08肝心なのは、エージェントにgitメッセージの作成ルールを指示しておくことです。
00:33:11これが将来の「長期記憶」になるからです。図解に戻りましょう。
00:33:18これも黄金律の一つ。「コミット履歴は長期記憶である」ということです。
00:33:24メッセージを標準化するために「/commit」コマンドで再利用可能にしておけば、
00:33:28エージェントが「prime」を実行する際に、gitログを見て最近何を作ったかの履歴を確認でき、
00:33:32それが次の方針や、従うべきコードパターンのガイドになります。これがこのメッセージの力です。
00:33:37「/commit」を実行します。自分で「git commit」を打つのも簡単ですが、
00:33:42コマンドにすることで一貫性が保たれます。今回はすでにカメラの外で実行したので、
00:33:46コミットするものはありませんが、各実装の後にこれを行うことが重要です。
00:33:51さて、プロジェクトの土台が整ったところで、もう一つ極めて重要なことがあります。
00:33:57それは、回帰テスト（リグレッションテスト）のフレームワークを構築することです。
00:34:01Ceci peut être plus détaillé si vous le souhaitez, mais l'essentiel est de fournir des instructions à l'agent sur
00:34:06la manière de créer un message GET, car nous allons l'utiliser comme mémoire à long terme. Pour en revenir
00:34:11図に戻りましょう。これは黄金律の1つです。コミット履歴は長期記憶となります。
00:34:17メッセージを標準化するために「/commit」コマンドを使用し、再利用性を高めています。
00:34:22そうすることで、エージェントがGitログを確認し、最近何を構築したかの履歴を把握できます。
00:34:28それが次に行うべきことや、従うべきパターンのガイドになります。これがコミットメッセージの力です。
00:34:32では「/commit」を実行します。自分で「git commit」を打つこともできますが、
00:34:38これを使えば一貫性のあるメッセージを常に生成できます。
00:34:43今回は、カメラの外ですでに実行済みなのでコミットするものはありませんが、
00:34:48実装が終わるたびに行うことが非常に重要です。
00:34:53プロジェクトの土台が整った後で、もう1つカバーすべき非常に重要なことがあります。
00:34:58それは回帰テスト（リグレッションテスト）のフレームワークを構築することです。
00:35:04今後、PIVループを何度も回して機能を追加していく際、
00:35:09既存の機能が壊れていないかを確認する必要があります。
00:35:14このテストハーネスの実装戦略については、また別の動画で詳しく説明する予定です。
00:35:19基本的には、エージェントに「今の状態は素晴らしい」と伝えた上で、
00:35:25Aqua Voiceなどに向かって「実行したすべてのE2Eテストをリストアップして、
00:35:31コマンドにまとめてくれ」と依頼します。そうすれば、後で他の機能を構築した際に、
00:35:36以前構築したものがすべて正常に動作しているか確認できますよね。
00:35:41今はあまり深入りしません。テストハーネスの構築と設定には時間がかかりますが、
00:35:46これが、開発を続けながらアプリケーションの安定性を保つための方法です。
00:35:50ただ、これを作成し維持するには、常に更新が必要なため多大な労力がかかります。
00:35:55そこで、これを代行してくれる非常に強力なソリューションが存在します。
00:36:00その1つが「QA tech」です。彼らはコードベースに合わせて進化・適応するAIテストエージェントを提供しています。
00:36:05機能を追加するたびに、テストケースも自動で追加され、
00:36:11開発中もアプリケーションが正常に動作し続けることを保証してくれます。
00:36:16その例を簡単にお見せしましょう。使い始めるのはとても簡単です。
00:36:22QA techにアクセスします。無料プランがあるので、まずは試してみてください。
00:36:26プロジェクトを作成し、テストしたいURLを貼り付けるだけです。
00:36:30このアプリをGitHubにプッシュしてあるので、
00:36:35Vercelに1分ほどでデプロイしました。Next.jsで構築したサイトを無料でホストするのに最適です。
00:36:40プロジェクトからこのURLをコピーして貼り付けます。
00:36:45プロジェクトが作成され、コードベースが分析されるまで少し時間がかかります。
00:36:50「サイトのテストをセットアップして、最初の3〜5個のテストケースを作成して」と伝えます。
00:36:55これは「bolt.new」や「Lovable」のように、プロンプトを与えるだけで、
00:36:59プロジェクトのテストスイートを構築してくれます。推奨される手順で進めてみましょう。
00:37:04実行します。インフラを管理する必要は一切ありません。
00:37:08AIが実際にウェブサイトをクロール（巡回）して分析し、テストケースを生成します。
00:37:12結果が出るまで少し待ちましょう。実行中の様子を少しお見せします。
00:37:16数分でサイトのクロールが終わりました。次に重要なのは、
00:37:21オートメーションがサイトにログインする方法を確保することです。
00:37:25ユーザー名とパスワードを入力する場所があり、安全な方法で保存されます。
00:37:29作成しておいたテストアカウントを入力して保存します。
00:37:34AIはこの情報を使ってログインし、テストしたいユーザー体験を深く理解します。
00:37:38ご覧の通り、多くのテストケースが生成されました。
00:37:43各ケースをクリックして、AIがたどった正確なフローを確認することもできます。
00:37:48これでテストのセットアップが完了しました。QA techのAIテストエージェントは、
00:37:53コードベース全体を常にカバーできるよう、時間とともにテストケースを進化させてくれます。
00:37:59機能が増えるほど、その真価を発揮します。本当に素晴らしいです。
00:38:04もちろん、自分たちでコマンドシステムを構築して同じようなことを行うことも可能ですが、
00:38:09こうしたプラットフォームにすべてを任せられるのは非常に助かります。
00:38:14内部のエージェントと対話してテスト内容を調整し、回帰テストが完璧か確認することもできます。
00:38:19何かが壊れたときには、「アプリにバグがあるから、失敗するはずのテストを作成して」と指示し、
00:38:24問題を解決してから、テストがパスすることを確認すればいいのです。
00:38:28これが最後の黄金律である「システム進化のマインドセット」に繋がります。
00:38:33コードベースでバグに遭遇したとき、ただバグを直すだけでは不十分です。
00:38:40再発を防ぐために「AIレイヤー」で何を修正できるかを考えることが重要です。
00:38:46スタイルガイドやルールを具体化したり、新しいオンデマンド・コンテキストを作成したりする必要があります。
00:38:51コマンドやワークフローにE2Eテストを追加して、
00:38:57二度と同じ問題が起きないようにします。
00:39:02QA techや自作のシステムでテストを追加し、二度とバグが発生しないようにします。
00:39:06これには時間がかかりますが、コーディング・エージェントの信頼性と再現性が高まり、
00:39:12コードベースとともにエージェントも進化していきます。
00:39:16私たちは3つのことを並行して行っているのです。コードベースの構築と同時に、
00:39:21テストベース、コードベース、そしてAIレイヤーを進化させています。この効果は時間とともに増大します。
00:39:26Cloud Codeでの簡単な例をお見せしましょう。
00:39:32カメラの外で一度繰り返した作業の1つに、サイトのスタイルの調整があります。
00:39:37動画の冒頭で、私が具体的なスタイルについて話し忘れていたことに気づくでしょう。
00:39:43そのため、エージェントが独自の判断で実装してしまい、あまり見栄えが良くありませんでした。
00:39:47そこで繰り返し調整が必要になったのですが、ここでできることは、
00:39:51「フロントエンドのスタイルが気に入らない。ルールやコンテキストに
00:39:56スタイルガイドが不足しているようだ。メタ推論を行ってほしい」と伝えることです。
00:40:01「今は何も変更しなくていいが、今後のページ作成で一貫したスタイルを保つために、
00:40:06ルールやオンデマンド・コンテキストに何を追加・更新すべきか考えてみてくれ」と頼みます。
00:40:10ここで重要なのは「まだ何も変えないで」と伝えることです。
00:40:15コードの実装はエージェントに任せたいですが、AIレイヤーの変更については、
00:40:20私は自分でしっかりコントロールしたいと考えています。推論はさせますが、
00:40:25変更自体は自分自身で、小さく、焦点を絞って行いたいのです。
00:40:29エージェントは、referenceフォルダに「style.md」を作成することを推奨しています。3つ目のオンデマンド・コンテキストですね。
00:40:34これは「components.md」と一緒に機能するでしょう。あちらは配置の方法、
00:40:39こちらはTailwind CSSやShadcnの使い方などを定義するものです。
00:40:44今は実装のすべてを説明はしませんが、バグが出たり期待とズレたりしたときは、
00:40:50常にAIレイヤーを進化させるチャンスであるという例です。
00:40:54開発を続けるにつれ、このプロジェクト専用のコーディング・エージェントと意思疎通がスムーズになります。
00:40:58これがプロセス全体の中で最もレバレッジが効く部分であり、最高の秘訣です。
00:41:03以上です。新しいプロジェクトを始める際に、コーディング・エージェントから
00:41:06信頼性が高く再現性のある結果を得るための、至ってシンプルなプロセスです。
00:41:11システムの進化が終われば、また最初に戻ってPIVループを回し、
00:41:16PRDの各フェーズを構築し、MVP（実用最小限の製品）が完成するまで機能を追加していきます。
00:41:20その後、次回の動画で公開予定の「ブラウンフィールド開発（既存プロジェクトの開発）」へと進みます。
00:41:26もしこの内容が気に入り、私のコマンドやルールのリソースライブラリをさらに深く学びたい、
00:41:32システムの進化の真髄を見たいという方は、ぜひ
00:41:35Dynamicsコミュニティにある「エージェンティック・コーディング・コース」をチェックしてみてください。
00:41:40概要欄と固定コメントにリンクを貼っておきます。
00:41:45私がお伝えしたかったことは以上です。この動画が参考になった、
00:41:49あるいはブラウンフィールド開発の動画も楽しみだという方は、
00:41:54ぜひ「高評価」と「チャンネル登録」をお願いします。
00:41:59それでは、次の動画でお会いしましょう。
00:42:04ご視聴ありがとうございました。
00:42:08また次回。
00:42:13さようなら。
00:42:17（音楽終了）
00:42:22（画面暗転）