エージェントの記録は改ざんされうる｜EQTY Labが示す証明

「エージェントが取引先にメールを送った記録はある。でも、その記録が後から書き換えられていないと、どうやって証明するのか」「承認ボタンを押したのが誰かはログに残っているが、そのログ自体を管理者が直せてしまう」——AIエージェントを業務に入れ始めた会社の、監査や情報システムの担当者から出てくる問いです。2026年3月18日、米国の EQTY Lab は NVIDIA の開発者会議 GTC 2026 で、エージェントの行動とその承認者をハードウェアの側で検証して記録する仕組みを発表しました。この発表が突きつけているのは、普通の操作ログは、書いた側が書き換えられる限り、第三者に対する証拠としては弱いという事実です。この記事では、普通のログで足りる場面と足りない場面、記録を検証できる形にする考え方、その制約と費用、まず整えるべきことを整理します。

EQTY Lab は、AIとエージェントの統制と証跡を扱う会社

EQTY Lab は米国の企業で、AIモデルやエージェントが「どのデータで作られ、どんな方針のもとで、誰の承認で動いたか」を、後から検証できる形で残すための製品を作っています。公式サイトに並ぶ製品は、エージェントと業務の流れを社内の規程や安全基準に沿わせ、報告を自動化する AI Guardian、統制の項目を一つの画面で定義して点検する Governance Studio、社内のAIシステムを一覧にして系譜を地図のように示す機能などです。系譜を示す機能は、公開のAIモデル共有サイトで無償版も出しています。

同社の特徴は、記録の信頼の起点をソフトウェアではなくハードウェアに置こうとしていることです。2024年12月にはインテル、NVIDIA と共同で「検証可能な計算」の枠組みを発表し、2025年7月には NVIDIA の最新世代の画像処理用半導体の上でこれを動かしたと公表しました。また、記録の要約値を公開型の台帳（ブロックチェーン）に刻んで時刻と内容を固定する仕組みを「AIの公証」と呼んで説明しています。

公式サイトや公表資料では、公共部門、ライフサイエンス、金融を主な適用先に挙げています。リナックス財団の機密計算の業界団体と、同財団の金融部門の団体にも加わっており、米国の大手セキュリティ会議の新興企業コンテストで最終候補に選ばれた経歴もあります。規制が厳しく、記録の証明力が問われる業界に寄った会社と見るのが実態に近いでしょう。一般の事業会社がすぐに導入する道具というより、考え方を学ぶ相手として有用です。

2026年3月の発表：検証可能な実行環境

2026年3月18日、EQTY Lab は米サンノゼで開かれた NVIDIA の開発者会議 GTC 2026 に合わせて、自律的に動くAIエージェントのための「検証可能な実行環境（ベリファイアブル・ランタイム）」を発表しました。公式ブログの説明では、NVIDIA の企業向けAI基盤とエージェントの実行環境の上で、エージェントを安全に動かし、その監督をハードウェアに根ざした形で行うものです。

公式の説明によると、この仕組みは三つのことを暗号の技術で証明するとしています。一つ目は、エージェントが動いている最中も行動が方針に沿っているかを継続して点検していること。二つ目は、各行動を誰が許可したかの連鎖（委任の連鎖）と、エージェントに与えられた権限の証明書を記録すること。三つ目は、セキュリティの方針がエージェント自身には書き換えられず、重要な認証情報にもエージェントが直接触れられないことです。

ただし、この発表は製品の一般提供ではありません。公式ブログは、会場で見せた実演を「エージェント統制の道のりの第一歩」と位置づけ、提供に向けた計画を示した段階です。最初の参考実装は同社のAIゲートウェイ（Gateway）とされていますが、一般提供の時期、価格、ライセンスの条件は公表されていません。性能への影響がほとんどないという説明も、公開された計測結果は確認できませんでした。この記事でも、発表された考え方として扱います。

• この記事の製品の説明は、EQTY Lab の公式ブログと公式サイト、台帳を運営する団体の事例紹介による。2026年3月以降の提供状況は公式で確かめてほしい
• 検証可能な実行環境は、同社が2024年12月にインテル・NVIDIA と発表した「検証可能な計算」の枠組みを土台にしていると公式は説明している

課題：普通の操作ログでは、説明責任を果たせない場面がある

