はじめに
執筆時点で、このブログの記事は53本ありました。
記事が増えてくると、書き手が「自分の記事が検索でどう伸びているか」を知る手段がほしくなります。
そこで Google Search Console（以下 GSC）のデータから伸びている記事を抽出し、定期的に Slack に通知する仕組みを作りました。
今回の開発では、AWS が提唱する AI-DLC（AI-Driven Development Life Cycle） というやり方を試しました。
本記事では、作ったツールの技術解説よりも、AI-DLC という進め方を実際に使ってみて よかったこと と 課題に感じたこと を中心に紹介します。
この記事の要点
- ✅ Inception（要件定義）から Operation（デプロイ）まで、1つのワークフローで進められる
- ✅ AI が questions file（選択式の質問）で要件を詰め、回答どうしの矛盾まで指摘してくれる
- ✅ reviewer（レビュー役のエージェント）が、設計やコードの穴を見つけてくれる
- ✅ 判断の経緯が記録に残り、途中でAI コーディングツールを替えても続きから進められる
- ⚠️ 小さなツールには、成果物と手続きが重い
- ⚠️ reviewer の指摘を残したまま Approve すると、後のステージにしわ寄せが来る
- ⚠️ AI の推論が、確かめられないまま learnings（学び）として残ることがある
AI-DLC とは
AI-DLC は、AWS が2025年7月に発表したソフトウェア開発の方法論です。
これまでの AI 活用は「人が作業を主導し、AI が補助する」形が中心でした。
AI-DLC では主従を逆にして、AI が計画を立て、不明点を人に質問し、成果物を作る。人は成果物を確認して承認する、というサイクルをステージごとに繰り返します。
AI-DLC は、AI コーディングツール向けのルール一式として GitHub で公開されています（awslabs/aidlc-workflows）。
ルールを読み込んで動かす AI コーディングツールのことを ハーネス（harness） と呼び、Claude Code、Kiro、Codex CLI、Cursor、GitHub Copilot などに対応しています。
今回は v2.5.64（執筆時点の最新は 2.10.0）を使い、ハーネスとして Claude Code と Codex を併用 しました。
全体の構成
v2.5.64 では、ワークフロー全体が5つのフェーズ・32のステージに分かれています。
- Initialization（3ステージ）：始める準備。作業場所を用意し、既存コードの有無を判定して、進捗を記録する状態ファイルを作る
- Ideation（7ステージ）：何を・なぜ作るかを固める。実装の話に入る前に、狙いの整理や市場調査、実現できるかの検討を行う
- Inception（8ステージ）：どう作るかを決める。チームのプラクティス、要件、画面、設計、作業の分け方と順番を決める
- Construction（7ステージ）：実際に作る。詳細な設計、コードの生成、テスト、CI の整備を行う
- Operation（7ステージ）：動かして運用する。デプロイ、監視、障害対応、運用で得た結果からの改善を行う
1つのステージの中は、おおむね次の流れで進みます。
① AI が questions file（選択式の質問）を作る
↓ 人が [Answer]: 欄に回答する
② AI が成果物（要件書・設計書・コードなど）を作る
↓
③ reviewer が成果物をレビューする（ステージによる）
↓
④ 人が approval gate で Approve か Request Changes を選ぶ
↓ Approve されたら
次のステージへ本記事で出てくる AI-DLC の用語を整理しておきます。
- スコープ（scope）：実行するステージと省略するステージの組み合わせ。既製のもの（bugfix・feature など）のほか、案件に合わせて作ることもできる
- composer：依頼内容とリポジトリの状態から、案件に合わせたスコープを提案するエージェント
- depth：各ステージでどこまで詳しく検討するかの設定（Minimal / Standard / Comprehensive）
- questions file：AI が作る選択式の質問ファイル。
[Answer]:欄に回答する - reviewer：成果物を作ったエージェントとは別に、成果物をレビューするエージェント。READY / NOT-READY で判定する
- approval gate：各ステージの最後で、人が Approve するまで次に進まない関門
- audit log：回答・Approve・Request Changes・レビュー結果などの記録
- observation diary：ステージごとの AI の作業記録（
memory.md）。AI の解釈・逸脱・トレードオフ・未解決の疑問を記録する - learnings：ステージの終わりに AI が挙げる教訓の候補。人が選んだものが
project.mdなどに追記され、以降のステージで参照される
今回作ったもの
GSC のデータを定期的に集計し、前週と比べて検索で伸びている記事を社内の Slack に投稿するツールです。アプリケーションコードは約1,000行の小さなものですが、扱う技術は多岐にわたります。
- アプリケーション：Python
- 実行環境（AWS）：Lambda、EventBridge Scheduler（定期実行）、Secrets Manager、IAM、CloudWatch Logs
- インフラのコード化：Terraform（state は S3 で管理）
- 外部サービス：Google Search Console API、Slack（Incoming Webhook）
- CI：GitHub Actions（Lint・テスト・Terraform の検証・デプロイ用パッケージの作成）
要件定義からデプロイ手順の作成まで、AI-DLC のワークフローに沿ってステージを順に進めました。
上に挙げたアプリケーションのコード、Terraform、CI の設定、デプロイ手順書は、すべて AI がワークフローの中で作ったものです（進めたステージは次の「スコープ」で紹介します）。
デプロイの実行だけは、AI が作った手順書に沿って人が行っています。
スコープ：32ステージのうち11ステージを実行
AI-DLC では、32のステージをすべて実行する必要はなく、案件に合わせて選べます。
今回は composer（スコープを提案するエージェント）が「11ステージを実行する」スコープを提案してきたので、私が承認しました。
実行したステージは次のとおりです（最初の Initialization の3ステージは自動で終わるので、一覧には載せていません）。
- Inception
- practices-discovery：チームの開発ルールを決める
- requirements-analysis：要件を整理する
- refined-mockups：Slack 通知の見た目を決める
- application-design：アプリケーションを設計する
- Construction
- code-generation：コードを書く
- build-and-test：ビルドとテストを行う
- ci-pipeline：CI を整える
- Operation
- deployment-execution：デプロイする（今回は手順書の作成まで）
composer は、作るものが依頼の時点で決まっていたことから、Ideation をまるごと省略していました。
よかったこと
1. Inception から Operation まで、1つのワークフローで進められる
前のステージで AI が見つけた課題を、後のステージで拾って解決していきます。
- build-and-test ステージで、AI が「Lambda に載せる zip を作る手順がない」と書き残しました。すると次の ci-pipeline ステージで、zip を作るスクリプトが作られました。
- deployment-execution ステージでは、スクリプトが出力する zip のファイル名と、Terraform が参照するファイル名の食い違いを AI が見つけて直しました。直さなければデプロイが失敗していました。
2. 回答どうしの矛盾を見つけて、追加で質問してくる
AI は questions file の回答を1問ずつ見るだけでなく、組み合わせたときに問題がないか まで確認してきます。
requirements-analysis ステージで、私は「順位が大きく上がった記事から上位10本を載せる」「表示回数がごく少ない記事も対象に含める」と答えていました。
すると AI は、表示回数が少ない記事ほど順位が大きく動くことを数字の例で示し、今の回答のままでは 上位10枠のほとんどが、ほぼ誰にも見られていない記事で埋まる と指摘してきました。
3. reviewer が、設計やコードの穴を見つける
いくつかのステージでは、成果物を作るエージェントとは別に、reviewer が成果物をレビューします。
今回 reviewer がついた4ステージは、すべて初回の判定が NOT-READY（まだ承認できる状態ではない） でした。
なお今回のレビューは advisory（助言）の扱いで、Approve するかどうかは人が決めます。
- requirements-analysis：比較に使う前週のデータが取れなかった場合に、同時に当てはまる2つの要件のどちらを優先するかが決まっていない
- refined-mockups：通知を「新しい検索語で見つかり始めた記事」と「検索順位が上がった記事」の2つの一覧に分ける設計で、両方に当てはまる記事をどちらに載せるかが決まっていない
- application-design：必ずテストすると決めていたケース（前週のデータが取れなかった場合）で、通知に出すはずの記事一覧を、設計したデータ構造では受け渡せない（Critical）
- code-generation：設定次第で通知に載る記事数が上限を超える、取得するデータが多いと続きのページを取りにいかない など
特に application-design の指摘は、コードを書いた後に気づくと手戻りが大きい問題です。reviewer は、コードを書く前の段階で見つけていました。
4. 判断の経緯が残る
AI-DLC は、決まったことだけでなく 採用しなかったこと も記録します。
practices-discovery ステージでは、quality・developer・devsecops の各エージェントがそれぞれ推奨を出しました。「テストカバレッジ80%以上」など、私が選ばずに採用しなかった推奨もあります。採用しなかった推奨も、どのエージェントがどんな根拠で出したかとあわせて、evidence.md（判断の根拠をまとめたファイル）に残っています。
さらに、各ステージの observation diary（AI の作業記録）には、AI が作業中に行った解釈やトレードオフ、未解決の疑問が残ります。後から参加した人でも経緯を追えます。本記事も、AI-DLC が残した記録をもとに書いています。
5. 途中でハーネスを替えても、続きから進められる
AI-DLC は、どのステージまで進んだか、何が決まったかを、すべてリポジトリ内のファイルに保存します。中断しても、ハーネスを替えても、ファイルを読み込めば続きから進められます。
今回の開発では何度か、Claude Code の利用上限に達しました。上限に達した後、Codex に「AI-DLCの続きをお願いします」と指示し、Codex で実装の続きを進め、reviewer のレビューを経て Approve まで終えました。
6. できなかったことを「できた」と書かない
deployment-execution ステージでは、手元の AWS 認証情報が期限切れだったため、AI はデプロイを実行できませんでした。
AI は実行できなかったことを記録し、成果物の冒頭にも「デプロイは未実施で、実行できる状態にした記録である」と明記しました。
後日、私がデプロイを済ませて完了を伝えたときも、AI は結果を見せていない確認項目を合格扱いにしませんでした。
7. learnings が後のステージに効く
ステージの終わりに、AI が learnings（次に活かす教訓）の候補を挙げ、私が残すものを選びます。
選んだ learnings は project.md（プロジェクト固有のルールをまとめたファイル）に追記され、以降のステージで参照されます。今回は9件を残しました。
例えば refined-mockups ステージで、「後のステージで要件の振る舞いを変えたら、要件書に反映するか相互参照を入れる」という learning を残しました。
次の application-design ステージでは、設計の変更で画面設計の資料が古くなっていました。
変更は設計書にしか書かれておらず、reviewer は残した learning を根拠に、画面設計の資料にも反映するよう指摘しています。
課題に感じたこと
1. 小さなツールには成果物が重い
アプリケーションコードは約1,000行ですが、AI-DLC が作った成果物は、questions file などの記録も含めて Markdown 49ファイル・約23万字 になりました。要件書（requirements.md）だけで約1万6千字あります。
本来は、成果物を読んでから Approve する必要があります。今回の規模のツールには重い量でした。
小さな案件では、ステージをさらに削るか、depth（検討の詳しさ）を今回の Standard より下げることを検討したほうがよいと思います。
2. サブスクリプションの利用上限に2回達した
Claude Code と Codex は、どちらもサブスクリプションの枠内で使っており、月額以外の費用はかかっていません。ただし「よかったこと5」で書いたとおり、Claude Code の利用上限に何度か達しています。
AI-DLC は、ルールや前のステージの成果物を読み込みながら進むため、使用量が多くなります。
audit log を見ると、1つのステージで数千万トークンを読み込んでいました（大半はキャッシュからの読み込み）。
今回は Codex に切り替えて続けられましたが、1つのハーネスしか使えない場合は、上限が戻るまで待つことになります。
3. エンジンのチェックが厳しく、手続きで足止めされる
AI-DLC のエンジン（ワークフローの進行や記録を管理するツール群）は、記録の食い違いを防ぐため、手順から外れた操作を機械的に拒否します。
例えば、人が回答の要約を確認した後に questions file が書き換わると、「確認をやり直す必要がある」として先に進めなくなります。
どれも「人が確認していない内容で先に進まない」ための仕組みで、趣旨は理解できます。
ただ今回、拒否は11件記録され、うち7件が refined-mockups ステージに集中しました。修正するたびに要約の再確認と reviewer の再レビューが必要になり、往復が続きました。
4. reviewer の指摘を残したまま Approve すると、後のステージにしわ寄せが来る
requirements-analysis ステージで reviewer が Major の指摘を3件出していましたが、私は反映しないまま Approve しました。結局、指摘は後のステージで解決することになり、要件書も遡って直しています。
5. 決めたプラクティスと実際の運用がずれていく
practices-discovery ステージで「main に直接コミット」と「CI が落ちたらマージ不可」を両方選んだところ、AI に矛盾を指摘され、いったん PR 方式に決めました。
後からチームのルールを main への直接コミットに変えましたが、プラクティスを記録した team.md は PR 方式のまま残っています。
ルールを変えたときは、AI-DLC の記録も人が更新する必要があります。
6. AI の推論が、確かめられないまま learnings として残ることがある
deployment-execution ステージで、AI は「GSC からデータを取得するサイトの指定を誤ると、エラーにはならず『データ0件』が返ってくるため、設定の誤りに気づきにくい」と書いていました。私は、AI の書いた内容を例に含む learning を、Approve と同時に project.md に残しています。
記事を書くにあたって実際に API を呼んで確かめたところ、サイトの指定を誤るとエラー（403）が返り、「データ0件」にはなりませんでした。
ツールも 403 を受け取ると「取得に失敗した」と Slack に通知するため、誤りには気づけます。AI のもっともらしい推論が、確かめられないまま learnings に残っていたことになります。
learnings は人が選んで残す仕組みですが、選ぶときに中身の正しさまで確かめなければ、誤った推論がルールとして残ってしまいます。
7. AI が肩代わりできない準備がある
Google Cloud や Slack 側の設定、AWS の認証情報の更新といった外部サービス側の準備は、人がやる必要があります。
AI-DLC 自体の導入にも、いくつか手間がありました。
- bun（フックやツールの実行環境）のインストールが必要
- 同梱の設定ファイルは AWS Bedrock 経由での利用が前提になっており、Bedrock を使わない今回は設定を書き換える必要があった
- 導入時に
.gitignoreの設定が不十分で、AI-DLC の不要なファイルが Git の管理下に入ってしまい、後から整理した
使ってみての所感：向いている案件・向いていない案件
向いている案件
- 要件に曖昧さが残っていて、詰めながら進めたい
- 外部 API・認証・インフラなど、判断の多い境界がある
- 後から別の人が引き継ぐ、判断の経緯を残したい
向いていない案件
- 仕様が明確で、とにかく早く作りたい
- 使い捨ての検証（PoC）
- AI が作った成果物を読む時間が取れない（中身を確かめないまま Approve することになる）
使うときのコツも挙げておきます。
- スコープでステージを絞る：全ステージを回す必要はありません。
- reviewer の指摘は Approve 前に潰す：先送りした判断は、後のステージで片付けることになります。
- AI の推論は、learnings として残す前に確かめる：実際に確かめた事実か、AI の推論かを見分けます。
- 迷ったら、選ばずに聞き返す：ci-pipeline ステージで「CI は GitHub Actions でよいか」と聞かれた際、選択肢を選ばずに「CodePipelineの方がよかったりする？」と聞き返したところ、AI は両者を比べ、根拠を添えて推奨を示してくれました。
- 複数のハーネスを使える状態にしておく：利用上限に達しても、ハーネスを替えて続きから進められます。
おわりに
AI-DLC を使うと、AI は Inception から Operation まで、決めるべきことを質問し、回答の矛盾を指摘し、経緯を記録してくれました。
一方で、成果物と approval gate の手続きは重く、記録が増えるほど、中身を人が確かめる責任も増えます。
小さなツールには重いところもありますが、要件に曖昧さがある案件や、判断の経緯をチームで残したい案件では、試してみる価値があると考えています。
（ちなみに作成した通知ツールはデプロイして実際に稼働中です）