Transcript
00:00:00SQLiteがRustで再構築されました。
00:00:02最近BunのRust再構築があったばかりなので
00:00:04なぜ誰も彼もがRustで何もかも
00:00:06書き直しているのかと思うでしょうが、これはRustの話ではありません。
00:00:09SQLiteの話でさえありません。
00:00:11Tursoというデータベースが存在することは知っています。
00:00:15これはすでにRustによるSQLiteの
00:00:18近代的な再実装となっています。
00:00:19プロダクション利用可能な
00:00:21RustベースのSQLiteデータベースを使いたいなら
00:00:23そちらを選ぶべきでしょう。
00:00:26代わりに、この「mini SQLite」という実験は
00:00:29概要欄にリンクがあり、確認できますが
00:00:32SQLiteやRust自体の話ではありません。
00:00:34これはCursorチームによる実験であり
00:00:37エージェントスウォームとAIエージェントシステムの
00:00:40設計、そして何が機能して何が機能しないかを
00:00:44見極めることを目的としています。
00:00:47ドキュメントだけからSQLiteのようなものを構築できるのか
00:00:51それこそがこの実験のテーマだからです。
00:00:53非常に詳細で興味深いブログ記事があるので
00:00:56詳しく見ていきましょう。
00:00:57そこには興味深い学びがたくさん詰まっており
00:00:59語るべきポイントが満載です（こちらも概要欄にリンクあり）。
00:01:02彼らはこの実験をどのように実行したのか、その出発点と
00:01:07アイデアを説明しています。それはSQLiteのドキュメントを取り入れることでした。
00:01:121つの文書にまとめると、なんと835ページにも及ぶものです。
00:01:18当然ながら、これは主に人間向けに書かれています。
00:01:23これまで見た中で最も親しみやすいドキュメントというわけではありませんが
00:01:27AIエージェントの流行よりもはるかに昔からあるため、人間に向けたものであることは明白です。
00:01:32それにもかかわらず、超詳細な仕様書としても機能します。
00:01:37SQLiteの詳しい使い方や、意図された動作
00:01:43意図された機能が事細かに記述されているからです。
00:01:48Cursorチームはそのドキュメントを用意し
00:01:52パブリックなテストセットである「SQLogicTest」を使用しました。
00:01:57これはSQLiteの動作や、特にクエリを検証する
00:02:02多数のテスト群です。
00:02:05そして、エージェントがドキュメントに基づいて
00:02:09構築した実装が
00:02:13その公式の巨大なテストスイートで実際に動作するか確認しました。
00:02:19ここで、あらかじめ重要ないくつかの注意点があります。
00:02:23このテストスイートはクエリとクエリの動作を検証するためのものです。
00:02:29SQLiteが持つすべての機能や能力をテストしているわけではありません。
00:02:35一般的なパフォーマンスを測定するものでもありません。
00:02:38並行性を検証するものでもありません。
00:02:40SQLiteには、これでテストできない要素が山ほどあります。
00:02:44そして実験の成果の1つであるこの「mini SQLite」は
00:02:49実際には異なるエージェントの組み合わせでSQLiteを何度も再構築しています。
00:02:53これについて深く探求していきますが、あくまで調査目的の成果物です。
00:02:57実用段階（プロダクション対応）ではありません。
00:02:59実際に使うためのものではないのです。
00:03:01ドキュメントを活用してSQLiteを再構築し
00:03:06その再構築版ですべてのテストをパスさせることを目的とした実験のアウトプットに過ぎません。
00:03:13Cursorチームはここで様々なモデルの組み合わせを使用しました。
00:03:17なぜ組み合わせなのか？
00:03:18後述するように、彼らは複数のエージェントが
00:03:21連携するアプローチ（プランナー、ワーカー、レビュアーエージェント）を採用したからです。
00:03:28彼らは異なる組み合わせでSQLiteデータベースを再構築し、同等の品質が得られるかを測定しました。
00:03:37これらすべての組み合わせで同等の品質、つまり同数のテスト通過を達成しましたが、どの組み合わせにいくらかかったかを測定したのです。
00:03:45例えば、プランナーとワーカーの全エージェントにGPT-5.5を使用した場合、ドキュメントに基づくRust製SQLiteの実装コストは約10,000ドルに達しました。
00:03:59一方で、Opus 4.8とComposer 2.5（Cursorによる超高速で非常に安価かつ効率的、ただし最高度に知的なわけではないモデル）を組み合わせた場合、他の組み合わせと同等の品質とテスト通過数を達成しながら、わずか1,300ドルというほんのわずかな費用で済みました。
00:04:24ここでのアイデアは、より高性能なモデルであるOpus 4.8を計画立案やタスク設計に使用し、作成されたタスクをComposer 2.5を使うワーカーエージェントに引き渡すというものでした。
00:04:39そしてこれこそが、この記事から得られる最初の重要なポイントです（決して真新しいものではありませんが）。
00:04:44ソフトウェアを開発する際、自分自身でも活用できます。
00:04:47作業の複雑さに応じて、異なるエージェント（サブエージェント）が実行する別々のタスクに分割するのは優れたアプローチです。一部のエージェントは計画立案に集中し、
00:05:03全体タスクから絞り込んだ個別の作業（職務）を設計し、それを実装する多数のエージェントを配置します。
00:05:14コンテキストが適切であれば、優れたコードを出力するためだけに必ずしも最先端の超高知能モデルを必要としないことが分かっているからです。
00:05:24タスクが明確に定義され、有益な情報がすべてタスク説明に含まれていれば十分であり、もちろん他の要因も影響してきます。
00:05:33例えば、周囲のコードベースの構造や、エージェントに提供するサンプルコードの質なども重要になります。
00:05:39それらすべてが出力に影響を与えますが、タスクが明確に仕様化されコンテキストが良ければ、単にコードを書くワーカーエージェントは数を増やせば対応できるのです。
00:05:49そしてそれこそが、この実験の主なテーマでした。
00:05:52この規模のタスクに対処できるシステムをいかに設計するか、ということです。
00:05:57前述の通り、ご自身のプロジェクトでもプランナー＋ワーカーエージェントの構成は検討に値します。
00:06:07もちろん、すべてのタスクに必要なわけではありません。
00:06:10手早いバグ修正や非常にシンプルなタスクであれば、CodexでもClaude Codeでも、お使いのエージェントに直接伝えるだけで十分です。
00:06:19「こういう問題がある」と。
00:06:20「これをやってほしい」と。
00:06:21補足のコンテキストを与えて、任せればよいのです。
00:06:24コーディングエージェントの基盤によっては、サブエージェントを立ち上げる場合もあります。
00:06:28Claude Codeならそうするかもしれません。
00:06:31Piのような他の基盤では、適切な拡張を与えなければ立ち上げないかもしれません。
00:06:36しかしサブエージェントがなくても、多くのタスクは単一のエージェントだけで問題なく解決できます。
00:06:43ですが、より複雑なプロジェクトやタスクでは、レビュアーエージェントを含めて役割を分割することが有益です。
00:06:51これは私自身も好んで行っている手法です。
00:06:54繰り返しますが、タスクの複雑さによります。
00:06:56しかし、この分割の手法は非常にうまく機能します。
00:06:59そして当然、これ自体は画期的に新しいことではありません。
00:07:02新しいのは、このSQLite再構築のように、プランナー、ワーカー、レビュアーエージェントの並列プロセスが複数存在し、多数のワーカーだけでなく多数のプランナーやレビュアーも動いている点です。
00:07:18そして、それらは絶えず衝突を起こします。
00:07:19これこそが、Cursorチームが最終的に発見したことです。
00:07:22さて、この非常に興味深いブログ記事において
00:07:26彼らは今年前半に、エージェント基盤を使ってウェブブラウザをイチから構築する実験をすでに行ったと述べています。
00:07:33そして今回、同じ基盤（あるいはエージェントシステムと言うべきか）を使ってSQLiteの再構築を行いました。
00:07:40しかし彼らはまた、これまでに得た学びに基づいた新たなシステムも実験として構築しました。
00:07:47この実験とブログ記事の中で、彼らはこれらの異なるアプローチを比較し、SQLiteを再構築するシステムを立ち上げ運用する中で直面したすべての課題を掘り下げています。
00:07:59数何百、数何千ものワーカーが同時に稼働するシステムで彼らが直面した最初の課題の1つは、Gitという従来のバージョン管理が通用しなくなることでした。
00:08:13スウォームに関する以前の投稿で書かれているように、GitやCargoなどのツールは並行性制御のために粗いロックに依存しており、同じデータ領域がロックされて複数の書き込みが同時に行えないようになっています。
00:08:30これは1人の開発者なら問題ありませんが、数何百もの並行エージェントが生み出す作業量には対応できません。
00:08:36今年前半のブラウザ構築スウォームは、ピーク時に1時間あたり約1,000コミットを記録しました。
00:08:41これがブラウザを再構築したスウォームの数字です。
00:08:45この実験のために設計された新システムは、ピーク時に1秒あたり約1,000コミットに達します。
00:08:52今年前半の旧スウォームは1時間あたり1,000コミットで、これでも大半の人間より遥かに多いのは言うまでもありません。
00:09:02しかし新システムは1秒あたり約1,000コミットという圧倒的な速度であり、明らかにGitが想定して作られた規模ではありません。
00:09:14言うまでもありませんが。
00:09:15この処理速度を実現するため、私たちはゼロから新しいバージョン管理システムを構築しました。
00:09:21このレイヤーを自作した理由はスループットだけではありません。
00:09:25システム内のすべての変更がバージョン管理システムを経由します。
00:09:29つまり、そこが衝突が最初に可視化される場所なのです。
00:09:31そして次節で述べる調停メカニズムのいくつかは、その中に直接実装されています。
00:09:37これは実に興味深いことです。
00:09:39彼らはAIエージェント時代のための新しいバージョン管理システムを作ったのです。
00:09:43私たちが使っている従来のGit自体に落ち度があるわけではありません。
00:09:48誤解のないように言っておきますが。
00:09:49ここで話しているのは、私たちの多くが（少なくとも当面は）取り組むことのない規模とタスクの実験についてです。
00:09:57それでも、旧来のGitシステムは、数何百ものエージェントやエンティティが同じコードで同時に作業することを想定して作られていません。
00:10:07そのため、超高並行性を処理できるだけでなく、エージェントを介したコンフリクト解消を支援する新しいバージョン管理システムを構築したのです。
00:10:192つの変更がファイル内の同じコードに影響を与えた場合、コンフリクトが表面化するのは当然バージョン管理システムだからです。
00:10:28これがまず重要なポイントです。
00:10:30彼らはこの実験を効率的に実行・処理するために、まったく新しいバージョン管理システムを構築しました。
00:10:37当然ながら、記事にある通り、秒間1,000コミットという変更速度と規模においては、多くの問題が発生しました。
00:10:48例えば（直面したすべての問題と解決策は極めて興味深いのですが）、少なくとも特定のシナリオにおいて、将来のソフトウェアエンジニアリングがどうなるかを垣間見せてくれます。
00:11:01「スプリットブレイン設計問題」です。
00:11:03お互いを認識していない2つのプランナーが、コードベースの異なる部分で同じ概念を異なる方法で実装してしまう問題です。
00:11:10つまり、コードベースの別々の場所で同じ概念が重複して異なる実装をされるわけです。
00:11:16通常なら、それを抽出してロジックを再利用したいところですよね？
00:11:21「私たちはこれをプロンプティングによって解決しました。」
00:11:24大掛かりな新システムを作ったのではなく、プロンプティングで解決したのです。
00:11:28プランナーエージェント自体が設計判断を下し、それを他へ委任しないようにしました。
00:11:34そして、委任された2つのサブツリーが同じ課題に対して重複決定を下さないよう義務付けました。
00:11:39これは構成（セットアップ）の問題です。
00:11:40システムをプランナーやワーカー等に分割する際、並列ワーカーだけでなく並行動作するプランナー同士が、衝突や重複を起こしにくい明確に定義されたタスクを持つように保証することが重要なのです。
00:12:02したがって、それは人間の側での設計から始まります。
00:12:08タスクをどう設計し、どうプロンプトを与えるかですね。
00:12:11「私たちはこれをプロンプティングによって解決しました。」
00:12:13エージェントのツリー構造を下っていく中で、並列ノードや並列リーフにおいて、タスクをサブタスクに分割する際、重複する確率が低い形に切り分けるようプロンプトを指示することが求められます。
00:12:34最終的には人間側のプランニングの課題であり、人間側からシステムを正しくセットアップすることがすべてとなります。
00:12:43これが彼らがこの問題に対処・解決した方法です。
00:12:47彼らが直面したもう1つの問題は、プランナー間の競合でした。
00:12:51より深刻な競合は、2つのプランナーがお互いの存在を知りつつ、同一ファイルに対して不毛な上書き合戦を繰り広げるケースです。
00:12:59問題は、2つの独立した認識が存在する場合、マージツールでは意見の相違を解決できない点にあります。
00:13:04代わりに、エージェントには共有の設計ドキュメントに決定事項を記録させます。
00:13:08決定に依存するコードは、そのドキュメントへのコンパイル時チェック参照を保持します。
00:13:13プランナーがそれと知らずに矛盾を起こした場合、リコンサイラー（調停役）がドキュメントを統合し、参照を通じて解決策がダウンストリームへ伝播します。
00:13:21前述のポイントと関連しますが、プランナー間で作業を分割しても、ソフトウェア開発の性質上、コードベース内でプランナーや最終的なワーカーが触れる領域の重複や共有ドメイン、共通ロジックを完全に避けることはできません。
00:13:43そのためプランナー同士が実装を巡って対立し始めた際、恐らくリコンサイラーエージェントを投入して、それらプランナーが作成したドキュメントを統合させることで解決したのです。
00:13:59ワーカーに引き渡すために作成されたドキュメントですね。
00:14:02対立するプランナーのドキュメントを合意・統合させる中間ステップを設け、一貫した記述と実装方針に揃えることで、同じ機能がコードベースの異なる場所で別々に再実装されるのを防ぎました。
00:14:21私の理解では、この2つは連携して機能しています。
00:14:24当然ながら、彼らはマージコンフリクトにも遭遇しました。
00:14:29重複をなくすか極力減らすよう計画し、プランナーの共通認識を保つことが最初の重要なステップですが
00:14:38それでも同一の計画に携わる複数のワーカー同士が同じファイルに手を加え、矛盾を発生させる可能性は極めて高いのです。
00:14:50そのため、意図的に担当ファイルを分離しない限り衝突は避けられません。
00:14:55だからこそ彼らは担当ファイルを分けて作業させようとしたのです。
00:14:57だからこそファイルの重複作業を避ける必要がありました。
00:14:58衝突を解決するには、作業を中断し、他方のコンテキストを読み込んでマージ作業を行う必要があります。
00:15:03当然ながら、2つのエージェント（あるいは人間）が同じファイルを編集する場合、競合を解消するには両者が手を止めて調整しなければなりません。
00:15:19衝突を解消する実装方針を決める必要があるためです。
00:15:23しかしワーカーエージェントはこれが苦手で、他方の変更を上書きするか、自分の変更を破棄してしまいます。
00:15:29皆さんもこれに気づいたことがあるかもしれません。
00:15:31私自身、確実に経験があります。
00:15:321つ以上のAIエージェントと一緒にコードベースで作業していて、自分が何か変更を加えたとします。
00:15:38恐ろしい話ですが、人間もまだコードを書きますよね。
00:15:40とにかく、自分が手を入れたとしましょう。
00:15:42コードの一部を変更した場合です。
00:15:44エージェントは常にそれを元に戻して上書きしてしまいます。
00:15:48人間の変更を尊重しようとしません。
00:15:50自分なりの目的（アジェンダ）を持っているからです。
00:15:52特定ファイルを編集すべきだと判断したら、容赦なくそれを実行します。
00:15:57その間に人間がどんな変更を加えたかなど気に留めません。
00:16:01変更をコミット済みであれば少し挙動が変わります。エージェントは人間のコミットを安易に消さないよう事後学習・微調整されているからです。
00:16:13しかし未コミットの変更であれば、ワーカーは一考だにしません。
00:16:17エージェントは気にも留めないのです。
00:16:19そしてそれこそが、彼らがここで遭遇した現象そのものでした。
00:16:21「これを解決するため、中立的な第三者エージェントがマージコンフリクトに介入し、全当事者に代わって解消する仕組みを作りました。」
00:16:29「その唯一の目的は、エンジニアリングチームのマージキューのように公平かつ効率的であることです。」
00:16:35これも非常に興味深いアプローチだと思います。
00:16:38要するに調停の一種です。
00:16:41昔の世界で手を止めて一歩引き、衝突の解決策を見出していたのと同様に、エージェントを一度停止させる手法です。
00:16:49コンフリクトの解決に向けて。
00:16:51しかしこれが明確に示しているのは（これも新しい発見ではありませんが）、適切な情報が与えられたクリーンなコンテキストがいかに超重要かということです。
00:17:03Cursorのような大規模タスクに取り組む場合でも、もっと小規模なプロジェクトで作業する場合でも
00:17:12プランナー、ワーカー、レビュアーエージェントに役割を分割する最大の利点は、フレッシュなコンテキストウィンドウで作業できる点にあります。
00:17:24これは空のコンテキストという意味ではありません。
00:17:26指定されたタスクに最適なコンテキストのみが充填された、新しいエージェントセッションを意味します。
00:17:33例えばワーカーは、自身の実装経緯がコンテキスト内に残っているため、自分の成果物をレビューするのが非常に苦手です。
00:17:41言わば偏見（バイアス）が生じてしまうのです。
00:17:44だからこそレビュアーエージェントはまっさらなコンテキストウィンドウで開始し、ワーカーの実施内容や計画、変更ファイルの情報だけを受け取るべきなのです。
00:17:55そうすることで初めて、作業内容を客観的にレビューできます。
00:17:59適切な情報で満たされたクリーンなコンテキストウィンドウが極めて重要な理由はそこにあります。
00:18:04そしてこれこそが、先ほどのマージコンフリクトをバイアスなしの新しいエージェントで解決させた手法と同じなのです。
00:18:17その後、ワーカーエージェントがコンフリクト解消結果を受け取って上書きを禁止されたか、あるいは新しいワーカーが立ち上げられたのだと推測されます。
00:18:30そのあたりの詳細はここでは完全には明かされていません。
00:18:32彼らが遭遇したもう1つの問題は「メガファイル」でした。
00:18:35一部のファイルは、エージェントにとって特に格好の作業場所となってしまいます。
00:18:39各エージェントはわずかなコードを追加するだけで、ファイルをコンパクトに保つ責任を誰一人負いません。
00:18:45これらの巨大ファイル（メガファイル）はすべてを低速化させます。
00:18:49転送、差分抽出、マージのコストが跳ね上がり、絶え間ない衝突の発生源となるのです。
00:18:54これもまた、はるかに小さな規模であっても皆さんが遭遇したことのある現象かもしれません。
00:19:00私自身も確実に経験があります。
00:19:01私たちが抱えている問題の1つです。
00:19:02特にテストに関してですが
00:19:03エージェントは同じファイルにひたすらテストを追加したがる傾向があります
00:19:08もちろんテストに限りませんが、特によく見られる領域です
00:19:13特に複数のエージェントが作業しており、それぞれに目的がある場合
00:19:18彼らは人間ではないので気にしません
00:19:21そもそも何かに配慮することなどできるでしょうか？
00:19:23ただタスクを実行しているだけですよね？
00:19:24ファイルサイズやシステム全体のアーキテクチャなど気にも留めません
00:19:30エージェント群にタスクを実行させ続けるだけでは、コードベースはいずれ混沌へと向かいます
00:19:37エージェントは気にしないからです
00:19:39彼らが気にするのはタスクの実行だけです
00:19:42そして、これらの巨大ファイルはその問題を明確に示す指標の一つです
00:19:48プロジェクトでより多くのエージェントが長期間働くほど、顕著になっていきます
00:19:55ファイルを分割したり、コードベースのアーキテクチャを整えたりする責任を持つエージェントはいません
00:20:02それは彼らの目的ではないのです
00:20:04そこで修正のため、ワーカーエージェントに肥大化したファイルをフラグ付けする手段を与えました
00:20:09フラグが立つと新規コミットをブロックし、別のエージェントが肥大化したファイルを小さなモジュールに分解します
00:20:16つまり、ここでも新しいエージェントを投入するのです
00:20:19ここに見られるパターンですね
00:20:21これらすべての問題において、問題を特定し、適切なタスクを与えたまっさらなエージェントを投入し、
00:20:28適切なコンテキストを与えて問題を解決させ、他のエージェントが作業を継続できるようにしました
00:20:35巨大ファイルの問題についても同じです
00:20:38彼らが直面したもう一つの問題は「硬化（Ossification）」です
00:20:40エージェントは人間が介入する既存のコードベースでの作業を通じて、
00:20:44変更が必要な場合であってもコアコードには手を触れないことを学んでしまっています
00:20:48これは先ほど話した内容とは異なります
00:20:50エージェントが作業中のファイルに変更を加えた際に、それを破棄してしまう話ではなく
00:20:55全体的な傾向についての話です
00:20:57エージェントは指示されたプロンプトや計画に基づいた明確なタスクを持っています
00:21:03そしてそれには当然、特定のファイルの変更が含まれます
00:21:07日常的にエージェントを使っていて既に分かっている、あるいは見られることとして、モデルにもよりますが
00:21:16一部のモデルは既存のコードを手放すことを極度にためらいます
00:21:21コードを削除してクリーンアップする代わりに、10個のフォールバックや10個のif分岐、さらなるレガシーコードを追加しようとします
00:21:31関数を確実に削除させたりコードファイルを処分させたりするには、明示的にプロンプトで指示する必要があります
00:21:39ファインチューニングの影響で自発的には行いません。モデル提供者は自由に暴走して
00:21:47あらゆる本番コードを破壊するようなモデルを作りたくないからです
00:21:50しかし、新規開発プロジェクトではなく、すでに本番稼働しているような既存のコードベースでない場合、
00:21:57コードに手を付けず永遠に残そうとするこの傾向は、非常に問題であり厄介なものとなり得ます
00:22:05また、ここで彼らが遭遇したように、他のエージェントが書いたコードを改善しようとせず
00:22:16その上にただ塗り重ねていき、最終的にコードベースの肥大化を招くという副作用を引き起こします
00:22:23これを解決するため、意図的な破壊を許可（ライセンス）しました
00:22:27コアの変更が価値あると判断したエージェントは、自身のスコープ外でも焦点を絞ったパッチを適用し、理由をコメントに残せます
00:22:36これもまた、小規模ながら自分のプロジェクトで実践できることです
00:22:41エージェントに対して明示的に許可を与え、「これを作っている最中だ」と伝えます
00:22:46初期開発段階であり
00:22:48まだ公開されていない
00:22:49破壊的な変更を求めている
00:22:51だから積極的にコードをクリーンアップしてほしい
00:22:54リファクタリングは大歓迎だ
00:22:56といったような指示です
00:22:58エージェントやAIモデルを後押しし、ファインチューニングされた指示を上書きしたいわけです
00:23:04組み込まれた知識を取り払い、単にコードを追加し続けるのではなく、コードベースを確実に進化させられるようにするためです
00:23:14小規模でも見られることですが、大規模でも当然同じことが起こります
00:23:19レビューに関して彼らは「レビューレンズ」と呼ばれるアプローチを採用しました
00:23:24プランナーとワーカーエージェントがいますが、バグが修正されコードベースが改善されるまでフォローアップを作成しループを再開するには、作業をレビューする必要があります
00:23:38長期運用かつマルチエージェントのシステムではエラーが蓄積するため、小さなミスが根本的になる前に群れ自身が自己修正する手段が必要です
00:23:47これも納得がいきます
00:23:48私たちも小規模な開発で同様の経験をしています
00:23:50レビューエージェントにワーカーの全実行ログを与える、出力のみ与える、あるいはコードベースのみ与えるなど、多くのレビューレンズを試しました
00:24:00異なるトレーニングやペルソナを持つ異なるモデルでレビュアーを動かす試みも行いました
00:24:05単一のレンズですべてを補足することはできませんが、相互補完的なレンズを重ねることで、完璧なコンポーネントがなくても自動運転システムのように人間以上の信頼性に達します
00:24:16レビューにかかる計算コストは、監査対象の作業自体よりはるかに安価なため、リターンが高いものです
00:24:21この積層型レビューシステムが、実行品質を維持できた大きな要因だったと考えています
00:24:28ここでの重要なポイントは
00:24:30単一または複数のレビューエージェントにコードベース全体をレビューさせるのは不可能だということです
00:24:39量が多すぎます
00:24:41代わりに、全トランスクリプトを与えるか、出力のみにするか、コードベースのみにするかといった異なる手法を試しました
00:24:47そして最終的に分かったのは、異なる観点に特化した異なるペルソナを持つレビュアーを用意することが有効だったということです
00:25:00コードベースと、ワーカーが何をしたかという一部の情報を提供するのだと理解しています
00:25:06複数のレビュアーの出力を組み合わせることで総合的なレビュー結果が得られ、それをプランナーが拾い上げて計画に落とし込み、ワーカーに修正させることができます
00:25:23小規模な開発であっても、これは応用できるアプローチだと思います
00:25:28もちろん、私たちはそこまで複雑なものは作っていません
00:25:34しかし経験上、異なる役割を持つ複数のレビューエージェントを用意するのは非常に有効です。例えば1つは「慣用的Rustか？」に焦点を当て
00:25:46もう1つはパフォーマンスやセキュリティ問題に焦点を当てるという形です
00:25:51また別のレビュアーは命名規則のパターンに特化させるなど、目的に応じて設定できます
00:25:58このように視点を分け、レビュアーには適切なコンテキストのみを与えます
00:26:03「ワーカーがこの機能に取り組んだ」といった情報です
00:26:07ワーカーの計画とおおまかな手順の情報だけを与え、それ以上は渡しません
00:26:15そして各レビュアーからの出力をまとめ、別のレビュアーで統合することもできます
00:26:22レビュー結果自体をさらにレビューさせる手法も気に入っています。モデルは何か問題を見つけたがる傾向があるからです
00:26:36どんなコードを渡しても、たとえ1行のコードであっても
00:26:405つも問題を見つけ出してくるような感覚があります
00:26:43そのため、指摘事項を分類し、実際には問題でないものを除外するレビュアーを置くのは非常に効果的です
00:26:55著者らも書いているように、適切なレビュアーの組み合わせや階層化が質の高い成果を生み、それを実装へと繋げることができます
00:27:06もちろん、タスクの規模や構築するソフトウェアの規模によります
00:27:11多くのソフトウェアにとってここまでの仕組みは複雑すぎますが、将来のソフトウェアエンジニアリングやシステムの姿を垣間見ることができ、個人的に大変興味深いです
00:27:27最後に彼らが行ったもう一つの試みは、エージェントに環境を形成させたことです
00:27:32エージェントに「フィールドガイド」というドキュメント群を作成させました。全体タスクのコンテキストとして機能させること以外特別な指示は与えず、学んだことや特定された主要課題などの共有メモリを構築させました
00:28:00メモを残し決定事項を記録するための、拡張メモリシステムのようなものを導入したわけです
00:28:10RustによるBUNの書き換え実験と同様、全体として非常に興味深い実験だと感じます
00:28:16恐ろしく感じる部分もありますし
00:28:17その気持ちもよく分かります
00:28:18今後はすべてのソフトウェアをこのように作るべきだ、と結論付けるべきではありません
00:28:24まず第一に、これは本番運用できるレベルのソフトウェアではありません
00:28:28本番レベルにするには、かなりの時間と労力がかかるはずです
00:28:33これを軽視してはいけません
00:28:35数時間でこのようなものを作り、あと数時間足せば本番運用可能になるという話ではないのです
00:28:43最初の80%を達成する方が、残りの20%を仕上げるよりずっと早いことは
00:28:48誰もが知っている通りです
00:28:49それが重要な教訓の一つです
00:28:51また、SQLiteの再構築という今回の特殊なタスクでは、ドキュメントとテストスイートが提供されていた点を認識することも重要です
00:29:04新規プロジェクトでは存在しないような、非常に詳細な仕様が存在していたわけです
00:29:13新しいソフトウェアを作る場合、20年以上続くソフトウェアのドキュメントほど詳細な仕様書はありません
00:29:24また、仮にドキュメントしか与えられていなかったとしても、SQLiteのソースコードやTursoによるRust再実装などは、使用されたモデルの学習データに含まれていた可能性が高いでしょう
00:29:46つまり、モデルにとって完全に未知の課題だったわけではありません
00:29:51試行錯誤や反復作業が不可欠となる、完全新規のソフトウェア開発とは事情が異なります
00:29:58途中で仕様変更することなく、まったく新しいソフトウェアをゼロから構築するのは極めて困難であり、不可能とさえ言えます
00:30:11最初に完璧な仕様書を書いて終わり、ということはあり得ないからです
00:30:17開発の規模に関わらず、作っている最中に常に新しい発見や変更したい点が出てきます
00:30:26したがって、今回の件が一般的なソフトウェア開発の未来像をそのまま表しているわけではありません
00:30:34とはいえ、実に興味深い実験です
00:30:37非常に興味深い実験であり、私たち全員にとって重要な学びが含まれています
00:30:43作業の分割や、適切なコンテキストを持ったフレッシュなコンテキストウィンドウの活用など、真新しくはないものの価値ある学びです
00:30:50将来的に新しいバージョン管理システムが登場し、必要とされるかもしれないという面白い視点もありました
00:30:57そしてもちろん、マルチエージェントのオーケストレーションが主流になっていくことも示されています
00:31:01これらの実験は、こうしたエージェントシステムを設計する人間や、新規ソフトウェアのアーキテクチャを決定する人間の重要性を証明しています
00:31:21仕様を作成し、アーキテクチャを考案し、それを実装・レビューするエージェントシステムを構築すること―これが重要です
00:31:336年前の開発手法とは大きく異なりますが、私たちはまさにこの方向へ向かっており、個人的にとてもワクワクしています
00:31:45エージェントシステムの構築とソフトウェアアーキテクチャの設計の両面で、システム思考の領域へ移行しつつあるのは非常に面白いことです
00:31:59そしてその両者を連携させていくわけです
00:32:01このような実験は非常に興味深いと感じます
00:32:04得られた学びは大変示唆に富むものです
00:32:07シンプルに簡略化した形であれば、日常のソフトウェア開発プロジェクトにも役立つ洞察があるでしょう
00:32:17みなさんはこのような実験についてどう思われるか、ぜひご意見をお聞かせください