「登録画面を作って」「検索機能を作って」。
生成AIに言葉で指示するだけで、数十分後には動くWebサービスができる時代になりました。
こうした開発は「バイブコーディング（Vibe Coding）」とも呼ばれ、IT部門だけでなく業務部門の市民開発としても広がっています。
ところが東洋経済オンラインなども指摘するように、動作は問題なくてもセキュリティが穴だらけ、というケースが増えています。
「AI活用」一辺倒で速度だけを追うと、日本企業の弱点が一気に露呈しやすいのです。
速さは強みです。ただし「確認」を同じ速度で増やさないと、動くサービスほど危険になります。
何が起きているのか
従来のシステム開発では、要件定義・設計・開発・レビュー・テストに時間をかけていました。
生成AIはそのうち「開発」の時間を劇的に短縮します。
一方で、人間がレビューやセキュリティ確認に使う時間まで同じ速度で短くなったわけではありません。
つまり、作る速度だけが数十倍になり、安全性を確かめる速度は従来のまま、という歪みが生まれています。
ここに、AI生成コード特有の抜け穴が重なります。
調査によっては、AI生成コードの相当数にセキュリティ上の欠陥が含まれる、開発速度がレビュー速度を上回っている、といった指摘もあります。
「動く」と「安全」は別物
生成AIは優秀なプログラマーです。
ただし目的は「要求どおり動くコードを書くこと」であり、人間が暗黙に求める「安全なコードを書くこと」とは一致しません。
報道や検証で繰り返し指摘されるのは、次のような問題です。
- 認証が弱い、または省略されている
- 管理画面が外部から見えてしまう
- APIキーや秘密情報がソースに埋まっている
- 権限管理が不十分なまま公開されている
- セキュリティ用ライブラリは入れたが、実際には有効化していない
共通点は、「なくてもアプリは動く」ことです。
画面は表示され、登録もでき、検索も動く。だからこそレビューが薄いと、穴が見逃されやすいのです。
AIは「必要な対策を知っている」のに、「最後まで適用しきる」ところにギャップがある、という指摘もあります。
たとえば対策パッケージを依存関係に追加しても、アプリ起動時に有効化する一行が抜けている、といったケースです。
日本企業で起きやすい弱点
日本企業で特に危険なのは、「AIで速く作れた＝完成」とみなしてしまう空気です。
市民開発が進むほど、セキュリティの専門知識がない担当者でも本番相当のサービスを公開しやすくなります。
その結果、次のような弱点が露呈しやすくなります。
- 開発速度のKPIばかりが先行し、レビュー体制が追いつかない
- 「動いたデモ」をそのまま本番公開してしまう
- 情シスやセキュリティ担当が後追いで関与する
- 依存パッケージや秘密情報の管理ルールが曖昧
- 障害時に「誰がコードを理解しているか」が分からない
AI活用そのものが悪いわけではありません。
問題は、速度に対して検証ゲートを増やさず、「活用したこと」だけを成果にしてしまう点です。
これはツールの問題というより、組織の進め方の問題です。
今すぐできる対策
対策の基本は「禁止」ではなく、「速く作っても安全に出せる仕組み」を先に作ることです。
- プロンプトに認証・権限・秘密情報の扱いなどセキュリティ要件を明記する
- デプロイ前に秘密情報スキャンと依存関係チェックを必須にする
- 静的解析や簡易診断をCIに組み込む
- 人間または別AIによるセキュリティレビューを工程に固定する
- 管理画面や本番公開の承認フローを残す
- 最小権限・監査ログ・最終確認ポイントを設計に入れる
特に重要なのは、「動作確認のチェックリスト」とは別に、「安全確認のチェックリスト」を持つことです。
見た目が動くことと、外部から守れていることは別問題だと、組織の共通認識にする必要があります。
AIで速く作るほど、公開前のゲートを厚くする。これが速度と安全を両立する現実的なやり方です。
まとめ
AIによる爆速開発は、Webサービスの試作と改善を大きく前に進めます。
ただし「動作OK」は「セキュリティOK」ではありません。
開発速度だけが上がり、確認速度が据え置かれたままでは、日本企業の弱点がそのまま事故につながります。
これからのAI活用は、「どれだけ速く作るか」と同時に、「どれだけ安全に止められるか・直せるか」を設計することです。
Makoto Tejimaでは、AIを使ったWeb・システム開発でも、既存システム連携・権限管理・公開面の hardening・人間の最終確認まで含めて設計することを重視しています。
AI開発の導入ルール作り、セキュアな公開設計、既存システムの見直しなど、目的に応じてご相談いただけます。
