Claude Codeを使う前に必ず設定すべきこと

AAI LABS
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00実を言うと、AIがソフトウェア開発プロセスに革命を起こすことはありません。少なくとも皆さんが思っているような形では。
00:00:05確かにすべてが速くなりますし、問題が起きた時の復旧も容易になります。
00:00:10しかし、60年以上の製品作りの歴史の中で確立されてきたプロセスは、今日でも依然として重要です。ただ、その理由が異なるだけです。
00:00:16以前は、人間が製品を開発するための体系的な方法を確保するために導入されていました。
00:00:21しかし現在では、AIエージェントが人間と同じように動けるようにすることへとシフトしています。
00:00:25AIエージェントを適切に機能させるには、彼らが実際にプロセスに従うよう、環境を正しく設定する必要があります。
00:00:32そこで今回は、構築を始める前に踏むべきすべてのステップを見ていきましょう。
00:00:36プロンプトを一行書く前に、要件を適切に計画することが最も重要なことです。
00:00:41これは、モデルがどれほど優れていても、時間を費やす必要がある部分です。
00:00:45さて、計画には複数の方法があります。
00:00:46Claude Codeのプランニングモードを使ってアプリを計画できますが、その計画は製品重視ではなく、非常に技術重視です。
00:00:52前回の動画でも触れたように、エージェントの進化に伴い、
00:00:56プランニングモードはそれほど詳細や技術的である必要はなく、代わりに製品の側面に重点を置くべきです。
00:01:01なぜなら、新しいモデルは強力であり、初期のモデルほど能力が低かった頃とは計画のあり方を変えなければならないからです。
00:01:07そのため、Claudeのプランニングモードの代わりに、アプリの計画を支援する別のエージェントを作成することができます。
00:01:11そこには、適切なPRD(製品要件定義書)を作成するための指示と、要件を正確にClaudeに導くためのテンプレートが含まれています。
00:01:18エージェントの設定ができたら、Claudeにプロンプトを与えて、構築したいアプリの計画を立てさせます。
00:01:23実際にプランナーエージェントを読み込み、すべての要件を理解するまで質問を続けます。
00:01:28あなたが計画に満足するまで、質問を繰り返します。
00:01:32MVP(実用最小限の製品)を理解するために、エージェントは多くの質問をするように設計されています。
00:01:36そして最後に、アプリに他に何か必要なものはないか尋ねます。
00:01:40もしあれば、エージェントに実装してほしいものを追加できます。
00:01:43すべての質問に納得し、エージェントが計画を理解したと思えば、「以上です」と伝えるだけです。
00:01:49質疑応答セッションの後、PRDドキュメントが作成され、プロジェクトフォルダに保存されます。
00:01:54このドキュメントには、話し合ったすべての要件の詳細が含まれています。
00:01:57実装はフェーズごとに分割され、主要な設計決定やアプリに必要なすべてが含まれています。
00:02:04アプリの内容が固まったら、次のステップは Claude.md ファイルを適切に定義することです。
00:02:10このファイルは、エージェントに従わせたいすべての指示が含まれているため、非常に重要です。
00:02:15PRDドキュメントをリンクすることで、アプリの要件すべてに直接アクセスでき、ここで繰り返す必要がなくなります。
00:02:21このファイルには、エージェントがすでに知っていることではなく、知らないことだけを記述すべきです。
00:02:27プロジェクトで守るべきルールを参照させます。
00:02:30プロジェクトの規約や、アプリの実装中にClaudeに特に守らせたい指示を追加できます。
00:02:37理想的なアプローチは、initコマンドから Claude.md を作成するのではなく、自分で作成することです。
00:02:43なぜなら、このコマンドは既存のコードベースに基づいたファイルを生成するだけで、実際に知るべきことに基づいていないからです。
00:02:49しかし、このファイルは一度書いて終わり、というものではありません。
00:02:53作業を進めながら、アプリ構築のプロセスを段階的に改善できるよう、項目を追加し続ける必要があります。
00:02:58前回の動画でお話しした通り、このファイルは一度読み込まれるとコンテキストに残り続け、作業中のガイドラインとして機能します。
00:03:05ですから、このファイルに不要なものや、特定の領域に限定された詳細を含めないように注意してください。
00:03:12このファイルに追加すべきは、プロジェクトのベストプラクティス、コーディング規約、執筆スタイルや規約などです。
00:03:19しかし、プロジェクトの構造など、エージェントが自分で判断できることは含めません。
00:03:24それについては、エージェントがファイル構造を読み取って自分で理解できるからです。
00:03:28ですから、実際に実装を始める前に、時間をかけてこのファイルを自分のニーズやプロジェクトに合わせて適切に作成してください。
00:03:36次に設定するのは、スキル、エージェント、そしてプロジェクトで使用したいMCP(Model Context Protocol)です。これらも構築前に行います。
00:03:42MCPの接続は簡単です。
00:03:44エージェントにアクセスさせたい外部サービスを接続し、インストールコマンドを実行してインストールするだけです。
00:03:50例えば、バックエンドをSupabaseで構築したかったので、プロジェクト内のエージェントにSupabase MCPを接続しました。
00:03:57UIコンポーネントに shadcn/ui を、ブラウザテストに Playwright を使用する場合、
00:04:01構築前にこれらすべてを接続しておき、エージェントが構築中にこれらのツールにアクセスできるようにする必要があります。
00:04:07これらは外部サービスへの接続でしたが、エージェントの設定も必要です。
00:04:12必要に応じて、いくつでもエージェントを設定できます。
00:04:14すでに計画専用のプランナーエージェントがあります。
00:04:16他にも、コミット、事前チェックの実行、Conventional Commitsに沿ったメッセージ作成を担当するコミットエージェントも作成できます。
00:04:23コードをリファクタリングし、全体的なパフォーマンスを向上させるリファクタリングエージェントも持てます。
00:04:28さらに、Playwright MCPのツールを使用してUIやユーザーフローが意図通りに動作するかを確認し、その方法についての全指示を含む検証エージェントも設定できます。
00:04:39エージェント以外に、スキルも設定する必要があります。
00:04:42スキルは必要なだけ作成でき、オープンソースのGitHubリポジトリにある Skill Creator を使って簡単に作成できます。
00:04:49参照をいくつでも追加でき、スクリプトを直接実行してその出力を利用させることもできます。
00:04:55エージェントとスキルの使い分けについては、繰り返し可能でガイドや参照が必要なワークフローを「スキル」として実装してください。
00:05:04例えば、フロントエンドのスキルを作成できます。これは繰り返し発生するワークフローであり、アプリ全体で専用のガイドラインを一貫して守る必要があるからです。
00:05:11専用のコンテキストウィンドウが必要なタスクについては、エージェントを実装してください。
00:05:14Claude Codeの作成者自身も積極的に使用している、オープンソースのフロントエンドスキルを利用することも可能です。
00:05:20また、アプリの特定の側面に対してパス固有のルールを追加する必要もあります。
00:05:23これらのルールは適用されるパスを定義し、その特定の部分を実装するために必要なすべての指示を含みます。
00:05:29これらは好きなだけ設定でき、Claude.md にリンクすることで、エージェントがそれらの指示に従うべきだと認識できるようにします。
00:05:36先ほど述べたように、Claude.md は広範な原則のためのものです。そのため、特定の実装に必要なことをエージェントが把握できるよう、パス固有のルールが必要なのです。
00:05:46このチャンネルでは、AIを使った製品開発に関するこれらの設定などを網羅しています。もっと見たい方は、ぜひチャンネル登録をして今後の動画をチェックしてください。
00:05:54しかし、これらすべての「肯定的な指示」があっても、まだギャップがあります。
00:05:58エージェントは行動を優先する傾向があり、肯定的な制約で指定された以上のことを実装してしまうことがあります。
00:06:03したがって、エージェントに「すべきでないこと」を明示的に伝える必要があります。
00:06:06docsフォルダにこのファイルを作成し、Claude.md にリンクすれば、エージェントに制約の存在を知らせることができます。
00:06:12プロジェクトに合わせて、エージェントに作成してほしくないあらゆる指示を含めるべきです。
00:06:19肯定的な仕様だけでは暗黙の隙間が生じますが、否定的な制約はその隙間を埋め、曖昧さを排除し、エージェントが勝手な試行錯誤をすることを防ぎます。
00:06:29これにより、出力がどのようであってはならないか、より明確な目標が与えられます。
00:06:32例えば、AIがよく使うデフォルトの紫や青と白の組み合わせを避けたいなら、暗黙にするのではなく、それを使わないよう明示的に述べてください。
00:06:41先に進む前に、スポンサーの Way in Video からのお知らせです。
00:06:44長い動画を扱うなら、その大変さはご存知でしょう。良い場面を一つ見つけるために何時間も映像をチェックし、さらに編集に時間を費やすことになります。
00:06:52Way in Video はそれをすべて解決します。これは動画の内容を実際に理解するAI動画プラットフォームです。
00:06:56OpenClawにある彼らのAIクリッピングスキルは、どんな長い動画からでも最もバイラルな瞬間を見つけ出し、自動で垂直方向にリフレームしてキャプションを追加します。
00:07:04コーディングも設定も不要です。スキルを実行するだけで、クリップが投稿可能な状態で完成します。それだけです。
00:07:08特定のものを探したい場合は、普通の英語で動画内を検索できます。「面白いリアクション」や「最高の名言」と入力すれば、その場面にジャンプします。
00:07:16スピーカーラベル付きの動画要約や文字起こしも処理できます。ポッドキャスト、講義、配信に最適です。
00:07:22コンテンツの再利用でもワークフローの自動化でも、Way in Video は毎週何時間もの時間を節約してくれます。
00:07:27手動編集で時間を無駄にするのはやめましょう。固定コメントのリンクから始めてみてください。
00:07:32さて、これはほとんどのAIフレームワークが何らかの形で採用していることですが、異なる目的のために複数のドキュメントを使用します。
00:07:38しかし、それらすべてのドキュメントの核となるのが、進捗(Progress)と学習(Learning)のドキュメントです。
00:07:42大規模なアプリで複数の機能を開発していると、エージェントはどの機能を実装済みで、どれが未着手かを見失うため、進捗ファイルは極めて重要です。
00:07:52このファイルがないと、エージェントは過去の実装を読み直し、ドキュメントと比較して何が終わったかを確認しなければなりません。
00:07:58それはオーバーヘッドを生み、時間とトークンの両方を無駄にします。
00:08:01ですから、エージェントが一箇所を見るだけで状況を正確に把握できる進捗ファイルを作成してください。
00:08:07しかし、進捗を追跡するだけでは不十分です。エージェントは何が間違っていたかを知る必要もあるからです。
00:08:11そのため、エージェントがエラー、その原因、そしてどう修正したかを記録する学習ファイルも必要です。
00:08:17こうすることで、後で似たような状況に遭遇したときに、同じ間違いを二度繰り返さないようになります。
00:08:22これらのファイルは両方とも、エージェントがアプリを実装している間に積極的に更新されるべきものです。
00:08:26そのため、Claude.md でエージェントに対し、構築中にこれらのファイルに追記し続け、知識ベースを向上させるよう明示的に指示する必要があります。
00:08:34これら2つのファイルは、あらゆるセットアップに不可欠な最も重要なものです。
00:08:38ご自身のコーディング環境を構築する際に活用してください。
00:08:41フレームワークを自作する方法についての動画も以前公開していますので、チャンネルでご覧いただけます。
00:08:46もし、自分でセットアップする手間を省きたいのであれば、
00:08:49既存のコーディングフレームワークに頼ることもできます。それらは、まさにこれを行うための様々なメカニズムを備えており、直接導入できます。
00:08:56もう一つのよくある間違いは、開発の最後にだけテストを実装することです。
00:09:00これは問題です。機能が構築された後にテストを書くようにエージェントに頼んでも、
00:09:05事前に書かれた場合ほど、そのテストは効果的ではないからです。
00:09:09テストを書く際、エージェントに作成したPRDを参照させ、それに基づいて機能がどう動作すべきかを推論させるべきです。
00:09:16エージェントは、これらの推論された要件からテストを書く必要があります。
00:09:19つまり、PRDから機能やアプリが失敗しそうな箇所を逆算して設計するのです。
00:09:24テストの準備ができたら、最後にそれを実行して、実装が要件を満たしているかを相互検証できます。
00:09:29先にテストを書く理由は、後から実装すると、エージェントは「実際に実装されたもの」しか知らないからです。
00:09:35エージェントは、仕様で求められた機能ではなく、存在する機能に合わせてテストを最適化してしまいます。
00:09:41これにより、仕様にはあったが正しく実装されなかった機能のテストが漏れる可能性があります。
00:09:46エージェントは実装されたアプローチに合わせて最適化するため、徹底したテストを怠り、
00:09:50仕様から直接テストを導き出していれば捉えられたはずのエッジケースを見逃す可能性があります。
00:09:55「アプリケーションをテストして」というような曖昧な指示を出すべきではありません。それではClaudeは実装に合わせて最適化するだけだからです。
00:10:02代わりに、仕様に基づいた適切なテストを実装し、エージェントが何を最適化すべきかを正確に把握できるようにしてください。
00:10:07また、私たちのコンテンツを楽しんでいただけているなら、Hypeボタンを押すことを検討してください。より多くの人に届ける励みになります。
00:10:14多くの人がアプリ開発中に直面するもう一つの問題は、事前の問題(Issue)管理の欠如です。
00:10:19管理していないと、何が原因でいつ始まったのかという記録もないまま問題が山積みになり、アプリの規模が大きくなるにつれて追跡が困難になります。
00:10:26そのため、テスト中に適切なログを保持することが極めて重要です。
00:10:29多くの人がこのためにGitHubを使用しており、GitHubは問題の追跡と管理に優れたプラットフォームです。
00:10:34それを構造化されたGitコミットメッセージと組み合わせることで、各コミットで何が行われたかの指針をClaudeに与え、進捗を追跡させることができます。
00:10:42Gitの最高の機能の一つは、変更によってコードベースが壊れた場合にコミットを元に戻せることです。
00:10:47また、実験的なことを試したい場合は、worktreeを使用して隔離した状態でテストできます。
00:10:51実装ごとに詳細なメッセージを添えてコミットし、明快さを維持するようにセットアップを設定できます。
00:10:58しかし、GitHubは技術的なユーザーには向いていますが、非技術的なチームメンバーは問題の報告に苦労するかもしれません。
00:11:03そのため、彼らのためには、エージェントを Trello や Notion のようなプロジェクト管理ツールに接続するのが理想的です。
00:11:08これにより、問題のログ記録、進捗の追跡、修正作業のコラボレーションが可能になります。
00:11:12それぞれのツールのMCPを接続し、エージェントがアクセスして問題を追跡し、ボード間で移動させ、レポートを効率的に管理できるようにすべきです。
00:11:20また、Claude.md に、エージェントがバグや問題を適切に追跡するために Notion MCP を使用すべきという指示を追加する必要もあります。
00:11:28プロジェクトが拡大し、複数の人が共同で開発を始める際に、すべてを効率的に記録・追跡できるよう、最初にこれを設定しておくことは非常に価値があります。
00:11:36しかし、テストでアプリが完璧に動作したとしても、AIが生成したコードは、本来、複数のユーザーの同時利用を想定して作られているわけではありません。
00:11:43これが、多くの人がAIの実装が本番環境でパフォーマンス不足だと感じる理由です。
00:11:47そのため、その備えも必要です。
00:11:49予測されるユーザー数がわかっている場合は、エージェントにそれを伝え、複数のユーザーが同時に使用することを知らせることができます。
00:11:56そして、この情報に基づいて、負荷をストレスパスするためのテストケースをエージェントに書かせるべきです。
00:12:01使用できるテストツールは複数あり、要件に合ったものを選べます。
00:12:05私たちは Next.js アプリに k6 を使用しました。実装が容易で、私たちの要件に合致していたからです。
00:12:10ここでは詳細な技術計画が必要なため、Claudeのプランニングモードを使用して複数のアプローチをマッピングすることもできます。
00:12:17Claudeは PRD と、同時に利用が予想される概算のユーザー数に基づいて計画を立てます。
00:12:23Claudeは様々な視点から複数の質問を投げかけ、本番環境で発生する可能性のある潜在的な問題を明確にします。
00:12:29これにより、問題が発生してもアプリが適切に終了(Graceful failure)できるようになり、ユーザー体験が最適化されます。
00:12:34このモードを使用することで、意図を明確にし、エージェントにスケーラビリティの計画も立てさせることができます。
00:12:39この計画が、アプリをアイデアから本番レベルへと引き上げるための最後のピースとなります。
00:12:43ここで紹介したすべてのエージェントとスキルは、この動画および過去のすべての動画用として AI Labs Pro で提供されており、ダウンロードして自身のプロジェクトで使用できます。
00:12:53私たちの活動に価値を感じ、チャンネルを支援したいと思っていただけるなら、これが最良の方法です。
00:12:57リンクは概要欄にあります。
00:12:59これでこの動画は終わりです。
00:13:00もしチャンネルを支援し、このような動画作りを続けてほしいと思っていただけるなら、下の Super Thanks ボタンから支援をお願いします。
00:13:07いつものように、ご視聴ありがとうございました。それではまた次の動画でお会いしましょう。

