ソリューションハンドブック
Makeによる契約受付レビューループの計画ガイドです。設定、Jodooフィールド、検証レコード、展開時の注意点を含みます。
ハンドブックを開くMAKE + JODOO
MakeとJodooを使って契約受付レビューを実行し、リスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況を返し、その結果を追跡可能なJodooレコードに保存します。
動画ウォークスルー
この動画では、Northstar Logistics MSA renewalが、金額、部門、目標署名日、不足している保険情報、更新の背景情報とともにワークフローに入り、その後Jodooに運用レコードとして保存される流れを紹介しています。
Northstar Logistics MSA renewalが、金額、部門、目標署名日、不足している保険情報、更新の背景情報とともにワークフローに入ります。
このワークフローでは、曖昧な文章を返すのではなく、リスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況を明確なフィールドとして保持します。
テスト済みの実行では、レビュー結果がJodooに送信され、ブリッジからJodoo data IDを受け取ります。
公開用の検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットでシナリオ履歴内のwebhook bundle、モジュールバブル、オペレーション数、HTTPレスポンスを確認できます。
Jodooアプリには、契約名、取引先、契約種類、申請部門、契約金額、目標署名日、不足情報が保存され、レビューとフォローアップに活用されます。
デモ概要
この実装は、シナリオキャンバスの可視性、Run onceでのテスト、モジュール履歴を重視するオペレーションチームに適しています。このページでは、視覚的なシナリオ設定、実際の実行、Jodooへの書き戻しをすべて確認できます。HTTPモジュールの証跡も視覚的で、メソッド、エンドポイント、ボディタイプ、解析済みレスポンス、完了ステータスをコードエディタを開かずに確認できます。
Make Custom webhookがサンプルペイロードを受信し、HTTPモジュールが構造化フィールドをJodooに送信します。
このワークフローは、Northstar Logistics MSA renewalに対して、リスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況を返します。
Makeの実行履歴には、HTTPモジュールの完了、実行の詳細、Jodoo data IDのレスポンスが表示されます。
まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。
契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。
Jodooは契約受付レコードを保存し、次のアクションを可視化します。
推奨される次のアクションは、法務と財務に振り分ける前に、不足している保険証明書とデータ処理確認を依頼することです。
活用キットには、ハンドブック、Jodooフィールド設計図、Makeワークフローレシピが含まれます。
プラットフォーム設定メモ
Jodooのレコードモデルは一貫して保てますが、各エージェントプラットフォームでは構築スタイル、テスト画面、本番への引き継ぎ方法が異なります。
この検証ではRun onceを使用しているため、受信したbundleとHTTPレスポンスを確認できます。
HTTPモジュールでは、メソッド、URL、ボディタイプ、レスポンス解析を確認可能な状態で保持できます。
シナリオ履歴は、オペレーション数、所要時間、書き戻しレスポンスの視覚的な記録を提供します。
本番計画では、webhookの担当範囲、router、エラーハンドラー、オペレーション数をカバーする必要があります。
公開用の検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットでシナリオ履歴内のwebhook bundle、モジュールバブル、オペレーション数、HTTPレスポンスを確認できます。
HTTPモジュールの証跡も視覚的で、メソッド、エンドポイント、ボディタイプ、解析済みレスポンス、完了ステータスをコードエディタを開かずに確認できます。
まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。
高額契約、緊急請求、不足情報ありのケースで異なるJodooキューが必要な場合は、基本検証の後にrouterを使用します。
Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。
HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行するか、手動レビュー経路へ移せるようにします。
契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。
最初のJodoo書き戻し検証が安定した後は、routerで中リスクの更新案件と高リスクの新規契約を分岐できます。
ワークフローキット
ハンドブックを確認し、ワークフローのレシピをコピーし、Makeワークフローを調整する際はJodooのフィールドモデルを活用してください。
Makeが視覚的なシナリオを処理し、Jodooが担当者キュー、レビュー状況、フォローアップのために契約受付レビューフィールドを保存します。
再利用可能なワークフロー
Northstar Logistics MSA renewalで契約受付テストを開始します。まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。
Make Custom webhookがサンプルペイロードを受信し、HTTPモジュールが構造化フィールドをJodooに送信します。
構造化JSONをJodoo書き戻しブリッジに送信します。HTTPモジュールの証跡も視覚的で、メソッド、エンドポイント、ボディタイプ、解析済みレスポンス、完了ステータスをコードエディタを開かずに確認できます。
プラットフォームでの実行成功とJodoo data IDを表示します。公開用の検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットでシナリオ履歴内のwebhook bundle、モジュールバブル、オペレーション数、HTTPレスポンスを確認できます。
担当者レビュー、ステータス管理、フォローアップ用のフィールドを保存します。Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。
ワークフローループ
Custom webhookが契約受付レビューを受信する、またはまず合成データで開始します。
Makeは焦点を絞ったレビュー指示を適用し、リスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況を返します。
HTTPモジュールが構造化された出力をJodoo書き戻しブリッジへ送信し、data IDを受け取ります。
契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。
最初のJodoo書き戻し検証が安定した後は、routerで中リスクの更新案件と高リスクの新規契約を分岐できます。
シナリオ履歴は、各モジュール、所要時間、オペレーション数、受け付けられたJodooレスポンスを示すため、法務オペレーションにとって最適な検証証跡です。
まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。
高額契約、緊急請求、不足情報ありのケースで異なるJodooキューが必要な場合は、基本検証の後にrouterを使用します。
Jodooは契約受付フォームのレコードを作成し、契約名、取引先、契約種類、申請部門、契約金額、目標署名日、不足情報、リスクレベルを保存します。
チームはキューをレビューし、担当範囲を割り当て、次のアクションを完了します。法務と財務に振り分ける前に、不足している保険証明書とデータ処理確認を依頼します。
Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。
HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行するか、手動レビュー経路へ移せるようにします。
フィールドマッピング
| エージェントまたはソースデータ | Jodooレコードのフィールド |
|---|---|
| 元の申請詳細 | 契約名、取引先、契約種類、申請部門 |
| レビュー判定フィールド | 不足情報、リスクレベル、優先度、レビューの振り分け先、推奨担当者 |
| ワークフローレスポンス | ソースプラットフォーム、元のワークフロー出力 |
エージェントレシピ
1件の契約受付レビュー申請を確認し、Jodooで保存・振り分け・レポート可能な構造化フィールドを返してください。まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。
Northstar Logistics MSA renewalのサンプル文脈を使い、リスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況を判断し、推奨する次のアクションは具体的にしてください。契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。
予測可能なJSONオブジェクトをHTTPモジュール経由で送信してください。Jodooは毎回同じフィールド名を受け取る必要があります。Makeは、キャンバス、フィルター、router、モジュール単位の実行履歴を使って引き継ぎを説明したいオペレーションチームに適しています。
監査用コンテキストとして、risk level、priority、review route、missing information、suggested owner、next best action、review status、source_platform、agent_confidence、original workflow outputを返してください。
Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行するか、手動レビュー経路へ移せるようにします。webhook URLの担当者と、本番の申請データを扱うモジュールを編集できる担当者を文書化してください。
契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。最初のJodoo書き戻し検証が安定した後は、routerで中リスクの更新案件と高リスクの新規契約を分岐できます。シナリオ履歴は、各モジュール、所要時間、オペレーション数、受け付けられたJodooレスポンスを示すため、法務オペレーションにとって最適な検証証跡です。
{
"contract_name": "Northstar Logistics MSA 更新",
"counterparty": "Northstar Logistics",
"contract_type": "基本サービス契約",
"contract_value": 186000,
"currency": "USD",
"risk_level": "中",
"priority": "高",
"review_route": "法務、その後財務",
"missing_information": "更新済み保険証明書とデータ処理補遺の確認",
"suggested_owner": "法務オペレーション",
"next_best_action": "不足書類を依頼し、法務レビューへ回す",
"review_status": "受付内容のフォローアップが必要"
}Jodooスターターアプリ
契約受付レビューのワークフローをチーム向けに調整する際は、このフィールドモデル、ビュー、自動化を活用してください。
展開チェックリスト
ワークフロー
Makeが視覚的なシナリオを処理し、Jodooがチームで絞り込み、割り当て、レビューできるレコードを保持します。
Custom webhookが契約受付レビューを受信する、またはまず合成データで開始します。
Makeは焦点を絞ったレビュー指示を適用し、リスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況を返します。
HTTPモジュールが構造化された出力をJodoo書き戻しブリッジへ送信し、data IDを受け取ります。
契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。
最初のJodoo書き戻し検証が安定した後は、routerで中リスクの更新案件と高リスクの新規契約を分岐できます。
シナリオ履歴は、各モジュール、所要時間、オペレーション数、受け付けられたJodooレスポンスを示すため、法務オペレーションにとって最適な検証証跡です。
まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。
高額契約、緊急請求、不足情報ありのケースで異なるJodooキューが必要な場合は、基本検証の後にrouterを使用します。
Jodooは契約受付フォームのレコードを作成し、契約名、取引先、契約種類、申請部門、契約金額、目標署名日、不足情報、リスクレベルを保存します。
チームはキューをレビューし、担当範囲を割り当て、次のアクションを完了します。法務と財務に振り分ける前に、不足している保険証明書とデータ処理確認を依頼します。
Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。
HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行するか、手動レビュー経路へ移せるようにします。
Jodooレコード
ワークフロー実行後、Jodooには契約名、取引先、契約種類、申請部門、契約金額、目標署名日、不足情報、リスクレベルといった主要フィールドが保持されます。
実際のテスト実行
スクリーンショットには合成データを使用しており、Makeの設定、成功した実行、そしてワークフローによって作成されたJodooの行を確認できます。

