AI アプリの技術スタック全体像と主要プレーヤー（毎月更新）

AI 関連の名前を追っていると、LLM、推論エンジン、ゲートウェイ、エージェントフレームワーク、MCP、ベクトルデータベース、クラウドサービスが同じ文脈で並びます。ただし、これらは同じ役割の競合製品ではありません。ここでは製品名ではなく、責務で分類します。

1つの製品が複数の責務にまたがることもあります。分類は、新しい技術の比較対象と組み合わせを判断する目安として使います。

この記事でわかること

• AI アプリの技術スタックを4つのレイヤーと横断的関心事に分けた全体像
• レイヤーごとの役割と主要プレーヤー、選定時の観点・比較軸

まず、AI 基盤全体は次のように大別できます。

全体像：4つのレイヤーと横断的関心事

この記事の中心である推論・アプリケーション基盤と、AI アプリケーションを合わせて「AI アプリの技術スタック」とし、次の4つのレイヤー（モデル層・推論層・エージェント層・アプリケーション層）に分けて見ます。オブザーバビリティ（Observability、可観測性）とセキュリティは、特定のレイヤーではなく横断的関心事として扱います。ユーザーのリクエスト経路を図示します。

flowchart LR
    E[外部のツール・データ<br>他のエージェント]
    U([ユーザー])
    subgraph X[横断的関心事：オブザーバビリティ・評価、サンドボックス、ガードレール]
        subgraph APP[アプリケーション層]
            UI[UI・<br>エージェント製品]
            B[ワークフロー<br>ビルダー]
        end
        subgraph AGT[エージェント層]
            H[フレームワーク<br>ハーネス<br>マネージド実行環境]
            R[(RAG・データ)]
        end
        subgraph INF[推論層]
            G[AIゲートウェイ<br>推論ゲートウェイ]
            S[推論ランタイム<br>サービング]
        end
        subgraph MOD[モデル層]
            M[モデル<br>形式・量子化]
        end
    end
    U --> UI
    UI -->|AG-UI| H
    B --> H
    H --> R
    H -->|推論API| G
    G --> S --> M
    H -->|MCP| E
    H -->|A2A| E

これとは別に、ローカル PC、VPS、GPU クラウド、AWS などのクラウドのどこにデプロイするかという「実行環境」の軸があります。以下、下位のレイヤーから順に解説します。

各レイヤーの表では、提供元と製品名が違う場合は「提供元 / 製品」と書きます。提供形態は、OSI 承認のライセンスで公開されているものを「OSS」、独自の条件を付けたライセンスで公開されているものを「ソース公開」、ホスト型のサービスとして提供されるものを「マネージド」、中身を公開せずに配布されるものを「商用」とし、同じ提供元の有償版があれば「＋有償版」を付けます。

モデル層

LLM はモデルの一種

LLM（Large Language Model）はモデルの一種です。AI 基盤で扱うモデルには、文章やコードを生成するモデルだけでなく、Embedding、Reranker、画像・音声モデル、判断に特化したモデルもあります。

TypeSafe AI のJevは、チャットモデルではなく、あらかじめ定義された型の選択、スコア、確率などを返す判断モデルとして位置づけられています。

Jev のような判断モデルは、エージェントやアプリケーションのコードから呼び出すコンポーネントです。「どのルートへ送るか」「処理を続けるか」「どの候補を選ぶか」といった分岐判定に使います。

LLM 系統を中心に見ると、主要なプレーヤーは次のようになります。提供形態の「オープンウェイト」は、学習で決まったモデルの中身である重み（weights、パラメータの数値）を公開し、ダウンロードしてローカルで実行できるモデルを指します。学習データや学習コードまで公開されるとは限らず、ライセンスや利用ポリシーで条件が付くこともあるため、オープンソースとは区別されます。

OpenAI も現在は API だけではなく、gpt-oss-120b と gpt-oss-20bというオープンウェイトモデルを、Apache 2.0と利用ポリシーのもとで提供しています。Google にもGemmaがあります。Meta は API で提供する Muse と別に、Muse Glimmerを Apache 2.0のオープンウェイトで公開しています。

