BudaとMake AI Agents：業務シナリオを作るか、継続するAgentの作業環境を持つか
入力・ツール・失敗時の確認と引き継ぎから、運用に合う方法を選びます。
顧客の問い合わせに、整っていない要件表が添付されています。製品を特定し、資料を探し、不足条件を確認して返信案を作る必要があります。固定項目はマッピングできますが、曖昧な要求には判断が必要です。見積もりの送信は人が確認します。
MakeはScenario BuilderにAgentを配置し、トリガーやデータ連携の中でツール選択と知識利用を行います。Budaはファイル、Browser、Terminalと成果の修正を一つの作業環境にまとめます。選ぶ基準は、システム間の流れを保守したいのか、開いて修正できる成果物を管理したいのかです。
仕事を三つに分ける
Makeの新Agent入門は、固定ルールの同期や更新には標準scenario、翻訳・要約など入力出力が決まる処理にはAI app、変動する判断やツール選択にはAgent入りscenarioを勧めています。
ルールで答えが決まる処理にAgentを追加すると、不確実性も増えます。逆に、不完全な問い合わせを無数の固定分岐で扱うのも無理があります。
Make AI Agent (New)は2026年2月2日公開の新バージョンです。確認時点でもopen betaと記載され、機能と価格は変わる可能性があります。
Makeで問い合わせを処理する設計
まず草稿だけを作る問い合わせ処理を組みます。顧客への送信や正式な見積もり更新は行いません。
まずトリガーを決めます。メール、Chat、フォーム、webhook、mailhookに加え、予定に基づく自主実行も説明されています。
次に今回のinputとfilesを、knowledgeから分けます。顧客文面と添付は毎回変わり、製品資料、FAQ、社内方針は参照知識です。MakeはknowledgeをAgentのmemoryに保存するファイルと説明しており、「記憶がない」とは言えません。
toolsにはmodules、scenarios、MCP server tools、他のagentsを使えます。既存の製品検索scenarioを利用する前に、入力、戻り値、書き込み権限を確認します。
出力は製品分類、根拠、不足項目、返信草稿などに固定し、社内確認先にマッピングします。「顧客をうまく対応して」だけでは検証できません。接続、フィールド変更、空の検索結果を誰が保守するかも決めます。
Makeにも可視化とデバッグがある
新アプリの説明では、Scenario Builder内で構築、実行、テスト、デバッグできます。アニメーションは思考状態、時間、ツール順序を示し、Reasoningパネルは判断の説明を提供します。
Makeをブラックボックスと描く比較は不正確です。Makeはscenarioと呼び出しを軸に、Budaはファイル、ウェブ、コマンド、コード成果を軸に確認を整理します。
Reasoningの説明は正しさの独立した証拠ではありません。選んだツールが正しくても古い資料を使うことがあり、成功した実行でも要件を落とすことがあります。
Budaでは修正できる作業資料を残す
Agent Workspaceでは、チャット、Files、Terminal、AI Browser、Web Preview、Gitが同じクラウドコンピューターを表示します。
顧客原文、承認済み資料、禁止する約束、出力条件を入力にします。Agentは添付を整理し、許可した公開資料の調査やスクリプト処理を行い、要件表、出典一覧、返信草稿を作ります。
責任者は実ファイルと中間成果を確認して修正を依頼します。ファイルが存在しても外部操作の権限は得られません。メールやCRM接続は別に設定と検証が必要です。
Driveと記憶では個別AgentとSpaceの共有資料を区別します。引き継ぎ時は共有する資料と受け入れた版を指定し、全Agentが自動的に文脈を知ると考えないでください。
保守するものを比較する
| 確認点 | Make AI Agents | Buda |
|---|---|---|
| 入力 | triggerとマッピング | タスク、Drive、設定した接続 |
| 参照・操作 | knowledge、modules、scenarios、MCP | ファイル、Browser、スクリプト、許可したtools |
| 失敗の確認 | ステップ、呼び出し、入出力、Reasoning | ファイル、コマンド、ウェブ、成果 |
| 引き継ぎ | scenario、接続、契約、テスト入力 | 作業フォルダ、指示、版、基準 |
| 返却 | 後続moduleと権限 | 承認ファイルまたは検証した接続 |
イベントを複数システムへ渡し、その途中で判断する仕事はMakeで始めるのが自然です。既存のMakeユーザーがすべてを移す必要はありません。
調査、ファイル、スクリプト、何度もの修正が中心で、責任者が成果を開いて継続したいならBudaを試す価値があります。効率の実測順位ではなく、運用方法の違いです。
失敗する入力で試す
製品番号なし、本文と添付の矛盾、ツールの結果なしを用意します。両方で不足を明示し、推測で埋めず、人の判断用草稿を残すよう依頼します。
資料の版、欠落、失敗したツール、再実行時の重複書き込み、別担当者による継続、受け入れた版を記録します。設定、手戻り、確認、引き継ぎの時間を測り、速さや費用を先に決めません。Make Credits、モデル費用、Buda Creditsは別の単位です。
同期と成果制作を分けて導入する
固定同期は既存Makeに残し、研究や修正を伴う成果はBudaで準備できます。形式、レコードID、資料の版、書き戻し担当、許可操作を決めます。
まずファイルの引き渡しから始め、両側に必要な接続とツールを個別に設定します。両方で同じ顧客記録を同時更新しないようにします。
Budaでは匿名化した入力から確認用資料を作り、反復手順をSkillにまとめます。Buda AIのMarketplaceで適切なSkillを検索してインストールすることもできます。別担当者が継続できてから予定実行へ広げます。
構築時につまずく三つの点
指示を書いたのにCRMを検索できないのは？
検索するmoduleやscenarioがtoolとして登録され、接続アカウントが対象レコードを読めるか確認します。同じ顧客IDでtool単体を実行し、返るフィールドを調べてからAgentへ渡します。instructionsは依頼を定義するもので、接続や権限を作るものではありません。
既存scenarioをAgentのtoolにするには？
「販売を処理する」ではなく「製品番号で在庫を検索する」のように一つの動作に絞ります。必須入力、戻り値、結果なしの応答を定義して単体テストします。検索と送信・書き込みを分け、草稿試行では副作用を開放しません。scenarioを使えることと、正しく使える契約は別です。
不足情報の推測や再実行時の二重送信を防ぐには？
不足項目と要確認項目を出力に残し、製品番号なしなら見積もりではなく草稿を返します。送信と正式な書き込みは別のステップにし、人の受け入れ後に実行します。レコードIDと処理済み確認を用意し、番号なし、矛盾する添付、検索結果なしの三例で確認位置に停止するか試します。