/ai-dev-os-check 実践ガイド — 動的チェックでAIコードを自動レビューする方法

AIで開発していて、こんな経験ありませんか？

「ガイドラインをCLAUDE.mdに書いたはずなのに、生成後にぽろぽろ漏れが見つかる」「チェックして直して、またチェックして——の繰り返しが地味につらい」「ガイドラインファイルを増やしたら、むしろ品質が下がった気がする」

前回の記事で、CLAUDE.md（AIへの指示書ファイル）にガイドラインを読み込ませることでコード品質が大幅に上がる、という話をしました。自分自身もそれで満足していた時期がありました。

でも実際に運用し続けると、壁にぶつかったんです。ガイドラインファイルを10本読み込ませても、スコアは 85点前後で頭打ち になってしまいました。

そこで試したのが、今回紹介する /ai-dev-os-check（動的チェック） です。静的ルール10ファイル読み込みの約85点を 95.2点 まで引き上げることができました。しかも驚くことに、ガイドラインファイルをほとんど読み込ませなくても、動的チェックだけでこのスコアに到達できたのです。

この記事でわかること

• なぜ静的なルール読み込みだけでは品質が頭打ちになるのか（Attention Dilutionの話）
• 「動的チェック」という考え方と、/ai-dev-os-check が内部でやっていること
• /ai-dev-os-check の3ステップの仕組み（CLAUDE.md解析 → git diff → ルールマッチング）
• Check & Fix Report の読み方と、3つのセクション（Passed / Fixed Violations / Manual Review Required）の活用法

前回記事の続きとして書いていますが、/ai-dev-os-check 単体の話として読んでいただいても問題ありません。

前提と環境

この記事は以下の環境を前提としています。

• 前回記事: 【30分】Next.jsプロジェクトにAIコーディングのガイドラインを導入する手順を読んでいると理解しやすいです（必須ではありません）
• AIコーディングツール: Claude Code
• フレームワーク: Next.js 15 App Router
• 所要時間の目安:
  • 記事の通読: 約15分
  • 設定作業: 約5分
  • 合計: 約20分

CLAUDE.md とは、Claude Codeがプロジェクトを開いたときに自動で読み込む「AIへの指示書ファイル」です。このファイルにガイドラインへのパスや守るべきルールを書いておくことで、AIが毎回そのルールを参照しながらコードを生成するようになります。初めて聞いた方は「AIへの設計書」というイメージで大丈夫です。

/ai-dev-os-check とは、Claude Codeのカスタムスラッシュコマンドです。スラッシュコマンドとは、チャット欄で /コマンド名 と入力するだけで決まった処理を実行できる仕組みのこと。/ai-dev-os-check を実行すると、AIが書いたコードをガイドラインに照らして自動チェック・自動修正してくれます。

静的ルールの壁: なぜ85点で止まったのか

少し想像してみてください。新しくチームに入ったメンバーに、コーディング規約のドキュメントを渡したとします。「はい、読んでおいてください」——それだけで、品質の高いコードを書き続けてもらえるでしょうか？

おそらくNoですよね。規約を読んで「知っている」状態になることと、実際のコードに「適用できている」状態は、別の話です。品質を上げるには、コードレビューのサイクルが必要です。書いたコードを誰かがチェックし、指摘し、修正する——この繰り返しがあってはじめて、品質は上がっていきます。

AIも、まったく同じです。

CLAUDE.md にガイドラインを列挙して読み込ませることは、「規約ドキュメントを渡す」行為に相当します。AIはルールを「知っている」状態になりますが、それだけでは 「適用できているか」の検証 が抜けています。これが、静的コンテキスト（CLAUDE.md＋ガイドラインファイル）だけでは品質が頭打ちになる、根本的な理由です。

しかも、ガイドラインファイルを増やしすぎると逆効果になる現象があります。

Attention Dilution（アテンション・ダイリューション） とは、AIが読み込む情報量が増えすぎると、個々の情報に割ける注意（Attention）が薄まっていく現象です。ガイドラインを10ファイル読み込ませると、AIはそれを全部「なんとなく考慮」しようとしますが、どのルールも薄く浅い適用になりがちです。その結果、ルールを増やしたはずなのにスコアが85点付近で伸び悩む、という逆転現象が起きます。

動的チェックは、この問題を回避します。「生成後に、変更したコードだけを対象にして、ルールを一つひとつ照合する」という構造なので、AIの注意が分散しません。

