MakeでAIエージェントを構築する方法

Make(旧Integromat)は、3,000以上のアプリ連携を備えたビジュアルなワークフロー自動化プラットフォームで、既存のシナリオエンジンの上に、専用のAI Agents機能を追加しました。固定された直線的なシナリオに従うのではなく、Makeのagentはタスクを受け取り、接続されたLLMで推論し、取り付けたツールのうちどれを、どの順番で呼び出して仕事を完了するかを自分で判断します。agentは4つの要素を組み合わせて構築します。頭脳(LLM)、指示(職務記述書のように機能するsystem prompt)、ツール(使用を許可されたモジュール、シナリオ、MCP接続)、そしてメモリ(ステップをまたいで保持するコンテキスト)です。

このガイドでは、Makeが特定のagent構築チームに適している理由、AI Agentsモジュールが実際に何で構成されているか、構築手順の全体像、実際の数字を伴う実際の顧客事例、コストと制限、そして代替ツールよりMakeを選ぶべき場面を解説します。

チームがMakeでエージェントを構築する理由

Makeの中核的な強みは、AI Agents機能よりも前からのものです。競合する多くのプラットフォームよりも多くのSaaSアプリケーションに、標準で接続できます。agentは、実際に到達できるシステムの範囲でしか役に立たないため、この幅広さこそが、agentの強力な土台になります。

連携カタログはこのカテゴリで最も幅広い。 Makeは、最も一般的なSaaSツールについてMakeチームが直接メンテナンスしている3,000以上のアプリ連携を掲載しており、構築済みコネクタのないものには汎用のHTTPモジュールも用意されています。1回の実行で5〜6つの異なる業務システムに触れる必要があるagentにとって、このカタログがあれば、配管作業の大半が不要になります。

AI Agentsレイヤーは、Makeのシナリオエンジンの代わりではなく、その上に載っています。 既存のシナリオを、入出力を手作業で再定義することなく、agentが呼び出せるツールに変換できます。つまり、すでにMakeでプロセスを自動化しているチームは、agentを追加する際にやり直す必要がなく、すでに構築したものを包み込めばよいということです。これは、ワークフローコパイロットパターンで解説している形に近いものです。AIが、既存のプロセスを置き換えるのではなく、その内部で支援します。

エンジニアだけでなく、ビジネスチーム向けに作られています。 Makeのビジュアルなキャンバス、モジュールライブラリ、エラー処理のルートは、開発者だけでなく、オペレーションやRevOpsの担当者が設定できるよう設計されています。非技術系のチームが最初に手に取るagent構築ツールになることが多いのは、そのためです。

Makeは現在、プロセスインテリジェンスの企業であるCelonisの一部です。Celonisは自社のワークフローをMakeのAI Agents機能で稼働させており、このプラットフォームがデモだけでなく、実際の本番の自動化に使われていることを示しています。

MakeのAI Agentsモジュールの構成要素

通常のMakeのシナリオとの実質的な違いは、制御にあります。シナリオは毎回、同じ固定の順序で実行されます。AI agentは判断します。各ステップで、現在の状況にどのツールが合うかを選びます。フローチャートというより、AIエージェントはどのように推論するかで解説している、推論、行動、観察のループに近いものです。モジュールをツールとして設定すると、Makeは裏側でそのためのシナリオを自動的に作成するため、生のAPIを配線するときのように、入出力を手作業で定義する必要はありません。

この柔軟性こそが、固定のシナリオよりもここで役割とルールの構成要素がより重要になる理由でもあります。硬直したワークフローは、外れるべきスクリプトがないため、脱線できません。system promptが曖昧なagentは、脱線します。

構築手順

1. instructionsでagentの職務を定義する。 役割とルールの構成要素と同じように扱います。何を担当するかを1文で、決してしてはいけないことを常時有効なルールの短いリストで書きます。
2. 頭脳を接続する。 まずはMakeの組み込みAIプロバイダーを使います。特定のモデルが必要な場合や、利用料を自分のアカウントに直接請求したい場合は、有料プランで自分のOpenAI、Anthropic、Googleのアカウントを接続します。
3. agentのツールを構築する。 既存のMakeモジュールを直接ツールとして追加するか、すでに構築したシナリオを、agentがひとつの単位として呼び出せるように包みます。各ツールには、明確で具体的な説明が必要です。agentは、ツールが内部で実際に行っていることではなく、ツールが何をするかとして伝えられた内容に基づいて選択します。
4. メモリを設定する。 単一の実行内でagentに記憶させるべきことと、別々の実行をまたいで記憶させるべきことを決め、それに応じて設定します。業務に必要な以上の永続メモリを与えないでください。
5. 重要な処理にはヒューマンインザループのチェックポイントを追加する。 レビューすべき出力(承認、支払い、外部へのコミュニケーション)は、本番反映の前に人間のステップを経由させ、最もリスクの高いステップでagentを監督なしに動かさないようにします。
6. 架空のものではなく、実際の過去の入力でテストする。 本番のトリガーをオンにする前に、agentがどのツールを選ぶかを観察します。
7. トリガーをオンにして、初期の実行を注意深くモニタリングする。 誤ったツールを選んだり、捕捉してほしかったケースを見逃したりした箇所では、instructionsを調整します。

構築の流れは、スコープとモデルの選択から、ツール、メモリ、人間のチェックポイント、過去事例でのテストへと進みます。

