結論: 理解していないコードは守れない
AIが生成したコードを「動くからOK」で本番に入れていませんか？
私はAI生成コード特化のセキュリティスキャナー（CodeHeal）を開発・運用する中で、「技術負債」より厄介な負債が急増していることに気づきました。
それが**「理解負債」** ― 自分が理解していないコードを本番で動かしている状態です。
きっかけ: PRレビューで凍りついた瞬間
あるPRを見ていた時のことです。コードは綺麗で、エッジケースも処理されていて、一見シニアレベルの実装でした。
ただ1行、dangerouslySetInnerHTMLを使っている箇所があった。
「なぜここでサニタイズされたレンダラーじゃなくてdangerouslySetInnerHTMLを使ったの？」と聞くと、答えが返ってこない。AIが提案して、動いたからそのまま使った、と。
その1行はXSS脆弱性そのものでした。 そして開発者はそれを理解していなかった。
この経験から「理解負債」という概念が生まれ、スキャナーを作る原動力になりました。
技術負債 vs 理解負債
| 技術負債 | 理解負債 | |
|---|---|---|
| 発生源 | 自分が選んだショートカット | 自分が書いていないコード |
| 認知 | 存在を知っている | 何がわからないかもわからない |
| 修正 | リファクタリング | まず理解してから修正 |
| セキュリティリスク | 既知のトレードオフ | 未知の脆弱性 |
技術負債は意識的な判断の結果です。理解負債は無意識のうちに積み上がるから怖い。
スキャンで繰り返し見つかる3つのパターン
CodeHealの静的解析エンジンを運用する中で、AI生成コードに繰り返し現れるパターンがあります。
パターン1: 「動くから安全」の誤解
AIが生成するコードはeval()やnew Function()を「技術的に正しい」形で使うことがあります。テストは通る。でもそれはコードインジェクションの入口です。
私自身、AIにconfig parserを書かせた時、new Function()で動的評価するコードが出てきました。エレガントだけど、脆弱性でもあった。テストが全部通っていたから、静的解析で引っかけなければ気づかなかった。
実態: スキャンしたNode.jsコードの28%に、開発者が認識していない動的コード実行パターンが含まれていました。
パターン2: 認証の「90%正しい」罠
AIは認証を一から実装するのが好きです。JWT検証、セッション管理、CSRF対策 ― 90%は正しい。
残りの10%でインシデントが起きます。
実際に見たケース:
- JWTの署名は検証するが有効期限をチェックしない
- トークン形式は正しいがハードコードされたsecretが残っている
開発者に「あなたの認証フローを説明して」と聞くと、多くが「AIが作った」と答えます。自分のトークン検証ロジックを説明できない。
実態: AI生成の認証実装の41%に、開発者が指摘できない重大な欠陥がありました。
パターン3: 見えないデータフロー
最も厄介なパターン。AIは「ベストプラクティス」として、ログ送信・エラートラッカー・分析サービスへのデータ送信を勝手に追加することがあります。
開発者が指定していない外部エンドポイントへの通信が、コードに紛れ込む。
私自身のAI生成コードが、設定した覚えのないサードパーティにエラーレポートを送信していたのを発見した時、スキャナーの必要性を確信しました。
実態: AI生成フルスタックアプリの19%に、仕様書にない外部通信パターンが含まれていました。
理解負債の自己診断
AI生成コードを含むファイルごとに、4つの質問をしてください:
- すべてのimportの理由を説明できるか？（何をするかではなく、なぜ必要か）
- データの入力から出力まで追跡できるか？
- セキュリティ境界（信頼/非信頼の境目）を特定できるか？
- AIのコードを消して、重要な部分を自分で書き直せるか？
| スコア | 状態 | アクション |
|---|---|---|
| 4/4 | このコードを所有している ✅ | そのまま |
| 3/4 | 軽度の負債 | レビューをスケジュール |
| 2/4 | 重度の負債 | 次のリリース前にレビュー必須 |
| 0-1/4 | 危険 | このコードは負債そのもの |
私が変えたワークフロー
CodeHealを作ってから、自分のAIコーディングの習慣を変えました:
- コミット前に全行読む。 流し読みではなく精読。説明できない行は書き直すか消す
- AI生成コードには必ず静的解析を通す。 AIを信用していないのではなく、手動で全部見つけられる自分を信用していない
- AIのコードをベンダーコードとして扱う。 サードパーティライブラリを検証なしで本番投入しないのと同じ
Vibe Codingとの向き合い方
Vibe Codingは楽しい。高速に出荷できる爽快感がある。
でも、理解していないコードの1行1行が、守れないコードの1行1行です。
今ZennやQiitaでもVibe Codingの限界が話題になっています。「作ったけどやめた」「理解負債」― みんな同じ壁にぶつかっている。
技術負債と違って、理解負債は開発速度を落とさない。一気に全部壊れるまで。
AIが書いたコードはファーストドラフトであって、最終成果物ではない。そう扱えるかどうかが、セキュリティ事故を起こすかどうかの分かれ目です。
理解負債をスキャンで可視化する
CodeHealは、AI生成コードのセキュリティ脆弱性を14カテゴリ・93以上の検出ルールで静的解析します。LLM不使用・API費用ゼロ・同じコードに対して常に同じ結果。
理解負債が隠しているパターンを、自動で見つけ出します。