【現実】生成AIで非エンジニアはどこまでプログラミングできるのか？

【現実】生成AIで非エンジニアはどこまでプログラミングできるのか？

本記事で解決できること

• 生成AIでアプリ開発が「途中で止まる理由」がわかる
• 市民開発・ノーコードが失敗する構造を理解できる
• AIを“魔法”ではなく“道具”として使うための前提が整理できる
• PoCと本番開発を切り分ける具体的な進め方が分かる

"Program testing can be used to show the presence of bugs, but never to show their absence!"
（テストでバグは存在を示せるが、不在は証明できない）
― エドガー・W・ダイクストラ（Edsger W. Dijkstra）

はじめに：なぜ「作れるのに、続かない」のか

最近よく、「AIを使えば、非エンジニアでもアプリが作れる」という言説を目にします。これは本当なのでしょうか？

結論から言うと、これは事実であり、同時に危険な誤解でもあります。

実際に私自身が1人の個人開発者として生成AIを用いてアプリケーションを作ってみると、驚くほど簡単に「動くもの」はできます。したがって、この主張はある意味で正しいと言えます。いくつかプロンプトを与え、「ここはこういう風にしてほしい」と修正を依頼するだけで、1時間程度で最低限の機能を備えたアプリケーションが完成することも珍しくありません。

ここでいう「動くもの」とは、少なくとも自分の用途において一度は価値を発揮するプロダクトです。初めてアプリケーションが出来上がった瞬間の感動は、多くの人にとって忘れがたい成功体験となるでしょう。

しかし、生成AIを用いた開発を1か月ほど継続すると、多くの場合、ある種の「限界」に突き当たります。

なぜ、「作れる」のに「続かない」のでしょうか。そしてこの現象は、現場部門が業務アプリケーションを開発する、いわゆる市民開発の文脈において、どのような示唆を与えるのでしょうか。

AIは「成功体験」を量産する

まず押さえておきたいのは、生成AIのインパクトは単なる効率化ではないという点です。成功体験の民主化でもあるのです。すなわち、これまで開発経験のなかった人でも、「自分で作れた」、「動いた」、「役に立った」という感覚を、極めて低コストで得られるようになりました。これは非常に大きな変化です。

一方で、この成功体験はある種の錯覚も生みます。「このままいけば、もっと高度なものも作れるのではないか」という期待です。

この期待自体は自然なものですが、ここに最初の落とし穴があります。

なぜ生成AIでの開発は「1か月」で止まるのか

生成AIでの開発を始めて1か月ほど経った頃、多くの人が同じ悩みに直面します。その悩みはおおむね、「作りたいものが分からなくなる」「AIへの指示が曖昧になる」「生成されたコードや設定が理解できない」に集約されます。

これらは一見すると別々の問題です。しかし、実際には原因はひとつです。

生成AIは「言われたこと」を実装するのは得意です。しかし、何を解決すべきで、なぜそれを作るのか、そしてそのシステムがどんな構造であるべきかといった設計そのものをよしなに決めてくれるわけではありません。

同時に、多くの場合、人間側もその設計を明確に言語化できていません。結果として、意図と違う機能が実装され、修正が修正を呼び、構造が崩壊します。最終的に、「誰も触れないシステム」が出来上がってしまいます。

これは個人開発に限らず、企業のDXでもまったく同じです。

解決策は2つある──ただし、どちらも「コスト」がかかる

この停滞を突破する方法は、シンプルに2つしかありません。

① 高性能なAIで殴る

より賢いモデルを使えば、指示の解釈精度が上がり、設計っぽいこともある程度やってくれるようになります。その結果、試行錯誤の回数が減り、アプリケーションを作成するために必要な時間を短縮することができます。これは否定しようのない事実です。 しかしこれは、思考を外注しているだけであり、本質的な解決ではありません。コストも継続的に増えます。

② 自分が設計できるようになる

もう一つの方法は、より地味で、しかし決定的です。つまり、プログラミングの基礎を理解し、システムの構造を考え、問題を言語化する力を持つことです。これによって初めて、AIを正しく使う側に回れます。

ここで重要なのは、求められているのは「すべて自分で書ける能力」ではなく、あくまでAIに正しく指示できるレベルの理解が必要だということです。

DX・市民開発における示唆

