10月16日の Kaigi on Rails 2026 で「真のREST 2026」というタイトルの発表をしました。
内容を詰め込みすぎたため早口になってしまい、特に後半の実験パートがかなり駆け足になってしまいましたが、当日聞いていただいた方はありがとうございました。
詳しい内容についてはスライドや後日公開される予定の動画を見ていただくとして、要旨は、前半はRESTのよくある誤解を解いてRESTの制約と得られるメリットを説明、後半はAIエージェントに同じ Rails アプリを HTML と JSON API の両方で操作させて比べてみた、というものです。結論としては、HTML のほうが JSON API より変化に強かった。ただし、往復の数やトークンでは HTML のほうが劣ります。 実験に使ったアプリ、エージェント、全実行の記録と集計は github.com/tkawa/true-rest-2026 で公開しているので、興味のある方は手元で試してみてください。
この記事では、なぜこの発表をしようと思ったのかという経緯と、これから考えていることを書いておきます。11月6日の事後勉強会の LT で話した内容がもとになっています。
経緯
最初のきっかけは、2013年に出た "RESTful Web APIs"（Leonard Richardson, Mike Amundsen & Sam Ruby）という本です。 以前この本の読書会をやっていて、そのために日本語訳をしていました。
この本のテーマは「セマンティックチャレンジ」です。
コンピュータは HTML や JSON の構造（構文）は解析できても、その意味までは理解できない。このギャップをどう埋めるか、という課題です。
たとえば <a href="/messages">Get started</a> というタグはパースできても、「Get started」が何を意味していて、次にそれを押すべきなのかは、プログラムにはわかりません。ブラウザなら人間が画面を見て判断しますが、Web API では人間を介さずにプログラム同士で処理を完結させたい。しかも「投稿本文」のフィールド名が API ごとに text だったり content だったり blogPost だったりすると、クライアントは API ごとに専用のコードを書くことになります。
本では、メディアタイプ、プロファイル（ALPS）、標準の語彙（IANA のリンク関係や schema.org）を使って共有できる制約を増やすことで、このギャップを縮めようとしています。それでも完全に解消するのは難しい挑戦だ、という位置づけでした。
さらに、この本の付録Cにはフィールディング論文のガイドがあって、それを頼りに論文も少し読んでみました。 論文では、Web を成功させた特性として「低い参入障壁」「拡張性」「分散ハイパーメディア」「インターネット規模」の4つが挙げられています。今回の発表で取り上げた拡張性とインターネット規模も、ここから来ています。 興味のある方は、koriymさんによる日本語訳がおすすめです。
この内容をまとめて話したのが、2019年12月の平成Ruby会議01での『真のREST』です。
そして2026年になって、その内容を見直してみたところ、ふと思ったわけです。AIエージェントなら、これができるのではないか？
セマンティックチャレンジで「プログラムにはできない」とされていたのは、意味を理解して、次に押すべきリンクやボタンを選ぶことでした。人間の代わりに AIエージェントに Web アプリを操作させれば、意味の理解もできるし、リンクやボタンを押すこともできるだろう。そこが今回の発表のスタートでした。
ポイントは、ブラウザの画面を操作させるのではなく、HTML を解釈させて操作させることです。エージェントが読むのはレスポンスのテキストだけで、API と同じような使い方をします。こうすると、HTML と JSON API を同じ条件で比べることができます。その結果が冒頭に書いた「HTML のほうが変化に強かった」です。
これから考えていること
次の比較相手は MCP や CLI かなと思っています。 MCP にはツールの更新通知があって（ステートレス化でちょっとあやしいところもありますが…）、認証の面でも優位性があります。HTML とどういう比較ができるかを、いま考えているところです。
ここからは実験したことではなく想像なのですが、「アプリを操作する」という側面で見たとき、人間と AIエージェントは何が違うのか、もう少し深く考えることができます。
人間が GUI を使うときは、単に画面を見ている以上に並列的です。ドロップダウンが開く、スピナーが回る、エラーメッセージが赤く出る、といった変化を同時に認識しながら、必要なところに注意を振り分けている。送信ボタンを押したら画面の下にトーストが出て、上のリストに項目が増えた、という離れた場所の変化も一瞬でまとめて理解できます。SPA やネイティブアプリのリッチな GUI は、部分だけ更新したり、見ていない場所でも状態を変えたりしますが、これは人間のこの並列的な認知を前提にした設計だといえます。
一方、LLM ベースのエージェントの動きは逐次的です。世界とのやりとりは「リクエストを送る → レスポンスを受け取る → 次のリクエストを送る」というターン制で、状態の認識もその時点のスナップショットです。変化が起きていく過程を連続的に追うのは苦手で、これは LLM という仕組みに由来するものなので、当面は変わりそうにありません。
ソフトウェアの進歩という目で見ると、逐次的なやりとりに戻るのは退化のように見えます。でも、エージェントが主要なユーザーになる時代には、逐次性は退化どころか、積極的に追求すべき性質になるかもしれない、と考えています。 （もちろん、並列的に認知するエージェントや非同期のエージェントがこれから大きく進化する可能性もあります）
RESTに興味がある方へ
最後に、RESTに興味がある方に本を2冊紹介しておきます。
- RESTful Web APIs（2013年9月） www.oreilly.com Leonard Richardson, Mike Amundsen & Sam Ruby
- きっかけとなった本。過去のRubyKaigiの発表のきっかけもだいたいこれ。セマンティックチャレンジ、ハイパーメディア、プロファイルについて、初歩から丁寧に説明されています。多少古いですが、本編発表のようなAI観点以前の知識は一通り得られます
- RESTful Web API Patterns & Practices Cookbook（2022年10月） www.oreilly.com Mike Amundsen
- HTTP とハイパーメディアを使って、変化に耐える Web API を作るための実践的なレシピ集です
謝辞
koriymさんには内容をレビューしていただきました。ありがとうございました。そして、たぶんこのタイミングでしかこの話はできなかったと思うので、貴重な機会をくださった Kaigi on Rails 2026 のオーガナイザー・スタッフのみなさん、ありがとうございました。