実際の事例：CelonisがMakeで経費監査エージェントを構築した方法

仮定の話ではなく、ここでは文書化された本番の事例を紹介します。Celonisは、従業員の経費報告書を、1件ずつ人間が確認することなく監査する必要がありました。そこでチームは、Makeでヒューマンインザループのagentを構築しました。

1. 従業員がWorkdayで経費報告書を提出すると、Makeへのwebhookが発火します。
2. Makeはmonday.comに構造化されたアイテムを作成し、チームが処理中のすべての報告書を一元的に確認できるようにします。
3. agentが最初のポリシーチェックを実行します。金額、日付、支出上限、カテゴリのルールです。
4. より深い判断が必要なものは、GoogleのVertex AI(Gemini)に送られ、領収書を読み取って社内ポリシーに照らして評価されます。
5. Makeは通貨の検証などの補足チェックを実行し、結果を振り分けます。チェックを通過した報告書はWorkdayで自動的に次へ進み、フラグが付いたものはmonday.comのレビューキューに移され、チームが従業員に返信できるテンプレート化された回答が用意されます。

Celonis自身が公表している数字によると、その成果は監査コストの99.7%削減です。年間数万ドルだったコストが、Vertex AIの利用料として年間約150ドルにまで下がりました。処理量は1ドルあたり約1,000件のドキュメントで、慎重なコンテキストエンジニアリングと、60〜70日間の並行テスト期間を経て、チームが全量を任せるまでに、ほぼ100%の精度を達成しています。この並行稼働の規律は、AIエージェントの構築方法が推奨していることと同じです。agentに実際の権限を与える前に、実際の過去のケースに対してテストします。また、ゼロからではなくテンプレートから似たものを構築する場合は、AI経費承認エージェントのブループリントに、同じ機能の完全なルールとガードレールが記載されています。

コストと制限

Make自身の料金は「オペレーション」で決まり、おおむねシナリオ内のモジュール実行1回につき1オペレーションで、プランのティアごとに価格が設定されています。AI Agents機能は、Make独自のAIプロバイダーを使う場合はすべてのプランで利用でき、カスタムプロバイダー接続(自分のOpenAIまたはAnthropicアカウントの持ち込み)は有料ティアで利用できます。この2つ目の選択肢は、ボリュームが大きくなるほど重要です。頻度の高いagent呼び出しを、Make組み込みのプロバイダーではなく自分のモデルアカウント経由にすることが、利用が増えるにつれて支出を予測しやすく管理する方法になることが多く、決める前にAIのTCOで十分に理解しておく価値があります。

主な制約はモデルではなく、シナリオの複雑さです。ツールと分岐ロジックが多いagentでは、各分岐が存在する理由を誰も文書化しないと、数か月後にMakeのキャンバスが、監査が本当に難しいものになりかねません。エラー処理のルートを意図的に組み込み、これはあらゆるワークフローに必要な規律です。すべてのツール接続を権限の付与として扱ってください。同じ実行の中でCRMと請求システムの両方に書き込み権限を持つagentは、instructionsが誤っていた場合の影響範囲が広くなります。これは、AIエージェントのセキュリティで解説している、ツールへの過剰な権限付与のリスクと同じです。

Makeと代替ツールの選び方

Makeの率直な強みは、連携の幅広さと、非エンジニアにとって緩やかな学習曲線の組み合わせです。率直な制約は、AI Agentsレイヤーが、その土台であるワークフローエンジンよりも新しいことです。そのため、最も負荷の高い複数ステップの推論タスクでは、agentのロジックがビジュアルなキャンバスで快適に表現できる範囲を超えると、よりコード寄りのプラットフォームを選ぶチームもあります。承認ワークフロー、データ入力agent、Celonisが構築したようなポリシーチェックagentなど、ほとんどのオペレーション向けagentでは、Makeの幅広さと親しみやすさの組み合わせが、選ばれる理由です。

Key Facts

• MakeのAI Agents機能は、3,000以上の連携を持つ既存のシナリオエンジンの上に、頭脳(LLM)、指示、ツール、メモリを重ね、agentが固定の順序に従うのではなく、どのツールを呼び出すかを選べるようにします。
• MakeはCelonisの一部であり、Celonis自身のチームがMake AI Agentsを使って、経費報告書の監査コストを99.7%削減しました。年間数万ドルから、モデル利用料として年間約150ドルになりました。
• どのプランでもMakeの組み込みAIプロバイダーを使えます。有料プランでは、自分のOpenAI、Anthropic、Googleのアカウントを接続できます。
• 既存のMakeシナリオは、そのままagentのツールとして包めるため、すでに自動化したものを作り直す必要はありません。
• 主な運用上のリスクは、モデルそのもののコストではなく、シナリオの複雑さとツールへの過剰な権限付与です。

次のステップ

業務が多くのSaaSツールにまたがり、チームがビジュアルに設定したい場合、Makeは最も有力な選択肢です。セルフホスティングで、ロジックをより手作業で制御したい場合は、n8nでAIエージェントを構築する方法をご覧ください。ほぼセットアップなしで最初のagentへ最短で到達したい場合は、LindyでAIエージェントを構築する方法をご覧ください。構築の前にMakeを他のツールと比較する際の次の参考として、自動化ツールのまとめと、ベストno-code自動化ツールガイドも役立ちます。