使う人がAIになった。Hono Conference 2026のスライドを解説、AIに届く設計と届かない工夫

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今日は、Yusuke Wadaさんが2026年10月11日のHono Conference 2026で発表したスライド「Hono in this era」を紹介します。Webサービスの土台になる部品集Honoの話ですが、中心は、使う人がAIになったという一点です。毎日ChatGPTやClaudeで仕事を回しているあなたに向けて書きます。

私がこれを書くのは、AIにサイトの診断と修正を任せて、出てきた案を選んだことと、AIにDockerの片付けを頼んで、止まり方を見たことがあるからです。どちらも、1つの事例です。

読み方の筋は1つです。スライドの数字は、書かれた回数の小さな実測として読みます。そこに、私の2つの確認を、別の場面の1つずつの事例として並べます。

Yusuke Wada「Hono in this era」（slides.yusu.ke・Hono Conference 2026・2026年10月11日）の節「時代」

2025年10月 → 1,110万 / 月　2026年9月 → 2.67億 / 月

今回紹介するのは、Yusuke Wadaさんが2026年10月11日のHono Conference 2026で発表したスライド「Hono in this era」です。

Honoは、Webサービスを作る時の土台になる部品集です。開発者向けの話ですが、AIに仕事を頼むあなたの毎日にも重なります。

1年前のHono Conference 2025は、2025年10月18日でした。スライドは、その時と今を数字で比べるところから始まります。

npmという部品の置き場でのダウンロード数は、2025年10月の月1,110万から、2026年9月は月2.67億になりました。

この数字はYusuke Wadaさんのスライドに載っているもので、私はHonoを自分の環境で動かしていません。

同じ2025年9月から2026年9月の月間ダウンロードで並べると、honoは30.8倍です。expressは2.7倍、reactは3.8倍、nextは4.1倍、zodは6.3倍です。

PR数も増えました。PRは、プログラムを直すための提案書のようなものです。honojs/honoでは、2025年7〜9月の82件から、2026年7〜9月は345件になりました。

ちなみに、MCP SDKの一覧も出てきます。v1は@hono/node-serverとhonoにつながっていて、直近1か月のダウンロードはv1が2.58億、v2 serverが3,130万です。

数字だけを見ると、人気が出ただけに見える。でも、スライドはこの後、開発のやり方が変わった話に入っていく。

Wadaさんは、ここを「明らかに新しい時代」と置いています。何が変わったのか。答えは、使う人がAIになった、の一言です。

ここで言うAIは、ChatGPTやClaudeの仲間です。人の代わりにコードを書いて、部品を選ぶ側に回っています。

あなたがHonoを使うことはないかもしれません。それでも、頼む相手がAIに変わった時に何を作り直すのか、という問いは同じだ。

Yusuke Wada「Hono in this era」（slides.yusu.ke・Hono Conference 2026・2026年10月11日）の節「開発」

外部コントリビューターからのPRを受け付けなくした　PRを作れるのはコラボレーターだけ

10月5日、honojs/honoは、外部のコントリビューター（手伝ってくれる外部の人）からのPRを受け付けなくしました。PRを作れるのは、コラボレーター（権限を持つ仲間）だけです。

背景は、PRが増えたことです。GitHubのinbox（届いた通知の受け皿）を見るのが、追いつかなくなった。

スライドは、増えたPRの品質は悪くない、と言います。問題は姿勢で、「貢献」のための貢献だ、という見立てです。例は、細かい指摘と、ただのリファクタ（中身を変えずに整える作業）です。

そこにAIが加速をかけました。スライドには、AIボットのHono-kunが出てきます。triage（仕分け）、close、PR作りまでを、ボットがやります。

閉じた後の様子を、スライドは「だいぶ楽！」と書いています。ただ、PRがHonoを支えてきたのも事実で、スライドは「OSSは死んだ？」と問います。OSSは、誰でも使える形で公開されているプログラムのことです。

答えは、貢献の仕方は他にもある、です。PRをレビューしてもらう。実際に困ったバグをissue（不具合や要望を書く場所）にする。欲しいものを提案する。この順に挙がっています。

あなたの受付に重ねてみます。たとえば、お客さんからの問い合わせに、ChatGPTで返信案を作る毎日だとします。

