1週間で作り、3週間で磨くAI開発

AIツールやコード生成機能を活用すると、これまで数週間を要していたプロトタイプがわずか数日で手元で動き始めます。私たちが最初にこのスピード感を体験したとき、「開発期間全体がそのまま短縮され、一気にプロダクトが完成するのではないか」と期待しました。

しかし、実際のプロジェクト現場で起きたのは全く別の現実でした。短縮されたのは「アイデアが目に見える形（プロトタイプ）になるまでの時間」だけだったのです。

プロトタイプに本番相当のテストデータを流し込んだ瞬間、入力データの揺れ、想定外のエラー例外、複雑なユーザー権限、APIのレスポンス遅延、UI上の説明不足といった課題が一気に噴出しました。動くものが即座に作れるようになったからこそ、本当の意味での「プロダクトづくり」の工程の多くが、最初のコード実装の後に残されていることがより鮮明になったのです。

そこで私たちが現在実践しているのが、「最初の1週間で骨組みを作り、続く3週間で徹底的に磨き上げる」という時間配分です。これは形式的な固定スケジュールではなく、試作の速さに目を奪われて早急な本番公開を急ぎ、失敗することを防ぐための思考フレームワークです。

試作品とプロダクトでは、向き合う問いが全く異なる

プロトタイピングの段階と、実際にユーザーが業務で利用するプロダクトの段階では、検証すべき焦点が大きく異なります。

試作段階で作ったハードコードやショートカット（近道）を残したまま安易に機能を増やしてしまうと、その近道自体が本番稼働時の複雑な技術的負債へと化けてしまいます。開発段階が進むごとに、「何をプロダクトに残し」「何を作り直し」「何を潔く捨てるか」を冷徹に判断する必要があります。

最初のプロトタイプをいかに速く作れるかよりも、リリース後にどれだけスムーズに改善を回し続けられるかの方が、プロダクトの真の競争力になります。

【1週目】価値の核心（コア体験）だけを愚直に動かす

1週目のゴールは、対象ユーザーを「たった一人」、解決する課題を「たった一つ」、成功の基準を「たった一つ」にまで絞り込むことです。詳細な画面設計書や仕様書を作り込む前に、まずは主要な体験フローを端から端まで一気通貫で動く状態にします。

このフェーズで検証したいのは、実装した機能の数ではありません。「利用する前に比べて意思決定が速くなったか」「面倒なデータ変換の手間が消えたか」「必要な情報に迷わず到達できたか」という、ユーザーの行動や感情の実質的な変化です。

テストには、都合のよいダミーデータではなく、少量であっても本物の現場データを使用します。生成AIの出力結果だけを見て満足するのではなく、ユーザーの入力、データの参照、DBへの保存までの全行程を通し、未実装の部分や既知の制約事項は目に見える場所に明記しておきます。

もしこの時点で期待した価値が確認できなければ、機能を足して誤魔化すのではなく、前提となる仮説そのものを修正します。開発速度が上がったからこそ、作ったものを捨てる判断も素早く行えるのです。

【2週目】マニュアルなしで、実際のユーザーに使ってもらう

2週目は、開発者自身と実際のターゲットユーザーが毎日プロダクトを使い倒し、操作が止まった場所や迷ったポイントを愚直に記録していきます。

「説明を受けないと押せない操作ボタン」「別の画面から手動でコピー＆ペーストしている情報」「AIの生成結果を待つ間の心理的ストレス」「出力を修正するためにかかる余計な手間」。ユーザーから寄せられた要望の数を単純に数えるのではなく、メインフローを阻害している「体験の摩擦（フリクション）」を徹底的に取り除いていきます。

AIがコーディングを強力にアシストしてくれる時代になっても、人間の観察眼と洞察が不要になるわけではありません。「観察された行動の事実」と「ユーザーが口にした要望」を明確に区別し、なぜそこで手が止まったのかの根本原因を追究します。安易に設定ボタンを増やすよりも、不要な入力項目や画面遷移自体を消し去る方が、はるかに体験を向上させることがよくあります。

このプロセスを経て、単なる「動くデモ」から「誰かの実際の仕事に組み込めるツール」へと深化していきます。

【3週目】発生したエラーや失敗を個別にモグラ叩きしない

