顧客の LLM エージェントのテレメトリデータを分析した結果、複数プロバイダーを併用する傾向が組織の間で高まっていることがわかりました。OpenAI が 63% のシェアを維持する一方で、Google の Gemini と Anthropic の Claude は、この 1 年でそれぞれ 20 ポイント、23 ポイントシェアを伸ばしています。

重要なのは、OpenAI のシェアは 1 年前の 75% から低下しているものの、利用量自体が減少しているわけではないという点です。Datadog の顧客においては、OpenAI を利用する企業数は 2 倍以上に増加しており、他のプロバイダーの成長がそれを上回った結果としてシェアが相対的に低下しています。

モデルの多様化は組織内でも進んでいます。現在、70% 以上の組織が 3 つ以上のモデルを利用しており、7 つ以上のモデルを利用する組織の割合もほぼ倍増しています。単一のデフォルトモデルを選択するのではなく、各ワークロードのレイテンシー、コスト、運用リスク、タスク要件に応じて最適なモデルを使い分けるために、モデルポートフォリオを構築する動きが広がっています。

ただし、このマルチプロバイダー型のプラットフォーム構成は、プラットフォームエンジニアリング、DevX、コンプライアンスの面で新たな課題も生み出します。複数のモデルプロバイダーやサービスにまたがる API 呼び出しを個別に扱う必要があるため、迅速な改善サイクルの実現や、安全性基準とコンプライアンス基準の一貫した適用が難しくなります。また、プロバイダー側でレート制限やパフォーマンス低下が発生した場合のフェイルオーバー対応も複雑になります。そのため、各環境でモデルプロバイダーの API を直接呼び出すのではなく、LLM リクエストを一元管理するためのモジュール化されたルーティング機構 (ゲートウェイサービスや、OpenRouter のようなマネージドゲートウェイ) を活用する必要性が高まっています。

先進的なチームは、推論をパイプラインとして扱い、抽出やタグ付けには軽量モデル、統合には高性能モデルといったように各ステージに最適なモデルを継続的に評価、ベンチマークしながら切り替え、コストの低下やモデル性能の進化に応じて最適化を進めています。モデルゲートウェイを運用し、評価を継続的に行えるようにすることで、チームは出力品質、コスト、レイテンシーに基づいて、各ユースケースに最適なモデルを選択できます。特に、オンライン評価の活用は、本番環境におけるモデルやエージェントの出力品質、安全性、パフォーマンスを把握し、適切なモデル選定を行ううえで重要です。

組織がマルチモデル環境へ移行するにつれて、その運用の複雑さも増しています。Datadog の顧客におけるモデル利用状況の分析から、チームは競争力を維持するために新しいモデルの検証には積極的である一方、本番環境で稼働中の旧モデルの廃止には時間がかかる傾向があることがわかりました。その結果、多くの組織では、モデルの整理が追いつかないまま、新しいモデルが追加され続けている可能性があります。エージェントを本番環境で運用する場合、モデルが増えるほど運用負荷が高まり、評価の負担も増加します。そのため、導入済みのすべてのモデルについて、パフォーマンスの継続的な検証とリグレッション管理が必要になります。

同じプロンプト、ツール、エージェントワークフローでも、モデルによって結果が異なるため、モデルが増えるごとに品質、レイテンシー、コストの特性もそれぞれ異なります。実務上は、こうしたモデルの入れ替わりがガバナンス上の課題になります。

Datadog では、組織が新しいモデルのリリースにどのように対応しているかを把握するため、7 つの主要なモデルの採用率を分析しました。その結果、チームは新モデルのリリース後、それを比較的短期間で導入していることがわかりました。例えば、Claude Sonnet 4.6 はリリース初月で採用率 17% に達しています。一方で、Sonnet 4.5 や GPT-4o といった旧モデルの採用率は低下しているものの、2026 年 3 月時点でもそれぞれ 19%、22% と一定の水準を維持しており、Sonnet 4.6 や GPT-5.4 と同程度となっています。2026 年時点では、どのモデルが最適かははっきりしておらず、複数のモデルを並行して運用する傾向が強まっています。

マルチモデル環境は、継続的な評価やガバナンス、ゲートウェイによる効率的なルーティングによって適切に管理できますが、プロバイダーが旧モデルの提供終了を進める中で、これらのモデルの段階的な廃止にも継続的に対応していく必要があります。例えば、2026 年 3 月のリクエストトレースでは GPT-4o が依然として最も多く使われているモデルでしたが、OpenAI はすでに ChatGPT の UI 上でこのモデルの提供を終了しており、API での今後のサポートには不透明な点があります。

