AIで初めてWebサービスを作るロードマップ

初めてのWebサービス開発は、コードを書く前と公開した後を含めて設計します。順番は、問題定義、要件、試作品、実装、限定公開、本番運用判定、監視・復旧です。

対象は、AIコーディングを使って小さなWebサービスを初めて公開する人です。解く問題と利用者がまだ曖昧なら、先に「AIで何か作って」を課題へ変える方法を済ませてください。特定のフレームワーク（開発の土台）やホスティング（Web上で公開する環境）の設定手順、完成日数の保証は扱いません。

7工程の早見表

工程	作る成果物	終わったと判断する条件	AIに任せやすいこと
1. 問題定義	課題文、現状値、非対象	作る・作らないを比較できる	質問案、整理
2. 要件	フロー、データ、権限、受入条件（完成の判定基準）	テスト可能な文章になった	抜け漏れ候補
3. 試作品	最小の試作品	最大の不確実性を検証した	仮UI、使い捨てコード
4. 実装	テスト付きの小さな変更	受入条件を満たす	コード案、テスト案
5. 限定公開	少人数が使える版	フィードバックと運用負荷を確認した	ログ要約、課題の整理
6. 本番運用判定	公開チェックリスト	監視・保護・回復手段がある	チェックリスト照合
7. 運用・復旧	アラート、バックアップ、運用手順書	障害を検知し戻せる	調査補助、手順検索

1. 問題を決める

最初に、対象者、困りごと、現在の手順、現状値、今回扱わない範囲を1枚にします。GOV.UKのDiscovery（問題発見）ガイドは、サービスを作ると決める前に、問題、利用者、制約を理解するよう求めています。Discoveryの段階では、まだ構築を始めません。

小規模開発なら大きな調査期間は不要です。利用者への短い聞き取り、現在の画面や表計算、問い合わせ記録を確認し、作る価値があるかを決めます。

2. 要件をテストできる文章にする

画面一覧だけでは足りません。次を決めます。

誰が何をするか
正常経路と失敗時の経路
入力、処理、出力
保存するデータと保存しないデータ
閲覧、編集、管理の権限
完了と判定できる受入条件
運用責任者と問い合わせ先

そのまま使える型は小さなシステムの要件定義テンプレートにあります。

3. 試作品で最大の不確実性を試す

試作品の目的は完成品を早く作ることではありません。GOV.UKのAlpha（試作）ガイドは、失敗時の影響が大きい仮定から試す考え方を示しています。

たとえば「LLM（文章などを生成するAI）なら何とか分類できる」ではなく、次のように試します。

実際の入力に近く、機密を除いた例を用意する。件数はリスクと入力の分布から決める
誤分類すると困る例を先に含める
現行手順と同じ指標で比べる
合格、追加検証、中止の条件を決める

試作品のコードは本番品質とは限りません。認証、エラー処理、監視、アクセシビリティ（使える人を狭めない設計）、データ移行が未設計なら、そのまま公開しません。

4. 実装を小さな変更に分ける

一つの受入条件を、一つの変更単位へ近づけます。リポジトリは、コードと変更履歴をまとめて保管する場所です。AIへリポジトリ全体の書き換えを頼まず、変更対象、非対象、実行するテストを明記します。

実装中の履歴管理はAIコーディングを壊しにくくするGit入門を参照してください。AIが生成したコードも、人が差分を理解し、テスト結果を確認してから統合します。

5. 少人数で限定公開する

いきなり全利用者へ開きません。自分、関係者、招待利用者の順に広げます。確認するのは機能だけではありません。

問い合わせは誰へ届くか
失敗をログから見つけられるか
料金や処理時間が想定内か
誤操作を戻せるか
データ削除依頼へ対応できるか
担当者が不在でも止められるか

フィードバックは要望一覧にせず、元の課題と成功指標に戻して優先します。

6. 本番運用へ進む条件を確認する

GOV.UKのLive（本番運用）ガイドは、成功指標、情報保護、可用性、状態監視、性能・脆弱性テストを継続できる状態を挙げています。必要な強さは規模と被害リスクで変わりますが、小規模でも担当者と確認方法は必要です。

[ ] 成功指標と安全指標を見られる
[ ] エラーと異常利用を検知できる
[ ] 秘密情報を安全に管理している
[ ] 依存関係と脆弱性を更新できる
[ ] 問い合わせ・インシデントの連絡先がある
[ ] 旧版または代替手順へ戻せる
[ ] データをバックアップし、復元を試した

7. バックアップと復元を別々に確認する

バックアップの有無だけでは復旧準備を評価できません。NIST CSF 2.0は、バックアップを保護・保守・テストし、復元前後のデータが壊れていないか確認することを、望ましい成果として挙げています。

最低限、対象、頻度、保管場所、保持期間、復元担当、復元手順、最後のテスト日を記録します。データ移行がある場合は、アプリケーションの切り戻しとデータの復旧を分けて考えます。旧版との互換期間、roll-forward（修正版を適用して先へ進む方法）、バックアップからの復元のうち、システムに合う方法を公開前に試します。

AIを使う場所と使わない場所

AIは、調査候補、コード案、テストケース、文書、ログの整理を速められます。一方、次は責任者が決めます。

何を解くか
どのデータを渡せるか
何を合格とするか
誰が承認するか
いつ停止し、どう戻すか

工程別の詳しい確認

課題を定める：AI案件の課題定義
要件を一枚にする：小さなシステムの要件定義
変更を管理する：AIコーディングのGit入門
生成コードを確認する：AI生成コードのレビュー
LLM機能を測る：LLM機能の評価設計
ツール実行を守る：プロンプトインジェクション対策
入力データを選ぶ：生成AIへ入力する前の確認
方式を比較する：作る・買う・やめる判断表
運用を引き継ぐ：社内システムの棚卸し

7工程を一度回したら、公開後の測定と改善へ戻ります。公開して終わりにしないための一周です。