そのため、プロバイダー名だけで「API 型」「セルフホスト型」と分けるのは難しくなっています。モデル単位で、API 提供か、重みを取得できるか、ライセンスは何かを確認する必要があります。

この記事では個々の最新バージョンを網羅しません。モデルの更新速度が速いため、ここではファミリーと提供形態を整理し、個別バージョンの性能比較は別の論点とします。

モデル名とファイル形式は別物

モデル名と、モデルファイルの形式は別です。

「Qwen の GGUF を Ollama で動かす」という場合、Qwen はモデル、GGUF は形式、Ollama は推論ランタイムです。

GGUF は量子化済みモデルの配布でもよく見かけます。

量子化は RAM・VRAM の削減に有効ですが、速度、カーネル対応、精度にも影響します。

比較軸

• タスク性能（コーディング、Reasoning、マルチモーダル）とコンテキスト長
• 提供形態（API・オープンウェイト）とライセンス
• コスト（API のトークン単価、セルフホスト時の必要 VRAM）
• 量子化の形式と、推論ランタイムの対応（GGUF は llama.cpp 系、AWQ・GPTQ は vLLM など）

推論層

推論ランタイムは、ローカル実行向けとサービング向け

モデルの重みを CPU や GPU へ読み込み、実際にトークンを生成するのが推論ランタイムです。

Ollama には Apple Silicon 向けのMLX 対応（Preview）も加わっています。MLX で LLM を実行する場合は、MLX LMを使います。

vLLM、SGLang、TensorRT-LLM は、多数のリクエストをさばくモデルサービングの代表的なエンジンです。バッチ処理や KV Cache（過去のトークンの Key / Value を保持し、再計算を省く）の管理で、スループットを上げます。NVIDIA Dynamo は、こうしたエンジンを複数の GPU ノードにまたがって実行するための分散推論フレームワークです。vLLMは OpenAI 互換 API や分散推論を提供し、Apple Silicon 上で並行してサービングするvllm-metalもあります。

AI ゲートウェイと推論ゲートウェイ

「ゲートウェイ」という名前には、少なくとも2つの役割があります。

1つは、複数のモデルプロバイダーの API エンドポイントを統一するAI ゲートウェイ（LLM ゲートウェイとも呼ばれます）。もう1つは、GPU クラスタ内でどのモデルサーバーへリクエストを送るかを決める推論ゲートウェイです。

LiteLLMは、セルフホストで実行する AI ゲートウェイです。

Kong AI Gateway 2.0は、モデルへのアクセスだけでなく、複数の MCP サーバーを1つにまとめる機能、ID に基づくアクセス制御、コスト管理などを扱います。Kong AI Gateway 2.0は、Kong のマネージドサービスである Kong Konnect で提供されています。

一方、SageMaker HyperPod Inference Gatewayは、GPU-aware なルーターです。KV Cache の使用率、Queue Depth、LoRA アダプター（追加学習した差分の重み）の所在などの推論のシグナルを見ながら、vLLM や SGLang など OpenAI 互換サーバーの Pod へリクエストをルーティングします。

どちらも「ゲートウェイ」ですが、LiteLLM や Kong はアプリケーションから見たモデルへのアクセスの統制、HyperPod Inference Gateway は GPU クラスタ内のリクエストのルーティングに近い役割です。

推論ゲートウェイはクラウドの専用機能だけではなく、Kubernetes でも Gateway API Inference Extension や llm-d のように、オープンソースで標準化が進んでいます。

比較軸

• 用途（ローカル検証は Ollama・llama.cpp、本番サービングは vLLM・SGLang）
• TTFT（最初のトークンが返るまでの時間）とスループット（tokens/sec）、複数 GPU への分散
• 対応ハードウェア（NVIDIA GPU、Apple Silicon、CPU）と OpenAI 互換 API の有無
• ゲートウェイは、セルフホストかマネージドか（LiteLLM・Kong と OpenRouter）、キー・コスト管理、ルーティング単位（プロバイダー間か GPU Pod 間か）

エージェント層

フレームワークは部品、ハーネスは完成した実行系

