【Okta】Workflows委任フローのCaller入力フィールドを活用したAccess Requests連携 | Nextmode Blog

はじめに

こんにちは、ネクストモード株式会社のゆきなわです。

Okta Identity Engine (OIE) の 2025年12月リリースにて、Okta Workflows の Delegated Flow（委任フロー）にアップデートがありました。それが今回ご紹介する [Caller（呼び出し元）] 入力フィールドの追加です。

Okta Identity Governance (OIG) の Access Requests 機能を利用している環境において、承認後の Workflows による自動化処理を実装する際、これまでは「どのトリガー方式でフローを起動するか」「データの受け渡しをどうするか」という点で検討が必要でした。

今回の新機能によって、Access Requests から Delegated Flow を直接起動するアクション駆動による連携がより使いやすくなりました。本記事では、従来の手法（イベント駆動 vs アクション駆動）を整理しつつ、Delegated Flow に追加された新機能である Caller 入力フィールドを活用した構成をご紹介します。

参考リリースノート
Okta Identity Engine Release Notes - Production Version: 2025.12.0

Workflows 連携の2つのアプローチと課題

Access Requests の承認完了後に Workflows を起動する場合、主に2つのアプローチがあります。
それぞれの特徴とこれまでの課題を整理した後、今回新たに加わった Caller 入力フィールドによる解決策を示します。

1. イベント駆動 (Access Request Resolved イベントによるフローの起動)

Okta の Access Request Resolved イベントカードをトリガーにフローを起動する方法です。

• 特徴: Access Requests 全体で発生するリクエスト完了のイベントを検知します。
  ※Okta のアプリケーションイベントは、指定されたイベントが発生すると Webhook 経由で Workflows に通知されます（help.okta.com)。
• 課題: すべてのリクエスト完了時にフローが発火するため、特定のリクエスト（例：アカウント作成申請）だけで処理を行いたい場合、フロー側で条件分岐（If/Else）を作成してイベントをフィルタリングする必要がありました。

2. アクション駆動 (承認後のアクションとしてフローを起動)

Request Type の設定画面で、承認後のアクションのタイプとして [Okta] Run a workflow を指定し、特定の Delegated Flow を直接呼び出す方法です。

• 特徴: 特定のリクエストに対してのみ、明示的にフローを起動できます。不要な発火がなく、構成がシンプルです。
• 課題: フロー側で必要な情報（プロビジョニング時の例: 姓、名、部署、利用期間など）をすべてフローへの入力引数として定義し、Access Requests 側で一つ一つ手動でマッピング設定をする必要がありました。申請フォームに項目が一つ増えるたびに、Workflows の入力定義を変更し、Access Requests のマッピングもやり直す手間が発生していました。

※ご注意
Access Requests から直接 Delegated Flow を呼び出すアクション駆動は、本記事執筆時点で Early Access (早期アクセス) 機能となっています。
ご利用の際は環境設定をご確認ください。

リクエストタイプを作成する - Okta Help Center

新機能: Caller 入力フィールドによる解決策

今回のアップデートにより、2つ目のアクション駆動アプローチにおいて、Delegated Flow 側で、フローの呼び出し元（実行元）の情報を持つ Caller オブジェクトを実行時の入力として受け取れるようになりました。

例えば、Okta Admin Console メニュー [Workflows（ワークフロー）] > [Delegated flows（委任されたフロー）] からフローをマニュアル実行した場合は、実行したユーザーの username、id を含む情報が、また、Access Requests からフローを実行した場合は、該当するリクエストの ID (requestId) を含む情報が Caller オブジェクトとして自動的に入力されます。

これにより、Access Requests と Workflows の連携において以下の構成が可能になります。

1. アクション駆動で起動: 必要なリクエストタイプからフローを呼ぶ（イベント駆動のフィルタリング処理を回避）
2. 呼び出し元イベントの ID 取得: Access Requests は Workflows に requestId を自動的に渡す（手動マッピング不要）
3. API による詳細情報の取得: Workflows はその ID を使って API を呼び出し、申請内容の詳細情報を取得する

つまり、イベント駆動のようにデータを手軽に取得しつつ、アクション駆動の明確さでフローを制御する構成が実現できます。

今回の検証シナリオと前提

今回は、ユーザーが Okta Identity Governance の Access Requests (Request Types) で申請を行い、承認された後に Workflows を自動実行させるシナリオを想定します。

前提1：Request Types の利用

Access Requests には大きく分けて Request Types（リクエストタイプ）と Conditions（条件）の2つの設定方法があります。今回は Request Types を利用します。

Request Types は、リクエストのライフサイクルを定義する構造化フローです (help.okta.com)。質問、タスク、タイマーなどのステップから構成され、Teams、Slack、Jira 、ServiceNow などの外部システムとの統合も可能です。

Request Types の概要と基本的な作成方法については、過去のブログ記事をご参照ください。

