現代のAIアプリスタック、端から端まで

人々がAIアプリケーションを思い描くとき、思い描くのはモデルです。しかしモデルはいくつもの層のうちの一つにすぎず、AI機能が実際に機能するかどうかを決めるものの大半は、その周りの地味な層に宿っています。スタック全体――各部品が何をし、なぜ存在するか――を理解すれば、「AIは予測不能な魔法だ」が、推論し、デバッグし、改善できる構成要素の集合に変わります。本稿はユーザーの入力からモデルへ、そして戻ってくるまでのエンドツーエンドの地図であり、各層がどこでその価値を勝ち取るかについての本音の注釈を添えます。

モデル層：アプリケーションではなく、能力

中心に座るのはモデルそのもので、プロバイダーがホストするか、自分で動かします。これが生の能力です。テキストが入り、テキストが出て、その間にいくらかの推論がある。それは不可欠であり、同時に最も制御の効かない層でもあります。ほとんどの場合、構築するのではなく選択肢の中から選んでいるからです。間違いは、この選択をプロジェクト全体と捉えることです。貧弱なアプリケーションに組み込まれた高性能モデルは、よく作られたアプリケーションの中のそこそこのモデルに劣ります。

実際的には、この層はトレードオフを伴う決定です。ホスト型か自前運用か、大きいか小さいか、汎用か専用か。それぞれにコスト、レイテンシ、プライバシー、能力の含意があります。正しい選択はタスク次第であり――そして重要なことに――それは交換可能です。選択肢が改善したり要件が変わったりしたときに、後でモデルを差し替えられるよう設計することは、早い段階で下せる最もてこの効くアーキテクチャ上の決定の一つです。

オーケストレーション層：呼び出しを振る舞いに変える

単一のモデル呼び出しがアプリケーションであることはまれです。実際の機能は、呼び出しを連鎖させ、結果で分岐し、失敗時に再試行し、ツールを呼び、複数のソースからプロンプトを組み立てます。オーケストレーション層は、それらすべてを協調させるコードです――何を、どんな順序で送るか、そして各応答をどう扱うかを決めます。ここにアプリケーションの実際のロジックが宿り、エンジニアリングの労力の大半が注がれます。

オーケストレーションはまた、複雑さが静かに蓄積する場所でもあります。追加される各ステップ――検索呼び出し、ツール起動、最初の出力を確認する二度目のモデル通過――は、レイテンシ、コスト、そして新たな失敗の仕方を加えます。ここでの規律は、ステップがその場所を勝ち取るときにだけ追加し、何かがうまくいかなかったときに何が起きたかをまだ推論できるくらいフローを単純に保つことです。トレースできないパイプラインは、直せないパイプラインです。

コンテキスト層：プロンプト、検索、メモリ

モデルは目の前にあるものしか知りません。コンテキスト層は、モデルが見るものを組み立てるすべてです。タスクを枠づけるプロンプト、答えを自分のデータに根拠づける取得文書、そして会話の以前のやり取りのメモリ。これは頻繁に品質を決める層です。同じモデルでも、与えられるコンテキスト次第で結果が大きく異なるからです。

検索はここに属します。アプリケーションが自分の文書を使って答えるとき、この層はクエリを埋め込み、関連する一節を見つけ、それらをプロンプトに折り込みます。メモリもここに属します――会話の以前の部分から何を持ち越す価値があり、何を捨てるかを決めます。うまくやれば、この層は汎用モデルをあなたの特定の世界を知っているかのように感じさせます。下手にやれば、無関係または矛盾する素材をモデルに与え、その結果についてモデルを責めることになります。

ツール層：モデルに行動させる

テキストしか生み出せないモデルには限界があります。多くの有用なアプリケーションは、モデルに何かをさせる必要があります――ライブデータを調べ、計算を実行し、データベースに問い合わせ、外部サービスを呼ぶ。ツール層は、モデルが使える行動を定義し、モデルが求めたときにそれらを安全に実行します。モデルは何をするかを決め、あなたのコードはそれが実際に起きるかどうか、どう起きるかを決めます。

