【2026年9月版】 Make.com（AIエージェント）料金・無料範囲・クレジットの数え方と最適プランの決め方

まず結論：AIエージェント運用のコストは「クレジット×トークン」で決まる。最初はFree/10,000クレジットで実測し、モデルと設計で最適化を

確認日：2026年8月22日。MakeのAIエージェント（Make AI Agent［New］）は、通常の自動化操作に加え、LLMのトークン消費がクレジットに連動します。費用は「操作（1操作=1クレジット）＋トークン換算（モデル別・更新あり）」の合算で決まるため、まずは無料枠/小さめのクレジットで実測→設計改善→必要量に応じてプラン調整が安全策です。カスタムAIプロバイダ（OpenAI/Anthropic等）を使うと、Make側は操作分のみを消費し、トークン費用は各プロバイダに直接支払う方式を選べます。

最初の30日での安全な進め方（推奨フロー）

• Week 1：FreeプランでPoC用の最小シナリオを構築し、1日あたりの実行数・平均処理秒数・トークン量を計測
• Week 2：プロンプト短縮・ナレッジ分割・軽量モデル検証でトークン最適化。ルーター/エラーハンドラ設計を見直し
• Week 3：想定ピーク負荷で負荷試験。Credit usageの「実行別」明細をエクスポートして単価ドライバ（操作/トークン/コード秒）を特定
• Week 4：10,000クレジット/月に上げて実運用に近い条件で再計測。通知（75/90/100%）の配布先とPrivate spacesの上限をセット

Makeとは何か：ビジュアル自動化にAIの意思決定を統合

Makeは、ドラッグ&ドロップのビジュアルUIでワークフロー（シナリオ）を構築する自動化プラットフォームです。新しいMake AI Agent（オープンβ、2026年2月2日公開）は、意思決定（LLM）とアクション（SaaS・データ連携）を同一キャンバスで実行可能にします。エージェントの思考過程（Reasoning）やツール呼び出し、使用トークン量の可視化ができ、社内ユースケースに合わせてツール・ナレッジ・ガードレール（Agent Firewall）を組み合わせられます。

AIエージェントはMakeの全プランでMakeのAI Providerを利用でき、有料プランではOpenAIやAnthropic等のカスタムAIプロバイダ接続も選べます。どちらを選ぶかで、トークン費用の支払い先と統合運用のしやすさが変わります（詳細は本稿「AI Provider別の課金挙動」参照）。

どんな人・組織に向くか／向かないか

向いている読者像

• 事業会社で業務自動化や生成AI活用を担う企画・情シス・事業部PM
• マーケ/CS/営業Opsのリーダーや自動化担当（分岐・例外処理を伴う業務）
• ノーコード/ローコードでAIエージェントを作りたい個人事業主・中小企業
• 日本企業案件を扱う自動化コンサル/開発パートナー

向かないケース

• 完全オンプレミスでプラットフォーム自体を閉じたい（Makeはクラウド提供）
• 日本語UI・日本語公式サポートが必須（現状は英語UI中心）
• 厳密な固定従量単価でコスト確定が必要（LLMトークン連動で変動）
• セルフホスト前提のOSS志向（例：n8n自社ホスティング）

できることと適否：代表ユースケース

Make AI Agentは、以下のような業務で効果が出やすい一方、センシティブな最終判断が必要な領域は適用を慎重にすべきです。

• CS：サポートチケットの自動トリアージ、一次回答、エスカレーション判断
• 営業：リード調査、要約、候補者とのメール/日程調整、CRM更新
• マーケ：コンテンツ作成支援、SEO下書き、マケットリサーチ要約
• 人事：採用候補者のスクリーニング、面接日程の自動調整

適用が難しい領域：法的拘束のある承認、コンプライアンス違反リスクが大きい決定、誤回答が重大損害につながる判断などは人間の確認を挟む設計が推奨です。

ユースケース別の成功条件（例）

