AIスタックの選定——ベンダーロックインと単価の設計

「LLMを使うことは決まった。どのモデル、どのフレームワーク、どのベクトルデータベースを選ぶべきか？」——このタイプの選定相談を、私たちは毎月のように受けている。

結論から言うと、正解は組織によって異なる。ただし、選び方には共通の骨格がある。この記事では、AIスタック選定を「特定製品のオススメ」ではなく、「意思決定のフレームワーク」として整理する。

選定軸を、先に定義する

比較を始める前に、少なくとも以下の軸を書き出す。それぞれに、自組織にとっての重みを付ける。

• 品質：自分たちのゴールデンセットでの正解率、要約品質、指示追従性。
• レイテンシ：P50・P99の応答時間。ストリーミング対応か。
• 単価：入力トークン単価、出力トークン単価、キャッシュ割引の有無。
• 機能：ツール呼び出し、構造化出力（JSONスキーマ準拠）、長文コンテキスト、マルチモーダル対応。
• データ扱い：学習データへの流用がないか、リージョン、暗号化、監査ログ。
• 可用性・SLA：稼働率保証、レート制限、サポート応答時間、地理冗長。

この6軸に、組織ごとに重みを付ける。「品質最優先で、単価はほどほど」なのか「単価が最優先で、品質は最低ラインを満たせばよい」なのか。ここが合意できていないと、比較表を作っても選べない。

ベンダー公表のベンチマークを、額面通り信じない

MMLU、HumanEval、GSM8Kのようなベンチマーク数値は、モデル紹介ページで頻繁に引用される。しかしこれらは、自組織の業務を代表していない。

編集部が推奨するのは、選定の早い段階で自組織のゴールデンセット（50〜200件）を作り、それで候補モデルを走らせて比較することだ。評価の設計に関する記事で扱ったように、業務代表性のあるサンプルでの評価は、公表ベンチマークよりも実導入後の満足度を予測しやすい。

モデル1つに賭けない

「今期はモデルAを採用しました」で意思決定を終えると、半年後に困ることがある。モデル価格の下落、新モデルのリリース、既存モデルの品質更新は、想像より頻繁に起きる。

本番構成では、モデル呼び出しを抽象化するレイヤーを最初から用意しておく。呼び出しコードは統一インターフェイス（例：LiteLLM、独自ラッパー）を通し、実際のバックエンドを設定で切り替えられるようにする。ゴールデンセットでの再評価と組み合わせれば、モデル切り替えが数時間の作業になる。

ベクトルDBとフレームワークは、遅く決める

「LangChainを使うべきか」「Pineconeを選ぶべきか」——選定の早い段階で頻繁に問われる。しかし編集部の観測では、これらは選定を急ぐ必要はない。

初期のプロトタイプは、シンプルな構成（例：SQLiteでベクトル管理、ラッパーなしの直呼び出し）で始めて構わない。実データで動かしてみて、明らかにこれ以上スケールしないと判断してから、専用製品への移行を検討する。ベクトルDBの選定基準は別記事で扱った。

四半期に一度、見直す

AIスタックの選定は、一度で終わる作業ではない。モデル価格は数ヶ月単位で変動する。新機能（構造化出力、ツール呼び出し、長文コンテキスト）は継続的にリリースされる。編集部が観測した運用チームは、四半期に一度、以下を再評価していた。

直近3ヶ月のゴールデンセット評価スコアが、他モデルを試したときと比較してどうか。単価が下落した候補モデルへの切り替えで、月次コストがどれだけ変わるか。新機能（例：Prompt Caching、Structured Output）を採用することで、実装がどれだけ簡潔になるか。

もっとも、選定に時間をかけすぎない

ただし、選定に時間をかけすぎるのも失敗パターンだ。3ヶ月かけて完璧なベンチマークを作っても、その間にモデル自体が更新されてしまう。編集部の推奨は、「2週間以内に暫定選定→本番投入→四半期ごとの見直し」という運用サイクルだ。完璧な選定より、切り替えられる構成のほうが長期的には有利になる。

参考にした一次資料

• Anthropic. “Model Card and Evaluations for Claude Models.” anthropic.com.
• Liang, P. et al. “Holistic Evaluation of Language Models (HELM).” arXiv:2211.09110.