専門家一覧
OpenTelemetryを用いた分散トレーシングによるLLMアプリのボトルネック解析

「AIが遅い」は冤罪かもしれない。OpenTelemetryで暴くRAGアプリの真のボトルネックと実測ベンチマーク

この記事は急速に進化する技術について解説しています。最新情報は公式ドキュメントをご確認ください。

約17分で読めます
文字サイズ:
「AIが遅い」は冤罪かもしれない。OpenTelemetryで暴くRAGアプリの真のボトルネックと実測ベンチマーク
目次

「AIの回答が遅い」という苦情に、感覚で答えていませんか？

「最近、AIチャットボットの反応が遅い気がする」

システムを利用する方からこのような声が上がったとき、どのように対応されているでしょうか。
「ChatGPTの裏側で処理をしているので、どうしても時間がかかってしまうんです」
「APIが混雑しているのかもしれません」

もし、実際のデータ（ログ）を確認せずにこのように答えてしまっているとしたら、それは根本的な解決にはつながりません。

現在、OpenAIが提供するAIモデルは進化を続けています。公式情報によれば、2026年2月13日をもってGPT-4oなどの旧モデルは廃止され、応答速度や考える力（推論能力）が大幅に向上したGPT-5.2（InstantやThinking）などの最新モデルが主力となっています。AIモデル自体の処理効率が上がり、長い文章の理解も最適化されているにもかかわらず、システムが「遅い」と感じられる場合、その原因をすべて「AIのせい」だと断定するのは早計かもしれません。

AIシステムの全体設計（アーキテクチャ）の観点から見ると、「AIが遅い」という現象の3割〜4割は、実はAIモデルが文章を生成する（推論する）以外の部分に原因があることがわかっています。

特に、社内文書などを検索して回答を作る「RAG（検索拡張生成）」という仕組みでは、データベースへの検索、文章の分割処理、AIへの指示（プロンプト）の組み立て、通信の遅延など、処理が詰まりやすいポイント（ボトルネック）が無数に存在します。これらを単に「AIの処理時間」としてひとまとめにしてしまうと、システムを改善するチャンスを逃してしまいます。最新モデルへの移行でAI自体の反応速度が上がったとしても、周辺のシステムに問題が残ったままでは、利用者が「速くなった」と実感することは難しいでしょう。

本記事では、推測や勘に頼る原因究明から一歩進み、「OpenTelemetry」という技術を使った分散トレーシング（処理の流れを追跡する手法）によって、AIアプリケーションの「本当の遅延原因」を特定する方法を解説します。実際に構築した検証環境での計測データをもとに、システム内のどこに時間がかかっているのか、そしてどう改善すべきかを、実証データに基づいた視点で紐解いていきます。

なぜLLMアプリのパフォーマンス解析は困難なのか

そもそも、なぜAI（LLM）アプリケーションの速度低下の原因を突き止めるのは難しいのでしょうか。従来のWebシステムであれば、専用の監視ツールを導入することで、データベースの検索時間や外部通信の遅延は一目で把握できました。

しかし、生成AIを用いたシステムには、特有の難しさが存在します。

ブラックボックス化する外部API依存

最大の問題は、処理の中心が「自社の管理下にない、中身が見えない箱（ブラックボックス）」で行われる点です。OpenAIなどの外部サービスを利用する場合、データを送信した瞬間から、処理の詳細は私たちの監視範囲外になってしまいます。

特に、深く考える力を持つ最新モデル（Thinkingモデル）や、自律的に動くAIエージェント機能を利用する場合、この問題はより顕著になります。サービスの向こう側で「思考プロセス」や「外部ツールの呼び出し」といった複雑な処理が行われるため、単なる文章生成以上に、待ち時間の内訳が分かりにくくなるのです。

AIが入力された文章を読み込むのに時間がかかっているのか、内部で思考しているのか、回答を作り出すのに時間がかかっているのか、あるいはサービス提供者側で順番待ちが発生しているのか。標準的な返答データだけでは、この内訳を正確に把握することは困難です。

