検査の範囲と限界（Cheloop）

版: 1.1.0 ／ 作成日: 2026-10-08 ／ 改訂: 2026-11-12 ／ 施行日: 2026-11-11 ／ 対象: Cheloop 1.1.0（AI との接続を含む版。macOS／Apple Silicon）・自社静的ルール 1.10.0・DB 対応表 1.1.0・Firebase の rules 検査 1.1.0・公開URL検査 url-check-0.1.0

本文書は、「Cheloop（チェループ）」（以下「本製品」）が何を検査し、何を検査しないかを説明します。本製品は、事業者（個人事業主を含みます）に限って販売します。本文書は利用規約から参照され、アプリ内と販売サイトから閲覧できるようにします。本文書の記載は本製品の実装（ルール台帳・DB 対応表・検査エンジンの版）と一致させ、実装を変えるときは本文書も同時に更新します。

1. 標準表示文

結果画面・すべての export（JSON・Markdown・HTML）に、次の文を一字一句そのまま表示します。

この結果は、今回実施した検査の範囲内での確認結果です。検出がない場合も、脆弱性が存在しないことやアプリの安全性を保証しません。未検査項目を確認し、必要に応じて追加の診断を実施してください。

2. 本製品が行うこと（概要）

本製品は、対応する言語・ルール・依存情報・取得可能なレスポンスについて、特定時点で問題候補を検査する補助ツールです。

• 対象: 利用者が選択したフォルダー（端末内）のファイル。JavaScript/TypeScript、Next.js、React、npm/pnpm/yarn の lockfile を主な対象とします。
• 検査の方法: ファイルを読み取るだけです。依存関係のインストール、アプリの起動、npm scripts の実行、ビルド、対象コードの実行はしません。対象のデータベースや管理 API へは接続しません。
• 規模の上限: 選択フォルダー内の 10,000 ファイル・合計 100MB・1 ファイル 2MB まで。上限を超えた分と除外したファイルはレポートに記録し、検査済みとは扱いません。
• 既定で除外するもの: .git node_modules .next dist build coverage とバイナリファイル。選択フォルダーの外を指すシンボリックリンクはたどりません。.env 類は秘密情報の検査の対象に含め、見つけた値は伏せ字にし、値そのものは検査結果に保存しません（検査の間の一時的な複製と、伏せ字の限界は、4.1 のとおりです）。
• ビルドの出力先と判定した out/: フォルダー名が out で、同じ階層の package.json が読めて、electron-vite の設定ファイル（electron.vite.config.*）がある・package.json の main・module が out/ を指す・scripts に next export か --outDir out／--out-dir out がある、のどれかに当たるときだけ、ビルドの成果物として既定で除外します（検査前の確認の除外の内訳に表示します）。名前が out でも、この条件に当たらないフォルダーは検査します。ビルドの成果物に埋め込まれた値（環境変数等）は、元のソース・設定の検査で見つける前提で、成果物そのものは検査しません。
• 入れ子の git リポジトリ・worktree・submodule: 選択フォルダーの下で、リポジトリの形をした .git（HEAD・objects・refs を持つディレクトリ、または HEAD を持つ先を指す gitdir: のファイル）を持ち、選択フォルダーのリポジトリがその配下のファイルを追跡していないフォルダーは、別の作業コピーのためたどりません。検査前の確認には「入れ子の git リポジトリ／worktree（別の作業コピーのため対象外）」の件数と相対パスを、レポートには件数だけを表示します。選択したフォルダー自体の .git は通常どおり既定の除外として扱います。
• 走査の順序: 各階層で、ファイル（.env 等の . で始まるものを含む）、. で始まらないフォルダー、. で始まるフォルダー（隠しフォルダー）の順にたどります。上限に達した場合に、隠しフォルダーが本体のコードや .env より先に上限を使い切らないようにするためです。
• Git の履歴は検査しません（現在のファイルだけを見ます）。
• 対応言語以外のファイルは、秘密情報の検査だけを行い、言語固有の検査は「未対応」と表示します。
• 同梱の検査エンジン（Gitleaks・OSV-Scanner）の起動: 選択フォルダーの中にある実行ファイルは実行しません。同梱の検査エンジンは、置き場所に関係なく（本製品の中にある場合も、ビルドした本製品をリポジトリの release/ 等に置いたまま、そのリポジトリを検査する場合も）、同梱時に記録したハッシュ（sha256）と一致することを確認してから、選択フォルダーの外の一時フォルダー（利用者だけが読み書きできる権限）へ複製し、複製のハッシュも同じ値と一致することを確認してから複製を実行し、その検査の終了時に一時フォルダーごと削除します（確認の後に元のファイルが差し替えられても、実行するのは確認した複製です）。ハッシュが一致しない実行ファイルは、場所に関係なく実行しません。複製・確認ができなかった場合は、その検査エンジンを「失敗」とし、理由を表示します（検査エンジンが検査対象のフォルダーの中にある場合は「検査エンジンが検査対象のフォルダーの中にあるため起動しませんでした」、それ以外は「検査エンジンを一時フォルダーへ複製して照合できなかったため起動しませんでした」）。自社静的ルール・DB 検査の解析の処理（worker）とその部品は、ビルド時に記録したハッシュ（sha256）と一致することを確認してから読み込み、一致しなければ解析を実施せず「失敗」とします。Supabase の migration の SQL の構文解析に使う部品（WASM）が一致しない場合は、その部分の構文解析を行わず、該当する migration を要確認とし、DB 検査は一部未完了とします（解析の処理全体は止めません）。これらの確認は、本製品のファイルを、本製品を使う利用者と同じ権限で動くほかのプログラム（同じ macOS の利用者として動くマルウェア等）が書き換えることを防ぐものではありません。そのようなプログラムは、確認から実行・読み込みまでの間に差し替えられる余地があり、確認そのものを外すこともできます（同じ利用者の権限で動く攻撃者は、この確認の対象外です）。また、この確認の処理を含む本製品の共有の部品は、起動時にこの確認をせずに読み込んでいます。
• 検査時間の上限: 検査全体 10 分、各検査エンジン 5 分。超えた場合は停止し、その検査は「失敗（制限時間超過）」、検査全体は「一部未完了」として表示します。

3. 結果の読み方

3.1 結果の分類

未実施・失敗・除外・未対応の項目は、検査済みではありません。 結果画面の上部に「重大問題」「開発用の部品の重大な脆弱性」「要確認」「検査未完了」を別々に表示し、検査未完了の件数を隠しません。重大問題は、検出事項のうち危険度 Critical・High のもので、開発用の依存（devDependencies 等）からだけ届く依存パッケージ（依存の種類が「直接依存（開発用）」「間接依存（開発用のみ）」のもの）を除きます。依存の種類を判定できないものは重大問題に含めます。除いたものは「開発用の部品の重大な脆弱性」として件数を別に表示し、一覧からは消しません（危険度・分類は変えません）。AI への依頼で AI が「誤検知」と報告した修正の依頼の検出事項も、重大問題に数えたままにし、そのうちの件数を「AI が誤検知と報告（未確認・重大問題の数には含めています）」として重大問題の近くに別に表示します（3.7。アプリは確かめていません。数から外すのは、あなたが確かめて非表示にしたときだけです）。依存の種類は lockfile の記録だけから判定しており、開発用と判定したものが本番のビルドに取り込まれる場合があります。また、開発用の部品の脆弱性も、開発者の端末や CI（自動ビルド）に影響することがあり、安全という意味ではありません。重大問題には、利用者が対応する単位で数え直した「対応単位」（依存パッケージの lockfile・パッケージ・版の組の数、秘密情報の候補のファイルの数、それ以外の件数）を併記します（件数そのものは 1 件ずつのままです）。結果画面とレポートは同じ集計を使います。

3.2 検査の状態

検査の状態は「完了（今回の検査範囲内）」「一部未完了」「失敗」「取消」などで表示します。対象としたすべての検査エンジンが成功したときだけ「完了（今回の検査範囲内）」とし、一部の検査が完了していない場合を成功として表示しません。0〜100 点の点数や、安全を示すバッジは表示しません。

3.3 検出事項が 0 件のとき

検出事項が 0 件の場合も、標準表示文を同じ画面に並べて表示します。検査が失敗・取消で終わった場合は、検出事項の有無を判断できる結果ではないと表示します。

3.4 危険度と確信度

危険度（Critical / High / Medium / Low / Info / Unknown）と確信度（高・中・低）は独立した評価です。Critical は直接的な重大影響を裏付ける限定的なルールにだけ使います。依存関係の脆弱性は情報源の severity・CVSS をそのまま表示し、情報源に無ければ Unknown とし、推測で数値を作りません。危険度は色だけでなく記号と文字でも示します。

3.5 再検査の比較

前回の同じプロジェクトの検査と比べて「新規」「引き続き検出」「今回未検出」「比較不能」を表示します。

• 「今回未検出」は、前回その項目を検出した検査が今回も成功し、同じファイルを解析したうえで今回は検出されなかったことだけを意味します。修正済みであることは意味しません（書き方が変わって検出条件から外れた可能性があります）。
• 検査の失敗・未実施、ファイルの除外・削除、検査の版の違いなどで同じ条件にならない場合は「比較不能」とします。
• 結果画面の「前回からの変化」は、同じプロジェクトの前回の完了した点検（失敗・取消した点検を飛ばした、完了または一部未完了の最も新しい点検）との比較を、今回の点検で見つからなくなったもの（上の「今回未検出」。以前の表示名は「直ったもの」）・新しく出たもの（「新規」）・残っているもの（「引き続き検出」と「比較不能」。比較不能は「今回は確かめられませんでした」と添えます）として数えます。「今回の点検で見つからなくなったもの」は、同じ条件で点検して、前回の検出が再検出されなかったことだけを意味します。修正済みであること、問題が消えた証明ではありません。アプリ全体の安全性も意味しません。比較不能を「見つからなくなったもの」に数えることはありません。今回の点検が最後まで終わらなかったときや、同じ規則の検出が同じファイルにまだあるときも、「見つからなくなったもの」には数えず「残っているもの」として扱います。誤検知として非表示にした項目は数えません。
• AI への依頼で、AI が「修正した」と報告した項目は、報告ではなく次の点検の結果で確かめます。同じ項目が見つからず、そのすべてが「今回未検出」なら「点検で見つからなくなった」に数え（直ったと断定はしません）、まだあれば「前回『修正した』と報告されましたが、まだ残っています」として列の先頭に戻します。どちらとも言えなければ「今回の点検では確かめられませんでした」と表示します。業務上の認可などの手動確認項目と、要確認の項目への確認・対応の依頼は、正しく直しても点検に出続けることがあるため、まだあっても「まだ残っています」とはせず列の先頭にも戻さず、「確かめられませんでした」に数えます（手動確認項目は毎回、手で確かめる項目のため、無くなっても見つからなくなったとは数えません）。この表示も、再検出されなかったことだけを示し、問題が消えたことを保証しません。

3.6 誤検知として非表示にした項目

利用者が非表示にした項目は削除せずに記録し、レポートには除外件数を表示します。結果画面の検出事項から非表示にするときは、利用者が理由を書いて非表示にします。AI への依頼の列の「誤検知と報告済み」の行（3.7）では、「誤検知として非表示にする」を 1 回押すだけで、理由の入力と見直しの期限の選択を求めずに、決まった理由「AI の誤検知の報告を確かめて非表示にしました。」と既定の 90 日の見直しの期限で非表示にします。非表示にしたことは、その項目に問題が無いことを意味しません。

結果画面の検出事項から非表示にするときは、見直しの期限（30 日・90 日・1 年・期限なし。既定は 90 日）を選びます。選ばなければ 90 日です。選んだ期限は、非表示の記録に日時（expires_at）として保存します。期限なしの場合は空です。期限が過ぎた非表示は自動で効かなくなり、その項目は通常の表示（件数・確認項目・前回からの変化・AI への依頼）に戻り、「見直しの期限が来ました」と、非表示にした日と理由を添えて表示します。期限の前でも、結果画面の非表示の一覧から「元に戻す」で取り消すことができ、取り消した項目は次の表示から通常の表示に戻ります。元に戻したときは、その日時（revoked_at）を非表示の記録に書き、記録そのものは消しません。期限が来た項目には「見直し済み（表示のままにする）」の操作が出ます。これを押すと、元に戻すのと同じく revoked_at を書いて、「見直しの期限が来ました」の添え書きを消し、その項目を通常の表示のままにします。もう一度非表示にしたときは、同じ記録を新しい理由・日時・期限で上書きし、revoked_at を空に戻します。同じ組・同じ依頼でまとめて非表示にした項目は、まとめて元に戻ります。期限・取り消しは表示の計算だけを変え、保存済みの検査の結果は書き換えません。期限が来ても定期的な通知はしません（結果を開いたときに表示します）。この版より前に非表示にした項目は、期限なしとして扱います（見直しの期限は来ません。非表示の一覧から元に戻せます）。

