00:00:00ここ数ヶ月、BMAD、GSD、SpecKit、Superpowersなど、多くのAIコーディングフレームワークを取り上げてきました。
00:00:08実際に使い始めた方も多いでしょう。しかし、Anthropicが自社のテスト環境で実験を行いました。
00:00:14コンポーネントを1つずつ取り除き、何が本当に重要かを測定した結果、
00:00:17彼らの結論は、そのほとんどが今や「デッドウェイト（無用の長物）」であるということでした。
00:00:25フレームワークの各要素は、モデルが自力でできないことへの仮定に基づいています。
00:00:32しかし、Opus 4.6の登場により、それらの仮定はもはや時代遅れになりました。
00:00:37私たちは全容を把握し、何が依然として重要で、何を削ぎ落とせるのか、
00:00:43そして現在のセットアップがどうあるべきかをまとめました。
00:00:50エージェント・ハーネスは、長期的なタスクにおいてエージェントの性能を大幅に向上させる重要な役割を担います。
00:00:55Anthropicはすでにエージェント・ハーネスを公開しており、以前の動画でセットアップと使用方法を詳しく解説しました。
00:01:01他にも同様の文脈でいくつかのフレームワークを紹介しましたが、
00:01:06実装方法は違えど、目指しているゴールはすべて同じです。
00:01:11しかし、それらのフレームワークが登場した当時、モデルは現在のOpus 4.6ほどの能力を持っていませんでした。
00:01:17例えば、GSDのようなフレームワークは「コンテキストの分離」に重点を置いていますが、
00:01:24Opus 4.6においては、それはもはや問題ではありません。
00:01:29100万トークンのコンテキストウィンドウがあるからだけではありませんが、その別の理由については後ほどお話しします。
00:01:35したがって、以前に実装された多くのフレームワークは、今や新しいモデルの能力に対してオーバーヘッド（余計な負荷）となっています。
00:01:38Anthropicは、ハーネスのさまざまな側面をテストする実験を行い、
00:01:46各要素を取り除いた際の影響を測定しました。
00:01:54その結果、エージェント・ハーネスに本当に必要なのは、計画、生成、評価のためのエージェントだけだと結論付けました。
00:02:01それ以外は、モデルが非常に有能になった現在では、単なる「デッドウェイト」に過ぎない手法なのです。
00:02:06核心となる理論は、どのフレームワークを使用していようとも、エージェント・ハーネスのすべてのコンポーネントが同じ原則に基づいているということです。
00:02:14各コンポーネントは、モデルが単独でできることについての仮定をエンコードしています。
00:02:20これらの仮定は、モデルが進化するにつれて不正確になったり、陳腐化したりするため、ストレスステストを行う必要があります。
00:02:27彼らは記事全体を通してそれを行いました。
00:02:30したがって、モデルの進化に合わせてハーネスも進化させるべきであり、
00:02:43数ヶ月前の原則のまま作業しているなら、最新の状態についていけていないことになります。
00:02:45「計画（Planning）」は、どのフレームワークでも変わらない最初のステップですが、
00:02:50より能力の高いモデルに合わせて、その計画の仕方は変える必要があります。
00:02:55Anthropicの以前の長期実行ハーネスでは、ユーザーが事前に詳細な仕様を提供する必要がありました。
00:02:57BMADやSpecKitのようなフレームワークは、文字通りタスクを小さな断片やマイクロタスクに分割し、
00:03:02AIエージェントが簡単に実装できるようにしていました。
00:03:08これらは単なる小さなタスクではなく、エージェントが考えずに従うだけの「詳細な手順」でした。
00:03:18当時はモデルの能力が十分ではなく、望み通りに動作させるには細かく誘導する必要があったからです。
00:03:23しかし、Opus 4.5や4.6では状況が変わりました。
00:03:32Anthropicのテストによれば、プランナーが事前に細かい技術的詳細を指定しようとすると、
00:03:401つのエラーが実装のすべてのレベルに連鎖し、
00:03:46エージェントが自ら軌道修正して問題を解決することが難しくなることが分かりました。
00:03:52すべては「いかに完璧な計画書が書かれているか」に依存していたのです。
00:03:56そのため、現在、計画は詳細な技術実装ではなく、ハイレベル（抽象的）なものであるべきです。
00:04:06エージェントは自ら判断できるほどスマートになったため、必要な成果物（デリバラブル）を伝えるだけで十分です。
00:04:12彼らは自分たちでそこに至るまでの道筋を見つけ出すことができます。
00:04:22この変化により、BMADやSpecKitのような計画アプローチは、もはやそれほど重要ではなくなりました。
00:04:31BMADの使用をPRD（製品要求仕様書）生成までの計画フェーズに限定し、技術的な分割プロセスは省くことができます。
00:04:40以前述べたように、BMADによるPRD生成が効果的なのは、
00:04:44Claude単体よりも製品要件を深く理解するための専門エージェントを備えているからです。
00:04:47これらのエージェントには、作成者によって特定のタスクに関する外部コンテキストが追加されているためです。
00:04:56あるいは、Superpowersの質疑応答セッションを利用することもできます。
00:04:59これはエッジケースを特定することを目的としており、多層的なタスク文書化よりも効果的な場合があります。
00:05:02しかし、過度に詳細な計画の根本的な問題は、エージェントを束縛してしまい、
00:05:12AIが自ら発見し、解決策を導き出す余地をなくしてしまうことです。
00:05:21Anthropicは、独自のプランナーエージェントを設定する際に参考にできる、プランナーエージェントが生成した計画例も公開しています。
00:05:27そこでは、計画はスコープを大きく持ち、提供されたアプリのアイデアの限界を押し広げるべきだと明確に示されています。
00:05:33核心的な考え方は、プロジェクトを「実装レベル」ではなく「製品レベル」で維持することです。
00:05:39もしプロジェクト計画の中で実装まで細かく計画しようとすると、技術的な詳細に固執しすぎてしまい、
00:05:42完全な製品として本当に必要なものを届けるのに失敗する可能性があるからです。
00:05:46「Claude自身のプランモードも、質問を投げかけたり詳細な計画を立てたりして同様のことをしているのではないか」と思うかもしれません。
00:05:56しかし、ここが違います。Claudeには計画エージェントがいますが、依然として実装の詳細に大きく偏っており、
00:06:03Anthropicの知見に反して、真に製品レベルで動作しているわけではありません。
00:06:08したがって、この体制を整えた後は、作成したエージェントを使ってアプリの計画を立てるようClaudeに依頼するだけです。
00:06:10すると、進行に合わせて完全な計画を生成し、フォルダ内にドキュメント化してくれます。
00:06:15この計画には製品レベルでの全機能のブレイクダウンが含まれ、
00:06:19各フェーズにはユーザーの視点を示すユーザーストーリーも含まれています。
00:06:26これにより、Claudeはユーザーが実際に期待する正しいワークフローを実装できるようになります。
00:06:34さて、先へ進む前に、スポンサーであるMinimaxからのお知らせです。
00:06:39AIエージェントのセットアップは悪夢です。APIキー、サーバー構成、Docker設定、
00:06:47それだけ苦労しても、タブを閉じた瞬間にアシスタントはすべてを忘れてしまいます。
00:06:54解決策は、指先ひとつで使えるクラウド型AI「MaxClaw」です。
00:06:58セットアップも悩みも不要で、独自のOpenClawをデプロイできます。
00:07:02デプロイをクリックするだけで、10秒以内に稼働します。ウェブサイトの構築、コード作成、リサーチ、
00:07:06そしてルーチンワークの自動化まで、すべてシンプルなテキストプロンプトから行えます。
00:07:12MaxClawはTelegram、Slack、Discordなどと直接連携し、ワークフローの自動化、ウェブ閲覧、
00:07:18さらには画像や動画の生成まで、すべてシンプルなチャットから実行可能です。
00:07:22これは「Minimax Agent」の一部であり、誰もがエージェントデザイナーになれるAIネイティブなワークスペースです。
00:07:27MacとWindowsで動作し、M 2.7を搭載。これはSWE-benchにおいてClaude Opus 4.6に匹敵する性能です。
00:07:32複雑なセットアップに格闘するのはもうやめて、MaxClawに任せましょう。固定コメントのリンクから始めてください。
00:07:38「コードを書くエージェントは、それを評価するエージェントであってはならない」。
00:07:42これは2番目に多い問題ですが、あまり議論されることはありません。
00:07:51自己評価には問題があります。コードを書いたのと同じエージェントに評価をさせると、
00:07:57たとえ品質が明らかに基準以下であっても、非常に自信たっぷりに反応し、自画自賛する傾向があるからです。
00:08:02「実装したAPIが実際に動作するか」といった定量的な指標があるタスクなら、まだ管理しやすいかもしれません。
00:08:08しかし、明確に検証可能な結果がないタスクでは、この問題はより顕著になります。
00:08:13その最大の例がUIです。
00:08:17何が良いUIであるかは主観的であり、AIはあなたの意図を完全には把握できないかもしれません。
00:08:21あなたの基準に達していなくても、AIは自らの実装を「よくできている」と見なす可能性があります。
00:08:28この問題は複数のフレームワークの制作者によってすでに認識されており、独自の評価メカニズムが実装されています。
00:08:37GSD、BMAD、Superpowersなど、紹介してきたすべてのフレームワークは、
00:08:42コードを書いたエージェント自身がその品質を評価しないようにしています。
00:08:47このアプローチにより、エージェントによる評価の正確性と信頼性が大幅に向上します。
00:08:50したがって、既存のフレームワークを使うにせよ、自作するにせよ、
00:08:56評価担当（エバリュエーター）を実装担当（インプリメンター）から完全に分ける必要があります。
00:09:02実装が始まる前に、生成エージェントと評価エージェントの両者が「コントラクト（契約）」を交わし、
00:09:07その作業における「完了」の定義について合意します。
00:09:11これにより、両方のエージェントが何を達成し、何を検証すべきかを明確に把握できます。
00:09:18ハイレベルな計画であっても、実行可能で実装可能なステップは必要です。
00:09:21しかし、ハーネスのテスト中、彼らは「スプリント・コントラクト」を取り除いてみました。
00:09:30その結果、Opus 4.5では、評価担当が問題をキャッチするために介入し続ける必要があり、効率が低下しました。
00:09:39ところがOpus 4.6では、モデルの能力が非常に向上していたため、もはやコントラクトは必要ありませんでした。
00:09:46生成エージェントは、ほとんどの作業を自力でこなせるほど有能になっていたのです。
00:09:50そのため、SonnetやHaikuのような小規模なモデルでは、依然としてタスクのドキュメント化が必要です。
00:09:57タスクをスプリント構造に適切に分解し、各エージェントに「完了」の定義を合意させる必要があります。
00:10:04しかし、より有能なモデルであれば、追加のステップなしに、Opusにハイレベルな計画の実行を任せることができます。
00:10:10さて、先ほど「コンテキストの分離」が重要である理由があると言いました。
00:10:13それは、小規模なモデルが「コンテキスト不安（Context Anxiety）」を起こすためです。
00:10:18これは、コンテキストウィンドウが埋まるにつれて、長いタスクにおいてモデルの一貫性が失われ始める現象です。
00:10:24これが発生すると、AIは作業を途中で切り上げ、実際には終わっていないのに「正しく実装した」と主張し始めます。
00:10:35有効だった解決策は「コンテキストのリセット」、つまり実装を開始する前にコンテキストウィンドウを消去することでした。
00:10:43コンテキストがクリアされても、外部に記録されたタスク分解を参照すれば、リセットを跨いで継続できます。
00:10:49しかし、モデルのコンテキスト不安は非常に強く、要約（コンパクション）だけでは不十分でした。
00:10:54長期的なタスクで問題を防ぐには、さらなる対策が必要だったのです。
00:11:02しかし、Opus 4.5以降、モデルはこの挙動を示さなくなりました。
00:11:06これらのエージェントはセッション全体を通して連続して動作でき、Claudeの要約機能だけで十分に機能します。
00:11:12したがって、コンテキストのリセットはもはや不要であり、BMADやSpecKitのような詳細なタスク分解も必要ありません。
00:11:19ハイレベルなガイダンスだけで十分なのです。
00:11:27生成（ジェネレーター）エージェントは、アプリを機能ごとに構築していくメインの実装担当です。
00:11:37計画から仕様を受け取り、Gitと連携してバージョン管理を行いながら、継続的に実装を進めます。
00:11:44生成担当は評価担当エージェントと連携して動作します。
00:11:54機能を構築した後、それをテストに回し、フィードバックを受けて実装を改善します。
00:12:02そのワークフローは、タスクの理解、実装、そして実装のブラッシュアップといういくつかのステップに分かれています。
00:12:10実装フェーズの中でも、作業は異なる側面をカバーする4つのサブフェーズに分割されています。
00:12:17デザインの方向性に従い、自らの作業を検証してから、評価担当に渡します。
00:12:21これにより構造化された段階的なパターンが生まれ、エージェントがアプリ全体を独立的かつ体系的に実装できるようになります。
00:12:35評価（エバリュエーター）エージェントは、生成担当に対する「検閲官」として機能します。
00:12:49その役割は、単に「バグを探す」といった一般的なパスではなく、バグが存在するという前提で批判的にアプローチすることです。
00:12:58Playwrightなどのツールを使用して、ユーザー操作をシミュレートしてテストを行い、
00:13:03事前定義された基準に基づいてバグを特定し、生成担当にフィードバックを返します。
00:13:10評価担当は計画を読み込むことで「完了」の定義を明確に理解し、承認前にすべてを徹底的にチェックします。
00:13:24各フレームワークにバリデーターはありますが、そのアプローチは大きく異なります。
00:13:33BMADは専門のコードレビューおよびQAエージェントを使用し、テストを生成・実行して多角的にコードを評価します。
00:13:43GSDは、既存の計画に照らして実装をチェックし、文書レポートを作成する検証サブエージェントを使用します。
00:13:48Superpowersは新しいサブエージェントに依存し、テストケースを書く前にコードを書いてはならない厳格なTDD（テスト駆動開発）を強制します。
00:13:57エージェントがこれをバイパスしようとすると、ブロックされます。