今回は Request Type の一例として、下図の姓、名、メールアドレス、所属グループ、入社日をフォーム入力項目として持つ、新規アカウント作成申請を想定したフローを作成するものとします。

前提2：承認後のアクション設定

Access Requests の承認完了後のアクションとして [Okta] Run a workflow を設定し、起動する Delegated Flow を指定します。指定したフローには明示的な入力フィールドを設けず、Request Type のフォームに入力されたフィールド値のマッピングは行いません。

なお、Access Requests で Run a workflow アクションを使用するには、事前準備が必要です (help.okta.com)。以下の設定手順を参照してください。

1. 委任フローの作成: Workflows コンソールで Delegated Flow を作成し、アクティブにする
2. カスタム管理者ロールの設定:
   • 「Run delegated flow（委任されたフローを実行）」権限を持つロールを作成
   • 実行する委任フローをリソースセットに含める
   • このロールとリソースセットを Okta Access Request OAuth アプリケーションに割り当てる
3. 統合設定の有効化:
   

• • Access Requests コンソールの左メニューの Settings をクリックし、Integrations タブを開く
  • Access Request Configurations の Edit connection をクリックする
  • Teams セクションで Select teams をクリックし Requests Types を管理するチームを選択する
  • Actions セクションで Run a workflow トグルを有効にして（下図）、Update connection ボタンをクリックする
    

実装ステップ

それでは、実際の Workflows 実装を見ていきましょう。

Step 1: Delegated Flow で Request ID を取得する

まず、Workflows のトリガーカード（Delegated Flow）を確認します。新しく Caller というオブジェクト入力フィールドが追加されています。

Access Requests から Delegated Flow が呼び出されると、Caller 入力フィールドに呼び出し元の情報を含む Caller オブジェクトが格納されます。オブジェクトの中にある ID フィールドには、Access Requests の一意な Request ID（下図例: 695b2f50...）が格納されているので、これを後続の処理で使用します。

Step 2: OIG API で申請内容詳細を取得する

取得した ID を使い、Okta Connector の Custom API Action カードなどで Okta Identity Governance API リクエストを実行します。今回は Request Types で作成されたリクエストを取得するため、以下の Access Requests V1 API を使用します。

• Endpoint: /governance/api/v1/requests/{requestId}
• Method: GET

補足: API バージョンの使い分け
今回は Request Types を対象としているため v1/requests エンドポイントを使用しています。
Access Requests Conditions で作成されたリクエストを扱う場合は、API のスキーマが異なるため、Access Requests V2 API (/governance/api/v2/requests/{requestId}) を使用してください。

API で取得した詳細情報

API から返却されるレスポンス (JSON) には、入力フォームの値を示す requesterFieldValues だけでなく、approvals、createdBy のようなリクエストに関するメタ情報も含まれています。

• requesterFieldValues: ユーザーが入力した値（姓、名、所属グループなど）
• approvals: 誰がいつ承認したか（approverName、decided など）
• createdBy: 申請者情報

このように、従来のアクション駆動によるマッピング方式では取得しにくかった承認者のコメントや承認日時なども、Caller 入力フィールドから得られるリクエスト ID 情報を用いて、API 経由で取得することが可能です。

Step 3: データの整形 (Pluck & Zip の利用)

API で取得した requesterFieldValues は、フォーム入力項目のキーに対応する prompt と値に対応する value を含むオブジェクトのリスト形式になっているため、そのままだと扱いづらい場合があります（下図）。

1. List - Pluck: prompt（項目名）だけのリストを作成
2. List - Pluck: value（入力値）だけのリストを作成
3. Object - Zip: 2つのリストを結合してオブジェクトを作成

List - Pluck と Object - Zip カードによるオブジェクト作成の処理フロー

これにより、{"姓": "Yamada", "名": "Taro"} のようなシンプルなオブジェクトに変換でき、後続のアクション（プロビジョニングや Slack 通知など）で値を参照しやすくなります。

あとは、ユーザープロビジョニングや通知に関するカードを用い、要件に応じた具体的な処理を実装していく流れとなります。

まとめ

Delegated Flow の新機能 Caller 入力フィールドを活用することで、Access Requests と Workflows の連携をより疎結合でメンテナンスしやすい形にできます。

• メンテナンス性: フォーム項目の変更に伴う Workflows の引数修正やマッピング変更が不要になる
• 情報量: API 経由で、承認者情報やタイムスタンプなどのメタデータも活用できる
• 制御のしやすさ: アクション駆動（Delegated Flow）を利用することで、イベント駆動のようなフィルタリング条件を書く必要がなく、余計なフローの起動を抑制できる

Access Requests の自動化を設計される際は、この Caller 入力フィールド + API によるリクエスト詳細情報の取得の構成をぜひご検討ください。

Okta についてのお問い合わせ

Okta Identity Governance と Okta Workflows による業務フローの自動化、Okta のライセンス体系や価格などについてさらに詳しく知りたい方は、ぜひ弊社窓口までお気軽にお問い合わせください。