2026年のLLMスタック：モデル、推論、ツール、トレードオフ

2026年に実用的なAI製品を構築する場合、もはや「OpenAIとAnthropicのどちらを使うべきか」とは問いません。その捉え方は2年前のものです。多層スタック全体で何十もの意思決定を行う必要があり、その大半が重要です。

この記事では、2026年のLLMスタックを実務に携わるアーキテクトの視点から解説します。各層に何があり、どのようなトレードオフが生じ、この分野がどこへ向かっているかを扱います。避けられたはずの失敗を一通り経験する前に、誰かに書いておいてほしかった記事です。

各層

スタックの概略は次のとおりです。

┌────────────────────────────────────┐
│       アプリケーション層           │  製品 / エージェント / ワークフロー
├────────────────────────────────────┤
│   オーケストレーション / フレームワーク │  LangGraph、CrewAI、独自実装、直接利用
├────────────────────────────────────┤
│   プロンプト + コンテキスト管理     │  プロンプトテンプレート、コンテキストエンジニアリング
├────────────────────────────────────┤
│   検索 / メモリ                     │  RAG、ベクトルストア、構造化メモリ
├────────────────────────────────────┤
│   ツール / MCP層                   │  ツール呼び出し、MCPサーバー、関数API
├────────────────────────────────────┤
│   モデル層                          │  特定モデルの選択、ルーティング
├────────────────────────────────────┤
│   推論層                            │  ホステッドAPI、自社運用、エッジ
├────────────────────────────────────┤
│   可観測性 / eval                   │  ログ、トレース、evalスイート
└────────────────────────────────────┘

各層には実用的な選択肢が複数あります。ある層での選択は、ほかの層の選択肢を制約します。初期の決定は後から変えにくく、モデルの選択が推論の選択に影響し、それがオーケストレーションの選択に影響します。

各層を順に見ていきます。

第1層：モデル層

2026年のモデルはいくつかの大まかな階層に分かれます。呼び出しごとにどの階層から選ぶかは、システム内で最も影響の大きい判断です。

最上位の推論モデル。 現行の最上位モデルが備える思考モード、すなわち推論機能付きGPT-5.5、適応型思考機能付きClaude Opus 4.8、Gemini 3.1 Pro thinkingに加え、DeepSeek R1のような推論専用モデルです。多段階の問題、数学、コード、複雑な分析に優れています。高価で（入力100万トークン当たり3～30ドル、出力はさらに大幅に高価）、低速です（5～60秒）。推論品質がボトルネックになる場合に使用します。

最上位の汎用モデル。 GPT-5.5、Claude Sonnet 5、Gemini 3.1 Proです。ほとんどの知的作業に優れ、高速で（2～5秒）、価格は中程度です（入力100万トークン当たり2～5ドル）。高品質なユーザー向け回答の標準的な選択肢です。

中位モデル。 Claude Haiku 4.5、Gemini 3.5 Flash、OpenAIの中位モデルです。単純から中程度のタスクに適し、高速で（1～2秒）、安価です（入力100万トークン当たり1～2.50ドル）。分類、抽出、単純な生成のために本番環境で多用されています。

小型 / 低価格モデル。 各プロバイダーの現行最小モデル（Gemini 3 Flash Previewなど）と小型のオープンソースモデルです。限定的な構造化タスクには十分です。非常に安価で（入力100万トークン当たり0.50～1ドル）、非常に高速です（1秒未満）。ルーティング、スコアリング、バッチ処理に使用します。

（掲載価格は2026年7月7日に各ベンダーの料金ページで確認済みです。階層は変動するため、見積もりに使う前に再確認してください。）

特化型モデル。 埋め込みモデル、リランキングモデル、ビジョンモデル、音声モデル、コード特化モデルです。特定のタスクでは汎用モデルより安価で、通常は性能も優れています。該当するタスクでは必ず検討してください。

オープンソースの最先端モデル。 Llama 4、DeepSeek V3 / R2、Qwen 3、Mistral Largeです。推論プロバイダー（Groq、Together、Fireworks）でホストするか、自社運用します。多くのタスクで、価格と品質はクローズドな最先端モデルに匹敵しますが、一部のタスク、特に長期的な推論では後れを取ります。

ここから次のことが分かります。