3週目は、システムの脆弱性や例外処理をあえて浮き彫りにするテストを行います。空文字の入力、極端な長文、曖昧な指示、ユーザー権限の不足、外部APIの障害など、起こり得るトラブルを意図的に発生させます。

発見された不具合をその場の突貫工事（モグラ叩き）で直すのではなく、以下の表のようにエラーの「種類」ごとに分類し、共通の設計パターンとして解決していきます。

このように分類・抽象化して対策を講じることで、同種の原因から派生する複数のバグを単一の堅牢な設計で一括解決できます。また、システム側で自動解決できないエラーについては隠蔽せず、人間へスムーズにタスクを引き継ぐ仕様（ヒューマン・イン・ザ・ループ）として組み込みます。

【4週目】「システムが壊れた後」のリカバリー設計をつくる

本番運用において最も重要なのは、「絶対にエラーを起こさないこと」ではなく、「問題が起きた際に即座に検知し、安全に元の状態へ復元できること」です。利用状況、エラー発生率、AIの出力品質、APIコストを常時モニタリングし、障害が発生した際のアラート体制と復旧手順を構築します。

運用の担当者がエラーログを正しく解読できるか。緊急時に設定を変更できるか。バージョンを一つ前の正常な状態に戻せるか。開発者しか復旧作業を行えないようなブラックボックスな仕組みは、ユーザーが増えるほど開発チームの運用負担を爆発させます。

データの更新や削除といった重大な操作には二重の確認と権限チェックを設け、モデルや外部APIが一時停止してもユーザーのデータを消失させない設計を施します。さらに、ユーザーが日常的に行う修正やフィードバックが、そのまま次のAIモデルの評価やプロダクト改善へと自動的に還元されるループを構築します。

設計の重要性は減っていない。判断する「場所」が変わっただけ

生成AIによって実装スピードが飛躍的に向上したことで、すべての画面仕様やデータ構造を事前の企画段階で100%確定させる手法は、費用対効果が大きく低下しました。まずは動くプロトタイプを作り、実際の利用体験から学習する方がはるかに合理的です。

しかし、これは「設計という工程が不要になった」ことを意味しません。設計における意思決定のタイミングが、事前の一括策定から、「実装中」および「リリース後の運用プロセス」へと広く分散・移行したのだと捉えています。

仮説を短文で言語化し、最短のフローを構築し、自分たちとターゲットユーザーで使い倒す。そこで観察された生の事実から、次に解決すべき本質的な課題を選び取る。この泥臭い往復運動こそが現代のプロダクト設計です。企画書を簡略化することと、設計の判断を放棄することは全く意味が異なります。

スピードを求めるあまり、チーム作業を無秩序に並列化しない

複数のAIエージェントや開発メンバーに同時に作業を割り振ると、局所的なコード作成スピードは上がります。しかしその反面、それらの成果物を一つに統合する人間のレビュー負荷は跳ね上がります。個々が異なる前提で画面デザインやデータ構造を変更してしまうと、結果として手戻りと調整のために膨大な時間を失うことになります。

作業を並列化してよいのは、タスクの境界線と検証方法が明確に定義されている領域（技術調査、独立したモジュールテスト、アセットの最適化など）に限られます。プロダクトのコアとなるユーザー体験や、複雑に相互依存する仕様については、あえて作業ラインを絞り込み、シングルスレッドで集中して進めるべきです。

AIによって初期の実装コストがゼロに近づいたとしても、その後のシステム保守や意思決定にかかるコストが消えるわけではありません。だからこそ「何を作るか」という基準と同じくらい、「作らない機能（非機能）を決める基準」が極めて重要になります。ユーザーに使われない機能、コア価値に貢献しない自動化、運用コストが提供価値を上回る施策は、容赦なく保留または削減すべきです。

「1週間で作り、3週間で磨く」というアプローチは、あらゆる開発案件に機械的に当てはめる固定ルールではありません。プロトタイプが完成した瞬間の初期の興奮と、実際にユーザーが安心して使い続けられるプロダクトの状態を混同しないための健全な指針です。高速な試作によって仮説の確信を得たら、その後は実際の利用体験、例外処理、品質評価、システム復旧といった泥臭い工程へ丁寧に向き合う。そこまでやり抜いて初めて、プロトタイプは一時的なデモの域を脱し、人々の役に立つ本物のプロダクトへと昇華するのです。