ここまでは個人開発者を前提に議論してきました。しかし、この構造は、そのまま企業のDXにも当てはまります。企業における市民開発もまた、アプリ開発をより容易にするツール（ノーコード・ローコードか生成AIかを問わず）を用いて、自主的に行うという点において共通しているからです。

ノーコードを入れたが使われない。市民開発が一部で止まる。PoC止まりで終わる。

これらの原因は、ツールでも人材でもありません。設計が存在しないことが原因の場合がほとんどです。

企業にシステムを発注する時には要件定義が行われます。要件定義ほど精緻に仕様を固める必要はありませんが、簡単なExcel資料でもよいので、どのようなものを作るかをざっくりまとめておくとよいでしょう。簡単にまとめる作業を行うことで、どのような仕様にしたいかについてもある程度言語化されます。なお、その際にも生成AIを用いて壁打ちを行うとよいでしょう。

そして、設計が存在しない理由をさらに「なぜなぜ分析」すると、「WHY」の欠如に行きつきます。つまり、「WHYがない → 要件が定義できない → AIに指示できない」 という構図が浮き彫りになるのです。なお、なぜ「WHY」を考える必要があるのかについては、サイモン・シネックについて書いた以下のページを参照してください。

“Start with Why”とは何か？サイモン・シネックに学ぶ、DXプロジェクトの始め方 - イーストみんなのDX推進室

おすすめの進め方：PoCは生成AI、本番はSIer

ここまでを踏まえると、現実的な解は次の形になります。それは、PoC（概念実証）は生成AIやBaaSやノーコード・ローコードツールで内製し、本番システムはSIerに依頼するというものです。

FirebaseやSupabaseといったBaaS (Backend as a Service)や生成AIやノーコード・ローコードツールを使えば、画面、データ構造、処理フロー、ユーザー操作を実物として素早く可視化できます。

PoCの目的は「完成品を作ること」ではなく、 何を作るべきかを決めることです。このフェーズで生成AIは非常に強力な武器になります。

一方で、セキュリティや運用・保守、組織的な責任分界が求められる本番システムは、やはり専門家の仕事です。

PoCで設計の輪郭が見えていれば、SIerとの要件定義もスムーズになり、手戻りが減り、見積もりが現実的になり、発注者とSIerが対立しにくくなるというメリットも生まれます。

結論：AIは“入口”しか救わない

生成AIは、「作る」という行為のハードルを劇的に下げました。

しかし同時に、「設計できない問題」を可視化したとも言えます。

AIは書くことはできますが、設計は得意ではありません。

この前提に立てるかどうかが、個人開発においても企業DXにおいても分水嶺になります。

よくある質問（FAQ）

Q. 非エンジニアでも生成AIで業務アプリは作れますか？
A. 簡単な業務改善レベルなら作れます。しかし、使い続けるシステムには設計理解が不可欠です。

Q. ノーコードや市民開発は失敗しやすいのですか？
A. ツール自体ではなく、設計不在のまま進めると失敗します。

Q. DXがPoC止まりになる理由は何ですか？
A. 実装に注目しすぎて、問題定義と設計が曖昧なままだからです。SIerに発注する場合と同様に、AIを使う場合も、ある程度の要件定義は必要です。

おわりに

「生成AIでアプリは作れるのか？」という問いへの答えはシンプルです。

• お試しなら作れる
• 使い続けるものを作るなら、設計から逃げられない

だからこそ、 PoCは生成AI、本番はSIerという分業こそが、生成AI時代の現実解なのだと思います。

筆者：W.S.

ITガバナンスおよび市民開発推進を得意領域とするコンサルタント。中堅〜大手企業のIT統制設計・DX推進支援に従事。
個人開発者としてJavaScriptおよびFirebaseを用いたWebアプリ開発にも取り組み、開発現場と統治設計の両面からDXを研究している。
同志社大学大学院経済学研究科博士後期課程修了単位取得退学。

＼今なら無料！／

【30分DX無料相談 実施中】

「業務を効率化したいけれど、どこから手をつければいいかわからない…」「どのツールが自社に合っているのか、比較検討したい…」「市民開発をどのように推進すればよいか、専門家の意見を聞きたい…」

そんな悩みに、経験豊富なDX推進コンサルタントが個別に対応！

→ お申込みはこちら：https://www.qloba.com/forms/10862?_gl=1*1iahbda*_g...