• システム内のすべての呼び出しに、一つのモデルで対応することはできません。コスト管理にはルーティングが不可欠です（第5層を参照）。
• 最先端は四半期ごとに変化します。モデルに固定するのではなく、交換できるように構築してください。
• オープンソースは、もはや実験用に限らず、多くの本番ユースケースで真に実用的な選択肢です。

第2層：推論層

モデルは実際にどこで動作するのでしょうか。

クローズドAPIプロバイダー — OpenAI、Anthropic、Googleです。稼働までが最も速く、最良のモデルを利用でき、信頼性も最も高い選択肢です。割増料金を支払い、そのデータおよびセキュリティモデルを受け入れることになります。

オープンソース推論プロバイダー — Groq、Together AI、Fireworks、Replicateです。さまざまなチューニングでオープンモデルを実行します。自社運用よりはるかに高速なことが多く、価格も競争力があります。（この市場では統合が急速に進んでいます。2024年頃に存在したプロバイダーの一部は、すでに事業を終了しています。契約前に必ずベンダーを確認してください。）

クラウドネイティブ — AWS Bedrock、Azure OpenAI、Google Vertexです。クローズドモデルとオープンモデルを、利用中のクラウドの認証、請求、コンプライアンスで包み込みます。多くの企業環境で必要になります。

自社運用 — 自社のGPU上でvLLM、TGI、SGLang、LMDeployを実行します。大規模運用ではトークン当たりのコストが最も低くなりますが、運用の複雑さは最も高くなります。通常、推論費用が月額数千ユーロ台後半に達して初めて検討に値します（損益分岐点の計算については、自社運用対ホステッドの記事を参照してください）。

エッジ / オンデバイス — Apple Intelligence、MediaPipe、ONNX、またはOllamaやllama.cpp経由のGGUFモデルです。呼び出しごとの費用はかかりませんが、モデルの能力に制約があります。限定的なユースケースでは、実用性がますます高まっています。

トレードオフは次のとおりです。

• レイテンシーが重要です。音声エージェントや会話型UXでは、最初のトークンがすぐに返る必要があります。この点ではGroq、Cerebras、オンデバイスが優勢です。
• バッチ処理ではスループットが重要です。数百万件のレコードを処理するなら、低レイテンシーではなく高スループットが必要です。
• コンプライアンスが重要です。GDPR、HIPAA、SOC 2によって、利用できるプロバイダーやリージョンが決まることがよくあります。
• ベンダーリスクが重要です。一つのプロバイダーだけに依存すると、単一障害点になります。複数プロバイダーの利用は適切な基本対策です。

2026年によく見られる構成は、最高品質が必要なユーザー向けリクエストにはホステッドのクローズドモデルを、大量かつ低コストの処理にはホステッドのオープンソースモデルを、限定的でレイテンシーが重要な機能にはオンデバイスを使うものです。自社運用は、規模と経済性が運用負荷に見合う場合に限ります。

第3層：ツールとMCP

LLMだけでできることは多くありません。データ、API、操作へのアクセスを提供する、利用者が定義した関数であるツールを呼び出せるようになると、LLMは有用になります。

ネイティブな関数呼び出し。 主要モデルはすべて、構造化された関数呼び出しAPIをサポートしています。JSONスキーマで関数を定義し、モデルが呼び出すタイミングを判断し、ホスト側が呼び出しを実行して結果を返します。

MCP（Model Context Protocol）。 Anthropicが導入し、現在ではOpenAI、Cursorなどにも広く採用されている、ツールサーバー向けの標準化プロトコルです。MCPサーバーがツールを公開し、MCPクライアント（LLMエージェント）が接続して利用します。ツールの実装を特定のモデルから切り離せます。

直接統合。 特定のCRMやデータベースなど、大量処理を伴う特定のユースケースでは、汎用MCPサーバーよりも直接アダプターを作成する方が容易なことがよくあります。

2026年の傾向は明確です。MCPが標準として優勢になっています。新規ツール開発の大半はMCPを対象にすべきです。性能が重要な経路では、直接統合も引き続き有用です。

実装上の現実をいくつか挙げます。

• ツールの説明は極めて重要です。 説明が不十分なツールは正しく使われません。ツールのdocstringは、プロンプトを書くように作成してください。
• ツール数は重要です。 50個以上のツールを利用できるモデルは、関連する5～10個だけを利用できるモデルより性能が低下します。積極的に絞り込んでください。
• エラー処理は重要です。 モデルが対応を変えられるよう、ツールエラーを構造化して伝える必要があります。
• 認可は難題です。 ユーザーごとにLLMの権限が異なるマルチユーザーシステムは、単純ではありません。認可判断をLLMに任せず、ツールラッパーで行ってください。

