AI 向けの「案内」を用意する仕様や慣習は、ここ 1〜2 年で一気に増えました。置けば AI に見つけてもらいやすくなる一方で、書き方を誤ると「攻撃者向けの地図」にもなります。

この記事では、このブログ（クエビコ）のログに実際に残った探索を手がかりに、AI 向けの案内ファイルとセキュリティの勘所を整理します！

このブログに実際に来た「探索」

このブログは、しばらく閲覧できる相手を限って運用していました。2026年10月6日の昼に誰でも閲覧できる状態にしたので、その前後のログを読みました（送信元のアドレスなど個人を特定できる値は載せません）。

1 行目の検査ツールは、名乗り（User-Agent）に「Chrome-Lighthouse」を含み、送信元は Google のホスト名でした。Google が開発する検査ツール Lighthouse は、2026年9月公開の 13.5 版で AI エージェント向けの検査に ai-catalog.json の確認を加え、既存の llms.txt の確認と並べました。robots.txt も読むのは、ai-catalog.json の置き場所の指定（後述の Agentmap 行）を探すためです（Lighthouse v13.5.0 リリースノート）。

OpenAI のクローラーは名前だけなら誰でも名乗れるので、OpenAI が公開する送信元アドレスの一覧と照らし合わせました。今回のアクセスはすべて一覧の範囲内でした。

目を引いたのは最後の行です。公開後に来たある送信元は、.git/HEAD を見たあと、約 2 秒のうちに AWS 用の .env.aws.local と並べて .env.anthropic・.env.openai・.env.openai.local・.env.gpt・.env.llm・.env.ai を要求しました。AI サービスの API キーを置いていそうな名前を並べた探索です。これらはサイトの前に置いている WAF（Web アプリケーションファイアウォール）が、公開してはいけない種類のファイルへのアクセスとして 403 で止めました。そもそも、このブログにそうしたファイルはありません。

同じ日のログに、「AI 向けの案内を読みに来る検査ツール」と「AI の鍵を探しに来る探索」が並んでいたわけです。

AI向けの「案内」は大きく3種類

サイトが AI に向けて出す案内は、目的で分けると次の 3 つです。

これとは別に、robots.txt が「どのボットに来てほしいか」を伝えます。順に見ていきます。

llms.txt：AI 向けのサイト案内

llms.txt は、2024年9月に Jeremy Howard 氏が提案した、サイトのルートに置く Markdown のファイルです。サイトの概要と、詳しい情報へのリンクを、AI が短い文脈で読める形にまとめます。提案は v2 に改訂され、主要な AI 事業者も自社の開発者向けドキュメントに置いています（llms-txt「The /llms.txt file」）。

提案文書は、robots.txt とは目的が違うと書いています。robots.txt は「どんなアクセスを受け入れるか」を伝え、llms.txt は利用者を手伝う AI がその場で読む情報で、主に学習ではなく回答の生成に使われる想定です。

一方で Google は、検索の AI 機能（AI による概要など）に表示されるために、新たな機械可読ファイルや AI 用のテキストファイルを作る必要はないと明言しています（Google 検索セントラル「AI features and your website」）。llms.txt は、置けば必ず効くものではありません。

ai-catalog.json（ARD）：サイトの「道具」の目録

ARD（Agentic Resource Discovery）は、AI エージェントが使える道具（MCP サーバ、A2A エージェント、スキルなど）を、Web ページのように検索して見つけられるようにする仕様です。Microsoft・Google・GoDaddy・Hugging Face などの参加者が作る草案で、2026年6月に公開が告知されました（Hugging Face「Agentic Resource Discovery: Let agents search」）。

サイトは自分のドメインに道具の目録（マニフェスト）を置き、各項目に識別子・表示名・種類・接続先の URL などを書きます。検索サービス（レジストリ）がそれを集めて索引を作り、エージェントは「やりたいこと」で検索して道具を選びます。

ここで注意したいのが置き場所の名前です。2026年8月26日付の v0.91 で、目録の場所は /.well-known/ard.json に一本化され、従来の /.well-known/ai-catalog.json は「前の版の名前」になりました。読み手が旧名を見るかどうかは任意で、旧名にしか置いていない目録は見つけてもらえない可能性があります。目録の場所は、robots.txt の Agentmap: 行や HTML の link 要素でも示せます（ARD Specification v0.91）。2026年10月6日時点の Lighthouse のソースは旧名の ai-catalog.json を見に行くので、このブログのログにも旧名が残っていました。

Agent Card（A2A）：エージェントの自己紹介

A2A（Agent2Agent）は、AI エージェント同士が仕事を頼み合うためのプロトコルです。各エージェントは能力・接続先・認証方式を書いた Agent Card を /.well-known/agent-card.json に置いて見つけてもらいます（A2A Protocol Specification）。ARD の目録は、こうした Agent Card や MCP サーバの説明を「指し示す」側の仕組みです。

robots.txt：AIクローラーの書き分け

AI のクローラーは、学習用（OpenAI の GPTBot、Anthropic の ClaudeBot など）・AI 検索用（OAI-SearchBot・Claude-SearchBot など）と目的で名前が分かれ、Google の Google-Extended は Gemini の学習やグラウンディング（回答の根拠づけ）への利用を断るための robots.txt 上の名前です（OpenAI・Anthropic・Googleの公式ドキュメント）。書き分け方と守られる実態は、シリーズの AIクローラーとサイト運営 で詳しく扱っています。

📄 論文: エージェントの「目録」は、どんな方式が競っているのか

Evolution of AI Agent Registry Solutions: Centralized, Enterprise, and Distributed Approaches（Aditi Singh ほか、2025年8月、arXiv:2508.03095）は、査読前の論文（プレプリント）です。AI エージェントを見つけるための仕組みとして、MCP のレジストリ、A2A の Agent Card、分散型のディレクトリ、企業向けのディレクトリなど 5 つの方式を取り上げ、セキュリティ・認証・規模の拡大・保守のしやすさの 4 つの観点で比べました。

著者らは、中央集権的な管理・企業の統制・分散による耐障害性の間のトレードオフを示し、検証できる身元や共通の語彙が必要だと結論づけています。

運営者にとっての意味は、「見つけてもらう仕組み」も、載っている情報の身元を確かめる仕組みも、まだ発展途上だということです。

📄 論文: エージェントの道具は「読む」から「動かす」へ

How are AI agents used? Evidence from 177,000 MCP tools（Merlin Stein、2026年3月、arXiv:2603.23802）も査読前の論文です。2024年11月〜2026年2月に公開リポジトリで作られた MCP の道具 177,436 個を、データを読む道具・分析する道具・外部の環境を変える「行動」の道具に分類しました。

ツールの利用全体に占める「行動」の道具の割合は、16 か月で 27% から 65% に増えていました。金融取引のような影響の大きい道具もあります。

運営者にとっての意味は、目録に載せた道具が「何かを変更できる」なら、見つけた相手が実際に操作を試みうるということです。

セキュリティの視点：「案内」は攻撃者も読む

公開した目録は、攻撃面の一覧になる

ai-catalog.json（ard.json）や Agent Card は、誰でも読める場所に置くファイルです。社内向けの MCP サーバや管理用の API を載せれば、攻撃者には「どこに何があるか」の一覧になります。

A2A の仕様は、認証した相手にだけ詳しい内容を見せる「拡張 Agent Card」の取得に認証を必須とし、その拡張カードにさえ、漏れたら悪用されうる情報（内部サービスの URL や資格情報など）は載せるべきでないとしています（A2A Protocol Specification）。公開のカードに載せないのは言うまでもありません。

ARD の仕様は、認証を道具ごとのプロトコルに任せ、目録の仕組みとしては定めていません。仕様の例でも、社内のエージェントは社内の検索サービスから返す形です。社内の道具は公開の目録ではなく、社内の仕組みで案内するのが筋です。また ARD は、識別子に含まれるドメインと発行元の証明が一致するかを検索サービス側で確かめる仕組みを用意しています。なりすましの目録が出回りうる前提の設計です。

llms.txt と robots.txt は「お願い」であって強制ではない

robots.txt はアクセス認可の仕組みではないと、標準（RFC 9309）自身が明記しています（RFC 9309）。llms.txt も、AI に「ここを読んでほしい」と伝えるだけで、読まれたくないページを守る力はありません。見せたくないものは、認証の内側に置くのが原則です。

AI の API キーを狙う探索への備え

.env は、設定やパスワード、API キーを書いておく定番のファイル名です。公開ディレクトリに置いたままだと、URL を当てるだけで中身を読まれます。探索側は AI サービス向けの名前まで用意しています。

📄 論文: Web に置き忘れられた API キーは珍しくない

Keys on Doormats: Exposed API Credentials on the Web（Nurullah Demir ほか、2026年3月、arXiv:2603.12498）は arXiv 版で、ACM CCS 2026 に採録されています。1,000 万の Web サイトを実際に表示して調べ、14 の事業者向けの資格情報 1,748 件が、実際に使える状態で露出していることを確かめました。表 2 によると、そのうち OpenAI の鍵は 181 件でした。

露出の多くは公開用にまとめた JavaScript の中や外部から読み込む部品で起きていて、ソースコードを静的に調べるだけでは見逃されがちでした。露出は数か月から数年残ることが多かったといいます。

運営者にとっての意味は、.env を置かないだけでなく、公開するファイルに鍵が混ざっていないかを確かめ、漏れたら無効にするところまでが対策だということです。

このブログの結論

ai-catalog.json（ard.json）は置きません。 このブログは記事を読んでもらうサイトで、AI エージェントに提供する道具（MCP サーバや API）がありません。載せるものが無い目録を置く理由はなく、検査ツールで「見つからない」と出ても、それで正しい状態です。

llms.txt は、置いたままにして期待はしない、という扱いにします。 実はこのブログの llms.txt は、使っている SEO プラグインが自動で作っていました。中身は公開済みの記事の題名・要約・URL とサイトマップへのリンクで、すでに誰でも見られる情報です。AI の助けになるなら良いものの、検索の AI 機能に出る条件ではありません。下書きや非公開の情報が混ざっていないかだけ、ときどき確かめます。

robots.txt は、今は AI 向けの書き分けをしていません。

AIエージェント時代のサイト運営の鍵は次の3点です

1. 案内ファイルは「誰が読んでも困らない」ものだけにする
   ai-catalog.json（ard.json）や Agent Card は攻撃者も読みます。社内の道具や内部の URL は載せず、詳しい情報は認証の内側に置きましょう。
2. llms.txt と robots.txt は「お願い」と心得る
   どちらもアクセスを止める力はありません。守りたいものは認証やサーバ側の制御で守ります。
3. AI の鍵は置かない・埋め込まない・漏れたら無効にする
   AI の API キーを狙う探索はすでに来ています。設定ファイルを公開ディレクトリに置かず、WAF などで探索そのものも止めておきましょう。

まとめ：AIへの案内は「出してよいもの」だけ、鍵はしまっておく！

AI 向けには、llms.txt、ai-catalog.json（新しい名前は ard.json）、agent-card.json といった新しい入口が用意されつつあります。このブログのログでも、検査ツールが llms.txt と ai-catalog.json を確かめに来る一方で、別の送信元は AI の API キーを探して .env.openai を要求していました。案内は提供する機能があるときに、外に出してよいものだけを載せる。鍵は公開の場所に置かない。この 2 つを押さえて、AI エージェント時代の入口に備えましょう！

参考文献

• GoogleChrome「Lighthouse v13.5.0 release notes」（https://github.com/GoogleChrome/lighthouse/releases/tag/v13.5.0）2026-10-06 確認
• ards-project「Agentic Resource Discovery Specification v0.91」（https://github.com/ards-project/ard-spec/blob/main/spec/ard.md）2026-10-06 確認
• Hugging Face「Agentic Resource Discovery: Let agents search」（https://huggingface.co/blog/agentic-resource-discovery-launch）2026-10-06 確認
• Jeremy Howard「The /llms.txt file, v2」（https://llmstxt.org/）2026-10-06 確認
• a2aproject「A2A Protocol Specification」（https://github.com/a2aproject/A2A/blob/main/docs/specification.md）2026-10-06 確認
• Google 検索セントラル「AI features and your website」（https://developers.google.com/search/docs/appearance/ai-features）2026-10-06 確認
• OpenAI「Overview of OpenAI Crawlers」（https://developers.openai.com/api/docs/bots）2026-10-06 確認
• Anthropic「Does Anthropic crawl data from the web, and how can site owners block the crawler?」（https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler）2026-10-06 確認
• Google「Google’s common crawlers」（https://developers.google.com/crawling/docs/crawlers-fetchers/google-common-crawlers）2026-10-06 確認
• IETF「RFC 9309: Robots Exclusion Protocol」（https://www.rfc-editor.org/rfc/rfc9309.html）2026-10-06 確認
• Aditi Singh ほか「Evolution of AI Agent Registry Solutions: Centralized, Enterprise, and Distributed Approaches」（https://arxiv.org/abs/2508.03095）2026-10-06 確認
• Merlin Stein「How are AI agents used? Evidence from 177,000 MCP tools」（https://arxiv.org/abs/2603.23802）2026-10-06 確認
• Nurullah Demir ほか「Keys on Doormats: Exposed API Credentials on the Web」（https://arxiv.org/abs/2603.12498）2026-10-06 確認

The post 【AI×セキュリティ】AIエージェントはサイトをどう探しに来るか｜「ai-catalog.json や llms.txt は置くべき？」を解く first appeared on クエビコ.

一方で、こんな不安もあるのではないでしょうか。「AI に渡した権限で、消してはいけないデータを消されたらどうしよう」「つないだ先のサーバーは、ちゃんと鍵がかかっているの？」。人間の担当者なら「この作業には閲覧権限だけ渡す」と自然に考えますが、AI に対しては、つい全部の権限をまとめて渡してしまいがちです。

この記事では、AI とツールをつなぐ共通の仕組み「MCP」を例に、AI エージェントにどこまで権限を渡してよいかを考えます。悪意ある指示を紛れ込ませるプロンプトインジェクションの検知や、ツール説明文の罠については LLMエージェントのセキュリティの記事 で詳しく扱いました。今回はその手前の、「そもそも AI に何を許すか」という権限と認証の設計に絞ってお話しします！

MCP とは

MCP（Model Context Protocol）は、AI アプリケーションと外部のデータやツールをつなぐための公開された共通仕様です。仕様では、AI アプリそのものを「ホスト」、ホストの中で外部との接続を受け持つ部品を「クライアント」、ツールやデータを提供する側を「MCP サーバー」と呼びます。クライアントと MCP サーバーが決まった形式でやり取りすることで、いろいろなツールを同じ方法で AI につなげられます。MCP サーバーには、自分のパソコン上で動かす「ローカル」のものと、インターネット越しに使う「リモート」のものがあります。

MCP の仕様は、冒頭の「セキュリティと信頼」の節で、この仕組みが任意のデータへのアクセスやコードの実行につながる強力なものだと注意しています。そのうえで、利用者がすべてのデータアクセスと操作を理解して明示的に同意できること、共有するデータや実行される操作を利用者が管理し続けられることを原則に掲げています（MCP Specification）。

MCP の仕様は認証と権限について何を求めているか

2026年10月時点の最新版（2026-07-28 版）の仕様から、運営者が知っておきたい点を三つ挙げます。