エージェントは、モデル呼び出し、ツール実行、結果のフィードバックを繰り返すエージェントループで動作します。

このエージェントループを組み立てるのがエージェントフレームワークや SDK です。加えて、必要なコンポーネントを統合済みの「ハーネス」という呼称も定着しつつあります。

フレームワークとハーネスの境界は厳密ではありません。この記事では、フレームワークをエージェントループや状態管理の構築用コンポーネント、ハーネスをコンテキスト管理、ツール利用、サブエージェントなどを統合済みの実行系として扱います。

Strands harnessは、汎用エージェントを統合済みの状態で、ローカルまたは任意のプロバイダーへデプロイできるハーネスです。

Microsoft Agent Frameworkも、メモリ、ユーザーとの対話的なやり取り（Interactive Experience）、障害から再開できる実行（Resilient Execution）などを備えるようになっています。

エージェントループごと任せる、マネージドなエージェント実行環境

エージェントフレームワークを自プロセスで実行する構成とは別に、長時間実行、コンテキスト管理、サンドボックス、サブエージェントなどをプラットフォームに委譲するサービス（Managed Agent Runtime）が増えています。

OpenAI Agents APIは、Codex で使われているハーネスに加え、エージェントを長時間・継続的なセッションで実行するためのインフラ、ファイルやコードを扱うサンドボックス環境などを、マネージドな API として提供します。Anthropic のClaude Managed Agentsも、構成済みのハーネスと、Anthropic のクラウドまたは自社の環境に置くサンドボックスを、API として提供します。

なお、Agents API と Agents SDK は別のものです。Agents SDK はエージェントを組み立てるための SDK、Agents API はそのエージェントループや長時間実行のインフラまで OpenAI 側で実行する、マネージドな実行環境です。

AWS のBedrock AgentCore、Google Cloud のGemini Enterprise Agent Platformの Agent Runtime（旧 Vertex AI Agent Engine）、Microsoft のFoundry Agent Serviceも、エージェントの本番運用向けに、実行環境、メモリ、ツール連携、ID・権限管理、オブザーバビリティなどをまとめて提供します。

MCP はツール、A2A はエージェント、AG-UI は UI

エージェント周辺の接続も、役割別に分化しています。

MCP のトランスポートは、ローカルのプロセスとは stdio（標準入出力）、ネットワーク越しのサーバーとは Streamable HTTP です。2026-07-28版の仕様では、ステートレス化などリモート運用向けの変更が入りました。

A2Aは1.0が安定版になり、AG-UIも Core / Client が1.0になりました。

この3つは競合ではなく、担当する境界が違います。

MCP と Tool Calling も役割が別です。MCP で集めたツールの定義も、最終的には Tool Calling のツールとしてモデルに渡されます。MCP はツールの取得と実行、Tool Calling はモデルによる呼び出し対象の指定を担います。

RAG は、検索を含む構成全体

RAG（Retrieval-Augmented Generation）はベクトルデータベースそのものではなく、外部情報を検索し、生成時のコンテキストへ加える構成全体です。

典型的な RAG では、Embedding、検索、必要に応じた Reranking を行い、取得したドキュメントをコンテキストへ入れます。全文検索とベクトル検索を混ぜるハイブリッド検索も一般的です。

エージェントでは検索用のデータ以外にも、セッション、途中の状態、ジョブ、ツールの結果、ファイル、監査ログなどが必要になります。これらには PostgreSQL、Redis、オブジェクトストレージ、キューなど、従来のバックエンド技術も使われます。

比較軸

• 言語（Python・TypeScript）
• 状態管理と永続化、マルチエージェント対応
• モデル依存度（特定プロバイダーの SDK か、プロバイダー非依存か）
• 実行形態（自プロセスか、マネージドな実行環境か）
• RAG・データは、既存 DB（PostgreSQL＋pgvector）で足りるか、専用のベクトル DB が必要な規模か

アプリケーション層

エージェント製品も、中は複数のレイヤーでできている

フレームワークや実行環境とは別に、タスクを直接委任できるエージェント製品（コーディングエージェントなど）があります。

