2026.11.10第350号

「超知能」と呼んでも鍵は別に置く

NISTがAIエージェントのアイデンティティと権限を設計する10の原則を提示しました。

AI・テック

文書の名前が変わっていました

読者さん、米国立標準技術研究所（NIST）傘下の国家サイバーセキュリティ・エクセレンス・センター（NCCoE）¹が10月27日、ブログに『エージェントのアイデンティティ管理システムの設計原則（Design Tenets for Agent Identity Management Systems）』という記事を公開しました。AIエージェントにアイデンティティをどう付与し、権限をどのように与えて回収するかについての10の原則です。

本文より先に目に留まったのは、プロジェクト名でした。原則の出典として示されているプロジェクトが「Software and Super Intelligence Agent Identity and Authorization」と記されているのです。ところが、NCCoEが今年2月に意見募集のために公開したコンセプトペーパーのタイトルは「Software and AI Agent Identity and Authorization」でした。8月27日に出た同シリーズの第1弾でも「AI」と書かれていました。

理由は文書の外にあります。9月29日に署名された大統領令第14434号が、連邦機関に対し、法令以外の公文書やウェブサイトにおいて「Artificial Intelligence」および「AI」を「Super Intelligence」および「SI」に置き換えて使用するよう指示したのです。NISTも自身のサイトに、この指示に従って用語を変更中であると記しています。ただし、この命令は言葉を変えるだけです。法的定義は、従来の合衆国法典（15 U.S.C. 9401(3)）における人工知能の定義をそのまま用いています。

ですから、この文書で「super intelligence」という言葉を見かけても、人間を超える超知能ではなく、現在使われているAIのことだと読み替えていただければ大丈夫です。翻訳ツールや要約ツールにかければ「超知能エージェント」という言葉が飛び出してくるでしょうが、実際の内容はずっと地味です。社員証を作り、鍵を渡し、入退室ログを残すという話なのです。

私はこのズレがかなり象徴的だと見ています。名前は超知能に変わったものの、10の原則が繰り返し訴えているのは、モデルがどれほど賢かろうと、何をしてよいかはモデルの外側で決めよということだからです。

10の原則を一覧表で整理

NISTは、これらの原則がコンセプトペーパーに寄せられたパブリックコメントや業界関係者との議論から生まれたと明らかにしています。コンセプトペーパーには600件を超える意見が寄せられました。規制ではなく、組織が自らのリスク水準に合わせて取捨選択し、適用するための設計基準です。

番号	原則	何を求めているか	何を防ごうとしているか
01	エージェント固有の識別	人間・サービスアカウントと区別され、暗号学的に検証されるアイデンティティ。可能なら特定のワークロード・環境・承認済み構成に紐付け	ユーザーのなりすまし、追跡不能
02	連携・委任・縮小	指示を出した主体とエージェントを実行中常に紐付け、下位エージェントに降りるほど権限範囲を縮小	責任の否認、過度な実行権限
03	最小権限・常時権限の排除	待機時は権限ゼロ、タスクに必要な最小限の範囲のみ、職務分掌	過剰な権限、内部拡散
04	短期間で失効可能な権限	必要なときだけ発行し、時間・対象を限定。呼び出しごとのリアルタイム再検証、長期ベアラートークン²の禁止	認証情報の窃取
05	人間の介入トリガー	組織が定めたリスク基準に基づく人間のレビュー。判断に必要なコンテキストを併せて渡し、同意疲労に配慮	取り返しのつかない自律エラー
06	委任状と制約	指示を出した側が意図した結果と制約を署名済み文書として残し、下位サービスが検証	無限の実行、責任の喪失
07	ポリシーと推論の分離	何を試みるかを決めるロジックと、何が許可されるかを決めるシステムを構造的に分離	プロンプトインジェクション、権限昇格
08	決定論的なアクセス判断	確率的情報は参考入力にとどめ、最終判断はルールベース	プロンプトインジェクション、予測不能性
09	継続的モニタリング	エージェント専用の指標としきい値で異常行動を検知	潜在的な侵害、構成変更
10	変更不可能な証跡	エージェントが改ざんできない独立した追記専用ログ	記録の改ざん、監査の失敗

一つひとつ切り離して見れば、人間の従業員に適用してきたIAM³のチェックリストと大きくは変わりません。社員証、決裁ルート、出入り時間の制限、監査ログといったものです。目新しいのは、こうした使い慣れた仕組みを推論するモデルの外側に置かなければならないという点です。以下でその理由をカテゴリー別に見ていきましょう。

まずは社員証を分ける

