ai-audit マニュアル — 目的・使い方・メリット・監査内容

1. このスキルは何か

ai-audit は、AIコーディングエージェントで開発したシステムを、開発時の説明から切り離した別系統AIレビューと機械検査で評価し、その過程と結果を要求事項単位の証拠付き技術監査報告書として出力する、Claude Code / Codex 用のPreviewスキルです。既定は読み取り専用の audit-only です。別のAI提供者を使うことは組織的な第三者性を意味しません。

このシステムの目的

目的は、AI開発を無条件に安全だと宣言することではありません。要求、実施した検査、得られた証拠、判定、未検証事項、承認を一つの流れで追跡し、開発者以外にも説明できる状態を作ることです。同時に、レビュアーのいない個人開発でも、長いコードを一貫した基準で・複数の独立したAIで検査できる——これは人手だけでは現実的に難しい水準であり、AIによる支援の明確な実利です(詳細は「12. AIレビューが実際に強いこと」)。ただしそれは能力の話であって、安全の保証ではありません。

品質を見える化「問題なし」ではなく、何をどの方法で確かめたかを証拠と一緒に残します。

納品説明を標準化顧客、セキュリティ担当、外部専門家が確認しやすい共通資料を生成します。

限界まで正直に記録未実施の検査や残余リスクを隠さず、次に必要な専門検証を明らかにします。

利用するメリット

個人開発でも、レビュー・証拠保存・判定・承認を再現可能な手順にできます
受託案件で、品質管理を口頭説明ではなく納品物として示せます
外部診断へ渡す対象範囲と未検証領域が明確になり、説明の往復を減らせます
変更後に封印照合が失敗するため、「監査したコード」と「納品コード」の取り違えを検出できます

生成される標準成果物は次の6点です。

成果物	役割	読者
品質プロファイル(quality-profile.json)	対象種別、参照規格と版、適用レベル、技術評価結論を機械可読で固定する	発注元・セキュリティ担当・機械検証
要求マトリクス(requirements-matrix.csv)	要求ID、適用性、重要度、検証方法、証拠、結果、未解決事項を追跡する	品質保証・外部専門機関
監査報告書(audit-report.md)	技術評価結論(acceptable-within-scope/conditional/not-acceptable)・重大指摘・残余リスクを示す	経営層・決裁者・発注元
監査調書(audit-workpaper.md)	全検査のコマンド・ツールバージョン・マスキング済みAI出力。第三者が同じ監査を再実行できる証跡	技術者・外部専門機関
未検証面台帳(unverified-ledger.md)	「検証しなかった領域」の一覧。「指摘なし」と「安全」を区別する	全読者・外部診断の発注仕様
封印記録(seal.json)	生成物を除く監査範囲内の全追跡ファイルのハッシュ値。検証コマンドで変更・削除・追加を検出する	機械照合用

こんな人のためのスキルです ・AIでアプリ・業務システムを作ったが、「本当に大丈夫なのか」を口頭ではなく文書で示したい開発者(個人・企業を問わず)
・納品物に「AI開発でもここまで検証しています」という品質説明資料を付けたい個人開発者・開発会社
・官公庁・取引先などの監査・審査に説明責任を負う組織で、AIで作ったシステムの検証記録・証跡が必要な人

本スキルの文書設計は、公開された品質・セキュリティ標準、監査技法、セキュア開発の考え方をAI開発向けに整理したものです。「監査に耐える文書化」は、コードの実装力とは別に必要になる品質管理の技術です。

単発のコードレビューが欲しいだけなら、レビューコメントを返すツールで足ります。このスキルの価値は、「何を・どの基準で・どこまで検査し、何を検査していないか」まで文書として残ることにあります。

2. なぜ必要か(背景データ)

本スキルの監査基準は、公開された一次資料と公知標準を参照して設計しています。特定の数値をAI生成コード全般へ一般化せず、各研究の対象と条件を区別します。

生成コードは人間の検証を省略できない — NYUの2021年研究は、当時のGitHub Copilotを特定のCWEシナリオで評価した結果を報告しています。「40%」はこの実験条件の値であり、すべてのAIコードの一般値ではありません。
仕様適合はSASTだけでは判定できない — 静的解析と依存検査に加え、仕様・禁止事項とコードの突合が必要です。
過剰な自律性を分離する — 修正、欠陥注入、外部副作用を伴う試験は監査とは別の承認対象にします。
未検証を可視化する — 「検出なし」を「安全」と言い換えず、実施できなかった検査を台帳へ残します。
公開証拠を保護する — 秘密値を保存せず、マスキング済み出力と再実行手順を残します。

