SLAとは
SLAとは、AIサービス提供者と利用者の間で結ばれる品質保証の約束でありシステムの稼働率
読み: エスエルエー
AIサービス提供者と利用者の間で結ばれる品質保証の約束でありシステムの稼働率や障害時の対応基準を明確に定める契約概念である。
かんたんに言うと
賃貸マンションの設備保証に近い。給湯器が壊れて何日も風呂に入れなければ家賃が減額されるように、クラウドAIが規定時間以上止まったら利用料が一部返金される仕組みである。
稼働率99.9%の裏にある月間43分のダウンタイムとSLAの現実
クラウドベンダーが提示するSLAの数字を鵜呑みにしていないだろうか。
可用性99.9%という数字は一見頼もしく見える。だが月間に換算すれば約43分のダウンタイムが許容されている計算になる。
物流の配送ルート計算APIが朝のピーク時に40分止まったらどうなるか。トラックの出発が遅れ、サプライチェーン全体に波及する。
SLAは決して絶対落ちない魔法の盾ではない。落ちた時のペナルティを定めただけの事後処理のルールである。
現場のエンジニアとしては、この43分をどうやって乗り切るかの設計こそが問われる。フォールバック先のモデルを用意するのか、それとも一時的に手動運用に切り替えるのか。ここは常に判断が分かれる。
稼働率の測定とサービスクレジットの罠
SLAが未達だった場合、ベンダーはサービスクレジットという形で次月の利用料から一部を割り引く。
しかし、この返金手続きは自動で行われるわけではない。
APIリクエストのエラー率を自社で監視し、規定の期間内にベンダーへ申請する必要がある。ログを突き合わせてダウンタイムを証明する手間は想像以上に重い。
経理部門からすれば、数百円から数千円のクレジットを取り戻すためにエンジニアの工数を何時間も割くのは割に合わないだろう。
結局のところ、SLA違反の申請を諦める企業は多い。実務においてサービスクレジットは、金銭的な補填というよりベンダー側の品質維持に対するプレッシャーとしての意味合いが強い。
主要クラウドのSLA適用範囲と実態
実際のサービスを見てみよう。Microsoft Azure OpenAI ServiceやGoogle Cloud Vertex AI、そしてAmazon Bedrockは、いずれもエンタープライズ向けのSLAを明記している。
だが細部を読むと適用条件は厳しい。
例えば特定のリージョンや特定のモデルバージョンに限定されていたり、プレビュー版の機能はSLAの対象外だったりする。
法務部門が契約書レビューシステムを構築する際、最新のClaude 3.5 Sonnetを使いたいと要望を出してくることはよくある。しかしそのモデルが利用予定のクラウド環境でSLA対象として一般提供されているかは別問題である。
最新モデルの性能をとるか、枯れたモデルでSLAの保証をとるか。このトレードオフは非常に悩ましい。
インフラの保証と生成品質のベストエフォート
SLAについて最も誤解されやすいのが、保証されるのはあくまでインフラの応答性だという点である。
AIがどれだけ的確な回答を返すかという生成品質は一切保証されない。
APIが正常なステータスコードを返しさえすれば、中身が全くのデタラメであってもSLA上は正常稼働とみなされる。
ハルシネーションを起こさないことや、期待通りのJSONフォーマットで出力されることは、ベンダーからすればベストエフォートの領域に過ぎない。
インフラが落ちないことと、業務が回ることは同義ではない。出力結果の妥当性をどう担保するかは、結局のところ我々利用側のアプリケーション設計に委ねられている。
業務影響度から逆算する選定基準
AIをどの業務に組み込むかで、求めるべきSLAの水準は変わる。
社内向けのFAQ自動化ボットなら、半日止まっても誰も死なない。だが製造業の生産ラインにおける外観検査AIが止まれば、工場の稼働そのものが停止する。
事業継続計画の観点から、システムが復旧するまでの目標時間であるRTOと、どの時点までのデータを復旧させるかのRPOを定義しなければならない。
SLAの数字だけを見てベンダーを選ぶのは危険である。自社の業務がどれだけのダウンタイムを許容できるのか。
その限界点を知らずして、システムを本番環境にデプロイするべきではない。
当社の見解
当社はAIの安全運用のために多層防御を設計・実装している（2026年4月現在）。この仕組みにより、AIが誤って機密情報を外部に送信するリスクを構造的に排除した。加えて、万が一インシデントが発生しても即座に復旧できるバックアップ体制を構築している。実際にAIが暴走して本番環境を停止させた経験があり、その際も緊急復旧スクリプトとデプロイ前の自動ロールバック機構で数分以内に復旧した。2026年4月にはAIによるファイルの無断変更を追跡するため、5つのリポジトリにgit自動追跡を導入し、全変更をコミット単位で記録・復元可能にした。安全性は「失敗を防ぐ」だけでなく「失敗しても戻せる」「誰が変えたか追跡できる」設計が本質だ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。