一つ目は、仕様が定める認可の仕組み（誰に何を許すかを決める部分）は「任意（OPTIONAL）」だという点です。インターネット越しに使う HTTP ベースの MCP サーバーでこの仕組みを使う場合は、OAuth 2.1（ログイン情報を渡さずに、限られた権限だけを他のアプリに委ねる標準的な仕組み）をもとにした仕様に従うことが推奨されています。裏を返すと、仕様の認可方式を使っていない MCP サーバーもありえます。独自の方法で守っている場合もありますが、認証も認可もないまま公開されているものが含まれる可能性もある、ということです（MCP Specification「Authorization」）。

二つ目は、トークン（認可済みであることを示す一時的な鍵）の扱いです。MCP サーバーは、自分宛てに発行されたトークンだけを受け入れなければならず、別のサービス宛てのトークンを受け取ったり、そのまま先へ渡したりしてはいけない、と定められています。セキュリティのベストプラクティスの文書は、この「素通し」を禁止された危険な設計として挙げ、本来の制限や監査の記録をすり抜けられてしまうと説明しています（MCP「Security Best Practices」）。

三つ目は、権限の範囲（スコープ）を最小にする考え方です。同じ文書は、最初から何でもできる広いスコープを与えると、トークンが盗まれたときの被害が広がり、取り消しも難しくなると指摘しています。そして、最初は閲覧などの低リスクな操作だけを許し、強い操作が必要になった時点で段階的に権限を追加し、その記録を残す設計を勧めています。ローカルの MCP サーバーについても、ワンクリックで設定できる AI アプリには、実行されるコマンドを省略せずに表示し、利用者の明示的な承認を得ることを求めています。

また、仕様は冒頭の原則として、ホストはどのツールを呼び出す前にも利用者の明示的な同意を得ること、利用者は許可する前に各ツールが何をするかを理解できるようにすることを挙げています。ただし、これはプロトコル自体が強制できるものではなく、実装する側に同意と認可の仕組みを作り込むよう求める形です（MCP Specification）。

仕様は「正しく作ればこうなる」という基準を示しています。では、実際に動いている MCP サーバーはどうなっているのでしょうか。

📄 論文: リモート MCP サーバーの認証の実態

A First Measurement Study on Authentication Security in Real-World Remote MCP Servers（Huijun Zhou ほか、2026年5月、arXiv:2605.22333）は、査読前の論文（プレプリント）です。

研究チームは、インターネット上で実際に稼働しているリモート MCP サーバーを 7,973 台見つけ出し、認証の状況を調べました。その結果、調べた範囲の約 4 割（40.55%）が認証なしでツールを公開していました。これは研究が見つけたリモートのサーバーについての、調査時点の値です。また、認証には OAuth が主に使われていましたが、検証できた 119 台にはすべて何らかの欠陥があり、なかでも「動的クライアント登録」（AI アプリが事前登録なしにその場で自分を登録する仕組み）まわりの欠陥は 96.6% のサーバーに見つかりました。欠陥の多くは情報漏えいやアカウントの乗っ取りにつながりうるもので、研究チームは責任ある開示を通じて、CVE（公開された脆弱性の識別番号）も取得しています。

なお、2026-07-28 版の MCP 仕様では、動的クライアント登録は「非推奨で、後方互換のために残す」扱いになり、別の登録方式（クライアント ID メタデータ文書）を優先する位置づけになっています（MCP Specification「Authorization」）。

運営者にとっての意味は、つなぐ先の MCP サーバーに「鍵がかかっているか」を自分で確かめる必要があるということです。そして、鍵があっても実装の質はさまざまなので、提供元が更新を続け、最新の仕様に追随しているかも判断材料になります。

📄 論文: 別の調査でも見えた「認証なし」の公開サーバー（補足）

Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale（Nicolás Padilla、2026年7月、arXiv:2608.00150）は、単著の査読前の論文（プレプリント）です。他の研究者による検証を経ていない段階の報告なので、傾向を補う参考として紹介します。

この研究は、公開されている MCP サーバーのうち 414 台に実際にリクエストを送って動作を確かめ、SQL インジェクションや SSRF（サーバーを踏み台にした不正なリクエスト）といった従来型の脆弱性を 68 件報告しています。また、調べたサーバーの 91.8% が OAuth による認証を備えていなかったとしています。

運営者にとっての意味は、MCP サーバーは「AI 用の新しい窓口」であっても、中身は普通のウェブの仕組みだということです。公開するなら、従来どおりの脆弱性診断の対象に含める必要があります。

📄 論文: AI エージェントが「強いほうの道具」を選ぶ傾向

When Lower Privileges Suffice: Investigating Over-Privileged Tool Selection in LLM Agents（Kaiyue Yang ほか、2026年6月、arXiv:2606.20023）は、査読前の論文（プレプリント）です。

研究チームは、同じ目的を果たせる権限の低いツールと高いツールを並べて AI エージェントに渡し、どちらを選ぶかを測る評価用の課題集を作りました。8 つの分野・5 つの典型的なリスクの型で、最初の選択と、ツールが一時的にエラーを返したあとに権限を上げるかどうかを調べています。

この研究の評価では、権限の低いツールで十分な場面でも、主要な AI エージェントが高い権限のツールを選ぶことはよくありました。さらに、一時的なエラーが起きると、より強いツールへ切り替える傾向が強まりました。AI に施されている一般的な安全対策は「必要最小限の権限を選ぶ」ことには必ずしも効かず、プロンプトで「権限の低いツールを使って」と指示する方法も、エラーが起きた場面では効果が限られていました。研究チームは、AI 自体を追加で訓練して改善する方法も提案しています。

運営者にとっての意味は、「AI が自制してくれる」ことを前提にできない、という点です。強いツールを渡せば、AI はそれを使う可能性がある。だから、渡すツールと権限そのものを設計で絞る必要があります。

運営者のやること

ここからは、研究と公的な資料を合わせて、AI エージェントにツールをつなぐときの手順を整理します。OWASP の「LLM アプリケーションの 10 大リスク」は、AI に任せすぎることで被害が起きるリスクを「過剰なエージェンシー（LLM06:2025 Excessive Agency）」と呼び、その原因を「機能の過剰」「権限の過剰」「自律性の過剰」の三つに分けています（OWASP「LLM06:2025 Excessive Agency」）。この三つに沿って考えると整理しやすくなります。

機能を絞る：必要なツールだけつなぐ

• 業務に必要なツールだけをつなぎ、試しに入れて使わなくなったものは外す。OWASP も、開発中に試して採用しなかった拡張機能が残っている例を挙げています
• 「メールを要約する」用途なら、読むだけのツールを選ぶ。送信や削除までできるツールは渡さない
• コマンドを何でも実行できるような汎用ツールは避け、目的を限った個別のツールを使う

権限を絞る：読むだけで済むなら読むだけ

• AI が使うアカウントやトークンには、業務に必要な最小限の権限だけを与える。閲覧で足りるなら書き込み権限は付けない
• 全員分のデータにアクセスできる管理者アカウントを共用せず、操作する利用者本人の権限の範囲で動かす。OWASP もこの点を対策に挙げています
• 許可するかどうかの判断を AI に任せず、つなぐ先のシステム側でアクセス制御をかける

自律性を絞る：重要な操作は人が承認する

• ツールを使う前に利用者の同意を得て、何をするツールか分かるようにする。MCP の仕様もこれを原則に挙げています
• 特に削除・送信・支払い・公開など、取り返しのつかない操作は、実行内容を示したうえで、その都度人が確認して承認する仕組みにする
• 新しいローカルの MCP サーバーを追加するときは、表示される実行内容を確認してから承認する。中身の分からないものは入れない

つなぐ前に相手を確かめ、つないだ後は記録を見る

• 外部の MCP サーバーを使う前に、認証があるか、提供元はどこか、更新が続いているかを確認する
• 自社で MCP サーバーを公開する場合は、認証（相手が誰かの確認）と認可（何を許すかの制御）を設け、操作ごとにサーバー側で権限を確認する。通常のウェブサービスと同じく脆弱性診断の対象にもする
• AI がどのツールをいつ使ったかの記録を残し、定期的に見直す。OWASP は、記録の監視や回数制限は被害を防ぐものではないが、被害を小さくするのに役立つとしています

プロンプトインジェクション対策との関係

AI エージェントの安全を考えると、悪意ある指示を紛れ込ませて AI を操るプロンプトインジェクションの話が必ず出てきます。その検知の方法と限界、設計での閉じ込め方は LLMエージェントのセキュリティの記事 で解説しました。

この記事で扱った権限の設計は、それと補い合う関係にあります。注入を完全に見抜くのは難しいからこそ、「仮に AI が操られても、できることが限られている」状態を作っておく。最小権限と人の承認は、注入が成功してしまったときの最後の歯止めになります。

AIエージェントに権限を渡す鍵は次の3点です

1. つなぐ先の認証を自分で確かめる
   ある調査では、見つかったリモート MCP サーバーの約 4 割が認証なしでした。使う前に認証の有無と提供元、更新の状況を確認しましょう。
2. 権限は AI の判断ではなく設計で絞る
   研究の評価では、低い権限で足りる場面でも高い権限のツールが選ばれることがよくありました。渡すツールと権限そのものを、業務に必要な最小限にしましょう。
3. 取り返しのつかない操作は人が承認する
   削除・送信・支払いなどは実行前に人が確認し、AI の操作の記録を残して見直しましょう。

まとめ：AIエージェントには「必要な分だけ」任せよう！

AI エージェントとツールの連携は、正しく設計すれば頼もしい存在です。ただし、研究からは、調査対象の MCP サーバーの一部が認証なしで公開され、認証のあるサーバーにも実装の欠陥が見つかったこと、そして評価では AI エージェントが必要以上に高い権限のツールを選ぶ傾向があったことが見えてきました。

人の担当者に仕事を頼むときと同じように、「この仕事にはこの権限だけ」と範囲を決めて渡す。それが、便利さと安全を両立させる一番の近道です。まずは、いま AI につないでいるツールを一覧にして、使っていないもの・権限が強すぎるものがないか見直してみましょう！

参考文献

• Model Context Protocol「Specification（Version 2026-07-28）」（https://modelcontextprotocol.io/specification/2026-07-28）2026-10-01 確認
• Model Context Protocol「Authorization（Version 2026-07-28）」（https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization）2026-10-01 確認
• Model Context Protocol「Security Best Practices（Version 2026-07-28）」（https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices）2026-10-01 確認
• OWASP Gen AI Security Project「LLM06:2025 Excessive Agency」（https://genai.owasp.org/llmrisk/llm062025-excessive-agency/）2026-10-01 確認
• Huijun Zhou ほか「A First Measurement Study on Authentication Security in Real-World Remote MCP Servers」arXiv:2605.22333（https://arxiv.org/abs/2605.22333）2026-10-01 確認
• Nicolás Padilla「Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale」arXiv:2608.00150（https://arxiv.org/abs/2608.00150）2026-10-01 確認
• Kaiyue Yang ほか「When Lower Privileges Suffice: Investigating Over-Privileged Tool Selection in LLM Agents」arXiv:2606.20023（https://arxiv.org/abs/2606.20023）2026-10-01 確認

The post 【AI×セキュリティ】AIエージェントとMCPの権限設計｜「つないだツールに、どこまで任せてよいか」を解く first appeared on クエビコ.

もうひとつの心配は、作業の途中でエージェントの行動が変わってしまうことです。読み込んだWebページやメールに紛れ込んだ指示に引きずられ、頼んでいない送信や削除をしていたとしても、長い作業の記録から「どこで、何が起きたのか」を後から突き止めるのは簡単ではありません。いざというときに、その記録自体が正しいと言い切れるかどうかも気になるところです。

当ブログ独自の arXiv 急上昇ワード集計では、「tool call（ツール呼び出し）」がセキュリティ分野（cs.CR）で伸びています。論文全体に占める割合は2026年1〜6月の0.9%から7〜9月は2.2%になり、平滑化した伸びは2.2倍です。ソフトウェア工学の分野でも同じく2.2倍でした。この記事では、個人情報保護委員会や OWASP などの資料で考え方を整理したうえで、論文4本から「承認した操作が裏で広がっていないか」を確かめる方法を読み解きます。結論を先に言うと、送る前にデータを削り、送った後は記録を読み返して変化点を探し、その記録を改ざんに気づける形で残すのが基本です！

ツール呼び出しで「裏で広がる」もの

ツール呼び出しとは、エージェントが外部のサービスや社内のシステムを使うときに、宛先の機能と、そこに渡す値（引数）をまとめて送る仕組みです。どのツールを使わせるか、どの権限を持たせるかの設計は、近日公開予定の記事「AIエージェントとMCPの権限設計」で扱います。この記事では、権限の範囲内で許可した操作であっても、次の3つが知らないうちに広がりうる点に注目します。

• 渡すデータ: 操作に必要な分を超えて、個人情報などが外部のサービスに送られる
• 行動: 途中で読んだデータに紛れ込んだ指示により、依頼と違う操作に切り替わる
• 記録: 後から確かめるための記録が欠けたり、書き換えられたりする

公的な資料が求めていること

個人情報保護委員会は2023年6月の注意喚起で、事業者が生成AIサービスに個人情報を含む指示を入力する場合は、利用目的の達成に必要な範囲内であることを十分に確認するよう求めています（個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」）。この注意喚起は生成AIサービスへの入力を対象にしたものですが、エージェントが自動で組み立てるツール呼び出しにも同じ考え方を当てはめる、というのがこの記事の立場です。

OWASP の「Top 10 for LLM Applications 2025」は、エージェントに過大な機能や権限を与えるリスクを「過剰な自律性（Excessive Agency）」としてまとめ、防ぐ策として拡張機能とその権限を必要最小限に絞ることを挙げています。あわせて、それ自体では防げないものの被害を抑える策として、拡張機能と連携先のシステムの動きを記録・監視し、望ましくない操作が起きている場所を突き止めることも挙げています（OWASP「LLM06:2025 Excessive Agency」）。

経済産業省と総務省の「AI事業者ガイドライン（第1.2版）」も、検証可能性を確保するため、データの量や内容に照らして合理的な範囲で、開発過程、利用時の入出力、推論過程、判断根拠などのログを記録・保存し、事故の原因究明や再発防止に照らして記録の方法・頻度・保存期間を検討するよう求めています（経済産業省・総務省「AI事業者ガイドライン（第1.2版）」）。

渡すデータの広がりを、送る前に削る

📄 論文: ツールに渡す個人情報を「必要な分だけ」に書き換える

ToolMinimize: Auditing and Rewriting LLM Agent Tool Calls to Minimize Privacy Exposure（Wenbiao Li ほか、2026年8月、arXiv:2608.24957）は、査読前の論文（プレプリント）です。

著者らはまず、天気の確認や予定の登録といった日常的な20の作業を GPT-4o、Claude 3.5 Sonnet、Llama-3.3-70B に実行させ、ツールに渡された値を調べました。この実験では、通常の設定でツール呼び出しの81〜88%に、そのツールには不要な個人情報が含まれていました。「個人情報は必要な分だけ渡すように」と明示的に指示しても、36〜76%は過剰なままで、指示がほとんど効かないモデルもありました。たとえば天気を調べるのに番地までの住所を送ってしまう、病院名のように病気を推測させる情報を添えてしまう、といった形です。

そこで論文は、エージェントとツールの間に入って呼び出しを止め、各ツールの入力項目の定義をもとに「この項目は本当に必要か」を判断し、不要な項目を消す、住所を市の単位に丸める、といった書き換えをしてから送る仕組みを提案しています。可否の判断で止めてしまうのではなく、作業を続けられる形に直して送るのが特徴です。著者らが作った90の模擬シナリオ、外部の50シナリオ、実在する25の MCP サーバーの入力定義をそれぞれ評価し、送られる個人情報を大きく減らせたと報告しています。ただし論文の「作業を損なわない」という評価は、送る値の形式が正しく必要な項目が残っているかを見たもので、作業を最後までやり遂げられたかは別に確かめています。