Claude Code や Codex はコーディング用のエージェント製品、LangGraph や Agents SDK はエージェント構築用の基盤です。

エージェント製品の内部にも、モデル、ハーネス、Tool Calling、MCP、サンドボックスなど、下のレイヤーの技術が入っています。部品を組み込んで完成させた製品なので、この記事ではアプリケーション層に置きます。製品名だけでなく内部構成まで把握すると、何と比べるべきかが見えます。

業務フローにエージェントを組み込むビルダー

エージェントや RAG を組み合わせて、業務で使うアプリケーションやワークフローを構築するプラットフォームです。業務ワークフローとエージェントを同一画面で構築・運用するため、フレームワークとも UI とも別カテゴリとして扱います。

Dify はエージェントとワークフローを同じプラットフォーム内で扱い、セルフホストにも対応します。

n8n はワークフローの自動化が中心ですが、n8n Agentsではエージェントが既存の n8n のワークフローをツールとして使えるため、決定的なワークフローとエージェントの非決定的な処理を、同じプラットフォームで組み合わせられます。

大手クラウドでは、Microsoft Copilot Studio や Gemini Enterprise の Workflow Builder が、業務担当者も使えるノーコード・ローコードのビルダーを提供しています。

UI は、エンドユーザー向けフロントエンド

モデルやエージェントの利用 UI も独立したカテゴリです。

Open WebUI、LibreChat、AnythingLLM は、モデルへの接続だけでなく、RAG、ツール、エージェント、ユーザー管理など複数の機能を持っています。

Dify や n8n などのビルダーは開発・運用基盤、Open WebUI などはエンドユーザー向けの利用環境という区分です。ただし製品機能は重複します。

比較軸

• 対象ユーザー（開発者、業務担当者、エンドユーザー）
• セルフホストの可否
• 接続できるモデルとツール（MCP 対応の有無）
• ユーザー・権限管理

横断的関心事：オブザーバビリティとセキュリティ

オブザーバビリティは挙動、評価は出力の品質を見る

AI アプリケーションでは、通常の CPU、メモリ、レイテンシ、エラー、ログに加えて、プロンプト、トークン数、コスト、ツール呼び出し、エージェントの実行ステップなどを観測します。

このほか、OpenAI Agents SDK などのエージェント SDK にも、Run、Tool Call、Handoff などを記録する組み込みのトレースがあります。

オブザーバビリティは「何が起きたか」を見るものです。評価（Evals）は、モデルやエージェントの出力をテストデータと採点基準で測るもので、回答の正確さ、RAG の検索結果の妥当性、タスクの達成、プロンプトインジェクションへの耐性などが対象です。

エージェントが触れられる範囲を、実行時に制限する

エージェントがコードやシェル、ファイル、ネットワーク、認証情報を扱うようになると、エージェントが何にアクセスできるかを実行時に制限するレイヤーも必要になります。一般にサンドボックスと呼ばれます。

NVIDIA のOpenShellは、Claude Code、Codex、OpenCode などのエージェントをサンドボックス内で実行し、ファイルシステム、ネットワーク、プロセスにポリシーを適用し、認証情報は承認した接続先にだけ渡します。NVIDIA はこれを、エージェントのための安全なランタイム（secure runtime）と説明しています。

OpenAI Agents API のホスト型サンドボックスのように、マネージドなエージェント実行環境そのものがサンドボックスを内包する場合もあります。このためサンドボックスは、単独の製品として提供される場合と、マネージドな実行環境の一機能として提供される場合があります。単独の製品として提供される主なサンドボックスは次のとおりです。

ガードレールは、入出力を検査する

サンドボックスが「何に触れられるか」を制限するのに対して、ガードレールはモデルやエージェントの入出力そのものを検査します。プロンプトインジェクションやジェイルブレイクの検知、有害な出力の分類、話題の制御などが対象です。

ガードレールは、大手クラウドのマネージドなサービスのほか、Kong などの AI ゲートウェイやマネージドな実行環境に組み込まれている場合もあります。

データがどこで処理・保持されるかを確認する

モデルの API に送った入力は、学習に使われなくても、不正利用の監視などのために一定期間保持されることがあります。また、同じモデルでも、提供元と推論の設定によって、処理される地域が変わります。