3.7 確認項目とアプリの判定

結果画面とレポートは、要確認と手動確認項目を「何を確かめるか」でまとめた 確認項目 として示します（「確かめること N（対象 M 件）」）。1 件ずつの検出・比較・非表示の記録は変わりません。

• アプリの判定: 通信も AI も使わずに、テスト・検査用のファイルの読み込み関係（JS/TS の import・require・import() と、パスとして使われ得る文字列のファイル名、package.json の入口）、コマンド実行・eval / new Function・SQL 文の組み立て・dangerouslySetInnerHTML の値の出どころ（選択フォルダーの中のほかのファイルの定数・呼び出し元まで。dangerouslySetInnerHTML は参考の判定だけで確認済みにしません）、秘密情報の候補の値の形を調べた結果です。方法と限界を各項目に示します。判定できないものは「判定できず」として人の確認に回し、確認済みにしません。アプリの判定は、問題が無いことや安全性を保証するものではありません。文書・テスト内の秘密情報の候補は、値の形の判定だけでは確認済みにしません。
• 読み込み関係の判定の限界: 次の場合は、読み込み関係を「判定できず」とします。(1) ファイルの列挙に上限があり、本番側のファイルを全部は調べられなかったとき。(2) .vue・.svelte・.astro・.mdx の本番用のファイルを解析していないとき。一方、読み込みとして扱う書き方は import・require・動的 import に限らず、createRequire・import.meta.resolve・module.require・jest/vi のモック用の補助関数（jest.mock・vi.mock 等）も含みます。既定で除外するフォルダー（dist・build・.next・coverage 等。どの階層でも）の中のコードからの読み込みは確認していません。ビルドの出力先と判定した out の中のコードからの読み込みも確認していません。git 管理外のビルド・配布の出力先（.gitignore 等で除外され追跡されていない release/・out/・dist/ 等の下）のコンパイル後の .js・.mjs・.cjs は、元のソースから作られた生成物として読み込み元にしていません（.ts・.vue 等は読み込み元に含めます。ほかの検査の対象からは外しません）。文字列のファイル名のうち、和文・句読点を含む文章の中のファイル名と、空白を含む和文でない文字列のうち空白で区切った語にテスト・検査用のフォルダー（tests・fixtures 等）を含むパスが無いもの（どちらもコマンドの実行（exec・spawn・zx の $ 等）に直接渡す文字列を除く）、同じファイルの文字列にも、そのファイルが import しているファイル（1 段）のパスの形（/ を含む）の文字列にもテスト・検査用のフォルダー名が出てこないファイル名（*.test.*・*.spec.* 等のファイル名だけでテスト用と分かるものを除く）は、読み込みとして数えていません。このため次の読み込みは見逃すことがあります: import していないファイル・2 段以上先のファイルの定数や関数でだけテスト用のフォルダーを指す読み込み、埋め込み式のあるテンプレート文字列（`${dir}/x.json` 等。文字列での参照を調べていません）で組み立てるパス、空白を含むパス（テスト用のフォルダー名を含む語とファイル名が別の語に分かれるもの）、和文・句読点を含む文章の中に書いたコマンドやパス。
• 値の出どころの判定の限界: 値の出どころを、選択フォルダーの中の JS/TS のファイルの定数と呼び出し元まで、構文（型検査なし）から調べています。関数の戻り値・環境変数・データベースや外部から読み込む値・実行時に変わる設定・CommonJS の書き方・選択フォルダーの外のコードは追跡していません。フレームワーク・実行環境（Web のルート・API の関数・サーバーレスの handler 等）が呼び出す関数は呼び出し元を辿らず、その引数は外から値が入り得るものとして扱います。アプリの判定であり、外から値が入らないことを保証するものではありません。読み込み先を特定できない指定子があるとき等は、ほかのファイルの呼び出し元を辿らず、その理由を各項目に示します。辿る段数（3 段）・ファイル数（50 ファイル）・記号の数・時間に上限があり、超えた値は解決できないとして扱います。Function コンストラクタ（Function(...)・new Function(...) とその別の呼び方）・文字列のタイマー（setTimeout・setInterval に文字列を渡す書き方）・eval・with などで組み立てた難読化された動的なコードは、値を静的に決められないため解決できないものとして扱います。表（オブジェクト・配列）の要素のうち、キーが文字列などの固定の値でないもの（計算したキー等）は、出どころを「解決できず」として扱い、安全側の判定にはしません。結果はアプリによる機械の判定であり、問題が無いことの証明ではありません。
• 確認済み（あなたの確認）: 利用者が理由を書いて確認済みにした記録です（まとめて・1 件ずつ・質問への回答から）。アプリは回答や理由の正しさを確かめません。「確認した人」の名前は任意で、入力した場合はレポートに含まれます。前提（読み込み元・値の出どころ・確認項目の種類）が変わると記録は無効になり、もう一度確かめるよう表示します。
• 質問の方針: 確認項目の質問は、すべて AI（Claude Code 等）にそのまま渡せる 確認の依頼 として AI への依頼の列に入れ、利用者には質問しません（ファイルの実際の置き場所が同期・共有されるフォルダーの中か、本番の Supabase のテーブルで RLS が有効か、データを他の人に見られてよいか、他の人のデータ・管理者だけの画面や API を守る作りか、本番のコードがテスト・検査用のファイルを実際に読み込むか、値の出どころ、デプロイに含まれるか、鍵が本物か等）。AI が確かめられないこと（本番のデータベースに接続できない、実際の置き場所が分からない等）は、依頼文で「判断できない」と報告するよう求め、推測で「該当しない」にさせません。「判断できない」と報告された項目は「あなたの作業待ち」に残ります。ファイルをメール・チャット等で他の人に送ったかどうかは、アプリも AI も確かめていません。
• AI の答えの引き継ぎ: 前の点検で記録した AI の報告の答えのうち、安全側の答えだけ（「該当しない」に当たるもの。「該当する」「判断できない」は引き継がず、次の点検でもう一度確認の依頼を出します）を、同じ確認項目・同じ質問・同じ対象（検出事項の組）・同じ確認の前提で、確認項目の質問集の版が同じときだけ、次の点検に引き継ぎ、同じ確認の依頼を出し直しません。引き継いだ答えは「前回の点検から引き継ぎ」として元の日時（日本時間）とともに表示し、レポートの回答の表にも載せます。認可の確認は点検ごとに確かめるため引き継ぎません。対象の確認済みを取り消した場合や、「もう一度 AI に確認する」を押した場合は引き継ぎません。アプリは AI の報告の正しさを確かめません。
• 確認済み（AI の報告をあなたが記録）: 確認の依頼に対する AI の報告の最後の返信ブロックの結果（「該当しない」「該当する」「判断できない」）を、利用者が AI の報告の集め箱に入れ、「記録の内容を確かめる」の確認の画面で内容を確かめて「確定して記録する」を押して記録したものです。「該当しない」を記録すると、その確認項目の対象は確認済みになり、利用者が自分で答えた確認済みと区別して表示・レポートします。アプリは AI の報告の正しさを確かめません。 これはアプリの検証ではなく、AI の報告をあなたが記録したものです。AI の報告が誤っている可能性があります。前提が変わると記録は無効になる点は、ほかの確認済みと同じです。AI の報告は、その依頼文をコピーした後だけ記録できます。また、前の点検の AI の報告を引き継いで、アプリが確認済みにすることがあります（下の「AI の答えの引き継ぎ」。引き継ぐのは安全側の答えだけです）。そのときの答えの確認した人は「AI の報告（前回の点検から引き継ぎ・<元の報告の日本時間の日時>）」、確認済みの理由は「前回の点検の AI の報告（結論: 該当しない）を引き継いで記録」と表示します。
• AI の報告の貼り付けと集め箱: 依頼文の最後に、AI に決まった形の返信ブロックを書かせます。利用者が AI の返事を貼り付けて「集め箱に入れる」を押すと、本製品は返信ブロックを AI の報告の集め箱 に入れます。集め箱に入れた内容は、端末の中に一時的に保存します（最長 30 日）が、確定するまでは、判定・確認済みの記録には反映しません（集め箱の返事は、記録する前は「返事あり（まだ記録していない）」と表示されます）。記録するのは、利用者が「記録の内容を確かめる」を押し、確認の画面で中身を確かめて「確定して記録する」を押して確定したときだけです。本製品は決まった欄の決まった値（結果・挙動の変化の有無・テストの結果）だけを読み、記録・判定に使います。「理由」「挙動の変化の内容」の文は、秘密らしき値を伏せ、端末のパスを置き換えた後の文だけを集め箱に入れて表示し、記録した後は検査履歴と同じく 30 日保存しますが、記録・判定には使いません。集め箱は 1 アプリにつき 200 件までで、入れてから 30 日で消え、検査履歴の削除・プロジェクトの削除でも消えます（プライバシーポリシー 2.2・2.5）。集め箱を使えるのは、そのアプリのいちばん新しい点検の画面だけです。入れる段では、返信ブロックを 1 つずつ照合し、受け付けられない返信ブロック（形が読めない・その依頼文をコピーした記録が無い・最新の点検が未完了のときの前の点検の依頼への報告等）だけを理由とともに断り、ほかの返信ブロックは入れます。貼り付けの全体が長すぎる・返信ブロックが多すぎる（1 回に 20 個まで）・返信ブロックが無いときは、何も入れません。同じ依頼への同じ中身の報告は 1 つにまとめ、同じ依頼への中身の違う報告（または同じ依頼に別の依頼番号の報告）は「2 通あります」として両方を残し、どちらを使うか選ぶまで記録できません。「記録の内容を確かめる」を押すと、集め箱のすべての報告を、確定の直前にいちばん新しい点検でもう一度照合します。通らない報告（入れた後にその依頼文をコピーし直した・まとめで渡し直した・「あとで」にした等の古い報告を含みます）が 1 つでもあれば何も記録せず、報告ごとに理由を示し、「この報告を外す」で外せます（記録は全部か無かです）。依頼番号は点検ごとに違い、その依頼文をコピーした記録が無い報告は記録しません。点検し直した後に前の点検の依頼文への報告を入れた場合は、同じ依頼がいちばん新しい点検の列にあるときだけ、いちばん新しい点検に記録します。アプリは AI の報告の正しさを確かめません。
• AI への依頼のまとめ（まとめてコピー・書き出し）: AI への依頼をまとめて、アプリごとに、設定した件数（5・10・20 件のどれか。既定は 10 件）まで 1 本の依頼文にし、点検の画面でコピーするか、登録したアプリの分をまとめてファイルに書き出せます。中身は 1 件ずつコピーするときと同じテンプレートの依頼文で、本製品は AI へ送りません。まとめに入れた依頼は、依頼文をコピーしたものとして記録し、その依頼の「あとで」の印を外します。書き出すのは、最新の点検が完了していて、まとめに入れる依頼があるアプリだけです（ライセンスの上限の外のアプリは書き出しません）。書き出しは、あなたが書き出しのボタンを押したときだけ行い、自動の点検の後に自動で書き出すことはありません。書き出し先は、ホームフォルダーの下で、かつ検査の対象のフォルダーの外に限ります（既定は ~/Desktop/Cheloop/まとめ依頼/）。書き出し先やアプリのフォルダーが登録したアプリのフォルダーと重なる（中にある・同じ・含む）ときや、重なりを確かめられないときは書き出さず、検査の対象のフォルダーには書き込みません。AI が書き出し先に書いた返信ファイル（返信.md）は、一覧や点検の画面を開いたとき・ボタンを押したときだけ探し、フォルダーの見張りはしません。見つけただけでは集め箱に入れず、記録もしません（取り込めるかを確かめるために中身を読みます）。あなたが「返信ファイルを取り込む」を押すと、返信ファイルの返信ブロックを集め箱に入れます（確認の画面を挟まず、まだ記録しません）。記録するのは、貼り付けと同じく、あなたが「記録の内容を確かめる」の確認の画面で中身を確かめて確定したときだけです。読み方と入れる・記録する決まりは、上の「AI の報告の貼り付けと集め箱」と同じです。取り込んだ返信ファイルは、断られた返信ブロックが 1 つも無く、全体の誤りも無いときだけアプリのフォルダーの 取込済 に移します（ひな形のままのブロック・集め箱に同じ報告があるもの・記録済みの報告と同じもの・点検し直して検出事項が見つからなくなった依頼への返事（下記）は、断られた数に入れません）。断られた返信ブロックがあるときは返信ファイルを動かさず、そのまま残します。「この返信を使わない」を選んだ返信ファイルも 取込済 に移します。どちらも消しません。点検し直した後に前の点検の依頼への返事を入れるとき、最新の点検が完了していて、その依頼の検出事項が最新の点検で 1 つも見つからなくなっていれば、その返事は集め箱に入れずに飛ばし、飛ばした数を表示します。「記録の内容を確かめる」の確定の直前の照合で同じ状態になった報告も、記録せずに飛ばして数え、確定したときに集め箱から消します。最新の点検が未完了のときなどは飛ばさず、入れる段ではその返信ブロックだけを断り、確定の直前の照合では何も記録しません。アプリは AI の報告の正しさを確かめません。
• AI との接続（MCP）: 利用者がアプリの設定で AI との接続を入にしたときだけ（最初は切。同意の前は入にできません。切はいつでもできます）、同じ Mac の中で、利用者が登録した AI のコマンドラインツール（当初の対象は Claude Code と Codex）が、依頼文を受け取り、返信ブロックを集め箱に入れ、再点検を始められます。AI が受け取る依頼文は、画面のまとめと同じ選び方・件数の、同じテンプレートの依頼文で、受け取った依頼は依頼文を渡したものとして記録します。AI から受け取った報告は、利用者が画面で確かめて確定するまで記録しません。集め箱に入れる段と確定の決まりは、上の「AI の報告の貼り付けと集め箱」と同じです。集め箱に記録していない報告があるアプリは、AI から再点検を始められません（先に、利用者が「記録の内容を確かめる」で確かめて記録します）。AI からの再点検は、1 アプリにつき 1 時間に 6 回までです（アプリを再起動すると数え直します）。AI が始めた再点検は、前回の点検と同じ設定（OSV への照会の有無・オフラインかどうか）で行います。公開 URL 検査を含んだ点検は、AI から再点検を始められません。AI が示したフォルダーが、登録したフォルダーとは別の作業ツリー（git worktree 等）のときは、依頼を出しません（登録したフォルダーで作業するか、そのフォルダーを登録してください）。AI が誤検知と報告しても、重大問題の数は減らしません（下の「誤検知と報告済み」と同じです）。同じ利用者のほかのプログラムは、この接続を使えます。これは、同じ利用者のプログラムが本製品のデータのファイルを直接読めるのと同じ範囲です。管理者権限のないほかの利用者のプログラムからは使えません（接続のためのファイルの権限で限っています。同じ端末の管理者権限からの完全な隔離は保証できません。プライバシーポリシー 2.1）。本製品から外部への通信は増えません（外部への通信について 4.1）。アプリは AI の報告の正しさを確かめず、AI が依頼のとおりに作業したことも確かめません。
• 誤検知と報告済み: AI が「誤検知」と報告した修正の依頼は、AI の主張として列の下のほうに出し続けます。アプリは確かめていません。AI が誤検知と報告しても、重大問題の数（対応単位・重大問題の内訳を含みます）は減らしません（2026-10-21 から 2026-10-25 の 0.6.18-draft までは、秘密情報の候補と CISA KEV を含む依頼を除いて重大問題から外していましたが、0.6.19-draft で改めました）。結果画面とレポート（JSON・Markdown・HTML）の概要には、重大問題のうち AI が誤検知と報告したものの件数を「AI が誤検知と報告（未確認・重大問題の数には含めています）」として別に表示します（秘密情報の候補と、実際に悪用が確認された脆弱性（CISA KEV に載っているもの。3.10）を含む依頼も同じに数えます）。検出事項の危険度・分類・一覧・件数は変えません。AI の報告を記録する前の確認の画面では、誤検知と報告された依頼ごとに、アプリが見つけた場所（ファイル:行）と伏せ字にした根拠を表示し、根拠にコメント（//・/* */・<!--・#・--）が含まれるときは「根拠にコメントが含まれます」と添えます（見るのは伏せ字にした根拠の抜粋だけで、隣の行のコメントは見ていません）。AI の報告の理由は、コードの中のコメント等に書かれた指示に影響され得るため、この場所と根拠をあなたが見て確かめてください。「列に戻す」を押すと AI の主張が外れます。検出事項の中身が変わると通常の列に戻ります。件数から外すには、あなたが確かめたうえで、その行の「誤検知として非表示にする」を 1 回押して非表示にします（理由の入力は求めず、決まった理由と既定の 90 日の見直しの期限で記録します。3.6 と同じ扱いです）。AI が「直せない」「利用者の作業が必要」「判断できない」と報告した依頼も、同じく「あなたの作業待ち」として出し続けます。
• 認可の手動確認（AUTHZ-001〜003）の確認済みは、その検査の中だけ有効です。認可はアプリの変更で変わるため、検査ごとに確かめてください。AI の報告を記録した場合も、それは あなたが外部の AI から得て記録したもので、本製品は、AI がコードを読んだこと、実際に試したこと、報告の内容が正しいことを確かめていません。業務上の認可の手動確認は、引き続きあなたの確認が必要です（誰がどのデータを見たり変えたりできるかは、アプリも AI の報告も保証しません）。
• git の履歴（過去にコミットした鍵等）は検査していません。

