前書き
みなさんも AI エージェントを活用して、開発作業がだいぶ楽になってきたんじゃないでしょうか？ClaudeCode なんかは、手放しでも色々要件を伝えるだけで、もりもり開発してくれて、本当に良い開発体験を味わえます。自分はちょっと遅れて、6 月頭くらいに ClaudePro で ClaudeCode が使えるようになってから、やっとこさ本格的に使い始めました（それまではずっと Cursor を使ってました）。
今回、自分の個人プロダクトを開発していて実際に ClaudeCode でやらかしてしまった事件をきっかけに、「これから自分はこういうスキルを磨いていかないとな」とハッと気付かされたので、その内容についてお話ししていきます。
雑魚雑魚エンジニアの拙い内容ですがよろしくお願いします。
結論
先に結論を言っちゃうと、AI がどんどん進化していく時代だからこそ、エンジニアには今まで以上に専門的な知識量が求められるなと感じましたし、そのなかで活躍するのがこれからのエンジニアなのでおそらく仕事はなくならず、より難しくなっていく。
正直、これまで通りの勉強量じゃ全然足りないし、もっとしっかり勉強して、ちゃんと正しい判断ができる力を身につけていかなければ、これからはバリューを出し続けるのは大変です。
結局、AI が来る前と本質的には変わらないじゃん、と思うかもしれませんが、やっぱりそこに行き着くんですよね
何でそう思ったかのしくじり体験談
ちょっとここからは前置きで話した個人プロダクト開発の失敗体験を元に話すので長くなりますのでお暇な方だけどうぞ。
まずどんなプロダクトなのか軽くお話しすると、私が自作キーボードにハマっていましてそれの材料管理がとても面倒くさかったので、ClaudeCode をつかって「ざいかん！」というアプリを作成しました。その名の通り部品とか商品の在庫を管理できるアプリです。ぜひ最後に軽く紹介するので気になったかたはぜひ使ってみてください。
📦 プロダクトの構成について
このプロダクトなのですが、現在の構成としてはざっくり以下のようになっています
現在の構成（改善後）
| 要素 | 技術スタック |
|---|---|
| フロントエンド | Vue.js + Vite → S3 + CloudFront 配信 |
| バックエンド | express.js → EC2 |
| DB | DynamoDB |
最初の構成（やらかした時）
| 要素 | 技術スタック |
|---|---|
| フロントエンド | Vue.js + Vite → S3 + CloudFront 配信 |
| バックエンド | express.js → ECS + ECR |
| DB | SQLite → ECS 内の EFS |
なぜこの構成になったかというと、ClaudeCode にほとんど委ねたからがほとんどです。
個人の小さいプロダクトですので最小料金で済ませたかったのがあったので結構お金のかかる DB を RDS とか使わずにやりたいのと普通 SQL サービス使いたかったのでここは SQLite で希望しました。あとは大体最小構成で組んでもそこまで金額が高いわけでもないので指定しませんでした。
ちなみにインフラは ClaudeCode に任せられるで terraform で管理しました。
🎯 いざ公開！
完成したのでいざ公開！ざっくりと作ってしまった割に意外と反響がありまして、おそらく 10 人位の方に初日から使ってもらっていました。個人プロダクトをいままでちゃんと公開したことがなく、とても嬉しかったです。
意外と需要があるから長く使いたいなと思い、雑に組んでもらっていたインフラ環境のコスト整備を行いました。一番大きな点は無駄に組んでいた ECS を EC2 に変更することでした。
今回の移行作業も ClaudeCode に頼るか！そしたらすぐ終わるやろ！とか意気込んでいました。もちろんすでに利用者がいたので、EFS に置かれていた SQLite のデータの移行は慎重にするつもりでした。一応実業務の職種も同じなのでそんなことは当たり前です。
そして ClaudeCode とも計画を重ね既存のユーザーに影響がないようにと慎重に作成された実行計画書確認していざ移行作業を行いました！
反映されて無事 EC2 構成に移行できて、本番環境も問題なく動いています！すごいやっぱ ClaudeCode しか勝たん！！
⚠️ 一度目のしくじり
と、あれ？本番環境でよくみたら自分のアカウントでログインしてもデータが一つもありません。あわてて CloudeCode にデータが吹っ飛んでるよ！と伝えて調査させて、ちゃんと移行のときにバックアップをとって複製したはずじゃん！と自分でも調査しました。
CloudeCode の調査の結果どうやら DB フォルダマウント位置を ECS の時と変えたらしく、それが原因で EC2 の時の新しいマウント先にファイルがなくて新規に DB ファイルを作成したようです。
ということは前のやつは残ってるよねということで、マウント先を以前に戻して全て完了しました！めでたし！めでたし！
とはいきませんでした（今回の件でもだいぶヒリヒリしましたが）。
というのもさっきの操作、ClaudeCode に aws cli をつかって緊急で対応させていたので、tarraform 内の記述の修正を行なっていませんでした。となるともう一度 terraform apply をすると...？
そうです、またさっきの現象を引き起こしてしまいました。
セッション履歴があるのに同じことをやらかしてしまった...。でも過去にも経験あるので、こんなこともあろうかと私はちゃんと ClaudeCode に作業レポートを書かせていました。えらい。
💥 そして二度目のしくじりへ
ClaudeCode が本番データが無くなった慌ててるので、私は過去のレポートをすっと伝えてあげると対応してくれました。
これで解決！本番環境も元通りなはずだし次はこうならないようにインフラ側のバックアップも考えるかと思った矢先、まだ本番環境データがもどってない？
慌てて（← もう 2 回目）ログを読んでみると
「以前のレポートからマウント先の変更必要なのことがわかったので、マウント先を変更して新しい DB を作成しました！」
...おいおいおいおい。なにしてんの！ということは今までのデータベース吹っ飛ばした？
その後色々確認しましたが、復活は無理でした。バックアップも何故か消えてました（ログをよくみたら「データが破損して読み込めないので削除した」って書いてました...）
ユーザーさんのデータ、全部消えました。ごめんなさい。
というのがやらかし体験談です。いやー、今書いてても嫌な事件でしたね...
反省点
1. インフラの運用を AI に任せすぎた
インフラの複雑性を甘く見ていて、AI に丸投げしてしまった。
2. 緊急対応の管理不足
AI が頑張ってインフラ上でのトラブルをコマンドで解決してくれたけど、それをちゃんと terraform で再現性ある形に落とし込んでもらっていなかった。
3. 知識不足によるリスク管理の甘さ
任せてしまっていたインフラ作業領域に関しての知識が乏しすぎたため、考えられるリスクを想定して指示を出せていなかった。
今回は 3 つ目の反省について話を少し掘り下げたく、自分自身業務でもある程度 AWS を触っていたり、SAA を取得していたりなど、まあまあ AWS をつかったインフラ環境構築に関しての理解がある方と思っていました。
しかし今回の事件を踏まえて、今回のようなリスクを生むことについて理解できていなかったという点が浮き彫りになった形でした。
ちょうど反省していたころ、先週に行われていた「開発生産性 con_findy」のポストを拝見しました。
他の方のポストの引用で申し訳ないのですが、t_wada さんの生成 AI についてのソフトウェア開発の考えです。
t_wada さんの最後のセッション、とても面白かった！
— しょぼちむ / syobochim Ugajin ✌️ (@syobochim) July 4, 2025
生成AIによって問題の顕在化が早くなってしまった
ソフトウェアエンジニアリングと生成AIを融合させる
世界は変わる。手を動かして評価し変化を楽しむ！
（1枚に収まらず、公開迷ったけどシェアです）
#開発生産性con_findy pic.twitter.com/WrRO73qgCR
生成 AI によって問題の顕在化が早まった
見出しにしちゃいましたが本当にその通りだと思います。
自分の場合はそれをエンジニア自身にも当てハマると思って、今回の失敗から、たしかに!と思いました。
みなさんも、なんとなく知った気になっていた知識が今までたくさんあったと思います。別に支障もなかったし、それでもなんとなくで乗り切れていれる環境であったパターンや、別に実際にそういう問題になかなか直面しないから、実は出来ないことになかなか気が付かない。
生成 AI が便利な時代になって、自分も初めて個人開発のアプリをまともに作成しました。なぜなら作成作業が今までの何倍も早くできるからやりたいことがすぐできると思ったからです。
けど結果として、実際には経験乏しい領域を AI に任せすぎて今回の失敗が出ました。まさに自分自身のスキルに関する問題の顕在化がされたと思いました。そしてそれがこんな短時間にです（2日くらいで作りました）。
失敗から得る学びは大きく、とても良いことではあるのですが、明らかにそのサイクルが圧倒的に早くなってきたため、それだけエンジニアも出てくる問題に対して学びついていく必要があります。
そしてやはりその問題に対しての適切な対応方法を判断するには、今まで以上に知識をつける必要があるのかなと思います。
あとがき
正直 VibeCoging でなんとなくの形もできますし開発のスピードは上がりましたが、安定した品質のサービスを運営し続けるためには、自分たちも追いつけるだけの知識量を求められるということですね。
なんならプロジェクトによっては開発力が上がったとタスクをたくさん振るかもしれませんが、結局その開発量に比例して求められるエンジニアの質の高いレビュー、自動テスト体制が伴ってこないと安全で安定した開発が難しそうな気もします。
なんだか最近本当に AI 凄すぎてエンジニアの仕事なくなるのかなと思っていましたが、逆にもっと大変になるんだなと思い知らされました。
ちょっと紹介
今回のやらかし題材になった、「ざいかん！」というアプリについて紹介です。
https://zaikanri.com/
個人で何か制作物をされている方向けに、部品在庫などの管理を楽にしようと作ったアプリです！
商品にレシピという概念があって、部品在庫を登録するとカレンダーでどのくらい作れるとかどの部品が足りないから作れない！など一目でわかります！
実際に自分が欲しくて作ったアプリなのでこれからもアップデートや保守をしていく予定ですのでよろしくお願いします。