HTTPメソッド QUERY とAIエージェント時代の操作分節――「安全で冪等な検索」がもたらす統治可能性
目 次
はじめに................................................................................ 2
前提――TCP/IPモデルにおけるQUERYの位置......................... 2
第1章 QUERYメソッドの輪郭................................................. 3
第2章 検索APIが抱えていた意味論の歪み................................ 3
第3章 安全・冪等・キャッシュ可能を分けて捉える................... 4
第4章 AIエージェント時代における「操作の種別」..................... 5
第5章 承認境界の語彙としてのQUERY.................................... 6
第6章 監査とログにおけるQUERYの効き方............................. 6
第7章 宣言は保証ではない――統治に残る課題......................... 7
第8章 MCPのツール注釈との照応........................................... 8
第9章 実装と導入戦略............................................................. 9
おわりに................................................................................ 10
はじめに
二〇二六年、HTTPに新しいメソッド QUERY が加わった。RFC 10008 として Proposed Standard となったこのメソッドは、GET・POST・PUT・DELETE といった見慣れた語彙の隣に、小さな棚をひとつ増やしただけのようにも見える。実際、機能としては「ボディを持てる、安全で冪等なGET」という一行でほぼ説明が済んでしまう。仕様書を追っても、劇的な新機能が立ち現れるわけではない。
新しいHTTPメソッドが標準に加わること自体、久しぶりの出来事である。この稀少さは、それだけで示唆的だ。HTTPは長寿命の規約であり、そこに語彙がひとつ増えるということは、多くの実装者が「この区別には名前を与えるだけの価値がある」と合意したことを意味する。裏を返せば、QUERYが埋めようとしている隙間は、長年にわたって多くの開発者がその場しのぎでやり過ごしてきた、それだけ普遍的な不便だったということでもある。
本稿の立場は、この地味な標準化こそ、AIエージェントが自律的にAPIを呼び出す時代において想定以上の意味を持つ、というものである。鍵になるのは、操作の意味――これは読み取りなのか、それとも状態変更なのか――が、サーバ内部の実装ではなく、プロトコルの層で外から判定できるようになる点にある。以下ではまず、QUERYが何を解決するのかを整理し、続いてそれがエージェント統治の語彙としてどう効くのか、さらに監査やログとどう接続するのか、そして最後に、どこに限界が残るのかを順に検討していく。