第4層：検索とメモリ

LLMには、学習していないデータが必要です。それを担うのが検索層です。

ベクトルデータベース。 Pinecone、Weaviate、Qdrant、Chroma、pgvectorを備えたPostgreSQL、Turbopufferです。埋め込みを保存し、最近傍検索を提供します。成熟し、よく理解された技術であり、セマンティック検索の標準です。

ハイブリッド検索。 ベクトル検索と従来のBM25キーワード検索を組み合わせます。意味的な一致と語彙上の一致をどちらも捉えます。統合にはReciprocal Rank Fusionを使用します。ツールにはElasticsearch、OpenSearch、Vespaがあります。

ナレッジグラフ。 Neo4j、Memgraph、独自のトリプルストアです。関係性の豊富なデータに使用し、Graph RAGアーキテクチャで利用されます。構築にはより多くの作業が必要ですが、関係性が重要な領域では品質が高くなることがよくあります。

RAG特化プラットフォーム。 LlamaIndex（現在は成熟しています）、LangChainのRAG抽象化、Haystackです。一般的なパターン向けの高レベルなフレームワークです。

リランキング。 Cohere Rerank、Voyage、独自のクロスエンコーダーです。最初の検索後、上位候補をより高価なモデルで並べ替え、精度を高めます。通常、検索品質が2～3倍向上します。

メモリ。 エージェントと会話には、Mem0、Letta（旧MemGPT）、または独自実装の構造化メモリ層を使用します。短期（現在の会話）、中期（最近の話題）、長期（ユーザーやアカウントに関する永続的な事実）を区別します。

アーキテクチャ上の問いは、この層をどこに置くかです。

• アプリ内： チームが記述した検索ロジックでLLM呼び出しをラップします。
• MCP層： 検索をツールとして公開します。
• サービス： アプリが呼び出す専用の検索サービスを設けます。

単一製品のモノリシックなシステムなら、アプリ内で問題ありません。複数製品を持つ組織では、検索を一貫した品質とポリシーを備えたサービスとして扱うことが、長期的に効果を発揮します。

第5層：プロンプトとコンテキストエンジニアリング

2026年には、「プロンプトエンジニアリング」はおおむね「コンテキストエンジニアリング」と同義です。呼び出しごとにコンテキストウィンドウへ何を入れるかを管理することを意味します。

構成要素は次のとおりです。

プロンプト。 多くの場合、変数を使ってテンプレート化します。バージョン管理に保存し、評価スイートでテストし、コードのように扱います。

プロンプト管理。 Promptfoo、Langfuse、PromptLayer、または社内システムなどのツールを使います。バージョン管理、A/Bテスト、ロールバックを担います。（HeliconeなどのLLMプロキシは、ここではなく後述の可観測性層に属します。この2カテゴリーは混同しやすいため注意してください。）

コンテキスト戦略。 各呼び出しに何を含めるかを決定します。

• system prompt（安定しており、振る舞いを定義）。
• 検索した知識（動的で、RAGから取得）。
• 会話履歴（管理し、長くなれば要約することが多い）。
• few-shotの例（クエリに基づいて動的に選択）。
• ツールの説明（関連ツールのみに絞る）。
• ユーザーの現在のクエリ。

コンテキスト圧縮。 コンテキストが長くなると、モデルの性能は低下します。過去のターンを要約する、重要な事実を構造化メモリへ抽出する、無関係な内容を削るといった戦略があります。活発に研究されている分野です。

ロングコンテキストの利用。 現在の最上位モデル（Claude、GPT-5.5、Gemini）では、100万トークンのウィンドウが標準です。実際に機能しますが、「context rot」は現実に起こります。モデルが技術的には対応していても、長い入力では品質が低下します。ロングコンテキストは慎重に使ってください。入れられるからといって、すべてを投入してはいけません。

第6層：オーケストレーション

多段階のLLMワークフローやエージェントをどのように連携させるのでしょうか。

APIの直接利用。 PythonまたはTypeScriptでループを自分で記述します。単純なケースや、実際に起きていることを理解するには最適です。

LangChain / LangGraph。 広く利用されています。エージェント用ステートマシンであるLangGraphは大幅に成熟しました。抽象化が厚く学習曲線もありますが、強力です。