3. 仕組みの全体像

3-1. 異系統AI相互監査という考え方

実装するAIと監査するAIを開発元の異なる別系統にし、同じ会話の説明に引きずられない独立した観点を追加します。

正直な留保(重要)異系統AI監査の利点は研究に基づく理論的な期待であり、実証された保証ではありません。本スキルは報告書にもこの留保を必ず記載します。「AIがAIを監査するから完璧」という主張は、本スキルの思想と正反対です。

3-2. 説明分離レビュー

監査AI(Codex)には仕様書とコードを一次入力として渡し、実装AIの自己説明を根拠にしません。説明への誘導を減らすための手法ですが、組織上の独立性や第三者監査を成立させるものではありません。人間のレビュー担当者、利害関係、承認者は別に記録します。

3-3. 監査の流れ

4. 導入(インストール)

4-1. 前提

Claude Code(Anthropic)が動作していること
OpenAI Codex CLI が導入済みで codex exec が使えること(ChatGPTの利用枠を消費します)。Codexがない場合、スキルは縮退モード(Claude内部の別視点レビュー)を提案しますが、異系統AI監査の独立性は失われるため報告書にその旨が記録されます
対象プロジェクトが git 管理されていること。未管理の場合、スキルは勝手に初期化せず、封印不能として記録します

4-2. スキルの配置

# このリポジトリを取得して、skills/ 配下を Claude Code のスキルフォルダへコピー
git clone https://github.com/goonobu-dot/ai-audit-skill.git
cp -R ai-audit-skill/skills/ai-audit   ~/.claude/skills/
cp -R ai-audit-skill/skills/code-atlas ~/.claude/skills/   # 付属(任意)

# Codex の個人スキルとして使う場合
cp -R ai-audit-skill/skills/ai-audit   ~/.agents/skills/
cp -R ai-audit-skill/skills/code-atlas ~/.agents/skills/

4-3. 検査ツール(任意・推奨)

以下を導入するとツール層検査の精度が上がります。未導入でも動作します(代替手法で検査し、その限界を未検証面台帳に自動記録します)。

brew install gitleaks   # シークレット(APIキー等)検出
brew install semgrep    # 静的解析(SAST)
brew install jscpd      # 複製コード検出

semgrep利用時の注意semgrepはレジストリのルールを使う際にメトリクス(利用統計)を送信する既定動作があります。本スキルは --metrics=off を付けて実行する運用です。

5. 監査の実行手順

5-1. あなた(利用者)が準備するもの

仕様書(plan.md など):目的・主要機能・扱うデータを書いた文書。仕様書がないと監査は始まりません(「仕様通りか」を判定する基準がないため)。なければスキルが対話で1ページに文書化するところから始めます。
禁止事項リスト(仕様書内):「してはいけないこと」の明文化。例:「外部への通信を行わない」「ファイルを削除しない」「個人情報をログに書かない」。これが領域2(挙動の統制)の監査基準になります。

5-2. 実行

# 対象プロジェクトのフォルダで Claude Code を開き、
/ai-audit

既定では読み取り専用監査を進めます。修正や能動的試験は、初回結果を見た利用者が対象と副作用を明示承認した場合だけ実行します。

5-3. 実行例(サンプルプロジェクト)

本リポジトリの examples/memo-tool/ は、削除・入力検証・リンク追跡などの欠陥を持つ公開fixtureを読み取り専用で監査した再現例です。v1.1の9件の受入試験と逆向き検証は成功していますが、v1.2の要求ID単位で証拠を再収集していないため、技術評価結論を安全側の not-acceptable としています。過去の結果を新基準へ水増し移行しない例でもあります。

6. 監査パイプラインの詳細

前提確認 — 仕様書と禁止事項リストの存在確認、gitの状態確認(作業ツリーがクリーンであること)、対象コミットIDの記録、Codex CLIの動作確認。

リスク格付け — 影響度・データ機密度・自律性の3軸でシステムを格付けし、監査メニュー(簡易/標準/厳格)を決定。判定理由は監査調書に記録(詳細は第7章領域0)。

ツール層検査 — 機械で白黒つく項目:シークレット検出、通信経路の全数検索、静的解析、依存パッケージの実在確認(AIが実在しないパッケージ名を挙げる「slopsquatting」対策)、既知脆弱性(CVE)、ライセンス。全コマンドとバージョンを調書に記録。指摘には可能な限りCWE番号(脆弱性の世界共通の分類番号)を併記。