• CSトリアージ：ナレッジの最新版維持（更新時の埋め込みコストを織り込む）、分類結果に応じた確度しきい値と人手レビュー経路
• 営業メール作成：軽量モデルで下書き、高性能モデルで文面仕上げの二段構え、CRM更新のトランザクション設計（失敗時のリトライ）
• マーケットリサーチ要約：収集データの重複除去→要約プロンプトの出力フォーマット固定（JSON等）→BI連携
• 採用スクリーニング：評価基準の明文化（出力スキーマ化）とバイアス対策（Agent Firewallと要件定義）

導入の実際：最初のAIエージェントを作る手順

1. 計画：目的・KPI・許容リスクを定義。どのデータを使い、どのツールを呼ぶかを棚卸し。想定トリガー頻度（例：時間/Webhook/手動）とピーク時の同時実行を見積もる。
2. シナリオ作成：ビジュアルキャンバスでトリガーと各モジュールを配置。分岐やエラーハンドラも設計。ルーターやRollback/Break/Resume/Commit/Ignoreなどの例外モジュールはクレジット対象外なので、制御フローに積極活用。
3. エージェント設定：モデル選択、システム指示（プロンプト）を定義。Reasoningパネルで思考過程を可視化し、余計な思考や冗長出力が起きていないか確認。チャット実行は1入力=1クレジット（必要に応じツール/トークン分が加算）。
4. ツール追加：メール/CRM/カレンダー/DBなどの連携を接続。MCP Server経由の外部ツール拡張も可能。副作用のある操作（削除/更新）はルールベースで最終確認（人手）を挟む。
5. ナレッジ追加：製品マニュアルやFAQなどをRAG用にアップロード（埋め込み時にトークン計上）。MakeのAI Provider利用時はファイル説明生成のトークンも課金対象。ファイルは章/FAQ単位に分割し、メタデータ（バージョン/日付/カテゴリ）を付与して更新コストの肥大化を防ぐ。
6. テスト：少量データで試行。Credit usage画面と実行履歴でクレジット/トークン/実行時間を検証。性能・コストのしきい値（例：1件あたりのクレジット上限）を定め、逸脱時の停止/通知ルールを決める。

オンプレ資産（例：SAP）や社内ネットワークへの到達が必要な場合は、On-prem agentの併用でセキュアな経路を構成できます（可用性・条件は公式情報を要確認）。

料金と無料枠の現在地（確認日：2026年8月22日）

2025年8月27日以降、Makeの課金単位はクレジットに統一。多くの通常モジュールは「1操作=1クレジット」で計上されます。AI関連はトークン等に連動する動的消費が追加されます。

Freeプランの主な条件

• 月1,000クレジット
• 同時アクティブシナリオ2本
• 実行最短間隔15分
• 1実行あたり最大5分（有料は最大40分）
• データ転送512MB
• 実行ログ保存7日

有料プラン（Core/Pro/Teams）は、価格が10,000クレジット/月選択時の月額例で、Core $12、Pro $21、Teams $38（いずれもUSD・税込表記のない価格、月払い時）。
データ転送・保存などのUsage allowanceは購入クレジットに比例し、10,000クレジットあたりの目安は以下です。

• データ転送 5GB
• データ保存 10MB
• 未完了実行 10MB
• Webhookキュー 667件

データストアは1組織あたり最大1,000個まで利用可能（プラン非依存）。支払方法はクレジット/デビットカード、ACH、Apple Pay/Google Pay/Amazon Pay/Cash App Pay等に対応（Core/Pro/Teams向け）。

プランの“実務差”と選び方

• Free：PoCや低頻度運用に限定。最短間隔15分と5分上限があるため、待ち時間/タイムアウトが品質KPIに影響しやすい。
• Core/Pro：最大実行40分が共通。コードや外部API待ちが発生する実務でも現実的。購入クレジットに合わせてUsage allowanceが線形拡張するため、スループット設計がしやすい。
• Teams：部門横断の運用で、Private spacesによるクレジット上限設定や権限整理を前提にした運用ルールを作りやすい。
• Enterprise：統制・監査・接続要件（オンプレ到達など）が主眼。個別見積・機能の差は最新の料金ページと担当者ヒアリングで確認。