CrewAI。 役割ベースのエージェントに重点を置くマルチエージェントフレームワークです。LangGraphより始めやすい一方、柔軟性は低くなります。

LlamaIndex agents。 特にRAGを多用するワークフローに強みがあります。

OpenAI Agents SDK。 より単純で規約が多く、OpenAIモデル向けに最適化されています。

Anthropic Claude SDK。 同様にClaude向けに最適化されています。

独自実装。 本番エージェントを提供する成熟したチームでは、独自のオーケストレーションが一般的です。フレームワークが課すコスト（抽象化による負担、デバッグの複雑さ、頻繁なバージョン変更）が、利点を上回るためです。

2026年に見られるパターンは、フレームワークでプロトタイプを作り、本番用には独自コードで書き直すことです。フレームワークはパターンの発見に役立ちます。パターンが分かれば、直接記述したコードの方が単純で信頼できます。

第7層：可観測性

可観測性なしに、本格的なLLMアプリケーションを提供することはできません。すべての本番システムに、次の機能が必要です。

トレース。 タイムスタンプ、モデル、入力、出力、レイテンシー、コスト、成功 / 失敗を含む、すべてのLLM呼び出しを記録します。多段階トレースはツリーで表現します。

コスト追跡。 呼び出し、機能、ユーザーごとに追跡します。コストは大きく、上限がありません。追跡しなければ、月末になって初めて気付きます。

品質監視。 本番トラフィックのサンプルを自動で品質確認し、品質低下時にアラートを出します。

ユーザーフィードバックの収集。 高評価 / 低評価、明示的なフィードバック、暗黙のシグナル（再試行率、離脱）を収集します。

デバッグ。 問題発生時には、呼び出しチェーン全体を確認する必要があります。エージェントの実行失敗には、多くの障害点が考えられます。

ツールにはLangSmith、Helicone、Arize、Phoenix、Braintrust、Weights & Biases、Datadog LLM Observabilityがあります。それぞれ強みが異なるため、早期に一つ選び、継続して使用してください。

小規模チームなら、LLM呼び出しごとに1行を記録する単純なPostgresテーブルでも、必要な機能の80%を得られます。規模や機能要件に見合う段階で専用ツールへ移行してください。

第8層：評価

本格的な本番運用で最も重要な層です。

オフライン評価。 定義済みデータセット、期待する出力、スコアリングを用意します。変更のデプロイ前に実行して、リグレッションを検出します。（中級レベルで詳しく説明しました。）

オンライン評価。 本番トラフィックのサンプルを、自動（LLM-as-judge）またはユーザーシグナルで評価します。ドリフトを検出します。

デプロイ前評価。 プロンプトやモデルの変更を本番反映する前に、評価スイートを実行してレビューします。CIの一部になります。

評価の分類。 懸念事項ごとに異なる評価を使います。

• 振る舞い：期待どおりに動作するか。
• 安全性：拒否すべき内容を拒否するか。
• 品質：出力はどの程度優れているか。
• 堅牢性：敵対的入力にどう対処するか。
• コスト / レイテンシー：予算内に収まっているか。

ツールにはPromptfoo、Braintrust、LangSmith、独自スイートがあります。どれにも用途がありますが、最も簡単に始められるのはPromptfooです。

第9層：アプリケーション層

固有の製品が置かれる層です。ここでは次のことを決定します。

エージェントかワークフローか。 エージェント（ツールを使うLLMのループ）は強力ですが、信頼性の確保が難しくなります。ワークフロー（固定された一連のLLM呼び出し）は簡単で、多くの場合は十分です。標準ではワークフローを選び、本当に必要な場合だけエージェントを使ってください。

同期か非同期か。 ユーザー向けのリアルタイム処理か、バックグラウンドのバッチ処理か、ストリーミングかによって、モデル、インフラ、UXの選択が変わります。

シングルテナントかマルチテナントか。 顧客固有のデータ分離要件が、重要なアーキテクチャ判断を左右します。

オンプレミスかクラウドか。 コンプライアンス、セキュリティ、コストによってオンプレミスを選ぶ場合があります。運用ははるかに複雑になります。

エッジケース。 ハルシネーション、プロンプトインジェクション、不正利用です。本番システムにはガードレールが必要です。導入せずに提供してはいけません。

重要なトレードオフ

