MakeとChatGPTを連携してAIワークフローを作る方法

MakeとChatGPT（OpenAI）を連携する基本は、scenarioの開始条件を決め、必要なdataだけOpenAI moduleへ渡し、検証した結果を次のappへ写すことです。全payloadをAIへ送るより、目的に必要なfieldだけをmappingし、出力を後続moduleが扱える形に固定します。最初から多数のRouterやAgentを追加せず、trigger → OpenAI → 保存先という一つの処理で境界を確かめてください。

MakeのOpenAI appには複数のmoduleがあり、公式Apps Documentationはmoduleごとの接続条件や入力を説明しています。MakeのscenarioやUIは更新されるため、ここではnode名の暗記ではなく、scenarioのdata契約、失敗時の扱い、再実行の安全性を中心にします。記事は公式情報に基づく設計例で、Makeの実操作をした体験談ではありません。

例：会議メモを要点へ分けて保存する

架空の会議メモを受け取り、要約を社内の記録先へ保存するscenarioを考えます。

表は横にスクロールできます

項目	設計例	なぜ決めるか
Trigger	Webhookまたは接続appの新規record	何が起きたら1回実行するかを固定
Input	record_id、本文、会議日	後で同じrecordを照合する
OpenAI	要点、決定事項、未決事項の抽出	出力用途を3つに分離
Validation	必須key、空欄、上限、根拠の存在	形式崩れを後段へ流さない
Action	記録先へupsertまたはreview依頼	二重appendを防ぎ、人が確認できる
Error path	incomplete execution / 通知	retryと手動復旧を分ける

AIの要約は議事録そのものではありません。意思決定や担当者をモデルが本文にないのに補わないよう、抽出と提案を区別します。decisionsやownersが本文に明示されていなければ空配列、unknownなどにする契約を設定します。

Scenarioを一つの成果で定義する

「ChatGPTを使う」ではなく、「毎週届く会議メモから決定事項と未決事項を抜き、担当者が確認できる記録を作る」のように、開始条件と完了状態を書きます。ここで次の三つを決めます。

1. 開始条件：Webhook、app event、scheduleのどれか。test時に何を送るか。

2. 完了条件：保存先にrecord_idで照合できる結果が作られ、statusが更新された状態。

3. 人に渡す条件：本文が短い、決定事項が曖昧、必須keyがない、外部送信を伴う場合など。

Makeではmodule間で前工程のdataをmappingし、scenarioを構成します。最初にtrigger、OpenAI module、保存先だけの線を作り、sample dataで各moduleのinput/outputを一つずつ確認します。全体を一度に組んでから原因を探すより、境界ごとにtest runする方がmappingのズレを見つけやすくなります。

OpenAI moduleと接続の選び方

Makeの公式OpenAI module documentationは、Simple text promptのように接続不要のmoduleがある一方、他のmoduleではOpenAI app connectionを作成する必要があると案内しています。したがって「MakeにOpenAIをつなぐ」だけでは設定は特定できません。使うmoduleを先に決め、そのmoduleのcredential、入力形式、利用条件を確認してください。OpenAI APIを使う接続では、ChatGPT subscriptionとAPI billingを同一視せず、OpenAI側の料金・利用制限を別に確認します。

connectionは、誰のaccountで作ったか、teamやscenarioのどこまで共有されるか、担当者が変わったときに誰が保守するかを含む運用要素です。画面へAPI keyを貼り付けるのではなく、Makeのconnection管理を使います。共有範囲が広いteamで接続を使う場合は、対象app側の権限も必要最小限にしてください。

Mappingは必要fieldのallowlistにする

Webhookや前のmoduleが多数の値を返しても、OpenAIへ渡すのは必要なfieldに限ります。例えば議事録の処理なら、record_id、会議本文、必要なら会議日で足りるかもしれません。参加者email、内部URL、添付metadata等は要約に不要ならmappingから外します。

表は横にスクロールできます