効果は、個人情報をどれだけ見逃さずに見つけられるかに左右されます。著者ら自身、見つけられなかった情報は書き換えられずにそのまま送られること、模擬の宛先で実際に動かした確認では、地図の作業で必要な住所まで削ってしまい、元と同じ結果にならない例があったことを限界として挙げています。運営者にとっての意味は、「指示で気をつけさせる」だけでは足りず、送る直前に機械的に削る層が有効だということです。

行動の広がりを、記録から後で突き止める

📄 論文: 乗っ取られた作業記録に「一手ずつ」印をつけたデータ集

AgentDrift: A Step-Labeled Benchmark of Injection-Hijacked LLM Agent Trajectories（Asif Pinjari ほか、2026年9月、arXiv:2609.06972）は、査読前の論文（プレプリント）です。

エージェントが読んだデータに指示が紛れ込み（間接プロンプトインジェクション）、乗っ取られたときの作業記録は、正常な手順がしばらく続いたあと、攻撃者のための操作に切り替わる形になります。著者らは、メール、銀行、Web、コーディング、医療の5分野で、1つのモデルを使って合成した12,536件の作業記録を作り、すべての手順に「正常」「指示が入り込んだ地点」「乗っ取られた操作」「入り込んだが従わなかった」のいずれかの印をつけました。攻撃に見えるが正当な内容を含む紛らわしい記録も入れてあります。

表面的な特徴だけで判定する単純な分類器を試すと、見つけられた攻撃は55.4%にとどまり、途中から一部だけ乗っ取られた型に限ると8.2%しか見つけられませんでした。記録全体の雰囲気ではなく、手順の並びを追わないと分からない攻撃が多いということです。

📄 論文: どこから入り込み、どこまで汚れたかを一度に示す

DriftNet: A Dual-Head Trajectory Transformer for Detecting and Localizing Prompt Injection in LLM Agents（Asif Pinjari ほか、2026年9月、arXiv:2609.10892）は、査読前の論文（プレプリント）で、同じ著者らによる上のデータ集の続編です。

保存されたツール呼び出しの記録だけを読み、「この作業は乗っ取られたか」と「どの手順で入り込み、どの手順が汚れたか」を同時に答える小さなモデルを作りました。エージェント本体のモデルの中身にも、実行のやり直しにも頼らない、記録だけを使う方式です。

AgentDrift のデータで評価したところ、攻撃が成功した記録の98.7%で入り込んだ地点を正確に言い当て、指示が入り込んだが従わなかった218件はひとつも誤って警告しませんでした。ただし、学習も評価も1つのモデルで合成した記録で行っており、実際のエージェントの記録で同じ精度が出るかは確かめていないと、著者ら自身が明記しています。データ集の側でも、同じ架空の環境から作られた記録は同じ分類に偏るという性質が測られており、その影響を除いた評価は今後の課題とされています。

2本から言えるのは、「乗っ取られたかどうか」だけでなく、「どこから変わったか」と「攻撃が来たが防げたか」を分けて記録を読むことが、調査と再発防止の役に立つということです。プロンプトインジェクションそのものの仕組みと対策は、LLMエージェントのセキュリティの記事で解説しています。

記録そのものを守る

📄 論文: エージェントの作業に「フライトレコーダー」をつける

A Black Box for Agentic Processes: Blockchain-Anchored Evidence for AI Agent Communication, Human Oversight, and GRC Audits（Arslan Brömme、2026年9月、arXiv:2609.04017）は、単著の査読前の論文（プレプリント）です。設計の考え方を示す立場表明の論文で、性能や安全性を実験で確かめたものではありません。

エージェント同士のやり取り、人による承認、ツール呼び出しの引数と結果といった記録から、内容を表す短い指紋（ハッシュ値）を作り、改ざんしにくい外部の台帳に時刻とともに固定しておく設計です。記録の中身は社内に置いたままにし、外に出すのは指紋だけにします。後から記録の指紋を計算し直して照らし合わせれば、固定した時点から書き換えられていないかを確かめられます（記録の取り漏れや出来事の順番までは、これだけでは分かりません）。たとえば「人の承認は、実行より前に得られていたか」「実行された引数は、承認された内容と一致するか」を検証できるようになります。

一方で著者は、この仕組みが証明できるのは「その時点からこの記録が変わっていないこと」までで、記録の内容が正しいことや、記録を取る段階で漏れやすり替えがなかったことは証明できないと強調しています。出来事の順番を確かめるには別の仕組みが必要で、すべてを固定するのではなく、外部への送信や権限の変更、承認といった影響の大きい出来事を優先して選ぶよう勧めています。

現場でやること

ツールごとに「本当に必要な項目」を決め、送る前に削る

つないでいるツールの入力項目を一覧にし、それぞれ「必ず要る」「あれば便利」「不要」を決めます。住所や日時の細かさなど、丸めてよい項目も決めておきます。そのうえで、エージェントの指示に頼らず、呼び出しの直前に不要な項目を削る処理を挟みます。

呼び出しの記録は「読み返せる形」で残す

ツールの名前だけでなく、渡した引数、読み込んだデータ、返ってきた結果、人が承認した内容を、作業ごとに順番どおり残します。ただし記録自体が個人情報の置き場所になるので、保存先の権限と保存期間を決めておきます。

読み返すときは「どこから変わったか」を探す

定期的な見直しや問題が起きたときは、承認した内容と実際に実行された引数を突き合わせ、依頼と関係のない宛先への送信や削除が、どの手順の後から始まったかを探します。直前に読み込んだデータが入り口の候補です。自動で判定する仕組みは研究段階なので、人が読む前提で記録を整えておきます。

大事な記録は、改ざんに気づける形で残す

承認、外部への送信、権限の変更といった影響の大きい記録は、エージェントが書き換えられない別の保存先にも送り、ハッシュ値を残しておきます。ブロックチェーンを使わなくても、追記しかできない保存先を分けるだけで、後から書き換えに気づきやすくなります。

ツール呼び出しを監査する鍵は次の3点です

1. 送るデータは、指示でなく仕組みで減らす
   ツールごとに必要な項目を決め、呼び出しの直前に不要な個人情報を削ったり丸めたりします。
2. 記録は「どこから変わったか」を追える形で残す
   引数・読んだデータ・結果・承認を順番どおりに残し、承認した内容と実行された内容を突き合わせます。
3. 大事な記録ほど、改ざんに気づける場所に置く
   影響の大きい出来事を選び、エージェントが書き換えられない保存先とハッシュ値で守ります。

まとめ：「承認した」で終わらせず、送る前と送った後を確かめよう！

ツール呼び出しの承認は、操作の名前に対して行われがちです。9月の論文からは、その裏で不要な個人情報が送られていることが珍しくないこと、乗っ取りは記録の手順を順に追わないと見落としやすいこと、そして記録そのものも守る対象であることが見えてきました。

権限を絞って「できること」を決めたら、次は「実際に何が送られ、何が起きたか」を確かめる番です。送る前にデータを削り、送った後は記録を読み返し、その記録を改ざんに気づける形で残す。この3つを押さえれば、「承認したはずの操作が裏で広がっていないか」に、記録をもとに答えられるようになるはずです！

参考文献

• Wenbiao Li ほか「ToolMinimize: Auditing and Rewriting LLM Agent Tool Calls to Minimize Privacy Exposure」arXiv:2608.24957（https://arxiv.org/abs/2608.24957）2026-10-02 確認
• Asif Pinjari ほか「AgentDrift: A Step-Labeled Benchmark of Injection-Hijacked LLM Agent Trajectories」arXiv:2609.06972（https://arxiv.org/abs/2609.06972）2026-10-02 確認
• Asif Pinjari ほか「DriftNet: A Dual-Head Trajectory Transformer for Detecting and Localizing Prompt Injection in LLM Agents」arXiv:2609.10892（https://arxiv.org/abs/2609.10892）2026-10-02 確認
• Arslan Brömme「A Black Box for Agentic Processes: Blockchain-Anchored Evidence for AI Agent Communication, Human Oversight, and GRC Audits」arXiv:2609.04017（https://arxiv.org/abs/2609.04017）2026-10-02 確認
• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（https://www.ppc.go.jp/files/pdf/230602_alert_generative_AI_service.pdf）2026-10-02 確認
• OWASP「LLM06:2025 Excessive Agency」（https://genai.owasp.org/llmrisk/llm062025-excessive-agency/）2026-10-02 確認
• 経済産業省・総務省「AI事業者ガイドライン（第1.2版）」（https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html）2026-10-02 確認

The post 【2026年9月 急上昇ワード】エージェントのツール呼び出しの監査×論文4選｜「承認したはずの操作が裏で広がっていないか」を解く first appeared on クエビコ.

しかも、重みが手元にあるモデルは、攻撃者も同じように手元で改変できます。「中身が見えるから安心」なのか、「中身をいじられるから危ない」のか。両方の声を聞いて、判断に迷っている方も多いのではないでしょうか。

当ブログ独自の arXiv 急上昇ワード集計では、「open-weight model（オープンウェイトモデル）」がセキュリティ分野（cs.CR）で急に伸びました。論文全体に占める割合は2026年1〜6月の0.4%から7〜9月は1.4%になり、平滑化した伸びは2.5倍です。ソフトウェア工学と自然言語処理の分野でも同時に伸びています。この記事では、米国商務省の電気通信情報局（NTIA）などの公的資料で前提を整理したうえで、9月に出た論文4本から「どこに差が出て、何で埋めるか」を読み解きます。結論を先に言うと、差は「オープンウェイトかどうか」よりもモデルの規模や世代で大きく変わるので、自分の用途で測り、足りない分はモデルの外側の仕組みで補うのが基本です！

オープンウェイトモデルとは：「重みが手元にある」ことの意味

「オープンソース」と「オープンウェイト」は同じではない

AIモデルの振る舞いは、学習で決まった膨大な数値（重み、パラメータ）で決まります。この重みを誰でもダウンロードできる形で公開したモデルを、一般に「オープンウェイトモデル」と呼びます。

現場では「OSSモデル」とひとまとめに呼ばれがちですが、オープンソース・イニシアティブ（OSI）の「オープンソースAIの定義 1.0」は、重みなどのパラメータに加えて、学習と実行に使ったコードの全体と、同等のシステムを作り直せるだけの学習データの詳しい情報まで公開されていることを求めています（Open Source Initiative「The Open Source AI Definition 1.0」）。重みだけが公開されていても、この定義でいう「オープンソースAI」にはあたりません。この記事では、重みが手に入るかどうかに注目して「オープンウェイト」と呼びます。

重みを公開すると何が変わるか

NTIA は2024年7月の報告書で、重みが広く公開されると次の3つが起きると整理しています（NTIA「Dual-Use Foundation Models with Widely Available Model Weights」）。

• 開発者の想定を超えて、誰でも追加学習などで手を加えられる。悪意のある人は追加学習で安全のための仕組みを外し、それを自由に配布できる
• 開発者は利用者の行動を見ることも、配布した重みを取り消すこともできなくなる
• 自分の計算機で動かせるので、開発者にデータを渡さずに使える。その一方で、利用や悪用を見張る力は API で提供されるモデルより弱くなる

自社運用を考える組織にとっては、3つ目が「データを外に出さずに済む」という最大の利点です。同時に、商用 API なら提供元も担っていた見張りの役割を、自分たちで引き受けることになる、とも読めます。

自前で運用する側の心構え

米国国立標準技術研究所（NIST）の生成AI向けのリスク管理の手引きは、外部から取り入れる生成AIについて、オープンソースでも商用でも、調達時の確認や構成部品の一覧（SBOM）の要求など、既存のリスク管理の手順を当てはめられると書いています（NIST「AI 600-1: Generative Artificial Intelligence Profile」）。オープンウェイトだから特別な魔法が必要なわけではなく、「どこから入手し、どう確かめ、どう見張るか」を普段のソフトウェアと同じ目線で決めることが出発点になります。

研究で見る「安全性の差」はどこに出るか

📄 論文: 危ない依頼を「そのまま実行してしまう」割合

AURA-Eval: Evaluation Framework for Acting Under Risk Awareness in LLM Agent Trajectories（Ruoxi Shang ほか、2026年9月、arXiv:2609.06783）は、査読前の論文（プレプリント）です。

既存の安全性ベンチマークから集めた157件のエージェントの作業記録をもとに、条件を少しずつ変えた1,249問を作り、20のモデルに「次に何をするか」を答えさせています。実際の環境で動かしたのではなく、途中までの作業記録を同じ条件で見せて、次の一手を比べる方式です。判定は複数のLLMによる採点を人が抜き取りで確かめています。

問題には、安全なやり方で依頼をかなえられる場面と、そのまま実行すると危険でしかない場面の両方があります。危険な行動を取った割合は、Claude Opus 4.6 や GPT-5.4 などのフロンティアモデルが16.9〜23.6%だったのに対し、フロンティア級に分類された1モデルを除くオープンウェイトモデル（Llama、Qwen、Gemma など、いずれも700億パラメータ以下）は36.5〜52.0%でした。差が大きいのは「安全な道がない」場面で、フロンティアモデルは代わりの方法を提案することが多く、オープンウェイトモデルはリスクに気づかないまま実行する傾向が目立ちました。

ただし、フロンティア級でありながら重みも公開されている GLM-5.1 は19.4%で、フロンティアモデルの群と同じ水準でした。また、実行前に人が確認する機会を減らしたり、影響の及ぶ範囲を広げたりした問題では、モデル全体として危険な行動が増えました。運営者にとっては、「オープンウェイトだから危ない」ではなく、選んだモデルの規模と世代、そして人の確認を挟めるかどうかで安全性が大きく動く、という結果として受け取るのがよさそうです。

📄 論文: セキュリティの分析に使ったときの実力差

SCRIPTIOC-BENCH: A Benchmark for Recognizing Actionable Threat Intelligence from Script-Based Malware using LLMs（Hanna Kim ほか、2026年9月、arXiv:2609.06149）は、査読前の論文（プレプリント）です。

人の手で確認した実在の悪性スクリプト634件（Webページや Windows の自動処理で使われる3種類の言語で書かれたもの）を使い、スクリプトを実行せずに読むだけで、接続先のURLやドメイン、IPアドレス、作成されるファイルといった「侵害の痕跡（IOC）」をどこまで正しく取り出せるかを測っています。80億から4,800億パラメータのオープンウェイトモデルと、商用の上位モデルを同じ手順で比べました。

最も成績のよい商用モデルでも、正確さと網羅性をまとめた指標（F1）は65.4止まりで、オープンウェイトの最上位は49.8でした。値が難読化されていて組み立て直す必要がある痕跡ほど、取りこぼしが増えます。一方で、80億パラメータの小さなモデルに文字列処理の道具を使わせることと、この作業向けの追加学習を組み合わせると、出した答えのうち正しいものの割合（適合率）が31%から48%に上がりました。

自前で動かす小さなモデルを分析の補助に使う場合、そのままでは商用の上位モデルと差がある一方、道具と追加学習で差を縮められるということです。いずれにしても、結果は人が確かめる前提で使うべき水準です。

研究で見る「重みが手元にある」ことの表と裏

📄 論文: 安全機能を外す改変を、重みの側で邪魔する

Bait-and-Recover: Poisoning Internal Refusal Signals to Defend LLMs against White-Box Editing Jailbreaks（Tian Gao ほか、2026年9月、arXiv:2609.05794）は、査読前の論文（プレプリント）です。

