MakeでOpenAI APIを使う基本

MakeでOpenAIを使う場合は、Scenarioの途中へAI処理を入れ、前のmoduleから受け取ったデータを要約・分類・生成して次のmoduleへ渡す形が基本です。

現在のMakeにはOpenAI (ChatGPT, Sora, Whisper) appがあり、プロンプト・response・files・画像など複数のmoduleを利用できます。またSimple text プロンプトはOpenAI アカウント接続なしで使える入口として用意されています。

先に結論：Make＋OpenAIも「入力→AI→検証→次Module」に分ける

Trigger / 前Module

→ 必要な項目をMapping

→ OpenAI Module

→ Router / Filter

→ Destination

OpenAI側のAPI利用とMake側のクレジットは別に確認します。AI Module単体ではなくScenario全体でTestするのが完了条件です。

最小構成を作る

AIで処理する内容を1つに絞る

問い合わせ分類、文章要約、返信下書き、商品説明生成など、入力と出力を明確にします。

使うModuleを決める

簡単なtext処理ならSimple text プロンプトも選択肢です。一方、OpenAI appの他moduleを使う場合はOpenAI connectionを設定します。

OpenAI Connectionを設定する

Make公式DocsではOpenAI app利用にOpenAI アカウントとクレジットが必要と案内されています。API利用分はChatGPTのsubscriptionとは別に扱われます。

前ModuleのDataをMappingする

Gmail本文、form回答、Sheet rowなど、AIに必要な項目をOpenAI moduleへ渡します。不要なデータまですべてプロンプトへ入れないようにします。

本番運用へつなぐ

PromptとOutputを後続処理向けに整える

人が読む文章だけでなく、カテゴリ、要約、JSON相当の項目など、次moduleで扱いやすい出力を指定します。

RouterやFilterで検証する

AI resultが空、想定外のlabel、要確認内容だった場合は別ルートへ分けます。AI 出力を無条件で外部送信やDB更新へ渡しません。

CostとCreditを確認する

Simple Text Promptを含むAI moduleはconnection方式でMake creditsの計算が変わります。OpenAIのcustom connectionならMake側は主にoperation、OpenAI側はtoken利用です。Make AI Providerや自動provider connectionではtoken等もMake creditsへ反映される場合があります。利用moduleのconnection設定と公式Credits説明を確認してください。

OpenAI APIの429はrate limit、prepaid balance、organization / projectのusage・spend limitなど複数の原因があります。responseのmessage・code・Retry-Afterを確認し、rate limitとbilling/quotaを分けて対応します。

Scenario全体でTestする

OpenAI moduleだけでなく、トリガー→データ mapping→AI→filter→destinationまで通して確認します。入力が空の場合やAPI error時のルートもテストします。

AIものさしの判断

MakeとOpenAIの連携は、AI単体を使うというより、Scenarioの途中に「判断・変換ステップ」を追加する使い方が中心です。

トリガー→mapping→AI processing→validation→アクション→monitorという順にすると、AI処理を既存の自動化へ安全に組み込みやすくなります。

AIものさしでは、OpenAIからresponseが返ったことではなく、その出力が後続moduleへ安定して渡り、costとerrorを含めて運用できる状態をこのワークフローの完了条件にします。

実装前に決める：Connection方式と課金の境界

Makeでは、同じ「OpenAIを使う」でも選んだmoduleとconnection方式でMake側のcredit計算が変わります。シナリオを組む前に、Makeの使用量とOpenAI APIの請求先を別々に記録してください。

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

利用方式	Make側	AI provider側	作成前に見ること
OpenAI appのカスタム接続	原則、実行operationに応じてcredits	OpenAI API利用分をOpenAI側へ支払う	API keyのproject、budget、model
Make AI Provider	operationとtoken等に応じたcredits	Make経由のcreditsに含まれる方式	利用可能modelと当該機能のcredit説明
自動provider接続の対象module	token、operation、その他利用要素で変動	Makeが選ぶproviderを利用	module固有の説明、実行履歴の消費量

