レポート 7027

AI Shipping Labsのウェブサイト（https://aishippinglabs.com/）の拡張に取り組んでおり、現在の静的サイトをGitHub PagesからAWSに移行したいと考えています。その後、既存のNext.js環境をDjangoに置き換える予定です。

段階的な計画は以下のとおりです。

1. 現在の静的サイトをGitHub PagesからAWS S3に移行する

2. DNSをAWSに移行し、ドメインを完全にAWSで管理する

3. 新しいDjangoバージョンをサブドメインにデプロイする

4. すべてが正常に動作することを確認したら、メインドメインをDjangoに切り替える

この方法であれば、すべての環境が既にAWS上に構築されているため、最終的な切り替えはスムーズに行えるはずです。

移行戦略自体は妥当でしたが、問題は実行方法にありました。

Claude Codeエージェントに過度に依存していたため、誤ってDataTalks.Clubコース管理プラットフォームの運用インフラストラクチャ全体を消去してしまいました。このプラットフォームには、2年半分の提出物（宿題、プロジェクト、リーダーボードのエントリーなど）が保存されていました。

さらに悪いことに、自動スナップショットもすべて削除されてしまいました。迅速なサポートを受けるためにAWSビジネスサポートにアップグレードする必要があり、追加料金10%を支払いました。幸いにも、AWSのサポートのおかげでデータベースを復元でき、完全復旧には約24時間かかりました。

この記事では、なぜこのような事態を招いてしまったのか、そして再発防止のためにどのような対策を講じたのかをお伝えします。

インシデント発生までのタイムライン

2月26日(木)

• 午後10時頃：Terraformを使ってウェブサイトの変更をデプロイし始めましたが、状態ファイルが古いコンピューターにあったため、それを使うのを忘れてしまいました。

• 午後11時頃：Terraformの自動承認コマンドが誤って実行され、Amazon Relational Database Service（RDS）を含むすべての本番環境インフラストラクチャが消去されました。その後、すべてのスナップショットも削除されていたことが判明し、AWSサポートに問い合わせました。

2月27日（金）

• 午前0時頃：より迅速な対応のため、AWSビジネスサポートにアップグレードしました。

• 午前0時30分頃：AWSサポートから、AWS側でスナップショットが存在することが確認されました。

• 午前1時～2時頃：AWSサポートと電話で連絡を取り、復旧のため社内チームにエスカレーションされました。

• 日中：バックアップ用のLambda関数の設定、削除保護の有効化、S3バックアップの作成、TerraformステートのS3への移行など、予防措置を実施しました。

• 午後10時頃：データベースは完全に復旧し、courses_answerテーブルだけでも1,943,200行のデータが含まれていました。プラットフォームは復旧しました。

障害発生の経緯

既存のTerraform設定の再利用

私は既に別のプロジェクト（DataTalks.Club Zoomcampsのコース管理プラットフォーム）でTerraformを使って本番環境のインフラストラクチャを管理していました。AI Shipping Labs用に別の設定を作成する代わりに、既存の設定に追加することで、わずかなコスト削減を図りました。

Claudeは、Terraformは別の設定にすべきだと説得しようとしていましたが、私はコスト削減のために、すべてのリソースをプライベートネットワーク内の仮想プライベートクラウド（VPC）に配置し、マシンをホストするための拠点として使用している既存の設定をそのまま利用しました。

削減額はそれほど大きくなく、月額5～10ドル程度でしたが、「なぜ別のVPCが必要なのか」と考え、すべての処理をVPC内で行うように設定しました。しかし、この設定変更によって、このサイトへの変更が他のインフラストラクチャへの変更と混在するようになり、複雑さとリスクが増大しました。

最初の警告サイン

手動でプランを確認する代わりに、Claude Codeにterraform planとterraform applyを実行させました。何かがおかしいと気づいた最初の兆候は、作成されたリソースのリストが長々と表示されたことでした。これは全く意味が分かりません。インフラストラクチャは既に存在していたからです。新しい環境を構築しているわけではありません。

Claudeを止めて、「なぜこんなに多くのリソースを作成しているのですか？」と尋ねました。エージェントの答えは単純でありながら、同時に恐ろしいものでした。Terraformは何も存在しないと認識していたのです。