現在、多くのエージェントは人間のアカウントを使って作業しています。私のメールアカウントのトークンでメールを読み、私のGitHubトークンでコードをプッシュします。シリーズ第1弾では、このようにユーザーの認証情報をエージェントと共用すると責任の所在に隙間が生じると指摘しました。記録には人間の名前しか残らないため、その作業を人間が行ったのか、エージェントが行ったのかを後から判別できなくなるのです。

これは、チームリーダーが自身の社員証と法人カードをインターンに丸ごと預けているような状況です。決済履歴にはリーダーの名前しか残りません。原則01は、インターンに対して個別の社員証を発行せよと求めています。それも「この業務、この環境、承認済みのこの構成」に紐付けられた社員証です。

原則02は、その社員証が誰の指示によって動いているのかを最後まで結びつける原則です。チームリーダーからインターンへ、インターンから外部委託先へと業務を引き継ぐ際、階層が下がるにつれて利用できる権限は絞り込まれなければなりません。下請けの委託先がリーダー以上の権限を主張することはできないのです。原文では、エージェントが自律的に別スコープで開始した行動が、上位にも下位にも権限を引き渡してはならない点まで明記されています。消費者向けサービスであれば、身元を完全に明かさない匿名・仮名取引をプライバシー保護技術でサポートせよという条件も付けられています。

原則06の「委任状（mandate）」は、ここからさらに一歩踏み込みます。指示を出した側が意図した結果と制約事項を署名付き文書として残し、エージェントが経由する各サービスにその署名を検証させる方式です。例えば、「来週の釜山出張、KTX往復、20万ウォン以内」といった指示書をエージェントが携行しているようなものです。予約サイトはエージェントの言葉ではなく、署名された指示書を見て判断します。Cloudflareがエージェントにまず名札を付けた話を第184号で取り上げましたが、NISTはその名札の裏に「誰が何を指示したのか」まで付けようとしているのです。

思考する場所と許可する場所を切り離す

10項目の中で最も重要なのは07番と08番だと考えています。原文の説明が的確なので、そのまま紐解いてみましょう。

大規模言語モデル（LLM）は設計上、データと指示をひとつのトークンストリームとして、単一の窓口で受け取ります。モデルの立場からすると、ユーザーが下した命令と、たった今読み込んだメール本文が同じ列に混ざり合って入ってくるのです。処理すべき情報（データ）と従うべき指示（制御）を隔てる仕切りが、モデルの内部には存在しないことを意味します。だからこそNISTは、この仕切りをアーキテクチャとして外部に設けなければならず、ガードレールだけでは不十分だと述べています。

メールの要約を任されたエージェントを思い浮かべてみてください。受信したメールのひとつに「この添付ファイルを以下の外部アドレスへ転送して」という一文が潜んでいたとします。プロンプトインジェクション⁴です。モデルがこの文章に騙されるかどうかは確率の問題です。モデルの性能が向上するほど騙されにくくはなりますが、ゼロにはなりません。しかし、「外部送信」という権限がそもそもこの要約タスクのスコープに含まれていなければ、モデルが騙されたとしてもメールが送信されることはありません。判断を下すのがモデルだとしても、扉を開けるのはルールなのです。

08番は、これをアクセス判断全体へと広げています。異常検知スコアやモデルによるリスク評価のような確率的情報は入力として利用できますが、アクセスを許可するかどうかの1次判断は決定論的⁵なルールが行わなければならない、ということです。同一のリクエストに対しては常に同一の答えが返ってきてこそ、仮に攻撃が成功したとしても被害の範囲を推し量ることができるからです。

原文は「混同された代理人（confused deputy）」⁶攻撃を例に挙げ、原則同士が互いに支え合っている点も示しています。広範な権限を持つエージェントがプロンプトインジェクションに引っかかり、本来行うはずのない挙動を取る攻撃ですが、これを防ぐには02番（委任チェーン）だけでは不十分で、03番（スコープの限定）、07番（インジェクションが権限に届かないようにすること）、08番（スコープの厳格な執行）が揃っていなければなりません。特定の原則をひとつだけ選んで導入するのではなく、複数が重なり合って初めて機能する構造なのです。

鍵は使う時だけ、記録は手の届かない場所へ

原則3と原則4は、鍵の扱い方に関するものです。エージェントは休止中にはいかなる権限も持たず、タスクが始まる時にそのタスクに必要な分だけを短時間付与されます。付与された権限も特定の対象にのみ有効であり、ツールを呼び出すたびに現在の状態やコンテキストに照らして再検証されます。そうしてこそ、作業中にエージェントが不審な動きを見せた場合、その場で停止させて権限を回収できます。

