プロポーザル

Test

わたしはhono/ssgの提案者です。とはいえ色々あって最近のHonoにキャッチアップできておらず、久しぶりにみたところ残課題のplugin機能が実装されていたのだった… このトークは一応SSGを実装した一人が、いちユーザーとしての新鮮な気持ちを持ってhono/ssgをキャッチアップしていくための最新の知識を紹介します。

API開発においては、型定義・バリデーション・仕様書の管理が多くの開発者にとって大きな課題です。
@hono/zod-openapi を利用すると、1つの Zod スキーマから 型・バリデーション・OpenAPI 仕様書 を自動生成でき、この課題をシンプルに解決できます。

私たちが開発した勤怠管理システムでは、平日/休日の勤務パターンや勤怠承認状態の組み合わせなど、複雑な状態管理を型安全に実装する必要がありました。
本LTでは、この要件を @hono/zod-openapi を用いてどのように実現したのか、具体的なコード例を交えてお伝えします。

楽譜にはmusicXMLという標準化されたデータ形式が存在しますが、このファイルは肥大化しやすく、そのままLLMに渡すとコンテキストを圧迫してしまって欲しい結果が得られないことが多いです。そこで、XQueryを用いてmusicXMLを検索し、MCP Serverとして提供する方法を考案します。
hono/mcpを用いて実装し、動作する様子をライブコーディング＆デモ形式でお届けしたいと思います。

このトークでは、フロントエンドフレームワークで採用されることの多いFile-based Routingの概念をバックエンドのREST API開発にも適用し、スケーラブルで管理しやすいAPI設計を実現する方法について紹介します。

Honoの実装の柔軟性は開発者に大きな自由度を与えてくれますが、その自由さゆえにプロジェクトが成長するにつれてルーティングの管理が複雑化しがちです。
いくつかのルーティングパターンを比較しながら、File-based Routingを採用するに至った理由と、その具体的な実装方法について解説します。

File-based Routingで実装される場合1ファイル = 1エンドポイントとなり、ほとんどのファイルで似たような構造を取ります。
そのためファイルが満たすべきルールを明確に定義しやすく、Claude CodeをはじめとするAgent Coding系ツールとの相性も非常に良いです。

近年シェアを拡大しているSvelteKitというフレームワークがあります。 SvelteKitはフロントエンドフレームワークにSvelteを採用しており文法がHTMLに極度に似ているため直書きユーザーにもやさしいフレームワークです。

そしてSvelteKitではアダプターというシステムを採用しています。 そのシステムのおかげで公式のアダプター以外にもユーザー側がアダプターを作る事によって様々なホスティングサービスに対応させることが出来ます。 今回はその特性を活かしてSvelteKit用のHonoアダプターを作りました。
これによってSvelteKitで作ったプロジェクトをHono製のウェブサーバーに組み込むことが出来ます。

話す内容

• serveStaticを自作する
  hono公式のserveStaticは相対パスのみしかサポートしていません。
  無ければ作ればいいじゃないかという事でhono公式のserveStaticをベースに自作しました。

• 公式アダプターの @sveltejs/adapter-node をHonoに置き換える過程
  SvelteKit公式のadapter-honoには元々express.js用のハンドラーが用意されています。 SvelteKitユーザーが使いやすいようにするためにこちらを参考に作成することにしました。
  環境変数でのポート指定やハンドラー機能などはそのままにミドルウェアや静的ファイルサーバーなどをHonoに置き換えました。

成果物