しかし、なぜでしょうか？最近新しいコンピュータに移行したばかりで、Terraformを移行していませんでした。terraform planを実行した際、既存のインフラストラクチャは存在しないと想定し、ゼロから構築しているとみなしたのです。

すぐにterraform applyをキャンセルしましたが、既にいくつかのリソースが作成されていました。

AWS CLIによる重複リソースの分析と削除

次のステップは、作成されたリソースを評価することでした。私はクロードに、AWS CLIを使って環境を分析し、新規作成されたリソースと本番環境に存在するリソースを特定するよう指示しました。既存のインフラストラクチャには手を加えず、新規作成された重複リソースのみを削除したかったのです。

アシスタントは、AWS CLIを使って重複リソースを特定し、削除していると報告しました。これは正しいように思えました。

このクリーンアップ処理が行われている間、私は古いコンピュータでTerraformフォルダ（ステートファイルを含む）をアーカイブし、新しいマシンに転送しました。クリーンアップも完了したと思い、エージェントにTerraformアーカイブを指定し、新規作成されたリソースとアーカイブされたリソースを比較できるようにしました。

terraform destroyによる削除

エージェントはファイルの削除を続け、ある時点で「実行できません。terraform destroyを実行します。リソースはTerraformで作成されたため、AWS CLIを使うよりもTerraformで削除する方がよりクリーンで簡単です。」というメッセージを出力しました。

それは理にかなっていました。Terraformがリソースを作成したのなら、Terraformが削除するはずです。そこで、エージェントがterraform destroyを実行するのを止めませんでした。destroyコマンドは完了しました。その時点では、新しく作成されたリソースだけがクリーンアップされていると信じていました。

その後、DataTalks.Club Zoomcampsのコース管理プラットフォームを確認したところ、ダウンしていました。「これは一体どういうことだ？」と思い、AWSコンソールを開いて調査しました。

データベース、VPC、ECSクラスター、ロードバランサー、そして踏み台ホストがすべて消えていました。本番環境のインフラストラクチャ全体が破壊されていたのです。

