「リリース後」に向き合うAI駆動開発の実践

「Timee AI Sprint Day2 「リリース後」に向き合うAI駆動開発の実践」の登壇資料です。
https://timeedev.connpass.com/event/390292/

1. 2026/04/21 Yu Nakamura - chanyou 「リリース後」に向き合う AI駆動開発の実践 @chanyou0311
2. Yu Nakamura - chanyou • スタートアップでデータエンジニアとして交通データ分析基盤 の構築‧運⽤を経験 • その後、株式会社タイミーの DRE グループにジョイン • 最近はデータ利活⽤の⺠主化をキーワードに、 データモデリングやAIエージェントの開発に注⼒ • 広島在住。趣味はおうち Kubernetes クラスタ
3. タイミーとは 3 ｢働きたい時間｣と｢働いてほしい時間｣を マッチングするスキマバイトサービス 従来の「求⼈サイト」でも「派遣」でもない
4. タイミーの実績 スキマ バイト No.1 ※1 [調査⽅法]インターネット調査 [調査対象]直近1年以内にスキマバイトを経験したことのある18〜69歳の男⼥1033⼈ [調査期間]2025年1⽉31⽇〜2025年2⽉4⽇ [調査委託先]株式会社マクロミル ※2 2026年1⽉時点 利⽤率 ‧リピート率 ※1 ※1 導⼊事業者数 226,000企業 ワーカー数 1,340万⼈ ※2 ※2
5. 目次 • AI-DLC とは • Operation フェーズの設計 • Operation の実践例 • やってみて⾒えたこと
6. 1 AI-DLC とは
7. AI 駆動開発の現在地 • 開発プロセスに AI を組み込む動きが当たり前になってきている • 仕様書駆動開発やハーネスエンジニアリングなどの事例も⾒聞きするように • ⾃分たちのチームでも AI-DLC を実践して数ヶ⽉ ◦ リードタイムの短縮を実感してきている
8. AI-DLC の全体像 • AI-DLC とは AI を開発プロセスの中核に据えたワークフローのこと ◦ スクラムをやめて AI-DLC で開発をしている • Intent（意図）を AI に与えて、実装させるのが基本的な流れ ◦ Intent 単位で開発を⾏う ◦ スクラムでいう PBI に近い概念だが、AIの恩恵で粒度は⼤きめ
9. AI-DLC の全体像 • Intent を3つのフェーズで、段階的に成果物を残しながら実装していく ◦ Inception: 何を作るか、なぜ作るかを決める ◦ Construction: どう作るかを設計‧実装する ◦ Operation: リリース後の検証と運⽤ • 各フェーズの中でも、細かくステージが定義されている
10. AI-DLC の始め⽅ • awslabs/aidlc-workflows リポジトリに AI-DLC のルールがまとまっている ◦ Claude Code や Cursor を使ったスタートガイドが記載されている • おすすめの始め⽅ ◦ 1. チームごとに AI-DLC ⽤の git リポジトリを作成する ◦ 2. aidlc-workflowsリポジトリのルールを空のリポジトリに持ち込む ▪ スキルとして各フェーズを呼び出せるようにしておくと使いやすい ◦ 3. 複数の Intent の成果物を扱えるようにルールやスキルを調整する ◦ 4. コードリポジトリも参照‧編集できるようにしておく
11. AI-DLC の始め⽅ • /inception <Intent> で開始して AI がルールに沿って進⾏ • Intent や要件の明確化からコードリポジトリの PR 作成まで、 成果物を残しながら進む
12. 特徴① AI の⾃律性を引き出す • 細かい仕様を伝えるのではなく「意図」を伝える ◦ 例「ソーシャルログインを導⼊して会員登録時の離脱率を下げたい」 • AI からの質問や提案に答えながら仕様を明確化 • AI の振る舞いはルールやスキルで固めて⾃律的に動かす 🙋「こういうコードを書いて」 → 「こういうことしたいんだけど、どう思 う？」
13. 特徴② モブプログラミングが推奨されている • ⼈間のレビューがボトルネックになると⾔われて久しい • レビュー待ち時間を最⼩化するために、同期的に指摘事項を解消しながら 進められるモブプログラミングのスタイルが推奨されている • 私のチームでは1⽇4時間を AI-DLC による開発に充てている ◦ レビュー待ちが発⽣しないので、リードタイムの短縮を実感
14. リリースまでは速くなった。その先は？ • AI-DLC の実践で Intent をリリースするまでのリードタイムは短くなる • リリース後の検証や運⽤にかかるリソースの⽐重が⼤きくなっていく ◦ 「ビジネス意図に沿った変化が出ているか？」 ◦ 「⼀度リリースした機能が使い続けられているか？」 ◦ 「定期的なバッチ処理は健全か？ 所要時間に異常はないか？」 • aidlc-workflows でも Operation はプレースホルダだった • 独⾃に Operation フェーズを構築した
15. 2 Operation フェーズの設計
16. Operation フェーズの性質 • Inception: 何を作るか、なぜ作るかを決める WHY / WHAT • Construction: どう作るかを設計‧実装する HOW • Operation: リリース後の検証と運⽤ SO WHAT? • Inception / Construction: 「意図→現実」 • Operation: 「現実→意図」
17. OODA ループの採⽤ • AI にこの OODA を実⾏させて「現実→意図」のプロセスを構造化 • この考えをもとに Operation スキル‧ルールを独⾃に導⼊
18. Observe — 現実を観測する • AI が現実を観測するためにはツールを持たせる必要がある ◦ インフラ指標: Datadog MCP Server ◦ ビジネス指標: BigQuery
19. Orient — 観測結果をもとに、状況を解釈する • 観測したデータだけでは良し悪しが判断できない • AI が現実の状況判断をするには、対象の理想状態を伝える必要がある ◦ インフラ指標: SLO ◦ ビジネス指標: ⽬標値
20. Decide / Act — 解釈した状況から意思決定‧⾏動する • 理想状態に近づけているかどうかの解釈から、次のアクションを決める ◦ 例: 次に⾏うべき Intent の候補を提案する
21. 理想状態を3つの概念に落とし込む • 先ほどのイメージ例「インフラ指標: SLO / ビジネス指標: ⽬標値」 • 守りと攻めの2つの性質に分けられる。独⾃の概念に落とし込んだ • Contract ◦ 「このサービスが正常とはどういう状態か」を定義する ◦ 定量的に SLO としてもよいし、定性的に表現されてもよい • Objective ◦ 「このサービスを通して実現したいビジネス⽬標は何か」を定義する ◦ 「離脱率を20%下げる」のように定義される ◦ Objective の達成に向けて複数の Intent を積み重ねていく
22. 理想状態を3つの概念に落とし込む • Contract / Objective も AI が読み込める環境に定義する ◦ AI-DLC のリポジトリに Markdown に定義する ◦ MCP Server 経由で取得できる環境に定義する • 不確実性の⾼い Intent は仮説と⾔える ◦ 「X すれば Y が起きるはず」 ◦ こういったものも AI と⼀緒に仮説検証したい • Intent Objective ◦ Intent で成し遂げたい⽬標を定義する ◦ Inception フェーズで定義して成果物として残す（ようにルールを調整する）
23. 理想状態を Operation の⼊⼒とする • Operation の⼊⼒として Contract / Objective / Intent Objective を指定する ◦ /operation <contract-path> のようなイメージ ◦ 観察対象や状況判断の振る舞いを調整させる • Operation の実⾏タイミング ◦ Contract / Objective: Intent ライフサイクルの外。週次の定期実⾏など ◦ Intent Objective: Intent のデリバリー後。
24. AI-DLC の各フェーズのまとめ • Inception: 何を作るか、なぜ作るかを決める WHY / WHAT • Construction: どう作るかを設計‧実装する HOW • Operation: リリース後の検証と運⽤ SO WHAT? • Inception / Construction: 「意図→現実」 • Operation: 「現実→意図」
25. 3 Operation の実践例
26. シナリオ設定 • 架空の EC サイトを開発しているものとする • Objective: 会員登録時の離脱率を 10% 下げる • Intent: ソーシャルログインを導⼊して離脱率を下げたい • /inception ソーシャルログインを導入して離脱率を下げたい で開始
27. Inception — Intent Objectiveの定義 • 先⾏指標 ◦ ソーシャルログインの利⽤率が新規登録の 30% 以上 ◦ メカニズムが機能しているかの早期判断 • 遅⾏指標 ◦ 会員登録時の離脱率がリリース前⽐ 5% 改善 ◦ 最終的に改善したい成果指標 • リリース後に何を Observe するかを開発前に決めておく
28. Operation — Intent Objectiveの定義 • Construction が終わってリリース後に Operation を開始する ◦ /operation ソーシャルログインを導入して離脱率を下げたい • Observe ◦ BigQuery から、ソーシャルログインの利⽤率が55%、離脱率が4ポイント改善と観測 • Orient ◦ 利⽤率は⽬標の30%を上回るで意図通りの結果。離脱率は⽬標の5ポイント改善は未達。 • Decide ◦ ⽬標未達だが、⽅向性は正しい。別のアプローチを提案する • Act ◦ 新しい Intent 「⼊⼒フォームの簡略化」をユーザーに提案する
29. 4 やってみて⾒えたこと
30. 検証基準が開発前に固まる • 「何をもって成功とするか」を開発前に明確にするステップを確実に踏める • データ基盤の開発では「こんな分析マートが欲しい」のような依頼から始ま ることが多く、Objective が曖昧なまま進みがち ◦ 依頼だったとしても、開発の⼿前でステークホルダーと⽬標を詰めるプ ロセスを確実に踏めてよい
31. ツール整備が⾃然と推進される • AI が Observe できる環境がないと、⼈間が代わりにデータを集めることに • MCP Server やセマンティックレイヤーの整備が進む • ⼈間は分析や判断に集中できるように
32. データ基盤が Operation を⽀える • ビジネス指標の観測にはデータ基盤へのアクセスが不可⽋ • セマンティックレイヤーの整備が AI の Observe の精度を左右 • データ基盤が Operation の重要な役割を担うという気づき
33. AI が Observe しにくい情報の重要性 • Operation が洗練されるほど、AI で Observe しにくい情報の重要性が増す • N1分析のような、現時点で⼈間だけが⾏えるインタビュー‧探索活動 • AI の定量的な観測と⼈間の定性的な対話の棲み分けが求められる
34. 5 まとめ
35. まとめ • AI-DLC の基本的な流れと独⾃構築した Operation フェーズについて紹介した • リリース前もリリース後も理想と現実のギャップを埋め合わせる活動である ことに変わりはない ◦ リリース前の現実はコードを読み取ることで観測できる ◦ リリース後の現実の観測には、データ基盤の整備が効果的 • まだまだ荒削りなので、引き続き改善を重ねて洗練していきたい