OAuth Scopeとは？AIに許可する範囲をどう決めるか

まず結論

OAuth Scope（スコープ）は、外部アプリケーションに委任するアクセス権限の範囲を表す値です。

たとえばAIから文書サービスを利用するとき、「文書を読む権限」と「文書を変更する権限」は分けて考えます。OAuthの認可要求でScopeを指定すると、認可サーバーは要求内容や利用者の承認、サービスの方針などに基づき許可範囲を決めます。

Scopeはファイル単位・利用者単位の細かな権限をすべて置き換えるものではありません。 実際の操作には対象サービス側のアクセス制御も必要です。

OAuthそのものの解説は「OAuthとは？」を参照してください。

定義

OAuthではアプリが希望するアクセス権限を scope パラメータで要求できます。

Scopeの例	権限のイメージ	用途
documents.read	文書を読む	検索・要約
documents.write	文書を更新する	議事録を編集
calendar.read	予定を読む	空き時間の確認
calendar.write	予定を作成・変更する	スケジュール登録

上記は架空の例です。 Scope名とその意味は個々のサービスが定義します。RFC 6749の規定では、Scopeは大文字と小文字を区別する文字列の集合として扱われ、複数の値を空白で区切ります。

仕組み

具体例：AIに議事録を探してもらう

「先週の議事録を探して、要点をまとめて」という依頼なら、必要なのは基本的に資料の検索・読み取りです。削除や変更は依頼していません。

読み取りと書き込みのScopeが分かれているサービスなら、まず読み取りだけの許可を検討するのが合理的です。

一方「議事録に決定事項を書き加えて」なら、書き込み権限が必要になる場合があります。それでも対象ファイルのアクセス権、本人の意思、操作の安全性を別途確認します。

AIに最初から広い権限を渡すのではなく、依頼した仕事に必要な操作から考えることが重要です。

要求したScopeと実際に許可されたScope

1. Clientが権限を要求する。 たとえば読み取り用のScopeを指定します。
2. 認可サーバーが判断する。 アプリ設定、サービス方針、必要に応じた利用者の同意を確認します。
3. 許可範囲を反映したTokenを発行する。 要求のすべてが許可されるとは限りません。
4. API側が権限を検証する。 Tokenと対象操作の許可を確認します。

RFC 6749では要求Scopeと発行されたTokenのScopeが異なる場合、実際に許可したScopeをClientに通知することとされています。

Scopeがあっても操作できない理由

制御	役割	例
OAuth Scope	アプリへ委任された操作範囲	文書の読み取り
サービス内の権限	対象へのアクセス可否	チーム内フォルダだけ閲覧
Toolの提供・設定	AIが利用できる機能	検索Toolのみ有効
個別の実行条件	現時点で処理可能か	ファイルが存在する

Scopeを増やすだけでは、すべてのアクセスエラーを解決できません。

検索は成功しても更新に失敗する場合、書き込みScopeが不足している可能性があります。しかしファイル自体が読み取り専用だったり、更新Toolが無効だったりする場合もあります。

必要なScopeがあっても文書を読めない場合、サービス側の共有設定や個別のアクセス権限を確認します。

AIアプリへどのScopeを要求するか

**最小権限（least privilege）**を基本にします。

• 検索・要約： 読み取りだけを優先して検討

• 作成・更新： その操作に必要な書き込み権限を検討

• 削除： 削除権限が本当に必要か慎重に判断

• 複数サービス： サービスごとに必要性を確認

細かすぎる権限区分は使い勝手を下げる場合もあります。利用目的に即した意味のある区分が大切です。

よく混同される概念

MCP Toolの名前とOAuth Scopeは別

MCPはAIアプリケーションと外部Tool・データの接続を標準化し、OAuth Scopeはアプリに委任する権限範囲を表します。

たとえば search_documents というToolが見えていても、そのToolを使える認可条件はServer側の設計によります。Toolが表示されない場合の原因も必ずしもScope不足ではありません。

MCP完全ガイドとMCPツールが表示されないときの確認ポイントも参考にしてください。

Scope不足とデータ単位の権限不足は別

許可されたScopeがあっても、他者の非公開ファイルを自由に読めるとは限りません。接続先が利用者やファイルごとにアクセスを判断する必要があります。

OGINAUとの関係

OGINAUでは、OGINAU RemoteとOGINAU Browserの開発で、AIから外部環境へ接続する際の認可と操作権限を検証してきました。

一般化できる知見は、「接続を許可したこと」「Toolが提供されていること」「個々の操作を実行してよいこと」を別に考える必要があるという点です。

AIから接続できていても、すべてのファイルや操作が無条件で許されるわけではありません。OAuth Scopeだけで権限制御の全体が完成するという意味でもありません。

OGINAU固有の内部Scope体系、権限判定の順序、制御ロジックは公開していません。

よくある質問

Q. OAuth Scopeは誰が決めますか？

Scope名と意味はサービス提供者が定義します。Clientが要求し、認可サーバーが実際に許可する範囲を決めます。

Q. Scopeを増やすとAIは何でもできますか？

いいえ。サービス側の利用者権限、Tool、実行条件が別途関係します。

Q. Scope不足と出たら全部許可すべきですか？

いいえ。拒否された操作と不足している権限を特定します。

Q. 要求したScopeと許可されたScopeが異なることはありますか？

はい。接続先の仕様と認可結果を確認してください。

根拠・一次情報

• RFC 6749 Section 3.3：Access Token Scope：Scopeの構造と要求・許可の違い。

• RFC 9700：OAuth 2.0 Security Best Current Practice：OAuthを安全に利用する考え方。

• MCP Authorization（2026-07-28）：MCPでのOAuth認可。

• OGINAU Remote・OGINAU Browserの開発検証記録：接続・操作権限の分離。

まとめ

OAuth Scopeは、外部アプリへ委任するアクセス権限の範囲を表す仕組みです。

理解のポイントは、読み取りと更新などを分けること、要求と許可されたScopeが異なり得ること、Scopeと個別データのアクセス権は別ということです。

「何でもできるようにする」のではなく、必要な仕事を安全に実行できるようにする。 それがAI連携でScopeを考える出発点です。