Makeを業務利用するときに確認したい条件

Makeは企業のinternal workflow automationを前提としたserviceです。

sales、marketing、operations、ITなど業務automationへ利用できます。

一方、Makeそのものを第三者へ提供するserviceを作る場合や、client dataを跨いで扱う場合は、通常の社内利用と同じ前提では考えない方が安全です。

internal business useが基本

MakeのMaster Services Agreementでは、subscription期間中、serviceをinternal purposesで利用できると定めています。

自社の業務効率化のために、

CRM連携

invoice automation

社内通知

marketing process

AI workflow

へ使うのは基本的な利用形態です。

contractorは自社へserviceを提供する目的で利用できる

MSAでは、第三者supplierやcontractorが、Customerへgoods / servicesを提供する目的でMakeへaccessすることを認めています。

つまりagencyや外部developerが、契約企業のMake環境でautomationを構築・保守する形は契約構造として想定されています。

ただし誰のaccount・organizationで運用するかは明確にした方が安全です。

third partyの利益のための利用には注意

MSAではserviceの利用をCustomerのinternal purposesに限定し、第三者のbenefitのための利用を原則として制限しています。

そのため、

Make access自体をclientへ販売する

Makeをbackendとして複数clientへautomation serviceを再提供する

platform機能をresellする

ようなmodelでは、通常subscriptionだけで足りると判断しない方が安全です。

具体的なservice modelはMakeへ確認する必要があります。

client dataを扱うならDPAを確認する

業務automationではcustomer dataやemployee dataを処理する場合があります。

MakeのTerms pageではData Processing Agreementが用意されています。

personal dataを扱う場合、processor / controllerの役割、subprocessor、data transfer、retentionなどを契約面でも確認します。

third-party serviceのtermsも別に適用される

Makeは多くのAPIやSaaSを接続します。

Makeの契約を守っていても、Salesforce、Google、OpenAI、Stripeなど接続先serviceのtermsまで自動的に満たすわけではありません。

commercial use、rate limit、data transfer、AI training policyなどは接続先ごとに確認が必要です。

AI workflowではprovider契約も見る

Make AI Agentでcustom AI providerを使う場合、model provider側のtermsと料金が別にあります。

client confidential dataをAI providerへ送る場合は、training、retention、DPA、regionを確認します。

Makeのsecurity certificationだけでAI provider側のriskまでcoverされるわけではありません。

Enterpriseではgovernance機能が増える

EnterpriseではSSO、role-based access、audit logs、analytics、spend control、on-prem agentなどが利用できます。

automationを部署横断で広げると、誰でもscenarioを編集できる状態では管理が難しくなります。

規模が大きくなるほどgovernance機能が重要です。

productionではmonitoringも必要

automationは一度作って終わりではありません。

API change

credential expiration

rate limit

schema change

AI output variation

などで失敗することがあります。

business-criticalなscenarioではerror handling、alert、execution log、ownerを決めて運用します。

client workでは責任分界を決める

受託でMake automationを構築するなら、

Make subscriptionは誰が持つか

connection credentialは誰が管理するか

scenario ownerは誰か

credit超過を誰が負担するか

障害対応範囲

退職・契約終了時のaccess

を最初に決めます。

技術よりこの運用設計が後から問題になりやすい部分です。

まずは使ってみる

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

• 

  Make

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

業務利用を始める前の契約・運用チェック

「商用利用できるか」は一語で決まりません。MakeのMaster Services Agreementは、利用を基本的に顧客自身のinternal purposesに限定し、第三者のbenefitのための利用を制限しています。一方、第三者supplierやcontractorが顧客へgoods / servicesを提供するためにaccessする条項もあります。個別のservice modelが許されるかは契約本文・Documentation・注文条件で決まり、次の分類だけで法的結論を出せません。

| 利用形態 | 契約確認の出発点 | 確認先 |

| 自社の社内業務を自動化 | 自社organization内のinternal useか | MSA、利用plan、接続先terms |

| 顧客環境で受託構築・保守 | 顧客自身のためのsupplier/contractor accessか | 顧客契約、account owner、Make MSA |

| 自社Makeを使い顧客向け処理を提供 | serviceが第三者benefitとみなされるか | Makeへ具体的なflowと顧客関係を示して確認 |

| Make accessやplatformを再販売・ホスト | resale / managed serviceの許諾があるか | 個別契約または明示的なDocumentation |

特に「自社の内部processを自動化し成果物を顧客へ納める」形と、「顧客のsystem間をMakeで動かし、その利用自体を提供する」形は同じと断定できません。顧客がMake editorへ入れるか、どのaccountが接続を所有するか、dataの主体は誰か、Makeが顧客への独立serviceの一部かを整理し、曖昧なら本番契約前にMakeへ書面で確認します。

顧客dataやemployee dataを扱うなら、Termsページから適用されるDPA、subprocessor一覧、Technical and Organizational Measuresを確認します。Make以外の接続先にも各サービスの利用条件やprivacy policyが適用されるため、Google、CRM、AI providerなどを別の列で確認してください。Makeのsecurity認証だけで接続先の条件やAI providerのretentionまで確定するわけではありません。

契約前に埋める責任分界：

・Make organization / subscriptionの契約者とowner

・各SaaS connectionとcredentialの管理者

・顧客dataを閲覧・削除できる担当者

・月間creditsと超過費用の負担者

・失敗通知、復旧、手動代替の担当者

・契約終了時のaccess停止、scenario引継ぎ、data削除記録

たとえばagencyが顧客のMake環境でworkflowを構築する場合、顧客側にorganization ownerを置き、agencyのaccessを必要な期間・権限に限定し、引継ぎ時に個人connectionと共有secretを更新します。これは運用上の推奨であり、Makeの契約承認を意味しません。

受託範囲や第三者への再提供が曖昧な場合は、実際のdata flow、顧客のeditor access、課金主体、利用者を1枚にまとめてMakeへ問い合わせるところで止めます。回答と適用契約が揃う前に、「通常の有料planなら問題ない」と公開判断しないでください。

Makeへ確認する前にservice modelを一枚にする

契約上の扱いが曖昧なら、問い合わせ文に「誰がMake organizationを契約・所有するか」「誰のdataを処理するか」「automationの成果を誰が受け取るか」「clientがMakeへ直接loginするか」「Make利用料と外部AI料金を誰が負担するか」を記載します。構成図には接続先、dataの流れ、利用者、再提供・resaleの有無を含め、適用されるMSA / Order条件とあわせてMakeへ書面で確認してください。これは本文から許可を推定するためではなく、個別条件を正しく照会する準備です。

AIものさしの判断

Makeは自社の業務automationへ使う用途とは相性があります。

受託支援でも、client organization内へautomationを構築する形なら整理しやすいです。

一方、Makeそのものを第三者へ再提供するservice modelは、通常のinternal useと同じ前提で進めない方が安全です。

「仕事で使えるか」ではなく、

誰のorganizationか

誰のdataか

誰にserviceを提供するか

誰がcredentialsとcreditsを持つか

で判断することが重要です。