zapierで資産データは安全？導入前に見るべき落とし穴と守り方

Zapierを使って業務を自動化したいけれど、「顧客情報・売上データ・社内アカウント・AI連携まで通して本当に安全なのか」と不安に感じている人は多いはずです。特に「zapier 資 安」と検索している人は、おそらく「Zapierは資産や機密情報を扱っても安全なのか」「セキュリティ面で注意点はあるのか」を短時間で把握したい状態ではないでしょうか。

この記事では、Zapier公式のセキュリティ情報、Trust Center、データプライバシー関連情報、WebhookやEmail Parserのコミュニティ回答、さらにnpmサプライチェーン攻撃でZapier関連パッケージ名が出た事例まで整理し、安全に使える部分・注意すべき部分・導入前に確認すべき設定をまとめます。結論だけでなく、社内導入時のチェックリストとしても使えるように、できるだけやさしく整理しました。

この記事のポイント
✅ ZapierのSOC 2 Type II・SOC 3・GDPR・CCPA対応の見方がわかる
✅ 資産データや顧客情報を連携する前に確認すべき設定がわかる
✅ Webhook・Email Parser・AI機能で注意したい保存期間や権限管理がわかる
✅ Zapierを安全に使うための現実的な運用ルールがわかる

zapierで資産データを扱う前の安全確認

1. zapierで資産データを扱う安全性は「公式基盤」と「自社設定」の両方で決まる
2. Zapierの認証・監査レポートはTrust Centerで確認するのが基本である
3. SOC 2 Type IIやSOC 3は安全性を見るうえで重要な判断材料になる
4. 暗号化・SSO・SCIM・2FAは企業利用で優先して見るべき項目である
5. AI連携はデータ利用ポリシーと学習オプトアウトを確認する必要がある
6. Email Parserは通常のZapデータとは保存の考え方が異なる点に注意する
7. WebhookはURLだけに頼らず追加の認証や検証を考えるべきである

zapierで資産データを扱う安全性は「公式基盤」と「自社設定」の両方で決まる

Zapierの安全性を考えるとき、まず押さえたいのは、Zapier自体のセキュリティ体制と、利用者側の設定・運用は別物だという点です。Zapierは公式情報で、SOC 2 Type II、SOC 3、GDPR、CCPAなどへの対応を掲げています。これは「基盤として一定のセキュリティ対策をしている」と見る材料になります。

ただし、それだけで「どんな使い方をしても安全」とは言えません。たとえば、顧客リストをGoogle Sheetsに転記するZap、請求情報をCRMに流すZap、AIツールへ問い合わせ内容を送るZapでは、扱う情報の重さがまったく違います。どの情報を、どのアプリに、どの権限で、どれくらい保存するかによってリスクは変わります。

特に「資産データ」といっても、会社の固定資産、顧客資産、金融系の情報、社内アカウント情報、営業データなど意味が広いです。一般的には、情報の機密度が高いほど、Zapierに流す前に社内ルールを作る必要があります。Zapierが安全対策をしていても、利用者が個人アカウントで重要データを連携してしまえば、管理の抜け道が生まれるかもしれません。

✅ 結論としては、Zapierはセキュリティ機能や認証情報を公開している一方で、資産データを安全に扱えるかは自社側の設計に強く左右されます。 つまり「Zapierは安全か？」ではなく、「このデータを、この設定で、Zapierに流してよいか？」と考えるほうが実務的です。

📌 安全性の見方

見るポイント	確認内容	重要度
Zapier側の基盤	SOC 2、SOC 3、暗号化、監査ログ、Trust Center	高
自社側の設定	誰がZapを作れるか、どのアプリに接続できるか	高
データの種類	個人情報、請求情報、認証情報、社外秘資料など	高
保存期間	Zap履歴、Parser内データ、連携先アプリの保存期間	中〜高
運用ルール	退職者対応、定期棚卸し、ログ確認、権限見直し	高

---

📋 まず分けて考えるべき2つの安全性

区分	内容	例
プラットフォーム安全性	Zapierがどんなセキュリティ基盤を持つか	暗号化、SOC 2、監査、Trust Center
運用安全性	自社がどう使うか	個人アカウント禁止、SSO、不要Zap停止

Zapier公式のセキュリティページでは、暗号化、SSO、SCIM、監査ログ、VPC Peering、IP allowlistなど、企業利用を想定した機能が説明されています。これらは、単なる個人向け自動化ツールではなく、組織利用を意識した設計になっていると見てよいでしょう。

一方で、Zapierは多くのアプリを簡単につなげられるサービスです。便利さと引き換えに、設定ミスの影響範囲も広がりやすくなります。たとえば、Slack通知だけのつもりが、顧客名・メールアドレス・注文内容までチャンネルに流れていた、という事態は設定次第で起こり得ます。

そのため、資産データや機密情報を扱う場合は、Zapierの導入前に「流してよいデータ」と「流してはいけないデータ」を分けることが大切です。特に、認証情報、APIキー、パスワード、マイナンバーに近い情報、金融資産に関わる情報などは、一般的には慎重に扱うべきです。

🧭 導入前の基本判断

判断項目	OKに近い例	注意が必要な例
データの機密度	公開済みの投稿情報、タスク名	顧客情報、売上詳細、契約情報
連携先の信頼性	社内管理済みSaaS	個人管理の無料ツール
権限管理	SSO・2FAあり	共有ログイン、個人メール管理
ログ確認	監査ログを確認できる	誰が何をしたか追えない

ここで重要なのは、Zapierを「危ないツール」と決めつけることではありません。むしろ、Zapierは公式にセキュリティ情報を公開しており、企業向けの管理機能も整えています。ただ、ノーコードで誰でも連携を作れるからこそ、ルールなしに広げるとリスクが増えます。

「zapier 資 安」と調べている人にとっての最初の答えは、Zapierは安全機能を持つが、資産データを扱うなら設定・権限・保存期間・ログ確認まで含めて判断すべきということです。

Zapierの認証・監査レポートはTrust Centerで確認するのが基本である

Zapierのセキュリティを調べるうえで、最初に見るべき場所はZapier Trust Centerです。Zapier公式ヘルプによると、Trust CenterではSOC 2 Type IIレポート、SOC 3レポート、ペネトレーションテスト結果、セキュリティホワイトペーパー、セキュリティポリシーなどを確認できます。

