「社内ツール、GitHubに置けたよ！」
うれしそうな報告の画面に、小さく「Public」の文字。……ちょっと待ってください。それ、全世界に公開されています。
今回は、実際にあったヒヤリハットをもとに、GitHubの「公開設定」について漫画でまとめました。エンジニアの方はもちろん、「開発は外部に任せているけど、GitHubはよくわからない」という経営者・管理部門の方にこそ読んでいただきたい内容です。読み終わったら、そのまま今日確認できるチェックリスト付きです。
第1条：公開設定を確認せよ
GitHubにコードを置くとき、リポジトリ（コードの保管場所）には「Public」と「Private」という設定があります。Publicは、社内のメンバーだけでなく、インターネット上の誰でも閲覧できる状態です。
本人に公開するつもりがなくても、設定がPublicなら世界中から見えます。「アップロードできた＝安全に保管できた」ではない、というのが今日の出発点です。
PublicとPrivateはワンクリック差
- Public：誰でも閲覧できる
- Private：許可した人だけが閲覧できる
この2つ、作成画面ではラジオボタンひとつの違いです。悪意がなくても、急いでいても、間違えられる距離にあります。
さらに見落としがちなのが「新規作成時の初期値」。デフォルトがPublicになっている環境では、何も考えずに作ったリポジトリが次々と公開状態になります。個人の注意力の問題ではなく、設定の問題です。
コード公開を「家」でたとえると
コードは、家の設計図のようなものです。
Publicリポジトリは、家の門に「間取り図」「防犯カメラの配置」「見回り当番表」を貼り出している状態に近い。それだけで泥棒が入ってくるわけではありません。でも、侵入の手がかりを自分から増やしていることは間違いない。泥棒の作戦会議に資料を配っているようなものです。
コードの中は情報の宝庫
「コードなんて公開しても、素人には読めないでしょ？」と思うかもしれません。実際にコードの中に入っているのは、こんな情報です。
- 取引先の名前
- 社内システムのURL
- 業務ロジック（自社の業務の進め方そのもの）
- APIキー（外部サービスに接続するための「鍵」）
どれも、外に出してはいけない情報です。そしてPublicリポジトリの中身は、検索で見つかります。
人より先に、Botが見つける
「公開しちゃったけど、誰も見てないでしょ」——これが一番危険な思い込みです。
公開リポジトリは、APIキーなどの秘密情報を探すBot（自動プログラム）が常時巡回しています。人間が偶然見つけるより先に、機械が網羅的に見つける世界です。
「気づいてすぐ消したから平気？」——残念ながら、GitHubには変更履歴が残り、複製（フォーク）にも残ります。だから原則はひとつ。秘密情報は、公開された時点で漏えいした前提で動く。消して終わり、にはできません。
実際にあった「たまたまセーフ」
これは実際にあった話です。あるとき確認したら、Publicのリポジトリがいくつも見つかりました。作った本人に聞くと「PublicとPrivateを意識していなかった」。
慌てて中身と履歴を調べた結果——APIキーなし、顧客情報なし。今回は、被害につながる情報が入っていませんでした。
つまり、「たまたまセーフ」。
でも、「たまたま」は対策ではありません。次も同じ幸運が続く保証はどこにもないのです。
「公開」でセキュリティリスクが上がる理由
公開されると何が起きるのか、整理するとこうなります。
- 構成や接続先を知られる：システムの中身と外部接続が丸見えになる
- 攻撃者の手間を減らす：弱点を探すコストが大幅に下がる
- 秘密があれば被害に直結：APIキーが含まれていれば、サイト改ざん・情報流出・不正利用につながる
公開しただけで即侵入されるわけではありません。ただ、確実に「敵を助ける」行為ではあります。この温度感で理解しておくのが正確です。
見つけた直後の応急対応
もし「Publicになっている社内リポジトリ」を見つけたら、この順で動きます。
- まずPrivateに切り替える（これ以上の閲覧を止める）
- 公開されていた内容と履歴を確認する（何が・いつから見えていたか）
- APIキー等が含まれていたら、無効化して再発行する（鍵を替える）
- アクセスログを確認する（足跡を調べる）
ポイントは、「秘密が含まれていた前提」で動くこと。鍵を替えて、足跡も調べる。ここまでやって応急対応です。
今日、全リポジトリを一覧確認する
応急対応の話をしましたが、本当にやるべきは「事故が起きる前の棚卸し」です。やることはシンプルで、会社で使っている全リポジトリを一覧にして、1件ずつ確認するだけ。
確認する項目は3つ。「公開設定（PublicかPrivateか）」「管理者（誰が管理しているか）」「利用目的（何のためのリポジトリか）」です。
判断基準もシンプルです。公開する理由が説明できないなら、Private。「いつか」ではなく、今日やる。それくらいの温度感でちょうどいいテーマです。
事故は「仕組み」で防ぐ
最後に、再発防止です。個人の注意力に頼る対策は、いつか破られます。仕組みに落とし込みましょう。
- 新規リポジトリの初期値をPrivateにする（Organization設定で変更できます）
- Publicにするのは、理由がある場合だけ申請制にする
- 定期的に全件確認する
「全件確認」「初期値Private」「公開は申請」。この3点セットが回っていれば、「たまたまセーフ」に頼らなくてよくなります。
まとめ：今日の確認で、会社の家を守る
- GitHubのPublicは「全世界に公開」。PublicとPrivateはワンクリック差
- コードには取引先名・社内URL・業務ロジック・APIキーが入っている
- 公開リポジトリはBotが常時巡回。秘密は公開時点で漏えい前提
- 見つけたら：Private化 → 内容確認 → キー再発行 → ログ確認
- 予防は仕組みで：初期値Private・公開は申請制・定期的な全件確認
「うちの会社、大丈夫かな」と思った方は、この記事を閉じる前に、GitHubのリポジトリ一覧を開いてみてください。確認は数分で終わります。その数分が、会社の家を守ります。
株式会社Four Youでは、AI導入支援・システム開発とあわせて、こうした開発まわりのセキュリティ整備のご相談もお受けしています。「GitHubの棚卸し、何から手をつければいいかわからない」という段階からで大丈夫です。お気軽にお問い合わせください。
#GitHub #セキュリティ #情報セキュリティ #情報漏えい #開発 #DX #エンジニア #漫画でわかる #IT #システム開発
