21 ポイント 投稿者 GN⁺ 2026-03-11 | 6件のコメント | WhatsAppで共有
  • 最近、AIコーディングツールの利用に関連したサービス障害が相次いだことを受け、AmazonはすべてのAI支援によるコード変更についてシニアエンジニアの事前承認プロセスを導入
  • 内部メモによると、障害の原因として**「ベストプラクティスとセーフガードがまだ完全に確立されていない新しいGenAI活用」**が指摘された
  • 今月、AmazonのWebサイトとショッピングアプリが約6時間ダウンし、顧客は決済完了、アカウント情報の確認、価格照会などができなかったが、原因は誤ったソフトウェアコードのデプロイ
  • AWSでもAIコーディング支援ツールKiroが環境を削除・再作成したことで13時間の障害が発生するなど、少なくとも2件のAI関連インシデントが報告された
  • AIコーディングツールの本番適用に伴う運用リスクが現実化する中、ジュニアおよびミドルレベルのエンジニアによるAI支援変更にはシニアエンジニアのサインオフを必須とする即時措置を実施

Amazonの社内会議と対応措置

  • AmazonのEコマース部門は、最近発生した連続的なサービス停止を分析するため、大規模なエンジニア会議を招集
    • 会議の議題にはAIコーディングツールの利用に関連した事故が含まれた
    • 社内ブリーフィングメモでは、ここ数カ月で「高リスク(high blast radius)」の事故が増えており、「Gen-AI支援の変更」が主要因として言及された
  • 文書には、**「まだ完全に確立されていない新しいGenAIのユースケース」**が寄与要因として明記された
  • 上級副社長のDave Treadwellはメールで、「最近、サイトとインフラの可用性が良くなかった」と述べた

AI関連の障害事例

  • AmazonのWebサイトとショッピングアプリは今月初めに約6時間停止し、原因は「誤ったソフトウェアコードのデプロイ」だと確認された
    • これにより顧客は決済完了、アカウント情報の確認、商品価格の照会などができなかった
  • AWSでもAIコーディングアシスタントKiroの利用中に問題が発生
    • 12月中旬、Kiroが環境を「削除してから再作成」すると判断したことで、13時間にわたりコスト計算機サービスが停止した
    • Amazonはこの件を、**「中国本土の一部地域における単一サービスに限定された非常に限定的な事象」**と説明
    • 2件目の事故については、**「顧客向けAWSサービスには影響がなかった」**とAmazon側が付け加えた

新たな承認プロセスと運用改善

  • Treadwellは週次会議**「This Week in Stores Tech (TWiST)」**を通じて、問題の原因と短期的な改善措置を議論する予定
    • 従来は任意参加だった会議を、全従業員に参加を推奨する形へ変更
  • 今後、ジュニアおよびミドルレベルのエンジニアが行うAI支援コード変更は、シニアエンジニアのサインオフ承認を受けなければならない
  • Amazonは今回の見直しを**「通常の業務プロセスの一環」**と位置づけ、継続的な改善を目指すとしている

人員削減と障害増加を巡る議論

  • Financial Timesは、一部のエンジニアが**人員削減後に「Sev2」級のインシデント(迅速な対応が必要な中程度の障害)**が増えたと述べていたと報じた
  • Amazonは近年複数回のリストラを実施しており、2026年1月だけで16,000人のコーポレート職を削減した
  • ただし会社側は、人員削減が障害増加の原因だという主張には同意していない

今後の方向性

  • AmazonはWebサイトの可用性レビューと運用実績の点検を定例化している
  • 会社はAIコーディングツールの安全な活用と障害防止体制の強化を並行して進めている
  • 今回の措置は、AI導入の拡大の中で人的検証プロセスの重要性を改めて浮き彫りにする事例と評価される

6件のコメント

 
click 2026-03-11

AIコードをシニアがレビューすれば安全だと保証できるわけではないですよね。
CrowdStrikeの事件 はAIが原因ではなかったですし、
HeartbleedもAIがなかった時代の事故ですよね。

結論としては、誰かに責任を負わせるというのが要点で、
法的に責任を負う人間が必要だから自分たちは代替されないだろうと話していた税理士の方々のブラックユーモアを思い出します。

 
sea715 2026-03-11

そうですね。だから、AIエージェントに法的な署名のようなものを組み込まない限り、こうしたことは続く気がします..

 
click 2026-03-11

では、Anthropic や OpenAI の利用コストは天文学的に高くならないといけませんね
APIを1回呼び出すたびに保険料を払うことになるでしょうから

 
sea715 2026-03-11

うーん……妄想ではありますが、IAMみたいに何かが出てくるんじゃないかという……感じです

 
yeobi222 2026-03-11