ただし、すべての文書が一般公開されているわけではありません。公式情報では、一部の文書はNDA、つまり秘密保持契約の締結が必要とされています。手続きはTrust Center内でセルフサービス形式で行えると説明されています。企業導入で稟議やセキュリティ審査が必要な場合は、まずここを確認するのが自然です。

Zapierのセキュリティ・コンプライアンス文書はTrust Centerから確認でき、一部文書はNDA締結後に取得できると説明されています。
引用元：https://help.zapier.com/hc/en-us/articles/8496181993613-Security-and-Compliance

Trust Centerを見るメリットは、営業資料のような表現だけでなく、監査レポートやポリシーに近い情報を確認できる点です。もちろん、実際の文書内容の解釈には専門知識が必要な場合があります。社内にセキュリティ担当者がいる場合は、導入前に一緒に確認するのがよいでしょう。

🔍 Trust Centerで確認したい文書

文書・情報	何を見るか	使いどころ
SOC 2 Type IIレポート	統制が一定期間運用されているか	企業のセキュリティ審査
SOC 3レポート	外部向けに要約された信頼性情報	概要確認
ペネトレーションテスト結果	第三者による攻撃耐性チェック	技術審査
セキュリティホワイトペーパー	セキュリティ体制の説明	稟議資料
セキュリティポリシー	社内統制・管理方針	契約前確認

---

📝 Trust Centerを見るときの実務ポイント

見る順番	確認内容	コメント
1	SOC 2 Type IIの有無	まずは基本の信頼材料
2	暗号化・アクセス管理	自社の要件に合うか確認
3	データ保存・削除	機密データを扱う場合に重要
4	AI関連の扱い	AI連携を使う場合は必須
5	監査ログ	事故時に追跡できるか

Zapier公式ヘルプでは、SOC 2 Type II監査は年次で実施され、更新されたレポートは監査サイクル後にTrust Centerで公開されると説明されています。この点は、継続的にセキュリティ審査を受けているかを見る材料になります。

ただし、Trust Centerの文書を取得したからといって、自社の利用方法まで自動的に安全になるわけではありません。たとえば、社内の誰でもZapを作れる状態にしている場合、従業員が意図せず機密情報を外部ツールへ送る可能性があります。Trust Centerは「Zapier側の基盤確認」であり、「自社運用の確認」とセットで見る必要があります。

特に、社内のセキュリティチェックシートに回答する場合は、「ZapierはSOC 2に対応しているか」だけでなく、「当社ではSSOを使うのか」「個人アカウントを許可するのか」「ログは誰が見るのか」まで決める必要があります。

📌 社内確認で使える質問例

質問	理由
Zapierの利用プランはTeamかEnterpriseか	使える管理機能が変わる可能性があるため
SSOやSCIMを使うか	入退社時の権限管理に関わるため
Trust Centerのレポートを誰が確認するか	技術・法務・管理部門の判断が必要なため
Zapの作成権限を誰に与えるか	シャドーIT化を防ぐため
機密データを流すZapを許可するか	情報漏えいリスクを下げるため

Zapierを業務に入れるときは、まず公式Trust Centerを見て、次に自社の使い方に落とし込む。この順番が大切です。

SOC 2 Type IIやSOC 3は安全性を見るうえで重要な判断材料になる

Zapierは公式ヘルプとセキュリティページで、SOC 2 Type IIおよびSOC 3に関する情報を示しています。これらは、外部の第三者監査に関わる認証・報告の仕組みです。難しく聞こえますが、ざっくり言えば「会社がセキュリティや運用管理をきちんと行っているかを、外部の監査人が確認する枠組み」と理解するとわかりやすいです。

SOC 2 Type IIは、ある一時点だけではなく、一定期間にわたって管理体制が運用されているかを見るものです。つまり「仕組みがあります」だけではなく、「その仕組みが継続的に動いていますか」という観点が含まれます。資産データや顧客情報を扱うSaaSを選ぶ際には、重要な判断材料になります。

SOC 3は、SOC 2に比べて一般公開向けのレポートとして扱われることが多いです。社内の詳細審査ではSOC 2 Type IIが重視されやすく、外部向けの概要確認ではSOC 3が見られることがあります。Zapier公式情報でも、SOC 2 Type IIとSOC 3の文書がTrust Centerで確認できるとされています。

📊 SOC 2 Type IIとSOC 3のざっくり比較

項目	SOC 2 Type II	SOC 3
主な用途	詳細なセキュリティ審査	一般向けの信頼性確認
内容の細かさ	詳細	要約的
取得方法	Trust Centerで確認、場合によりNDA	Trust Centerで確認
企業導入での重要度	高	中〜高
見る人	セキュリティ・法務・情報システム	経営・管理部門も見やすい

---

🧩 SOCレポートを見るときの視点

視点	確認したいこと
対象範囲	どのサービスや機能が監査対象か
監査期間	いつの期間を見たレポートか
例外事項	重大な指摘がないか
統制内容	アクセス管理、変更管理、ログ管理など
自社要件との一致	自社のセキュリティ基準に合うか

ただし、SOC 2やSOC 3があるからといって、すべてのリスクが消えるわけではありません。監査レポートは、あくまでZapier側の管理体制を確認する材料です。利用者側が不用意に個人情報を公開チャンネルへ送ったり、不要なアプリ連携を残したりすれば、事故は起こり得ます。

たとえば、Zapierで「新規問い合わせをSlackに通知する」Zapを作る場合、問い合わせ本文に個人情報や機密情報が含まれていれば、Slack側のチャンネル設定も安全性に関係します。ZapierのSOC対応だけを見ていても、連携先の設定が甘ければ意味が薄れます。

このため、SOC 2 Type IIやSOC 3は「Zapierを候補に入れてよいか」を判断する材料であり、「このZapを本番運用してよいか」は別途確認すべきです。企業利用では、サービス選定と個別ワークフロー審査を分けて考えると整理しやすくなります。

✅ 実務でのおすすめ判断

判断段階	確認するもの	ゴール
サービス選定	SOC 2、SOC 3、Trust Center	Zapierを利用候補にするか
プラン選定	Enterprise機能、SSO、SCIM、監査ログ	組織利用に耐えるか
Zap作成	流すデータ、連携先、権限	個別処理が安全か
運用開始後	ログ、退職者、不要Zap	継続的に安全か

