CLIを複数のリポジトリへ入れるときは、既存の検査を残し、実際の変更に近い内容で新旧の判定を比べてから、追加検査を有効にする。この順番を先に置くと、導入できたことと普段の作業で使えることを分けて確認できます。
個人情報の混入をコミット前に検知するdoxguardのRust候補を、30リポジトリへ配置しました。現在、コミット時の追加gateは15件有効、15件保留です。この記事では、その半分を保留にした判断をまとめます。
数値は2026年10月3日のローカル検証を公開用に集約した記録に基づきます。外部環境で再現した結果ではありません。
配置と空indexの確認で何が分かったか
doxguardはAPIキーを主に探すスキャナを補完し、監視語を使って名前などの混入を検知するローカルCLIです。監視語は手元に置き、CIへ持ち出しません。Rust本体に、npmの薄いプラットフォーム選択ランチャーを組み合わせています。
今回使ったのは、固定したソースsnapshotから作った未公開の試用候補です。ローカル未コミット差分も含むため、公開repoのbase commitだけでは候補の全ソースを特定できません。公開版に同じ機能が揃っている、と読み替えないでください。
最終候補のRustテストは103件成功しました。これとは別に、導入スクリプトの18ケースも成功しています。正常系のほか、検知時の停止、入力欠落、既存hookの停止、dirty・stagedなhookの拒否、冪等性を確認しました。
その候補を、既存スキャナのある30件へ配置しました。全件で実際のindexを保持し、既存検査とCIも残しています。空indexでの追加検査と実hookの確認は通りました。
ここで確認できたのは、追加検査を呼び出せることです。変更内容がない状態で通っても、普段コミットする内容が新しい検査を通るかは分かりませんでした。
実indexを触らずに変更相当の内容を比べる
次に、実際のindexを変更しない仮想indexで、変更相当の内容を旧検査とRust検査にかけました。作業中のステージングを崩さず、同じ内容に対する判定の差を見ます。
空indexの成功は配線の確認、仮想indexの比較は内容の受入確認です。両方を分けて記録すると、どこまで確かめたかが曖昧になりません。
Gitには別のindexファイルを指定する仕組みがあります。たとえば、使い捨ての検証用cloneで、未使用の相対パスを指定して始める最小例は次のとおりです。POSIX shell / Git Bash用です。これは今回の実測を再現するスクリプトではありません。
# HEADのある検証用cloneで実行。既存ファイルは指定しない
GIT_INDEX_FILE=./trial.index git read-tree HEAD
GIT_INDEX_FILE=./trial.index git add -- sample.txt
GIT_INDEX_FILE=./trial.index git diff --cached --stat
sample.txtには合成データを置きます。別indexを作ってもgit addはGitオブジェクトを書き込むため、本番作業用cloneで試す例にはしていません。詳しくはGitのGIT_INDEX_FILEとgit-read-treeを参照してください。
新検査の通過14件とgate有効15件が違う理由
比較した30件のうち、旧検査が通るのは29件、新検査が通るのは14件、新検査で止まるのは16件でした。
新検査の検知は139件あり、そのうち136件は、旧スキャナが自身のソースを検査対象から除外していたことに関係する差でした。139件は一意な漏えい人数でも、一意な語数でもありません。すべてが誤検知、あるいはすべてが実漏えい、とも断定していません。
旧検査では通るのにRust追加検査で止まる15件は、通常作業への影響を確認するため、追加gateを保留しました。一方、旧検査でも止まる1件は、その停止を維持するためRust有効群に含めています。新検査が通る14件に、この1件を加えた15件が有効群です。
保留は、候補の削除や検査全体の停止ではありません。候補は全30件に配置済みで、直接scanできます。保留群でも旧検査は続きます。再起動時に動く常駐処理ではなく、コミット時のhookで呼ぶ追加検査を、リポジトリごとに保留した状態です。
短語境界など旧設定の移行漏れは修復しましたが、検査を通すためのallowを自動追加することはしていません。判定差をなくすことだけを目標にすると、確認すべき差まで隠してしまうからです。
次回は広く配る前に比較を置く
次回は、小さく配置した段階で旧設定と変更相当の検査を比較し、その結果を見て展開範囲を広げます。候補バイナリの更新とリポジトリ別設定の更新も分け、個別設定を上書きしないようにします。
今回の自然なコミットの実使用観測は0件で、数日間の試用はまだしていません。候補の公開Releaseも未実施です。性能ベンチマークもないため、Rust化による速度向上はここでは評価できません。
30件への配置、内容の受入、数日の使用、Releaseを別の状態として扱う。この区別を残したまま、保留した15件の判定差を確認していきます。CLIを複数repoへ導入する際の確認順として、doxguardの公開ソースとあわせて参考になればうれしいです。
※ ヘッダー画像とインフォグラフィックの絵は AI（画像生成）で作成しています。
※ 本文の挿絵も AI（画像生成）で作成しています。
※ 日本語・数値の組版、固定猫素材の合成、本文図はHTML/SVG等で制作しています。
書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://ishizakahiroshi.com/
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）：
https://x.com/ishizakahiroshi
バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。