AIエージェントに権限を任せるには｜IoT機器のID・委任の範囲・事故時の止め方

目次（タップで折りたたみ）

ある工場の設備保全部門が、AIエージェントに仕事を任せることにしました。設備の温度センサーを読み、異常があれば保守チケットを作る仕事です。ゆくゆくは、弁の開け閉めのような操作も任せたいと考えています。

試しに動かしてみると、監査ログには「agent-01」とだけ残っていました。これでは分からないことがいくつもあります。

同じモデルで動く別のエージェントと、同じものなのか。再起動した後も同じなのか
誰の依頼で動いたのか。どの会社が責任を負うのか
センサーを読むだけのはずが、設定を変えられる権限まで持っていないか

要になるのは、「そのエージェントは誰か」だけではありません。「誰の依頼で、どの機器に、何回まで、いつまで操作してよいか」です。この委任を、短い時間だけ有効な権限として出し、操作のたびに記録します。広い権限を長く持たせるほど、事故のときの被害が広がるからです。

決める順番は次のとおりです。まず、責任を負うのは誰か、許す操作はどこまでか。次に、どこから先は信用しないか、権限をいつ出していつ止めるか、どうやって本人と確かめるか。共有の台帳（ブロックチェーン）が要るかどうかは最後に考えます。

以下では、この温度センサーの例を最後まで使って、AIエージェントとIoT機器のIDの作り方を見ていきます。AIエージェントが支払いまで行う場合の基礎は「AIエージェント決済とは」で解説しています。

この記事で使う言葉

マシンアイデンティティ（Machine Identity）：人ではなく、プログラムや機器に与えるID
委任：人や業務の流れが、エージェントに「ここまでやってよい」と権限を渡すこと
状態証明（アテステーション）：機器やプログラムが、期待した状態で動いていることを確かめる仕組み
縮退：安全のため、できることを読み取りだけなどに絞って動かし続けること

まず、4種類の「誰」を分ける

「agent-01」の一語では、4つの別々のものが混ざっています。温度センサーの例に当てはめると、次のとおりです。

責任を負う会社（所有・運用主体）：工場を持つ会社や、その部門、委託先
エージェントの定義（論理主体）：「温度を見て保守を依頼するエージェント」という登録。IoT機器なら資産の記録
いま動いているプロセス（実行主体）：今日起動した、そのエージェントの実行。機器なら、その上で動くファームウェア
依頼した人（行為の委任元）：指示した保全担当者、上位のエージェント、業務の流れ

それぞれ、何で見分け、どれだけの間有効かが違います。

主体	識別する対象	寿命
所有・運用主体	企業、部門、委託先、サービスの責任者	契約・組織の変更まで
論理主体	AIエージェントの定義、IoT機器の資産レコード	用途の廃止まで
実行主体	エージェントの実行単位、ワークロード、機器上で動くファームウェア	数分〜数時間、または起動単位
行為の委任元	指示した人、上位のエージェント、業務ワークフロー	タスク・セッション単位

それぞれを何で証明するかは、後半の「実装する人向けの詳細」にまとめています。

AIエージェントでは、「どのソフトが動いたか」と「誰の依頼で何をしてよいか」が別の問題です。IoT機器では、「どの製品の個体か」と「いまのファームウェアが許された状態か」が別です。

AIエージェントと機器で共通のID基盤を作る場合も、この違いは消しません。共通にするのは、次の4つに限ります。

識別子の名前の付け方
鍵の発行
判定方針の評価
監査記録の形式

標準づくりも途中です。NISTのNCCoEは2026年2月5日に、コンセプトペーパーを公開しました（NCCoE: Software and AI Agent Identity and Authorization Concept Paper、意見募集は2026年4月2日まで）。ソフトウェアとAIエージェントの識別、認可、権限の委任、監査を、企業で使うときの課題として整理しています。既存の標準がどこまで使えるかを確かめる段階で、完成したAIエージェントのID標準ではありません。

だから、特定の製品のID方式に全面的に頼らないことです。あとで別の方式に替えられるように作っておきます。

任せる権限は、範囲・期限・回数・人の承認で縛る

AIエージェントの事故の多くは、本人確認の失敗から起きるのではありません。正しいエージェントが、広すぎる権限を長く持っていることから起きます。

そこで委任は、署名付きの記録として出します。中身は次のとおりです。

依頼した人と、実行するエージェント
許す対象と操作、期限、最大回数
人の承認が要る操作の一覧

温度センサーの例では、次のように縛ります。

