この記事の目次
個人開発のページを公開する前に、READMEとスクリーンショットを見直しました。会社の名前も、自分のメールアドレスも書いていません。
でも、公開した変更履歴には、普段の仕事で使っているメールが記録されていました。ページの文章だけを見ていたら、ここには気づきにくいかもしれません。
これは説明のための架空の場面です。この記事は、仕事や私生活と分けた名前で、AIを使ってアプリや記事を公開する人に向けています。匿名で活動すべき、という話ではありません。公開したい名前や連絡先を、自分で選べる状態にするための点検です。
本文の外にも、公開される面がある
メタデータは、内容に付随する情報です。例えばGitのコミット、つまり変更の記録には、ファイルの差分とは別に作成者の名前やメールアドレスが含まれます。
公開される情報は、一枚のページに集まっているとは限りません。まず、自分が管理する公開先を、次の3つに分けて見てみます。
本文のほかに、2つの公開面を見る
- 自分が公開するもの
出す名前と範囲を、先に選ぶ。
- 本文と画像
コード・説明・スクリーンショット。
- 履歴と配布物
コミットの作成者、付随情報。
- プロフィールとURL
表示名・画像・リンク先。
一つ目は、コードや記事、画像の中身。二つ目は、その履歴と配布物に付く情報。三つ目は、公開サービス上の表示名・画像・URL・リンクです。本文でメールを検索して見つからなくても、残りの面を確認したことにはなりません。
逆に、ハンドル名や顔を自分の活動として公開する選択もあります。大切なのは、仕事用の連絡先や家族の情報まで、意図せず同じまとまりへつながっていないかです。
見せる名前を、先に決めよう
活動名、公開用の連絡先、使う画像を一度決めておくと、登録画面やAIの提案を一つずつ迷わず確認できます。人によって、出したい範囲は違って構いません。
GitHubのプロフィールと、Gitの作成者は別に見る
GitHubの表示名を替えても、手元で作ったコミットの作成者情報まで同時に替わるわけではありません。Gitは、実行環境やリポジトリの設定を使って、その時点の作成者を記録します。
リポジトリは、コードと履歴を管理する場所です。仕事と個人開発で同じPCを使う場合は、全体の設定を変える前に、その個人開発リポジトリで使う名前・メールの設定を確認します。全体への変更は、他の作業にも影響します。
アカウントの表示と、記録の作者を分ける
- プロフィールの変更
サービス上で見える名前や画像を設定。
- コミットの作成者
作成時のGit設定が記録に付く。
GitHubのSettings → Emailsでは、メールの非公開設定と、GitHubが提供するnoreplyアドレスを確認できます。手元のGitで使う場合は、画面に表示された自分用のアドレスを設定します。他人の例の番号やアドレスは流用しません。コミット用メールの公式資料
noreplyは、個人メールをコミットへ載せる代わりの選択肢です。公開ユーザー名や他の手がかりまで隠す仕組みではありません。また、GitHub画面上のメール非公開設定だけで、手元のGitによる今後すべての記録が置き換わるとは考えません。
手元の設定を確かめる場合は、自分が管理する対象リポジトリのフォルダで、次の読み取りだけのコマンドを使えます。名前やメールが表示されるため、結果は自分の画面で確認し、そのまま公開やAIへの貼り付けをしないでください。
git config --show-origin --get user.name
git config --show-origin --get user.email設定元と値を確かめます。何も出なければ、設定の存在を確認できていません。空欄を「非公開」の意味にしないでください。
環境変数や開発ツールの指定で、作者が変わる場合もあります。最後に公開予定のコミットを見て、実際の作者を確かめます。
設定が意図と違う場合は、対象リポジトリの範囲で公開用の作者へ直し、次に作った記録で結果を確かめます。作成済みの記録への対応は、後の節で分けて考えます。
GitHubには、非公開メールを露出するコマンドラインからのpushを止める設定もあります。公式説明では、push時の最新コミットの作成者メールが対象です。本文、過去の全コミット、別の公開情報をすべて検査するものではありません。pushを止める設定の公式説明
本文にないメールが、記録には付いている
次は、自分のPCのNode.jsで動かせる架空例です。実際のGit設定や履歴は読みません。example.invalidはこの例のための架空アドレスです。実行しない人も、結果から違いを追えます。
const file = "# Demo app\n公開する説明です。";
const record = {
file,
author: { name: "DEMO_HANDLE", email: "demo@example.invalid" },
};
console.log("本文にメール:", file.includes(record.author.email));
console.log("記録にメール:", Boolean(record.author.email));
const nextAuthor = { name: "NEXT_HANDLE", email: "next@example.invalid" };
console.log("次の設定:", nextAuthor.name);
console.log("過去の記録:", record.author.name);本文にメール: false
記録にメール: true
次の設定: NEXT_HANDLE
過去の記録: DEMO_HANDLE本文にはなくても、記録の別の欄には情報があります。さらに、次に使う設定を作っても、過去の記録は変わりません。このコードはGitの実装や匿名化ツールではなく、本文・付随情報・今後の設定を分けるためのモデルです。
その確認で分かるのは、どこまで？
本文のメールを検索
本文の確認ができた
作成者の記録や、プロフィールまで確認した意味ではありません。
今後の作成者設定を変更
過去の記録は別に確認
設定変更だけで、以前のコミットが置き換わったとは判断しません。
公開プロフィールを更新
URLや他の写しも見る
別の公開面、残るコピー、リンクの関係を整理します。
実際の確認では、公開予定のコミットの作成者とメールを、自分の端末やサービス上の詳細表示で見ます。出力を丸ごと公開したり、AIへ貼ったりする必要はありません。画面上で省略されて見えなくても、情報がないとは限らないため、必要ならGitHubの詳細表示と公式資料を照合します。
同じ名前を隠しても、別の手がかりは残る
例えばプロフィールの表示名を活動名へ替えても、アイコンが仕事用の顔写真のままだったり、自己紹介のリンクが個人アカウントへつながっていたりします。各情報は単独では問題なくても、組み合わせると自分が分けたかった活動につながることがあります。
登録時の3つの項目を見比べる
- 表示名
活動で見せたい名前になっているか。
- 画像
初期値や別活動の画像が残っていないか。
- URLとリンク
ユーザー名やリンク先が意図したものか。
外部アカウントでのログインでは、名前や画像が初期値として入るサービスがあります。何が取得・公開されるかはサービスごとに異なります。登録前の確認画面と、登録後に他の人へ見えるプロフィールの両方を見ます。
ユーザー名がURLに使われる場合は、表示名と別に確認します。名前を変えてもURLが変わらない、古いURLが転送されるなど、挙動はサービスによります。「替えれば以前のつながりも消える」とは約束できません。
同じPCで仕事用と個人用のアカウントを使うときは、登録や公開の直前に、今どのアカウントを使っているかを見ます。ブラウザのプロファイルを分ける方法は取り違えを減らす助けになりますが、Gitの設定や他アプリのログインまで自動で分離する保証にはなりません。
自分に見える設定と、相手に見えるページ
設定画面で意図した名前を選べたら、公開ページも確かめます。ログアウト状態などで確認できる範囲を見て、見えない部分は推測で埋めません。
参考記事で報告された、プロフィールの初期値
分類：確認できる事例なし。 この節では、独立した調査で確認された漏えい事故ではなく、著者自身の公開準備の報告を扱います。第三者に閲覧・保存された範囲や、その後の被害は確認できません。
情シス窓口さんは、2026年10月22日の個人開発時の運用記事で、登録時に表示名を変更した一方、アイコンは初期値のまま登録し、後から差し替えたと説明しています。
この報告から学べるのは、表示名を確認する工程があっても、同じ画面の別の公開項目を見落とし得ることです。「Googleログインを使う全サービスで、必ず顔写真が公開される」という一般化はしません。原記事には、実施済みの設定と今後見直したい推奨も含まれるため、すべて設定済みの環境として扱いません。
画像や配布物も、受け取った状態で見る
スクリーンショットには、本文以外にもタブ名、通知、アカウントのアイコン、ファイルパスなどが写ります。載せたい画面だけでなく、周辺に何があるかを確認します。
ファイル形式によっては、文書の作成者などの付随情報も持ちます。扱う形式のプロパティや公開用の書き出し設定で確認します。アプリによって保持される項目は異なり、この教材では「この書き出しならすべて除去できる」とは判定しません。
編集したファイルから、実際の配布物へ
- 作業中に整える
不要な周辺情報を含めない。
- 形式に応じて確認
画像や文書の付随情報と書き出し設定。
- 受け取る物を見る
公開URLから届くファイルを照合。
例えば「作業用の画像を公開用へ差し替えた」なら、実際にダウンロードされる画像が差し替わっているかも見ます。プレビューだけが新しく、配布ファイルが古い状態は別の問題です。配布物の確認へつなげて考えます。
一方、運営上必要な表示や連絡窓口まで、何でも消すという意味ではありません。活動として出す情報、問い合わせに必要な情報、出す必要のない仕事・私生活の情報を分けます。必要な表示の判断に迷うときは、利用サービスの規約や該当する専門家へ確認します。
既に公開した情報は、これからの設定と分けて対応する
今後の設定を直したら、既に公開した場所、公開期間、情報の種類、残る写しを整理します。メールなら個人メールか業務連絡先か、画像なら誰が写っているかで、必要な対応は変わります。
今後の設定と、既に公開した情報
- これから記録する情報
対象環境とリポジトリの設定を確認。
- 既に外へ出た情報
種類・範囲・コピー・削除方法を整理。
GitHubの公式資料は、履歴の書き換えには共同作業者との調整や副作用があることを説明しています。現在のファイルや表示を消しても、コピーやforkなどに情報が残る場合があります。機密情報の削除に関する公式資料
そのため、ここでは一律に履歴の書き換えや強制pushを勧めません。影響を判断し、必要なら共同作業者・サービスのサポートと削除方法を調整します。第三者が既に保存した情報を完全に回収できるとは限りません。
パスワードやAPIキーまで含まれていた場合は、個人情報の表示調整とは別です。発行元で失効・交換し、利用状況を確かめる事故対応へ進みます。メールをnoreplyへ替えることでは、露出した認証情報は無効になりません。
3つの役割で、公開する情報を選ぶ
活動する本人：見せたい範囲を決める
活動名、公開用の連絡先、アイコン、リンク先を選びます。仕事の規則や共同運営者の意向がある場合は、それも確認します。AIが作ったプロフィールの文章に、自分が出すつもりのない所属や情報が足されていないかを見ます。
作業環境を扱う人：記録の設定を確かめる
個人用リポジトリの作成者設定、公開予定のコミット、ログイン中のアカウントを確認します。新しく複製したリポジトリ、別PC、クラウドの開発環境でも同じとは限りません。実際に記録された情報を見て判断します。
公開物を確認する人：相手に届く面を確かめる
ファイル本文だけでなく、履歴・配布物・プロフィール・URLを見ます。自分の管理する公開先を対象にし、他人の情報を集める調査には広げません。第三者の顔や連絡先が含まれた場合は、本人や管理者と対応を調整します。
一人で兼ねても構いません。AIには公開予定の項目やチェックの整理を頼めますが、実際の個人メールや画像を追加で渡さない方法を選べます。公開前の確認結果がそろった後の手順は、必要に応じて自動化できます。
公開前に、結果で確かめる
- 活動の境界： 表示名・連絡先・画像・リンク先について、今回公開するものを自分で選んでいる。匿名性を保証するチェックとはしない。
- コミット： 対象リポジトリの公開予定の作成者とメールを確認した。今後の設定と、過去の記録を混同しない。
- プロフィール： 登録後に見える名前・アイコン・URL・自己紹介を確認した。表示名だけの点検で終えない。
- 画像と配布物： 相手が受け取るファイルと画面を確認し、不要な周辺情報や形式に応じた付随情報を見た。未確認の形式は安全確認に数えない。
- 既存の公開： 対象と情報の種類を把握し、設定修正だけで済むか、削除や相談が必要かを分けた。秘密なら失効対応へ進む。
- 次の環境： 新PC・新アカウント・新公開先を使う際の確認担当と項目が決まっている。
新しい連携と、公開先が増えたときに見直す
公開面が増えたときに見直す
- 新しい環境・連携
新PC、ログイン、共同作業。
- 増えた情報経路
記録の作者と公開先をたどる。
- 意図した範囲へ
結果を確認し、必要な設定だけ整える。
新しい開発環境、外部ログイン、共同作業、配布形式の追加は、見直しのきっかけです。全部を毎回一から疑うより、増えた公開面と、そこへ渡す情報を具体的に追います。
出したい自分を、ちゃんと選ぶ
名前を隠すことだけが目的ではありません。活動として見せたい情報が、意図した場所と範囲へ届くように整えましょう。
AIへ渡す情報の整理、会話やログの写し、公開前のGitHubチェックも合わせて確認してください。
一次資料と参考記事
情報確認日：2026年10月24日。プロフィールの取得項目や公開設定、メールの表示方法はサービスと操作方法で異なります。現在の設定と公式説明を照合してください。
- GitHub：コミット用メールアドレスの設定 — GitとWebの設定、変更前のコミットの扱い。
- GitHub：個人メールを露出するpushを止める — 設定の対象と限界。
- GitHub：リポジトリから機密情報を削除する — 履歴変更の影響と、残るコピーへの対応。
- 情シス窓口：個人サービス公開時のプライバシー運用 — 2026年10月22日公開。著者の実践・推奨を区別して参照。
書いた人
マーケティングの現場から、AIをつくり、仕事で使う側へ。実際に試したことや、つまずいたことを、図解と具体例で伝えています。
この記事のURL：https://nekoai-lab.github.io/ai-security-playbook/learn/developer-privacy/
続けて読む
次に読む緑のチェックが付いた。その変更を公開していい？
読む順番・ルートを見る
AIで作って公開する基本- AIに渡す情報を、送る前に分ける
- 「学習しない」AIなら、仕事の個人情報を使える？
- AIで作ったアプリの、動く場所を知る
- AIに「APIキーを設定して」と言われた。どこに入れるのが正解？
- APIキーを替えたのに、古いキーが使われている？
- ログインと、データを使う権限を分ける
- 公開したのは、本当に見せたいファイルだけ？
- コードには書いていない。名前やメールは、どこから公開される？
- 緑のチェックが付いた。その変更を公開していい？
- AIレビューが合格した。その結果を、どこまで信じていい？
- AIにデプロイを頼んだ。その認証情報は、どこまでできる？
- AIで作ったサービスを、公開する前に確かめる
- 外部サービスが止まったら、自分のアプリはどうなる？
- 漏えい・異常・消失に気づいたとき、最初にすること
