はじめに

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

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

この記事でわかること

• 技術記事公開時にマスクすべき情報の分類

• 各カテゴリごとの具体的なマスク方法

• マスク後も技術的価値を維持するコツ

• 自動化に組み込む際の判断基準

対象読者

• 業務で得た知見を技術記事として公開したいエンジニア

• 社内ドキュメントを外部公開用に変換したい方

• 自動記事化システムを構築したい方

マスキングが必要な理由

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

1. セキュリティリスク: APIキーやパスワードの漏洩

2. プライバシーリスク: 個人情報の流出

3. ビジネスリスク: 競合への情報漏洩

4. コンプライアンスリスク: 契約違反・NDA違反

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

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

1. 会社・組織情報

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

# Before
Hakky社のtmc24プロジェクトで...
gaio-technology/tmc24リポジトリの...

# 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 hakkyUserId = "usr_12345";
async function processGaioOrder(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 はマスク不要

• 自動化と組み合わせることで安全かつ効率的な記事公開が可能

参考リンク

• OWASP - Information Disclosure

• GitHub - Secret Scanning

• Qiita / Zenn 投稿ガイドライン