「気をつける」では止まりません

社内で情報の取り扱いルールを決めるとき、最後はたいてい「各自、気をつけること」で終わります。

ただ、気をつけていても止まらない種類の事故があります。 しかも代表的な例では、起きたあとに取り消すことができません。

この記事では、実際に何が起きているのかを整理します。対策の中身までは書きません。 まず、何が起きうるのかを知っていただくための記事です。

何が起きているのですか？

社外に出すべきでない情報が、意図せず外部へ上がっています。

査読付きの学術調査があります。GitHubという、プログラムの開発現場で広く使われているファイル保管サービスを対象にしたものです。調査期間は2017年10月から2018年4月で、NDSS Symposium 2019で発表されました。

秘密情報の漏洩は10万を超える保管場所に及んでいた
毎日、数千件の新しい漏洩が発生していた
見つかった秘密情報のうち、89.10%が実際に悪用されうるものだった

出典はHow Bad Can It Git?（NDSS 2019）です。

ここでいう秘密情報とは、外部サービスに接続するための鍵にあたるものです。 盗まれると、他人が自社の名前でそのサービスを使えてしまいます。

なお、GitHubを運営する会社自身も、2024年の1年間で3,900万件を超える秘密情報が漏洩したと公表しています（GitHub公式ブログ、2025年4月時点）。学術調査とは対象も検出方法も違うため単純な比較はできませんが、近年も相当な規模で起きていることは分かります。

うっかり上げてしまったら、消せばいいのでは？

自分の手元から消しても、それで終わりにはなりません。

GitHubの公式ドキュメントには、機密情報を削除する手順のページがあります。そこには、削除しきれない範囲について次のように説明されています（GitHub Docs）。

履歴を書き換えて上書きしても、他人がコピーした先には残り続ける
他人のコピーからは、こちらで削除できない
特定の識別番号を知っていれば、削除したはずのものにも直接たどり着ける

先ほどの学術調査は、この制約を実験で確かめています。運営会社が推奨する削除方法を両方とも試したうえで、識別番号さえ分かれば削除済みの中身を丸ごと復元できたと報告されています。

公式ドキュメントは、削除の手順よりも先に、鍵そのものを無効にして作り直すことを挙げています。取り消せない前提で書かれているということです。

削除された割合は、どれくらいですか？

約2週間のうちに削除されたのは、見つかった秘密情報の19%でした。 残りの81%は、その時点で残ったままです。

これも同じ学術調査の数字です。人数ではなく、秘密情報の件数の割合です。

なぜ8割が残ったままなのか、その理由まで調査は示していません。手順が分からなかったのかもしれませんし、消せないと知って諦めたのかもしれません。ただ、上げてしまったこと自体に気づいていない場合も含まれている可能性があります。

そして、気づいていない人は、当然ながら申告もしません。 会社として「事故は起きていない」と認識していても、それは報告が上がってきていないというだけかもしれない、ということになります。

なぜ気をつけていても防げないのですか？

人の注意力に頼る対策には、限界が知られているからです。

これは情報セキュリティに限った話ではありません。製造業や食品業の現場では、以前から扱われてきた考え方です。

農林水産省が公開しているヒューマンエラーの研修資料に、次のように書かれています（第1部ヒューマンエラーの仕組み）。

大切なことは、ミスをしないことではなく、事故やトラブルに拡大しない仕組みを作ることです。

同じ資料は、確認の回数を増やす対策についても触れています。3人で確認する体制にしても、「自分は見逃しても他の2人が見てくれる」という甘えが出てしまう、という指摘です。

確認を増やせば安全になる、とは限らないということです。 これは担当者の気の緩みというより、体制の作り方から生まれるものだと、この資料は説明しています。

そして情報の事故には、もう1つ条件が加わります。手が滑ったことが、その場では何も起きないことです。 ファイルを1つ余分に含めてしまっても、画面上は正常に処理が終わったように見えます。異常が起きないので、確認しようという気持ちにもなりません。

プログラムを扱わない会社にも、関係ありますか？

GitHubへの誤公開という事故そのものは、当てはまらない会社もあります。

正直に書きます。紙とメールだけで業務が回っている会社であれば、GitHubへの誤公開という事故は起きません。

ただ、業務をパソコンの中のファイルで動かすようになると、事情が変わります。 ファイルを共有する、バックアップを取る、外部のサービスと連携させる。こうした場面が増えるほど、「うっかり一緒に含めてしまう」機会も増えます。

AIに業務を任せる場合はなおさらです。ClaudeCodeに、パソコンの中を勝手に見られませんかでも書いたとおり、AIはファイルを扱う道具です。扱うファイルが増えれば、混ざる機会も増えます。

そして、より広く当てはまるのは構造のほうです。「各自が気をつける」で終わらせているルールは、情報管理以外にも社内にあるのではないでしょうか。

では、どうすればいいのですか？

人の注意ではなく、仕組みで止めるしかありません。

農林水産省の資料が言うとおり、目指すべきは「ミスをしないこと」ではありません。ミスをしても事故にならない状態です。

具体的にどう組むかは、御社が何を扱っていて、誰がどう作業しているかによって変わります。ここから先は、業務ごとに設計する話になります。

この記事では、そこまでは書きません。まず知っていただきたかったのは、次の2点です。

一度外に出た情報は、自分の手元から消しても取り消せない
削除されないまま残っている割合が、調査では8割にのぼっていた

この2点を踏まえたうえで、「気をつけましょう」で終わらせてよいかどうかを、一度考えていただければと思います。

よくある質問

非公開の設定にしていれば大丈夫ですか？

非公開の設定は前提として必要ですが、それだけで完結する話ではありません。閲覧できる人が増えるほど範囲は広がりますし、設定は人が行うものである以上、この記事で書いた「気をつける」の限界がそのまま当てはまります。

古い調査のようですが、いまも同じ状況ですか？

学術調査の対象期間は2017年から2018年です。2024年についてはGitHub社自身の公表数字があり、規模の大きさは分かりますが、対象も検出方法も違うため、増えたか減ったかを比べることはできません。 少なくとも、解消された問題ではありません。

漏れたかどうかは、どうすれば分かりますか？

自分の手元を見ても分かりません。この記事で書いたとおり、他人がコピーした先はこちらから確認できないためです。起きてから探すのではなく、起きないようにする側に手をかけるしかありません。

まとめ

外部に上げた秘密情報は、他人のコピー先からは削除できないと公式ドキュメントが説明している
学術調査では、約2週間で削除されたのは19%。8割は残ったままだった
確認の回数を増やしても、「他の人が見てくれる」という甘えが出ると公的資料が指摘している

「各自、気をつけること」で終わっているルールが社内にあるなら、そこは止まっていない可能性があります。

Black Bullの導入支援では、業務ごとに何を止めるべきかを整理し、「ClaudeCode構築仕様書」という形にまとめて御社に残しています。何から手をつけるべきか分からない、という段階でのご相談で構いません。お気軽にお声がけください。