LangChain、Pydantic AI、LangGraph、Vercel AI SDK などのエージェントフレームワークは、一般的なパターンを容易に組み込めるようにすることで、開発を加速します。当社の調査では、フレームワークの導入率は 2026 年に前年比でほぼ倍増しており、2025 年初頭の 9% 以上から、2026 年初頭には約 18% にまで増加しています。同様に、エージェントフレームワークを利用するサービス数も、同期間で 2 倍以上に増加しています。フレームワークは開発を加速させる一方で、運用の複雑さやコストの増加を招く可能性もあります。そのため、エージェントの実行状況を可視化し、非効率な共通ロジックを特定して、より最適化されたワークフローに置き換えるためには、包括的なエージェントテレメトリが不可欠です。

特筆すべき点として、このフレームワーク導入の拡大は、スタートアップ、中堅企業、大企業のいずれにおいても同様の傾向が見られました。

フレームワークの定型コードを使って主要なパターンを実装すると、内部でステップや分岐が増え、実行時の挙動が把握しにくくなることで、エージェントの肥大化が起こりやすくなります。フレームワークを活用した AI アプリケーション開発では、ツールの分岐呼び出しやリトライ、条件分岐といった処理も、1 回のインポートで簡単に追加できます。これにより、コストやレイテンシーが徐々に増加し、障害の再現も難しくなる可能性があります。そのため、エージェントの実際の実行状況を把握し、想定外の挙動を診断し、ワークフローが意図した結果からどこで逸脱しているかを特定するために、包括的なエージェントテレメトリの収集が重要になります。こうしたシグナルは、非効率な共通ロジックをカスタムのワークフローに置き換える判断にもつながります。

当社の調査では、顧客トレースにおける入力トークンの 69% が、ユーザーの初期クエリから連鎖的に実行される内部指示、ポリシー定義、ツールのガイダンスなどを含むシステムプロンプトに費やされていました。この結果は、Datadog の顧客におけるコンテキスト設計の多くが、繰り返し使用されるシステムプロンプトの最適化に費やされていることを示しています。トークン使用量を削減するため、可能な限りシステムプロンプトを短縮し、再利用可能な要素はモジュール化してキャッシュできるようにすることが推奨されます。

構成があらかじめ組み込まれたシステムでは、ツールの利用やポリシー、安全対策のルールが増える傾向があります。こうしたガードレールやツールガイダンスが呼び出しごとに繰り返しそのまま使われる場合、コストとレイテンシーの大きなボトルネックになります。

プロンプトキャッシュは、モデルの挙動を変えずにコスト削減と高速化を実現できる有効な手段です。特に、システム指示、ポリシー、ツールスキーマといった安定した構成要素が呼び出し間で再利用できる場合に効果を発揮します。しかし、プロンプトキャッシュに対応しているモデルであっても、キャッシュ読み取り入力トークンが確認できた LLM 呼び出しスパンは全体の 28% にとどまりました。これは、多くの LLM 呼び出しで依然としてプロンプト全体が毎回処理されていることを示しています。

アプリケーションにおけるキャッシュヒット率やキャッシュ済みトークンの割合が低い場合、その主な原因はプロンプトの構成にあることが少なくありません。プロンプトの構成が非効率であると、動的なコンテンツが過度に前方へ挿入されたり、本来は固定であるべき状態情報のブロックがリクエスト間で並べ替えられたり書き換えられたりする可能性があります。その結果、キャッシュの前提となるプレフィックスの再利用が妨げられ、キャッシュの効果が十分に発揮されなくなります。

エージェント型 AI が業界標準となりつつある中で、モデルの性能は向上し、大規模なリクエストのコストも低下しています。主要モデルのコンテキストウィンドウは、この 2 年間で桁違いに拡大しており、128,000 トークンから、一部の価格帯では最大 200 万トークンに達しています。このことは、コンテキストウィンドウがもはや大多数のユーザーにとってボトルネックではなくなりつつあることを示しています。その結果、チームは会話履歴、取得したドキュメント、ツールの出力、ポリシーやガードレールなど、より多くの状態情報をプロンプトに組み込むようになっています。こうしたコンテキストは、エージェントの信頼性を高め、より複雑なユースケースに適合させるうえで不可欠な要素です。

当社の調査では、Datadog の顧客における LLM 呼び出しのトレーススパンを分析した結果、リクエストで使用されるトークン数の平均が、中央値の顧客では前年比で 2 倍以上に増加し、上位 10％ のヘビーユーザーでは 4 倍に増加していることが明らかになりました。

プロンプトの規模が拡大し、チームがエージェントパイプラインにおいてコンテキストを収集、生成、注入する新たな手法を見出すにつれて、レイテンシーやコストに関する課題は必然的に生じます。さらに、プロンプトに会話履歴、取得ドキュメント、ツールの出力、ガードレールなどが多く含まれるようになると、ノイズや冗長性が増大して重要な情報が埋もれやすくなり、特に重要な詳細が長大な入力の奥深くに埋もれる場合には、シグナルがノイズにかき消されやすくなります。