SOC対応は重要です。しかし、それはゴールではなくスタートラインです。Zapierを安全に使うには、公式認証を確認したうえで、自社の業務フローに合わせて「どこまで自動化するか」「何を手動承認に残すか」を決めることが欠かせません。

暗号化・SSO・SCIM・2FAは企業利用で優先して見るべき項目である

Zapierのセキュリティページでは、暗号化、SSO、SCIM、2FA、IP allowlist、監査ログ、アプリ制御など、企業利用で重要になる機能が紹介されています。資産データや顧客情報を扱うなら、これらの機能を単語として知るだけでなく、何のために使うのかを理解しておくと判断しやすくなります。

暗号化は、データをそのまま読めない形にする仕組みです。Zapier公式情報では、通信時の保護や、保存時のAES-256暗号化に関する説明があります。一般的には、通信中と保存中の両方で暗号化されているかは、SaaS選定でよく確認されるポイントです。

SSOは、社内で使っているID管理サービスを使ってZapierへログインする仕組みです。SAML 2.0が出てくる場合もありますが、簡単に言えば「会社のログイン管理に統一する」ためのものです。退職者のアカウント停止やパスワード管理を一本化しやすくなります。

SCIMは、ユーザーアカウントの作成・更新・削除を自動化する仕組みです。入社した人に権限を付け、退職した人の権限を外す作業を自動化しやすくなります。資産データを扱うツールでは、退職者のアクセス残りは大きなリスクになり得ます。

🔐 企業利用で見たい主要機能

機能	何をするものか	なぜ重要か
暗号化	データを読み取りにくい形にする	通信・保存時の保護に関わる
SSO	社内IDでログイン管理する	個人アカウント乱立を防ぎやすい
SCIM	ユーザー管理を自動化する	入退社対応を漏れにくくする
2FA	二段階認証を追加する	不正ログイン対策になる
監査ログ	操作履歴を追跡する	事故時の調査に役立つ
IP allowlist	接続元を制限する	社外からの不正アクセス対策になる

---

🛡️ 機能ごとの優先度マトリクス

利用状況	優先したい機能	理由
個人の軽い業務自動化	2FA、接続アプリの見直し	まず不正ログインを防ぐ
小規模チーム利用	権限管理、共有接続の管理	誰が何を動かすか整理する
全社利用	SSO、SCIM、監査ログ	入退社・ログ管理が重要
機密データ利用	IP allowlist、データ保持設定、承認フロー	情報流出の影響が大きいため
AI連携利用	AIアプリ制御、学習オプトアウト確認	データ利用範囲の確認が必要

Zapier公式情報では、Enterprise向けにガバナンス機能やアプリごとのアクセス制御、アクション制限、管理された接続、ドメイン制限なども紹介されています。これらは、いわゆる「シャドーIT」を防ぐために役立つ機能です。シャドーITとは、会社が把握していないツール利用やデータ連携が勝手に広がる状態のことです。

たとえば、ある部署が便利だからと個人メールでZapierアカウントを作り、顧客データを外部ツールへ転送していると、情報システム部門や管理者が把握できません。こうした状態を避けるには、ドメイン管理やSSO、アプリ制御が重要になります。

また、2FAは個人利用でもすぐに取り入れたい対策です。パスワードが漏れた場合でも、追加認証があることで不正ログインのリスクを下げられる可能性があります。もちろん2FAだけで万全とは言えませんが、基本対策としては優先度が高いです。

📌 導入前チェックリスト

チェック項目	確認
管理者アカウントに2FAを設定しているか	□
退職者の接続アプリを削除するルールがあるか	□
個人アカウントでの業務Zap作成を禁止または管理しているか	□
SSOやSCIMが必要な規模か検討したか	□
監査ログを誰が見るか決めているか	□
機密データを流すZapを事前審査しているか	□

Zapierは簡単に始められる反面、組織で本格的に使うなら管理機能の確認が欠かせません。特に資産データや顧客情報を扱う場合は、便利さよりも「誰が、どこまで、何をつなげられるか」を先に決めることが大切です。

AI連携はデータ利用ポリシーと学習オプトアウトを確認する必要がある

Zapierは近年、AIオーケストレーションやAIアプリ連携を強く打ち出しています。業務自動化とAIを組み合わせると、問い合わせの分類、文章生成、データ要約、タスク作成などが簡単になります。一方で、AI連携は通常のアプリ連携よりも慎重な確認が必要です。

理由は、AIに渡したデータがどのように処理されるのか、どの範囲で保存されるのか、学習に使われる可能性があるのかを見ておく必要があるためです。Zapier公式のセキュリティページでは、Enterprise顧客はモデル学習から自動的にオプトアウトされると説明されています。他のプランでもオプトアウトの方法が用意されているとされています。

ただし、ここで注意したいのは、Zapierだけでなく、接続先のAIサービス側のポリシーも関係する点です。Zapierを通じてAIツールにデータを送る場合、そのAIツールのデータ保持や学習利用の条件も確認すべきです。Zapier側が安全でも、連携先の扱いが自社基準に合わない可能性があります。

Zapierの公式セキュリティページでは、Enterprise顧客のAIデータ学習オプトアウトや、AIアプリ利用制御に関する説明があります。
引用元：https://zapier.com/security-compliance

🤖 AI連携で確認したい項目

項目	確認内容
AIに送るデータ	個人情報や機密情報を含むか
学習利用	モデル学習に使われる可能性があるか
保存期間	入力・出力がどれくらい保存されるか
管理機能	AIアプリを禁止・制限できるか
承認フロー	AI連携Zapを誰が承認するか
連携先規約	AIサービス側の利用規約・プライバシー条件

---

📊 AI連携のリスク分類

リスク	例	対策
過剰送信	問い合わせ全文をAIに送る	必要項目だけ送る
機密混入	契約書や顧客情報を要約させる	機密データ除外ルールを作る
出力ミス	AIが誤分類する	重要判断は人が確認する
学習利用	入力データがモデル改善に使われる可能性	オプトアウトを確認する
連携先リスク	外部AIサービス側の保存条件	連携先ポリシーも確認する

AI機能を使うときは、最初から重要データを流すのではなく、低リスクな用途から始めるのが現実的です。たとえば、公開済みブログ記事の要約、社内タスク名の整形、FAQ候補の下書きなどは比較的始めやすいかもしれません。一方で、顧客の資産情報、医療・金融に関わる情報、契約交渉の詳細などは慎重に扱うべきです。