3.8 ループの記録の保存

点検・依頼・もう一度点検するの流れ（ループ）の記録は、この端末の中にだけ保存します。回ごとの要約（loop_rounds）は、件数などの数だけを持ち、パス・パッケージ名・検出内容は持ちません。30 日の自動削除の対象外で、1 プロジェクトにつき新しい 400 回分まで保存し、検査履歴の削除・プロジェクトの削除で削除されます。AI への依頼の列の記録（依頼文をコピーした回数と日時・単位の識別用ハッシュ）と、まとめてコピー・書き出しの 1 回ごとの記録（まとめの種類・件数・書き出しのフォルダー名・日時）は検査履歴に付き、30 日で削除されます。「もう一度点検する」は URL を引き継ぎません（入力した URL の一覧は、もう一度点検するためには保存しないため、点検の前の確認の画面で入れ直します。検出事項に含まれる対象の URL は、検査結果に保存します）。詳しくはプライバシーポリシー 2.2・2.5 を参照してください。

3.9 自動の見張り（毎日の部品の照会と週 1 回の自動点検）

• 毎日の照会は、記録した lockfile から部品の名前・版を読み、OSV に照会して、前回の照会と比べて新しく該当した脆弱性を知らせます。照会だけでは、点検の結果（依頼文）は変わりません。依頼文に入れるには、もう一度点検してください。
• 週 1 回の自動点検は、手動の「もう一度点検する」と同じ点検です。公開 URL の検査は外します。前回と比べて、新しい重大問題と新しい確かめることを知らせます。
• 前回の照会・点検が無い・失敗した・照会した lockfile の組み合わせが違うときは、比べられないと扱い、新しいものとして数えません。比べられないことは知らせます。
• 結果は、点検・照会をした時点のものです。Mac の電源が切れている・眠っている・フォルダーを読む許可が無い等で見張れていない間に起きたことは分かりません。予定の 2 回分を続けて完了しなかったときは、そのことを知らせます。

3.10 悪用の情報（CISA KEV・EPSS）の印と並び

• 依存関係の脆弱性（OSV に照会した検出事項）のうち、CVE の番号で照合できたものについて、米国 CISA の「悪用が確認された脆弱性の一覧」（KEV カタログ）に載っていれば「緊急 悪用を確認」の印を付け、FIRST の EPSS（今後 30 日以内に悪用の動きが観測される確率の推定値）の値と百分位を表示します。あわせて、自分のコードの import の文字列が見つかったかどうかを表示します。
• 印と値は、どれから確かめるかを決めるための判断の補助です。一覧と修正指示の並び順に使いますが、検出事項の件数・危険度・分類・重大問題の数は変えず、一覧から外したり、まとめて隠したりしません。
• KEV・EPSS の一覧は、OSV への照会に同意した点検で受け取ります（受け取る条件・頻度と、部品・プロジェクトの情報は送らないこと、接続に伴って相手に伝わる情報（接続元の IP アドレス・User-Agent・要求の時刻・KEV の前回の ETag）は、プライバシーポリシー 3.1 と「外部への通信について」2.1 に書いています）。受け取れないときは、端末のキャッシュか、アプリに同梱した KEV の控えを使い、使った一覧の日付を結果に示します。データの日付が点検の開始より 14 日以上前（日本時間の暦日で数える）なら、古いことを示します。EPSS は同梱しないため、受け取れず、キャッシュも無いときは表示しません。
• 自動の見張りの照会で、該当中の脆弱性が新しく KEV に載ったときは知らせます（最初の照会は、比べる基準を作るため知らせません）。
• KEV・EPSS の情報を使った点検の結果とレポートには、次の限界の文を示します。
  • KEV・EPSS はその時点の情報です。KEV に載っていないこと、EPSS の値が低いことは、安全を意味しません。
  • CVE の番号が無い検出事項は、KEV・EPSS と照合できません。照合できなかったことは、悪用されていないことを意味しません。
  • 「使用の有無」は、自分のコードの import の文字列が一致したかどうかだけで判定しています。import が見つからなかったことは、使っていない証明ではありません。文字列で指定する設定のプラグイン、npm: の別名、変数を通した require、フレームワークの自動の読み込み、ビルドの道具、コマンドとしての利用は取りこぼします。
  • KEV・EPSS のデータは、通信路（TLS）と形の検査だけで受け取っており、配布元の署名は確かめていません。誤ったデータを受け取っても、変わるのは並び順と印だけで、検出事項の件数や分類は変わりません。
• 出典: CISA Known Exploited Vulnerabilities Catalog（CC0 1.0）、EPSS（FIRST.org、データの提供 Empirical Security）。

4. カテゴリごとの検査範囲と限界

4.1 秘密情報