「生成→チェック→修正」のサイクルを回すイメージはこんな感じです。

生成（AIがコードを書く）
    ↓
/ai-dev-os-check（ルールに照らして自己レビュー）
    ↓
AI Dev OS Check & Fix Report（合否・要確認・修正済みを一覧化）
    ↓
違反箇所が自動で修正される
    ↓
品質向上

このサイクルが1回まわるだけで、見落としていた違反が潰れます。さらに繰り返すことで、精度は上がり続けます。

/ai-dev-os-checkの仕組み — 3ステップで動く

「動的チェック」の概念はわかった。でも実際、/ai-dev-os-check は内部で何をしているのでしょうか？

仕組みは大きく3ステップに分かれています。

Step 1: CLAUDE.md を解析して、参照ガイドライン一覧を取得する

まず、プロジェクトルートの CLAUDE.md を読み込み、どのガイドラインファイルが参照されているかを自動で抽出します。「どんなルールが存在するか」の地図を作るイメージです。プロジェクトごとに異なるガイドライン構成も、CLAUDE.md さえ整っていれば自動で認識されます。

Step 2: git diff で「今回の変更」だけを対象にする

次に、指定されたコミット範囲の差分（git diff = 変更内容の差分）を取得します。プロジェクト全体ではなく、今回変更されたコードだけ を対象にすることが、このツールの設計上の核心です。

Step 3: 変更コードとガイドラインをAIに送り、Check & Fix Report を生成する

Step 1で取得したガイドラインと、Step 2で取得した差分コードをAIに渡し、修正済み違反・要確認・合格の3分類でレポートを生成します。

実際の使い方はシンプルです。

# 未ステージの変更をチェック＋自動修正（コミット前に実行）
/ai-dev-os-check

# レポートのみ確認したい場合（修正なし）
/ai-dev-os-check --dry-run

# mainブランチとの差分をチェック（PR review向け）
/ai-dev-os-check main

# ステージング中のファイルのみ対象（git addしたファイルだけ / Hooks連携用）
/ai-dev-os-check --staged --dry-run

日常的な使い方としては、コミット前に引数なしで実行するパターンが最も多いです。--dry-run オプションをつけると修正は実行されずレポートだけ出力されるので、「まず確認したい」ときに便利です。

「全ファイルではなくdiff対象のみ」にする3つのメリット

1. 高速: 変更箇所だけを見るので、大きなプロジェクトでも数秒〜数十秒で完了します
2. 焦点が当たる: 今回の変更に直接関係するルールだけが報告されるため、ノイズが少ないです
3. 修正しやすい: 「今書いたコードの話」なので、違反の指摘を受けてもすぐに文脈を思い出せます

実際の出力を読む — Check & Fix Reportの3セクション

/ai-dev-os-check を実行すると、以下のような AI Dev OS Check & Fix Report が出力されます。

## AI Dev OS Check & Fix Report

### Scope
- Mode: Check & Fix
- Target: unstaged changes (`git diff`)
- Files checked: 6

### Summary
- ✅ Passed: 7 / 🔧 Fixed: 3 / ⚠️ Manual Review: 2

### Fixed Violations
| # | File | Line | Rule | What was fixed |
|---|------|------|------|----------------|
| 1 | `src/app/actions/task.ts` | 23, 41, 67 | server-actions: revalidatePath を必ず呼ぶ | Server Action後のrevalidatePath()を3箇所に追加 |
| 2 | `src/app/api/tasks/route.ts` | 15 | validation: Zodスキーマでバリデーション | Zodスキーマ定義とsafeParse()によるバリデーションを追加 |
| 3 | `src/components/TaskForm.tsx` | 8 | naming: ハンドラ名は handleXxx パターン | submitForm → handleSubmit にリネーム |

### Manual Review Required
| # | File | Line | Rule | Why manual review is needed |
|---|------|------|------|----------------------------|
| 1 | `src/app/api/tasks/route.ts` | 1 | security: CSRF対策 | Server Actionのみのケースは自動判定不可。手動確認が必要 |
| 2 | `src/app/api/tasks/[id]/route.ts` | 1 | performance: ページネーション | 件数増加時のパフォーマンス影響は実測が必要なため手動対応 |

### Checklist Coverage
- Items checked: 12 / 12
- Pass rate: 83% (after fixes)

レポートは3つのセクションで構成されています。

✅ Passed — Summary に件数だけ表示。読み流してOK

