はじめに こんにちは、 ネクストモード株式会社 のSaaSおじさん久住です...
【Okta | OIGシリーズ】Access RequestsでWorkflowsを実行するための権限設定
はじめに
こんにちは、 ネクストモード株式会社 のSaaSおじさん久住です
ネクストモードではID統合管理(IDaaS)のOktaを利用して各SaaSへのシングル・サインオンやプロビジョニングの一元管理をしています。
今回は、シリーズでお届けしているOkta Identity Governance (OIG) と呼ばれるIDガバナンスに特化したソリューションで「Access Requestsの設定画面で、なぜかWorkflowsの一覧が表示されない!」という、思わぬ落とし穴にはまってしまった原因と具体的な解決手順を詳しく解説していきます。
ことの始まり - Access RequestでWorkflowsが選べない!
Okta Identity Governance (OIG) の中核機能の一つである Access Requests。
これを利用することで、ユーザーは必要なリソースへのアクセス権をセルフサービスで申請し、管理者は定義されたワークフローに沿って承認できます。
このAccess Requestsのアクションとして Okta Workflows を呼び出すことで、「アカウントが作成されたら、特定のSlackチャンネルに通知する」「ライセンスを割り当てたら、利用方法の案内メールを自動送信する」といった、より高度で柔軟な自動化が実現できます。
Access RequestsからWorkflowsを実行する設定については別ブログでご紹介しますが、この連携を検証しようとしたところ、Access Requestsのリクエストタイプ設定画面で、肝心のWorkflowsが一覧に表示されないという事象に遭遇しました。
確認済みの設定項目
すでに設定を確認していた項目を記載します。
Early Access(EA)機能の有効化
アクセスリクエストからOkta Workflowsを実行する機能は2025/8/26時点でEA機能となっています。
そのため、Okta管理画面の設定 → 機能から「アクセスリクエストでのOkta WOrkflowsアクション」を有効化する必要があります。

Access Requests設定
Access Requestsの管理画面上でSettings → Integrations → OktaのEdit connectionにおいてRun Workflowsにチェック済みであることも確認しました。
管理者権限
操作している管理者はスーパー管理者権限を保有しているのでWorkflowsへのフルアクセス権限も付与済みでした。
基本的な設定はすべて行っているはずなのに、なぜWorkflowsが表示されないのでしょうか?
原因と解決策:Access Requests専用のカスタム権限設定
結論から言うと、原因はAccess RequestsがWorkflowsをAPI経由で呼び出すための、より詳細な権限設定が不足していたことでした。
スーパー管理者であっても、Access Requestsのシステムが内部的にWorkflowsの情報を取得するためには、OAuthベースの明確な権限委任が必要となります。
これを解決するためには、以下の手順でカスタムロールとリソースセットを作成し、Access Requestsが必要とする権限を明示的に付与する必要があります。
設定手順
これから紹介する手順は、Oktaの公式ドキュメント「リクエストタイプを作成する」の前提条件にも関連する内容です。特に、Workflowsのような他のOkta機能を呼び出す際には、このようなリソースベースの権限設定が重要になります。
1. カスタムロールの作成
まず、Access RequestsにWorkflowsの実行権限を与えるための専用ロールを作成します。
-
Okta管理コンソールの セキュリティ → 管理者 に移動します。
-
ロール タブを選択し、「新しいロールを作成」をクリックします。
-
ロール名と説明を入力します。(例: Delegated Workflows Admin)
-
権限を選択から「Workflow」を探し、以下の権限にチェックを入れます。
-
委任されたフローを表示
- 委任されたフローを実行
-
-
「ロールを保存」をクリックして保存します。
2. リソースセットの作成
次に、作成したロールをどのリソース(今回はすべてのWorkflow)に適用するかを定義する「リソースセット」を作成します。
-
管理者 → リソース タブを選択し、「新しいリソースセットを作成」をクリックします。
-
リソースセット名と説明を入力します。(例:
Access Request Workflows
) -
リソースの追加を押してリソースタイプを検索で「Workflows」を選択し、ラジオボタンで「すべてのフロー」を選択します。
-
「選択を保存」をクリックしてリソースセットの作成をクリックします。
3. リソースセットへのカスタムロールの割り当て
最後に、作成したリソースセットとカスタムロールを紐づけ、Access Requestsのサービスプリンシパルに権限を割り当てます。
-
作成したリソースセット(Access Request Workflows)の編集から割り当てを表示または編集をクリックします。
-
管理者 の項目で、Okta Access Requestと入力して検索し、表示された Okta Access Request OAuthを選択します。
-
ロール のドロップダウンから、手順1で作成したカスタムロール(Delegated Workflows Admin)を選択します。
-
「変更を保存」をクリックします。
以上の設定が完了すると、Access Requestsのシステムは、作成された権限を通じてWorkflowsの一覧を正しく読み込めるようになります。
設定後、再度Access Requestsのリクエストタイプ設定画面を開くと、無事にWorkflowsが一覧に表示され、選択できるようになっているはずです。
おわりに
Okta Identity Governance (OIG) は、ID管理の課題を解決する強力なソリューションですが、各機能が連携する際の詳細な権限設定でつまずくこともあります。今回の事象は、まさにその一例でした。
本ブログでは、これまでにもアクセス申請、アクセス権の棚卸し(レビュー)、権限管理(エンタイトルメント管理)、そして職務分離(SoD)といったOIGの主要機能に関するブログを執筆してきました。これらの記事を以下にまとめておきますので、ご興味のある方はぜひご覧ください。
OIGを活用することで、アクセス権限を効率的かつセキュアに管理し、不正アクセスや内部統制のリスクを大幅に軽減できます。
導入をご検討の際は、ぜひネクストモードにご相談ください!