• 検査すること: 同梱の Gitleaks v8.30.1（既定ルール、Git 履歴なしのファイル検査、値を伏せた出力）と、自社の限定ルール SEC-001（Supabase の秘密キー）・SEC-002（ブラウザーへ公開される環境変数に入った秘密）で、秘密情報の候補とファイル・行を表示します。見つけた候補の値は伏せて表示し、値そのものは検査結果に保存しません。ただし、検査の間は、検査対象のファイル（.env 類を含みます）を一時フォルダーへ平文のまま複製します。伏せ字には限界があり、検出できなかった秘密情報が抜粋などに残る場合があります。詳しくはプライバシーポリシー 2.3・2.4 を参照してください。
• 検査しないこと・限界: Git の履歴、分割・符号化・暗号化された値、ルールに無い形式の秘密、実行時に読み込まれる値は検出できません。Supabase の anon key・publishable key は公開を前提とした値のため、それだけでは秘密の漏えいとして扱いません。
• git 管理外のファイル: 選択フォルダーの .gitignore・.git/info/exclude・.git/index と、この Mac の git の設定（~/.gitconfig・$XDG_CONFIG_HOME/git/config（未設定なら ~/.config/git/config）・環境変数 GIT_CONFIG_GLOBAL の指すファイル・選択フォルダーの .git/config）の core.excludesFile が指す全体の無視設定（未設定なら $XDG_CONFIG_HOME/git/ignore・~/.config/git/ignore）を読み（git コマンドは実行しません。設定・無視設定の内容は保存・送信しません）、.gitignore 等で除外され追跡されていないファイルでの SEC-001（Gitleaks・自社ルール）・DB-004 の候補は「要確認」（危険度は Medium まで）とし、題名に .env 類なら「（git 管理外のローカル設定ファイル）」、それ以外のファイルなら「（git 管理外の作業ファイル）」を付けます。ただし .env 類以外でビルド・配布の出力先（out/・dist/・build/・release/・.next/・.output/・.vercel/output/・.svelte-kit/・.netlify/・storybook-static/）の配下にあるものは、配布物に入り得るため危険度を変えず、根拠に「git 管理外の生成物（配布される可能性があります）」と添えます。現在 git で追跡されていません。過去にコミット・push していた場合は履歴に残っているため、その場合は失効・再発行してください（本アプリは git の履歴を検査していません）。端末・バックアップ・共有を経由した漏えいの影響は残るため、バックアップ先と共有範囲の確認と、漏えいの疑いがあるときの失効・再発行を案内します。git で追跡されているファイルは分類を変えず、.env 類なら根拠に「git で追跡されています」と添えます。git で追跡されている文書・テストのファイル（tests/・test/・fixtures/・docs/ 配下（選択フォルダーの直下、または packages/・apps/ 等の各パッケージの直下にあるもの）、どの階層でも __tests__/ の下、*.md・*.mdx・*.rst・*.txt（secret・token・key・env 等を名前に含む .txt を除く）、*.test.*・*.spec.*）の SEC-001 の候補は、「要確認」（危険度は Medium まで・確信度 Low）とし、題名に「（文書・テスト内）」、根拠に「テスト・文書内（ダミー値の可能性）」と添えます（重大問題・対応単位には数えません）。ただし、値が発行元固有の形式で実在のキーと同じ長さ・ばらつきがあるもの（AWS の AKIA・ASIA、GitHub の ghp_ 等・github_pat_、Stripe の sk_live_・rk_live_、Supabase の sb_secret_・service_role の JWT（Supabase CLI のローカル用の既定値を除く）、Anthropic の sk-ant-、OpenAI の sk-proj- 等・旧形式、Slack の xox、Google の AIza、Gitleaks の秘密鍵（private-key）。確信度を高にします）は、文書・テストの中でも危険度を変えず、根拠に「テスト・文書内ですが、値が実在のキーの形式と長さに一致します」と添えます。Stripe のテストモードのキー（sk_test_）は実在の秘密ですが本番の値ではないため、この例外に含めません。DB-004 は危険度を変えず、確信度だけ Low にして同じ注記を添えます。git の状態を判定できない場合（.git が無い、選択フォルダーの外を指す .git ファイル、未対応の index の形式・split index、コミットがあるのに index が無い、読めなかった .gitignore の配下、走査が上限で途中まで止まった階層等）は分類を変えません。大文字小文字だけが違う名前で追跡されているファイルは、追跡中として扱います（core.ignorecase が false のときは判定しません）。全体の無視設定は git と同じく最も優先度が低く、.git/info/exclude・.gitignore の否定（!）が優先されます。設定に include・includeIf がある、core.excludesFile の値が無い・~user/・%(prefix) の形、設定・無視設定のファイルを読めない場合は全体の無視設定を反映しません（追跡も除外もされていないファイルとして扱います）。system の設定（/etc/gitconfig 等）の core.excludesFile は読みません。全体の無視設定はこの Mac の git の設定によるため、同じフォルダーでも Mac ごとに判定が変わることがあります。SEC-002（ブラウザーへ公開される環境変数）は git に関係なく配布物に入るため、この扱いにしません（テスト・検査用のファイルの扱いは 4.3 のとおり）。
• ダミー値・例示: Gitleaks の候補のうち、値の形から、典型的なダミー値・例示の可能性が高いと推定したもの（空の代入で次の環境変数名を値と取ったもの（例: A_KEY= B_KEY= npm run …）、環境変数の参照（${TOKEN}・$TOKEN・process.env.X 等）、<token> のような山括弧の例示、xxxx のような伏せ字、プレースホルダーの語だけの並び（例: local-dev-token・your-api-key・changeme。パスワードらしいキー名の値は対象外）、発行元の接頭辞の直後にテスト用の目印（e2e・test・dummy・fake 等）があり実在のキーの長さに満たない値（例: sk-proj-e2e-…））は、「条件を満たした」（危険度 Info）とし、題名を「ダミー値・例示（秘密情報としては扱いません）」にします。重大問題・要確認には数えず、総評にその件数を書きます。判定は値の形だけによるもので、秘密情報でないことを確認したものではありません。実在のキーの形式と長さに一致する値と Stripe のテストモードのキーは、この扱いにしません。
• curl の認証ヘッダー: Gitleaks の curl-auth-header の値（表示する先頭）は、Authorization（Bearer・Basic 等の後のトークン）・X-API-Key 等のヘッダーの値から取り、行はヘッダーのある行にします。ヘッダーを特定できなければ先頭を出さず（•••）、一致が複数行にまたがるときは開始行のまま根拠に「（照合が複数行にまたがる）」と添えます。
• 識別子らしい値（スラッグ）: Gitleaks の generic-api-key のうち、値が英小文字・数字とハイフンだけの形（例: abc-12）で、英大文字・16 文字以上の 16 進・20 文字以上の base64 風の連続・UUID を含まず、ハイフンを除くと 16 文字以上の 16 進だけになるものでもないものは、ID・名前等の識別子の可能性が高いため、消さずに「要確認」（危険度 Low・確信度 Low）とし、題名を「識別子らしい値（スラッグ）の秘密情報候補」にします。キー名が分からないとき、またはキー名が秘密らしい名前（secret・token・password・api_key・auth・private・access・creds・pwd・passphrase・encrypt・signing・session・master・jwt・hmac・cookie 等を含む）のときは、値の形に関係なくこの扱いにしません。判定は値の形だけによるもので、秘密情報でないことを確認したものではありません。
• git のコミット番号等の識別子: Gitleaks の sourcegraph-access-token の候補のうち、次の全てに当てはまるものは「条件を満たした」（危険度 Info）とし、題名を「git のコミット番号等の識別子（秘密情報としては扱いません）」にします（重大問題・要確認には数えません）。ファイル名がライセンス・告知・SBOM の文書（LICENSE*・LICENCE*・NOTICE*・COPYING*・THIRD_PARTY_NOTICES*・CREDITS*・ATTRIBUTION*（拡張子が無いか .md・.txt・.rst・.html 等。THIRD_PARTY_NOTICES* は .json も）、*.spdx*・*.cdx.json・bom.json・sbom*.json）で、名前やフォルダーに secret・credential・token・private・key・.env 等を含まない。値が git のオブジェクト ID の形（40 桁の英小文字の 16 進。64 桁は直前に sha256・object id とあるときだけ）。同じ行の値の直前に commit・sha・blob・tree・rev（revision）・hash・oid・object id の語、または git+…# の URL がある。キー名が key・secret・token・pass・cred・auth・sign・priv を含まない。Gitleaks 8.30.1 の sourcegraph-access-token は sgp_ の無い 40 桁の 16 進にも一致し、ファイルのどこかに sourcegraph の語があれば対象になるため、ライセンス文書に記録した取得元の commit・blob の番号が一致することがあります。ビルド・配布の出力先の下でも同じ扱いです。これ以外（他の規則、ライセンス等の文書でないファイル、文脈の無い値）は、Sourcegraph の旧形式のアクセストークン等この形の実在のキーがあるため、従来どおり秘密情報の候補として表示します。判定はファイル名・同じ行の文脈・値の形だけによります。
• 過去に公開された鍵は、コードから削除しただけでは無効になりません。鍵の失効・再発行は発行元で利用者が行ってください（本製品は鍵の変更を行いません）。

4.2 依存パッケージの既知の脆弱性

• 検査すること: 同梱の OSV-Scanner v2.6.0 で lockfile（npm・pnpm・yarn）を読み、OSV（api.osv.dev）に照会して、既知の脆弱性・対象バージョン・修正版・情報源 ID と取得日時を表示します。
• 外部への送信: 利用者が検査前に同意した場合だけ実施します。送信内容と送信先はプライバシーポリシーと「外部への通信について」に記載しています。同意しない場合・オフライン設定の場合は「未実施」、通信に失敗した場合は「失敗」（検査全体は「一部未完了」）と表示します。プロキシ経由の接続には対応していません。
• 限界: lockfile に記載された依存だけが対象です。lockfile が無い場合は「未実施」です。脆弱性情報は OSV に登録された既知のものに限られ、登録の遅れや未登録の脆弱性は検出できません。到達可能性は未評価です（アプリが該当の機能を実際に使っているかは確認していません）。依存関係のインストールや更新は行いません。
• 表示: 同じ lockfile・パッケージ・版の既知の脆弱性は 1 つにまとめて表示し（保存・比較・非表示は脆弱性ごと）、重大度の段ごとに「依存の種類」（直接依存（本番）・間接依存（本番経路あり）・依存の種類を判定できず・直接依存（開発用）・間接依存（開発用のみ））の順に並べます。依存の種類は lockfile（pnpm-lock.yaml v6/v9・package-lock.json v2/v3・yarn.lock v1/berry）と同じフォルダーの package.json だけから判定し、危険度は変えません。全件を解消する最小の修正版は、誤検知として非表示にしたものを除く同じパッケージの全ての脆弱性について、情報源の影響範囲から互換性のある範囲（同じメジャー系列。0.x は同じマイナー、0.0.x は同じパッチ）の中で導けた場合だけ表示します（導けない場合は脆弱性ごとの修正版を表示します）。
• 概要の内訳と更新の候補: 重大問題の内訳を「依存パッケージ（本番経路あり）」「依存の種類を判定できず」「その他の検出事項」に分けて表示し（開発用のみのものは重大問題に含めず、「開発用の部品の重大な脆弱性」として別に表示します）、危険度が情報源（GitHub Advisory 等）の一般的な値で、アプリの使い方での影響（到達可能性）は評価していないことを添えます。「次に確認するとよい更新」では、同じ lockfile・パッケージ・版ごとに上記の最小の修正版で解消が見込まれる件数を数え、依存の種類 → 修正版を特定できたもの → 解消見込みの Critical の件数 → 解消見込みの Critical・High の件数 → 解消見込みの総数の順に上位 5 件を示します。示した版より新しい版に上げる場合は、その版でも再確認が必要です。修正版を導けない場合は「修正版を情報源から特定できません」（互換性のある範囲の中に無い場合は「（互換範囲内の修正版なし）」を添えて）と表示し、版を推測しません。間接依存には、親パッケージの更新や lockfile の再生成で解消する場合があることと、lockfile のグラフ（pnpm-lock.yaml・yarn.lock）から分かる場合は経由する直接依存の例（最大 3 件）を添えます。いずれも見込みであり、更新後の動作や解消を確認したものではありません。
• 悪用の情報（CISA KEV・EPSS）の印と並び、import が見つかったかどうかの表示: 3.10 のとおりです。危険度・件数は変えません。
• 実行コマンド（bin）を含む本番の依存の補足: dependencies にある直接依存のうち、lockfile に実行コマンド（bin）を含むと記録されたもの（pnpm-lock.yaml の hasBin・package-lock.json の bin。yarn.lock は記録が無いため対象外）で、JS/TS のファイルからの import・require が見つからないものについて、開発時だけ使うなら devDependencies へ移すと、その依存を経由するだけの本番経路にある既知の脆弱性が開発用に分類される見込みであることを補足します（件数は pnpm-lock.yaml でだけ数えます）。CSS（.css・.scss）からの @import 等の有無も添えます。import の有無は構文から読み取った指定子だけによるもので（設定ファイルの文字列での参照、実行時の読み込み等は見ていません）。package.json の scripts でパッケージ名・コマンド名が使われているもの、JS/TS のファイルを全て解析できなかった場合、.vue・.svelte・.astro・.mdx のファイルがある場合は補足しません。依存の種類・危険度・件数は変えません。

4.3 危険なコード・Next.js/React の設定（自社静的ルール 1.10.0）

型検査をしない構文解析（AST）による限定的な判定です。関数の戻り値の流れ・実行時の設定は追跡していません。別ファイルの定数・呼び出し元は、3.7 の範囲と限界のとおり一部だけ辿ります。ルールに一致しないことは、問題が無いことを意味しません。