Key Takeaway

Claude Codeの実装精度を最大化するには、プロンプトを投げる前にPRD、Claude.md、否定的な制約、および先行テストの4つの環境設定を完結させる必要があります。

Highlights

AIエージェントにPRD(製品要件定義書)を作成させ、すべての要件を理解するまで質疑応答を繰り返すことで技術的負債を最小化します。

プロジェクトのルートに配置するClaude.mdには、エージェントが知らないプロジェクト固有の規約やベストプラクティスのみを記述し、ファイル構造などの推論可能な情報は除外します。

実装後にテストを書くとエージェントは既存のコードに最適化してしまうため、PRDから逆算して先にテストを実装しエッジケースの漏れを防ぎます。

k6などのツールを用いて、本番環境での複数ユーザー同時利用を想定した負荷テストケースを構築段階でエージェントに作成させます。

エージェントが過去の実装を読み直すオーバーヘッドを減らすため、進捗状況とエラー解決記録を管理する専用のMarkdownファイルを常に更新させます。

Timeline

製品重視のプランニングとPRDの自動生成

  • AIエージェントを人間と同じプロセスに従わせるための環境設定が開発の成否を分けます。
  • 技術的な詳細よりも製品の側面に重点を置いたPRD(製品要件定義書)を専用エージェントに作成させます。
  • エージェントがMVPの全容を把握するまで質疑応答を継続し、合意形成後にプロジェクトフォルダへドキュメントを保存します。

