【セキュリティ】技術記事における機密情報マスキング設計パターン

はじめに#

開発中の学びや知見を技術記事として公開したい。でも、そのままコードやログを載せると会社名やAPIキーが漏れてしまう...

この記事では、そんな悩みを解決するための「機密情報マスキング設計パターン」を紹介します。Claude Code Skills で自動記事化する仕組みを作る中で設計したルールを、汎用的に使えるパターンとして整理しました。

マスキングが必要な理由#

技術記事を公開する際、以下のリスクがあります：

1. セキュリティリスク: APIキーやパスワードの漏洩
2. プライバシーリスク: 個人情報の流出
3. ビジネスリスク: 競合への情報漏洩
4. コンプライアンスリスク: 契約違反・NDA違反

一方で、過度なマスキングは記事の価値を損ないます。バランスの取れた設計が重要です。

マスキング対象の7つのカテゴリ#

1. 会社・組織情報#

会社名、プロジェクト名、リポジトリ名、チーム名などが対象です。

# Before
〇〇社の××プロジェクトで...
△△/△△リポジトリの...

# After
[Company]の[ProjectName]で...
[organization]/[repository]の...

2. 認証・シークレット情報#

APIキー、アクセストークン、パスワード、データベース接続文字列などが対象です。

# Before
Authorization: Bearer sk-1234567890abcdef
DATABASE_URL=postgres://user:pass@host:5432/db

# After
Authorization: Bearer [API_KEY]
DATABASE_URL=postgres://[user]:[password]@[host]:5432/[database]

3. ファイルパス#

ユーザーホームディレクトリやプロジェクト固有のパスが対象です。

# Before
/Users/tanaka/Desktop/Job/Company/project/src/components/

# After
./src/components/
# または
[project-root]/src/components/

4. 個人情報#

氏名、メールアドレス、電話番号、社内 Slack/GitHub ID などが対象です。

# Before
田中太郎さんに確認して...
[email protected]

# After
[Name]に確認して...
[[email protected]]

5. URL・エンドポイント#

社内システム URL、ステージング環境、管理画面 URL などが対象です。

# Before
https://admin.company-internal.com/dashboard
https://api.staging.project-name.jp/v1/users

# After
https://[internal-admin-url]/dashboard
https://[staging-api]/v1/users

6. コード内の固有名詞#

ビジネスロジック固有の変数名や社内用語を含む関数名が対象です。

// Before
const acmeUserId = "usr_12345";
async function processFooBarOrder(orderId: string) {

// After
const userId = "[USER_ID]";
async function processOrder(orderId: string) {

7. インフラ・ネットワーク情報#

内部 IP アドレス、サーバー名、ポート番号などが対象です。

# Before
192.168.1.100:8080
db-server-prod-01.internal

# After
[internal-ip]:8080
[db-server].internal

マスキングの判断基準#

迷った時は以下のチェックリストで判断します：

• この情報が外部に出て問題ないか？
• 競合他社に知られて困る情報か？
• 個人を特定できる情報か？
• セキュリティリスクになりうるか？

マスキングプレースホルダー一覧#

マスク後の品質チェック#

マスキング後は以下を確認します：

1. Grep チェック: 会社名・プロジェクト名が残っていないか
2. パスチェック: 絶対パスが残っていないか
3. シークレットチェック: キー・トークンらしき文字列がないか
4. 可読性チェック: マスク後も技術的に意味が通るか

自動化への組み込み#

このマスキングルールは、Claude Code Skills の自動記事化機能に組み込むことで、手動チェックの手間を削減できます。

# ~/.claude/skills/[skill-name]/MASKING_RULES.md
# にルールを定義しておくと、
# Skills 実行時に自動参照される

まとめ#

• マスキング対象は7カテゴリ（組織・認証・パス・個人・URL・コード・インフラ）
• 統一されたプレースホルダーを使うことで可読性を維持
• 「迷ったらマスク」が原則
• 公開 OSS 名や公式ドキュメント URL はマスク不要
• 自動化と組み合わせることで安全かつ効率的な記事公開が可能

参考リンク#

• GitHub: Secret scanning
• OWASP: Information exposure
• Claude Code × Notion で開発セッションを自動記事化する仕組み（別記事）