2026年8月28日／株式会社東京ネット工務店 海老沢敦
① 事実
米国立標準技術研究所(NIST)が、AIを入れた会社の問題を5つ挙げました
2026年8月27日、米国立標準技術研究所（NIST＝米国政府が使う技術基準を決める機関。暗号や情報セキュリティの規格を出しています）のサイバーセキュリティ研究拠点が、公式ブログで提言を出しました。書いたのは Bill Fisher と Ryan Galluzzo の2氏。進めているプロジェクトの名前は「Software and AI Agent Identity and Authorization」——ソフトウェアとAIエージェントの、身元と権限。
冒頭の一文が、こうです。
初期のエージェント導入は、見慣れた型を繰り返している——機能の開発と目先の価値を、安全より先に置くという型を。
タグ＝セキュリティ
実際の導入現場で見つかった問題を、5つ挙げています。
- 認証情報の共有——人が、自分の認証情報（IDとパスワード、あるいはそれに相当する鍵）をエージェントに渡している。誰がやったのかを、後から追えなくなります。
- 期限の無い、静的な鍵——APIキー（システムに接続するための長い文字列の鍵）やベアラートークン（bearer＝持参人。持参人払いの小切手と同じで、持っている側が誰であれ、それだけで通ります）。なりすましができます。
- 広すぎる権限——役割ごとにまとめて与えるため、範囲が大きくなる。データの一括削除のような、意図しない被害が起きます。
- 手元のアカウントを、そのまま使わせている——エージェントに、その機械の利用者アカウントの資格をそのまま持たせる形。
- 人の承認への依存——最後は人が承認するから安全、という設計。NISTはこれをconsent fatigue（承認疲れ）と呼んでいます。
5番目に、こういう説明が付いています。MFA bombing（多要素認証の通知を、被害者が反射的に承認するまで浴びせ続ける攻撃）と同じ形になる、と。承認を求める回数が増えると、人は中身を見ずに押すようになります。 そうなった時点で、承認は安全装置として働きません。
ブログの題は「Back to the Future」です。 新しい仕組みを作れ、とは書いていません。対策として挙がっているのは、OAuth 2.0、SPIFFE、DPoP、ゼロトラスト（社内の内側だからと信用せず、接続のたびに身元と権限を確かめる考え方。NIST SP 800-207）——すべて、既にあるものです。
鍵を手渡した記憶がなくても、4つの場面で渡っています
1番目の「認証情報を渡している」は、鍵を手渡した記憶がなくても成立します。当てはまる場面を並べます。
- 自分のPCにAIエージェントを入れて動かした。 そのPCには、社内システムにログインしたままの状態、保存されたパスワード、クラウドの接続情報が入っています。あなたが開けるものは、AIも開けます（NISTの1番目と4番目）。
- AIツールの設定欄に、業務システムのAPIキーを貼り付けた（2番目）。
- 「このアプリからのアクセスを許可しますか」で、許可を押した。 メール、カレンダー、共有フォルダ。自分が見られるものが、そのまま範囲になります（3番目）。
- 確認の画面で「今後は確認しない」を選んだ（5番目）。
どれも、その時は業務を進めるための操作です。 鍵を渡すつもりでやった人は、ほとんどいません。
同じ日、Anthropicは鍵の種類を入れ替えました
同じ2026年8月27日、AnthropicがClaude APIのリリースノートを更新しました。
これまで主に使われてきたのは、ワークスペースAPIキー（作業場ごとに発行する鍵）です。ここに2種類が加わりました。個人キー（発行した本人として動く）と、サービスアカウントキー——サービスアカウントとは、人ではないもの、つまりプログラムやAIに与える、専用の利用者登録です。
リリースノートの一文が、こうです。
Workspace API keys remain supported as a legacy option.
（ワークスペースAPIキーは引き続き使えます。旧来の選択肢として。）
理由は、公式の認証ドキュメントの表に書かれています。 鍵の種類ごとに「Acts as」——その鍵は、誰として動くのか——という欄があります。
| 鍵の種類 | 誰として動くか | いつ止まるか |
|---|---|---|
| 個人キー | あなた自身（あなたの役割と権限のまま） | あなたが組織から外れたとき |
| サービスアカウントキー | そのサービスアカウント | そのアカウントが停止されたとき |
| ワークスペースキー（旧来） | No one（誰でもない） | 期限切れ・無効化・削除。作った人が辞めても、止まりません |
同じドキュメントに、こうあります。
keys won't accidentally outlive the people or workloads that own them
（鍵が、持ち主である人や処理より長生きしてしまうことがなくなります。）
共有された個人キーについては、こう書かれています。 「一人の人間として動くので、その人が辞めれば止まる」。止まることが、仕様として書かれています。
期限を付けると、入れ替える人が要ります
Anthropicはその4か月前、2026年5月4日に Workload Identity Federation（ワークロードID連携）を出しています。
AIやプログラムが、自社が既に運用しているアイデンティティプロバイダー（IdP＝社員や機械の身元を一元管理する仕組み。Microsoft Entra ID、Okta、Google Workspace など）から身元の証明を受け取り、それと引き換えに、期限付きの鍵を受け取ります。 身元の受け渡しには OIDC（OpenID Connect＝ログイン済みの身元を、別のサービスに証明として渡す共通の規格）を使います。
受け取る鍵の期限は、既定で1時間（3,600秒）。設定できる範囲は60秒から24時間まで。設定画面の初期値は10分です。期限が来る前に、プログラムが自動で取り直します。
公式ドキュメントの説明が、こうです。
There are no static secrets to mint, store in CI, rotate, or leak.
（発行して、保管して、定期的に入れ替えて、漏らす対象になる固定の秘密が、そもそも存在しません。）
APIキーにも、期限は設定できます。 Anthropicの管理画面では、3時間・1日・7日・30日、あるいは任意の期間を選べます。「無期限」も選べます。
期限を付けると、切れる前に入れ替える作業が生まれます。 誰かがその作業をやらないと、鍵が切れた時点でシステムが止まります。ワークロードID連携が置き換えているのは、その入れ替え作業のほうです。 プログラムが期限前に自動で取り直すので、人の手が要りません。
出典（一次）：
- NIST NCCoE「Back to the Future: Why Agentic AI Needs a Strong Identity Foundation」（2026年8月27日／Bill Fisher・Ryan Galluzzo）https://www.nist.gov/blogs/cybersecurity-insights/back-future-why-agentic-ai-needs-strong-identity-foundation
- Claude Platform リリースノート（2026年8月27日＝個人キーとサービスアカウントキーの追加／2026年5月4日＝Workload Identity Federation）https://platform.claude.com/docs/en/release-notes/api
- Claude Platform「Authentication」（鍵の3種類と「Acts as」の表）https://platform.claude.com/docs/en/manage-claude/authentication
- Claude Platform「Workload Identity Federation」（トークンの期限・対応する提供元）https://platform.claude.com/docs/en/manage-claude/workload-identity-federation
- 引用の訳は当社によります。 原文は各URLにあります。
② 構造
鍵そのものか、鍵を持つ誰かか
AIに使わせる鍵には、2つの作りがあります。 Anthropicの公式ドキュメントに、一行の対比があります。
a workspace API key is a credential, while a service account has credentials
（ワークスペースAPIキーは、資格そのものである。サービスアカウントは、資格を持っている。）
この違いが、記録に出ます。
鍵そのものが権限を持っている場合、その鍵で何が行われても、記録に残るのは鍵の名前だけです。 誰が使ったのかは、記録の外にあります。だから公式の表は、その欄に「誰でもない」と書いています。
会社の中の権限は、人に割り当てる仕組みしかありません。 職務権限規程も、システムの利用者登録も、退職時のアカウント停止も、全部「人」を単位に作られています。AIには、その単位がありません。 だから人の権限を借ります。借りたまま動けば、記録に出るのは貸した人の名前です。
「営業データには使わない」と決めても、守られたかは確かめられません
AIの利用ルールは、上の階層の話です。 誰が使ってよいか、何に使ってよいか、どこまで任せるか。本紙のVol.22で、中小企業の6割が「個人の判断に任せている」と答えた調査を扱いました（方針を決めていない、という状態です）。
今回のNISTの指摘は、その下の階層にあります。 誰の権限で動いているか。
下が空白だと、上のルールは確かめられません。 「営業データには使わない」と決めても、誰がどのデータに触れたかの記録が人単位で残っていなければ、守られたかどうかを検証できません。 方針を決めた会社と、決めていない会社が、同じ場所に立つことになります。
プログラムの変更は全員分残ります。AIが何をしたかは、残りません
ソフトウェアの世界では、同じ問題を一度解いています。
Git（プログラムの変更履歴を管理する仕組み）は、誰が、いつ、どの行を変えたかを、全員分残します。 中小の開発現場でも、これは標準になりました。コードについては、記録の問題は片付いています。
片付いていないのは、実行の側です。 AIエージェントは、各自のPCで、各自の鍵で動いています。何をしたかの記録は、その人の機械の中にあります。会社には残りません。
NISTのブログの題「Back to the Future」は、そこを指しています。人間のアカウント管理では、同じ部署で一つのIDを共有するやり方を捨てて、個別のIDにしました。 誰がやったかを残すためです。AIエージェントの世代で、共有に戻っています。
コードの管理は集約された。エージェントは、この1年で各自の手元に分散した。集約への揺り戻しが、始まっています——鍵を人と機械に紐づけ、会社の身元管理に接続する方向です。8月27日の「legacy」の印は、その一歩です。
AI側は、先に動いています
この話を「AIが鍵を盗む」と読むと、外れます。
AI側は、すでに鍵を見ないように作られています。 設定ファイルに書かれた認証情報を避ける、読み込まない、表示しない。それでも読んでしまったときには、自己申告してきます——「認証情報を見てしまいました。ローテーション（鍵を新しいものに入れ替えること）をしてください」。
これは、AIエージェント側の自衛です。 追いついていないのは、鍵を渡す側の配線です。
自己申告には、受け皿が要ります。 「入れ替えてください」と言われて、その鍵を入れ替えられる人が、その場にいるかどうか。 ここで規模が効きます。
③ 自分事
個人開発なら、手元を固めれば足ります
小規模な会社では、社長が全部を把握できます。 鍵を作ったのも、使っているのも、入れ替えるのも、同じ人間です。AIエージェントを動かしている機械を固めておけば、いまのところ足ります。「見てしまいました」と申告が来たら、その場で入れ替えます。
数人の会社も、同じです。 ここに書いたことの大半は、まだ関係がありません。関係が出るのは、使い方が変わったときです。
数十人で、バラバラに使い始めたときに効きます
分かれ目は、AIを使う人と、鍵を作る人が別になったときです。
数十人の会社には、部門があります。AIを使うのは各部署の担当者で、鍵を発行するのは総務や情シスです。 ここで、さきほどの自己申告が宙に浮きます。担当者の画面に「ローテーションしてください」と出ても、その担当者に鍵を入れ替える権限はありません。 総務に伝わるかどうかは、担当者がそれを重大だと判断するかどうかにかかります。中身を分かっていない人が、緊急度を判定することになります。
もう一つ、人が辞めたときです。 会社には、退職時にアカウントを止める手続きが既にあります。メール、勤怠、会計、共有フォルダ。 チェックリストになっている会社も多いはずです。
AIの鍵は、その手続きに繋がっていません。 担当者が自分で作って、自分の設定ファイルに書いて、動かしています。総務は、その鍵の存在を知りません。 止める対象の一覧に載っていないものは、止まりません。
新しい仕組みは要りません。 既にある退職の手続きに、その一行を足すだけです。 NISTが「Back to the Future」と書いたのは、この意味です。
当社のAIチャットは、集約する側の設計です
当社が提供しているCoBANTO3-AIチャットは、この形で作っています。 社内向けに使う場合、個々の社員が自分でAIの鍵を取得して、自分の機械に置く形にはなりません。 会社が窓口を一つ持ち、そこを通します。
理由は、認証情報のコピーを許さないためです。 鍵が各自の手元に散ると、誰がどれを持っているかを会社が把握できません。把握できないものは、止められません。
⚠️ これで安全になる、という話ではありません。 窓口を一つにすると、その窓口の記録が全部になります。 誰が何を訊いたかが残る、ということでもあります。どちらを選ぶかは、会社の判断です。 本紙が言えるのは、いま自社がどちらの形になっているかを、把握している必要があるということだけです。
明日できること
決裁は要りません。訊くことと、確かめることだけです。
- 「そのAI、誰のIDで動いていますか」と訊く。 答えが「私のIDです」なら、1番目に当たっています。担当者を責める話ではありません。 そう作らないと動かなかった、というだけです。
- 先月辞めた人が作った鍵が、まだ生きていないか確かめる。 一覧を出せるかどうかから始まります。一覧が出せない状態そのものが、答えです。
- 次に鍵を作るとき、期限を入れる。 そして、切れる前に入れ替える人を、同時に決める。 期限を付けると入れ替え作業が生まれます。面倒だから無期限にする——期限の無い鍵が現場に残る理由は、たいていこれです。作業を決めずに期限だけ付けると、ある日システムが止まります。
- 「認証情報を見てしまったので入れ替えてください」と出たとき、誰が入れ替えるかを決めておく。 決めていないと、その通知は担当者の画面で閉じられます。
最初の問いに戻ります。 渡した覚え、ありますか。覚えが無いのが普通です。 自分の機械でAIを動かした時点で、その機械が開けるものは、全部渡っています。 渡す操作をしていないから、記憶に残りません。
確かめるのは、渡したかどうかではありません。 渡っているものの一覧が、会社の手元にあるかどうかです。
今月のモデル
新しいAIが出るたびに、点数が並びます。ですが、点数と、自社の仕事で使えるかどうかは、別です。
今号は、新ネタ無しです。
CoBANTO3-AIチャット
https://www.netkomuten.tokyo/lp/co-banto3-ai
本紙のバックナンバーを記憶し、本紙の読み方（戦略の階層・歴史循環）で、あなたの会社の状況に当てて答えるAIチャットです。記事は「地図」ですが、地図は現地には当たりません。「この号の話、うちの場合はどうなるのか」を訊く場所として用意しました。
ご利用は事前購入のクレジット制です（1,000円から）。月額の契約ではないので、解約の手続きはありません。使った分だけ減り、無くなれば止まります。
読者登録をいただいた方に、無料クレジットを500クレジット追加させていただきました。ぜひ使ってみてください。
ライトノベル「ようこそ、東京ネット工務店へ」
https://www.netkomuten.tokyo/channels/novel-tnk-part2/articles/ch27
小さなIT企業の現場を書いた小説です。毎号1話ずつご紹介します。
今号の話：〈第二部 第27章「AIが書いた」〉
出社すると、夜中の二時に「自分の名前」で提出物が上がっていました。その時間、誰も起きていません。
Q&Aコーナー
AI・IT業界に関するご質問を募集しています。CoBANTO3-AIチャットのサポートも、こちらへお願いします。
いただいたお名前は匿名にして回答します。内容によっては、個別に回答させていただく場合があります。