セルフホストAPIツール：クラウドから離れるべきか？

GitHubが、自社の約3,800の内部リポジトリから攻撃者によってデータが盗まれたことを認めた週、セルフホスト型APIツールは、ニッチなコンプライアンスチェック項目から経営陣レベルの課題へと変化しました。数千万人の開発者のコードをホストするクラウドプラットフォームは、一人の従業員のラップトップで実行されていた改ざんされたVS Code拡張機能を通じて侵害されました。業界がコードをどのように保存するかを定義する企業が侵害され得るのなら、自社のスタックについて、より厳しい質問を投げかけるのは妥当です。つまり、API仕様、共有コレクション、テストデータ、環境シークレットは一体どこに存在しているのでしょうか？

多くのチームにとって、正直な答えは「誰かのクラウドの中、そしてどのサーバーかは正確には分からない」でしょう。これは自動的に間違っているわけではありません。クラウド同期型のAPIツールは便利で、導入が早く、コラボレーションに非常に優れています。しかし、GitHubの事件は、APIの信頼できる情報源（source-of-truth）を冷静に見つめ直し、それが自社のセキュリティ境界内にあるべきか、それとも外にあるべきかを意図的に決定するための有用なきっかけとなります。

要約

セルフホスト型APIツール、またはオンプレミスAPIプラットフォームとも呼ばれるものは、OpenAPI仕様、リクエストコレクション、テストデータ、認証情報を、ベンダーのマルチテナントクラウドではなく、自社で管理するインフラ内に保持します。2026年5月のGitHubの侵害事件（攻撃者がトロイの木馬化したVS Code拡張機能を通じて約3,800の内部リポジトリからデータを抜き取った）以降、より多くのチームがデータレジデンシーとクラウドの利便性を比較検討しています。規制産業、機密性の高い認証情報の保存、エアギャップネットワークにおいては、セルフホスト型またはオフラインツールが理にかなっています。一方、運用上のオーバーヘッドが少なく、リアルタイムのコラボレーションが必要な分散型チームには、依然としてクラウド同期が優位です。Apidogは両方の選択肢を提供します。クラウド製品と、セルフホスト型オンプレミスデプロイメントに加えてオフラインモードも用意しているため、選択は自由です。

GitHubで実際に何が起こったのか、なぜAPIチームが気にするべきなのか

2026年5月20日、GitHubは攻撃者が約3,800の内部コードリポジトリからデータを盗んだことを確認しました。侵入経路はGitHubのコアプラットフォームにおけるゼロデイ脆弱性ではありませんでした。それは、GitHub従業員のデバイスにインストールされた、改ざんされたVS Code拡張機能でした。その拡張機能が従業員の権限で実行されると、攻撃者はGitHub自身のネットワーク内に足がかりを得ました。TeamPCPとして追跡されている脅威グループは、npm、PyPI、PHPパッケージエコシステムにおけるサプライチェーン攻撃で知られており、セキュリティ報告によると、このグループは盗んだデータセットをアンダーグラウンドフォーラムで5万ドル以上で販売しました。GitHubは、内部リポジトリ外に保存された顧客データが影響を受けたという証拠は見つかっていないと述べており、調査は継続中です。

これはGitHubにとって唯一の困難な月ではありませんでした。2026年4月には、クラウドセキュリティ企業WizがCVE-2026-3854を開示しました。これはGitHubの内部Gitインフラにおける重大なリモートコード実行の脆弱性で、パッチ適用前には数百万のリポジトリを危険にさらしていました。SecurityWeekは、この脆弱性とその範囲を詳細に記録しています。同じベンダーで2ヶ月間に2件のインシデントが発生したのは、注目に値するパターンです。