[

](https://substackcdn.com/image/fetch/$s_!ropw!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fcc7921dd-b81d-453a-b832-7c8670a9fbeb_1600x880.jpeg)

破壊された本番環境インフラストラクチャの全リスト - VPC、RDS、ECSクラスター、ロードバランサー、踏み台ホスト

データベースの場所をクロードに尋ねたところ、答えは単純明快でした。削除されたとのことでした。

実際に何が起こったのか

実際には、クロードが私のTerraformアーカイブを解凍したことに気づきませんでした。その結果、現在の状態ファイルが、DataTalks.Clubコース管理プラットフォームに関するすべての情報を含む古いファイルに置き換えられてしまいました。

クロードがterraform destroyを実行した際、一時的な複製ファイルだけでなく、コースプラットフォームの基盤となる実際のインフラストラクチャまで削除してしまいました。作成されたステートファイルではなく、インフラストラクチャ自体が破壊されてしまったのです。

解決策の模索

1. バックアップの検索 本番環境のインフラストラクチャが消失したことに気づいた後、バックアップを探すことにしました。毎日バックアップが作成されているはずでした。

時刻は午後11時頃で、毎晩午前2時にスナップショットが作成されることを知っていました。RDSコンソールにアクセスして利用可能なスナップショットを確認しましたが、何も表示されませんでした。もう一度コンソールを確認しましたが、やはり何も表示されませんでした。

木曜日のRDSイベントを確認したところ、バックアップは午前0時24分に作成され、AWSコンソールのイベントセクションに表示されていましたが、バックアップ自体は消失していました。

次に、RDSイベントセクションを開くと、予想通り午前2時にバックアップが作成されていることが確認できました。イベントは一覧に表示されていましたが、クリックしても何も開かず、スナップショットにアクセスできませんでした。

その時点では、バックアップが削除されたのか、単に表示されなくなっただけなのか分からなかった。

2. AWSサポートへの問い合わせ 深夜0時頃、データベースの削除とバックアップの消失についてサポートチケットを発行した。AWSの担当者に連絡したが、こんなに遅い時間には返信がないだろうと思っていた。

返信がなかったため、ビジネスサポートでは本番環境のインシデントに対して1時間以内の対応を提供していることに気づき、アップグレードした。これによりクラウド料金が約10%増加した。

その後、必要な詳細情報をすべて記載した別のチケットを作成した。サポートからは約40分後に返信があった。

3. AWSサポートの調査結果 AWSサポートは、データベースとすべてのスナップショットが削除されたことを確認した。これは全く予想していなかった。APIリクエストでは、AWSにすべてを削除するよう明確に指示していた。

AWSサポートからの回答：クラスターの削除確認と利用可能なスナップショットの発見

AWSサポートからの最初の回答では、削除が確認され、コンソールに表示されていないスナップショットが見つかったと報告された。 AWS側では、私のコンソールには表示されていないスナップショットが見つかった。私がその点を指摘した後、彼らは電話会議を提案しました。

3. AWSとの電話会議 私たちは電話会議に参加し、状況を一緒に確認しました。

彼らは自社側で復旧手順を試みました。しばらくして、サポートエンジニアは社内でエスカレーションする必要があると伝えました。彼らが調査している間、私たちは電話を切らずに待機しました。

本番環境が既に停止していたため、私はTerraformを使ってインフラストラクチャの他の部分の再構築を開始しました。これは比較的迅速に進みました。また、この機会を利用して、複数のロードバランサーを1つに統合するなど、いくつかの簡素化も行いました。

万が一の復元に備えて、新しい空のデータベースインスタンスを作成しました。

電話会議は約40分から60分続きました。最終的に、彼らはもう少し時間が必要であり、状況が明確になり次第連絡すると言いました。

4. 24時間後 データベースが削除されてからちょうど24時間後、AWSはスナップショットを復元しました。

スナップショットの復元が完了し、使用可能になったことを確認するメールを受信しました。

AWSサポートからのスナップショット復元完了確認メール

AWSサポートからのスナップショット復元完了確認メール 以前は表示されていなかったスナップショットがコンソールに表示されました。

復元されたスナップショット 5. データベースの復元 Terraformを使用して、復元されたスナップショットからデータベースを再作成しました。

この時点で、Claude Codeを使用してTerraformの操作方法を変更しました。すべての権限を無効にし、自動実行もファイル書き込みも無効にしました。

プロセスはシンプルになりました。

プランを生成する

手動でプランを確認する

コマンドを自分で実行する

データベースの復元後、データを確認しました。courses_answerテーブルには1,943,200行が含まれていました。

ターミナルに、courses_answerテーブルに1,943,200行が復元されたことを示すPostgreSQLクエリが表示されています。

データが復元されました：courses_answerテーブルに1,943,200行 コース管理プラットフォームがオンラインに戻りました。すべての課題が表示されました。

データエンジニアリングZoomcamp 2026コースのダッシュボード（すべての課題を表示）

最終ステップは、新しいデータベースインスタンスでバックアップを設定し、インシデント発生時に作成された一時的な空のデータベースを慎重に削除することでした。両者を混同しないように注意しました。

今後の対策 AWSがスナップショットの問題を解決するのを待っている間に、安全対策の実装を開始しました。単一のdestroyコマンドで全てが消去されるような事態は二度と起こしたくありませんでした。

変更点は以下のとおりです。

1. Terraformステートとは別のバックアップ Terraformで管理されないバックアップを作成しました。

スナップショットがデータベースと共に消えてしまうとは想定していませんでした。このリスクを回避するため、Terraformライフサイクルとは独立したバックアップを確保しました。

また、S3ベースのバックアップも追加しました。これらはデータベースとは別に保存され、インフラストラクチャの状態とは連動していません。

2. LambdaとStep Functionsを使用した日次リストアテスト 自動バックアップワークフローを構築しました。

毎晩午前2時に、AWSが定期的な自動バックアップを作成します。午前3時頃、Lambda関数が起動し、自動バックアップから新しいデータベースインスタンスを作成します。これにより、毎日本番環境の最新のコピーが確保されます。所要時間は約20～30分です。

データベースが作成されると、Step Functionsでオーケストレーションされた別のLambda関数が実行されます。この関数は、SELECT COUNT(*) FROM emailのような簡単な読み取りクエリを実行して、データベースが実際に使用可能であることを検証します。検証が完了すると、データベースは削除されずに停止されます。そのため、ストレージ料金のみが発生し、コンピューティング料金は発生しません。

その後、前日に復元されたデータベースは削除されます。常に、最近復元されたレプリカが1つ利用可能です。

この構成にした理由は2つあります。

バックアップが実際に復元できることを継続的にテストしたい。

本番環境がダウンした場合、すぐに起動できるレプリカにトラフィックをリダイレクトできる。

常にこの方法を使用するとは限りませんが、このオプションを確保しておきたいのです。

3. TerraformとAWSの削除保護 削除保護を2つのレベルで有効化しました。

Terraformの設定

AWS自体

どちらも誤削除を防ぐための対策です。

Claude Codeによるdelete_protectionとprevent_destroyの違いの説明、および権限プロンプト付きでterraform planを実行する方法

削除保護の設定。これで、すべてのTerraformアクションに明示的な承認が必要になります。 技術的には、これらの保護はユーザーが明示的に無効化すればCLI経由で解除できます。しかし、操作の手間を増やし、意図しない破壊的な操作を防ぎます。

4. S3バックアップ保護 S3バックアップについては、バージョン管理を有効にしました。何かが削除されても、以前のバージョンは保持されます。バケットを削除するには、まずその内容を削除する必要があり、これもまたセキュリティ上の障壁となります。

5. TerraformステートのS3への移行 最も重要なのは、TerraformステートをS3に移行したことです。

ステートはもはや単一のマシンにローカルに保存されません。Terraformはインフラストラクチャの一貫性のある共有ビューを持つようになりました。これにより、以前のマシン上では実際にはローカルに存在していた状態が既にリモートにあると想定していたために、リソースの重複が発生していたという問題が解消されました。

S3に状態を保存することで、以下のメリットが得られます。

特定のラップトップに依存しない

マシンを切り替えても、状態が突然消えることはない

Terraformは常にインフラストラクチャの一貫したビューを維持できる

教訓 今回のインシデントは私の責任でした。

Terraformコマンドの実行をAIエージェントに過度に依存していました。plan、apply、destroyといった処理を委任できるものとして扱っていたため、最後の安全層が失われていました。

また、バックアップが存在すると思い込んでいたことも問題でした。自動バックアップはデータベースとともに削除されていました。復元パスのエンドツーエンドのテストを十分に行っていませんでした。

データベースは簡単に削除できてしまう状態でした。破壊的な操作を遅延させるための十分な保護策が講じられていませんでした。

AWSサポートからの連絡を待つ間、データが永久に失われる可能性も考慮しなければなりませんでした。

現在受講生が最終モジュールに取り組んでいるアクティブデータエンジニアリングコースについては、既に復旧計画を検討していました。過去のコースであれば、データは完全に失われていたでしょう。

幸いにも、AWSサポートがスナップショットを見つけ、すべてを復元してくれました。

今回の変更点 私が実装したセキュリティ対策は継続します。

Terraformについて：

エージェントはコマンドを実行しなくなりました。

すべてのプランは手動でレビューされます。

すべての破壊的な操作は私が実行します。

AI Shipping Labsについては、リリース前に適切な隔離を行うため、開発用と本番用に別々のAWSアカウントを使用することを検討しています。

最近の取り組み

1. AI Engineering Buildcamp AI Engineering BuildcampのモニタリングモジュールのDIYモニタリングプラットフォームセクションの録画を完了しました。

前回のコホートでは、このモジュールは主に独自のモニタリングプラットフォームの構築に焦点を当てており、Pydantic LogFireは後付けのような位置づけでした。今回のコホートでは、統合が容易で、唯一の課題がデータ抽出であるPydantic LogFireに重点を移しました。その回避策についても丁寧に説明しました。DIYモニタリングプラットフォームは、引き続きオプションのディープダイブセクションとして提供しています。

前回の受講生からのフィードバックも取り入れ、教材を調整しました。このセクションの録画は完了しています。

今週後半には、AIエンジニアリングビルドキャンプの残りのセクションをいくつか完成させる予定です。

2. AIエンジニアリングニュースレターシリーズ 今週は、毎週水曜日に配信しているAIエンジニアリングニュースレターシリーズの一環として、新しい記事を公開しました。この記事では、世界中の主要なテクノロジーハブから1,000件以上のAIエンジニアの求人情報を分析し、企業が現在この役割をどのように定義しているかを明らかにしました。

これらの求人情報に共通して見られる要素、すなわち、AIエンジニアの役割の様々なサブタイプ、企業が期待する責任、最も頻繁に登場するスキルとツール、そしてチームが採用している具体的なユースケースについてご紹介しました。

3) AIエンジニア向けライブリサーチシリーズ

