エンジニア未経験の経営者がAIでWebサービスを本番運用するまで

つくったもの

作ったのは、IZNM（イザナミ）という、茅ヶ崎を中心にしたIDプラットフォームです。

QRコード付きのIDタグと、Webサービスの組み合わせでできています。

タグを読み取れば、いつでもどこでもプロフィールを共有できます。さらに、災害などもしもの時には、緊急連絡先にアクセスしてもらえる仕組みです。

防災機能付きのIDアクセサリという位置づけで、物理タグを買うとサービスが拡張される仕様にしました。

業務フローも自動化しました

作ったのはサービスだけではなく、製造から配送までの手作業も自動化しています。

刻印は、タグごとにQRとID番号が違うため、内容を1件ずつ設定していました。これに1件あたり15分かかっていました。

配送も、クリックポストに1件ずつ登録して購入していたため、1回の登録作業に5分ほどかかっていました。

いまはどちらも自動化し、体感では5分の1ほどの時間で処理できています。

製造から配送までをどう自動化したのかは、こちらの記事に詳しく書きました。

タイムライン

2026年3月10日ごろに着手し、4月上旬に公式リリースしてFOUNDERタグの販売を開始しました。5月にはフェーズ2の大きなアップデートを行い、それ以降も改修とアップデートを続けています。

着手からリリースまで約1ヶ月、実働20日でした。

ただ、この記事で伝えたいのは「AIなら1ヶ月で作れる」ということではありません。リリース後の実運用を通じて、AIの役割分担、承認方法、検証方法、開発ルール自体も継続的に見直してきたということです。

IZNMは、3段階でサービスを見直してきました

現在の形に至るまで、IZNMは大きく3段階でサービスを見直してきました。

最初は、茅ヶ崎に特化したイベント情報の地域メディアを2年続けました。ただ、情報の収集から公開までがすべて手作業で、運用負荷が高すぎました。

次に、地域掲示板と地域情報の発信を組み合わせたアプリを1年運営しました。イベントや注目情報などを運営側から発信しながら、地域の人も掲示板で情報を投稿・交換できる形です。プロモーションのためにYouTubeを立ち上げ、日々ライブ配信もしましたが、アプリのインストールハードルが高く、広がりませんでした。マネタイズも難しかったです。

そして2026年に、現在のWebアプリへ作り直しました。ここで初めて、地域情報や掲示板を中心にしたサービスから、人・店・イベントなどとのリアルな接点をQRで記録するサービスへ変えています。マネタイズは防災機能付きIDアクセサリの販売に置いています。

この変遷では、地域への価値、運用負荷、利用ハードル、マネタイズをそれぞれ見直してきました。

事業仮説をどう整理し直してきたのかは、別の記事にまとめています。

詳しくは → 新規事業の仮説は、「誰が・何を・どれだけ・いくら」まで書く

AIに「作らせる」のではなく「体制を組ませる」

ここが、この記事で一番伝えたいところです。

使ったツール

Claude（Chat）は、事業戦略・商品戦略・サービス戦略・マーケティング戦略の相談と、編集者としての役割。

Claude（Code）が開発の実行主体です。GitHub連携、ファイル同期、タスク管理、仕様書の作成と更新、実装、レビュー、検収。

Claude（Design）で、サイトのフロントデザインとUI/UXデザイン。

ChatGPT（Pro）は、画像の生成と編集、LP設計、編集者としての役割。Claudeの提案の質が低いときの比較・相談先として使いました。

ClaudeはMaxプランを契約しています。

4つの役割に分けました

AIに実装を任せる前に、まず役割を分けて開発体制を組みました。

Producerは、企画・要件整理・タスク起票・指示書作成・進行管理を担当し、私と話す唯一の窓口です。

Architectは、実コードの調査、影響範囲の分析、実装前の仕様書更新を担当します。

Reviewerは、実装前レビュー、実装後レビュー、実装後の仕様書更新を担当します。

Devは、指示書どおりの実装だけを担当し、指示外の変更は禁止しています。

Claude Codeのサブエージェントとして分離し、Producerが他を兼務することを禁止しました。

理由は、同じ役割の中で実装とレビューまで完結させると、前提の見落としや認識の偏りに気づきにくくなるからです。