読むことと、物を動かすことを別の権限にする：センサーの値を読むのを許しても、弁の開け閉めや設定の変更は許さない。
仕事が終われば権限も終わる：権限に仕事の番号（タスクID）と期限を入れる。完了・中断・エージェントの停止で、すぐに失効させる。
上位のエージェントから下へ渡すときは、狭める一方にする：子に渡せるのは、親の権限と判定方針が両方許す範囲だけ。
人の承認を権限の条件に入れる：物理的な操作、送金、設定変更は、承認の番号がなければ実行できないようにする。

本人確認が通っても、その操作をしてよいとは限らない

「鍵を持っているのは確かにこのエージェントだ」と確かめるのが認証です。「このエージェントが今回の操作をしてよいか」を決めるのが認可です。認証が通ったことを、業務上の許可と同じに扱ってはいけません。

状態証明を使うときも同じです。証拠を評価する役と、その結果で業務を判断する役を分けます。IETFのRATSという仕様が、この役割分担を定めています。

IoT機器側の状態証明の役割分担、証拠の鮮度、登録から失効までの流れは「DePIN機器のIDとリモートアテステーション設計」で詳しく扱っています。

身元の確かめ方は、動く場所によって変えます。

クラウドで動くエージェントやゲートウェイ：プログラムに、短い時間だけ有効な身分証を自動で配る仕組み（SPIFFE）が候補になる。
通信できない小型センサー：同じ仕組みを載せる必要はない。製造時に守られた領域へ入れた鍵、機器ごとの識別子（IEEE 802.1AR DevID）、ゲートウェイが代わりに確かめる方法など、機器の能力に合うものを選ぶ。

NISTIR 8259AのIoT機器の基本要件は、各機器を論理的・物理的に一意に識別できる能力を挙げています（NIST: Device Identification）。

ただし、一意な機器IDだけでは、いま安全な状態かも、操作してよいかも証明できません。状態の証明に使うRFC 9711 Entity Attestation Tokenも、利用者の識別や認可とは別の仕組みとされています。

8つの状態のうち、まず4つ。いつ切り替えるか

「有効」と「失効」の2つだけでは、区別できない場面があります。登録の前、鍵の入れ替え中、一時的な隔離、持ち主の移転、状態を証明できないときなどです。

全体では8つの状態を用意します。ここでは、そのうち次の4つを先に見ます。

使える（ACTIVE）：状態証明と承認が通った。判定方針の範囲で動ける。
読むだけに制限（DEGRADED）：状態を確かめられない、時計がずれた、監視に異常が出た。物を動かす操作や決済は拒否する。
止める（SUSPENDED）：調査、保守、持ち主の確認待ち。出した権限は失効させる。
無効（REVOKED）：鍵の漏えい、改ざん、契約の終了。元に戻さず、登録からやり直す。

残りの4つ（検出、登録中、鍵の入れ替え中、廃止）を含めた全体の表は、後半にまとめています。AIエージェントにもIoT機器にも、同じ状態を定義します。

温度センサーの例で、1回の操作をどう確かめ、どう残すか

エージェントが温度センサーを読み、異常時に保守チケットを作るまでを、次の順で確かめます。

依頼を確定する：依頼した人か上位の業務の流れのID、タスクID、許す設備群、期限、最大の操作回数を、署名付きの委任にします。
エージェントの実行を証明する：承認済みのプログラムと実行環境であることを証明します。エージェントの定義のIDに、短い時間だけ有効な実行IDを結びつけます。
機器の状態を確かめる：センサーの機器ID、鍵、ファームウェアの版、直近の状態証明の時刻、止められていないかを見ます。
判定方針に照らす：依頼者、実行者、対象、操作、環境、判定方針の版を入れて評価します。読むことと物を動かすことは別の権限です。
同じ操作が二重に起きないようにする：チケット作成や設備の操作には、一意の操作IDを付けます。タイムアウトした後は、結果を照会してからでないとやり直しません。
記録を残す：入力データそのものは残しません。参照ID、判定結果、権限ID、判定方針の版、実行結果、時刻を監査ログに残します。

IoTネットワーク全体のサービス単位、作業の証明、不正対策、精算の設計は「DePINネットワークの作り方」を参照してください。AIエージェントの支払い権限と二重実行の対策は「x402の仕組みと実装」で扱っています。

事故の種類ごとに、止め方を変える

状態を証明するサービスが止まっても、エージェントや機器が乗っ取られたとは限りません。一方、鍵が漏れたなら、すぐに止める必要があります。エージェントの誤った判断は、本人確認が正しくても起きます。これらを同じ手順で止めると、止めすぎるか、止め足りないかのどちらかになります。だから、事故の種類ごとに止め方を変えます。