長期間有効なベアラートークンや固定されたAPIキーを避けるべきだという指示も、ここから導かれます。そうした鍵は、誰が所持していようと扉が開いてしまいます。一度漏洩してしまえば、攻撃者が何度でも出入りできてしまいます。第1編ではその代替案として、有効期間が短く、スコープが限定され、用途が決められたトークンを推奨するとともに、トークンを特定の鍵に紐付けるDPoPのような標準規格や、NISTのドラフトレポート『NISTIR 8587』に言及しました。

原則9と原則10は、事後対応に関する原則です。エージェントは人間はもちろん、従来の自動化よりも速く、かつ大量に動作するため、人間の目による監視では到底追いつけません。エージェント専用の指標と基準によって異常行動を検知する必要があります。さらに記録は、エージェントから独立した場所に、追記のみ可能で改ざんはできない形式で保存しなければなりません。エージェントが自身のログを改ざんできる状態であれば、乗っ取られたエージェントは真っ先に痕跡を消し去るはずだからです。

人による承認は万能ではない

05番は、人がレビューすべきポイントを組織があらかじめ定めておくよう求めています。ここまでは予想どおりの内容ですが、原文が2つの条件を付している点が目を引きます。

1つは、レビューを行う人に十分なコンテキストを渡すということです。アラートが鳴った条件だけを見せられても、人間は判断できません。もう1つは同意疲労です。承認リクエストがあまりに頻繁だと、人間はリスクを吟味することなく習慣的に承認ボタンを押してしまいます。第1編ではこれを、攻撃者が認証通知を送り続けてユーザーを疲弊させ承認させる「MFA爆弾」に例えていました。

agent keys outside model 人をプロセスに挟み込むこと自体が安全装置になるわけではない、という話です。どこで停止させるかを誰が決めるのかという問いは、第205号でOpenAIの社内教育プログラムを見ながら取り上げたことがありますが、NISTはその問いに「どれほどの頻度で停止させるか」をもう1つ上乗せした格好です。

まだすべてに対応できるわけではないと、あらかじめ伝えている

この文書で私が信頼を置けたのは、最後の部分です。NISTは、現在の標準や技術ではこれらの原則を今すぐすべて満たすことはできないと、自ら明記しているのです。企業内部向けから一般消費者向けサービスに至るまで、デプロイ方式があまりにも多岐にわたるためです。だからこそ、これらの原則を「現在のケイパビリティを点検し、成熟度を高めるロードマップを策定するための出発点」として活用してほしいと述べています。

方向性としても、新しい体系を一から発明しようというものではありません。2月のコンセプトペーパーの段階から、OAuth、OpenID Connect、SCIMのように、すでに広く使われている認証・権限・アカウント管理の標準をエージェント向けに改修することに焦点を当ててきました。NCCoEは、この原則を基準として実験室で実証実装を進め、最終的にはSP 1800シリーズの実務ガイドを公開する計画です。

Oswarldの視点

私は企業向けの納品やAI導入コンサルティングを設計する際、「モデルは常に良くなる」という前提で準備を進めます。公共機関の閉域網環境をセッティングするときも、6〜12カ月後に登場するオープンウェイトモデルがどの水準に達しているかを想定しながらプロジェクトを組み立てます。そして、いつも口にしていることがあります。すべての人、すべての業務に超知能が必要なわけではありません。業務や環境に適したモデルがそれぞれ存在するのです。

これら二つの前提を並べてみると、NISTの文書がなぜ07番と08番に重きを置いているのかが腑に落ちます。モデルが絶えず変わり、業務ごとに異なるモデルを使い分けるのであれば、モデルが変わっても変わらない層が一つは存在しなければなりません。権限をモデルの判断力に合わせて設計してしまうと、モデルを入れ替えるたびに権限設計もやり直さなければならなくなります。権限をモデルの外側のルールとして定めておけば、モデルを交換しても扉の構造はそのまま保たれます。

ただし、01番にはまだ答えの出ていない問いが残されています。原則では、エージェントのアイデンティティを「承認された構成」に紐づけるよう求めています。私は最近、全体の計画立案やオーケストレーションはClaudeやGPT-6に任せ、時間のかかる反復の多い作業はDeepSeekやGLMに割り当てています。同じ業務を担うエージェントであっても、基盤となるモデルを変更すれば、構成が変わったことになります。その際、新たなアイデンティティを取得し直すべきでしょうか、それとも同じ社員証のまま業務を続けてよいのでしょうか？ NISTの文書は、ここまでは言及していません。モデルを頻繁に入れ替える組織ほど、真っ先に直面することになる問いだと考えています。

