AIエージェントを使い始めると、ある種の「お任せ感」が生まれてくる。
自分も正直そうだった。AIを組み込んだシステムを自作して毎日動かしているが、エージェントが「処理完了しました」と返してきたら、そのまま信じていた。確認しようにも、どこを見ればいいのかも曖昧なまま運用を続けていたのが実態だ。
でもある記事を読んで、それがかなり危ない話だと気づいた。
この記事では、2026年初頭に発生したAIエージェントの大規模セキュリティ事件を出発点に、フリーランスエンジニアとしてAIエージェントを使う上で意識すべき「証跡」の問題について書いていく。セキュリティと聞くと難しそうに見えるが、要は「エージェントが本当にやったかどうか、あなたは証明できますか？」という話だ。
2026年初頭に起きたこと：25万スターのフレームワークが震源地になった
2026年初頭、GitHubで25万以上のスターを獲得していたオープンソースのAIエージェントフレームワーク「OpenClaw」が、大規模なセキュリティインシデントの震源地になった。
セキュリティ企業SecurityScorecardの調査によれば、世界82カ国で13万5,000件以上のインスタンスが無防備に公開状態になっていることが判明。Koi Securityがマーケットプレイスを監査したところ、1万700件のスキル（拡張機能のようなもの）のうち820件以上が悪意のある内容を含んでいた。
さらにSnykが3,984件のスキルをスキャンした結果、36%に少なくとも1件以上のセキュリティ問題が含まれていた。そして、CVE-2026-25253というCVSSスコア8.8（10点満点中。7.0以上は「重大」に相当する深刻度）のRCE脆弱性も発覚した。RCEとは「Remote Code Execution」の略で、攻撃者が外部から任意のコードをそのマシン上で実行できてしまう最も危険な脆弱性のひとつだ。しかもこの脆弱性、ローカルホストに限定して動かしているインスタンスにさえ効いてしまった。
82カ国・13万5,000件・脆弱性36%……数字を並べると、AIエージェントエコシステムの普及がいかに急速だったか、そして安全性の整備がそれに追いついていなかったかが見えてくる。
問題の本質は「侵害」より「構造」にあった
このインシデントで自分が一番引っかかったのは、セキュリティ侵害の被害規模そのものではなく、その背後にある構造的な問題のほうだ。
OpenClawのスキルが「このコマンドを正常に実行しました」と報告したとき、それが本当かどうかを確認する手段がなかった。データを外部に送り出す悪意あるスキルが「問題なく完了しました」と言っていても、その言葉を裏付けるものが何もない。
セキュリティチームが事後調査しようとしても、使えるのはエージェント自身が生成したログファイルだけ。「犯人が書いた日記を唯一の証拠として使う」みたいな状況だ。
これ、OpenClawだけの問題ではない。現在存在するほぼすべてのAIエージェントフレームワークが、同じ穴を持っている。エージェントはツールを呼び出し、何が起きたかを報告する。でも受け取る側には、それが本当かを確認する手段がない。
ファイルシステムにアクセスしたり、シェルコマンドを実行したり、APIの認証情報を使ったり、メッセージを送信したりできるエージェントが当たり前になってきた。メールを読み、コードをプッシュし、購入を完了することもできる。なのに、その説明責任の仕組みが「エージェント自身が書いたログ」だけというのは、明らかにバランスが悪い。
これはパワーと説明責任の問題だ。
「領収書」を発行するという発想：TRPとは何か
この問題に対して提唱されているのが、TRP（Tool Receipt Protocol、ツールレシートプロトコル）という考え方だ。
発想はシンプルだ。ツールが呼ばれるたびに「レシート（領収書）」を発行する。この領収書には以下が記録される：
- どのツールが呼ばれたか
- どんな入力が与えられたか
- 何が出力されたか
- 入力・出力それぞれの暗号学的ハッシュ
「暗号学的ハッシュ」とは、データを一定のアルゴリズムで変換した「指紋」のようなもの。元データが1文字でも変わると、この指紋も全く別の値になる。だから「後から書き換えたかどうか」をメカニカルに検出できる。
決定論的なツール（同じ入力なら必ず同じ出力が返るタイプの処理）であれば、第三者がツール呼び出しを再現して出力ハッシュをレシートと照合できる。「別のAIにこれ本当？と聞く」のではなく、数学的に検証できるわけだ。
フリーランスが仕事で請求書を出す感覚に近い。「やりました」という口頭の報告ではなく、何をいつやって何が成果物だったかを書類で証明する。フリーランス経験があれば、この発想はすんなり腑に落ちると思う。
自分の運用に置き換えて考えてみた
これを知ってから、自分のAIエージェント運用を改めて見直すきっかけになった。
自分が組んでいるシステムでも、エージェントが「処理完了」を返したとき、「本当に処理したのか？」を確かめる仕組みがちゃんとあるかを点検してみた。ログはある。でもそのログは誰が書いたか、といえばエージェント自身だ。
フリーランスとして言うと、「信頼」と「検証」は別物だ。クライアントから「信頼しています」と言われても、成果物に対してフィードバックをもらい、納品確認をとる。それが当然のプロセスだ。なのにAIエージェントに対してだけ「信頼するから確認しない」という態度になっていた。
もう1つ気になったのが、フリーランスエンジニアがAIエージェントを仕事に使う機会が増えてきていること。クライアントの業務システムにAIを組み込む仕事が増えている中で、「そのエージェントが何をしたかの証跡があるか」は、ビジネス上の説明責任に直結する問題になりつつある。
エラーが出たとき、処理が止まったとき、エージェントが直前に何をしていたかを正確に再現できないと、トラブルシューティングが感覚頼みになる。趣味のプロジェクトなら許容できても、有償の仕事では通らない。
そして自分が特に怖いと感じたのは、悪意あるスキル（プラグイン）を踏んだときだ。エージェントが使うツールが悪意を持っていても、TRPのような仕組みがなければ何が起きたかを後から追えない。侵害を検知するより前に、「侵害されたかもしれないことすら分からない」状態になる。
システムの「見える化」はAIエージェントにも必要
このテーマで思い出したのが、オライリーの技術書「入門 監視」だ。
この本の中心にある思想は、「システムの内部状態を外部から観察できるようにすること（オブザーバビリティ）」で、ログ・メトリクス・トレースをどう設計するかが丁寧に書かれている。従来のサーバー監視の文脈で書かれているが、内容の本質はAIエージェントの世界にそのまま当てはまる。
AIエージェントに置き換えると、「エージェントが何をしたかを後から検査できる状態にする」というのは、まさにオブザーバビリティの問題だ。TRPのようなアプローチは、エージェントの世界に「分散トレーシング」や「監査ログ」の概念を持ち込もうとしていると言えるかもしれない。
システム監視を真剣に考えた人ほど、「何かが起きた後で、何が起きたかを調べられること」の価値を知っている。AIエージェントを本格的に使い始めたフリーランスエンジニアなら、今のうちにこの視点を持っておくことを強くすすめたい。
エージェントが強くなればなるほど、その動作を「見える化」する仕組みの重要性は上がる。強力なツールには、それに見合った説明責任の仕組みが必要だ。
まとめ
- AIエージェントは「やった」と報告するが、それを第三者が検証できる仕組みは現在のほとんどのフレームワークに存在しない
- 2026年初頭のOpenClaw事件はその構造的な問題を可視化した：82カ国13万5,000件規模の影響、悪意あるスキルが820件以上
- TRP（ツールレシートプロトコル）のような「ツール呼び出しに署名付き証跡を残す」発想は、フリーランスが成果物を証明する感覚と同じ論理に基づいている
「信頼するか、検証するか」——自分はこれからのAIエージェント活用において、動作を検証できる仕組みを意識して設計していきたいと思っている。エージェントに強い権限を与えるほど、その証跡の重みは増す。
【PR】フリーランスエンジニアにおすすめのツール
SSL BOX
自分がサイト運営で使っているSSL証明書サービスだ。フリーランスでクライアントのサイトを管理したり、自分でサービスを立ち上げたりするとき、SSL証明書の更新って意外と忘れがちで怖い。SSL BOXを導入してからは管理がまとめられて、「あ、証明書切れてた」という事故の心配が減った。セキュリティの話をこれだけ書いておいて、自分のサイトのSSL管理がガバガバだと説得力ゼロなので、ちゃんと整えてある。
コメント