AIの進化に伴い、計画段階での指示はより抽象的な製品レベルの要求へとシフトしています。人間が満足するまで質問を繰り返すプランナーエージェントを使用することで、実装フェーズでの曖昧さを排除します。生成されたPRDは実装フェーズの分割や主要な設計決定の指針として機能します。

Claude.mdとパス固有ルールの定義

  • Claude.mdにはエージェントが知らないプロジェクト固有のルールや命名規約のみを記述します。
  • initコマンドによる自動生成ではなく、プロジェクトのニーズに合わせて手動でファイルを構築します。
  • エージェントが自分でファイル構造を読み取れる情報はコンテキストの無駄を省くために含めません。

Claude.mdは作業中のガイドラインとして常にコンテキストに残り続けるため、情報の密度を最適化する必要があります。コーディング規約や執筆スタイルなど、広範な原則をここに集約します。一度作成して終わりにせず、開発プロセスに合わせて段階的に項目を更新し続けます。

MCP接続と役割別エージェント・スキルの構築

  • Supabaseやshadcn/uiといった外部ツールは構築前にMCPを介してエージェントに接続します。
  • コミット、リファクタリング、検証など、特定のタスクごとに専用のエージェントを使い分けます。
  • 繰り返し発生するワークフローは「スキル」として定義し、専用コンテキストが必要なタスクは「エージェント」に割り当てます。

