00:00:00Claude CodeはAI開発において最も強力なツールの1つですが、
00:00:03特定のタスクでうまく機能しないのはなぜでしょうか? Anthropicが最近
00:00:08次々とリリースしている機能や、私たちが構築してきたワークフローによって、このツールの
00:00:12推奨される使い方は、数週間前とは全く別物になっています。私たちのチームはClaude Codeを
00:00:16毎日活用しており、開発だけでなく、リサーチや本番環境の
00:00:21パイプライン管理、さらにはコードに関係のないタスクの自動化にも使っています。そこで、私たちが
00:00:26これまでに解明したすべてをご紹介しましょう。Anthropicは最近、Claude Codeに「insights」コマンドを追加しました。これは
00:00:31一定期間の過去のセッションをすべて分析し、レポートを生成する機能です。
00:00:36レポートでは、作業スタイルを分析し、パターンを厳しく指摘(ロースト)し、良かった点と
00:00:40改善すべき点を浮き彫りにします。私たちが特に注目したのは、
00:00:45どこで失敗したかの特定です。そこにこそ成長のヒントがあるからです。レポートは
00:00:49最も摩擦が生じていた部分を指摘し、ワークフローを改善するための
00:00:54機能提案もしてくれました。例えば、エージェントチームを使用していた際、メインエージェントが
00:00:58長時間タスクリストをポーリングし続けてしまったセッションがありました。その結果、
00:01:03セッションが長引きすぎ、自分たちで終了させる必要がありました。これを今後防ぐために、
00:01:07このプロンプトを「claude.md」にコピーしておけば、マルチエージェント環境でも
00:01:12無限にポーリングすることなく、適切に行動してくれます。こうしたコツをプロジェクトに取り入れることで、
00:01:17Claude Codeの体験は時間とともに向上します。私たちのチームは多くの時間を
00:01:22Claude Codeに費やしてきましたが、最も重要なステップは、やはりエージェントにどれだけ適切なコンテキストを与えられるかです。
00:01:26これは細分化されたプロジェクト要件や、使用しているフレームワーク、
00:01:30ライブラリのドキュメントなどが該当します。正しいコンテキストがあれば、エージェントは何をすべきか理解し、
00:01:35エラーは実質ゼロになります。プロジェクトのドキュメント作成については、自分たちで書くよりも
00:01:39Claudeに書かせる方が効率的です。私たちは、プロジェクトのアイデアを
00:01:44必要なドキュメントに分解するために必要な情報をすべて含めた、特定のプロンプトをClaudeに与えました。
00:01:48アプリの特定の側面に焦点を当てた4つのドキュメントの作成を依頼したのです。最も重要なのは、
00:01:53プロジェクトの要件とスコープを記した「PRD(製品要件仕様書)」です。次に「architecture.md」があり、
00:01:57データ形式、ファイル構造、API、その他すべてのアーキテクチャの詳細が記述されています。
00:02:02さらに「decision.md」には、プロジェクト作成中にClaudeが行ったすべての決定事項が記録され、
00:02:08将来の参照用となります。そして最も重要なのが、特定のJSON形式ですべての機能を記述した「feature.json」です。
00:02:12これは各機能の詳細をトークン効率の良い方法で保持し、
00:02:17機能の完了基準と、実装済みかどうかを追跡するための「passes」キーを含んでいます。
00:02:22大きなタスクが細分化されたら、次は実装に必要なツールのドキュメントを
00:02:27「Context 7 MCP」を通じて提供する必要があります。ここにはあらゆるライブラリや
00:02:31フレームワークのドキュメントがあり、頻繁に更新されているため、エージェントは
00:02:36最新のドキュメントを取得し、モデルの知識と実際の最新アップデートとのギャップを埋めることができます。
00:02:41MCPの設定はわずか数ステップです。インストールすると、
00:02:46Context 7のツールを使用してライブラリ情報を直接取得します。これにより、
00:02:50最新のドキュメントを使用し、依存関係の不一致によるコードエラーを防ぎ、より
00:02:55正確な実装が可能になります。また「フック」も、あまり活用されていない強力な機能です。
00:03:00Claude Codeのフックは、ライフサイクルの特定のポイントで実行されるシェルコマンドです。
00:03:05セッション開始時やツールの使用前後など、特定のタイミングでトリガーされる多くの種類があります。
00:03:11しかし最も重要なのは、これらを特定の「終了コード」で設定することです。終了コードによって、
00:03:16Claude Codeにアクションを続行、ブロック、または無視させるかを指示できます。コード0は成功、
00:03:22コード2はブロッキングエラーを意味します。Claudeがすべきでないことをしようとした際、コード2に当たると
00:03:27エラーメッセージが返され、自己修正が可能になります。それ以外のコードは非ブロッキングで、
00:03:32詳細モードで表示され、実行は継続されます。このコード2は、エージェントの動作を制御する上で
00:03:37非常に重要です。Claude Codeを使ってテスト駆動開発(TDD)をしたことがあるなら、
00:03:41テストが通らない場合にClaudeがテスト自体を書き換えてしまう傾向に気づいたかもしれません。
00:03:46それを防ぐために、ツールの使用前にトリガーされるカスタムフックを設定しました。このフックは、
00:03:50テストスクリプトが修正されるのを保護します。対象のパスがテストディレクトリであるか、
00:03:55名前に「test」が含まれている場合、「テストフォルダの修正は許可されていません」というメッセージを出し、
00:04:00終了コード2を返します。このフックを設定した状態で、テストを実行し失敗した際、Claudeが
00:04:05テストファイルを修正しようとしましたが、スクリプトがそれをブロックし、「修正がブロックされました」という
00:04:10メッセージが表示されました。これにより、編集すべきでないファイルをClaudeがいじるのを止められました。
00:04:15MCPを使ったことがある人なら、コンテキストウィンドウが肥大化することをご存知でしょう。
00:04:19大規模なプロジェクトでは接続されるMCPが増え、それらすべてのツールが
00:04:25コンテキストウィンドウを占領してしまいます。この問題を解決するために、Claude Codeには
00:04:31実験的な「MCP CLIモード」があります。このフラグをtrueに設定すると、これまで
00:04:36コンテキストに表示されていたすべてのMCPが消え、ウィンドウを消費しなくなります。
00:04:41では、メモリ上に存在しないツールにどうアクセスするのでしょうか? Claude Codeは、
00:04:45すべてのツールのスキーマを事前に読み込む代わりに、「MCP CLI info」と「MCP CLI calls」を使い、
00:04:52接続されたMCPをbash経由で実行します。この設定では、プロンプトを与えた際、
00:04:56MCPツールを直接呼び出すのではなく、MCP CLIツール経由でbashコマンドとして実行します。
00:05:03これにより、必要なツールだけをオンデマンドで読み込み、コンテキストの肥大化を防ぎます。
00:05:08もし私たちのコンテンツを気に入っていただけたら、ぜひ高評価(Hype)ボタンを押してください。
00:05:13励みになりますし、より多くの人に届けることができます。以前の動画でも強調しましたが、
00:05:18gitを使用して、エージェントのすべての作業をバージョン管理下で追跡することが重要です。
00:05:23そうすれば、実装が正しくない場合に元に戻すことができます。また、gitを使用してエージェントを
00:05:28長期タスクで実行する動画も公開していますので、ぜひチェックしてみてください。私たちは
00:05:32並列エージェントを使用して異なる「ワークツリー(worktree)」で作業させ、各機能の作成を
00:05:37互いに孤立した状態で行いました。同じファイルを複数のエージェントがいじると競合するため、
00:05:41後で出力をマージするこの方法が有効です。ブランチは、同じ作業ディレクトリを共有するため
00:05:46エージェントが切り替えに苦労しやすく、競合も起きやすいですが、ワークツリーなら別々です。
00:05:50そこで、実装すべき複数の機能を提示し、それぞれ別のワークツリーで
00:05:55作業するよう指示しました。その結果、各ワークツリーに別々のエージェントが割り当てられ、
00:05:59タスクの内容が一部重なっていても、隔離された状態で実装が進められました。
00:06:03すべての機能が別ブランチで正しく実装された後、出力をマージさせることで、
00:06:08単一の作業ディレクトリにすべての機能を統合することができました。
00:06:13次に「厳密(ストリクト)モード」は、エラーチェックの負担をエージェントに移すために不可欠です。
00:06:18使用する言語を問わず、実行時ではなくビルド時にバグをキャッチできるように設定すべきです。
00:06:22私たちは主にTypeScriptを使用しているため、常にプロジェクトで厳密モードを有効にしています。
00:06:26これにより、null値や暗黙的な型のチェックが有効になり、型定義が強制されます。
00:06:31結果として実行時エラーが減少します。AIエージェントには実行時エラーを自力で
00:06:36検知する機能がないため、これは重要です。厳密モードは実行時の失敗を最小限に抑え、
00:06:41代わりにコンパイラに問題を処理させます。エージェントはターミナルのエラーログを頼りに、
00:06:46既知の修正を適用できます。プロジェクトをスクリプトだけでテストするのではなく、
00:06:51さらなるテストレイヤーを追加する価値があります。それは「ユーザーストーリー」を書き、
00:06:56アプリ構築後のテストプロセスを導くために、ユーザーがシステムとどう対話するかを記述することです。
00:07:00私たちは実装前にユーザーストーリーを定義します。これが、実装が従うべき基準となるからです。
00:07:05プロンプトを使って、Claudeに考えられるすべての操作パターンを含むストーリーを
00:07:10フォルダ内に作成させました。各ストーリーは、アプリの特定の側面、
00:07:15優先度、そしてエージェントがテストするための受け入れ基準を備えています。これらのストーリーは、
00:07:21正常系からエッジケースまで、あらゆるテストシナリオを網羅しています。つまり、
00:07:26構築したシステムとどう対話すべきかをエージェントに教える役割を果たします。正しい指示があれば、
00:07:31どんなエージェントでも同じ原則を適用でき、ユーザーの期待に沿ったアプリを作れます。
00:07:35ストーリーを文書化した後、Claudeにそれらを1つずつ実装するよう依頼し、
00:07:40各ストーリーの最適なパスから始め、すべてのエッジケースを網羅するよう促しました。
00:07:45この方法により、実装の漏れが減り、全体的なユーザー満足度が向上しました。
00:07:50さて、今回紹介したすべてのヒントは、「AI Labs Pro」で、すぐに使えるテンプレートとして提供しています。
00:07:55ご存知ない方のために説明すると、これは最近私たちが立ち上げたコミュニティで、
00:08:00今回の動画や過去の動画で紹介したテンプレート、プロンプト、コマンド、スキルが手に入ります。
00:08:05もし私たちの活動を価値があると感じ、チャンネルをサポートしたいと思っていただけるなら、
00:08:10これが最良の方法です。リンクは概要欄にあります。
00:08:14次に、並列化を最大限に活用する必要があります。これがエージェントのワークフローを加速させ、
00:08:20互いに依存しないタスクを同時に実装する方法だからです。Claudeは自動的に
00:08:25タスクが並列か逐次かを検出し、自身で判断しますが、自分たちでエージェントを作るのも有効です。
00:08:29前回の動画でも、エージェントを使ってワークフローを高速化する方法について触れましたが、
00:08:34このスピードはトークン使用量の増加というコストを伴います。それでも、並列化の努力には価値があります。
00:08:39以前、同じモデルを使ってOpus 4.6の改善による影響をリサーチしていた際、
00:08:43ソースを提供しているにもかかわらず、事実を捏造(ハルシネーション)し続けました。
00:08:49誤った情報を書き続けるため、何度も修正する必要があり、自分たちで直すなら
00:08:54リサーチをさせている意味がないと感じるほどでした。これを二度と起こさないために、
00:08:58並列エージェントを採用しました。「KimiK 2.5」と「Claude」のエージェントスウォーム(群れ)機能を
00:09:03比較するリサーチタスクを設定した際、2つのエージェントを使用しました。
00:09:09一方はリサーチを担当し、もう一方はそのリサーチをファクトチェックする役割です。
00:09:14重要なのは、両者が対話して調査結果の正確性を確認し、私たちが手動でやる必要をなくすことです。
00:09:19このセットアップでは、一方のタスクをもう一方が批判的に分析する「敵対的」な関係になります。
00:09:24リサーチエージェントがまず作業を開始し、ファクトチェッカーは初稿ができるまで待機します。
00:09:28初稿が完成すると、ファクトチェッカーが検証を始めました。するとすぐに
00:09:33リサーチエージェントが挙げたデータの多くの不正確さを特定しました。もう私たちが
00:09:38手動で見つける必要はありません。両者は対話を続け、ファクトチェックのプロセスを厳密に保ちました。
00:09:43一方のエージェントが、もう一方の誤った情報を指摘することに専念したのです。
00:09:47このような敵対的な構成で実行できるタスクは多くあります。リサーチだけでなく、
00:09:52一方が機能を実装し、もう一方が計画通りかレビューする開発作業にも有効です。
00:09:57Claude Codeのクリエイターによれば、エージェントは自身の作業を検証する手段があるときに
00:10:02より良く機能します。核心となる考え方は、エージェントに「目」を与えること、
00:10:07つまり実装された機能が正しく、期待を満たしているかを確認する能力を持たせることです。
00:10:12これらのエージェントはターミナルベースであるため、特にクライアントサイドで発生する
00:10:17実行時の問題を特定できません。そこで、私たちは複数の検証方法を使っています。
00:10:211つはClaude Chrome拡張機能で、DOMキャプチャやコンソールログのチェックなど、ブラウザ中心のツールを提供します。
00:10:26もう1つは「Puppeteer MCP」です。これは既存のセッションを含まない
00:10:31独立したブラウザで動作するため、プライバシーが守られ、現在の作業を邪魔しません。
00:10:36しかし、私たちが最も好んで使うのは、Vercelの「agent-browser」です。
00:10:41これはMCPではなく、エージェントにブラウザテスト機能を与えるCLIツールです。
00:10:46ナビゲーションやスクリーンショットの撮影などが可能です。他のツールと違うのは、
00:10:51スクリーンショットだけに頼らず「アクセシビリティツリー」を使用する点です。
00:10:56各要素に一意の参照があり、数千トークンのDOM全体を200〜400トークン程度に圧縮できるため、
00:11:01非常にコンテキスト効率が良いのです。これがClaude Chrome拡張機能の最大の課題であり、
00:11:07agent-browserが解決した問題です。拡張機能はDOM全体を読み込み、すぐにコンテキストを使い果たしてしまいます。
00:11:12そこで、claude.mdに、MCPベースのテストにフォールバックする前に、
00:11:17まずagent-browserを頼るよう指示を追加しました。これにより、これが主要な検証方法となります。
00:11:23しかし、別の側面もあります。テストは常に重要ですが、テストやコードレビューを介さずに
00:11:28エラーを減らす方法があります。それは、Claudeに「まだ起きていないこと」を予測させることです。
00:11:33実装をチェックし、アプリが失敗する可能性がある箇所を特定するようClaudeに依頼します。
00:11:38自分たちがテストで遭遇していなくても、他のアプリに存在した失敗例とパターンマッチングさせることで、
00:11:43潜在的な問題を予測させるのです。これにより、Claudeはこれまでとは異なる角度から
00:11:47コードを見るようになります。実際にそう依頼したところ、多層的なテストプロセスさえ
00:11:52すり抜けていた重大な欠陥が特定され、本番環境で有害になり得た18もの問題が見つかりました。
00:11:57これらは通常のテストプロセスではキャッチできませんでした。Claudeに別の角度から
00:12:01プロジェクトを見させることで初めて特定できたのです。以上で今回の動画を終わります。
00:12:06もしチャンネルを支援し、このような動画作りを応援していただけるなら、
00:12:10下の「スーパーサンクス」ボタンからお願いします。いつものように、ご視聴ありがとうございました。
00:12:15また次回の動画でお会いしましょう。