.gitignore 等で除外され git で追跡されていない作業ファイル（ビルド・配布の出力先を除く）での CODE-001〜005・DB-001 の候補は「要確認」（危険度は Low まで）とし、題名に「（git 管理外の作業ファイル）」を付け、配布・デプロイ対象外の可能性が高い旨を添えます。ビルド・配布の出力先の配下は危険度を変えず、根拠に「git 管理外の生成物（配布される可能性があります）」と添えます。

テスト・検査用のファイル（選択フォルダーの直下、または packages/・apps/ 等の各パッケージの直下の tests/・test/・fixtures/・fixture/・testdata/・test-data/・__tests__/・__fixtures__/ の配下（tests/e2e/ 等を含む）、どの階層でも __tests__/・__fixtures__/ の下、*.test.*・*.spec.*）での CODE-001〜005・CFG-001〜002・SEC-002・DB-001〜004・SUPA-001〜005・FB-001〜006 の候補は、git の状態に関係なく「要確認」（危険度は Low まで）とし、題名に「（テスト・検査用のファイル）」を付け、何が困るかの先頭に「テスト・検査用のファイルです（意図的に脆弱に書いた見本の可能性があります）。本番のコードから読み込まれていないか確認してください。」と添えます（重大問題・対応単位には数えません）。src/app/api/test/ のように本体のコードの中にある test という名前のフォルダーは対象にしません。Supabase の migration から判定する SUPA-001〜003・005 は、migration のフォルダー自体がテスト・検査用のフォルダーの下にある場合だけこの扱いにします（ファイル名が *.test.sql 等でも、supabase/migrations の本物の migration は下げません）。Firebase の Security Rules から判定する FB-001〜005 は、そのファイルを指す firebase.json がすべてテスト・検査用のフォルダーの中にある場合だけこの扱いにします（テスト・検査用のフォルダーの外の firebase.json が指していれば、本番に配備され得るため下げません）。ビルド・配布の出力先の配下と、上記の git 管理外の作業ファイルの扱いになるものは、この扱いにしません。ただし、確認項目のアプリの判定（3.7 の読み込み関係）で、そのファイルが本番のコードから読み込まれている（import・require・パスとして使われ得る文字列・package.json の入口）と判定できたときは、危険度・分類を元に戻し（重大問題・対応単位にも数えます）、何が困るかの先頭に「テスト・検査用のフォルダー等にあるファイルですが、本番のコードから読み込まれているため、危険度を下げていません。」と添えます。読み込み関係を判定できなかったとき・読み込みが見つからなかったときは、上の扱い（要確認・Low まで）のままです。読み込みが見つからなかったことは、本番のコードから読み込まれていないことの確認ではありません（3.7「読み込み関係の判定の限界」）。SEC-001（秘密情報）は 4.1 の文書・テストの扱いによります。

CODE-003 は、JSX の dangerouslySetInnerHTML（spread の中の短縮記法 {...{ dangerouslySetInnerHTML }} を含みます）を調べます。値を DOMPurify・isomorphic-dompurify・sanitize-html・xss から import（または require）した関数に通しているときだけ要確認（Low）に下げ、自前で定義した sanitize 等の関数を通しているだけでは下げません。サニタイザーの設定内容と、値がどこから来たかは確かめていません。innerHTML への代入・iframe の srcDoc・href の javascript: は見ていません。

CODE-001・CODE-002・CFG-001・CFG-002 は、よく使う書き方（const の別名・カンマ式・bind・process.getBuiltinModule・文字列の計算キー・メソッドの短縮記法・import の別名・spread の後勝ち）を辿ります。辿れない書き方（解決できない spread・束縛の分からない cors(...) 等）は、危険度を下げすぎないよう要確認として出すことがあります。辿れる書き方は限られ、ルールに一致しないことは問題が無いことを意味しません。

CODE-004 は、fs・fs/promises・fs-extra のファイル操作と Express の res.sendFile・res.download に渡すパスの出どころを調べます。値は同じファイルの中で辿り（ファイルの最上位の const も辿ります）、許可したフォルダーに収まっているかの確かめは同じ関数の中だけで探します。環境変数から組んだパス、アップロードで multer がサーバーの側で作る値（保存先のパス・ファイル名）、リクエストを処理しないファイルの出どころの分からない値は、検査カバレッジの件数にだけ数え、項目にしません。このため、別のファイルから渡された値（例: lib/ の補助関数 getPost(slug) を、ルートが params.slug を渡して呼ぶ場合）は報告されません。ファイルをまたぐ値の流れ・許可リストとの照合・書庫の展開（Zip Slip）・express.static の設定・stat／access／exists は確認していません。許可したフォルダーに収まっているかの確かめを見つけても検出を消さず、要確認（危険度は Low まで）にします。path.basename を通した値と、res.sendFile に root の指定がある場合も、消さずに要確認（Low）に下げます。

CODE-005 は、外から来たキーでオブジェクトの共通のひな形を書き換え得る箇所を、同じファイルの中だけで調べます。値は同じファイルの中で辿り（ファイルの最上位の const も辿ります）、変数の別名・ループは同じ関数の中（その場で書く forEach・map・reduce 等の関数を含む）で辿ります。外から来たキーで 2 段以上の代入をする箇所（同じ関数の中の別名・ループで辿る場合を含む）、書き込み先を外から来たキーで決める Object.assign・深いマージ・部品の関数（lodash の merge 等でも、書き込み先が外から来たキーで決まるなら High になり得ます）、危ないキー（proto・constructor・prototype）を拒まない自前の深いマージ・パスで辿って入れる自作の関数（path.split('.') の部品のように、引数から作ったキーで降りて代入する関数）へ外部入力を渡す呼び出しを、重要度 High の候補にします。自前の深いマージ・パスで辿って入れる関数は、名前のある関数（function 宣言、const に入れた関数・矢印関数）だけを見ます。クラスの static メソッド・オブジェクトリテラルのメソッドとして書いたものは見ません。外部入力を渡す呼び出しが同じファイルに無ければ、関数の位置に要確認（Medium）として出します（パスで辿って入れる関数で、ファイルの外へ出しておらず、同じファイルの呼び出しがすべて固定のキー・固定の入れ物のときは報告しません）。別のファイルからの呼び出しは辿りません。自分を再帰で呼んで辿るパスの関数と、引数をそのままキーに使う関数（split・ループ等で作ったキーでないもの）は、パスで辿って入れる関数として見ません（後者は、リクエストを処理するファイルでは書き込みの位置に要確認（Medium）として出します）。lodash の merge・set 等、部品の深いマージ・パスを指定した代入の関数に外部入力を渡す箇所は、使っている部品と版によって安全かどうかが変わるため、要確認（Medium）とし、確かめを見つけても下げません。既知の脆弱な版は依存の検査で見つけます。部品（lodash 等）の中のコードは見ません。1 段の代入は要確認（Low）にとどめます。危ないキーを拒む確かめ（3 つのキーとの比較、定数の許可・拒否の一覧、書き込み先についての hasOwn）は、その代入の降りる段ごとに同じ関数の中だけで探し、見つけても検出を消さず要確認（Low）にします。ひな形の無い入れ物（Object.create(null) 等）への書き込みも、消さずに要確認（Low）にします。書き込み元についての hasOwn の確かめ（受け取った JSON の proto は自分の項目になるため通り抜けます）は確かめとみなしません。Object.assign・スプレッドの書き込み元は対象にしません。キーを列挙する先が同じファイルの単純な z.object・z.strictObject で検証した結果の場合は対象にしません。キーの出どころが分からない場合は、2 段の代入だけを、リクエストを処理するファイルで要確認（Medium）にします。1 段の代入・部品の関数・自前の深いマージの呼び出しで出どころが分からないキーは、検査カバレッジの件数にだけ数えます。ファイルをまたぐ値の流れ・実行時の対策（Object.freeze 等）は確認していません。

複雑な汚染解析（入力から危険な処理までの全経路の追跡）は行いません。

4.4 DB 共通の検査

• 検査すること: 依存名・import・lockfile・migration・設定を根拠にした DB 製品の利用の検出、対応 API での生 SQL の組み立て（DB-001）、DB 接続の TLS 証明書の検証の無効化（DB-002）、Web 公開ディレクトリ内の SQLite ファイル候補（DB-003）、接続文字列のパスワード直書き（DB-004）。
• 製品別の検査は、第 5 章の対応表に載っているパッケージ・API・版だけが対象です。DB の利用を検出しただけで、その DB の設定を検査したことにはなりません。
• ORM（Prisma・Drizzle）を使っているだけで安全とは扱いません。ORM の通常の API はクエリの組み立てとして判定せず、raw / unsafe 系の API を区別して検査します。
• DB ごとに「検出した製品」「実施した検査」「未対応API」「解析できなかった設定」「本番未確認」を表示・export します。

4.5 Supabase

• 検査すること: supabase/migrations 直下の SQL をファイル名の順に構文解析し（libpg-query）、public スキーマのテーブルごとの RLS・GRANT・ポリシーの状態を合成して判定します。クライアント側のコードでの service_role key の利用候補も検査します。

• 限界: 確認しているのはローカルの migration だけです。migration で設定を確認できても、本番 DB に適用されていることは確認していません。 動的 SQL（EXECUTE）、RLS・GRANT・ポリシー・所有者を変え得る、またはテーブルを作成・削除・改名・別スキーマへ移し得る DO ブロック・関数の本体、構文解析できない文、欠けた migration が関係するテーブルは「要確認」とし、状態を断定しません（制約・列・索引の追加等だけの DO ブロックは、RLS・GRANT の状態を変えないため要確認にしません）。RLS が無いことだけで一律に脆弱性とは判定しません。Supabase 固有の規則（Data API・anon・authenticated・service_role）を、一般的な PostgreSQL や他の DB には適用しません。

4.6 公開URL検査

• 検査すること: 利用者が入力した URL（最大 5 件・同じホスト）について、HTTPS の利用、TLS 証明書の検証、最終レスポンスのヘッダー、取得した Set-Cookie の属性（名前と属性だけ。値は保存しません）を確認します。
• 実施の条件: 利用者が「この URL は自分が管理しており、検査する権限があります」と確認した場合だけ実施します。確認が無い場合・オフライン設定の場合・URL 検査を含まない版では「未実施」と表示します。入力した URL が条件（形式・最大 5 件・同じホスト・許可されたアドレス等）を満たさない場合は、検査前の確認の画面で開始できないようにし、理由を表示します。検査に入った場合も、通信せずに「入力した URL が条件を満たさないため未実施」と表示します。
• 取得の方法: GET のみ。各 URL を 1 回（同一ホスト内のリダイレクト最大 3 回を含む）だけ取得し、要求の間隔は 1 秒、1 URL あたり 10 秒、本文は 1MB まで読み取って中身は保存しません。http/https の 80/443 番ポートだけを扱い、ループバック・プライベート・リンクローカル・予約アドレス・クラウドの metadata 先は接続前に拒否します。Cookie・Authorization 等の認証情報は送りません。フォームの送信、ログイン、攻撃用の入力、パスの総当たり、リンクの巡回は行いません。
• 限界: GET のみでもアクセスログや副作用が生じ得ます。ログイン後のページ・ログイン後に設定される Cookie は対象外です。Cookie を観測できなかった場合は、Cookie の属性は確認できていないと表示し（URL-012）、設定に問題が無いとは扱いません。CSP や HSTS の不足は文脈に応じた設定改善事項であり、一律に Critical にはしません。ローカル開発用の URL の検査、認証後の検査、動的な脆弱性診断（ZAP 等）は行いません。