Make Custom webhookがサンプルペイロードを受信し、HTTPモジュールが構造化フィールドをJodooに送信します。

Makeの実行履歴には、HTTPモジュールの完了、実行の詳細、Jodoo data IDのレスポンスが表示されます。

契約受付レビューはJodooに書き込まれ、契約名、取引先、契約種類、申請部門、契約金額、目標署名日の各フィールドを確認できます。
FAQ
Jodooのレコード、ワークフロー、アプリテンプレートとエージェントプラットフォームを組み合わせて使う際の回答です。
はい。検証では合成データ、実際のMake実行、そして検証マニフェスト付きのJodoo書き戻しスクリーンショットを使用しています。
シナリオキャンバスの可視性、Run onceでのテスト、モジュール履歴を重視するオペレーションチームにはMakeが適しています。Jodooはその後、レビューとフォローアップのための永続的なレコードを保持します。
公開用の検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットでシナリオ履歴内のwebhook bundle、モジュールバブル、オペレーション数、HTTPレスポンスを確認できます。まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。
Jodooは、契約名、取引先、契約種類、申請部門、契約金額、目標署名日、不足情報、リスクレベル、優先度、レビューの振り分け先に加えて、監査コンテキスト用に元のワークフロー出力を保存します。
はい。まずは検証済みの合成データ実行から始め、契約受付レビューのスキーマが安定したら、フォーム、ポータル、受信箱、API、社内システムへ接続できます。高額契約、緊急請求、不足情報ありのケースで異なるJodooキューが必要な場合は、基本検証の後にrouterを使用します。
ワークフローは判定フィールドを準備できますが、担当者は引き続き、事業リスク、支払いや法務の承認、最終的な運用判断をレビューする必要があります。webhook URLの担当者と、本番の申請データを扱うモジュールを編集できる担当者を文書化してください。
次のステップ
まずは検証済みのMake実行を1回行い、その後は同じ書き戻しパターンを周辺のレビューキューや運用上の引き継ぎにも再利用できます。Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。