AI コーディング環境の文脈重視化を提唱

エージェント型開発の最前線

コード生成支援ツールの「ハルネス」に注目が集まる中、Augment Code の VP であるヴィナヤ・ペルネティ氏がモデルや文脈管理について語る。

（写真：プレゼンテーションで話す Augment Code のエンジニアリング担当バイスプレジデント、ヴィナヤ・ペルネティ氏。提供：Augment Code）

現在、AI を活用したコーディングアプリケーションは数多く存在します。大規模言語モデルやそれによって実現されたエージェントの能力が驚異的なものになっている一方で、最近の AI 支援開発における最も注目すべき進展は、モデルそのものというよりも、それらを管理・運用するソフトウェア側にあるのです。

今年の夏、私は Anthropic の Claude Code プロダクト責任者であるキャット・ウー氏にインタビューを行いました。そこで同社がどのようにしてこの管理ソフトウェアを構築しているのかについて話を伺いました。

会話の中でウー氏が繰り返し強調していたのは一つの点です。Anthropic のモデル（およびその直接競合他社のモデル）はあまりにも急速に進化しており、将来を見越した過度な計画を立てたり、特定の方向性を強要する機能や制限を設けたりするのは意味がないというのです。

そのため、Claude Code のプロダクトチームが目指しているのは、彼らが「リーン・ハルネス（簡素な枠組み）」と呼ぶアプローチです。

ハルネス（harness）とは、1 つ以上の AI モデルを囲むように構築されたソフトウェアのことで、モデルがどのように使われるかを決定する役割を果たします。モデルが見る情報や実行可能なアクション、そしてコードベースとの相互作用の方法まで、すべてハルネスが決めるのです。要するに、これはモデルと開発者の実際のプロジェクトの間に位置するレイヤーのようなものです。

Claude Code というアプリケーションおよびそのハルネスにも、特定の機能や設計思想がないわけではありません。しかし、製品チームはむしろ、今後 1 年間で AI モデルがどこまで進化するかを信頼し、それに任せる方向に傾いているように見えます。

ただし、Claude Code 以外にもハルネスは存在します。OpenAI の Codex や Google の Antigravity、そして OpenCode といったオープンソースの選択肢、さらに Cursor や Augment Code といったスタートアップが提供するオプションもあります。それぞれのアプローチには、エージェントワークフローにおいてモデルをどう活用すべきかという異なる機能や重点、あるいは独自の考え方が反映されています。

Claude Code が特に重視している選択の一つは、コードベースの周囲に事前構造化されたコンテキスト（context）をデフォルトで構築するアプローチを避けることです。

「評価結果を見る限り、これらのアプローチには明確な改善が見られません」と彼女は述べています。「私たちは一般的に、特定の機能やツールを減らした軽量なハルネスを提供し、必要に応じて開発者自身に追加の機能を組み込んでもらう方針を好んでいます。」

Augment Code は、両社が必ずしも同じ介入を試しているわけでも、同じ成果を最適化しているわけではないものの、かなり異なる賭けに出ています。同社の製品は、埋め込み（embeddings）、検索モデル、ベクトルデータベースを用いてリポジトリを事前にインデックス化し、概念的に関連するコードを検索します。この議論の別の側面を知るため、私は Augment Code のエンジニアリング担当バイスプレジデントであるヴィナイ・ペルネティ氏に話を聞きました。

ペルネティ氏は、Augment Code が採用している独自の手法を簡潔に説明し、自チームによる評価に基づく利点を提示しました。また、より軽量なハーン（harness）を支持する論点への反論を行い、開発者が AI ツールや広義の自律型ワークフローに対して抱く懸念に対する自身の見解も共有しました。

ヴィナイ・ペルネティ氏との対話

*本インタビューは、長さの調整と明瞭化のために編集されています。*

*Ars Technica: Augment Code のコンテキストエンジンがどのように機能するのか、説明いただけますか？

