---
title: 【Okta】ID-JAGの設計思想から読み解くCross App Accessの背景と技術の裏側【生成AIセキュリティ対策シリーズ】｜Nextmode Blog
description: OktaのCross App AccessとID-JAGの仕組みを解説し、AIエージェント時代のセキュリティ設計について考察します。
image: https://info.nextmode.co.jp/hubfs/%E3%83%96%E3%83%AD%E3%82%B0%EF%BC%BF%E3%82%AD%E3%83%BC%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB/%E7%94%9F%E6%88%90AI%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3_Okta.png
---

[![nextmode blog](https://info.nextmode.co.jp/hubfs/raw_assets/public/NextMode_Theme/nextmode%20blog.png)](https://info.nextmode.co.jp/blog)

[ホワイトペーパー](https://info.nextmode.co.jp/white-paper/) [資料請求](https://info.nextmode.co.jp/request/) [お問い合わせ](https://nextmode.co.jp/contact/)

- [会社TOP](https://nextmode.co.jp/)
- [生成AIセキュリティ](https://nextmode.co.jp/services/ai/security/)
- [SaaSライセンス＆サポート](https://nextmode.co.jp/services/saas/)
  
    - [Oktaライセンス＆サポート](https://nextmode.co.jp/services/saas/okta/)
    - [Netskopeライセンス＆サポート](https://nextmode.co.jp/services/saas/netskope/)
    - [Notionライセンス＆サポート](https://nextmode.co.jp/services/saas/notion/)
    - [Asanaライセンス＆サポート](https://nextmode.co.jp/services/saas/asana/)
    - [SysCloudライセンス＆サポート](https://nextmode.co.jp/services/saas/syscloud/)
    - [CrowdStrikeライセンス＆サポート](https://nextmode.co.jp/services/saas/crowdstrike/)
- [AWS総合支援](https://nextmode.co.jp/services/aws/)
  
    - [AWS導入コンサル・構築](https://nextmode.co.jp/services/aws_consulting/)
    - [AWS運用・保守代行](https://nextmode.co.jp/services/aws_operation/)
- [導入事例](https://nextmode.co.jp/casestudy/)
- [会社情報](https://nextmode.co.jp/company/)
- [セミナー](https://info.nextmode.co.jp/seminar/)
- [ブログ](https://info.nextmode.co.jp/blog)

[![YouTube](https://nextmode.co.jp/assets/images/common/icon_youtube.svg)](https://www.youtube.com/@nextmode) <https://x.com/Nextmode_Inc>

目次

 2025/12/01 18:16

# 【Okta】ID-JAGの設計思想から読み解くCross App Accessの背景と技術の裏側【生成AIセキュリティ対策シリーズ】

[» Okta](https://info.nextmode.co.jp/blog/tag/okta) [» 技術](https://info.nextmode.co.jp/blog/tag/技術) [» 生成AIセキュリティ対策シリーズ](https://info.nextmode.co.jp/blog/tag/生成aiセキュリティ対策シリーズ)

[テクニカルサポート](https://info.nextmode.co.jp/blog/author/tech-support)

共有： [facebook-f icon](http://www.facebook.com/share.php?u=https://info.nextmode.co.jp/blog/okta-id-jag-cross-app-access-tech) [linkedin-in icon](http://www.linkedin.com/shareArticle?mini=true&url=https://info.nextmode.co.jp/blog/okta-id-jag-cross-app-access-tech) [Twitter icon](https://twitter.com/intent/tweet?url=https://info.nextmode.co.jp/blog/okta-id-jag-cross-app-access-tech) [pinterest-p icon](http://pinterest.com/pin/create/link/?url=https://info.nextmode.co.jp/blog/okta-id-jag-cross-app-access-tech) [envelope icon](mailto:?body=https://info.nextmode.co.jp/blog/okta-id-jag-cross-app-access-tech)

## はじめに

こんにちは、[ネクストモード株式会社](https://nextmode.co.jp/)テクニカルサポート担当です。

前回Cross App Accessについての検証ブログを公開致しましたが、そもそもCross App Accessとはどのような考えにもとづくのか、背景にあるID-JAG(Identity Assertion JWT Authorization Grant)に触れながら少し深ぼってみようと思います。

<iframe class="hatenablogcard" style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; border: none;" src="https://hatenablog-parts.com/embed?url=https://info.nextmode.co.jp/blog/okta-cross-app-access-ai-agent" width="600" height="150" frameborder="0" scrolling="no">
</iframe>

 

 

本記事では、以下の観点から考察します。これらを整理することで、AIエージェント時代のセキュリティ設計を紐解いていきます。

- どのような課題を解決しようとしているのか
- 背景にある**ID-JAG**の仕組み
- 企業のAIエージェント基盤を設計する際、認可をどう捉えるべきか

 

## Cross App Accessが解決したい課題

### 課題：Cross App Accessが登場前の世界

企業内でMCPサーバーの利用が増え、AIエージェントが乱立し始めると、以下のような課題に直面します。

- 「このAIエージェントを経費精算システムやCRMに接続したいが、どこまでアクセスを許可すべきか判断できない」
- 「MCPサーバーとの連携で、ユーザー自身にAPIキーの管理を任せることに不安がある」
- 「連携のたびにユーザーにOAuthの同意画面を承認させるのは現実的ではない」
- 「どのエージェントが、いつ、どのシステムにアクセスしたのかを確認する手段がない」

 

### 解決：Cross App Accessが実現する世界

OktaのCross App Accessは、「アプリ間の認可」を個々のアプリ任せにせず、IdP(Identity Provider)の管理下で一元的に制御する仕組みです。

これにより、ユーザーは煩わしいOAuth同意画面から解放され、管理者は認可ポリシーとアクセスログを一箇所で管理できるようになります。

 

## なぜ「アプリ間の認可」が課題となるのか

まず、AIエージェント導入におけるよくあるシナリオから考えてみましょう。

### AIアシスタント「Aria」の一日

ある企業で、情シス部門がAIアシスタント「Aria」を導入したとします。このAIエージェントは、社員の代わりに次のようなタスクを自律的に行います。

- 社員のカレンダーを確認し、空き時間にミーティングを設定する
- 経費精算SaaSから「承認待ち申請」を取得し、サマリを送る
- CRMから顧客情報を取得し、訪問直前の顧客の要約をSlackで通知する

これらはすべて「ユーザー本人に代わって、AIエージェントが他のSaaSのAPIを実行」する動作です。この時、管理者は3つの壁に直面します。

1. **OAuth同意の氾濫**  
   連携先(カレンダー、経費、CRM…)が増えるたびにユーザーへ同意を求めると、体験が悪化し、ユーザーが何も確認せずに「承認」ボタンを押す習慣がついてしまいます。
2. **ガバナンスの分散**  
   「どのAIエージェントが、誰のデータに対して、どんな権限を持っているか」を確認するために、各SaaSの管理画面を巡回しなければなりません。
3. **監査と停止の困難さ**  
   インシデント時に「このAIエージェントの権限だけを一括で停止したい」と考えても、各SaaSに発行されたトークンを個別に無効化する必要があります。

従来のOAuth 2.0は「ユーザー←→アプリ」の1対1の関係には強力ですが、「多数のアプリ←→多数のアプリ」を一元管理する観点は手薄になりがちです。

Cross App Accessは、このギャップを埋めるために設計されました。

> 「AIエージェントと業務アプリの信頼関係は、ユーザー個人の同意ではなく、IdP管理者のポリシー設定で決定する」

この点が最大の特徴です。

 

## Cross App Accessとは

Cross App Accessの仕組みを簡潔に表現すると、以下のようになります。

- ユーザーはOktaに一度ログインするだけでよい
- 「どのエージェントが、どの業務アプリに代理アクセス可能か」は、Okta管理者が**Managed connection**として事前に定義する
- AIエージェントは、その許可設定に基づいてOktaから業務アプリ用のアクセストークンを取得する

この関係性を整理するために、用語を定義しておきます。

| **用語** | **役割・イメージ** |
| --- | --- |
| **Requesting App** | 代理でAPIを呼ぶ側(例：AIアシスタント「Aria」) |
| **Resource App** | データを持つ側(例：経費精算SaaS) |
| **Managed Connection** | 上記2つの「事前に許可された接続ルート」 |
| **Cross App Access** | これらを統合管理するOktaの機能群 |

ポイントは、**「ユーザー単位の同意(Consent)」ではなく、「アプリ間の接続単位の許可」を扱う** という点です。

 

## 「誰が、誰の代わりに、どのトークンを得るのか？」

ここからは少し技術的な仕組みに踏み込みます。

AIアシスタント「Aria」が社員Bさんの経費データにアクセスする際、システムの裏側では以下の3点を検証する必要があります。

1. AIエージェントは**誰の代わりに**動いているのか？(社員Bさん)
2. 読みたいデータは**どのアプリ**にあるのか？(経費SaaS)
3. その組み合わせは**管理者に許可されているか？**

Cross App Accessは、ID-JAGでこれらを解決します。具体的な流れは以下の通りです。

1. Oktaが「このユーザーは社員Bさんです」という署名付き証明書(**Identity Assertion**)をAIエージェントに渡す
2. AIエージェントがその証明書を提示し、「社員Bさんとして経費SaaSにアクセスするトークンをください」とOktaに要求する
3. OktaがManaged Connectionを確認し、許可されていればアクセストークンを発行する

 

## ID-JAGのフローを理解する

ID-JAGは[IETFのOAuthワーキンググループで議論されている仕様](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/)で、「Identity Assertion(身元の主張)を用いてアクセストークンを取得する」ための Grant Type です。

ID-JAGの最新の仕様は以下のGitHubで確認することができます。

<iframe class="hatenablogcard" style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; border: none;" src="https://hatenablog-parts.com/embed?url=https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/blob/main/draft-ietf-oauth-identity-assertion-authz-grant.md" width="600" height="150" frameborder="0" scrolling="no">
</iframe>

 

### 登場人物

- **ユーザー**：社員Bさん
- **Requesting App**：AIアシスタント「Aria」
- **Resource App**：経費精算SaaS
- **IdP / Authorization Server**：Okta

### ID-JAGの詳細フロー

ここからは、実際のプロトコルレベルでの動作を、シーケンス図とともに詳しく見ていきます。

### 全体のシーケンス図

以下は、全体のフローを示したシーケンス図です。（クリックで拡大できます。）

[![ID-JAGのシーケンス図](https://info.nextmode.co.jp/hs-fs/hubfs/okta-id-jag-cross-app-access-tech-01.png?width=3394&height=2457&name=okta-id-jag-cross-app-access-tech-01.png)](https://info.nextmode.co.jp/hubfs/okta-id-jag-cross-app-access-tech-01.png)

[https://developer.okta.com/blog/2025/06/23/enterprise-ai](https://developer.okta.com/blog/2025/06/23/enterprise-ai) をもとに作成

 

### Step1～7：ユーザーがOktaにログイン(SSO)

社員Bさんは通常通りOktaにサインインし、AIアシスタント「Aria」を利用開始します。ここまでは一般的なOpenID Connect(OIDC)のフローです。

1. クライアント(Aria)がログインリクエストを開始
2. ユーザーのブラウザがIdP(Okta)にリダイレクト
3. ユーザーがIdPにログイン
4. IdPが認可コードをブラウザに返却
5. ブラウザが認可コードをクライアントに渡す
6. クライアントが認可コードをIDトークンに交換
7. IdPがIDトークンを返却

この時点で、ユーザーはAriaにログインした状態になります。

### Step8～10：エージェントが「Identity Assertion JWT」を取得(Token Exchange)

次に、AriaはOktaに対してToken Exchange(RFC 8693)リクエストを送信します。

<iframe src="https://carbon.now.sh/embed?bg=rgba%28255%2C255%2C255%2C1%29&amp;t=seti&amp;wt=none&amp;l=htmlmixed&amp;width=680&amp;ds=true&amp;dsyoff=20px&amp;dsblur=68px&amp;wc=true&amp;wa=true&amp;pv=56px&amp;ph=56px&amp;ln=false&amp;fl=1&amp;fm=Hack&amp;fs=14px&amp;lh=133%25&amp;si=false&amp;es=2x&amp;wm=false&amp;code=POST%2520%252Foauth2%252Ftoken%2520HTTP%252F1.1%250AHost%253A%2520acme.okta.com%250AContent-Type%253A%2520application%252Fx-www-form-urlencoded%250A%250Agrant_type%253Durn%253Aietf%253Aparams%253Aoauth%253Agrant-type%253Atoken-exchange%250A%2526requested_token_type%253Durn%253Aietf%253Aparams%253Aoauth%253Atoken-type%253Aid-jag%250A%2526audience%253Dhttps%253A%252F%252Fauth.saas.com%252F%250A%2526subject_token%253DeyJraWQiOiJzMTZ0cVNtODhwREo4VGZCXzdrSEtQ...%250A%2526subject_token_type%253Durn%253Aietf%253Aparams%253Aoauth%253Atoken-type%253Aid_token%250A%2526client_assertion_type%253Durn%253Aietf%253Aparams%253Aoauth%253Aclient-assertion-type%253Ajwt-bearer%250A%2526client_assertion%253DeyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0..." style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; border: none;" sandbox="allow-scripts allow-same-origin" width="256" height="NaN">
</iframe>

主なパラメータ

- `requested_token_type` ：ID-JAGを要求
- `audience`：リソースアプリ(経費SaaS)の認可サーバーのIssuer URL
- `subject_token`： Step7で取得したIDトークン
- `subject_token_type`： IDトークンであることを示す識別子

### Step9：IdPによる検証とポリシー評価

Oktaは以下のチェックを実行します。

- IDトークンが、リクエストを送信しているクライアント(Aria)に発行されたものか
- ユーザー(社員Bさん)が存在し、アクティブな状態か
- ユーザーがリソースアプリ(経費SaaS)に割り当てられているか
- **管理者が設定したManaged Connectionで、この接続(Aria→経費SaaS)が許可されているか**

すべての検証をクリアすると、OktaはID-JAGを発行します。

<iframe src="https://carbon.now.sh/embed?bg=rgba%28255%2C255%2C255%2C1%29&amp;t=seti&amp;wt=none&amp;l=application%2Fjson&amp;width=680&amp;ds=true&amp;dsyoff=20px&amp;dsblur=68px&amp;wc=true&amp;wa=true&amp;pv=56px&amp;ph=56px&amp;ln=false&amp;fl=1&amp;fm=Hack&amp;fs=14px&amp;lh=133%25&amp;si=false&amp;es=2x&amp;wm=false&amp;code=%257B%250A%2520%2520%2522issued_token_type%2522%253A%2520%2522urn%253Aietf%253Aparams%253Aoauth%253Atoken-type%253Aid-jag%2522%252C%250A%2520%2520%2522access_token%2522%253A%2520%2522eyJhbGciOiJIUzI1NiIsI...%2522%252C%250A%2520%2520%2522token_type%2522%253A%2520%2522N_A%2522%252C%250A%2520%2520%2522expires_in%2522%253A%2520300%250A%257D" style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; border: none;" sandbox="allow-scripts allow-same-origin" width="256" height="NaN">
</iframe>

このJWTは、Oktaが通常IDトークンに署名するのと同じ鍵で署名されています。これにより、リソースアプリ側はSSO設定で既に知っている公開鍵を使って検証できます。

### Step11～13：ID-JAGを使ってアクセストークンを取得

Ariaは、取得したID-JAGを持って、経費SaaSの認可サーバーにアクセストークンをリクエストします。これはJWT Bearer Authorization Grant(RFC 7523)の形式です。

<iframe src="https://carbon.now.sh/embed?bg=rgba%28255%2C255%2C255%2C1%29&amp;t=seti&amp;wt=none&amp;l=htmlmixed&amp;width=680&amp;ds=true&amp;dsyoff=20px&amp;dsblur=68px&amp;wc=true&amp;wa=true&amp;pv=56px&amp;ph=56px&amp;ln=false&amp;fl=1&amp;fm=Hack&amp;fs=14px&amp;lh=133%25&amp;si=false&amp;es=2x&amp;wm=false&amp;code=POST%2520%252Foauth2%252Ftoken%2520HTTP%252F1.1%250AHost%253A%2520auth.saas.com%250AAuthorization%253A%2520Basic%2520yZS1yYW5kb20tc2VjcmV0v3JOkF0XG5Qx2%250A%250Agrant_type%253Durn%253Aietf%253Aparams%253Aoauth%253Agrant-type%253Ajwt-bearer%250A%2526assertion%253DeyJhbGciOiJIUzI1NiIsI..." style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; border: none;" sandbox="allow-scripts allow-same-origin" width="256" height="NaN">
</iframe>

```
経費SaaSの認可サーバーは以下を実施します。
```

- JWTのIssuer(発行者)を確認し、どのIdP(Okta)から来たトークンかを特定
- Oktaの公開鍵を使ってJWTの署名を検証
- その他のクレーム(audience、expiration等)を検証

検証が成功すると、経費SaaSはアクセストークンを発行します。

<iframe src="https://carbon.now.sh/embed?bg=rgba%28255%2C255%2C255%2C1%29&amp;t=seti&amp;wt=none&amp;l=application%2Fjson&amp;width=680&amp;ds=true&amp;dsyoff=20px&amp;dsblur=68px&amp;wc=true&amp;wa=true&amp;pv=56px&amp;ph=56px&amp;ln=false&amp;fl=1&amp;fm=Hack&amp;fs=14px&amp;lh=133%25&amp;si=false&amp;es=2x&amp;wm=false&amp;code=%257B%250A%2520%2520%2522token_type%2522%253A%2520%2522Bearer%2522%252C%250A%2520%2520%2522access_token%2522%253A%2520%25222YotnFZFEjr1zCsicMWpAA%2522%252C%250A%2520%2520%2522expires_in%2522%253A%252086400%250A%257D" style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; border: none;" sandbox="allow-scripts allow-same-origin" width="256" height="NaN">
</iframe>

### Step14～15：リソースへのアクセス

Ariaは取得したアクセストークンを使って、経費SaaSのAPIにリクエストを送信します。これは通常のOAuthフローで取得したトークンと同じように機能します。

 

## 単なるToken Exchangeとの違い

「既存のToken Exchange(RFC 8693)やJWT Bearerと何が違うのか？」と思われるかもしれません。

技術的なベースは同じですが、Cross App Accessとして実装されることで運用上のインパクトが大きく異なります。

### アプリ間の「道」を管理者が設計できる

- **従来：**開発者が個別にOAuth連携を実装し、管理者は感知しにくい。
- **Cross App Access**：「このAIエージェントは、このSaaSとだけ繋がって良い」というルールを、Okta管理者がコンソール上で一元管理できます。

 

### トレーサビリティの向上

Identity Assertion には「どのユーザーが、どのエージェントを使って、どのリソースへ行こうとしたか」という情報が含まれます。IdPが発行の起点となるため、「いつ、誰が、どのAIエージェントでデータに触れたか」をIdPのログから追跡可能になります。

 

### 緊急停止(Kill Switch)の明確化

インシデント発生時、IdP側で停止ポイントを制御できます。

- 特定のユーザーのみAIエージェント利用を停止したい → **ユーザー単位の無効化**
- AIエージェント自体に欠陥が見つかった → **Managed Connectionの無効化**(全ユーザーに対し、そのAIエージェントからのアクセスを即時遮断)

 

## AIエージェント・MCPとの親和性

昨今のMCP(Model Context Protocol)などのトレンドは、「AIエージェントから見たツール呼び出しの標準化」に注力しています。しかし、「そのツールの裏側でどう認証認可を通すか」は実装者に委ねられています。

Cross App Access・ID-JAGの考え方を取り入れると、以下のように役割分担できます。

- **認可ロジック(Oktaに集約)** 
    - OAuthの複雑な処理、ポリシー判定、監査ログ
- **ツール・エージェント側(シンプル化)** 
    - 「どのResource Appを呼びたいか」「どのスコープが必要か」だけを知っていれば良い

これにより、エージェントやツールが増えても認可のガバナンスが破綻しにくくなります。Oktaを利用しない場合でも、「ユーザーの身元と代理関係を1つのトークンに封入して検証する」というID-JAGの設計パターンは、セキュアなエージェント基盤構築の参考になるはずです。

 

## 将来的な導入検討のポイント

Cross App AccessやID-JAGは、まだ採用しているSaaSやAIエージェントがほとんどない新しい仕組みです。しかし、将来的にAIエージェントの活用が広がった際に備えて、以下の観点を整理しておくとよいと思います。

- IdPへの委任範囲の検討：すべてのアプリ間連携をこの仕組みに移行するのか、それとも「AIエージェント ↔ 主要SaaS」のようなハイリスクな連携に絞るのか。
- 既存実装との共存計画：すでに各SaaSと直接OAuth連携しているアプリがある場合、新しい仕組みとどう共存させるか、移行のタイミングをどう設計するか。
- スコープ設計の粒度：Resource App側で「読取専用」「書込許可」「管理者権限」など、適切な粒度のスコープが用意されているか、将来的に必要になるか。
- 監査ログの運用体制：「誰が・何を使って・どこにアクセスしたか」のログを、将来的にどう管理・モニタリングするかの体制を検討する。

 

## おわりに

本記事では、Okta Cross App Accessの背後にあるID-JAG(Identity Assertion JWT Authorization Grant)という考え方を中心に解説しました。

ID-JAGの本質は、**「誰が、誰の代わりに、どのリソースにアクセスしているのか」という代理関係を、1つのJWTトークン(Identity Assertion)に封入し、IdPが一元的に発行・検証する**という点にあります。

これにより、以下のメリットが生まれます。

- アプリ間の信頼関係をIdPに集約し、管理者が一元管理できる
- 「誰が・どのエージェントで・どこにアクセスしたか」のトレーサビリティが向上する
- インシデント時の緊急停止ポイントが明確化される

AIエージェントが企業システムに組み込まれていく時代において、ID-JAGの設計パターンは、セキュアな認可基盤を構築するための重要な指針となるはずです。

これから自社のAIエージェント基盤を設計される方は、ぜひID-JAGの考え方を参考にしてみてください。

[![SaaSバナー\_Okta](https://hubspot-no-cache-na2-prod.s3.amazonaws.com/cta/default/20481958/interactive-256988631778.png)](https://info.nextmode.co.jp/hs/cta/wi/redirect?encryptedPayload=AVxigLLq0xi7TjbyOhSqQa6ELKuyUAw041SZRGl%2F0AKY4aZ3NDPaWu8kAE%2B0PfI93XrcXjLXQsr0m7EgqPPC%2FXPsmBi7ZhF1dFEFC81NM1OWTUxZ5ETTa82m7iRlGOwxCCVvym1MGOBjkc600TPxx4R%2BEVS9JLgx3MM0GQKtylaJLIzyhdnmqrAiVOFAilvHCh0CUgSwEZ3MwjmWEetsED40%2FCtB&webInteractiveContentId=256988631778&portalId=20481958)

### 関連記事

[![【Okta】Okta for AI Agents 検証記事まとめ：AI エージェントの登録・接続制御・可視化【生成AIセキュリティ対策シリーズ】](https://info.nextmode.co.jp/hubfs/%E3%83%96%E3%83%AD%E3%82%B0%EF%BC%BF%E3%82%AD%E3%83%BC%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB/%E7%94%9F%E6%88%90AI%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3_Okta.png) 【Okta】Okta for AI Agents 検証記事まとめ：AI エージェントの登録・接続制御・可視化【生成AIセキュリティ対策シリーズ】 ![](https://info.nextmode.co.jp/hubfs/avator_yukinawa.jpg) yuki 2026/10/08](https://info.nextmode.co.jp/blog/okta-for-ai-agents-hands-on-roundup)

[![【Oktane26】英語に不安があっても大丈夫！コミュニティミートアップ参加レポート](https://info.nextmode.co.jp/hubfs/%E3%83%96%E3%83%AD%E3%82%B0%EF%BC%BF%E3%82%AD%E3%83%BC%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB/oktane26.png) 【Oktane26】英語に不安があっても大丈夫！コミュニティミートアップ参加レポート テクニカルサポート 2026/09/29](https://info.nextmode.co.jp/blog/oktane26-community-meetup-report)

[![【世界一周ワーケーション：中国編②】深セン・南頭古城](https://info.nextmode.co.jp/hubfs/ebdcf542-d03c-43c1-b16d-b3993bd44302.jpg) 【世界一周ワーケーション：中国編②】深セン・南頭古城 ![](https://info.nextmode.co.jp/hubfs/satomi.jpeg) ネクストモード　代表取締役社長　里見宗律 2026/10/10](https://info.nextmode.co.jp/blog/china_2)

### Category

[» 技術](https://info.nextmode.co.jp/blog/tag/技術) [» Okta](https://info.nextmode.co.jp/blog/tag/okta) [» Notion](https://info.nextmode.co.jp/blog/tag/notion) [» イベントレポート](https://info.nextmode.co.jp/blog/tag/イベントレポート) [» Netskope](https://info.nextmode.co.jp/blog/tag/netskope) [» CrowdStrike](https://info.nextmode.co.jp/blog/tag/crowdstrike) [» Notion AI](https://info.nextmode.co.jp/blog/tag/notion-ai) [» AWS](https://info.nextmode.co.jp/blog/tag/aws) [» Asana](https://info.nextmode.co.jp/blog/tag/asana) [» カルチャー](https://info.nextmode.co.jp/blog/tag/カルチャー) [» ワーケーション](https://info.nextmode.co.jp/blog/tag/ワーケーション) [» 生成AIセキュリティ対策シリーズ](https://info.nextmode.co.jp/blog/tag/生成aiセキュリティ対策シリーズ) [» Oktane25](https://info.nextmode.co.jp/blog/tag/oktane25) [» SaaS](https://info.nextmode.co.jp/blog/tag/saas) [» AI](https://info.nextmode.co.jp/blog/tag/ai) [» re:Invent](https://info.nextmode.co.jp/blog/tag/reinvent) [» リモートワーク](https://info.nextmode.co.jp/blog/tag/リモートワーク) [» Keeper](https://info.nextmode.co.jp/blog/tag/keeper) [» ネクストモードアドベントカレンダー2024](https://info.nextmode.co.jp/blog/tag/ネクストモードアドベントカレンダー2024) [» Oktane24](https://info.nextmode.co.jp/blog/tag/oktane24) [» Oktane23](https://info.nextmode.co.jp/blog/tag/oktane23) [» Oktane26](https://info.nextmode.co.jp/blog/tag/oktane26) [» Asana AI](https://info.nextmode.co.jp/blog/tag/asana-ai) [» Slack](https://info.nextmode.co.jp/blog/tag/slack) [» OIGシリーズ](https://info.nextmode.co.jp/blog/tag/oigシリーズ) [» その他](https://info.nextmode.co.jp/blog/tag/その他) [» 脱Excelシリーズ](https://info.nextmode.co.jp/blog/tag/脱excelシリーズ) [» SysCloud](https://info.nextmode.co.jp/blog/tag/syscloud) [» Oktane22](https://info.nextmode.co.jp/blog/tag/oktane22) [» Google](https://info.nextmode.co.jp/blog/tag/google) [» HubSpot](https://info.nextmode.co.jp/blog/tag/hubspot) [» Zapier](https://info.nextmode.co.jp/blog/tag/zapier) [» Azure AD](https://info.nextmode.co.jp/blog/tag/azure-ad) [» Entra ID](https://info.nextmode.co.jp/blog/tag/entra-id) [» Googleドライブ](https://info.nextmode.co.jp/blog/tag/googleドライブ) [» SentinelOne](https://info.nextmode.co.jp/blog/tag/sentinelone) [» ゼロトラスト](https://info.nextmode.co.jp/blog/tag/ゼロトラスト) [» DocuSign](https://info.nextmode.co.jp/blog/tag/docusign) [» Jamf](https://info.nextmode.co.jp/blog/tag/jamf) [» セキュリティ対策](https://info.nextmode.co.jp/blog/tag/セキュリティ対策) [» トラブルシューティング](https://info.nextmode.co.jp/blog/tag/トラブルシューティング) [» 利用者目線](https://info.nextmode.co.jp/blog/tag/利用者目線) [» 運用](https://info.nextmode.co.jp/blog/tag/運用) [» GitHub](https://info.nextmode.co.jp/blog/tag/github) [» GitHub Gist](https://info.nextmode.co.jp/blog/tag/github-gist) [» JOUG](https://info.nextmode.co.jp/blog/tag/joug) [» Notion Calendar](https://info.nextmode.co.jp/blog/tag/notion-calendar) [» Proflly](https://info.nextmode.co.jp/blog/tag/proflly) [» kintone](https://info.nextmode.co.jp/blog/tag/kintone)

[![ネクストモード株式会社](https://nextmode.co.jp/assets/images/common/logo_white.svg)](https://nextmode.co.jp/)

Service

- [生成AIセキュリティ](https://nextmode.co.jp/services/ai/security/)
- [SaaSライセンス＆サポート](https://nextmode.co.jp/services/saas/) 
    - [Oktaライセンス＆サポート](https://nextmode.co.jp/services/saas/okta/)
    - [Netskopeライセンス＆サポート](https://nextmode.co.jp/services/saas/netskope/)
    - [Notionライセンス＆サポート](https://nextmode.co.jp/services/saas/notion/)
    - [Asanaライセンス＆サポート](https://nextmode.co.jp/services/saas/asana/)
    - [SysCloudライセンス＆サポート](https://nextmode.co.jp/services/saas/syscloud/)
    - [CrowdStrikeライセンス＆サポート](https://nextmode.co.jp/services/saas/crowdstrike/)
    - [Keeperライセンス＆サポート](https://nextmode.co.jp/services/saas/keeper/)
- [AWS総合支援](https://nextmode.co.jp/services/aws/) 
    - [AWS導入コンサル・構築](https://nextmode.co.jp/services/aws_consulting/)
    - [AWS運用・保守代行](https://nextmode.co.jp/services/aws_operation/)

Company

- [会社情報](https://nextmode.co.jp/company/)
- [サービス一覧](https://nextmode.co.jp/services/)
- [導入事例](https://nextmode.co.jp/casestudy/)
- [お知らせ](https://nextmode.co.jp/news/)
- [サステナビリティ](https://nextmode.co.jp/sustainability/)
- [採用](https://nextmode.co.jp/recruit/)
- [私たちの働き方](https://nextmode.co.jp/workstyle/)
- [カルチャー](https://nextmode.co.jp/culture/)

Contact

- [お問い合わせ](https://nextmode.co.jp/contact/)
- [資料請求](https://info.nextmode.co.jp/request/)

Media

- [セミナー](https://info.nextmode.co.jp/seminar)
- [ブログ](https://info.nextmode.co.jp/blog)
- [ホワイトペーパー](https://info.nextmode.co.jp/white-paper/)

- [![ネクストモード公式YouTubeチャンネル](https://nextmode.co.jp/assets/images/common/icon_youtube.svg)](https://www.youtube.com/channel/UCeW8ocoe9C3E0GOINh167MA)
- [![ネクストモード公式Xアカウント](https://nextmode.co.jp/assets/images/common/icon_x.svg)](https://twitter.com/Nextmode_Inc)

[English](https://nextmode.co.jp/en/)

- [NTTグループカスタマーハラスメント基本方針](https://group.ntt/jp/group/customer_harassment/)
- [就活ハラスメント防止方針](https://docs.nextmode.co.jp/nextmode_recruit_harassment.pdf)

- 運用アシスタント利用規約([AWS](https://docs.nextmode.co.jp/nextmode-unyo-assistant-aws-terms-of-use.pdf)/[Azure](https://docs.nextmode.co.jp/nextmode-unyo-assistant-azure-terms-of-use.pdf))
- [日中運用支援定型約款](https://docs.nextmode.co.jp/nextmode-nittyu-unyo-shien-terms-of-use.pdf)
- [定型約款](https://docs.nextmode.co.jp/nextmode-standard-contracts.pdf)

[プライバシーポリシー](https://nextmode.co.jp/company/privacy.html)

Copyright(c) Nextmode, Inc.

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "テクニカルサポート",
    "url" : "https://info.nextmode.co.jp/blog/author/tech-support"
  },
  "dateModified" : "2026-07-26T05:54:36.379Z",
  "datePublished" : "2025-12-01T09:16:29.000Z",
  "headline" : "【Okta】ID-JAGの設計思想から読み解くCross App Accessの背景と技術の裏側【生成AIセキュリティ対策シリーズ】｜Nextmode Blog",
  "image" : [ "https://info.nextmode.co.jp/hubfs/%E3%83%96%E3%83%AD%E3%82%B0%EF%BC%BF%E3%82%AD%E3%83%BC%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB/%E7%94%9F%E6%88%90AI%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3_Okta.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://info.nextmode.co.jp/blog/okta-id-jag-cross-app-access-tech",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://info.nextmode.co.jp/hubfs/nm_l_color.png"
    },
    "name" : "ネクストモード株式会社"
  }
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://nextmode.co.jp/#organization",
  "@type" : "Organization",
  "alternateName" : "Nextmode, Inc.",
  "logo" : "https://nextmode.co.jp/assets/images/common/logo_white.svg",
  "name" : "ネクストモード株式会社",
  "sameAs" : [ "https://www.youtube.com/channel/UCeW8ocoe9C3E0GOINh167MA", "https://twitter.com/Nextmode_Inc", "https://info.nextmode.co.jp/" ],
  "url" : "https://nextmode.co.jp/"
}
```