Make公式のcredit説明では、OpenAIなどの第三者AI appで自分のprovider connectionを作る方式は、Make側がoperation基準、provider側がtoken基準です。一方、Simple Text Promptのように接続方式を選べるmoduleや自動接続されるmoduleは、選択内容によって計算が変わります。「Simple Text Promptなら常にtokenに応じてMake creditsが減る」と一括りにはできません。設定画面に表示されるconnectionと、実行後のcredit履歴で自分のケースを確認してください。

最小Scenarioを組む順序

1. Trigger：一件だけのテストデータで起動する。

2. 前処理：AIに不要な個人情報や長文を渡さず、必要項目だけmappingする。

3. AI module：分類、要約など用途を一つに絞る。出力項目と「不明」の扱いを指定する。

4. 検証：必須項目の欠落、許可外の分類、長すぎる出力をFilter / Routerで分ける。

5. Destination：最初は下書き保存など、取り消しやすい動作へ送る。

6. 運用：成功・失敗・再実行・利用量を確認してから本番データへ広げる。

失敗時の切り分け表

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

症状	最初に見る場所	次の対応
Make側creditsが想定より多い	Scenario runのmodule数、moduleごとのusage、connection方式	同一入力を一度だけ実行し、どのmoduleが消費したか特定
OpenAI側で課金・usage error	OpenAI project / organization、API billing、spend limit、error code	ChatGPT subscriptionではなくAPI側の利用状態を確認
429が返る	response本文・code・Retry-After	rate limitなら送信間隔を調整。credit残高・spend limit系なら該当設定を確認し、同じrequestを連打しない
出力が空・形式違い	Makeの実行bundle、prompt、後続Filter	空値・schema不一致を別経路へ送り、外部更新を止める
同じ処理が重複する	Triggerの再取得条件、retry、Destinationのidempotency	固有IDで重複判定し、再実行可能な設計にする

OpenAI APIの429は一種類の「クレジット不足」を意味しません。短時間のrate limit、prepaid balance不足、organization / projectの使用上限などがあり、error codeとresponse内容で切り分けます。課金・quota系は再試行だけで解消せず、rate limit系はRetry-Afterや待機を考慮します。

まず一件だけテストする記録項目

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

実行ID	Input	Make credits前後	OpenAI project/model	HTTP結果	後続処理	再実行時の重複
test-001	機密を除いた例	実行履歴から記録	接続設定から記録	status / code	Draftへ保存	固有IDで照合

この表を埋められないまま回数を増やすと、Make利用量とAPI利用料のどちらが増えたのか分からなくなります。最初の本番相当テストは実データの送信先を限定し、費用と誤送信の両方を確認してください。

情報の根拠として、Make Creditsのconnection別説明とOpenAI API 429の公式切り分けを確認しました。課金モデルや表示されるmodelは変更され得るため、数値価格は固定せず、実際のScenario設定と当日の公式説明を基準にします。

Outputを後続Moduleで壊さないための契約

文章の自由度が高いまま後続処理へ渡すと、表記ゆれや欠落でRouterが期待どおりに動きません。後工程が必要とする値だけを指定し、出力が契約に合わない場合は外部Actionへ進ませない設計にします。

分類結果の例

• category: billing / access / bug / other のいずれか

• summary: 原文に沿った短い説明

• needs_human: true / false

• evidence: 入力中の該当語句または「見つからない」

• unknown_fields: 判定できない項目

このように選択肢、空欄の扱い、根拠欄を決めると、MakeのFilterで許可値だけを通せます。JSON形式を要求しても、形式が整ったことは内容が正しい証明ではありません。分類の根拠と元入力を人が追えるようにしてください。

API keyとデータの境界

OpenAI API keyはMakeのConnection設定へ保管し、プロンプト本文、共有可能なScenario説明、出力先のSheetへ貼りません。入力データも、業務処理に必要な列だけを渡します。接続を作る人の権限、キーの所属Project、Make Scenarioを編集・実行できる人、実行ログの閲覧権限を分けて点検します。

本番接続前に、テスト用の非機密データを使い、次の順で確認します。まずTriggerが一件だけ発火すること、次にAI出力が許可した項目・値に収まること、最後にDestinationが意図したレコードだけを更新することです。送信や削除など取り消しにくいActionは、最初の検証では無効にするか、下書き・承認待ちへ送ります。