エージェントを業務に入れると、多くの会社はまず操作ログを取ります。どのエージェントが、いつ、どの道具を呼び、何を送ったか。承認が必要な操作では、誰が承認ボタンを押したか。これで社内の振り返りは十分にできます。ところが、その記録を社外の誰かに証拠として示す場面になると、話が変わります。

たとえば、エージェントが取引先に誤った見積もりを送り、取引先が損害を主張したとします。会社は「担当者が承認していない、エージェントの誤作動だ」と説明したい。取引先は「本当は承認していたのに、後からログを直したのではないか」と疑う。このとき会社が出せるのが、自社のサーバーに自社が書いたログだけだと、書き換えていないことを、書いた本人が証言しているだけの状態になります。監査人や規制当局に対しても同じ構図が生まれます。

この問題は、エージェントが増えるほど重くなります。人が操作していた時代は、操作した本人に聞けば一定の説明ができました。エージェントが人の代わりに動き、しかも複数のエージェントが互いに仕事を渡し合う形になると、記録だけが事実を語る唯一の材料になります。その材料の信頼性が、説明責任の重さを決めます。

普通のログで足りる場面、足りない場面

すべてのエージェントに検証可能な記録が必要なわけではありません。むしろ、ほとんどの社内業務では普通のログで足ります。分け方の軸は、記録を誰に見せ、その相手が自社の言い分を疑う理由があるかです。社内の改善会議で振り返るだけなら、記録を疑う人はいません。社外の相手と利害が対立しうる場面ほど、記録の証明力が問われます。

場面	記録を見る相手	普通のログ	検証できる記録
社内の業務改善・不具合の振り返り	社内の担当者	足りる	不要
社内監査・内部統制の点検	監査部門	多くは足りる（変更履歴の管理が前提）	あれば望ましい
取引先への説明、取引上の紛争	取引先・相手方の弁護士	疑われると弱い	効く
規制当局への報告、許認可業務	当局	業界の要求次第	要求されうる
人の権利に影響する判断（採用、与信、医療）	本人・当局・裁判所	弱い	効く

表の下の行ほど、検証できる記録の価値が上がります。EQTY Lab が公共部門やライフサイエンス、金融を適用先に挙げているのも、この表の下の方の場面が多い業界だからです。逆に、マーケティングの記事の下書きや社内の問い合わせ対応のように、間違っても社内で直せば済む業務に、ハードウェアに根ざした記録を入れる意味は小さいでしょう。どのエージェントがどの場面に当たるかを、まず仕分けることが出発点です。

原因1：記録を書く仕組みと、記録される側が同じ場所にいる

普通のログが証拠として弱い原因は三つに整理できます。一つ目は、ログを書く仕組みと、記録される対象（エージェントやその管理者）が、同じサーバーや同じ管理権限の中にいることです。エージェントを動かしているサーバーの管理者は、多くの場合ログの保存先も消したり直したりできます。エージェント自身がログを書く設計なら、エージェントの不具合や乗っ取りが、そのままログの改ざんにつながるおそれもあります。

EQTY Lab の発表は、この原因に正面から手を入れています。公式ブログによると、記録と方針の執行を担うのは、エージェントが動くサーバー本体とは物理的に分かれた NVIDIA のデータ処理用の専用チップ（DPU）です。このチップは独自の処理装置を持ち、エージェントの実行環境の記憶領域を直接のぞけるとされています。記録する側を、記録される側の手の届かない場所に置くという考え方です。

この考え方自体は、ハードウェアがなくても応用できます。たとえば、エージェントのログを、エージェントを管理する部署とは別の部署が管理する保存先に、書き込み専用で送る。保存先では削除や上書きをできない設定にする。こうするだけで、少なくとも「エージェントの管理者がこっそり直す」経路は塞げます。ハードウェアの仕組みは、その分離をより強く、管理者も含めて誰にも破れない形にしたものと理解するとよいでしょう。

逆に、次のようなログの持ち方は、社内の振り返りには使えても、社外に示す証拠としてはほとんど力を持ちません。エージェントを導入した直後の会社でよく見かける形です。