これは15年、クライアント様の新規事業でご一緒してきた進め方と同じでした。進める役割とレビューする役割を分ける。AI相手でも、必要な理由はまったく変わりませんでした。

1タスクを10ステップに固定しました

起票、実コード調査、実装方針の策定と私の承認、仕様書の事前更新、実装前レビュー、指示書作成、実装、実装後レビュー、デプロイ後の検証と仕様書の事後更新、クローズ、という流れです。

6つのゲートすべてで、私の明示的な承認を挟みます。

そして「OK」「進めて」を複数ゲートの包括承認として扱うことも禁止しました。ここまで細かくしたのは、実運用の中で問題が出たためです。4つのステップを一括で進めた結果、UIや業務フローを十分に確認しないまま本番へ反映されたことがありました。

検証は機械で自動化します

GitHubと本番の全ファイル105件のMD5一致を確認するスクリプト。

本番の動作27項目を確認するスモークテスト。

どちらも全件PASSでなければ、タスクをクローズできません。

AIの提案は、そのまま採用せず確認する

今回の開発では、AIの提案をそのまま採用するのではなく、前提・影響範囲・実装結果を一つずつ確認してきました。

こちらから確認すると、AI側の認識違いだと分かることもあります。一方で、自分一人では気づけなかった重要な論点を指摘してくれることもあります。

そのため、必要に応じて複数のAIで比較し、片方の提案をもう片方に検証させることもあります。

重要なのは、AIを信用するか、しないかの二択ではなく、AIをどこに使い、どこを人が確認・判断するかを決めることです。

AIが具体的に何をできなかったかは、別の記事に8つ挙げています。 → AIで本番運用してわかった、できなかったこと8つ

多くの時間を使ったのは、コードよりもルール設計でした

実装そのもののエラーよりも、実装フローと実装ルールの設計に時間を使いました。

開発ルールを書いたファイルは、v7.1からv8.0まで何度も改訂しています。実運用で見つかった問題や認識のずれを、次のタスクで繰り返さないためです。

実際の運用で分かったことをルールへ戻し、次の実装に反映する。その積み重ねです。

こうしたルールは最初から完成させるのではなく、実運用に合わせて継続的に更新することが重要だと感じています。

そして、更新し続けているこのルールこそが、いま一番の資産だと思っています。

コードそのもの以上に、実運用を通じて蓄積した判断基準や再発防止のルールに価値があると考えています。

これから同じことをやる人へ

手順ではなく、判断の指針を4つ。

1. GitHubとの連携から始める

ドキュメントもコードも、AIが直接読み書きできる場所に置く。

ここを後回しにすると、あとで結局すべて移すことになります。私は最初Notionで管理していて、結局すべてGitHubに移しました。

2. 実装のフローとルール設計から入る

実装フローやルールを決めずに進めると、問題が起きるたびに進め方そのものを見直すことになります。

ただし最初から完成形を作る必要はありません。実運用で見つかった課題を反映しながら更新する前提で始めるのが現実的です。

3. 人に頼む線を、先に決める

法務、セキュリティ、UI/UX・LP・コピー。ここは最初から人に見てもらう前提で予算と時間を組んでください。

ここは、AIに任せきれなかった領域です。

4. AIの提案は、そのまま採用せず必ず自分で確認する

これが、私の中では最も重要です。

実際に使っていると、AIから前向きな提案が出ることもあれば、逆に強い懸念を示されることもあります。どちらも、そのまま正しいとは限りません。

何をするにしても、最終的な判断と責任は自分にあります。本当にポジでいいのか、ネガでいいのか、全体感と五感を働かせて総合的に判断する必要があります。

そのために、2つを必ず確認するようにしています。

判断を求めるときは、メリット・デメリットを整理し、推奨の理由まで提示してもらう。

判断が必要な事柄については、認識の齟齬がないよう、前提や選択肢をより具体的に提示してもらう。

まとめ

• エンジニア未経験でも、AIでWebサービスを本番運用まで持っていける。ただし「AIに任せる」ではなく「AIを運用する」
• やるべきは実装の指示ではなく、役割分離・承認ゲート・機械による検証の設計
• 最も価値のある資産の一つは、実運用を通じて更新してきた実装フローと判断ルール

15年、クライアント様の新規事業で「進める役割とレビューする役割は分けたほうがいい」とお伝えしてきました。

相手がAIになっても、必要な理由は一つも変わりませんでした。