要約

  • Lambdaが公表する99.99%は社内ストレステストの報告値であり、顧客側の測定期間、契約上の除外、請求手続き、救済のいずれも付いていない。
  • 契約で時間に紐づく唯一の数値は1-Click Clustersのサポート初回応答（Severity 1で1時間）で、これは復旧期限ではなく、稼働率の約束もダウン時間の算式も補償表も存在しない。

まず数字の出どころを押さえる。LambdaはMLPerf Inference v5.0に関する自社記事のなかで、広範なストレステスト中にインフラが99.99%の稼働率を維持したと述べている。記事は2025年4月2日付で公開され、2026年10月22日に更新されている（LambdaのMLPerf記事）。この百分率には、顧客側の測定期間も、契約上の除外項目も、請求の手続きも、外れたときの救済も添えられていない。テストの記録そのものを独立に検証したわけでもない。つまり99.99%は、設備がどれだけ持ちこたえたかという報告であって、買い手が何かを請求できる権利の根拠ではない。

次に、時計に結びついた唯一の数値を見る。1-Click Clustersのサポートページは、初回応答をSeverity 1で1時間以内、Severity 2で2時間以内、Severity 3で6時間以内、サービスリクエストで24時間以内と定めている（1-Click Clustersのサポートページ）。Severity 1には、サービスが停止している、アクセスできない、有用な作業を実行できない状態が含まれる。だが1時間というのは初回応答までの時間であって、復旧までの期限ではない。同じページには稼働率の百分率も、ダウン時間の計算方法も、サービスクレジットの表も、応答が遅れた場合の補償式も載っていない。ページは24時間365日のチケット窓口を説明し、そこに「契約に定めた応答時間」という位置づけを与えている。約束されているのは、機械が戻ることではなく、人が返事をすることだ。

その返事の外側にあるのが契約条件である。LambdaのCloud利用規約では、サービスは現状有姿（as-is、提供側が品質を保証しない条件）で提供され、明示された条項と適用法令の範囲にとどまる（Lambda Cloud利用規約）。クレジットは提供側の裁量で付与され、取り消し可能で、現金ではなく、原則として12か月で失効する。責任は原則として直前12か月に支払った額と支払うべき額を上限とし、間接損害は除外される。重大な契約違反による解除には通知と30日の治癒期間、治癒にそれ以上かかる場合は10日以内の治癒計画の提示が要る。そして注文書（Order）がサービス条件と料金を定め、矛盾する条項に優先し、この契約が以前の販促資料に優先する。買い手が実際に突きつけられる文書は、公開ページではなく、この注文書とそこに取り込まれた別紙だ。

ここで一段の留保が要る。Managed Slurmのドキュメントは、継続的なヘルスチェック、24時間365日の監視、不健全なノードの隔離、自動修復、人手による修理へのエスカレーションを説明し、修理や交換は顧客のサービス品質合意（SLA、サービス水準を定めた合意）の条件に従うと書いている（Managed Slurmの自動修復）。つまりLambdaはSLAの存在を前提にしている。ただしそのページはSLAの水準を再掲もリンクもしていない。だから「LambdaはSLAを提供していない」と書くのは誤りであり、本記事はそう書かない。言えるのは、公開文書の側からは、その中身も、閾値も、修理期限も、クレジットの算式も読み取れない、ということだ。

設備の数値も同じ層にある。1-Click Clustersの紹介ページは、400 Gb/sのQuantum-2 InfiniBand、最大3200 Gb/sのピアツーピアGPUDirect RDMA、各ノード2基の100 Gb/s Ethernet NICを記載する（1-Click Clustersの紹介）。同時に、Direct Internet Accessはデータセンターのエッジにおける共有の上流容量で提供され、テナントごとの専用ではないと明記している。だからNICやInfiniBandの数字を、そのまま専用のインターネット帯域として読むのは誤りだ。これらは構成の説明であって、稼働率や最低スループットの約束にクレジットの救済を添えたものではない。

規模の記述には、出版者自身が調整していない食い違いもある。紹介ページは16〜512 GPUと書き、価格ページは16〜2,000+ GPUとうたう（Lambdaの価格ページ）。どちらが正しいかを本記事は決めない。決められないという事実のほうが、調達の判断には効く。

オンデマンドの構成表は2025年12月時点と明記され、8基のB200を載せる構成ではGPUあたり180 GBのVRAM、208 vCPU、2900 GiBのRAM、22 TiBのルートボリュームを挙げる（オンデマンドの概要）。同じページは、すべてのインスタンスタイプがすべてのリージョンで利用できるわけではないとも書いている。APIはインスタンスタイプごとに、その型を提供するリージョンを示すregions_with_capacity_availableフィールドを返す（Cloud APIのドキュメント）。レート制限は概ね毎秒1リクエスト、インスタンス起動は12秒に1回または毎分5回で、これは要求の上限であって応答時間や可用性の保証ではない。同じドキュメントは、上流ネットワークの障害、サービスの利用不能、リソースの枯渇を、提供側のエラーとして認めている。

課金の側にも、時間の扱いだけが精密に書かれている。オンデマンドは時間単位の価格で、1分刻みで課金され、起動時のヘルスチェックの後に始まり、終了時に止まる。動いていて使っていないインスタンスも課金対象だ（請求の概要）。返金は将来のLambda Cloud利用に対するサービスクレジットで、現金化できず、12か月で失効する。ダウン時間の適格基準も、算式も、請求期限も、クレジット率の表もない。

価格ページには日付の罠もある。表示されているインスタンス価格は2026年11月16日00:00 UTCに発効し、それは本記事の調査日である2026年11月12日より後だ。ページ自身が、それまではアカウントで価格を確認するよう案内している。セルフサービスのインスタンス利用は先着順と説明されている。

運用の現況も確認しておく。取得時点のステータスページは全コンポーネントの正常稼働を報告し、Cloud API、ネットワーク、仮想マシン、ストレージ、電源を並べていた（Lambda GPU Cloudのステータス）。そこに稼働率の目標も、SLAの算定方法も、除外規定も、補償の予定も公表されていない。正常であることの表示は、正常であり続ける義務の代わりにはならない。

最後に証拠の境界を一度だけ置く。Lambdaの独立したSLA文書は取得できていない。lambda.ai/legal/service-level-agreementはリダイレクトの後に失敗し、報告された遷移先のlambda.com側も失敗した。これは出版者が404を返した確認ではなく、到達できなかったという取得の失敗である。顧客別の注文書とSLA別紙も入手できていない。したがって個々の買い手が何を合意したかは、本記事の範囲の外にある。

買い手が公的文書の上で指させるのは、返信の速さだ。機械の稼働は、現状有姿の条項と、裁量で取り消せる非現金のクレジットと、12か月分の料金という上限の上に置かれている。設備仕様は設備の説明であって、サービスの約束ではない。この二つを同じ棚に並べて発注書を書くと、障害の日に初めて、自分が何を買っていなかったかに気づく。

BTWのディレクトリでは、Lambda AIを継続して追跡している（BTWのLambda AIディレクトリ項目）。