ガイドラインに照らして問題なしと判定された項目数です。Passed が多いほど「ちゃんと守れている」部分が多いということ。個別の項目は出力されず、件数のみ表示されます。

🔧 Fixed Violations — 自動修正済みの違反一覧

明確なルール違反と判定され、AIが自動修正した項目の一覧です。File・Line・Rule・What was fixed（何を修正したか）の4列で構成されています。レポートを確認したら、必ず git diff で修正内容を目視確認する習慣をつけてください。AIは基本的に意図通りの修正をしますが、まれにリファクタリングの範囲が広がりすぎることがあります。

⚠️ Manual Review Required — 人間が判断する必要がある項目

AIが合否を自動判定できなかった項目です。「実装の意図によっては問題ない」「実測しないと判断できない」といった理由で、自動修正に踏み切れないケースがここに入ります。Why manual review is needed（なぜ手動確認が必要か）の列を読んで、優先度をつけて対応しましょう。セキュリティ関連（security: 始まりの Rule）は最優先です。

Rule列からL2原則を遡って理解する

Check & Fix Report の Fixed Violations テーブルを見ると、Rule 列に違反したルールが記載されています。

server-actions: revalidatePath を必ず呼ぶ

このルールは、AI Dev OS の4層モデルで言うと L3（実装パターン） に相当します。「何をすべきか」は分かりますが、「なぜこのルールが必要なのか」はここだけでは分かりません。

4層モデルとRule列の対応

AI Dev OS は、設計思想を4つの層で整理しています。

層	役割	例
L1: プリンシパル（設計哲学）	絶対に変わらない根本原則	「可観測性」「最小権限」
L2: 決定基準（判定軸）	L1を具体的なルールに落とした基準	「データ変更後は必ずキャッシュを無効化する」
L3: 実装パターン ← Rule列はここ	L2を満たす具体的なコードパターン	「Server Actionの後にrevalidatePath()を呼ぶ」
L4: プロジェクト固有	チームの慣習・業務ルール	「このプロジェクトではrevalidate対象は/tasksのみ」

Report の Rule 列は L3 の記述です。「なぜこのルールが存在するのか」を知りたい場合は、参照先のガイドラインファイルを開いてみましょう。

ガイドラインファイルを開くと何がわかるか

たとえば server-actions.md を開くと、revalidatePath が必要な理由が L2 の判定基準として記述されています。

[L3 実装パターン ← Rule列に表示されるのはここ]
  Server ActionのあとにrevalidatePath()を呼ぶ
        ↑ なぜ？（server-actions.md を開くとわかる）
[L2 決定基準]
  キャッシュの一貫性 — データ変更後は必ずキャッシュを無効化する
        ↑ なぜ？
[L1 プリンシパル]
  可観測性 — 状態の変化は常に一貫して見える

この連鎖を理解した上で修正に臨むと、「このページだけrevalidateすればいい」ではなく、「このアクションが影響するすべてのキャッシュを洗い出す」という判断ができるようになります。「次も同じ間違いをしない」修正、というのはこういうことです。

Report の Rule 列に「なんでこのルールがあるんだろう？」と思ったら、ガイドラインファイルを開いてL2まで遡ってみてください。AIへの修正指示の質が一段上がります。

セキュリティ違反の検出例 — IDOR・入力バリデーション・CSRF/Cookie属性の実例

「AIが生成したコードだから安全なはず」と思っていませんか？

ベンチマーク（013〜015番のテスト、計45試行）を通じて分かったのは、AIはセキュリティ系の実装をかなりの頻度で省略するという事実です。ガイドラインなしの状態では、5ファイル中4件にrevalidatePathの欠落が見つかりました。それらの4件すべてを /ai-dev-os-check が検出・自動修正しています（検出率100%）。

ここでは /ai-dev-os-check が実際に検出した3パターンを紹介します。

パターン①: IDOR（他人のリソースが取れてしまう）

IDOR（Insecure Direct Object Reference）は、URLのIDを変えるだけで他のユーザーのデータにアクセスできてしまう脆弱性です。

// Before（ガイドラインなし — 他ユーザーのデータが取れてしまう）
export async function GET(req: Request, { params }: { params: { id: string } }) {
  const task = await db.task.findUnique({ where: { id: params.id } })
  return NextResponse.json(task)
}

このコードに対して /ai-dev-os-check はこう報告します。

