AIエージェントの設計は外部から複製されうる｜研究解説

【更新 2026-08-02】本記事を見直し、修正しました。主な修正点：論文の著者数を訂正しました（「Yu Cui氏ほか7名」→「Yu Cui氏ほか6名」。arXivの著者欄・論文本文とも著者は計7名）。

社内で作り込んだAIエージェントの「中身」は、外から使えるだけで写し取られる可能性がある——2026年7月30日にarXivで公開された査読前の研究が、そう指摘しています。攻撃者はモデルの重みもソースコードも必要とせず、通常の対話（ブラックボックスアクセス）を繰り返すだけで、エージェントを動かしている指示や連携手順を段階的に復元できたと報告されています。

これは「作った資産が盗まれる」という知財の話にとどまりません。エージェントの設計が割れるということは、どこに安全策が仕込まれているかも割れるということです。生成AIを社内業務に組み込み始めた組織にとっては、設計の前提を見直す材料になります。

この記事でわかること
そもそも「ハーネス」とは何か
何が新しいのか：黒箱アクセスだけで2段階に復元する
情シスにとっての本題は「知財」ではない
現場目線の課題
情シスはどうすべきか
限界・留意点
まとめ
関連記事
出典

この記事でわかること

「ハーネス」とは何を指すのか、なぜそれが資産なのか
査読前研究が示した、ブラックボックスアクセスだけで設計を復元する2段階の手口
知財漏えいより情シスに効いてくる「守りの位置が割れる」という二次被害
社内AIエージェントを運用するうえで、今のうちに固めておくべき前提

そもそも「ハーネス」とは何か

ハーネス（harness）とは、LLM本体の外側で推論と行動を組み立てる仕組みのことです。具体的には、システムプロンプト（役割指示）、タスクの分解手順、複数エージェントへの役割分担と受け渡し、呼び出せるツールの定義、失敗時のリトライ方針といった一式を指します。

論文が強調しているのは、このハーネスが安く手に入るものではないという点です。組み合わせが膨大な探索空間の中で反復的に最適化され、しかも土台となるLLMの更新に合わせて作り直す必要がある。つまり相応の工数と計算資源が投じられた、その組織固有のノウハウの塊です。

何が新しいのか：黒箱アクセスだけで2段階に復元する

研究チーム（Yu Cui氏ほか6名）が提案したのは Agent Harness Distillation（AHD） という枠組みです。手口は大きく2段階に分かれます。

段階	やること
pre-distillation （事前蒸留）	対象のエージェントに問いかけ、応答の癖・手順の踏み方から、ハーネスの初期的な振る舞いを推定する
post-distillation （事後蒸留）	推定したハーネスを自分の手元で動かし、本物との差分を見ながら反復的に精緻化していく

複数のLLMバックボーン上で実験した結果、実運用されている自律型マルチエージェントシステムにも相当な知財漏えいリスクがあると論文は結論づけています。あわせて、抽出の精度を下げつつ本来の機能は保つ「欺瞞（deception）」ベースの防御案も提示されています。

情シスにとっての本題は「知財」ではない

「うちのプロンプトなんて盗まれても困らない」と感じる担当者は多いはずです。実際、ハーネスそのものの商業価値が問題になるのは、AIエージェントを製品として外販している組織に限られるでしょう。

ただ、情シスにとって効いてくるのは二次被害のほうです。ハーネスが復元されるということは、次のような情報が相手に渡るということでもあります。

ガードレールの位置と文言：「この話題には答えるな」「この操作は承認を取れ」という指示がどこに書かれているかが分かれば、それを避ける入力を設計できてしまう
ツールの一覧と権限：エージェントがどの社内システムを叩けるのかが、外から推測できる
社内固有の情報：プロンプトに書き込みがちな組織名、承認フロー、内部システム名、URLなど

この3点目については、OWASPのLLM向けリスク一覧でも LLM07:2025 System Prompt Leakage として独立した項目になっています。そこでの指摘は明快で、システムプロンプトは秘密ではないし、セキュリティ制御として使ってはいけないというものです。認可の判定や権限分離は、LLMの外側で決定論的に効かせる必要があります。

現場目線の課題

正直なところ、この手の話が刺さるのは「社内チャットボットを作ってみた」段階を越えた組織だと思います。ただ、実際に困るのはたいてい作った直後ではなく、その後です。

社内向けに公開したエージェントは、業務委託先の担当者も、異動予定者も、退職手続き中の社員も触れます。「社内限定だから安全」という線引きは、実務ではかなり緩い。しかもプロンプトの改修は開発チームが独自に回していることが多く、情シス側からは今どんな指示が入っているのか把握できていない——このもどかしさは、端末の細部まで目が届かない状況とよく似ています。

加えて、ハーネスは棚卸しの対象にすらなっていないことがほとんどです。サーバやアカウントは台帳があるのに、エージェントのプロンプトとツール定義は誰の管理下にあるのか曖昧、というケースは珍しくないでしょう。

情シスはどうすべきか

この研究を受けて特別な新製品が必要になるわけではありません。むしろ、既存の指針に立ち返るのが実際的です。

まず参照したいのが、IPAの AIセキュリティのページです。「AI利用者のためのセキュリティ豆知識」「AIシステムに対する既知の攻撃と影響」といった資料が整理されており、AIシステムに対する攻撃をひととおり俯瞰するのに向いています。利用者側の啓発資料としてもそのまま配れる粒度なので、開発チーム任せにせず全社で共有する使い方が効きます。

技術的な設計方針は、前掲のOWASP LLM07が挙げる原則がそのまま指針になります。認証情報や接続文字列をプロンプトに書かない、重要な制御をプロンプトの言い回しに依存させない、出力の検査はモデルの外側の仕組みで行う——この3つを満たしていれば、仮にハーネスが復元されても被害は限定できます。

そして地道ですが、プロンプトとツール定義を構成管理の対象に含めること。誰がいつ何を書き換えたかが追えない状態では、漏えいしたときに何が漏れたのかすら分かりません。