明示しておくべきトレードオフをいくつか挙げます。

品質、コスト、レイテンシー

基本となる三角関係です。通常は二つを最適化できても、残る一つが悪化します。

• 高品質 + 低レイテンシー = 高コスト。
• 低コスト + 低レイテンシー = 低品質。
• 高品質 + 低コスト = 高レイテンシー（バッチ処理または推論モデル）。

タスクごとに優先順位を決めてください。三つすべてを最適化しようとしてはいけません。その結果、すべてが中途半端になります。

構築か購入か

各層は、自社で構築することも購入することもできます。

• 構築： 制御しやすくなる一方、保守とコスト（エンジニアの時間）が増え、差別化能力を得られます。
• 購入： すぐに始められ、制御しにくく継続的なベンダーリスクがある一方、差別化にならない機能を外部化できます。

有効な目安は、コモディティ層（ベクトルストレージ、基本的な可観測性）を購入し、差別化層（固有のオーケストレーション、プロンプト、評価）を構築することです。これを逆にして、差別化要素を購入し、コモディティインフラを構築するのは、よくある間違いです。

オープンソースかクローズドか

2026年の現実として、多くのタスクでオープンソースモデルは競争力があります。一部のタスクでは、より高速で安価なため優れています。長期的な推論など、ほかのタスクではクローズドな最先端モデルが依然として先行しています。

判断要因は次のとおりです。

• 品質要件。 あらゆるタスクの最先端を求めるなら、クローズドモデルが依然として優位です。
• 大規模運用時のコスト。 オープンソースを自社運用すると、大量処理では安価になります。
• プライバシー / コンプライアンス。 機密データには、自社インフラでの自社運用が必要になることがよくあります。
• カスタマイズ。 ファインチューニングや独自学習にはオープンソースが必要です。
• 運用能力。 クローズドAPIの運用は極めて簡単ですが、自社運用には多大な作業が必要です。

2026年の本番システムの大半はハイブリッドであり、呼び出しごとの判断に基づき、一部にはクローズドモデル、ほかにはオープンモデルを使います。

レイテンシーか推論の深さか

推論モデル（GPT-5.5 thinking、適応型思考機能付きClaude）は、難しい問題の品質を高める代わりにレイテンシーが増えます。価値がある場合もあれば、ユーザーが30秒待てない場合もあります。

よくあるパターンは、単純なクエリを高速モデルへ、難しいクエリを推論モデルへ振り分けることです。ルーター（小型モデルまたはヒューリスティック）で判断します。

ロングコンテキストかRAGか

コンテキストをモデルに詰め込む（100万トークンのウィンドウを使う）ことも、関連するチャンクを検索する（RAGを使う）こともできます。

• ロングコンテキスト：単純で検索インフラが不要ですが、呼び出しごとの費用が高く、「context rot」が実際に起こります。
• RAG：呼び出しごとの費用は安い一方、準備が増え、検索品質そのものがエンジニアリング上の課題になります。

2026年の成熟した答えは、通常、本番環境ではRAGを使い、プロトタイプ、特殊な一回限りのタスク、または検索品質が低すぎて結果を損なう場合にはロングコンテキストを使うことです。

エージェントかワークフローか

前述のとおりです。標準ではワークフローを選び、柔軟性が本当に必要な場合にエージェントを使用してください。私たちが目にする多くの「エージェント」システムは、ワークフローにすべきものです。

2026年のリファレンスアーキテクチャ

具体化するため、AI機能を備えた中規模SaaS製品の典型的な本番システムを示します。

ユーザー → アプリケーション（React/Next.js）
    ↓
APIゲートウェイ / 認証
    ↓
LLMサービス（独自ラッパー）
    ↓
  ルーター（小型モデルまたはヒューリスティック）
    ├→ 単純なタスク：中位モデル（Claude Haiku 4.5クラス）
    ├→ 標準タスク：Claude Sonnet 5またはGPT-5.5
    ├→ 難しいタスク：Claude Opus 4.8または推論モデル
    └→ 特殊タスク：ビジョン / 音声 / 埋め込みの特化モデル
    ↓
ツール層（MCPサーバー + 直接統合）
    ↓
検索層（Pinecone + ハイブリッド + リランカー）
    ↓
可観測性（HeliconeまたはLangSmith）
    ↓
evalスイート（Promptfoo、CIで実行）

