00:00:00今回の動画はHubSpotの提供でお送りします。
00:00:03実は2025年12月に、非常に大きな出来事がありました。
00:00:07しかし、ほとんどの人はそのことに気づいてさえいません。
00:00:09先週、アンドリュー・カプシーがこれについてツイートしていました。
00:00:10「この2ヶ月間でAIによってプログラミングがどれほど変化したか、
00:00:15特に昨年12月以来の変化を言葉で伝えるのは非常に難しい」と。
00:00:17OpenAIのグレッグもこれについて言及しています。
00:00:2012月以降、モデルとツールができることに段階的な飛躍が見られるというのです。
00:00:24数名のエンジニアからは、2025年12月を境に
00:00:28自分たちの仕事が根本的に変わったと聞いているそうです。
00:00:29では、2025年12月に実際に何が起きたのでしょうか？
00:00:32一言で言えば、当時導入された最新モデルが、ついに完全自律型の
00:00:37長時間実行タスクをこなせる段階に達したということです。
00:00:38AIにおける究極の夢は、私たちが眠っている間も
00:00:43AIが24時間365日、完全に自律してタスクを処理してくれることです。
00:00:462023年を振り返ると、最も人気だったプロジェクトは「AutoGPT」でした。
00:00:50これが初めて導入された完全自律型エージェントシステムでした。
00:00:54その仕組みは、GPT-4をモデルとして使い、ユーザーの目標に基づいて
00:00:59自律的にタスクを分解し、結果を保存するための
00:01:03単純なメモリを備えているという、かなり基本的なものでした。
00:01:04当時は「10万ドル稼げ」といった目標を与えて、
00:01:08完了するまで無限にタスクをループさせるような、無茶なことも行われていました。
00:01:11しかし、当時はモデルの準備が整っておらず、システムは無残に失敗していました。
00:01:15ところが、昨年12月以来、状況は一変しました。
00:01:18モデルの品質と長期的な一貫性が大幅に向上し、
00:01:22より大規模で長時間のタスクをやり遂げられるようになったのです。
00:01:24そして業界からは、あらゆる種類の実験的な試みが登場しました。
00:01:28まず1月には「Rough Loop」という非常にホットな概念が登場しました。
00:01:33これは最も基本的でシンプルなエージェントの反復ループで、モデルを長時間働かせ、
00:01:37より複雑なタスクを処理させるためのものです。
00:01:38単純な条件チェックを伴うループを回すだけですが、それでも
00:01:42すでに明らかな違いが見え始めています。
00:01:43その1週間後、CursorもGPT-5.2を使用して、300万行のコードから成る
00:01:49ブラウザをゼロから自律的に構築するという実験結果を公開しました。
00:01:52また、Anthropicも、Claude Codeのチームが2週間にわたって
00:01:57Cコンパイラをゼロから自律的に作成させるという実験を公開しました。
00:02:01最終的に、手動でのコーディングなしで機能するバージョンが完成しました。
00:02:05そのコンパイラ内で「Doom」を動かすことさえできたのです。
00:02:08同時期に「OpenClaw」が注目を集め始め、
00:02:13これまでに見たことがないほどの爆発的な成長を遂げました。
00:02:14OpenClawで何が起きているのかを理解するのは、当初は困難でした。
00:02:18外から見れば、単に自分のコンピュータ内に常駐し、
00:02:23Telegramからもアクセスできるエージェントの一つに過ぎないように見えたからです。
00:02:27なぜこれほど人気があるのでしょうか？
00:02:29深く使い込んでみて初めて、真の違いに気づきました。OpenClawは、
00:02:35「常時稼働・長時間実行・完全自律型」というタイプのエージェントを象徴しており、
00:02:40人間が主な原動力となって次のアクションを促す（プロンプトを出す）という、
00:02:45これまでのエージェントシステムとは全く異なるものだったのです。
00:02:46OpenClawは常に稼働しており、かつ能動的です。
00:02:49この自律的な感覚は、かなりシンプルなアーキテクチャによって作られています。
00:02:53トリガーとcronジョブを備えたメモリコンテキスト層を持ち、自動的にアクションを実行します。
00:02:58さらにコンピュータへのフルアクセス権という、強力な動作環境を持っています。
00:03:02OpenClawは、2026年における最大のパラダイムシフトを切り開いた
00:03:06最初のプロジェクトだと私は信じています。私たちは、単発のタスクベースの「副操縦士」から、
00:03:13長時間実行される「完全自律型エージェント」へと移行しているのです。
00:03:15常に稼働し、常に準備ができており、極めて複雑で連携の取れた仕事を完遂する。そんな存在です。
00:03:20これは理解しておくべき重要な転換点です。
00:03:22適切なシステムさえ設計すれば、現在のモデルは
00:03:27皆さんが考えている以上にずっと強力なのです。
00:03:28そして、これこそが今日お話ししたいことの核心です。
00:03:30長時間実行される自律型システムを実現するための「Harness Engineer」についてです。
00:03:34「Harness Engineer（ハーネス・エンジニア）」という言葉を初めて聞くかもしれませんが、これは
00:03:38以前お話しした「Context Engineer」や「Prompt Engineer」が進化したものです。
00:03:41これまでは、単一のエージェント・ループ・セッションにおいて
00:03:46モデルのパフォーマンスを最大化するために、有効なコンテキスト・ウィンドウ内のプロンプトを最適化することに重点を置いていました。
00:03:49しかし、Harness Engineerが焦点を当てるのは長時間実行されるタスクです。
00:03:53つまり、異なるセッションや複数のエージェントを跨いで動作するシステムをどう設計するかということです。
00:03:57また、各セッションで関連するコンテキストが確実に取得されるようなワークフローをどう設計し、
00:04:01モデルから最大限の能力を引き出すための適切なツールセットをどう構築するか、ということです。
00:04:05これはかなり新しい概念ですが、幸いなことに、AnthropicやVercel、
00:04:09LangChainなどから、すでにいくつかのベストプラクティスが生まれています。
00:04:14それらを一つずつ見ていき、どのようなパターンがあるのかを確認していきましょう。
00:04:16しかしその前に、この完全自律型エージェントへのパラダイムシフトにおいて、
00:04:21今後6〜12ヶ月で最大のチャンスとなるのは「特定の垂直市場向けOpenClaw」の構築です。
00:04:25つまり、ある特定の業界のエンドツーエンドのワークフローを深く調査・理解し、
00:04:29そのプロセスを完結させるための適切な環境とツールを備えた自律型エージェントを構築するのです。
00:04:34そこで紹介したいのが、HubSpotが行った「メールマーケティングにおける
00:04:39AI導入に関する調査レポート」という素晴らしいリサーチです。
00:04:40このレポートは、メールマーケティングという分野で、現在人々が
00:04:44どこで実際にAIを使用しており、どこにギャップがあるのかを理解するのに非常に役立ちます。
00:04:47なぜなら、このレポートはメールマーケティングにおける明確なワークフローと、
00:04:51自動化できる可能性のあるチャンスを提示しているからです。
00:04:52彼らは一流企業の数百人のメールマーケターを対象に調査を行い、
00:04:57AIが彼らのワークフローをどのように再形成しているのかを正確に把握しました。
00:04:58なぜマーケターがいまだに多くの手動編集を行っているのか、その原因は何か、
00:05:03そしてメールマーケティングにAIを導入する際に直面している
00:05:06最大の課題は何かについて語られています。
00:05:07これらの一つひとつが、完全自律型エージェントを構築するための大きなチャンスとなります。
00:05:11レポートでは、彼らが重視する具体的なKPIや、
00:05:15AIが実際に成果を上げている事例についても掘り下げています。
00:05:16さらに、メールマーケターがAIに本当に求めているものが何なのかも示されています。
00:05:20次世代の大きなエージェント製品を作ろうと考えているビルダーの方は、
00:05:24ぜひこの素晴らしいリソースをチェックしてみてください。
00:05:27下の概要欄に、無料でダウンロードできるリンクを貼っておきます。
00:05:30HubSpot、動画のスポンサーをありがとうございます。
00:05:32さて、長時間実行されるエージェントシステムのための「Harness Engineer」の話に戻りましょう。
00:05:36ハイレベルで見ると、そこから得られた3つの教訓があります。
00:05:39一つ目は、長時間実行タスクのエージェントにおいて、システム設計の肝は
00:05:44「判読可能な環境」を作ることである、という点です。これにより、各サブエージェントやセッションが
00:05:49現在の状況を正確に把握できるようになります。
00:05:50おそらく、環境の判読性を高めるために強制できるワークフローがあるはずです。
00:05:54これについては後ほど詳しく説明します。
00:05:56二つ目は「検証」が不可欠であるということです。
00:05:58より高速なフィードバックループを通じて、エージェントが自らの作業を効果的に検証できるようにすることで、
00:06:03システムのアウトプットを大幅に向上させることができます。
00:06:04そして三つ目は、推論やロジックを時期尚早にラップした専門ツールを詰め込むのではなく、
00:06:08モデルをもっと信頼すべきだということです。
00:06:11モデルには最大級のコンテキストと、ネイティブに理解できる汎用ツールを与え、
00:06:16人間のように探索させるべきです。
00:06:17これら3つのポイントを、各事例を通して一つずつ紐解いていきましょう。
00:06:20まずは、Anthropicによる「長時間実行エージェントのための効果的なハーネス」についてです。
00:06:24彼らは、Claude Code SDKを使用して、Claude.aiのウェブサイトのクローンを作成するといった、
00:06:29非常に時間のかかるタスクのための専用エージェントを構築する実験を行いました。
00:06:32そこで最初に観察された失敗は、まず「エージェントは一度に多くをやりすぎる傾向がある」ということでした。
00:06:37基本的には、アプリ全体を一度に完成させようとしてしまうのです。
00:06:40その結果、実装の途中でモデルのコンテキストが不足し、
00:06:45次のセッションが、機能が中途半端に実装されたり記録されたりした状態で始まることになります。
00:06:49すると、エージェントは何が起きたのかを推測しなければならず、
00:06:52アプリを再び動作させる状態に戻すだけで、多大な時間を費やすことになります。
00:06:55次に観察された失敗は、「エージェントは仕事を途中で完了したと宣言しがちである」ということです。
00:07:00皆さん自身も、何度か経験があるのではないでしょうか。
00:07:02Claude CodeやCursorが、プロジェクトや機能が完了したと主張するものの、
00:07:05実際にテストしてみると、全く動かないという状況です。
00:07:07これらのモデル特有の失敗挙動を解決するために、彼らが取ったアプローチは、
00:07:12まずプロンプトで要求された全機能の基礎となる「初期環境」をセットアップし、
00:07:16エージェントがステップ・バイ・ステップ、機能ごとに進められるように整えることでした。
00:07:20これは、私たちが通常行う「計画」や「PRD（製品要求仕様書）」のアプローチに似ています。
00:07:23二つ目は、各エージェントに対し、目標に向かって段階的に進捗を出しつつ、
00:07:27各セッションの最後には環境をクリーンな状態に保つよう促すことです。
00:07:32彼らが設計したのは、この「2部構成のソリューション」です。
00:07:35まず「初期化エージェント」を用意し、専用のプロンプトを使って
00:07:40「init.sh」スクリプトで初期環境（例えば開発サーバーの起動など）をセットアップさせます。
00:07:45これにより、次のモデルがそれらの心配をする必要がなくなります。
00:07:48さらに、エージェントが行った作業のログを記録する「progress.txt」ファイルと、
00:07:53どのファイルが追加されたかを示す初期のgitコミットを作成させます。
00:07:55その後の各セッションでは「コーディング・エージェント」が段階的に進捗を出し、
00:08:01構造化された更新内容を残すようにします。
00:08:02これらすべての努力は、一つの目的のためにあります。
00:08:07新しいコンテキスト・ウィンドウで作業を開始した際、エージェントが
00:08:11作業の状態を即座に理解できる環境をいかに定義するか、ということです。
00:08:13ワークフローとしては、まず初期化エージェントが環境のセットアップ、
00:08:17あるいは全体計画を追跡・維持するための「ドキュメンテーション・システム」の構築を試みます。
00:08:21彼らが設計した環境では、まず「機能リスト・ドキュメント」を作成し、
00:08:25エージェントがアプリを一度に作ろうとしたり、早まった完了宣言をしたりするのを防ぎます。
00:08:30初期化エージェントにプロジェクトを200以上の機能に分解させ、
00:08:34それらをローカルのJSONファイルに記録させます。そこには各タスクの詳細な仕様と、
00:08:39パス（成功）またはフェイル（失敗）の状態が含まれます。
00:08:41デフォルトでは、すべてのタスクが「フェイル」としてマークされます。
00:08:43これにより、モデルは常にプロジェクト全体の目標と進捗を確認し、
00:08:49最も優先度の高いタスクを選んで次に進まざるを得なくなります。
00:08:50しかし、このワークフローを機能させるには、コード変更後にモデルが
00:08:55環境をクリーンな状態に保つように強制する方法も必要です。実験の結果、
00:08:59最も効果的だったのは、説明的なコミットメッセージと共にgitに進捗をコミットさせ、
00:09:05進捗ファイルに概要を書き込ませることでした。しかし、ドキュメントとコンテキストだけでは
00:09:08不十分です。なぜなら、モデルはデフォルトで、適切なテストをせずに
00:09:13完了とマークしてしまう傾向があるからです。当初、彼らはClaude Codeに対し、
00:09:17コード変更後に必ずユニットテストやAPIテストを行って
00:09:22開発サーバーを確認するようプロンプトを出していました。
00:09:23しかし、それでも機能がエンドツーエンドで動作していないことを見逃すことがよくありました。
00:09:27状況が劇的に変わったのは、Puppeteer MCPやChrome DevToolsのように、
00:09:30モデル自身がエンドツーエンドのテストを行える適切なツールを与えた時でした。
00:09:35これにより、エージェントはコードだけでは分からないバグを特定し、修正できるようになりました。
00:09:39基本的には、初期化エージェントがユーザーの目標を機能リストに分解し、
00:09:43開発サーバーを動かすための「init.sh」と進捗ファイルを用意するという構造です。
00:09:47そうすれば、次に起動するコーディング・エージェントは、機能リストを読んで
00:09:49プロジェクト全体の計画を把握し、優先タスクを拾い上げ、
00:09:53進捗ファイルとログから現状を理解することができます。
00:09:57そして「init.sh」を実行して即座に開発サーバーを立ち上げ、
00:09:59エンドツーエンドのテストで環境がクリーンであることを確認します。これにより、
00:10:04セッションやコンテキスト・ウィンドウが変わっても、全体像を把握し、
00:10:09高速なフィードバックループを回すことが可能になります。
00:10:10OpenAIのブログでも、非常に似たことが語られています。
00:10:13アプリケーションの環境が「判読可能」であることを確認しなければなりません。
00:10:16彼らはリポジトリ全体を「知識のシステム」あるいは「記録の場」として位置づけています。
00:10:19当初は巨大な「agents.md」ファイルを置いていましたが、予想通り失敗しました。
00:10:23一つのエージェントが管理・維持するには、コンテキストがあまりに多すぎたためです。
00:10:27そこで彼らは、適切なドキュメント環境構造を設計し、
00:10:32「agents.md」ファイルを目次として扱うことにしました。
00:10:33アーキテクチャ、設計ドキュメント、実行計画、DBスキーマ、製品仕様、
00:10:37フロントエンド計画、セキュリティなどのドキュメントシステムを構築し、
00:10:42それらの目次を「agents.md」にまとめることで、エージェントが必要な時に
00:10:47関連する情報を取得できるようにしました。
00:10:49これにより情報の「段階的開示」が可能になり、OpenAIはさらに一歩踏み込みました。
00:10:53コードの知識だけでなく、GoogleドキュメントやSlackのメッセージなど、
00:10:58断片化した情報をすべて、リポジトリ内のローカルな成果物（アーティファクト）として
00:11:03データを取り込みました。
00:11:04そうすることでエージェントもそれらを取得できます。エージェントの観点からは、
00:11:09環境内でアクセスできないものは、実質的に存在しないのと同じだからです。
00:11:11しかし、ドキュメントだけでは、エージェントが生成したコードベースの一貫性を完全には保てません。
00:11:16彼らは「不変条件（インバリアント）」を強制するための、プログラムによるワークフローも導入しました。
00:11:20例えば、ドメインアーキテクチャに明示的な横断的境界を設け、
00:11:25カスタムチェック、リンター、構造テストによってそれらのルールを強制しました。
00:11:29これらはgitのpre-commitごとに自動的にトリガーされ、実行されます。
00:11:33伝統的なソフトウェア企業なら、エンジニアが数百人になるまで後回しにするような設計ですが、
00:11:37コーディング・エージェントを利用する上では、初期段階での必須条件となります。
00:11:41こうした境界線の中で、チームやエージェントには、細かく管理したり設計の逸脱を心配したりすることなく、
00:11:46自由にソリューションを表現することを認めています。
00:11:49同時に、彼らはコードベースも大幅に改善しました。
00:11:52例えば、gitのworktreeごとにアプリを起動できるようにし、
00:11:55エージェントが多くの異なるインスタンスを立ち上げて操作できるようにしました。
00:11:57また、エージェントのランタイムにChrome DevToolsプロトコルを組み込み、
00:12:01DOMのスナップショット、スクリーンショット、ナビゲーションによってバグを再現・検証できるようにしました。
00:12:05こうした環境とワークフローが整ったことで、リポジトリはようやく、
00:12:09エージェントが新機能をエンドツーエンドで実装できる最小限の基準を超えたのです。
00:12:13今では、プロンプトを一つ受け取るたびに、エージェントは現在のコードの状態を検証し、
00:12:17報告されたバグを再現し、失敗を示す動画を記録し、
00:12:21修正を実装し、アプリを動かして修正を検証し、解決を示す2つ目の動画を記録して、
00:12:25最終的に変更をマージするというプロセスをこなしています。
00:12:29これら2つの事例は、完全自律型システムに不可欠なハーネス・システムの構築方法について
00:12:32非常に優れた教訓を示しています。
00:12:34一方で、別の教訓もあります。
00:12:36エージェント、特に特定の業界向けのエージェントを作る際、私たちは
00:12:40ドメイン固有のタスクをこなすための「専門ツール」を作ろうとしがちです。
00:12:43しかし、大規模言語モデルは、それらがネイティブに理解している
00:12:47「汎用ツール」を使用したほうが、ほぼ常にうまく機能するということが分かりました。
00:12:49Vercelは、タスクをSQLに変換するエージェントをどのように再設計したかについての素晴らしい記事を公開しました。
00:12:53彼らは何ヶ月もかけて、専門ツールを多用したプロンプトエンジニアリングと綿密なコンテキスト管理を備えた、
00:12:58高度で複雑な内部「Text-to-SQL」エージェントを構築しました。
00:13:02しかし、多くの人が経験しているように、そうしたシステムはある程度は動くものの、非常に脆く、
00:13:06低速で、絶え間ないメンテナンスを必要としました。
00:13:09新しい例外的なケースが発生するたびに、エージェントに新しいプロンプトを注入しなければならなかったからです。
00:13:12ところがその後、彼らが試した一つのことが、その後の軌道を完全に変えました。
00:13:15彼らはエージェントから専門ツールのほとんどを削除し、単一の「バッチコマンドツール」へと削ぎ落としたのです。
00:13:20このはるかにシンプルなアーキテクチャによって、エージェントの動作速度は3.5倍になり、
00:13:25トークン消費量は37%削減され、成功率は80%から100%に向上しました。
00:13:30同様の教訓はAnthropicのチームからも共有されています。彼らも、
00:13:34専門的な検索・リンク・実行ツールを揃える代わりに、一つの「バッチツール」を用意しました。
00:13:38そこでは grep、tail、npm、npm run lint などを実行できます。
00:13:41根本的には、大規模言語モデルにとって、何十億ものトークンで学習された
00:13:45コードネイティブなツールのほうが、生成しなければならない
00:13:49オーダーメイドのツール呼び出し用JSONよりも、はるかになじみがあるからだと思います。
00:13:51これについては、先週公開した「プログラムによるツール呼び出し」の動画でもお話ししました。
00:13:55ここでも同じ基本原理が働いていると信じています。ただし、こうしたシンプルなアーキテクチャの土台となるのは、
00:13:59やはり優れたコンテキストとドキュメント環境であり、モデルが汎用ツールを使って
00:14:05段階的にコンテキストを取得できることが重要です。
00:14:06これはOpenClawのケースでも同様です。
00:14:09OpenClawが非常に興味深い理由の一つは、驚くほどシンプルながら効果的な
00:14:13コンテキスト環境を備えていることです。
00:14:15彼らはコア情報を保存するためのドキュメントリストを持っており、この土台があることで、
00:14:18ファイルの読み書き、編集、バッチコマンドの実行、メッセージ送信といった
00:14:23最も基本的なツールだけで動作させることができています。
00:14:24残りの可能性は、エージェントに関連するコンテキストを取得するための環境と、
00:14:29機能を拡張するための大規模なスキルライブラリを与えることから生まれます。
00:14:31以上が、長時間実行される複雑なエージェントのための「Harness Engineer」に関する3つの実践的な学びです。
00:14:35一つ、判読可能なコンテキスト環境を整え、各セッションが効果的に情報を取得できるようにすること。
00:14:36二つ、モデルが自らの作業を効果的に検証し、高速なフィードバックループを回せるように適切なワークフローとツールを整えること。
00:14:41三つ、モデルがネイティブに理解できる汎用ツールを使い、エージェントを信頼すること。
00:14:46もし興味があれば、これらの学びをどのように開発ライフサイクルプロセスに落とし込んでいるかについて、
00:14:50さらに詳しく共有したいと思います。
00:14:54AI Builder Clubでは、「Vibe Coding」や実用的なエージェント構築に関するコースや
00:14:58解説を用意しています。
00:15:02また、毎週私や業界のエキスパートが最新の実践的な学びを共有しています。
00:15:03私が毎日学んでいることに興味がある方は、ぜひ下のリンクから
00:15:08コミュニティに参加してください。
00:15:12今回の動画を楽しんでいただけたなら幸いです。
00:15:13ありがとうございました。また次回お会いしましょう。
00:15:14（終了）