ローカルデバッグ用に作った開発用 IAM が、AI 主体の開発で役目を失った話

はじめに

開発用に作った IAM の仕組みが、そろそろ使われなくなる。壊れたからでも、権限として間違っていたからでもない。当時はちゃんと機能していた。それでも役目を失う。理由は一つ、自分の開発のやり方そのものが変わったからだ。

なぜ作ったか：ローカルで実 AWS に触れないと開発できなかった

以前は E2E もデバッグも「dev 環境の AWS に繋ぐ」前提だった。今でこそ DB 系は InMemory 実装に寄せて AWS 無しでも動かせるが、当時は手元から実 dev リソースに接続しないと動作確認すらできなかった。そのための権限が無いとローカルでデバッグできず、開発がままならない。便利枠ではなく、開発の前提を支える load-bearing な足場だった。

作った仕組み：共通のベース＋「実行時と同じ権限」のサービス別ユーザー

権限はローカルからアクセスキーで使う IAM ユーザーとして持たせ、二層にした。まず横断的な土台として共通のローカル開発ユーザーを 1 つ置き、プラットフォーム横断の共通ポリシーをまとめる。その上で、サービスごとに専用の dev ユーザーを用意し、そのサービスの Lambda 実行ロールと同じ権限を持たせた。

狙いは「ローカルでも本番（デプロイ後）と同じ権限で動かし、権限ミスをデプロイ前に潰す」こと。ローカルだけ緩い権限で動いて、デプロイして初めて権限不足で落ちる——という事故を避けたかった。サービスが増えても共通の土台は据え置き、サービス固有ぶんだけ足していける形にしてある。

どう腐ったか：手元でデバッグすること自体が消えた

風向きが変わったのは、開発の主体が自分から Claude に移ってからだ。今は Claude が実装を進め、自分の責務はレビューと方針の確定になった。自分がローカルで実 AWS に繋いでデバッグする場面が、そもそも無くなっていった。

代わりに増えたのは dev 環境に適用して、そこで確認する流れだ。ローカルで再現するより、実際にデプロイして動く姿を見る。DB 系は InMemory でそこそこ担保できるようになり、「手元から実 AWS を覗く」必要が薄れた。Claude には Claude で、閲覧用の ReadOnly な IAM を別に払い出している。条件が一つずつ外れていくと、あの開発用ユーザー群はいよいよ使われなくなる。誰かが「廃止しよう」と決めたわけではない。前提が消えて、気づけば出番が無くなっていた。

残ったもの：足場には寿命がある

死因は権限設計の欠陥ではなく、支えていた前提（人間がローカルで実 AWS に繋いで開発する）が、AI 主体の開発への移行でまるごと消えたことにある。道具が良いか悪いかより、その道具が寄りかかっている前提の寿命の方が、その道具の寿命を決める。

AI 支援開発は「作り方」を変えると言われる。でも今回実感したのはもう一段深く、必要な"足場"そのものを変えてしまうことだった。だとすると、教訓は「前提の寿命を見極めろ」みたいな器用な話ではない。流れが速い時代には、長く使う前提で作り込みすぎないことの方が効く。最初から短命を覚悟して、必要十分で軽く組む。前提が変わったら惜しまず捨てる。今回の道具も、そのくらいの重さで済んでいたから、静かに退場させられる。アイデアが悪かったわけじゃない。開発環境の移行、時代の流れ——そういうものとして受け止めている。