重みが手元にあると、攻撃者はモデルの内部の計算を観察し、「断る」働きに関わる部分を探して重みを直接書き換えることができます。著者らによれば、この種の改変は追加学習よりはるかに安く、1台のGPUで数分で済み、普段の受け答えはほとんど変わりません。論文は、攻撃者が観察する場所にわざと紛らわしい信号を仕込み、すぐ後ろでその影響を打ち消すことで、正しい改変箇所を見つけにくくする防御を提案しています。

Qwen3 と Gemma 3 の4つのモデル（10億〜120億パラメータ）で試したところ、普段の振る舞いをほとんど変えない範囲に改変を限った条件で、最も効いた改変に対しても危ない依頼を断れた割合（4モデルの平均）は16.25%から71.75%に上がり、一般的な性能評価への影響はわずかでした。ただし著者ら自身が、有害なデータを集めて追加学習する攻撃は防げないこと、改変の自由度を広げると突破されることを限界として挙げています。

運営者にとっての意味は、一度配布された重みは、安全機能を外した版が作られうる前提で扱うことです。入手元がはっきりしない「改良版」の重みを使わない理由が、ここにあります。

📄 論文: 内部の状態を見て、攻撃を受けたことに気づく

MechAudit-40: White-Box Auditing across 40 LLM Attack Mechanisms（Zhen Guo ほか、2026年9月、arXiv:2609.06612）は、査読前の論文（プレプリント）です。

重みが手元にあることは、防御側にとっても利点になります。この論文は、30億〜200億パラメータの5つのオープンウェイトモデルに、8分類・40種類の攻撃を総当たりで試し、そのときのモデル内部の状態を記録して、攻撃を受けたときに共通して表れる変化があるかを調べました。

この変化を手がかりに、モデルごとに正常時の状態で基準を合わせた監視の仕組みは、学習に使っていない種類の攻撃でも81.1%を、誤検知0.70%の設定で見つけました。一方で、内部の状態からは「攻撃が成功したかどうか」はほぼ見分けられませんでした。著者らは、警告を「攻撃にさらされた証拠」として扱い、「侵害された」という判定とはみなさないよう求めています。

内部の状態を読む監視は、重みを自分で動かしているからこそ可能な手段です。ただし研究段階の仕組みで、運用にそのまま入れられる製品ではありません。警告を、ログの確認や処理の一時停止につなげる網のひとつとして位置づけるのが現実的です。

現場でやること

自分の用途で、候補モデルを並べて測る

一般的なベンチマークの順位だけで選ばず、自社で実際に任せる作業を数十件ほど用意し、候補のオープンウェイトモデルと商用モデルを同じ条件で比べます。AURA-Eval の結果からは、「安全なやり方がある依頼」と「断るべき依頼」の両方を混ぜて試すことが大切だと分かります。前者だけで比べると、差が見えにくくなります。

足りない安全性は、モデルの外側で補う

モデルが危ない依頼を見抜けなくても被害が出ないように、使えるツールや権限を絞り、取り消せない操作の前には人の承認を挟みます。AURA-Eval でも、承認の機会を減らすと危険な行動が増えました。エージェントに渡す権限の設計は、近日公開予定の記事「AIエージェントとMCPの権限設計」で詳しく扱います。プロンプトインジェクションへの備えは、LLMエージェントのセキュリティの記事も参考にしてください。

重みの入手元と中身を管理する

重みは開発元の公式な配布先から入手し、配布元が確認用のハッシュ値を示している場合は照らし合わせてから保存します。第三者が手を加えた版は、安全機能が外されていても見た目では分かりません。使う版とライセンス、入手日を記録し、ソフトウェアの部品と同じように一覧で管理しておくと、問題が見つかったときに差し替えやすくなります。

見張る役割を自分で引き受ける

API なら提供元も担っていた利用状況の監視は、自前運用では自分たちの仕事になります。入力と出力、ツールの呼び出しを記録し、定期的に見直す仕組みを最初から用意しておきましょう。内部の状態を使った監視は、将来の選択肢として知っておく程度で十分です。

オープンウェイトモデルを安全に使う鍵は次の3点です

1. 「オープンウェイトだから危ない」ではなく、規模と世代で測る
   差はモデルの規模や世代で大きく変わります。自分の用途と、断るべき依頼を混ぜた問題で、商用モデルと並べて確かめます。
2. 足りない分は、モデルの外側の権限と承認で補う
   モデルが見抜けなくても被害が出ないように、ツールと権限を絞り、重要な操作の前に人の確認を挟みます。
3. 重みは「改変されうる部品」として管理し、見張りは自分で担う
   公式の配布元から入手して版を記録し、利用の記録と見直しの仕組みを最初から組み込みます。

まとめ：オープンウェイトは「差を測って、外側で埋める」前提で使おう！

オープンウェイトモデルには、データを外に出さずに使えるという大きな利点があります。一方で、9月の論文からは、評価した中小規模のオープンウェイトモデルが、危ない依頼をそのまま実行しやすく、セキュリティの分析でも商用の上位モデルに届かない場面があることが見えてきました。ただしその差は、フロンティア級のオープンウェイトモデルでは小さく、道具や追加学習でも縮められます。

重みが手元にあることは、攻撃者が安全機能を外せるという弱みであり、防御側が中を見て監視できるという強みでもあります。自分の用途で差を測り、権限と承認で外側を固め、重みと利用状況を自分で管理する。この3つを押さえれば、「乗り換えたら安全性はどこまで落ちるのか」という不安に、根拠を持って答えられるはずです！

参考文献

• Ruoxi Shang ほか「AURA-Eval: Evaluation Framework for Acting Under Risk Awareness in LLM Agent Trajectories」arXiv:2609.06783（https://arxiv.org/abs/2609.06783）2026-10-02 確認
• Hanna Kim ほか「SCRIPTIOC-BENCH: A Benchmark for Recognizing Actionable Threat Intelligence from Script-Based Malware using LLMs」arXiv:2609.06149（https://arxiv.org/abs/2609.06149）2026-10-02 確認
• Tian Gao ほか「Bait-and-Recover: Poisoning Internal Refusal Signals to Defend LLMs against White-Box Editing Jailbreaks」arXiv:2609.05794（https://arxiv.org/abs/2609.05794）2026-10-02 確認
• Zhen Guo ほか「MechAudit-40: White-Box Auditing across 40 LLM Attack Mechanisms」arXiv:2609.06612（https://arxiv.org/abs/2609.06612）2026-10-02 確認
• 米国商務省 電気通信情報局（NTIA）「Dual-Use Foundation Models with Widely Available Model Weights」（https://www.ntia.gov/sites/default/files/publications/ntia-ai-open-model-report.pdf）2026-10-02 確認
• Open Source Initiative「The Open Source AI Definition 1.0」（https://opensource.org/ai/open-source-ai-definition）2026-10-02 確認
• 米国国立標準技術研究所（NIST）「AI 600-1: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」（https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf）2026-10-02 確認

The post 【2026年9月 急上昇ワード】オープンウェイトモデルの安全性ギャップ×論文4選｜「OSSモデルに乗り換えたら安全性はどこまで落ちるのか」を解く first appeared on クエビコ.

今週の対象は 704 本（主分野で数えて cs.CL 409 本・cs.CR 184 本・cs.SE 111 本）でした。

🔁 急上昇テーマの続報：コーディングエージェント（今週 22 本）

月次の急上昇ランキングでは、コーディングエージェントは直近 3 か月で cs.SE 1.9 倍・cs.CR 2.6 倍・cs.CL 2.1 倍と、3 分野そろって伸びているテーマです。今週は、実際にどれだけ信頼できてどれだけコストがかかるかを数字で示した論文が目立ちました。実務に効きそうな 3 本を紹介します。

AIだけで書かれた2万行のコードベースは、どれだけ間違っているか

Between the Commits: Process, Error, and Claim Reliability in a Wholly AI-Authored Codebase（arXiv:2609.29744）

人間のコードやテストを一切含まない、Claude だけで書かれた 2 万 1000 行の Python ツールの開発履歴を分析した研究です。

• AIによるコード生成イベントのうち 14.3% は、AI 自身が書いたテストスイートに後から捕まる本物のエラーを含んでいた
• AI の対話的な応答のうち 4〜5 件に 1 件は、何らかの事実誤認を含んでいた（設計の修正案を除いて数えた値。含めると約 3 割）

マージ後もエージェントは「自分の尻拭い」をしている

Who Finishes the Job? A Study of Follow-Up Fixes and Commit Authorship on AI Coding Agent Pull Requests（arXiv:2609.26847）

OpenAI Codex・GitHub Copilot・Devin・Cursor・Claude Code の 5 つのコーディングエージェントによるマージ済み PR 6,774 件を追跡し、同じリポジトリの人間の PR 5,044 件と比較した研究です。

• マージされたエージェントの PR は、同じ期間・同じリポジトリの人間の PR に比べて、あとから検証済みの修正を受けるオッズが 1.62 倍だった
• エージェントの PR が受けた検証済みの修正のうち 69.6% は同じエージェント自身が行っており、エージェントが作った修正 PR（Codex を除く）の 76.4% はコミットのすべてがエージェント作成だった

コストがかさむのは「同じ調べ物・同じスクリプト・同じテスト」の繰り返し

Analyzing and Mitigating Cost-Inefficient Behaviors in Coding Agents（arXiv:2609.30725）

Claude Code と Mini-SWE-Agent による SWE-bench Verified 上の 1,200 トラジェクトリを分析した研究です。

• 「同じ情報を何度も探し直す」「似たスクリプトを何度も書く」「テストを何度も再実行する」という 3 つの非効率な振る舞いが、タスクの 79.00%〜98.00% で見られ、タスクコストの最大 22.75% を占めていた
• 開発者が設計したスキルを与えるとコストを最大 41.73% 削減でき、これはエージェント自身が生成したスキルの最大の削減幅（22.32%）のおよそ 2 倍だった

🆕 今週の新語

過去 13 か月の論文には一度も出てこず、今週は複数の論文タイトルに現れた語です。

acoustic grounding（音響グラウンディング）— 2 本

• 音声認識モデルは、音声が入っていない・弱い・不明瞭な入力に対して、実際には支持されないテキストを生成してしまうことがあります。デコーダのクロスアテンションに小さな編集を加える手法で、非音声入力での幻覚率を 89.18% から 1.94% まで下げました（Whisper-Large-v3 と環境音データ UrbanSound8K での値）（arXiv:2609.23979）
• 音声言語モデルは、音声そのものより「テキストとして予測しやすいか」に頼って答えてしまうことがあります。音声の有無で教師モデルの予測がどれだけ変わるかを報酬にして蒸留する手法を提案し、3B モデルで音声理解ベンチマーク MMAU の 72.72% という、比較した 3B モデルの中で最高の精度を達成しました（arXiv:2609.28778）

synthetic research（LLMによる合成調査研究）— 2 本

• LLM で作った「合成回答者」を人間の調査の代わりに使う研究が増えていますが、今の検証の多くは、意思決定者が本当に知りたい「実際の行動」ではなく別のものを測っていると指摘しています。そのうえで、属性ごと（サブグループごと）に妥当性を報告することと、同じ人物像で条件だけを変える反実仮想実験を検証の要件にする枠組みを提案しています（arXiv:2609.27690）
• もう 1 本は、9 つの言語モデルと 20 の人間データを比較する 11 種類のテストからなるベンチマークを提示し、内的妥当性・構成概念妥当性・外的妥当性のうち 1 つの観点で成績が良くても、ほかの観点で人間を再現できる裏付けにはならないことを示しました（arXiv:2609.30030）

2026-10-01 更新: エージェントの PR の修正を誰が書いたかの研究で、76.4% の母数の記述の誤りを修正しました

The post 【週刊論文ウォッチ 9/21〜9/27】コーディングエージェントの続報と、今週の新語「音響グラウンディング」 first appeared on クエビコ.

ところが現場では、「エージェントを増やしたのに成果がほとんど変わらない」「どこで失敗したのか追いかけられない」「APIの呼び出し回数だけが増えて費用がかさむ」といった声がよく聞かれます。

この記事では、各社の公式ドキュメントやエンジニアリングブログをもとにマルチエージェントの基本と使いどころを整理し、「なぜ失敗するのか、本当に単体より良いのか」を扱った論文4本を紹介します。結論を先に言うと、まず強い単体エージェントを作り、増やすときは同じコストで比べ、協力の手順と失敗の記録を設計に組み込むのが基本です！

マルチエージェントとは何か：複数のエージェントで仕事を分ける構成

エージェントと「複数のエージェント」

Anthropic は、エージェントを「LLMがツールを使いながら、自分で手順を決めて繰り返し動くもの」と説明し、マルチエージェントを「そうしたエージェントが複数で協力して動くシステム」と定義しています。同社はあわせて、あらかじめコードで決めた経路でLLMを呼ぶ「ワークフロー」と、LLM自身が進め方を決める「エージェント」を区別しています（Anthropic「How we built our multi-agent research system」、Anthropic「Building effective agents」）。

よくある3つの構成

各社の資料に出てくる構成は、おおむね次の3つに整理できます。

OpenAI のガイドは、中心の「マネージャー」が専門エージェントをツールとして呼ぶ型と、対等なエージェント同士が仕事を引き継ぐ分散型の2つを挙げています（OpenAI「A practical guide to building agents」）。Anthropic の調査機能は、主役のエージェントが計画を立て、3〜5体の下位エージェントを並行して走らせるオーケストレーター型です。Microsoft の設計ガイドは、議論型（グループチャット）には別名として「マルチエージェント・ディベート」もあると説明し、会話の制御を保つために参加するエージェントを3体以下に抑えることを勧めています（Microsoft「AI agent orchestration patterns」）。

単一エージェントとの使い分けとコスト

各社とも「まず単体」を勧めている

OpenAI のガイドの基本方針は、まず単体のエージェントの能力を最大限に引き出すことです。分けるのは、条件分岐の多い複雑な指示を扱いきれないときや、似たツールが多すぎて選び間違えるときとしています。Microsoft も、ツールを持つ単体のエージェントを「企業での用途では多くの場合、妥当な既定の選択」とし、複数にするのは単体では確実に処理できない理由があるときだと書いています。Anthropic も、必要になるまで複雑にしないよう勧めています。単体のエージェントの作り込みはエージェント・ハーネスの記事で扱っています。

増やすほどトークンが増える

Anthropic の社内データでは、エージェントは通常のチャットのおよそ4倍、マルチエージェントはおよそ15倍のトークンを使います。同社の社内評価では、マルチエージェント構成が単体の Claude Opus 4 を90.2%上回った一方、Web閲覧の評価（BrowseComp）で成績のばらつきの80%はトークンの使用量だけで説明できたとも述べています。つまり、性能の上積みの多くは「多くの計算を使えたこと」から来ている可能性があります。同社は、並行して進められ、価値が費用に見合う調査のような仕事に向き、多くのコーディング作業のように依存関係の多い仕事には今のところ向かないとしています（Anthropic「How we built our multi-agent research system」）。Microsoft も、エージェントごとに作業の難しさに合ったモデルを割り当てることを勧めています。モデルの使い分けによる費用の下げ方は推論コストの記事で詳しく扱っています。

研究で見る「なぜ失敗し、どこで失敗したか」

📄 論文: 失敗は「設計」「すれ違い」「検証不足」の3系統に分かれる

Why Do Multi-Agent LLM Systems Fail?（Mert Cemri ほか、2025年3月投稿・10月改訂、arXiv:2503.13657）は、査読前の論文（プレプリント）です。