税理士は刑務所に行く役割だと言われていたけど、保険会社が代わりに刑務所に行ってくれるわけではないので、結局は...

 
GN⁺ 2026-03-11
Hacker Newsの意見
  • 今回の「mandatory meeting」は毎週開かれている全社運用会議のことらしい
    先週大きな運用事故があったので、今週は参加率が高いだけだという
    メディアがかなり誇張しているように感じる

    • 内情を知っていると、ニュース報道はいつも現実感が違って見える
    • 記事では「普段は任意参加だが、今回は出席要請があった」としていたが、それが事実なのか気になる
      さらに「ジュニアおよびミドルレベルのエンジニアによるAIコード変更にはシニアの承認が必要」という方針にも触れていた
      定例会議であっても新方針の発表があるならニュース価値はあると思う
    • ニューヨークでは先週金曜の午後いっぱい、Amazonストアフロントがダウンしていた
      価格が表示されず、カートにも入れられなかった
      Walmartのような競合だったらニュースになっていたはずで、不思議だ
    • このスレッドは別タイトルの投稿から統合されたように見える。コメント時刻が元記事よりずっと前だ
    • 「メディアが誇張する」という意見には同意する。ケーブルニュースが生まれて以来ずっとそうだ
  • 「ジュニアとミドルレベルのエンジニアはシニアの承認なしにAIコードをプッシュできない」という方針は、
    シニアレビューが万能だという思い込みから来ているように見える
    実際には、シニアがコードを完全に検証するには、自分で書くのとほぼ同じだけの時間がかかる
    つまりレビューには価値があるが、悪いコードを良いコードに変えるものではない
    結局、「idiot proof」なシステムを作れば**『idiot』を雇ってもいい**という誤解が生まれるのが問題だ

    • キャリア初期にメンターから「コードレビューはバグを見つけるためではなく、文脈共有が目的だ」と教わった
      バグ発見は副次効果にすぎず、本当に重要なのはテストしやすくし、コード複雑度を下げることだ
      だが、そうした仕事は昇進の役には立たない
    • AIコードを実用に耐えるものにするには専門家レビューが必須だ
      モデルが作業している最中から監視するほうが効率的だ
      そうでなければAIは低品質コードの爆弾をまき散らす
      専門家が5~15倍の時間をかけて修正すれば何とかなるが、そうでなければコードベースは壊れる
    • 他人のコードをレビューするのは、しばしば自分で書くより遅くて混乱しやすい
      とくにひどいコードは理解するのに倍の時間がかかる
    • 雑なコードを直すのは新しく書くより難しいと感じる
      既存コードと新しい解決策を同時に頭の中に置いて比較しなければならず、認知負荷が大きい
    • AIがジュニアの生産性を10倍にするなら、シニアを10倍に増やすべきか、ジュニアを減らすべきか考えることになる
      結局、企業が平均的成果の管理中心へ変わっていく自然な進化のようにも見える
  • Amazon内部では、大半の人が解雇されないこと昇進にしか関心がない
    開発者評価は「チケット処理速度」「PRコメント数」「ドキュメント作成」で決まる
    AIを使わなければ競争に負ける
    こういう構造では「AIの使用を控えろ」という要請は現実的に機能しにくい

    • PRにコメントが多すぎても、他人のPRにコメントを残さなくても不利益を受ける
    • PRで議論が多いのは、協業せず一人で作業したシグナルかもしれない
      うまく協業しているチームほどPRでの議論は少ない
    • 結論として、ハンガー・ゲーム式の競争文化では働くべきではない
  • 本当に必要なのはself-reviewプロセスだと思う
    AIが書いたコードをそのままプッシュするのは危険だ
    GitHubのような場所に「self-review必須」オプションを追加して、作者自身が確認したことを明示すべきだ

    • 単にAIの出力をざっと眺めるだけではレビューではない。Heinlein流の『grok』レベルの理解が必要だ
    • 私はgitとSublime Mergeを使い、編集とレビューを分離する習慣をつけている
      ローカルUIが速いので、プロジェクトの流れをよりよく把握できる
    • 自分のコードすら読まない人にボタンを1つ増やしても意味はない
    • self-reviewだけでもデバッグ出力のようなミスは防げる
    • 私たちのチームはPRテンプレートにself-reviewチェックリストを入れている
      当たり前のことに思えるが、実際には役に立つ
  • Amazonのリーダーシップへの信頼が低下している
    ベテランの退職、AI品質の低下、頻発する障害によって、エンジニアリングが崩れていく印象だ

    • 長年のシニアたちがAIコードレビューばかりして時間を過ごしたくないのは当然だ
  • 意思決定者たちはパイプラインのボトルネックを理解していないようだ
    AIが10倍の速さでdiffを作れても、レビューがボトルネックなら全体速度は変わらない
    結果としてコストと不確実性だけが増える

    • 次の段階は「AIがAIコードをレビューする」と言い出すことだろう
  • AIコードレビューをPR段階で行うようになると、生産性上の利点は消える
    AIは10分で機能を作れるが、人間のレビューには10~20倍の時間がかかる
    本当に難しいのは「何を、なぜ作るのか」と「正しく作れたか」を知ることだ
    AIはまだその2つができない

    • CEOの立場から見れば、結局人間が直接確認しなければならないなら、AIの速度優位には意味がない
      LLMが生産とレビューの両方をうまくこなせるようになるまでは、リスクだけが増す
    • シニアがすべてのPRを承認しなければならないなら、専門コードレビュアーになるようなものだ
      現実的ではない方針だ
    • AI支持者は、いずれモデルが改善されてレビューのボトルネックは解消されると信じている
      そのときには、テスト後すぐにデプロイする時代が来ると言う
    • リーダーシップがこうした現実を知らないことに驚く
    • 実際にはリーダーシップも分かっているのだろう。コード品質の低下を防ぐためのブレーキにすぎない
  • コードレビューの本質はエラー検出ではなく、チームの同期と学習
    レビューを通じて設計や標準を共有し、ジュニアを育成し、多様な視点を取り入れる
    こうした過程こそがエラーそのものを減らす鍵になる

    • デミングの言う「検査は品質を改善しない」という原則はソフトウェアにも当てはまる
      設計の方向を誤ると、後から戻すのは難しいからだ
  • AIブームに注ぎ込まれている時間とコストが大きすぎる

    • だが今は追うべき別の対象がない
    • コードを検証しないのは結局ギャンブルと同じだ
  • 今後、重要インフラのソフトウェアがどうなるのか心配だ
    航空ソフトウェアまでこの流れに巻き込まれれば致命的な結果になりかねない

    • それでも中核インフラのコードは、今後も人間中心で書かれ続けるだろう
      AIは品質向上のための補助ツールとして使われる可能性が高い