• URL-006 の判定: CSP に frame-ancestors があるときは、その値だけで判定します（CSP に対応したブラウザーは frame-ancestors があると X-Frame-Options を使わないためです）。値が 'none'・'self'・ホストの指定だけのときに、埋め込み元を限っているとし、条件を満たしたとします。*・スキームだけ（https: 等）・空の値は埋め込み元を限っていないとし、有効な X-Frame-Options（DENY・SAMEORIGIN）が一緒にあっても、条件を満たしたとはせず、要確認（設定改善事項）にします。たとえば、frame-ancestors * と X-Frame-Options: DENY を一緒に送るページは実際には埋め込みを許すため、要確認にします。同じポリシーの中に frame-ancestors が複数あるときは最初のものを使います。CSP のヘッダーが複数あるとき（値がカンマでつながって届きます）は、どれか 1 つのポリシーが埋め込み元を限っていれば、限っているとします。frame-ancestors が無いときだけ、有効な X-Frame-Options（DENY・SAMEORIGIN）があれば条件を満たしたとします。CSP に対応していないブラウザーでの動きは確かめていません。ホストの指定の広さ（*.example.com のようなワイルドカードがどこまでを含むか。*.com のような公開の接尾辞だけのワイルドカードを含みます）は確かめておらず、ホストの指定だけなら条件を満たしたとします。
• URL-007 の判定: Referrer-Policy が既知の制限的な値（no-referrer・same-origin・strict-origin・strict-origin-when-cross-origin・origin・origin-when-cross-origin）のときだけ条件を満たしたとします。unsafe-url・no-referrer-when-downgrade・認識できない値は要確認（設定改善事項）にします。カンマで並べた値は、最後の既知の値で判定します。

4.7 業務上の認可（手動確認）

認可は自動では判定しません。次の項目は確認リストとして表示し、利用者が手動で確認します（AI への確認の依頼で AI にコードを読んで確かめてもらうこともできますが、AI の報告は、あなたが外部の AI から得て記録するものです。本製品は、AI がコードを読んだこと、実際に試したこと、報告の内容が正しいことを確かめていません）。コードに関係なく毎回表示するため、結果画面・レポートの「要確認」の件数には含めず、「手動確認項目」として別に数えます（一覧には表示します）。

4.8 Firebase（Firestore・Storage の Security Rules）

• 検査すること: firebase.json の firestore・storage が指す Security Rules のファイルと、プロジェクト直下・workspace のパッケージ直下（packages/・apps/・libs/・services/ の各パッケージ）の firestore.rules・storage.rules を、自作の限られた構文解析器で読み、allow ごとに条件を判定します。同じファイルの関数は 3 段まで展開します。firebase-admin の利用を検出した場合は、認可の手動確認に 1 件加えます（FB-006。要確認の件数に数えます）。
• 判定できない場合: 解析できない書き方（未知のキーワード・解析できない式・未知の rules_version・版 1 で使えない書き方等）が 1 つでもあるファイルは、ファイル全体を「判定できず（解析できない書き方）」として未実施にし、部分的に読めた結果で検出なしにしません。firebase.json が指すファイルが見つからない・選択フォルダーの外を指す・シンボリックリンク・読み取れない場合も、その指定を未実施にします。
• ファイルの最上位（service { … } の外）に書いた function も、同じファイルのすべての service から呼べる関数として展開します（match のワイルドカードの名前を引数で受け取らずに使う関数と、service の直下にも同じ名前がある関数を使う条件は、判定できないものとして FB-004（要確認）にします）。match の中の関数は、同じ名前の最上位の関数より優先します。最上位の関数から service の直下の関数は呼べないため、そのような呼び出しは判定できないもの（FB-004）にします。Firebase の組み込みの関数（exists・get 等）と同じ名前の関数を書いた場合、その名前の呼び出しは判定できないもの（FB-004）にします。最上位に同じ名前の関数が 2 つあるファイルは、ファイル全体を未実施にします。
• 根拠として残す rules の文では、文字列の値とコメントを伏せます。パスの値のうち、小文字の英字と _・- だけでできたもの（コレクションの名前など）は書かれたとおりに残し、それ以外のパスの値（数字・大文字・記号を含むもの）は「…」に伏せます。
• request.auth だけで書いた条件のうち、ログインしていれば誰でも満たせる形（request.auth.token.email_verified・request.auth.uid != '' 等）は request.auth != null と同じ扱いにし、独自の claim をリテラルと == で比べる形（request.auth.token.admin == true 等）以外で判定できないものは、FB-004 の要確認にします。
• 限界: Firestore・Storage の Security Rules を、プロジェクトの中のファイルから読んでいます。Firebase のコンソールで直接変更した本番の rules、App Check・Cloud Functions の中の処理、管理用の SDK（firebase-admin。rules を通らない）からのアクセスは確認していません。条件の意味は限られた形だけを判定しています。アプリの判定であり、データが守られていることを保証するものではありません。
• 本人と比べる条件（request.auth.uid == userId 等）は、通常の match では規則に当てず、確認済みにもしません（認可の手動確認の範囲です）。ただし {document=**} 等の再帰のワイルドカードに付いている場合は、下の階層すべてに効くため FB-004（要確認）にします。
• Realtime Database の rules（database.rules.json、firebase.json の database）は未対応です。見つけた場合は「未対応のため確認していません」と表示し、確認したことにはしません。

5. DB 製品別の対応表

次の表は、本製品の DB 対応表から作っています。

対応表の版: 1.1.0（src/db/support-matrix.json）

表に無いパッケージ・API・版は未対応です（検出した場合は「未対応API」「要確認」として表示し、検査済みとは扱いません）。

専用検査が未対応の製品（利用を検出した場合も、接続秘密などの共通検査だけを行い、専用検査は「未対応」と表示します）:

MongoDB の専用検査（クエリ演算子への外部入力など）は未対応です。 利用を検出した場合も、接続秘密などの共通検査だけを行い、専用検査は「未対応」と表示します。Firebase は Firestore・Storage の Security Rules の検査と、firebase-admin の利用の検出（FB-006。認可の手動確認）を行います（4.8）。Realtime Database の rules（database.rules.json）は未対応です。 すべての DB に対応しているわけではありません。

6. 本番環境について

本番 DB の認証、実効権限、ネットワーク公開、暗号化、稼働中の RLS 等は、ローカルのソースだけでは確認済みにしません。ローカルの migration・設定ファイルが本番と一致するとは限りません。本番環境の設定・権限・適用状態は、利用者が別途確認してください。

7. 手動確認が必要な領域

次の文は結果画面とすべての export にも表示します。

• 認可（利用者ごとのアクセス制御・権限の確認）は自動では判定していません。手動で確認してください。AI への確認の依頼で記録した AI の報告は、あなたが外部の AI から得て記録したものです。本製品は、AI がコードを読んだこと、実際に試したこと、報告の内容が正しいことを確かめていません。
• 業務ロジックの不備（手順の飛ばし・金額や数量の改ざん等）は検査していません。
• 本番環境のデータベース設定・RLS・権限・適用状態は確認していません（ローカルのソースと設定ファイルだけを見ています）。
• 未知の脆弱性や、対応ルールの無い種類の問題は検出できません。

8. 結果の読み方の固定の注意事項

次の文は結果画面とすべての export にも表示します。

• 依存関係の脆弱性の到達可能性は未評価です（アプリから実際に使われるかは確認していません）。
• 依存パッケージの「依存の種類」（直接依存（本番）・間接依存（開発用のみ）等）は、lockfile（と同じフォルダーの package.json）に記録された依存関係のグラフだけから判定しています。「開発用のみ」は本番で使われないことを意味しません（ビルド時に実行されるコードや、本番のビルド結果に取り込まれる開発用のツール・コードがあり得ます）。危険度は情報源の値のままで、依存の種類によって変えていません。到達可能性（アプリから実際に呼び出されるか）は引き続き未評価です。lockfile の形式が未対応・解析できない・workspace で確かでない場合は「依存の種類を判定できず」と表示します。
• 検出事項はルールの条件に一致したことを示し、実環境での悪用を確認したことを意味しません。
• ローカルの migration・設定ファイルは本番と一致するとは限らないため、本番環境の状態は別途確認してください。
• 研究の統計（例: 調査対象アプリの脆弱性の割合）は、その研究の対象と方法に限られた数値です。研究の統計は本製品の性能を示さない点に注意してください。
• 選択フォルダーの中にある入れ子の git リポジトリ・worktree・submodule（.git を持つ下位のフォルダー）は別の作業コピーのため検査していません。それぞれのフォルダーを選んで検査してください。
• 秘密情報の候補（SEC-001・DB-004）のうち、.gitignore 等で除外され git で追跡されていない（git 管理外の）ファイル（.env 類・作業ファイル）のものは「要確認」（危険度は Medium まで）として表示します。現在 git で追跡されていません。過去にコミット・push していた場合は履歴に残っているため、その場合は失効・再発行してください（本アプリは git の履歴を検査していません）。端末・バックアップ・共有を経由した漏えいの影響は残ります。ブラウザーへ公開される環境変数（SEC-002）は git に関係なく配布されるため、この扱いにしません。
• git 管理外かどうか（.gitignore 等で除外され git で追跡されていないか）は、選択フォルダーの .gitignore・.git/info/exclude・.git/index に加えて、この Mac の git の設定の全体の無視設定（core.excludesFile。未設定ならホームフォルダーの .config/git/ignore）からも判定しています（git コマンドは実行していません。設定・無視設定の内容は保存・送信しません）。このため、同じフォルダーでも Mac ごとの git の設定によって判定と危険度が変わることがあります。全体の無視設定でだけ除外されているファイルは、他の人の環境やリポジトリの .gitignore では除外されていない可能性があります。
• 危険なコード（CODE-001〜005）・生 SQL への外部入力（DB-001）の候補のうち、.gitignore 等で除外され git で追跡されていない作業ファイル（ビルド・配布の出力先を除く）のものは「要確認」（危険度は Low まで）とし、配布・デプロイ対象外の可能性が高い旨を添えます。手元で実行するスクリプト等では同じ注意が必要です。git の状態を判定できない場合は分類を変えません。
• 確認項目は、要確認の項目を確かめる内容でまとめた表示です。1 件ずつの検出・比較・非表示の記録は変わりません。
• 「アプリの判定」は、読み込み関係・値の出どころ（選択フォルダーの中のほかのファイルの定数・呼び出し元まで）・値の形を、限られた方法で調べた結果です。判定の方法と限界を各項目に示しています。アプリの判定は、問題が無いことや安全性を保証するものではありません。判定できないものは人の確認に回します。
• 質問への回答・確認済みにした記録は、利用者自身の判断として記録します。アプリは回答の正しさを確かめません。確認済みにした項目も、レポートに理由・日時とともに残ります。
• 認可の手動確認の確認済みは、その検査の中だけ有効です。

AI との接続（3.7）で、AI が依頼を受け取り、報告を集め箱に入れ、再点検を始めた場合も、上の注意事項の読み方は同じです。AI から受け取った報告は、利用者が画面で確かめて確定するまで記録しません。AI が始めた再点検で検出されなくなったことも、修正済みであることは意味しません（3.5）。

9. 本製品が行わないこと

• すべての脆弱性の発見、結果の完全性・正確性、誤検知や見逃しが無いことの保証、侵入・漏えい等の防止の保証。
• 法令適合・公開の可否・第三者認証の判断（「検出なし」「今回未検出」はこれらを示しません）。
• 侵入テスト、動的な脆弱性診断、認証後の画面の検査、ローカル開発用 URL の検査。
• 実 DB・管理 API への接続、本番設定の変更、鍵の失効・再発行、修正の自動適用。
• Git 履歴の検査、汚染解析、型情報を使った解析、対応言語以外の言語固有の検査。
• AI（LLM）によるコードの解析。依頼文はテンプレートから作り、AI API にコードを送りません。利用者が AI との接続（3.7）を入にしたときも、同じ Mac の中で AI が同じ依頼文を受け取るだけで、本製品から AI のサービスへは通信しません。結果画面の「AI への依頼」の列（以前の「次の修正指示」に代わるもの）と、社内の手順で使う書き出しの道具（pnpm fix-queue:export）も、同じテンプレートから 1 件ずつの依頼文を作るだけで、AI へ送りません。列は次の 7 つの帯の順に並べた優先度の目安です。(1) 前回「修正した」と報告されたのにまだ残っている検出事項の修正の依頼、(2) 危険度 Critical・High の検出事項の修正の依頼（秘密情報の候補を先に）、(3) 危険度 Critical・High の要確認の項目の対応の依頼・確認の依頼、(4) 危険度が中程度以下の検出事項の修正の依頼、(5) そのほかの要確認の項目の対応の依頼・確認の依頼、(6) 開発用の部品の修正の依頼、(7) 業務上の認可などの手動確認項目の対応の依頼・確認の依頼（毎回の点検で出るため最後に置きます）。要確認の項目は、AI にコードを読んで確かめてもらう「確認の依頼」として入り、確かめた結果「対応が必要」になったものは「対応の依頼」として入ります。「あとで」は利用者の作業の印で、修正できたことを確かめたものではなく、検出事項の件数・一覧・レポートを変えません。印はその検査にだけ付きます。AI が「修正した」と報告した項目は、次の点検の結果で確かめます。

