マルチモデル化が加速
単一AIモデルに依存するのではなく、各ワークロードのレイテンシ、コスト、運用リスク、タスク要件に応じて最適なモデルを選び分ける。そうした「モデルポートフォリオ」の構築が標準になりつつあります。
LLM リクエストを一元管理するためのモジュール化されたルーティング機構 (ゲートウェイサービスや OpenRouter のようなマネージドゲートウェイ) を活用する必要性が高まっています。
OpenRouterとは、「OpenAI 互換 API で 100 種類以上のモデルに横断アクセスできるサービス」
技術的負債として膨らむ LLM モデル運用
新しいモデルを評価し旧モデルとの入れ替えが必要で、評価の負担が増加する。
エージェントフレームワークの普及とともに高まる、深いテレメトリの必要性
エージェントフレームワークを使い、エージェントがどのように実行されているかを把握し、非効率なインポートロジックを特定し、必要に応じて専用ワークフローに置き換えるための包括的なエージェントテレメトリが不可欠です。フレームワークの定型コードで主要なパターンを実装すると、フレームワークが内部でステップや分岐を増やし、実行時に何が起きているのかをエンジニアが把握しづらくなります。その結果、エージェントのスプロールが起こりやすくなります。フレームワークを活用した AI アプリケーション開発では、ツールのファンアウト、リトライ、分岐を 1 回のインポートで追加できます。これにより、コストやレイテンシが徐々に増加し、障害の再現も難しくなります。
エージェントフレームワーク
LangChain、Pydantic AI、LangGraph、Vercel AI SDK
大規模なシステムプロンプトを持つエージェント設計が進む一方で、プロンプトキャッシュは十分に活用されていない
入力トークンの 69% がシステムプロンプトに費やされている。複雑に構成されたエージェントシステムで繰り返し使用されるシステムプロンプトの最適化に向けられていることを示しています。トークン使用量を削減するには、可能な限りシステムプロンプトを短縮し、再利用可能な要素をモジュール化してキャッシュできるようにすることが重要です。
アプリケーションのキャッシュヒット率やキャッシュ済みトークンの割合が低い場合、その主な原因はプロンプトレイアウトにあることが少なくありません。プロンプト構成が非効率だと、動的コンテンツが過度に前方へ挿入されたり、本来は安定しているべき状態ブロックがリクエスト間で並べ替えられたり書き換えられたりします。
システムプロンプト
AI（大規模言語モデル）の振る舞いや役割、制約、回答のトーンをあらかじめ規定するための事前指示です。通常、ユーザーの会話画面には表示されず、AIの内部処理における「土台」として機能します。
コンテキストウィンドウの拡大により高まる、コンテキストエンジニアリングの可能性
会話履歴、取得したドキュメント、ツール出力、ポリシーガードレールなど、より多くの状態情報をプロンプトに組み込むようになっています。こうしたコンテキストは、エージェントの信頼性を高め、複雑なユースケースにより適合させるうえで不可欠です。
モデルを最大限活用するには、コンテキストエンジニアリングが大事
コンテキストエンジニアリング
AI（大規模言語モデル）がタスクを実行する際に参照する情報環境全体を設計・最適化する技術
エージェントの信頼性が直面するキャパシティの上限: LLM 呼び出しで最も多い失敗要因はレート制限エラー
すべての LLM 呼び出しスパンのうち 5％ がエラーを報告しており、そのうち 60％ がレート制限の超過によるものでした。
エージェントは依然としてモノリシックが主流
エージェント型アプリケーションのリクエストのうち 59% が単一のサービス呼び出しのみで構成されており、エンドツーエンドで 3 回以上のサービス呼び出しを伴うものは 18% にとどまりました。これは、多くのエージェントが依然としてモノリシックな構成にとどまっていることを示しています。一方で、マルチエージェントアーキテクチャを検証したり、既存環境とマイクロサービス形式で連携できるようにエージェントを専用サービス上にデプロイしたりする組織もあります。
大事な点
プロンプトを「文章」ではなく「資産」として管理する
プロンプトが単なる指示文ではなく、コスト・品質・セキュリティに直結する中核資産になっている、これを作成し最適化し管理していくことが大事