• エージェントを動かすサーバーの中に、エージェント自身がログを書き込んでいる
• ログの保存先の削除や上書きの権限を、エージェントの運用担当がそのまま持っている
• 承認の記録が「承認済み」という状態の項目だけで、誰がいつ押したかが別の場所にしかない
• エージェントの方針の設定を変えても、変更の履歴と承認が残らない
• ログの保存期間が短く、取引先から問い合わせが来た時点で既に消えている

原因2：誰が承認したかが、委任の連鎖として残っていない

二つ目の原因は、承認の記録の持ち方です。多くのシステムでは、承認は「誰々が承認ボタンを押した」という1行のログとして残ります。ところがエージェントの世界では、承認はもっと複雑な連鎖になります。部長が担当者にエージェントの利用を許可し、担当者がエージェントに見積もり作成を任せ、そのエージェントが別のエージェントに価格計算を頼む。事故が起きたとき問われるのは、最終的な行動が、どの人の、どの許可にさかのぼれるのかです。

EQTY Lab の発表で「委任の連鎖」と呼んでいるのが、まさにこれです。公式の説明では、各行動を誰が許可したか、エージェントにどんな権限の証明書が与えられていたか、行動が方針に沿っていたか、セキュリティの状態が改ざんされていなかったかを記録するとしています。許可が人からエージェントへ、エージェントから別のエージェントへ渡るたびに、その受け渡しを証明できる形で残す発想です。

ただし、公式ブログを読む限り、人の承認者がどう記録されるか（どの本人確認と結びつけるか、承認の画面をどう作るか）の具体的な説明はありません。ここは導入を考える会社が自分で設計しなければならない部分です。承認者の本人確認が弱ければ、どれだけ記録を固くしても、「誰が」の部分は信用できません。記録の強さは、いちばん弱い輪で決まります。

原因3：方針そのものが、後から書き換えられる

三つ目の原因は、エージェントが従うべき方針（何をしてよいか、何をしてはいけないか）が、記録とは別に書き換えられることです。行動のログが完全に残っていても、その時点でどの方針が有効だったかを示せなければ、「その行動は許されていたのか」を判断できません。方針の設定ファイルを誰かが一時的に緩め、事故の後で元に戻していたとしたら、ログだけでは見抜けません。

公式ブログでは、セキュリティの方針はエージェント自身には書き換えられず、別の管理面で管理され、専用チップが執行すると説明しています。また、重要な認証情報（外部サービスの鍵など）には、エージェントが直接触れられないとしています。エージェントが自分の権限を広げたり、鍵を持ち出したりする経路を、構造的に断つ考え方です。

普通のシステムでこれに近づけるには、方針の変更そのものを記録の対象に含めることです。方針の版を管理し、変更には承認を必須にし、どの時点でどの版が有効だったかを行動のログと結びつけて残す。行動の記録と方針の版の記録を、同じ時刻の軸でつなげることが、後から「許されていたか」を判断する前提になります。

対策の考え方：記録を「検証できる」形にするとは

記録を検証できる形にする仕組みは、専門用語を使わずに言えば三つの道具の組み合わせです。一つ目は「指紋」です。記録の中身から、中身が1文字でも変われば別物になる短い値（ハッシュ値）を計算します。二つ目は「印鑑」です。その指紋に、特定の装置しか持たない鍵で署名します。三つ目は「消印」です。署名した指紋を、時刻とともに、自社だけでは書き換えられない場所に預けます。

この三つがそろうと、後から誰かが記録を直したとき、指紋が合わなくなり、直したことが分かります。EQTY Lab の公式ブログでは、専用チップがエージェントの処理の中身と実行時の状態から指紋を作り、チップ上の鍵で署名した証明を出すとし、この証明はエージェントのソフトウェアからは偽造できないと説明しています。消印の役割は、同社が公開型の台帳に要約値を刻む仕組みが担います。

大事なのは、この仕組みが証明するのは「記録が改ざんされていない」ことであって、「行動が正しかった」ことではないという点です。エージェントが誤った見積もりを送ったなら、検証できる記録は「誤った見積もりを送ったこと」を確かに証明します。記録の強さと、エージェントの判断の正しさは別の問題で、後者は相変わらず人が確認する範囲を決めて担保するしかありません。

対策1：承認者の記録は、人と権限と時点の三つで持つ