10. 研究の統計について

本製品の説明で引用することがある研究（公開 Web アプリ 200 件中 182 件（91%）で脆弱性を確認、再実装実験での再導入率 25.7% から 11.0% への改善など）は、その研究の対象（特定条件で抽出した標本）と方法（コード監査と専門家の検証を含む）に限られた統計です。本製品の検出率・安全率・改善効果を表すものではなく、本製品で同等の問題を同じように検出できることを示すものでもありません。

11. 対応 OS

• macOS（Apple Silicon）: 対応（Apple シリコン）。提供対象は、Apple シリコン（M1 以降）を搭載した Mac です。配布版は Developer ID の署名と Apple の公証（notarization）をしています。macOS 13 以降で起動する設定にしています。動作を確認した macOS の版は、販売ページで示します。メモリ 8GB 以上、空き容量 1GB 以上を目安として推奨します。
• Windows（x64）: 未検証です。Windows 版は提供していません。
• その他の環境: 未対応です。

12. レポートの共有

レポート（JSON・Markdown・HTML）には、検査日時、対象、検査エンジンとルールの版、検査範囲、除外・失敗・未実施の項目、本文書の限界の説明を含め、共有後も説明が残るようにします。検出事項・要確認の一覧は、重大度の高い順に並べ、同じ重大度の依存パッケージは依存の種類（本番経路あり → 判定できず → 開発用）の順に並べ、その旨をレポートにも記載します（レポート形式 2 で JSON に表示用の組の種類・並べ方の説明・重大問題のうち依存パッケージの件数を、形式 3 でその依存の種類ごとの内訳と次に確認するとよい更新の候補を追加。形式 4 で対応単位・手動確認項目の件数、実行コマンド（bin）を含む本番の依存の補足、日本時間の表記を追加し、要確認の件数から手動確認項目を除きました。形式 9 で、重大問題・対応単位から開発用の部品を除き（既存の欄の意味の変更）、開発用の部品の重大な脆弱性の件数と数え方の説明を追加しました。形式 11 で、重大問題・対応単位・重大問題の内訳から AI が誤検知と報告した検出事項（秘密情報の候補を除く）を除き（既存の欄の意味の変更）、その件数と説明を追加しましたが、形式 15 でこの扱いを戻しました。現在のレポートでは、AI が誤検知と報告しただけでは、重大問題・対応単位・重大問題の内訳から除きません。重大問題のうち AI が誤検知と報告した件数は、別に示します）。保存の前に次の確認文を表示します。

OSV に照会した検出事項がある点検では、結果の画面とレポート（JSON・Markdown・HTML）の「検査の範囲と限界」に、脆弱性情報の出典（OSV）と、含まれる情報源ごとのライセンスを示します。検出事項ごとにも、情報源・元の勧告の URL・ライセンスを示します（例: ID が GHSA- で始まる記録は GitHub Advisory Database・CC BY 4.0、RUSTSEC- で始まる記録は RustSec Advisory Database・CC0 1.0、MAL- で始まる記録は OpenSSF Malicious Packages・Apache License 2.0）。表示は改変を含みます。本製品は情報源の概要（summary）だけを英語のまま表示し、空白をまとめ、200 文字を超える部分は省略し、秘密情報に見える文字列は伏せる場合があります。CC BY-NC-ND 4.0 で提供される記録（ID が CGA- で始まるもの）は、概要を表示せず、ID と URL だけを示します（レポート形式 16 で、JSON に出典の欄 attribution と、検出事項ごとの source.attribution を追加しました。追加のみです）。

ファイル名・URL・パスにも機密が含まれ得ます。共有前に内容を確認してください。確認した人の名前を入力していれば、レポートに含まれます。

公開URL検査の前には、次の注意も表示します: GET のみでもアクセスログや副作用が生じ得ます。

13. 改訂

検査エンジン・ルール・DB adapter・対応表を追加・変更するときは、検査条件と限界の説明、テスト、版の管理を同時に更新します。検査範囲を狭める等の重要な変更は重要な変更を含む版として記録し、重要な変更を含む版以降に同意していない場合はアプリ内で再同意を求め、DB 対応表の再生成・表現の整理等の軽微な変更はマイナー版・パッチ版を上げて周知だけを行います（利用規約 第14条）。

2026-10-10（0.2.0-draft）: 確認項目とアプリの判定（3.7・8）を追加。結果の読み方を変える重要な変更として再同意の対象にした。自社静的ルールを 1.6.0 に更新（表の要素のキーが固定の値でないものは解決できず、読み込みの書き方の追加、ファイル一覧の上限・未解析の本番用ファイルでは判定できず）。

2026-10-11（0.3.0-draft）: ファイルをまたぐ値の出どころ（C1）の範囲と限界を追記（3.7・4.3・8）。結果の読み方を変える重要な変更として再同意の対象にした。自社静的ルールを 1.7.0 に更新。

2026-10-11（0.4.0-draft）: Firebase の Security Rules の検査（C2）の範囲と限界を追記（4.3・4.8・5）。DB 対応表を 1.1.0 に更新し、Firebase/Firestore を専用検査の対象に移した。Realtime Database の rules は未対応。結果の読み方を変える重要な変更として再同意の対象にした。

2026-10-11（0.5.0-draft）: 重大問題から開発用の部品（開発用の依存からだけ届く依存パッケージ）の Critical・High を除き、「開発用の部品の重大な脆弱性」として別に数える変更（3・4.4・レポート形式 9）と、次の修正指示（対象外の AI の項）を追記。結果の読み方を変える重要な変更として再同意の対象にした。

2026-10-12（0.5.1-draft）: Firebase の rules 検査を 1.1.0 に更新し、ファイルの最上位に書いた function を判定するようにした（4.8。これまでファイル全体を未実施にしていたもの）。検査する範囲が広がる軽微な変更のため、パッチ版とし再同意は求めない。

2026-10-12（0.6.0-draft）: 点検のループ（前回からの変化・「済んだ」の確かめ・AI への依頼の列・確認の依頼と AI の報告の確認済み・ループの記録の保存）を追記（2・3.5・3.7・3.8）。ビルドの出力先と判定した out/ を既定で除外するようにした（検査範囲を狭める変更）。確認済みの根拠に AI の報告が加わり、「直ったもの」の意味を定めたため、結果の読み方を変える重要な変更として再同意の対象にした。テスト・検査用のファイルを「本番から読み込まれていません（アプリが確認）」とする判定は従来のアプリの判定のままで、表示の文だけを変えた。

2026-10-13（0.6.1-draft）: AI への依頼の「済んだ」と AI の結論のボタンをなくし、AI の報告（返信ブロック）を貼り付けて記録する方法に変えた（3.5・3.7）。「誤検知と報告済み」「人の作業待ち」の表示と、利用者が理由を書いて非表示にする道を追記。確認済みの根拠の種類・「直ったもの」の意味・件数・検査の範囲は変わらず、記録の操作の手段が変わるだけのため、周知のみとし再同意は求めない。

2026-10-13（0.6.2-draft）: 確認項目の質問を利用者に聞かず、すべて AI への確認の依頼にした（3.7「質問の方針」）。AI が確かめられないことは「判断できない」と報告させる。前の点検の AI の答えを次の点検に引き継ぐことを追記（3.7「AI の答えの引き継ぎ」）。表示・確かめ方の整理のため、パッチ版とし再同意は求めない（周知のみ）。

2026-10-13（0.6.3-draft）: 結果の分類「確認済み」の表示名を「条件を満たした」に変えた（3.1・4.1。結果画面のカード・一覧・レポートの表示名も同じ）。要確認をあなたの確認・AI の報告で確認済みにしたもの（要確認の内訳）と取り違えないため。分類の意味・件数・検査の範囲は変わらず、表示名の変更だけのため、パッチ版とし再同意は求めない（周知のみ）。

2026-10-14（0.6.4-draft）: 商用販売に向けて、施行日（2026-11-01）、事業者に限って販売すること、販売する製品の版の欄を冒頭に書いた。11 章に、macOS（Apple Silicon）が提供対象で、署名・公証をした配布版での確認はまだであること、Windows 版は提供していないことを書いた。検査の範囲・標準表示文・DB 対応表・結果の読み方は変えていない。表現の整理のため、パッチ版とし再同意は求めない（周知のみ）。冒頭の表示文を「この文書は弁護士のレビューを受けていません。」に改めた（2026-10-14 提供者の決定。表示だけの変更で、この版の内容に含める）。

2026-10-14（0.6.5-draft）: 11 章に、対応する macOS の版（13 以降）と、Apple シリコン（M1 以降）を搭載した Mac が対象であることを書いた。検査の範囲・標準表示文・DB 対応表・結果の読み方は変えていない。表現の補充のため、パッチ版とし再同意は求めない（周知のみ）。

2026-10-14（0.6.6-draft。同じ日の 0.6.5-draft（動作環境の補充）の次の版）: テスト・検査用のファイルの読み込み関係の判定で、文章の中のファイル名と、テスト用の場所を指す根拠の無いファイル名の文字列を読み込みとして数えないこと、git 管理外のビルド・配布の出力先のコンパイル後の .js を読み込み元にしないこと、見逃しになり得る書き方を追記した（3.7「アプリの判定」「読み込み関係の判定の限界」）。読み込み元の AI への質問を「本番のコードが、テスト・検査用のファイルを実行時に実際に読み込むか」に改めた。検査の対象・保存する内容は変わらず、判定の精度と説明の変更のため、パッチ版とし再同意は求めない（周知のみ）。

2026-10-14（0.6.7-draft）: 誤検知として非表示にした項目に、見直しの期限（既定 90 日）と「元に戻す」を追記した（3.6）。期限が過ぎると通常の表示に戻る。検査の範囲・標準表示文・結果の分類・件数の定義は変えず、非表示の扱いの追加のため、パッチ版とし再同意は求めない（周知のみ）。

2026-10-14（0.6.8-draft）: 3.6 に、非表示の見直しの期限の保存（expires_at。選ばなければ 90 日）、元に戻した日時の保存（revoked_at）、期限が来た項目の「見直し済み（表示のままにする）」の操作を、実装に合わせて正確に書いた。11 章の動作環境を、起動する設定と推奨の目安の書き方に改めた。検査の範囲・標準表示文・結果の分類・件数の定義は変えず、非表示の扱いの説明と表示の訂正だけのため、パッチ版とし、周知のみ（再同意の判断は 0.6.0-draft の重要な変更のまま変えない）。

2026-10-19（0.6.9-draft）: 自動の見張り（毎日の部品の照会と週 1 回の自動点検）の範囲と限界を 3.9 に書いた。検査の範囲・標準表示文・結果の分類・件数の定義は変えず、追加機能の範囲と限界の説明のため、パッチ版とし、周知のみ（再同意の判断は 0.6.0-draft の重要な変更のまま変えない）。

2026-10-19（0.6.10-draft）: 製品名を「App Safety Check」から「Cheloop（チェループ）」に改めた。検査の範囲・標準表示文・結果の分類は変えていない。内容の変更ではないため、周知のみ（再同意は求めない）。弁護士未レビュー。

2026-10-21（0.6.11-draft）: 依存関係の脆弱性に、悪用の情報（CISA KEV・EPSS）の印と、import が見つかったかどうかの表示を足したことに合わせて、3.10 に範囲と限界（判断の補助であること・件数と危険度を変えないこと・限界の文・出典）を書き、4.2 から指した。検査の範囲・標準表示文・結果の分類・件数の定義は変えていないため、周知のみ（再同意は求めない）。弁護士未レビュー。