Codex別系統レビュー — 監査AIに仕様書とコードのパスを一次入力として渡し、重大度付きで判定。秘密値を除去した出力と正確なセッションIDを調書に記録。第三者性は主張しません。

修正ループ — 初回報告後に明示承認がある場合だけ修正し、同じセッションIDで全対象を再検証します。

能動的試験 — 別承認を得たうえで隔離環境だけで実施します。本番環境では実行しません。逆向き検証は本体を変更しないfixtureまたは一時worktreeで行います。

成果物生成と封印 — 生成物を除く監査範囲内の全追跡ファイルをSHA-256で封印。静的ファイルは自動更新されないため、公開・納品前に検証コマンドを実行し、差分があれば失効扱いにします。

7. 監査基準の解説(10領域)

監査基準書(skills/ai-audit/references/audit-standards.md)は10領域・約40項目で構成されます。各項目は [ツール](自動検出可能)/[判断](AI・人間の判断が必要)/[証跡](記録・文書で担保)のいずれかの検出層に属します。この章では「何を・なぜ調べるのか」を解説します。

領域0:リスク格付け(監査の前提工程)

何を:監査を始める前に、システムを3軸で格付けします。なぜ:使い捨ての個人ツールと、機密データを扱う全社システムに同じ監査をかけるのは過剰または過少だからです。1つでも「高」があれば厳格、すべて「低」なら簡易、それ以外は標準。

軸	低	中	高
影響度(誤動作時)	個人の手間が増える	部門業務に支障	全社業務・金銭・安全・信用に実害
データ機密度	公開情報のみ	社内情報	個人情報・営業秘密・制御データ
自律性	人間が毎回確認して実行	提案を人間が承認	人間の確認なしで自動実行あり

この「検証の深さをリスクに応じて変える」設計は、OWASP ASVS(セキュリティ検証標準)のレベル1〜3の考え方を借用しています(第8章参照)。

領域1:情報保護 — 「情報を外に出さない」の検証

多くの利用者・発注者が最初に不安に思う「個人情報・重要情報が漏れないか」を、4つの角度から検証します。

シークレット直書き検査 [ツール]:APIキー・パスワードがコードに埋め込まれていないか。AI支援で書かれたコードは機密情報の漏洩率が人間の約2倍という実測(GitGuardian 2026)があり、必須検査です。
データフロー検証 [判断]:データが「どこから入り、どこに保存され、どこへ出ていくか」の全経路を列挙し、仕様にない外部送信(API・ログ・テレメトリ)がないことを確認。ツールでは検出できない、判断層の中核です。
通信先の全数確認 [ツール+判断]:コードが接続する外部ホストをすべて列挙し、1つずつ正当性(仕様上の根拠)を判定。
おとり情報による漏洩試験 [判断+ツール](厳格メニュー):架空の個人情報(カナリアデータ)を投入して実運転し、ログ・通信・出力のどこかに現れたら不合格。「外に出ないはず」を実地で確かめる能動的試験です。実在の個人情報は絶対に使いません。

個人データを扱うシステムでは、個人情報保護法の安全管理措置(識別認証・アクセス制御・アクセス記録・暗号化・監視)との対応確認が加わります。

領域2:挙動の統制 — 「勝手な動作をしない」の検証(本スキルの独自価値)

既存の検査ツールが原理的にカバーしない領域であり、本スキルの中心です。

権限の最小化 [判断]:システムが持つ権限(ファイル・DB・ネットワーク・外部サービス)がすべて目的に対応づくか。OWASPの「Excessive Agency(過剰な自律性)」分類に対応。
不可逆操作の人間承認 [判断]:削除・上書き・外部送信・本番反映など取り返しのつかない操作に、確認ステップまたは実行前バックアップがあるか。AIエージェントによる本番DB削除事件(2025年)の教訓です。
ネガティブ要件の検証 [判断]:仕様書の禁止事項リスト全項目について、違反するコードが存在しないことを1件ずつ突合。従来の検収方法論にない、AI開発監査特有の検査です。
異常時の挙動 [判断]:想定外入力・接続断・権限エラーで「安全側に停止する」か(黙って壊れたり、暴走したりしないか)。
業務不変条件への連続攻撃 [判断](厳格):「何が起きても守るべき条件」(例:合計金額が合う、データが二重登録されない)を明文化し、重複操作・同時実行・日付境界・中断再試行のシナリオで攻撃して破れないか検証。

領域3:仕様適合・追跡可能性 — 「頼んだことが、頼んだとおりに」の検証