対象は、公開されている7つのマルチエージェントの枠組み（MetaGPT、ChatDev など）を、プログラミング・数学・汎用タスクで動かした実行記録です。まず専門家が150件超の記録を読んで失敗の型を洗い出し、3人の注釈者で定義を詰めて一致度（κ=0.88）を確かめました。そのうえでLLMを使った自動分類で、1,642件の記録に失敗の型を付けています。

結果、失敗は14の型に分かれ、「システム設計の問題（指示や役割に従わない、同じ手順の繰り返しなど）」「エージェント間のすれ違い（確認せずに思い込みで進む、情報を渡さないなど）」「タスクの検証（早すぎる終了、検証の不足や誤り）」の3系統にまとまりました。検証役を持つ枠組みは失敗が少ない傾向がありましたが、検証役がいてもコンパイルが通るかだけを見るような表面的な確認にとどまる例も多く見られました。付録では役割の指示や構成を見直す改善も試していますが、ChatDev での改善は大きなものではなかったと著者ら自身が述べています。

運営者にとっての意味は、失敗を「モデルが弱いから」で片付けず、設計・受け渡し・検証のどこで起きたかを分けて見られるということです。

📄 論文: どのエージェントのどのステップが悪かったかは、自動ではまだ特定しにくい

Which Agent Causes Task Failures and When? On Automated Failure Attribution of LLM Multi-Agent Systems（Shaokun Zhang ほか、2025年4月投稿・6月改訂、arXiv:2505.00212）は、査読前の論文（プレプリント）です。

対象は、Web検索などを伴う質問集（GAIA、AssistantBench）を解かせた127のマルチエージェントシステムの失敗記録です。自動生成した構成（GPT-4o で動作）と、人が作り込んだ構成（Magentic-One）の両方を含みます。人が「原因のエージェント」と「決定的な誤りのステップ」を注釈したデータセット（Who&When）を作り、主に GPT-4o に記録を読ませて当てさせました。

記録を一度に全部読ませる方法は、原因のエージェントを当てるのが最も得意で、正答率は平均53.5%でした。一方、誤りのステップを当てるのは1ステップずつ判定させる方法が最も得意でしたが、それでも平均14.2%にとどまりました。どちらも GPT-4o での、正解の有無と構成の種類をまたいだ4条件の平均です。ランダムより平均で悪かったのは、一度に全部読ませる方法でステップを当てる場合で、エージェントを当てる場合はどの方法もランダムを上回っています。人が作り込んだ構成の記録で OpenAI o1 や DeepSeek R1 に替えて試しても、GPT-4o を一貫して上回ることはありませんでした。

運営者にとっての意味は、失敗の原因探しをまだAIに任せきれないということです。人が後から追えるよう、記録の残し方を最初から決めておく必要があります。

研究で見る「協力するか、本当に単体より良いか」

📄 論文: 賢いモデルほど協力的とは限らない

More Capable, Less Cooperative? When LLMs Fail At Zero-Cost Collaboration（Advait Yadav ほか、2026年4月投稿・6月改訂、arXiv:2604.07821）は、ICML 2026 採録（abs のコメント欄の記載）です。

対象は、実際の業務ではなく著者らが作った模擬環境です。10体のエージェント（すべて同じモデル）が20ラウンドにわたり、他のエージェントが持つ情報を集めてタスクを完了させます。情報を渡しても渡した側は何も失わず、全員に「システム全体の収益を最大化し、協力せよ」と同じ指示を与えています。8つのLLMで各5回ずつ試しました。

最適な動きをした場合と比べると、OpenAI o3 は17%しか達成できず、より小型の o3-mini は50%に達しました。一般的な性能の高さと、この環境での成果には相関が見られませんでした。一部のモデルは、渡しても損をしないのに、求められた情報を渡しませんでした。対策の効き方はモデルで分かれ、「必要な情報を求め、求められたら渡し、そろったらすぐ提出する」という手順を明示すると、手際の悪さで失敗していたモデルの一部は成果がおよそ2倍になりました。協力しないことで失敗していたモデルには、情報を渡すたびの小さな報酬が効きました。

運営者にとっての意味は、「賢いモデルなら自然に協力する」とは考えず、誰が何をいつ渡すかを手順として書いておく必要があるということです。

📄 論文: 最適化の予算を揃えると、チームは単体を有意に上回れなかった

At Equal Inference Cost, Multi-Agent Structure Does Not Beat a Single Frozen Agent（David Dylan ほか、2026年6月、arXiv:2609.04217）は、査読前の論文（プレプリント）です。

対象は、家庭内の作業をこなすテキストの仮想環境（ALFWorld、評価用134タスク）と、模擬的なネット通販の環境（WebShop、80セッション）です。すべての役割で同じ Qwen2.5-7B を固定して使い、プロンプトだけを最適化しました。多くの比較ではチームの方が1ステップあたり多くのモデル呼び出しを使えるため、この論文はプロンプトを最適化する段階で使えるLLMの呼び出し総数を揃えて、計画役・実行役・批評役のチームと単体のエージェントを比べています。最適化後の評価での呼び出し回数は揃えていません。評価は条件ごとに1回です。

ALFWorld では、チームの平均が最も高かったものの、単体との差は統計的に有意ではありませんでした（0.769対0.754、p=0.80）。しかも評価での1タスクあたりの呼び出し回数は、チームが単体の1.8倍でした。最適化の段階でチームに2〜3倍の呼び出しを許しても、チームは単体と並ぶだけでした。WebShop ではプロンプト最適化の効果自体が見られず、チームはむしろ悪化する傾向でした（有意差はなし）。計画役と批評役のプロンプトは最適化しても空のままで、成績の上積みにつながっていませんでした。著者ら自身、7Bモデル1種類・1つの構成での結果で、大きなモデルや役割ごとに違うモデルを使う場合に当てはまるとは主張しないと述べています。また、表の一部の行は検定の値が空欄で、一部の実験はエラーで完了しなかったと著者ら自身が書いています。

運営者にとっての意味は、「チームにしたら良くなった」という結果を見たら、まず同じ呼び出し回数の単体と比べたかを確かめるべきだということです。

現場でやること

まず「強い単体エージェント」を基準線にする

いきなり複数にせず、ツールと指示を整えた単体のエージェントで、どこまでできるかを測ります。この成績と費用が、後でチームを評価するときの基準線になります。

増やすときは、同じ呼び出し回数・トークン数で比べる

以下は論文の条件ではなく、運用上の提案です。チームを試すときは、成績と一緒に本番でのLLMの呼び出し回数とトークン数を記録します。4本目の論文のように、作る段階の予算を揃えても、本番ではチームの方が多く呼び出すことがあるためです。単体にも同じ回数を使わせて（たとえば複数回答えさせて選ぶなど）比べ、差が構成の効果なのか、計算を多く使った効果なのかを切り分けます。

受け渡しの手順を明文化する

エージェントごとに、目的・出力の形式・使うツール・担当の範囲を書きます。Anthropic も、下位のエージェントへの指示があいまいだと、同じ検索を重複して行ったり抜けが出たりしたと述べています。あわせて次を決めておきます。

• 誰が、どの情報を、いつ渡すか
• どの条件で作業を終えてよいか
• 検証役は何を基準に合否を出すか

実行記録を残し、失敗の型で読む

各エージェントの入出力とツールの呼び出しを、後から順に追える形で残します。失敗したら、設計・受け渡し・検証のどの系統かで分類します。自動での原因特定はまだ精度が低いので、AIの判定は手がかりとして使い、最後は人が確かめます。

マルチエージェント導入の鍵は次の3点です

1. まず強い単体エージェントを基準線にする
   各社とも単体から始めることを勧めています。複数にするのは、単体では確実に処理できない理由が見えてからです。
2. 同じコストで比べてから増やす
   チームの上積みは、多くの計算を使えたことから来ている場合があります。呼び出し回数とトークン数を揃えて単体と比べます。
3. 協力の手順と失敗の記録を設計に組み込む
   賢いモデルでも自然には協力しません。受け渡しの手順を明示し、人が後から追える実行記録を残します。

まとめ：マルチエージェントは「増やせば強い」から「必要なときだけ、設計して使う」へ！

マルチエージェントは、並行して進められる調査のような仕事では大きな力を発揮します。一方で、トークンの消費は大きく増え、失敗の原因は追いにくくなり、同じコストで比べると単体を上回らない例も報告されています。

まずは今のエージェントの成績・呼び出し回数・トークン数を記録し、「単体ではどこまでできるか」を測ってみてください。そのうえで増やすかどうかを決めれば、費用だけが膨らむ構成を避けられます！

参考文献

• Anthropic「Building effective agents」（https://www.anthropic.com/engineering/building-effective-agents）2026-10-01 確認
• Anthropic「How we built our multi-agent research system」（https://www.anthropic.com/engineering/multi-agent-research-system）2026-10-01 確認
• OpenAI「A practical guide to building agents」（https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf）2026-10-01 確認
• Microsoft「AI agent orchestration patterns」（https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns）2026-10-01 確認
• Mert Cemri ほか「Why Do Multi-Agent LLM Systems Fail?」arXiv:2503.13657（https://arxiv.org/abs/2503.13657）2026-10-01 確認
• Shaokun Zhang ほか「Which Agent Causes Task Failures and When? On Automated Failure Attribution of LLM Multi-Agent Systems」arXiv:2505.00212（https://arxiv.org/abs/2505.00212）2026-10-01 確認
• Advait Yadav ほか「More Capable, Less Cooperative? When LLMs Fail At Zero-Cost Collaboration」arXiv:2604.07821（https://arxiv.org/abs/2604.07821）2026-10-01 確認
• David Dylan ほか「At Equal Inference Cost, Multi-Agent Structure Does Not Beat a Single Frozen Agent」arXiv:2609.04217（https://arxiv.org/abs/2609.04217）2026-10-01 確認

2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、失敗原因の自動特定の正答率とランダムとの比較、チームと単体の比較で揃えた条件の記述の誤りを修正しました

The post 【2026年最新】マルチエージェントの協調×論文4選｜「エージェントを増やしたのに精度が上がらない」を解く first appeared on クエビコ.

その答えとして、いま arXiv で急に語られ始めているのが 「エージェント・ハーネス（agent harness）」、つまりモデルの周りにある「何を見せるか・どのツールを使わせるか・どうループを回すか」を決める外側のコードです。Claude Code や Codex のような製品で、モデル以外の部分すべてを指す言葉だと考えると分かりやすいでしょう。

本記事では、当ブログ独自の arXiv 急上昇ワード集計 で直近 3 か月にいちばん伸びたこのテーマについて、実務に効く論文を 4 本選んで解説します。

目次

• 📈 今月の急上昇ワード（ソフトウェア工学 cs.SE）
• 1. 【同じモデルでも別物】コンテキストが狭い条件では、ハーネスを替えるだけで解ける課題が 43 件 → 72 件に
• 2. 【どこに効くか】コンテキスト管理は「窓が狭いほど」効く。計画はモデルが強いとコスト削減に変わる
• 3. 【自動で育てる】ハーネスを「進化」させるだけで業務タスクが 20〜35 ポイント改善
• 4. 【ハーネスは攻撃面】ハーネスが組み立てるコンテキストで、低い権限の指示が「昇格」する
• ハーネスを現場で設計する 3 大原則
• まとめ

📈 今月の急上昇ワード（ソフトウェア工学 cs.SE）

cs.SE に投稿された論文を毎月 250 本ずつ集め、各概念が「論文全体の何 % で語られたか」を、直近 3 か月（2026年7〜9月）とその前の 6 か月（1〜6月）で比べました。

※「伸び」は、少数の偶然で跳ねないよう平滑化した値です（集計方法は末尾を参照）。

agent harness という言葉を使った論文は、2026年4月まで 0 本でした。5月に初めて現れ、8月には 250 本中 8 本（3.2%）まで増えています。

分野をまたいでも同じ動き: coding agent はセキュリティ（cs.CR）で 2.6 倍、自然言語処理（cs.CL）で 2.1 倍と、3 分野すべてで上位に入りました。セキュリティ分野では、ほかに radio access network（無線アクセス網, 2.5倍）と cpu（2.2倍）が伸びています。

1. 【同じモデルでも別物】コンテキストが狭い条件では、ハーネスを替えるだけで解ける課題が 43 件 → 72 件に

• 関連論文: Same Model, Different Harness: Different Coding-Agent Results (arXiv:2608.26218)

💡 現場の課題

エージェントの比較や選定は、「どのモデルが強いか」で語られがちです。しかし実際に使うのは「モデル＋ハーネス」の組み合わせで、ハーネス側の差がどれだけ効くのかは見過ごされてきました。

📄 論文が明かす最新知見

• モデルと課題を固定し、ハーネスの設定だけを変えて比べた
• 主な変更は、コンテキストが埋まってきたら古いツール出力を機械的に短くすることと、同じ作業の繰り返しや停滞を検知して介入すること
• コンテキスト窓が狭い条件（Qwen3.6, 20,480 トークン, 169 課題, 1 課題 480 秒まで）で、SWE-bench Verified の完全解決が 43 件 → 72 件。修正後に通るべきテストのうち実際に通った割合（課題ごとの平均）は 28% → 49%
• 窓が広い条件（262,144 トークン）では、Verified と Pro で 2 つの設定の差はほぼ消えた（FeatureBench では改善が残った）
• モデルごとに調整し直さなくても、設計の異なる別の 3 モデルでも改善した
• 結論: エージェントの評価では、「モデルとハーネスを一体の解答者」として扱うべき

2. 【どこに効くか】コンテキスト管理は「窓が狭いほど」効く。計画はモデルが強いとコスト削減に変わる

• 関連論文: An Empirical Study of Harness Design for Coding Agents (arXiv:2609.20804)

💡 現場の課題

「計画を立てさせる」「専用ツールを用意する」「履歴を要約する」など、ハーネスの工夫は多いものの、どの部品がどれだけ効くのかは分かっていませんでした。そのため、自社用に作るときに何を優先すべきか判断できません。

📄 論文が明かす最新知見

• 4 モデル × SWE-Bench Verified / Terminal-Bench 2.1 で、176 通りの設定を部品ごとに比較した
• コンテキスト管理は窓が小さいほど効く。効果の大半は「あふれて落ちる失敗」を防ぐことによるもの
• 最も効率が良いのは、ルールで削ってから LLM で要約するという 2 段構え。削った内容を後から取り出せる仕組みを足しても、モデルがほとんど使わず精度は上がらない
• 計画ステップは、弱いモデルでは精度を支え、強いモデルでは主にコスト削減として働く
• bash が得意なモデルなら、専用ツールを揃えなくても bash だけで十分動き、コストも大きく下がる（特にコマンド操作が中心の Terminal-Bench で。SWE-Bench では専用ツールの方が良いモデルもあった）

3. 【自動で育てる】ハーネスを「進化」させるだけで業務タスクが 20〜35 ポイント改善

• 関連論文: StarHarness: Evolving Harnesses with Stratified Search for Enterprise Environments (arXiv:2608.24804)

💡 現場の課題

SRE、ITSM、経理など社内の業務環境には、独自のツールや慣習があります。汎用のエージェントをそのまま持ち込むと、モデルと環境のミスマッチでつまずきます。とはいえ、モデルを追加学習するのは重い作業です。

📄 論文が明かす最新知見