開発を加速させるために、ブラウザテスト用のPlaywrightやバックエンドのSupabaseなどの外部サービスを事前に統合します。特定のディレクトリに限定されたルールを適用するパス固有ルールをClaude.mdにリンクさせることで、エージェントは場所に応じた適切な指示を認識します。これにより、一貫したフロントエンド構築やエラーのないデプロイフローが可能になります。

否定的な制約による出力の境界線設定

  • 肯定的な指示だけでは埋められない暗黙の隙間を「すべきでないこと」のリストで埋めます。
  • AIが多用するデフォルトの配色や特定のライブラリ使用を禁止事項として明示します。
  • docsフォルダに制約ファイルを配置し、エージェントが勝手な試行錯誤をすることを防ぎます。

AIエージェントは行動を優先しすぎる傾向があり、指示以上のことを過剰に実装してしまう場合があります。出力の目標を明確にするために、曖昧さを排除する否定的な制約が必要です。これにより、デザインの好みや技術的な制限を厳密に守らせることができます。

進捗管理と学習ログによる効率化

  • Progressファイルを作成し、エージェントが実装済み機能と未着手機能を一目で把握できるようにします。
  • Learningファイルにエラーの原因と修正内容を記録させ、同じ間違いの再発を防止します。
  • これら2つのファイルを構築中に動的に更新させる指示をClaude.mdに含めます。