### Fixed Violations
| # | File | Line | Rule | What was fixed |
|---|------|------|------|----------------|
| 1 | `src/app/api/tasks/[id]/route.ts` | 3 | security: 所有者確認（IDOR防止） | auth()でセッション取得し、userId条件をwhereに追加 |

自動修正後のコードはこうなります。

// After（自動修正後）
export async function GET(req: Request, { params }: { params: { id: string } }) {
  const session = await auth()
  if (!session?.user?.id) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
  }
  const task = await db.task.findUnique({
    where: { id: params.id, userId: session.user.id }  // 所有者確認を追加
  })
  if (!task) return NextResponse.json({ error: 'Not found' }, { status: 404 })
  return NextResponse.json(task)
}

where 句に userId: session.user.id を追加するだけですが、これがないと認証済みユーザーなら誰でも任意のタスクIDを叩けてしまいます。AIはシンプルなCRUDを生成するとき、この確認を省略しがちです。

パターン②: 入力バリデーション欠落（生のbodyをそのまま保存）

// Before
export async function POST(req: Request) {
  const body = await req.json()
  const task = await db.task.create({ data: body })  // 生のbodyをそのまま保存
  return NextResponse.json(task)
}

### Fixed Violations
| # | File | Line | Rule | What was fixed |
|---|------|------|------|----------------|
| 1 | `src/app/api/tasks/route.ts` | 15 | validation: Zodスキーマでバリデーション | Zodスキーマ定義とsafeParse()によるバリデーションを追加 |

// After（自動修正後）
const taskSchema = z.object({
  title: z.string().min(1).max(100),
  description: z.string().max(1000).optional(),
})

export async function POST(req: Request) {
  const body = await req.json()
  const parsed = taskSchema.safeParse(body)
  if (!parsed.success) {
    return NextResponse.json({ error: parsed.error.flatten() }, { status: 400 })
  }
  const task = await db.task.create({ data: parsed.data })
  return NextResponse.json(task)
}

data: body をそのまま渡すコードは、Prismaのモデルに存在するフィールドなら何でも上書きできてしまいます。Zodによるスキーマ検証（型・長さ・必須チェック）を挟むことで、「受け取ってよいフィールドだけ」に絞り込めます。

パターン③: CSRF対策・JWT_SECRET・Cookie属性の欠落

ベンチマークでは他にも、以下のような認証系のセキュリティ漏れが複数検出されました。

• CSRF対策の欠落: 状態変更を伴うAPIエンドポイントにCSRF（クロスサイトリクエストフォージェリ）対策がない。/ai-dev-os-check は Server Action のみのケースは自動判定できないため Manual Review Required として報告し、手動確認を促します
• JWT_SECRET の例外処理欠落: process.env.JWT_SECRET が未設定の場合にエラーをスローせず、undefinedのまま処理が続いてしまう
• Cookie の Secure 属性欠落: HTTP通信でもCookieが送信されてしまう設定になっている

これらは「動いているように見えるが本番環境で穴になる」タイプの問題で、コードレビューでも見落とされやすいものです。

セキュリティ違反の検出・修正の詳細については、シリーズ④の記事（セキュリティ実証編 — 脆弱性発生率を48%から5%以下に下げた検証）で公開予定です。

チェック結果からの自動修正フロー — AIが違反を直す手順

レポートを出すだけでスコアは上がるのでしょうか？ ベンチマークの結果は「No」でした。

--dry-run と Check & Fix の違い

/ai-dev-os-check には2つの動作モードがあります。

• --dry-run モード: レポートを出力するだけ。コードは一切変更しません。
• デフォルト（Check & Fix）モード: レポートを出力し、Fixed Violations の修正をそのまま適用します。

この違いがスコアにどう影響したか、実測値がこちらです（ベンチマーク45試行平均・100点換算）。

条件	スコア（100点換算）	静的ルールのみとの差
ガイドラインなし（Before）	56点	—
CLAUDE.md + 静的ルールのみ	80点	ベースライン
+ --dry-run（レポートのみ）	80.8点	+0.8点
+ Check & Fix（自動修正）	89.9点	+9.9点

dry-runで0.8点しか上がらない理由はシンプルで、レポートを読んでも人間が手で全件修正するのは手間がかかるからです。件数が多いほどスキップが増え、修正漏れが生まれます。一方、Check & Fix なら Fixed Violations 全件をまとめて自動適用するため、網羅性が格段に上がります。

