AIエージェント
非エンジニアの AI 開発をどこまで許可すべきか — vibe coding が本番に持ち込んだ脆弱性の教訓
非エンジニアが AI で作ったアプリを本番公開し、認証漏れの脆弱性を残した実体験から、組織が設けるべきレビューゲートの引き方を考える。
原題
“I Vibe Coded a Security Risk” （ノンエンジニアが AI で本番デプロイしたセキュリティ脆弱性）
原文からの引用
“AI can help us make something before it gives us the ability to tell whether it is safe or ready for other people.”
日本語訳 AI は、それが安全か、他人に使わせてよい状態かを見分ける能力を私たちに与えるより先に、何かを作る力を与えてしまう。
要点
- 非エンジニア出身の著者が Claude で開発した執筆スタイルガイド生成アプリに、public API エンドポイントの認証漏れが本番環境で存在していた
- 著者のケースでは、「動作確認 = 検収完了」という錯覚と、AI が提供する説得力のある説明により、セキュリティレビューが後回しになった
- 心理学でいう「説明の深さの錯覚（Illusion of Explanatory Depth）」が、AI アシスタント時代に増幅されている
- OpenAI の調査では、全 ChatGPT ビジネス利用の 16.8% が「task crossover」（別職種の仕事を AI で代替）だった
- 著者は復帰時に複数モデル検証・敵対的テスト・人間のセキュリティレビューを必須フローに組み込む方針を示す
編集部の考察
経営が決めるべきは AI 開発ツールの利用範囲の規制ではなく、「本番公開・外部接続・権限管理に触れる変更」を定義し、そこにだけ強制的な人間レビューゲートを設けることだ。この記事で見逃せないのは、著者の失敗そのものより、それを検知した経緯である。著者は Claude に MCP コネクタを作らせ、Claude 自身のチェックを通過し「完成」と報告された時点で本番デプロイした。脆弱性(公開登録ルートが誰でも叩ける状態)が発覚したのは、後日たまたま別系統の GPT-5.6 Sol に同じコードを見せたときだった。同一モデルの自己申告だけでは検出できなかった欠陥を、モデルを変えた瞬間に見つけている。OpenAI の調査で ChatGPT 業務利用の16.8%が「task crossover」(本来の職掌外の業務をAIで代替)だったという数字（要点4）も踏まえると、これは著者個人の特殊事情ではなく、非エンジニアが AI を使って本番相当の機能を作る行為が組織内で常態化していることを示す。自分の組織に置き換えれば、まず「誰が・どの権限で本番環境に外部公開機能をデプロイできるか」を可視化する必要がある。営業やマーケティング部門の担当者が AI で作った社内ツールや外部連携機能が、正式なエンジニアリングレビューを経ずに本番稼働している例はすでに存在しうる。著者が事後的に AGENTS.md へ組み込んだ「外部公開・共有・本番影響のある変更は、複数モデルによる敵対的レビューと人間のセキュリティ担当者の承認を必須とする」というルールは、個人の自主規制ではなく、AI ガバナンスとして会社側が承認フローに組み込むべき最低ラインであり、冒頭のレビューゲートの具体形そのものである。
本記事は海外記事の独自キュレーション・考察であり、原文の翻訳ではありません。引用部分の著作権は原著者に帰属します。