この記事についてClaude（Anthropic）との共同編集により作成されました。
要約
- バイブコーディング全盛の今、「ノーコード不要論」を書こうとしていた
- しかし素人バイブコーディングはSQLインジェクション・APIキー流出・認可ガバガバ等のリスクを内包する
- ノーコードは触れる範囲が制限されるぶん「事故の上限」が低く、認証・権限の最低限を強制してくれる
- 「ノーコード vs AIコーディング」は生産性ではなく、技術力で線引きすべきで、中途半端なバイブコーディングが一番危ない
あるネタ帳に「ノーコードはバイブコーディング時代に意味があるのか」というメモを書いていた。
書こうとしていた内容は大体こうだ。「Lovable や Bolt.new で自然言語からアプリが作れるようになった今、ノーコードの存在意義はほぼ消えた。コードという資産を残せるAIコーディングの圧勝。ノーコードは百害あって一利なし」——そう書いて終わろうとしていた。
手が止まったのは、「じゃあ非エンジニアの社内DX担当者に、AIコーディングを使えと言うのか？」と考えたときだった。
「ノーコードってもう意味なくない？」と書こうとしていた
まず元の否定論から整理する。ノーコードが抱える構造的な問題は本物だ。
ベンダーロックインがとりわけ深刻だ。一度ノーコードプラットフォームに乗ると、データも設定も独自形式に閉じ込められる。公正取引委員会の2022年調査では、自治体の98.9%が既存ベンダーとの再契約実績があり、約半数が「ベンダーのみがシステム詳細を把握していたため」と回答している^1。
可搬性がゼロという問題もある。ノーコードの成果物はプラットフォーム上の設定データに過ぎない。AIコーディングで生成したコードはGitで管理でき、別のエンジニアが引き継げる。ノーコードはそれができない。
エラー対応で結局エンジニアが必要になるというパターンも典型的だ。「非エンジニアでも作れる」が売り文句でも、アプリは必ずエラーを起こす。サーバーログが見えない、原因の切り分けができない、「作った人」がいなくなれば完全にブラックボックス——内製化したはずがベンダー依存、という矛盾が残る。
LLMコストのマージン問題も見逃せない。ノーコードサービスのAI機能は、OpenAIやAnthropicのAPIを呼んでいるに過ぎない。ユーザーはLLM利用料の上にプラットフォームのマージンを乗せて払い、使用モデルの選定もプロンプト最適化も自社でコントロールできない。
これだけ並べると「ノーコード不要論」は説得力がある。
しかし、書いていて手が止まった
「AIコーディングがあればコードという資産が残る。ノーコードを選ぶ合理的な理由はない」——その通りだと思いながら、ふと想定読者を変えてみた。
想定読者が「現場をよく知っている非エンジニアの経理担当者が、部署の申請フローをアプリにしたい」という人だったとき、私は本当にAIコーディングを勧めるだろうか。
そこで気になり始めたのが、素人バイブコーディングのセキュリティリスクだ。
素人バイブコーディングが踏みやすい地雷
Lovable や Bolt.new はたしかに「自然言語でアプリが作れる」。動く。見た目もいい。でも、セキュリティ要件を明示的に指定しないと、AIは「安全なコード」より「動くコード」を出す傾向がある。
具体的に何が起きるか。
APIキーのハードコードは頻出だ。「APIに接続したい」と頼むと、キーをフロントエンドのコードに直書きした状態で返ってくることがある。それをそのままGitHubにpushすれば、キーは即座に公開される。実際に数分でbotがスキャンして悪用するケースが報告されている^2。
認可の抜けも起きやすい。認証（ログインできるか）と認可（何ができるか）は別物だが、素人が「ログイン機能をつけて」と頼むだけでは認可ロジックが実装されないことがある。/admin のルートに、ログインしていればロールに関係なく誰でもアクセスできる状態になる。
SQLインジェクションは古典的だが、AIが生成したコードにも入り込む。ORMを使わず生のクエリを組み立てる実装をAIが選んだ場合、入力値のサニタイズが甘いと攻撃の入口になる。
CORS全許可・Cookieの設定不備も地味に多い。Access-Control-Allow-Origin: * のまま、HttpOnly も Secure も未設定でCookieを発行する——これを「動くから」で本番に出す。
AIは「このコードのセキュリティ上の問題は何か？」と聞けばOWASP Top 10^3 に沿って指摘してくれる。でも、それを聞かなければ指摘しない。素人は何を聞けばいいかを知らない。
ノーコードが構造的に提供している”安全柵”
ここでノーコードを見直すと、別の側面が浮かぶ。
ノーコードプラットフォームは、触れる範囲を構造的に制限する。これは自由度の低さとして批判されるが、裏を返せば「事故の上限が低い」ということでもある。
認証・認可の枠組みはプラットフォーム側で完成している。SSOやMFA、ロール管理は用意されており、非エンジニアが認可ロジックをゼロから実装する必要がない。というより、できない。ここに素人実装の地雷は存在しない。
データベースアクセスは抽象化されており、SQLを直接書く余地がない。テーブルの操作はUIを通じて行う設計になっているため、SQLインジェクションは原理的に起きにくい。
監査ログ・バックアップ・通信の暗号化は標準装備だ。エンタープライズ向けのノーコードツールはSSO・DLP・監査ログ管理を備えている。これをコードベースのアプリで自前で実装しようとすると、相応の設計コストがかかる。
もちろん、セキュリティの根幹をベンダーに委ねる、という構造的リスクは残る。それは否定しない。ただ、「ベンダーが管理するセキュリティ」と「素人が書いたセキュリティ」を比べたとき、確率的にどちらが安全かという話でもある。
整理：「技術力」で線を引くのが正しい
結局、問いの立て方が間違っていた。
「ノーコード vs AIコーディング」は生産性の比較ではなく、誰が触るかで判断すべきだった。
| 使う人 | 向いている選択 | 理由 |
|---|---|---|
| 技術力がある個人・開発組織 | AIコーディング | コード資産、カスタマイズ、コスト最適化 |
| 完全な非エンジニア・社内業務の簡易アプリ | ノーコード | 事故上限の制御、認証・認可の標準装備 |
| 「AIに書かせれば動く」と思っている中間層 | どちらも危険 | セキュリティ要件を知らないまま本番投入するリスクが最大 |
一番危ないのは中間層だ。自分で「ある程度わかってる」と思っている、でも実はセキュリティの要件設計を知らない人間が、「AIが書いたから大丈夫だろう」と本番に出す状況。
その意味で、バイブコーディングが普及するほど、「動く」と「安全」の乖離が広がるリスクも上がる。AIは動くコードを出すが、セキュリティ要件を指定するのは人間の仕事だ。それができない人には、触れる範囲が制限されたノーコードのほうが、事故の規模を抑えられる。
まとめ
「ノーコードは百害あって一利なし」というのは、技術力のある人間の視点で正しい。
でも、完全な非エンジニアが社内向けの小規模アプリを作る場合に限れば、ノーコードの”一利”は「事故の上限が低いこと」だ。認証・認可の標準装備、SQLに直接触れない構造、監査ログの自動取得——これはAIコーディングでは構造的に再現しにくい性質だ（実装すれば再現できるが、それができる人はそもそも技術力がある）。
AI時代のノーコード選択の判断軸は「生産性」ではなく、「自分が安全なコードを書けるかどうか」だと思う。
バイブコーディングが広がるほど、「動くアプリ」は増える。「安全なアプリ」が増えるかは別の話だ。
参考文献
- 公正取引委員会「デジタル化と競争政策に関する調査報告書（自治体のベンダーロックインに関する調査）」(2022年) https://www.jftc.go.jp/houdou/pressrelease/2022/dec/221207.html
- GitGuardian “State of Secrets Sprawl 2024” — GitHubに公開されたシークレットはbot経由で数分以内にスキャンされるという調査 https://www.gitguardian.com/state-of-secrets-sprawl
- OWASP Top 10 (2021) https://owasp.org/www-project-top-ten/