結論: 理解していないコードは守れない

AIが生成したコードを「動くからOK」で本番に入れていませんか？

私はAI生成コード特化のセキュリティスキャナー（CodeHeal）を開発・運用する中で、「技術負債」より厄介な負債が急増していることに気づきました。

それが**「理解負債」** ― 自分が理解していないコードを本番で動かしている状態です。

きっかけ: PRレビューで凍りついた瞬間

あるPRを見ていた時のことです。コードは綺麗で、エッジケースも処理されていて、一見シニアレベルの実装でした。

ただ1行、dangerouslySetInnerHTMLを使っている箇所があった。

「なぜここでサニタイズされたレンダラーじゃなくてdangerouslySetInnerHTMLを使ったの？」と聞くと、答えが返ってこない。AIが提案して、動いたからそのまま使った、と。

その1行はXSS脆弱性そのものでした。 そして開発者はそれを理解していなかった。

この経験から「理解負債」という概念が生まれ、スキャナーを作る原動力になりました。

技術負債は意識的な判断の結果です。理解負債は無意識のうちに積み上がるから怖い。

CodeHealの静的解析エンジンを運用する中で、AI生成コードに繰り返し現れるパターンがあります。

AIが生成するコードはeval()やnew Function()を「技術的に正しい」形で使うことがあります。テストは通る。でもそれはコードインジェクションの入口です。

私自身、AIにconfig parserを書かせた時、new Function()で動的評価するコードが出てきました。エレガントだけど、脆弱性でもあった。テストが全部通っていたから、静的解析で引っかけなければ気づかなかった。

実態: スキャンしたNode.jsコードの28%に、開発者が認識していない動的コード実行パターンが含まれていました。

AIは認証を一から実装するのが好きです。JWT検証、セッション管理、CSRF対策 ― 90%は正しい。

残りの10%でインシデントが起きます。

実際に見たケース:

開発者に「あなたの認証フローを説明して」と聞くと、多くが「AIが作った」と答えます。自分のトークン検証ロジックを説明できない。

実態: AI生成の認証実装の41%に、開発者が指摘できない重大な欠陥がありました。

最も厄介なパターン。AIは「ベストプラクティス」として、ログ送信・エラートラッカー・分析サービスへのデータ送信を勝手に追加することがあります。

開発者が指定していない外部エンドポイントへの通信が、コードに紛れ込む。

私自身のAI生成コードが、設定した覚えのないサードパーティにエラーレポートを送信していたのを発見した時、スキャナーの必要性を確信しました。

実態: AI生成フルスタックアプリの19%に、仕様書にない外部通信パターンが含まれていました。

AI生成コードを含むファイルごとに、4つの質問をしてください:

CodeHealを作ってから、自分のAIコーディングの習慣を変えました:

Vibe Codingは楽しい。高速に出荷できる爽快感がある。

でも、理解していないコードの1行1行が、守れないコードの1行1行です。

今ZennやQiitaでもVibe Codingの限界が話題になっています。「作ったけどやめた」「理解負債」― みんな同じ壁にぶつかっている。

技術負債と違って、理解負債は開発速度を落とさない。一気に全部壊れるまで。

AIが書いたコードはファーストドラフトであって、最終成果物ではない。そう扱えるかどうかが、セキュリティ事故を起こすかどうかの分かれ目です。

CodeHealは、AI生成コードのセキュリティ脆弱性を14カテゴリ・93以上の検出ルールで静的解析します。LLM不使用・API費用ゼロ・同じコードに対して常に同じ結果。

理解負債が隠しているパターンを、自動で見つけ出します。