ヴィナイ・ペルネティ: まず一歩引いて考えてみましょう。特定の開発者が目指しているのは何でしょうか？彼らは特定の実装タスクを完了させたいと考えており、それをエージェントに任せるのです。今日のエージェントの面白い点は、利用可能なコンテキストウィンドウが限られていることです。そのため、必要な情報をすべて取得して作業を開始するたびに、その都度文脈を集め直す必要があります。

コンテキストの扱い方には大きく分けて二つのアプローチがあります。一つは grep ベースの手法です。Claude Code や Codex、そして他のエージェントがこれを実装しています。もう一つがセマンティック・リトリバル（意味的検索）によるアプローチです。Augment では常に後者の道を選び、その構成要素について解説していきます。

核心的な要素は二つあります。まず、システム内で連携する埋め込みモデルと検索モデルのペアが存在すること。そして、サブミリ秒単位での検索を可能にするベクトルデータベースと、それを支える高効率なバックエンドシステムが整っていることです。

*Ars: これは特定のコードベースにおいて優位性を発揮するのでしょうか？*

Perneti: はい、実際には大規模で非公開のコードベースにおいてその優位性が現れます。その理由を説明しましょう。

ベンチマークの多くが実施されている公開されたオープンソースリポジトリでは、すべてのモデルが事実上そのリポジトリの内容を暗記してしまっています。これらのモデルは十分に大きいため、リポジトリ全体を記憶することが可能です。そのため、何かを実行しようとする際、モデルはすでにどこを見ればよいかを知っており、素早く結果にたどり着くことができます。

一方、非公開のリポジトリでこれを行う場合、モデルはそのリポジトリを一度も見たことがありません。すると、結果を得るまでの試行錯誤のループが非常に長くなってしまいます。しかし、非公開リポジトリ全体に対する意味的な理解があれば、質問をするだけではるかに素早く目的の結果に到達できるのです。

Ars: トークンの効率性について懸念する声があります。この意味論的なアプローチは、その点に寄与するのでしょうか？

Perneti: 確かに特定の状況では効果を実感しています。実は先日、Terminal-Bench というベンチマークで Claude Code と Augment Code を同じモデルで比較したブログ記事を公開しました。両者とも同程度の精度を達成しましたが、Augment Code は Claude Code よりも 33% トークンを節約できました。つまり、探索に費やす時間を減らせるため、トークンの使い方がより効率的になっていると言えます。

Ars: Anthropic 氏は、意味論的なコードナビゲーションツールを追加しても Claude Code の評価スコアに目立った改善は見られないと述べています。しかし、あなたのブログではベンチマーク結果や他の主張が掲載されており、実際には大きな効果があるように見えます。両社で測っているものが違うのでしょうか？それとも Anthropic 側の評価に何か見落としがあるのでしょうか？

Perneti: 素晴らしい質問です。Anthropic が具体的にどの検索エンジンを使用したかは存じ上げませんが、よくある誤解として「すべての検索システムが等価である」と思い込まれることが挙げられます。データベースも同様で、すべてが同じ性能を持つわけではありません。私が言いたいのは、モデルとシステムが連携して動作する「コンテキストエンジン」そのものが、結果の質に大きな影響を与えるということです。

例えば、Augment では2022 年設立直後から約 18 ヶ月間、ChatGPT が登場する前の時期に、大規模なコードベースを対象とした検索および埋め込みモデルの研究に注力しました。特定の成果を達成する際に、どのコード片が埋め込み空間に適しているかという問いには多くの研究が寄せられており、その知見はすべて当社の検索モデルに織り込まれています。

そして、これを極めて高速で実現するのが、私たちが構築したシステムです。そのため、「Claude Code を RAG 実装で試したが効果を実感できない」という声がある場合、それは実装や文脈エンジンが根本的に異なるためです。

*Ars: モデルの進化があまりに速く、仮定を置いた仕組みを作ること自体が無意味だという意見があります。これは超軽量なハーンネス（基盤）を作るか、あるいは何もせず現状維持すべきだという主張につながります。6 ヶ月後や 12 ヶ月後の未来を予測できないからです。

