企業がGitHubを
避けた理由を振り返ってみる

by

GitHubは、2010年代、すでに個人開発者やスタートアップに広く使われていました1。
ただ、それでも多くの大企業は、社内のSubversionやCVSを使い続けました。
理由としては、「機能が足りなかった」というよりも、もっとシンプルな感覚で、「ソースコードをクラウドに置くのは、なんとなく危ない」ということだったと記憶しています。

関連記事

1. 「危ない気がする」は、なぜ力を持ったか

GitHubの便利さを知ると、この感覚は「慎重過ぎる」と感じますが、当時は意味があるものでした。

「危ない気がする」は、なぜ力を持ったか クラウド ＋ 機密コード ✕ → 情報漏洩ニュースが リスク感を高めた 「許可しない」が 組織的に安全だった 持ち出し禁止ルールが クラウドに転用された 実際のリスク評価より「責任を取れるか」が先に立っていた → 事故がなければ「正しかった」と見なされる構造

意思決定のパターンには、それが有効だった時代の文脈が埋め込まれています。
ただ、ある時期に正しかった基準が、10年後にも正しいとは限りません。

2000年代後半から2010年代前半にかけて、企業の情報漏洩は繰り返しニュースになっていたからです2。
それゆえ「クラウドは危険だ」という論調は強く、社内で慎重論が正当化されやすくなりました。
実際のリスク評価以上に、「何かあったときに責任を取れるか」という問いが先に立っていたのです。

IT部門にとって、外部サービスの導入には説明責任が伴います。
事故が起きれば「なぜ許可したのか」と問われる構造の中では、「許可しない」という判断が組織的に安全でした。

1.1. 社内ルールが先に固まった

もう一つの背景は、「ソースコード持ち出し禁止」というルールです。

多くの企業では、2000年代の初頭にセキュリティポリシーが整備されました3。
「社外へのソースコード持ち出し禁止」という条項は、当時の脅威モデルに基づいて書かれたものです。
USBメモリや私用PCへのコピーを想定した条文が、クラウドサービス全般に読み替えられていきました。

1.2. 慎重さが生き残りに働いた局面もあった

ただ、この慎重さが完全に的外れだったとは言い切れません。

GitHubは2012年にRuby on Railsのマスアサインメント脆弱性を悪用され、開発者がRailsプロジェクトへの管理者権限を不正取得する事態が発生しました4。
2014年には「Heartbleed」と呼ばれるOpenSSLの脆弱性が公開され、多くのクラウドサービスが影響を受けました5。
同年、コード共有サービスCodeSpacesはAWSアカウントへの不正アクセスにより、事業継続が不可能になっています6。

こうした事例は、外部サービスを使うことの実際のリスクを示していました。

2. 生存者バイアスが判断基準を固定した

問題は、その確信がその後の判断に長らく引き継がれたことです。

生存者バイアスが判断基準を固定した 👁 見えるもの ✈️ 事故を避けた実績 「慎重にやってきた」 → 正しかった証拠に見える ≠ 🚫 見えないもの ・開発者の採用競争力低下 ・リリース速度の停滞 ・OSS コミュニティとの乖離 → 財務諸表には出ない損失 「大丈夫だった」は「正しかった」の証拠にならない 避けなかった場合の結果と比較しなければ判断できない

事故を避けた事実は見えます。
しかしGitHubを使わなかったことで、何を失ったかは見えにくい。
開発者が採用市場で不満を持ち始めたこと、ツールの制約によってリリース速度が上がらなかったこと、オープンソースコミュニティとの距離が広がったこと——こうした損失は、財務諸表に出ません。

生存者バイアスとは、成功した事例だけが観察可能になり、失敗や機会損失が統計から消える現象です7。
「慎重にやってきたから大丈夫だった」という語りは、それ自体が正しいとしても、「慎重にやらなければどうなっていたか」を同時に問わない限り、判断基準の根拠にはなりません。

2.1. 何が合理的で、何が偏りだったか

振り返れば、二つを分けて見ることができます。