検収基準の事前確定 [証跡]:合否基準・テストケースが実装前に定義されているか(受託開発の定石の援用)。
要件トレーサビリティ [判断]:仕様の各要求⇔コード・テストの対応表を作り、対応のない要求(実装漏れ)と、仕様に根拠のない機能(頼んでいないものの混入)の両方向を検出。
受入テスト(UAT)[ツール+判断]:業務シナリオベースの実動作確認。スクリーンショット・実行ログを証跡として保存。
テストの実効性=逆向き検証 [判断]:AIが実装とテストを両方書くと、テストが「要件」ではなく「書いたコード」を追認するだけになる問題(テストの形骸化)が指摘されています。対策として、わざと欠陥を混入してテスト・検査が赤くなるかを確認します。検証後の欠陥除去はdiffで確認します。

領域4:セキュリティ品質(ツール層の中心)

静的解析(SAST)[ツール]:SQLインジェクション・XSS等の既知脆弱パターン。指摘はCWE番号で分類。
依存パッケージの実在・健全性 [ツール]:AIが実在しない名前を提案し、攻撃者が同名パッケージを登録するslopsquattingのリスクがあるため、全依存の実在・公開日・メンテナを確認します。
既知脆弱性(SCA)[ツール]:依存ライブラリの既知CVE照合。
非推奨API・サポート終了ランタイム [ツール]:AIの学習データは古いため、非推奨の書き方を提案しがちという構造的リスクへの対応。
入力検証・認証認可・暗号化の設計 [判断]:OWASP ASVSの該当章を参照した設計妥当性の確認。

領域5〜9:来歴・保守性・運用後保証・監査の規律・基本品質

領域	何を調べるか	なぜ
5. 供給網・来歴	生成記録(使用AIモデル・バージョン・日時・指示概要)、依存バージョン固定(lockファイル)、ライセンス検査	後から「誰が・何で・どう作ったか」を追跡できなければ、問題発生時に原因も責任も特定できない。AI生成コードの来歴標準は未確立のため本スキルが独自定義
6. 保守性・引継ぎ	複製コードの計測、構造の明快さ、説明文書(code-atlas等)とコード実態の整合	「作った本人(とAI)にしか触れないシステム」は組織にとってリスク。外部エンジニアに引き継げる状態は発注側の安心材料
7. 運用後保証	動作ログと保持期間、監視・通知、再監査トリガー、障害復旧手順	納品時点の安全は永続しない。国際的なAI管理規格(ISO/IEC 42001等)も「検証は一度きりでなく継続的に」を共通要求としている
8. 監査プロセス自体の規律	実装AIと提供元が異なる監査AI、独立再現モード、未検証面台帳、保証水準、再現可能性、調書、封印。同一提供元または来歴不明なら「異系統」と呼ばず、限定版報告として保証水準と意見を下げる	監査の信頼は「何を監査したか」だけでなく「監査がどう行われたか」で決まる
9. 基本品質(非機能)	性能、同時実行・データ整合性、バックアップの実復元試験、障害復旧演習	「安全だが業務で使えない」システムを通さないため。IPA非機能要求グレードの分類を発注者との共通言語に使う

8. 参照している公知の標準

本スキルの監査基準は、プロの受託開発・監査実務が拠り所にする公知の標準を参照して設計されています。

「準拠」ではなく「参照」— 誇張禁止の原則本スキルは認証を取得するものではないため、報告書では「ISO準拠」「ASVS認証」のような言い切りを禁止し、「〜を参照して設計した監査基準」と表記します。なお OWASP ASVS の一次文書自身が「OWASPは何も認証しない。第三者の『ASVS認証』の主張は非公式」と明記しており、この表記方針は標準側の推奨態度とも一致します。

v1.2では、適用した資料の名称・版・公式URL・取得日・適用レベルを quality-profile.json に固定し、各要求IDと証拠を requirements-matrix.csv で結びます。単に規格名を並べるのではなく、referenced、mapped、verified を区別します。

省略・空証拠・報告書改ざんを機械拒否AI-AUDITの54統制、ISO品質9特性、NIST SSDF v1.1の47 task ID、iOS時のMASVS v2.1.0全24統制とApple検査群を版付き母集団として照合します。元要求IDの重複と証拠ID・パス・ハッシュの要求間使い回しを拒否し、pass系の行には期待値、実測値、非空証拠、SHA-256を要求します。validate-report はJSONの結論とMarkdown見出し、代表的な禁止保証表現を照合します。

