読み込み中…
読み込み中…
テスコのラジクマール・サクトィヴェル氏は、AI コーディングツールの利用料が急増した背景として、不要なコンテキスト(ファイル)の送信過多を指摘しました。彼らは既存のプロンプト調整や出力圧縮では不十分だと判断し、ローカルで動作するハイブリッド検索層と軽量なスコアリングシステムを開発しました。その結果、平均的なクエリでのトークン使用量を94%削減しつつ、コードの精度を90%維持することに成功しています。このアプローチは、エンタープライズレベルでの生成AIコスト管理と開発者体験の最適化に新たな基準を示すものです。
「モデル選び」に固執しがちな開発者に対し、「入力制御」という視点の転換を促す非常に実用的なケーススタディです。具体的な数値とオープンソースツールの提供により、即座に検証可能な内容となっています。
AI コストの90%は入力(コンテキスト)にあり、出力圧縮だけでは不十分で、不要なファイル送信を止める必要がある。
コードベースを関数単位で分割し、意味検索とキーワード検索のハイブリッド方式で必要な箇所のみ抽出する仕組み。
複雑なAIモデルを使わず、意味・キーワード・最新性の単純な数式で関連性を判定し、0.4ms でフィルタリングする。
FastAPIなどのプロジェクトでテストし、クエリあたりのトークンを83Kから4.9Kへ減らしつつ精度を維持した実績。
この動画は、生成AIのコスト構造に関する誤解(モデル選択が全て)を正し、インフラ側での最適化(コンテキスト管理)の重要性を浮き彫りにしました。特に、大規模コードベースにおけるローカル検索と軽量フィルタリングの組み合わせは、セキュリティとコスト効率を両立する企業向けAI導入の標準的なベストプラクティスとして定着する可能性があります。
AI コーディングツールの利用料が予測不能に跳ね上がる現象、実はモデルの性能やプロンプトの調整では解決できない根本的な問題を抱えています。テスコのエンジニアであるラジクマール・サクトィヴェル氏と友人フォス氏が直面した「請求書の急増」は、不要なコンテキスト(ファイル)を過剰に送信していたことが原因でした。彼らが開発したローカル検索層と軽量スコアリングシステムは、トークン使用量を 94% 削減しながらもコード精度を 90% 維持するという驚異的な成果を達成しています。
AI コーディングツールを利用する際、多くの開発者は「プロンプトを工夫すればいい」「モデルの温度設定を変えれば解決する」と考えがちです。しかし、テスコの実務者が調査した結果、これらの対策は根本的な解決にはなりませんでした。
彼らが測定した典型的なクエリでは、45,000 トークンのコンテキストが AI モデルに送信されていました。しかし、実際にモデルが必要としていたのはそのうち約 5,000 トークンだけでした。残りの 40,000 トークンは無関係なコードであり、開発者は「食べない余分な 9 枚分のピザ」に対して毎回代金を支払っているような状態だったのです。
「AI コストの 90% は入力(コンテキスト)側にあり、出力はわずか 10% です。出力を 75% 削減しても総コストは約 8% しか減りません。しかし、入力を 94% 削減すれば、総コストの約 61% を節約できます。」
プロンプトの短縮やモデル設定の変更は「出力」を変えるだけで、「入力側」のコストには影響しません。出力圧縮を試みた結果、回答長さは 75% 減りましたが、総コストはわずか 10% の削減にとどまりました。この事実が示すのは、「お金がかかっているのは AI が考える時間ではなく、送信される不要なファイルの量」ということです。
そこで開発チームは、既存のプロンプト調整や出力圧縮に頼らず、インフラ側でコンテキストを最適化するアプローチを採用しました。彼らが構築したのは、コードベースと AI モデルの間に位置する「ローカル検索層」です。
この仕組みでは、ファイル全体をそのまま送信するのではなく、コードを関数、クラス、メソッドといった意味のある単位に分割し、必要な断片のみを抽出します。検索プロセスは以下の 5 つのステップで構成されています。
「検索結果が 10 件返されても、すべてが正しいとは限りません。悪い結果を使うことは、回答がないことよりも最悪です。」
検索で結果を見つけられたとしても、それが本当に「関連性がある」かどうかを判断するのは難しい課題でした。開発チームはまず、「AI に自分で判定させる」方法を試しましたが、1 クエリあたり 2〜3 秒の遅延が生じ実用化できませんでした。
次に、「スコア制限を単純化する」アプローチを試みました。その結果、「複雑な AI モデルを使うよりも、シンプルな数式の方が圧倒的に効果的である」という教訓を得ています。
彼らが採用したスコアリングシステムは以下の単純な数式です。
この計算結果に基づき、閾値を動的に調整します。この処理には追加の AI モデル呼び出しは不要で、0.4 ミリ秒という驚異的な速度でフィルタリングを実行しています。
「数字が必要です。物語だけでは不十分です。複雑なものよりシンプルな選択が効果的です。」
また、すべての処理は開発者のマシン上(ローカル)で行われ、クラウドへデータを送信しないため、セキュリティ面でも安心できます。
このアプローチの有効性は、オープンソースの実プロジェクト「FastAPI」を用いたテストで証明されました。対象は 53 ファイル、開発者が実際に問うた 20 の質問です。
結果、トークン使用量は 94% 削減されました。驚くべきことに、この劇的な削減にもかかわらず、コードの正解率は依然として90%を維持しています。
「答えはより優れたモデルではありませんでした。答えは送信量を減らすことでした。」
なお、この 94% は「毎回すべてのファイルを読み込む」という最悪ケースでの数値です。実際の現場では、クラウド上のコードツールもすでに一定の賢さを持っているため、真の節約効果はさらに大きくなる可能性があります。
このアプローチが持つ最大の価値は、大規模なコードベースにおけるセキュリティとコスト効率の両立にあります。テスコの実務者は、複数の AI ツール(Cloud Code, Cursor, Copilot など)を状況に応じて使い分けていましたが、それぞれが独立して起動し、互いに情報を共有しないという非効率さに直面していました。
彼らが構築した解決策は、「すべてのツールが接続する一つの共有インデックス」です。これにより、検索結果や学習した知識がツール間で共有され、同じコードベースを異なる日に何度も説明する必要がなくなります。あるツールでプロジェクトについて学習すれば、その知識は保持され、次のセッションでも別のツールを使えば文脈はすでに存在しています。
実プロジェクトでの 1 週間の運用レポートでは、247 クエリで約 1,240 万トークンの削減(推定金額換算)を達成しました。このうち84% の節約効果は検索レイヤーから発生しており、残りは出力圧縮によるものです。
「どのモデルが最良か(Opus か Sonnet か)で議論しますが、モデルのコストは全体の 30% に過ぎません。残りの 70% は何を与えているか、つまり入力さえ正せば、モデル選択は思ったより重要ではありません。」
テスコの事例は、生成 AI のコスト管理において「モデルの性能競争」に固執するのではなく、「コンテキストの最適化」というインフラ側の視点を持つことの重要性を浮き彫りにしました。このローカル検索と軽量フィルタリングのアプローチは、今後エンタープライズレベルでの AI コーディング導入における標準的なベストプラクティスとして定着していく可能性があります。
開発者たちは今、より良いモデルを探すのではなく、「何を送信しているか」を問い直す必要があります。その一歩が、巨額の請求書から解放される鍵となるのです。
この記事はAIが動画の内容を記事化したものです。正確な発言は動画および文字起こしをご確認ください。