決定的な言葉は安全にです。ツールは、AIアプリケーションが現実世界に触れる場所であり、つまり間違いが下手な文以上の結果をもたらす場所です。この層にはガードレールが必要です。モデルが要求するものを検証し、到達できる範囲を制限し、不可逆な行動を確認します。モデルのツール要求を信頼できない入力として扱いましょう。実際そうだからです――モデルは行動を提案しているのであって、承認しているのではなく、権限を握るのはあなたのコードです。

評価層：機能しているかを知る

従来のソフトウェアは、動くかエラーを投げるかのどちらかです。AIアプリケーションはもっと微妙に失敗します。もっともらしいが間違った出力を生み、プロンプトを変えたりモデルを差し替えたりするにつれて静かに劣化します。評価層は、システムが実際に仕事をこなすかどうかを知る手段です――代表的なテストケースの集合と、それらに照らして品質を測る方法であり、いくつかの出力を目視して一度確認するのではなく、継続的に実行されます。

この層は、チームが最も飛ばしがちで、飛ばしたことを最も後悔する層です。それがなければ、すべての変更が賭けになります。あるケースを改善し、気づく手段もないまま三つを静かに壊すのです。ささやかな評価セットがあるだけでも、モデルを変え、プロンプトを調整し、検索ステップを追加して、助けたのか害したのかを測れます。評価は、AI開発を当て推量からエンジニアリングへ変えるものであり、必要だと思う前に作る価値があります。

オブザーバビリティとコスト層：開かれた場所で運用する

AI機能が稼働したら、それが何をしているかを見る必要があります。オブザーバビリティ層は、プロンプト、取得したコンテキスト、モデルの応答、ツール呼び出し、レイテンシ、コストをログに残します。ユーザーが悪い答えを報告したとき、推測する代わりに実際に何が起きたかを再構成する手段です。AIシステムは非決定的であり、それは良いログ取りを通常のソフトウェアより重要にこそすれ、軽くはしません。

コストはオブザーバビリティと並んで宿ります。AIアプリケーションではコストが固定された費目ではなく実行時の性質だからです。すべての呼び出しがトークンを消費し、すべての検索がコンテキストを加え、すべての余分なオーケストレーションステップが使用量を倍加させます。可視性がなければ、コストは請求書かレート制限が議論を強いるまで、気づかれず上昇していきます。コストを一級のシグナルとして見張ること――リクエストごと、機能ごと、時系列で――が、経済性が静かにプロダクトを壊すのを防ぎます。

各層がどう噛み合うか

単一のリクエストをたどると、スタックが具体的になります。ユーザーの入力が届き、オーケストレーション層が引き継ぎ、コンテキスト層が取得文書とともにプロンプトを組み立て、モデルが応答を生み、ツール層がモデルの要求した行動を実行し、結果が返ります――その間、オーケストレーションとは別に、オブザーバビリティ層が旅全体を記録し、評価層がオフラインで、こうした旅がまだうまくいくかを確認し続けます。各層は交換可能で、どれか一つの弱さが全体の品質に天井を設けます。

戦略的な洞察は、これらの層が独立して失敗し、独立して改善するということです。期待外れのアプリケーションは、根本的に弱い設計ではなく、たいてい一つの弱い層を抱えています。どの層か――不適切な検索、ずさんなオーケストレーション、安全でないツール、評価の不在――を診断することこそ、AI機能を着実に改善するチームと、次のモデルがすべてを直してくれることを願ってモデルを差し替え続けるチームとを分けるのです。

まとめ

現代のAIアプリケーションはモデルではなくスタックです。モデルは能力を供給しますが、オーケストレーションがそれを協調させ、コンテキスト層がそれに与え、ツール層がそれに行動させ、評価が機能しているかを教え、オブザーバビリティが白日のもとで運用させます。品質の大半とコストの大半は、モデルそのものではなく、モデルの周りの層に宿っています。その地図を念頭に構築すれば、AI開発は魔法のように感じられなくなり、それが本当はそうであるもの――中心に一つの異常に予測しにくい構成要素を据えた、ありふれたエンジニアリング――のように感じられ始めます。