鍵が漏れた：権限をすぐ失効させ、対象を「無効」か「止める」へ移します。影響があった期間の記録を評価し直し、新しいルートから登録し直します。
状態証明のサービスが止まった：乗っ取られたとは限りません。最後に成功した時刻と操作の危険度に応じて、読み取りだけ、順番待ちで保留、拒否のどれかに絞ります。
登録台帳やチェーンが止まった：最後に確定したブロックと、キャッシュの期限を記録します。古い状態のまま物を動かす操作や高額の決済を続けないよう、止める条件を決めておきます。
時計がずれた：短い有効期限の証明書、使い回し防止の番号（nonce）、記録の順番の判定が壊れます。許せる差を超えた機器は「読むだけに制限」へ移し、時刻を合わせてから確かめ直します。
持ち主が変わった：鍵を渡すだけで済ませません。前の委任、トークン、保守の権限を失効させ、どの時刻で切り替えたかを監査用に残します。
エージェントが誤った判断をした：本人であることが確かでも、出した答えが正しいとは限りません。物を動かす操作、送金、設定変更には、許す範囲、上限、人の承認、元に戻す手段を別に用意します。

ブロックチェーンは要るか

1つの会社がすべての機器、エージェント、判定方針を管理し、台帳を誰が管理するかで参加者が争わないなら、PKI、IAM、資産DB、改ざんを検知できる監査ログで足ります。

候補になるのは、複数の組織が同じ登録・失効の状態を確かめたいときです。メーカー、持ち主、保守会社、エージェントの提供者、利用する企業などが、1つの管理者を全面的には信頼できない場合です。そのときも、置くのは一緒に確かめるのに要る最小限の情報だけです。

情報	推奨する置き場所	理由
登録ID、所有者の参照、鍵・証明書の参照先	必要ならオンチェーン	組織をまたぐ発見と変更の検証に使える
失効・停止の状態、判定方針・スキーマの版のハッシュ	必要ならオンチェーン	共有する最小の状態と改ざんの証跡になる
監査記録を集約したルート値	必要ならオンチェーン	詳細を開示せず、後日に整合性を検証できる
秘密鍵、APIトークン、機器の秘密情報	オフチェーンの保護領域	公開台帳へ置けば秘密ではなくなり、更新も難しい
プロンプト、センサーの生データ、位置・顧客情報	アクセス制御したストレージ	容量、機密性、削除・訂正、相関のリスクがある
詳細な認可の判定方針	判定エンジン（policy engine）	即時の変更、状況に応じた評価、機密の条件に対応する

エージェント向けのブロックチェーン上の登録の提案もありますが、まだ草案です（詳細は後半）。チェーンに登録しても、社内での持ち主の確認、短い権限、委任の範囲、実行時の状態証明の代わりにはしません。

W3CのDIDやVCを使う場合も同じです。DIDが鍵のありかを示すことと、その管理者を業務上信頼することは別です。詳しくは「DID・VCの導入設計」で整理しています。

どの方式にするかは、5つの試験で決める

方式の良し悪しは、次の5つの試験に通るかで判断します。

試験	合格条件	確認する失敗
主体の追跡	1件の記録から、所有者、論理ID、実行ID、委任へたどれる	共有のAPIキーで主体を区別できない
権限の制限	タスク終了、回数超過、対象外のリソースで即時に拒否される	エージェント停止後もトークンが有効
鍵の更新	業務の停止許容時間内に更新し、期限後は旧鍵を拒否できる	オフラインの機器が永久に旧鍵を使い続ける
縮退運転	状態証明・登録台帳の停止時に、リスク別に読み取り／保留／拒否へ移る	キャッシュだけで危険な操作を継続
監査の再現	当時の判定方針と権限で、許可した理由を再計算できる	最新の判定方針で過去の記録を誤って判定

PoCでは、正常に署名が通ることだけを見ません。次の異常をわざと起こします。

漏れた鍵、失効の反映の遅れ、再送
時刻のずれ、ネットワークの分断
持ち主の移転

ブロックチェーン案を検討するなら、同じ試験を通常のPKI・共有DB案でも行います。複数の組織の間の食い違い、復旧時間、運用費まで含めて比べます。

管理者が1つで足りる場合は、ブロックチェーンを使わない判断も合理的です。機器がよくオフラインになり、失効をすぐ確かめられない場合も同じです。

実装前のチェックリスト