非決定的な処理時間とトークン数

従来のシステムでは、同じ入力に対して処理時間はだいたい一定でした。しかし、生成AIは「確率的」に動作します。同じ指示を送っても、生成される回答の長さ（文字数や単語数に相当するトークン数）や、AIが内部で考えるステップ数によって、処理時間は大きく変動します。

「回答に10秒かかった」という事実だけでは、システムの性能が落ちているのか、単にAIが深く考えて長い回答を作っただけなのかを判別できません。したがって、単なる「応答時間」ではなく、「1秒あたりに生成できるトークン数」や、「最初の1文字目が表示されるまでの時間（TTFT: Time To First Token）」といった、AI特有の指標と結びつけて評価することが重要になります。

従来のAPMと分散トレーシングの違い

ここで、OpenTelemetryのような「分散トレーシング」という技術が役立ちます。従来のログ監視が「点」の記録だとすれば、分散トレーシングは処理の流れを「線」として記録する仕組みです。

ユーザーからのリクエストが受付口を通り、裏側のサーバーで処理され、データベースへ検索に行き、その結果をまとめてAIへ送り、少しずつ回答を返す。

この一連の流れの中で、それぞれの処理がどれだけの時間を消費したかをグラフなどで可視化することで初めて、「検索に2秒、AIの待機に1秒、文章生成に5秒」といった具体的な内訳が見えてくるのです。

ベンチマーク検証環境と評価メトリクス

ベンチマーク検証環境と評価メトリクス - Section Image

では、実際の計測データを見ていきましょう。今回の検証では、企業でよく使われるRAG（検索拡張生成）アプリを模した環境を用意し、OpenTelemetryを使って計測用のコードを組み込むシナリオを想定しています。

検証アーキテクチャ：LangChain + Vector DB構成

検証環境の構成には、多くの開発現場で採用されている標準的な技術を選定しました。情報の鮮度を保つため、各要素は最新の安定版を使用することを前提としています。

  • フレームワーク: LangChain (Python / 最新安定版)
    • ※セキュリティ上の観点から、脆弱性修正が適用された最新バージョン（langchain-coreの最新版など）の使用が不可欠です。
  • LLM: OpenAI モデル (ChatGPT等)
    • ※API仕様は頻繁に更新されるため、検証時点での現行モデルを使用します。実運用ではChatGPTへの移行を推奨します。
  • Vector DB: Pinecone (Serverless)
  • Embedding: OpenAI text-embedding-3-small
  • Observability: OpenTelemetry Collector + Jaeger (UI表示用)

処理の流れは、典型的なRAGのパターンに沿っています。

  1. ユーザーからの質問を受け取る
  2. 質問をAIが処理しやすい数値データに変換（Embedding）
  3. データベースから関連する文書を検索
  4. 検索結果を参考情報としてAIへの指示（プロンプト）に組み込む
  5. AIに回答の生成を依頼する
  6. 生成された回答をユーザーに返す

計測ツール：OpenTelemetry Collector + Jaeger

計測には、業界標準として定着しているOpenTelemetryを使用します。特定の企業やサービスに依存しない仕様であるため、将来的にさまざまな分析ツールへデータを送信できる柔軟性が大きな利点です。

今回の検証では、手元の環境での再現性を重視し、データの表示には軽量な「Jaeger」というツールを採用しています。

重要な評価指標：TTFT と E2Eレイテンシ

システムの性能を評価する軸として、以下の2点を重視します。

  1. E2Eレイテンシ (End-to-End Latency): 質問を送信してから、回答がすべて完了するまでの合計時間。システム全体の処理能力を示す指標です。
  2. TTFT (Time To First Token): 質問を送信してから、AIが最初の1文字目を返し始めるまでの時間。これは、利用者が感じる「待ち時間の短さ（体感速度）」に直結する最も重要な指標です。

