この記事を読むと
- AIエージェントの権限管理を、非人間ID（NHI）の管理として捉え直せます。
- サービスアカウント、APIキー、OAuthトークン、CI/CD資格情報を棚卸しする台帳項目がわかります。
- APIキー管理ポリシーと、NHIセキュリティチェックリストのたたき台を作れます。
この記事の監修者
宮﨑 一旗
宅地建物取引士 / 連続起業家 / 株式会社ライフワンネクスト取締役
宅地建物取引士(登録番号:(神奈川)第129630号)。補助金SEOメディア「補助金プラス」運営、AIスタートアップAtlas株式会社共同創業者。不動産・住宅領域のSEO/LLMOコンサルティングと記事監修を行う。
プロフィールを見るAIエージェント権限管理の答え
AIエージェント権限管理とは、AIに「何を読ませるか」だけでなく、「どのIDで、どの範囲まで、いつまで実行させるか」を管理することです。実務では、AIエージェントを人間の社員アカウントではなく、サービスアカウント、APIキー、OAuthトークンなどと同じ非人間ID（NHI）の一種として扱います。
| 検索で知りたいこと | 実務で見るべき答え | 最初に作るもの |
|---|---|---|
| AIエージェント 権限管理 | AIが使うID、権限、承認、ログ、停止手順を決めること。 | AIエージェント権限表 |
| 非人間ID 管理 | 人間以外のシステム、アプリ、トークン、AIエージェントを台帳化すること。 | NHI台帳 |
| サービスアカウント 棚卸し テンプレート | 所有者、用途、権限、最終利用日、有効期限、失効手順を1行で追うこと。 | 棚卸し台帳 |
| APIキー 管理 ポリシー | 固定キーを例外扱いにし、発行、保管、ローテーション、失効を決めること。 | APIキーポリシー |
| NHI セキュリティ チェックリスト | 過剰権限、長期キー、退役漏れ、秘密情報漏えいを先に潰すこと。 | 10項目チェックリスト |
2026年6月時点で押さえたい最新論点
Microsoft Learnでは、AIエージェント専用のIDであるMicrosoft Entra Agent IDの説明ページが2026年6月15日に更新されています。そこでは、AIエージェントの操作を人間や従来のアプリIDと区別すること、適切な大きさのアクセス権にすること、重要な管理ロールへ入れないことが課題として整理されています。
さらにMicrosoft Entra ID GovernanceのAgent Identitiesページは、AIエージェントに人間のスポンサーを付け、期限付きアクセスやConditional Accessで管理する考え方を示しています。AIエージェントは「便利な自動化」ではなく、組織内でアクセス権を持つIDとして管理する段階に入っています。
AIエージェントを社内で使うと、最初は「Slackを読ませたい」「Gmailの下書きを作らせたい」「CRMを更新させたい」という業務改善の話に見えます。しかし、実際にはその裏でサービスアカウント、APIキー、OAuthトークン、CI/CD資格情報、クラウドIAMロールが動きます。
人間のアカウントであれば、入退社、部署異動、MFA、権限申請、アクセスレビューの運用があります。一方で、非人間IDは所有者が曖昧になりやすく、使われなくなっても残りやすく、長期キーがコードやSaaS設定に散らばりがちです。AIエージェント導入でこの問題が増幅します。
この記事では、OWASP Non-Human Identities Top 10、Microsoft Entra、Google Cloud IAM、AWS IAM、GitHub Secret Protection、NIST、Cloud Security Allianceなどの一次情報をもとに、日本企業がすぐに使える実務テンプレートとして整理します。
AIエージェント権限管理とは何を管理することか
AIエージェント権限管理で見る対象は、AIの回答品質だけではありません。AIが外部ツールを呼び出す時に、どのIDを使い、どのデータにアクセスし、どの操作まで実行し、どの時点で人間の承認を必要にするかを決めます。
| 管理対象 | 例 | 放置した時の問題 |
|---|---|---|
| ID | AIエージェントID、サービスアカウント、サービスプリンシパル | 誰の責任で動いているか追えない |
| 資格情報 | APIキー、OAuthトークン、証明書、秘密鍵、接続文字列 | 漏えい時に長期間悪用される |
| 権限 | read、write、delete、send、admin、billing | AIや攻撃者が過剰な操作を実行できる |
| 承認 | 送信、削除、購入、外部共有、個人情報更新 | 不可逆な操作が自動で進む |
| 監査 | tool call、API呼び出し、承認者、失敗ログ | 事故後に原因と影響範囲を説明できない |
AIエージェントにとって危険なのは「賢いこと」そのものではなく、曖昧なIDで広い権限を持ち、長期の資格情報を使って、ログなしに業務システムを操作できることです。したがって最初に作るべきものは、AI利用規程の美しい文章ではなく、NHI台帳と権限設計表です。
非人間ID（NHI）とは：AIエージェントも管理対象に入る
OWASP NHI Top 10は、ソフトウェア環境には識別されるべき多数のアプリケーションがあり、それらが非人間IDになると説明しています。アプリケーションIDは、人間のパスワードに似た役割を持つシークレットを使い、社内や第三者SaaSへ認証することがあります。
この考え方をAIエージェントに当てはめると、AIエージェントは「チャット画面の機能」ではなく、組織のデータやSaaSを操作する非人間IDの一部です。
| NHIの例 | AI時代の使われ方 | 棚卸しの焦点 |
|---|---|---|
| AIエージェントID | Copilot Studioや社内エージェントが業務データにアクセスする。 | 人間スポンサー、目的、利用システム、期限 |
| サービスアカウント | AIワークフローがクラウド、DB、社内APIへアクセスする。 | IAMロール、最終利用日、過剰権限 |
| APIキー | AIツールが外部SaaSやLLM APIを呼び出す。 | scope、保管場所、ローテーション、失効 |
| OAuthトークン | Gmail、Slack、Notion、Google Driveなどを代理操作する。 | 同意したユーザー、許可scope、再認可 |
| CI/CD資格情報 | AIがコード生成やデプロイ補助を行う時に使われる。 | 本番権限、環境分離、OIDC利用 |
Cloud Security Allianceの2026年調査も、AIは新しいIDパラダイムを完全に生むというより、既存のNHIリスクを増幅すると整理しています。特に、可視性、所有者、資格情報ライフサイクル、トークンの増殖が問題になります。
サービスアカウント棚卸しテンプレート：台帳に入れる項目
Google Cloudのサービスアカウント概要は、サービスアカウントをアプリケーションやワークロードが使う特別なアカウントと説明しています。アプリケーションがサービスアカウントとして認証すると、そのサービスアカウントに許可されたリソースへアクセスできます。つまり、台帳で「何のためのIDか」「どこまでアクセスできるか」を管理しないと、AIワークフローの権限範囲も説明できません。
サービスアカウント・NHI棚卸し台帳テンプレート
| 項目 | 入力例 | 確認ポイント |
|---|---|---|
| ID種別 | AI Agent / Service Account / API Key / OAuth Token / CI/CD Credential | 人間アカウントと混ぜず、非人間IDとして分類する。 |
| システム | Microsoft Entra、Google Cloud、AWS、GitHub、Notion、Gmail | どの管理画面で停止できるかを明確にする。 |
| ID名 | sales-crm-draft-agent、ci-prod-deploy-sa | 用途が名前から推測できる命名にする。 |
| 所有部門 | 営業企画、SRE、情報システム、開発基盤 | 棚卸し依頼を出せる部署を入れる。 |
| 人間スポンサー | 責任者名、管理者名 | 退職・異動時に引き継ぎ先を決める。 |
| 用途 | CRM要約、Gmail下書き、CI/CDデプロイ、請求データ同期 | 用途が説明できないIDは停止候補にする。 |
| 権限範囲 | read only、draft only、deploy only、admin | read/write/delete/send/adminを分ける。 |
| 有効期限 | 2026年7月31日、四半期末まで | 無期限のIDを例外扱いにする。 |
| 最終利用日 | 2026年6月20日、90日以上未使用 | 未使用IDと未使用キーを削除候補にする。 |
| 資格情報の保管場所 | Secret Manager、Secrets Manager、GitHub Secrets | コード、Excel、チャットに置かれていないか確認する。 |
| ローテーション周期 | 30日、60日、90日、発行禁止 | 長期キーは短期認証へ移行できないか検討する。 |
| 緊急停止手順 | key revoke、role detach、アプリ無効化、OAuth consent削除 | 事故時に誰が何分で止めるかまで書く。 |
| ログ確認先 | Cloud Audit Logs、CloudTrail、GitHub audit log、Entra sign-in logs | AI実行、API呼び出し、承認者を追えるようにする。 |
棚卸しでは、いきなり全社すべてを完璧に調べるより、AIエージェントが接続するSaaS、クラウド、GitHub、メール、CRMから始めるのが現実的です。AIが触るデータの機密度が高いほど、台帳の更新頻度も短くします。
APIキー管理ポリシー：固定キーを例外扱いにする
AIエージェント導入でAPIキーが増える理由は単純です。外部LLM、ベクトルDB、SaaS、メール、社内API、ワークフロー自動化ツールをつなぐほど、どこかでキーやトークンが必要になるからです。
しかし、固定APIキーは便利な反面、漏えい時の影響が大きくなります。Google Cloudのサービスアカウントキー管理ベストプラクティスは、サービスアカウントキーをソースコードリポジトリに入れないこと、バイナリに埋め込まないこと、不要になったキーを無効化・削除すること、利用状況をメトリクスで確認することを示しています。
AWS IAMのベストプラクティスでも、ワークロードにはIAMロールによる一時的な認証情報を使わせること、最小権限にすること、未使用のユーザー、ロール、権限、ポリシー、資格情報を定期的に見直して削除することが挙げられています。
APIキー管理ポリシーのたたき台
- 発行条件: 所有者、用途、利用システム、scope、有効期限、保管場所、失効手順が台帳に入っていないAPIキーは発行しない。
- 原則: 可能な場合はAPIキーではなく、IAMロール、Workload Identity、Managed Identity、OIDC、短期トークンを優先する。
- scope: read、write、delete、send、adminを分け、AIエージェントには必要最小限のscopeだけを渡す。
- 保管: GitHub、Slack、Notion、Excel、ローカルファイルに平文保存しない。Secret Managerや組織で承認した保管場所を使う。
- 検知: リポジトリ、Issue、Pull Request、Wiki、CIログに秘密情報が混入しないようsecret scanningやpush protectionを使う。
- 期限: 本番キーは期限とローテーション周期を持たせ、無期限キーは例外承認にする。
- 退役: AIエージェント、MCPサーバー、SaaS連携、担当者が不要になった時はキーを停止・削除する。
GitHub Secret scanningは、Git履歴上のAPIキー、パスワード、トークンなどのハードコードされた資格情報を検出し、secret sprawlの把握に役立つと説明しています。さらにGitHub Push protectionは、秘密情報がリポジトリへ到達する前にpushをブロックする仕組みです。AIエージェントがコード生成やMCP経由でGitHubを操作する場合、この層は必須に近くなります。
NHIセキュリティチェックリスト：導入前の10項目
OWASP NHI Top 10 2025では、退役漏れ、シークレット漏えい、脆弱な第三者NHI、安全でない認証、過剰権限、クラウド設定不備、長期シークレット、環境分離の不足、NHIの使い回し、人間によるNHI使用などが主要リスクとして整理されています。
| チェック項目 | 確認すること | NG例 |
|---|---|---|
| 1. 台帳 | AIエージェント、サービスアカウント、APIキー、OAuthトークンが一覧化されているか。 | 誰も全体数を知らない。 |
| 2. 所有者 | 各NHIに所有部門と人間スポンサーがいるか。 | 退職者の個人トークンで動いている。 |
| 3. 期限 | 有効期限、レビュー日、ローテーション周期があるか。 | 無期限APIキーが本番で使われている。 |
| 4. 最小権限 | AIエージェントに必要なread/writeだけを渡しているか。 | 下書き作成のためにadmin権限を渡す。 |
| 5. 秘密情報漏えい | リポジトリ、ログ、チャット、プロンプトにキーが出ていないか。 | APIキーを.envごとIssueに貼る。 |
| 6. 保管場所 | Secret Manager、GitHub Secrets、Vaultなど承認済み保管場所を使っているか。 | NotionやExcelに平文で置く。 |
| 7. 環境分離 | 本番、検証、個人開発でIDとキーを分けているか。 | 検証AIが本番DBを書き換えられる。 |
| 8. 第三者連携 | 外部SaaS、MCPサーバー、拡張機能の権限を審査しているか。 | 出所不明のMCPサーバーに本番トークンを渡す。 |
| 9. 監査ログ | AIのtool call、API呼び出し、承認者、失敗を追跡できるか。 | 誰が送信したメールか判断できない。 |
| 10. 退役 | AIエージェント、SaaS連携、担当者変更時にNHIを停止・削除しているか。 | PoC終了後のキーが残り続ける。 |
AIエージェントに渡してよい権限・渡してはいけない権限
AIエージェントの権限は、業務の便利さではなく、不可逆性、影響範囲、機密度で分けると判断しやすくなります。最初は「読む」「下書きする」「候補を作る」までを基本にし、「送信する」「削除する」「支払う」「権限を変更する」は人間承認か禁止にします。
| 操作 | 初期設定 | 理由 |
|---|---|---|
| 社内FAQや公開情報を検索する | 許可しやすい | 影響範囲が小さく、読み取り中心。 |
| CRMやNotionを要約する | 条件付きで許可 | 対象DBと権限を絞れば実務効果が高い。 |
| GmailやSlackの下書きを作る | 条件付きで許可 | 送信前に人間確認を挟める。 |
| 外部へメール送信する | 承認必須 | 誤送信、機密情報流出、契約上の影響がある。 |
| 顧客情報や契約金額を更新する | 承認必須 | 業務影響と監査責任が大きい。 |
| レコード削除、権限変更、支払い実行 | 原則禁止から開始 | 不可逆で、攻撃時の影響範囲が大きい。 |
MCPやn8nなどの実装論点は、既存記事「MCPとは？AIエージェントで何が変わるのかをNotion権限設計から解説」でも扱っています。この記事ではその一段手前の、IDと資格情報の管理に焦点を当てています。
Microsoft Entra・Google Cloud・AWS・GitHubで見る実装ポイント
ツールごとの実装は異なりますが、考え方は共通しています。AIエージェントやワークロードに「長期の強い秘密情報」を持たせないこと、所有者を明確にすること、使っていないIDを消すことです。
| 環境 | 見るべき公式情報 | 実務ポイント |
|---|---|---|
| Microsoft Entra | Agent identities、Agent identity governance | AIエージェントを専用IDとして扱い、人間スポンサー、期限付きアクセス、Conditional Accessで管理する。 |
| Google Cloud | Service accounts overview、service account key best practices | サービスアカウントの権限を最小化し、キーではなく短期認証やWorkload Identityを優先する。 |
| AWS | IAM best practices | ワークロードにはIAMロールと一時的な認証情報を使わせ、未使用のロールや資格情報を定期的に削除する。 |
| GitHub | Secret scanning、Push protection | AI生成コードやMCP経由の操作で秘密情報が混入しないよう、検知とpush前ブロックを入れる。 |
| APIゲートウェイ | NIST SP 800-228 | サービスIDやサービスアカウントを使い、ユーザーアクセスとサービスアクセスを監査・管理できる形にする。 |
Xで注目されたAIエージェントIDの論点
Xでは、AIエージェントの権限管理、Agent ID、非人間ID、APIキーやサービスアカウントの管理に関する投稿が増えています。ただし、X投稿は話題化の手がかりであり、製品仕様や運用判断は公式ドキュメントで確認する必要があります。
日本語圏で広がった「AIエージェント時代の権限管理」
LayerXのエンジニアブログ紹介投稿は、日本語圏でAIエージェント権限管理を考えるきっかけになっています。記事としては、ここからさらに非人間ID、サービスアカウント、APIキー台帳へ落として考えるのが実務的です。
Entra Agent IDの権限・検知に関する技術的な話題
海外では、Microsoft Entra Agent IDの権限、検知、監査をめぐる技術投稿も出ています。こうした投稿は、AIエージェントを本番投入する前に「どのIDがどの権限を持つか」を棚卸しする必要性を示しています。
AIエージェント権限管理でよくある質問
AIエージェント権限管理とは何ですか？
AIエージェントが社内外のツールを使う時に、どのIDで、どのデータへ、どの操作まで、いつまでアクセスできるかを管理することです。回答内容だけでなく、サービスアカウント、APIキー、OAuthトークン、承認フロー、監査ログまで含めて設計します。
非人間ID（NHI）とは何ですか？
人間ではなく、アプリケーション、ワークロード、自動化プロセス、AIエージェントなどがシステムへ認証・認可されるためのIDです。サービスアカウント、APIキー、トークン、証明書、CI/CD資格情報などが含まれます。
サービスアカウントの棚卸しでは何を見ればよいですか？
ID種別、システム、所有部門、人間スポンサー、用途、権限範囲、有効期限、最終利用日、資格情報の保管場所、ローテーション周期、緊急停止手順、ログ確認先を見ます。特に所有者、期限、最終利用日、失効手順が空欄のIDは優先的に確認します。
APIキー管理ポリシーで最初に決めることは何ですか？
発行条件、保管場所、scope、有効期限、ローテーション周期、失効手順です。可能な場合は固定APIキーではなく、IAMロール、Workload Identity、Managed Identity、OIDC、短期トークンを優先します。
NHIセキュリティチェックリストで最も重要な項目は何ですか？
まずは台帳、所有者、最小権限、長期シークレットの削減、退役漏れ防止です。AIエージェント導入前に、この5つだけでも確認すると、過剰権限や放置された資格情報のリスクを減らせます。
AIエージェントにadmin権限を渡してもよいですか？
原則として、初期段階では避けるべきです。AIエージェントにはread、draft、限定的なwriteから始め、外部送信、削除、支払い、権限変更、管理者操作は人間承認か禁止から開始するのが安全です。
出典・一次情報
- OWASP Non-Human Identities Top 10
- Microsoft Learn: What are agent identities?
- Microsoft Learn: Governing Agent Identities
- Google Cloud: Service accounts overview
- Google Cloud: Best practices for managing service account keys
- AWS IAM: Security best practices in IAM
- GitHub Docs: Secret scanning
- GitHub Docs: Push protection
- NIST SP 800-228: Guidelines for API Protection for Cloud-Native Systems
- Cloud Security Alliance: The State of Non-Human Identity and AI Security