• モデルの重みは固定したまま、プロンプト、ツールの与え方、スキル、MCP、サブエージェント構成、ループ設定といったハーネス側を自動で改良する
• 失敗の傾向で課題を層別化し、「改良案を探す課題」と「採否を決める課題（提案側からは見えない）」を分けて、過剰適合を防ぐ
• ITBench SRE / EnterpriseOps-Gym ITSM / AutomationBench Finance で、採用した変更は環境ごとに 4〜12 件だけで、既定のハーネスと比べて 20〜35 ポイント改善（改良に使ったモデル GPT-5.4 での値）
• 改良に使わなかった課題でも効果が残り、GPT 系と Qwen 系の間で作り直さずに流用できた
• 効いていたのは、インターフェースの修正、環境の慣習、運用知識の書き込みといった地味な改善。一部の環境では誤診断が減り、手順（ターン数）も短くなった

4. 【ハーネスは攻撃面】ハーネスが組み立てるコンテキストで、低い権限の指示が「昇格」する

• 関連論文: When Context Gets Root: Privilege Escalation in LLM Harnesses (arXiv:2608.27299)

💡 現場の課題

モデル側には「システム指示 ＞ ユーザー ＞ ツール出力」のような指示の優先順位（instruction hierarchy）で守る仕組みがあります。しかし、実際にどの文字列をどの立場でモデルに渡すかを決めているのはハーネスです。

📄 論文が明かす最新知見

• ハーネスがコンテキストを組み立てる過程で、低い権限の悪意あるコンテンツが上位の指示として扱われてしまう攻撃「instruction privilege escalation」を提示した
• マルチエージェントの仕組みを使った攻撃で、6 つのコーディングエージェント向けハーネスを検証した。操作を無制限に許可した設定では、機密性・完全性・可用性・リモートコード実行にわたる 13 の攻撃目標をすべて達成（各目標で数回までの試行を重ねた結果。1 回あたりの成功率はハーネスにより 31.7〜100%）
• 自動の権限レビューを備えた 3 つのハーネスでも、13 目標すべてが成功した
• ハーネスの「永続的なゴール」や「スケジュール実行」の機能経由でも再現できた

ハーネスを現場で設計する 3 大原則

1. 評価は「モデル＋ハーネス」の組で行う
   モデルを比べる前にハーネスを固定する。ベンダー公表値と自社の結果が違うのは、ハーネスが違うからかもしれません（論文1）。
2. 窓が狭い・作業が長いなら、まずはコンテキスト管理から。足すより削る
   古いツール出力の機械的な切り詰めとルールによる削除が最初の一手です。専用ツールや計画ステップは、モデルの得意不得意を見て足します（論文1・2）。
3. ハーネスは「育てるもの」であり「守るもの」
   失敗ログから少しずつ改良し、採否は別の課題で判断する（論文3）。同時に、コンテキストを組み立てる箇所を権限境界として監査します。論文4が示すとおり、ハーネスの設計は性能の問題であると同時に、セキュリティ境界の問題でもあると考えるべきでしょう。

まとめ：エージェント選びは「どのモデルか」から「どう包むか」へ！

7〜9 月の arXiv では、「agent harness」という言葉が前の半年の約 3 倍（平滑化後の値）の割合で語られました。論文から見えてくるのは、同じモデルでも包み方次第で成果が大きく変わり、しかもその包み方は自動で改良できるという流れです。一方で、ハーネスは新しい攻撃面にもなっています。

次にエージェントを見直すときは、モデルの載せ替えより先に、ハーネスのコンテキスト管理と権限設計を点検してみてください。

2026-10-01 更新: 論文1の、コンテキスト窓が広い条件での結果の記述の誤りを修正しました

The post 【2026年9月 急上昇ワード】エージェント・ハーネス×論文4選｜「同じモデルなのに、エージェントの出来が安定しない」を解く first appeared on クエビコ.

ところが現場では、「上限には収まっているのに、長い資料を渡すと大事な箇所を見落とす」「前回の会話で伝えたはずの情報が反映されない」といった声がよく聞かれます。上限の数字だけを見て設計すると、こうした見えにくい劣化に気づけません。

この記事では、各社の公式ドキュメントをもとにコンテキストウィンドウとメモリ機能の仕組みを整理し、「長い入力を実際にどこまで使いこなせるのか」「記憶をどう評価すべきか」を扱った論文4本を紹介します。結論を先に言うと、上限ではなく「実際に読める量」を自分の資料で測り、長い資料は置き方と渡し方を工夫し、記憶機能は事実ごとに点検するのが基本です！

コンテキストウィンドウとは何か：AIの「作業机」の広さ

会話の履歴も出力も、すべて含めて数える

Anthropic のドキュメントは、コンテキストウィンドウを「モデルが応答を作るときに参照できるテキストのすべて（応答そのものを含む）」と説明し、学習に使われた大量のデータとは別の「作業用の記憶」にあたるとしています。Google も、短期記憶にたとえて説明しています（Anthropic「Context windows」、Google「Long context」）。

注意したいのは、数えられるのが質問文だけではない点です。Anthropic の説明では、システムプロンプト、それまでの会話のすべて、ツールの実行結果や画像・文書、ツールの定義、さらにモデルが生成する出力や思考の部分まで、すべてが上限に数えられます。OpenAI も、上限には入力・出力・推論のトークンが含まれ、超えた分は切り捨てられうると書いています（OpenAI「Conversation state」）。会話が長引くほど、資料を置ける余白は減っていきます。

2026年10月時点で、Anthropic は最新世代を中心とする多くのモデルの上限を100万トークン、それ以外のモデルを20万トークンとしています。Google も、多くの Gemini モデルが100万トークン以上を扱えるとしています。

上限に収まっても、長いほど精度は落ちる

大事なのは、各社とも「入れられること」と「使いこなせること」を分けて説明している点です。Anthropic は、トークン数が増えるほど正確さや思い出す力が落ちる現象を「コンテキストの劣化（context rot）」と呼び、何を入れるかを選ぶことは、空きの大きさと同じくらい重要だとしています。Google も、1つの情報を探す試験では高い精度が出る一方で、探す情報が複数になると同じ精度は出ず、内容によって大きく変わると明記しています。

会話をまたぐ「記憶」の仕組み

APIは本来「前の会話を覚えていない」

OpenAI のドキュメントは、文章生成のリクエストは1回ごとに独立していて状態を持たない、と説明しています。複数回のやりとりは、それまでの会話をリクエストに含めて送ることで成り立っています。つまり、AIが「覚えている」ように見えるのは、過去のやりとりがコンテキストウィンドウに入っている間だけです。

チャットサービスのメモリ機能

会話をまたいで覚えておくのがメモリ機能です。Anthropic のヘルプによると、Claude のメモリは会話の終了後に要約するのではなく、会話中に話題ごとに保存し、利用者が確認・編集できます。プロジェクトごとに記憶は分かれ、1つのチャットだけメモリを使わない設定もあります。健康や信条などの個人的な話題は既定では保存せず、Team・Enterprise プランでは管理者が利用の可否を決めます（Anthropic「Use Claude’s chat search and memory to build on previous context」）。Google の Gemini アプリの過去のチャットに基づく個人化は、個人の Google アカウントで使う機能で、仕事用や学校用のアカウントでは使えないと案内されています（Google「Get personalization in Gemini Apps」）。

開発者が作る記憶：メモリツール

自社のエージェントに記憶を持たせる場合は、仕組みを自分で用意します。Anthropic のメモリツールは、モデルが記憶用のファイルの作成・読み出し・更新・削除を要求し、実際の保存はアプリ側が行う方式です。同じドキュメントは、機密情報を書き込む前に取り除く検証、ファイルの大きさの上限、長く使われていない記憶の定期的な削除、そして記憶用の保存場所の外にあるファイルに触れられないよう、操作のたびに指定先を検証することを、アプリ側の責任として挙げています（Anthropic「Memory tool」）。

研究で見る「長い入力のどこで見落とすか」

📄 論文: 長さが同じでも「情報の詰まり具合」で見落とす

Dense Contexts Are Hard Contexts: Lexical Density Limits Effective Context in LLMs（Giovanni Dettori ほか、2026年6月、arXiv:2606.06203）は、査読前の論文（プレプリント）です。

対象は 9B〜685B パラメータの、重みが公開されたモデル8種で、小さめのモデルは研究用のGPUで、大きなモデルは商用APIで動かしています。長さをどれも約1万2千トークンにそろえた3種類の「探し物」課題を作り、各100問で、正解の位置を少しずつずらして測りました。3種類は、同じ定型文が並ぶ対応表から値を探すもの（疎）、場面に反するルールを一覧から探すもの（中）、文に含まれる禁止語を単語の一覧から探すもの（密）で、情報の詰まり具合が違います。課題の種類も違うため、各課題の中で同じ項目を繰り返して密度だけを下げる実験も加えています。

結果は、疎な対応表ではどの位置でもほぼ満点だった一方、密な2種類では正解が後ろにあるほど成績が下がり、8モデルの平均で、正解が1万2千トークン地点にあるときのスコアは2千トークン地点に比べて、満点を100として27ポイントと31ポイント低くなりました。約1万2千トークンは、長さだけなら劣化しないと考えられてきた短さです。密度だけを下げると成績はおおむね戻りましたが、単語の一覧では、中程度に間引くとかえって悪くなる場合もありました。

運営者にとっての意味は、表や一覧、設定ファイルのように新しい情報がぎっしり詰まった資料は、短くても見落としが起きやすいということです。

📄 論文: 上限の「半分手前」で崩れたモデルがある

Intelligence Degradation in Long-Context LLMs: Critical Threshold Determination via Natural Length Distribution Analysis（Weiwei Wang ほか、2026年1月、arXiv:2601.15300）は、査読前の論文（プレプリント）です。

対象は公開モデルの Qwen2.5-7B（上限12万8千トークン）1つで、読解問題1,000件を、資料を切り詰めたり水増ししたりせず元の長さのまま解かせ、答えの一致度（F1）を測りました。短い資料は SQuAD、長い資料は NarrativeQA という別のデータセットから500件ずつ取っています。

結果は、上限の40%（約5万1千トークン）まではF1が0.55〜0.58で安定していたのに、40〜50%の間で0.556から0.302へ45.5%落ち、その先も戻りませんでした。ただし1モデル・1種類の課題での結果で、著者ら自身も、ほかのモデルや課題に当てはまるかは今後の検証が必要だとしています。

運営者にとっての意味は、「上限に収まるか」だけでは安心できず、使うモデルと資料で落ち始める長さを確かめる必要があるということです。

長い資料を「読ませずに扱う」、記憶を「事実ごとに測る」

📄 論文: 長い資料はファイルとして置き、エージェントに探させる

Coding Agents are Effective Long-Context Processors（Weili Cao ほか、2026年3月、arXiv:2603.20432）は、査読前の論文（プレプリント）です。

長い資料をモデルに丸ごと読ませる代わりに、文書をファイルとしてフォルダに置き、既製のコーディングエージェントに検索コマンドやプログラムで探させる方法を試しました。対象は、長い文書の読解・集計や、最大3兆トークンの文書群からの質問応答など公開ベンチマーク5種で、それぞれ200問を無作為に選び、Codex（GPT-5）を中心に、2種では Claude Code（Sonnet 4.5）でも測っています。比較相手は、GPT-5 に資料を区切って読ませる方法、一般的な RAG、検索ツール付きのエージェントなどです。

結果は、5種のうち4種で公表済みの最高値を上回り、相対的な改善幅は平均17.3%でした。一方で、多様な長文読解を集めたベンチマークでは最高値に届かず、GPT-5 にそのまま読ませた場合とほぼ同じでした。また、検索ツールを追加するとかえって成績が下がる場合があり、1問あたりの費用は RAG より高くなっています。

運営者にとっての意味は、長い資料への対策として「上限の大きいモデルに入れる」「RAGで一部を渡す」に加えて、「ファイルとして探させる」も比べる価値があるということです。

📄 論文: 記憶は「正解率」でなく事実ごとの変化で測る

MemTrace: Probing What Final Accuracy Misses in Long-Term Memory（Xianxuan Long ほか、2026年6月、arXiv:2606.17328）は、査読前の論文（プレプリント）です。

既存の評価用データ（HaluMem）にある20人分の複数回の会話履歴から、利用者に関する835の事実を取り出し、事実ごとに「何回前の会話で出たか」「今の状態・以前の状態・変化の経緯のどれを聞くか」「根拠がある・ない・誤った前提を含むか」を変えて、1万5千問以上を作りました。長文脈モデル、RAG、外部記憶、エージェント型の計13構成を比べました。長文脈モデルは会話履歴を直接読んで自分で答え、ほかの構成は取り出した記憶を共通のモデル（gpt-4o-mini）に渡して答えさせています。

結果は、全体の正解率が近くても弱点がばらばらでした。長文脈モデルの Qwen3.5-35B は、新しい事実の「変化の経緯」には49.0%答えられたのに、会話が積み重なると6.7%に落ちました。話に出ていない事実についてはほぼ必ず回答を控えるのに、誤った前提はあまり正せないシステムもありました。1種類の簡単な検索器を使った300問の追試では、正しい会話に届いていたのに解けなかった例が、届かなかった例の約10倍ありました。この倍率は検索器によって変わりうると著者らは断っています。

運営者にとっての意味は、記憶の改善は「保存を増やす」より「取り出せた情報を正しく使わせる」ことが課題で、評価も事実の更新や誤った前提を含めて行う必要があるということです。

現場でやること

長い資料は「置き方」を整える

各社のガイドは、長い資料の渡し方について具体的な指針を示しています。

• 長い資料はプロンプトの先頭に置き、質問は最後に書く（Anthropic は、質問を最後に置くと、特に複数の資料を含む複雑な入力で、回答の質が試験で最大30%上がったとしています）
• 複数の資料は1つずつ区切り、出典や資料名を添える
• 答える前に、関係する箇所を資料から引用させる

（Anthropic「Prompting best practices」、Google「Long context」）

自社の資料で「落ち始める長さ」を測る

上限の数字ではなく、実際に使う資料と質問で確かめます。資料の長さを変えたり、答えの書かれた箇所を前後に動かしたりして、同じ質問への正答がどこから崩れるかを見ます。表や一覧のように情報が詰まった資料は、短くても分割して渡すことを前提にしましょう。

長い資料は「探させる」構成も比べる

すべてを1回で読ませる方法、関連部分だけを渡す RAG（RAGの実務の記事）、ファイルとして置いてエージェントに探させる方法を、同じ質問で比べます。精度だけでなく、1件あたりの費用と待ち時間も合わせて判断します（推論コストの記事）。

記憶機能は「事実ごと」に点検する

• 利用者の情報が変わったとき（担当者の交代、締め切りの変更など）に、新しい内容で答えられるか
• 「以前はどうだったか」「どう変わったか」を聞いても正しく答えられるか
• 話していない事実を聞かれたら「分からない」と言えるか、誤った前提を含む質問を正せるか
• 業務で使うなら、保存される内容の確認方法、オフにする手順、古い記憶の削除の運用を決めておく

長文脈と記憶を使いこなす鍵は次の3点です

1. 「上限に収まるか」ではなく「実際に読める量」で設計する
   自社の資料で長さや情報の詰まり具合を変えて精度を測り、どこから落ち始めるかを把握します。
2. 長い資料は置き方と渡し方を工夫する
   資料を先頭・質問を末尾に置き、引用させてから答えさせます。読ませるだけでなく、ファイルとして探させる構成も比べます。
3. 記憶機能は事実ごとと変化の追跡で評価する
   全体の正解率だけで判断せず、情報の更新や誤った前提を含む質問で正しく振る舞えるかを確かめます。