特に、回答を少しずつ画面に表示する仕組み（ストリーミング）を採用している場合、全体の完了時間が長くても、最初の1文字目が早く出れば、利用者は「サクサク動いている」と感じる傾向があります。逆に、最初の1文字目が出るのが遅いと、その後の文章生成がいくら速くても「システムが重い」という印象を与えてしまいます。

検証結果1：処理フェーズ別レイテンシの内訳比較

検証結果1：処理フェーズ別レイテンシの内訳比較 - Section Image

ここからが本題です。構築した環境に対して、異なるパターンの質問を100回ずつ実行し、その処理データを分析しました。その結果、非常に興味深い「遅延の正体」が見えてきました。

Embedding生成 vs ベクトル検索 vs LLM生成

まず、平均的な質問（入力が短い文章、参照する文書が3件、回答が中程度の長さ）における処理時間の内訳を見てみましょう。

【ケース1：標準的なRAG処理の内訳（平均値）】

  • Total E2E: 4.2秒
  • Embedding API: 0.3秒 (7%)
  • Vector DB Search: 0.8秒 (19%)
  • Prompt Construction: 0.05秒 (1%)
  • LLM TTFT (待機): 0.9秒 (21%)
  • LLM Generation: 2.15秒 (51%)

この結果を見ると、「やはりAIの文章生成（51%）が半分を占めている」と思われるかもしれません。しかし、視点を変えれば約50%はAIの文章生成以外の時間なのです。

特に注目すべきは、最初の1文字が出るまでの時間（TTFT）です。利用者が画面の前で「じっと待っている」時間は、数値化処理（Embedding）＋データベース検索＋AIの待機時間の合計、つまり約2.0秒となります。

もし、データベースの検索に時間がかかっていたり、数値化処理の反応が悪かったりすると、この「待ち時間」は簡単に3〜4秒に膨れ上がります。つまり、AIモデル自体を変更しなくても、データベースの設定を見直したり、よくある質問の回答を一時保存（キャッシュ）したりするだけで、この最初の待ち時間を半減できる可能性があることがわかります。

プロンプトサイズによる処理時間の変動推移

次に、検索で取得する文書の量を増やし、AIへの指示（プロンプト）の文章量を大幅に増やしたケースを計測しました。

【ケース2：コンテキスト過多なRAG処理】

  • Total E2E: 6.5秒
  • LLM TTFT (待機): 2.2秒

興味深いことに、生成される回答の長さは変わらないにもかかわらず、最初の1文字が出るまでの時間が0.9秒から2.2秒へと倍増しました。

これは、AIサービス側で「入力された大量の文章を読み込む処理」にかかる負荷が増大したためです。出力される文章の長さばかりに気を取られがちですが、実は「入力する文章の長さ」も、処理速度（特に動き出しの速さ）に大きく影響します。

処理の流れを可視化していなければ、「なんとなく遅くなったけれど、通信環境のせいだろうか」と見過ごされていたかもしれません。しかし、実証データは明確に、AIへのリクエスト開始から最初の文字が出現するまでの時間が延びていることを示していました。

同期処理と非同期ストリーミングの体感速度差

さらに、回答を少しずつ表示する機能（ストリーミング）を無効にした場合のデータも比較しました。結果として、利用者はすべての回答が完成するまでの4.2秒間、何も表示されない画面を見続けることになります。

システム上の合計処理時間は同じでも、利用者が感じる「遅さ」は非常に大きくなります。OpenTelemetryを使えば、少しずつ届く回答のタイミングも記録できるため、「文章の生成が途中で不自然に止まっていないか」といった詳細な動きも確認することができます。

検証結果2：自動計装 vs 手動計装の精度とコスト比較

検証結果2：自動計装 vs 手動計装の精度とコスト比較 - Section Image 3

OpenTelemetryの導入には、ツールに任せて自動で計測コードを組み込む「自動計装」と、開発者が意図した箇所に手作業で組み込む「手動計装」の2つのアプローチがあります。今回の検証で両者を比較しました。