APIチームが真剣に考えるべき点はここにあります。GitHubは、ほとんどのエンジニアリング組織にとって、単なるコードホスト以上のものです。それはAPIの信頼できる情報源（source-of-truth）の本拠地なのです。OpenAPIやSwaggerの仕様はリポジトリに存在します。リクエストコレクションをコミットすれば、それもリポジトリに存在します。`.env.example`ファイル、APIゲートウェイをプロビジョニングするTerraform、デプロイトークンを保持するCIワークフロー、統合テストフィクスチャ、モックサーバーの定義など、これらすべてが同じ場所に集積する傾向があります。その場所がクラウドプラットフォームである場合、そのプラットフォームの侵害は、潜在的にあなたの侵害となり得ます。

GitHubのインシデントについて正確に言えば、盗まれたデータはGitHub自身の内部コードであり、顧客のリポジトリではありませんでした。この区別は重要であり、曖昧にするべきではありません。しかし、その教訓は明確に一般化できます。悪意のあるVS Code拡張機能のベクター、サプライチェーン攻撃のパターン、単一の侵害されたラップトップがネットワークアクセスにつながる事態。これらはどれもGitHub固有のものではありません。同じ攻撃連鎖は、製品を開発環境に接続するあらゆるベンダーに対して機能します。私たちはこれの開発者側の視点について、VS Code拡張機能のAPIキーセキュリティに関する記事で取り上げ、リポジトリ側のリスクについてはGitリポジトリにおけるAPIドキュメントのセキュリティを維持する方法で説明しました。この記事は、プラットフォームレイヤーに焦点を当てています。「この拡張機能は安全か」ではなく、「APIの設計とデータはそもそもベンダーのクラウドに置くべきか」という問いです。

APIクライアントが実際にベンダーのクラウドに同期するもの

APIの信頼できる情報源（source-of-truth）がどこに属するかを決定する前に、APIクライアントがあなたのマシンから何を送信しているかについて正直な棚卸しをする必要があります。ほとんどの開発者はこれを過小評価しています。クラウド同期型APIツールにサインインし、チームワークスペースに参加すると、以下のカテゴリのデータが通常、あなたのデバイスを離れてベンダーのインフラに着地します。

API仕様書。あなたのOpenAPIドキュメントは、サービスが公開するすべてのエンドポイント、すべてのパラメータ、すべてのスキーマ、すべての認証フローを定義します。攻撃者にとって、完全な仕様書は地図です。どのエンドポイントが存在し、どれが列挙可能なIDを受け取り、どれが文書化されていないか、そして認証境界がどこにあるかを教えてくれます。仕様書はパスワードのような秘密ではありませんが、完全なAPIブループリントが誤った手に渡ると、攻撃の偵察段階が劇的に短縮されます。

リクエストコレクションと保存された例。保存されたリクエストには、実際のペイロードが頻繁に含まれます。実際のペイロードには、テスト中に使用された顧客のメールアドレス、アカウントID、内部ホスト名、ステージングからコピーされたサンプルレコードなど、実際のデータが含まれています。保存されたレスポンス例はさらに悪く、捕捉されたレスポンスには、誰かが一度貼り付けて忘れた完全なユーザーオブジェクトやレコードのリストが含まれている場合があります。

環境変数とシークレット。これが核心です。多くのチームは、APIキー、ベアラートークン、OAuthクライアントシークレット、データベース接続文字列をAPIクライアント内に環境変数として保存し、それらの環境をクラウドに同期させて、チームメイトが同じリクエストを実行できるようにします。これにより、本番環境の認証情報がサードパーティのマルチテナントデータベースに保存されることになります。チームメイトの「自分のマシンでは動く」という同期問題をデバッグした経験があれば、このレイヤーがいかに不透明であるかを知っているでしょう。私たちは、この表面の理解が困難であることから、まさにPostmanの環境同期問題に関する完全な診断を執筆しました。

テストデータとモックの定義。モックサーバーはサンプルデータでシードされます。テストシナリオは実際のデータの形式、そして時にはデータそのものを符号化します。自動テストスイートはビジネスルールを明らかにするアサーションを含んでいます。

ワークスペースのメタデータと活動履歴。コメント、サービス名、チームメンバーリスト、フォルダー構造、変更履歴。個々には些細なものですが、全体として詳細な組織図と製品ロードマップとなります。