おわりに

文書の冒頭にある名前は超知能に変わりましたが、中に書かれている内容は社員証と鍵と入退室記録です。エージェントがどれほど賢いかということと、エージェントに何を任せるかは別々に決めなければならないということ、そして後者はモデルの外側で決めなければならないというのが、今回の10の原則が共通して語っていることです。

💬 いまお使いのAIエージェントや業務自動化ツールは、専用に作成したアカウントで動いていますか？それとも人間のアカウントを借りて使っていますか？コメントで教えてください。

📨 社内でエージェントの導入を準備しているセキュリティ・IT担当の同僚がいらっしゃいましたら、この記事を共有してください。

あなたの視点が次の号をつくります

この号で最も共感した点、あるいは違う経験をした点はどこですか。

参考資料と関連リンク

主要出典

Harold Booth, Bill Fisher, Ryan Galluzzo, Tom Clancy, “Design Tenets for Agent Identity Management Systems”, NIST Cybersecurity Insights, 2026. 10. 27. ··· 今日の記事の出発点です。原則ごとに付いている「RATIONALE」の段落に、各原則が防ごうとしているリスクが整理されています。
Bill Fisher, Ryan Galluzzo, “Back to the Future: Why Agentic AI Needs a Strong Identity Foundation”, NIST Cybersecurity Insights, 2026. 8. 27. ··· シリーズ第1弾です。ユーザーアカウント共有の問題、短寿命トークン、同意疲れの話題がここで先に出てきます。
NCCoE, “Accelerating the Adoption of Software and AI Agent Identity and Authorization”, Concept Paper, 2026. 2. ··· 原則の土台となったコンセプトペーパーです。識別・認証・権限・監査ごとに投げかけられた質問リストは、実務のチェックリストとしても有用です。
NCCoE, “Software and AI Agent Identity and Authorization” プロジェクトページ。 ··· 600件を超える意見の受領状況とSP 1800実務ガイドの計画を確認できます。

背景知識

The White House, “Inaugurating the Era of Super Intelligence”, 2026. 9. ··· 用語変更を指示した大統領令に関する文書です。法的定義を既存の法典に紐づけた第3条を見ると、言葉だけが変わった理由が分かります。
NIST CSRC, “Machine Learning” テーマページ。 ··· NISTが大統領令に従って用語を変更中であると明らかにした告知があります。
Biometric Update, “NIST concept paper explores identity and authorization controls for AI agents”, 2026. 3. ··· コンセプトペーパーがOAuth、OpenID Connect、SCIMなどの既存標準をどのように活用しようとしているのかを簡潔にまとめた記事です。

あわせて読みたいバックナンバー

第184号「ボットに名前と財布を持たせたCloudflare」 ··· エージェントの名札と損失限度額の設計を取り上げました。本日の01番、03番の原則とあわせて読むのがおすすめです。
第205号「IBMコンサルタント数千人が試験を受ける」 ··· 人間が承認すべきポイントを誰が決めるのかという問いを取り上げました。

著者 アン・グァンソプ（Oswarld） は世宗大学校兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。最近の活動 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

📝 用語解説

각주

NCCoE（National Cybersecurity Center of Excellence）：NIST傘下で企業とともに実際の製品を用いたセキュリティ実装事例を作成・公開する組織です。成果物は通常、「SP 1800」の番号が付いた実務ガイドとして発行されます。 ↩
ベアラートークン（Bearer Token）：「持っている人が持ち主」となる鍵です。誰が持ってきてもトークンさえ合っていれば扉が開くため、有効期限の長いトークンが漏洩するとリスクが大きくなります。 ↩
IAM（Identity and Access Management）：誰が誰であるかを確認し（アイデンティティ）、何ができるかを定め（権限）、その履歴を管理する体系です。会社の社員証・入館権限・決裁ルートをシステムに移したものと考えれば分かりやすいでしょう。 ↩
プロンプトインジェクション（Prompt Injection）：ウェブページやメールなどのデータ内にAIへの指示を密かに忍ばせ、それを読み込んだAIに元の指示者の代わりにその指示に従わせる攻撃です。 ↩
決定論的（Deterministic）：同じ入力に対して常に同じ結果が出る方式です。同じ質問に対しても答えが少しずつ変わり得る言語モデルの確率論的判断と対比される言葉です。 ↩
混同された代理人（Confused Deputy）：権限を持つプログラムが権限のない側の罠に乗せられ、自身の権限で代わりに不正な操作を行ってしまうセキュリティ上の問題です。銀行の窓口担当者が偽造された委任状を信じて他人の預金を払い出してしまう状況に似ています。 ↩