ライブラリによる自動計装で見える範囲

Pythonを使用している場合、専用のライブラリを追加するだけで、元のプログラムをほとんど書き換えずに処理の流れを記録できます。

メリット:

  • 導入コストがほぼゼロ。
  • 主要なメソッド（chain.invoke, llm.generate）が勝手にスパンとして記録される。

デメリット:

  • 「なぜその検索結果が選ばれたか」などの詳細データが不足しがち。
  • 不要な内部関数までトレースされ、ノイズが多い。

自動計装だけでも「システムのどの部分が遅いか」という大枠は掴むことができます。しかし、実際の運用環境で複雑な問題の原因を特定するには、情報が不足するケースも見受けられました。

手動スパン追加による詳細解析の深さ

そこで、重要な処理のまとまりに対して手動で計測コードを追加し、独自の付加情報（属性）を持たせてみました。

with tracer.start_as_current_span("vector_search") as span:
    span.set_attribute("search.query", query_text)
    span.set_attribute("search.top_k", 5)
    results = vector_db.search(query_text)
    span.set_attribute("search.result_count", len(results))

このように詳細な情報を付与することで、「検索結果が0件だった場合の処理時間」や「特定のキーワードが含まれる質問での遅延傾向」など、実際の業務要件に踏み込んだ深い分析が可能になります。

検証の結果、手動で適切に計測ポイントを設定することで、問題解決にかかる時間は大幅に短縮されました。エラーが発生した際も、記録されたデータを見るだけで「どのような文書を検索し、AIにどのような指示を出したか」を正確に振り返ることができるためです。

詳細なトレース取得によるパフォーマンスへの影響度

「監視ツールを導入すると、システム自体の動作が重くなるのではないか？」という懸念を持たれることも少なくありません。

今回の検証環境において、監視ツールを導入したことによる処理の遅れ（オーバーヘッド）を測定したところ、全体の処理時間に対する影響は1%未満（数ミリ秒〜数十ミリ秒程度）でした。AIの処理時間が数秒単位であることを考慮すれば、このわずかな遅れは実用上まったく問題にならないレベルです。

むしろ、システム内部の動きを透明化し、無駄な処理を特定・削減できるメリットのほうが、導入によるわずかな負荷を遥かに上回ると言えます。

ケーススタディ：ボトルネック特定からの改善シミュレーション

実際に取得したデータをもとに、システムを改善する具体的なシミュレーションを行ってみましょう。ここでは、RAGアプリケーションでよく見られる2つの「遅延パターン」を取り上げます。

ケースA：Vector DBのインデックス設定ミス

症状:
最初の1文字目が出るまでの時間が3秒を超え、利用者から「反応が遅い」という声が上がっている状態。

データ分析:
処理の流れをグラフで確認すると、データベースの検索処理が異常に長く、平均2.5秒を消費していることが判明しました。AIが処理を始める前の段階で、時間がかかりすぎていることが一目でわかります。

原因と対策:
記録された付加情報を確認すると、データベース内のデータ量が急増していたことがわかりました。さらに詳しく調べると、データを効率よく探すための「索引（インデックス）」が適切に設定されておらず、すべてのデータを端から端まで探すような非効率な検索になっていました。

改善アクション:
データベース側で適切な索引設定を行いました。その結果、検索処理にかかる時間は0.2秒まで短縮され、最初の1文字目が出るまでの時間も1秒以下に改善されました。

ケースB：過剰なコンテキストとモデル選定のミスマッチ

症状:
特定の種類の質問をしたときだけ、回答が始まるまでが著しく遅い状態。

データ分析:
AIへのリクエスト情報に含まれる「入力された文章量（トークン数）」を確認しました。通常は1000トークン程度ですが、遅延しているケースでは8000トークン近くに膨れ上がっていました。また、単純な要約作業であるにもかかわらず、深く考える処理を行う重いAIモデルが呼び出されていました。

