ソリューションハンドブック
Makeによる請求書例外レビューのループに関する計画ガイドです。設定、Jodooフィールド、検証レコード、展開時の注意点を含みます。
ハンドブックを開くMAKE + JODOO
Make + JodooによるAI請求書例外レビュー
MakeとJodooを使って請求書例外レビューを実行し、例外種別、保留理由、支払い準備状況、割り当てられたレビュー担当者、予算責任者、推奨対応、優先度を返し、その結果を追跡可能なJodooレコードに保存します。
一貫した評価基準で請求書例外データをレビュー例外種別、保留理由、支払い準備状況、割り当てられたレビュー担当者、予算責任者、推奨対応、優先度をJodooに書き込む担当者キューとフォローアップ状況を可視化ワークフローを本番データソース向けに調整する前にMakeの検証結果を活用公開された検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットにWebhookバンドル、モジュールバブル、操作回数、HTTPレスポンスをシナリオ履歴として表示できます。
動画ウォークスルー
Makeデモで行われること
動画では、Atlas Packaging Co.のINV-2026-1048がPO金額不一致と受領確認不足の状態でワークフローに入り、その後Jodooに運用レコードとして保存される流れを紹介します。
Custom webhookが申請を受信
Atlas Packaging Co.のINV-2026-1048が、PO金額不一致と受領確認不足の状態でワークフローに入ります。
Makeが構造化レビュー用フィールドを準備
ワークフローは、曖昧な段落を返すのではなく、例外種別、保留理由、支払い準備状況、割り当てられたレビュー担当者、予算責任者、推奨対応、優先度を明示的に保持します。
HTTPモジュールがJodooに書き込み
テスト実行では、レビュー結果をJodooに送信し、ブリッジからJodoo data IDを受け取ります。
Makeの検証結果は確認可能なまま保持
公開された検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットにWebhookバンドル、モジュールバブル、操作回数、HTTPレスポンスをシナリオ履歴として表示できます。
Jodooがチーム用レコードを保持
Jodooアプリは、仕入先名、請求書番号、請求日、請求金額、PO番号、支払期限日、例外フラグを保存し、レビューとフォローアップに活用できます。
デモ概要
Makeが請求書例外をレビューし、Jodooがフォローアップを管理
この実装は、シナリオキャンバスの可視性、Run onceテスト、モジュール履歴を重視するオペレーションチームに適しています。このページでは、視覚的なシナリオ設定、実際の実行結果、Jodooへの書き戻しを確認できます。HTTPモジュールの証跡は視覚的に確認でき、コードエディタを開かなくても、メソッド、エンドポイント、ボディ形式、解析済みレスポンス、完了ステータスを確認できます。
Makeシナリオ
Make Custom webhookがサンプルペイロードを受信し、HTTPモジュールが構造化されたフィールドをJodooに送信します。
構造化された判定
ワークフローは、INV-2026-1048に対して例外種別、保留理由、支払い準備状況、割り当てられたレビュー担当者、予算責任者、推奨対応、優先度を返します。
Makeの正常実行
Makeの実行履歴には、HTTPモジュールの完了、操作詳細、Jodoo data IDのレスポンスが表示されます。
Make実装の詳細
まずCustom webhookから始め、サンプル申請を貼り付けて、Makeにバンドルを推測させてから、判定フィールドをHTTPモジュールのボディにマッピングします。
請求書例外レシピの詳細
請求書例外レビューでは、基本の書き戻し後に、MakeでPO不一致、受領確認不足、予算責任者承認のケースを別ルートに分岐できます。
Jodooへの書き戻し
Jodooは請求書例外レコードを保存し、次の対応を見える化します。
運用フォローアップ
推奨される次の対応は、支払い保留、受領確認の依頼、予算責任者への差異承認依頼です。
再利用可能なキット
このキットには、ハンドブック、Jodooフィールド設計図、Makeワークフローレシピが含まれます。
プラットフォーム設定メモ
Make特有のポイント
Jodooのレコードモデルは一貫して保てますが、各エージェントプラットフォームでは構築スタイル、テスト画面、本番への引き継ぎ方法が異なります。
設定の検証
この検証ではRun onceを使用しているため、受信バンドルとHTTPレスポンスを確認できます。
アクション経路
HTTPモジュールでは、method、URL、ボディ形式、レスポンス解析を確認可能な状態で保持できます。
レシピの焦点
シナリオ履歴により、操作回数、所要時間、書き戻しレスポンスを視覚的な記録として確認できます。
本番計画
本番計画では、Webhookの管理責任、ルーター、エラーハンドラー、操作回数を含めて検討する必要があります。
証跡の詳細
公開された検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットにWebhookバンドル、モジュールバブル、操作回数、HTTPレスポンスをシナリオ履歴として表示できます。
実行証跡
HTTPモジュールの証跡は視覚的に確認でき、コードエディタを開かなくても、メソッド、エンドポイント、ボディ形式、解析済みレスポンス、完了ステータスを確認できます。
構築の詳細
まずCustom webhookから始め、サンプル申請を貼り付けて、Makeにバンドルを推測させてから、判定フィールドをHTTPモジュールのボディにマッピングします。
実装パス
高額契約、緊急請求書、情報不足のケースで異なるJodooキューが必要な場合は、基本検証の後にルーターを使用してください。
ガードレール
Run onceによる検証をアクティブなワークフローに切り替える前に、操作回数、Webhookの管理責任、シナリオのスケジュールを確認してください。
レビュー管理
HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行または手動レビュー経路へ移せるようにしてください。
シナリオレシピ
請求書例外レビューでは、基本の書き戻し後に、MakeでPO不一致、受領確認不足、予算責任者承認のケースを別ルートに分岐できます。
ワークフロー調整
HTTPモジュールのボディでは、保留理由、支払い準備状況、例外種別、割り当てられたレビュー担当者を明示的にマッピングしたフィールドとして保持する必要があります。
ワークフローキット
同じ請求書例外レビューのループを構築
ハンドブックを確認し、ワークフローレシピをコピーして、Makeワークフローを調整する際にJodooのフィールドモデルを活用してください。
チームで再利用できるもの
Makeが視覚的なシナリオを処理し、Jodooが担当者キュー、レビュー状況、フォローアップのために請求書例外レビューのフィールドを保存します。
業務ワークフローJodooフィールドモデルエージェントプロンプト展開チェックリスト
再利用可能なワークフロー
ワークフローが判断し、Jodooが業務を前に進めます。
- 01
Custom webhook
INV-2026-1048を使って請求書例外テストを開始します。まずCustom webhookから始め、サンプル申請を貼り付けて、Makeにバンドルを推測させてから、判定フィールドをHTTPモジュールのボディにマッピングします。
- 02
Makeシナリオ
Make Custom webhookがサンプルペイロードを受信し、HTTPモジュールが構造化されたフィールドをJodooに送信します。
- 03
HTTPモジュール
構造化JSONをJodoo書き戻しブリッジに送信します。HTTPモジュールの証跡は視覚的に確認でき、コードエディタを開かなくても、メソッド、エンドポイント、ボディ形式、解析済みレスポンス、完了ステータスを確認できます。
- 04
検証レスポンス
正常なプラットフォーム実行とJodoo data IDを表示します。公開された検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットにWebhookバンドル、モジュールバブル、操作回数、HTTPレスポンスをシナリオ履歴として表示できます。
- 05
Jodooキュー
担当者レビュー、ステータス管理、フォローアップのためのフィールドを保存します。Run onceによる検証をアクティブなワークフローに切り替える前に、操作回数、Webhookの管理責任、シナリオのスケジュールを確認してください。
ワークフローループ
Makeの請求書例外レビューからJodooへ
Custom webhookがまず合成データで請求書例外レビューを受信または開始します。
Makeが絞り込まれたレビュー指示を適用し、例外種別、保留理由、支払い準備状況、割り当てられたレビュー担当者、予算責任者、推奨対応、優先度を返します。
HTTPモジュールが構造化された出力をJodoo書き戻しブリッジに送信し、data IDを受け取ります。
請求書例外レビューでは、基本の書き戻し後に、MakeでPO不一致、受領確認不足、予算責任者承認のケースを別ルートに分岐できます。
HTTPモジュールのボディでは、保留理由、支払い準備状況、例外種別、割り当てられたレビュー担当者を明示的にマッピングしたフィールドとして保持する必要があります。
APにとってシナリオ履歴は有用です。各テスト請求書のバンドル、ルート、操作回数、レスポンス詳細を、1つの視覚的な実行画面で確認できます。
検証後は、Makeに請求書バッチ用の集約モジュール、重複請求書チェック用のデータストア、AP例外担当者向けのSlackまたはメールモジュールを追加できます。
まずCustom webhookから始め、サンプル申請を貼り付けて、Makeにバンドルを推測させてから、判定フィールドをHTTPモジュールのボディにマッピングします。
高額契約、緊急請求書、情報不足のケースで異なるJodooキューが必要な場合は、基本検証の後にルーターを使用してください。
Jodooは請求書承認ワークフローレコードを作成し、仕入先名、請求書番号、請求日、請求金額、PO番号、支払期限日、例外フラグ、例外理由を保存します。
チームはキューをレビューし、担当者を割り当て、次の対応を完了します：支払い保留、受領確認の依頼、予算責任者への差異承認依頼。
Run onceによる検証をアクティブなワークフローに切り替える前に、操作回数、Webhookの管理責任、シナリオのスケジュールを確認してください。
HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行または手動レビュー経路へ移せるようにしてください。
フィールドマッピング
エージェントの出力をJodooフィールド化
| エージェントまたはソースデータ | Jodooレコードのフィールド |
|---|---|
| 元の申請詳細 | 仕入先名、請求書番号、請求日、請求金額 |
| レビュー判定フィールド | 例外フラグ、例外理由、仕訳状況、支払い準備状況、承認状況 |
| ワークフローレスポンス | ソースプラットフォーム、元のワークフロー出力 |
エージェントレシピ
プロンプトと構造化出力
Makeの役割
1件の請求書例外レビュー申請をレビューし、Jodooで保存、振り分け、レポートできる構造化フィールドを返します。まずCustom webhookから始め、サンプル申請を貼り付けて、Makeにバンドルを推測させてから、判定フィールドをHTTPモジュールのボディにマッピングします。
レビュー指示
INV-2026-1048のサンプルコンテキストを使用し、例外種別、保留理由、支払い準備状況、割り当てられたレビュー担当者、予算責任者、推奨対応、優先度を判断し、推奨される次の対応は具体的にしてください。請求書例外レビューでは、基本の書き戻し後に、MakeでPO不一致、受領確認不足、予算責任者承認のケースを別ルートに分岐できます。
書き戻し契約
予測可能なJSONオブジェクトをHTTPモジュール経由で送信してください。Jodooは毎回同じフィールド名を受け取る必要があります。Makeは、キャンバス、フィルター、ルーター、モジュール単位の実行履歴で引き継ぎを説明したいオペレーションチームに適しています。
必須出力
監査コンテキストのために、例外種別、保留理由、支払い準備状況、割り当てられたレビュー担当者、予算責任者、推奨対応、優先度、source_platform、agent_confidence、original workflow outputを返します。
Makeの管理ポイント
Run onceによる検証をアクティブなワークフローに切り替える前に、操作回数、Webhookの管理責任、シナリオのスケジュールを確認してください。HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行または手動レビュー経路へ移せるようにしてください。本番の申請データを扱うモジュールについて、Webhook URLの管理責任者と編集可能な担当者を文書化してください。
請求書例外の実装メモ
請求書例外レビューでは、基本の書き戻し後に、MakeでPO不一致、受領確認不足、予算責任者承認のケースを別ルートに分岐できます。HTTPモジュールのボディでは、保留理由、支払い準備状況、例外種別、割り当てられたレビュー担当者を明示的にマッピングしたフィールドとして保持する必要があります。APにとってシナリオ履歴は有用です。各テスト請求書のバンドル、ルート、操作回数、レスポンス詳細を、1つの視覚的な実行画面で確認できます。検証後は、Makeに請求書バッチ用の集約モジュール、重複請求書チェック用のデータストア、AP例外担当者向けのSlackまたはメールモジュールを追加できます。
{
"invoice_number": "INV-2026-1048",
"vendor_name": "Atlas Packaging Co.",
"invoice_amount": 18640,
"po_number": "PO-7782",
"exception_type": "PO 金額の不一致",
"hold_reason": "金額不一致と受領確認の不足",
"payment_readiness": "保留中",
"approval_status": "例外レビュー",
"assigned_owner": "AP 例外処理",
"budget_owner": "Maya Chen",
"recommended_resolution": "支払いを保留し、差異承認を依頼する",
"priority": "高"
}Jodooスターターアプリ
請求書例外スターターアプリ
貴社チーム向けに請求書例外レビューワークフローを調整する際に、このフィールドモデル、ビュー、自動化を活用してください。
含まれるフィールド
- 仕入先名
- 請求書番号
- 請求日
- 請求金額
- PO番号
- 支払期限日
- 例外フラグ
- 例外理由
- 仕訳状況
- 支払い準備状況
- 承認状況
- 割り当てられたレビュー担当者
- 予算責任者
- 推奨対応
- 元のワークフロー出力
推奨ビュー
- 例外レビュー
- 支払い保留キュー
- 予算責任者レビュー
- 支払い可能
- すべての請求書申請
自動化ルール
- Makeが構造化出力を返した後にJodooレコードを作成する。
- 高優先度または例外レコードを適切な担当者キューに移動する。
- 情報不足または保留理由がある場合に、推奨された担当者へ通知する。
- 監査コンテキストのために元のワークフロー出力を保持する。
展開チェックリスト
本番前に確認すべきこと
- シナリオを有効化する前に、合成データをCustom webhookに送信する。
- 編集後にHTTPモジュールを開き直し、保存されたJSONマッピングを確認する。
- シナリオ履歴を使ってステータス、操作回数、レスポンスボディを確認する。
- 基本の書き戻しが安定してから、ルーター、フィルター、通知を追加する。
- Run onceによる検証をアクティブなワークフローに切り替える前に、操作回数、Webhookの管理責任、シナリオのスケジュールを確認する。
- HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行または手動レビュー経路へ移せるようにする。
- Webhook URLの管理責任者と、本番の申請データを扱うモジュールを編集できる担当者を文書化する。
- HTTPモジュールのボディでは、保留理由、支払い準備状況、例外種別、割り当てられたレビュー担当者を明示的にマッピングしたフィールドとして保持する。
- APにとってシナリオ履歴は有用です。各テスト請求書のバンドル、ルート、操作回数、レスポンス詳細を、1つの視覚的な実行画面で確認できるためです。
- 検証後は、Makeに請求書バッチ用の集約モジュール、重複請求書チェック用のデータストア、AP例外担当者向けのSlackまたはメールモジュールを追加できる。
ワークフロー
Makeの請求書例外からJodooレコードへ
Makeが視覚的なシナリオを処理し、Jodooがチームで絞り込み、割り当て、レビューできるレコードを保持します。
Custom webhookがまず合成データで請求書例外レビューを受信または開始します。
Makeが絞り込まれたレビュー指示を適用し、例外種別、保留理由、支払い準備状況、割り当てられたレビュー担当者、予算責任者、推奨対応、優先度を返します。
HTTPモジュールが構造化された出力をJodoo書き戻しブリッジに送信し、data IDを受け取ります。
請求書例外レビューでは、基本の書き戻し後に、MakeでPO不一致、受領確認不足、予算責任者承認のケースを別ルートに分岐できます。
HTTPモジュールのボディでは、保留理由、支払い準備状況、例外種別、割り当てられたレビュー担当者を明示的にマッピングしたフィールドとして保持する必要があります。
APにとってシナリオ履歴は有用です。各テスト請求書のバンドル、ルート、操作回数、レスポンス詳細を、1つの視覚的な実行画面で確認できます。
検証後は、Makeに請求書バッチ用の集約モジュール、重複請求書チェック用のデータストア、AP例外担当者向けのSlackまたはメールモジュールを追加できます。
まずCustom webhookから始め、サンプル申請を貼り付けて、Makeにバンドルを推測させてから、判定フィールドをHTTPモジュールのボディにマッピングします。
高額契約、緊急請求書、情報不足のケースで異なるJodooキューが必要な場合は、基本検証の後にルーターを使用してください。
Jodooは請求書承認ワークフローレコードを作成し、仕入先名、請求書番号、請求日、請求金額、PO番号、支払期限日、例外フラグ、例外理由を保存します。
チームはキューをレビューし、担当者を割り当て、次の対応を完了します：支払い保留、受領確認の依頼、予算責任者への差異承認依頼。
Run onceによる検証をアクティブなワークフローに切り替える前に、操作回数、Webhookの管理責任、シナリオのスケジュールを確認してください。
HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行または手動レビュー経路へ移せるようにしてください。
Jodooレコード
Jodooに保存される内容
ワークフロー実行後、Jodooには請求書例外の主要フィールドが保持されます：仕入先名、請求書番号、請求日、請求金額、PO番号、支払期限日、例外フラグ、例外理由。
仕入先名請求書番号請求日請求金額PO番号支払期限日例外フラグ例外理由仕訳状況支払い準備状況承認状況割り当てられたレビュー担当者予算責任者推奨対応元のワークフロー出力
実際のテスト実行
Makeワークフローが請求書例外をJodooに書き込みました
スクリーンショットでは合成データを使用し、Makeの設定、正常実行、ワークフローによって作成されたJodooのレコードを示しています。
Makeシナリオ設定
Make Custom webhookがサンプルペイロードを受信し、HTTPモジュールが構造化されたフィールドをJodooに送信します。
Makeの正常実行
Makeの実行履歴には、HTTPモジュールの完了、操作詳細、Jodoo data IDのレスポンスが表示されます。
Jodooへの書き戻し
請求書例外レビューはJodooに書き込まれ、仕入先名、請求書番号、請求日、請求金額、PO番号、支払期限日の各フィールドが表示されます。
FAQ
よくある質問
Jodooのレコード、ワークフロー、アプリテンプレートとエージェントプラットフォームを組み合わせて使う際の回答です。
このMakeによる請求書例外レビューはエンドツーエンドで検証されていますか？
はい。検証では合成データ、実際のMake実行、そしてproof manifest付きの検証済みJodoo書き戻しスクリーンショットを使用しました。
請求書例外レビューにMakeを使う理由は？
シナリオキャンバスの可視性、Run onceテスト、モジュール履歴を重視するオペレーションチームにはMakeが適しています。Jodooはその後、レビューとフォローアップのための永続的なレコードを保持します。
このMake実装は他のプラットフォーム例と何が違いますか？
公開された検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットにWebhookバンドル、モジュールバブル、操作回数、HTTPレスポンスをシナリオ履歴として表示できます。まずCustom webhookから始め、サンプル申請を貼り付けて、Makeにバンドルを推測させてから、判定フィールドをHTTPモジュールのボディにマッピングします。請求書例外レビューでは、基本の書き戻し後に、MakeでPO不一致、受領確認不足、予算責任者承認のケースを別ルートに分岐できます。
ワークフロー実行後にJodooは何を保存しますか？
Jodooは仕入先名、請求書番号、請求日、請求金額、PO番号、支払期限日、例外フラグ、例外理由、仕訳状況、支払い準備状況に加え、監査コンテキストのために元のワークフロー出力も保存します。
後から本番の元データに接続できますか？
はい。まずは検証済みの合成実行から始め、請求書例外レビューのスキーマが安定したら、フォーム、ポータル、受信箱、API、社内システムに接続できます。高額契約、緊急請求書、情報不足のケースで異なるJodooキューが必要な場合は、基本検証の後にルーターを使用してください。
チームで引き続き確認すべきことは何ですか？
ワークフローは判定フィールドを準備できますが、担当者は引き続き、事業リスク、支払いまたは法務承認、最終的な運用判断を確認する必要があります。Webhook URLの管理責任者と、本番の申請データを扱うモジュールを編集できる担当者を文書化してください。
次のステップ
請求書例外を追跡可能なフォローアップへ
まずは検証済みのMake実行を1回行い、その後は同じ書き戻しパターンを周辺のレビューキューや運用上の引き継ぎにも再利用できます。Run onceによる検証をアクティブなワークフローに切り替える前に、操作回数、Webhookの管理責任、シナリオのスケジュールを確認してください.