自由記述は人間が意味レビュー同義語や遠回しな表現を正規表現だけで完全判定することはできません。報告書は既定で外部提出不可です。外部提出では、人間の承認記録をOpenSSHで署名し、顧客がbundle外で管理する公開鍵で validate-release します。署名記録は報告書、profile本体、matrix、調書・未検証台帳・証拠を含むbundle manifest、sealのハッシュを結びます。公開鍵の本人性・権限・失効は顧客組織が管理します。

標準	それは何か	本スキルでの使い方
ISO/IEC 25010:2023	製品品質モデルを9特性で定義する国際規格。「品質とは何か」の共通語	領域9と要求マトリクスの品質分類
ISO/IEC/IEEE 29119-2:2021 / 29119-3:2021	テストプロセスとテスト文書の国際規格	テスト設計・監査文書の型
NIST SP 800-218 SSDF v1.1	セキュアなソフトウェア開発実務を整理したNISTのフレームワーク	開発・供給網・脆弱性対応の要求ID
OWASP MASVS v2.1.0	モバイルアプリのセキュリティ検証標準	iOS/Android案件の要求ID。iOSではAppleのPrivacy Manifest・Entitlements・署名証拠も追加
OWASP ASVS v5.0(2025年5月・17章)	Webアプリのセキュリティ検証項目を網羅した事実上の世界標準。検証の深さをレベル1(基本)〜3(最高保証)で段階化	レベル1〜3の考え方を監査メニュー(簡易/標準/厳格)に借用(設計思想の借用であり、要件の技術的同一視ではない)。領域4の設計妥当性確認
OWASP Top 10 / CWE Top 25	Webアプリの10大リスクと、危険なソフトウェア弱点の公的ランキング	領域4の検査対象定義。指摘のCWE番号併記(第三者機関との共通語彙)
OWASP LLM Top 10	AI(大規模言語モデル)応用の10大リスク分類。※実行時にAIを含む製品向けの基準であり、概念の援用であることを注記して使用	領域2の「Excessive Agency(過剰な自律性)」等の概念
IPA 非機能要求グレード	非機能要件(可用性・性能・保守性等6分類)について発注者と開発者が同じ言葉で話すための国内フレームワーク	領域9の分類
経産省システム監査基準(令和5年)	国内のシステム監査人の行為規範。監査技法(チェックリスト法・ドキュメントレビュー法・突合/照合法・ウォークスルー法等)を定義	検査手順の型・監査調書の型(一次資料で技法の列挙を確認済み)
経産省・IPA 情報システム・モデル取引・契約書〈第二版〉	受託開発の契約雛形。検収(検査→不合格時の修正→みなし合格)と契約不適合責任の構造を定義	報告書第9章(技術評価結論・承認・有効期限)の書式の参考
個人情報保護法(APPI)安全管理措置	個人データを扱う事業者に求められる技術的措置(識別認証・アクセス制御・記録・暗号化・監視)	領域1の検証項目
ISO/IEC 42001・NIST AI RMF(参考)	AIマネジメントの国際規格と米国のAIリスク管理フレームワーク。※AIシステム全般向けであることを注記して使用	領域7(ログ・継続監視・再監査)の翻案元

安全関連・OT・規制対象は強制停止安全関連インフラ、産業制御、機能安全などでは、一般IT向けの品質プロファイルだけで acceptable-within-scope にできません。案件固有の専門規格、ハザードから安全要求・試験・証拠・逸脱・承認までの追跡、FAT/SAT、独立V&V、責任者承認を別途要求します。このスキルは法定検査や運転許可を代替しません。

9. 監査報告書の読み方

報告書は9章構成です。設計上のルールとともに解説します。

章	内容	読みどころ
1. 経営要約	技術評価結論・重大指摘数・残余リスクを1ページで	適用範囲内の判断と未解決条件が分かる
2. 対象システムと業務目的	何のためのシステムで、壊れたら何が起きるか	非技術者の言葉で書かれる
3. 監査対象・範囲・同一性	対象コミットID・ハッシュ・対象外の明示	「監査したもの」と「動いているもの」が同じである証明
4. リスク格付けと検証深度	格付け理由と検証の強度	参照・対応付け・検証済みの違いに注意
5. 監査基準・方法・独立性	参照標準の一覧・独立再現モード・監査の限界	第三者がこの監査の設計を評価できる章
6. 総合結果・領域別評価	各領域を「適合/条件付き適合/不適合/未評価」の4値で	合格率・点数は意図的に使わない(重大な1件を平均が隠すため)
7. 重要指摘と修正結果	重大度・業務影響・修正・再検証の一覧(CWE併記)	「何が見つかり、どう直したか」の透明性
8. 残余リスク・未検証事項・利用条件	残る危険と、安全に使うための条件	「指摘なし」と「安全」は違う——検証しなかった領域は未検証面台帳に全件記載
9. 技術評価結論・有効期限・承認	結論(acceptable-within-scope/conditional/not-acceptable)・失効条件・承認欄	コードが変更されたら結論は失効。責任者の承認欄で「残余リスクを誰が受容したか」を記録