プラン	月額例（10,000クレジット）	主な枠/上限	備考
Free	$0	1,000クレジット/月、同時2本、最短15分、最大5分実行、転送512MB、ログ7日	本番・高頻度には非推奨
Core	$12	購入クレジットに比例（10,000毎に転送5GB 等）	最大実行時間は40分（有料共通）
Pro	$21	同上	AI/分岐が多い部門利用に
Teams	$38	同上	複数部門・権限管理に適合

注意：具体的な同時実行数や間隔の詳細は変更される可能性があるため、最新の料金ページで要確認。Enterpriseは個別見積の要素が多く、統制・セキュリティ・管理機能が重視されます。

クレジットの数え方・見積り方（固定/動的・例外モジュール）

• 固定（多くの通常モジュール）：1操作=1クレジット
• 動的（AI/ファイル等）：モデルの入力/出力トークン、ページ数、ファイルサイズ、実行時間などに連動
• 例外：ルーターやエラーハンドラ（Rollback/Break/Resume/Commit/Ignore）はクレジット対象外
• Make Code App（JS/Python）：実行時間1秒あたり2クレジット
• AIエージェントのチャット実行：チャット入力1回=1クレジット＋必要に応じてツール/トークン分
• Knowledgeアップロード：埋め込み（ベクタ化）トークンが発生。MakeのAI Provider利用時はファイル説明生成のトークンも計上

ざっくり見積りの式

月間クレジット ≒（通常操作回数×1）＋（AI推論回数×1）＋（入力トークン×レート）＋（出力トークン×レート）＋（知識埋め込みトークン×レート）＋（コード実行秒数×2）＋（ファイル/ページ要素の動的分）

レート（トークン→クレジット換算）はモデル別に定義され、変更され得ます。実際は、パイロット運用での実測値（Credit usage・実行履歴・Reasoningパネルのトークン量）を母集団に外挿するのが最も安全です。

見積りワークシートの作り方（例）

• シナリオ内の「確定操作」を棚卸し（例：Gmail取得→パース→CRM更新→Slack通知＝4操作/ケース）
• AI推論の発火回数を特定（例：分類1回＋返信草案1回＝2回/ケース）。各回の平均入力/出力トークンはPoCで実測し、中央値と95パーセンタイルを記録
• Knowledgeの更新頻度と1回あたりのファイル数・ページ数を洗い出し、月間の埋め込みトークンを別枠で合算
• Code Appの平均実行秒数（成功/失敗別）を測り、月間総秒数×2クレジットで算入
• ピーク時の同時実行に対するWebhookキューの余裕（10,000クレジットあたり約667件目安）を確認

AI Provider別の課金挙動：MakeのAI Provider vs カスタム接続

利用方式	Make側のクレジット消費	トークン費用の行き先	向くケース
MakeのAI Provider	操作1回=1クレジット＋モデルのトークン等に応じ加算	Makeのクレジットとして計上	請求をMakeに集約したい、モデル比較をMake内で簡便に行いたい
カスタムAIプロバイダ接続（OpenAI/Anthropic等）	操作分のみ（1操作=1クレジット等）	各プロバイダに直接支払い	既存のベンダー契約がある、モデル単価を直接管理したい

判断基準の例

• コスト管理：一元管理を優先→MakeのAI Provider。既存の割引/上限/利用規約を生かす→カスタム接続。
• データポリシー：各モデルのデータ保持/学習利用の取り扱いをベンダー側で直接管理したい→カスタム接続が適する場面が多い。
• 可観測性：どちらもCredit usageで実行別に分析可能。Reasoningで思考・ツール呼び出しの可視化は共通。

コスト可視化と上振れ対策

