ソリューションハンドブック
Makeによる購買申請の承認振り分けループの計画ガイドです。設定、Jodooフィールド、検証レコード、展開時のメモを含みます。
ハンドブックを開くMAKE + JODOO
Make + JodooによるAI購買申請の承認振り分け
MakeとJodooで購買申請の承認振り分けを処理する流れを紹介します。元の申請を確認し、構造化された判断フィールドを返し、結果をJodooに書き戻して、担当者、ステータス、次のアクションを可視化します。
1
一貫した評価基準で購買申請データをレビュー
2
承認ステータス、調達ステータス、購買担当者、承認ルート、不足情報、見積合計、優先度、推奨される次のアクションをJodooに書き込み
3
担当者キューとフォローアップ状況を可視化
4
本番データソースにワークフローを適用する前に、Makeで検証
5
公開検証ではMakeのRun onceモードを使用するため、取得したスクリーンショットでシナリオ履歴内のWebhookバンドル、モジュールバブル、操作回数、HTTPレスポンスを確認できます。
動画ウォークスルー
Makeデモで行われること
動画では、フィールドサービスチームが予算コード、導入時期、見積支出、不足しているデバイス管理情報を添えて12台の堅牢タブレットを申請し、Makeがそれを処理した後、Jodooが業務レコードとして保存する流れを示します。
Custom webhookが申請を受信
フィールドサービスチームが、予算コード、導入時期、見積支出、不足しているデバイス管理情報を添えて、12台の堅牢タブレットを申請します。
Makeが構造化されたレビューフィールドを準備
ワークフローは自由記述の文章ではなく、承認ステータス、調達ステータス、購買担当者、承認ルート、不足情報、見積合計、優先度、推奨される次のアクションを明示的に保持します。
HTTPモジュールがJodooに書き込み
テスト実行ではレビュー結果をJodooへ送信し、ブリッジからJodooデータIDを受け取ります。
Makeの検証結果を確認可能
公開検証ではMakeのRun onceモードを使用するため、取得したスクリーンショットでシナリオ履歴内のWebhookバンドル、モジュールバブル、操作回数、HTTPレスポンスを確認できます。
Jodooがチーム用レコードを保持
Jodooアプリは、レビューとフォローアップのために申請者名、部門、申請日、優先度、品目カテゴリ、品目説明、数量を保存します。
デモ概要
Makeが申請をレビューし、Jodooがフォローアップを管理
この実装は、視覚的なシナリオキャンバス、Run onceテスト、モジュール履歴を必要とするオペレーションチームに適しています。このページでは、視覚的なシナリオ設定、実行結果、Jodooへの書き戻しを確認できます。HTTPモジュールの証跡は視覚的に確認でき、メソッド、エンドポイント、ボディ形式、解析済みレスポンス、完了ステータスをコードエディタを開かずに点検できます。
Makeシナリオ
MakeのCustom webhookがサンプルペイロードを受け取り、HTTPモジュールが構造化フィールドをJodooへ送信します。
構造化された判断
ワークフローは、フィールドサービスチーム向けの12台の堅牢タブレット（保護ケースとデバイス登録サポートを含む）について、承認ステータス、調達ステータス、購買担当者、承認ルート、不足情報、見積合計、優先度、推奨される次のアクションを返します。
成功したMake実行
Makeの実行履歴には、HTTPモジュールの完了、操作の詳細、JodooデータIDのレスポンスが表示されます。
Make実装の詳細
Custom webhookから開始し、サンプル申請を貼り付け、Makeにバンドルを推測させてから、判断フィールドをHTTPモジュールのボディにマッピングします。
購買申請レシピの詳細
購買申請の承認振り分けでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドル内で申請者、部門、品目、数量、見積合計、予算コード、希望納期、不足情報を可視化しておく必要があります。
Jodooへの書き戻し
Jodooは購買申請レコードを保存し、次のアクションを可視化します。
業務上のフォローアップ
推奨される次のアクションは、ベンダー見積を依頼し、予算担当者の承認を確認し、調達前に申請を財務部へ振り分けることです。
再利用可能なキット
持ち帰り用キットには、ハンドブック、Jodooフィールド設計図、Makeワークフローレシピが含まれます。
プラットフォーム設定メモ
Make特有のポイント
Jodooのレコードモデルは一貫して保てますが、各エージェントプラットフォームでは構築スタイル、テスト画面、本番への引き継ぎ方法が異なります。
設定の検証
この検証ではRun onceを使用するため、受信バンドルとHTTPレスポンスを確認できます。
アクションパス
HTTPモジュールでは、メソッド、URL、ボディ形式、レスポンス解析を点検できます。
レシピの焦点
シナリオ履歴により、操作、所要時間、書き戻しレスポンスの視覚的なレコードが得られます。
本番計画
本番計画では、Webhookの担当範囲、ルーター、エラーハンドラー、オペレーション使用量を確認する必要があります。
証跡の詳細
公開検証ではMakeのRun onceモードを使用するため、取得したスクリーンショットでシナリオ履歴内のWebhookバンドル、モジュールバブル、操作回数、HTTPレスポンスを確認できます。
実行証跡
HTTPモジュールの証跡は視覚的に確認でき、メソッド、エンドポイント、ボディ形式、解析済みレスポンス、完了ステータスをコードエディタを開かずに点検できます。
構築の詳細
Custom webhookから開始し、サンプル申請を貼り付け、Makeにバンドルを推測させてから、判断フィールドをHTTPモジュールのボディにマッピングします。
実装パス
高額契約、緊急請求書、不足情報があるケースで異なるJodooキューが必要な場合は、基本検証後にルーターを使用します。
ガードレール
Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション使用量、Webhookの担当範囲、シナリオのスケジュールを確認してください。
レビュー管理
HTTPモジュールの周辺にエラーハンドラーを追加し、書き戻しに失敗した場合に再試行するか、手動レビューパスへ移動できるようにします。
シナリオレシピ
購買申請の承認振り分けでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドル内で申請者、部門、品目、数量、見積合計、予算コード、希望納期、不足情報を可視化しておく必要があります。
ワークフロー適用
最初の書き戻し検証が安定した後、ルーターで低額申請、見積が必要な購買、財務承認、緊急調達業務を分岐できます。
ワークフローキット
同じ購買申請の承認振り分けループを構築
Makeワークフローを適用する際は、ハンドブックを確認し、ワークフローレシピをコピーして、Jodooのフィールドモデルを使用します。
再利用可能なワークフロー
ワークフローが判断し、Jodooが業務を前に進めます。
- 01
Custom webhook
フィールドサービスチーム向けの12台の堅牢タブレット（保護ケースとデバイス登録サポートを含む）で購買申請テストを開始します。Custom webhookから開始し、サンプル申請を貼り付け、Makeにバンドルを推測させてから、判断フィールドをHTTPモジュールのボディにマッピングします。
- 02
Makeシナリオ
MakeのCustom webhookがサンプルペイロードを受け取り、HTTPモジュールが構造化フィールドをJodooへ送信します。
- 03
HTTPモジュール
構造化されたJSONをJodoo書き戻しブリッジへ送信します。HTTPモジュールの証跡は視覚的に確認でき、メソッド、エンドポイント、ボディ形式、解析済みレスポンス、完了ステータスをコードエディタを開かずに点検できます。
- 04
検証レスポンス
成功したプラットフォーム実行とJodooデータIDを示します。公開検証ではMakeのRun onceモードを使用するため、取得したスクリーンショットでシナリオ履歴内のWebhookバンドル、モジュールバブル、操作回数、HTTPレスポンスを確認できます。
- 05
Jodooキュー
担当者レビュー、ステータス追跡、フォローアップのためのフィールドを保存します。Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション使用量、Webhookの担当範囲、シナリオのスケジュールを確認してください。
ワークフローループ
Makeによる購買申請の承認振り分けからJodooへ
Custom webhookが、まず合成データで購買申請の承認振り分けを受信または開始します。
Makeが焦点を絞ったレビュー指示を適用し、承認ステータス、調達ステータス、購買担当者、承認ルート、不足情報、見積合計、優先度、推奨される次のアクションを返します。
HTTPモジュールが構造化された出力をJodoo書き戻しブリッジへ送信し、データIDを受け取ります。
購買申請の承認振り分けでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドル内で申請者、部門、品目、数量、見積合計、予算コード、希望納期、不足情報を可視化しておく必要があります。
最初の書き戻し検証が安定した後、ルーターで低額申請、見積が必要な購買、財務承認、緊急調達業務を分岐できます。
シナリオ履歴は、各モジュール、操作回数、レスポンスボディ、受け付けられたJodooデータIDを示すため、購買部門にとって強力な証跡になります。
検証後、Makeは購買通知、財務承認ブランチ、サプライヤー見積検索、書き戻し失敗時のエラーハンドラーを追加できます。
Custom webhookから開始し、サンプル申請を貼り付け、Makeにバンドルを推測させてから、判断フィールドをHTTPモジュールのボディにマッピングします。
高額契約、緊急請求書、不足情報があるケースで異なるJodooキューが必要な場合は、基本検証後にルーターを使用します。
Jodooは購買申請フォームのレコードを作成し、申請者名、部門、申請日、優先度、品目カテゴリ、品目説明、数量、見積単価を保存します。
チームはキューをレビューし、担当範囲を割り当て、次のアクションを完了します。ベンダー見積を依頼し、予算担当者の承認を確認し、調達前に申請を財務部へ振り分けます。
Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション使用量、Webhookの担当範囲、シナリオのスケジュールを確認してください。
HTTPモジュールの周辺にエラーハンドラーを追加し、書き戻しに失敗した場合に再試行するか、手動レビューパスへ移動できるようにします。
フィールドマッピング
エージェントの出力をJodooフィールド化
| エージェントまたはソースデータ | Jodooレコードのフィールド |
|---|---|
| 元の申請詳細 | 申請者名、部門、申請日、優先度 |
| レビュー判断フィールド | 数量、見積単価、見積合計、希望納期、予算コード |
| ワークフローレスポンス | ソースプラットフォーム、元のワークフロー出力 |
エージェントレシピ
プロンプトと構造化出力
Makeの役割
1件の購買申請をレビューし、Jodooが保存、振り分け、レポートできる構造化フィールドを返します。Custom webhookから開始し、サンプル申請を貼り付け、Makeにバンドルを推測させてから、判断フィールドをHTTPモジュールのボディにマッピングします。
レビュー指示
フィールドサービスチーム向けの12台の堅牢タブレット（保護ケースとデバイス登録サポートを含む）というサンプルコンテキストを使用し、承認ステータス、調達ステータス、購買担当者、承認ルート、不足情報、見積合計、優先度、推奨される次のアクションを判断し、推奨される次のアクションを具体的に保ちます。購買申請の承認振り分けでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドル内で申請者、部門、品目、数量、見積合計、予算コード、希望納期、不足情報を可視化しておく必要があります。
書き戻し契約
予測可能なJSONオブジェクトをHTTPモジュール経由で送信します。Jodooは毎回同じフィールド名を受け取る必要があります。Makeは、キャンバス、フィルター、ルーター、モジュール単位の実行履歴で引き継ぎを説明したいオペレーションチームに役立ちます。
必須出力
承認ステータス、調達ステータス、購買担当者、承認ルート、不足情報、見積合計、優先度、推奨される次のアクション、source_platform、agent_confidence、監査コンテキスト用の元のワークフロー出力を返します。
Makeの管理ポイント
Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション使用量、Webhookの担当範囲、シナリオのスケジュールを確認してください。HTTPモジュールの周辺にエラーハンドラーを追加し、書き戻しに失敗した場合に再試行するか、手動レビューパスへ移動できるようにします。Webhook URLの担当者と、本番申請データを扱うモジュールの編集権限を持つ担当者を文書化します。
購買申請の実装メモ
購買申請の承認振り分けでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドル内で申請者、部門、品目、数量、見積合計、予算コード、希望納期、不足情報を可視化しておく必要があります。最初の書き戻し検証が安定した後、ルーターで低額申請、見積が必要な購買、財務承認、緊急調達業務を分岐できます。シナリオ履歴は、各モジュール、操作回数、レスポンスボディ、受け付けられたJodooデータIDを示すため、購買部門にとって強力な証跡になります。検証後、Makeは購買通知、財務承認ブランチ、サプライヤー見積検索、書き戻し失敗時のエラーハンドラーを追加できます。
{
"requester_name": "Avery Brooks",
"department": "オペレーション",
"item_category": "IT機器",
"item_description": "フィールドサービスチーム向けの堅牢タブレット12台",
"quantity": 12,
"estimated_total": 5820,
"needed_by_date": "2026-06-21",
"budget_code": "OPS-FIELD-2026",
"approval_status": "レビュー待ち",
"sourcing_status": "見積が必要",
"approval_route": "部門マネージャー、その後財務部",
"procurement_owner": "購買オペレーション",
"missing_information": "デバイス管理ライセンス数と配送先住所を確認",
"recommended_next_action": "仕入れ前にベンダー見積もりを依頼し、財務へ回付"
}Jodooスターターアプリ
購買申請スターターアプリ
チーム向けに購買申請の承認振り分けワークフローを適用する際は、フィールドモデル、ビュー、自動化を使用します。
含まれるフィールド
- 申請者名
- 部門
- 申請日
- 優先度
- 品目カテゴリ
- 品目説明
- 数量
- 見積単価
- 見積合計
- 希望納期
- 予算コード
- 業務上の理由
- 承認ステータス
- 調達ステータス
- 購買担当者
- 承認ルート
- 不足情報
- 推奨される次のアクション
- 元のワークフロー出力
推奨ビュー
- 購買レビューが必要
- 財務承認キュー
- 見積が必要
- 高優先度の購買
- すべての購買申請
自動化ルール
- Makeが構造化された出力を返した後にJodooレコードを作成します。
- 高優先度または例外レコードを適切な担当者キューへ移動します。
- 不足情報または保留理由がある場合、推奨された担当者に通知します。
- 元のワークフロー出力を監査コンテキストに保持します。
展開チェックリスト
本番前に確認すべきこと
- シナリオを有効化する前に、合成データをCustom webhookへ送信します。
- 編集後にHTTPモジュールを再度開き、保存されたJSONマッピングを確認します。
- シナリオ履歴を使って、ステータス、操作、レスポンスボディを確認します。
- ルーター、フィルター、通知は、基本の書き戻しが安定してから追加します。
- Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション使用量、Webhookの担当範囲、シナリオのスケジュールを確認してください。
- HTTPモジュールの周辺にエラーハンドラーを追加し、書き戻しに失敗した場合に再試行するか、手動レビューパスへ移動できるようにします。
- Webhook URLの担当者と、本番申請データを扱うモジュールの編集権限を持つ担当者を文書化します。
- 最初の書き戻し検証が安定した後、ルーターで低額申請、見積が必要な購買、財務承認、緊急調達業務を分岐できます。
- シナリオ履歴は、各モジュール、操作回数、レスポンスボディ、受け付けられたJodooデータIDを示すため、購買部門にとって強力な証跡になります。
- 検証後、Makeは購買通知、財務承認ブランチ、サプライヤー見積検索、書き戻し失敗時のエラーハンドラーを追加できます。
ワークフロー
Makeの購買申請からJodooレコードへ
Makeが視覚的なシナリオを処理し、Jodooがチームでフィルタ、割り当て、レビューできるレコードを保持します。
Custom webhookが、まず合成データで購買申請の承認振り分けを受信または開始します。
Makeが焦点を絞ったレビュー指示を適用し、承認ステータス、調達ステータス、購買担当者、承認ルート、不足情報、見積合計、優先度、推奨される次のアクションを返します。
HTTPモジュールが構造化された出力をJodoo書き戻しブリッジへ送信し、データIDを受け取ります。
購買申請の承認振り分けでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドル内で申請者、部門、品目、数量、見積合計、予算コード、希望納期、不足情報を可視化しておく必要があります。
最初の書き戻し検証が安定した後、ルーターで低額申請、見積が必要な購買、財務承認、緊急調達業務を分岐できます。
シナリオ履歴は、各モジュール、操作回数、レスポンスボディ、受け付けられたJodooデータIDを示すため、購買部門にとって強力な証跡になります。
検証後、Makeは購買通知、財務承認ブランチ、サプライヤー見積検索、書き戻し失敗時のエラーハンドラーを追加できます。
Custom webhookから開始し、サンプル申請を貼り付け、Makeにバンドルを推測させてから、判断フィールドをHTTPモジュールのボディにマッピングします。
高額契約、緊急請求書、不足情報があるケースで異なるJodooキューが必要な場合は、基本検証後にルーターを使用します。
Jodooは購買申請フォームのレコードを作成し、申請者名、部門、申請日、優先度、品目カテゴリ、品目説明、数量、見積単価を保存します。
チームはキューをレビューし、担当範囲を割り当て、次のアクションを完了します。ベンダー見積を依頼し、予算担当者の承認を確認し、調達前に申請を財務部へ振り分けます。
Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション使用量、Webhookの担当範囲、シナリオのスケジュールを確認してください。
HTTPモジュールの周辺にエラーハンドラーを追加し、書き戻しに失敗した場合に再試行するか、手動レビューパスへ移動できるようにします。
Jodooレコード
Jodooに保存される内容
ワークフロー実行後、Jodooは申請者名、部門、申請日、優先度、品目カテゴリ、品目説明、数量、見積単価など、永続的な購買申請フィールドを保持します。
申請者名部門申請日優先度品目カテゴリ品目説明数量見積単価見積合計希望納期予算コード業務上の理由承認ステータス調達ステータス購買担当者承認ルート不足情報推奨される次のアクション元のワークフロー出力
実際のテスト実行
Makeワークフローが購買申請をJodooに書き込み
スクリーンショットでは合成データを使用し、Makeの設定、成功した実行、ワークフローによって作成されたJodooの行を示しています。
Makeシナリオ設定
MakeのCustom webhookがサンプルペイロードを受け取り、HTTPモジュールが構造化フィールドをJodooへ送信します。
成功したMake実行
Makeの実行履歴には、HTTPモジュールの完了、操作の詳細、JodooデータIDのレスポンスが表示されます。
Jodooへの書き戻し
購買申請の承認振り分けがJodooに書き込まれ、申請者名、部門、申請日、優先度、品目カテゴリ、品目説明フィールドが表示されています。
FAQ
よくある質問
Jodooのレコード、ワークフロー、アプリテンプレートとエージェントプラットフォームを組み合わせて使う際の回答です。
このMakeによる購買申請の承認振り分けはエンドツーエンドでテストされていますか？
はい。検証では合成データ、実際のMake実行、検証マニフェスト付きのJodoo書き戻しスクリーンショットを使用しました。
購買申請の承認振り分けにMakeを使う理由は何ですか？
視覚的なシナリオキャンバス、Run onceテスト、モジュール履歴を必要とするオペレーションチームにはMakeが適しています。その後、Jodooがレビューとフォローアップのための永続的なレコードを保持します。
このMake実装は、他のプラットフォーム例と何が違いますか？
公開検証ではMakeのRun onceモードを使用するため、取得したスクリーンショットでシナリオ履歴内のWebhookバンドル、モジュールバブル、操作回数、HTTPレスポンスを確認できます。Custom webhookから開始し、サンプル申請を貼り付け、Makeにバンドルを推測させてから、判断フィールドをHTTPモジュールのボディにマッピングします。購買申請の承認振り分けでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドル内で申請者、部門、品目、数量、見積合計、予算コード、希望納期、不足情報を可視化しておく必要があります。
ワークフロー実行後、Jodooには何が保存されますか？
Jodooは、申請者名、部門、申請日、優先度、品目カテゴリ、品目説明、数量、見積単価、見積合計、希望納期に加え、監査コンテキスト用の元のワークフロー出力を保存します。
後から本番データソースに接続できますか？
はい。検証済みの合成データ実行から始め、購買申請の承認振り分けスキーマが安定した後に、フォーム、ポータル、受信箱、API、社内システムへ接続できます。高額契約、緊急請求書、不足情報があるケースで異なるJodooキューが必要な場合は、基本検証後にルーターを使用します。
チームが引き続きレビューすべき点は何ですか？
ワークフローは判断フィールドを準備できますが、ビジネスリスク、支払いまたは法務承認、最終的な業務判断は担当者が引き続きレビューする必要があります。Webhook URLの担当者と、本番申請データを扱うモジュールの編集権限を持つ担当者を文書化してください。
次のステップ
購買申請を追跡可能なフォローアップへ
検証済みのMake実行を1件作成するところから始め、隣接するレビューキューや業務上の引き継ぎにも同じ書き戻しパターンを再利用します。Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション使用量、Webhookの担当範囲、シナリオのスケジュールを確認してください。