まとめ：長文脈と記憶は「どれだけ入るか」から「どれだけ使えるか」へ！

コンテキストウィンドウは会話の履歴や出力まで含めた「作業机」の広さで、各社とも長くなるほど精度が落ちうると説明しています。研究でも、情報の詰まり具合や長さによって上限よりずっと手前で見落としが起きる例や、記憶が「保存されていても使われない」例が示されました。

まずは、よく使う長い資料を1つ選び、答えの書かれた箇所を動かしながら同じ質問をしてみてください。自社の環境で「どこまで読めるか」が見えてきます！

参考文献

• Anthropic「Context windows」（https://platform.claude.com/docs/en/build-with-claude/context-windows）2026-10-01 確認
• Anthropic「Prompting best practices」（https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices）2026-10-01 確認
• Anthropic「Memory tool」（https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool）2026-10-01 確認
• Anthropic「Use Claude’s chat search and memory to build on previous context」（https://support.claude.com/en/articles/11817273-using-claude-s-chat-search-and-memory-to-build-on-previous-context）2026-10-01 確認
• Google「Long context」（https://ai.google.dev/gemini-api/docs/long-context）2026-10-01 確認
• Google「Get personalization in Gemini Apps」（https://support.google.com/gemini/answer/16598623?hl=en）2026-10-01 確認
• OpenAI「Conversation state」（https://developers.openai.com/api/docs/guides/conversation-state）2026-10-01 確認
• Giovanni Dettori ほか「Dense Contexts Are Hard Contexts: Lexical Density Limits Effective Context in LLMs」arXiv:2606.06203（https://arxiv.org/abs/2606.06203）2026-10-01 確認
• Weiwei Wang ほか「Intelligence Degradation in Long-Context LLMs: Critical Threshold Determination via Natural Length Distribution Analysis」arXiv:2601.15300（https://arxiv.org/abs/2601.15300）2026-10-01 確認
• Weili Cao ほか「Coding Agents are Effective Long-Context Processors」arXiv:2603.20432（https://arxiv.org/abs/2603.20432）2026-10-01 確認
• Xianxuan Long ほか「MemTrace: Probing What Final Accuracy Misses in Long-Term Memory」arXiv:2606.17328（https://arxiv.org/abs/2606.17328）2026-10-01 確認

2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、情報密度の実験条件、上限の半分手前での性能低下を調べた対象モデル、コーディングエージェントの比較結果の記述の誤りを修正しました

The post 【2026年最新】長文脈とAIの記憶×論文4選｜「長い資料ほど見落とす」「前に伝えたことを忘れる」を解く first appeared on クエビコ.

やっかいなのは、利用者が直接入力しなくても、エージェントが読みに行った先に指示が仕込まれていれば攻撃が成立する点です。「検知を1つ挟めば安心か」「どこまで権限を渡してよいか」の判断材料が足りず、PoCから先に進めないという声も少なくありません。とはいえ「怖いから権限を絞る」だけでは、エージェントの価値も一緒に小さくなってしまいます。

この記事では、OWASP や英国の国家サイバーセキュリティセンター（NCSC）、各社の公式ドキュメントをもとに仕組みと対策の全体像を整理し、「検知で防ぐ」「検知の限界」「設計で閉じ込める」「ツール経由の新しい攻撃」を扱った論文4本を紹介します。結論を先に言うと、検知は「確率を下げる網」と割り切り、騙されても被害が出ないように権限と処理の流れを設計するのが基本です！

プロンプトインジェクションとは何か：「データ」と「指示」の区別がつかない

OWASP による定義

OWASP は、LLMアプリケーションのリスク一覧（2025年版）の1番目にプロンプトインジェクションを挙げ、入力によってLLMの振る舞いや出力が意図しない形で変わる脆弱性と定義しています。人間の目に見えない形でも、モデルが読み取れば効果を持ちます（OWASP「LLM01:2025 Prompt Injection」）。

直接型と間接型

OWASP は、プロンプトインジェクションを2つの型に分けています。

Anthropic の公式ドキュメントも同じ分け方で、間接型の例に受信メール、取得したWebページ、ツールの実行結果などを挙げています（Anthropic「Mitigate jailbreaks and prompt injections」）。エージェントにとって問題が大きいのは間接型です。Microsoft も、報告を受けるAIの脆弱性で最も多い手法の1つだと述べています（Microsoft「How Microsoft defends against indirect prompt injection attacks」）。

なお、検索して取り込む文書に指示を仕込むRAGの「毒入れ」については、RAGの実務×論文4選で扱っています。

なぜ根本的には防げないのか

英国 NCSC は2025年12月のブログで、プロンプトインジェクションを SQL インジェクションと同じように考えるのは危険だと指摘しています。SQL インジェクションはデータと命令を分けて扱う仕組みで根本から防げますが、LLMの内部には「データ」と「指示」の区別がなく、あるのは「次に来る言葉の予測」だけです。そのため同じ意味で完全に防げるようにはならない可能性が高い、としています（NCSC「Prompt injection is not SQL injection (it may be worse)」）。

OWASP も確実な防ぎ方があるかは分からないとし、OpenAI も対策でリスクは大きく下がるがなくならないと書いています（OpenAI「Safety in building agents」）。NCSC は、残るリスクを前提に設計と運用で管理すべきで、それを許容できないならLLMに向いた用途ではないかもしれない、とまで述べています。

対策の全体像：「起きにくくする」「見つける」「被害を小さくする」

Microsoft は対策を「予防」「検知」「影響の軽減」に分け、攻撃の可能性を下げるだけの確率的な対策と、設計で特定の攻撃が成功しないことを保証する決定的な対策を区別しています。すべてに決定的な対策は使えないので、組み合わせる考え方です。

起きにくくする

各社に共通するのは、外部から来た内容を開発者の指示と混ぜないことです。Anthropic は外部の内容をツールの結果として出どころとともに渡し、それが信頼できないデータだとシステムプロンプトに明記するよう勧めています。OpenAI も、信頼できない入力を開発者向けの指示に入れないこと、処理の間を決まった形式の出力でつなぐことを挙げています。

見つける

入力やツールの結果を、本体に渡す前に小型のモデルで判定させる方法も紹介されています（Anthropic）。ただし NCSC は、既知の危険な言い回しを拒否リストで止める方法には、言い換えが無限にあるため注意が必要だとしています。

被害を小さくする

OWASP は、最小権限と、権限の大きい操作に人の承認を挟むことを挙げています。同じ一覧の「過剰な権限（Excessive Agency）」の項目では、被害の根本原因を「機能が多すぎる」「権限が強すぎる」「自律性が高すぎる」の3つに整理しています（OWASP「LLM06:2025 Excessive Agency」）。NCSC は、LLMを使わない仕組みで行動を縛る対策を重視すべきだとしています。ここからは、それぞれの層に取り組んだ論文を見ていきます。

研究で見る「検知」の実力と限界

📄 論文: 既製のLLMに「紛れ込んだ指示」を見つけて取り除かせる

PromptArmor: Simple yet Effective Prompt Injection Defenses（Tianneng Shi ほか、2025年7月、arXiv:2507.15219）は、査読前の論文（プレプリント）です。

評価は、銀行・メッセージ・旅行・業務の4種類の模擬環境でエージェントの作業を再現するベンチマーク AgentDojo 上で、検知役には主に OpenAI のAPIのモデルを使っています。

市販のLLMに工夫したプロンプトを与え、エージェントが読む前のツールの結果から紛れ込んだ指示を見つけて取り除かせる方法です。検知役に GPT-4o、GPT-4.1、o4-mini を使うと、ベンチマーク付属の定型的な手口に対して誤検知と見逃しがともに1%未満で、防御なしでは約55%だった攻撃成功率も1%未満に下がりました。防御を知ったうえで自動で手口を変えて試す攻撃（1手法）でも、攻撃成功率は0.34%でしたが、見逃しは約2%と通常の評価より増えています。古いモデル（GPT-3.5）を検知役にすると、誤検知・見逃しとも1割を超えました。

運営者にとっての意味は、性能の高いモデルを検知役にすれば手軽な「1枚目の網」として有力だが、評価の範囲外の攻撃にも同じ数字が出るとは限らない、ということです。

📄 論文: 「ほぼ完璧な検知」が構造的に崩れるケース

How Not to Detect Prompt Injections with an LLM（Sarthak Choudhary ほか、2025年7月投稿・2025年12月改訂、arXiv:2507.05630）は、査読前の論文（プレプリント）です。

評価の対象は、KAD を強化した代表的な防御（検知役を追加学習したもの）1つで、感情分析や要約など7種類の文章処理の課題に、本体のモデルとして GPT-4.1 や Claude 4 Sonnet など4つを組み合わせて測っています。エージェントでの評価ではありません。

「既知回答検知（KAD）」は、検知役のLLMに答えの分かっている確認用の課題を出し、入力に指示が紛れ込んでいれば検知役がそちらに引っ張られて正しく答えられなくなる、という性質を利用する方式で、「ほぼ完璧」と報告されていました。著者らはこの前提そのものの構造的な弱点を突く攻撃を設計しました。モデルの内部へのアクセスも、攻撃文の最適化計算も使っていません。検知率はほとんどの課題で0%まで下がり、攻撃の成功率は課題とモデルによっては9割前後に達しました（1割未満の組み合わせもあります）。

運営者にとっての意味は、検知の数字は「攻撃者が仕組みを知らない」前提のことが多く、検知だけに頼るのは危険だということです。

研究で見る「設計で閉じ込める」

📄 論文: 信頼できないデータが「処理の流れ」を変えられない構造にする

Defeating Prompt Injections by Design（Edoardo Debenedetti ほか、2025年3月投稿・2025年6月改訂、arXiv:2503.18813）は、査読前の論文（プレプリント）です。

評価は AgentDojo の模擬環境で、o3、Claude 4 Sonnet、Gemini 2.5 Pro など各社のモデルを使っています。

「LLMが騙されても被害が出ない」構造を目指した「CaMeL」で、NCSC のブログでも設計で防ぐ主要な研究として紹介されています。利用者の依頼から先に処理の手順とデータの流れを組み立て、外部のデータは中身の読み取りにしか使わせません。さらにデータごとに「どこへ渡してよいか」を表す権限情報（ケイパビリティ）を付け、ツールを呼ぶ直前にルールと照合して持ち出しを止めます。o3 を使った場合、普通にツールを呼ばせる方式の84%に対してタスクの77%を解きましたが、この差はモデルによって3ポイント程度から30ポイント以上まで開きます。著者ら自身も、ルールを保守する手間や、データの流れに関わらない攻撃は対象外であることを挙げ、「完全に解決したわけではない」と明言しています。

運営者にとっての意味は、「どのデータをどのツールに渡してよいか」をLLMの外で決めておけば、モデルが騙されても重大な操作を止められるということです。下がる成功率が許容できるかは、使うモデルで確かめます。

📄 論文: ツールの「説明文」が他のツールの使い方をねじ曲げる

Think Twice Before You Act: Protecting LLM Agents Against Tool Description Poisoning via Isolated Planning（Shanghao Shi ほか、2026年6月、arXiv:2606.20922）は、ICML 2026 採録（abs のコメント欄の記載）です。

評価は AgentDojo と、10種類の業務場面を模した ASB という2つのベンチマーク上で、GPT-4o などのAPIのモデルを使って行ったものです。

ツールの説明文（何ができるかを書いたメタデータ）は、エージェントが計画を立てるたびに読み込まれます。あまり使われないツールの説明文を書き換えるだけで、送金など別の重要なツールを呼ばせる脅威で、書き換えられたツール自体が選ばれなくても成立します。既存の対策5種では、一部は攻撃を減らすものの成功率は高いまま残りました。提案手法「Tool-Guard」は、呼び出しが依頼内容とかみ合わないと判定されたツールを「影響を受けた可能性があるもの」の一覧に移し、その一覧と残りのツールとで計画を別々に立てさせます。移されたツールは悪者扱いではなく、引き続き使えます。AgentDojo で GPT-4o を使うと、攻撃成功率は防御なしの約43%から約2%に下がり、ASB でも低い水準に抑えられました。

運営者にとっての意味は、つないだツールの説明文も「信頼できない入力」として扱う必要がある、ということです。

現場でやること

まず「何を読ませて、何をさせているか」を一覧にする

エージェントごとに、読み込む外部の内容と、使えるツールや権限を書き出します。外部の内容を読む処理と、送信・削除・支払いのような重要な操作が同じエージェントにあれば、最初に見直す対象です。

権限は「機能・権限・自律性」の3つで絞る

• 業務に要らないツールはつながない（機能）
• 読み取りだけでよいなら書き込み権限を渡さない（権限）
• 送信・削除・外部への共有など取り消しにくい操作の前に、人の承認を挟む（自律性）

外部の内容は「指示と分けて」渡し、検知は網として使う

外部の内容は出どころを明示してツールの結果として渡し、性能の高いモデルによる事前の判定を1枚目の網として入れます。ただし、どちらも防げることを保証するものではないので、前の項目の権限の絞り込みと必ず組み合わせます。コード生成エージェントのように、リポジトリの中身を読んで書き込む使い方なら、コード生成エージェント×論文4選で扱ったレビュー体制も合わせて考えます。

ログを残し、追加するツールを審査する

LLMの入出力とツールの呼び出しを記録しておけば、攻撃者が試行錯誤している段階で気づける可能性があります（NCSC）。新しいツールの説明文に他のツールの使い方を指図する記述がないかを確認し、出どころの分からないツールは重要な操作のあるエージェントと一緒にしないようにします。

エージェントに権限を渡すための鍵は次の3点です

1. 検知は「確率を下げる網」と割り切る
   既製のLLMによる検知は手軽で効果も高い一方、仕組みを知った攻撃者に崩される方式もあります。検知だけに頼らない構成にします。
2. 権限とデータの流れを「LLMの外」で縛る
   最小権限、取り消しにくい操作の前の承認、データを渡してよい先のルールを、モデルの判断に任せずに決めておきます。下がる成功率が許容できるかも確かめます。
3. ツールの説明文も「信頼できない入力」として扱う
   つなぐツールを審査し、ツール同士の影響を切り分けられるようにしておきます。

まとめ：エージェントの安全は「見抜く」だけでなく「騙されても壊れない」設計で！

プロンプトインジェクションは、LLMがデータと指示を区別できないことから生まれる問題で、公的機関も各社も「完全には防げない」という立場です。だからこそ2026年現在は、検知で攻撃の可能性を下げる対策と、騙されても被害が出ないように権限と処理の流れを設計する対策を、組み合わせる考え方が重視されています。

まずは自社のエージェントが「何を読み、何をしているか」を一覧にしてみてください。外部の内容を読む処理と重要な操作が同じ場所にあれば、そこが最初に手を入れるところです！

参考文献

