AIがコードを書く時代に、誰がレビューするのか？

コードレビューが追いつかない時代

10年前を思い出してほしい。チームは5人、言語はJava、フレームワークはSpringくらい。PRは1日2〜3件。全部目で見てレビューできた。SQLインジェクションも「あ、ここ文字列結合してるよ」で気づけた。ライブラリは限られていたし、オープンソースを使うことすら禁止されていた会社も多い。コードを書くのも人間、レビューするのも人間。速度が合っていた。

しかし、今はどうだろうか。

CursorやCopilotでReactアプリを作れば、1日でPRが10件、差分3,000行。AIが勝手にnpmパッケージを5個追加している。中身を知らない。ライセンスも確認していない。レビュアーが「LGTM（Looks Good To Me＝問題なさそう）」と書いたけど、本当に全部読んだだろうか？

コードを書く速度はAIで10倍になった。でもレビューの速度は変わっていない。 ここにギャップが生まれている。

AIが書くコードの「落とし穴」

AIは「動くコード」を書く。テストも通る。でも**「誰がアクセスしていいか」「エッジケースでどうなるか」「本番環境で安全か」は考えない。** 具体的に見てみよう。

落とし穴①：他社のデータが丸見え（IDOR）

AIに「請求書APIを作って」と頼むと、こう書く：

// ❌ AIが生成しがちなパターン
app.get('/api/invoices/:id', async (req, res) => {
  const invoice = await db.invoice.findById(req.params.id);
  res.json(invoice);
});

動く。テストも通る。でも、URLの :id を1つ変えるだけで他社の請求書が見える。マルチテナントSaaSなら一発で情報漏洩だ。正しくはこう：

// ✅ テナントチェックを追加
app.get('/api/invoices/:id', async (req, res) => {
  const invoice = await db.invoice.findById(req.params.id);
  if (!invoice || invoice.tenantId !== req.user.tenantId) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  res.json(invoice);
});

たった1行の if 文の差。でもこの1行がなければ、顧客データの流出事故になる。

落とし穴②：SQLインジェクション

# ❌ AIが文字列結合で書く
query = f"SELECT * FROM users WHERE name = '{name}'"

# ✅ パラメータ化クエリ
cursor.execute("SELECT * FROM users WHERE name = %s", (name,))

name に '; DROP TABLE users;-- を入れられたら、テーブルごと消える。AIはパラメータ化を「知っている」が、常にそう書くとは限らない。

落とし穴③：ゼロ除算でクラッシュ

// ❌ AIが考慮しない
const avg = total / users.length;

// ✅ ガードを追加
const avg = users.length > 0 ? total / users.length : 0;

普段は問題ない。でも新規サービス立ち上げ時やテストテナントでユーザー0人のとき、本番がクラッシュする。深夜3時にアラートが鳴る。

落とし穴④：認証情報がログに残る

// ❌ デバッグで残しがち
console.log("DB接続:", process.env.DATABASE_URL);

// ✅ 機密情報はログに出さない
console.log("DB接続: established");

開発中は便利。でもそのまま本番にデプロイすると、DatadogやCloudWatch Logsにデータベースのパスワードが平文で残る。過去に実際あった事故だ。

落とし穴⑤：破られるハッシュ

# ❌ AIが平気で使う
hashlib.md5(password.encode()).hexdigest()

# ✅ 安全なアルゴリズム
hashlib.pbkdf2_hmac('sha256', password.encode(), salt, 100000)

MD5は数秒で総当たり解読される。2026年にMD5でパスワードをハッシュしているコードがPRに含まれていたら、それはセキュリティインシデントの種だ。

実際にやってみた：AIが書いたサイトをAikidoでスキャンした結果

ここまで「理論上の落とし穴」を紹介してきた。では、実際にどう動くのか？

私たちは aikido-community.jp というコミュニティサイトをClaude Code（AIコーディングツール）で構築した。Next.js + TypeScript + Prismaのフルスタック構成だ。そのコードをAikido Code Qualityでスキャンしてみた。

43秒で見つかった脆弱性

PRを作成してからわずか43秒。Aikidoが自動でコードをスキャンし、PRにコメントを残した：

Using dangerouslySetInnerHTML in React can lead to XSS attacks - high severity

Using dangerouslySetInnerHTML can allow attacks to insert HTML into your page, or even scripts if you don't have strict CSP rules set up. Worst case, it could be used as a way to start a social engineering attack or start an account takeover attack.

Remediation: Avoid dangerouslySetInnerHTML usage. If you must use HTML, sanitize it with a library such as DOMPurify.

✅ Aikido Security: check code — Successful in 43s — Scan completed