限定範囲の技術的検証結論は requirements-matrix.csv の行判定から機械的に導出します。acceptable-within-scope でも認証や無欠陥を意味しません。必須の未試験、重大な不合格、対象外、将来の脆弱性は別に開示します。

10. 第三者機関への引き継ぎ

この報告書一式は、外部のセキュリティ診断会社・監査人にそのまま引き継げるよう設計されています。

共通語彙:指摘にCWE番号・OWASP項目を併記しているため、外部機関は自社の診断項目と翻訳なしで突合できます
再実行可能な調書:使用ツール・バージョン・実行コマンド・対象コミットIDが記録されており、同じ検査を再現できます
未検証面台帳=外部診断の発注仕様書:「検証していない領域」の一覧が、そのまま外部機関に依頼すべき範囲になります。診断範囲の重複が省け、見積もりが正確になります
封印ハッシュ=照合キー:外部機関は受け取ったコードが監査対象と同一かを機械的に確認できます

位置づけとして重要なのは、本監査は外部の専門検証を置き換えるものではなく、外部検証を安く・速く・深くするための前工程だということです。外部診断の初期工数の多くは「このシステムは何がどう作られているか」の把握に消えます。そこが文書で渡れば、専門家の時間は未検証領域の深掘りに使えます。

11. code-atlas(付属スキル)

code-atlas は、コードを読めない人が「コードを読んでいるかのように」システムの中身を把握できる、単一HTMLの「システム地図」を生成する付属スキルです(/code-atlas で実行)。

左に機能一覧、中央にデータフロー図(配管図イメージ)、各処理ステップに根拠チップ(ファイル名:行番号)——クリックするとコード抜粋と平易な解説が開きます
すべての説明に根拠リンクが付くため、「AIの説明を信じる」のではなく「説明とコードの対応を検証できる」文書になります
ai-audit の監査成果物がある場合、生成時の封印検証結果と監査バッジを表示します。後日の変更を自動検知しないため、再表示前にアトラスを再生成します
外部依存ゼロの単一HTMLなので、社内ネットワーク・オフラインでもブラウザで開けます

実例は examples/memo-tool/atlas/index.html をブラウザで開いてください。

12. 別系統AIレビューで実際に見つかった欠陥(観測された事例)

なぜ別系統AIの監査に実利があるのか レビュアーのいない個人開発では、長いコードを一貫した基準で最後まで読み切ること自体が難しい。人は疲れ、飽き、後半ほど注意が落ちます。ここは別系統AIの強みです——疲労や飽きなく全ファイルを同じ観点で検査し、しかも開発元の異なる複数のAIで独立にクロスチェックできます。

これは抽象論ではなく、本プロジェクト自身の開発で観測された事例があります。直近の2026-08-25、実装AI(Claude)とは別系統のCodex(OpenAI)とGrok(xAI)にこの監査ツール自身を独立監査させたところ、実装AIが見落としていた欠陥を、再現手順つきで複数検出しました:①外部送信bundle生成が --output 先の既存ディレクトリを無条件削除しうるデータ消失リスク、②封印(seal)の除外リストを自己申告で信用するため全ソースを除外した「空の封印」が valid と判定されるバイパス、③依存脆弱性スキャンが空結果やCVSS 9.8を「問題なし」で通す fail-open、④非エンジニア向けサンプルが旧コードを「機械確認済み」と表示していた陳腐化。いずれも修正し、再発防止の回帰テストと機械ゲート(verify-atlas 等)を追加しました。過去には、ある秘密トークンを一方の検出器が見逃しもう一方が捕捉した例もあります。

ポイントは「AIは万能」ではなく、実装者と認知を共有しない別系統が、実装者の思い込みを外して実行証拠で欠陥を突くという一点です。数百行のコードをレビュー体制なしに一貫検査する現実的な手段の一つがこれであり、その検査を仕組みとして再現できることに実利があります。

——ただしこれは「見つける力がある」という能力の話であって、「だから安全だ」という保証ではありません(限界は次章)。能力は事実と再現手順で述べ、保証は述べない——この区別を、本スキルは一貫して守ります。

