powered by TechFeed
表示モード
Deep Dive

AIの本番障害、原因の約60%はハルシネーションではなくレートリミット — プロンプト改善より先に取り組むべき信頼性問題

7月28日、Manifest.buildが「The Biggest Reliability Problem in AI Isn't Hallucinations Anymore」と題した記事を公開した。本番環境におけるAIシステムの最大の信頼性問題がハルシネーションではなくレートリミットによる障害であるという主張は、多くのチームの優先順位を根本から問い直すものだ。なお、Manifest.buildはAIシステムの信頼性向上を手がけるソリューション提供者であり、本記事は自社の問題意識と製品方針に基づく主張を含む点は読者として念頭に置きたい。

7月28日、Manifest.buildが「The Biggest Reliability Problem in AI Isn't Hallucinations Anymore」と題した記事を公開した。本番環境におけるAIシステムの最大の信頼性問題がハルシネーションではなくレートリミットによる障害であるという主張は、多くのチームの優先順位を根本から問い直すものだ。なお、Manifest.buildはAIシステムの信頼性向上を手がけるソリューション提供者であり、本記事は自社の問題意識と製品方針に基づく主張を含む点は読者として念頭に置きたい。


本番のAIが壊れる本当の原因

AIプロダクトが実験フェーズを脱して本番稼働に入ると、チームが直面する問題の性質が根本から変わる。

Datadogの2026年版「State of AI Engineering」レポートによれば、本番環境でのLLMリクエストのうち約5%が失敗している。そしてその失敗の約60%はレートリミット(HTTP 429)やキャパシティ制約に起因する。モデルの品質とは無関係だ。

数字に直すとわかりやすい。1日100万件のLLMリクエストを処理するSaaSであれば、5%の失敗率は毎日5万件のリクエストが完了しないことを意味する。その大半は「プロンプトが悪かった」のではなく、429エラーで切り捨てられている。

ユーザーには内部事情は見えない。レートリミットなのか、タイムアウトなのか、プロバイダー障害なのか、エンドポイントの過負荷なのか——ユーザーが知るのはひとつだけだ。「製品が動かなかった」という事実だけである。


ハルシネーション対策より先に取り組むべき問題

多くのチームは今もプロンプトの改善やRAG(Retrieval-Augmented Generation、外部知識をリアルタイムで検索・参照しながら回答を生成する手法)の最適化、ベンチマークスコアの向上に注力している。RAGはモデルの知識の限界やハルシネーションを補う有力なアプローチとして広く普及しているが、記事が指摘するのは、ユーザーフラストレーションの最大の原因がそうした精度レイヤーとは別の場所にあるという逆説だ。

アプリケーションとモデルの間に存在するインフラ層——リトライ処理、レートリミット、プロバイダーの可用性、レイテンシスパイク、タイムアウト、ストリーミングの中断——これらは技術メディアの見出しを飾ることはないが、本番環境では大きな痛みを生む。

記事はこの状況を端的に表現している。

「少し精度が落ちた回答」は多くの場合許容される。「回答がまったく返ってこない」は、たいてい許容されない。

信頼性は複利で効く。プロンプトを磨いても、インフラが不安定ではユーザー体験は改善しない。


Web工学が歩んだ道をAIが辿る

この状況には前例がある。20年前、Web工学は「Webサイトを作る」フェーズから「分散システムを運用する」フェーズへと移行した。データベースが落ち、キャッシュが不整合を起こし、ネットワークが分断し、サードパーティAPIが応答しなくなる——開発者はそれを学んだ。

その過程でオブザーバビリティ、SRE(Site Reliability Engineering)、インシデント管理、カオスエンジニアリングといった専門領域が生まれ、信頼性そのものがプロダクトの機能として位置づけられるようになった。

記事はこの歴史的経緯をAIエンジニアリングの現在地に重ねる。Web工学が「サービスが落ちることを前提にシステムを設計する」という発想へ転換したように、AIシステムもまた「モデルが応答しないことを前提にしたインフラ設計」が必要な段階に来ているという主張だ。

AI工学は今、同じ転換期を迎えている。違いは、管理対象がデータベースやマイクロサービスではなく、自分たちがコントロールできない外部モデルであり、そのモデルが継続的に変化し続けるという点だ。


次の競争優位はどこにあるか

フロンティアモデルはどのチームも同じように使える。プロンプト技術は素早く広まり、ベンチマークは数ヶ月で陳腐化する。

一方、信頼性はコピーが難しい。プロバイダー障害時のフォールバック、自己修復するリクエスト処理、エラーが表面化する前に問題を吸収するシステム設計——こうしたインフラ層の積み上げは、プロンプトを真似されるよりはるかに再現しづらい。

記事の締めくくりには、Manifestが取り組む方向性が示されている。「より賢いモデルを作るのではなく、壊れないシステムを作る」——プロバイダー間のフォールバックと、不良リクエストがユーザーに届く前に自己修復する仕組みだ。


「AIエンジニアリング」という言葉はやがて分化していくかもしれない。プロトタイプを作るためのプロンプトエンジニアリングと、本番を生き残るための信頼性エンジニアリングへ。どちらのフェーズにいるかによって、優先すべき課題は大きく異なる。

詳細はThe Biggest Reliability Problem in AI Isn't Hallucinations Anymoreを参照していただきたい。