本記事は 夏休みクラウド自由研究2026 8/19付の記事です。 |
こんにちは。SCSK品田です。
私は趣味として、2人専用の動画共有アプリを、休みの日にひとりで細々と開発しています。
AWSが「AI-DLC」という開発手法を打ち出しています。AIエージェントに要件定義からデプロイまでを任せ、2週間のスプリントを数時間の「Bolt」に圧縮する、生産性は10〜15倍という触れ込みです。
実装はOSSとして公開されています。
今回は、私が個人的に開発しているアプリを対象に保守用としてAI-DLC v2を導入し、小さなバグ修正を1本、最初から最後まで通してみることにしました。
要点
・セットアップだけで丸一日でした。原因の9割はフレームワーク自体ではなく、Windows/Git Bash特有の環境要因でした。
・レビューゲート・学習機構は「小さくても効く」という実感があった。1行のバグ修正にしては相応のセレモニー量で、個人開発の日常使いには向かないという最初の予想は変わりませんでした。
前提条件
・少人数専用のプライベート動画共有アプリ(React + Vite フロントエンド、AWS CDK + Lambda バックエンド)で、アプリ自体は開発済み。
・今回はAWSのaidlc-workflowsv2ブランチ(検証当時preview版)を導入。・実行環境はWindows 11。フレームワーク本体の状態管理・監査ログ・フック処理はBun(TypeScriptランタイム)で動く前提で作られているため、Bunを合わせて環境構築。
つまり、AI-DLC v2 を保守タイミングで導入。
・AI-DLCは特定のAIコーディングツールに縛られない設計で、Kiro・Amazon Q Developer・Cursor・Cline・Claude Code・GitHub Copilot・OpenAI Codexなど複数の「ハーネス」に対応しています。AWS自身のIDEであるKiroとセットで語られることが多い印象ですが、今回はKiroではなく普段使っているClaude Codeをハーネスとして導入しています。
したがって、検証当時2026年7月時点での、個人開発・Windows環境・Claude Codeというハーネスの組み合わせにおける検証記録になります。
セットアップの現実
Bunのインストール、AWS Bedrockのアクセス確認までは順調でした。躓いたのはその先です。
Claude Codeをハーネスとして利用する場合かつ、既存プロジェクトの場合は.claude/settings.jsonが導入済みかと思います。
プロジェクトの途中からAI-DLC v2を導入する場合は、.claude/settings.jsonに変更が多数入るため、既存との競合確認や変更確認に時間を要します。
ここはプロジェクトの途中から導入するには困難なポイントの1つかと。
次にBolt起動に必要な、フレームワーク配布物のフックスクリプト(監査ログ・状態管理を担う12個のTypeScriptファイル)を.claude/settings.jsonに組み込もうとしたところ、Claude Code側の安全機構(auto-modeクラシファイア)に4回連続で拒否されました。。。
ということで念のため、12個のフックスクリプトを全部読み、危険なパターン(外部送信・認証情報アクセス・eval・curl/wget)がないか確認した後、.claude/settings.jsonを修正しました。
セットアップを終えたはずなのに「動かない」トラブルへの対処
セットアップを終え、いざ試運転(bugfixスコープ、7ステージ)を始めたところ、最初の承認ゲートで詰まりました。
Refusing to approve "reverse-engineering": a real human has not acted at this gate since it opened.
人間の承認を記録するはずのフックが動いていない、ということはわかりました。ただ原因特定までに2つの見当違いをしました。
1つ目の仮説(外れ): 「新しいフックはセッション起動時にしか登録されないはず。再起動すれば直るだろう」。Claude Codeを再起動し、新セッションで試し直しましたが、解決せず。
2つ目の仮説(外れ): グローバルにインストールしていた別のプラグインが、同じイベント種別(PreToolUse/PostToolUse/SessionStart等)のフックを既に握っていて競合しているのではないか。プラグインを無効化して再起動・再テストしましたが、結果は変わりませんでした。
最終的にデバッグモードで実際のログを見て判明した原因は、もっと地味なものでした。
UserPromptSubmit hook error Failed with non-blocking status code: /usr/bin/bash: line 1: bun: command not found
Claude Codeがフックを実行するシェルは/usr/bin/bash -c "..."という非対話・非ログインシェルで、~/.bashrcを読み込みません。事前に~/.bashrcに書いたBunのPATH設定は、このフック実行の文脈には一切反映されていませんでした。対処は単純で、フックの呼び出しコマンドをすべてbunから"$HOME/.bun/bin/bun"というフルパス直指定に書き換えるだけです。全部で13箇所ありました。
このタイミングで、別の壁にもぶつかっていました。。。フレームワークが既定で使うOpus 4.8モデルがAWSアカウントの設定起因で呼び出せなかったのです。※2026年7月時点
AccessDeniedException: anthropic.claude-opus-4-8 is not available for this account. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/
→ 今回はOpus 4.6にフォールバックして解決しました。
→ ここまでで丸一日。フレームワーク自体の不具合というより、環境要因のデバッグに大半の時間を溶かした形です。
実際にワークフローを1本回してみる
題材は、動画一覧のソート機能が効かないという、私が開発していたアプリに実在していたバグです。
フロントエンドは正しくソート条件を送っているのに、バックエンドのLambdaがそのパラメータを無視して常に固定の並び順で返す、というものでした。
bugfixスコープ(全32ステージ中7つを実行)で、Reverse Engineering→要件定義→コード生成→ビルド・テストの順に進みます。
ふむふむと思ったのは、要件定義のレビューです。私が用意した要件定義書を、レビュー専用のエージェントが一度突き返してきました。理由は、「バックエンドとの後方互換性を守る」という要件の説明例が、実際のソースコードと食い違っている、というものでした。指摘は正確で、修正して出し直したところ2周目で通りました。
→ レビューゲートは飾りではなく、実際に事実誤認を捕まえて突き返してきた、という点は素直に評価したいところです。
AI-DLC v2の記憶機能を使う: MFAログインのテスト方針を記憶
当アプリケーションのログインでは、MFAを有効化しております。Claude Codeで自動テストできるか検討していたところ、MFAの入力タイミングで繰り返し失敗しておりました。
この問題は明らかにテスト設定側です。新しいテストファイルだけを個別に指定して実行し直し(vitest run test/<ファイル名>.test.ts)、無事解決に向かいました。
このエピソードで一番良かったのは後始末です。AI-DLCには、ステージが終わるたびに「今回の作業で得た教訓を今後のルールとして残すか」を尋ねてくる仕組みがあります。この一件をvitestにおけるMFAの扱いという恒久ルールとしてプロジェクトのメモリファイルに記録したところ、次のビルド・テストステージでは実際にそのルールに従って安全にテストが実行されました。
→ (実務では最初にテスト方針を決めておく必要がありますが、、、)この機能はAIの恩恵を受けられてよいと感じました。
デプロイして動作確認
デプロイおよびMFAログインを含む動作確認は手作業にて実施しましたので割愛します。
まとめ
Good
- レビューゲートが実際に事実誤認を捕まえて差し戻した
- 学習機構が「MFAの失敗」の教訓をその場でルール化し、次のステージで実際に活きた
- 監査ログ・承認記録がすべて残るので、後から何が起きたかを追いやすい
No Good
- 数十行のバグ修正のために、丸一日分のセットアップと環境デバッグが必要だった。特に今回の環境の場合 .claude/settings.json の競合に時間を要した
- レビュー・学習儀式など、bugfixスコープ(最小構成)でも相応のセレモニー量があり、日常のちょっとした修正には重い
「AIで開発が10〜15倍速くなる」という数字は、おそらくチーム開発でのスプリント短縮を指しているのだと思います。今回のような個人の小さなバグ修正1件に対しては、その数字を実感できる場面ではありませんでした。むしろ丸一日を環境構築とデバッグに使った、というのが正直な実測です。
一方で、レビューゲートや学習機構が「小さな検証でもちゃんと効いた」という実感は残りました。次に複数人でこのアプリを触るようなことがあれば、また使ってみたいと思っています。