火曜日に、私のイベントシリーズ「AIエンジニアリング：面接プロセス」の第3回ライブセッションを開催しました。

このセッションでは、実際の面接資料を大量に収集し、そのデータに基づいた知見を共有しました。AIエンジニア候補者に企業が実際に何を期待しているのか、面接でよく出題される技術的・概念的な質問の種類、そしてライブコーディング課題の例などを議論しました。

このセッションの準備として、700以上の情報源（レポート、TwitterやRedditの議論、YouTubeのインタビューなど）を精査しました。そこから面接に関する質問を大量に抽出し、その中から最も関連性の高いものを厳選しました。作業の大部分は、これらの資料のフィルタリング、検証、分類に費やされました。

この研究成果は、GitHub の AI エンジニアリング フィールド ガイド にも掲載され、継続的に更新されています。もし役に立つと感じたら、スターを付けてソーシャルメディアで共有してください。以下のテンプレートもご利用いただけます。

Alexey Grigorev 氏による、実際のデータ (1,765 件の求人情報と面接体験談) に基づいた AI エンジニアリング フィールド ガイドのリポジトリを見つけました。

AIエンジニア職への就職準備に最適です。

• 職務内容と必要なスキルの内訳

• 面接質問と持ち帰り課題

• 学習パスとプロジェクトアイデア