Zapier公式情報では、AIアプリを完全にオフにしたり、利用できるAIアプリを制限したりできるガバナンス機能が紹介されています。組織でAI連携を使う場合は、自由に使わせるよりも、許可したアプリだけを使えるようにするほうが管理しやすくなります。

AI連携のポイントは、「AIだから危険」と単純に考えることではありません。問題は、AIに渡すデータの中身と、その後の扱いです。Zapierを通じてAIを使うなら、どのデータを渡し、どの出力を信用し、どこで人間が確認するかを明確にする必要があります。

🧭 AI連携の実務ルール例

ルール	内容
機密情報は原則送らない	顧客資産・契約金額・認証情報など
送信前に項目を絞る	全文ではなく必要フィールドだけ
重要判断は自動化しない	審査・承認・削除判断は人が確認
AI Zapは事前承認制にする	管理者または責任者が確認
定期的にログを見る	想定外のデータ送信がないか確認

AIとZapierの組み合わせは強力ですが、強力だからこそルールが必要です。特に「資産」や「安全」を気にして検索している人は、AI連携を使う前にデータの扱いを確認しておくべきです。

Email Parserは通常のZapデータとは保存の考え方が異なる点に注意する

ZapierのEmail Parserは、メール本文から必要な情報を抜き出してZapに渡せる便利な機能です。たとえば、注文メールから氏名や金額を抽出してスプレッドシートに入れる、問い合わせメールから会社名を取り出してCRMに登録する、といった使い方ができます。

しかし、Zapierコミュニティの回答では、Parser by Zapierは通常のZapデータとは少し違う扱いになると説明されています。メールテンプレートや転送されたメールは、削除するまでParserアプリ側に残ると説明されています。これは、機密情報を含むメールを扱う場合にかなり重要なポイントです。

特に、メール本文には意図せず多くの情報が含まれます。顧客名、住所、電話番号、注文内容、相談内容、請求情報などがそのまま入ることもあります。Email Parserで抜き出す項目が一部でも、転送されたメール全体が保存される可能性を考える必要があります。

Zapierコミュニティでは、Parser by Zapierのメールやテンプレートは通常のZapデータと異なる保存の考え方になると説明されています。
引用元：https://community.zapier.com/how-do-i-3/zapier-email-parser-data-privacy-and-security-8945

📩 Email Parserで注意したい保存ポイント

対象	保存に関する注意
テンプレート作成用メール	テンプレート内に情報が残る可能性がある
転送されたメール	Parserのメールボックスに保存される
抽出されたデータ	Zapを通じて連携先に送られる
Zap履歴	一定期間、履歴として確認できる可能性がある
削除操作	メール、テンプレート、メールボックス単位で確認が必要

---

🧹 Email Parser利用時の安全運用

対策	内容
ダミーメールでテンプレート作成	機密情報の代わりに架空データを使う
定期的にメール履歴を削除	Parser内に不要データを残さない
メールボックス削除の条件を決める	テンプレートごと消す必要がある場合に備える
機密メールを転送しない	そもそもParserに流さないルールを作る
Zap履歴も確認する	抽出データが履歴に残る可能性を見る

コミュニティ回答では、テンプレート作成時に使ったメールの情報も保存対象になり得ると説明されています。そのため、テンプレート作成では本物の顧客情報を使わず、同じ形式のダミーメールを使うのが安全寄りです。これはすぐ実践できる現実的な対策です。

また、転送後のメールは削除できると説明されていますが、削除範囲を正しく理解する必要があります。メール履歴を削除しても、テンプレート作成に使った情報が残る場合があるため、必要に応じてテンプレートやメールボックス自体の削除も検討します。

Email Parserは非常に便利ですが、メールという性質上、情報が多く入り込みやすいです。フォーム入力のように項目が整理されていないため、不要な機密情報までZapierに渡ることがあります。機密性の高い業務では、ParserよりもフォームやAPI連携など、送るデータを絞りやすい方法を選ぶほうがよいかもしれません。

📌 Parserを使ってよいかの判断表

条件	判断
メールに機密情報がほぼない	比較的使いやすい
メールに顧客情報がある	削除運用と権限管理が必要
メールに金融・医療・契約情報がある	慎重に判断
保存期間を厳密に管理したい	Parser以外の方法も検討
ダミーデータでテンプレートを作れる	安全性を高めやすい

資産データや個人情報をメールで扱っている会社は、Email Parserの導入前に「メール本文全体が保存される前提」でリスクを見たほうがよいです。抜き出す項目だけでなく、メール全体の中身を見ることが大切です。

WebhookはURLだけに頼らず追加の認証や検証を考えるべきである

ZapierではWebhooks by Zapierを使って、外部サービスと柔軟にデータをやり取りできます。Webhookは、あるイベントが起きたときに指定URLへデータを送る仕組みです。たとえば、フォーム送信があったらZapierに通知する、Zapierから社内システムにデータを送る、といった使い方ができます。

Webhookは便利ですが、セキュリティ面では注意が必要です。Zapierコミュニティでは、WebhookのURLは長く推測しにくい値を含み、HTTPSで送信されることが重要だと説明されています。また、より高い安全性が必要な場合には、送信元の確認や改ざん検知のために署名検証などを使う考え方も触れられています。

Webhookの難しさは、通常のAPI呼び出しと違って、送信側と受信側が必ずしも強い認証関係を持たないことです。URLを知っている相手がデータを送れる形になる場合もあります。もちろん、長く推測しにくいURLは一定の防御になりますが、機密情報を扱うならそれだけで安心とは言いにくいです。

Zapierコミュニティでは、Webhook URLはトリガーごとに一意で、長く推測しにくい値を含み、通信を安全に行うことが重要だと説明されています。
引用元：https://community.zapier.com/general-discussion-13/outgoing-webhooks-security-in-zapier-7736

🔗 Webhookで確認したい安全ポイント

項目	確認内容
URLの扱い	推測困難で外部に漏れていないか
HTTPS	暗号化通信になっているか
認証	APIキーやトークンを使えるか
署名検証	HMACなどで改ざん検知できるか
リプレイ対策	同じリクエストの再利用を防げるか
ログ	誰がいつ送ったか追えるか