これらはどれもクラウド同期が無謀だという意味ではありません。データが本物であり、全体として機密性が高く、インシデントが質問を強制する前に、ベンダーに委ねた情報カテゴリが正確に何であるかを把握しておくべきだということです。この特定の表面についてより深く読むには、Postmanは安全かという私たちの分析が、クラウド同期データモデルを詳細に分解しています。

クラウド同期と共有ワークスペースの実際の攻撃対象領域

クラウド同期型APIツールは、データがローカルに留まっている場合には存在しない攻撃対象領域を追加します。これは特定のベンダーのセキュリティチームに対する批判ではありません。彼らのセキュリティチームはしばしばあなたの組織よりも強力です。これは構造的な観察です。データに到達できる場所が増えれば、データに到達される可能性のある場所も増えるということです。

ベンダー自体が標的となります。何千もの企業のAPI仕様や認証情報を保持するマルチテナントSaaSは、価値の高い標的です。そこで単一の侵害が発生すれば、それはすべてのテナントに同時に影響を与える侵害となります。あなたはベンダーのセキュリティ体制、パッチ適用頻度、インシデント対応の質、従業員のラップトップの衛生状態を継承することになります。GitHubのインシデントは典型的な例です。脆弱なリンクは一人の従業員のデバイスであり、その影響範囲は数千のリポジトリに及びました。

アカウント乗っ取りは深刻な問題になります。クラウドツールは認証情報で認証され、認証情報はフィッシングされ、再利用され、漏洩します。チームメイトがパスワードを再利用し、それが漏洩したダンプに現れた場合、そのチームメイトとしてログインした攻撃者は、共有ワークスペース、同期された環境、すべてのシークレットへのアクセスを継承します。多要素認証は大いに役立ち、強制すべきですが、セッションハイジャックやOAuthトークンの窃盗はこれを迂回します。

過度なワークスペース共有。共有ワークスペースは、人々がツールを導入する理由となる機能であり、同時に情報漏洩の原因となる機能でもあります。2週間の契約で追加されたが、決して削除されなかった請負業者。「エンジニアリング」ワークスペースは、すべての新入社員が追加される場所ですが、3回の組織再編前の本番環境がいまだに含まれているかもしれません。デフォルトで開かれた共有設定は、機密性の高い環境が必要ない人々にも到達することを意味します。

統合と拡張レイヤー。これはまさにGitHubを襲ったベクトルです。APIクライアントとIDEは、拡張機能、プラグイン、統合をサポートしています。それぞれが、あなたの権限で実行されるサードパーティのコードです。改ざんされた拡張機能は、同期されたデータ、ローカルファイル、トークンを読み取ることができます。攻撃者が人気のパッケージや拡張機能を侵害して、ダウンストリームのすべての人に到達するサプライチェーンパターンは、現在、開発者環境への最も信頼できる侵入経路の一つとなっています。TeamPCPは、GitHubのインシデントが発生する前に、npmとPyPI全体でまさにこの実績を築き上げました。

テレメトリー、ログ、サブプロセッサー。クラウドツールはテレメトリーを発します。クラッシュレポートはリクエストボディを捕捉することがあります。サーバーログはヘッダーを捕捉することがあり、ヘッダーには`Authorization`トークンが含まれます。また、データはベンダーのサブプロセッサー、そのクラウドホスト、その分析プロバイダー、そのサポートツールにも流れ、それぞれがあなたが制御せず、めったに監査しない独自の表面となります。

有用な比較として、Vercelの侵害とそれがAPIチームに教えたことがあります。デリバリーパスにあるプラットフォームが侵害された場合、その教訓はめったに「そのベンダーが悪かった」ではありません。そうではなく、「どのサードパーティがあなたの機密データに触れる可能性があるかをマッピングし、データが十分に機密性が高いと判断できる場合にはそのマッピングを縮小する」ということです。

