Make AI AgentへScenarioをtoolとして追加したのに結果が回答へ入らないときは、toolの選択、受け取った入力、Scenarioの処理、返す出力を分けて確認します。Scenario内で検索や取得が成功していても、その結果をagentへ返す設定がなければ、回答に使えるとは限りません。
この記事は、Make AI Agent (New)がScenarioを呼び、その結果を受け取る経路の確認手順です。Makeの作成・実行、接続、検索、外部更新は行っていません。後半の注文検索と出力項目は独自の架空例で、Makeの予約された出力形式ではありません。
目次
最初に、選択・処理・返却のどこで止まるかを見る
表は横にスクロールできます
| 観察した状態 | 最初の確認先 | まだ判断しないこと |
|---|---|---|
| toolが選ばれていない | toolの説明と今回の依頼 | Scenarioの処理失敗 |
| toolは呼ばれたが対象が違う | mappingされた入力値 | AI modelを変えれば直る |
| Scenarioは処理したが結果がない | outputs、Return output、待機設定 | 検索先にデータが存在しない |
| 結果は返ったが回答が違う | 返却項目、Instructions、根拠 | 入出力全体が正常 |
まず一つのtoolと一つの架空入力に絞ります。tool名だけでなく、何を受け取り、何を返すかを短く説明できる状態にします。使用しないtoolを同時に増やすより、対象の往復を確認してから広げます。
呼ばれるScenarioの入出力を定義する
MakeのScenario inputs and outputsは、別ScenarioやAIシステムと交換するデータを定義する機能です。公式は、呼ぶ側のCall a scenario、呼ばれる側のStart scenarioとReturn outputを説明しています。inputsは受け取る情報、outputsは返す情報として分けます。Make：Scenario inputs and outputs（新しいタブで開く）
例えば、注文番号を受け取って該当レコードを探す読み取り専用toolなら、入力は検索に必要な識別子、出力は見つかったかどうかと確認先に絞れます。顧客の全履歴や接続情報を、便利だからという理由だけで返しません。
入出力の名前と説明は、agentが渡す値と受け取る意味を理解するための情報になります。入力をdata、出力をresultとだけ書くより、どの番号をどの形式で受け取るか、見つからない場合に何を返すかを明示します。型も、文字列、数値、配列など実データに合わせて決めます。
Scenarioをtoolとして追加し、戻り値を対応づける
公式の作成ガイドは、Add toolからScenarios > Call a scenarioを選び、既存Scenarioを指定するか、新規に作る経路を案内しています。説明には、そのScenarioが何をするか、いつ使うかを書きます。結果をagentへ返す場合、呼ばれるScenarioをReturn outputで終える必要があると説明されています。Make：Create your first AI agent（新しいタブで開く）
Return outputでは、定義した出力項目へ実際の処理結果をmappingします。outputsの欄を作っただけで、その値も入ったとは考えません。途中の検索moduleの出力と、Return outputに設定した値が対応しているかを確認します。
呼び出し側のWait for the scenario to finishは、終了や返却を待ってから続けたい場合、公式手順に沿ってYesを選びます。呼ばれるScenarioのOn demand設定と有効化も、公式の作成手順と照合します。これらを確認したことだけで、外部サービスの検索結果や回答内容まで正しいとは判定しません。
架空の検索toolで、見つからない場合も返す
説明用に、入力order_numberを受け取るtoolを考えます。接続先の権限は受信側で確認し、agentが渡した注文番号だけで他人の注文を読める設計にはしません。ここでは検索の実装や接続を行わず、返す項目の案だけを示します。
出力はすべて文字列とし、次の契約を例にします。
- lookup_status：FOUND、NOT_FOUND、NEEDS_REVIEWのいずれか。
- record_id：FOUNDなら確認できたレコードのID。それ以外は空文字。
- reason：検索結果や確認が必要な理由。未確認の原因を断定しない。
{
"lookup_status": "FOUND",
"record_id": "order-R01",
"reason": "対象条件に一致するレコードを一件確認"
}
{
"lookup_status": "NOT_FOUND",
"record_id": "",
"reason": "今回の検索条件では一致するレコードなし"
}
{
"lookup_status": "NEEDS_REVIEW",
"record_id": "",
"reason": "候補が複数あり、対象を一件に確定できない"
}
これはMakeが自動で返す標準JSONではありません。Scenario inputs and outputsで定義する名前と型に合わせ、Return outputへ結果をmappingするための説明例です。agentの最終回答形式とも別です。
NOT_FOUNDは「今回の条件で見つからない」という意味に限定します。検索権限不足や取得失敗を、データが存在しないという結果へ隠しません。エラー時には、実際のerror経路と返す契約を設計し、成功結果の空欄へ置き換えないようにします。
一入力で、返却された値まで追う
確認では、次の順に値を対応づけます。
- 呼ぶ側が今回のtoolを選んだか。
- 注文番号などの入力が想定した値に解決されたか。
- 呼ばれるScenarioが、その値を使って処理したか。
- 処理結果がReturn outputの各項目へ入ったか。
- 呼ぶ側がその結果を受け取り、回答の根拠にしたか。
agentのmodule outputにはResponseと実行のMetadataがあり、Reasoningの画面でも入力やtoolの利用経路を確認できます。最終回答だけでなく、実行時にどのtoolと値を使ったかを見るための入口として使います。Make：AI Agent (New) app（新しいタブで開く）
結果が返っているのに回答が誤る場合は、出力の意味とInstructionsを確認します。例えばNEEDS_REVIEWなのに「注文が確定した」と回答していれば、検索自体の成功だけでは完了しません。agentへ、未確定の結果を断定せず、確認が必要な点を返すように指示します。
空の結果と、処理が戻らない状態を分ける
対象が見つからない場合に、どの経路でReturn outputへ進むかも確認します。処理の途中で止まった状態と、見つからないという結果を返した状態を同じ空欄にしないようにします。RouterやFilterがある場合は、想定した入力がどの経路を通るかを図や実行記録で確認します。
また、Scenario内で外部更新まで行ってから返却に失敗した場合、呼び直せば未実行部分だけが動くとは限りません。まず接続先の状態を照合し、同じ更新や通知を重ねない方法を判断します。再試行の問題は、出力mappingの修正とは分けて扱います。
初回の確認は、外部送信・更新を含めない読み取り専用の例から始めます。入力が不足、該当なし、候補が複数、取得エラーの場合も、正しいレコードを見つけた場合とは別の結果として確認します。
入出力を変更したら、呼ぶ側も確認する
項目名や型を変えたら、呼ぶ側が以前の出力を期待していないかを確認します。Scenarioの途中で値が取れたことだけを報告せず、返した項目、呼ぶ側が受け取った値、最終回答を対応づけて記録します。
確認記録には、agentとScenarioの識別、入力、出力の版、toolの説明、待機設定、返却された結果、未確認の経路を残します。接続情報や顧客本文を丸ごと共有する必要はありません。機密を除いた再現入力で、どの境界で期待と違ったかを説明できる形にします。
Make AI Agentの基本構成はMakeでAI自動化を始める手順で確認できます。Scenarioをtoolにする場合は、処理を作った後に、agentへ結果が戻るところまでを一つの確認範囲にしてください。
参考資料
- Make：Scenario inputs and outputs（新しいタブで開く）
- Make：Create your first AI agent（新しいタブで開く）
- Make：AI Agent (New) app（新しいタブで開く）
公式資料の確認日：2026年10月21日。注文検索とJSON三例、確認順は独自の設計例です。ローカルでJSONの構文、項目、状態とrecord_idの整合を検査しました。Make実行、実際のtool選択・返却、外部検索、エラー経路、更新、料金は未検証です。