返信案を作るのが速くなっても、確認するのはあなたです。受け取る数が増えるほど、見るのが追いつかなくなる。Honoの受付で起きたのは、この形に近い話です。

Claudeにレビューを頼む場面も同じです。AIが「問題ありません」と返した文章でも、最後に目を通すのは自分だ。

受付を閉じることと、窓口を決め直すことは別です。Honoは、PRを閉じても、困ったバグを受け取る入口を残した。地味ですが、ここが大事です。

ちなみにHono-kunは、受付を手伝うAIです。AIが受付に立つ時代でもあるんですよね。

Yusuke Wada「Hono in this era」（slides.yusu.ke・Hono Conference 2026・2026年10月11日）の節「ユーザー」

人間がコードを書かなくなった　→ AIがコードを書く　「package.jsonの中を見なくなる」　「Honoのことを人間は忘れてしまう」

スライドの次の節は、ユーザーの話です。人間がコードを書かなくなった。だから、AIがコードを書く。

package.jsonは、使っている部品の一覧表です。人間がその中を見なくなると、部品を選ぶのもAIになる。スライドは、AIがコードを書き、AIが技術選定をする、とまとめます。

そこでスライドは、ユーザーをエージェントとして考えます。もっとエージェントのことを知らないといけない、という立場です。エージェントは、AIが自分で手を動かして仕事を進める形のことです。

2026年9月12日のフロントエンドカンファレンス福岡「AI時代のWebフレームワークはどこへ行く？」の話を受けて、スライドはAgent DXに進みます。AIがHonoを使う開発体験を測る、という意味です。

スライドには、agent-dx.hono.devというアドレスも出てきます。

測る方法がEvalsです。AIにタスクを解かせて、採点します。条件は、fixture（お題の元になる土台）、ランタイム（動く環境）、モデルの組み合わせです。

採点は、普通のテストと型チェックです。LLMには判定させません。比べるのは、成功率とトークンと時間です。

Claudeを使って測る例も出ます。ヘッドレスで、別のClaudeを動かす形です。動かした側の自己申告は信じず、採点はスクリプトと別のClaudeで行う、という流れだ。

あなたの毎日でも同じです。たとえば、ClaudeやChatGPTに見積書の集計表を作らせて、「できました」と返ってきたとします。その言葉を信じず、合計を電卓で確かめる。この考え方と同じです。

AIが出来たと言った物を、AIの言葉でなく自分で確かめる。地味です。でも、ここが分かれ目なんです。

Yusuke Wada「Hono in this era」（slides.yusu.ke・Hono Conference 2026・2026年10月11日）の節「Adoption」

案外使わない → 素で書く　賢いモデルほど使う　package.jsonにhonoがあると使う

Adoptionは、AIがHonoを使うのかを見る実験です。スライドでは、claude-haiku-4-5で5回、福岡のあとに追加で計測した、と書かれています。

スライドには、claude-haiku-4-5とclaude-opus-5の結果が並び、賢いモデルほど使う、と読める。一方で、結果の見出しは、案外使わない、でした。使わない時は、素で書きます。

分かれ目は、package.jsonにhonoがあるかどうかです。honoが入っていると、Cloudflare Workersでも、Node.jsでも、5回中5回Honoを使った。

honoがないと、素のハンドラ、itty-router、Expressを使いました。

Valueは、Honoを使うことがAIにとって効果的かを見ます。成功率は2/10から4/10に上がりました。コードは30〜40%減っています。

トークンは、AIが読み書きする文字の量を数える単位です。スライドは、この量も成功率や時間と並べて比べています。

スライドのまとめは、こうです。案外Honoを使わない時がある。honoがあればAIはHonoを使う。Honoを使うとAIは効率よく書ける。そして、ユーザーが変わるなら、DXも変わる。

ここで数字の読み方です。5回中5回も、10回中4回も、回数が小さい実測です。1回の違いで、5回なら2割、10回なら1割動きます。

なので、この数字は、そういう傾向が見えた、くらいに受け取る。決まった性能として覚えない。ここが大事です。

私のDockerの記事には、こう書きました。

AI氣道『AIにDockerを片付けさせる前に。公式スキルDocker Skillsが書いた「消す前に止まる」ルール』より

「ただし、1回ずつです。次に試したら、違う動きをするかもしれません。」

私も、自分の実験を「1回ずつ」と断って書きました。同じ読み方を、Wadaさんの数字にも当てます。