バランスを保つために、この反論も確かにあります。信頼できるクラウドベンダーは、保存時および転送時にデータを暗号化し、正式なセキュリティプログラムを実行し、SOC 2およびISO 27001認証を取得し、専任のセキュリティチームを配置し、ほとんどの社内運用グループよりも迅速にパッチを適用します。小規模なスタートアップのデータは、多くの場合、古くてパッチが適用されていないサーバーよりも、成熟したベンダーのクラウドに置かれている方が安全です。要点はクラウドが安全でないということではありません。要点は、クラウド同期は意図的なトレードオフであり、デフォルトではなく意図的にそれを行うべきだということです。

コンプライアンスとデータレジデンシー：セルフホストが選択肢でなくなる時

規制産業にとって、クラウドとセルフホストのどちらを選ぶかという問題は、多くの場合、単なる好みではありません。それは、書類証拠と監査人が付随する要件なのです。

データレジデンシーと主権。EUのGDPRのような規制、そして増え続ける国家のデータ現地化法は、人に関するデータが物理的にどこに存在できるかを制限しています。もしあなたのAPIテストデータや保存されたリクエストペイロードにEU居住者の個人データが含まれており、そのデータが米国地域のマルチテナントデータベースに存在する場合、これはコンプライアンス上の問題となる可能性があります。自社のデータセンター、または明示的に指定したクラウドリージョンで実行されるセルフホスト型APIプラットフォームは、データレジデンシーを再びあなたの管理下に戻します。欧州データ保護委員会（EDPB）のガイダンスは、越境データ転送規則の参照点です。

業界固有のフレームワーク。HIPAAの下で保護される医療情報（PHI）を扱う医療チーム、PCI DSSの下で決済を扱うチーム、FedRAMPの下で米連邦政府のベンダー、CMMCの下で国防総省の請負業者など、これらすべてが、規制対象データがどこに存在し、誰がアクセスできるかについて明確な管理体制に直面しています。これらのフレームワークの一部は、最も機密性の高いワークロードに対して、事実上エアギャップ環境またはオンプレミス環境を要求します。私たちはそのシナリオについて、セキュアな環境のためのエアギャップAPIテストツールに関するガイドで深く掘り下げています。ベンダーのクラウドに同期することによってのみ機能するツールは、どんなに優れていても、これらの設定では選択肢になりません。

契約上のデータ取り扱い義務。正式な規制外であっても、企業顧客はベンダー契約にデータ取り扱いに関する条項をますます多く書き込んでいます。顧客の契約で、そのデータが未承認のサブプロセッサーによって処理されてはならないと規定されており、あなたのAPIクライアントがそのデータを含むテストペイロードを密かに自身のクラウドに送信している場合、あなたは気づかずに結んだ約束に違反している可能性があります。

監査と管理の連鎖。監査人はずばり尋ねます。「誰がこのデータにアクセスでき、どうやってそれを知るのか？」と。セルフホスト型デプロイメントの場合、答えは具体的です。データはあなたが所有するサーバー上にあり、あなたのネットワーク制御の背後にあり、あなたのログに記録され、あなたのアクセスポリシーの下にあります。マルチテナントクラウドの場合、答えの一部は常に「そしてベンダーを信頼している」となり、これは監査で証拠を提示し、防御することがより困難になります。

簡単な経験則として、APIデータが規制対象、契約上の義務、または真に機密性の高い情報と重複するほど、セルフホストの運用コストは、適切にビジネスを行うためのコストとなります。趣味のプロジェクトや機密性のないデータを持つ社内ツールの場合、同じコストは正当化するのが難しいでしょう。

セルフホストが優位に立つ場合と、クラウドの利便性が正当に優位に立つ場合

セルフホストは道徳的に優れているわけではありません。それは実際のコストを伴うエンジニアリング上のトレードオフであり、そうでないと主張することはチームを間違った選択に導きます。以下に正直な区分を示します。

セルフホストまたはオフラインが運用コストをかける価値がある場合：規制産業に属している場合、APIツール内に本番環境の認証情報や顧客データを保存している場合、エアギャップ環境や制限されたネットワークで運用している場合、セキュリティまたは法務チームが防御可能な管理の連鎖を必要としている場合、または単一ベンダーがすでにあなたの重要なデータの多くを集中させており、その集中度を減らしたい場合です。これらの場合、運用上のオーバーヘッドは無駄ではありません。それは実際に必要とされる制御の代償なのです。

