4日でWebサービスを作れた理由
AIが消したのは
職種間の調整コストだった

画面を作るだけでなく、データが正しくつながる必要がある

公開したサイトには、商品一覧だけでなく、商品マスター、検索条件、価格取得、商品照合、価格履歴、集計、記事、スマートフォン表示がある。商品名が似ていても、言語、商品種別、販売単位が違えば別商品として扱う。在庫切れや価格未取得も状態として分ける。画面を作るだけでなく、データが正しくつながる必要がある。分類としては、静的なホームページより、小規模なWebシステムとメディアを組み合わせたものに近い。

実作業だけでなく、説明する時間が発生する

通常の外注では、企画、要件定義、UI設計、フロントエンド、データ処理、テスト、記事制作、公開管理を分担する。分担には専門性の利点がある一方、役割の間で情報を渡す必要がある。企画意図を仕様へ変え、デザインを実装へ説明し、完成物を検収し、修正理由を再び伝える。実作業だけでなく、他の人が正しく動けるように説明する時間が発生する。

違和感を見つけた本人が、その場で修正を依頼できる

一人＋AIの開発では、違和感を見つけた本人が、その場で修正を依頼できる。会議日程を調整し、チケットを作り、見積もりを待つ必要がない。修正後の画面を見て、さらに直す。この往復を一日に何度も行える。AIはコードを書く時間だけでなく、「次の担当者が着手するまでの時間」を消した。

完成像を短い往復で修正へ反映できる

今回、目的、優先順位、UIの違和感、商品条件、公開可否を同じ人が判断した。発注者と実装者の間で「なぜ必要なのか」を毎回説明し直さずに済む。頭の中にある完成像を、AIとの短い往復で修正へ反映できる。役割間の会議がなくなったことが、制作速度へ大きく効いた。

入口と出口の判断は残る

同じAIを使えば、誰でも同じ日数で作れるわけではない。何を作るか決める。商品データの不整合に気づく。画面の使いにくさを言語化する。規約上危ない処理を止める。完成報告をそのまま信じず、実物を確認する。AIが中間工程を埋めても、入口と出口の判断は残る。基礎知識と品質基準があるほど、修正回数を意味のある方向へ使える。

速く作れることと、正しく作れることは別である

トップページと商品ページで価格が違う。更新日がそろわない。似た商品を誤って最安値にする。スマートフォンで表示が崩れる。AI開発でも、こうした問題は起きる。短縮できた時間の一部を、データ整合性、リンク、表示、規約、例外処理の確認へ使う必要がある。

一作目で残るのは、完成したサイトだけではない

商品データの構造、API取得処理、照合ルール、デザイン、テスト、公開手順、失敗例が残る。次のサイトでは、これらを土台として使える。一度4日で作れたことより、次はさらに短く作れる仕組みが残ったことの方が大きい。

コードだけでなく、判断の理由を残す

短期制作を偶然で終わらせないために、次を保存する。

• 要件と完了条件
• データ構造
• デザインルール
• テスト項目
• 公開手順
• 失敗と修正理由
• 再利用可能な部品

コードだけでなく、判断の理由を残す。そうすれば、別ジャンルへ横展開する時にも同じ品質基準を持ち込める。

職種別の待ち行列へ渡さず、一つの判断ループで連続処理する

短期間で作れたと言うと、AIが数時間で完成品を吐き出したように見える。実際には、商品データ、外部API、価格履歴、商品照合、ガイド記事、テスト、公開作業など、複数種類の仕事があった。違ったのは、それらを職種別の待ち行列へ渡さず、一つの判断ループで連続処理できたことだ。

大きく削られたのは、手を動かす時間だけではない。「仕様を説明する」「担当者が空くまで待つ」「戻ってきた成果物の意図を再説明する」という調整時間である。企画者と実装者が同じ人で、AIがその場で草案を作ると、判断から修正までの距離が極端に短くなる。