アクティブユーザー1人当たりの月額コスト：利用頻度に応じて通常1～10ユーロです。 構築のエンジニアリング工数：経験豊富なチームで6～12週間です。 運用コスト：トラフィックに応じて低から中程度です。

よくある問題

本番LLMスタックで繰り返し発生する失敗パターンです。

パターン1：すべてに一つのモデルを使う。 コスト超過と品質問題が発生します。対策：ルーティング。

パターン2：可観測性がない。 デバッグ、測定、改善ができません。対策：早期に計測を組み込む。

パターン3：評価がない。 品質のドリフトを検知できません。対策：初日から評価を用意する。

パターン4：フレームワークへのロックイン。 LangChainやCrewAIのデバッグが専任業務になります。対策：コストを上回る効果がない限り、フレームワークを使わない。パターンが明確になったら直接記述したコードへ移行する。

パターン5：購入すべきインフラを構築する。 独自のベクトルDBは、おそらく時間の無駄です。独自の可観測性も、おそらく時間の無駄です。コモディティ層は購入してください。

パターン6：構築すべきインフラを購入する。 プロンプトを第三者へ外注することや、評価を外注することです。これらは競争上の堀であるため、自社で保有してください。

パターン7：プロンプトインジェクションを無視する。 ユーザー提供コンテンツを入力サニタイズしない本番システムです。大きなリスクなので、早期に軽減してください。

パターン8：影響の大きいフローでエージェントを信頼する。 人による確認なしで返金を承認するLangGraphエージェントなどです。いずれ必ず問題が起こります。重大な操作にはhuman-in-the-loopを追加してください。

パターン9：誤った対象を最適化する。 総コストの大半がエンジニアリング時間なのに推論コストを最適化する、またはユーザーが気にしていないのにレイテンシーを最適化することです。実際に重要なものを測定してください。

パターン10：複数プロバイダーの計画がない。 主要プロバイダーで障害が発生したとき（発生するかどうかではなく、いつ発生するかの問題です）、システムも停止します。フォールバックを構成してください。

日付を明記した三つの予測（2027年半ばに再確認）

予測するだけなら簡単ですが、日付を定め、反証可能にするのは簡単ではありません。誤りだったと公に認める覚悟のある三つの予測です。

1. EUでホストされる推論は、2027年半ばまでに中位モデルで実用上の価格同等性を達成します。 EU主権下の処理能力が急速に稼働し始め、米国リージョンのエンドポイントに対する割増料金は縮小しています。同等になれば、GDPRの影響を受けるワークロードに対する標準推奨は、「マスキングを伴うハイブリッド」から「EUホストを標準」に変わります。確信度：中。

2. フレームワーク層の統合は続き、プロトコル層はさらに優勢になります。 過去18か月でMicrosoftは二つのエージェントフレームワークを統合し、OpenAIは独立していたブラウザエージェント製品をChatGPTに再統合しました。一方、MCPは発表段階からベンダー横断の標準へ進みました。私たちは、統合作業をプロトコル（MCP、構造化出力）に集中し、オーケストレーションフレームワークは交換可能に保ちます。確信度：高。

3. 小型モデルによるルーティングは、最適化策ではなく標準アーキテクチャになります。 最上位モデルの価格が維持され、小型モデルが改善を続けるなら、「すべてに最上位モデルを使う」という考え方は、クラウドエンジニアにとっての「すべてをベアメタルで動かす」という考え方と同じくらい時代遅れに見えるようになります。確信度：コスト重視の中小企業については高。

意図的に予測しないものは、モデルの順位です。ここに特定の順位を掲載しても、このページの次回レビュー日より前に古くなります。

アーキテクチャを正しく設計する

2026年のLLMスタックは現実に存在する多層構造であり、選択が重要です。成功するチームは次のことを実践しています。

• 担当部分だけでなく、スタック全体を理解する。
• 呼び出しごとに明示的なトレードオフ（品質、コスト、レイテンシー）を設定する。
• 差別化する部分は構築し、そうでない部分は購入する。
• 初日から計測する（可観測性、評価）。
• 機動性を保つ（モデルを移行可能にし、複数プロバイダーに対応する）。

失敗するチームは、一つのベンダーを選んでそのAPIをハードコードし、計測も測定も行わなかった結果、高価で壊れやすく、改善できないシステムを抱えています。

アーキテクチャを正しく設計してください。その後のすべてが容易になります。