13. 限界と免責(必読)

本スキルが保証しないこと

本監査はAIによる監査です。未知の攻撃手法、監査AI自身の盲点は検出できません
異系統AIの組み合わせは理論的な対策であり、両方のAIが同じ誤りをする可能性はゼロではありません
監査時点の知識・脆弱性データベースに基づきます。将来公表される脆弱性は対象外です
監査の依頼者と監査の運用者が同一人物である場合(個人利用の典型)、組織的な意味での完全な第三者性はありません。これを補うのが「再現可能な調書」(誰でも同じ監査を再実行できる)です
本スキルおよび生成される報告書は、法令上・契約上の保証や専門家(公認会計士・情報処理安全確保支援士等)による監査を代替するものではありません。重要システムでは人間の専門家による検証を併用してください

これらの限界は、生成されるすべての報告書・未検証面台帳に自動的に記載されます。限界を隠さないことが、このスキルの信頼の根拠です。

別系統AIによる自己評価(2026-08、率直な現在地) 注:以下はこのツールの構成要素であるAI自身による自己評価であり、利害が一致した内部評価です(独立した第三者評価ではありません)。参考値として読んでください。

本スキルは、実装したClaudeとは独立に、Codex(OpenAI)とGrok(xAI)の2つの別系統AIへ「外部の専門審査に耐えるか」を評価させました。外部審査到達度を5段階中3と評価しています。

高く評価された点:誇張表現の機械的な禁止、重大未合格を通さないfail-closed設計、証跡と未検証の構造化。
不足として一致した点:①敵対的コードに対する実行時の隔離 ②証拠の真正性(誰が・いつ・実際に実行したかの証明) ③標準要求カタログの網羅性 ④外部LLMへ送るデータの多層防御 ⑤異系統AI監査の性能の実証データ。

v1.3ではこのうち④(送信前DLP・秘密検出の拡張・外部提出時の指紋除去)、①の運用規律(隔離実行の明文化)、証拠の署名分離を反映しました。さらにv1.3.1では、同じ3体のAIによる再監査で「v1.3の改善が基準・文書には書かれたが機械ゲートに接続されていなかった」不一致を発見・修正しました——外部提出ゲートが指紋除去モードを使っていなかった抜け、新統制が必須母集団に入っていなかった抜け、実施者≠承認者が宣言のみで自己承認を許していた抜けの3点です。これは「監査の仕組み自体を、別系統AIが監査して穴を見つける」ことの実例です。それでもなお、到達しうる現実的上限は「外部診断会社が前工程として信頼できる」水準(4/5)であり、監査法人・情報処理安全確保支援士が無条件に信頼する水準(5/5)は、人間の資格者の関与と第三者タイムスタンプ機関が構造的に必要で、本ツール単体では到達しません。この線引きを宣言すること自体を、本スキルは誠実性の一部と考えます。

v1.5では、セキュリティ・監視・監査の強化として「入口の機械ゲート」を追加しました——外部AIへコードを渡す前に秘密・個人情報を機械的にマスクする送信前DLP(既定は全文脈を保ったまま秘密だけを伏せるので、外部AIの能力を落としません)と、コミット前に秘密の混入を止めるゲート(gitleaksと同梱パターンの両方を走らせ、どちらかが見つけたら止める)です。これまで文書に書いてあるだけだった防御を、実際に動くコードにしました。3体のAIによる会議とOSSの徹底調査で、個人開発者に過剰な常時監視は載せず、少数の強いゲートに絞る方針を確認しています。

v1.8(2026-08-25)では、同じ3体AIの再監査が「宣伝と実装の食い違い」と「機械ゲートのバイパス」を実証——外部送信bundleの既存ディレクトリ削除、封印の全除外バイパス、依存スキャンの空通し、サンプル可視化の陳腐化を修正し、CVSSの数値評価・封印除外の制限・生成物の verify-atlas 整合検査・回帰テストを追加しました。「このツール自身が、別系統AIの監査で毎回まだ穴を指摘される」という事実こそ、独立監査に実利がある最も正直な証拠です。

14. よくある質問

Q. AIは何個必要ですか? Claude Code と Codex の2つだけでも使えますか?

はい、Claude(実装)+ Codex(独立監査)の2つが正式サポートの最小構成です。「作った本人以外の目」が1つ入るので、異系統AI監査の核心である認知的独立性は2つで成立します。Cursor経由のGrokを加えた3つは推奨構成で、監査役をラウンドごとに交代でき、単一チェッカーの盲点への過剰適合を防げます。Claude単独(1つ)は縮退モードで、独立性が無い旨を報告書に明記し結論を安易にacceptableにしません。監査AIは環境変数でモデルを選べます。

