株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
ソースコード納品前のセキュリティ検品とは？なぜ「grep一発」では不十分なのか
受託開発やPoC開発において、ソースコードをクライアントに納品する場面は頻繁に発生します。しかし、開発中のコードベースには社名、個人の開発環境パス、APIキー、データベース接続文字列、Azure/AWSリソース名、案件名など、本来クライアントに渡してはならない情報が散在しています。
GitGuardianの2026年版調査によると、2025年の公開GitHubコミットから約2,900万件の新しいハードコードされたシークレット（2,865万件）が検出されました。前年比34%増で、同社の観測で最大の年間増加です。また、2022年に有効と確認したシークレットの同一データセットを2026年1月に再検査したところ、64%超が依然有効でした（2026年3月17日公表の原調査解説）。
本記事では、ソースコード納品前に実施すべきセキュリティ検品（コードサニタイズ）の手法を、実際の開発現場で使われるチェックリストと具体的な作業手順に基づいて解説します。
納品前に除去すべき7カテゴリの情報
ソースコード納品前のサニタイズで対象となる情報は、大きく7つのカテゴリに分類できます。
1. 企業固有情報（社名・組織名）
開発会社の社名がコードベース全体に散在しているケースは非常に多く見られます。
- ロガー名：
logger = getLogger("mycompany.service") - docstring・コメント：
# Created by MyCompany Inc. - 環境変数テンプレート：
.env.example内のサンプル値 - Terraform変数名：
mycompany_vpn_ip→client_vpn_ipに変更
Terraformの入力変数名のリネームでは、名前と参照先の変更、実際の設定値の変更、リソースアドレスの変更を区別して確認します。.github/、.tfvars、CI/CDからの-var参照箇所を洗い出し、変数名と一緒に更新してからplanの差分を確認します。
2. クレデンシャル・シークレット
- APIキー：OpenAI、Anthropic、Azure等のAPIキー
- データベース接続文字列：
DB_URL=mysql+pymysql://user:password@host:3306/db - デフォルトパスワード：docker-compose.ymlのフォールバック値（
rootpassword等） - KeyVault名・リソース名：Azure KeyVaultの実名
- Terraformのtfplanファイル：commit済みのtfplanにはクレデンシャルが含まれる場合がある。保存したplanには機密値が平文で残り得る（Terraform公式仕様）
特に注意すべきは、commit済みのtfplanファイルです。納品対象に含まれている場合は、資格情報などの機密情報が残っていないか確認します。これは点検対象を説明する例であり、特定の開発現場で漏えいが起きたとする報告ではありません。
3. 個人開発環境パス
/Users/developer_name/Desktop/project/...C:\Users\developer_name\Documents\...
これらは開発者の氏名を含む場合があり、個人情報保護の観点からも除去が必要です。
4. 案件固有情報（プロジェクトコード・クライアント名）
- 変数名に含まれる案件名：
clientname_failure_data→analysis_data - コメント内の案件コード
- テストデータに含まれる実企業名
5. インフラリソース名
- Azure Resource Group名、ACR名
- AWS S3バケット名、Lambda関数名
- GCPプロジェクトID
6. 不要なAPI設定項目
- コードから参照されていないAPI設定（検証を終えたサービスの設定など）
- 開発時にのみ使用したデバッグ用エンドポイント設定
7. テスト・デバッグ用の残留コード
- デバッグページの表示制御コード
- テスト用ユーザー作成スクリプト
- 開発用のseedデータ
3コミット構成のサニタイズ作業手順
効率的にサニタイズを進めるため、変更対象をレイヤー別に3つのコミットに分割します。レイヤーごとに分けることで、レビュー時に「この変更はどの層に影響するか」が明確になります。
コミット1：アプリケーションコード・環境変数テンプレート
最もリスクの高い層から着手します。
- ロガー名の匿名化
- auth設定のdocstringからの社名除去
- 各
.env.example内のデフォルト値をプレースホルダーに置換 docker-compose.ymlのデフォルトパスワードフォールバック値の削除
なぜフォールバック値を削除するか：.env未設定時に弱いパスワードで起動できてしまう状態は、クライアント環境でのセキュリティリスクとなります。
コミット2：ドキュメント
docs/配下のサンプル値（メールアドレス、KeyVault名、FQDN、個人パス）をプレースホルダーに統一- README内の実環境URLをダミーに置換
コミット3：インフラ・スクリプト
terraform/内の変数名・リソース名から社名を除去scripts/内のハードコードパスとフォールバック値をプレースホルダーに変更
grepベースの完了検証
既知の文字列の確認では、公開・納品不可と決めた対象の残存がゼロ件になることを確認します。ゼロ件でも未指定のパターンやGit履歴の安全性は示せません。以下の検索例に、履歴スキャン・除外範囲の確認・差分レビューを組み合わせます（履歴を含む漏洩対応）。
| 検索対象 | grepパターン例 | 許容される残存 |
|---|---|---|
| 社名 | grep -ri --include="*.py" --include="*.ts" --include="*.yml" --include="*.md" --include="*.tf" "mycompany" . | 0件 |
| 案件名 | grep -ri "project_code_name" | 0件 |
| 個人パス | grep -ri --include="*.py" --include="*.ts" --include="*.yml" "/Users/" . | 0件（ドキュメント内のプレースホルダーは除く） |
| デフォルトパスワード | grep -ri "rootpassword\|password123" | 0件 |
| APIキー形式 | grep -rE "sk-[a-zA-Z0-9]{20,}|AKIA[A-Z0-9]{16}" . | 0件 |
スコープ外の判断基準
すべてのファイルをサニタイズ対象にすると、作業量が膨大になります。以下の判断基準でスコープを制御します。
スコープ外とすべきもの
data/配下の実データ：顧客の実データは匿名化ではなく「納品物から除外」で対応- ロックファイル内の案件名：
# viaコメントのみで動作に無関係。パッケージマネージャの再実行で自然に消える - デバッグページの除去：ページ定義の削除は機能変更を伴うため、別PRで対応
「変更はプレースホルダー置換のみ。ロジックには触れない」原則
サニタイズ作業では、ロジックの変更は一切行わないことが重要です。ロジック変更とサニタイズを同じコミットに混ぜると、レビューの負荷が跳ね上がり、デグレードのリスクも高まります。
シークレット検出ツールの活用
手動のgrepだけでは見落としが発生します。専用のシークレット検出ツールを併用することを推奨します。
主要ツール比較（2026年版）
| ツール | 特徴 | 検出時の確認点 | 用途 |
|---|---|---|---|
| GitGuardian | 450以上の検出器（公式紹介）、MLを用いた汎用検出（公式説明） | 特定形式向けと汎用の検出器で誤検知の傾向が異なる | CI/CD統合、リポジトリ全体スキャン |
| TruffleHog | OSSで利用可能、Gitのコミット履歴をスキャン（公式リポジトリ） | 有効・未検証・検証エラーを区別。取得済み履歴や対象設定を確認 | コミット履歴のレトロスキャン |
| GitHub Secret Scanning | Secret scanningでシークレットを検出。Push protectionはプッシュ時の混入防止機能 | 公開/非公開・契約と有効化・対応パターンによる | プッシュブロック、アラート |
| gitleaks | OSS、CI・pre-commitへの組み込みに対応 | 正規表現・エントロピー等の検出規則と除外設定を確認 | pre-commitフック |
Prevention-Firstアプローチ
上表は同一条件の精度比較ではなく、検出方法と確認点の整理です。GitHubの公開リポジトリのSecret scanningは無料で自動実行され、組織の非公開・内部リポジトリは対象プランとSecret Protectionの有効化が必要です。Push protectionも利用形態と設定で対象が変わります。
「検出→修正」に加え、「最初からシークレットを混入させない」Prevention-Firstアプローチを取り入れます。GitHub公式もpre-commitフックやシークレット管理サービスによる混入防止を案内しています。導入効果は、混入・検出・解消の状況を計測して確認します（公式の予防策）。
具体的には以下を実装します。
- pre-commitフックでのスキャン：コミット前にローカルでシークレットを検出
- CI/CDパイプラインでのスキャン：PR作成時に自動検出し、マージをブロック
- シークレットマネージャーの標準化：HashiCorp Vault、AWS Secrets Manager、1Password CLIでシークレットを一元管理
Terraform変数リネームの安全な手順
インフラコードのサニタイズでは、Terraformの変数名・リソースアドレス・属性値の変更を区別します。入力変数名だけを変更し、参照と値を揃えることと、stateに紐付くリソースアドレスを変更することは別です。後者ではmovedブロック等による移行が必要になる場合があります（入力変数、リソースの改名・移動）。
事前確認チェックリスト
- .tfvarsファイルの確認：変更する変数名が
.tfvarsで参照されていないか - CI/CDの確認：
-varフラグで外部から値を渡していないか - GitHub Actionsの確認：
.github/workflows/内で変数名を参照していないか - tfstateの確認：変数名だけでなく、リソースアドレスや属性の実際の値が変わるかを確認。再作成の有無はplanとプロバイダー仕様で確認
変数名と参照だけを変え、設定値・リソースアドレスを変えない場合（例：VPN IPアドレスの変数名をmycompany_vpn_ip→client_vpn_ipに変更）、入力変数の改名だけを理由とするリソースの再作成は通常不要です。ただし、値の受け渡し漏れがないことをplanで確認します。
docker-compose.ymlのサニタイズ
コンテナ化された開発環境では、docker-compose.ymlに機密情報が集中します。
よくある問題パターン
- デフォルトパスワードのフォールバック：
${DB_PASSWORD:-rootpassword}→.env未設定で弱いパスワードが使われる - ACR認証情報のハードコード：ACRのログイン情報がスクリプト内に直書き
- ボリュームマウントのパス：開発者のローカルパスが残っている
推奨対応
- フォールバック値を削除し、
${DB_PASSWORD:?DB_PASSWORD is required}のように必須指定する。環境変数や.env等から値を渡し、未設定・空文字ならエラーにする（Composeの必須値構文） .env.exampleにプレースホルダーと説明コメントを記載- ボリュームパスを相対パスに統一
AIエージェントを活用したサニタイズ効率化
AIコーディングエージェントを活用することで、サニタイズ作業を大幅に効率化できます。
AIに依頼する際のプロンプト設計
サニタイズ作業をAIに依頼する際は、以下の構造で指示します。
- スコープの明確化：対象ディレクトリ、除外対象を明示
- 「ロジックに触れない」制約の明記：プレースホルダー置換・削除・リネームのみ
- 完了条件の定義：既知の禁止文字列の残存ゼロに加え、履歴・除外範囲・差分の確認を完了条件として明示
- コミット分割の指示：レイヤー別（アプリ→ドキュメント→インフラ）に分割
業務をトレースし、各ステップの依存関係を理解してから自動化に取り組むことが重要です。「コードサニタイズを自動化」と言っても、どのファイルのどの情報を何に置換するかを事前に定義しなければ、漏れや誤置換が発生します。
AIエージェント活用の注意点
- AIにコードを渡す際のリスク：AIサービスにソースコードを送信する行為自体が、機密情報の外部送信となる可能性がある。エンタープライズプランやオンプレミスLLMの利用を検討
- AIの置換ミス：AIが文脈を誤解し、正常なコードまで書き換えるリスクがある。必ず差分レビューを実施
納品前セキュリティ検品チェックリスト
| チェック項目 | 確認方法 | 完了基準 |
|---|---|---|
| 社名・組織名の除去 | grep -ri "社名" | 残存0件 |
| 案件名・プロジェクトコードの除去 | grep -ri "案件名" | 残存0件 |
| 個人開発環境パスの除去 | grep -ri "/Users/" | 残存0件 |
| デフォルトパスワードの除去 | grep -ri "password" *.yml *.yaml | フォールバック値0件 |
| APIキー・トークンの除去 | シークレット検出ツール実行 | 検出0件 |
| tfplanファイルの除外 | git ls-files '*.tfplan'（拡張子のないplan等も別途確認） | 残存0件 |
| インフラリソース名の匿名化 | grep -ri "リソース名パターン" | 残存0件 |
| 不要API設定の除去 | コード参照確認 | 未使用設定0件 |
| .env.exampleの整備 | プレースホルダー確認 | 実値0件 |
| テストデータの確認 | 実企業名・実データ確認 | 実データ0件 |
| Git履歴の確認 | gitleaks / TruffleHog実行 | 歴史的シークレット0件 |
| ビルド確認 | yarn build / docker build | エラー0件 |
まとめ：サニタイズは「最後の作業」ではなく「プロセスに組み込む」
ソースコード納品前のセキュリティ検品は、プロジェクト終盤の「最後のタスク」として扱われがちですが、それでは漏れが生じます。理想的には、以下のようにプロセスに組み込みます。
- 開発開始時：
.env.exampleをプレースホルダーで作成、.gitignoreでシークレット系ファイルを除外 - 開発中：pre-commitフックでシークレット混入を防止、CI/CDでスキャン
- 納品前：本記事のチェックリストに基づくサニタイズ実施、レイヤー別コミット
- 納品後：commit済みのシークレットを発見したら即座に無効化・ローテーション。納品前に見つけた場合も同様に対応
「後から消す」のではなく「最初から入れない」。Prevention-Firstの考え方を組織の開発文化に根付かせることが、長期的なセキュリティ向上の鍵です。
あわせて読みたい
- 5Sとは｜整理・整頓・清掃・清潔・しつけの意味・目的・進め方を解説
- AIリードスコアリング実装ガイド【2026年版】— 4要素スコアリング×テリトリー管理×ステータス倍率の本番アーキテクチャ
- AIカスタマーサポート完全ガイド【2026年版】— RAG・チャットボット・有人連携の実装パターンとツール比較
関連記事
開発プロセスの改善はrenueにご相談ください。