LLM エージェントにおいては、コンテキストの量ではなく質が新たな制約要因となっており、多くのチームはモデルが提供するコンテキスト容量を十分に活用できていません。その結果、課題の中心はトークン量の管理から、どの情報が実際にモデルの判断に影響を与えるのかを見極めることへと移行しています。検索品質の向上、要約、重複排除、明確な情報階層の設計といったコンテキスト設計に投資する組織は、長大なコンテキストを扱えるモデルの能力と、本番環境のエージェントが実際に安定して扱える範囲とのギャップを埋めることができます。そのためには、モデルを最適に活用できるよう、意思決定に最も関連性の高い情報を的確に選択し、圧縮し、構造化する仕組みを継続的に整備することが求められます。

当社は、Datadog LLM Observability の顧客トレースデータをもとに、LLM 呼び出しの失敗を分析しました。2026 年 2 月の分析では、すべての LLM 呼び出しスパンのうち 5％ がエラーを報告しており、そのうち 60％ がレート制限の超過によるものでした。さらに 2026 年 3 月には、全体の 2％ の LLM スパンがエラーを返し、その約 3 分の 1 がレート制限エラーで、合計で約 840 万件に達しています。こうした結果は、モデル提供側のキャパシティ上限が、エージェントの信頼性に影響を及ぼしていることを示唆しています。レート制限が実質的なキャパシティ上限となる動的な環境において信頼性を確保するためには、予算管理やバックプレッシャー制御といった運用面の工夫に加え、プロンプトの最適化も不可欠となります。

LLM アプリケーションにおいて、本番環境での主要な障害要因がキャパシティに起因する場合、チームはキャパシティ設計への取り組みを一層強化する必要があります。特に、組織全体で共有されるキャパシティ枠や、同時実行数の増加およびリトライのスパイクが重なると、リクエスト量の一時的な増加によって、割り当てられたキャパシティが予測不能な形で枯渇するケースが生じます。これは、例えば ReAct 手法を用いた可変ループを実行するシステムや、複数のエージェントが連携する構成において特に顕著です。さらに問題は、長時間稼働するエージェントループがプロバイダーのレート制限や組織固有の同時実行制限に達した場合に深刻化します。このような状況ではリトライが連鎖的に発生し、負荷がさらに増大することで、問題が持続的なシステム障害へと発展する可能性があります。

プロンプトおよびアプリケーションロジックは、ループの長さやツール呼び出しの過度な拡散によるスパイクを回避するよう設計する必要があります。同時に、プラットフォームチームは、キューイングシステム、バックオフ制御、代替キャパシティの確保といった仕組みを、LLM アプリケーションのコアランタイムに実装することが求められます。さらに、エージェントループに対して、呼び出し回数やトークン使用量の上限に達した時点で処理を終了させるための予算を設定することで、暴走ループを防ぎ、キャパシティ枯渇が下流サービスへ波及するリスクを抑制することが可能となります。

当社の調査では、エージェント型アプリケーションのリクエストのうち 59％ が単一のサービス呼び出しのみで構成されており、エンドツーエンドで 3 回以上のサービス呼び出しを伴うものは 18％ にとどまることが明らかになりました。この結果は、多くのエージェントが依然としてモノリシックな構成にとどまっていることを示唆しています。一方で、他の組織ではマルチエージェントアーキテクチャの検証や、既存環境とマイクロサービス的に連携するために、独立したサービス上でエージェントを運用する取り組みも進められています。

モノリシックな構成はスケーラビリティに課題があることを多くのチームが認識しており、変革を模索していますが、本番環境のエージェントは依然としてその多くがモノリシックなままです。専用のエージェントサービスやマルチエージェントアーキテクチャへの移行は、組織のプラットフォームに対して新たな要件をもたらします。これらのアプリケーションをデバッグおよびテストするためには、サービス境界をまたいでコンテキストやトレースを伝播させる必要があります。さらに、このような分散型プラットフォームを管理するためには、ツールも含めたサービスマップの整備が求められます。

今後の展望

今日の AI テクノロジー組織は、マルチモデル化、スキャフォールド化、コンテキストの高度化、そして分散化が進むシステムへと移行しており、エージェントの挙動、性能、コストを継続的に評価することが成功の鍵となっています。AI エージェントのアーキテクチャは、ますます複雑化しています。コンテキストウィンドウは拡大し、プロンプトは増加し、目に見えないドリフトの影響範囲も広がり続けています。

これにより、チームには新たに習得すべきスキルが求められます。それは、信頼性の高い評価ループの運用、意図的なコンテキスト設計、シグナルの高い入力の構造化、そしてモデルやコンテキストの無秩序な拡張が技術的負債へと発展する前に主体的に統制する能力です。また、こうした変化の中にあっても、運用における基本原則の重要性は変わりません。チームは引き続き、予算管理やバックプレッシャーの制御を徹底し、フォールバック手段を組み込み、適切なタスクを適切なモデルに振り分ける必要があります。次なる競争優位は、エージェントを安定して運用可能な本番システムへと成熟させ、継続的な評価と改善を通じて、状況の可視化、適切な統制、障害への耐性、ならびにコストを意識した運用を実現できる組織において確立されます。