• OWASP「LLM01:2025 Prompt Injection」（https://genai.owasp.org/llmrisk/llm01-prompt-injection/）2026-10-01 確認
• OWASP「LLM06:2025 Excessive Agency」（https://genai.owasp.org/llmrisk/llm062025-excessive-agency/）2026-10-01 確認
• 英国 NCSC「Prompt injection is not SQL injection (it may be worse)」（https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection）2026-10-01 確認
• Microsoft Security Response Center「How Microsoft defends against indirect prompt injection attacks」（https://www.microsoft.com/en-us/msrc/blog/2025/07/how-microsoft-defends-against-indirect-prompt-injection-attacks）2026-10-01 確認
• Anthropic「Mitigate jailbreaks and prompt injections」（https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/mitigate-jailbreaks）2026-10-01 確認
• OpenAI「Safety in building agents」（https://developers.openai.com/api/docs/guides/agent-builder-safety）2026-10-01 確認
• Tianneng Shi ほか「PromptArmor: Simple yet Effective Prompt Injection Defenses」arXiv:2507.15219（https://arxiv.org/abs/2507.15219）2026-10-01 確認
• Sarthak Choudhary ほか「How Not to Detect Prompt Injections with an LLM」arXiv:2507.05630（https://arxiv.org/abs/2507.05630）2026-10-01 確認
• Edoardo Debenedetti ほか「Defeating Prompt Injections by Design」arXiv:2503.18813（https://arxiv.org/abs/2503.18813）2026-10-01 確認
• Shanghao Shi ほか「Think Twice Before You Act: Protecting LLM Agents Against Tool Description Poisoning via Isolated Planning」arXiv:2606.20922（https://arxiv.org/abs/2606.20922）2026-10-01 確認

2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、既知回答検知を破る攻撃の成功率、CaMeLのタスク成功率の比較、Tool-Guardが隔離するツールの記述の誤りを修正しました

The post 【2026年最新】LLMエージェントのセキュリティ×論文4選｜「プロンプトインジェクションが怖くて権限を渡せない」を解く first appeared on クエビコ.

しかし、実際にチームへ導入すると「AIが出すPRのレビューに人間の時間が取られる」「テストが十分なのか分からない」「ベンチマークのスコアほど実務で役に立たない」といった悩みに直面します。この記事では、各社の公式ドキュメントと OWASP・OpenSSF の公開資料をもとに、コード生成エージェントの仕組みと、その中でレビューとテストがどこに置かれているかを整理します。そのうえで、レビュー・テスト・評価の3つの観点から論文4本を紹介します。結論を先に言うと、「完成の定義」をテストとして人が先に決め、PRは変更行が本当にテストされているかで確かめ、AIレビューは自分たちの規約に沿わせるのが基本です！

コード生成エージェントとは何か：Issue から PR までを自走する

隔離された環境で「読む・直す・試す」を繰り返す

コード生成エージェントは、指示を受けると自分でリポジトリを調べ、複数のファイルを書き換え、テストなどのコマンドを実行して結果を確かめます。各社の公式ドキュメントでは、次のように説明されています。

• GitHub Copilot cloud agent: GitHub Actions を使った一時的な開発環境の中でコードを調べ、変更し、自動テストやリンターを実行して、ブランチ上の変更からPRを作ります。IDEの中で動く「エージェントモード」とは別の機能だと明記されています（GitHub「About GitHub Copilot cloud agent」）
• Claude Code: コードベースを読み、ファイルを編集し、コマンドを実行するツールで、ブランチの作成からPRの作成までgitの操作も行えます。プロジェクトに置いた設定ファイル（CLAUDE.md）に、コーディング規約やレビューのチェックリストを書いておけます（Anthropic「Claude Code overview」）
• Codex（クラウド）: タスクごとに独立した作業環境を用意し、利用者は変更とテスト結果を確かめてからコミットやPRの作成に進みます（OpenAI「Codex Cloud」）

どの製品も「エージェントが作業し、人が確かめて取り込む」分担が前提です。

歯止めは「人のレビュー」と「権限の絞り込み」

GitHub のドキュメントでは、Copilot cloud agent が作ったPRは人がレビューしてマージする必要があり、エージェント自身はPRを承認もマージもできないと説明しています。さらに、エージェントが書き込めるのは専用のブランチだけで、作業を頼んだ本人はそのPRを承認できません。CIのワークフローも、既定では書き込み権限のある人が承認するまで動きません（GitHub「Risks and mitigations」）。

Claude Code も、手動で承認するモードでは読み取り専用の権限から始まり、ファイルの編集やテストの実行の前に利用者へ確認します。承認前にコードとコマンドを確かめる責任は利用者にある、とも書かれています（Anthropic「Security」）。エージェントに渡す権限の話は、LLMエージェントのセキュリティの記事で詳しく扱っています。

レビューとテストは「省略できない工程」

OWASP は「AIが生成したコードへの不適切な信頼」を挙げた

OWASP Top 10 の2025年版は、本体の10項目とは別の「Next Steps」で、選外ながら取り組む価値がある問題を3つ挙げており、その X03 が「AIが生成したコードへの不適切な信頼（いわゆるバイブコーディング）」です。AIが生成したコードは人が書いたコードより脆弱性を含みやすいことがよく知られているとしたうえで、提出するコードはAIが書いたものでもすべて読んで理解し、責任を持つこと、AIの助けを借りたコードはできれば自分の目と静的解析などのツールの両方で徹底的にレビューすることを勧めています（OWASP「Top 10:2025 Next Steps」）。

OpenSSF は「レビューとテストの代わりにはならない」と明記

オープンソースのセキュリティに取り組む OpenSSF も、AIのコーディング支援向けのガイドで、AIが生成したコードはコードレビュー、テスト、静的解析といった工程を飛ばす近道ではないと述べています。AIはエラー処理を無視するなどの問題を持ち込むことがあるとして、AIへの指示ファイルに「重要な関数には、失敗すべきときに安全に失敗することを確かめるテストも作る」といった内容を書くことを勧めています（OpenSSF「Security-Focused Guide for AI Code Assistant Instructions」）。

つまり、エージェントを入れてもレビューとテストは人の仕事として残ります。ここからは、それをどう回すかに取り組んだ論文を見ていきます。

研究で見る「レビュー」と「テスト」の回し方

📄 論文: チームの規約に沿わせると、AIレビューの指摘が採用されやすくなる

SGCR: A Specification-Grounded Framework for Trustworthy LLM Code Review（Kai Wang ほか、2025年12月投稿・2026年1月改訂、arXiv:2512.17540）は、ASE 2025 採録（abs のコメント欄の記載）です。

対象は、HiThink Research 社の本番の Java 開発プロジェクトです。経験のある開発者が業務に合わせて書いた140個のルールを用意し、自社で動かした32Bパラメータの言語モデルでレビューを行い、200人の参加者の開発の中で比べました。比較の相手は、同じモデルにルールを渡さずレビューさせた場合です。

LLMのレビューには、一般論的な指摘や業務の文脈に合わない指摘が混ざりがちです。この論文の仕組みは、規約から導いたルールをモデルに渡して確実に当てはめる経路と、モデルが自由に問題を探したあとで関連するルールを検索して本当に問題かを検証する経路を組み合わせます。指摘が最終的なコミットに反映された割合（採用率）は、ルールなしの22%に対して42%に上がりました。

現場にとっての意味は、少なくともこの環境では、同じモデルでも自分たちの規約を言葉にして渡すだけで指摘が採用されやすくなった、ということです。他の環境での効果は自分たちで確かめます。ルール集を保守する手間は課題として挙がっています。

📄 論文: 人がテストを書き、AIがそれを通す分業

TDFlow: Agentic Workflows for Test Driven Development（Kevin Han ほか、2025年10月投稿・2026年1月改訂、arXiv:2510.23761）は、EACL 2026 採録（abs のコメント欄の記載）です。

対象は、Django などの Python のオープンソースから集めた公開ベンチマーク SWE-Bench の問題です。通常は隠されている「人が書いた正解判定用のテスト」をあえてシステムに渡し、そのテストを通せるかを測りました。修正案の作成・デバッグ・修正案の手直しを別々のサブエージェントに分け（テストがなければテスト作成も別のサブエージェントが担当）、1つのエージェントが長い文脈を抱え込まないようにしたのが特徴です。

修正側に GPT-5 を使い、検証済みの500問（SWE-Bench Verified）で試した結果、人が書いたテストを渡すと94.3%の問題を解けた一方、テストもAIが自分で作る設定では68.0%にとどまりました。人が書いたテストを渡した実行（2つのベンチマークで計800件）を人手で調べたところ、テストを通すためだけの不正な修正が7件見つかり、これらは失敗として数えています。著者らは、自動修正の最大の壁は「バグを正しく再現するテストを書くこと」だと結論づけています。

現場にとっての意味は、何ができたら完成かをテストとして人が先に書けば、エージェントが成果を出しやすくなるということです。ただし、テストが間違っていても後から直す仕組みはないと著者ら自身が述べており、テストの正しさは人が担保する必要があります。

研究で見る「テストの薄さ」と「スコアの当てにならなさ」

📄 論文: AIが出したPRは、どこまでテストされているか

Test Coverage Analysis of Agentic Pull Requests（Atish Kumar Dipongkor ほか、2026年7月、arXiv:2607.18057）は、ICSME 2026 掲載予定（abs のコメント欄の記載）です。

対象は、5種類のコード生成エージェントが GitHub 上の実際のリポジトリに出したPRを集めた公開データセットのうち、Java 532件と Python 4,350件です。テストの変更を含むかはこの全件で調べ、網羅率（カバレッジ）は、マージ済みでビルドと計測ができた Java 213件・Python 1,664件のPRについて、研究者がリポジトリのテストを実行して測りました。

本体のコードを変えたPRのうち、テストも変更していたのは49.6%で、約半数はテストに手を付けていませんでした。既存のテストで実行された変更行の割合は、Java で61.5%、Python では27.0%にとどまり、Python では64.8%のPRで変更行が1行も既存のテストで実行されていませんでした。エージェント自身が書いたテストで網羅率が上がったPRも少数派です。また、try や catch のブロックなどのエラー処理は、両方の言語で共通して8割以上の行がテストで実行されていませんでした。

現場にとっての意味は、「CIが通った」は「変更がテストされた」と同じではない、ということです。OWASP Top 10:2025 でも「例外的な状況の不適切な処理」が10項目の1つに入っており（OWASP「Top 10:2025」）、エラー処理はレビューで重点的に見たい箇所です。

📄 論文: ベンチマークの高いスコアには「暗記」が混ざっている可能性

The SWE-Bench Illusion: When State-of-the-Art LLMs Remember Instead of Reason（Shanchao Liang ほか、2025年6月投稿・2025年12月改訂、arXiv:2506.12286）は、査読前の論文（プレプリント）です。

対象は、OpenAI と Anthropic の10個のモデルで、各社のAPIを既定の設定で使いました。SWE-Bench Verified（12個の Python リポジトリから集めた500問）と、SWE-Bench に含まれない有名な7つのリポジトリから作った245問などを比べています。課題は、リポジトリの中身を見せずに Issue の文章だけからバグのあるファイルを当てるなど、「本来は解けないはずの」診断用の問題です。

ファイルを当てる課題では、正答率が SWE-Bench Verified で最大76%だったのに対し、SWE-Bench に含まれない7つのリポジトリの課題では最大53%にとどまりました。関数を書かせる課題でも、正解のコードと5トークン連続で一致する割合が SWE-Bench Verified で最大約35%と、同じリポジトリの新しい Issue や他のベンチマークの最大約18%より高くなりました。著者らは、学習データにベンチマークの問題や正解が含まれていた可能性を指摘しています。

現場にとっての意味は、公開ベンチマークのスコアは自社のコードでの実力をそのまま表すとは限らない、ということです。製品は自社のリポジトリで試して選びます。

現場でやること

「完成の定義」をテストとして先に書く

エージェントに任せる前に、何ができたら完了かを人がテストとして用意します。バグ修正なら、まずそのバグを再現するテストを書きます。テストはエージェントが書き換えられないように守りましょう。

PRは「CIが緑」ではなく「変更行が実行されたか」で見る

• PRの差分ごとに、変更行がテストで実行されたかをカバレッジで確かめる
• エージェントが追加したテストが変更行を実行しているかを見る
• エラー処理の分岐は、失敗すべきときに安全に失敗するかをレビューで重点的に確かめる

AIレビューには自分たちの規約を渡す

コーディング規約やレビューの観点を短いルールにまとめ、エージェントやAIレビューの指示ファイルに書きます。規約を外部の資料と照らし合わせて使いたい場合は、RAG の記事も参考になります。ルールは採用されなかった指摘を見直しながら少しずつ増やします。

製品選びは自社のリポジトリで試す

公開ベンチマークのスコアは参考程度にとどめます。過去に人が直した自社のバグを修正前の状態から各製品に解かせ、正しく直せたか、テストを付けたか、レビューの手間を比べます。

コード生成エージェント導入の鍵は次の3点です

1. 「完成の定義」をテストとして人が先に書く
   通すべきテストがあれば、エージェントが成果を出しやすくなります。バグ修正では再現テストを最初に用意し、テストの正しさは人が担保します。
2. PRは「変更行がテストされているか」で確かめる
   差分のカバレッジを確認し、エラー処理のような手薄になりやすい箇所を重点的にレビューします。
3. AIレビューは規約に沿わせ、製品選びは自社のコードで測る
   論文の環境では、規約に基づく指摘のほうが採用されやすくなりました。公開ベンチマークのスコアは参考にとどめ、自分たちのリポジトリで試して判断します。

まとめ：コード生成エージェントは「書かせる」から「検証の仕組みごと設計する」へ！

コード生成エージェントは、隔離された環境でリポジトリを読み、コードを直し、テストを走らせてPRを出すところまで来ました。一方で、各社の仕組みも OWASP や OpenSSF の資料も、最後に確かめて責任を持つのは人だという前提に立っています。論文からは、テストを人が先に決める、変更行のカバレッジを見る、規約に沿ってレビューさせる、という具体的な手がかりが見えてきました。

まずは直近のAIのPRを数件選び、変更行が既存のテストで実行されているかを確かめてみてください。どこから手を付けるべきかが見えてきます！

参考文献

• GitHub「About GitHub Copilot cloud agent」（https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent）2026-10-01 確認
• GitHub「Risks and mitigations」（https://docs.github.com/en/copilot/concepts/security-governance-and-network-settings/risks-and-mitigations）2026-10-01 確認
• Anthropic「Claude Code overview」（https://code.claude.com/docs/en/overview）2026-10-01 確認
• Anthropic「Security」（https://code.claude.com/docs/en/security）2026-10-01 確認
• OpenAI「Codex Cloud」（https://learn.chatgpt.com/docs/cloud）2026-10-01 確認
• OWASP「OWASP Top 10:2025」（https://owasp.org/Top10/2025/）2026-10-01 確認
• OWASP「Top 10:2025 Next Steps」（https://owasp.org/Top10/2025/X01_2025-Next_Steps/）2026-10-01 確認
• OpenSSF「Security-Focused Guide for AI Code Assistant Instructions」（https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions）2026-10-01 確認
• Kai Wang ほか「SGCR: A Specification-Grounded Framework for Trustworthy LLM Code Review」arXiv:2512.17540（https://arxiv.org/abs/2512.17540）2026-10-01 確認
• Kevin Han ほか「TDFlow: Agentic Workflows for Test Driven Development」arXiv:2510.23761（https://arxiv.org/abs/2510.23761）2026-10-01 確認
• Atish Kumar Dipongkor ほか「Test Coverage Analysis of Agentic Pull Requests」arXiv:2607.18057（https://arxiv.org/abs/2607.18057）2026-10-01 確認
• Shanchao Liang ほか「The SWE-Bench Illusion: When State-of-the-Art LLMs Remember Instead of Reason」arXiv:2506.12286（https://arxiv.org/abs/2506.12286）2026-10-01 確認

2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、GitHub Copilot のPRを作る機能の名称、ベンチマークの暗記を調べた論文の一致率の単位と比較対象、テストの網羅率を調べた論文のエラー処理の記述の誤りを修正しました

The post 【2026年最新】コード生成エージェント×論文4選｜「レビューが追いつかない」「テストが薄い」を解く最前線 first appeared on クエビコ.