https://github.com/alexeygrigorev/ai-engineering-field-guide/tree/main

シリーズ最終回となる「AIエンジニアリング持ち帰り課題」は、来週月曜日にZoomで開催されます。このセッションでは、企業が実際に候補者に自宅でどのような課題を作成させているのかを分析し、その課題の背後にあるパターンを明らかにします。Zoomリンクを受け取るには、事前登録からご登録ください。

4) 対面形式ワークショップ

[

00x900.png)

](https://substackcdn.com/image/fetch/$s_!Z7_G!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F31785cfa-b9a5-4f35-b8c8-120d14b07599_1600x900.png)

来週3月10日（火）、ベルリンで開催されるExasol Xperience 2026にて、実践的なデータエンジニアリングワークショップを開催します。

このセッションでは、10億件を超える英国国民保健サービス（NHS）の処方箋データを用いて、生データの取り込みから分析準備完了のシステム構築まで、完全なデータパイプラインを構築します。データセットの取り込み、ステージング環境のセットアップ、AWS上のExasol Personalを使用したデータウェアハウスの構築、Kestraによるパイプラインのオーケストレーション、そしてGrafanaダッシュボードによる結果の分析を行います。

ベルリンにお住まいの方は、ぜひご参加ください。DataTalks.Clubコミュニティのメンバーは、コード「EXA-VIP-RDTC」を使用することで、カンファレンスに無料で参加できます（https://www.exasol.com/events/exasol-xperience/registration/）。ただし、ワークショップへの参加には別途登録が必要です（https://www.meetup.com/en-au/berlin-datatalks-club/events/313061198/?eventOrigin=group_upcoming_events）。会場入口で参加者リストを確認させていただきます。

資料は1ヶ月ほど前に準備済みで、現在、Exasolチームと内容の最終調整とワークショップのリハーサルを行っています。また、AWSアカウントをお持ちでない参加者向けにデータベースへのアクセス方法も検討中です。

5) Apache Flinkワークショップ

水曜日に、データエンジニアリングZoomcampのストリーミングモジュールを更新するために、Apache Flinkのワークショップを実施しました。

