社内の AI 開発ハッカソンで、ピアボーナスサイトを 1 本作りました。
部署を越えて感謝カードを送り合う、社内向けの Web アプリです。
人間が書いたコードは 0 行です。 要件定義も、設計も、実装計画も、実装も、テストも、
検証も、ドキュメントも AI にやらせました。人間がやったのは「判断」と「差し戻し」だけです。
何を解決するか
- 部署が違うと、助けてもらっても感謝を伝える場がない
- 誰が誰を助けているかが見えず、部署をまたいだ協力が評価にも記憶にも残らない
- ただし個人ランキングにすると逆効果になるので、順位を作らず交流の広がりだけを見せる
触ってほしいポイント
- カードを 1 枚送る。 宛先を選ぶと「初めての相手 +5pt」のような加算が送信前に出ます
- タイムラインにポイントが出ないこと。 ポイントは本人のマイページにしか出ません
結論
どう進めたか
| やったこと | ねらい |
|---|---|
| 計画を書く AI と、レビューする AI を分ける | 同じセッションに自分の計画を評価させても、だいたい褒めて終わる |
| 実装 AI には「計画にない変更は、実装せずに報告しろ」と指示する | AI は放っておくと親切に直す。並列開発では、その親切さが事故になる |
| 後半は 4 セッション並列。共有ファイルは連絡ボード経由で集約 | 衝突するのはコードより先に、ポートとテスト |
| 別モデルに敵対的検証をやらせる | 作った AI は自分の実装を疑えない |
| ブラウザ操作 AI に実画面を触らせる | 自動テストが原理的に見られない層がある |
何を学んだか
-
「テストが緑」は「動く」を意味しません。
全テストが緑の状態で、機能が 2 つ実装ごと存在しないことに提出直前で気づきました。 -
だから「完了」の定義を変えました。
「テストが緑」ではなく、**「検証観点の ID がテスト名に現れ、そのテストが実際に実行され、実機で確認された」**に。 -
AI は「調べる範囲」を勝手には広げてくれません。
メールが届かない件で、AI は丁寧な比較実験の末に間違った結論に到達しました。正解は「迷惑メールフォルダ」でした。
工程はほぼ全部 AI に渡せる。ただし「できた」の判定だけは渡せない、というのが今回の結論です。
作業時間の目安は 8 時間でしたが、実測は AI 稼働で 29.4 時間でした。内訳は 4 章に書きます。
1. 何を作ったか
ホーム（タイムライン）。表示はすべてダミーデータです。
カード送信ダイアログ。各 50 字で書き、宛先を選ぶとその場で加算内容が出ます。
設計で一番大事にしたのは、人と人、部署と部署のつながりを見せることです。
カードが 1 枚送られるたびに「誰が誰を助けたか」が記録され、それを 部署間の交流マップとして可視化します。
自分の部署がどの部署とやりとりしているか、今月初めて交流した相手が何人いるか、が見える。
感謝の「量」ではなく、つながりの広がりが主役です。
だからポイントは本人のマイページにしか出しません。上の画面をよく見ると、カードのどこにもポイントが出ていません。
順位が付いた瞬間に「感謝」が「稼ぎ」に変わり、つながりを見せるという目的が壊れるからです。
技術構成
- フロント: React 18 + Vite + React Router + Tailwind
- API: API Gateway (REST) + Lambda (Node.js 20 / Hono)
- DB: DynamoDB（オンデマンド）
- IaC: AWS CDK の 1 スタック
- テスト: 単体 409 件 / フロント部品 132 件 / 統合（DynamoDB Local）/ E2E（Playwright）
社内限定公開なので URL は出せません。「同じ相手には 1 日 1 回」「1 日あたりの上限」といった
制約は、DynamoDB の条件付き書き込みとトランザクションで原子的に実装しています。
2. どう開発したか
2.1 方針と体制
最初に決めたのはこれだけです。
人間が手を動かしたほうが速い場面でも、まず AI にやらせてみる。人間は「判断」と「差し戻し」だけをやる。
[人間] ← 判断・差し戻し・優先度付けだけ
│
[オーケストレーター役の AI セッション]
│ 計画をレビューして差し戻す／合流フェーズを回す
├─ 計画作成エージェント（上位モデル）
├─ 実装エージェント（軽量モデル）× 各 Step
│
├── Step 5 セッション ─┐
├── Step 6 セッション ─┼→ 連絡ボード（handoff/*.md）で
├── Step 7 セッション ─┤ 共有ファイルの差分を集約
└── Step 8 セッション ─┘
後半は別々のターミナルで 4 セッション同時に進めました。同時に動かして最初に衝突するのは、
コードではなくポートとテストです。そこで、並列フェーズでは単体テストとフロント部品テストだけ走らせ、
統合テストと E2E は「書くだけで走らせない」（DynamoDB Local と dev サーバのポートを取り合うため）と決めました。
このとき一番強く書いた注意書きがこれです。
skip を「通った」と読み替えない。 skip は「未検証」であって「完了」ではない。
これが後で自分に刺さります（3.1）。
2.2 計画を書く AI と、レビューする AI を分ける
同じセッションに「自分の計画をレビューして」と言っても、だいたい褒めて終わります。
レビュー専任のセッションを立てて差し戻させ、そのまま実装していたら確実に壊れていたものを 3 つ止めました。
- Lambda の実応答に CORS ヘッダが付かない設計だった。 プリフライトだけでは、ブラウザは本応答をブロックします
-
CSP のメタタグが本番ビルドに残る設計だった。 ヘッダとメタの両方を満たす形で評価されるので、メタ側の
connect-src 'self'が本番で API 通信を遮断します - 実行すると必ず失敗するテスト定義が 2 件。 「テンプレートに IPv4 リテラルが無いこと」を検査するテストなど（許可 IP を注入する以上、必ず載ります）
どれも計画の文章としては綺麗に書けていたものです。整った文章であることと、動くことは無関係でした。
2.3 実装 AI に「勝手に直すな」と言う
実装エージェントへの指示に、必ずこの 1 行を入れました。
計画にない変更が必要になったら、実装せずに報告すること。
ある Step の実装者が、別の Step が持っているファイルのバグ（通知レコードの TTL 書き忘れ）を見つけたとき、
勝手に直さず報告してきました。並列で 4 セッションが動く中で各々が「ついでに直す」をやると、
コンフリクトと出どころ不明の変更が積み上がります。AI は放っておくと親切に直します。親切さを禁止するのも設計のうちでした。
2.4 ブラウザ操作 AI に実画面を触らせる
自動テストが原理的に見られないものがあります。実ブラウザでの見た目の崩れ、キーボードだけで最後まで操作できるか、
日本語入力（IME）中の文字数カウント、連打・中断・リロードといった割り込み。
ここはブラウザを操作する AI エージェントに、全 14 画面 × デスクトップ / モバイルのスクリーンショットを撮らせたうえで
実際に操作させました。画面の説明文と実挙動が食い違っているもの 16 件が出ました。
- 機能設定の「リマインド通知」の説明にある通知が実装されていない（実際の効果はバナー表示だけ）
- 送信前プレビューにボーナスが出ず、実際の加算とプレビューが食い違う
- 管理画面の入力欄 14 件にアクセシブルな名前が無い
- 読み込み完了前にスイッチを操作すると、保存されず成功メッセージも出ない
指摘を反映したあとの機能設定画面。「送信リマインドのバナー」は監査前「リマインド通知を有効にします」と書かれていましたが、通知は実装されていませんでした。
エージェントに渡す指示書は丸ごと貼れば開始できる形にし、使い捨てアカウント（すべて @example.invalid）、
壊してよい範囲、バックアップでも戻せない 3 つ（送信済みメール・アップロード画像・他人の操作）を書きました。
効いたのは 「推測で『動いた』と書かない。確認できなかったものは『未確認』と明記すること」 の 1 行です。
検証用アカウントは実在しないドメインで作り、「壊してよい」と言える状態を構造的に保証しました。
2.5 別モデルに敵対的検証をやらせる
作った AI に「脆弱性を探して」と言っても、自分の実装は疑えません。 別のモデルに攻撃者視点で触らせました。
セキュリティ面は「多層防御が効いている」と評価された一方、UX に重大な欠陥が出ました。
- 通報後のダイアログから脱出できない（閉じるボタン無し・ESC 無効）
- キーボード利用者が送信フォームに到達できない
- スタンプを取り消せず、別スタンプで無言置換される
- 「ポイント上限に達しています」と出たまま送信が成功し「+5pt」と併記される
- ヘッダーの検索バーが完全に無機能
このレポートは自分の検証の甘さも自己申告していました。管理者アカウント 1 つで検証したため
「API レベルでも一般ユーザーに拒否されるか」は確定できない、と。後から一般権限で再検証し、
1 回目の所見 2 件が訂正されました。検証する側の AI も間違えます。
3. そこで得た学び
3.1 「緑」は「検証済み」を意味しない
テストが全部緑の状態で壊れていたものを並べます。
単体テスト 132 件が緑で、管理画面 3 つが開けなかった。 壊れていたのはルート登録の 1 行で、
部品単体テストの守備範囲外です。E2E を 1 本動かした瞬間に落ちました。
統合テストが CI でだまって全件スキップされていた。 接続先が未設定だと skip される作りで、
CI 側の環境変数が抜けていて、**赤 0 件・skip 全件で「緑」**でした。
セキュリティ要件「他人のデータを書き換え・削除できない」の検証が 1 件も走っていない状態です。
2.1 で「skip を通ったと読み替えるな」と大書きした当人が、CI で踏んでいました。注意書きは実行されません。
観点 ID とテスト名を突き合わせたら、実装ごと無い機能が 2 つ出た。
検証観点には ID（F-013 のような）を振ってありました。ID がテスト名に現れるかを機械的に突き合わせるのは
1 コマンドでできるのに、提出直前まで一度もやっていませんでした。やってみたら 20 個の ID がテスト名に無く、
うち 2 件は実装そのものが存在しませんでした。
| 見つかったもの | なぜ誰も気づかなかったか |
|---|---|
| タグ統合機能の API が無い | 前提の 2 関数が入らないまま並列フェーズが終了。計画には「未了なら合流フェーズへ」とあったが、拾われなかった。画面には「準備中です」の無効ボタンが残っていた |
| 管理者向け API に累計ポイントが含まれない | ある計画が「隣の Step の担当」と申し送り、隣は API を作ったがその項目を含めなかった。2 つの計画の隙間に落ちた |
どちらも全テストが緑で、画面も普通に動いていました。
計画ファイルの「状態: 完了」という見出しは、実装された証拠になりません。
3.2 AI は「調べる範囲」を勝手には広げてくれない
メールが届かない問題で、AI の仮説は 3 つとも外れました（送信ドメイン認証／本文の URL／宛先の大文字小文字）。
そこで送信元・宛先・経路を固定して本文だけ変える比較実験に切り替え、
「リンク先が特定のドメインのときだけ届かない」という結論に到達しました。実験としては綺麗です。
そしてこの結論も間違っていました。 後日探し直したら、3 通とも迷惑メールフォルダに入っていました。
なぜ気づかなかったか。「届かない」を調べるあいだ、受信箱しか見ていなかったからです。
探す場所が最初から狭かったので、どれだけ仮説を精緻にしても正解には届きません。
変数を丁寧に分離した実験をしていたぶん、「実験は正しいのだから結論も正しい」と思い込みやすくもありました。
観測が正しいときほど、観測していない場所を疑う必要がある。
3.3 人間が実際にやったこと
-
要件をどう解釈するかの決定。 運営の手順書には「S3 の静的ウェブサイトホスティング」とありましたが、
必須要件「Block Public Access を外さない」と衝突するので、CloudFront + OAC を選びました。
AI は「書いてあるとおりに作る」ほうに倒れがちです - 「つながりを見せる」を中心に据え、ランキングを作らないという設計思想の決定
- 計画の差し戻しの最終判断と、「直さないと決めたもの」の線引き
- AI が「できた」と言ったものを疑うこと
最後が一番重要でした。AI は嘘をつくというより、「テストが緑である」という真の命題を「動いている」という別の命題に
置き換えて報告します。 本人に悪意はなく、区別もしていません。その置き換えを検出する仕掛けを作ることが、人間側の仕事でした。
4. 時間とコストの実態
作業時間の目安は 8 時間でした。Claude Code のセッションログ（23 本・応答 6,881 ターン）と git 履歴から実態を出しました。
4.1 8 時間で何ができて、残りは何に消えたか
AI が動いていた時間を「応答の間隔が 30 分未満ならひと続き」として合計すると 29.4 時間、目安の約 3.7 倍です。
| 日 | AI 稼働 | 主にやったこと |
|---|---|---|
| 9/5 | 7.5 h | ルール整理 → 要件定義 → 基本設計 → テスト観点 → Step 0〜3 実装 → Step 5〜8 を 4 セッション並列 |
| 9/6 | 10.5 h | 合流・E2E・本番スモーク → Should 機能 → 敵対的検証の UX 指摘を 6 並列で修正 → デザインルール導入 |
| 9/7〜8 | 3.7 h | デザイン移植 → 認証をマジックリンクからパスワードへ変更（要件変更） |
| 9/9〜13 | 7.6 h | UI 監査 → 間欠的に落ちるテストの原因特定 → メール調査 → 実画面テスト |
**8 時間の枠内（9/5 の 16:31、開始から 7 時間）で入っていたのは「ログイン・タイムライン・カード送信・スタンプ・
社内限定アクセスの実証・CI」**です。触って動く最小構成はここで揃っていました。
残り 21 時間は、ざっくり **3 分の 1 が「Must の残りを統合して本番で動かす」、3 分の 1 が「Should 機能と見た目」、
3 分の 1 が「検証で見つけた不具合の修正」**でした。
人間が打ったプロンプトは 110 回、中身は「承認・方針の決定」「環境作業の完了報告」「質問」「再開してください」の
4 種類です。自動化できなかったのは AWS ログインのブラウザ認証（7 回）、メール受信の確認、CI の環境変数登録、
社外からの疎通確認 —— すべて「手元の端末かブラウザか受信箱が要る」作業でした。
出力トークンは 8.5M、うち 48% が 9/5 の 1 日です。突出しているのは 9/5 の 19 時台の新規入力 6.66M で、
並列 4 セッションが設計書と計画ファイル（9 本・約 8,500 行）を別々に読み込んだためです。
4.2 分岐点は 9/5 の 14 時 16 分だった
14:16（人間） 現状の速度だと 17 時までに完了しなさそうなんですが、実装内容は変えずにスピードアップする方法はありますか？
14:20（AI） 結論から言うと、Must 全機能を今日中に終えるのは届きません。残りは実装だけで約 12 時間分です。
午前中に要件定義（285 行）・基本設計（539 行）・設計の敵対的検証（246 行）・テスト観点（840 行）と
合計 1,910 行を 2.5 時間で書き、その全部を 1 日で実装する計画にしていました。AI は正しく「届かない」と言っています。
問題は要件定義が詳細だったことではなく、詳細な要件の全部を 8 時間に入れようとしたことでした。
「実装内容は変えずに速くする方法」を聞いたのは人間で、スコープを削らなかったのも人間です。
詳細にやったこと自体には効果もありました。設計段階の敵対的検証で CORS と CSP の欠陥（2.2）を実装前に潰しています。
14:20 の時点で「Step 5〜8 は画面だけ作ってダミーデータを出す」に切り替える選択肢はあり、
「どこまで AI にやらせられるか」を試す目的では正しかったのですが、8 時間という枠に対しては間違いでした。
4.3 3 つの仮説を検証する
仮説 A：複数セッションを最初から計画に組み込んでいれば、もっと速かったか
効くが 1.5〜2 時間程度。それより空白時間のほうが大きかった。
並列は「途中から」ではなく、16:50 時点で 6 セッションが同時に動いていました。前倒しできたのは
カード送信に依存しない Step 7 を 12 時に始めることと、Step 4〜8 の計画を午前中に本体が書いておくことで、
合わせて 1.5〜2 時間です。一方で並列の実費もあります：同じ文書の重複読み込み（6.66M）、セッション間のコンフリクト、
計画と計画の隙間に落ちた機能 2 つ（3.1）、合流フェーズ 3 時間。並列は作業を消すのではなく、合流に移す面があります。
それより大きかったのが空白です。9/5 の 13 時台の AI 稼働がゼロ、17〜18 時台もほぼゼロ。
「Continue」「再開してください」のプロンプトから、セッションが人間の返答を待って止まっていたことが分かります。
8 時間のうち約 2 時間が人間待ちでした。並列を増やすほど全セッションが 1 人を待つので、
人間に聞かずに進めてよい範囲を先に決めることがセットで必要でした。
仮説 B：テストを後回しにしていれば、8 時間に収まったか
「後回し」ではなく「最小セットに絞る」が正しい。初日 2 時間、後日 4〜5 時間を節約できた。
| 領域 | ソース | テスト |
|---|---|---|
| backend | 12,605 行 | 13,885 行 |
| frontend | 9,075 行 | 8,633 行 |
| infra + shared + e2e | 1,812 行 | 4,397 行 |
| 合計 | 23,492 行 | 26,915 行（53%） |
テストコードがソースコードより多い状態です。最初の計画ファイルがテスト基盤で、Step 0〜3 の時点でテストが同梱されていました。
初日の実装時間の半分近くがテストで、約 2 時間分。書いた後の維持費も大きく、CI で落ちた 10 件、9/6 に追加した 170 件、
9/10 の間欠的失敗 2.4 時間（原因 3 つのうち 2 つはテスト側）で 4〜5 時間。ルールにも「テスト量やカバレッジは評価されない」とありました。
一方で、無しには進めないものもあります。E2E 1 本（画面が開くことの証明）、CDK テンプレートの検査と ESLint（要件の静的な証跡）、
認可の統合テスト（要件「他人のデータを書き換えられない」の証跡）、本番スモーク。
どれを、どの順で書くべきだったかは 5 章で役割別に評価します。単体テスト 409 件は、緑でも動かないことを 3 回証明しただけです。
仮説 C：カバレッジを上げる代わりに、AI に画面を触らせていたら
そのとおりだった。同じ日に両方やっていて、結果がはっきり分かれている。
9/6 の夕方、人間が画面を触って実装漏れに気づき、「カバレッジを上げる」ことで対応しようとしました。
その 1 時間半後に、AI に画面を触らせる敵対的検証を始めています。
| 時刻 | やったこと | 見つかった不具合 | |
|---|---|---|---|
| カバレッジ | 16:27〜17:12 | 170 件追加（分岐 backend 68→74%、frontend 63→85%） | 0 件 |
| 画面を触る | 17:25〜18:56 | 別モデルが実ブラウザで操作 | 修正ブランチ 6 本 |
その後も画面を触った検証は数字が出続け、UI 監査 16 件、実画面テスト 8 件、複数アカウント検証 5 件で 合計 30 件超。
170 件のテストが見つけた不具合は 0 件のまま、backend のテストを 562 件にして 9/10 の間欠的失敗（並列数過多でタイムアウト）を生みました。
理由は道具の性質です。カバレッジは「存在するコードが実行されたか」の指標で、存在しないコード＝実装漏れは原理的に検出できません。
画面を触る検証は「あるべき振る舞いがあるか」を見ます。 「人間が画面で気づいた」は「その種の不具合は画面でしか見つからない」という
シグナルで、正しい変換は人間がやったことを AI にやらせることでした。
5. 反省
テストが肥大化しすぎた —— 0 から 1 を作るとき、テストは何のためにあるか
原因は 2 つ。「実装とテストをセットで作る」を原則にした結果、AI は律儀にすべての関数に単体テストを付けたこと。
そして 9/6 に人間が「ユーザーが到達しうる経路は全部カバー」と指示して 170 件が追加されたこと。
ただ「量が多かった」で終わらせると、次も同じことをします。テストを同列に扱わず、それぞれがシステムの何を
チェックしていて、0 から 1 を作る局面で実際に機能したかで評価し直しました。
前提として、ハッカソンは 0 → 1 です。守るべき既存の振る舞いがありません。 通常のテストの最大の役割である
「回帰の防止」は、コードを書いている最中には意味を持ちません。0 → 1 でテストが果たせる役割は 3 つだけです：
要件の証跡、「動く」の存在証明、並列で動く AI の足場。回帰防止が意味を持ち始めるのは、
修正の波が始まった 9/6 の夕方からでした。
| 順位 | テスト | システムの何をチェックするか | 0 → 1 で機能したか |
|---|---|---|---|
| 1 | E2E 1 本（ログイン→送信→タイムライン） | ルート・ビルド・API 配線・DB が縦に 1 本つながっているか | 最も機能した。 1 本目でルート欠落を即検出。「動く」の唯一の存在証明 |
| 2 | CDK テンプレート検査 + ESLint | インフラ設定（Block Public Access、IAM *）と描画経路（innerHTML） |
完全に機能した。 静的なので書いた瞬間に効き、コストはほぼゼロ。計画レビューで「必ず失敗するテスト」2 件を止めたのもここ |
| 3 | 認可の統合テスト（テーブル駆動） | API の認可マトリクス。誰が何をできてはいけないか | 一番重要で、一番長く機能していなかった。 CI で skip、ヘルパーの不備で 403 の検査行に未到達。0 → 1 では一度も赤を見ていないテストは信用できない |
| 4 | 本番スモーク + 社外からの疎通確認 | デプロイ後の実環境の配線（CloudFront・API Gateway・IP 制限） | 機能したが、テスト自身が 2 回壊れた。初回デプロイでしか出ない問題（CORS、デプロイ順序）はここでしか見えない |
| 5 | 送信トランザクションの統合テスト | 中核の書き込みが原子的か。「同じ相手に 1 日 1 回」 | 中核ルールの仕様書として機能。不具合を止めた記録は無い |
| 6 | backend 単体（409 件） | 純粋関数（ポイント計算、日付キー、CIDR） | 足場としてだけ機能した。 並列フェーズで各セッションが唯一走らせられる層。品質の証明としては 0 件 |
| 7 | フロント部品（132 → 282 件） | 部品の振る舞い（jsdom） | 132 件緑で画面が開かなかった。価値が出たのは修正の波が始まってから：敵対的検証の提案に従って右カラムに累計ポイントを出した修正を、要件違反として止めた（E-02） |
| 8 | カバレッジ +170 件 | 既存コードの実行率 | 機能しなかった。 発見 0 件、562 件に膨れて間欠的失敗を生んだ。存在しないコードは測れない |
この順位で見ると、取り組む順番は実際とは逆です。実際は「テスト基盤と単体テスト（6）」を最初の計画にし、
E2E（1）は 2 日目、本番スモーク（4）も 2 日目、部品（7）と カバレッジ（8）に 2 日目の夕方を使いました。
0 → 1 で最初に要るのは、動くことの存在証明（1）と静的な証跡（2）で、これは最初の 1 時間に入ります。
認可（3）は認証ができた時点で書き、一度わざと赤にして CI で走ることを確認する。
ここまでで AI の作業時間はおよそ 2 時間で、実際に 9/5 に単体テストへ使った 2 時間と同じです。
8 時間に収まるのは 1〜5 まで。 6 は並列フェーズを組むなら、ポイント計算のルール関数だけ最小で書きます。
7 は修正の波（8 時間の外）が始まってから、8 は書きません。
「テストを書く」と「検証する」は別のことで、AI は前者を無限にやってくれるので、
後者に効くものだけを、この順で人間が指定する必要がありました。
デザインは直したい箇所が多いが、どう直せばよいか分からなかった
フロントの経験が浅く、「何が悪いか」は分かっても「どう直すか」を指示できませんでした。
結局、別のツールでデザイン参照を作って持ち込み、AI に 7 段階で移植させています。
効いたのはデザインルールを Markdown にして AI に守らせたことです。「センスで直す」ではなく「ルールとの差分を直す」に変えると、
フロントの経験がなくても判断できます。次は既製の UI キットを初日に採用して、その上にルール文書を載せます。
AWS CLI のセッションが短すぎた
「AWS ログインをお願いします」というプロンプトが 7 回残っています。ブラウザのコンソールセッションに紐づく方式で
数分で失効し、cdk deploy が合成まで通ったあと「アカウントを解決できない」で落ちる。
対策は、書き込み操作の直前に必ず aws sts get-caller-identity を実行することと、ログインしたらデプロイと検証を一気に流すことの 2 つ。
ログイン自体は最初「AI からは実行できない」と結論づけましたが、バックグラウンド実行なら起動できました
（2 通り試して駄目だったことを「できない」と一般化した、という別の反省があります）。
AI にやらせる範囲を広げるほど、残った人間の作業がボトルネックになります。
6. 実務に活かすなら
6.1 8 時間に収めるには
| 時間 | やること | 今回との違い |
|---|---|---|
| 0:00〜1:00 | ルールの整理と、Must を「縦に 1 本通る最小構成」に絞る | Must 全部を初日に入れる計画にした（4.2） |
| 1:00〜1:30 | 画面のモックを先に作り、画面遷移と「ここで何が起きるか」を決める | 文章の要件定義に 2.5 時間 |
| 1:30〜2:00 | E2E の骨組み 1 本と、CDK 検査・ESLint を先に置く（5 章の順位 1・2） | テスト基盤と単体テストを最初の計画にした |
| 2:00〜5:30 | 縦 1 本を実装。認証ができた時点で認可の統合テストを書き、一度赤にする（順位 3）。依存のない Step と後続の計画作成は並列で先に | Step 7 と計画 4〜8 を 16:49 まで待たせた |
| 5:30〜7:00 | 残りの Must を並列実装 | 同じ |
| 7:00〜7:30 | 合流、E2E 1 本、デプロイ | 翌日午前 3 時間 |
| 7:30〜8:00 | AI に画面を触らせる | 2 日目の夕方から |
これに「人間に聞かずに進めてよい範囲を最初に決める」と「認証は最初からメール + パスワード」を足します。
この条件なら、Must の統合・本番デプロイ・E2E 緑まで 8 時間で届いたと見ています。推定であって実測ではありませんが、
削るのが「要件外のテスト」と「人間待ちの空白」なので、成果物の質は落ちません。
6.2 普段の AI 開発を効率よく進めるには
モックを最優先にする。文章の要件定義より先に
文章だけで「想定した機能が全部あるか」を確かめるのは、人間にも AI にも無理でした。
1,910 行の文書を書き、計画に「状態: 完了」と付けて、それでも機能が 2 つ存在しませんでした。
画面には「準備中です」の無効ボタンが残っていたので、モックがあれば初日に見えていたものです。
UI 監査の 16 件もほぼ「説明文と実際の挙動が違う」で、モックで「この画面でこのボタンを押すとこうなる」まで決めてあれば、
構造的に起きません。
実務では複数人でイメージを共有する必要があるので、この差はさらに広がります。1 人でも 2 件抜けたのです。
- 本当に簡易なもので構わないので、画面のモックを先に作る
- 画面遷移まで表現する。 モバイルで「情報開示の画面に到達する導線が無い」（UI 監査の 1 件）は、遷移図があれば出ない
- 「この操作でこれが起きる」まで詰める。 ここまで決まっていれば、AI への実装指示はモックへの参照で済む
要件定義書は、モックで決められないこと（データの制約、権限、非機能）だけを書くのが、AI に実装させる前提での分担だと思います。
検証と完了の定義
- リリース前の手動確認を AI のブラウザ操作に置き換える。 指示書は 1 回作れば使い回せる
- 完了の定義を「観点 ID がテスト名に現れ、CI で実行され、skip 件数が 0」にして、突き合わせを CI に入れる。 1 コマンドでできる
- 環境の摩擦（認証の失効、メール、手動デプロイ）を先に潰す。 AI では消えず、最後まで人間の作業として残る
おわりに
| 項目 | 数 |
|---|---|
| AI 稼働時間 | 29.4 h（目安 8 h） |
| 人間のプロンプト / AI の応答 | 110 回 / 6,881 ターン |
| 出力トークン | 8.5M |
| コミット | 84 |
| 計画ファイル | 9 本（約 8,500 行） |
| 判断記録 | 68 件 |
| ソース / テスト | 23,492 行 / 26,915 行 |
| 画面を触る検証で見つけた不具合 | 30 件超 |
| 人間が書いたコード | 0 行 |
AI に任せる範囲が広がるほど、人間が持つべきものは実装能力ではなく、「それは本当に確かめられたのか」を機械的に問い直す仕組みになっていきます。
今回いちばん役に立った道具が、賢いモデルではなく観点 ID とテスト名を突き合わせる 1 行のコマンドだったのは、その象徴でした。