Makeのプライバシー・接続データ・権限を確認

Makeは複数のSaaSやAPIをつなぐautomation platformです。

そのためprivacyを確認するときは、Makeそのものだけでなく、

どのserviceへ接続するか

どのdataをscenarioで扱うか

誰がconnectionを使えるか

AI providerへ何を送るか

まで見る必要があります。

Makeはapplication usage dataを収集する

2026年7月更新のPrivacy Noticeでは、Makeを含むCelonisのserviceについて、利用したapplicationやversion、user interaction、workflow内のstep数、operation type、queryなどのusage dataを収集する場合があると説明しています。

service提供、security、product改善などが目的です。

「Scenario内のbusiness data」と「platform usage data」は分けて考える必要があります。

Customer Dataは契約とDPAで扱われる

MakeのTerms pageでは、service利用にMaster Services Agreement、Data Processing Agreement、Privacy Noticeが適用されると案内しています。

業務dataやpersonal dataを扱う場合は、privacy noticeだけでなくDPAや契約条件も確認します。

特にcompany利用では、個人accountのprivacy設定だけで判断しない方が安全です。

security certification

MakeはGDPRへの対応を案内し、SOC 2 Type II、SOC 3 auditを完了しています。

Enterpriseのinformation security programはISO 27001 certifiedと説明されています。

第三者auditがあることと、個別workflowのdata設計が安全であることは別ですが、platform選定時の基礎情報になります。

data at restはAES-256

MakeのSecurity pageでは、full-disk encryptionにAES-256を使い、AWS KMSでcryptographic keyを管理すると説明しています。

passwordはencrypted formatで保存されます。

data in transitはTLS 1.2 / 1.3を利用します。

log dataはdefault 30日

MakeのSecurity pageでは、log dataはdefaultで30日保存されると説明されています。

Enterpriseではlonger retentionを選べる場合があります。

機密dataがexecution logへ残るworkflowでは、scenarioそのものだけでなくlog retentionも確認する必要があります。

connectionの権限範囲を確認する

MakeではGoogle、Slack、Salesforceなどへのconnectionを作ります。

connectionが持つOAuth scopeやAPI permissionによって、読めるdata・書けるdataが変わります。

read-onlyで足りるworkflowに強いwrite権限を持たせない、個人accountではなくservice accountを使う、という設計が重要です。

AI workflowではproviderもprivacy boundaryになる

Make AI AgentやAI moduleでOpenAI、Anthropic、Geminiなどを使う場合、dataはAI provider側のprocessingにも関係します。

Makeのprivacy policyだけで完結しません。

custom provider connectionを使う場合は、そのproviderの契約・training policy・retentionも合わせて確認します。

Google Workspace APIの扱い

MakeのPrivacy Noticeでは、Google Workspace APIから取得したdataをgeneralized AI / ML modelの開発・改善・trainingへ利用しないと明記しています。

Google Workspaceをautomationへ接続する場合の重要な明示事項です。

ただしworkflowから別のAI providerへそのdataを送る設計なら、その送信先provider側の条件は別途確認が必要です。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Make

  公式サイトを見るTool詳細を見る

Enterpriseでは環境が分離される

Make Enterpriseはself-service cloud customerとは別に管理されたAWS environmentで動作すると説明されています。

SSO、role-based access、audit logs、governance機能なども利用できます。

organization規模でdata accessを管理する場合は、個人planよりEnterprise controlの方が判断材料になります。

access権を最小化する

Scenario builderの便利さから、必要以上のconnectionを共有するとriskが増えます。

誰がscenarioを編集できるか。

誰がconnectionを使えるか。

誰がexecution dataを見られるか。

この3点を分けて考えた方が安全です。

接続前に作るData Flowと権限表

Makeの安全性はサービス単体の認証だけでは決まりません。入力元、Make、AI provider、出力先、実行ログを一枚に書き、どのfieldがどこへ移動するか確認します。次の表をScenarioごとに埋めてください。

| 経路 | 記録する内容 | 確認する理由 |

| Trigger app → Make | 対象field、件数、個人情報の有無 | 不要な列まで取得していないか |

| Make → AI provider | prompt、添付、本文、識別子 | Makeのproviderかcustom connectionか、送信範囲 |

| Make → Action app | 書き込み先、共有範囲 | 誤送信・誤更新の影響 |

| Execution log | input/output、エラー内容、保存期間 | 機密値がログに残るか、誰が閲覧できるか |

たとえば社内FAQ分類なら、社員番号やメールアドレスをAIへ渡さず、問い合わせ本文から識別情報を除いてcategoryだけ返す設計を先に検討します。給与、顧客識別子、認証情報、契約書などを扱う場合は、個人用の試験Scenarioへ実データを入れず、情報管理担当と契約上の可否を確認するまで接続を保留します。

Connectionの確認は、Scenario編集権限とは別に行います。read-only処理にwrite scopeを付けない、退職者個人のOAuth connectionを業務基盤にしない、共有connectionを使えるメンバーを絞る、という順で棚卸しします。Make公式Securityはlog dataの標準保存期間を30日と案内していますが、planや設定による差・変更の可能性があるため、実アカウントの表示と契約条件でも確認してください。

Google Workspace APIから得たdataをMakeがgeneralized AI/MLの開発・改善・trainingへ使わない旨はPrivacy Noticeに明記されています。この説明はMake側での扱いです。Scenarioから外部AI providerへ同じdataを送る場合、そのproviderの契約、retention、training設定、regionは別途確認します。Make Termsの一覧からDPA、subprocessor、Technical and Organizational Measuresへ進み、対象契約のversionと適用条件を確認してください。

| 判定 | 次の行動 |

| 公開情報だけ | dummy dataで動作確認 |

| 社内限定情報 | 最小field・閲覧者・logを確認 |

| 個人情報 / 顧客秘密 | DPA、法的根拠、接続先、AI providerを確認 |

| 認証情報 / 高機密 / 重要操作 | 承認者が決まるまで実データを流さない |

導入前と月次変更時に、connectionの所有者、scope、Scenario編集者、log閲覧者、保存期間、削除手順を記録します。データ分類が決められない場合は、試験用の架空dataだけに留めるのが次の安全な行動です。

AIものさしの判断

Makeのprivacyで重要なのは「Makeは安全か」という一問ではなく、data flowとpermissionです。

Trigger app

→ Make

→ AI provider

→ Action app

のようにdataがどこを通るかを書き出す。

各connectionのpermissionを確認する。

execution logとretentionを見る。

機密度が高いworkflowではEnterprise controlも比較する。

この順で確認するとriskを把握しやすくなります。