たとえば Claude Opus 5.5は、Anthropic の APIでは推論地域に米国か Global を指定します。Amazon Bedrock では、日本国内で処理するJP geo の推論プロファイルを指定できます。

比較軸

• OpenTelemetry 対応（既存の監視基盤と統合できるか）
• 評価の運用形態（リリース前のオフライン評価か、本番トラフィックのオンライン評価か）
• ガードレールとサンドボックスの適用位置（ゲートウェイ、実行環境、アプリケーション）
• データの扱い（学習への利用、保持期間、ZDR の可否、処理地域）

実行環境

次に、ここまでのソフトウェアを実際にどこへデプロイするかです。

実行環境はレイヤーの分類とは別です。LiteLLM はローカル、VPS、Kubernetes のいずれにもデプロイでき、vLLM も自社の GPU クラスタや GPU クラウドで実行できます。

一方、AWS、Google Cloud、Microsoft のマネージドな AI プラットフォームは、この記事で分けた複数のレイヤーを、1つのサービス群として提供します。製品同士を比べるときは、「どのレイヤーまで含んでいるか」を揃えて比べます。

比較軸

• コスト（常時稼働の固定費か、利用量に応じた従量課金か）
• GPU の確保（手元のハードウェアか、GPU クラウドか、マネージドな API に任せるか）
• 運用の手間（OS・ランタイムの更新、スケール、障害対応を誰が持つか）
• データの置き場所（自社環境に閉じるか、クラウドのどのリージョンで処理するか）

選定時の観点

各レイヤーの比較軸とは別に、レイヤーをまたいで確認する観点です。

まとめ

AI アプリケーションを構成する技術は、モデル・推論・エージェント・アプリケーションの4つのレイヤーと、オブザーバビリティ・セキュリティの横断的関心事として整理できます。各レイヤーの中でも、ゲートウェイ、ハーネス、マネージドな実行環境、接続プロトコル、ワークフロービルダーと、役割が細かく分かれてきています。

一方で、実際の製品は複数の役割をまたぎます。新しい製品や技術が出てきたときは、「何の代わりになるか」だけでなく、どの境界を担当し、前後に何を必要とするかを見ると、位置づけが明確になります。

この分類は固定ではなく、新しい製品やバージョンに合わせて改訂します。

参考資料

• Introducing System One Models & Jevtypesafe.ai
• Open models by OpenAIopenai.com
• Gemma releasesGoogle AI for Developers
• Safetensorshuggingface.co
• GGUFGitHub
• Ollama is now powered by MLX on Apple Silicon in previewollama.com
• Online Servingdocs.vllm.ai
• Announcing vllm-metal: Concurrent Serving on Apple Siliconvllm.ai
• LiteLLM Getting Starteddocs.litellm.ai
• Kong AI Gateway 2.0 Is Now GA — And It's Already Moving FasterKong Inc.
• Amazon SageMaker HyperPod Inference Gateway for scalable LLM inferenceAmazon Web Services, Inc.
• Introducing Strands harness: frontier performance with 28% lower token costStrands Agents
• What's new in Microsoft Agent Framework: Interactive experiences, memory, and resilient executionMicrosoft Agent Framework
• Introducing the Agents APIopenai.com
• Overview - Amazon Bedrock AgentCoredocs.aws.amazon.com
• Scale your agents - Gemini Enterprise Agent PlatformGoogle Cloud Documentation
• What is Microsoft Foundry Agent Service?learn.microsoft.com
• The 2026-07-28 SpecificationModel Context Protocol Blog
• A2A ReleasesGitHub
• AG-UI: the Agent-User Interaction ProtocolGitHub
• Introducing n8n Agentsn8n Blog
• OpenShellGitHub
• Data controls in the OpenAI platformOpenAI Developers
• Is my data used for model training?privacy.claude.com
• API and data retentionClaude Platform Docs
• Route model inference requests across AWS Regions with cross-Region inferencedocs.aws.amazon.com
• Data residencyClaude Platform Docs
• Claude Opus 5.5docs.aws.amazon.com