クラウドの利便性が正当に優位に立つ場合：あなたのチームがタイムゾーンをまたいで分散しており、リアルタイムコラボレーションが主要なワークフローである場合。適切に運用・セキュリティを維持する運用能力がない小規模チームの場合（なぜなら、半端に管理されたセルフホスト型サーバーは、適切に運用されたクラウドよりも悪いからです）。あなたのAPIデータが規制対象や機密情報を含まない場合。または、初期段階の製品開発で迅速に進める必要があり、導入スピードがデータレジデンシーの制御よりも優先される場合です。ここでクラウドを選択することは怠慢ではありません。それはトレードオフの正しい読み方です。

間違いは、これを一度きりの全か無かの決定として扱うことです。多くの成熟したチームは、分割して運用しています。本番環境のシークレットや顧客データに触れるものにはセルフホストまたはオフラインのセットアップを使用し、機密性の低いコラボレーションや公開APIドキュメントにはクラウドワークスペースを使用します。決定は企業ごとではなく、データクラスごとに行われます。そして、データの機密性、チーム規模、規制への露出は時間とともに変化するため、定期的に見直す必要があります。

ApidogでAPIの信頼できる情報源（source-of-truth）を自社のセキュリティ境界内に保持する

GitHubの侵害により、あなたのAPIデータがどこに存在するのかを見直しているなら、実用的な対策は、ツールがあなたに代わって決定するのではなく、あなたが決定できるツールを使用することです。Apidogは、設計、デバッグ、テスト、モック、ドキュメント作成を網羅するオールインワンのAPIプラットフォームであり、チームが必要に応じてそのワークフロー全体を自社のセキュリティ境界内に保持できるように構築されています。

正直なところ、Apidogもクラウド製品を提供しており、多くのチームにとってそれが最適な選択です。これはクラウドに反対する主張ではありません。重要なのは、APIの設計、仕様、テストデータ、認証情報を、あなたが管理するインフラ内に保持する選択肢があるということです。その仕組みは以下の通りです。

オンプレミスおよびセルフホスト型デプロイメント。Apidogは、企業向けに完全にセルフホスト型のオンプレミスデプロイメントを提供しています。あなたは完全なプラットフォームを自社のインフラ（プライベートデータセンター、自社のクラウドVPC、またはハイブリッドセットアップ）内で実行します。Apidogのセルフホストドキュメントによると、デプロイオプションには、アプリケーション、MySQLデータベース、Redisキャッシュがすべてあなたが所有するホストで実行されるスタンドアロンのDockerセットアップ、データベースとキャッシュがあなたが制御するマネージドクラウドサービスを使用しながらアプリケーションがあなたの環境で実行されるハイブリッドモデル、そしてエンタープライズ規模の展開のためのKubernetesが含まれます。あなたのOpenAPI仕様、コレクション、テストデータ、環境変数は、あなたのサーバー上にあり、あなたのネットワーク制御の背後にあり、あなたのログに記録され、あなたのアクセスポリシーの下にあります。監査人が「誰がこのデータにアクセスできるのか」と尋ねた場合、答えは具体的になります。

セルフホスト版は、セルフホスト型のテストランナーもサポートしており、自動APIテストはサードパーティを経由せずに社内ネットワーク内で実行されます。これにより、仕様とテストトラフィックの両方が社内境界内に保たれ、実際のトークンが送信される場合や社内専用サービスにアクセスする場合に重要となります。セルフホスト型Apidogにはエンタープライズユーザーおよびアクセスマネジメントも含まれており、デフォルトでオープンな共有に頼ることなく、どのプロジェクトに誰がアクセスできるかを範囲指定できます。