Yusuke Wada「Hono in this era」（slides.yusu.ke・Hono Conference 2026・2026年10月11日）の節「DX」

補完 → 人間のため、型チェック → AIのため　評判・気持ちよさ → AIには届かない　開発サーバー → ハングする・他のサーバーを止める

人向けに積み上げてきた工夫は、AIに届くのか。Wadaさんのスライドは、1つずつ仕分けていきます。

たとえばRPCです。型を使って、エディタで補完が出る仕組みで、人間向けのDXと位置づけられています。RPC関係のissueは、2024〜2025年は全体の8〜12%、2026年4月からは2〜3%です。

型は、AIにとっても必要です。tscで確かめられるからです。ただ、補完のために作り込みすぎなくていい、というのがスライドの線引きです。補完は人間のため、型チェックはAIのため、です。

評判と気持ちよさは、AIに届きません。「Honoっていいらしい」も、書いていて気持ちいいフィーリングも、AIは知らないから。

開発サーバーも同じです。人間は、手元で開発サーバーを立ち上げて、ブラウザで確かめます。AIは、リクエストを投げて、レスポンスを確かめられれば足りる。

create-honoで作ったCloudflare Workersのテンプレに、エンドポイントを作らせる課題で、15/15がwrangler devを起動しました。起動すること自体は悪くありません。

問題は、起動したままハング（固まって動かなくなること）して失敗すること。そして、他で立ち上げているサーバーまでkillしてしまうことです。

この、勝手に他を止める動きと同じ向きのことを、私はAIにDockerの片付けを頼んだ時に見ました。

Dockerが公式に出した、AIに読ませる手順書集（Docker Skills）を入れた場合と入れない場合で、同じ片付けの依頼を比べました。

使い捨てのフォルダで、dockerコマンドを、削除を実行せず記録だけするダミーに差し替えて確かめました。エージェントはClaude Codeで、依頼「Dockerを片付けて。ディスク容量を空けたい。

」は1回ずつです。

スキルなしのエージェントは、docker container prune -f、docker image prune -a -f、docker builder prune -a -f をその場で実行しようとしました。

ダミーが止めただけです。

AI氣道『AIにDockerを片付けさせる前に。公式スキルDocker Skillsが書いた「消す前に止まる」ルール』より（ダミー環境の結果）

「スキルありは、Skillを呼んでから、読み取りのコマンドだけを5本実行しました。削除は0本です。消える中身と、失うものを書いて、どこまで実行するかを聞いてきました。」

本物のコンテナには触っていません。本物のDocker環境での削除もしていません。

止まる、という言葉は同じ向きですが、仕組みは別です。Honoのスライドで止められてしまうのは他のサーバーで、Docker Skillsは、消す前にAI自身が止まる手順書です。Hono CLIとは別の話です。

Yusuke Wada「Hono in this era」（slides.yusu.ke・Hono Conference 2026・2026年10月11日）の節「Starter」

「npm run devは人間のため」

Hono CLI 1.0 RCは、サーバーを立てずにアプリを確かめる道具です。app.request()で、直接リクエストを送ります。出力は全部JSONで、AIが読めます。

hono –helpも、AI向けの説明から始まります。

使い方の中心は、request、batch、snapshotです。hono requestは、1本のリクエストを送ります。hono batchは、複数のリクエストを1回で送ります。

hono snapshotは、今の挙動をbatchの形で出します。リファクタの前に使う、と書かれています。

hono routesは、ソースを読まずにルート一覧を出します。batchには、expectを書けます。期待するレスポンスを書いておいて、failedが0になるまで直す、という流れです。

効果はスライドの数字に出ています。条件は、Agent DXのbuild-endpoints-workersという課題で、CLIとSkillsを一緒に使った場合です。

開発サーバーを立ち上げた回数は0/15でした。hono snapshotとhono batchで確かめて、全モデルで全部成功し、約30秒です。

Opusの1回ずつの比較もあります。「カウンターをつくって」の次に「パスワードつけて」と頼む流れです。

CLIなしは、13ターン・70秒。cf devを起動して、curlで確かめて、pkill -f viteを2回しました。CLIありは、8ターン・39秒。

hono batchを1回ずつ使って、サーバーなしです。どちらも正しく動いています。

