ハクソク

世界を動かす技術を、日本語で。

HNを表示: 私が構築したOSSエージェントがGemini-3-flash-previewのTerminalBenchでトップに立ちました

6時間前原文(github.com)

概要

  • DiracはオープンソースのAIコーディングエージェントで、高精度・高効率を実現
  • Terminal-Bench-2で65.2%のスコアを記録し、公式・有力モデルを上回る成績
  • APIコストを平均64.8%削減しつつ、作業の正確性・速度も向上
  • 複数ファイル同時編集やAST操作など高度な最適化機能を搭載
  • チートなしの完全オープンソースで評価・検証が容易

Dirac: 高精度・高効率なオープンソースAIエージェント

  • Diracは、コンテキスト長による推論精度低下問題を解決するために設計されたAIコーディングエージェント
  • 重要な情報だけを厳選してコンテキストに含めることで、精度・コスト・大規模変更の一括処理性能の向上を実現
  • APIコストを平均64.8%削減しながら、従来よりも高精度・高速な作業を提供
  • ハッシュアンカー編集、AST操作、高度な最適化などを活用
  • MCP（Minimal Command Prompting）非対応で、必要最小限のプロンプト設計を重視

主な特徴

  • ハッシュアンカー編集：安定した行ハッシュを使い、従来の行番号ベース編集の誤差を回避
  • ASTネイティブ精度：TypeScriptやPython、C++など言語構造を理解し、関数抽出・クラスリファクタリング等を100%正確に実行
  • マルチファイルバッチ処理：複数ファイルを1回のLLMラウンドで編集し、レイテンシ・APIコストを大幅削減
  • 高帯域コンテキスト：関連情報のみを厳選し、トークン消費を最小限に抑えつつ高速化
  • 自律的なツール利用：ファイル読み書き、ターミナルコマンド実行、ヘッドレスブラウザ操作などを承認フロー付きで実施
  • プロジェクト固有のカスタマイズ：AGENTS.mdや.ai/.claude/.agentsディレクトリからスキル・指示を自動取得
  • ネイティブツールコール専用：信頼性・性能重視のため、ツールコール対応モデルのみサポート（MCP非対応）

ベンチマーク・コスト比較

  • TerminalBench 2.0でgemini-3-flash-previewを使い65.2%スコアを記録
    • Google公式（47.6%）、**Junie CLI（64.3%）**を上回る
    • ベンチマーク固有情報やAGENTS.mdファイルの挿入なし
  • 平均APIコスト：$0.18（他エージェント比で約2.8倍安価）
  • 全タスク100%正解を複数回達成し、再現性も高い
  • Clineリポジトリのバグによるコスト過小報告があったが、PR提出済みで今後修正予定

導入方法

  • VS Code拡張機能：VS Code Marketplaceからインストール
  • CLI（ターミナル）：npmでグローバルインストール
    • コマンド：npm install -g dirac-cli
  • 認証：dirac authで認証、または環境変数でAPIキーを設定
    • 対応APIキー：Anthropic, OpenAI, OpenRouter, Gemini, Groq, Mistral, x.ai, HuggingFaceなど
  • 主なコマンド例
    • dirac "prompt"：インタラクティブなタスク開始
    • dirac -p "prompt"：プランモード（戦略確認後に実行）
    • dirac -y "prompt"：Yoloモード（全自動承認、簡易修正向け）
    • git diff | dirac "レビュー"：変更内容を直接パイプ
    • dirac history：過去タスクの履歴・再開

ライセンス・クレジット

  • Apache License 2.0の下でオープンソース提供
  • ClineプロジェクトをベースにMax Trivedi（Dirac Delta Labs）が開発

ベンチマーク公正性に関する補足

  • チート報告が多いTerminalBench 2.0において、Diracは完全に公正な方法で評価
    • AGENTS.mdやskills.mdの挿入なし
    • リーダーボード準拠のCLI実行、リソース・タイムアウトの改変なし
    • 公開GitHubバージョンと同一のオープンソースコードで実施
  • Pull Requestの承認遅延により公式リーダーボード反映が遅れているが、評価内容は公開済み
  • 実験から、ベンチマーク環境（ハーネス）の影響が非常に大きいことが判明