何が合理的で、何が偏りだったか ✔ 当時は合理的だった 外部サービスの信頼性評価が困難 （2010年代初頭） インシデント対応体制が未整備 のまま依存するリスクを感知 説明責任の非対称性への対応 （事故時に「なぜ許可したか」） ✘ 環境変化後の偏り GitHub が SAML・監査ログ・ IP 制限を追加（2016年以降） 要件を満たせる水準になった後も 「クラウドは危ない」が上書き継続 評価のやり直しが起きなかった → 前提の更新を怠った状態 「その判断の前提がいつ書かれたか」を確認する習慣があるか それが環境の変化に追いつけるかどうかを分ける

当時の慎重さが合理的だった部分は、外部サービスの信頼性評価がまだ難しかったこと、インシデント対応の体制が整っていないまま依存することへのリスク感知、そして制度的な説明責任の非対称性への対応でした。

偏りが入り込んだのは、環境が変わった後もそのまま使い続けた部分です。
GitHubはSAML認証、IP制限、プライベートリポジトリ、監査ログといった機能を順次追加しました8。

2016年以降のGitHub Enterpriseは、多くの大企業のセキュリティ要件を満たせる水準になっています。
それでも「クラウドは危ない」という感覚が判断を上書きし続けた組織では、評価のやり直しが起きませんでした。

GitHubの話は、開発ツールの選択だけに留まりません。
組織がある判断を繰り返すとき、その判断の前提がいつ書かれたものかを確認する習慣があるかどうか——それが、環境の変化に追いつけるかどうかを分けます。

  1. GitHubのユーザー数は2013年1月時点で300万人に達し、リポジトリ数は500万件を超えていた。Wikipedia「GitHub」より。 – GitHub – Wikipedia
  2. 2011年にSony PlayStation Networkが不正アクセスを受け、約7700万件のアカウント情報が流出した事件は、クラウドサービスへの信頼を大きく揺るがした。当時、クラウド上のデータ管理リスクを問い直す論調が各国のIT部門で強まった。 – PlayStation Network outage – Wikipedia
  3. 2008年前後、国内外の大企業でUSBメモリからの情報漏洩が相次いだことを受け、多くの企業が「外部記録媒体の使用禁止」を明文化した。この流れで「社外へのデータ持ち出し禁止」という条項が広まり、後にクラウドサービスへの接続制限にも援用された。
  4. ロシア人開発者Egor Homakovが、GitHubで使われていたRuby on Railsのマスアサインメント脆弱性を実証するためにGitHubを侵害した。自身の公開鍵をRailsリポジトリの開発者として登録し、コミット権を取得した。GitHubは1時間以内に修正。なお記事の初稿では「SQLインジェクション」と記載したが、これは正確ではなく、マスアサインメント脆弱性が正しい。 – User hacks GitHub to showcase vulnerability – CSO Online
  5. Heartbleed（CVE-2014-0160）は2014年4月7日に公開された。当時、インターネット上のアクティブなウェブサーバーの約66%がOpenSSLを使用しており、Apache・nginxを経由して多くのクラウドサービスが影響を受けた。 – Heartbleed – Wikipedia
  6. 2014年6月、CodeSpaces.comはDDoS攻撃を受けた後、攻撃者にAWS EC2コントロールパネルへのアクセスを許した。身代金要求を拒否したところ、EBSスナップショット・S3バケット・AMIを含むほぼ全データが削除された。12時間以内に廃業。多要素認証を導入していなかったことが侵入の主因とされる。 – Hacker Puts Hosting Service Code Spaces Out of Business – Threatpost
  7. 生存者バイアスの概念は、第二次世界大戦中に数学者エイブラハム・ウォールドが戦闘機の装甲強化の問題で定式化したことで知られる。帰還した機体の損傷箇所ではなく、帰還できなかった機体が被弾した箇所を強化すべきという逆説的な結論が、この概念の典型例として引かれる。 – Survivorship bias – Wikipedia
  8. GitHubのエンタープライズ向けオンプレミス版「GitHub Enterprise」は2012年にリリースされた。その後のアップデートでSAMLによるシングルサインオン（SSO）が追加され、企業の既存のActive DirectoryやOktaなどのIDプロバイダーとの統合が可能になった。 – GitHub(Enterprise) Review 2026 – linktly.com