自動研究、Claude、そして制約付き最適化（13 分読了）

## イントロダクション AI を使って数十人の人間の仕事をこなしているという主張は、どこを探しても見つかるでしょう。私は根拠のない改善の主張には常に懐疑的です。そこで、その懐疑心を実践に活かすことにしました。これは X での「ループ」に関する議論と少し重なる部分がありますが、それは偶然です。 ここ数週間で、Kaparthay の『Autoresearch』をテーマにしたプロジェクトを組み立てました。従来の機械学習や数値最適化の問題ではなく、それでも何らかの客観的な成功指標を持つ問題を選びたかったのです。 このような問題を選んだのは、私が関わってきた多くのプロジェクトや製品がそのような構造をしているからです。変更したい指標（増やすか減らすか）があり、それを測定する方法もあれば理想的です。また、何らかの制約もあるでしょう。例えば、「この機能ではページ読み込み時間が 500ms を超えないようにする」といった制約です。 未知の状態から成功に至る道筋が、機械学習のように明確な勾配最適化であるような問題にまだ取り組んだことはありません。むしろ、ある作業を完了し、『現実世界』でテストし、そのパフォーマンスを確認した上で、次のステップについて判断を下すことが一般的です。すべての変更が肯定的な結果をもたらすわけではなく、局所的に最適な結果をもたらす道へと深く入り込んでしまうのは容易です。 私は、主に監督なしの状態で AI エージェントに大きな作業を任せる方法について直感的な理解を得るための実験を望んでいました。この結果を実現しようとする既存の仕組みとして、Ralph Loops や、現在 Claude Code に組み込まれている /goal コマンドなどがあります。今回の設定との違いは、成功の主要指標として定量化可能な数値を選択し、いくつかの合格・不合格制約で問題に境界を設ける点です。 複雑化させすぎないよう、私はファイル圧縮の問題を選びました。これは目的と制約が単純だったからです。最終的なファイルサイズが小さいほど、圧縮アルゴリズムは優れています。この問題には 2 つの制約を追加しました。1 つ目は、非圧縮ファイルが完全に一致する必要があるという点で、2 つ目は圧縮もデコードもそれぞれ 300 秒を超えてはならないという点です。私は意図的に速度の最適化を行わず、時間のカットオフを設定し、タイムアウトが無限ループを検出・停止できることを踏まえて、プロセスをほぼ監督なしで実行できるようにしました。 ファイル圧縮のもう一つの優れた点は、最終的なベンチマークに使用できる既存ツールが多数存在することです。これは小規模な概念実証（PoC）だったので、新しい最上位クラスのアルゴリズムを作成できるとは期待していませんでした。 それでも、この自作版が既存のツールに対してどの程度機能したかを知ることは、ライブラリや市販ソリューションからどれほど離れる可能性があるかというデータポイントを提供するのに役立ちます。エージェントが外部依存関係によって以前解決されていた問題を迅速かつ確実に解決できるのであれば、サプライチェーン攻撃などのリスクよりも社内ソリューションの価値が上回るある時点が存在するはずです。これは単一の実験で答えが出るようなことではありませんが、これ以上検討する価値があるかどうかを判断する助けにはなるでしょう。 ## 方法論 ## 問題設定 まず、このアプローチが実現可能であるかを確認することが目的であり、特定のモデルのベンチマークを行うものではないことを思い出してください。 次に、本題に入る前に、このプロジェクトに関するすべてのコードは以下で利用可能です：[https://github.com/smitec/agent-compression](https://github.com/smitec/agent-compression?ref=elliotcsmith.com) 今回の作業では、Sonnet 4.6 の Claude Code をデフォルト設定で使用しました。異なるモデルであれば別の対応をした可能性はありますが、それはまたの機会に譲ります。 エージェントが関与する前に、プロジェクトのための基本的な骨組みを構築しました。型システムを通じて「関数のシグネチャを変更しない」といった暗黙的な制約を容易に適用できるため、Rust を選択しました。圧縮と展開を行うスタブ（stub）を作成しましたが、これらは単にバイト列をコピーするだけのものです。これは「動作」しますが、データに対して何の圧縮も提供しませんでした。 その後、文字列と単純なファイルの両方に対して圧縮・展開の往復処理を検証するためのいくつかの基本的なユニットテストを実装しました。これらのテストは網羅的なものではありませんでしたが、圧縮および展開関数がビット完全な往復処理という目標を遵守していることを確認するものでした。 そこからベンチマークスクリプトを作成しました。このスクリプトは、動画、音声、テキストにわたるパブリックドメインのファイルサンプルを取得し、さまざまなサイズのランダムデータで埋められたファイルも作成します。これらのファイルの多くはすでに何らかの形で圧縮された形式であったため、より非圧縮な形式に変換するステップを追加しました。これにより、全体の圧縮ベンチマークに加えて、ファイルごとの詳細なベンチマークが可能になります。 このサンプルセットには、高エントロピーと低エントロピーのファイルフォーマットが混在していました。優れた圧縮アルゴリズムは、低エントロピーのフォーマットを縮小し、高エントロピーのフォーマットはほとんど変更しないはずです。フォーマット固有のバイトによるファイルサイズのごくわずかな変動は予想されますが、全体的に意味のある方法でファイルサイズが増加することは望ましくありません。 サンプルセットの中で最大のファイルは約 150MB でした。圧縮はさらに大きなファイルにおいてより有意義な結果をもたらす可能性がありますが、特に後続のステップでは非常に遅いテストループになってしまうため、今回はその規模には至りませんでした。 ベンチマークスクリプトは各ファイルを順にループ処理し、個別に圧縮した後に展開しました。スクリプトは、展開されたファイルが元のファイルとビット単位で一致しているかを確認し、サイズの変化と、圧縮・展開の各ステップにかかった時間を記録しました。各ファイルの処理には主に意図しない無限ループを検出するために 300 秒のタイムアウトが設定されていました。 スクリプトは、ファイルごとの変更を概説する debug.csv ファイルを生成し、改善が見られた場合は主要な指標を results.csv ファイルに書き込みました。注目すべき点の一つとして、結合圧縮指標は（総圧縮バイト数）/（総元バイト数）で計算されました。私はまた、サンプルセット全体における平均パーセンテージ圧縮率を採用することも検討しました。この選択の違いとその影響については、後ほど詳しく説明します。 これらすべての設定が整った後、スタブ実装に対してベンチマークを実行し、実験を開始する準備ができたと判断しました。 ## Iterations 比較的厳密に制御するために、各イテレーションの前に Claude のコンテキストをクリアし、モデルには「現在のコードベースを見直し、改善の別のイテレーションを試みてください」とプロンプトしました。Claude Code はデフォルトでプランモードに設定されているため、私はまずプランを待機し、その後簡易レビューを経てそのプランを採用し、エージェントに単独で実行させました。 私はこの実験において、計画のいずれも意図的に変更せず、完全に自律的な選択を行わせるようにしました。介入が必要だったと思われる場面がいくつかありましたが、それは今後の教訓として学びました。 10 回の反復を実行した後、一般的な圧縮ツールとの比較ベンチマークと、データ固有の最適化を制御するための新しいデータセットを用いた最終的な拡張ベンチマークを実施しました。これらの反復は約 2 週間にわたって実行され、通常は他の作業をしている間に開始して放置される形でした。この長い期間設定は実験の設計上の意図というよりは、むしろ他の作業中に Claude Code の利用制限を消費しすぎないための措置でした。 ## 結果 ## 反復 最初の反復では、エージェントが独自の実装 LZSS を生成しました。これは比較的標準的でよく知られた圧縮手法です。続く 9 回の反復は、この手法の拡張であり、エントロピーを除去しようとして新たなエントロピーチェックと符号化技術を追加するものでした。 各ループで要した時間や使用トークン数は大きくばらつきました。Claude Code の /usage コマンドに基づく平均では、1 回の反復あたりのコストは約 4 ドルでした。これはデフォルト設定での結果であり、モデルによって価格が大きく変動するため、この金額に過度な意味を見出しているわけではありません。 興味深いことに、モデルは特定の反復内で一度以上の変更セットを行うことはありませんでした。仮説を形成し、コードを追加し、ベンチマークを実行して「完了」と宣言するのみです。これはおそらく、/goal コマンドを使用しないプロンプト設定に起因するものと考えられます。 以下の結果は、モデルが圧縮率の改善を継続して行えたことを示しています。特に「圧縮可能」比率に注目すると、タスクの要件が非常に緩いにもかかわらず、私の意見では結果は非常に印象的でした。 ![image](https://storage.ghost.io/c/ea/1d/ea1d42ce-212e-4795-993b-1716a8c550ed/content/images/2026/06/evolution.png) ## ベンチマーク 最終結果を評価するために、同じデータセットに対して複数の圧縮ツールを実行しました。これらのツールは、たまたま既にインストールされていたものを選定したものです。これはベンチマーク選択において最も堅牢な方法ではありませんが、一般的なツールの比較という点では反映されています。 全体的に、カスタムアルゴリズムは概ね良好なパフォーマンスを示しました。音声および動画の圧縮においては特に優れており、他のカテゴリではやや劣るか同等の性能でした。音声や動画でのスコアが低かったことは、最適化に使用された指標を考慮すれば驚くべきことではありません。これらのファイルタイプが圧縮されるバイト数の大部分を占めていたため、総合スコアはそこでの勝利によって最も大きく変動しました。 ![image](https://storage.ghost.io/c/ea/1d/ea1d42ce-212e-4795-993b-1716a8c550ed/content/images/2026/06/ratio_by_type.png)このプロジェクトの目的に戻ると、これは画期的な圧縮アルゴリズムを見つけるための探求ではなく、エージェントにソフトウェア最適化を指示することに関する直感を養うことを目指したものでした。 ## Learnings このプロジェクトのまとめとして、もしこの記事が長すぎて読みたくない方のために、高レベルな教訓をいくつか挙げておきます。全体として、堅牢で測定可能かつ適切に制約された指標を見つけて最適化できるのであれば、このような自動研究/ループ型の作業は理にかなっていると私は考えます。しかし、そのような指標を見つけることは往々にして難しいものです。 ## Models race to be 'done' セットアップを観察・レビューしている間、私が感じた全体的な雰囲気は、このモデルが可能な限り早く「完了」したいという欲求を持っているということでした。これを踏まえると、本番環境向けの実装においては、明示的なループ機構を設けることが重要だと考えられます。 ## The choice of objective function is key もう一つの観察点は、300 秒という時間パラメータがおそらく非常に緩すぎる制約だったということです。これは変更による悪影響（ダウンサイド）を制限するには有用でしたが、モデルは常に圧縮率の最適化のみを行っていました。ミッチェル・ハシモト氏が最近 X (旧 Twitter) のスレッドで捉えた現象です: フレームタイムとテスト測定を最小化することを目的に、レンダラーを最適化するエージェントをループさせています。結果として、実行時間は 88ms から 2ms に、アロケーション数は約 150K から 500 にまで削減されました。素晴らしい成果に見えますね？いいえ、それは間違いです。まさにこれこそが、エージェントの精神病（agent psychosis）がなぜ深刻な問題なのかを示す例なのです。 As… — Mitchell Hashimoto (@mitchellh) [May 28, 2026](https://x.com/mitchellh/status/2060088112257372610?ref_src=twsrc%5Etfw&ref=elliotcsmith.com) この手法の実世界への適用には、最適化するより複雑な「スコア」が必要か、あるいは後で速度の最適化に切り替える必要があります。コード長やメモリ使用量などの他の二次指標についても同じことが言えます。 ![image](https://storage.ghost.io/c/ea/1d/ea1d42ce-212e-4795-993b-1716a8c550ed/content/images/2026/06/speed_vs_ratio.png)これは決して新しい問題でもなく、エージェントベースのコーディングに固有のものでもありません。エンジニアリング組織において「成功」や「完了」をどう測るかという課題は古くから存在しています。現実的には、あらゆる指標または指標の組み合わせにはトレードオフが伴うものです。おそらく、この事実に慣れ、ニーズの変化に応じて焦点を時間とともにシフトしていく覚悟が必要になるでしょう。 最近、PostHog が新製品「PostHog Code」でこの分野での取り組みを行っていることを知りました。ユーザーがプロダクト分析をコーディングエージェントの文脈に持ち込み、意思決定をより適切に導けるようにするものです。まだ試していませんが、これは正しい方向性のように感じられます。 ## 実世界の目標は測定がそれほど単純ではないことが多い 指標について議論する際、この手法が「実世界」でどのように異なるかを考慮する価値があります。圧縮ツールには非常に短いフィードバックループがあります。ファイルを取得し、圧縮し、展開して結果を比較するだけです。もしこの変更がより広範なもので、「チェックアウトのコンバージョン率を向上させる」といった場合であれば、サンプルを集めるのに多くの時間が必要となり、データのノイズの影響を大きく受けることになります。 一つの解決策は、コンバージョン率の向上を期待・仮定して、プロキシ指標を最適化することです。例えば「ページ読み込み速度の改善」や「チェックアウトに必要なクリック数の削減」といったものが該当します。これらは確かに反復しやすくなりますが、最終目標と緩やかにしか相関しないプロキシ指標に対して過剰に最適化するリスクが生じます。複雑な指標と完全に線形相関するプロキシ指標を見つけるのは困難です。 ## 制限事項 ここでは制限事項についてごく簡単に言及します： - モデルの選択、これらの結果の有効期限はどれくらいか。モデルは常に変化しており（Sonnet 5 が本日リリースされた）、現実的には同じ試行を今日実施した場合の結果は大きく異なる可能性が高い。 - コスト、これは妥当だろうか。Claude の見積もりによると、各ループでトークン使用料として約 4 ドルがかかっている。「実用的な」製品でこれを行うには ROI（投資対効果）が必要だ。10 ループで 40 ドルは決して高いハードルではないが、コードベースの変更ごとにこのようなループを実行すればコストがかかる可能性がある。 - 単一マシン・スレッド単位の結果。圧縮ベンチマークは CPU によって大きく変動する。これらはすべて M2 Macbook Pro で実施されたが、他の環境では結果が異なっていたことは間違いない。 - 最適化関数の選択。これが最大の要因であり、前述の通り何度も言及されているが、もし平均値（compressed / raw）や中央値など別の指標を選んでいたなら、より良い方向への道筋は全く異なるものになっていたはずだ。私は過去に指標の選び方について多く書いてきたが、これは人間だけでなくエージェントにも当てはまる話だ。

自動研究、Claude、そして制約付き最適化（13 分読了）

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト