Amazonが社内のコード変更管理を引き締めている。Financial TimesとBusiness Insiderが2026年3月10日から11日にかけて報じた内容によると、同社の小売関連システムでは2025年第3四半期以降、「影響範囲が大きい障害」が続いており、社内文書ではその一因として「Gen-AI assisted changes」が挙げられた。これを受け、上級エンジニアによる承認や二重レビュー、変更文書化の徹底を含む90日間の安全措置が導入されるという。

もっとも、Amazonは「最近の全障害がAI起因だった」という見方は認めていない。Business Insiderに対して同社は、3月上旬に検証対象となった事案のうちAI関連だったのは1件だけで、しかも「AIがコードを書いたこと」が原因ではないと説明した。The Registerへの説明でも、AIツールの利用で障害が増えているという説得力ある証拠は見ていないとの立場を維持している。今回の論点は、AIが障害を起こしたかどうかを単純に断じる話ではなく、生成AIがコード生成と変更速度を押し上げたとき、既存の審査体制と制御面が耐えられるのかという点にある。

AD

連続障害で表面化した「高い blast radius」

Financial Timesが確認した会議用メモでは、Amazonの小売技術部門で最近のインシデントに「爆発半径が大きい」、つまり変更の影響が広範囲へ一気に波及する傾向があったと整理されていた。Dave Treadwell氏は社内メールで、サイトと関連インフラの可用性が最近良くなかったと述べ、週次会議で原因の深掘りと短期対策を扱うと案内したという。普段は任意参加とされる会議に幅広い出席を求めたという報道も出ている。

Business Insiderが入手した内部文書は、問題の輪郭をもう少し具体的に示している。文書では2025年第3四半期以降に障害の傾向が続き、直近数週間には「いくつかの主要な」な事案があったとされる。そこで焦点になったのが、control plane、すなわち本番環境への設定変更やデータ処理の流れを制御する側の安全策が足りず、広域に影響する変更が通ってしまった点である。

3月2日の配送予定表示障害

内部レビューによると、2026年3月2日には、商品をカートに入れた顧客へ誤った配送予定が表示される障害が起きた。Business Insiderは、この障害で約12万件の注文逸失と約160万件のサイトエラーが発生したと報じている。ここではAmazonのAIコーディング支援ツールQが「主な貢献者の一つ」だったと文書に記された。

同じ文書は、生成AIの活用がcontrol plane運用に入ることで保護策が存在しない箇所の露出を加速させると警告していた。読み取れるのは、AIが単独で障害を起こしたというより、既存の統制が薄い領域で変更速度だけが上がり、欠陥のある運用設計が先に破綻したという構図である。

3月5日の注文急減障害

さらに3月5日には、北米マーケットプレイスの注文数が99％落ち込む障害が発生し、約630万件の注文逸失につながったと報じられた。こちらでは、Modeled Change Managementと呼ばれる正式な文書化・承認手続きを使わずに本番変更が投入されたことが主要因の一つとされる。内部文書には「自動の事前デプロイ検証がない」「権限を持つ単独の担当者が、保護策なしに影響範囲の大きい設定変更を実行できた」といった記述がある。

この2件を並べると、障害の共通項はAIそのものより、変更の説明責任、事前検証、複数人承認、そして高影響システム向けの強制的な制約が足りなかった点にある。生成AIはその欠陥を新たに作ったというより、もともと存在した運用上の鋭い角を短期間で露出させたと見る方が実態に近い。

争点は「AIが悪いか」ではなく、誰が最後に責任を持つか

今回の報道で最も注目されたのは、AI補助コードに対する上級エンジニアの承認強化だ。Financial Timesの報道では、ジュニアおよび中堅エンジニアによるAI支援の変更について、今後はシニアエンジニアのサインオフが必要になるとされた。これは経験の浅い開発者が書くのではなく、機械が出したコードを上級者が審査する役回りへ比重が移るように整理されたためだろう。

一方でAmazonは、この説明が広すぎると否定している。Business Insiderへの説明では、「AI補助の変更すべて」に上級者承認が必要になるという理解は正確ではないという。ここには明確な温度差がある。報道側は生成AI利用と承認強化の結び付きを強調し、会社側は恒常的なAI起因論に見える描写を切り離そうとしている。

ただし、両者の主張を突き合わせても、結論はそれほど離れていない。Amazon自身が変更プロセスに意図的な摩擦を入れる暫定安全策を実施すると説明している以上、同社が現行の変更速度と統制水準のバランスを問題視していることは確かである。生成AIはその議論を早めた触媒であり、論点の本丸は、人間による最終責任の位置を開発工程のどこに置くかにある。

AD

90日安全措置で変わる開発現場

Business Insiderによれば、新たな90日ガイドラインは約335のTier-1 systemsを対象にする。これは消費者へ直接影響し得るシステム群で、2025年以降に複数回の注文影響インシデントを起こした、VP配下組織が所有するサービスが中心だという。対象の絞り方は象徴的である。Amazonは全社一律で開発を遅くするのではなく、売上や顧客体験へ直結する面から先に規律を強める。

新ルールでは、コード変更前に二人のレビューを受けること、社内の文書化・承認ツールを使うこと、そして中央の信頼性エンジニアリング規則に厳密に従う自動化システムを通すことが求められる。加えて、Tier-1システムの責任者やDirector、VPクラスには、本番コード変更活動の監査が指示されている。これは開発現場だけの改善ではなく、管理職側へ運用責任を引き戻す措置でもある。

同社は恒久対策として「決定論的」と「エージェント的」両方の面での安全策を検討している。前者はルールベースで再現性の高い検査であり、後者はAIを使って異常や危険な変更を見つける考え方だ。興味深いのは、生成AIで生じた不確実性を、別のAIだけで相殺するのではなく、再現可能な制御も組み合わせる方向を打ち出している点だ。大規模ECでは、価格、在庫、配送、決済のいずれも一度崩れると売上への直撃が早い。だからこそ、自由度の高い生成系と厳格な決定論的統制を並べて運用する設計が必要になる。

AWS事例が示したことと、小売への波及

今回の小売部門の話題は、AWS側で先に起きたAIコーディング支援絡みの障害報道とも切り離せない。Financial Timesは、2025年12月にAWSのKiroが一部の変更に関与し、中国本土リージョンのCost Explorer系サービスで約13時間の障害が起きたと報じた。これに対しAmazonは、原因は誤設定された権限ロールであり、AIでも手動操作でも起こり得る人為的ミスだと説明した。

この反論は一見もっともである。現場で障害を起こすのは、最終的には不適切な変更が本番へ入ることだからだ。だが、生成AI時代の難しさは、誰がどの論理でその変更を組み立てたのかを後追いしにくくなる点にある。従来の人手実装なら、設計意図はコードレビュー、コミット履歴、担当者の説明から比較的追える。AI支援が深く入ると、提案生成の過程、採用理由、危険箇所の認識が散逸しやすい。大規模組織ほど、その曖昧さは監査や再発防止のコストとして跳ね返る。

Amazonが今回打ち出したのは、生成AI活用を止める方針ではない。むしろ使い続ける前提で、どのレイヤーに人間の判断を差し込むかをやり直す動きである。これは同社固有の修正に見えて、実際にはAIコーディングを本番運用へ広げた大企業が次に直面する標準課題でもある。生産性の上振れだけを見てレビュー工程を据え置けば、速度差はそのまま事故率の差になる。逆に、承認と検証を厚くしすぎれば、AI導入の費用対効果は鈍る。争点は、どこまでを自動生成に任せ、どこからを人間の責任境界として明示するかに移っている。

Amazonの今回の90日措置は、その境界線を売上直結システムで先に引き直す試みである。ここで監査手順、二重承認、決定論的な安全策が定着すれば、生成AIは開発者の代替ではなく、高速な下書き装置として再配置されるだろう。定着しなければ、AIコーディングの導入効果を語る企業は、障害後の説明責任まで含めた運用設計を問われることになる。次に市場が見るのは、AIが何行コードを書いたかではない。AIが関与した変更を、どの企業が壊さず、説明可能な形で本番へ流せるかである。

Sources