はじめに——エージェントが「最大の攻撃ベクトル」になった
2026年、企業のIT環境は「人間よりもAIエージェントのほうが圧倒的に多い」時代に突入しました。
サービスアカウント、APIキー、OAuthトークン、そして自律的に行動するAIエージェント——これらの非人間アイデンティティ（NHI：Non-Human Identity）は、多くの企業で人間のユーザー数を25〜100倍以上も上回っています。ManageEngineの2026年レポートでは、500:1に達した企業もあると報告されています。
にもかかわらず、ほとんどの組織ではこれらのIDが正式なガバナンスの対象外に置かれたままです。
Dark Readingの2026年リーダーシップ投票では、48%のセキュリティ専門家がエージェントAIを今年最大の攻撃ベクトルと認識しました。Cisco State of AI Security 2026では、83%の組織がエージェントAIのデプロイを計画する一方、安全に利用できる準備ができているのはわずか29%と報告されています。
この記事では、中小企業のIT管理者・経営者が「NHIとは何か」を理解し、自社のAIエージェントを「デジタル従業員」として安全に管理するための実践的な手法を解説します。
この記事でわかること：
・NHIの定義と、人間ID・サービスアカウント・エージェントIDの違い
・エージェントID台帳の設計と登録すべき属性
・ライフサイクル管理（プロビジョニング→レビュー→デプロビジョニング）のワークフロー
・シャドーエージェントの発見・棚卸し手法
・中小企業向け簡易NHI管理テンプレート
NHI（非人間アイデンティティ）とは何か
NHIの定義
非人間アイデンティティ（NHI）とは、人間ではなく、マシン・アプリケーション・AIエージェントが認証に使用するデジタルIDの総称です。具体的には以下のようなものが含まれます。
| 種類 | 具体例 | 典型的な寿命 |
|---|---|---|
| サービスアカウント | CI/CDパイプライン用アカウント、バッチ処理用アカウント | 数年〜無期限（放置されがち） |
| APIキー・トークン | SaaS間連携キー、OAuthリフレッシュトークン | 設定次第（多くは長期間有効） |
| マシン証明書 | TLS証明書、SSH鍵 | 1〜3年（更新忘れリスクあり） |
| AIエージェントID | コーディングエージェント、カスタマーサービスBot、自律ワークフローエージェント | プロジェクト単位〜常時稼働 |
Cloud Security Alliance（CSA）の2026年調査レポートでは、多くの組織がAIアイデンティティを従来のNHIと同じ枠組みで管理しようとしていると報告しています。しかし、AIエージェントは従来のサービスアカウントとは本質的に異なる特性を持っています。
AIエージェントIDが特別な理由——従来のサービスアカウントとの違い
| 比較項目 | 従来のサービスアカウント | AIエージェントID |
|---|---|---|
| 動作パターン | 事前定義されたロジックに従う | 自律的に判断・行動する |
| 権限の変動 | 固定的 | タスクに応じて動的に変化し得る |
| ID生成 | 人間が手動で作成 | エージェント自身が新しいIDを動的に生成する場合がある |
| 監査の難しさ | ログが予測可能 | 推論・マルチステップ動作で追跡が困難 |
| 攻撃リスク | 認証情報の窃取 | プロンプトインジェクション、ツール悪用、権限エスカレーションの複合リスク |
特に注意すべきは、AIエージェントが自分自身で新しいサービスプリンシパル（NHI）を動的に生成し、タスク完了後に削除しないというケースです。Oasis Securityの分析では、Azure環境でAIエージェントが自身の権限を拡大し、管理者が意図しないアクセス権を取得した事例が報告されています。
⚠ ここがポイント：従来のIAM（Identity and Access Management）は「人間が作り、人間が管理する」ことを前提に設計されています。AIエージェントは「マネージャーがいない」「退職しない」「MFAをバイパスする」——これらの特性が、既存のセキュリティモデルでは捕捉できない盲点を生んでいます。
エージェントID台帳の設計——何を登録すべきか
NHI管理の第一歩は、すべてのエージェントを「台帳」に登録し、可視化することです。CSAの調査では、16%以上の組織が新規AI関連IDの作成を追跡していないと報告されています。まずは「何が動いているか」を把握することが出発点です。
エージェントID台帳に登録すべき属性
| 属性 | 説明 | 記入例 |
|---|---|---|
| エージェント名 | 識別しやすい名称 | sales-report-agent-01 |
| 種別 | コーディング／カスタマーサポート／データ分析 など | データ分析エージェント |
| 所有者（オーナー） | 責任を持つ人間の担当者 | 営業部 田中太郎 |
| 作成日 | デプロイ日 | 2026-03-01 |
| 権限スコープ | アクセスできるシステム・データの範囲 | Salesforce（読取のみ）、Google Sheets（読書き） |
| 接続先ツール・API | MCPサーバー、外部API等 | Slack API、Supabase DB |
| 認証方式 | APIキー／OAuth／マネージドID | OAuth 2.0（リフレッシュトークン、90日更新） |
| 最終レビュー日 | 権限棚卸しの実施日 | 2026-03-15 |
| 次回レビュー予定日 | 定期レビューのスケジュール | 2026-06-15 |
| ステータス | 稼働中／休止中／廃止済み | 稼働中 |
💡 実践ヒント：最初から完璧な台帳を目指す必要はありません。まずは「エージェント名」「所有者」「権限スコープ」「作成日」の4項目だけでスタートし、段階的に属性を追加していくアプローチが現実的です。
ライフサイクル管理——「入社→異動→退職」で管理する
エージェントを「デジタル従業員」として捉え、人間の従業員と同じライフサイクルで管理します。
フェーズ1：プロビジョニング（入社）
エージェントを新たにデプロイする際のチェックポイントです。
■ プロビジョニング・チェックリスト □ エージェントID台帳に登録したか □ 所有者（責任者）を明確に指定したか □ 最小権限の原則で権限を設定したか（読取のみで十分なら書込み権限は付与しない） □ 認証情報は短寿命トークンを使用しているか（可能な限り長期APIキーを避ける） □ アクセスできるシステム・データの範囲を文書化したか □ ネットワークアクセスポリシーを設定したか（必要な接続先のみ許可） □ 次回レビュー日を設定したか（推奨：90日以内）
Entro Securityの調査では、97%のNHIが過剰な権限を持っていると報告されています。「とりあえず管理者権限を付与して動かす」という開発時の慣行が、そのまま本番環境に持ち込まれることが原因です。
フェーズ2：定期レビュー（異動・棚卸し）
稼働中のエージェントを定期的に棚卸しし、権限の妥当性を確認します。
■ 定期レビュー・チェックリスト（推奨：四半期ごと） □ このエージェントはまだ必要か（ビジネス上の目的が存在するか） □ 現在の権限は最小限か（使っていない権限はないか） □ 認証情報は適切にローテーションされているか □ 所有者は現在も在籍しているか（退職していないか） □ 異常なアクセスパターンはないか（通常と異なる時間帯・頻度のアクセス） □ 接続先ツール・APIに変更はないか
CSO Onlineの報道によれば、71%のNHIは推奨される期間内に認証情報がローテーションされていないとされています。認証情報が変更されない日数が増えるほど、攻撃者がそれを悪用するリスクも高まります。
フェーズ3：デプロビジョニング（退職・廃止）
不要になったエージェントを安全に廃止するプロセスです。
■ デプロビジョニング・チェックリスト □ エージェントの稼働を停止したか □ すべての認証情報（APIキー、トークン、証明書）を失効させたか □ 関連するサービスプリンシパル・マネージドIDを削除したか □ 接続先システムからのアクセス許可を削除したか □ ID台帳のステータスを「廃止済み」に更新したか □ 廃止日と理由を記録したか
⚠ 注意：人間の従業員が退職する場合、HRが起点となってオフボーディングが実行されます。しかしサービスアカウントやエージェントIDには「退職」のトリガーがありません。これが「ゾンビNHI」——使われていないのにアクセス権限が残り続けるID——が蓄積する根本原因です。
シャドーエージェントの発見——「野良エージェント」を棚卸しする
シャドーエージェントとは
シャドーエージェントとは、IT部門やセキュリティチームの把握なしに、従業員が独自にデプロイしたAIエージェントのことです。
2026年のAI Risk and Readiness Reportでは、94%の組織がAI活動の可視性にギャップがあると報告されています。さらに88%の組織は、個人のAIアカウントと企業のAIインスタンスを区別できていないとされています。
シャドーエージェントの発見手法
| 手法 | 具体的なアクション | 対象 |
|---|---|---|
| APIゲートウェイログの監査 | 外部API呼び出しのログを分析し、未登録のエージェントからの通信を特定 | クラウド環境 |
| OAuthトークンの棚卸し | Google Workspace、Microsoft 365等のOAuth連携アプリ一覧を定期確認 | SaaS環境 |
| ネットワークトラフィック分析 | AI関連サービス（OpenAI API、Anthropic API等）へのアウトバウンド通信を監視 | ネットワーク |
| 従業員ヒアリング | 各部門に「利用中のAIツール・エージェント」を申告してもらう（棚卸しアンケート） | 全社 |
| ID・シークレットスキャン | コードリポジトリ、CI/CDパイプラインに埋め込まれたAPIキーやトークンをスキャン | 開発環境 |
💡 中小企業向けの現実的アプローチ：専用のNHI管理ツール（Astrix、Entro Security、GitGuardian等）を導入できない場合は、まずGoogle Workspace管理画面のOAuth連携アプリ一覧とクラウドプロバイダ（AWS/Azure/GCP）のIAM一覧を定期的にエクスポートし、ID台帳と突合するだけでも大きな効果があります。
中小企業向け簡易NHI管理テンプレート
大企業向けのNHI管理プラットフォームは高コストですが、中小企業でもスプレッドシートで始められます。以下は、NotionまたはGoogleスプレッドシートで管理できるテンプレート例です。
テンプレート構成
シート1：エージェントID台帳
| エージェント名 | 種別 | 所有者 | 作成日 | 権限スコープ | 認証方式 | 次回レビュー日 | ステータス |
|---|---|---|---|---|---|---|---|
| slack-summary-bot | 業務効率化 | 総務部 佐藤 | 2026-01-15 | Slack（読取） | OAuth | 2026-04-15 | 稼働中 |
| invoice-ocr-agent | データ処理 | 経理部 鈴木 | 2026-02-01 | Google Drive（読書き） | APIキー | 2026-05-01 | 稼働中 |
| old-chatbot-v1 | カスタマーサポート | （退職済み） | 2025-06-01 | CRM（読書き） | APIキー | 期限切れ | 要確認 |
シート2：認証情報ローテーション管理
| 対象 | 認証方式 | 最終更新日 | 有効期限 | ローテーション間隔 | 対応状況 |
|---|---|---|---|---|---|
| slack-summary-bot | OAuth | 2026-03-01 | 2026-06-01 | 90日 | ✅ 対応済み |
| invoice-ocr-agent | APIキー | 2025-08-15 | なし（無期限） | 未設定 | ⚠ 要対応 |
シート3：レビュー履歴
| レビュー日 | 対象エージェント | レビュー実施者 | 結果 | アクション |
|---|---|---|---|---|
| 2026-03-15 | slack-summary-bot | 佐藤 | 問題なし | 次回レビュー設定 |
| 2026-03-15 | old-chatbot-v1 | 鈴木 | 不要 | デプロビジョニング実施 |
■ 90日サイクルのNHI管理ワークフロー（中小企業向け） Day 1-7: ID台帳の更新（新規登録・変更・廃止の反映） Day 8-14: シャドーエージェント発見（OAuth連携一覧の確認） Day 15-30: 認証情報のローテーション Day 31-60: 権限レビュー（最小権限の確認） Day 61-90: レビュー結果の記録・次サイクルの計画
NHI管理と既存のセキュリティ対策の関係
NHI管理は単独で機能するものではなく、既存のセキュリティ対策と組み合わせることで効果を発揮します。
| 既存の対策 | NHI管理との関係 | 参考 |
|---|---|---|
| ゼロトラスト設計 | NHIにも「常に検証」の原則を適用。エージェントのリクエストも毎回認証・認可する | ゼロトラスト設計ガイド |
| A2A（Agent-to-Agent）セキュリティ | エージェント間の通信にも相互認証を実装。NHI台帳で通信ペアを管理 | A2Aセキュリティ |
| 権限エスカレーション防止 | エージェントが自身の権限を拡大しないよう、最小権限＋動的権限チェックを実装 | 権限エスカレーション防止 |
| 鍵・シークレット管理 | NHIの認証情報（APIキー、トークン）を安全に保管・ローテーション | 鍵管理ガイド |
| シャドーAI対策 | シャドーエージェントの発見・棚卸しはシャドーAI対策の一部 | シャドーAI対策 |
| ガードレール設計 | エージェントの行動範囲をポリシーで制限するガードレールとNHI管理を連携 | ガードレール設計 |
| 運用監視 | NHIの異常アクセスを検知するモニタリングを運用監視に組み込む | 運用監視ガイド |
| NIST AI RMF統合監査 | NHI管理をAIリスクマネジメントフレームワークの一部として位置づける | NIST AI RMF統合監査 |
よくある質問（Q&A）
Q1. うちは従業員10人の会社ですが、NHI管理は必要ですか？
はい。従業員が少なくても、SaaS間のAPI連携やAIツールを利用しているなら、NHIは存在しています。Google WorkspaceのOAuth連携アプリが5個あれば、それだけで5つのNHIがあるということです。まずは棚卸しから始めてみてください。
Q2. 専用ツールがないと管理できませんか？
いいえ。この記事で紹介したスプレッドシートテンプレートで十分にスタートできます。NHIの数が50を超えてきたり、マルチクラウド環境で管理が複雑になった場合に、専用ツールの検討をお勧めします。
Q3. AIエージェントのIDと、従来のサービスアカウントは別々に管理すべきですか？
CSAの調査では、多くの組織がAIアイデンティティを従来のNHIと同じ枠組みで管理していると報告されています。統合管理が理想ですが、AIエージェント特有の属性（自律性レベル、接続先MCPサーバー、推論ログの保存場所など）は追加で記録することを推奨します。
Q4. どのくらいの頻度で認証情報をローテーションすべきですか？
一般的な推奨は90日以内ですが、機密性の高いシステムにアクセスするエージェントには、短寿命トークン（数時間〜数日で失効するもの）の使用を強く推奨します。静的なAPIキーの使用はできる限り避け、Just-in-Time（JIT）アクセスへの移行を検討してください。
Q5. シャドーエージェントを完全に防ぐことはできますか？
完全な防止は困難ですが、発見と可視化を継続的に行うことがリスク軽減の鍵です。API利用ポリシーの策定、従業員への啓発、OAuth連携の定期的なレビューを組み合わせることで、シャドーエージェントのリスクを大幅に軽減できます。既存のシャドーツール接続ガイドも参考にしてください。
まとめ——「デジタル従業員」としてのエージェント管理を始めよう
2026年のIT環境では、人間よりもNHIのほうが圧倒的に多い——これはもはや大企業だけの課題ではありません。
NHI管理の要点を3つに整理します。
1. 可視化から始める。 まずは自社にどんなエージェント・サービスアカウント・APIキーが存在するかを棚卸しします。見えないものは守れません。
2. ライフサイクルで管理する。 エージェントを「入社→異動→退職」のフレームワークで管理し、不要になったら速やかにデプロビジョニングします。
3. 最小権限を徹底する。 「とりあえず管理者権限」を排除し、各エージェントに必要最小限のアクセス権だけを付与します。
専用ツールがなくても、スプレッドシート1枚から始められます。大切なのは「完璧な仕組み」ではなく、「今日、台帳を作り始めること」です。
参考リンク
- Cloud Security Alliance「The State of Non-Human Identity and AI Security」
- Cisco「State of AI Security 2026」
- Dark Reading「2026: The Year Agentic AI Becomes the Attack-Surface Poster Child」
- CSO Online「Why Non-Human Identities Are Your Biggest Security Blind Spot in 2026」
免責事項： 本記事は2026年3月時点の公開情報に基づく情報提供であり、特定のセキュリティ製品・サービスの推奨ではありません。具体的なセキュリティ対策の実装については、自社の環境・要件に応じて専門家にご相談ください。記載した統計データ・調査結果は各調査元の報告に基づいており、調査対象・方法によって数値が異なる場合があります。
コメント