トーク

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

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

「開発が先行し、ドキュメントが古くなる」「ドキュメントの更新が追いつかない」そういった課題に悩まされていませんか。
この課題に対し、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を本格的に導入したいが踏み切れていない組織の人
• サーバサイドの技術選定に迷っている人
• 企業の採用活動において技術の思想を伝える役割を担う人

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

講談社「現代ビジネス」では、全ページを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 を用いたスキーマ駆動開発をどう適用できるかを判断するための視点を持ち帰っていただければと思います。

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

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

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

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

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の自動生成など...)

Web地図界隈では古来より「地図タイル」という仕組みが存在します。
地図タイル配信のベストプラクティスは日進月歩で変化しており、かつてより遥かに低いコストで巨大な地図タイルを配信することが可能となっています。
タイル配信の最新のプラクティスをHonoと組み合わせることで、とても手軽に安いタイルサーバーを構築できます。本トークでは、地図タイルの理屈を簡単に紹介したうえで、AWSやCloudflareという基盤でHono製のタイルサーバーを構築・運用する手法を実際の事例を添えて紹介します。

アウトライン（予定）

1. 地図タイルの概要
2. Honoでタイルサーバーを実装する
3. AWS/Cloudflareにデプロイする
4. 事例紹介

レガシーJavaで作られたToilに溢れたスタブサーバーをHono(zod-openapi)にリプレースし、開発者体験を向上させるまでの軌跡を5分に詰め込んでお話しします。具体的には以下についてお話しします。

• リプレース前のToilについて
• 技術選定時におけるHonoの以外の選択肢
• なぜHonoを選んだのか？
• Honoを使うことにより得られた恩恵
• Hono×Devinを活用することでどの程度の工数で移行できたのか
• 開発の過程でHonoに貢献できたこと