【セキュリティ】技術記事における機密情報マスキング設計パターン
設計約5分で読めます
この記事でわかること
- 公開前にマスクすべき情報の 7 カテゴリと、それぞれの Before / After
- 変数名や関数名に混ざる固有名詞が一番見落としやすいということ
- マスク後も技術的な意味が残るプレースホルダーの揃え方
- 公開前に回す 4 つのチェック
特にありません。業務で得た知見を公開する立場の人なら、言語やツールを問わず使えます。
ポイント
技術ブログやドキュメントを公開する際に、機密情報を安全にマスクするための設計パターンと実装ガイドラインを解説します。
はじめに
開発中の学びや知見を技術記事として公開したい。でも、そのままコードやログを載せると会社名やAPIキーが漏れてしまう...
この記事では、そんな悩みを解決するための「機密情報マスキング設計パターン」を紹介します。Claude Code Skills で自動記事化する仕組みを作る中で設計したルールを、汎用的に使えるパターンとして整理しました。
マスキングが必要な理由
技術記事を公開する際、以下のリスクがあります：
- セキュリティリスク: APIキーやパスワードの漏洩
- プライバシーリスク: 個人情報の流出
- ビジネスリスク: 競合への情報漏洩
- コンプライアンスリスク: 契約違反・NDA違反
一方で、過度なマスキングは記事の価値を損ないます。バランスの取れた設計が重要です。
マスキング対象の7つのカテゴリ
1. 会社・組織情報
会社名、プロジェクト名、リポジトリ名、チーム名などが対象です。
# Before
〇〇社の××プロジェクトで...
△△/△△リポジトリの...
# After
[Company]の[ProjectName]で...
[organization]/[repository]の...注意
例外: React, Next.js, Django など一般公開されている OSS 名はマスク不要
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]重要
ポイント: 変数名（OPENAI_API_KEY など）は残してOK。値のみをマスク
3. ファイルパス
ユーザーホームディレクトリやプロジェクト固有のパスが対象です。
# Before
/Users/tanaka/Desktop/Job/Company/project/src/components/
# After
./src/components/
# または
[project-root]/src/components/4. 個人情報
氏名、メールアドレス、電話番号、社内 Slack/GitHub ID などが対象です。
# Before
田中太郎さんに確認して...
tanaka@company.com
# After
[Name]に確認して...
[email@example.com]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/users6. コード内の固有名詞
ビジネスロジック固有の変数名や社内用語を含む関数名が対象です。
// Before
const acmeUserId = "usr_12345";
async function processFooBarOrder(orderId: string) {
// After
const userId = "[USER_ID]";
async function processOrder(orderId: string) {重要
このカテゴリが一番見落としやすいです。環境変数や URL は「秘匿すべきもの」として意識されますが、変数名や関数名に混ざった固有名詞はコードの一部に見えるので、目が滑ります。grep するときは文章だけでなく、コードブロックの中の識別子まで見てください。
7. インフラ・ネットワーク情報
内部 IP アドレス、サーバー名、ポート番号などが対象です。
# Before
192.168.1.100:8080
db-server-prod-01.internal
# After
[internal-ip]:8080
[db-server].internalマスキングの判断基準
迷った時は以下のチェックリストで判断します：
- この情報が外部に出て問題ないか？
- 競合他社に知られて困る情報か？
- 個人を特定できる情報か？
- セキュリティリスクになりうるか？
注意
原則: 1つでも該当すればマスクする。迷ったらマスク。
マスキングプレースホルダー一覧
| 種類 | プレースホルダー | 例 |
|---|---|---|
| 会社名 | [Company] | [Company]のプロジェクト |
| プロジェクト名 | [ProjectName] | [ProjectName]リポジトリ |
| APIキー | [API_KEY] | Bearer [API_KEY] |
| パスワード | [PASSWORD] | password=[PASSWORD] |
| ファイルパス | [project-root] | [project-root]/src/ |
| 個人名 | [Name] | [Name]さんに確認 |
| メール | [email@example.com] | 連絡先: [email@example.com] |
| 内部URL | [internal-url] | https://[internal-url]/api |
マスク後の品質チェック
マスキング後は以下を確認します：
- Grep チェック: 会社名・プロジェクト名が残っていないか
- パスチェック: 絶対パスが残っていないか
- シークレットチェック: キー・トークンらしき文字列がないか
- 可読性チェック: マスク後も技術的に意味が通るか
自動化への組み込み
このマスキングルールは、Claude Code Skills の自動記事化機能に組み込むことで、手動チェックの手間を削減できます。
# ~/.claude/skills/[skill-name]/MASKING_RULES.md
# にルールを定義しておくと、
# Skills 実行時に自動参照されるまとめ
- マスキング対象は7カテゴリ（組織・認証・パス・個人・URL・コード・インフラ）
- 統一されたプレースホルダーを使うことで可読性を維持
- 「迷ったらマスク」が原則
- 公開 OSS 名や公式ドキュメント URL はマスク不要
- 自動化と組み合わせることで安全かつ効率的な記事公開が可能
参考リンク
更新履歴
- 本文のコード例に実在の固有名詞が残っていたのを汎用のダミー名に差し替え（マスキングを解説する記事自体がマスクできていなかった）。あわせて、コードブロック内の識別子まで grep すべきだという注意を追加。参考リンクがテキストだけで URL がなかったのをリンクに差し替え。「この記事でわかること」「対象読者」を概要プロパティへ移動。