実際の操作フロー（6ステップ）

# 1. コードを生成（まだコミットしない）

# 2. コミット前にチェック＋自動修正
/ai-dev-os-check

# 3. Check & Fix Report を確認（30秒）
# → Passed / Fixed Violations / Manual Review Required の3セクションが表示される

# 4. Fixed Violations が自動適用される
# → Manual Review Required は目視で確認・対応

# 5. 変更内容を確認
git diff

# 6. 問題なければコミット
git add -p
git commit -m "feat: add task CRUD"

ステップ5の git diff は省略しないでください。AIは基本的に意図通りの修正をしますが、まれにリファクタリングの範囲が広がりすぎたり、ロジックに触れてしまうことがあります。差分確認はダブルチェックの最後の砦です。

全体の所要時間は60〜120秒。このフローをコード生成のたびに1回まわすだけで、品質が継続的に担保されます。

カスタマイズ — チェック項目の追加・除外

/ai-dev-os-check がデフォルトでチェックする対象は、CLAUDE.mdに記載されたガイドライン全体です。つまり、CLAUDE.mdを育てるだけでチェック内容も自動的に育っていきます。

チェック項目を追加する

プロジェクト固有のルールを追加したいときは、CLAUDE.mdに「L4ルール（プロジェクト固有）」セクションを追記するだけです。特別な設定ファイルを触る必要はありません。

たとえば、こんなルールを追加できます。

• 「コンポーネントには必ず Storybook ファイルを作る」
• 「全APIレスポンスには X-Request-ID ヘッダーを含める」
• 「Zodスキーマは src/lib/schemas/ ディレクトリに集約する」

CLAUDE.mdに書いた瞬間から、次回の /ai-dev-os-check 実行時にそのルールがチェック対象に加わります。

チェック対象から除外する

逆に「このルールは今のフェーズでは見ないでほしい」という場合は、CLAUDE.mdに ## /ai-dev-os-check 除外ルール セクションを追加します。

# My Project - Claude Code ガイドライン

## 開発ガイドライン
- docs/ai-dev-os/03_guidelines/common/security.md
- docs/ai-dev-os/03_guidelines/frameworks/nextjs/server-actions.md

## プロジェクト固有ルール（L4）
- 全APIレスポンスに `X-Request-ID` ヘッダーを含める
- Zodスキーマは `src/lib/schemas/` に集約する
- コンポーネントの Props は型エイリアスではなく `interface` で定義する

## /ai-dev-os-check 除外ルール
- performance.md: 現フェーズでは計測優先のため除外

チームで開発しているなら、スプリントごとに「今回重点的に守るルール」をL4に追加していくやり方がおすすめです。積み重ねていくうちに、そのプロジェクト固有の品質基準が自然と育っていきます。

あなたのプロジェクトで「AIに絶対守らせたいルール」は何ですか？ まずその1つをL4に書いてみてください。

Hooks連携 — コミット前に自動実行する設定

チェックの効果を最大化するには「チェックを忘れても走る仕組み」が必要です。Claude Code には Hooks という機能があり、コミットやメッセージ送信などの特定イベントに合わせてコマンドを自動実行できます。これを使えば、git commit のたびに自動で /ai-dev-os-check が走るようにできます。

設定手順

プロジェクトルートの .claude/settings.json に以下を追加します。

{
  "hooks": {
    "PreCommit": [
      {
        "type": "command",
        "command": "claude -p '/ai-dev-os-check --staged --dry-run'"
      }
    ]
  }
}

各オプションの意味

オプション	動作
--staged	ステージング済みのファイルのみを対象にする（git add したファイルだけ）
--dry-run	Check & Fix Report を表示するだけ。コミット自体はブロックしない

--dry-run をつけておくと、違反があってもコミットは通ります。レポートを見て開発者が自分で判断して対応する、という運用です。最初はこの設定から始めるのがおすすめです。

動作確認

設定後、以下のように通常どおりコミットするだけでフックが起動します。

# 設定後の動作確認
git add src/app/actions/task.ts
git commit -m "feat: add task creation"
# → PreCommitフックが起動してCheck & Fix Reportが表示される

Manual Review Required の項目が検出された場合はレポートに内容が表示されるので、コミット後に対応するかを判断できます。

自動修正も走らせたい場合

