自サイトをAI Code Analysisにかけてみた——SASTのさらに奥を、やってみて確かめる

AIがコードを書き、AIが自分でレビューし、自分で直す。エージェント型の開発では当たり前の光景です。では、外部のセキュリティ検査はもう要らないのか——口で論じるより試すのが早いので、当サイト（aikido-community.jp、Next.js + Prisma + PostgreSQL + cronバッチ）そのものを、AikidoのAI Code Analysisにかけてみました。手順と、実際に出てきたものを順に記録します。

手順1：監査タイプを選ぶ

まず監査の種類を選びます。2つ用意されていました。

• Code Security Audit（AI SAST） — コードから実際の攻撃経路と検証済みのセキュリティリスクを見つける
• Data Exposure Audit（DSPM） — コードから機微データの流れと露出リスクを見つける

今回はCode Security Auditを選択。DSPM（データ露出監査）は別テーマなので、次便で扱います。

手順2：対象リポジトリを選ぶ

GitHub連携済みのリポジトリから対象を選ぶだけです。追加のコンテキスト（Additional Notes）を渡すこともできます。

手順3：先に料金（クレジット）が計算される

ここが実務的に重要でした。実行前に、対象コードの規模から消費クレジットの見積もりが表示され、それを確認してから実行に移る設計です。今回の見積もりは30クレジットでした。使い放題ではなく都度コストが見えるので、どのリポジトリにいつかけるかを計画できます。日本の年間予算での運用とも相性がいいポイントです。

手順4：実行——4段階で進む

実行すると、Mapping（構造の把握）→ Analyzing（解析）→ Validating（検証）→ Finalizing（確定）→ Completed の4段階で進みます。今回の所要時間は13分でした。

出力されたのは、Open Issue 4件（サブ指摘含む）と、信頼境界図つきのThreat Model（脅威モデル）。SASTの検出リストではなく、コードレビューの報告書に近い形です。うち2件を当日中に修正まで進めたので、順に見ます。

指摘1：公開ルートが「未公開」を返せてしまう（設計の逸脱）

記事表示ルートの取得がこうなっていました。

const article = await prisma.newsArticle.findUnique({ where: { slug } });

published（公開フラグ）を見ていない。下書き記事のslugを知っていれば、誰でも未公開の本文が読める状態です。

指摘の根拠の組み立て方が特徴的でした。「一覧ページは published: true で絞っている」「共通の取得ロジックも同様」「スキーマに published フラグが定義されている」——つまり未公開を隠すのがこの設計の意図であり、このルートだけがそれを破っている、という論証。単一ファイルのパターン照合では書けない、コードベース横断で設計意図を復元してから逸脱を特定する指摘です。

指摘2：環境変数が無いと固定トークンで認証が通る（運用まで読んだ判定）

バッチAPIの認証です。

const expectedToken = process.env.BATCH_SECRET_TOKEN || "batch-secret";

環境変数が未設定なら固定文字列 "batch-secret" で誰でも認証が通る——フェイルオープン（失敗時に開く）設計です。さらにこの指摘は、隣のバッチルートが別名の変数（BATCH_SECRET）を使い、そちらは未設定時に止まるフェイルクローズ実装であることまで対比し、「変数名が不揃いだから片方だけ設定し忘れるのは現実的な運用ミス」と、条件付きの脆弱性を現実性込みで判定してきました。

なお本番は両方の変数が設定済みで、この扉は一度も開いていませんでした。実害ゼロのうちに設計の欠陥を潰せたことになります。

ビジネスロジックの指摘も出る

残る指摘は、投票による評価ポイントの整合性や、購読フローの状態遷移といった、純粋なビジネスロジックの領域でした。「ワークフローや状態遷移の前提は、個々の技術的コントロールが機能していても迂回できる」という分類で、リクエスト順序や状態操作による想定外の遷移を突いてくる。SASTのルールでは書けない領域です。こちらの修正と実際のビジネステスト（挙動検証）は次便で実行し、詳報します。

Threat Model（脅威モデル）：構成をヒアリングなしで復元する

同時に生成された脅威モデルは、4つのパートで構成されていました。

概要（Overview） — アプリの主要コンポーネント（Nginxリバースプロキシ、Next.js、PostgreSQL、cronで動くバッチAPI、Claude翻訳やSMTP等の外部サービス）を、こちらから何も説明せずに列挙。

信頼境界（Trust Boundaries） — Public / Application / Batch / Data の4境界を図と文章で定義し、各境界で何がどう検証されているか（TLS終端の位置、セッション検証、バッチのBearerトークン照合、内部ネットワーク分離）を明記。

脅威シナリオ（Threat Scenarios） — 「markdown経由の格納型XSS」「単一バッチ認証情報の漏えいによる一斉配信・なりすまし投稿」「購読エンドポイントの無認証・無制限による迷惑メールリレー化」など、具体的な攻撃シナリオを尤度×影響で評価し、緩和策と検証手順（ペンテストの観点）まで提示。

アーキテクチャの脆さ（Architectural Fragilities） — 「すべての特権操作が単一の共有シークレットで認可されている」という設計上の弱点を名指しし、操作ごとに鍵を分ける設計を提案。

設計レビューの叩き台として、そのまま使える水準でした。

AutoFixで時間が稼げる

各指摘にはAutoFixボタンがあり、押すとAIがパッチを生成してPull Requestを作ります。指摘1の修正見積は2時間と表示されていましたが、実際にかかったのはレビューとマージで15分程度。パッチの中身も、Prismaで複合条件を通すための findUnique → findFirst の書き換えや、OGPメタデータ側の取得にも同じゲートを入れる修正まで含む、的確なものでした。

ただしパッチには「review carefully before using」と明記されており、これは飾りではありません。指摘2の修正は認証を正しい変数に統一しフェイルクローズ化する内容で、パッチ自体は模範的ですが、このAPIが受け付けるトークンの契約を変える修正でもあります。cronで動いている呼び出し側を同時に直さなければ、マージ翌日から自動処理が静かに401で止まる。パッチのマージ、cron側のトークン参照の一本化、旧トークンが拒否されることの確認までやって、初めて決着です。

TEST：Retestで当日中にSolved

修正をデプロイした後、各指摘の「Retest」を押すと再監査が走ります。2件とも当日中にSolvedになり、検出→パッチ→デプロイ→再検証→クローズの全過程が、日付・根拠つきでダッシュボードに残りました。

SASTよりさらに奥が深い

パターンではなく設計を読む。ファイル単位ではなくコードベース横断で意図を復元する。技術的な脆弱性だけでなくビジネスロジックの穴まで指摘する。脅威モデルを自動生成し、パッチまで作り、再検証して記録を残す——SASTの置き換えではなく、そのさらに奥にあるコードレビューの自動化です。

そして実行の入口は「監査タイプを選ぶ → リポジトリを選ぶ → 料金を確認して実行」の3ステップ。所要13分、消費30クレジットで、ここまでが手に入りました。

次便では、残るビジネスロジック指摘の修正と実際の挙動テスト、そしてもう一方のData Exposure Audit（DSPM）を同じ手順でやってみます。

AI Code AnalysisはAikidoのダッシュボードからGitHub連携済みリポジトリに対して実行できます。コードを読むだけで動くため、本番環境やデータベースへの接続は不要です。