ローカルファーストストレージを備えたオフラインモード。機密性の高い作業をローカルに保持するために、完全なオンプレミス展開が必要なわけではありません。Apidogのオフラインスペースを使用すると、単一の開発者または小規模チームが完全にデバイス上で作業できます。Apidogオフラインスペースのドキュメントによると、すべてのデータはローカルマシンに残り、クラウドにアップロードされることはありません。バックグラウンド同期もありません。一時的な「再接続するまでキャッシュ」のようなオフラインモードとは異なり、Apidogのオフラインスペースは永続的で自己完結型です。つまり、完全にオフラインでエンドポイントを設計、デバッグ、テストでき、データはあなたが置いた場所にのみ存在します。

オフラインスペースは、シークレットの問題に特に関連しています。オフラインスペースの環境変数とグローバル変数はローカルに保存され、クラウドに同期されることはなく、チームメンバーと共有されることもありません。つまり、ベアラートークン、アカウント認証情報、接続文字列を、それらの値がラップトップから離れることなくAPIクライアント内に保持できるということです。エアギャップまたは制限されたネットワークの場合、これは使用できるツールと使用できないツールの違いを意味します。

デフォルトの姿勢としてのローカルデータストレージ。両方のオプションを結びつけるのは、ローカルファーストな制御です。オンプレミス展開では、チームの共有APIの信頼できる情報源があなたのインフラ上に存在します。オフラインスペースでは、個人の機密作業がそのデバイス上に存在します。いずれにせよ、あなたのAPI仕様、テストデータ、認証情報は、デフォルトでマルチテナントクラウドに委ねられることはありません。それらは、あなたが指し示し、監査し、防御できる場所に存在します。

ついていくには、Apidogをダウンロードし、デスクトップアプリからオフラインスペースをオンにするか、エンタープライズオンプレミス展開を検討している場合は、セルフホストのドキュメントを確認してください。正直なところ、ApidogがGitHubの侵害を止めることはなかったでしょうし、どのAPIツールもそうだったでしょう。Apidogが提供するのは、他の誰かのインシデント中に答えを発見するのではなく、あなたのAPIデータがどこに存在するかについて意図的な決定を下せるようにすることです。

結論

GitHubの侵害はパニックに陥る理由ではなく、クラウドが壊れている証拠でもありません。それは「きっかけ」です。以下にポイントをまとめます。

• 何百万人ものユーザーから信頼されているクラウドプラットフォームであるGitHubが、一人の従業員のデバイス上で改ざんされたVS Code拡張機能を通じて侵害され、約3,800の内部リポジトリからデータが盗まれました。
• ほとんどのチームにとって、コードをホストするプラットフォームは、APIの信頼できる情報源（OpenAPI仕様、コレクション、テストデータ、環境シークレット）も保持しています。
• クラウド同期型APIツールは、ベンダー自体が標的となる、アカウント乗っ取り、過度なワークスペース共有、拡張機能と統合レイヤー、およびサブプロセッサーといった、実際の攻撃対象領域を追加します。
• クラウド同期には真のメリットもあり、成熟したベンダーは社内運用よりもセキュリティが高い場合がよくあります。目標は、盲目的な不信感ではなく、意図的なトレードオフです。
• 規制産業、機密性の高い認証情報の保存、エアギャップネットワークでは、セルフホスト型またはオフラインのツールが選択肢ではなく必須となります。
• 分散型チーム、運用能力が不足している小規模チーム、機密性の低い作業では、クラウドの利便性が正当に優位に立ちます。
• 賢明なパターンはデータクラスごとの対応です。機密情報と顧客データにはセルフホストまたはオフラインを、低リスクのコラボレーションにはクラウドを使用し、成長に合わせて見直します。

次のステップは小さく、今週中に実行する価値があります。あなたのAPIクライアントが何を同期しているかを棚卸しし、各データタイプを機密性によって分類し、各クラスがどこに属するべきかを意図的に決定してください。もし答えの一部が「私たちの境界内」であるならば、Apidogは、オンプレミスのセルフホストデプロイメントとオフラインモードを提供し、それを実現します。Apidogをダウンロードして開始し、エンタープライズ展開を検討している場合は、セルフホストのドキュメントを参照してください。