• 可視化ポイント：ダッシュボード、Subscription、Credit usage、シナリオ履歴/ビルダーで追跡。75%/90%/100%で通知
• 停止挙動：クレジット不足時はシナリオ停止。Webhookはキュー上限（購入クレジットに比例、10,000あたり667件）まで待機
• ガバナンス：Private spacesでメンバーごとに上限クレジットを設定可能（Enterpriseは閲覧権限拡張）。部門予算管理に有効
• 設計面の節約：短いプロンプト、適切なコンテキスト長、軽量モデルの活用、ナレッジの前処理（抽出/要約）、不要ログの削減
• Extra credits：追加クレジットは当該請求サイクル内のみ有効（年払いは契約年末まで）。2025/11/6以降はプラン単価比で+25%へ調整

運用プロセス例（毎週/毎月）

• 毎週：Credit usageのトップシナリオ上位5件をレビューし、1件あたりのクレジット増減要因（トークン肥大/コード秒数増/外部APIリトライ）を是正
• 月初：前月の75/90/100%通知の発生日・時間帯を確認し、トリガー間隔やバッチ時刻を平準化
• イベント発生時：90%到達で一部シナリオを一時停止に切り替える「節約プリセット」を用意（重要度の低いレポート系など）

モデル/ナレッジ/ツール設計で変わるクレジット最適化パターン

• モデル階層化：下書き/要約は安価モデル、最終文面は高性能モデルで仕上げる二段構え
• プロンプト・制約の明確化：冗長出力を避け、出力形式をJSONなどで短く固定。必要なら「最大語数」「箇条書き上限」を明記
• ナレッジ整備：長大PDFを丸ごと埋め込むのではなく、FAQ単位の分割＋要約で埋め込みコストを抑制。更新は差分のみ再埋め込み
• ツール呼び出し最小化：API呼び出し前に条件分岐で不要実行をスキップ（例：重複レコード検知後に更新を回避）
• Code Appの時間管理：1秒=2クレジットのため、計算/スクレイピングは効率化または外部関数化。タイムアウトと失敗時の早期リターンを徹底

具体例：CS一次回答ボット

• 流れ：Webhook受信→分類（AI）→FAQ検索→草案作成（AI）→担当者レビュー→送信/CRM更新
• 最適化：分類は軽量モデル、草案は最大語数を明記。FAQは質問タイプ別に短文チャンク化し、上位3件のみ参照。
• 効果：1件あたりの入出力トークンを抑制しつつ、操作数（更新/通知）も無駄打ちを削減。

日本語対応の実情と現実解

現時点でプラットフォームUIは英語のみ（コミュニティ公式回答）。日本語UI・日本語公式サポートは確認できないとの独立系解説もあります。運用上は、ブラウザ翻訳や国内の認定パートナーの活用が現実解です。ナレッジやプロンプトは日本語で設計可能ですが、検証時はモデルの日本語性能・用語表記の統一を試験しましょう。

日本語運用のTips

• プロンプトは敬体/常体・表記ゆれ（全角/半角・カタカナ英語）を統一。出力規格をスキーマで固定
• ナレッジは固有名詞・略語のグロッサリーを別ファイルで用意し、優先参照させる
• ログの英語UIは翻訳で十分に追えるが、アラート文面は日本語/英語併記にして運用チーム内の解釈齟齬を防ぐ

メリットとデメリット（βの前提を含む）

メリット

• ビジュアルUIで分岐/例外処理を見通しよく設計
• AIの意思決定からSaaSアクションまで同一キャンバスで完結
• Reasoningやトークン量の可観測性、Agent Firewallなどのガードレール
• カスタムAIプロバイダ接続でコスト/契約を外部に分離可能
• MCP Server連携、On-prem agentでの拡張/到達性

デメリット/留意点

• AI Agent（New）はオープンβであり、機能/価格/換算レートが変わる可能性
• 日本語UI/公式日本語サポートが未整備
• LLMトークンに連動するため、コストの上振れリスクがある
• センシティブな最終判断には不向きで、人手確認が推奨

代替比較：Zapier／n8n／Power Automate