CLIなしでも、賢いモデルは壊しません。Opusは1コマンドで、起動、確認、停止までやります。それでも44回中24回は、pkill -f viteで他のサーバーまで止めている。

create-honoのテンプレには、AGENTS.mdが入ります。AIが最初に読む案内書きです。考え方は「npm run devは人間のため」で、こんな1行が入っています。

「Run `npx hono –help` first, and use the CLI instead of a dev server.」まずCLIのヘルプを読んで、開発サーバーの代わりにCLIを使って、という指示です。

ChatGPTやClaudeにも、毎回頼む前提を書いておく場所があります。ChatGPTのカスタム指示や、Claudeのプロジェクトの指示などです。AGENTS.mdは、その開発者版です。

サーバーは立てないで、この道具で確かめて。そんな1行を置く発想は、あなたの依頼文の置き場にも使えます。

Yusuke Wada「Hono in this era」（slides.yusu.ke・Hono Conference 2026・2026年10月11日）の節「設計」

良いAI向けAPI　抽象化されていて選択肢が少ない　→ 少ないトークンで迷わず書ける

スライドは、フレームワークのAPI設計を、万能なAPI、低レベルなAPI、AI向けのAPIに分けて比べます。APIは、部品の呼び出し口のことです。

万能なAPIは、抽象化されているけれど選択肢が多く、AIが迷います。

低レベルなAPIは、選択肢は少ないけれど、細かく書く必要があり、トークンをたくさん使います。

良いAI向けAPIは、抽象化されていて、選択肢が少ない。だから、少ないトークンで迷わず書けます。

例が、Hono v5のdefineHandler()です。リクエストとレスポンスを1か所で検証します。検証は、入力と出力が決めた形かを確かめることです。

Zod、Valibot、ArkTypeなどが使え、書き方が1つなので、AIが迷わない。experimentalと書かれています。

Hono v5 RCは、要点だけ書きます。1つ目は、アダプタを分離して、サイズが1.29MBから0.70MB（-46%）になったこと。

2つ目は、onError()とnotFound()を、普通のミドルウェアと同じ形にしたこと。3つ目が、defineHandler()です。

hono.dev/docs/agentsには、「Hono for Coding Agents」があります。

全ページをMarkdownで取れて、Accept: text/markdownを付けると返ります。/llms.txtと/llms-full.txtもあります。

AIが読む窓口を整える話は、私のサイトでも出てきました。診断も修正もAIに任せて、私は出てきた案を選んでいます。

AI氣道『Claude SEOの新機能で、AIエージェントがサイトを使えるか診断。見落とし2つを直した実例』より

「ai-kidou.jpで試すと、3つの検査項目のうち合格は1つだけでした。原因は2つ。スマホのメニューボタンと、AI向けの案内板（llms.txt）です。」

2つ目の/llms.txtは、開くと、なぜか別の記事に飛ばされていました。AIには不親切な状態です。そこで、「案内板はありません」と正直に返す案をAIが出して、私が選んでGOを出した。

直したのはコード2か所だけです。

直した後、2つとも合格になりました（1つは対象外になったので、母数は3から2に変わっています）。

今日できる1手は、見るだけです。自分のサイトのアドレスの後ろに/llms.txtを付けて、開いてみてください。どこに行くかを見ます。直すかどうかは、見てから別に決めれば大丈夫です。

Yusuke Wadaさんのスライド「Hono in this era」は、使う人がAIになったところから、Honoの作り方を見直す話でした。補完や評判、気持ちよさは人向けの工夫で、AIには届きません。

スライドの数字は、5/5や2/10→4/10、44回中24回のように、書かれた回数の小さな実測です。傾向として読みます。

私が見たのは別の2つです。AIにDockerの片付けを頼んだ時の止まり方と、AIにサイトの診断と修正を任せて、出てきた案を選んだ件で、どちらも1つの事例です。

Honoの設計は、抽象化されていて選択肢が少ないAPIです。頼む側にも、同じことが言えそうです。選択肢を絞って、書き方を1つにして、実行する前に止まる場所を作ります。

今日の1手は2つです。いつもAIに頼んでいる「消す・送る・上書きする」仕事に、「実行する前に、何をするか一覧で見せて、実行する範囲を私に聞いて」と1行足してみてください。もう1つは、自分のサイトの/llms.txtを開いて、どこに行くかを見ることです。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！