はじめに
この記事はディップ Advent Calendar 2025の19日目の投稿です。
専門外の領域でもAIの力を借りればサクッとアプリを作れるはず！
ということでタイトルの通り、バックエンドエンジニアがAI-DLCというアプローチでモバイルアプリ、その名も寸計1を作ってみました。
アイコン
本記事では、AIを開発の主体に据えることで、いかにして知見のない領域を突破したのか。また、人間一人の思考では陥りがちな「考慮漏れ」を防げたのかを共有します。
自己紹介
Goがメインのバックエンドエンジニアです。
最近はスポットバイトルのリアーキテクチャに取り組んでいます。
アプリ開発経験はFlutterを少し触ったことがあるくらい。
AI-DLC（AI-Driven Development Life Cycle）とは
AIに人間の意図・要求を伝え、AIが要件・仕様を整理し実装まで行う手法です。
開始（Inception）、構築（Construction）、運用（Operation）の3つのフェーズに分けて実施していきます。（今回はアプリ作成までが目的なので運用フェーズは対象外）
よく仕様駆動（SDD）と比較されますが、開発の主体がAIなのか、人間なのか、という点が大きな違いになります。
| 特徴 | AI-DLC | 仕様駆動開発 (SDD) |
|---|---|---|
| 開発主体の中心 | AIエージェント | 仕様書を定義する人間 |
| プロセスの流れ | AIが計画・実行し、人間が検証 | 人間が仕様を定義し、AIが実行を支援 |
| 目的 | 開発ライフサイクル全体の自動化・効率化 | 仕様に基づいた正確な実装と品質向上 |
AI-DLCの詳細については以下を参照ください。
https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/
アプリ開発のきっかけ
リアーキテクチャチームでは開発手法としてAI-DLCを採用していますが、AIからの膨大なアウトプットをレビューしているうちに、気づけば残業…という本末転倒な事態が起きることが度々ありました。 「タイムボックスを設けて集中し、作業のチェックポイントを作りたい」 そう思ったのが、今回のアプリ開発のきっかけです。
開発してみた
環境
- VSCode
- Github Copilot
- GPT-5 mini（途中からClaude Sonnet4.5を利用2）
こちらの要求
# 概要
ユーザーが指定した時間が経過すると通知をslackなどに飛ばせるアプリの開発を検討しています。
以下に記載されている必須要件（must）を全て満たし、希望要件（want）を可能な限り実装できる設計を考えてください。
## must
- 時間設定できる
- 最大1h
- 残り時間が視覚的にわかりやすい
- 時間が来たら通知を送れる
- 設定したslackチャンネルに通知を出せる
## want
- 繰り返し設定できる
- slack以外にも連携できる
- 通知メッセージを任意のものに変更できる
## 使用技術
- Flutter
上記以外は自由。ミニマムかつコストが掛からない技術を選定してください。
inceptionフェーズ
ここでは、抽象的な「やりたいこと」をAIに渡し、詳細なユーザーストーリーに落とし込ませます。 プロンプトには、AIが勝手に暴走しないよう 「熟練PM」としてのロールと、「独自の判断をせず不明点は必ず質問すること」 という制約を課しました。
出力されたユーザーストーリー作成計画書
## 実感タイマー（寸計） - ユーザーストーリー計画
このドキュメントは、ネイティブアプリケーション「寸計」のユーザーストーリー作成と実装計画の契約書です。
各ステップにチェックボックスを付けています。いずれかのステップで追加情報が必要な場合は [Question] を記載し、下に空の [Answer] 欄を用意しています。私の判断で仕様を決定せず、あなたの回答を待って進めます。
---
### チェックリスト
- [x] 1. スコープと成功基準の確定
- 目的: アプリ名、対応プラットフォーム、必須/希望要件（must/want）、MVPの定義、成功の定義を確定する。
- 理由: 以降の設計・実装の基準を揃えるため。
- [Question] 以下の点を決めてください：
- 対応プラットフォーム（例：iOS / Android / 両方 / macOS等）
- Slack連携方法の初期希望（Incoming Webhook / Bot with OAuth / その他）
- アプリ名の確定（現在の候補：寸計）
- [Answer]
- 対応プラットフォームはiOS / Android の両方です。
- ミニマムな方法でお願いします
- アプリ名は「寸計」で確定です
- [x] 2. ユーザーストーリー作成（エピックと詳細ストーリー）
- 目的: must/want をもとに、ペルソナ、エピック、各ユーザーストーリーを作成し、受け入れ基準を定義する。
- 期待成果: 各ストーリー（例：タイマー設定、通知送信、繰り返し設定、カスタムメッセージ）のAcceptance Criteriaを含む一覧。
---
## ユーザーストーリー（作成済み）
### ペルソナ
- 名前: 佐藤 太郎（仮）
- 職業: エンジニア / プロダクト担当
- 年齢: 25-40
- 目的: 集中作業／短い作業セッションの管理。作業完了をチームに共有して流れを止めないようにしたい。
- 技術慣れ: スマホ（Android/iOS）を日常的に使用。Slack は業務で活用。
### エピック一覧
1. タイマーの作成・管理
2. 通知（Slack）送信
3. UI/UX と視覚フィードバック
4. 繰り返し・スケジュール設定（want）
5. 外部連携拡張（want）
---
### ユーザーストーリー（must 要件）
1) タイマーを設定できる（最大 1 時間）
- 役割: ユーザー
- ストーリー: ユーザーは作業時間を最大 1 時間まで設定できるようにしたい。そうすれば短時間セッションを正確に計測できる。
- 受け入れ基準:
- UI から 1 分単位（または 30 秒刻みでの選択を含む）で時間を指定できる。
- 入力が 1 時間を超える場合、設定を拒否しエラーメッセージを表示する。
- 保存されたタイマー設定はアプリ再起動後も保持される（ローカル保存）。
2) 残り時間が視覚的に分かる
- 役割: ユーザー
- ストーリー: ユーザーは残り時間を視覚的に把握したい。そうすれば作業の見通しが良くなる。
- 受け入れ基準:
- 実行画面に残り時間の数値表示がある（mm:ss）。
- 残り時間が視覚的に分かるインジケーターを表示する（例: プログレスリング、タイムバー、色の変化）。
- 進行中に一時停止/再開ができる。
3) 時間が来たら Slack に通知を送れる
- 役割: ユーザー
- ストーリー: ユーザーはタイマー終了時に設定した Slack チャンネルへ通知を送信したい。そうすればチームへ作業完了や合図を自動で伝えられる。
- 受け入れ基準:
- 設定画面で Slack Incoming Webhook の URL を登録できる。
- タイマー終了時に、登録された Webhook に対して HTTP POST を行い、Slack にメッセージが投稿されること（成功時の 200 系レスポンスで確認）。
- 送信に失敗した場合、アプリ内でエラーステータスを表示し、再試行ボタンを提供する。
- Webhook URL は安全に保存され、平文での共有表示はしない（デバイスの安全領域または暗号化で保存する）。
---
### ユーザーストーリー（want / 将来の拡張）
4) 繰り返し・シーケンス設定ができる（want）
- 役割: ユーザー
- ストーリー: ユーザーは複数の時間区間を順番に実行するシーケンス（例: 1時間作業 -> 20分休憩 -> 1時間作業 ...）を作成・実行したい。これにより作業／休憩サイクルを自動化できる。
- ユースケース例: 1時間作業 -> 20分休憩 -> 1時間作業 -> 20分休憩 を繰り返すサイクルをワンタップで開始したい。
- 受け入れ基準:
- ユーザーが複数のステップを順序付きで定義できる（各ステップにラベルと時間を設定可能。例: {ラベル: "作業", 時間: 60分}、{ラベル: "休憩", 時間: 20分}）。
- 各ステップの時間は分単位で設定でき、各ステップは最大 1 時間まで設定可能（プロダクトの must ルールに準拠）。
- シーケンスをループ（繰り返し）させるオプションがあり、指定回数または無限ループを選べる。
- 実行画面で現在のステップ名、残り時間、次のステップのプレビューが表示される。
- ステップ終了時に（オプションで）Slack通知を送れる（各ステップごとに通知のオン/オフを切り替え可能）。
- 実行中に次へスキップ、一時停止、再開、停止が可能で、ユーザー操作は即時反映される。
- 作成したシーケンスは保存・編集・削除でき、保存されたシーケンスはアプリ再起動後も保持される（ローカル保存）。
- シーケンス実行中にネットワーク障害があってもローカルのタイマー動作は継続し、Slack送信は指数バックオフで再試行する。ユーザーには送信失敗のステータスと手動再送オプションを表示する。
- UI でシーケンスの並び替えが容易にできる（ドラッグ & ドロップなど）か、ステップの挿入・削除ができる。
- デフォルトのプリセット（例: 作業60/休憩20）を用意し、ユーザーはそれを保存して再利用できる。
5) 通知メッセージを任意の内容に変更できる（want）
- 役割: ユーザー
- ストーリー: ユーザーはSlackへ送る通知メッセージを自由に編集したい。
- 受け入れ基準:
- 設定画面でテンプレートを編集できる（例: "{ユーザー名} のタイマーが終了しました: {タイトル}" のような変数を使用可能）。
6) Slack 以外の連携（want）
- 役割: ユーザー / 管理者
- ストーリー: 将来的に Teams / Email / webhook-proxy など他サービスに通知を送れるようにしたい。
- 受け入れ基準:
- 抽象化された通知送信インターフェースが存在する（実装詳細は別タスク）。
---
### 非機能要件・セキュリティ・運用上の受け入れ基準
- Webhook URL 等の機密情報はデバイス上で暗号化して保存する。
- ネットワークが不安定な場合、通知送信は指数バックオフで再試行し、一定回数失敗したらユーザーに手動再送を促すUIを表示する。
- 標準的なプライバシーポリシーに準拠する（ユーザーデータを外部に送らないことを明記）。
### 想定されるエッジケース（テスト観点）
- バックグラウンド/フォアグラウンドでのタイマー継続性（OSにより制約あり）。
- Webhook が無効・権限不足・タイムアウトした場合の取り扱い。
- デバイスの時刻変更やタイムゾーン変更時の挙動。
- アプリ削除や再インストール時の設定復元（必要性を要検討）。
---
### 次のアクション（要あなたの承認）
- 上記ユーザーストーリーをレビューしてください。
- 修正がなければ承認をお願いします—承認後に「3. 優先順位付けと受け入れ基準の確定」を開始します。
---
- [x] 3. 優先順位付けと受け入れ基準の確定（MVP確定）
- 目的: MVP を確定し、イテレーション優先度を決定する。
- 期待成果: MVP ストーリー集合とそれぞれの完了条件。
- [x] 4. UX フローとワイヤーフレーム作成
- 目的: 主要画面（タイマー設定、実行画面、連携設定、履歴等）のフロー図と簡易ワイヤーを作成する。
- [Question] デザインの制約やブランド要素（カラー、ロゴ、フォント等）があれば提示してください。
- [Answer]
- 特に決めていません。これらも含めて提案をお願いします。
- [x] 5. API / 連携仕様（Slack）定義
- 目的: Slack 通知の方式、権限、メッセージフォーマット、エラーハンドリング、再試行ポリシーを明確にする。
- [Question] Slack 連携について、以下を教えてください：
- 組織に既に Slack App があるか（ある / ない）
- Bot を使った OAuth フローを希望するか、簡易でWebhookだけ使うか
- [Answer]
- 組織に既に Slack App があるか -> ない
- 簡易にWebhookだけでOKです
- [x] 6. データモデルとローカル保存戦略
- 目的: タイマー設定、繰り返し情報、連携先設定、ユーザー設定のデータモデルを定義し、保存方法（例：SQLite / ファイル / Keychain 等）を決定する。
- [x] 7. 技術選定とアーキテクチャ設計
- 目的: ネイティブ開発（Swift/Kotlin）かクロスプラットフォーム（React Native/Flutter等）かの選定、モジュール分割、通知の実装方針を決める。
- [Question] 対応プラットフォームの優先度を教えてください（例：まずiOS、その後Android等）。
- [Answer]
- クロスプラットフォームで開発想定です。
- 対応プラットフォームはAndroid優先でお願いします
- [x] 8. 実装計画（イテレーション分解）
- 目的: 開発を小さなイテレーションに分解し、各イテレーションのスコープと完了条件を定義する。
- 期待されるイテレーション例:
- イテレーション A: 基本タイマー UI（最大1h、残り時間の視覚化） + ローカル通知
- イテレーション B: Slack 送信（Webhook か Bot） + 通知のステータス表示
- イテレーション C: 繰り返し設定、通知メッセージ編集
- イテレーション D: 他サービス連携、設定画面改良
- [x] 9. テスト計画作成
- 目的: 単体・統合・受け入れテストの範囲と合格基準を定義する。Slack連携はモックを用いた自動テストと手動検証を組み合わせる。
- [x] 10. ドキュメント／README 作成
- 目的: セットアップ、開発手順、Slack連携手順、デプロイ/配布手順を整備する。
- [x] 11. レビューと承認
- 目的: 上記計画をあなたにレビューしていただき、承認を得る。承認後、1ステップずつ実行し、各完了時にチェックをつけて進めます。
---
### 承認のお願い
この計画書をレビューしていただき、以下の点について承認または修正指示をください：
- 対応プラットフォーム（Question欄の回答）
- Slack連携方式の希望（Question欄の回答）
- デザイン制約やブランド要素（Question欄の回答）
承認いただければ、私（担当PM）はこの計画に従って次のステップ（「ユーザーストーリー作成」）を開始し、完了時にこのドキュメントのチェックを更新してレビューを求めます。
---
作成日: 2025-11-15
AIと壁打ちをする -> 自分では気づけない「不具合・考慮漏れ」の発見
- 実行中に次へスキップ、一時停止、再開、停止が可能で、ユーザー操作は即時反映される。
- 作成したシーケンスは保存・編集・削除でき、保存されたシーケンスはアプリ再起動後も保持される（ローカル保存）。
AIと壁打ちをしていて良かったと思ったのが、こちらが指示していない 「一時停止・再開機能」や「デバイス再起動後のデータ保持」 をAI側から提案してきたことです。
バックエンドの感覚で「通知を送る」ことばかり考えていた私にとって、モバイルアプリ特有の「ユーザーが途中で操作を中断する」「アプリがキルされる」といった考慮事項を、設計段階でAIが補完してくれたのは非常に大きな助けになりました。
要求に記載していない一時停止や再開の機能をAI側から整理・提案され、「あー確かにこの機能も必要だな」と気付かされます。
construction
inceptionで作ったドキュメントを「経験豊富なエンジニア」ロールのAIに渡し、モデリング -> コード実装と進めていきます。
爆速の開発体験
結果として、5日間（実働10時間程度）で3タブ構成のアプリが完成しました。
シーケンスの作成、実行、通知先設定を下部のタブから選択
実行画面
通知（Slack Webhook連携）
通常、不慣れなフレームワークだと「環境構築」や「非同期処理の書き方」で数日溶かすことも珍しくありませんが、AI-DLCならそこをスキップして 「ドメインロジックの確認」に脳のメモリを割ける のが強みです。
AI-DLCを実践して
良かった点
-
未知の領域の高速突破
- Flutter特有の記法やライフサイクルを知らなくても、レビューができる知識さえあれば形になる
-
思考の外部化
- AIを壁打ち相手にすることで、仕様の穴（エッジケース）をかなり埋められる
-
モチベーションの維持
- 環境構築などの「詰まりどころ」をAIが解消してくれるため、開発が止まらない
課題点
-
トークン消費
- AIを主軸に作業を進めるため、すぐにトークン上限に達する3（高性能なモデルを使うとさらに一瞬）
-
レビュー疲れ
- 自分でコードを書くのとは違う、常に「正しいか？」を判定し続ける脳の疲れがある
所感
「バックエンドエンジニアだからアプリは作れない」という壁は、AI-DLCによって取り払われたのかなと感じています。 もちろん、最終的な品質責任は人間にありますが、「0から1を作る」フェーズにおいて、AIは優秀なパートナーになります。
今回使用したLLMでは、GPT-5 miniなどの軽量モデルも案外優秀だなぁと感じた一方、やはり指示への忠実さや文脈理解では Claude 4.5 Sonnet が圧倒的に使いやすかったです。
時間を見つけてブラッシュアップとストア公開までやってみるのも面白そうです。
Appendix
スポットバイトルにおけるリアーキテクチャの取り組みをチームで積極的に発信しています。興味のある方はぜひ読んでみてください。