項目	Make	Zapier	n8n	Power Automate（AI Builder）
開発体験	ビジュアルで分岐に強い	簡単さで評価されやすい	高度拡張・コード強い（自ホスト可）	Microsoftエコシステム統合
提供形態	クラウドSaaS	クラウドSaaS	セルフホスト/クラウド	クラウド（Microsoft 365連携）
AI課金の考え方	クレジット統一＋トークン動的	プラットフォーム独自の課金	ホスト/設定に依存	AI Builderクレジット（非互換）
向く組織	分岐/可視化重視、SaaS運用の手軽さ	手早い自動化立ち上げ	OSS志向・厳格なカスタマイズ	Microsoft中心のIT標準化

独立系レビューでは、Makeは分岐と見通し、Zapierは手軽さ、n8nは拡張性/自ホストで評価される棲み分けが示されています。Power AutomateはAI Builderの別体系クレジットで、単位換算が異なる点に注意が必要です。

比較時の意思決定軸

• 運用形態：クラウド前提で早期立ち上げ→Make/Zapier。自社ホスティング要件→n8n。
• 分岐の複雑さ：視覚的に把握したい→Make。シンプルな直列自動化→Zapier。
• エコシステム依存：Microsoftライセンス一体運用→Power Automate（AI Builderはクレジット体系が別）。

よくある落とし穴と回避策

• 無料枠を超えた本番運用：Freeは最短15分/5分制限。頻度/時間要件がある本番は早めに有料へ
• トークン肥大：長文プロンプト・巨大ナレッジ投入で急増。事前要約・必要最小限のコンテキストで抑制
• 実行時間超過：Code Appや外部API遅延で時間課金/失敗。タイムアウト設計と再試行の径路を用意
• ファイルサイズ/ページ数：Knowledge投入時の埋め込みコストに注意。分割＆ノイズ除去
• Extra creditsの失効：月末（年払いは契約年末）で失効。期末駆け込みを避け、運用側の消化計画を作成

運用ガードレール例

• 1件あたりの最大出力長・最大ツール呼び出し回数をプロンプトとシナリオで二重制御
• Credit usageのしきい値超過で、重要度の低いシナリオを「夜間だけ動かす」モードへ切替
• Knowledgeは月次の棚卸しで古い版をアーカイブ化し、ベクタDBの肥大を防ぐ

ユースケース別の最適プラン判断フレーム

• 少量・定型（月間数百操作、低頻度）：Free。PoC/社内評価に適合。トライアル時はWebhookでオンデマンド実行に寄せると消費が安定。
• 日次～分単位の自動化（部門利用）：Core/Pro。10,000クレジットを初期値に、実測で調整。Usage allowanceの線形拡張を見込み、データ転送/キューの上限を計画に反映。
• 複数部門・権限/予算ガバナンス：Teams。Private spacesと通知を併用し、部門ごとの上限設定と週次レビューを標準化。
• 統制・接続要件（オンプレ/ネットワーク/監査）：Enterpriseを検討（要件ヒアリング）。On-prem agentの適合性は事前検証を推奨。

AIエージェント中心の運用では、モデル選定とナレッジ設計がクレジットに最も影響します。まずは軽量モデル＋限定コンテキストで出発し、必要に応じて段階的に拡張するのが定石です。

購入前チェックリスト（実務）

• 目的/KPIと「人手確認を必ず挟む工程」を明文化
• 対象シナリオの1サイクルあたり操作数・推論回数・予想トークン量を試算
• クレジット通知（75/90/100%）の配布先、Private spacesの上限値を設定
• ナレッジの分割・要約・メタデータ設計（埋め込み最適化）
• カスタムAIプロバイダ利用可否（契約/セキュリティ/データ保持）を確認
• 無料枠でのPoC計画と、上振れ時の一時的なExtra credits方針
• ログ保存期間・Webhook待機・最大実行時間などのSLA前提を整合
• リリース計画（パイロット→段階拡大）と回帰テストの観点（モデル/プロンプト変更時の品質計測）を準備

まとめ：β期の前提で「計測→設計→拡張」