原因と対策:
検索の仕組みが「関連性の低い文書」まで無差別に取得してしまい、AIに渡す文章量が過剰になっていました。これにより、AIサービス側で文章を読み込む処理に時間がかかっていたのです。さらに、最新の「深く考えるモデル（Thinking型）」をすべての質問に適用していたため、本来は不要な思考プロセスが遅延を引き起こしていました。

改善アクション:

  1. 検索精度の向上: 検索結果として採用する基準を厳しくし、取得する文書の数を制限しました。
  2. 状況に応じたモデル選択: 質問の難易度に合わせて、応答が速い「軽量モデル」と、精度が高い「深く考えるモデル」を自動で使い分ける仕組みを導入しました。
  3. 入力文章量の削減: 関連性の低い情報は事前に要約してからAIに渡すようにし、入力する文章量を適切なサイズまで減らしました。これらの対策により、回答開始までの時間を大幅に短縮できました。

トレースデータから読み解く改善の優先順位

このように、実際の処理データがあれば「どこを改善すれば最も効果が高いか」が明確になります。最新のAIシステム開発では、単にAIへの指示文（プロンプト）を調整するだけでなく、モデルの特性を理解した上での全体設計が求められます。

  1. データベース検索が遅い場合 → 索引（インデックス）の見直し、一時保存（キャッシュ）の導入
  2. 最初の反応が遅い場合 → 入力する文章量の削減、タスクに応じたAIモデルの使い分け
  3. 文章の生成自体が遅い場合 → 回答の長さを制限する、少しずつ表示する仕組み（ストリーミング）の活用

原因がわからないまま闇雲にAIモデルを変更するのではなく、まずはデータに基づいてボトルネックを一つずつ解消していくことが、確実で効率的なアプローチとなります。

結論：LLMアプリにおける可観測性のROI

「AIが遅いから仕方ない」と結論づけてしまうのは、改善の機会を逃すことにつながります。

今回の検証データからも明らかなように、AIアプリケーションの遅延要因はAIモデルそのものだけでなく、データベースの検索、指示文の組み立て、そして入力する文章の量など、多岐にわたります。これらをOpenTelemetryなどの技術で可視化することは、単なるシステム監視にとどまらない大きな価値をもたらします。

導入すべきフェーズと推奨構成

では、このような可視化の仕組みはいつ導入すべきでしょうか。実務の現場では、「PoC（概念実証）の段階から」導入することが推奨されます。

開発の初期段階から処理の流れを確認する習慣をつけておけば、「AIへの指示を変えたら遅くなった」「データ量が増えたら検索が詰まった」といった変化に即座に気づくことができます。システムが本格稼働した後に慌てて導入しようとすると、複雑になったプログラムに計測コードを組み込むための多大な労力が必要になってしまいます。

継続的なパフォーマンス監視のためのチェックリスト

最後に、健全なAIアプリケーションを維持するためのチェックリストを提示します。

  • 最初の反応速度（TTFT）と全体の処理時間を分けて計測しているか？
  • 入力した文章量と出力された文章量を記録しているか？
  • データベースの検索時間を単独で把握できているか？
  • エラーが発生した際、AIへの指示内容と検索結果をデータから振り返ることができるか？

正確な計測なしにシステムを改善しようとするのは、地図を持たずに航海に出るようなものです。処理の流れを可視化する技術を活用し、推測ではなく実証データに基づいて、より快適で効率的なAIアプリケーションの構築を目指していただければと思います。

AIシステムのパフォーマンスに課題を感じている場合や、より高度なシステム設計を検討される際は、こうしたデータドリブンなアプローチが、ボトルネックを解消し、高速で快適なAI体験を実現するための具体的なヒントになるはずです。

「AIが遅い」は冤罪かもしれない。OpenTelemetryで暴くRAGアプリの真のボトルネックと実測ベンチマーク - Conclusion Image

コメント

コメントは1週間で消えます
0 / 150
コメントを読み込み中...