元の資料は、昨年このコースでFlinkのストリーミング配信を行ったZach Wilsonによって作成されました。ワークショップの内容の約80～90%は、彼の資料を基に、Flink 2.xと最新のPythonバージョン（3.12、3.9、3.8）で動作するように更新したものです。

Flinkは私の専門分野ではないため、非常に完成度の高いZachの資料を参考にしました。ザックさん、素晴らしいワークショップ資料をありがとうございました！

ワークショップでは、まずザックさんのオリジナルサンプルを詳しく見ていき、その後、透かしとボルトウィンドウを使った集約処理に関する別のケースを検討しました。資料の更新には、すべてが正しく動作することを確認するためにかなりのテストが必要でした。クロード・コードさんが更新作業を手伝ってくれましたが、かなりの指導が必要でした。

ツール

[

](https://github.com/getnao/nao)

naoは、分析エージェントの構築とデプロイのためのオープンソースフレームワークです。

• nao: 分析エージェントの構築とデプロイのためのオープンソースフレームワークユーザーが自然言語でデータを照会できると同時に、エンジニアリングレベルの制御と信頼性を維持します。データチームは、CLIを使用して構造化されたバージョン管理されたコンテキストを定義し、あらゆるデータスタックと統合し、単体テストによるパフォーマンス評価を行い、独自のLLMキーを使用して安全にセルフホストできます。ビジネスユーザーは、ネイティブな視覚化、透過的な推論、組み込みのフィードバックループを備えたチャットインターフェースを利用でき、分析エンジニアリングと意思決定の間のギャップを埋めることができます。

• Pilot Shell: Claude Code用のプロフェッショナルな開発環境で、エンジニアリングのガードレールをワークフローに直接組み込みます。複雑なマルチエージェントの足場を追加する代わりに、セッション間でコンテキストを維持しながら、すべての編集でテスト、リンティング、フォーマット、型チェックを強制します。その結果、本番環境の標準が組み込まれたエージェント型コーディングが実現し、開発者はタスクを委任し、一時的に作業を中断した後、検証済みで規約に準拠した出荷準備の整ったコードに戻って作業できます。

• rtk (Rust Token Killer): 高性能なCLIプロキシで、コマンド出力をモデルコンテキストに入る前にフィルタリングおよび圧縮することで、LLMトークンの消費量を削減します。一般的なClaude Codeセッションでは、git、テスト、ファイル読み込み、検索コマンドなどの一般的な操作においてトークン使用量を60～90%削減し、コストを大幅に削減するとともに、コンテキスト効率を向上させます。大規模なターミナル出力によってトークン予算が圧迫されるような、AI支援開発ワークフロー向けに特化して設計されています。

リソース

[

](https://github.com/alexeygrigorev/ai-engineering-field-guide/tree/main)

AIエンジニアリングフィールドガイド: AIエンジニアリングの役割に関するデータ駆動型リソース ― スキル、ツール、面接質問、学習方法パス

• AIエンジニアリングフィールドガイド: AIエンジニアの役割に関するデータ駆動型リソース。スキル、ツール、面接質問、学習パスなどを、実際の求人情報と実務家の知見に基づいて解説しています。企業がAIエンジニアに実際に何を期待しているかを分析し、役割責任、採用プロセス、よくある面接質問、さまざまなバックグラウンドを持つ人向けの学習パスといったトピックを網羅しています。このプロジェクトは、AIエンジニアとしてのキャリアを目指すすべての人にとって包括的なリファレンスとなるよう進化を続けています。

• 創業者向けマーケティング: 技術系創業者が多額の予算をかけずに最初の10人、100人、あるいは1,000人のユーザーを獲得できるよう支援するために設計された、厳選された実践的なリソースハブです。本書は、高レベルの成長ストーリーではなく、ローンチプラットフォーム、SEO（LLM SEOやAEOを含む）、コールドアウトリーチ、コンテンツ、価格設定、コンバージョン最適化、アイデア検証など、実践的なガイドを提供します。理論ではなく実行に基づいた、初期段階の市場参入戦略を構築するための体系的な出発点となります。

---

編集：Valeriia Kuka