結論：一人でも作れる。ただし、丸投げはできない
仕様を小さく分け、正本を一つにし、実装とレビューを分離し、自動検証を通せば、一人でもAIを使ってWebサービスを開発できます。AIは作業を大きく担えますが、誰の問題を解くか、何を公開するか、どのリスクを受け入れるかは人が決めます。私の考え方は『作業はAI 8、人 2でも、責任は人が100』です。
| 目的・優先順位を決める | 人が担当誰のどの問題を解くか、今回は何を作らないかを決める |
|---|---|
| 調査・選択肢の整理 | AI＋人AIが候補と根拠を集め、人が一次情報を確認して選ぶ |
| 設計・実装・修正 | AI中心小さな単位で依頼し、変更理由と影響範囲を残す |
| コードレビュー | 別のAI＋人実装したAIとは役割を分け、仕様・安全性・既存機能への影響を確認する |
| ビルド・テスト | 自動検証＋人型、静的解析、テスト、プレビューを通し、主要操作は人も確認する |
| 本番公開・認証情報・課金 | 人が最終承認取り返しにくい操作と事業判断はAIへ委ねない |
複数AIを使う6つの手順
AIの数を増やす前に、同じ仕様を参照し、役割と完了条件を分けます。
STEP 1 目的と完成条件を一枚に書く
対象ユーザー、解決する問題、必要な機能、今回は作らない機能、完成の判定方法を短く書きます。AIへ最初に渡すのは長いアイデア集ではなく、判断に使える基準です。
STEP 2 正本を一つ決める
仕様、決定事項、未完了の作業を一つの文書またはリポジトリ内のファイルへ集めます。AIごとに別の説明を持たせると、更新のたびに内容がずれます。会話ではなく正本を引き継ぎます。
STEP 3 一回の変更を小さく分ける
認証、予約、通知、決済を同時に変更せず、一つずつ実装して確認します。変更範囲を小さくすると、AIが誤ったときに原因を戻って特定できます。
STEP 4 実装役とレビュー役を分ける
一つのAIに実装と自己採点を任せ切らず、別のAIまたは別の文脈で、仕様との一致、権限、入力値、エラー処理、既存機能への影響を確認します。多数決ではなく、役割を分けるための複数AIです。
STEP 5 機械的な検証を必ず通す
型チェック、静的解析、テスト、ビルド、デプロイプレビューを実行します。「動くはず」という説明を完了条件にしません。失敗した場合は、ログを基に原因と修正範囲を絞ります。
STEP 6 人が本番と事業判断を承認する
顧客データ、認証情報、課金、メール送信、データ削除、本番公開など影響の大きい操作は、人が対象と結果を確認します。作業量はAI中心でも、公開後の責任は人が持ちます。
実際にこの方法で作っているもの
企画、設計、実装、改善を一人でつなぎ、AIを工程ごとの実働として使っています。
| Hanami Nail | 多言語プラットフォーム訪日客向けのサロン検索と相談導線。公開情報をAIが理解しやすい構造も設計 |
|---|---|
| MUSUBU | LINE×AI予約SaaS問い合わせ受付から予約確定までを、LINEと予約データにつなぐ |
| MotenasuOS | 宿泊施設向け運営システム予約、客室、顧客、ゲスト対応を一つの業務動線にまとめる |
それぞれの技術構成と担当範囲は制作実績にまとめています。重要なのは、AIごとにプロジェクトを分断しないことです。顧客、予約、通知、認証といった事業全体の流れは、人が一つの設計として持ちます。
AIが書いたコードを安全に公開するために
AIが生成したコードも、人が書いたコードと同じようにレビューと検証が必要です。GitHubも、AIエージェントの回答とコードは利用者が確認し、要件への適合、エラー、セキュリティ上の問題を検証するよう案内しています。
最低限、認証情報をコードへ含めない、AIへ必要以上の権限を渡さない、変更は専用ブランチで行う、型チェック・静的解析・テスト・ビルドを通す、本番データの削除や課金は人が承認する、という境界を置きます。AIエージェントへ外部ツールを持たせる場合は、権限の過大付与や意図しない操作も確認します。
参考：GitHub「Responsible use of Copilot agents」／OWASP「AI Agent Security Cheat Sheet」
よくある失敗
複数AIへ同じ曖昧な依頼を投げる
回答数は増えますが、判断基準がなければ比較できません。先に完成条件を決め、調査、実装、レビューの役割を分けます。
会話だけでプロジェクトを引き継ぐ
チャットが長くなるほど、古い方針と新しい方針が混ざります。現在の仕様と未完了事項を正本へ更新し、次のAIはそこから開始します。
一度に大きな変更をさせる
多数の画面やデータベースを同時に変更すると、問題が起きた場所を特定しにくくなります。一変更、一検証、一記録の単位を守ります。
AIのレビューだけで安全だと思う
別のAIによるレビューは見落としを減らす補助ですが、正しさの保証ではありません。自動テスト、権限確認、実際の操作、本番データの保護を組み合わせます。
よくある質問
一人でもAIを使ってWebサービスを開発できますか？
範囲を小さく分け、仕様の正本、バージョン管理、自動テスト、レビュー、本番公開の承認手順を持てば可能です。ただし、AIへすべてを丸投げするのではなく、人が目的、優先順位、最終判断を担当します。
複数のAIを使うメリットは何ですか？
同じ質問への多数決ではなく、調査、実装、レビューなど役割を分けられることです。実装した文脈から離れて確認することで、仕様漏れや安全上の問題に気づきやすくなります。
どのAIを選べばよいですか？
モデル名だけで決めず、必要な作業、扱える情報、外部サービスへの接続権限、費用、記録の残し方で選びます。プロジェクト全体の正本と検証手順は、使用するAIが変わっても維持します。
AIが書いたコードはそのまま公開できますか？
そのまま公開すべきではありません。型チェック、静的解析、テスト、ビルド、権限と認証情報の確認を行い、影響の大きい変更は人が確認します。生成元に関係なく、公開するコードへの責任は公開者が持ちます。
AI中心の開発で最も重要なものは何ですか？
現在の仕様と決定事項をまとめた正本、変更を小さく区切ること、検証結果を完了条件にすることです。AIの数を増やすこと自体が品質を上げるわけではありません。
アイデアを、動く仕組みにします
事業の目的から整理し、必要なWebサイト、管理画面、予約、通知、AI連携を一つの流れとして設計します。企画から実装、公開後の改善まで通して担当します。
LINE で相談する