Perneti: その点には確かに一理あります。しかし、いくつかの異なる視点から考える必要があると思います。

Augment では、高品質な成果を出すためには「知能」と「文脈」の 2 つの要素が必要だと考えています。モデルの性能が向上すれば、その知能は間違いなく指数関数的に高まります。しかし、知能が高まったからといって、自動的に適切な文脈が得られるわけではありません。

人間であれば、必要な文脈を得るためにトークン（計算リソース）を投入することで対応できます。ここで重要になるのが、もう一つの次元である「コスト」です。現在、エンジニアリングのリーダーたちが最も懸念している点もここにあります。「トークン予算のうち、どの程度が文脈収集に費やされ、成果物の生成に使われているのか？」また、「最高品質の結果を得るために、モデルを正しく活用できているか？」という問いです。

そこで重要になるのが、ハーン（枠組み）の設計と文脈の扱い方です。私にとってこれは「知能」と「文脈」の組み合わせであり、最終的にはシステムエンジニアリングの問題となります。「各領域に適切なリソースを投入し、最小のコストで最良の結果を得るにはどうすればよいか？」という課題です。

*Ars: ソフトウェア開発における AI への懐疑的な読者も少なくありません。特に共通する懸念として、2 つの意見が目立ちます。1 つ目は、「これらのシステムをまだ十分に信頼できない」という点で、技術的負債が蓄積されるリスクがあるという主張です。もう 1 つは、エージェント型ワークフローのコストが高すぎるという指摘です。これらについてどうお考えでしょうか？

ペルネティ氏: 両方について触れさせていただきます。まず前提として、皆様が共通して認識すべき根本的な真実があります。それは、AI モデルの性能が指数関数的なペースで向上し続けているという事実です。この流れに乗らない手はありません。現状を正しく理解し、その恩恵を受けられるよう姿勢を調整することが不可欠なのです。

さて、ご質問いただいた信頼性や検証、技術負債の問題に戻りましょう。もし「エージェントに任せて自分は立ち去る」というアプローチを取れば、それは失敗します。重要なのは、人間チームとエージェントチームが連携して働くことです。判断力が必要な場面では、依然として人間の方が適任であるケースが多々あるからです。

例えば仕様レビューがその典型です。実は、エージェントは仕様書を書くのが得意ではありません。そのため、人間がエージェントを導きながら、高品質な仕様書を仕上げる必要があります。しかし、一度仕様書が完成すれば、実行フェーズではエージェントの能力が非常に高いことがわかります。この強みを活かせない手はないでしょう。

2 つ目のポイントですが、実は技術的負債（テックデット）は非常に現実的な課題です。Augment 社内で特にエージェント指向の取り組みを進める中で気づいたパターンとして、エージェントがコードを複製する能力に長けているという点があります。そのため、私たちはエージェントを活用して技術的負債を削減するための集中的なスプリントを実施する必要がありました。

このアプローチの素晴らしい点は、技術的負債を減らすための具体的な仕様（スペック）を定義すれば、それを実行に移すのが得意だということです。つまり、この部分への対応にはこうした方法が有効だと考えています。

2 つ目の話題はコストについてですね。ここにも興味深いポイントがあります。今後、これが標準的な働き方になると仮定するなら、限られたトークン数でいかに最良の結果を得られるかが問われます。そこで重要になるのが、コンテキストエンジン（Context Engine）のような技術です。私にとって、タスクに最適なモデルを選ぶかどうかは、結果に大きな差をもたらす要素だと思っています。

2 つ目のポイントは、やや哲学的かつ未来志向のものですが、モデルの能力が指数関数的に向上し続ける中で、オープンソースモデルもそれに追いついていくでしょう。そのうち、最先端ラボとオープンソースモデルの間で、処理されるトークンの割合が逆転するポイントが訪れるはずです。最も困難な問題については依然として最先端モデルに任せることになるでしょうが、私が以前説明したようなコーディングステップ——「何をするべきか」を明確に理解し、仕様書として記述済みである場合——であれば、オープンソースモデルでも対応可能になるかもしれません。そうなればコストは大幅に下がるはずです。つまり、そのような働き方を可能にするシステムが必要であり、コストの問題は自然と解決されるものだと私は考えています。