Q. AIを2つ・3つにすると、具体的に何が良くなりますか?

別ベンダーのAIごとに"見る癖"が違うため、それぞれ別々の欠陥を見つけます。これは実証済みです——本スキル自身をv1.8開発時に3AIで再監査したところ、GrokとCodexは重複しない別々の穴を検出しました。Grokは「削除許可の目印ファイル偽装」「CVSS 9.8を"低"と誤判定」を、Codexは「入力symlinkのすり抜け」「壊れた検査結果を"問題なし"と誤読」「CIが全履歴でなく現在ファイルだけを検査」「ゼロファイル封印」を——といった具合に手分けして発見し、一方で最初の監査では両者が同じ重大バグ(データ消失リスク等)に揃って警告しました。重要なものは全員一致で、細かいものは別々に発見されるため、複数の別系統AIほどカバレッジのUNIONが広がります。全工程を常時3AIで回すのはコストに見合わないため、実装はClaude・独立監査を別ベンダーへ、という分担で運用します。ただしこれも保証ではなく、確率的な補強です。

Q. 監査に通れば安全ということですか?

いいえ。「実施した検査の範囲で問題が発見されず、発見された問題は修正・再検証済み」という意味です。何を検査していないかは未検証面台帳に明記されます。この正直さが本スキルの設計思想です。

Q. 人間のコードレビューの代わりになりますか?

個人開発・小規模開発で「レビューする人がいない」状況の実用的な代替として設計されていますが、人間の専門家によるレビューが可能ならそれに勝るものではありません。第10章の通り、外部専門家への引き継ぎを前提とした設計です。

Q. どのくらい時間・コストがかかりますか?

小規模プロジェクト(数百行)で、Codex呼び出し2〜4回+ツール検査で30分前後が目安です。CodexはChatGPTプランの利用枠を消費します。

Q. 監査後にコードを1行でも変えたらどうなりますか?

封印(seal.json)のハッシュと一致しなくなり、技術評価結論は失効します。再監査(差分中心なので初回より速い)を実行してください。この厳格さが「監査済みのものと動いているものが同じ」という信頼の担保です。

Q. 自分のプロジェクトは仕様書がないのですが。

スキルが対話で「目的・主要機能・禁止事項・扱うデータ」を1ページに文書化するところから始めます。この仕様書化自体が、AI開発の品質を大きく上げる最初の一歩です。

15. 副業・受託開発で使う

営業で伝える価値は「絶対に安全」ではなく、品質確認の工程と限界を説明できることです。提案時、開発中、納品時の3段階で同じ要求マトリクスを更新すると、品質確認が後付けになりません。

段階	使い方	顧客へ渡すもの
提案前	対象範囲、禁止事項、個人情報、外部連携、必要な検証深度を確認する	監査予定範囲と対象外の一覧
開発中	要求IDとテスト・証拠を対応付け、重大指摘を修正して再検証する	要求マトリクスの中間版
納品前	コードを封印し、報告書・調書・未検証台帳を検証する	標準6成果物と利用条件
外部診断	未検証面台帳を外部専門家の検査範囲へ変換する	再実行手順と対象コミット

提案書で使える表現「公開標準を参照した要求マトリクスを作成し、機械検査・別系統AIレビュー・人間承認を区別して記録します。報告書には未検証事項と残余リスクも記載します。」

料金メニュー、契約上の境界、納品時の説明順、公開ポートフォリオの作り方は、副業・受託開発での活用ガイドにまとめています。営業先への説明、責任分界、納品物、第三者機関への引継ぎを一つの流れで示す場合は、印刷・PDF保存対応の企業向け「セキュリティ・監査付き納品」の説明資料を使用してください。

16. 公開時の情報保護

公開リポジトリと監査サンプルには、作者や利用者の勤務先、職歴、顧客名、案件名、実データ、端末の絶対パス、メールアドレス、秘密値を含めません。業界例が必要な場合も、個人との関係を示さない一般的な表現と架空データを使います。

監査前に対象コードと仕様書の秘密値・個人情報を確認する
AI出力と監査調書はマスキングしてから保存する
公開前にREADME、docs、Issue、Git履歴、成果物を再確認する
判断に迷う情報は公開せず、利用者側で差し替えられるプレースホルダーにする

具体的な確認コマンドと承認チェックは、公開前プライバシー・秘密情報チェックを利用してください。