---

🧪 Webhookの安全度マトリクス

使い方	安全度の考え方	追加対策
公開情報の通知	低リスク	URL管理とHTTPS
社内タスク通知	中リスク	トークン付与
顧客情報送信	高リスク	認証・署名・ログ確認
決済や資産情報	非常に高リスク	専門家レビュー、最小データ送信
システム操作命令	高リスク	送信元制限、承認フロー

Webhookでよくある失敗は、「URLが長いから大丈夫」と考えてしまうことです。URLが漏れた場合、そのURLにデータを投げられる可能性があります。特に、社内チャットやドキュメントにWebhook URLを貼る場合は、アクセスできる人を制限する必要があります。

また、Webhookで送るデータは必要最小限にすべきです。たとえば、顧客IDだけ送ればよいのに、氏名、住所、電話番号、注文詳細まで送ってしまうと、漏えい時の影響が大きくなります。Zapierの設定画面でフィールドを選べる場合は、必要な項目だけに絞るのが基本です。

署名検証については、一般的にはHMACという方式が使われることがあります。これは、送られてきたデータが本当に送信元から来たのか、途中で改ざんされていないかを確認するための仕組みです。ただし、Zapierの標準機能や連携先の仕様によってできることは変わるため、実装可否は個別に確認が必要です。

🧭 Webhook運用ルール例

ルール	内容
URLを共有ドキュメントに貼らない	漏えいリスクを下げる
本番用とテスト用を分ける	誤送信を防ぐ
送信データを最小化する	漏えい時の影響を抑える
トークンや署名を検討する	なりすまし対策
ログを定期確認する	想定外のアクセスを見つける

WebhookはZapierの柔軟性を大きく広げる機能です。ただし、資産データや重要処理に関わる場合は、URLの秘密性だけに頼らず、認証・署名・ログ・最小データ化を組み合わせる考え方が必要です。

zapierの資産連携を安全に使う運用設計

1. Zapierのデータ保持は機能ごとに確認しないと見落としが起きる
2. 監査ログとZap履歴はトラブル時の原因調査に役立つ
3. アプリ接続権限は「必要な人だけ・必要な範囲だけ」に絞るべきである
4. サプライチェーン攻撃のニュースはZapier本体と周辺パッケージを分けて見るべきである
5. セキュリティ自動化にZapierを使うなら通知と記録から始めるのが現実的である
6. 導入前チェックリストで資産データの流れを可視化するべきである
7. 総括：zapier 資 安のまとめ

Zapierのデータ保持は機能ごとに確認しないと見落としが起きる

Zapierの安全性を考えるとき、多くの人が暗号化や認証に注目します。しかし、実務では「データがどこに、どれくらい残るのか」も重要です。資産データや個人情報を扱う場合、処理が終わったあとに不要なデータが残り続けると、リスクになります。

ZapierコミュニティのEmail Parserに関する回答では、通常のZapデータ、Parser内のメール、テンプレート作成に使ったメール情報などで保存の考え方が異なると説明されていました。つまり、Zapier全体をひとくくりにして「保存期間はこれ」と考えると見落としが起きます。

Zapier公式ヘルプのデータプライバシー・セキュリティ一覧には、データ保持のカスタマイズ、監査ログ、アカウントデータのエクスポートや削除、AI利用、VPC Peering、静的IPなど、多くの関連項目が並んでいます。これは、機能ごとに確認すべき論点があることを示しています。

📦 データ保持で確認したい場所

場所	確認内容
Zap履歴	実行履歴に入力・出力データが残るか
Raw request	トラブルシューティング用のデータが残るか
Email Parser	メール本文やテンプレートが残るか
連携先アプリ	Google Sheets、Slack、CRMなどに残るか
AI連携先	入力・出力が保存されるか
ログストリーム	外部ログ基盤へ何を送るか

---

🕒 保存期間を考えるときの分類

データ種類	例	保存に注意すべき理由
個人情報	氏名、メール、電話番号	漏えい時の影響が大きい
資産情報	保有資産、契約額、売上	事業上の機密になりやすい
認証情報	APIキー、トークン	不正利用につながる
問い合わせ本文	自由記述の相談内容	予期しない情報が含まれる
AI入力	要約対象の文章	学習・保存条件の確認が必要

データ保持で特に見落としやすいのは、Zapierだけでなく連携先にもデータが残る点です。たとえば、ZapierからGoogle Sheetsに顧客情報を入れる場合、Zapier側の履歴を削除しても、Google Sheets側には当然データが残ります。Slack通知も同じで、チャンネルに投稿された情報はSlack側の保存ポリシーに従います。

また、Zapが失敗したときの履歴にも注意が必要です。エラー内容に送信データの一部が含まれることがあります。トラブル対応には便利ですが、機密情報を扱う場合は、誰がZap履歴を見られるかも管理すべきです。

Zapierのデータ保持を安全に管理するには、まず「データの流れ」を図にするのが有効です。どのアプリから入り、Zapierでどう加工され、どこに出て、どこにログが残るのかを整理します。これだけでも、不要な保存先や過剰なデータ送信に気づきやすくなります。

🧭 データフロー確認表

ステップ	確認すること
入力元	どのアプリからデータが入るか
Zapier内処理	フィルター、整形、AI処理があるか
出力先	どのアプリに送るか
履歴	Zap履歴に何が残るか
削除方法	不要データをどう消すか
管理者	誰が確認・削除できるか

資産データを扱うなら、保存期間は「あとで確認」ではなく、導入前に見るべき項目です。特にEmail ParserやAI連携のようにデータの扱いが複雑になりやすい機能は、通常のZapとは分けて確認しましょう。

監査ログとZap履歴はトラブル時の原因調査に役立つ

Zapierの企業向けセキュリティでは、監査ログやZap実行履歴が重要です。監査ログとは、誰が、いつ、何をしたかを追跡するための記録です。Zap履歴は、Zapがいつ実行され、どのステップで成功・失敗したかを見るための記録です。

資産データや顧客情報を扱う場合、問題が起きたときに「誰が設定を変えたのか」「どのZapがデータを送ったのか」「いつから誤作動していたのか」がわからないと対応が遅れます。監査ログや履歴があれば、原因調査や再発防止に使える可能性があります。

