「ベンダーに何%の精度を約束してもらえばいいのか分からないまま契約した」「本番で誤答が続発してから、そもそも合格基準を決めていなかったことに気づいた」——生成AI・AIエージェントの導入で起きがちなトラブルです。結論から言うと、AIエージェントのSLA（サービスレベル）は、可用性（止まらず動くか）・精度（どこまで正しい出力を返すか）・エスカレーション（判断できないときにどう人へ引き継ぐか）の3層で定義し、本番導入前にベンダーと社内の双方で合意しておく必要があります。従来のSaaSの稼働率保証だけでは、生成AI特有の「出力の確率性」を捉えられません。
この記事では、AIエージェントのSLAとは何か、何を定義すべきか、とくに難しい精度のSLAをどう握るか、社内合意とベンダー契約への落とし込み方、導入後の運用までを解説します（品質の測り方は生成AIの評価（Evals）、内部の動きの可視化はAIエージェントのオブザーバビリティ、人への引き継ぎ設計はヒューマン・ハンドオフも参照）。
AIエージェントのSLA（サービスレベル）とは？——なぜ「稼働率だけ」では済まないのか
AIエージェントのSLAとは、可用性・精度・エスカレーションについて、本番導入前にベンダーと社内で合意しておく基準のことです。 まず、従来のSaaSのSLAと何が違うのかを押さえます。
従来のSaaSのSLA（サービスレベルアグリーメント）は、多くの場合「稼働率99.9%」のように、システムが動いているか止まっているかという、比較的二値に近い指標で表現されてきました。障害が起きれば計測でき、原因も切り分けやすいためです。
一方、生成AI・AIエージェントは事情が異なります。システムとしては正常に稼働していても、出力の内容そのものが誤っている、業務に使えないレベルの回答をしている、という失敗のしかたをします。しかも同じ入力に対しても、常に同じ出力が返るとは限りません。「動いているか」を保証しても、「正しく動いているか」は別の話になる——ここが、AIエージェントのSLAを従来のSaaSと同じようには設計できない理由です。
SLAには何を定義すべきか？——可用性・精度・エスカレーションの3層
AIエージェントのSLAは、可用性・精度・エスカレーションという性質の異なる3層で組み立てます。 どれか一つでは、本番運用で起こりうる失敗をカバーできません。
AIエージェントのSLAは3層で組み立てる。可用性だけでは、精度の低下や誤判断を捉えられない。
- 可用性：システムとしての稼働率、応答時間、障害発生時の復旧目標時間。従来のSaaSのSLAに近い、比較的定義しやすい層
- 精度：出力がどこまで正しいか。何を「合格」とするかを、業務ごとの基準で定義する必要がある、生成AI特有の難所
- エスカレーション：AIが自信を持てない・判断の影響が大きいケースで、どの条件で・どのくらいの時間で人へ引き継ぐか
3層のうち、可用性は既存のSaaS契約の延長で握りやすい一方、精度とエスカレーションは生成AI・AIエージェントならではの合意事項です。次の章では、とくに難しい精度のSLAを掘り下げます。
精度のSLAはどう握る？——確率的な出力を「合格基準」に変える難所
精度のSLAで重要なのは、100%を約束させる（約束する）ことではなく、「何を合格とするか」と「基準を下回ったときにどうするか」を先に決めておくことです。 ここがAIエージェントのSLA交渉の核心になります。
生成AIの出力は確率的なため、「絶対に間違えない」ことをSLAにするのは現実的ではありません。代わりに実務で使われるのは、次のような組み立てです。
- 評価セットを用意する：想定される質問・依頼と、期待する回答をあらかじめ定義しておく（詳しいやり方は生成AIの評価（Evals）を参照）
- 合格基準（許容誤り率）を数値化する：たとえば「評価セットに対する正答率○%以上」「特定カテゴリの誤りは0件」など、業務のリスクに応じて基準を分ける
- 基準を下回ったときの対応を決める：原因調査、追加改善の実施期限、対応が難しい場合の条件見直し（利用範囲の縮小、料金や契約条件の見直し）など
たとえば、社内問い合わせ対応のAIエージェントを例に考えます（数値はすべて説明用の仮の値です）。「一般的な問い合わせは評価セットで正答率90%以上」「就業規則など影響の大きい分野は誤りゼロを目標に、誤答が出た場合は24時間以内に原因調査を開始する」というように、業務のリスクに応じて基準の重さを変えるのが実務的な握り方です。すべての業務を一律の高い基準で縛ろうとすると、ベンダー側もリスクを取れず、現実的な契約になりません。
社内合意とベンダー契約にどう落とし込む？——情シス・事業部門・ベンダーの握り方
SLAは技術部門だけで決めず、情シス・事業部門・ベンダーの三者で合意して初めて機能します。 それぞれの立場で見ている基準が違うためです。
| 立場 | 気にする基準 | 握っておくべきこと |
|---|---|---|
| 事業部門（利用側） | 「業務で使い物になるか」 | 誤答時の業務影響、許容できる誤り率の感覚 |
| 情シス（推進側） | 「安全に・止めずに運用できるか」 | 可用性の目標値、障害時の連絡・復旧フロー |
| ベンダー（提供側） | 「約束できる範囲はどこまでか」 | 評価セットの内容、精度基準の測り方、未達時の対応範囲 |
ここでよく起きるトラブルは、精度の合格基準を決めないままベンダー選定を進め、導入後に「思っていた精度と違う」という食い違いが表面化することです（生成AI導入支援会社の選び方はコンサル・SIer・FDEの違い、稟議での説明の仕方は生成AI導入の社内稟議も参照）。SLAは契約前に、少なくとも「評価セットの中身」「合格基準の数値」「未達時にどうするか」の3点をベンダーと事業部門の双方で確認しておくことが、後のトラブルを避ける最低ラインになります。
SLAは導入後どう運用する？——一度決めて終わりにしない見直しのサイクル
SLAは契約時に一度決めて終わりではなく、実際の運用データをもとに定期的に見直すものです。 導入前に完璧な基準を決め切ることは、そもそも難しいからです。
本番運用を始めると、監視や評価を通じて「想定していなかった誤りのパターン」や「エスカレーションが想定より多い・少ない業務」が見えてきます（監視・評価の回し方は本番運用の監視・評価を参照）。SLAは、この運用実績にもとづいて、基準そのものを見直すサイクルに組み込むべきです。たとえば、四半期ごとに評価セットと合格基準を棚卸しし、業務の変化や新しい失敗パターンを反映する、といった運用が現実的です。
決めた基準を一度も見直さないと、業務が変わってもSLAだけが古いままになり、「基準は達成しているのに現場では使われていない」という形骸化が起こります。SLAは契約書に書いて終わりの静的な文書ではなく、運用と一緒に育てる基準だと捉えることが重要です。
DeploAIのFDEはSLA設計・合意形成をどう支援するか
DeploAI の FDE（Forward Deployed Engineer／フォワードデプロイドエンジニア）は、可用性・精度・エスカレーションの基準を業務の実態に合わせて設計し、情シス・事業部門・ベンダー間の合意形成から契約・社内基準への落とし込みまでを現場で伴走します。
SLAの難しさは、決めること自体ではなく、「その基準が業務にとって現実的か」を、業務を理解した上で判断できるかどうかにあります。FDE は、評価セットの設計（生成AIの評価）や監視の仕組み（本番運用の監視・評価）と組み合わせて、合意した基準を運用の中で実際に測り続けられる状態まで作り込みます。契約時点の握りだけで終わらせず、見直しのサイクルまで含めて社内に残すのが特徴です。
まとめ
- AIエージェントのSLAは、可用性・精度・エスカレーションの3層で定義する。可用性だけでは生成AI特有の失敗を捉えられない
- 精度のSLAは、100%の約束ではなく「合格基準」と「未達時の対応」を先に決めることが核心
- SLAは情シス・事業部門・ベンダーの三者で合意して初めて機能する。契約前に評価セット・合格基準・未達時の対応を確認する
- SLAは契約時に決めて終わりではなく、運用実績にもとづいて見直すサイクルに組み込む
- DeploAI の FDE が、基準の設計から合意形成、運用しながらの見直しまでを伴走する
AIエージェントの本番導入でSLAをどう握るべきか迷う方は、生成AIの評価（Evals）で精度の測り方を、本番運用の監視・評価で運用の回し方を確認してみてください。導入前のご相談はお問い合わせから承っています。
関連記事：生成AIの評価（Evals）｜AIエージェントのオブザーバビリティ｜生成AI・AIエージェントの本番運用｜ヒューマン・ハンドオフ（エスカレーション）｜生成AI導入支援の選び方
