zapierとpostmanとposthogが巻き込まれたnpm攻撃、結局なにがヤバいのか
「zapier postman posthog」で検索している人の多くは、Zapier・Postman・PostHogという有名サービスが同時に話題になっていて、何が起きたのか、自分にも関係があるのか、何を確認すべきかを知りたいはずです。今回の中心は、npmパッケージを通じたサプライチェーン攻撃「Shai-Hulud 2.0」または「Sha1-Hulud: The Second Coming」と呼ばれる事案です。
この記事では、公開情報をもとに、Zapier、Postman、PostHogがなぜ並んで語られているのか、npm・GitHub・CI/CD・クラウド認証情報にどんなリスクがあったのかを、初めての人にもわかるように整理します。あわせて、Zapierの使い方、料金、日本語対応、Postmanとの違い、PostHogとの連携、Makeとの比較、WebhookやMCPの見方まで、検索意図に近い周辺情報もまとめます。
| この記事のポイント |
|---|
| ✅ zapier postman posthogで話題になったnpm攻撃の全体像がわかる |
| ✅ Zapier・Postman・PostHogの関係と、それぞれの役割がわかる |
| ✅ 影響確認・認証情報の見直し・CI/CD対策の考え方がわかる |
| ✅ Zapierの使い方、料金、日本語対応、Make比較、Webhook活用まで整理できる |
zapierとpostmanとposthogで起きたnpmサプライチェーン攻撃の全体像
- zapier postman posthogの検索意図は「3社が同時に話題になったnpm攻撃の確認」である
- zapierとは業務アプリをつなぐ自動化サービスであり、PostmanやPostHogとは役割が違う
- postman vs zapierの違いはAPI開発ツールか業務自動化ツールかで判断すること
- PostHogはプロダクト分析ツールでありZapier連携でイベントを業務フローへ流せる
- Shai-Hulud 2.0はnpmインストール時に動く仕組みを悪用した攻撃である
- 影響が大きい理由はGitHub・npm・クラウドの秘密情報が狙われたことにある
zapier postman posthogの検索意図は「3社が同時に話題になったnpm攻撃の確認」である
「zapier postman posthog」と検索した人がまず知りたいのは、この3つの名前がなぜ同じ文脈で出てきたのかです。結論からいうと、Zapier、Postman、PostHogはいずれも、npmパッケージに関連する大規模なサプライチェーン攻撃の報告で名前が挙がりました。
ここでいうnpmとは、JavaScriptやNode.jsの開発でよく使われるパッケージ配布の仕組みです。便利な部品をインストールして開発を早く進められる一方で、その部品が改ざんされると、開発者のパソコンやCI/CD環境に悪意あるコードが入り込む可能性があります。
今回の事案では、「Shai-Hulud 2.0」「Sha1-Hulud: The Second Coming」と呼ばれる自己増殖型のマルウェアが話題になりました。公開情報では、Zapier、Postman、PostHog、ENS Domains、AsyncAPIなどに関連する複数のnpmパッケージが一時的にトロイの木馬化されたとされています。
Wizは、Zapier、PostHog、Postmanなどのパッケージが一時的にトロイの木馬化され、盗まれたデータが入ったGitHubリポジトリが多数作られたと説明しています。
引用元：https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack
大事なのは、ZapierやPostmanやPostHogというサービスそのものを使っているだけで即感染する、という話ではない点です。公開情報から見る限り、主な焦点は「それらに関連するnpmパッケージを、問題のある時期・バージョンでインストールした開発環境やCI環境があるか」です。
🔎 今回の検索でまず押さえるべき整理
| 項目 | 内容 |
|---|---|
| 話題の中心 | Shai-Hulud 2.0 / Sha1-Hulud: The Second Coming |
| 主な経路 | npmパッケージの改ざん |
| 名前が挙がったもの | Zapier、Postman、PostHog、AsyncAPI、ENS Domainsなど |
| 狙われたもの | GitHubトークン、npmトークン、クラウド認証情報、環境変数など |
| 読者が確認すべきこと | 該当パッケージ・該当バージョン・GitHubリポジトリ・CI/CDの痕跡 |
今回のようなサプライチェーン攻撃は、一般ユーザーよりも、開発者、SaaS運用者、CI/CDを使うチーム、npmを使っている組織に影響が出やすいです。特に、GitHub Actionsなどの自動ビルド環境でnpm installを実行している場合、秘密情報が環境変数やシークレットとして置かれていることがあります。
🧭 読者別の関係度
| 読者タイプ | 関係度 | 見るべきポイント |
|---|---|---|
| Zapierをノーコード連携だけで使う人 | 低〜中 | ZapierアカウントのMFA、連携アプリの権限 |
| PostmanをAPIテストで使う人 | 中 | 関連npmパッケージを使っていないか |
| PostHogを分析で使う人 | 中 | posthog系npmパッケージの利用状況 |
| Node.js開発者 | 高 | lockfile、node_modules、CIログ、GitHubシークレット |
| npmパッケージ公開者 | 高 | npmトークン、公開履歴、意図しないバージョン |
つまり検索意図への最短回答は、「Zapier・Postman・PostHogの名前は、npmサプライチェーン攻撃で影響対象として報告されたため並んで検索されている」です。ただし、実際の影響は利用形態によって大きく変わります。
zapierとは業務アプリをつなぐ自動化サービスであり、PostmanやPostHogとは役割が違う
「zapierとは」と調べている人向けに、まずZapierの基本を整理します。Zapierは、Gmail、Slack、Google Sheets、Notion、HubSpot、Webhookなど、さまざまなアプリをつないで作業を自動化するサービスです。
たとえば、「フォームに問い合わせが来たらSlackに通知する」「スプレッドシートに行が追加されたらメールを送る」「購入者情報をCRMに登録する」といった処理を、コードを書かずに組み立てやすいのが特徴です。
Zapierの読み方は、英語では一般的に「ザピアー」に近い発音で紹介されることがあります。日本語検索では「ザピエル」「zapier と は 読み方」「zapier 読み方」のような検索もありますが、公式の日本語定着名としては「ザピアー」や「ザピア」と表記されることが多い印象です。ただし、読み方は文脈によって揺れがあります。
⚙️ Zapierの基本整理
| 項目 | 内容 |
|---|---|
| サービス分類 | 業務自動化・アプリ連携ツール |
| 主な利用者 | 非エンジニア、業務担当者、マーケター、開発者 |
| できること | アプリ間のデータ連携、通知、登録、加工、自動実行 |
| よく使う概念 | Zap、Trigger、Action、Filter、Formatter、Webhook |
| 関連検索 | zapier とは、zapier 使い方、zapier 無料、zapier 料金 |
PostmanとPostHogは、Zapierとは別ジャンルのサービスです。PostmanはAPI開発・テストのためのツール、PostHogはプロダクト分析やイベント計測に使うツールです。そのため、3つを横並びで「同じサービス」と見ると混乱します。
📌 3サービスの役割比較
| サービス | 主な役割 | わかりやすい説明 |
|---|---|---|
| Zapier | 自動化 | アプリ同士をつないで作業を自動化する |
| Postman | API開発 | APIを試す、確認する、共有する |
| PostHog | 分析 | ユーザー行動やイベントを計測・分析する |
今回3社が同じ文脈で語られたのは、サービスの機能が似ているからではありません。npmパッケージの供給網で名前が並んだからです。ここを分けて理解すると、ニュースの読み方がかなり楽になります。
たとえば、Zapierを日常業務の自動化で使っているだけの人と、Zapier関連のnpmパッケージを開発プロジェクトに入れている人では、確認すべき内容が違います。前者はアカウント保護や連携アプリの権限確認が中心、後者はパッケージのバージョンやCI/CDの調査が重要になります。
🧩 「zapier とは 無料」「zapier 使い方」検索者への補足
| 検索語 | 知りたいこと | この記事での位置づけ |
|---|---|---|
| zapier とは | サービスの基本 | アプリ連携ツールとして説明 |
| zapier 無料 | 無料で使えるか | 料金は変わるため公式確認が必要 |
| zapier 使い方 | Zapの作り方 | TriggerとActionの理解が入口 |
| zapier 日本語 | 日本語で使えるか | UIやサポート範囲は最新確認が必要 |
| zapier webhook 使い方 | 外部データ連携 | 開発寄りの使い方として有用 |
なお、料金やプランは変更されることがあります。この記事では料金の考え方は説明しますが、具体的な最新金額についてはZapier公式ページで確認するのが安全です。
postman vs zapierの違いはAPI開発ツールか業務自動化ツールかで判断すること
「postman vs zapier」と検索する人は、どちらを使えばよいのか迷っている可能性があります。結論として、APIを作る・試す・仕様を確認するならPostman、複数アプリをつないで業務を自動化するならZapierが向いています。
Postmanは、APIにリクエストを送ってレスポンスを確認したり、認証ヘッダーやパラメータを調整したり、チームでAPI仕様を共有したりするためのツールです。エンジニア寄りですが、API連携の確認には非常に便利です。
一方、Zapierは「APIを直接書かなくても、アプリ間の処理をつなぐ」ことに強みがあります。たとえば、PostmanでAPIの動作を確認し、そのAPIをZapierのWebhookで業務フローに組み込む、という使い方も考えられます。
🧪 PostmanとZapierの違い
| 比較項目 | Postman | Zapier |
|---|---|---|
| 主な目的 | API開発・テスト | 業務自動化・アプリ連携 |
| 利用者 | 開発者、QA、API担当 | 業務担当、マーケター、開発者 |
| コード知識 | ある程度あると便利 | なくても始めやすい |
| 得意なこと | APIリクエスト確認、仕様共有 | アプリ間の自動処理 |
| 今回の事案との関係 | 関連npmパッケージが話題 | 関連npmパッケージが話題 |
今回のnpm攻撃の文脈では、Postman関連パッケージとして、公開情報内に @postman/tunnel-agent、@postman/postman-mcp-cli、@postman/secret-scanner-wasm などの名前が挙がっています。これらは、Postmanというサービス名と関係するパッケージとして報告されています。
ただし、ここでも注意が必要です。Postmanアプリを使ってAPIを試しただけで、そのまま今回のnpm攻撃に巻き込まれたと決めつけるのは早いです。影響確認では、開発プロジェクトの package.json や package-lock.json、pnpm-lock.yaml、yarn.lock などを確認する必要があります。
📂 確認すべきファイルの例
| ファイル | 何を見るか |
|---|---|
| package.json | 直接使っているnpmパッケージ |
| package-lock.json | npmで固定された依存関係 |
| pnpm-lock.yaml | pnpmで固定された依存関係 |
| yarn.lock | Yarnで固定された依存関係 |
| CIログ | 問題時期にnpm installが走ったか |
PostmanとZapierを比較するときは、「どちらが優れているか」ではなく、目的が違うと考えるのが自然です。APIの動作確認をしたいならPostman、確認済みAPIを業務自動化に組み込みたいならZapier、という分け方がわかりやすいです。
🔁 使い分けマトリクス
| やりたいこと | 向いているツール |
|---|---|
| APIが正しく動くか試したい | Postman |
| APIレスポンスを見ながら開発したい | Postman |
| 問い合わせをSlackへ自動通知したい | Zapier |
| Google SheetsとCRMをつなぎたい | Zapier |
| APIをトリガーに業務フローを動かしたい | Zapier + Webhook |
| API仕様をチームで共有したい | Postman |
今回のニュースをきっかけに「PostmanとZapierのどちらを使うべきか」と考えるなら、セキュリティ面ではどちらにも共通して、MFA、トークン管理、不要な権限削除、CI/CDの見直しが大事になります。
PostHogはプロダクト分析ツールでありZapier連携でイベントを業務フローへ流せる
PostHogは、ユーザー行動を分析するためのプロダクト分析ツールです。たとえば、ユーザーがどのページを見たか、どのボタンを押したか、どのイベントで離脱したかなどを計測できます。
PostHogの公式ドキュメントには、PostHogのイベントデータをZapierへ送る方法が説明されています。これは、PostHogで検知したユーザー行動を、Zapier経由でSlack通知、CRM登録、メール送信などにつなげる使い方です。
PostHogのZapier連携では、PostHogイベントをもとにZapierのZapをトリガーできると説明されています。
引用元：https://posthog.com/docs/cdp/destinations/zapier
この連携は、今回の攻撃そのものとは別の話です。つまり、「PostHogとZapierが連携できる」という通常の便利な機能と、「PostHog関連npmパッケージが攻撃報告に含まれた」というセキュリティ事案は、分けて考える必要があります。
📊 PostHogとZapier連携のイメージ
| PostHog側のイベント | Zapier側の処理例 |
|---|---|
| 有料登録ボタンをクリック | Slackに通知 |
| 解約フォームを表示 | カスタマーサクセスにタスク作成 |
| 特定機能を初回利用 | CRMに属性追加 |
| 重要ページを閲覧 | 営業チームへ通知 |
| エラーイベント発生 | チケット管理ツールに登録 |
PostHog公式ドキュメントでは、Zapierアプリを使う方法と、PostHogのData pipelinesからWebhookを使う方法が紹介されています。一般的には、ノーコード寄りならZapierアプリ、柔軟な連携ならWebhookという選び方になるかもしれません。
🧭 PostHogからZapierへ送る方法
| 方法 | 特徴 | 向いている人 |
|---|---|---|
| Zapier上のPostHogアプリ | 設定が比較的わかりやすい | ノーコードで始めたい人 |
| PostHog Data pipelines + Webhook | 柔軟に送信しやすい | 技術担当者がいるチーム |
| 独自API連携 | 自由度が高い | 開発リソースがある組織 |
ただし、Webhookは便利な反面、URLが漏れると不正なリクエストを受ける可能性があります。一般的には、Webhook URLの管理、署名検証、IP制限、秘密情報を送らない設計などが重要です。
今回のようなサプライチェーン攻撃では、環境変数やAPIキーが狙われます。PostHog、Zapier、Postmanのどれを使う場合でも、連携先に渡すデータを最小限にする、不要になったトークンを削除する、権限を広くしすぎないといった考え方が役立ちます。
✅ PostHog利用者が確認したいこと
| 確認項目 | 理由 |
|---|---|
| posthog系npmパッケージの利用有無 | 影響対象か判断するため |
| 問題時期のインストール履歴 | 実行された可能性を見るため |
| Zapier連携で送るデータ | 不要な個人情報を送っていないか確認 |
| Webhook URLの管理 | 外部から悪用されにくくするため |
| APIキーの権限 | 漏れた場合の影響を小さくするため |
PostHogは分析、Zapierは自動化、PostmanはAPI確認。3つの役割を分けて理解したうえで、npm攻撃の影響確認を行うことが大切です。
Shai-Hulud 2.0はnpmインストール時に動く仕組みを悪用した攻撃である
Shai-Hulud 2.0の特徴は、npmパッケージのインストール時に実行される仕組みを悪用した点にあります。公開情報では、preinstall に node setup_bun.js が追加され、そこから bun_environment.js を実行する流れが説明されています。
npmには、パッケージをインストールするときに特定のスクリプトを実行する仕組みがあります。これは本来、ビルドや準備処理に使われる便利な機能です。しかし、悪意あるコードが入ると、インストールしただけで危険な処理が動く可能性があります。
Aikidoの分析では、今回の波は前回よりもいくつか違いがあり、Bunをインストールして使う点、ランダム名のGitHubリポジトリを作る点、感染できるnpmパッケージ数が増えた点などが挙げられています。
Aikidoは、setup_bun.jsがBunを使ってbun_environment.jsを実行し、盗んだ情報をGitHubリポジトリに公開する流れを説明しています。
引用元：https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting-zapier-ensdomains
🧨 攻撃の大まかな流れ
| ステップ | 起きること |
|---|---|
| 1 | 改ざんされたnpmパッケージをインストール |
| 2 | preinstallスクリプトが実行 |
| 3 | setup_bun.jsがBun環境を準備 |
| 4 | bun_environment.jsが実行 |
| 5 | 環境変数・トークン・クラウド認証情報などを探索 |
| 6 | GitHubリポジトリへデータを出す |
| 7 | npmトークンがあれば別パッケージへ感染を広げる可能性 |
この攻撃が厄介なのは、開発者が「アプリを実行した」わけではなく、依存パッケージをインストールしただけで処理が走る可能性がある点です。特にCI/CDでは、プルリクエストやデプロイのたびにnpm installが自動実行されることがあります。
🔐 狙われた情報の例
| 情報 | 具体例 |
|---|---|
| GitHub情報 | PAT、GitHub Actions secrets、リポジトリ情報 |
| npm情報 | npmトークン、公開権限 |
| クラウド情報 | AWS、GCP、Azureの認証情報 |
| 環境変数 | APIキー、DB接続情報、サービスキー |
| ローカル設定 | .npmrc、クラウドCLI設定、SSH関連情報 |
Wizの分析では、GitHub Actionsのワークフローを悪用する話や、自己ホストランナーを登録するような挙動も説明されています。これは、単なる情報窃取だけでなく、将来的な遠隔実行や持続化につながる可能性があるため、かなり注意が必要です。
「Bun」と聞いて難しく感じるかもしれませんが、ここではJavaScriptを動かすための実行環境の一つと考えれば十分です。攻撃側は、環境にBunがなければ入れようとし、Bun経由で本体コードを動かそうとしたと報告されています。
⚠️ 一般利用者向けの噛み砕き
| 専門用語 | ざっくり説明 |
|---|---|
| npm | JavaScript部品の配布場所 |
| package | 開発に使う部品 |
| preinstall | インストール前に自動で動く命令 |
| token | サービスにログインするための鍵のようなもの |
| CI/CD | テストやデプロイを自動実行する仕組み |
| supply chain attack | 使っている部品や供給経路を狙う攻撃 |
今回のポイントは、便利な自動化の裏側にある「自動で動く処理」が悪用されたことです。だからこそ、依存関係の固定、インストール時スクリプトの制御、トークンの権限縮小が重要になります。
影響が大きい理由はGitHub・npm・クラウドの秘密情報が狙われたことにある
今回の攻撃が大きく見られている理由は、単に有名な名前が並んだからではありません。GitHub、npm、AWS、GCP、Azureなどの秘密情報が狙われたことが大きいです。
秘密情報とは、APIキー、トークン、パスワード、クラウドのアクセスキーなど、外部サービスにアクセスするための情報です。これらが漏れると、リポジトリの操作、パッケージの公開、クラウドリソースの利用、データ閲覧などにつながる可能性があります。
Wizの公開情報では、25,000以上の悪意あるリポジトリ、約500のGitHubユーザー、さらに有効な秘密情報の悪用観測について言及されています。また、GitHubがトークンの失効、リポジトリの非公開化、通知などを進めたとも説明されています。
🧾 公開情報で示された規模感
| 情報源 | 規模に関する記載 |
|---|---|
| Aikido | 492パッケージ、合計1億3,200万月間ダウンロードと説明 |
| Wiz | 約700パッケージ、25,000以上のリポジトリと説明 |
| mnemonic | 約700パッケージ、25,000以上のGitHubリポジトリと説明 |
| LinkedIn投稿内の引用 | 200以上のパッケージ、26,000アカウント超との記載 |
数字に幅があるのは、調査時点や観測範囲が違うためと考えられます。サプライチェーン攻撃では、発見直後から情報が更新され続けるため、初期報告と後続調査で数が変わることがあります。
🔍 狙われた情報と起きうる影響
| 狙われた情報 | 起きうる影響 |
|---|---|
| GitHub PAT | リポジトリ操作、コード取得、ワークフロー操作 |
| npmトークン | パッケージ公開、改ざん版の配布 |
| AWSキー | クラウドリソース操作、課金リスク、データアクセス |
| GCPキー | プロジェクト操作、シークレット取得 |
| Azureキー | Key Vaultやリソースへのアクセス |
| SSHキー | サーバーやGitへのアクセス |
Wizの分析では、GitHub Actionsの自己ホストランナーを悪用する話も出ています。もし攻撃者がCI/CD環境に残る仕組みを作れた場合、一度トークンを変えただけでは不十分な可能性もあります。
そのため、対応は「該当パッケージを消す」だけでは足りないことがあります。一般的には、依存関係の確認、認証情報のローテーション、GitHubワークフローの監査、クラウドログの確認、npm公開履歴の確認がセットになります。
✅ まず優先したい確認
| 優先度 | 確認内容 |
|---|---|
| 高 | 該当パッケージ・バージョンをインストールしたか |
| 高 | 問題時期にCI/CDが走ったか |
| 高 | GitHubに不審なリポジトリやワークフローがないか |
| 高 | npmトークンやGitHub PATを使っていたか |
| 中 | クラウドキーが環境変数に入っていたか |
| 中 | node_modulesやnpm cacheを掃除したか |
| 中 | パッケージ公開者アカウントに異常がないか |
「大手サービスの名前が出たから怖い」というより、実際には自分の開発環境やCIが、問題のパッケージを実行したかどうかが重要です。ここを冷静に確認することが、過剰反応を避けつつ実害を減らす第一歩です。
zapierとpostmanとposthog利用者が今すぐ確認したい実務対応
- zapier 使い方の基本はTriggerとActionを安全に設計することである
- zapier webhook 使い方は便利だがURLと送信データの管理が重要である
- zapier filter 使い方とformatter 使い方は不要なデータ連携を減らすために役立つ
- zapier / makeの比較は料金だけでなく権限管理と運用負荷で見ること
- zapier mcp とはAI連携文脈で注目されるが安全設計が前提である
- zapier 料金と無料プランは最新公式情報で確認するのが安全である
- zapier 日本語対応は期待しすぎず英語UI前提で準備すること
- npm攻撃の影響確認はlockfile・GitHub・CI/CD・クラウドキーの順で見ること
- 総括：zapier postman posthogのまとめ
zapier 使い方の基本はTriggerとActionを安全に設計することである
Zapierの使い方を理解するうえで、最初に押さえるべきなのは「Trigger」と「Action」です。Triggerは自動化が始まるきっかけ、Actionはその後に実行される処理です。
たとえば、「Googleフォームに回答が届いたら」がTrigger、「Slackに通知する」がActionです。この1つの自動化単位をZapと呼びます。ZapierはこのZapを組み合わせることで、手作業を減らすサービスです。
ただし、今回のようなセキュリティ事案を踏まえると、Zapierの便利さだけでなく、どのアプリに、どの権限で、どんなデータを渡しているかを見ることが大切です。自動化は便利ですが、設定を広くしすぎると、漏えい時の影響も広がります。
🛠️ Zapierの基本構成
| 要素 | 意味 | 例 |
|---|---|---|
| Trigger | 自動化の開始条件 | 新しいフォーム回答 |
| Action | 実行する処理 | Slack通知、メール送信 |
| Zap | TriggerとActionのまとまり | 問い合わせ通知フロー |
| App connection | 接続した外部アプリ | Gmail、Slack、Sheets |
| Task | Zapier上で実行された処理単位 | 1回の通知送信など |
「zapier 使い方 chatgpt」と検索する人も増えています。一般的には、ChatGPTやAIツールとZapierを組み合わせて、問い合わせ内容の要約、メール下書き、分類、タグ付けなどを自動化する使い方が考えられます。
ただし、AIに渡すデータには注意が必要です。顧客情報、認証情報、社内メモ、未公開情報などを不用意に送ると、別のリスクが生まれます。AI連携では、送信する項目を絞り、個人情報や秘密情報を含めない設計が望ましいです。
✅ 安全なZap設計の考え方
| 設計ポイント | 内容 |
|---|---|
| 最小権限 | 必要なアプリ・必要な操作だけ許可する |
| データ最小化 | Zapに流す項目を減らす |
| フィルタ | 条件に合うものだけ処理する |
| ログ確認 | 想定外の実行がないか見る |
| 接続棚卸し | 使っていないアプリ接続を削除する |
Zapierは非エンジニアにも使いやすい反面、組織で使う場合は運用ルールが必要です。誰がZapを作れるのか、どのアプリを接続してよいのか、退職者や外部委託者の接続はどうするのか、といった点を決めておくと事故を減らせます。
今回のnpm攻撃とは直接の経路が違うとしても、「自動化ツールに権限が集まりやすい」という意味では同じ教訓があります。便利な連携ほど、権限とデータの流れを見える化する必要があります。
zapier webhook 使い方は便利だがURLと送信データの管理が重要である
ZapierのWebhookは、外部サービスからデータを受け取ったり、逆に外部APIへデータを送ったりするための仕組みです。「zapier webhook 使い方」と検索する人は、アプリ一覧にないサービスや、自社システムとZapierをつなぎたいケースが多いはずです。
Webhookを簡単にいうと、「指定URLにデータが届いたら処理を始める仕組み」です。PostHogのイベントをZapierに送る場合にも、Webhookを使う方法が紹介されています。
便利な一方で、Webhook URLは鍵のような意味を持つ場合があります。URLを知っている人がデータを送れる設計になっていると、第三者が不正なデータを送ってZapを動かす可能性があります。
🔗 Webhook利用時の注意点
| 注意点 | 理由 |
|---|---|
| URLを公開しない | 第三者が送信できる可能性があるため |
| 送信データを絞る | 不要な情報漏えいを避けるため |
| 署名検証を検討 | 本物の送信元か確認するため |
| 重要処理は承認を挟む | 誤実行の影響を抑えるため |
| ログを見る | 想定外の実行を検知するため |
Webhookは、Postmanとの相性もあります。PostmanでWebhook URLにテストリクエストを送り、Zapier側で受信できるか確認する、といった使い方ができます。つまり、Postmanは確認、Zapierは自動化という役割分担です。
🧪 PostmanとZapier Webhookの組み合わせ
| 作業 | 使うツール | 内容 |
|---|---|---|
| リクエストの確認 | Postman | Webhookへテスト送信 |
| 自動化の開始 | Zapier | 受信データをTriggerにする |
| データ加工 | Zapier Formatter | 日付や文字列を整える |
| 条件分岐 | Zapier Filter | 必要なものだけ通す |
| 通知・登録 | Zapier Action | Slack、Sheets、CRMへ送る |
Webhookを使うと、Zapierにないサービスとも連携しやすくなります。その反面、APIキーや個人情報を送る設計にすると、漏えい時の影響が大きくなります。
今回のShai-Hulud 2.0では、環境変数やシークレットが狙われたと報告されています。Webhookそのものが今回の中心ではありませんが、Webhook URLやAPIキーを環境変数に置いている開発環境では、同じように漏えい対象になりえます。
そのため、Zapier Webhookを使う場合は、URLを秘密情報として扱う、送信内容を最小限にする、重要処理は直接実行しないという考え方が実務的です。
zapier filter 使い方とformatter 使い方は不要なデータ連携を減らすために役立つ
ZapierのFilterとFormatterは、地味ですが非常に重要です。「zapier filter 使い方」「zapier formatter 使い方」と検索している人は、Zapierを少し使い始めて、もう少し精度よく動かしたい段階かもしれません。
Filterは、条件に合うデータだけを次の処理に進める機能です。たとえば、「問い合わせ種別が法人のときだけSlack通知する」「金額が10,000円以上の注文だけスプレッドシートに追加する」といった使い方ができます。
Formatterは、データの形を整える機能です。日付の形式を変える、名前を分割する、金額表記を整える、テキストを短くするなど、次のアプリに渡しやすい形へ変換します。
🧰 FilterとFormatterの違い
| 機能 | 役割 | 例 |
|---|---|---|
| Filter | 条件に合うものだけ通す | 重要問い合わせだけ通知 |
| Formatter | データを整える | 日付形式を変更 |
| Path | 条件で処理を分ける | 個人/法人で分岐 |
| Delay | 実行を遅らせる | 1時間後に通知 |
| Lookup | 対応表を使う | 部署名から担当者を選ぶ |
セキュリティ面でもFilterとFormatterは役立ちます。すべてのデータを無条件に別アプリへ送るのではなく、必要な条件だけ通し、不要な項目を削ることで、連携先へ流れる情報を減らせます。
📉 不要なデータ連携を減らす設計
| 悪い例 | 改善例 |
|---|---|
| フォーム全項目をSlackへ送る | 必要な項目だけ送る |
| 全問い合わせをCRM登録 | 法人問い合わせだけ登録 |
| 個人情報をAIへ丸投げ | 匿名化・要約後に送る |
| エラーも成功も同じ通知 | 重要度で分ける |
| APIキーを本文に含める | APIキーは送らない |
今回のようなサプライチェーン攻撃では、「どこに秘密情報が置かれているか」が重要です。Zapier上でも、APIキーやWebhook URL、顧客データが無駄に広がっていないか見直す価値があります。
Formatterを使ってデータを整えると、後続の処理が安定します。たとえばPostHogのイベント名を人間が読みやすい名前に変えたり、Postmanで確認したAPIレスポンスの一部だけをZapierに渡したりできます。
✅ Zapier便利な使い方の例
| 目的 | 使う機能 |
|---|---|
| 重要なイベントだけ通知 | Filter |
| 日付や名前を整える | Formatter |
| APIレスポンスを加工 | Formatter |
| 条件で担当者を変える | Paths |
| 送信前に確認を挟む | Slack承認、メール確認など |
Zapierは「つなげば終わり」ではありません。長く使うほど、FilterとFormatterでノイズを減らし、必要な情報だけを流す設計が効いてきます。
zapier / makeの比較は料金だけでなく権限管理と運用負荷で見ること
「zapier / make」「zapier make とは」と検索する人は、ZapierとMakeのどちらを使うべきか比較しているはずです。Makeは、Zapierと同じくアプリ連携・業務自動化のサービスとして知られています。
一般的には、Zapierは設定がわかりやすく、対応アプリが多く、非エンジニアでも始めやすい印象があります。一方、Makeはシナリオ設計が視覚的で、複雑な分岐やデータ処理に強いと見られることがあります。ただし、これはプランや時期、利用者の慣れによって変わるため、断定は避けるべきです。
料金だけで選ぶと、後から運用がつらくなることがあります。たとえば、誰が作った自動化かわからない、失敗通知を誰も見ていない、APIキーが個人アカウントに紐づいている、といった問題です。
⚖️ ZapierとMakeの比較観点
| 比較観点 | Zapier | Make |
|---|---|---|
| 始めやすさ | 比較的わかりやすい印象 | 慣れると柔軟 |
| 複雑な処理 | Paths等で対応 | 視覚的な分岐が得意な印象 |
| 対応アプリ | 多い | 多い |
| 料金 | 最新公式確認が必要 | 最新公式確認が必要 |
| 運用管理 | チーム設計が重要 | シナリオ管理が重要 |
今回の事案を踏まえるなら、自動化ツール選びではセキュリティ管理も見たいところです。MFA、接続アプリの棚卸し、ログ、チーム権限、共有アカウントの扱い、退職者対応などは、料金表だけでは見えにくい部分です。
🔐 自動化ツール選定で見るべき安全項目
| 項目 | 確認理由 |
|---|---|
| MFA対応 | アカウント乗っ取り対策 |
| チーム権限 | 誰が何を変更できるか |
| 監査ログ | 不審操作を追えるか |
| 接続アプリ管理 | 不要な連携を消せるか |
| エラー通知 | 失敗に気づけるか |
| 秘密情報管理 | APIキーの扱いが安全か |
ZapierもMakeも、業務自動化では強力です。しかし強力であるほど、誤設定や権限過多の影響も大きくなります。特に顧客情報や売上情報を扱う場合は、安さだけでなく運用体制も含めて判断したほうがよいです。
「zapier 便利 な 使い方」を探している人には、便利さの前に「止め方」も確認することをおすすめします。自動化が暴走したとき、どこを止めればよいのか、誰が管理者なのか、ログはどこか。このあたりが見えていると安心です。
📌 導入前チェックリスト
| チェック | 内容 |
|---|---|
| ✅ 管理者を決めた | 個人任せにしない |
| ✅ 連携アプリを絞った | 必要なものだけ |
| ✅ 失敗通知を設定した | エラーを放置しない |
| ✅ APIキーの置き場を決めた | メモやチャットに置かない |
| ✅ 定期棚卸しをする | 使っていないZapを止める |
ZapierかMakeかの選択は、単純な優劣ではありません。自社の業務フロー、担当者のスキル、必要な連携、セキュリティ要件を並べて選ぶのが現実的です。
zapier mcp とはAI連携文脈で注目されるが安全設計が前提である
「zapier mcp とは」「zapier mcp 使い方」「zapier mcp 料金」といった検索も増えています。MCPは、AIエージェントや外部ツール連携の文脈で語られることが多い仕組みです。
今回のリサーチ情報では、Zapier関連の影響パッケージとして @zapier/mcp-integration、Postman関連では @postman/postman-mcp-cli や @postman/postman-mcp-server などの名前が挙がっています。これにより、Zapier、Postman、MCPという言葉が同時に気になった人もいるはずです。
MCP自体の詳細は提供情報だけでは限定的ですが、一般的には、AIやツールが外部サービスとやり取りするための接続規格・仕組みとして語られます。ここで大事なのは、AI連携では外部ツールを動かす権限が発生しやすいことです。
🤖 MCP文脈で気をつけたいこと
| 観点 | 注意点 |
|---|---|
| ツール権限 | AIが何を実行できるか |
| 認証情報 | トークンをどこに置くか |
| 実行ログ | 誰が何をしたか追えるか |
| 承認フロー | 重要操作の前に人間確認があるか |
| データ範囲 | AIへ渡す情報を絞っているか |
AIエージェントがZapierを通じてメール送信、CRM更新、チケット作成などを行えるようになると、業務効率は上がります。一方で、誤作動やプロンプトインジェクション、権限過多があると、意図しない操作につながる可能性もあります。
🔎 AI連携で起きやすいリスク
| リスク | 例 |
|---|---|
| 誤送信 | AIが間違った相手にメールを作る |
| 過剰実行 | 条件が甘く大量処理される |
| 情報漏えい | 本来渡さないデータを外部に送る |
| 権限濫用 | 読み取りだけでよいのに更新権限を持つ |
| ログ不足 | 後から原因を追えない |
今回のnpm攻撃では、開発者環境やCI/CD環境に置かれた認証情報が狙われたとされています。AI連携でも同じく、トークンやAPIキーの管理は重要です。AIが便利に動くほど、その裏側には権限が集まります。
Zapier MCPを検討する場合、料金や使い方だけでなく、どのアプリを動かせるのか、誰が承認するのか、失敗時に止められるのかを確認したほうがよいです。特に外部送信、課金、顧客情報更新などは慎重に扱うべきです。
✅ Zapier MCPを触る前の確認
| 確認項目 | 理由 |
|---|---|
| 最新公式ドキュメントを読む | 仕様や料金が変わるため |
| テスト用アカウントで試す | 本番データを守るため |
| 権限を最小にする | 被害範囲を小さくするため |
| 重要操作に承認を入れる | 誤実行を防ぐため |
| ログを残す | 追跡できるようにするため |
「AIとZapierをつなげば便利」という見方は正しい面があります。ただし、業務の手足をAIに渡すことでもあるため、安全設計を前提に進めるのが現実的です。
zapier 料金と無料プランは最新公式情報で確認するのが安全である
「zapier 料金」「zapier 料金プラン」「zapier 料金体系」「zapier 料金表」「zapier 無料」と検索する人は、導入前にコスト感を知りたいはずです。Zapierには無料プランや有料プランがある時期が多いですが、料金や条件は変わる可能性があります。
そのため、この記事では具体的な最新金額を断定しません。2026年5月23日時点で検討するなら、Zapier公式サイトのPricingページを確認するのが安全です。特に、タスク数、更新頻度、利用できるアプリ、チーム機能、AI関連機能などは変更される可能性があります。
料金を見るときは、月額だけでなく「自動化が何回動くか」を見る必要があります。Zapierでは一般的に、Zapが実行される回数やタスク数がコストに関係することがあります。
💰 料金確認で見るべき項目
| 項目 | 見る理由 |
|---|---|
| 月額料金 | 基本コスト |
| タスク数 | 実行回数で費用が変わる可能性 |
| Zap数 | 作れる自動化数 |
| 更新間隔 | どれくらい早く動くか |
| チーム機能 | 複数人管理に必要 |
| 高度機能 | Paths、Webhooks、AI連携など |
「zapier とは 無料」と検索する人は、無料でどこまでできるか知りたいはずです。一般的には、無料プランは試用や小規模用途には便利ですが、業務利用では制限に当たりやすいことがあります。
📌 無料プランで確認したいこと
| 確認項目 | なぜ重要か |
|---|---|
| 実行回数の上限 | すぐ上限に達する可能性 |
| 利用できるアプリ | 使いたい連携が対象か |
| Webhook利用可否 | 開発連携に必要な場合がある |
| 複数ステップ対応 | 複雑なZapに必要 |
| エラー通知 | 業務運用で重要 |
料金だけで比較すると、ZapierよりMakeのほうが安く見える場面もあるかもしれません。ただし、設定にかかる時間、失敗時の復旧、担当者の学習コストも含めると、単純な月額比較では判断しづらいです。
今回のセキュリティ文脈でいうと、有料プランのほうがチーム管理や監査機能を使いやすい場合があります。もちろん、実際にどの機能がどのプランに含まれるかは公式情報で確認が必要です。
🧮 料金以外のコスト
| コスト | 内容 |
|---|---|
| 設定時間 | Zapやシナリオを作る時間 |
| 保守時間 | エラー対応・仕様変更対応 |
| 教育コスト | 担当者が覚える時間 |
| セキュリティ対応 | 権限管理・棚卸し |
| 乗り換えコスト | 他ツールへ移す手間 |
Zapierの料金を考えるときは、「いくらか」だけではなく、「何時間の手作業を減らせるか」「止まったときに業務影響がどれくらいか」まで見ると判断しやすくなります。
zapier 日本語対応は期待しすぎず英語UI前提で準備すること
「zapier 日本語」「zapier 日本語化」「zapier 日本語対応」「zapier 日本語設定」と検索する人は、日本語で使えるかどうかを気にしているはずです。Zapierは海外サービスのため、英語UIを前提に考えたほうが安全です。
一部の画面やブラウザ翻訳で日本語表示できる場合があるかもしれませんが、公式の日本語対応範囲は時期によって変わる可能性があります。業務で使うなら、英語のTrigger、Action、Field名を最低限読める状態にしておくと安心です。
日本語データを扱うこと自体は、多くの連携で可能な場合があります。ただし、文字化け、日付形式、姓名の順序、全角半角、改行、絵文字などで想定外の挙動が出ることがあります。
🌐 日本語利用で気をつけたい点
| 項目 | 注意点 |
|---|---|
| UI | 英語前提で操作手順を残す |
| 日本語データ | 文字化けや改行に注意 |
| 日付 | タイムゾーンと形式を確認 |
| 名前 | 姓名の分割に注意 |
| 翻訳 | ブラウザ翻訳で意味がずれる可能性 |
Zapierを日本語チームで使うなら、社内向けに簡単な運用メモを作るのが効果的です。画面が英語でも、「どのZapが何をしているか」「止めるときはどこを見るか」が日本語で書かれていれば、属人化を減らせます。
📝 日本語運用メモに書く項目
| 項目 | 例 |
|---|---|
| Zap名 | 問い合わせSlack通知 |
| 目的 | 法人問い合わせを営業へ通知 |
| Trigger | Google Forms new response |
| Action | Slack channel message |
| 管理者 | 営業Ops担当 |
| 止め方 | Zapier管理画面でOFF |
| 注意 | 個人情報を外部AIに送らない |
今回のようなセキュリティ事案では、英語の警告や技術記事を読む場面も出てきます。Zapier、Postman、PostHog、npm、GitHubなどの英語ドキュメントに触れる可能性があるため、重要な用語だけでもチーム内で共有しておくとよいです。
📚 覚えておきたい英語用語
| 英語 | 意味 |
|---|---|
| Trigger | 開始条件 |
| Action | 実行処理 |
| Webhook | 外部からデータを受けるURL |
| Token | 認証用の鍵 |
| Secret | 秘密情報 |
| Workflow | 自動処理の流れ |
| Repository | GitHub上の保管場所 |
| Dependency | 依存パッケージ |
「zapier 日本語設定」を探している人にとっては、完全な日本語化よりも、チームが迷わず運用できる日本語メモを作ることのほうが実務的かもしれません。
英語UIが不安な場合は、まず小さなZapから始めるのがおすすめです。たとえば、テスト用フォームから自分のSlackへ通知するだけのZapを作り、Trigger、Action、Filter、Formatterの動きを確認すると理解しやすくなります。
npm攻撃の影響確認はlockfile・GitHub・CI/CD・クラウドキーの順で見ること
ここからは、今回のShai-Hulud 2.0事案に対する実務的な確認です。開発者や技術担当者がいる場合、まず見るべきはlockfileです。lockfileには、実際にインストールされた依存関係のバージョンが記録されています。
公開情報では、setup_bun.js、bun_environment.js、preinstall: node setup_bun.js、GitHubリポジトリ説明文 Sha1-Hulud: The Second Coming、cloud.json、contents.json、environment.json、truffleSecrets.json などがIOCとして挙げられています。
mnemonicのアドバイザリでは、ファイルシステム、GitHub、npm、破壊的フォールバックの観点からIOCが整理されています。setup_bun.js があり、bun_environment.js がない場合でも、攻撃者側の自動化ミスによる痕跡として注意が必要だとされています。
mnemonicは、package.jsonにpreinstallでsetup_bun.jsが追加されていること、setup_bun.jsや大きなbun_environment.jsが含まれることをIOCとして挙げています。
引用元：https://www.mnemonic.io/resources/blog/advisory-shai-hulud-2.0-supply-chain-campaign-rapidly-spreading-through-npm-packages-and-github/
🔍 影響確認の優先順
| 順番 | 確認対象 | 見る内容 |
|---|---|---|
| 1 | lockfile | 該当パッケージ・該当バージョン |
| 2 | node_modules | setup_bun.js / bun_environment.js |
| 3 | GitHub | 不審リポジトリ・説明文・workflow |
| 4 | CI/CD | 問題時期のnpm install実行 |
| 5 | npm | 意図しないpublish |
| 6 | クラウド | AWS/GCP/Azureキーの利用ログ |
| 7 | 認証情報 | トークン・APIキーのローテーション |
Wizは、対策として、 compromised packagesの削除・置き換え、npm cacheのクリア、node_modules削除、既知の安全なバージョンへの固定、認証情報のローテーション、GitHubとCI/CD監査、パイプライン強化を挙げています。
🧯 基本的な対応方針
| 対応 | 内容 |
|---|---|
| 削除 | node_modules削除、npm cache clean |
| 固定 | 問題前の安全なバージョンへ戻す |
| ローテーション | GitHub、npm、クラウド、SSHキーを更新 |
| 監査 | GitHub workflows、リポジトリ、npm publish履歴 |
| 制限 | CI/CDの外部通信やlifecycle scriptを制御 |
| MFA | GitHub、npm、クラウドアカウントで有効化 |
ここで注意したいのは、単に依存パッケージを更新するだけでは不十分な可能性があることです。もし認証情報がすでに外部へ出ていた場合、パッケージを直しても漏れた鍵は使われ続けるかもしれません。
そのため、影響が疑われる場合は、認証情報のローテーションを優先的に考えます。特にGitHub PAT、npm token、AWS/GCP/Azureの長期キー、SSHキー、外部APIキーは重要です。
✅ ローテーション対象の例
| 種類 | 例 |
|---|---|
| GitHub | PAT、Actions secrets、deploy key |
| npm | automation token、publish token |
| AWS | access key、secret access key |
| GCP | service account key |
| Azure | client secret、Key Vault secret |
| 外部SaaS | Zapier、PostHog、Postman、Slack等のAPIキー |
| SSH | Gitやサーバー接続用キー |
「自分はZapierを使っているだけだから関係ない」と思う人もいるかもしれません。もしnpmを使っていないなら直接関係は薄い可能性があります。ただし、Zapierに接続しているアプリの権限棚卸しやMFA確認は、この機会にやっておく価値があります。
総括：zapier postman posthogのまとめ
最後に記事のポイントをまとめます。
- zapier postman posthogで話題になった中心は、npmサプライチェーン攻撃「Shai-Hulud 2.0」である。
- Zapier、Postman、PostHogは機能が同じだから並んだのではなく、関連npmパッケージが攻撃報告に含まれたためである。
- Zapierは業務自動化、PostmanはAPI開発・確認、PostHogはプロダクト分析のツールである。
- Postman vs Zapierは、APIを試すならPostman、業務フローを自動化するならZapierで判断する。
- PostHogとZapierは、イベントデータをZapierへ送り業務フローにつなげる連携が可能である。
- Shai-Hulud 2.0は、npmのpreinstallなどインストール時に動く仕組みを悪用した攻撃である。
- 公開情報では、setup_bun.js、bun_environment.js、Sha1-Hulud: The Second ComingというGitHubリポジトリ説明文などが重要な痕跡である。
- 影響確認は、package.jsonやlockfile、node_modules、GitHub、CI/CD、クラウドキーの順で見るのが現実的である。
- 影響が疑われる場合は、GitHub PAT、npm token、クラウドキー、SSHキー、外部SaaSのAPIキーを見直すべきである。
- Zapierの使い方では、TriggerとActionだけでなく、FilterとFormatterで不要なデータ連携を減らす設計が重要である。
- Zapier Webhookは便利だが、Webhook URLや送信データは秘密情報に近い扱いが必要である。
- ZapierとMakeの比較は、料金だけでなく、権限管理、ログ、運用負荷、担当者のスキルで見るべきである。
- Zapier MCPやAI連携は便利だが、AIが外部ツールを動かす権限を持つため、安全設計が前提である。
- Zapierの料金や日本語対応は変わる可能性があるため、最新の公式情報を確認する必要がある。
- 今回の教訓は、便利な自動化と開発効率の裏側にある認証情報管理を軽視してはいけない、という点である。
- https://www.reddit.com/r/programming/comments/1p5i31d/sha1hulud_the_second_comming_postman_zapier/
- https://www.linkedin.com/posts/bretefisher_npm-github-githubactions-activity-7398797500398120960-oXrG
- https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting-zapier-ensdomains
- https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack
- https://posthog.com/docs/cdp/destinations/zapier
- https://news.ycombinator.com/item?id=46035533
- https://www.mnemonic.io/resources/blog/advisory-shai-hulud-2.0-supply-chain-campaign-rapidly-spreading-through-npm-packages-and-github/
- https://community.mendix.com/link/spaces/security/questions/144611
- https://forum.level1techs.com/t/large-amount-of-popular-npm-packages-compromised-zapier-ens-asyncapi-posthog-browserbase-and-postman/241416
- https://safedep.io/shai-hulud-second-coming-supply-chain-attack
各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。
