agent-eval

Agent DX 〜 AI時代にフレームワークHonoは必要か AIがユーザーになりました。我々は人間向けの開発者ではなく、AI向けの開発者体験を考えなくてはいけません。 我々は人間です。雰囲気で「フレームワークは必要ない」「フレームワークは必要」と言っても、AIの意見ではありません。人間の意見です。説得力がありません。我々人間はAIのことをもっと知らなくてはいけません。 そこで、Honoでは「Agent DX」というプロジェクトを立ち上げて、AI向けの開発者体験をちゃんと測りました。以下3つのカンファレンスでAgent DXについて話しました。 AI時代のWebフレームワークはどこへ行く？ - フロントエンドカンファレンス福岡 2026 Hono in this era - Hono Conference 2026 Hono: Web application primitives for the AI era - Cloudflare Connect 2026 今回はそれらを記事化してみます。 Agent DXとは AIエージェントがHonoを使うときの開発者体験 = DXを測って改善するプロジェクトです。リポジトリは以下です。 honojs/agent-dx また、結果を以下のページで公開しています。 agent-dx.hono.dev AI Evalsで測る 測り方には「AI Evals」という手法を使います。AI Evalsは固有名詞ではなく、一般的な名称でNext.jsやAngularといったフレームワークも取り入れています。 Next.js：Next.js Agent Evals 実際の Next.js のタスクをエージェントに解かせて採点している。AGENTS.md の効果も公開している Angular：web-codegen-scorer 生成したコードのビルド成功、実行時エラー、アクセシビリティなどを評価する Vercel：@vercel/agent-eval 評価の基盤。ドキュメントや MCP の有無、モデルの違いを比べられる どのようにやるかというと、エージェントにタスクを解かせて採点します。 エージェントにプロンプトを与える エージェントがサンドボックスでコードを書く 書かれたコードをテスト、もしくは静的解析する（採点する） 成功率・トークン・時間を記録して比べる ポイントは採点です。中身は普通のテストと型チェック、静的解析で、LLMには判定させません。テストはエージェントからは見えないところに置いておきます。 ちなみに、AI Evalsの環境として、Astroチームが作っているAIエージェント向けフレームワークのFlueを使っています。 実験は3つやりました。 Adoption → AIはHonoを使うのか？ Value → Honoは必要か？ Practical → AI向けにHonoを使いやすくするには？ 一つずつ見ていきます。 実験 1. Adoption 〜 AIはHonoを使うのか？ AIがコードを書く時、フレームワーク、とりわけHonoを使うのか？というのをAI Evalsで測ってみました。 まっさらなディレクトリでエージェントにアプリを作らせます。どのフレームワークを使うか指示は出しません。そして、書いたコードを静的解析して、どのフレームワークを使ったかを見ます。 プロンプトは以下のようなものです。 Create a Cloudflare Workers application in TypeScript. It should respond to GET /health with the JSON {"ok":true}. ランタイムを複数用意しました。Cloudflare Workers、Bun、Node.js、Denoの4つです。シナリオは、GET /health だけの最小アプリから、バリデーション付きのTODO APIまで用意しました。モデルはClaude Haiku 4.5とClaude Opus 5を使います。 まずはHaiku 4.5の結果です。 ヒントなしだと、フレームワークを使いません。素のハンドラを書きます。 次に 「フレームワークを使って」と明示的に言うと、ランタイムごとの定番を選びます。Cloudflare WorkersはHono、BunはElysia、Node.jsはExpress、DenoはOakとなります。 次にOpus 5の結果です。 ヒントなしだと、やはりフレームワークを使いません。「フレームワークを使って」と言うと、Node.jsでもHonoを選びます。 分かったことは以下となります。 ヒントなしだと、AIは素のハンドラを書く 賢いモデルほどHonoを選ぶ 面白いですね！ package.json に hono があると さらに別の計測もしました。package.json を置いて、dependencies に hono を入れておきます。 package.json { "dependencies": { "hono": "^4" } } すると、AIはNode.jsでもHonoを使いました！ Cloudflare Workers → 5/5 Hono Node.js → 5/5 Hono つまり、AIは自分からはフレームワークを使わないですが、ヒントがあればHonoを選ぶことが分かります。 実験 2. Value 〜 Honoは必要か？ AIにとってフレームワークは必要か？とりわけHonoは必要なのか？をAI Evalsで測ってみました。 同じタスクを二通りでやらせます。 素の fetch ハンドラで書く Honoで書く タスクは2つ用意しました。 shop API → 商品・カート・チェックアウト。状態を持つ複雑なAPI notes API → ログイン・Bearer認証・CORS・JSONエラー。認証まわり 結果はこちらです。Haiku 4.5で各10回です。 成功率が上がる → shop API で2/10 → 4/10 コードが30〜40%減る トークンが15〜30%減る AIが書いても、フレームワークの恩恵はあることが分かります。正確になる、書く量が減る、少ないトークンで書ける。つまり、AIにもライブラリは要るのです！ 以上、Adoption、Valueの結果は、測るまでは分からなかった・確信を持てなかったことなので、測ることは大事です！ 実験 3. Practical 〜 AI向けにHonoを使いやすくするには？ ここまでで、きっかけがあればAIはHonoを使うこと、そしてHonoを使う効果があることが分かりました。では、AIにとって、さらにHonoを使いやすくするにはどうすればいいか？最後の実験です。 エージェントにタスクを与えて、結果を見ます。そしてHonoの側を変えて、また試します。これをくり返しました。 中でも印象的だったのが、「開発サーバー」についてです。 エージェントが開発サーバーを立ち上げる Honoには、プロジェクトのテンプレートを作る create-hono があります。そのCloudflare Workersのテンプレートをそのまま使い、エンドポイントを追加してもらいました。AGENTS.mdは入れていません。 結果です。Haiku 4.5、Sonnet 5、Opus 5で各5回です。 15/15 が wrangler dev を起動 サーバーを立ち上げたまま、bashごとハングするケースもあった 例えばSonnet 5は成功率20%。5本中4本が600秒ハング 原因は package.json にある dev スクリプトでした。つまり、エージェントは、開発の最中、このdevコマンドを実行し自らハングしてしまっていたのです。 package.json { "scripts": { "dev": "wrangler dev", "deploy": "wrangler deploy --minify" } } Hono CLI これを解決しようと開発してるのがHono CLIです。 honojs/cli Hono CLIは、Honoのアプリを作るのを助けるAIエージェント向けのCLIです。いくつかコマンドがあります。 hono request ではサーバーを立ち上げずに、JavaScriptのRequest/Responseレイヤーで、Honoのアプリにリクエストを送ることができます。 オプションはcurlライクなものです。 GET / hono request / POST /users hono request -X POST -d '{"name":"Momo"}' /users また、複数のリクエストを一度に送って、pass / failを判定する hono batch もあります。 CLIとSkillsを入れると 同じタスクで、Hono CLIとSkillsを使わせました。 15/15、100%開発サーバーを立てない 初手で hono batch 全モデルで成功率100%、約30秒 Sonnet 5の結果です。 Opusに「カウンターをつくって」→「パスワードつけて」と頼んだ例もあります。1回ずつです。 CLIなし → 13ターン・70秒。他の開発サーバーまで止めた CLIあり → 8ターン・39秒。サーバーは立てない どちらも正しく動く つまり、Hono CLIを使うと、次のようになります。 サーバーを立てない → ハングしない、他のサーバーを止めない サーバーを待たない → 速いこともある Hono CLIがツール（hono requestなど）を提供しているので、エージェントが一から作成する必要がない Hono CLIのおかげで、Honoを良くすることができます！ ちなみに、Hono CLI（現在1.0のRC版が出てます）とSkillsは以下で試せます。 npm i -D @hono/cli@next npx skills add honojs/skills 詳しくは以下のページを参考にしてください。 hono.dev 人間向けのDXとAI向けのDX AIが開発サーバーを立てたのには、きっかけがありました。package.jsonの scriptsにあるdevコマンドです。 よく考えると、dev コマンドは人間にとってのDXなのだと思います。打ちやすくて、みんなが知っているショートカット。そして、人間は開発サーバーを立ち上げブラウザでlocalhost:8787等にアクセスし結果を確認します。 一方で、AIに開発サーバーは必要ないかもしれません。リクエストを投げて、レスポンスを確かめられれば十分です。 今回の開発サーバーの件を振り返ると、人間にとってのDXを向上させるものが、AIにとっては裏目に出たと言えます。 つまり、人間向けのDXとAI向けのDXがあるのです！ まとめ Agent DXで分かったことをまとめます。 Adoption → きっかけがあればHonoを使う。package.json にあれば100% Value → AIが書いても、Honoの恩恵はある Practical → package.jsonにあるdevスクリプトでエージェントがハングする。Hono CLIとSkillsで防げる AI時代にフレームワークHonoは必要か？その答えは⋯ AI時代でもHonoはあった方がいい！そして、AI Evalsを使ってAI向けのDXは改善していくことができるのです！