Zapier公式のセキュリティページでは、すべての実行がログ化され、接続が追跡され、誰がいつどこから操作したかを見られるといった説明があります。Enterprise利用では、ログ、分析、アラートなどの観測性も重要な機能として示されています。

📜 監査ログで見たいこと

確認項目	目的
ユーザー操作	誰がZapを作成・変更・削除したか
アプリ接続	誰がどのアプリを接続したか
権限変更	管理者権限や共有設定が変わったか
実行履歴	どのZapがいつ動いたか
失敗履歴	エラーや再実行の有無
不審操作	通常と違う場所や時間の操作

---

🚨 トラブル時にログで確認する順番

順番	確認内容
1	問題が起きた日時を特定する
2	該当時間帯に動いたZapを確認する
3	Zapの入力元と出力先を確認する
4	直近で設定変更したユーザーを確認する
5	接続アプリや権限変更を確認する
6	不要なZapを停止し、影響範囲を調べる

Zap履歴は便利ですが、見られる人を制限する必要があります。Zap履歴には処理対象のデータが含まれることがあるためです。たとえば、顧客名やメール本文、注文内容などが履歴に表示される可能性があります。管理者だけが見られるようにする、チームごとに権限を分ける、といった対策が考えられます。

また、ログを残すことと、ログを確認することは別です。ログがあっても誰も見ていなければ、不審な動きに気づけません。高リスクなZapについては、月1回など定期的に実行履歴を確認する運用があると安心です。

Zapierには、ログストリームを使ってZap活動を監視する項目もヘルプ一覧にあります。大きな組織では、Zapier内だけで見るのではなく、外部のログ管理基盤に送って監視する方法も考えられます。ただし、ログにも機密情報が含まれる可能性があるため、送る内容は慎重に決めるべきです。

📌 ログ運用の現実的なルール

ルール	内容
管理者を明確にする	誰がログを見るか決める
高リスクZapをリスト化する	顧客・資産データを扱うZapを把握
月次で確認する	不要Zapや失敗を棚卸し
退職者の接続を確認する	古い接続情報を残さない
事故時の手順を作る	停止、調査、報告の流れを決める

監査ログとZap履歴は、単なる技術機能ではありません。ビジネス上は「問題が起きたときに説明できる状態」を作るためのものです。資産データを扱うなら、導入時からログ確認の担当と頻度を決めておきましょう。

アプリ接続権限は「必要な人だけ・必要な範囲だけ」に絞るべきである

Zapierの便利さは、数多くのアプリをつなげられる点にあります。しかし、これは同時にリスクにもなります。誰でも自由にアプリを接続できる状態だと、会社が把握していないデータ連携が増え、どこに情報が流れているのかわからなくなるかもしれません。

Zapierのセキュリティページでは、アプリごとのアクセス制御、アクション制限、管理された接続、ドメイン制限など、ガバナンス機能が紹介されています。これらは、組織が安全に自動化を広げるための仕組みです。特にEnterprise利用では、IT部門が全体を管理しながら、現場が必要な自動化を作れる状態を目指すのが理想です。

「必要な人だけ・必要な範囲だけ」という考え方は、最小権限の原則と呼ばれることがあります。難しく言えばそうですが、意味はシンプルです。営業担当が請求システムの管理者権限を持つ必要はありませんし、マーケティング担当が全社の人事データにアクセスする必要もありません。

👥 権限管理で分けるべき項目

項目	分け方
ユーザー権限	管理者、作成者、閲覧者
アプリ接続	接続してよいアプリ、禁止するアプリ
データ範囲	部署ごと、業務ごと
Zap作成	誰が本番Zapを作れるか
共有接続	会社所有の接続か個人所有か
承認	高リスクZapは事前承認制にするか

---

🔐 アプリ接続のリスク別管理

アプリ種類	リスク	管理方針
Slack・Teams	投稿先の誤り	チャンネル制限
Google Sheets	データコピーが容易	ファイル権限確認
CRM	顧客情報が多い	管理者承認
会計・請求ツール	金額・契約情報	高リスク扱い
AIツール	入力データの扱い	利用アプリを制限
Webhook	外部送信が柔軟	事前審査

個人アカウントでの接続にも注意が必要です。社員が個人のGoogleアカウントや個人SlackワークスペースをZapierに接続してしまうと、会社が管理できない場所にデータが移る可能性があります。組織利用では、会社が所有するアカウントや管理された接続を使うほうが安全です。

退職者対応も重要です。退職した社員のZapや接続情報が残っていると、後から問題になる可能性があります。SCIMやSSOを使えば管理しやすくなりますが、使っていない場合でも、退職時チェックリストにZapierの接続解除を入れるべきです。

また、Zapierのようなツールでは、現場が便利な自動化をどんどん作れることが価値です。そのため、すべてを禁止すると業務改善が進みにくくなります。大切なのは、低リスクな自動化は自由度を持たせ、高リスクなデータ連携は承認制にするというバランスです。

📋 権限設計のおすすめ

区分	運用例
低リスクZap	タスク作成、公開情報通知などは部署内で作成可
中リスクZap	顧客情報の一部を扱う場合は管理者確認
高リスクZap	資産・請求・契約情報は事前承認
禁止Zap	パスワードやAPIキーを外部送信する処理
定期棚卸し	月1回または四半期で不要Zapを停止

Zapierを安全に使うコツは、現場の便利さを残しながら、重要データだけしっかり守ることです。権限設計を先に決めるだけで、後から起きる混乱をかなり減らせます。

サプライチェーン攻撃のニュースはZapier本体と周辺パッケージを分けて見るべきである

リサーチ情報には、StepSecurityやAikidoによるShai-Hulud系のnpmサプライチェーン攻撃に関する記事が含まれていました。そこでは、Zapier、ENS、PostHog、Postmanなどの名前が出ており、複数のnpmパッケージが侵害されたと報告されています。こうしたニュースを見ると、「Zapierそのものが危ないのか」と不安になる人もいるでしょう。

ここで重要なのは、Zapier本体のクラウドサービスのセキュリティと、npmエコシステム上の周辺パッケージの侵害は分けて見ることです。記事で扱われているのは、主に開発者環境やCI/CDで利用されるnpmパッケージのサプライチェーン攻撃です。Zapierの通常ユーザーがWeb画面でZapを作る利用とは、リスクの種類が異なります。