MakeのAIエージェントは、意思決定と実行を同じキャンバスで回せるのが大きな利点です。一方で、オープンβのため機能や価格・トークン換算は変動し得ます。Free→10,000クレジットを起点に、Credit usageとReasoningの実測で無駄を特定、モデル/ナレッジ/ツール設計を磨きつつ段階的に拡張する進め方が、コストとリスクに強い導入パスです。導入可否に迷う場合は、国内パートナーの知見や既存のAIプロバイダ契約も併せて検討しましょう。

FAQ

Q1. クレジットは繰り越せますか？

いいえ。請求期間末で失効します。Extra creditsもサイクル末（年払いは契約年末）で期限切れとなります。

Q2. クレジットが尽きたらどうなりますか？

シナリオは停止します。Webhookはキュー上限（購入クレジットに比例、10,000あたり667件の目安）まで待機し、クレジット追加後に再開します。

Q3. AIエージェントのコストを最も左右するのは？

モデル選定と入出力トークン量です。Credit usage/実行履歴/Reasoningで各実行ごとに可視化し、プロンプト短縮・軽量モデル化・ナレッジ前処理で最適化します。

Q4. カスタムAIプロバイダを使うメリットは？

Make側では操作分だけを消費し、トークン費用は各プロバイダに直接支払います。既存契約の単価やデータ保持ポリシーを生かせる点が利点です。

Q5. どの画面でクレジットを監視できますか？

ダッシュボード、Subscription、Credit usage、シナリオ履歴/ビルダーなど複数で追跡できます。75%/90%/100%で通知されます。

Q6. 日本語UIや日本語サポートはありますか？

現時点では英語UIが中心です。日本語UI/公式日本語サポートの正式対応予定は公式の最新発表を確認してください。国内パートナーの活用が現実的です。

Q7. AIエージェントのKnowledge登録は都度課金されますか？

アップロード時の埋め込み（およびMakeのAI Provider利用時のファイル説明生成）に応じてクレジットが計上されます。更新頻度やファイル粒度に注意してください。

Q8. Code Appのコストはどう見ればよいですか？

実行時間1秒あたり2クレジットです。計算量が多い場合はアルゴリズム最適化、外部APIの遅延対策、バッチ化で削減できます。

Q9. 料金やトークン換算レートは固定ですか？

オープンβのため変更され得ます。価格/換算レートの最終仕様やβ終了時期は、現時点で公式の最新情報を確認する必要があります。

Q10. エージェントの安全対策は？

Agent Firewall（OWASP LLM Top 10 2025準拠のガードレール）などのプリセットが公開されています。プロンプト注入対策や権限分離も併用してください。

Q11. ルーターやエラーハンドラはクレジットを消費しますか？

いいえ。ルーターやRollback/Break/Resume/Commit/Ignoreなどのエラーハンドラ系はクレジット対象外です（制御フローの最適化に有効）。

Q12. クレジット不足時のWebhookはどれくらい待機できますか？

Webhookキューは購入クレジットに比例して上限が決まり、目安は10,000クレジットあたり約667件です。余裕を持った設計と早期のクレジット追加が推奨です。

参考情報・出典

• Pricing & Subscription Packages | Make
• Credits（クレジットの仕組み）
• Credit usage for AI agents
• How to track credits
• Introduction to Make AI Agent (New)
• Create your first AI agent
• Make AI Agents app（旧版仕様）
• Upcoming adjustments to plans and pricing
• Extra credits – Help Center
• New payment methods for greater flexibility
• Make AI Agents Library
• Language Settings – Make Community
• Private spaces – Help Center
• Zapier vs. Make comparison: Which is best? [2026]
• n8n vs. Make: Which is best? [2026]
• Make（Integromat） vs Zapier 2026 | Cloudwards
• Make Reviews 2026 | G2
• Make Reviews 2026 | Capterra
• Licensing and AI Builder credits | Microsoft Learn
• Make.comとは？使い方・日本語対応を解説（2026年8月） | AI Creator Path

補足：本稿は上記の公式ドキュメントと独立系レビューに基づいており、β版の仕様・価格・換算レートや各プランの詳細は将来変更される可能性があります。導入時は必ず公式ページの最新情報をご確認ください。