素人こそ「知りながら」作れ ― AIバイブコーディング時代の、安全な個人開発の作法

はじめに：誰でもアプリが作れる時代の、静かな不安

生成AIの性能が上がり、「バイブコーディング」――自然言語でAIに指示するだけでアプリが形になる開発スタイル――が広がりました。「IT素人の私が1週間でアプリを作りました」「100時間の仕事が5時間になりました」。こうした話は、もう珍しくありません。

その驚きは、本物です。素晴らしいことだと思います。

でも、私はこの流れに、いくつかの引っかかりを感じています。バイブコーディングによるブラックボックス化。情シスの管理外で増え続ける野良アプリ。そして、セキュリティ対策が実装されていない、あるいはそもそもセキュリティを設計すらしていないアプリが、世の中に静かに増えていくこと。

だからこそ私は、こう考えています。

この記事では、まずこの思想を、実際に現場で発信されている指摘と突き合わせながら掘り下げます。そして後半では、この思想を「今日から実際に手を動かせる形」――4つの懸念に対応したチェックリストと、完成後の設計書を自動で美しく残すHTMLテンプレート――に落とし込みます。

なお、本記事で触れる数字は、いずれも2026年10月時点で公開されている調査や分析を参照したものです。調査主体や時期によって数値には幅があるため、傾向をつかむ目安として読んでください。参照した記事のURLは末尾にまとめています。

私の不安は、作る側・守る側も同じことを言っていた

面白いのは、この素人としての不安が、プロのエンジニアやセキュリティ企業、受託開発の現場が鳴らしている警鐘と、ほぼ完全に一致していたことです。

ブラックボックス化は、数字でも裏づけられている。 あるコード分析サービスの調査では、AIの普及とともに、コードを整理し直す「リファクタリング」に関わる変更の割合が年々下がり、逆に「コピペ」の割合が上がっていると報告されています。「動いたコードをそのまま積む」が繰り返され、多くのプロジェクトが3ヶ月目あたりで壁にぶつかる。ファイルAを直したらファイルBが壊れる。でも、なぜ壊れたのかを説明できる人間がいない。私が恐れていた「何が行われているか分からない」状態は、こうして静かに技術的負債になります。

野良アプリは、時限爆弾と呼ばれていた。 非エンジニアが業務ツールを自作し、情シスの管理外で保守不能なアプリが増殖する。作った本人は異動する。引き継ぎドキュメントはない。でもそのツールに依存した業務フローだけが残る。ある日突然動かなくなって、誰も直せない。私の懸念そのものでした。

セキュリティは「動く」の裏に隠れている。 複数の調査で、AIが生成したコードのおよそ4割から6割に、何らかのセキュリティ上の欠陥が含まれると報告されています。「動く」と「安全」はまったく別の話なのですが、バイブコーディングのフローでは両者が区別されません。プロンプトを投げて、動いたらOK。セキュリティレビューが入る余地がない。あるエンジニアは、もっと厳しく言っています。「お前が作ったアプリで誰かのクレジットカード情報が漏れたとき、“AIが書いたコードだったので”は通用しない。法廷でも、SNSでも、自分の良心の前でも」。

私が素人として抱いた4つの不安は、妄想ではありませんでした。作る側も、守る側も、同じ場所を指差していたのです。

「全部を理解する」必要はない。「説明できる」ならいい

ただ、ここで一つ、自分の思想を修正する必要がありました。

「知りながら開発する」と言っても、素人がAIの吐くコードを一行残らず理解するのは非現実的です。ではどこまで分かればいいのか。あるエンジニアの記事に、繰り返し出てくるキーフレーズがヒントをくれました。それは「自分の言葉で説明できる」という基準です。

このアプリは、誰の、どんなデータを、どこに保存し、誰がアクセスできるのか。これを自分の言葉で説明できるか。それなら、素人でも判定できます。「知りながら開発する」の合格ラインは、行単位のコード理解ではなく、データとアクセスと責任の所在を自分の言葉で説明できること。ここに置けば、素人にも実行可能になります。

そして理解の矛先は、コードよりもデータ構造に向けるべきです。コードのバグは直せますが、データ構造の負債は、後から払うと利息がついて返ってきます。一度ユーザーデータが入ったテーブルの構造を後から変えるのは、新規に作るのとは比べ物にならないほど大変です。素人こそ、ここに力を注ぐべきです。

理解には穴がある。だから「賢く委ねる」

もう一つ、正直に認めるべきことがあります。人間の理解には、原理的に穴があるということです。

「知らないことを知らない」領域は必ず残ります。たとえばIDOR――URLのIDを一つずらすと他人のデータが見えてしまう脆弱性――は、存在自体を知らなければ「理解したつもり」で素通りします。だからこそ、理解を補う道具が要るのです。

あるエンジニアは「理解が浅いうちはクラウド（AWSなど）を生で触るな、LovableやBoltのような“安全側に倒した既定値”を持つツールに頼れ」と言います。これは私の思想と一見ぶつかりますが、むしろ補完します。賢い素人の戦略は「すべてを理解する」ではなく、「自分が説明できる範囲を誠実に持ち、説明できない範囲は安全な道具に賢く委ね、その境界線を常に自覚している」ことなのだと思います。

思想を、道具に変える

ここまでで、私の「知りながら開発する」という思想は、次の形に鍛えられました。

理解の合格ラインは「自分の言葉で説明できること」。矛先はコードよりデータ構造へ。要求水準は「捨てないもの・他人が使うもの・機微情報を扱うもの」に集中投下する。理解を強制する最小の習慣として「プロンプト前に3行仕様」。そして、理解の穴は安全な既定値と機械的検査で埋める。

でも、思想は道具にならなければ、ただの良い話で終わります。

そこで後半では、この思想を今日から実際に使えるものに変換します。具体的には、次の3つをお渡しします。

ひとつ。私の4つの懸念（ブラックボックス化／野良アプリ／セキュリティ未実装／セキュリティ未設計）それぞれに対応した、個人開発者向けチェックリスト。作るものの危険度で3レーンに分け、過剰な自己要求に陥らない設計にしてあります。

ふたつ。開発し終わったアプリの設計書を、1枚の美しいHTML（LP形式）として残すテンプレート。コードをそのままコピペして保存するだけで、未来の自分と引き継ぎ相手に「このアプリは何者か」を伝えられます。野良アプリ化の時限爆弾を外す決定打です。

みっつ。そのHTMLテンプレートを、AIに「完成したコードを読んで★部分を埋めて」と渡す使い方。設計書作成すら丸投げにならずに、しかも楽にする方法です。

ここから先は、実際の武器です。