所有者、論理主体、実行主体、委任を別のIDで追える。
人、AIエージェント、IoT機器、ゲートウェイの責任の範囲と操作対象が一覧になっている。
長く有効なAPIキーを共有せず、短い権限と最小権限を使う。
発行、鍵の更新、一時停止、失効、廃止の承認者と対応期限がある。
状態を証明できない、登録台帳の停止、時計のずれ、ネットワークの分断のときの縮退条件がある。
オンチェーンに置く項目ごとに、「複数の組織が共有して確かめる理由」を説明できる。
秘密情報、個人情報、生データ、詳細な判定方針を公開台帳へ置いていない。
監査記録に、判定方針の版、権限ID、操作ID、結果が残る。
鍵の漏えいとエージェントの誤った判断を、別の事故対応手順で扱う。
通常のPKI・IAM・DB案よりブロックチェーン案が優れる条件を測れる。

実装する人向けの詳細

ここからは、さきほどの工場で実際に仕組みを組む担当者向けの話です。

4種類の主体を何で証明するか

所有・運用主体：法人ID、契約、IAM上の責任者
論理主体：エージェントID、資産ID、製造番号との対応
実行主体：短命な証明書、ワークロードの状態証明、起動時の計測値
行為の委任元：依頼者（subject）と実行者（actor）を含むトークン、承認ID、タスクID

委任をトークンに記録する（RFC 8693）

OAuthのトークン交換を定めるRFC 8693は、2つを分けて表す仕組みを定めています。誰のためのトークンか（subject_token）と、権限を委ねられて実際に動く主体（actor_token、JWTではactクレーム）です。「委任元」と「実行主体」を1つのトークンに並べて記録する方法の1つになります。

状態証明の役割分担（RFC 9334）

状態証明を使う場合は、IETFのRFC 9334 RATS Architectureに沿います。証拠（Evidence）を評価する役と、その結果で業務判断する役を分けます。

信頼の連鎖は「登録・証明・権限・行為」を分ける

所有者 / ワークフロー → ID登録台帳 → 状態の検証（Attestation Verifier）→ 判定方針の評価 → 短命な権限

AIエージェントの実行 ⇄ APIゲートウェイ ⇄ IoTゲートウェイ / 機器

各行為には所有者ID・論理ID・実行ID・委任ID・判定方針の版を記録

ワークロードと機器のID

SPIFFE：SPIFFE IDと短命なSVIDを発行するワークロードの識別（workload identity）。信頼ドメイン、識別子、X.509/JWT形式のSVID、Workload APIを定義している（SPIFFE Specification）
IEEE 802.1AR DevID：機器ごとに持たせる識別子の規格。小型センサーの選択肢の1つ
エージェントの実行の証明：承認済みのイメージのダイジェスト（中身から計算した値）と実行環境を証明する

8つの状態の全体

状態	許可	遷移条件	失敗時の処理
検出（`DISCOVERED`）	なし	資産・エージェントの候補を検出	未登録として隔離
登録中（`ENROLLING`）	登録APIのみ	所有者、ルート鍵、用途を検証	同じ申請IDで照会し、重複登録を防止
使える（`ACTIVE`）	判定方針の範囲	状態証明と承認が成功	短命な権限を再取得
読むだけに制限（`DEGRADED`）	読み取り専用等へ縮退	状態を確認できない、時計のずれ、監視の異常	物理操作・決済は拒否
止める（`SUSPENDED`）	原則なし	調査、保守、所有者の確認待ち	発行済みの権限を失効
鍵の入れ替え中（`ROTATING`）	旧鍵と新鍵を短期間だけ併用	承認済みの鍵更新	期限後は旧鍵を拒否
無効（`REVOKED`）	なし	鍵漏えい、改ざん、契約終了	再有効化せず、登録からやり直す
廃止（`RETIRED`）	なし	廃棄・エージェントの廃止・所有者の移転	監査記録だけを保持

ERC-8004の位置づけ

ERC-8004 Trustless Agentsは、エージェントのIdentity Registry、Reputation Registry、Validation Registryを提案しています。確認した時点でもDraft（草案）です。ERC-721としての登録を、企業内の所有者確認、短命な権限、委任の範囲、実行時の状態証明の代わりにはしません。

XTELAができること

私たちは、マシンアイデンティティの技術選定にとどまらず、AIエージェントとIoT機器を含む業務フロー、委任と権限の表、状態遷移、監査項目を設計し、鍵漏えいや失効遅延を注入するPoCとして実装しています。貴社のエージェントに任せたい操作を一つ選び、範囲・期限・回数・人の承認で縛った委任から始められます。法的責任や個別の契約に関わる判断は、弁護士と連携して進めます。ご相談はお問い合わせからどうぞ。

参考資料

資料の確認日

標準と策定中の仕様（ERC-8004がDraftであることを含む）は、2026年9月24日時点で確認した内容に基づいています。

記事一覧