• adapter-hono (https://www.npmjs.com/package/adapter-hono)
• hono-absolute-serve-static (https://www.npmjs.com/package/hono-absolute-serve-static)

「開発が先行し、ドキュメントが古くなる」「ドキュメントの更新が追いつかない」そういった課題に悩まされていませんか。
この課題に対し、HonoエコシステムとAIを組み合わせた解決方法をご紹介します。

• @hono/zod-openapiや@hono/zod-validatorで作成したAPIのインターフェースや仕様を、@scalar/hono-api-referenceにより見やすいAPI仕様書として自動生成
• @scalar/openapi-to-markdownによりllms.txt形式に変換し、API仕様をAIが理解しやすいMarkdown形式で出力
• 既存ドキュメントをナレッジベース化したHonoで構築したワークフローサーバーMastraで、このllms.txtを定期取得し、Claudeにドキュメントを更新を依頼する

上記について、具体的な実装手順と実プロダクトにおける運用事例を交えながらお伝えします。

対象者:

• ドキュメント管理に悩んでいる開発チーム
• AIを用いたワークフローに興味がある方
• Honoを用いて効率的な開発を実現したい方

サービス間通信を実装する上で、スキーマを定義し何らかの方法で表現されているとスムーズに開発を進めることができます。言語に依存しないスキーマ表現方法としてOpenAPIがあります。

Next.jsはReactを用いたWebアプリケーションを作成するのに便利なフレームワークです。Next.jsはHTTP APIを提供する仕組みとしてRoute Handlersを提供しています。しかしながらRoute Handlersをそのまま用いてもAPIのスキーマを生成することはできません。Next.jsで提供しているHTTP APIのスキーマを別アプリケーションから参照したいときにこれでは不便です。

ところでhono/vercelを用いることによりNext.js Route HandlersでもHonoを使うことができます。
そしてhono-openapiと@hono/valibot-validatorを用いることによりHonoで提供するAPIのスキーマをOpenAPI形式で出力することができます。
さらに副次的な効果として、Honoならではの型や豊富なエコシステムによる支援を受けることができます。

このようにして我々はHTTP APIのスキーマを手に入れることができました。

このトークでは実際に以下の内容について話します。

• コードファーストでOpenAPIスキーマを生成するためのアプローチ
• Next.js Route HandlerからHonoへの段階的な移行

CARTA HOLDINGSではWebアプリケーションをチームで開発するインターン「Treasure」を10年以上に渡って開催し続けています。時代に合わせた様々な技術選定を経て、この2年はHonoをAPIサーバとして使ってきました。

本トークでは、さまざまな技術バックグラウンドを持つ学生たちにWebアプリケーションの型としてHonoが果たしてくれた役割を振り返り、さらにはWebアプリケーションの未来をどう紡いでいくのかをHonoを起点に探ります。

「小さなパーツの集合が全体の機能を提供する」Webアプリケーションフレームワークの系譜としてHonoの存在には普遍性があること、その上で現代の技術要素の多くを集約できるHonoは未来への道標であることが確認できるはずです。

何を話すの？

• Webアプリケーションの歴史におけるHonoの存在
• 様々なバックグラウンドを持つ人々がHonoで合流できた
• フロントエンドとバックエンドが再び溶け合う時代にどう向かうか

誰に届けたいの？

• Honoを本格的に導入したいが踏み切れていない組織の人
• サーバサイドの技術選定に迷っている人
• 企業の採用活動において技術の思想を伝える役割を担う人

介護・社会福祉業界向け勤怠管理システムで、数百のエンドポイントを持つ大規模Honoアプリケーションを運用しています。
本セッションでは、@hono/vite-build + bunを活用したビルド戦略の実装事例を紹介します。

話すこと

• 背景
• 実装事例紹介
• パフォーマンス比較

対象者

• Honoで本番環境を検討中の方
• Bunを活用したい方
• ビルド最適化やパフォーマンス改善に関心がある方

得られること

• @hono/vite-build + bun の実践的な設定方法
• 本番環境でのパフォーマンス最適化手法
• ビルドプロセスの課題と解決方法

アプリケーションのオブザーバビリティ構築において、OpenTelemetryの利用は多くの個人・企業にとってデファクトとなっています。
分散システムのオブザーバビリティを実現する上で、HTTP Client/Server間でテレメトリデータを正確に伝播させ、適切な計装を行うことは不可欠です。
本LTでは、Honoを用いたサーバー構築におけるOpenTelemetryの導入と、サービス間通信でのContext Propagationの具体的な実装例を紹介します。
実際のコード例を交えながら、トレーシングの設定からサービス間でのトレース連携まで、実装上のポイントを解説します。

本セッションでは、@hono/zod-openapi を活用して、API Gateway と複数の API をひとつのスキーマ定義から一元管理する実践的な方法を紹介します。

私たちのサービスでは、Web アプリからのリクエストをすべて API Gateway に集約し、そこから背後の複数の API へと振り分けています。この「1対多」の構成をとりながらも、スキーマはひとつのパッケージにまとめられており、@hono/zod-openapi のコンフィグから Web→Gateway、Gateway→API の両方向に対してスキーマを生成しています。

これにより、リクエストのバリデーションやモック生成を含めて一貫性を保ちながら開発を進めることが可能になりました。また、BFF 的な構成やプロキシ的な利用にも応用でき、API 管理の工数削減と柔軟性を両立しています。

本LTでは、この仕組みの設計と運用の実例を通して、Hono でのスキーマ一元管理のメリットを共有します。

Astroは本体のコンポーネント言語としてはJSXを第一級ではサポートしていません。
そのうえで、Astroに「もうひとつの選択肢としてのJSX」を取り入れるなら、Hono JSXが最適な候補になり得ると考えています。

理由はシンプルです。Astroの「サーバー優先・必要な所だけ動かす」思想に、Hono JSXの素直さと軽さがそのまま一致するから。さらにAstro公式ロードマップ（JSX対応の検討、部分描画、フォーム処理の改善など）とも方向性が揃っています。

本セッションでは、次の点を設計の観点から整理して共有します。

• Astro core team でJSXを検討する議論の中で、Hono JSXが有力候補となる理由
• 実験的レンダラーの構成と実装の要点
• .astro と並走できる最小の利用パターンとガイド
• 段階的な検証内容と結果、および今後の課題

講談社「現代ビジネス」では、全ページをHonoによるMPA (Multi-Page Application) で提供しています。本セッションでは、大規模メディアでのHono実運用の設計指針、Next.jsからの移行理由とプロセス、そこで直面した課題や解決の工夫を紹介します。

特に hono/jsx および hono/jsx/dom (Client Components) を利用して必要な箇所のみクライアントで動的に動作させるHydrationを取り上げます。いわゆるIsland Architectureを採用しており、Honoでの実例は珍しいのではないでしょうか。またなぜこれを採用したか、React / Preactなど他のライブラリと比較して説明します。

さらに、Next.js App Routerからの移行について、RSC (React Server Components) など特徴的な機能をどう移行したか、Reactで書かれたcomponentをHono JSXの互換性を活かして再利用する方法も紹介します。

またNextのようなファイルベースでのルーティングの実装、JS/CSSアセットのビルドと配信、Viteの採用可否など、フレームワークをプロダクトに合わせて構築していく実践知を共有します。

Honoの利用やNext.jsからの移行を検討する方へ参考になる情報をお届けします。

このトークでは、チーム開発における Hono と @hono/zod-openapi を活用したスキーマ駆動開発の具体的プラクティスを紹介します。私は現在、この構成を採用したプロジェクトに二つ参加しています。

ひとつ目のプロジェクトでは、フロントエンドとバックエンドの双方が TypeScript で実装され、いずれも Hono を利用しています。スキーマ定義は共有資産として扱われており、Hono が提供する RPC 機能を活用することで、HTTP レベルの詳細を意識せず型安全な関数呼び出しのように API を利用できる仕組みを整えています。

もうひとつのプロジェクトでは、フロントエンドは TypeScript、バックエンドは Kotlin で実装されています。現状スキーマはフロントエンドに置かれていますが、将来的には共有資産へ移行が検討されています。スキーマに基づいたレスポンス検証をフロントエンドに組み込むことで、バックエンドの実装とスキーマが乖離している場合に不整合を早期に検知できるようになっています。

両プロジェクトに共通するのは、フロントエンドがスキーマを基にモックを手動実装している点です。これによりバックエンドの進捗に依存せず開発を進められるほか、動的なレスポンスも柔軟に再現可能になっています。

これらの事例を通じて、スキーマをどのチームが所有すべきかという組織的な判断だけでなく、フロントエンド主体でモックを整備することによる独立性の確保、Hono の RPC 機能を活用した効率的な開発プロセスの実現、さらにスキーマとレスポンスの整合性検証による品質担保といった実践的な知見を共有します。

このトークを通じて、参加者が自身の開発現場において Hono を用いたスキーマ駆動開発をどう適用できるかを判断するための視点を持ち帰っていただければと思います。

REST API開発において、Honoを用いて、OpenAPIを作成する場合、Hono OpenAPIとZod OpenAPI Honoという選択肢があります。しかし、コードファーストのアプローチがメインです。スキーマファーストのアプローチが欲しかったため、hono-takibiというライブラリを作成し、試行錯誤しています。

「スキーマ駆動で、Zod OpenAPI Honoによる、API開発するために、Hono Takibiというライブラリを作っている」という、LTでも申し込みましたが、レギュラートークでも申し込みます。

OpenAPIやTypeSpecのスキーマ定義から、Zod OpenAPI Honoのコードを生成し、スキーマ駆動のHonoのアプローチを紹介します。

「2ちゃんねる」に代表されるスレッドフロート型掲示板は、日本のインターネット文化の象徴です。本トークでは、「ゼロちゃんねるプラス」を参考に、この伝統的な掲示板をHono, Bun, Cloudflare Workersといった令和の最新技術スタックで再構築した個人開発プロジェクト「VakKarma」についてお話しします。

開発の核としたのは、型安全性の徹底的な追求です。フロントエンドからバックエンド、データベースアクセスに至るまで、一貫して型安全な開発体験を目指しました。
UI構築には、Honoベースのメタフレームワーク「HonoX」を採用。JSXを用いてReactのような開発体験で型安全なHTMLを構築できる点が大きな魅力です。これにより、従来のテンプレートエンジンが抱える型情報の喪失といった課題を解決しました。
データベース操作には、ESLintプラグイン「SafeQL」を導入。SQLクエリを静的に解析し型情報を生成、タイプミスや型の不一致をコーディング中に検出することで、実行時エラーのリスクを大幅に低減させました。

アーキテクチャはドメイン駆動設計（DDD）を意識し、ドメイン層・ユースケース層・リポジトリ層に分割。堅牢で保守性の高いコードベースを構築しました。
また、専用ブラウザ（ChMate）からの接続もサポートし、JavaScriptを無効化した環境でも動作するよう、クライアントサイドのJSに依存しない設計を採用しています。デプロイ先の選択肢も複数対応しています。

このトークを通じて、HonoXを用いたモダンなWebアプリケーション開発の魅力と、型安全性を軸にしたシステム設計の実践的な知見を共有します。

「2ちゃんねる」に代表されるスレッドフロート型掲示板は、日本のインターネット文化の象徴です。本トークでは、「ゼロちゃんねるプラス」を参考に、この伝統的な掲示板をHono, Bun, Cloudflare Workersといった令和の最新技術スタックで再構築した個人開発プロジェクト「VakKarma」についてお話しします。

開発の核としたのは、型安全性の徹底的な追求です。フロントエンドからバックエンド、データベースアクセスに至るまで、一貫して型安全な開発体験を目指しました。
UI構築には、Honoベースのメタフレームワーク「HonoX」を採用。JSXを用いてReactのような開発体験で型安全なHTMLを構築できる点が大きな魅力です。これにより、従来のテンプレートエンジンが抱える型情報の喪失といった課題を解決しました。
データベース操作には、ESLintプラグイン「SafeQL」を導入。SQLクエリを静的に解析し型情報を生成、タイプミスや型の不一致をコーディング中に検出することで、実行時エラーのリスクを大幅に低減させました。

アーキテクチャはドメイン駆動設計（DDD）を意識し、ドメイン層・ユースケース層・リポジトリ層に分割。堅牢で保守性の高いコードベースを構築しました。
また、専用ブラウザ（ChMate）からの接続もサポートし、JavaScriptを無効化した環境でも動作するよう、クライアントサイドのJSに依存しない設計を採用しています。デプロイ先の選択肢も複数対応しています。

このトークを通じて、HonoXを用いたモダンなWebアプリケーション開発の魅力と、型安全性を軸にしたシステム設計の実践的な知見を共有します。

--- LT枠でも応募しているんですが、5分だとだいぶ切り詰める必要がありそうなので、レギュラートーク枠でも応募します ---

Hono・Bun・Drizzleという軽量かつモダンな技術スタックは、小〜中規模では高い開発体験を提供しますが、100を超えるテーブルを抱える大規模アプリケーションと組み合わせると、型定義の肥大化、マイグレーション管理の複雑化などの課題に直面します。
本LTでは、これらの課題を実際の開発現場でどのように捉え、対処しているのかを共有します。
特にテスト戦略では、Drizzleのネストしたトランザクションへの対応を活かし、Honoの処理全体をテスト単位でラップしてロールバック可能にすることで、DB状態をクリーンに保ちながらテストを高速に繰り返せる環境を構築しました。さらに、マイグレーション実行などI/O負荷の高い処理では、Dockerのtmpfs機能を利用してDBストレージをインメモリ化し、テスト速度を大幅に改善しています。
これから大規模DBにHonoやBun、Drizzleを導入しようと考えている方が、事前に押さえておくべき注意点や実践知見を持ち帰れる内容です。

REST API開発において、Honoを用いて、OpenAPIを作成する場合、Hono OpenAPIとZod OpenAPI Honoという選択肢があります。しかし、コードファーストのアプローチがメインです。スキーマファーストのアプローチが欲しかったため、Hono Takibiというライブラリを作成しました。

1. Hono Takibiについて
2. Hono Takibiを開発した背景
3. OpenAPI(yaml,json)、TypeSpecから、コードを生成する様々な方法(viteとの組み合わせなど...)
4. 今後の機能について(RPCの自動生成など...)