出力key	形式	ルール
summary	string	5行以内、本文中の事実だけ
decisions	string[]	決定事項がなければ空
open_questions	string[]	未決事項を別に抽出
owner	string / null	明示がなければnull
needs_review	boolean	参加者・金額・責任が曖昧ならtrue

自由文をRouter条件へ直接使うと、「重要」「最優先」などの語句や表記揺れでbranch分けします。まず許可値とschemaを決め、出力をvalidationしたあとFilterやRouterへ渡します。AIの結果を命令として実行する接続や削除操作へ直結させず、low confidence・unknown・不正形式はreviewへ送ります。

RouterとFilterを足す判断

Routerは、出力categoryごとに保存先が変わる、または承認が必要なcaseを分けるときに使います。Filterは、条件を満たすbundleだけ次へ通すときに使います。数を増やすこと自体は精度を上げません。例えば初期scenarioでは、needs_review = trueだけ人へ通知し、それ以外も「自動送信」ではなく内部記録へ保存するだけにします。

分岐は全ての経路で最終状態へ到達するように設計します。該当branchがない値、空欄、unknownをどこへ流すかを決めてください。設定後に正常値だけを試すのではなく、categoryがunknown、配列が空、文章が長すぎる、OpenAI応答が形式外のcaseで各branchを通します。

Error・retry・二重処理

Makeの公式helpでは、scenario設定でincomplete executionsを保存でき、error種別やRetry error handlerに応じて自動または手動で再試行する仕組みが案内されています。すべての失敗を自動retryしてよいわけではありません。timeoutや一時的な接続障害と、権限切れ、入力不正、出力先field変更を区別します。

表は横にスクロールできます

失敗	再試行の候補	先にすること
一時的なConnection / timeout	条件付きでretry	同じactionの二重実行有無を確認
Rate limit	backoff後のretry	頻度と処理量を見直す
認証失敗	即時retryしない	connectionを修復
mapping / validation error	retryしない	inputとschemaを修正
保存先で失敗	慎重に再実行	record_idで保存済みか照合

保存先がappendのみだと再試行で同一メモが二重登録される可能性があります。record_idを持たせ、存在すればupdateするか、既に完了なら処理をskipするなど、再実行の意味を決めます。Makeのincomplete executionは復旧に便利ですが、入力dataも保持され得るため、個人情報を含むbundleの保存要否と閲覧者を確認します。

ChatGPT内からMakeを使う案内は別の入口

MakeはChatGPT内からscenarioを作成・実行・確認するpluginを公式に案内した時期がありますが、Makeの公式記事にはplugin利用が一時的に停止されている旨も記載されています。利用可能性は変化するため、連携の前提として依存しないでください。scenario本体、connection、実行履歴の管理はMake側で確認し、ChatGPT内の入口が使える場合も、権限と作成内容を確認してから有効化します。

この機能が一時停止中でもMakeの通常scenarioは別に運用できます。本文の中心はMakeのOpenAI moduleとscenario設計に置き、pluginの状態が変わったら記事を更新できるよう、確認日と公式sourceを保ちます。

公開・運用前のQA

• sample recordを1件だけ流し、各moduleのinput/outputを照合した

• OpenAIへ渡すfieldをallowlist化した

• API billingとMake planを分けて確認した

• 出力key、type、許可値を固定した

• unknown / 不正出力は安全側へ送った

• 保存先をrecord_idで照合し、重複を抑えた

• ConnectionError、timeout、rate limit、権限失敗を別々に扱った

• incomplete executionに残るdataを確認した

• scenarioを変更したとき、正常・異常両方をtestした

• ChatGPT pluginの利用可否を導入条件にしていない

AIものさしの判断

MakeとChatGPTを組み合わせるとき、scenarioの使いやすさはAI module単体より、mapping、validation、再試行と保存先の関係で決まります。まず一つの業務結果に限定したscenarioを作り、入力の何をAIへ渡したか、出力のどのfieldをどこへ保存したかを追えるようにします。処理量や分岐が増えてからRouterを追加し、外部送信や更新を自動化する前に、人の承認と二重処理防止を確かめてください。