大規模なアプリ開発では、エージェントが現在のステータスを見失い、過去のコードを再読することでトークンと時間を浪費します。進捗管理ドキュメントは情報の核となり、オーバーヘッドを大幅に削減します。学習ログは知識ベースとして機能し、プロジェクト固有のトラブルシューティングを蓄積します。

仕様に基づく先行テストの実装

  • 実装が完了する前に、PRDの仕様から直接テストコードを生成させます。
  • 「テストして」という曖昧な指示ではなく、仕様に基づいた適切なテストケースを定義します。
  • 実装された機能にテストを合わせるのではなく、要求された仕様にコードが合っているかを検証します。

後からテストを書かせると、エージェントは「実際に書かれたコード」を正解として扱い、本来の仕様にあった欠陥を見逃します。仕様から失敗しそうな箇所を逆算して設計することで、徹底したエッジケースの捕捉が可能になります。これにより、仕様には存在するが実装から漏れた機能の発見が容易になります。

Issue管理と本番環境のスケーラビリティ計画

  • GitHub IssuesやNotion MCPを連携させ、バグの発生原因と修正履歴を構造化して管理します。
  • 同時ユーザー数を想定したk6による負荷テストをエージェントに書かせ、スケーラビリティを確保します。
  • Claudeのプランニングモードを用いて、本番環境で発生しうる潜在的な問題と異常終了(Graceful failure)の対策を練ります。

開発規模が大きくなるにつれて、問題の追跡が困難になります。GitHubのコミットメッセージやTrello等のプロジェクト管理ツールをエージェントに操作させることで、非技術的なメンバーとのコラボレーションも円滑になります。最後に、複数ユーザーの利用を想定した負荷テストを組み込むことで、AI生成コードをプロトタイプから本番レベルの製品へと昇華させます。

Community Posts

View all posts