A practical guide to hill climbing｜Cline、ヒルクライミング法による性能向上ガイド | AIニュース最前線

![image](https://storage.ghost.io/c/d6/fe/d6feb101-a8e6-444b-bae8-3ca714794abb/content/images/2026/02/Juan_P_Flores_mountains_and_river_with__hundreds_of_four-poin_c036eec3-370e-4542-996a-80eb18f5fd8a_0.png) あるパートナーから、Cline のベンチマーク数値について問い合わせがありました。当時、第三者によるベンチマークでは、Cline は Cursor や Claude Code、他のエージェントに比べて劣っている状況でした。私たちはパフォーマンスを体系的に測定・改善する方法を持っていませんでした。 そこで週末の 2 日間にわたり、3 人のチームで Cline を Terminal Bench の 89 の実務的なコーディングタスクに実行させ、すべての失敗箇所を診断し、针对性的な修正を行いました。その結果、スコアは 47% から 57% に向上し、Claude Code や OpenHands、OpenCode を抜いて首位となりました。 このガイドでは、モデルとエージェントの組み合わせをベンチマークし、スコアを改善するために私たちが行った「ヒルクライミング」のプロセスを紹介します。これは Cline のために構築されたものですが、Claude Code、Codex、OpenHands、Cursor、Gemini CLI など、お好みのモデルやエージェントの組み合わせにも応用可能です。 ## ヒルクライミングとは？ ヒルクライミングは、AI エージェントやモデルを反復的に改善する手法です。標準化されたコーディングタスクセットに対して AI コーディングエージェントを実行し、スコアを測定します。その後、プロンプトの微調整、バグ修正、設定フラグの変更など「一つだけ」変更を加えて再度実行し、スコアが向上すればその変更を採用します。逆にスコアが下がれば元に戻します。これを繰り返すのがヒルクライミングです。 コーディングエージェントの評価は、往々にして単発のタスクに限定されていたり、評価手法が飽和していたりするものです。しかし、Terminal Bench は、エージェントとしての一連の流れ全体をテストするための課題と検証器を用意しました。これにより、コーディングエージェントが実行可能な幅広いタスクや、その過程で行われるすべてのステップを包括的に評価・採点することが可能になります。 AI エージェント向けの高品質な評価指標の構築については多くの記事が書かれており、Anthropic の「Demystifying evals」ブログ（リンク）では、高品質な評価指標を設計し実行する方法について詳しく解説されています。 ![image](https://storage.ghost.io/c/d6/fe/d6feb101-a8e6-444b-bae8-3ca714794abb/content/images/2026/02/data-src-image-72f8a2a6-5646-4239-b103-f0cbab3a64a3.png)出典：Demystifying evals for AI agents 前提条件 インフラ、モデル、推論環境のセットアップにはいくつかの準備が必要です。しかし、一度設定が完了すれば、数十もの評価テストを並列かつ高速に実行できるアクティブなパイプラインが利用可能になります。 本ガイドでは、Python、Docker（オプションで Modal または Daytona）、および uv が既にマシンにインストールされていることを前提としています。 このガイドの主要ツールとして使用するのは Harbor です。Harbor は Terminal-Bench の開発者によって構築された、広く採用されているエージェント評価フレームワークです。これにより、評価におけるサンドボックス管理、エージェントループ、ロールアウト監視といった複雑な部分を抽象化して扱えるようになります。 Harbor のタスクは、単なるディレクトリ構成です。Harbor はサンドボックスの起動からエージェントの実行、結果検証、そして環境の破棄に至るまでの試行ライフサイクル全体を管理します。また、異なるデータセットへの対応も可能で、最適化目標に応じてデータセットを柔軟に切り替えることができます。 本リポジトリで主に評価に用いられているのは「Terminal Bench」です。これはターミナル環境内で動作する AI エージェント向けのベンチマークであり、89 の多様なタスクから構成されています。各タスクは複雑さや目的が異なります。今回の評価では、Cline CLI をこれら 89 の全タスクで実行し、全体の成功率を算出します。その結果は集計されたパーセンテージスコアとして提示されます。 Harbor はローカル環境で起動され、Terminal Bench のデータセット全体をダウンロードした上で、Modal 上に 89 個のコンテナを並列に生成して各タスクを処理します。これにより、すべてのタスクが並列実行されるため、評価プロセスを大幅に高速化できます。 ![image](https://storage.ghost.io/c/d6/fe/d6feb101-a8e6-444b-bae8-3ca714794abb/content/images/2026/02/data-src-image-96be27ec-c32d-4218-a7ea-8eef56125f37.png) ### 1. Harbor のインストール ``` pip install harbor # または uv tool install harbor ``` ### 2. API キーの取得 少なくとも 1 つのプロバイダー用 API キーが必要です。評価においては「OpenRouter」の使用が推奨されます。ローカル実行ではインフラやレート制限の問題により他のプロバイダーが不安定になる傾向がある一方、OpenRouter は最も信頼性が高いからです。 理想的な `.env` ファイルの構成は以下のようになります。 ``` export CPUS=14 export MEMORY_MB=8192 ``` export OPENROUTER_API_KEY="sk-or-v1-someotherwords" export API_KEY=$OPENROUTER_API_KEY ここでは CPU とメモリの割り当てを多めに設定しています。Harbor がタスクを実行する際、各タスクが個別にリソースを必要とするためです。 Harbor では、API_KEY を主要な変数として利用し、あらゆるプロバイダーから API キーを取得します。 3. Modal のセットアップ（並列クラウド実行用） Modal を使えば、89 以上のタスクを順次ではなく並列で実行できます。これは高速なイテレーションのために不可欠です。 pip install modal modal setup # 認証フローに従ってください Modal がなくても Docker (--env docker) を使ってローカルで実行は可能ですが、自分のマシンがタスクを順次処理しなければならないため、非常に遅くなります。単一の評価ランでも数時間かかることは珍しくありません。一方、Modal を使えば、評価全体を 35〜45 分で完了させることができます。このプロセスを通じて私たちをサポートしてくれた Modal プラットフォームに心から感謝しています。 セットアップの確認 source ~/.env harbor run \\ -d terminal-bench@2.0 \\ -a cline-cli \\ -m openrouter:anthropic/claude-opus-4.5 \\ --env modal \\ -n 3 \\ -l 3 セットアップが正しく機能しているか確認するには、クイックテストを成功させる必要があります。このテストでは並列で 3 つのタスクを実行しますが、Harbor のセットアップに時間がかかるため、各タスク自体には約 15 分かかります。その後、すべてのタスクが同時に完了します。もしエラーなく正常に終了すれば、セットアップは問題なく機能していると確信できます。 出力の読み方 89/89 Mean: 0.573 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0:45:05 0:00:00Mean = pass rate (0.573 = 57.3%) reward = 1.0 = tasks passed タスク失敗時の報酬は 0.0 です。 AgentTimeoutError は、タスク完了前に Cline の実行時間が尽きてしまったエラーです。 VerifierTimeoutError は、結果検証時にタイムアウトが発生したエラーです。 調整可能なパラメータ これらはすべて、Harbor に対して --ak (agent kwargs) フラグを指定して設定します。これは、当社の Harbor PR (#585) で定義された Cline CLI アダプターにマッピングされます。 Cline を扱う際、多くのパラメータを調整できます。これらの設定はエージェントの微調整や使いこなし方の理解に不可欠です。詳細は agent kwargs のドキュメントをご覧ください。 ヒルクライミングの実践プレイブック ステップ 1：ベースラインの確立 現在の最適構成で、89 タスク分のフルスweep を実行し、スコアを記録します。これが突破すべき目標値となります。 source ~/.env && export API_KEY=$OPENROUTER_API_KEY harbor run \ -d terminal-bench@2.0 \ -a cline-cli \ -m openrouter:anthropic/claude-opus-4.6 \ --env modal \ --ak thinking=6000 \ --ak timeout=2400 \ -n 89 -l 89 \ --override-cpus $CPUS --override-memory-mb $MEMORY_MB このコマンドは、各タスクに 40 分（2400 秒）のタイムアウトを設定して Harbor の評価を全実行します。同時に Terminal Bench 2.0 の 89 タスクも並列処理されます。Modal のセットアップ時間やタスク準備、CLI 実行などのオーバーヘッドを含めると、全体で約 40〜50 分程度かかる見込みです。 ステップ 2：失敗原因の分析 harbor jobs summarize ./jobs/LATEST --failed -m haiku このコマンドは、タスクが失敗した理由をカテゴリ分けします。私たちが発見した一般的な失敗パターンは以下の通りです。 AgentTimeoutError — Cline CLI のデフォルト設定である 600 秒のタイムアウトでは短すぎました。解決策：`--ak timeout=2400` 必要なファイルが見つからない — Cline は検証を行わずに成功と判断してしまいました。解決策：PR #9154（完了前に検証を必須化） コマンドの終了コードが反映されていない — Cline がコマンドの失敗を検知できませんでした。解決策：PR #9156 長時間実行されるコマンドが途中で切断される — ビルド、テスト、トレーニングなどのコマンドが早期に強制終了されてしまいます。解決策：PR #9159 推論エラー（プロバイダーからのレート制限、API プロバイダーの残高不足など） 失敗したケースを扱う際は、まずカテゴリ化して分類することが重要です。どんなにパラメータを調整してもカバーしきれない失敗も存在します。こうしたケースは全体の 25% 程度を想定しており、モデル自体のステップ関数的な改善が必要です。それ以外の失敗については、モデルが愚かな行動をとっているのか、あるいはプロンプトやアルゴリズムロジックの不足により設定が不適切だったのかを確認する必要があります。 発生した失敗の種類を区別し、適切に分類できるかが評価（evals）における真の要諦であり、そこには担当者の勘所が問われます。モデルのどこで間違えたかを正確に見極められれば、その教訓はポストトレーニングやその他の AI プロセスにも活かすことができます。 ステップ 3：コード変更の A/B テスト ここが本格的なヒルクライミング（改善）が行われる場所であり、Cline そのものの向上に直結します： # main ブランチのテスト harbor run -d terminal-bench@2.0 -a cline-cli \ -m openrouter:anthropic/claude-opus-4.5 \ --ak github_user=cline --ak commit_hash=main \ --ak thinking=6000 --ak timeout=2400 \ --env modal -n 89 \ --override-cpus $CPUS --override-memory-mb $MEMORY_MB # PR ブランチのテスト harbor run -d terminal-bench@2.0 -a cline-cli \ -m openrouter:anthropic/claude-opus-4.5 \ --ak github_user=cline --ak commit_hash=saoud/fix-exit-codes \ --ak thinking=6000 --ak timeout=2400 \ --env modal -n 89 \ --override-cpus $CPUS --override-memory-mb $MEMORY_MB スコアを比較し、PR でスコアが向上すれば成功とみなします。 ## ステップ 4: ノイズの多い結果には Pass@k を活用する 単一の試行ではノイズが含まれやすく、実行ごとに数ポイントスコアが変動することがあります。変更による差が僅かな場合や、どちらが優れているか迷う場合は、同じ設定で 3〜6 回実行して平均値を求めましょう。これにより信頼性の高い信号を得られます。 ステップ 1 から 3 の結果に確信を持ちたいとき、特にスコアが数ポイントしか差がない 2 つの設定を比較する際に、この手法を活用してください。 Opus 4.5 に thinking=6000 を適用し、ダブルチェックを 6 回実行した 2 月 8 日のデータ（変更前）は以下の通りです： 0.49, 0.43, 0.45, 0.44, 0.48, 0.46 → 平均 0.458、中央値 0.455 本ガイドでは harbor を Modal と併用していますが、これはローカルマシンでの処理負荷をほとんど増やさないため、`nohup` コマンドを使って並列で多数の評価実行を行うことが可能です。 モデルを微調整する際、どのような小さな変更が効果的か推測できる場合や、複数の異なるバージョンの Cline を試して並列で評価を行いたい場合があります。そのようなケースに対応するため、Cline では `--ak github_user=cline` や `--ak commit_hash=main` というフラグをサポートしています。これを使えば、マージ作業をせずに異なるコミット間でのテストが可能です。 このインフラは決して安価なものではありませんが、ここまでお読みいただいている方なら、おそらく予算に余裕のある企業にお勤めのことと推察します。 ステップ 5：反復こそが全て 上記の手順を通じて、大規模な評価の仕組みや、エージェントが生じうる基本的な失敗パターンについての理解を深めることができます。実際には、エージェントとモデルの対話におけるこれらの失敗モードに対処するだけで、数日間の作業が必要になることもあります。 例えば、私たちは上記の手順に従って進めましたが、Opus 4.5 の初期評価スコアは 47% でした。しかし、評価ハネス（評価枠組み）を微調整した結果、57% まで引き上げることができました。これは SOTA（最良の性能）に匹敵するレベルであり、Claude Code をも 5% 上回る成果です。 ![image](https://storage.ghost.io/c/d6/fe/d6feb101-a8e6-444b-bae8-3ca714794abb/content/images/2026/02/data-src-image-f3dbe96f-7c0e-41d9-ba03-40dcc20b8c7e.png) 今後の展望 私たちは現在も「ヒルクライミング（最適化手法）」の探求を続けており、新しいモデルがリリースされるたびに自動実行を自動化しています。これにより、結果は数時間以内に公開されます。また、他の評価フレームワークや Harbor 互換データセットへの展開も進めています。 一緒にヒルクライミングを行いたい方、あるいは自社のモデルを当社のパイプラインで検証したい方は、X（旧 Twitter）の Ara (@arafatkatze) までご連絡ください。 関連リンク https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents https://novasky-ai.notion.site/skyrl-harbor https://www.primeintellect.ai/blog/lab

Cline、ヒルクライミング法による性能向上ガイド

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

関連記事

調べる

選ぶ

サイト