10月7日、Harper（※元記事のドメインは harper.fast だが、公式サービスサイトは harperdb.io として運営されており、同社が運営する別ドメインと見られる）が「What If Your AI App Didn't Need All Those Services?」と題した記事を公開した。AIアプリケーションに必要なインフラを大幅に削減するためのアーキテクチャ思想と、それを実現するHarper 5.xの機能群について詳しく紹介されている。
AIスタックは「サービスの積み重ね」になりすぎていないか
第一世代のAIアプリケーションの典型的な構成を思い浮かべてほしい。LLM、ベクトルDB、エンベディングサービス、全文検索エンジン、キャッシュ、エージェントフレームワーク、キュー、スケジューラ、オブザーバビリティ基盤——それぞれは優れたツールだが、それらの「間」にこそ問題がある。
ネットワーク呼び出し、認証情報の管理、デプロイの増加、状態の不整合リスク。AIが本番環境に移行するにつれ、このアーキテクチャ上のコストがボディブローのように効いてくる。
Harperが提示する答えはシンプルだ。「インフラを外側に追加するのではなく、ケイパビリティをアプリケーションランタイムの内側に移す」。
AIアプリは本質的にループ構造
記事は、多くのAIアプリケーションが共通のプロセスを繰り返していると指摘する。
- 正しい情報を見つける
- その意味を理解する
- 何をすべきか判断する
- アクションを実行する
- 結果から学ぶ
現在この各ステップは異なるシステムに分散しており、アプリケーションはその大部分の時間とコストを「システム間のコンテキスト移動」に費やしている。
Harper 5.xが目指すもの
Harperは、DB・アプリサーバー・キャッシュ・メッセージングを単一プロセスに統合するアーキテクチャを従来から採用している。Harper 5.0〜5.3ではこの思想をAI領域に拡張した。
各バージョンの進化を大まかに整理すると、基盤整備（5.0）→AIインターフェースの統合（5.1）→検索・運用機能の強化（5.2）→判断・検索のネイティブ化（5.3）という流れになる。具体的には以下のとおりだ。
- 5.0：完全オープンソース化、ストレージ拡張、データとアプリロジックの統合基盤の確立
- 5.1：モデルプロバイダーを横断するテキスト生成・エンベディングの共通インターフェース、データ書き込み時の自動エンベディング生成、組み込みMCPサーバー、別途オーケストレーションサービス不要のツールコーリングループ
- 5.2：ベクトル検索の効率化、アプリレベルフィルタリングの検索参加、シークレット管理・キャッシュ・ルーティングのランタイム統合
- 5.3：ネイティブ全文検索とモデルアシスト型意思決定の追加
最も面白い部分：models.decide()による「制御された判断」
記事で最も読み応えがあるのが、**5.3で追加されたmodels.decide()**の設計思想だ。
多くのプロダクション用ワークフローは「新しい文章の生成」を必要としていない。必要なのは判断だ。
- このサポートリクエストは「billing」「refund」「engineering」のどれに振るべきか
- この商品は「カテゴリA」か「カテゴリB」か
- このアラートは「調査すべき問題」か「ノイズ」か
選択肢はすでにわかっている。モデルにはその中から最適なものを選ばせたい。
この「自由生成の代わりに境界付きの選択肢群から最良のものを選ぶ」というアプローチは、近年のAIアーキテクチャ議論でも注目されている考え方だ。Harperはこのパターンを、特定モデルに依存しない汎用インターフェースとして実装した。
※編集部の考察：この設計思想は、Jev（typesafe.ai）など「決定モデル」と呼ばれるカテゴリの議論と方向性が近い。Jevは自由生成を行わず、与えられた選択肢から最良のものを選ぶことに特化したモデルだが、元記事でHarperがJevに直接言及しているわけではない点に注意。
models.decide()の動作：
- アプリケーションがコンテキストと許可された回答セット（例：
billing,refund,bug）を渡す - Harperが設定済みモデルに判断を依頼する
- 選択された値と、各選択肢のスコアが返ってくる
スコアが高ければ自動ワークフローを継続、不確実なら人間レビューへ回す、「none of these」スコアが高ければ選択肢の設計自体を見直す——という制御をアプリケーション側が握り続ける。モデルが判断し、制御はアプリが持つという分離が重要だ。
さらに、判断結果を後続のアウトカムと紐づけて永続化できる。これにより、実際のワークロードでモデルがどう振る舞うかを評価し、観測された結果に基づいて自動化の閾値を設定できる。
全文検索とベクトル検索を両立する意味
5.3ではネイティブ全文検索も追加された。
- 全文検索：製品番号、エラーメッセージ、契約上の特定フレーズなど、「正確な言葉」が重要なケースに強い
- **ベクトル検索**：意味的類似性による検索。RAG（検索拡張生成）での自然言語クエリに強い
記事の表現を借りれば、「全文検索は言葉を見つけ、ベクトル検索は意味を見つける」。この2つが同じランタイム内で、同じデータとアプリロジックの隣で動作する点がHarperの主張だ。
検索が証拠を集め、models.decide()がそれをアクションに変換する——という一連のフローが、外部サービスを介さずにランタイム内で完結する。
インフラを減らすことの経済学
記事は「最速のネットワーク呼び出しは、アプリケーションがそもそも行わずに済む呼び出しだ」と述べる。
サービス境界を減らすことで：
- コンテキストがネットワークを渡る回数が減る
- 同一オペレーションを調整するシステムが減る
- 独立してスケールさせるコンポーネントが減る
モデル自体は引き続き外部プロバイダーのものを使う前提で、その周辺インフラを崩していくという設計方針だ。
詳細はWhat If Your AI App Didn't Need All Those Services?を参照していただきたい。
