【ITニュース解説】Opus 5.5 Made Cache Reads 60% Cheaper. I Redid the Math on My Text-to-SQL Architecture

ITシステムにおいて、人間が自然な言葉で質問をすると、AIがデータベースから適切な情報を見つけてきて答えを生成する仕組みが注目されている。この技術は「Text-to-SQL」と呼ばれ、AIが自然言語の質問を理解し、その内容に基づいてデータベースへの問い合わせ言語であるSQLを自動的に生成するものだ。このようなシステムを開発・運用する上で、AIの利用にかかるコストは非常に重要な要素となる。

今回、大手AIモデル提供者であるAnthropic社の大規模言語モデル（LLM）「Claude Opus」の最新版「Opus 5.5」が登場した。この新しいモデルは、その利用料金体系、特に「キャッシュ読み込み」のコストが劇的に変化したことで、Text-to-SQLシステムの設計に大きな影響を与えている。

記事の筆者は、「Aria」というAIアシスタントを開発している。これは、顧客関係管理（CRM）システムの担当者が、日常の言葉で質問するだけで、リアルタイムのデータベース情報から必要な答えを得られるようにするものだ。Ariaの核となるアイデアは、データベースの「スキーマ」（つまり、どのテーブルにどんな情報があり、それぞれの列が何を意味するかといった、データベースの構造情報）を効率的にAIに渡す点にある。

従来のAriaの設計では、全てのデータベーススキーマ情報をAIに渡すのではなく、ユーザーの質問内容に関連する部分だけを抽出してAIに送る方法を採用していた。この関連情報抽出は、「RAG」（Retrieval Augmented Generation、情報検索拡張生成）と呼ばれる技術を使って行われる。具体的には、データベースの各テーブルや列、列挙値の説明文をあらかじめ用意し、ユーザーの質問とこれらの説明文の「意味的な近さ」を数値化（埋め込み）して比較する。そして、最も関連性の高い上位5つのスキーマ情報だけをAIに渡していた。この設計を選んだ主な理由は二つあった。一つは、全てのスキーマ情報をAIに送ると、その情報量に応じてAIの利用コストが高くなること。もう一つは、AIが少数の関連情報に集中した方が、より正確なSQLを生成できると考えたからだ。

しかし、Opus 5.5が登場したことで、このコスト構造が大きく変わった。特に注目すべきは、「キャッシュ読み込み」のコストが、以前のOpus 5と比較して60%も削減された点だ。キャッシュとは、一度使ったデータを一時的に保存しておき、次に同じデータが必要になったときに素早く取り出せるようにする仕組みのことである。これにより、再度AIに全ての処理を行わせるよりも、はるかに高速に、そして安価に情報が利用できるようになる。AIモデルの利用料金は、AIに与える情報（入力）とAIが出力する情報（出力）の量、そしてキャッシュの利用に対して「トークン」という単位で計算される。トークンは、単語や記号をAIが処理しやすいように分割した最小単位だと考えればよい。今回のコスト削減は、入力や出力の単価が20%下がったことよりも、データベーススキーマ情報のように繰り返し参照されるデータをキャッシュから読み出すコストが劇的に下がったことが、Ariaのようなスキーマ情報を多用するText-to-SQLシステムにとって最も重要な点だった。

このキャッシュ読み込みコストの劇的な低下を受けて、筆者はAriaの設計を再検討した。具体的には、以下の二つの設計選択肢についてコストを比較した。 一つ目の選択肢は、従来の方式である「関連性の高い上位5つのスキーマ情報のみを毎回検索してAIに送る」方法だ。この場合、質問ごとに検索内容が変わるためキャッシュはあまり活用できない。 二つ目の選択肢は、「全てのデータベーススキーマ情報をAIに送り、その大部分をキャッシュとして利用する」方法だ。 以前のOpus 5では、後者の「全スキーマ情報をキャッシュして送る」方式は、前者の「関連情報のみを検索して送る」方式に比べて約2.1倍のコストがかかっていたため、コストの面から従来の方式が有利だった。しかし、Opus 5.5ではそのコスト差が約1.2倍にまで縮まった。この程度のコスト差であれば、もはやコストだけが設計を決める主要な要因ではなくなり、どちらの方式がより正確なSQLを生成できるか、という「精度」の面が重要となる。

二つ目の選択肢、つまり全てのスキーマ情報をAIに渡すことには、いくつかの利点がある。一つは、質問ごとにデータベーススキーマの検索（埋め込みとベクトル検索）が不要になるため、システム全体の応答時間が短縮され、エラーが発生する可能性も減る。もう一つは、特定の重要な情報が検索漏れ（Retrieval Miss）でAIに伝わらないリスクがなくなる点だ。AIは常に全ての関連情報を見ながらSQLを生成できるため、生成されるSQLの精度向上が期待できる。

さらに、Opus 5.5の登場は、利用料金だけでなく、AIモデルとのやり取りのルール（API仕様）にも大きな変更をもたらした。これらの変更もText-to-SQLシステムの設計に直接影響する。 一つ目は、「ツールの強制利用」に関する変更だ。Text-to-SQLシステムでは、AIが勝手に質問に答えるのではなく、必ずSQLを生成する特定のツールを呼び出すように強制することが一般的である。Opus 5.5では、このツール利用を強制する方法が変更され、古い方法だとエラーになるようになったため、より具体的な指示と設定が必要となる。 二つ目は、「会話履歴の追記専用」というルールだ。AIモデルとの会話は、基本的に新しいメッセージを「追記」していく形が推奨され、過去のメッセージやシステム全体の設定（システムプロンプト）を会話の途中で編集すると、エラーが発生する可能性が出てきた。従来のAriaのRAGシステムでは、質問ごとにシステムプロンプト内のスキーマ情報を再構築していたため、この新しいルールに抵触してしまう。

これらのAPI変更は、皮肉にも前述の「全スキーマ情報をキャッシュして送る」という設計を強く後押しする形となった。すなわち、システムプロンプトを静的なものにし、全てのスキーマ情報をそこに固定で置いてキャッシュ利用する。そして、新しい情報（例えば、ユーザーの質問に関連する過去の会話例など）は、会話履歴の最後に追記する形で追加する、という設計だ。このように、料金体系の変更とAPI仕様の変更の両方が、「大規模で変更頻度の低いコンテキスト情報は固定のプレフィックスとしてキャッシュし、新しい情報は追記で加える」という方向へシステム設計を導いている。

筆者は、この新しい設計が実際に効果的であるかを検証する計画を立てている。既存の評価用データセット（質問とそれに対する正しいSQLのペア）を使い、「関連性の高い上位5つだけを検索する従来の方式」と「全てのスキーマ情報をキャッシュして利用する方式」の両方を実行し、どちらがより正確なSQLを生成するか、そして実際のコストや応答速度はどうなるかを測定する予定だ。もし、全てのスキーマ情報を使う方式で同等かそれ以上の精度が得られるのであれば、質問ごとにデータベーススキーマを検索する複雑なRAGのステップをシステムから削除し、よりシンプルで高速なシステムへと移行する可能性がある。

このニュースは、AIモデルの進化が、その利用方法やシステム設計のベストプラクティスをいかに大きく変えうるかを示す好例と言える。単に新しいAIモデルが登場しただけでなく、その料金体系やAPIの変更が、開発者がこれまで培ってきたシステム設計の思想を根本から見直すきっかけとなることを示している。