ソリューションハンドブック
Make のアクセス申請リスクレビューループの計画ガイドです。設定、Jodoo フィールド、検証レコード、展開メモを含みます。
ハンドブックを開くMAKE + JODOO
Make + Jodoo による AI アクセス申請リスクレビュー
Make と Jodoo でアクセス申請のリスクレビューを処理する流れをご覧ください。元の申請を確認し、構造化された判定フィールドを返し、結果を Jodoo に書き戻して、担当者・ステータス・次のアクションを見える化します。
1
一貫した評価基準でアクセス申請データをレビュー
2
リスクレベル、ポリシー例外、承認ルート、推奨レビュー担当者、プロビジョニングステータス、期限、次の推奨アクションを Jodoo に書き込み
3
担当者キューとフォローアップ状況を見える化
4
本番ソースにワークフローを適用する前に Make の検証結果を利用
5
公開検証では Make の Run once モードを使用するため、取得したスクリーンショットで Webhook バンドル、モジュールのバブル、オペレーション数、HTTP レスポンスをシナリオ履歴に表示できます。
動画ウォークスルー
Make デモで何が起きるか
動画では、財務分析ワークスペースへのアクセス申請が、申請者、部門、申請ロール、業務上の理由、ポリシー例外、緊急度のコンテキストとともにワークフローに入り、その後 Jodoo が運用レコードとして保存する流れを示しています。
Custom webhook が申請を受信
財務分析ワークスペースへのアクセス申請が、申請者、部門、申請ロール、業務上の理由、ポリシー例外、緊急度のコンテキストとともにワークフローに入ります。
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 に送信します。
構造化された判定
ワークフローは、財務分析ワークスペースについて、リスクレベル、ポリシー例外、承認ルート、推奨レビュー担当者、プロビジョニングステータス、期限、次の推奨アクションを返します。
成功した 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
財務分析ワークスペースを使ってアクセス申請テストを開始します。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 を示すため、IT 運用にとって有力な検証材料になります。
検証後、Make で通知、承認ブランチ、プロビジョニング引き継ぎ失敗時のエラーハンドラーを追加できます。
Custom webhook から開始し、サンプル申請を貼り付け、Make にバンドルを推論させてから、判定フィールドを HTTP モジュールの本文にマッピングします。
高額契約、緊急請求書、情報不足のケースで異なる Jodoo キューが必要な場合は、基本検証後にルーターを使用します。
Jodoo はアクセス申請管理レコードを作成し、申請者、部門、申請対象システム、申請ロール、アクセス種別、業務上の理由、リスクレベル、ポリシー例外を保存します。
チームはキューをレビューし、担当範囲を割り当て、次のアクションを完了します。申請をセキュリティへ振り分けてポリシーレビューを行い、プロビジョニング前にマネージャー承認を確認します。
Run once の検証を稼働中のワークフローに切り替える前に、オペレーション使用量、Webhook の担当範囲、シナリオのスケジュールを確認します。
HTTP モジュールの周辺にエラーハンドラーを追加し、書き戻し失敗時に再試行するか、手動レビューパスへ移せるようにします。
フィールドマッピング
エージェントの出力をJodooフィールド化
| エージェントまたはソースデータ | Jodooレコードのフィールド |
|---|---|
| ソース申請の詳細 | 申請者、部門、申請対象システム、申請ロール |
| レビュー判定フィールド | リスクレベル、ポリシー例外、承認ルート、推奨レビュー担当者、プロビジョニングステータス |
| ワークフローレスポンス | ソースプラットフォーム、元のワークフロー出力 |
エージェントレシピ
プロンプトと構造化出力
Make の役割
1 件のアクセス申請リスクレビュー申請を確認し、Jodoo が保存、振り分け、レポートできる構造化フィールドを返します。Custom webhook から開始し、サンプル申請を貼り付け、Make にバンドルを推論させてから、判定フィールドを HTTP モジュールの本文にマッピングします。
レビュー指示
財務分析ワークスペースのサンプルコンテキストを使用し、リスクレベル、ポリシー例外、承認ルート、推奨レビュー担当者、プロビジョニングステータス、期限、次の推奨アクションを判定し、推奨される次のアクションを具体的に保ちます。アクセス申請リスクレビューでは、HTTP モジュールが Jodoo に書き込む前に、Make バンドル上で申請者、部門、対象アプリケーション、申請ロール、理由、ポリシー例外のフィールドを確認できる状態にします。
書き戻し契約
予測可能な JSON オブジェクトを HTTP モジュール経由で送信します。Jodoo は毎回同じフィールド名を受け取る必要があります。Make は、キャンバス、フィルター、ルーター、モジュール単位の実行履歴で引き継ぎを説明したい運用チームに役立ちます。
必須出力
監査コンテキストとして、リスクレベル、ポリシー例外、承認ルート、推奨レビュー担当者、プロビジョニングステータス、期限、次の推奨アクション、source_platform、agent_confidence、元のワークフロー出力を返します。
Make の管理ポイント
Run once の検証を稼働中のワークフローに切り替える前に、オペレーション使用量、Webhook の担当範囲、シナリオのスケジュールを確認します。HTTP モジュールの周辺にエラーハンドラーを追加し、書き戻し失敗時に再試行するか、手動レビューパスへ移せるようにします。本番申請データを扱う Webhook URL の担当者と、モジュール編集を許可される担当者を文書化します。
アクセス申請の実装メモ
アクセス申請リスクレビューでは、HTTP モジュールが Jodoo に書き込む前に、Make バンドル上で申請者、部門、対象アプリケーション、申請ロール、理由、ポリシー例外のフィールドを確認できる状態にします。最初の書き戻し検証が安定した後、ルーターで低リスクのアクセス変更、マネージャー承認が必要な申請、セキュリティレビューが必要な例外を分岐できます。シナリオ履歴は、各モジュール、オペレーション数、レスポンス本文、受け付けられた Jodoo データ ID を示すため、IT 運用にとって有力な検証材料になります。検証後、Make で通知、承認ブランチ、プロビジョニング引き継ぎ失敗時のエラーハンドラーを追加できます。
{
"requester": "Maya Chen",
"department": "財務",
"requested_system": "財務分析ワークスペース",
"requested_role": "アナリスト",
"access_type": "新規アクセス",
"business_justification": "四半期末レポート作成と差異分析",
"risk_level": "中",
"policy_exception": "プロビジョニング前にマネージャー承認が必要",
"approval_route": "マネージャー承認後、セキュリティレビュー",
"suggested_reviewer": "セキュリティ運用",
"provisioning_status": "承認待ち",
"due_date": "2026-06-12",
"next_best_action": "マネージャー承認を確認し、セキュリティレビューへ回付"
}Jodooスターターアプリ
アクセス申請スターターアプリ
チーム向けにアクセス申請リスクレビューワークフローを適用する際に、フィールドモデル、ビュー、自動化を活用します。
含まれるフィールド
- 申請者
- 部門
- 申請対象システム
- 申請ロール
- アクセス種別
- 業務上の理由
- リスクレベル
- ポリシー例外
- 承認ルート
- 推奨レビュー担当者
- プロビジョニングステータス
- 期限
- 次の推奨アクション
- ソースプラットフォーム
- 元のワークフロー出力
推奨ビュー
- アクセスレビュー待ち
- セキュリティレビューキュー
- マネージャー承認キュー
- プロビジョニング準備完了
- すべてのアクセス申請
自動化ルール
- Make が構造化された出力を返した後、Jodoo レコードを作成します。
- 優先度の高いレコードや例外レコードを適切な担当者キューへ移動します。
- 不足情報または保留理由がある場合、推奨担当者に通知します。
- 監査コンテキストとして元のワークフロー出力を保持します。
展開チェックリスト
本番前に確認すべきこと
- シナリオを有効化する前に、合成データを Custom webhook に送信します。
- 編集後に HTTP モジュールを再度開き、保存済みの JSON マッピングを確認します。
- シナリオ履歴を使って、ステータス、オペレーション、レスポンス本文を確認します。
- 基本の書き戻しが安定してから、ルーター、フィルター、通知を追加します。
- Run once の検証を稼働中のワークフローに切り替える前に、オペレーション使用量、Webhook の担当範囲、シナリオのスケジュールを確認します。
- HTTP モジュールの周辺にエラーハンドラーを追加し、書き戻し失敗時に再試行するか、手動レビューパスへ移せるようにします。
- Webhook URL の担当者と、本番申請データを扱うモジュールの編集を許可される担当者を文書化します。
- 最初の書き戻し検証が安定した後、ルーターで低リスクのアクセス変更、マネージャー承認が必要な申請、セキュリティレビューが必要な例外を分岐できます。
- シナリオ履歴は、各モジュール、オペレーション数、レスポンス本文、受け付けられた Jodoo データ ID を示すため、IT 運用にとって有力な検証材料になります。
- 検証後、Make で通知、承認ブランチ、プロビジョニング引き継ぎ失敗時のエラーハンドラーを追加できます。
ワークフロー
Make のアクセス申請から Jodoo レコードへ
Make が視覚的なシナリオを処理し、Jodoo がチームでフィルター、割り当て、レビューできるレコードを保持します。
Custom webhook が、まず合成データでアクセス申請リスクレビューを受信または開始します。
Make が焦点を絞ったレビュー指示を適用し、リスクレベル、ポリシー例外、承認ルート、推奨レビュー担当者、プロビジョニングステータス、期限、次の推奨アクションを返します。
HTTP モジュールが構造化された出力を Jodoo 書き戻しブリッジに送信し、データ ID を受け取ります。
アクセス申請リスクレビューでは、HTTP モジュールが Jodoo に書き込む前に、Make バンドル上で申請者、部門、対象アプリケーション、申請ロール、理由、ポリシー例外のフィールドを確認できる状態にします。
最初の書き戻し検証が安定した後、ルーターで低リスクのアクセス変更、マネージャー承認が必要な申請、セキュリティレビューが必要な例外を分岐できます。
シナリオ履歴は、各モジュール、オペレーション数、レスポンス本文、受け付けられた Jodoo データ ID を示すため、IT 運用にとって有力な検証材料になります。
検証後、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 の担当範囲、シナリオのスケジュールを確認します。