非エンジニアがAIでWebアプリを作った話【実録】できたこと・できなかったこと

非エンジニアがAIコーディングツールを使って業務システムを作る——この半年、最も多く受けた「やってみたいが踏み出せない」という相談のテーマです。結論から言うと、動くデモは作れました。本番システムは別の話です。

自社でAI検索の観測ダッシュボードを実際に開発した記録をもとに、できたこと・やらかしたこと・できなかったことを正直に書きます。

何を作ったか：AI検索の観測ダッシュボード

自社で着手したのは、AI検索（ChatGPT・Gemini・Google AI Overviews）で自社ブランドや競合がどう言及されているかを観測するダッシュボードです。「AI検索に自社名が引用されるか」は最近の営業でよく聞かれるテーマで、いくつか競合サービスも調べた上で「まず自社で作って実際に使ってみる」方針を取りました。

アプリの要件はざっくり4画面です。

これを、HTMLとJavaScriptだけで作りました。

できたこと：フレームワークなしで4画面が動いた

AIコーディングツール（Claude Code）と相談しながら、Reactなどのフレームワークを使わずに静的SPAを組みました。ブラウザで開くだけで動く構成にしたのは意図的な選択です。ビルド環境の構築に詰まって立ち止まるリスクを最初から排除しました。

Phase 1として完成したもの：

• ブランド切替と時点切替でKPIが全画面連動して再計算される
• 施策の追加・推奨→実施中への登録・完了化が操作可能
• 設定画面でブランド・テーマ・競合をCRUDで管理できる
• データはlocalStorageに保存（サーバー不要）
• Vercelにデプロイして外部から参照できる状態

1週間かかりませんでした。AIがコードをほぼ全量書いてくれたため、私がやったことは要件の言語化とレビュー、バグ報告だけです。一人会社の営業をAIで仕組み化した記録でも書きましたが、「AIが量産、人間が検品」の分業はシステム開発でも同じ構造で機能します。

やらかしたこと：最初に作るものを間違えた

白状します。最初に作ったのはアプリ本体ではなく、営業用のLPでした。

「まず外に見せるページが要る」という思い込みで、LP・問い合わせフォーム・コラム付きの営業サイトを先に作り込みました。実際の正解は「アプリが先で、LPはその後」。着手段階でスコープを読み違えていました。

間違いに気づいたのは、アプリ画面の仕様を整理し始めてから。結果として、LPは凍結保管になりました（将来転用できる状態にはなっています）。

AIはどんなに高精度でも、「何を作るべきか」は判断しません。「LP作って」と指示すれば、AIは完成度の高いLPを作ります。方向が間違っていても止めてくれません。スコープの確認は、コードを書き始める前の最重要ステップです。 この教訓は、どの業務からAIを入れるかの診断と同じ問いです——作る前に「何を作るか」を固める工程は、ツール選定と同じくらい重要です。

できなかったこと：実際のデータは取れない

現状、このダッシュボードはサンプルデータで動いています。

本来の目的は「ChatGPTやGeminiに質問を投げ、その回答の中に自社ブランドが何回・どう言及されているかを日次で収集する」ことです。これには観測パイプライン（各AIのAPIにクエリを投げ、回答をパースし、言及有無を判定してデータベースに蓄積する）が必要で、この部分（Phase 2）は未着手です。

なぜできなかったか。2つ理由があります。

①仕様が未確定だった。クエリ設計（どの質問を・どの頻度で・何モデルに投げるか）、言及の判定基準（ブランド名が出れば言及か、文脈が必要か）、データの集計単位——これらを決めずにコーディングに入ると、作っては壊す繰り返しになります。AIはコードを書くのは速いですが、仕様の穴を埋めてはくれません。

②デモが動いた段階で一段落した。使ってみることで仕様が固まる部分があります。Phase 2はデモを実際に使いながら仕様を詰めてから着手する判断をしました。

「動くデモ」と「本番システム」の間には、仕様策定・データ設計・API連携の設計というエンジニアリング工程が横たわっています。AIはその工程を省いてはくれません。速くはしてくれます。

非エンジニアとAIの実際の分業

具体的に、私が何をしてAIが何をしたかを正直に分解します。

コードは一行も自分で書いていません。ただし、「どの画面に何の情報を出すか」「ボタンを押したら何が起きるか」は全部自分で考えました。 ここを怠ると、AIは「それっぽいもの」を大量に生成し続け、使えないシステムが積み上がります。

AIモデルの使い分け方でも触れましたが、AIを使いこなす上で一番重要なのはコードの知識ではなく「自分が何を欲しいかを言語化する力」です。これは業務設計と同じスキルです。

この手法が向かないケース

正直に書きます。以下に当てはまる場合は、非エンジニアによるAIコーディングより専門家への依頼を検討してください。

• 本番データを扱う：顧客データや売上データを保存するシステムは、認証・権限管理・セキュリティ設計が必要です。AIが生成したコードをレビューなしで本番に使うリスクは高い。
• 複数人が同時に使う：マルチユーザー・アクセス権限の設計は難易度が大きく上がります。
• 外部サービスとのAPI連携が多い：各サービスのAPI仕様の読解と実装はエンジニアスキルが前提です。

今回作ったのは「自社1人が使うサンプルデータのデモ」だから成立しました。本番化・マルチユーザー化するなら、設計からエンジニアが入る前提でのPhase 2です。

結論：AIでシステムは「速く」作れる。「正しく」作るのは設計力

この実録を通じて伝えたいのは、シンプルな1つのことです。AIは速くて正確なコーダーですが、設計者ではありません。 非エンジニアがAIを使うときに一番問われるのは、プログラミングの知識ではなく「作りたいものを仕様として言語化する力」です。

業務のどの部分を・どう変えたいかの整理から始めたい場合は、2週間のAI適用診断（現場同席・本番非接続）が入口になります。「方向性は決まっている、作るのを外に任せたい」という場合は、30分の無料相談で一緒に整理できます。

---

本記事の開発情報はすべて自社プロジェクト（AI検索観測ダッシュボードの開発実録、2026年7〜8月時点）の実測・実録です。

この記事で使ったAIコーディングツールの使いどころは、Claude Codeでできること25選に業務別のプロンプト例つきで整理しています。