生成AIやAIエージェントがコードを書く時代になりました。コードを書く速度は飛躍的に向上しましたが、その一方で、新しい問題も生まれています。
それがシークレットの誤コミットです。
APIキー、アクセストークン、データベースの接続文字列、秘密鍵など、本来Gitへコミットしてはいけない情報が、AIが生成したコードに混ざる可能性があります。この課題を解決するために、Gitへコミットする前にシークレットを検知するpre-commitフック KeyGate を公開しました。
そして公開から約2か月で、PyPIの累計ダウンロード数が10,000件を超えました。この数字にはCI環境からのダウンロードも含まれています。
この記事では、10,000ダウンロードという数字そのものではなく、開発・公開・運用を通して得られた知見を共有します。
作ろうと思った理由
きっかけは、AIエージェントでした。
人間は「これはAPIキーだからコミットしてはいけない」という知識があります。しかしAIは、入力や周辺コードに秘密情報が含まれていれば、それをそのまま生成結果へ含めることがあります。もちろん最終的な責任は人間にあります。しかし、AIがコードを書く量が増えるほど、人間だけでレビューし続けるのことは現実的ではありません。
そこで必要になるのが「Gitへ入る前に止めるガードレール」です。
なぜpre-commitなのか
シークレット検知ツールは数多く存在します。
しかし、多くは
- GitHubへPushした後
- CIが動いた後
- リポジトリをスキャンした後
に検知します。
私は、Gitの履歴へ入る前に止めることが重要だと考えました。
一度Git履歴へ残った秘密情報は、
- Force Push
- History Rewrite
など、後始末のコストが非常に大きくなります。
事故は、起きてから対処するより起こさない方が圧倒的に安価です。
一番重要視したのはRecallでした
シークレット検知では、
- Recall
- Precision
という2つの指標があります。
私はRecallを最優先にしました。理由は単純です。誤検知は手間ですが、見逃しは情報漏洩につながります。
検証では、
| 指標 | 結果 |
|---|---|
| Recall | 100.0% |
| Precision | 80.6% |
| F1 Score | 89.3% |
という結果になりました。
つまり、検証コーパスでは見逃しゼロを達成しています。
Precisionはあえて100%を目指さなかった
Recallだけを追求すると、誤検知は増えます。ではPrecisionを100%へ近付ければよいかというと、そうではありません。Precisionを上げるということは、「怪しいものでも通す」方向になります。
その結果、本当に危険なシークレットを見逃す可能性が高くなります。セキュリティツールとして、私はこのトレードオフを受け入れませんでした。
BLOCKとWARNを分けた理由
では誤検知をどう扱うのか。ここが設計で最も悩んだ点です。もし全てをBLOCKすると、開発者は面倒になってツールを無効化します。それでは意味がありません。
そこでKeyGateでは
- 明らかなシークレット → BLOCK
- 疑わしいもの → WARN
という二段階にしました。
つまり、セキュリティと開発体験のバランスを設計で解決しようとしました。
OSSは「良いコードを書けば使われる」のではなく、「課題設定・設計思想・発信」の3つが揃って初めて使われる
今回、KeyGateがPyPIで10,000ダウンロードを超えたことで、改めて感じたことがあります。それは、「OSSは良いコードを書けば自然に使われるわけではない」ということです。READMEを書き、Qiitaで設計思想を説明し、Xで継続的に発信して、ようやく少しずつ使ってもらえるようになりました。
振り返ると、OSSには次の3つが必要だと感じています。
1. 課題設定
「何を作るか」よりも、「どんな課題を解決するか」の方が重要です。私はAIエージェントがコードを書く時代に、「シークレットの誤コミット事故は今後さらに増える」という課題に着目しました。
もし単に「シークレット検知ツールを作りました」だけでは、多くの既存ツールに埋もれていたと思います。「AI時代のGitガードレール」という問題設定があったからこそ、興味を持ってもらえました。
2. 設計思想
OSSはソースコードだけでは伝わりません。なぜその設計にしたのかを説明することも重要です。
KeyGateでは、
- Recallを優先する理由
- BLOCK/WARNの二段階設計
- 誤検知とのトレードオフ
を最初から意識して設計しました。
単に機能を並べるよりも「なぜその設計なのか」を説明した方が、利用者は安心して導入できます。
3. 発信
最後に必要なのが発信です。どれだけ良いOSSでも、存在を知られなければ使われません。
私は
- READMEの改善
- Qiitaでの記事公開
- Xでの発信
を続けました。
公開して終わりではなく、「なぜ作ったのか」「何を解決するのか」を伝え続けることも、OSS開発の一部だと感じています。
技術だけではOSSは育たない
もちろん、コードの品質は重要です。しかし、それだけでは十分ではありません。
利用者はソースコードを読む前に、
- 何を解決するツールなのか
- なぜ必要なのか
- 他と何が違うのか
を判断しています。つまり、最初に評価されるのはコードではなく、課題設定と設計思想、そして発信です。10,000ダウンロードを通じて、私が最も強く実感したのはこの点でした。
10,000ダウンロードをどう受け止めているか
PyPIのダウンロード数は、利用者数ではありません。CI環境からの自動ダウンロードも含まれています。
そのため「10,000人が使っている」とは言えません。一方で、約2か月で10,000ダウンロードを超えたことは、少なくとも一定数の開発環境で試され、継続的に取得されていることを示す数字だと受け止めています。
数字以上にうれしかったのは、「こういうツールが欲しかった」というフィードバックでした。
AI時代に必要なのは「ガードレール」
AIはこれからますますコードを書くようになります。しかし、AIが生成したコードをそのまま本番へ流す時代にはならないと思っています。
必要なのは、AIを信用することではなく、AIを安全に使うための仕組みです。私はこれを「AI Security Gate」と呼んでいます。
- Gitへ入る前
- CIへ流す前
- 本番へデプロイする前
各段階にガードレールを置くことで、AIをより安心して活用できるようになるはずです。
今後やりたいこと
KeyGateはまだ完成形ではありません。
今後は、
- より多くのシークレットフォーマットへの対応
- AI生成コードを前提とした検知ロジックの改善
- 開発者体験を損なわない運用機能の追加
に取り組んでいく予定です。AIがコードを書く時代だからこそ、「安全に開発するためのガードレール」の重要性は今後さらに高まると考えています。