AIが書いたコードを、AIがレビューして、43秒で脆弱性を見つけた。 人間のレビューでは「LGTM」でスルーされていたかもしれない箇所だ。

修正提案まで自動で出る

Aikidoは問題を指摘するだけでなく、修正方法も提示する：

dangerouslySetInnerHTMLの使用を避ける
どうしても使う場合はDOMPurifyなどのライブラリでサニタイズする
CSPポリシーを設定して防御を多層化する

PRのコメント上で @AikidoSec ignore: [理由] と返信すれば、正当な理由がある場合は無視することもできる。

Aikido Code Quality：AIが書いたコードをAIがレビューする

AikidoのCode Qualityは、PRごとにコードを自動レビューする機能だ。46個のチェックが5つのカテゴリに分かれている：

Security — SQLインジェクション、IDOR、古いハッシュアルゴリズム、XSSなど、セキュリティ上の問題を検出
Bug Risk — ゼロ除算、スレッドセーフ違反、再帰の深さ制限なし、ロック未解放など、本番障害につながるパターン
Logic Bugs — 矛盾した条件分岐、デバッグコードの消し忘り
Readability — 関数が長すぎる、ネストが深い、TODO放置、コメントアウトされたコードの残存
Performance — O(n²)のネストループ、冗長なDBインデックス、SELECT * の使用

49言語に対応し、リポジトリを接続してチェックを有効にするだけで、PRごとに自動でこれらを指摘してくれる。人間が見落とすパターンも、AIは見落とさない。

上で紹介した5つの落とし穴は、すべてCode Qualityの既存チェックでカバーされている。設定するだけで、明日から防げる問題だ。

Custom Code Rules：チームの「二度と踏まない地雷」をルール化する

既存の46チェックだけでは足りないケースもある。チーム固有のルールが必要になる場面だ。例えば：

過去に process.env をログに出して認証情報が漏れた → 「process.envをconsole.logに渡すコードはPRブロック」 というルールを作る
deprecated APIの legacyAuth() をまだ使う人がいる → 「legacyAuth()の呼び出しは即警告」 を追加
本番DBのホスト名をハードコードしてデプロイされた → 「prod-db.example.comの文字列リテラルはブロック」 で防ぐ

ポストモーテムの教訓をルールとして埋め込む。 同じ事故を二度と起こさない仕組みだ。人が入れ替わっても、ルールは残る。

Code Context：「うちではOK」をAIに教える

Code Qualityを有効にすると、最初は指摘が多すぎると感じるかもしれない。

実際、先ほどのaikido-community.jpのスキャンでも dangerouslySetInnerHTML が指摘された。しかしこのケースでは、表示しているHTMLはAikido公式ブログの記事コンテンツであり、ユーザー入力ではない。つまり、XSSのリスクは実質的に低い。

こういうときに使うのがCode Contextだ。

チームの暗黙知――「これはうちではOK」という例外ルールをAIに教える機能。設定画面で自然言語で書くだけでいい：

「markdown.tsxはブログ記事の表示用コンポーネントなのでdangerouslySetInnerHTMLは許可」
「migrations/フォルダのファイルサイズ制限は不要」
「debug-toolsリポジトリのconsole.logは許可」

さらに、PR上で @AikidoSec にコメントするだけで、そのフィードバックが自動的にCode Contextに反映される。使えば使うほど、チームに合ったレビュアーに育っていく。

Custom Code Rulesが「新しいルールを足す」なら、Code Contextは「不要な指摘を消す」。 この2つを組み合わせることで、ノイズの少ない、精度の高い自動レビューが実現する。

まとめ：コードを書くのがAIなら、レビューもAIに任せる

Aikido Code Qualityは、この「レビューが追いつかない」問題をAIで解決する。

46個の既存チェックで、セキュリティ・バグ・パフォーマンスの定型パターンを自動検出
Custom Code Rulesで、チーム固有のルールを追加して「過去の失敗」を組織の記憶にする
Code Contextで、チームの暗黙知を教えてノイズを減らす

人間のレビューは「知ってる人が見れば気づく」。Code Qualityは「知らない人のPRでも止まる」。

実際に私たちは、Claude Codeで構築したサイトをAikidoでスキャンし、43秒でXSSの脆弱性を発見した。AIが書いたコードを、AIがレビューして止めてくれた。これが2026年のコードレビューの姿だ。

AIが大量にコードを吐く時代だからこそ、レビューもAIに任せる。Aikido Code Qualityは、チーム専属のAIレビュアーだ。

AIがコードを書く時代に、誰がレビューするのか？ — Aikido Code Qualityという答え