Postmanが静かにAIプラグインをインストールしAPIデータを共有しようとしている
開発ツールでAI機能がデフォルトで有効になることで、APIデータが同意なく外部へ送信される問題が広がっています。Postmanの事例を中心に、リスク経路と企業の監査・遮断チェックリストを解説します。
開発ツールでAI機能がデフォルトで有効になるにつれ、API呼び出し履歴や認証情報がユーザーの同意なく外部のAIモデルへ送信される構造が広がっています。PostmanのAI機能デフォルト有効化をめぐる議論は、単なる便利機能の追加ではなく、開発者個人と組織のデータガバナンスに直接的な脅威となることを示しています。最近ではAIコーディングツールの資格情報を狙うインフォスティーラーやAPIキー漏洩事故まで発生しており、開発ツールの「静かなAI化」はもはや無視できない信頼問題となっています。
静かなAI有効化が開発者ワークフローにもたらすリスク
Postmanは代表的なAPI開発コラボレーションツールで、最近AIアシスタントをデフォルトで有効化する形で機能を拡張しました。問題は、ユーザーが明示的に同意しなくてもリクエスト・レスポンスデータがAI処理パイプラインに流れるように設定される場合があることです。開発者はローカルで安全にAPIをテストしていると考えていても、実際にはコレクションに含まれるエンドポイントアドレス、リクエストヘッダー、レスポンスボディがクラウドAIサービスへ送信される可能性があります。
この変化は、特に「vibe coding」やAIコーディングツールが日常化した流れと重なり、さらに危険になります。開発者がAI機能をオンにしたまま本番APIを呼び出すと、本番トークンや顧客の個人情報がAIモデルに露出する恐れがあります。最近のSymantecの報告によると、AokiインフォスティーラーがAIコーディングアシスタントの資格情報とセッションファイルを狙い始めました。攻撃者がAIツールの保持するAPIキーとセッション情報の価値を正確に理解していることを意味します。
APIキー・リクエストデータが外部へ流出する具体的な経路と影響
AI機能がデフォルトで有効化されると、データは大きく3つの経路で外部に露出します。第一に、AIアシスタントがリクエスト・レスポンスをクラウドへ送り応答を生成する直接送信経路です。第二に、エラー診断やユーザー行動分析のためのテレメトリ収集にAI入力値が含まれる場合です。第三に、プラグインや拡張機能が過剰な権限を要求して静かにデータを収集する経路です。
実際の事故事例は、こうした懸念が杞憂ではないことを示しています。2026年10月、オープンソースAIコーディングエージェントのOpenCodeは、攻撃者がAIエージェントを利用してコンソールAPIキーを露出させる事故に見舞われました。この過程でOpenAI、Anthropic、GoogleのサードパーティAPIキーが漏洩し、全ユーザーの1.4%が影響を受けました。AIツール自体がAPIキーの新たな攻撃面となったのです。PostmanのAI機能が同じ方法で攻撃されたという報告はありませんが、デフォルトで有効化されたAI接続が増えるほど、同様のリスクにさらされる面積は広がります。
チームコンプライアンスとコードレビューへの波及効果
開発者が一人でもAI機能をオンにした瞬間、その行為はコードレビュー画面には現れません。diffにはコード変更しか表示されず、どのデータがAIへ送信されたかは監査ログを確認するまで分かりません。そのためチーム全体のコンプライアンスが静かに崩れます。GDPR、HIPAA、金融セキュリティ規制などはデータ処理経路を文書化し統制することを求めますが、デフォルトで有効化されたAI機能はこうした統制の外で動く「シャドーAI」を生み出します。
通知と同意がない状態では、セキュリティチームがリスクを事前に遮断することは困難です。「AI機能をオフにする方法」を開発者が自分で探して設定を変更しなければならない構造自体が問題です。組織は開発ツールのAIデフォルトを中央で強制的に無効化し、例外的に許可する場合はデータ送信範囲と保持ポリシーを文書化する必要があります。コードレビュー時にAI生成コードだけでなく、AI機能の利用有無もあわせてチェックするチェックリストが求められます。
企業環境のためのデータフロー監査・遮断の実践チェックリスト
企業でAIベースの開発ツールを導入する際は、以下の項目を順番に確認することをお勧めします。
- デフォルト設定の確認: 組織が使用するAPIクライアント、IDEプラグイン、コーディングアシスタントのAI機能がデフォルトで有効になっていないか中央設定で確認します。
- ネットワークフィルタリング: AIサービスエンドポイントへ向かうトラフィックをプロキシで監視し、許可されていないAIドメインを遮断します。
- APIキーの分離: 開発用キーと本番用キーを分離し、AIツールにはテスト専用キーのみを注入します。キーのスコープを最小化し、有効期限を短く設定します。
- データマスキング: AIへ送信する前に、リクエスト・レスポンスから個人情報、トークン、内部ホスト名を自動的に隠す前処理層を設けます。
- ポリシーの文書化: AI機能使用時にデータがどこへ送られ、どのくらい保持され、学習に使われるのかをベンダー文書で確認し、内部承認手続きを整備します。
このチェックリストは一度きりではなく、四半期ごとに繰り返す必要があります。AI機能はアップデートによって静かに再度有効化されたり、ポリシーが変更されたりする可能性があるためです。
オープンソースの代替とセルフホスティングで制御を取り戻す
PostmanのAIデフォルト有効化が気になる場合は、Bruno、Hoppscotch、InsomniaなどのオープンソースAPIクライアントへ移行する方法もあります。これらは基本的にデータがローカルにとどまり、クラウドAI呼び出しが強制されません。ただし、オープンソースだからといって万能ではありません。AI機能を追加すれば結局外部LLM APIを呼び出すことになり、その瞬間に同じデータ送信問題が再発します。セルフホスティング型LLMを連携するか、AI機能を完全に無効化した状態で使用するのが現実的な妥協案です。
また、オープンソースツールもセキュリティ事故から無縁ではありません。先に触れたOpenCodeの漏洩は、オープンソースAIコーディングエージェントで発生した事故です。セルフホスティングは制御を高めますが、パッチ管理やアクセス制御、ログ監視を組織が自ら責任を持って行う必要があることを意味します。結局、「どのツールを使うか」よりも「データがどこへ流れるかを把握しているか」の方が重要です。
まとめ
開発ツールのAI機能は生産性を高めますが、データ主権と信頼をデフォルトで犠牲にしてはいけません。ツールがどのデータをどこへ送るのかを透明に公開し、ユーザーが明示的に選択するまでは無効状態を維持すべきです。AI機能の有効化状況、データ送信範囲、監査結果を人が簡単にレビューし、不変のバージョンとして残すには、md-logのようなヒューマンインザループのレビュー・アーカイブ層を活用するのも一つの方法です。静かなAI化が損なう信頼は、結局透明な記録と明示的な制御によって回復できます。
参考資料
- ハッカーがAIコーディングツールOpenCodeを攻撃、ユーザーのAIアカウントに高額請求 - TechCrunch
- World of Warcraft: ForeverはすでにAIスロップであふれている - 404 Media
- OpenCode侵害はOpenAI、Anthropic、Googleに影響の可能性 - Infosecurity Magazine
- 新たなインフォスティーラーがAIコーディングアシスタントの資格情報を標的に - SC Media
- OpenCode、攻撃者がAIエージェントを使いコンソールAPIキーを暴露、ユーザーの1.4%に影響 - NewsCord
- Salt Security、2026年のInfoSec Innovator Awardsで3冠を獲得 - PR Newswire
- Postmanの代替ツール：6ツール、席は$3〜$19（2026年）
- Postman
よくある質問
- PostmanのAI機能がデフォルトで有効になると、どのようなデータが外部へ送信されますか？
- APIリクエスト・レスポンスに含まれるエンドポイントアドレス、ヘッダー、認証トークン、ボディデータがクラウドAI処理の過程で送信される可能性があります。ユーザーが明示的に同意していなくても、デフォルトで有効な状態ではローカルツールだと思っていたデータが外部に出るリスクがあります。そのため企業環境ではAI機能を中央で無効化するか、データマスキングを適用する必要があります。
- 企業でAIベースの開発ツールを安全に導入するにはどうすればよいですか？
- まずAI機能のデフォルト設定を確認し、中央管理で無効化した上で、許可されたAIドメインのみをネットワークで開放する必要があります。APIキーをテスト専用に分離し、リクエストデータをマスキングした後、ベンダーのデータ保持・学習ポリシーを文書化して承認手続きを行うことをお勧めします。四半期ごとに設定が再び有効になっていないか監査することも必要です。
- オープンソースAPIクライアントに移行すればデータ漏洩問題はすべて解決しますか？
- オープンソースツールは基本的にローカルで動作するためクラウドへの強制送信はありませんが、AI機能を連携すると外部LLM APIを呼び出し、同じ送信問題が発生する可能性があります。また、オープンソースツールもOpenCodeの漏洩事故のようにセキュリティ脆弱性にさらされる可能性があり、継続的なパッチ適用とログ監視が必要です。セルフホスティングは制御を高めますが、管理責任も伴います。
- 最近AIコーディングツールの資格情報を盗む事故が増えている理由は何ですか？
- AIコーディングツールがAPIキー、セッショントークン、クラウド資格情報をローカルに保存したりクラウドとやり取りしたりするため、攻撃者にとって魅力的な標的になったからです。実際に2026年10月のOpenCode漏洩では、攻撃者がAIエージェントを利用してOpenAI、Anthropic、GoogleのAPIキーを窃取しました。インフォスティーラーもAIツール専用の収集機能を追加し、攻撃が専門化しています。