このサイトはAIと一緒にコードを書いていますが、絶対に守らなければいけない制約が一つあります。「氏名・電話番号・会社名など、運営者個人を特定しうる情報を、ページのどこにも一切出力しない」というものです。これは口頭で一度伝えて終わり、にはできません。会話が長くなるほど指示は薄れていくので、リポジトリ直下に置く1枚のルールファイルとして実装しました。

「禁止リスト」と「許可リスト」をセットで書く

最初、禁止事項だけを書いていた時期がありました。しかしそれだけだと、AIは何を書けば安全なのか判断できず、経歴の記述そのものを過度に抽象化しすぎたり、逆に無難な固有名詞を混ぜて安全ラインを踏み越えたりします。そこで「書いてはいけないもの」と「書いていいもの」を対にして明記するようにしました。

## 記載してよいもの
- 一般に広く通じる技術・サービス名（例: PHP, Laravel, WordPress, AWS...）
- 役割・担当工程・技術スタック・成果（数値・規模）を抽象化した経歴
- 業界はぼかす前提で可（例: 「報道・メディア領域」程度の粒度まで）

「業界名はどこまでの粒度ならOKか」を明示しているのがポイントです。単に「業界を伏せる」とだけ書くと、AIは安全側に倒しすぎて「IT業界」のような無意味に曖昧な表現しか書けなくなり、経歴の説得力が失われます。逆に緩すぎると特定の企業や案件が透けて見える粒度まで書いてしまいます。「報道・メディア領域、程度まで」という具体的な基準を一つ与えることで、抽象化の“ちょうどいい高さ”をAIが再現しやすくなりました。

「組み合わせ」の危険性を明示する

個人情報保護で見落としやすいのが、単体では無害な情報同士の組み合わせによる特定です。これもルールに明記しています。

- 上記を推測させる固有の組み合わせ
  （例: 特定の企業 ＋ 特定のイベント ＋ 特定業務のように、
    絞り込めてしまう記述）

社名を書かなくても、「特定の年に・特定の海外イベントで・特定の技術支援をした」という3つの要素が揃うと、検索一つで個人が特定できてしまうケースがあります。経歴のTimelineコンポーネントを書く際は、この「組み合わせの絞り込み度」を毎回意識する必要があり、単純な禁止ワードのフィルタリングでは防げない領域です。

「サンプルだから安全」という判断こそが危ない

もう一つ、実装時に効いたのが「ダミーの氏名も不可」というルールです。コードコメントやコミットメッセージの例文を書く際、AIは「実在の人物ではなく、あくまでサンプルだから」という理由で、とっさに一般的な氏名を書いてしまうことがあります。しかし匿名性を守る側からすれば、それが実在の名前と偶然一致していないかどうかは確認しようがなく、「サンプルだから安全」という判断基準自体が成立しません。ルールには、氏名というカテゴリそのものを、実名かどうかを問わず一律で禁止する、という形で書いています。

この判断は、記事を書く自分自身にも同じように及びます。実際、この記事の初稿では「禁止されている具体例」を示そうとして、ルールが名指しで挙げている禁止語をそのまま引用してしまい、結果的に実名を公開してしまうという失敗をしました。ルールを説明する記事自体がルールを破ってしまう、という笑えない事故です。この経験から、「何が禁止されているか」を説明する際も、禁止語そのものを引用せず、あくまで抽象的なカテゴリ(氏名・電話番号・会社名など)として言及する、という運用に改めています。

ルールはコードと同じ場所に置く

このルールはドキュメントとして別置きにせず、リポジトリ直下の CLAUDE.md に置いています。AIが実装作業に入るたびに必ず読み込む場所に制約を置くことで、「今回はうっかり忘れていた」という事態を構造的に防ぐ狙いです。README（人間向けの説明）とは役割を分け、CLAUDE.md は「AIが実装する際に絶対に外してはいけないガードレール」専用のファイルとして運用しています。

匿名性を保ったままポートフォリオとしての説得力を出す、という一見矛盾した要求は、「何を隠すか」だけでなく「何を、どの粒度まで出していいか」を具体例つきで先に決めておくことで、AIと人間の両方が迷わず運用できるようになる、というのが実感です。そして、そのルールを解説する側にも同じ厳密さが要る、というのが今回の一番の教訓でした。