まとめ

  • Diracは高精度・高効率なオープンソースAIコーディングエージェント
  • コスト削減・正確性・速度で業界トップクラス
  • 誰でも再現可能な完全公開・チートなし評価
  • 多機能かつカスタマイズ性も高く、現場導入も容易

Hackerたちの意見

Diracの面白い機能: 1. ファイル編集のために最適化されたHash-Anchored編集を使ってる（https://dirac.run/posts/hash-anchors-myers-diff-single-token） 2. 言語のASTを利用して、コンテキストに何を取得するかを決めて、大きなコードファイルの読み込みを完全に回避 3. すべての操作をバッチ処理。大量の読み込みや編集を同時に行う（deepseek-v4-flashのデモ動画はここで見れるよ https://www.reddit.com/r/LocalLLaMA/comments/1suhdki/tested_...) 4. モデルがその場で分析するためにコードを実行できるようにしてるから、必要に応じてbash/python/perlスクリプトを書いて作業をこなせる 5. コンテキストのキュレーションや機会を捉えたコンテキスト更新がたくさん。つまり、モデルが次に何を聞くか確信できるものはすべてコンテキストに入れるってこと。
└
なんでASTが編集や変更のスコープ、コードのパースにもっと使われないのか、ずっと不思議だった。確か「grep」が同じくらい効果的だって言ってる記事を読んだ気がする。それに関しては納得できたけど。
└
> 言語のASTを利用して、コンテキストに何を取得するかを決めてるってことは、パーサーがある特定の言語でしか機能しないってこと？
└
ast-grepやgritqlを取り入れることを考えた？おめでとう、素晴らしい仕事だね。
└
どこかにツールの完全なリストってある？特にASTをどうやって公開するかに興味があるんだ。自分のハーネスの試みでは、ツールの数を絶対に最小限に抑えたくて、execute_pythonツールを通じてASTライブラリを使うことをちょっと試してみたんだけど（システムプロンプトにいくつかの例も含めて）。結果はまあまあだったけど、ほとんどのモデルはripgrepを好んでた。
└
> すべての操作をバッチ処理する。大量の読み取り/編集を同時に行う... これが何を意味するのか分からなかったから、ソースを見てみた。どうやら、ツールAPIが複数のターゲットをリストパラメータとして受け取るように設計されているみたいで、モデルが適切に並列ツール呼び出しをすることを期待するのではないみたい。（これ、私の経験とも一致してるけど、モデルは大量の並列呼び出しを同時に行うのをためらうことが多いし、特に弱いモデルではそれが顕著に見える。）
└
アンカーに基づく編集は、新しいアンカーをコンテキストに追加する必要があって、diracはそれをdiffを使ってやってるんだ。じゃあ、これが検索と置換よりも効率的（トークン的に）なのはどういうこと？？ ハッシュごとに1トークンでも。コードは書くよりも読むことが多いから、これらはどんどん増えていくよね。一度、安定したアンカーを使って実験したことがあるけど、単一トークンよりも長くて、逆に劣化したと思った。結論として、diracが見ている効率は、デフォルトでファイルのスケルトンを表示することから来てるんじゃないかな。
└
どれが一番効果的かを調べる因果関係の調査をするのはすごく面白そうだね。どれがどれだけ重要かを定量化できたらいいな。もしかしたら、全部が一緒に出荷されることで、部分の合計以上の相互作用があるのかもしれない。
└
最初の1700個のシングルトークンアンカーがなくなったら、どうやって2つのトークンアンカーを選ぶの？1700個の中から2語の組み合わせになるのかな。
まだ試してないけど、なんでpiで拡張を書く代わりに新しいハーネスを実装することにしたのか気になる。今までやったことからすると、拡張APIはかなり充実してるし、Hash anchored editsもpiで実装できるはず。とにかく、プロジェクトを見せてくれてありがとう。後でチェックしてみるね。よろしく！
└
数ヶ月前の午後、Clineが遅すぎてイライラして、内部を見てみることにした。いくつか変更を加えることにしたら、どんどんハマってしまった。約7万行の変更、さらに4万行の削除をして、2ヶ月後にここにいるって感じ。
AIハーネスがどれだけ重要かって、本当に面白いよね。Googleの公式結果で48%から65%に跳ね上がるのはすごいことだと思う。モデルを比較する結果はよく見るけど、ハーネスを比較する結果はあまり見ない気がする。同じモデルを使ってハーネスの結果を比較するリーダーボードってあるのかな？
└
ほんとにあったらいいのに！自分で作ろうかとも思ったけど、利害の対立になっちゃうからね。
└
モデルとハーネスの直積を比較したいね。
└
未来は人間のような中央集権的な知能じゃなくて、タコのような分散型の知能になるんじゃないかな。もっと「ハーネス自体を賢くする」ことに焦点を当てる感じで。
「ハーネスがどれだけ重要かは驚くべきこと」ってのは正しい見解で、これが長続きするべきだと思う。モデルはレンタブルだし、プロンプトもレンタブル。ベンチマークの数字はほとんどハーネスの影響だよね。同じハーネスの下でGeminiをSonnetに入れ替えても、モデルの周りのハーネスを入れ替えるよりもベンチの差が小さい。君がリンクしたcheating-agentsの投稿も、違う視点から同じ観察をしてる。測定されてるのはハーネスで、モデルはただの基盤に過ぎない。ただ、コンテキスト管理は今日のモデルの問題を解決しているようで、普遍的な特性というよりは、数世代後には時代遅れになってしまうかもね。ツールがRAGコンテキストの注入を時代遅れにしたように。
└
だからARC-AGI-3ではハーネスの使用が許可されてないんだ。モデルがハーネスを作らなきゃいけないんだよ。
Kimi 2.6を使ってRustのコードベースをリファクタリングするためにDiracを使ってるよ。クリーンアーキテクチャのデザインを強化中で、作業範囲はBeadsのエピックにサブ課題としてまとめてある。計画はgpt5.5でやって、gpt5.5が作業が完了してるかチェックしてくれてる。Diracは大規模なコードベースのリファクタリングにはOpenCodeよりも生産性が高いことが分かった。OpenCodeは.rsファイルを壊しちゃって、コードを戻さなきゃいけなかったからね。
└
gpt-5.5では、Diracも使ってるの？
1. 他のファミリーから少なくとも1つのモデルをベンチマークするのがいいと思う。そうすれば本当に一般化するかどうかが分かるから。Minimax 2.7は手頃な候補に見えるね。それまでは、Gemini 3 Flashに過剰適合してるかどうかは分からない。2. それまでの間、ランディングページにはすべての数字がGemini 3 Flashでの実行からのものだって書いておく必要があるよ。今のところGeminiについては全く言及がないから。3. この場合、安いということはモデルが同じなら速いってこと？もしそうなら、タスクの完了までの時間を強調するためにこれをベンチマークに追加してもいいんじゃない？もし逆に時間がかかる（あまり考えにくいけど）なら、それを透明にするのもいいと思う。4. スキルや（ネストされた）AGENTS.md、MCPなどをサポートしているかどうかも記載しておくと、移行を考えている人にとっては良いかも。
└
いいポイントだね。1. オープンウェイトモデルのベンチマークを試みてるけど、推論が遅くてタイムアウトに引っかかっちゃうんだ（ターミナルのベンチタスクには厳格なタイムアウトがあって、変更できない）。ここに不満を書いたよ https://www.reddit.com/r/LocalLLaMA/comments/1stgt39/the_fru... 2. 完了した（GitHubのREADMEを更新した） 3. はい、平均的には時間が短かったけど、ランダムなタイミングでモデルの出力が遅くなることがあるから、厳密なベンチマークはしてないよ。4. これについての情報も追加したよ。
すごく興味深いね、特にハーネスの点について。パフォーマンスのどれくらいがラッパーツールに依存してるのか（クレジットがほとんどなくなった時、モデルを小さいのに変えて、もっと構造的なプロンプトを与えようとすることが多いんだけど、gpt-5.4-miniの構造の方がgpt-5.4の雰囲気よりもよく機能することが多い）。これがきっかけで「スキル蒸留所」を始めようと思ったんだ。[0] 良いエージェントのワークフローアイデアを小さくて検査可能なインストール可能なスキルに変えていく感じ。最初のものはDiracの構造的コードワークフローに基づいたdirac-workflowだよ。ただのDiracのクローンじゃなくて、ランタイムや永続的なASTインデックス、ハッシュアンカー編集エンジン、ベンチマークハーネスはないんだ。小さなASTヘルパーとワークフローディシプリンを持ったポータブルスキルって感じ。Diracのリポジトリでも使ってみて、短いレポートも含めたよ。元の著者からのフィードバックがあれば嬉しいな、プロンプトとツール[1]が代表的かどうか知りたい。 [0] https://github.com/ouatu-ro/skill-distillery [1] https://github.com/ouatu-ro/skill-distillery/blob/main/skill...
すごい！おめでとう！最近の数週間、自分のハーネスを作るのが一番の楽しみになってるんだけど、もちろんいつも途中でやめちゃうんだよね…でも、以下のことについて君の経験を聞きたいな。1. コンテキスト管理 - 特に古いツールコールの応答を整理したり、ツールの出力を短縮したり、自動的にコンパクトにすること。これがすごくうまくいってるんだ。コンテキストを減らすメリットが「すべてを覚えておく」ことから得られる利益を大きく上回る気がする。ただ、いつも短い要約は残してるけどね。2. 「サブエージェント」 - 最近の試みは、メインエージェントには一切ツールを見せず、サブエージェントがクラシックな検索/実行/取得ツールにアクセスできる「run_agent」ツールだけを使うことにしてる。サブエージェントが簡潔な要約を返せば、親エージェントのコンテキストがずっときれいに保たれるんじゃないかと思ってる。まだ実験中だけど、サブエージェントのプロンプトを書くのは、現在のトレーニングセットから外れすぎてるかもしれない。
└
ありがとう。1. コンテキスト管理 - APIがキャッシュをサポートしていない限り、整理はしない方がいいよ。毎回整理するとキャッシュが壊れて、90%の割引キャッシュ率を失っちゃうから。2. Diracが受け継いだClineのサブエージェント機能を改善するために少し作業したよ。私の経験では、すべてのモデルが効果的に作業を委任するように訓練されているわけではないから、君の経験は違うかもしれない。注意すべき一般的な落とし穴は、1つ以上のサブエージェントがループにはまったり、何らかの理由で返さなかったりしたらどうなるかってこと。メインエージェントから彼らを制御するメカニズムが必要だよ。
これを見て、君がコントロールしているエンドポイントにテレメトリを送信していることに気づいたよ： https://dirac.run/v1/event。明らかに敏感な情報を送っているわけではないし、悪意があるわけでもないようだけど（ただ、APIエラーが送信されているのは見えるから、敏感な情報が漏れる可能性があるかも）、君がこのプロジェクトの唯一の開発者だと思うとちょっと怖いよね。それに、オプトアウトもできるし。ごめん、私には無理だな。
└
これが全てのテレメトリだよ：1. dirac.run/v1/eventへのテレメトリ — マシンID、トークン使用状況、モデル情報、イベント、エラー（最初の500文字）、プラットフォーム情報を送信。ハードコーディングされたAPIキー。デフォルトはオプトイン（設定は「unset」、ではなく「disabled」）。2. dirac.run/v1/event/decideからのフィーチャーフラグ — 60分ごとにマシンIDでポーリング。常に有効で、テレメトリのオプトアウトに依存しない。コード変更なしでは無効にできない。3. ウェブツールはapi.dirac.runを通る — ウェブ検索とウェブ取得ツールはDiracのAPIサーバーを通じてプロキシされ、リクエスト内容とシステムヘッダー（プラットフォーム、バージョン、マシンID）を送信。4. モデルリストの取得 — Anthropicプロバイダーを使っているときでも、OpenRouter、HuggingFace、Groqなどのモデルリストを呼び出す。
└
ありがとう！Clineのフォークだから、テレメトリのメカニズムは受け継いでるんだ。問題のデバッグに役立つかもしれないから、そのままにしておいたよ。悪意は全くないし、個人を特定できる情報を作成したり保存したりすることもないからね。
その機能の一部をCLIツールに抽出してくれたら嬉しいな。そうすれば、どのコーディングエージェントでも使えるし。