一方で、四日という日数だけを切り取って再現しようとしてはいけない。扱う技術の基礎理解、過去に作った部品、明確な対象範囲、外部サービスの状態が揃っていたから成立した。未知の規制領域、大規模な個人情報、決済、複雑な権限管理が入れば、同じ速度を優先すべきではない。

量産速度ではなく、意味の検査をボトルネックとして意識する

AI開発では、速くできる工程と、時間をかけるべき工程を分ける必要がある。

AIがテストコードを書いても、検査対象が正しいとは限らない。画面が表示されても、価格比較の計算母集団が間違っていれば価値はない。ガイド記事が24本あっても、同じ説明を水増ししただけなら独自性は生まれない。量産速度ではなく、意味の検査をボトルネックとして意識する。

私は、変更のたびに最低限、主要導線、データ欠損、外部リンク、スマホ表示、秘密情報、戻し方を確認するようにした。短期開発の品質は、最後に長時間テストすることより、小さな変更ごとに壊れていないことを確かめる方が守りやすい。

速さを偶然ではなく改善可能な制作手順へ変える

四日で作った経験を一度の武勇伝にしないため、次の制作へ残すものを決める。

二作目が速くなる理由は、AIの性能向上だけではない。一作目で得た失敗、設計境界、検査項目を再利用できるからである。逆に、完成したコードだけを残し、なぜその設計にしたかを捨てると、次回も同じ確認をやり直す。

短期開発の本当の成果は、四日で一つ公開したことだけではない。「企画から公開までのどこに待ち時間があり、どの判断は人間に残すべきか」という制作システムを手に入れたことだ。AIが強くなるほど、この制作システムの差が、そのまま次の速度と品質の差になる。

四日間の後に、本当のコストが見える

公開までの速さだけを測ると、短期開発は成功に見えやすい。だが、外部APIの変更、商品データの欠損、検索流入の確認、記事の更新、問い合わせ対応は公開後に始まる。四日で作れても、その後に毎週十時間の手作業が必要なら、制作コストを運用へ移しただけである。

そのため、公開した週から修正時間を記録する。何が自動で回り、何を人間が確認し、どの障害が繰り返されたかを分類する。三回以上同じ確認が発生したら検査へ組み込み、判断が必要なものは手順と責任者を残す。短期開発の評価は、公開日だけでなく、一か月後に保守可能かまで含めて行う。

利用者の反応も、制作中の想像とは異なる。力を入れた比較機能より基礎ガイドが読まれる、想定していなかった検索語から来る、スマホでは重要な項目が見つけにくい、といったずれが出る。ここで機能を増やす前に、実際に使われた導線を直す。四日で公開できた利点は、完成を誇ることではなく、現実のデータへ早く到達できることにある。

一人開発でも、役割は頭の中で分ける

企画、実装、品質確認を一人で行うと、認識合わせは減るが、自分の思い込みを指摘する人も減る。そこで、同じ人が作業していても時間と観点を分ける。実装直後には公開判断をせず、翌日に利用者の導線だけを見る。AIにも、実装を手伝った会話とは別に、壊し方、誤解しやすい表示、規約上の懸念を探させる。

また、AIの出力を複数同時に進めると、レビュー待ちが積み上がる。画面、記事、テスト、設定が一斉に戻ってきても、人間が意味を確認できなければ完成ではない。一日の終わりに未確認の成果物を数え、翌日に処理できる数を超えたら新規生成を止める。この制限が、短期開発で品質を落とさないためのブレーキになる。

四日という速度は、すべての案件へ適用する目標ではない。小さな対象、戻せる変更、確認可能なデータ、再利用部品が揃ったときに初めて意味を持つ。条件を無視して日数だけをまねると、未確認の負債が後へ残る。

次に同じ速度を再現したいなら、作業時間だけでなく、迷った判断、待ち時間、手戻りの原因を記録する。AIが短縮した工程と、人間の確認で品質を守った工程を分けて残すことで、速さを偶然ではなく改善可能な制作手順へ変えられる。