*Ars: ありがとうございます。お時間を割いていただき感謝します。

Perneti: はい、サムさんとの対談を楽しみにしていました。

まとめ

両者とも、最先端モデルの性能は今後も指数関数的なペースで向上し続ける、あるいはそのペースを上回る可能性があると予想しています（少なくとも今後 1 年間は）。また、これが多くの組織におけるソフトウェア開発のあり方を根本から変えている点でも一致しています。

実務的な議論は、文脈情報を事前に集めておくべきか、それとも各タスクの都度再発見すべきかという点にあります。特に大規模で非公開のコードベースにおいては、この選択が重要になります。

また、両者は評価や最適化の対象としているものが異なる場合もあります。ウー氏は具体的には、「利用可能な LSP（言語サーバープロトコル）を数個追加しただけでは、性能に計測可能な向上は見られなかった」と述べています。ここで注意すべきは、ウー氏が言及した「LSP」の範囲が、Augment Code のハーンセスが扱う広範な機能よりも狭いということです。

ペルネティ氏とウー氏は、単なる grep 検索を超えたツールやシステムの評価について語っていますが、必ずしも同じものを指しているわけではありません。これが両者が異なる結論に至った理由の一つ（他にも理由はあり得ます）と言えるでしょう。

ウー氏が言及しなかった点として、ペルネティ氏は、Anthropic の Opus や Fable といった最先端モデルが、開発者や組織の自律型ワークフローにおける主要モデル、あるいは唯一のモデルとして維持するにはコストが高すぎる可能性に言及しています。その結果、より小型のモデルやオープンウェイトモデルの利用が広がる可能性があるという見解です。

計算資源の不足が続く中、オープンウェイトモデルの一部—including those small enough and sufficiently quantized to run on local hardware, or at least on hardware maintained in-house by the organization—now approach relatively recent frontier performance on some coding tasks. 小規模で量子化も十分に施され、ローカル環境や組織内で管理されるハードウェア上で動作可能なモデルは、一部のコーディングタスクにおいて比較的新しい最先端の性能に近づきつつあります。これらのモデルが急速に進化し、多くのチームやプロジェクトでコード生成エージェントとして実用可能になる可能性も残されています。

今後 1 年後にどちらのアプローチが主流になるかに関わらず、より自律的なワークフローが導入されても、エンジニアリングの判断力が必要なくなるわけではありません。むしろ、生産速度と規模の拡大に伴い、誤った判断によるコストが高くなるため、エンジニアリングの判断力は以前よりも重要になっていると言えるでしょう。

チームは、計算資源を要する最先端モデルを最も困難な問題に限定して使い、より日常的で要件が明確な作業は、コストが安くローカルで動作するこれらのモデルへ振り分ける傾向が強まっています。

サムエル・アックスンは、アーステクニカ（Ars Technica）のテクノロジーおよびゲーム報道を統括する編集リーダーです。物理的 AI や生成 AI、大規模言語モデル、ソフトウェア開発、ゲーム、エンターテインメント、そして複合現実（MR）などを専門にカバーしています。

彼はほぼ 20 年にわたり、Engadget、PC World、Mashable、Vice、Polygon、Wired など主要メディアでゲームとテクノロジーに関する記事を書いてきました。過去にはゲーム業界のマーケティング・PR エージェンシーを運営し、CBS のテレビネットワークでは編集責任者を務めました。また、クリエイティブエージェンシー SPCSHP でサムスンモバイルのソーシャルメディアマーケティング戦略にも携わっています。

さらに、iOS や Windows など複数のプラットフォーム向けに独立してソフトウェアやゲームを開発するインディー開発者でもあります。デポール大学を卒業し、同校でインタラクティブ・メディアとソフトウェア開発を専攻しました。

15 件のコメント