承認者の記録をどう持つかは、ハードウェアの有無にかかわらず設計できます。基本は、承認ごとに「誰が（本人確認された個人）」「何の権限で（役職や委任の根拠）」「いつ、どの方針の版のもとで」承認したかの三つを一組にして残すことです。「承認済み」という状態だけを残すと、後から承認者を差し替えても分かりません。

エージェントに仕事を任せる委任も、承認と同じ扱いにします。部長が担当者にエージェントの利用を許したこと、担当者がエージェントに特定の業務を任せたこと、その範囲と期限を、委任の一件ごとに記録として残すのです。エージェントが別のエージェントに仕事を渡す場合も、どの委任の範囲内で渡したかを残します。範囲を超えた受け渡しは止める設計にしておくと、委任の連鎖が自然に記録されます。

ここで、何を承認の対象にするか、どの操作に人の承認を挟むかは、AIに決めさせないでください。エージェント自身に「この操作は承認が必要か」を判断させると、承認を省く方向に誤るおそれがあります。承認が必要な操作の一覧は、業務の責任者が決めて方針に書き、エージェントはそれに従うだけにします。

対策2：ハードウェアに根を置く仕組みと、その制約

EQTY Lab の仕組みの強みは、記録の信頼の起点を、管理者でも手を出せない専用チップに置くことです。ソフトウェアだけの仕組みでは、最終的にはサーバーの管理者や、クラウドの事業者を信じるしかありません。チップに根を置けば、その信頼の連鎖を、半導体の製造元が保証する鍵までさかのぼれることになります。第三者に示す証拠としての強さは、ここから来ます。

一方で、制約もはっきりしています。一つ目は、特定の会社のハードウェアに依存することです。公式ブログの説明は NVIDIA の企業向けAI基盤と専用チップを前提にしており、それ以外の環境で同じ証明が得られるかは示されていません。二つ目は、エージェントが外部のAIサービスを呼ぶ場合です。自社の管理下にないクラウドのAIの中で何が起きたかまでは、自社のチップでは証明できないので、証明できる範囲は自社の基盤で動く部分に限られます。

三つ目は、提供の段階です。前述のとおり、2026年3月の発表は計画と実演の段階で、一般提供の時期や価格は公表されていません。四つ目は、記録の読み手の側の準備です。暗号の証明を、監査人や取引先が自分で検証できる道具と知識を持っているかも問われます。どれほど強い証明でも、相手が確かめられなければ、結局は「専門家がそう言っている」という説明になってしまいます。

五つ目は、やめた後の扱いです。記録の証明は、何年も後に取引先や当局から問われることがあります。提供元との契約を終えたり、ハードウェアを入れ替えたりした後でも、過去の証明を自社や第三者が検証できるのか、検証に必要な鍵や手順の資料を手元に残せるのかを、導入前に確かめてください。公式ブログは記録の形式が開かれていることで他社も互換の監督の道具を作れると述べていますが、これは今後の構想として書かれたものです。証明の寿命が、提供元との契約の寿命より短くならないようにしておくことが、長く使う前提になります。

何が社外に出るか：公開型の台帳と、外部の基盤

検証できる記録を作るとき、何が社外に出るかを確認しておく必要があります。EQTY Lab の仕組みで社外に出うるものは二つあります。一つは、公開型の台帳に刻む要約値です。台帳を運営する団体の事例紹介によると、同社は機密計算の環境で作った証明をまとめ、その記録を公開型の台帳に刻んで、時刻つきの変更できない監査の跡にしているとされます。

このとき台帳に載るのが指紋のような要約値だけなのか、ほかの情報も含むのかは、事例紹介では明らかにされていません。一般論としては、指紋からは元の記録の中身を復元できないため、要約値だけを載せる設計なら中身は社外に出ません。ただし、どの情報が台帳に載るのか、載った情報は消せないことを、導入前に必ず提供元に確認してください。公開型の台帳は、一度載せたものを削除できないのが性質です。個人情報が混じれば、消去の求めに応えられなくなります。

もう一つは、統制の管理画面やゲートウェイを、提供元のクラウドで使う場合のデータです。エージェントの行動の記録そのもの、方針、委任の情報が提供元の基盤に置かれるなら、それは委託先にデータを預けることになります。記録の置き場所、保存期間、提供元の社員が閲覧できるか、契約終了時に返還・削除されるかを、通常の委託先の審査と同じ項目で確かめます。

