ラピットくん 
2026年4月24日、クラウドファンディング大手の CAMPFIRE 社が、GitHub アカウントへの不正アクセスを端緒に、最大 22.6 万件の個人情報漏えいの可能性を発表しました（うち口座情報を含むのは約 8.2 万件）。
このニュースを受けて、ある中小企業経営者と話していたところ、想定外の事実が判明しました。
「情報の住所」を決めていなかった経営者の話
ある日、その方が AI に自社のファイルシステムを点検させたところ、ソースコードリポジトリに紛れて、契約書・顧客リスト・人事・経理関連の業務ドキュメントまで、すべて GitHub の private リポジトリに push されていたのです。
数十回の commit 履歴。最古の commit に遡れば、過去のあらゆる時点のスナップショットが残っています。ファイル単位の削除では履歴に残るため、リポジトリ全体を即座に削除しました。
幸い、外部への流出は確認されていません。しかし、もし以下のいずれかが起きていたら、即座に重大インシデントになっていたはずです。
- アクセストークン（PAT）が他のリポジトリに混入し、第三者が取得していた
- 元従業員や業務委託先がアクセス権を保持したまま離反していた
- GitHub 側のサーバーインシデントが発生していた
問題の本質は「Private 設定だったかどうか」ではありません。「業務情報の住所」が決まっていなかったことです。
本記事で言う「情報の住所」とは、ある情報が どのシステム・どのフォルダに保管されるべきか を経営として明確に決めておくルールのことです。住所が決まっていないと、情報は意外な場所に流れ着きます。
※ 本記事は GitHub の危険性を指摘するものではありません。GitHub は適切に管理すれば極めて有用なツールです。本質は「どんなツールでも、情報の保管場所を経営として決めずに使えば事故につながる」という管理側の問題提起です。同じことは Google Drive、Dropbox、Slack、Notion、生成 AI ツールなど、すべてに当てはまります。
これは「セキュリティ」の話ではなく、「保管場所」の話
セキュリティ対策の前段階として、すべての情報には保管場所が決まっている必要があります。
例えば、、
- ソースコード → GitHub
- 契約書 → Google Drive（経営Drive）
- 顧客リスト → CRM ツール
- 経理 → 会計ソフト
- 人事 → 人事システム
住所が決まっていない情報は、必ずどこかに流れ着いてしまいます。たとえば、社長個人の PC のデスクトップに契約書 PDF が溜まっていく。Slack のスレッドに人事評価のメモが投稿される。AI とのチャット履歴に顧客リストが貼り付けられる ── どれも「便利だから」という理由で、行き先が曖昧なまま蓄積されていきます。
これは AI 時代に特に深刻になります。AI は何でも解釈し、何でも保存できる場所に流し込めるからです。情報の住所を決めることこそが、AI 時代の経営の最初の一歩 ── これが「フォルダ経営」の出発点です。
GitHub Private で情報が漏れる「7つの経路」（初心者向け）
「Private リポジトリは自分しか見られない」── そう思っている方に、まず知っていただきたい 7 つの漏洩経路 です。これは特殊なハッキングの話ではなく、日常の「うっかり」や「設定漏れ」で起きる現実的なパターンです。
① 共有相手の追加忘れ・解除忘れ
退職した従業員、契約終了した業務委託先のアクセス権が削除されないまま残り、後日リークされる経路。Twitter（2023）の事案が典型。「人を消す前にアクセス権を消す」が鉄則です。
② アクセストークン（PAT）の流出
PAT（Personal Access Token）は GitHub にログインするためのパスワード代わりのキー。これを別のリポジトリやネット上の投稿にうっかり貼ってしまうと、第三者がそのキーで private repo にアクセスできてしまいます。Mercedes-Benz（2024）の事案がこれです。
③ コード内に認証情報を直接書いてしまう（ハードコード）
API キー、データベースのパスワード、AWS の認証情報をコード内に直書きする経路。「private 内なら大丈夫」と思っても、コラボレーターやフォーク経由で容易に拡散します。Uber（2016）の 5,700 万人流出はこれが原因でした。
④ Public への切り替えミス
設定変更で誤って public にしてしまう経路。一度 public になれば Google にインデックスされ、その瞬間から世界中に公開されたものと同等の状態になります。SMBC（2021）の委託先エンジニアによる事案や、Toyota（2022）の 5 年放置はこのタイプ。
⑤ サードパーティ連携経由
GitHub に連携している CI/CD ツール、Bot、ブラウザ拡張機能、外部ベンダーが侵害された場合、その経路から private repo にアクセスされることがあります。Slack（2022）の事案は外部ベンダー経由のトークン窃取でした。
⑥ 個人アカウントの乗っ取り
開発者個人の GitHub アカウントが乗っ取られると、その人がアクセスできる private repo はすべて閲覧されます。2 要素認証（MFA）の未設定や、フィッシング被害が代表的な原因。CAMPFIRE（2026）の不正アクセスもアカウントレベルの侵害です。
⑦ Fork経由の履歴露出
private リポジトリから派生した fork や、過去に削除した commit / branch が、フォークした側の手元に残っていることがあります。「削除したから安全」とは限らない、という落とし穴です。
この 7 経路、すべてに共通する対策が、「情報の住所を決めること」です。住所が決まっていれば、これらは「越境（住所違反）」として検知できます。決めていなければ、そもそも越境かどうか判定すらできません。
国内外で実際に起きた「住所違反」事件
「Private リポジトリでも情報は流出する」── これは決して仮定の話ではありません。冒頭で取り上げた CAMPFIRE 事案を含め、過去の事例を時系列で並べると、共通項が浮かび上がります ──「情報の保管場所が曖昧だった」こと。
| 年 | 企業 | 流出経緯 | 規模・影響 |
|---|---|---|---|
| 2016 | Uber | private リポジトリ内に AWS キーをハードコード | 5,700 万人分の個人情報 |
| 2021 | 三井住友銀行（SMBC） | 委託先エンジニアが個人サービス利用目的で公開リポジトリにアップロード | 業務コード一部（顧客情報含まず） |
| 2022 | Toyota（T-Connect） | 委託先のソースコードに access key が混入し、5 年放置 | 約 30 万人の顧客情報 |
| 2022 | Slack | 外部ベンダー経由で従業員トークンが窃取され、複数のprivate リポジトリにアクセス | private リポジトリ複数 |
| 2023 | Twitter / X | 退職者と推定される人物が長期間にわたり commit し、ソースコードを公開 | 内部ツール含むコード一式 |
| 2024 | Mercedes-Benz | GitHub PAT が公開リポジトリに紛れ込み、内部リポジトリにアクセス可能に | DB 接続文字列・API キー |
| 2026 | CAMPFIRE | GitHub アカウントへの不正アクセスを端緒に、データベースへ侵入 | 最大 22.6 万件の個人情報（うち口座情報 8.2 万件） |
「住所が決まっていない情報は、いずれ間違った場所に流れ着く」 ── これが流出に共通するパターンです。
なぜ「住所が曖昧」だと漏れるのか
① 人的ミスは必ず起きる
新人の操作、疲労時のうっかり、引き継ぎ漏れ。「私だけは大丈夫」と思っている人ほど起こします。住所が決まっていれば、ミスは「置き間違い」で済みます。決まっていなければ、ミスは「漏洩」に直結します。Mercedes-Benz、Toyota、SMBC ── どれも「優秀なエンジニアの単純なミス」が起点でした。
② AI 時代で commit 頻度が爆発している
Claude Code、GitHub Copilot、Cursor ── AI 開発支援ツールの普及で、GitHub Copilot のランダム化試験では週次 commit 数が +13.55%、個人レベルのコード output は +20〜40% 増えたという研究報告があります。さらにコードだけでなく、Markdown で業務ドキュメントを管理する文化も広がっています。commit 頻度が増えれば、住所違反の機会も同じだけ増える── これが、いま経営に効いてくる構造変化です。
③ 越境チェックが効かなくなる
PAT、Deploy Key、Webhook、退職者の権限、サードパーティ連携、フォーク経由 ── すべてが「住所違反」の経路になり得ます。住所を決めていれば、これらは「越境」として検知できます。決めていなければ、そもそも越境かどうか判定すらできません。
フォルダ経営から見た 5 つの設計原則
【1】情報の住所を分離する（住所主義の原則）
GitHub に置くのはソースコードのみ。契約・顧客・人事・経理は、Google Drive や OneDrive など別系統のクラウドストレージへ。保管場所を物理的に分離することで、誤 commit のリスクを根絶します。
【2】行き先未定の情報は、ローカルにも置かない
開発機にあるとつい git add . してしまいます。業務情報はクラウドストレージにのみ置き、ローカルからは完全分離。行き先が決まっていない情報をローカルに溜めない、これだけで「うっかり commit」の半分は消えます。
【3】住所違反を機械で検知する
GitHub には push 前に認証情報を検知してブロックする機能（Push Protection）があり、2024年3月から個人アカウントでも無料で有効化できます。住所違反は人間の注意ではなく、機械で止めるのが鉄則です。
【4】保管場所と権限の四半期棚卸し
コラボレーター、Deploy Key、PAT、Webhook、Outside collaborator ── 四半期に一度、保管場所と権限を全部リスト化して見直します。退職・契約終了時の即時剥奪も徹底。Twitter のように退職者と推定される人物が後日リークする事案を防ぎます。
【5】AI に住所を点検させる
月に 1 回、AI に「このリポジトリに住所違反の情報が含まれていないか」を点検させます。AI で初期検知し、最終判断は人間が行う ── これが現実的なバランスです。冒頭の経営者がヒヤリハットを発見できたのも、まさにこの AI 点検の運用でした。
住所設計は、半年伴走でしか身につかない
ツールは半年で陳腐化し、攻撃手法は日々進化します。Claude Code が登場（2025年2月）してまだ 1 年余りなのに、業務への浸透度は劇的に変わりました。これは「変化が速い」というよりも、「変化が常態」です。半年で陳腐化するツールに対しては、半年単位で身につける研修こそが理にかなっています。
- 1 日の研修だけでは、現場で「どこまで安全か」を判断する感覚は身につきません
- 「住所を決めて運用する」習慣は、半年単位の伴走でしか定着しません
- セキュリティは知識ではなく、情報の住所を決め、守り続ける習慣です
AppTalentHub の DX-NoCode BootCamp® は、半年間の伴走型研修で、AI ツールを「住所を決めて」安全に運用する習慣まで定着させます。Claude Code・GitHub Copilot・Cursor などの AI 開発支援ツールを「使う前に何を確認すべきか」「住所違反を起こさないチーム運用」まで、実際の業務シナリオで身につけます。
まとめ ── 今夜、3つだけチェックしてください
- Private リポジトリは「住所」を保証しません
- すべての情報には住所が必要。住所が決まっていない情報は、いずれ間違った場所に流れ着きます
- AI 時代の経営の第一歩は、情報の住所設計（フォルダ経営） から
冒頭で紹介した経営者は、ヒヤリハット段階で気づけたことが幸運でした。あなたの会社でも、今夜、以下の3つだけチェックしてください。
- GitHub の private リポジトリに、業務文書（PDF・Excel・契約書等）が混じっていないか
- ローカル PC のデスクトップ・ダウンロードフォルダに、契約書・顧客リストが溜まっていないか
- アクセス権を持つメンバー全員が、現在も在籍しているか
1つでも気になる項目があれば、住所設計を見直すタイミングです。
情報の住所を決め、習慣化する。
DX-NoCode BootCamp® は、Claude Code・GitHub Copilot・Cursor などの AI ツールを「住所を決めて、事故を起こさず業務に組み込む」ための半年伴走型プログラムです。
▶ DX-NoCode BootCamp® の詳細はこちら