違反を検出したら即座に自動修正も走らせたい場合は、--dry-run を外して --staged のみにします。この場合、Check & Fix が実行されるため、+9.9点改善の効果も得られます。ただし、自動修正の内容は必ず目視確認することを推奨します。

Hooks を設定しておけば、/ai-dev-os-check を実行し忘れる心配がなくなります。「チェックする」という判断をしなくていい状態にしておくのが、品質を継続的に保つコツです。

よくある失敗と対処法

「Check & Fix で意図しないリファクタリングが走った」

なぜ起きるか: AIは「違反を修正する」際に、関連するコードをまとめて整理しようとすることがあります。修正の範囲が広がりすぎるケースが稀にあります。

対処: --dry-run で先にレポートを確認し、修正の方向を把握してから本実行してください。実行後は 必ず git diff で変更内容を確認 してからコミットするのが鉄則です。

「Manual Review Required の件数が多すぎて読む気がしない」

なぜ起きるか: ガイドラインにコンテキスト依存のルール（パフォーマンス系・可用性系など）が多いと、AIがすべてを Manual Review として報告するため件数が増えます。

対処: まず security: で始まる Rule の行を優先確認してください。それ以外は余力があるときに。件数を減らしたい場合は、CLAUDE.md の除外ルールセクションに performance.md を一時除外するのが手っ取り早いです。

「Hooks を設定したがレポートが表示されない」

なぜ起きるか: .claude/settings.json のファイルパスが間違っているか、JSON の構文エラーが原因であることがほとんどです。

対処: ファイルはプロジェクトルートの .claude/settings.json に配置してください（~/.claude/settings.json はグローバル設定で別物です）。設定後は cat .claude/settings.json で内容を確認し、JSON が壊れていないかチェックしてみてください。

この手法の限界

正直に書いておきます。

• 検出率100%はよく使われるパターンのみです。プロジェクト固有の実装や複雑なビジネスロジックが絡む違反は、Check & Fix でも検出できないことがあります
• AIのモデルバージョンが変わると挙動が変わる可能性があります。今回の実測データはある特定バージョンの Claude によるものです。同じ CLAUDE.md でも、モデルが更新されるとスコアが変動します
• 動的チェックは「ルール準拠」を確認するものです。ビジネスロジックが正しいか・要件を満たしているかは確認できません。「このAPIが仕様通りの動きをしているか」は人間が確認する必要があります
• 「ガイドラインを入れれば安全」ではありません。最終的な確認は人間が行う前提は、ガイドラインを導入しても変わりません

この手法は「完璧なシステム」ではなく、道具として使い続けながら育てていくものというスタンスで向き合うのがちょうどいいと思います。

まとめ

• 静的ルールだけでは85点が天井。CLAUDE.md を200行書いたら79点に下がった話で示した96.9点を支えていたのは、静的ルールではなく動的チェックの方でした
• /ai-dev-os-check の仕組みはCLAUDE.md解析 → git diff 取得 → Check & Fix Reportの3ステップ
• レポートはPassed / Fixed Violations / Manual Review Requiredの3セクション。security: 始まりのManual Review Requiredから優先的に対応する
• Rule列はL3（実装パターン）。「なぜ？」を知りたい場合は参照先ガイドラインファイルを開いてL2まで遡ると根本的な修正ができる
• Check & Fixで+9.9点、dry-runのみでは+0.8点（100点換算・45試行平均）。自動修正を走らせるかどうかがスコアに大きく影響する
• Hooks設定でコミット前に自動チェックが走る仕組みを作れば、チェック漏れをゼロに近づけられる

次回④: セキュリティ実証編 — AIが生成するコードの脆弱性含有率を48%から5%以下にした方法を、50回の実測データと実際の検出ログで解説します。

---

/ai-dev-os-check を使ってみて、どんな違反が検出されましたか？

思わぬ脆弱性が見つかった方も、うまく動かなくて困った方も、ぜひコメントで教えてください！

---

GitHub リポジトリ: AI Dev OS（MIT License）

関連記事

• AIが書くコード、毎回バラバラ問題を解決するOSSを作った
• CLAUDE.md を200行書いたら品質が79点に下がった話
• 【30分】Next.jsプロジェクトにAIコーディングのガイドラインを導入する手順（Before/Afterコード比較付き）
• AI生成コードのセキュリティ違反を44%から19%に削減した方法【バリデーション0%→100%の実測記録】
• 【プロンプトドリフト】AIで生産性20%上がった「つもり」が、実は19%遅くなっていた話