費用と規模感：どんな会社が検討の対象になるか

費用については、公式の公表がありません。ただし、前提となる基盤から規模感は推し量れます。NVIDIA の企業向けAI基盤と専用チップを自社で持ち、その上でエージェントを動かしている、またはその予定がある組織が対象です。自前でAIの計算基盤を持つ規模の組織であり、一般的な事業会社が、クラウドの生成AIをそのまま使っている段階で導入する道具ではありません。

検討の対象になりやすいのは、公共機関や、医薬・研究開発、金融のように、記録の証明力が規制や取引の条件として求められる組織です。同社の事例にも、検察の捜査を支えるエージェントや、研究データの検証の取り組みが並んでいます。日本の事業会社であれば、まず自社のエージェントのうち、表の下の方の場面に当たるものがどれだけあるかを数えることが先です。一つもなければ、当面は普通のログの整備で十分です。

費用を考えるときは、導入の費用だけでなく、運用の費用も見ます。方針の版管理、承認者の本人確認、委任の記録、証明の検証の手順書と、それを担う人。これらはハードウェアを入れても自動では整いません。むしろ、人の側の運用が整っていない会社が強い記録の仕組みだけ入れても、弱い輪が人の側に残るだけです。

まず普通のログで整えるべきこと

EQTY Lab のような仕組みを入れるかどうかにかかわらず、エージェントを使う会社がいま整えておくべきことがあります。ここで挙げる手順は、ハードウェアがなくても実施でき、将来もっと強い仕組みに移るときの土台にもなります。監査で見られる記録の項目や保存期間は別に整理が必要ですが、ここでは「改ざんされにくさ」と「承認の追跡」に絞ります。

最後の手順は、EQTY Lab の仕組みの「消印」に当たる部分を、既存の手段で近づけるものです。日本には、電子文書が特定の時刻に存在し、その後改ざんされていないことを証明する時刻認証の制度があります。ハードウェアの証明ほど強くはないが、自社だけの言い分よりは格段に強い記録になります。費用も小さく、まず試すには向いています。

導入を検討する前のチェックリスト

検証できる記録の仕組みを検討する段階に来たら、提供元に話を聞く前に、社内で次の点を確かめておきます。答えが曖昧なまま製品の説明を聞くと、仕組みの強さに引っ張られて、自社に必要な範囲を見誤りがちです。

• 記録を社外に示す必要があるエージェントはどれか、その相手は誰か
• 相手は暗号の証明を自分で検証できるか、検証の手順を誰が説明するか
• 承認者の本人確認はどの仕組みで行い、記録と結びつけられるか
• エージェントの方針は版で管理されており、変更に承認が要るか
• エージェントが外部のAIサービスを呼ぶ部分は、証明の範囲の外になることを受け入れられるか
• 公開型の台帳に何が載るか、載った情報は消せないことを確認したか
• 特定のハードウェアへの依存を、自社の基盤の計画と両立できるか
• 記録の保存期間と、提供元との契約終了時の扱いが決まっているか

このうち半分以上に答えられない場合は、製品の検討よりも先に、前の節の普通のログの整備に戻るのが近道です。記録の仕組みは、記録すべき事柄が決まって初めて役に立つからです。そして、何を記録し、誰が承認し、どの操作に人の確認を挟むかは、最後まで人が決める事柄です。AIに統制の設計をさせることはできても、その設計に責任を持つのは人です。

まとめ

エージェントの操作ログは、書いた側が書き換えられる限り、第三者に対する証拠としては弱いものです。EQTY Lab が2026年3月に発表した検証可能な実行環境は、記録と方針の執行を専用チップに移し、行動と委任の連鎖を偽造できない形で証明しようとする試みで、規制の厳しい業界に向いた考え方を示しています。一方で、提供時期や価格は未公表で、特定のハードウェアに依存し、外部のAIの中までは証明できません。まずは自社のエージェントを場面で仕分け、ログの保存先を分け、承認と委任と方針の版を一組で残し、要約値を外に預ける。そのうえで、社外に証明すべき場面が実際にあるときに、ハードウェアに根ざした仕組みを検討してください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。