ただし、無関係とまでは言い切れません。Zapier関連の開発ツールやパッケージを使っている開発者、CI/CDでnpm installを実行する環境を持つ会社は、影響確認が必要になる場合があります。特に記事では、悪意あるpreinstallスクリプト、Bunのインストール、GitHubトークンや環境変数の窃取、公開リポジトリへの情報流出などが説明されています。

StepSecurityの記事では、npmパッケージを通じたサプライチェーン攻撃と、GitHubトークンや環境変数の窃取リスクが分析されています。
引用元：https://www.stepsecurity.io/blog/sha1-hulud-the-second-coming-zapier-ens-domains-and-other-prominent-npm-packages-compromised

🧨 サプライチェーン攻撃で見るべき対象

対象	一般ユーザーへの関係	開発者への関係
Zapier Webサービス	通常利用の中心	API連携で関係する場合あり
npmパッケージ	直接関係しにくい	依存関係として影響し得る
GitHub Actions	通常利用では関係しにくい	CI/CDで重要
環境変数	通常ユーザーは意識しにくい	トークン漏えいリスク
自己ホストランナー	通常利用ではほぼ関係しにくい	攻撃継続のリスク

---

🛠️ 開発者・管理者が確認したいこと

確認項目	理由
package-lock.json	侵害バージョンが入っていないか確認
npm ls	依存関係を確認
GitHub監査ログ	不審なリポジトリ作成やトークン利用を見る
npmトークン	漏えい時は再発行が必要
CI/CD環境変数	AWS、GCP、Azure、GitHubトークンなどを確認
self-hosted runner	不審なランナー登録がないか確認

この手のニュースで避けたいのは、名前だけ見て過剰に怖がることです。たとえば「Zapierの名前があるからZapierを使うのは危険」と即断するのは、少し粗い判断かもしれません。問題が起きた場所が、Zapier本体なのか、Zapier関連のnpmパッケージなのか、別の依存関係なのかを確認する必要があります。

一方で、軽視もできません。サプライチェーン攻撃は、信頼しているパッケージ経由でマルウェアが入るため、開発者環境やCI/CDに強い影響を与えます。記事では、GitHubトークンや環境変数、npmトークンなどの窃取が説明されており、影響を受けた場合は資格情報のローテーションが必要になります。

Zapierをノーコード自動化ツールとして使う一般ユーザーは、まずZapier公式のTrust Centerやセキュリティページを見るべきです。開発チームがZapier関連SDKやnpmパッケージを使っている場合は、サプライチェーン攻撃情報も別途確認します。

📌 ニュースの読み分け表

ニュース内容	取るべき行動
Zapier公式の認証・セキュリティ更新	Trust Centerを確認
Zapier Webサービスの障害	ステータスや公式告知を確認
npmパッケージ侵害	開発環境・CI/CDの依存関係を確認
AIデータ利用ポリシー変更	AI連携Zapを棚卸し
コミュニティでの保存期間情報	実際の機能ごとに設定確認

サプライチェーン攻撃のニュースは重要ですが、見るべき対象を間違えると判断を誤ります。Zapierを使ううえでは、一般利用のセキュリティ、開発者向けパッケージのリスク、連携先アプリのリスクを分けて整理しましょう。

セキュリティ自動化にZapierを使うなら通知と記録から始めるのが現実的である

Zapier公式ブログでは、セキュリティ自動化の例として、バックアップ、脆弱性スキャン、監視ダッシュボード連携、SlackやTeamsへの通知、パスワード管理、詐欺検知などが紹介されています。これは、Zapierが単に「業務効率化ツール」ではなく、セキュリティ運用の補助にも使えることを示しています。

ただし、最初から高度な自動対応を作るのはおすすめしにくいです。たとえば、脅威を検知したら自動でアカウント停止、ファイル削除、ネットワーク遮断まで行うようなZapは、誤作動したときの影響が大きくなります。まずは通知と記録から始めるのが現実的です。

具体的には、OktaのイベントをGoogle Sheetsに記録する、Intruderの検知結果をZendeskやJiraにチケット化する、PagerDutyやincident.ioの情報をDatadogに送る、UpGuardのデータ漏えいアラートをSlackやGmailに通知する、といった例があります。これらは「人が気づく」「履歴を残す」ための自動化です。

Zapier公式ブログでは、セキュリティ自動化としてバックアップ、脆弱性スキャン、監視連携、チーム通知などのワークフロー例が紹介されています。
引用元：https://www.zapier.com/blog/protect-your-site-improve-security-with-automation/

🛡️ セキュリティ自動化の始め方

段階	内容	例
初級	通知する	Slack、Teams、Gmailに送る
初級	記録する	Google Sheets、Zapier Tablesに保存
中級	チケット化する	Jira、Zendeskに課題作成
中級	ダッシュボード連携	Datadogへ送る
上級	自動対応する	アカウント停止、権限変更など

---

📊 自動化してよい処理・慎重にすべき処理

処理	自動化しやすさ	コメント
アラート通知	高	まず始めやすい
ログ保存	高	監査に役立つ
チケット作成	高	対応漏れ防止になる
優先度付け	中	ルール設計が必要
アカウント停止	低〜中	誤停止の影響に注意
データ削除	低	人の確認を挟むべき

セキュリティ自動化の価値は、担当者の負担を減らし、重要なアラートを見逃しにくくすることです。手作業でログを確認し続けるのは現実的ではありません。Zapierを使えば、特定イベントが起きたときに自動で通知・記録・チケット化できます。

ただし、Zapierをセキュリティ運用に使う場合も、Zapier自体の権限管理が重要になります。セキュリティアラートを扱うZapは、機密性が高い情報を含むことがあります。誰でも見られるSlackチャンネルに流すのではなく、担当者限定のチャンネルやチケット管理ツールに送るほうが安全です。

また、アラートを増やしすぎると、かえって見られなくなります。Zapier公式ブログでも、セキュリティ自動化はノイズを減らし、重要な作業に集中するための考え方として説明されています。通知は多ければよいのではなく、見るべき人に、必要な情報だけ届く設計が大切です。

📌 おすすめの最初の3つ

優先順位	自動化内容	理由
1	重要アラートをSlackまたはTeamsに通知	見逃しを減らす
2	検知イベントをスプレッドシートやDBに記録	後から振り返れる
3	対応が必要なものをJiraやZendeskにチケット化	対応漏れを防ぐ

