※本記事は、YC(Y Combinator)が主催するイベント「YC Paper Club」における発表「Why The Harness Matters More Than The Model」の内容を基に作成されています。動画の詳細情報は https://www.youtube.com/watch?v=n9xKblqyQ28 でご覧いただけます。本記事では、当該動画の内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。
本発表には、以下の登壇者が参加しています。
- Seth Karten氏:Princeton大学の研究者であり、Prime Intellectに所属。自己改善型のRLM(Recursive Language Model)ハーネスである「Prime Agent」の開発者として登壇。
- Jon Saad-Falcon氏:Stanford大学において、共同研究者Ivanka Orion氏、指導教員Hazy氏およびChristopher Ré氏とともに、オンデバイス型パーソナルAIプロジェクト「OpenJarvis」を発表。
- Josh France氏:YC Labsの責任者。YCの内製エージェントハーネス「QM」について登壇。
- Regan Bell氏:Josh France氏とともに「QM」の開発チームとして登壇。
なお、当初登壇予定であったBen氏は、当日体調不良のため欠席しています。
次回のYC Paper Club「Alternative Compute Paradigms」への参加登録は、以下のページから可能です。 https://events.ycombinator.com/yc-pap...
Y Combinatorへの応募: https://www.ycombinator.com/apply スタートアップでの就業: https://www.ycombinator.com/jobs
1. オープニングとハーネスの重要性
1.1 導入とハーネス批判への反論
MC: まず今日は、新しくなったYC Paper Clubの見た目についてひと言お話ししたいと思います。実はこれは、YCのデザイン責任者であるEvに、私が何気なく思いつきを口にしただけだったのですが、二日後にはこんなに素晴らしいデザインを持ってきてくれたんです。Ev、後ろにいますよね、拍手をお願いします。本当に素晴らしい出来だと思います。
MC: さて、本題です。今夜のテーマは「なぜハーネスなのか」ということです。ハーネスなんて所詮ラッパーじゃないか、スキャフォールディングに過ぎない、プロンプトエンジニアリングの延長でしかない、という声があります。わざわざ一晩かけて語るほどの価値があるのか、と思う方もいるでしょう。実際、一か月ほど前にあったReddit上の投稿を見つけたのですが、これはかなり辛辣なもので、「こうしたプロンプトエンジニアリングがトップティアの機械学習カンファレンスに値するとは思えない」という趣旨のコメントがありました。もう一つ紹介したいのは「コンテキストエンジニアリングは研究の対象ではない」という意見です。つまり、ハーネスは長らく研究として軽視されてきた、という認識が業界にあるわけです。
MC: しかし実際のデータを見ると話は違います。私たちの手元にある結果では、ハーネス1とハーネス2の差だけで18%ものスコア向上が確認されています。そして後ほどSethが話してくれますが、これはARC-AGIを解けるか解けないかを分ける決定的な違いにもなっています。METERが出している有名なグラフ、つまりリリース日とエージェントが自律的に稼働し続けられる時間の関係を示したあのグラフを見ても、進歩の大部分はハーネスの改善によってもたらされていると私は考えています。ですので私は今のフェーズを、ハーネス自体が自己改善をしない「静的ハーネス時代」と、直近半年ほどで急速に広がってきた「自己改善型ハーネス時代」とに区分して捉えています。この後、両方の系譜をたどっていきます。
1.2 テスト時経験活用の仮説
MC: このプロットは、Trajectoryという会社のCEOのプレゼンテーションで見かけたもので、私は非常に気に入って引用させてもらっています。彼が話していたのは、私たちはずっとパープレキシティを測り続けていて、これはある程度IQのようなものと相関している、つまりモデルがどれだけ賢いかを示す指標だとされているけれど、私たちはひたすらこの「知能・IQ軸」を押し上げることばかりに注力していて、テスト時に生成される大量の経験をほとんど活用できていない、ということです。新しいドメインに直面しても、そこから素早く適応する仕組みが十分に整っていない、というのが彼の指摘でした。
MC: これは私自身の以前の実験とも重なります。最初期のYC Paper Clubで私が行った実験なのですが、オンラインでサンプル数を増やしていったときに、バッチサイズ1という最小単位からどうやって学習させるかを検証しました。結果として、私たちにはそのための明確な構造がまだ存在していないという結論に至りました。まずICL(インコンテキスト学習)を使いますが、これは大体40〜50例ほど読み込ませた時点で飽和してしまい、それ以上サンプルを与えてもバリデーションの成績は一切改善しません。そこから先に進むには、LoRAの小さいランクへ、それでも足りなければLoRAの大きいランクへ、最終的にはSFT(教師ありファインチューニング)へと、段階的に異なる学習手法を切り替えていく必要があります。私はこれを、モデルの学習手続きがこれだけバラバラに存在していること自体がむしろ奇妙だと感じており、まさにここにこそハーネスが輝く余地があると考えています。
1.3 ARC-AGIとハーネスの効果
MC: ARC-AGIというベンチマークが本質的に測ろうとしているのは、新しい問題、新しい分布に対してどれだけ速く適応し、その上でうまく成果を出せるかという点です。私たちはARC-AGIの2026年冬バッチにも関わっており、Gregの取り組みを手伝いました。各ゲームが前のゲームから独立したスキルになるよう、つまり流動性知能(fluid intelligence)を純粋に測定できるよう、直交性を保つための設計にどれほどの検討と配慮が注がれているかを間近で見てきました。
MC: 象徴的なデータをお見せします。Claude Opusは、Gregとフランソワ・シャレ(Chalet)以外は誰もアクセスできない、非公開のプライベートホールドアウトセットで初めて検証されたモデルの一つでした。その際のスコアは30%にとどまりました。ところが、研究に値しないと揶揄されがちなただのラッパー、スキャフォールディングを加えただけで、スコアは95%まで到達し、さらにNVIDIAのAVOというシステムに至っては100%を達成しています。Prime AgentとNVIDIAのこの成果は、どちらもごく最近発表されたばかりのものです。同一のモデル重みでありながら、ハーネスの違いだけでこれほどの差が生まれるという事実は、私にとって非常に説得力のある証拠です。
1.4 自作エージェント群での研究運用
MC: 個人的な体験もお話しします。Karpathyが3月にauto researcherというプロジェクトを公開したとき、私はそれをフォークして触っていました。もともとは進行状況を見るための簡単なユーザーインターフェースを作りたかっただけなのですが、気づけば意図せずハーネスをまるごと構築してしまっていました。
MC: その仕組みはこうです。まず「目的」を一つ指定します。実際に私が与えた例として、「diffusion LMはARLM(自己回帰型言語モデル)に勝てない、しかしdiffusion LMはGPUあたりの演算密度が非常に高いため、これを多数のシャードに分割してアンサンブルすれば、集約した結果としてARLMより良い成績が出せるのではないか」という仮説がありました。この目的を、私が抱えているエージェント群、いわば「スワーム」に与え、いくつかの種となるアイデアも渡します。たとえばアンサンブルのシャード数を100倍、10倍、5倍など様々に変えて試すよう指示し、評価指標としてGSM8KとGPT-2規模のセットアップを指定する、といった具合です。
MC: そこから、類似の論文やGitHubリポジトリを調べる「スコーピングエージェント」が動き出し、それを「Chris Ray」という名のPI(研究責任者)エージェントに渡します。Chris Rayはさらに「John Southcan」という名の研究エージェントに作業を引き継ぎ、研究エージェントが実際に手を動かして進めていきます。そして適宜「カウンシル」に助言を求める段階があり、そこで私とYasoがフィードバックを返します。フィードバックを踏まえてさらに作業が進み、準備が整ったところでChris Rayが1時間おきくらいに進捗を催促し続け、最終的に「著者エージェント」に引き渡されます。著者エージェントはアイデアを一旦凍結し、アブレーション実験を書き始め、論文執筆に移ります。
MC: このスコーピングエージェントから著者エージェントまでの流れ全体を見渡せる「コックピット」も用意していて、Tailscaleを使うことでどこからでもこのURLにアクセスし、進捗を確認したり、その場で対話したりすることができます。全体の構築が完了すると、メールで更新通知も届くようになっています。実際にこの仕組みが生成した論文を私は読みましたが、内容は本当にしっかりしています。3月や4月の初期はまだ精度が低かったのですが、5月頃には目に見えて改善していきました。今では8つのアイデアを8台のH100ノード(各ノードにH100を8基搭載)にそれぞれ割り当てて走らせ続け、私はときどき確認しに行っては論文を受け取る、というだけの運用になっています。
MC: 私はこの構築作業に膨大な時間をかけたわけではありません。それでも、これが私の研究活動、少なくとも初期のアイデア出しの大部分を占めるやり方になっています。6つほどの異なるアイデアを与えて、あとは放置して走らせておくだけです。まったく同じ重みファイルを使っているにもかかわらず、ハーネスの違いだけでこれほどのことができるようになったというのは、私自身、驚くべきことだと感じています。
2. ハーネスの歴史
2.1 静的ハーネスの黎明期
MC: 今日のこの発表のために、私は週末を使って古典的な文献を一通り読み直しました。Self-Refineから、Reflection、Voyager、そしてToolformerに至るまで、一通り目を通しています。せっかくなので、5分間でハーネスの歴史をたどる、私なりの説明を試みたいと思います。これは今AIの世界に入ってきた人たちがあまり持っていない文脈だと思うので、重要だと感じています。ただ、時系列順には並べません。そのほうが分かりやすいからです。かなり多くの論文を飛ばしますし、荒く粗視化して説明することになりますので、その点はご容赦ください。
MC: まず最初のハーネスは、2019年2月のGPT-2です。あるのはただの「while文」による終端シーケンスのループだけで、そこにtop-pサンプリングを組み合わせ、環境があるだけです。これがハーネスの全体像でした。ツール呼び出しもなく、スキルもなく、他に何もありません。これが私の言う「V0ハーネス」です。GSM8Kの例で考えてみると、システムプロンプトには「あなたは数学の教師です」と書かれているだけで、これは当時よくあった「ペルソナ」の付与です。そこに「スージーは5ドル持っていて、3ドル使いました。今いくら残っていますか」というコンテキストが与えられ、思考の連鎖(chain of thought)は一切ありません。出力はただ「####」に続いて答えの数字、そして終了トークンが並ぶだけです。この「####」の後に出てくる内容を見て、正解なら+1、不正解なら-1というスコアをつける、それがGSM8Kの評価形式でした。
MC: そこから過去6年間の進化というのは、基本的にはこの「静的ハーネス」に対してどれだけ多くの機能を追加していくか、という歴史でした。まず、コンテキストにいくつかの例を戻してあげたらどうか、というアイデアが出てきます。「こういう例があって、こう答えればいい」と示せば、前の例から学んで理解が深まるはずだ、というわけです。これが2020年7月のFew-Shot Learnersの論文です。次に登場したのがChain of Thoughtです。「####」に続く数字を直接予測するのは難しいかもしれない、それならば計算の論理をもっと多くのトークンに分散させて、答えの「2」に到達するように訓練しよう、というアイデアです。これは出力の生成方法そのものを変える、いわば出力空間・行動空間の革新でした。
2.2 ツールとメモリの獲得
MC: ここからToolformerとWebGPTが登場します。実際にはWebGPTが先に発表され、その後Toolformerが出てきました。これは、モデルにツールを与えるというアイデアです。ツールというのは、実際には単にいくつかの項目を指定したJSONオブジェクトに過ぎません。例えば「引き算」を考えてみると、モデル自身の重みの中で5-3を計算する代わりに、単純にPythonを呼び出して「sub(5,3)」と実行すれば、答えの2が返ってくる、というものです。これらのツールはすべてシステムプロンプトの中で列挙して見せることができ、これがツールという概念の起源になっています。
MC: 次にMemGPTが登場します。これが実現した最も面白いことの一つは、自分自身のコンテキストを読み書きできるようにしたことです。それまでは、コンテキストにひたすら追記していくことしかできませんでした。それに対して、コンテキストそのものに対して作成・読み取り・更新・削除、つまりCRUD操作を与えたらどうか、という発想が生まれ、これを「メモリ」という一つの独立した区画として切り出し、更新できるようにしました。
MC: そしてVoyagerです。このアイデアは、ツールを持っているのはいいが、タスクを達成するためにこれらのツールを組み合わせて連鎖させ、それを学習して、後でシステムプロンプトに蒸留して永続的に学べるようにしたい、というものでした。ここからスキルという概念が生まれます。彼らはこれをMinecraft上で実装しました。とても面白い論文で、これが今私たちが「スキル」と呼んでいるものの原型です。具体的には「skills.md」というファイルがあり、そこにスキルの名前が書かれていて、検索できるようになっており、その手順が記されている、という仕組みです。
2.3 自己改善ループの登場
MC: 続いてInterCodeというアイデアが出てきます。これも出力空間の革新の一種ですが、もしコードそのものを出力できるなら、その場でツールやスキルを作り出せるということになります。正直に言うと、これはツールなのかスキルなのか、私自身いまだに判断がついていません。ツールというのは技術的にはAPIのはずですが、関数を出力するのはツールなのかスキルなのか、という区別が曖昧なのです。
MC: そしてReAct、その後にSelf-Refine、Reflectionが続きます。ここでの核心的なアイデアは、異なる役割を持つ複数のエージェントがいて、それらが互いにコンテキスト上で自己改善を助け合えるなら、どんどん賢くなっていけるはずだ、というものです。まず何らかの行動を取ります。私の例では、3と5を取り違えてしまったとします。それを内部の評価者に送り、「これは正しいか」と尋ねます。「いいえ、これは正しく見えません」と返ってくれば、そこでループを繰り返すか、あるいは実際の環境から報酬信号を取得しに行くことができます。Reflectionのアイデアはここで登場し、「これら二つを取り違えているので、戻ってやり直せば結果を改善できます」と教えてくれます。これは、エージェントが自分自身の出力を振り返り、改善するという、最初期のマルチエージェント的な発想の一つです。
MC: マルチエージェントという発想はさらに先へ進みます。ツールの一つとして、サブエージェントの集合を生成できるようにする、というものです。これらは永続的なセッションの中で存在し続け、私はいつでもそれらと対話することができ、サブエージェントのリストを持つことになります。必要に応じてそれらを呼び出したり、新たに追加したりできます。そしてRLM(Recursive Language Model)はさらに一歩進んで、これを再帰的に行えるようにしました。RLMのクエリという概念が登場し、私はこのRLMクエリを再帰的に呼び出し続けることで、より大きなクラスの問題を解決できます。末端では、必要なときにLLMクエリを呼び出してそのLLMエージェントを生成することもできます。そして、これらすべてを統括するメインのオーケストレーターエージェントが存在します。これが私の言う「ハーネスv1」であり、この全体が「静的ハーネス」に分類されるものです。システムプロンプト自体を更新したり、ハーネス自体を更新したりすることはしていません。
MC: ここで、こうしたすべてを実現させてくれているGitのスタック、つまりGStackにも感謝を伝えたいと思います。これのおかげで私たちはこの一連のことができています。Garyありがとうございます、GStack大好きです。他にも触れておくべき重要な要素があります。まとめると、これがv1のハーネスの全体像です。エージェントの仕様、システムプロンプトがあり、「何ターンまで許可するか」「ツール呼び出しは何回まで許可するか」を指定します。無限には許可したくないからです。ツールのリストを指定し、スキルのリストを指定し、サブエージェントのリストを指定して、それをループの中に入れる、これがv1の大部分です。これはSlackチャンネルの中でのプロンプトによって起動されることもありますし(これは後ほどQMの話で聞くことになります、私自身も毎日使っています)、あるいはcronによって1時間おきに起きて作業を判断する、という形もあります。セッション管理があり、ループがあり、コンテキストのコンパイルという処理があります。つまりこれらすべてをLLM呼び出しの中に投入し、行動を返してもらい、必要に応じてツールを呼び出し、その結果をコンテキストに追記する、という一連の流れです。これが基本的なハーネスv1です。
2.4 メタハーネスへの進化
MC: ここから面白い部分に入ります。今、非常に多くの進展が見られているのが、ハーネス自体に学習させるという発想です。システムプロンプトを学習させるか、あるいはハーネス自体を学習させるか、これは非常に奇妙な感覚を伴うものです。有名な例の一つとして、実は今夜、開発者本人を呼んで話してもらいたかったのですが、彼らはちょうど今夜サンフランシスコで150人規模のDSPyミートアップを開催していて来られませんでした。以前彼らとポッドキャストで話したことがあり、本当に素晴らしいコミュニティです。これはDSPyというもので、Demonstrate、Search、Predictの略です。彼らのアイデアは、小さな訓練用の例のセットを用意して、そこから最適なシステムプロンプトを学習する、というものです。この過程を繰り返し繰り返し反復していきます。この過程では逆伝播はできませんが、いわゆる「遺伝的プログラミング」と呼べるような手法を使うことができます。候補を見つけ、候補同士を統合し、何らかの統合規則を用いて評価し、結果を見て、また作業を続ける、という流れです。これは基本的に、システムプロンプト自体に対するCRUD操作を私に与えてくれるものであり、任意のシステムプロンプトを選べるようにしてくれます。
MC: そしてDarwin machinesは、さらに一歩進みます。システムプロンプトを変更できるだけでなく、ハーネス自体、つまり実際に動いているハーネスのコードそのものを変更できるようにするのです。具体的には、ハーネスとシステムプロンプトの組み合わせからなる、多数の異なるエージェントのアーカイブが存在すると考えてください。そこからサンプリングを行い、それらを何らかの適応度関数(フィットネス関数)を通して評価し、その結果を再びアーカイブの状態に反映させます。ここで「自己修正」の部分を一つ説明が飛んでしまいましたが、実際にはエージェント自身が自分のハーネスを修正できるような「メタハーネス」が存在し、これによってエージェントは別のハーネスへと自らを変化させることができ、そのループがぐるぐると回り続けることで、時間をかけてより優れたエージェントへと成長していきます。
MC: つまり、メインのハーネスであるメタハーネスの役割は、ハーネスそのものを生み出すことにある、というわけです。これは実に「メタ」な発想です。ここで対象になっているのは、マルチエージェント構成やコンテキストのコンパイルといった出力空間全体であり、これらすべてに対してCRUD操作を許可することになります。ここで表示されている緑色の部分はすべて、ハーネスのコード、各エージェントのメタプロンプトやシステムプロンプト、エージェントの数など、それらすべてに対して増え続けるCRUD操作を意味しています。こうして、このメタハーネスは時間をかけて成長していくことになります。
MC: そして、この論文の主著者の一人が実は今夜ここに来てくれています。わざわざ車で来てくれて、とても嬉しく思っています。彼が「Continual Harness」について、より詳しく話してくれるはずです。私が特に気に入っているのは、彼らがメモリの分類にさらに色をつけている点で、「履歴(history)」という要素を追加しています。この記憶の分け方については、彼が後でもっと詳しく説明してくれると思います。しかし私が一番興奮しているのは、古典的な強化学習を専門とする方々にとって(Robertが後ろにいますね、彼なら絶対に気に入るはずです)、Daggerスタイルのオンライン学習です。これは、少数の学習例から実際にモデルの重みファイル自体を更新する、つまりテスト時に重みそのものを訓練するというアイデアで、私はこれが今後取り組むべき非常に重要な研究方向の一つだと考えています。以上が、この歴史部分の全体像です。
3. Prime Agent(Seth)の設計と実験
3.1 設計思想とアーキテクチャ
Seth: 皆さん、今夜はお集まりいただきありがとうございます。私はSethです。今夜は「Prime Agent」という、自己改善型のRLM(Recursive Language Model)ハーネスについて発表させていただきます。私がここで皆さんに伝えたいのは、ハーネスをどう構築すべきかについて、非常に第一原理的なアプローチで考えてほしいということです。
Seth: まず基本から始めます。生のLLMそのものを考えてみると、それはただの逐次処理装置に過ぎません。固定された重みを持ち、可視のコンテキストがあり、トークンを受け取ってトークンを出力し、次の判断を下している、それだけです。私たちは最近このようにLLMを捉えることはあまりありませんが。実際には、モデルがアクセスできるファイルの集合があり、使えるプログラムやツールを与え、他のLLMのセッションにメッセージを送ったり、サブエージェントを作成したりすることさえできます。しかし基本に立てば、それはトークンが入って、トークンが出てくる、ニューラルネットワークが予測を行っているだけのものです。ハーネスとは、このLLMと外の世界との間にある層であり、永続的な状態、ツール、そして計算能力を付加するものです。
Seth: これはPrime Agentの構造を示した図です。人間の視点から説明します。まずPrime Agentを開きます、ちょうどClaude CodeやCodex、Piなどを開くのと同じ感覚です。すると「エージェントビュー」に入ります。ここは自分が並行して動かしているすべてのエージェントの概観であり、それぞれについて非常にタイトな要約が表示されています。そこから一つを選んで入っていくと、「ルートセッション」に到達します。このルートセッションは基本的にプロジェクトのオーケストレーターであり、その下にある様々なサブエージェントを統括しています。サブエージェントを起動するようにわざわざ指示する必要はありません。有用だと判断すれば自らサブエージェントを活用します。これらはすべてプログラム的に呼び出されており、これはRLM(Recursive Language Model)の原理に基づいています。すべてがこのIPythonシェルの中にあり、ツール、メモリ、サブエージェント、それらをまとめて扱っています。さらに調整をしやすくするために、こうしたメッセージングの仕組みを外部にも公開しています。これによって、これらすべてを管理でき、これらのエージェントは自分の環境、つまりパソコン上のプログラムやファイルと直接やり取りすることも、オートリサーチのためにH200ノードクラスタを丸ごと動かすこともできます。
Seth: これらの各エージェントは、自分のパソコン上で動く永続的なデーモンによって裏付けられています。これはつまり、ラップトップを閉じたり、セッションをControl+Cで中断したりしても、バックグラウンドで動作が継続する、という仕組みです。実際に停止させたい場合には、明示的にセッションを止める操作が必要です。それに加えて、Continual Harnessから継承した機能もいくつか公開しています。これは、私たちが挙げたすべての構成要素、つまりメモリやスキル、サブエージェント、そして永続的な状態や自分自身のシステムプロンプトに対して、ライブでCRUD操作を提供できる、というものです。
3.2 コンテキスト管理の比喩
Seth: 私が積み重ねてきたこのコンテキストの全体像をどう考えているかというと、L1、L2、L3といった、キャッシュのような階層構造としてイメージしています。つまり、どの情報が最もアクセスしやすいか、という観点です。最も速く、常に利用可能な情報とは何か、モデルが最も素早く取得できる情報とは何かと考えると、それはモデルの重み自体です。誰もがすべての情報をモデルの重みの中に入れたいと考えます。しかし、すべての情報をそこに入れることはできません。なぜなら、更新のたびにファインチューニングをするのは非常にコストが高いからです。そこで私たちは「アクティブな入力コンテキスト」というものを持っています。ここでは入力に非常に多くのトークンを使い、以前見たようなインコンテキストの例をいくつか持たせて、様々な能力を追加していくことができますが、ある時点でコンテキストは限界に達します。
Seth: そこで、今でも最小限主義のハーネスを望む人々にさえ使われている、最も古い形のハーネスの一つが「コンパクション」です。コンパクションとは、エージェントが自分自身のコンテキスト履歴を要約する、非常に汎用的なツールであり、これによってコンテキストの長さという作業窓を越えて先に進むことができます。
Seth: アクティブなコンテキストから直接の入出力を越えたところ、L2からL3にかけての範囲を考えると、L3はファイルシステムを扱うようなもので、メインメモリの読み書きに近い、より「ディスパッチ」的な状態です。L2はというと、アクティブなコンテキストとファイルシステムの間くらいに位置するもので、これは例えば「ライブなリップル」であり、Pythonを直接、まるでJupyterノートブックのIPythonシェルのように動かすようなものです。そこにあるすべての変数はRAMに直接保存され、エージェントはそれらをプログラム的に操作し、そこにある情報に対して様々なプログラムを直接実行できます。これはコンテキストに直接投入するよりもトークンを大幅に節約できます。またサブエージェントの作成も同様の考え方で、特定の情報セットをタスクとして与えて何らかの操作を実行させ、最後に結果だけを報告してもらうことで、コンテキストを節約できるのです。
Seth: ここで面白いのは、先ほど触れたアクティブコンテキストのコンパクションの話です。コンテキストの履歴があり、これは時間とともに更新されていくものなので、継続して活用することができます。しかし、それを越えたところでは、CRUDについて話しましたが、単なる作成や読み取りを越えて、どうやって更新や削除を行うのか、コンテキストの限界を越えたところでの状態の更新をどう扱うのかを考える必要があります。私はこれを、リップルにおける「エージェント的ガベージコレクション」と捉えていて、状態にある変数や、使われうるサブエージェントをきちんと片付けていく作業だと考えています。これによって、私のパソコンのRAMが毎日クラッシュすることのないようにしています。それに加えて、システムに保存されているスキルやメモリ、プロンプトを更新・削除するという「リファインメント」の概念があります。これも同様に、ハードディスクの容量が尽きてクラッシュしないようにするためのものだと考えられます。つまりこれは、「これをどう表現するか、そしてそれを時間とともにどう改訂していくか」という関係性そのものです。
Seth: もう一つ私が好んでいる視点があります。ハーネスというものは、私たちが作り出しているある種の「エージェント的オペレーティングシステム」に向かっていると考えていて、これをより比喩的に捉えるならば、生のLLMというのはチューリングマシンに近いものです。ティッカーテープのようなものがあり、そこに一連の命令が入ってきて、何らかの処理を行って出力していく、というものです。しかしハーネスを見ると、これはむしろフォン・ノイマン型の計算機に近い姿をしています。外部メモリに対して読み書きの操作ができるようになっており、これによってチューリングマシン単体では表現できなかった、別のクラスの問題を扱えるようになるのです。
3.3 表現力と永続サブエージェント
Seth: では、良いハーネスをどう構築するかという話に移ります。ハーネスは、想像できる限り最も表現力の高いものであってほしいと考えています。データフライホイールが働き、モデル自身が改善を担えるようになる以前の初期のハーネスの多くは、非常に具体的でした。「計画し、実行し、批評する」という決まった手順を明示的に踏ませる必要がありました。しかし今、モデルはそれを自らできるようになっています。私たちが明示的に課さなければならないようなReActループのようなものは、もはや必要ないと考えることができます。モデルは自然にそれを見出しているのです。しかし、モデルがまだ自分では見出せていないのは、コンパクトを呼び出すための表現力、プログラムを実行するためにPythonのリップルを持つこと、サブエージェントをプログラム的に生成しアクセスし、異なるフィードバックの仕組みを持つための能力です。これらはモデルが制御する「表現力の機能」であり、そのうちの一つを取り除けば、モデルはそれができなくなってしまいます。
Seth: 私たちがこれをどう管理しているかについてですが、皆さんも私の共同著者であるAlexによるRLM論文はよくご存じだと思います、素晴らしい仕事です。私たちがRLM論文からさらに進めているのは、サブエージェントを永続的なサブセッションとして考えるという点です。親のセッションは新しいRLMサブエージェントを立ち上げることができ、それぞれが独立して起動されます。それらは何らかのタスクを実行し、完了すると何らかの終了状態として親セッションに報告します。この後、これらは「アイドル」状態になります。それでもRAMの中では動作を続けており、親セッションはいつでもそのサブエージェントの一つにメッセージを送って作業の継続を指示できます。そしてそのサブエージェントは、それまでに構築してきた良質なコンテキストをそのまま保持しているので、情報を見失ったり、以前開発した情報を再利用しなければならなくなったりすることはありません。そして当然、RAMを大量に消費し続けたくはないので、これらは非アクティブな状態にオフロードすることもでき、その状態からでも、この永続サブエージェントの仕組みの中でメッセージを送ることでいつでも呼び戻すことができます。
Seth: 私は先ほど、Continual Harnessについても少し触れました。これは私自身の以前の論文の一つで、ハーネスの状態全体をCRUDする、という考え方を扱っています。これは私たちのコーディングエージェントに持たせたいもう一つの機能で、これまでの履歴すべてを活用する、というものです。イメージとしては、いくつかの行動と結果、あるいは各ターンで何が起きたかという軌跡の集合があり、その情報すべてをエージェントが活用できるようにして、未来のハーネスがどうあるべきかを更新できるようにしたい、ということです。システムプロンプトを変更する必要があるか、新しいスキルを作る必要があるか。スキルというのは、私は何らかの特定の目標を達成するための指示のセット、あるいはプログラムのようなものだと考えています。メモリというのは、重要な事柄についての長期的な保存領域であり、それに加えて、先ほど話したサブエージェントの仕様も、この非常に永続的な仕組みの中に含まれます。後で再利用したいサブエージェントがあったかどうか、そのコンテキストが有用だったかどうかを判断し、こうした反省やリファインメントを行う能力を持つことは、モデルにとって非常に強力です。今のモデルはまだこれが完璧にはできていませんが、これはまさに、現在のモデルが持つ能力よりも少しだけ優れたものになるようにハーネスを構築したい、という目標の一つです。そうすることで、その推論の軌跡を得て、次の世代のモデルの反復に活用でき、モデルがハーネスを扱いこなし、自分自身をより高いパフォーマンスへとブートストラップしていけるようになります。
Seth: Prime Agentに搭載している機能の中で最も気に入っているものの一つが、最初にこのプロジェクトに取り組んでいた頃から追加していた、任意の二つのエージェント間でメッセージを送り合える機能です。これは親、子、兄弟といった、いわば「核家族」のような関係の範囲内で機能します。これを実装した理由は、私自身が、あらゆる作業を五方向、いや五十億の方向に分散させてやらせている多数のエージェントをどう管理するのが最善か、ということを常に考えていたからです。それらが直接コンテキストを共有し合い、調整し合えるようになれば、はるかに良くなるはずだと考えました。そしてこれは、典型的なソフトウェアエンジニアリングや長期水平線のジョブにおいても非常に効果的であることが分かりました。
3.4 長期水平線評価への問題意識
Seth: 私たちがハーネスを設計する際に最後に検討したのは、長期水平線(long horizon)における性能についてです。私はいくつかのジョブを実行したいと思ったとき、その間ずっとエージェントの様子を見守っていたくはありません。準備ができて確認したいときにチェックインし、何が起きているかを見る、という形にしたいのです。これは、私たちが目にしている多くの評価において、あまり見られていない視点だと感じています。多くの場合、モデルを十分な時間動かさずに「このモデルはこの予算量で作業が止まった」と言い、一方で別のモデルはより多くの予算を使い続けた、という比較がされます。しかしまず第一に、そもそも同じ固定された支出量でモデルを比較していないという問題があります。第二に、それによって見落としている性能を隠してしまっている可能性もあります。私が長期水平線の性能評価を見るときの視点は、「実務的なプラトー」がどこにあるかを見ることです。テスト時のトークンをどれだけ多く投入しても、増分的な利得しか得られなくなる地点はどこか、という問いです。これから、私たちがどのようにPrime Agentのデザイン哲学を作り上げたかについて、いくつかの実験をお見せします。テスト時スケーリングとその結果、そして長いコンテキストで作業しているリップルにおける情報管理が実際に役立っているのかどうか、なぜ役立つのか、そして本当に超長期水平線のタスク、つまり複数日にわたるような作業をどう持続させるか、そして週単位あるいはそれ以上続くような設定でリファインメントが実際に何をしているのか、といった点についてお話しします。
3.5 ARC-AGI実験の試行錯誤
Seth: これはおそらく皆さんもすでに見たことのある結果だと思いますが、元の結果には含めていなかった追加のデータポイントを一つ加えました。これは異なるハーネス間の比較のために追加したものです。私たちはARC-AGIに取り組みました。人々が今どんな評価を重視しているのか探していて、「ARC-AGIをやるべきだ」という結論に至りました。実は以前、Continual Harnessでいくつか結果を出していて、Gemini Flash、いえ失礼、Gemini Pearlで20%という結果を得ていました。ですので、少なくとも20%は取れるはずだと考えていました。この、ARC-AGI向けに構造化されていない私たちの汎用ハーネスがそれでもうまく機能したことは、多くの人にとって興味深いと感じられているようです。
Seth: そこで私はオンラインで調べて、良いシステムプロンプトを見つける必要があると考えました。情報を失うことがないようにしたかったからです。すると「Prolong」という別のコミュニティのリーダーボードを見つけ、そのシステムプロンプトをそのまま流用しようと考えました。他の部分は無視して、そのシステムプロンプトだけをそのままPrime Agentに投入したのです。すると実行結果は、最初の一回目でなんと99.9%を記録しました。私は「なんてことだ」と驚いたのですが、ログを見返してみると、実はズルをしていたことに気づきました。そこで「よし、ちゃんとしたサンドボックス環境を整備しなければ」と考え、さらに一日かけて環境をきちんと構築し直しました。そしてやり直したところ、今度はGPT-Soulで78%という結果になりました。「これは素晴らしい結果になりそうだ」と思いました。
Seth: そこから他のモデルとも比較してみようということになりました。プロンプト自体は、「世界モデルを使ってARC AGI 3を解いてください、取れる行動はこちらです」という汎用的なものと、Prime Agent用の一般的なシステムプロンプト、つまり「リップルを使えます、サブエージェントを呼び出せます、プログラム的に操作できます」という内容を組み合わせただけのものです。実際にトレースを確認してみると、様々なコーディング呼び出しを行って、異なるシナリオを検証したり、画像を解析して画像処理を行ったりと、リップルを活用しながら合理的な推論を行っているように見える、非常に興味深い挙動が多数見られました。
Seth: 他のモデルでも試しました。GPT-teroでは25.7%という結果で、これも非常に良い結果です。この結果を見ると、この一週間前くらいにOpenAIが出していた結果と比べても、評価を行う際にはハーネスが非常に重要であることが分かります。私たちはResponses APIを使用してこの結果を得ています。Teraでは実行を完了まで走らせることができなかったのですが、それでも比較すると非常に良好な結果が得られました。そして、GPT-Soul Extra Highを既に上回るような結果も出ていて、これには驚かされました。
Seth: そしてOpusを試したところ、95.5%というスコアを記録しました。これは信じられないという反応でした。さらに他の様々なハーネスとも比較を行いました。よく「Claude Codeでも試したのか」と聞かれるのですが、実際に試しました。ただ残念ながら、その結果は良好なものではありませんでした。そこで、悪い結果をそのまま出すのではなく、Claude Code側の公式の結果を採用することにしました。その後、他の方々が似た設定でこれを実行し、それ以来より良い結果を得ているようです。興味深いのは、多くの人気の高いハーネスは、Prime Agentが良い成績を出す状況では必ずしも良い成績を出さない、という点です。例えば、あるエージェント(名前は伏せますが)では、非常に短時間で大量の費用を消費してしまい、それほどの性能向上も得られないまま、5,000ドルほど使ったところで打ち切らざるを得ませんでした。これがそのハーネスの限界だと言っているわけではありませんが、それだけのコストがかかったのは事実です。したがって、コストと性能の比率は非常に重要だと考えていますし、それを節約する要因の一つが、コンテキストをプログラム的に扱える能力だと思っています。
3.6 長期水平線タスクでの検証
Seth: 私たちはoolongや、近く公開予定のコーディング用エミュレーターベンチ「emulator bench」といった、いくつかの長期水平線の評価も実施しました。emulator benchはprogram benchの代替のようなベンチマークです。その結果、異なるモデルを横断して見た場合、これらは基本的に他のハーネス、例えばPimono、Claude Code、Codexなどと比較して、GLM 5.2からOpus 5、5.6という設定で、おおむね同等かわずかに優れている成績となりました。
Seth: もう一つ非常に面白いと感じたのが、emulator benchというプログラムベンチの代替で、私たちはコンピュータシステムのエミュレーター全体、この例では「Game Boy Color」のようなものを丸ごと再現しようとする試みです。ぜひ確認してみてください。特に興味深いのは、RLMにおけるこのリップルへのアクセスがあることで、最終的な解答を提出する前に、いわば「ループの外」で実験デザインを試すことができ、より表現力豊かで自由な形でいろいろと試行できるという点です。私たちはGPUカーネルの生成でも試してみて、SoulとKimicoの両方でおおよそ同等の結果を得ました。片方が良く、片方が悪い、というだけで、全体としてはほぼ互角でした。つまり私たちは、特定の一つの評価にだけ過剰適合しているわけではない、ということです。
Seth: 長期水平線という観点で特に興味深かったのは、nanoGPT speedrunを用いたオートリサーチの実験です。これをそのままではなく、規模をさらに拡大しました。8基のH200ノードを1週間分与えて、何が起きるかを見ました。皆さんは「Prime Agentならプログラムをフルに使えるから、圧倒的に良い結果が出るだろう」と思うかもしれません。しかし実際には、これはかなり分散(バリアンス)の大きい結果になりました。これは非常に難しいタスクであるため、ハーネスとモデルどちらの効果によるものかを明確に切り分けることはできません。しかし、私たちが観察できたこととして、挙動そのものを検証することはできます。特に興味深かったのは、deep 6v4、GLM 5.3、Kim K3といったモデルたちが見せた挙動でした。これらは私たちの最初の結果よりも少し後に行ったものだと分かります。これらのモデルは、私たちが「ループ外の実験(out of loop experiments)」と呼んでいるものを行っていました。つまり、CPU上でパラメータ化を調べたり、ハイパーパラメータ探索を行ったり、データを分析したりすることで、コストの高いH200での実験を毎回実行しなくても済むようにする、という工夫です。なぜなら、その本実験こそが時間の大部分を占めてしまうからです。つまり、本命の実験ではない実験を実行することで、それを最適化しようとしている、ということです。これは非常に面白い挙動だと感じていて、私たちがPrime Agentに求める表現力をどう形作っていくかを考える上で参考になりました。もしそれがオートリサーチに強いのであれば、それは人間と組み合わせたときにさらに良くなり、人間がループの中に入って実験をブートストラップする助けになると考えられます。
Seth: 最後に、私たちは7日間にわたるファクトリオ(Factorio)的なランを実施し、合計633体のエージェントを、2,300万の出力トークンにわたって使用し、技術ツリー全体で着実な技術的進歩を継続させることを試みました。ここでの主な利点の一つは、サブエージェントを異なるタスクに分割して、工場内で資源を調査・収集・建設し、次のアイテムを設計するために活用できたことです。それに加えて、これまでの過去の出来事を活用するリファインメントの機能を使うことで、非常に長いコンテキストの中でも行き詰まることなく作業を進められました。特に興味深いのは、この実験の最後の段階に至っても行き詰まることなく、技術的な進歩を継続し続けたという点です。これは少し「Geminiがポケモンをプレイする」という有名な事例に近い結論だと考えています。
Seth: もし今日の話から一つだけ、皆さん自身のハーネスに取り入れてほしいことがあるとすれば、エージェント的なコンテキスト管理について考えてほしいということです。そしてスワーム、さらに深く掘り下げるならRLM、そして標準化された評価を実行することについても考えてほしいと思います。今日お見せした結果はすべて、私たちPrime Intellectが提供している「verifiers」というパッケージを使えば再現可能です。最後に、素晴らしい共同研究者たちにも感謝を伝えたいと思います。一緒に働けて本当に良かったです。ありがとうございました。
4. Open Jarvis(John)のオンデバイス構想
4.1 クラウド依存への問題提起
John: 皆さん、こんばんは。今日はスタンフォードで取り組んでいるプロジェクトについてお話しできることを大変嬉しく思っています。私はIvanka Orionと共同で、そして指導教員のHazyとChristopher Reyの助言のもとで、このプロジェクトを進めています。
John: 個人向けのAIは今、あらゆる場所に存在していますが、その大部分はクラウドに依存したものです。私たちは、日々の文章作成、リサーチ、コーディング、スケジューリングに焦点を当てた、非常に多くのハーネスやプロジェクトを目にしています。しかしOpenClawやHermes agentのようなプロジェクトは、その知性のほとんど、そしてクエリのほとんどについて、クラウド上のLLMに依存しているのが実情です。
John: これが意味するのは、まずコストが非常に高くつくということです。1年間累積すれば、APIコストは数千ドル単位に達します。また、プライバシーの面でも問題があります。自分の最も個人的なデータをクラウド上のLLMに送信することになり、そのデータがどこに向かっているのか必ずしも把握できません。さらに、これは知性を「所有」するのではなく「借りる」ことを強いられるという問題でもあります。そして最後に、こうしたクラウド利用は、ラップトップ上でLLMを動かす場合と比べて、桁違いに多くのエネルギーを消費する傾向にあります。
John: ここで注目すべきは、ローカルLLMがついに、人々が本当に必要としているクエリの多くを実際にこなせるレベルに達してきたという点です。現在のローカルLLMは、最先端のフロンティアモデルからわずか6〜12か月遅れの性能しか持っていません。例えば、Qwen 3.8 27Bのようなモデルは、当時、つまり2026年8月時点での最先端モデルであったClaude 4.6 Opusとほぼ同等の性能を達成しています。そして、このギャップはハードウェアアクセラレータの進化とともに、ますます縮まってきています。実際、今週もAppleから新しいMac Miniのリリースがありました。AppleもNVIDIAも、個人利用向けに特化したアクセラレータの開発に力を入れる動きを強めています。
John: こうした背景を踏まえて、私たちのプロジェクトが探求したい中心的な問いは、パーソナルAIスタックの核となる部分、つまりモデルの推論、エージェントの実行、メモリ、そして学習という、現在ほとんどクラウドに依存している要素を、すべてオンデバイスで実現しながら、クラウドのみに依存するスタックと競合できる性能を維持できるか、というものです。そこで私たちが提案するのが「Open Jarvis」です。名前についてはこれ以上の説明は不要かと思います。私たちが探りたかったのは、セキュリティ、プライバシー、そして品質を維持しながら、このスタックのどれだけをデバイス上で完全に無料で動かせるか、ということでした。
4.2 設計と最適化の実験結果
John: Open Jarvisを構築するにあたり、私たちはどんな種類のハーネス、あるいはパーソナルAIスタックでも定義できるような、最もシンプルな要素の組み合わせを作りたいと考えました。一つ目は、利用するユーザーインターフェースです。二つ目は、複合的な推論や異なる種類の知性・ツールを組み合わせる、実際のエージェント的なロジックです。知性そのものについては、システムを動かす推論エンジンとして使うLLMそのもので、これはQwenでもGPT-OSSでもGemma 3Nでも構いません。そして、それを実際に動かすための推論エンジンが必要になります。これはOllama、Llama.cpp、vLLM、SGLangなどが該当し、どのハードウェア上で動かすか、Apple SiliconでもNVIDIAでも、必要なものを選べます。これらすべてのエージェントと知性を実際に活用可能にするには、標準的なMCPプロトコルを通じて動作できる、ツールとメモリのセットが必要です。そして最後に、実際に学習を行うためのプリミティブのセットが必要になります。これはDSPyのようなプロンプトベースの手法かもしれませんし、GRPOやSFT、LoRAといった重みベースの手法かもしれません。どちらにしても、エージェントを時間とともに改善させ、より個人的で効果的なものにしていくための何らかの手段が必要なのです。
John: Open Jarvisの実際の構成について説明します。私たちは、人々がすでに慣れている標準的なインターフェースをすべて採用する方向で進めました。デスクトップから操作でき、通常期待するのと同じように動作しつつ、コストとエネルギーの両面でどれだけ節約になっているかを確認できるようにしたいと考えました。また、異なる種類の継続的なエージェント、つまりcronジョブのように永続的に動作し、標準的なプロトコルを日々実行できるエージェントを動かせるようにもしたいと考えました。基本的には、人々が既に慣れているワークフローすべてに対して、プラグアンドプレイで組み込めるようにすることを目指しました。そして、人々が初めてChatGPTやClaudeに触れたときのような体験を、オンデバイスのLLMでも得られるようにしたいと考えました。
John: 新しい永続ジョブを設定する仕組みも用意していますが、これは駆け足で説明を進めます。こうした複数の構成要素があり、それを実際に最適化する何らかの手段が必要になります。そこで私たちは、これら5つのプリミティブの単純な仕様を作ることで、LLM自体をできるだけ介在させずに最適化を進められるようにしました。この最適化のループ全体を通して分かったのは、コストの大幅な削減だけでなく、レイテンシの大幅な削減、そして全体的な品質の大きな改善も得られたということです。この構成は、人々がこうしたLLMハーネスを構築する際に気にかける主要な5つの要素、つまり知性、エンジン、それを取り巻くエージェント的ロジック、必要なツールや学習システム、そして仕様全体を対象とした最適化に単純化することを意図しています。
John: ローカルとクラウドのLLMの間にあるギャップを埋める上で興味深いと考えているアプローチの一つが、クラウドLLMを使ってローカルスタック全体を自動的に最適化させる、というものです。これは、クラウドLLMの能力を活用して、変更案を診断し、条件を絞り込み、改善された解決策を作り出すという方法であり、実際に推論を行う段階でローカルスタックをデプロイする際にはクラウドLLMのコストを負担しなくて済む、という利点があります。実際に確認できたのは、Claudeや ChatGPTのようなクラウドLLMによって最適化されたOpen Jarvisの構成は、そのまま何も調整せずにデプロイしたローカルスタックよりもはるかに効果的だったということです。これは、異なる種類のワークロードに対して、特定のLLM、特定のハーネスに合わせて調整できるからです。私たちが分かったのは、今日のオンデバイスLLMであっても、パーソナルAIに関する個人的な使用ケース、コーディング、エージェント的タスクといった様々なワークフローで、クラウドLLMと競合できるということです。ただし、ローカルサイズのLLMではまだ不十分なタスクも多く残っていますが、そのギャップは、これらのLLMがより良く蒸留され、より効果的になり、また私たちがより優れたアクセラレータを手にするにつれて、月を追うごとに驚くほど縮まりつつあります。そして、今日のLLMだけを使ったとしても、実行コストにおいて800倍もの低さを実現でき、レイテンシについても大幅な削減が得られることが分かりました。また分かったこととして、どのクラウドLLMを選んだとしても、このエージェント的なループ全体を最適化する上で、ローカルのOpen Jarvis構成に対して有用であるという点でした。
John: 具体的には、Opus 5やGPT 5.6 Soulが最も自然に最良の性能を発揮することが分かりました。一方で興味深かったのは、GeminiやKimi、GLMといった他の大規模なLLMファミリーを選んでも、これらのローカル構成を最適化するために使うことができ、後のローカル推論のために効率性や性能の向上を捉えられるという点でした。さらに分かったこととして、Open Jarvisのハーネス全体は、より多くのデータやより多くのLLM呼び出しを必要とする可能性のある代替手法と比べて、最適化にかかるコストが安かったということです。この一連の仕様とプリミティブの組み合わせが、ローカルLLMの設定において最も効果的であったのは、クラウドLLMがシステム全体を最適化する際に、LLMの抽象化全体を邪魔にならないように整理できたからであり、これによってシステム全体が本当に速く、本当に効果的になったのだと考えています。
John: このプロジェクトについて、今後さらに構築を進めていくことを楽しみにしています。近い将来、人々が日々行う推論呼び出しのかなりの割合、あるいは過半数さえも、クラウドに送り出す今日の標準的なやり方ではなく、ローカルデバイスやオンプレミスのラップトップやワークステーション上で行われるようになると考えています。アクセラレータが良くなり続け、LLM自体も良くなり続けるため、こうした流れは今後も続いていくだろうと考えています。もし、より良いローカルLLM、より良いアクセラレータ、データセンターを越えてデプロイするためのより良い推論エンジンなど、このスタックのいずれかの部分に興味がある方がいれば、ぜひご連絡ください。プロジェクトのQRコードもご用意しています。この後もこの場に残っている方がいれば、ぜひお話ししたいと思います。ありがとうございました。
5. QM(Josh & Rean)の内製ハーネス
5.1 QMの概要と変遷史
MC: さて、次はYC自身の取り組みです。JoshとReanに登場してもらいます。こんにちは、Joshです。こちらはReanです。私たちはQMというプロジェクトに取り組んでいます。これはYCが開発した、業務向けのオープンソースのエージェントハーネスです。
Josh: QMは一つのシステムであり、YCの全社員に対して、フルにカスタマイズ可能な、OpenClawのようなアシスタントを提供するものです。Slack上でも、あるいは今ご覧いただいているようなWeb UI上でも利用できます。各社員はQMの中で自分自身のパーソナルなコンテキストを持ち、それぞれ専用のサンドボックスやファイル、cronジョブを持っています。また、Slackチャンネルのようなマルチプレイヤーの設定の中でもQMとやり取りすることができます。
Josh: QMの利用範囲は非常に広く、メールのトリアージのような自動化業務、法務や財務のワークフロー、文書編集、社内データベースからのデータ抽出などに使われています。また、社内向けのライブなWebアプリを立ち上げたり、イベントの計画を手伝ったりすることもできます。基本的には、YCの社員が日々遭遇するであろう様々なタスクに対して、広く汎用的に役立つように設計されています。
Josh: なぜこれを作ったのかということですが、これは実際には、これまで社内で積み重ねてきた一連のエージェントプロジェクトの結果であり、いずれも当時どんどん賢くなっていくモデルの追い風に乗って進めてきたものです。最初に作ったのは2025年1月のもので、私たちは社内で「ジェネラルエージェント」と呼んでいます。ただ、実際にはかなりシンプルなもので、単純にシステムプロンプトとツールをループさせたものでした。全員が同じものと対話するという、いわば「ワンサイズフィッツオール」の仕組みでした。アーキテクチャとしてはかなり単純だったのですが、データに関する質問への回答という点では、驚くほど良い性能を発揮していました。興味深いことに、このジェネラルエージェントが得意な範囲は、基盤となるモデルが良くなるにつれて、当然のことながらどんどん広がっていきました。やがてこれをSlackにも接続し、cronを追加し、より多くの領域をカバーできるようにいくつかツールを増やしました。
Josh: 2025年6月になると、私たちのエンジニアの多くがClaude CodeやCodexを使い始めていて、これらを比較的簡単にVM上で動かせることに気づきました。そこでそれをSlackタグに接続したところ、ちょっとしたコード変更を一つやりたいだけの人にとって、非常に強力な手段になりました。また、これをCIパイプラインの実行や、テスト用の開発環境の立ち上げにも設定しました。これにより、人々はバグや実現したい何かを説明するだけで、ボットが実際に解決へ向かって動いてくれるようになり、これはたとえこれまでコード変更を一度もしたことがない人にとっても非常に強力なものになりました。それに加えて、このボットがどこで失敗したか、どこで間違えたかを観察する小さなループも同時に走らせていて、当時コードベースに存在していた「agents.md」を更新することで、利用状況を観察しながらこの仕組み自体が改善されていくようにしていました。
Josh: 2026年1月になると、多くのパートナーがOpenClawを使い始めました。YCのパートナーについて知っておいていただきたいのは、彼らが非常に多忙だということです。オフィスアワーの合間に大量の受信メールが来て、常に応募書類を読んでいます。ですから、彼らにさらなるレバレッジを与えられるツールは、YCにとって非常に価値があります。OpenClawが特に有用だったのは、彼らの多くにとって、自分専用のコンピュータを持つ初めてのエージェントだったという点です。これにより、それまでのエージェントのパラダイムにはなかった形で、非常にカスタマイズ可能なものになり、ほぼ個人アシスタントのように機能しました。そして2026年4月には、Macを一台ずつ全員に買い与えることなく、これを全社員に提供できるだろうか、という問いが出てきました。そこで私たちは、VM上で動く50台以上のHermesエージェントの群れを用意することになりました。これらは確かにかなり役立っていたのですが、人々が価値を得るためには多くの設定作業が必要で、この一群を管理すること自体が本質的に難しい作業になっていました。まるで「モグラたたき」のような状況で、個々のインスタンスにSSHで入って修正するということを私自身が行わなければならないこともありました。
Josh: そこで次の問いとして、私たちはこれまでこうしたエージェント的なシステムから多くの価値を得てきたのだから、この大規模なHermesエージェント群を運用することの欠点に対処するものを作ろう、という方向に進みました。ただし、人々が本当に価値を感じていたパーソナライズ性のような要素は維持したまま、という条件です。
Rean: はい、そうですね。基本的に、Joshがお見せしたところから、かなり明確な流れが見えてきます。モデルは指数関数的に良くなっていて、私たちはモデルにより多くの能力を与えるほど、ますます高い見返りを得られるようになっていました。OpenClawはエージェントに自分専用のコンピュータを与えるものであり、そこから本当に大きな見返りが見えてきました。そこで2026年5月ごろから、私たちはこの糸をどこまで引っ張れるかを考え始めました。私たちは「アンホブリング(unhobbling)」という視点をとても気に入っています。2024年に発表された「Situational Awareness」という文章を読んだ方もいるかもしれませんが、あの時期はまさに、テスト時計算がようやく話題になり始め、エージェントに初めてツールを与えるようになった頃でした。エージェントにできることについては、私たちが実際に活用している以上の知能がモデルの中に眠っている、という直感がありました。
5.2 設計思想とアーキテクチャ変更
Rean: もし私たちが本当にフロンティアを押し広げて、エージェントに提供する能力の幅を突き詰めていけば、そこから何か「マジック」のようなことが起こり始めるのではないか、と考えました。QMでその方向性を実現するための最初の方法は、システムの「頭脳」をサンドボックスの外に引き出すことでした。HermesやOpenClawでは、事実上エージェントが自分専用のコンピュータを持っているのですが、それはとても強力である一方で、そのコンピュータの中に閉じ込められてしまっている、という側面もあります。それが原因で、こうしたシステムを管理する側にとって、たとえほんの数十台程度であってもすぐに扱いにくくなる、という問題が生じていました。
Rean: もう一つの問題は、そうした個々のセッションはすべて、そのコンピュータの中に閉じ込められてしまうということです。そこで私たちが代わりに行ったのが、すべてをPostgresにオフロードすることでした。これによって、あらゆるエージェントの会話がすべて一元化され、それらをエージェント自身にも公開できるようになります。つまりエージェントは、システム全体から集約されてくるすべてのコンテキストを見ることができるのです。それに加えて、私たちはサンドボックスを、エージェントが「住む家」としてではなく、より「必要に応じて使うことができるリソース」として考え始めました。これによって、以前よりずっと制約の少ない仕組みになりました。
5.3 自動改善ループの実験結果
Rean: これがさらに開いてくれるもう一つの発想は、人々がエージェントと交わしている会話のトレースがすべて大規模に蓄積されていくという点です。理屈上は、それを使ってヒルクライミング(段階的な最適化)を行い、自動化された改善ループを持たせることも考えられます。私たちはこれについて、正直なところ「混合的な結果」を得ています。私が思うのは、たとえば遭遇したバグをすべて修正するために、大量のエージェントを一斉に走らせて、LLMを審査役として使うようなやり方をすると、いわば「メインキャラクター症候群」のようなものが生じてしまう、ということです。つまりエージェントたちが、それぞれ自分に見えている「象の一部分」しか見ずに修正を加えてしまうのです。全体像、システム全体を見渡せていないことがあり、そのため、人間がループの中に入ることが依然として非常に重要であり続けています。もちろん、私たちはこれが完全に自動で回るようになることを強く期待していますが。
5.4 権限管理と書き込み設計
Rean: もう一つ、私たちが行っている当然とも言える大きなことは、会社中のあらゆるリソースにエージェントを接続することです。YCには元々、多くのシステムをうまく連携させてくれるCLIがすでにありました。それに含まれていないものについては、基本的に任意のAPIキーを追加できるようにしています。それに加えて、社員が自分のラップトップで作業している場合と同等の状態を確保したいと考えています。つまり、デバイスコードによるOAuthを取り込んでキーチェーンに保存し、必要に応じてリフレッシュするようにしています。これは理想的には、人がパソコンで作業しているときの体験をそのまま模倣することを目指したものです。データベースへのアクセスは基本的に読み取り専用に留めていますが、書き込みについては、人間によるレビューを経た一括アップサートという形で許可しています。その仕組みは、エージェントがデータベースを編集するための計画をまず提示し、それを人が一通り確認して、何か変な操作をしていないかを確認した上で、実際の書き込みが行われる、というものです。
Rean: ここで一つ観察していることがあります。私たちは徐々に、こうしたレビューを「ラバースタンプ(形式的な承認)」のように処理してしまうようになってきているのです。これは少し、Claude Codeを初期の頃に使っていた方であれば経験があるかもしれませんが、最初はツールの使用を非常に細かくレビューしていたものが、やがてエージェントに対する信頼が積み重なっていく、という現象に似ています。ですのでこれは、今後数か月にわたって非常に注意深く見ていきたいと考えている点です。
5.5 リソース割り当てとハーネスの薄さ
Rean: 先ほどお話ししたように、私たちはこのシステムにおけるサンドボックスを、エージェントの「リソース」として捉えたいと考えています。エージェントが実際に「住む」場所というよりも、という位置づけです。QMでは、エージェントは基本的にデフォルトで特定のサンドボックスを使うことになります。それは、そのエージェントが対話しているユーザーに割り当てられたサンドボックスです。しかし一般には、エージェントが収束していけるような環境が他にも存在し、それらと連携することもできます。もう一つ重要な点として、エージェントがより重いdevワークロードに取り組んでいる場合には、より多くのリソースを持ったマシンに手を伸ばすことができます。逆に、よりシンプルな作業をしている場合には、より非力なサンドボックスを選ぶことになります。この判断を、ハーネス側ではなくエージェント自身に委ねるようにしたことは、非常に強力な変化だったと感じています。
Rean: 同様に、エージェント自身が自分の実行時環境(ランタイム)を選べるようにすることも行っています。つまり、エージェントが利用するプロバイダを自ら選べるようにすることで、皆さんもFableなどで経験したことがあるかもしれませんが、AIリサーチやサイバーセキュリティといった分野で何かをやろうとすると拒否応答が返ってくる、といった状況を避けられるようになります。エージェントがランタイムを自ら制御できれば、そうした状況を避けるために別のモデルにポップアウトすることができます。同様に、これは先ほどの話と似ていますが、異なるサンドボックスプロバイダの間をポップして切り替えることも、かなり簡単に行えるようになっています。
Rean: 一般的な方針として、私たちはハーネスを極力「薄く」保つように努めています。私たちはこのシステムの中核を、遠隔サンドボックスでの実行、オブジェクトストレージへの読み書き、そして内部アプリの公開(Git連携によるかなりシンプルなシステム)という3つのツールとして捉えています。それ以外にも、メモリやcronなどとやり取りするためのツールもありますが、これらはあくまでシステムの荒削りな部分を一時的に覆っているものだと考えています。本当のコアは、この3つのツールに尽きます。極力これを小さく保つように努めています。私たちはいわば「AGIを見越したハーネス」を目指しているのですが、まだそこには到達していないため、いくつか遭遇した課題があります。
5.6 運用上の課題と対処
Rean: 一つは、エージェントに非常に高い能力を持つ環境、あらゆるツールが使える環境を用意したのですが、それでもエージェントは早すぎるタイミングで諦めてしまうことが多い、という点です。そこで、特にここ一か月ほど実験しているのが、私たちが「grindツール」と呼んでいるものです。基本的には、目標に対して予算を設定するというものです。エージェントは、一定の実時間(たとえば数時間)や、一定のトークン消費量に達するまでは、タスクを諦めることを許されません。これによって実現できるのは、はるかに良いリサーチの成果物、より良いレポートなど、そういったものです。これは実際、OpenAIやAnthropicが数学の未解決問題をいくつか解く際に、非常に似た手法を使っていたのを見て、面白いと感じました。ただ、これは通常のオフィスワークのような業務にも同じように機能します。
Rean: もう一つよく見られる問題として、このハーネスはマルチプレイヤーの環境、つまりSlackの中でも動作するように設計されているのですが、モデルの訓練上の特性ゆえに、システムプロンプトの中で自分が置かれている状況をかなり明確に指定していても、エージェントが自分がどういう状況にいるのかについて、非常に混乱してしまうことがあります。そのため、こうした状況に対するローカルなアフォーダンス(手がかり)を用意することが、非常に重要になってきています。そしてもう一つ問題になっているのが、エージェントは社会的な文脈というものをうまく理解できない、という点です。もう少し具体的に言うと、例えば私がReganに何か情報を伝えたとすると、彼は直感的に、その情報をどこまで共有していいのか、という良いメンタルフレームワークをすでに持っています。しかしこれをエージェントで再現するには、実際にかなりの作業が必要になります。機密性の高い情報が、共有されるべきではない文脈に非常に簡単に漏れてしまうことがあり得ます。つまり、「頭脳」に入れられる情報の量は、実質的に、あなたの権限管理システムの精度によって制約されるということです。幸いなことに、YCには長年かけて構築してきた、きめ細かい権限管理を可能にする既存のソフトウェアシステムがありますが、多くの人々はそうした仕組みを持っていません。そのため、ニュアンスのある形で知識共有を実現するには、相応の作業が必要になります。
Rean: それでは、ご清聴ありがとうございました。QMはオープンソースで公開していますので、ぜひ試してみてください。コーディングエージェントであれば、これを立ち上げるのはかなり得意なはずです。何か問題があれば、ぜひissueを立てていただければ、私たちが確認します。また、私たちは採用も行っています。ここでお話しした内容に響くものがあった方、興味を持っていただけた方は、ぜひメールをお送りください。