2026-10-21（0.6.12-draft）: AI が「誤検知」と報告した修正の依頼の検出事項（開発用の部品を除く Critical・High。秘密情報の候補と、CISA KEV に載っている脆弱性を含む依頼を除く）を、結果画面とレポートの概要の重大問題に数えず、「AI が誤検知と判断（未確認）」として別に数えるようにした（3・3.7・レポート形式 11。これまでは件数・分類を変えず重大問題に数えていた）。アプリは確かめていないこと、秘密情報の候補と CISA KEV を含む依頼は人が確かめて非表示にするまで重大問題に数えること、「列に戻す」で重大問題に戻ることを書いた。検出事項の危険度・分類・一覧と検査の範囲・標準表示文は変えていない。提供者の決定（2026-10-21）により、パッチ版とし、周知のみ（再同意は求めない）。弁護士未レビュー。

2026-10-22（0.6.13-draft）: AI への依頼をまとめてコピー・ファイルに書き出す方法と、AI が書いた返信ファイルの取り込みを 3.7 に書いた（「AI への依頼のまとめ」）。書き出し先は検査の対象のフォルダーの外に限ること、返信ファイルはあなたが確認の画面で確かめて確定したときだけ記録すること、点検し直して検出事項が見つからなくなった依頼への返事は記録せずに飛ばすことを書いた。依頼文は 1 件ずつのものと同じテンプレートから作り、AI へ送らない。検査の範囲・検査の方法・標準表示文・結果の分類・件数の定義は変えていないため、パッチ版とし、周知のみ（再同意は求めない）。弁護士未レビュー。

2026-10-22（0.6.14-draft）: 自社静的ルールを 1.8.0 に更新し、CODE-004（ファイル操作へ外部入力が渡る候補）を足した（4.3・8）。検査する範囲が広がる変更のため、周知のみ（再同意は求めない）。弁護士未レビュー。

2026-10-23（0.6.15-draft）: AI の報告の集め箱を 3.7 に書いた（「AI の報告の貼り付けと集め箱」「AI への依頼のまとめ」「確認済み（AI の報告をあなたが記録）」）。貼り付けた返事と取り込んだ返信ファイルは、まず集め箱に入れ、「まとめて記録」を押して確認の画面で確定したときだけ記録すること、入れる段では受け付けられない返信ブロックだけを 1 つずつ断ること、記録は確定の直前の照合で全部か無かであること、返信ファイルは断られた返信ブロックが無いときだけ 取込済 に移すことを書いた。検査の範囲・検査の方法・標準表示文・結果の分類・件数の定義は変えていないため、パッチ版とし、周知のみ（再同意は求めない）。弁護士未レビュー。

2026-10-23（0.6.16-draft）: 3.6・3.7 に、AI への依頼の列の「誤検知と報告済み」の行は「誤検知として非表示にする」を 1 回押すだけで、理由の入力と見直しの期限の選択を求めずに、決まった理由と既定の 90 日の見直しの期限で非表示にすること（結果画面の検出事項からは今までどおり理由を書いて期限を選ぶこと）を書いた。検査の範囲・検査の方法・標準表示文・結果の分類・件数の定義は変えていないため、パッチ版とし、周知のみ（再同意は求めない）。弁護士未レビュー。

2026-10-23（0.6.17-draft）: 自社静的ルールを 1.9.0 に更新し、CODE-005（外部入力でオブジェクトの共通のひな形を書き換え得る候補）を足した（4.3・8）。検査する範囲が広がる変更のため、周知のみ（再同意は求めない）。弁護士未レビュー。

2026-10-23（0.6.18-draft）: ボタン名・状態名を画面に合わせた（3.7 の「まとめて記録」を「記録の内容を確かめる」と確認の画面の「確定して記録する」に、「人の作業待ち」を「あなたの作業待ち」に改め、集め箱の返事は記録前は「返事あり（まだ記録していない）」と表示されることを足した）。検査の範囲・検査の方法・標準表示文・結果の分類・件数の定義・記録の決まりは変えていないため、パッチ版とし、周知のみ（再同意は求めない）。弁護士未レビュー。

2026-10-25（0.6.19-draft）: 外部 AI の評価の指摘の修正に合わせて改めた。(1) AI が「誤検知」と報告した検出事項も重大問題の数（対応単位・内訳を含む）から外さず、そのうちの件数を「AI が誤検知と報告（未確認・重大問題の数には含めています）」として別に表示することにした（3・3.7。0.6.12-draft の扱いを改めた。提供者の決定 2026-10-25）。確認の画面にアプリが見つけた場所と伏せ字にした根拠を出すことを書いた（3.7）。(2) テスト・検査用のファイルの候補は、本番のコードから読み込まれていると判定できたときは危険度を下げないことにした（4.3）。(3) 自社静的ルールを 1.10.0 に更新し、CODE-001・CODE-002・CODE-003・CFG-001・CFG-002 がよく使う書き方を辿ること、CODE-003 の範囲（innerHTML・srcDoc・href の javascript: は見ていない）と下げる条件を書いた（4.3）。(4) URL-006・URL-007 の判定の値を書いた（4.6）。(5) 前回からの変化の「直ったもの」を「今回の点検で見つからなくなったもの」に、「直ったことを点検で確認しました」を「点検で見つからなくなった」に改めた（3.5）。(6) 検査エンジンを置き場所に関係なく一時フォルダーへ複製して照合してから実行すること、解析の処理（worker）と WASM の照合と、その限界を書いた（2）。重大問題の数え方は 0.6.12-draft より前（0.6.0-draft で同意を得た内容）と同じく、数を減らさない側に戻す変更で、検査の範囲を狭める変更は無いため、パッチ版とし、周知のみ（再同意は求めない。再同意の判断は 0.6.0-draft の重要な変更のまま変えない）。弁護士未レビュー。

2026-10-25（0.6.20-draft）: 最終レビューの指摘に合わせて改めた。(1) 2 の検査エンジン・解析の処理の照合が、本製品を使う利用者と同じ権限で動くほかのプログラムによる差し替え（確認から実行・読み込みまでの間を含む）を防ぐものではないこと（同じ利用者の権限で動く攻撃者は対象外）を書いた。(2) 2 の WASM が一致しないときの扱いを、解析の処理全体の「失敗」から、その部分の構文解析を行わず該当する migration を要確認・DB 検査を一部未完了とする、に正した（実装どおり）。(3) 4.6 の URL-006 の判定で、frame-ancestors * と X-Frame-Options: DENY を一緒に送るページを条件を満たしたと誤って判定すること、公開の接尾辞だけのワイルドカードも確かめないことを言い切った。検査の範囲・検査の方法・結果の分類・件数の定義は変えず、限界の説明を実装に合わせて正確にしたものであるため、パッチ版とし、周知のみ（再同意は求めない。再同意の判断は 0.6.0-draft の重要な変更のまま変えない）。弁護士未レビュー。

2026-11-09（0.6.21-draft）: 12 に、結果の画面とレポートに示す脆弱性情報の出典（OSV と、情報源ごと・記録ごとの元の勧告の URL・ライセンス）と、情報源の概要の表示のしかた（改変を含むこと・英語のまま・200 文字を超える部分の省略・伏せ字・CC BY-NC-ND 4.0 の記録は概要を表示しない）、レポート形式 16 の attribution・source.attribution を書いた（T5。2026-11-09 の提供者の決定。周知のみ。再同意は 0.6.0-draft のまま）。弁護士未レビュー。

2026-11-09（0.6.22-draft）: 販売開始日（2026-11-11）に合わせて施行日を改めた。検査の範囲・標準表示文・DB 対応表・結果の読み方は変えていない。内容の変更ではないため、周知のみ（再同意は求めない。再同意の基準は 0.6.0-draft のまま）。弁護士未レビュー。

2026-11-09（0.6.23-draft）: 販売する製品の版を 1.0.0 とし、冒頭の対象の版を 1.0.0 で埋めた（製品の版の未確定の印を消した）。11 章の macOS の行から「内部検証で通し確認済み（未署名ビルド）」の表現を改め、配布版は Developer ID の署名と Apple の公証をしていることを書いた（重複していた「提供対象です」と、署名・公証をした配布版での確認はまだという記載を外した）。共有の部品の起動時の確認の記載（2 章）から、署名・公証をした配布版での確認はまだという括弧書きを外した。検査の範囲・標準表示文・DB 対応表・結果の読み方は変えていない。周知のみ（再同意は求めない。再同意の基準は 0.6.0-draft のまま）。弁護士未レビュー。

2026-11-10（0.6.24-draft）: 冒頭の注記を削り、題の「（草案）」を外した（提供者の決定 2026-11-10）。あわせて、外部の評価の指摘に合わせて改めた。(1) 公開 URL 検査の URL-006（フレーム埋め込みの制限）の判定を直した。CSP に frame-ancestors があるときはその値だけで判定し、埋め込み元を限っていない値（*・スキームだけ等）は、有効な X-Frame-Options が一緒にあっても要確認にする（以前は条件を満たしたと判定していた。4.6）。CSP のヘッダーが複数あるときの扱いも 4.6 に書いた。(2) 2・4.1 の秘密情報の「値は保存しません」に、検査の間は検査対象のファイルを一時フォルダーへ平文のまま複製することと、伏せ字の限界を添えた。(3) 3.7 の集め箱は、入れた内容を端末の中に一時的に保存する（最長 30 日）が、確定するまで判定・確認済みの記録に反映しないことに、3.8 の URL は、入力した URL の一覧は保存しないが、検出事項に含まれる対象の URL は検査結果に保存することに書き分けた。(4) 3.10 の「送る情報が無い」を、送らない情報と、接続に伴って相手に伝わる情報に書き分けた。(5) 4.1 のダミー値・例示を、値の形から可能性が高いと推定したものと改めた。(6) 12 のレポート形式の説明に、形式 15 で AI の誤検知の報告の扱いを戻したことと、現在の数え方を書いた。(1) は判定が変わる（要確認が増える方向）。(2)〜(6) は書き方の整理で、検査の範囲・標準表示文・DB 対応表は変えていない。条項は変えていない。内容の変更ではないため、周知のみ（再同意は求めない。再同意の基準は 0.6.0-draft のまま）。施行日（2026-11-11）は変えない。

2026-11-10（1.0.0）: 販売開始（2026-11-11）に合わせて正式版とした（版名の -draft を外した）。0.x の版に同意している場合は、再同意を求める（再同意の基準を 1.0.0 とした）。あわせて、外部の評価の指摘に合わせて、3.7・4.7・7 の AI の報告の説明を、あなたが外部の AI から得て記録したもので、本製品は AI がコードを読んだこと・実際に試したこと・報告の内容が正しいことを確かめていない、と改めた（レポートの同じ文も改めた）。同じ日の 0.6.24-draft の行に書いた変更（URL-006 の判定の修正など）を含む。施行日（2026-11-11）は変えない。

2026-11-12（1.1.0）: AI との接続（MCP）を 3.7 に書いた。利用者が入にしたときだけ（最初は切・同意の前は入にできない）、同じ Mac の中で AI が依頼文を受け取り、返信ブロックを集め箱に入れ、再点検を始められること、AI から受け取った報告は利用者が画面で確かめて確定するまで記録しないこと、集め箱に記録していない報告があるアプリは AI から再点検を始められないこと、AI からの再点検の回数の上限、AI が始めた再点検は前回の点検と同じ設定で行うこと、別の作業ツリーには依頼を出さないこと、AI の誤検知の報告で重大問題の数を減らさないこと、同じ利用者のほかのプログラムもこの接続を使えること、管理者権限のないほかの利用者のプログラムからは使えないこと（管理者権限からの完全な隔離は保証できないこと）を書いた。8 に、AI との接続の場合も注意事項の読み方は同じであることを、9 に、AI との接続でも本製品から AI のサービスへは通信しないことを書いた。検査の範囲・検査の方法・標準表示文・結果の分類・件数の定義は変えていない。利用者の情報が AI に渡る経路と、AI が始められる操作が増えるため、重要な変更とし、再同意を求める（再同意の基準を 1.1.0 とした。提供者の決定 2026-11-11）。提供開始の時点で有償の購入者・無料体験の申込者がいなかったため、利用規約 第14条4項の予告の期間を置かずに提供を始めた（2026-11-12 提供者の判断）。冒頭の対象の製品の版を、AI との接続を含む Cheloop 1.1.0 とした。施行日（2026-11-11）は変えない。