Zapierを安全に使うだけでなく、Zapierで安全運用を支えることもできます。まずは通知と記録から始め、慣れてきたらチケット化や監視連携へ広げるのが現実的です。

導入前チェックリストで資産データの流れを可視化するべきである

Zapierを導入する前に最も大切なのは、資産データの流れを見える化することです。どのアプリからデータが入り、Zapierで何をし、どのアプリへ出ていくのか。これを把握しないまま自動化を始めると、後から「どこに情報が残っているのかわからない」という状態になりかねません。

特に、ノーコード自動化は簡単に作れるため、現場が便利さを優先して設定してしまうことがあります。最初は小さな通知だけだったものが、いつの間にか顧客情報、請求情報、社内メモ、AI要約まで扱うようになることもあります。だからこそ、最初にチェックリストを用意する意味があります。

チェックリストでは、データの種類、連携先、保存先、権限、ログ、削除方法、退職者対応を確認します。難しいセキュリティ用語を並べる必要はありません。「誰が見られるか」「どこに残るか」「消せるか」「問題が起きたら追えるか」を確認するだけでも、かなり整理できます。

✅ 導入前チェックリスト

チェック項目	確認
Zapierに流すデータの種類を分類したか	□
個人情報・資産情報・認証情報を分けたか	□
連携元アプリと連携先アプリを一覧化したか	□
Zap履歴に残る情報を確認したか	□
Email ParserやAI連携の保存条件を確認したか	□
Zap作成権限を制限したか	□
退職者の接続解除ルールを決めたか	□
Trust Centerの文書を確認したか	□
高リスクZapの承認フローを決めたか	□
定期棚卸しの頻度を決めたか	□

---

🧭 資産データフロー整理表

項目	記入例
データ名	顧客問い合わせ情報
入力元	Webフォーム
Zapier内処理	内容を分類しSlack通知
出力先	Slack、Google Sheets
含まれる情報	氏名、メール、相談内容
機密度	中〜高
保存先	Zap履歴、Slack、Sheets
削除方法	Slack投稿削除、Sheets行削除、履歴確認
管理者	情報システム担当者
承認要否	必要

資産データの流れを可視化すると、不要なデータ送信にも気づきやすくなります。たとえば、Slack通知には氏名だけでよく、メールアドレスや詳細な相談内容はGoogle Sheetsにだけ残せばよいかもしれません。あるいは、Google Sheetsではなく、権限管理されたCRMに直接入れたほうがよい場合もあります。

また、Zapierのアプリ連携は便利ですが、連携先アプリの権限も見逃せません。Zapier側で適切に管理していても、出力先のGoogle Sheetsが全社公開になっていれば意味がありません。Slackも、投稿先チャンネルの参加者によってリスクが変わります。

チェックリストは一度作って終わりではありません。新しいZapを作るたびに軽く確認し、四半期ごとに棚卸しするのがおすすめです。不要になったZap、使っていない接続、退職者の作ったZap、テスト用のWebhookなどは残りやすいので注意しましょう。

📋 定期棚卸しで見るもの

対象	確認内容
Zap一覧	使っていないZapがないか
接続アプリ	不要な接続が残っていないか
作成者	退職者や異動者のZapがないか
データ内容	高リスク情報を扱っていないか
エラー履歴	失敗が放置されていないか
通知先	不適切なチャンネルに送っていないか

Zapierの安全運用は、難しい技術よりも「見える化」と「定期確認」が効きます。資産データを扱うなら、まずデータの流れを表にするところから始めましょう。

総括：zapier 資 安のまとめ

最後に記事のポイントをまとめます。

1. ZapierはSOC 2 Type II、SOC 3、GDPR、CCPAなどの情報を公式に示しているサービスである。
2. Zapierの安全性は、公式基盤だけでなく、自社の設定・権限・運用によって大きく変わる。
3. 資産データを扱う場合は、Trust Centerで監査レポートやセキュリティ文書を確認するべきである。
4. 一部のセキュリティ文書はNDA締結後に取得する流れである。
5. SSO、SCIM、2FA、監査ログ、IP allowlistは企業利用で優先して確認すべき機能である。
6. AI連携を使う場合は、学習オプトアウト、AIアプリ制限、連携先AIサービスのポリシーを確認する必要がある。
7. Email Parserは通常のZapとはデータ保存の考え方が異なるため、テンプレートや転送メールの保存に注意が必要である。
8. Email Parserのテンプレート作成には、本物の機密情報ではなくダミーデータを使うべきである。
9. Webhookは便利だが、URLの秘密性だけに頼らず、認証、署名、ログ、最小データ送信を検討するべきである。
10. Zap履歴や監査ログは、事故時の原因調査と説明責任に役立つ重要な材料である。
11. アプリ接続権限は、必要な人だけ、必要な範囲だけに絞るべきである。
12. サプライチェーン攻撃のニュースは、Zapier本体のリスクとnpmパッケージ周辺のリスクを分けて読むべきである。
13. Zapierをセキュリティ自動化に使うなら、まず通知、記録、チケット化から始めるのが現実的である。
14. 資産データを扱うZapは、導入前にデータの流れ、保存先、削除方法、管理者を表にして確認するべきである。
15. 「zapier 資 安」の結論は、Zapierは安全機能を備えるが、資産データを安全に扱えるかは運用設計次第である。

記事作成にあたり参考にさせて頂いたサイト

1. https://help.zapier.com/hc/en-us/articles/8496181993613-Security-and-Compliance
2. https://www.zapier.com/blog/protect-your-site-improve-security-with-automation/
3. https://help.zapier.com/hc/en-us/sections/14037178066317-Data-privacy-security
4. https://zapier.com/security-compliance
5. https://trust.zapier.com/
6. https://community.zapier.com/general-discussion-13/outgoing-webhooks-security-in-zapier-7736
7. https://www.stepsecurity.io/blog/sha1-hulud-the-second-coming-zapier-ens-domains-and-other-prominent-npm-packages-compromised
8. https://community.zapier.com/how-do-i-3/zapier-email-parser-data-privacy-and-security-8945
9. https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting-zapier-ensdomains
10. https://www.linkedin.com/in/zeeshanalikhadim

当サイトについて

当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。 情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。 迅速に対応をさせていただきます。 その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。 今後とも当サイトをよろしくお願いいたします。