まずは箇条書きで。

• フロントエンドとPHPが一緒なのがよかった。広いテーマのトークを同会場で同時に聴けるのがいい。いい感じにフロントエンドとPHPがクロスしてるトークもあってよい。
• フロントエンドとPHPだと、個人的にどっちも知り合いがいて楽。
• トークが全部楽しかった！生成AI臭がなかった。
• 北海道、というか札幌なのかな。飯がうまいのと、うまい飯屋がたくさんあって気に入った。移住すら考えた。
• 主催の人が「北海道の魅力を知ってもらいたい！」ってスタンスがめっちゃいい。
• ハッシュタグが飯テロだったのもいい。
• 参加者が楽しそうだった。
• 活一鮮っていう回転寿司屋が異様にうまかった。回転寿司で一番じゃねってくらい。
• たくさんラーメン食べたけど、味の三平っていう味噌ラーメン元祖の店のラーメンが一番衝撃だった。最初「あれ、これ味噌ラーメン？？」って味噌感薄いんだけど、食べてうちに癖になる。
• かなり前から札幌にいたんだけど、金曜日以外の平日は人がすくないから飯屋とか並ばない。

あとまだまだたくさん書くことありそうだけど、一旦箇条書き終わり。

自分は「AI時代のUIはどこへ行く？その2！」という題名でトークした。かなり気合がはいってて、プレッシャーだったんだけど、終わってよかった。だいたい話してる最中って聴いてる人の顔をみても、いまいち反応が分からないし、Xも見ることができないので、トークしながら不安になるんだけど、終わった後のXポストとか、話しかけられたりするに評判がよくてよかった！魂込めました。

スライドはこれ。

• https://speakerdeck.com/yusukebe/aishi-dai-nouihadokohexing-ku-sono2

写真はすばるさんとsyumaiさんにとってもらった。ありがとうございます。

すばるさん撮影:

syumaiさん撮影:

最後に飯テロ。

運営のみなさん、お疲れ様でした！

色んな場所に行き、色んな人と出会った1年だった。 一つ一つのトピックを見ていく。

Hono

相変わらずHonoのメンテナンスをしている。Honoの「Initial Commit」は2021年の12月。開発から4年経った。

Honoは多くを変えた。一つは僕の職を変えた。HonoがキッカケでCloudflareに入社することになった。 多くの人間関係を変えた。Honoが色々な人を繋げた。 そして、JavaScriptバックエンドのエコシステムを変えた。これはオーバーな表現ではない。

2025年のHonoの動きは一見微かである。 年初にリリースされたのが「v4.6.16」で、現在の最新版が「v4.11.3」となっている。 つまりマイナーバージョンアップが5個だけインクリメントされただけで、メジャーバージョンアップはない。 これはまぁ、意図的というか「必要がなかった」というのが正直なところで、honoパッケージ自体のAPIや機能はだいぶ固まっていることの裏返しだと思う。 やるとしたら、型のパフォーマンス向上のために型の持ち方を変える破壊的変更を入れるか、レスポンスを検証するための機能を入れるかとか、薄いContextを導入するとかだが、今のところは具体的なアイデアもない。

動きがないように見えて、やることは大量にあった。 Honoは3rd-Partyミドルウェアといってgithub.com/honojs/middlewareモノリポ配下にコアパッケージとは別の第3者が作ったミドルウェアパッケージが置いてある。 その数、現在45パッケージ。基本的には作者にディスパッチすればいいのだが、基本的に最初のハンドリングは僕がやる。 また、それ以外にも、honojs/website、honojs/node-server、honojs/vite-plugin、honojs/create-honoといった10個以上のレポジトリをHonoは持っている。 そこの全てのIssueとPull Request（PR）を見るのはかなり骨が折れる。

例えば、2日間ほど放置しただけで（実は年末に来て体調を崩した）、13個のIssueもしくはPRがGitHubのInboxに溜まる。

これを僕は今から一つ一つ見ていかなくてはいけない。いくつかはノールックでマージできるものもあるが、解決するのに数時間かかるものもある。 後述する「OSS開発者の憂鬱」的な話である。この憂鬱をどうしていくかは2026年、本気で考えたほうがいいだろう。

とはいえ、2025年もHonoの快進撃は止まらなかった。GitHubスターは28Kになった。

これは日本人発のOSSで3位か4位らしい。少なくとも4位の数字である。

また、npmパッケージのダウンロード数も月間2,000万。相対的に言えば、目標だったJavaScriptフレームワーク「Fastify」のその数を超えた。

Cloudflareではインターナルで多くのプロダクトで使われているし、Mastraが内部のサーバーとしてHonoを採用した。 最近では、MCP公式のTypeScript SDKが使い始めた。

Honoは（おそらくあなたが知らないほどに）大きくなった。 そして、JavaScriptエコシステム、コミュニティ、そして僕の人生と多くのものを変え続けている。

Cloudflare

CloudflareのDeveloper Advocateとして働いている。 2023年の4月に入社したから、もう2年半以上になる。 Cloudflareが初めての会社員体験なので、それが自分的に長いか短いか判断しかねるが、よく続いてると思う。

僕はインターナショナルなDeveloper Relations（DevRel）チームに所属していて、メンバーは各地に散らばっている。これは本当に散らばってる（僕がこのチームの好きなことの一つだ）。

• US - オースティン
• US - ロサンゼルス
• US - サンフランシスコ
• US - ニューヨーク
• UK - ロンドン
• オランダ
• ドイツ
• インド
• オーストラリア
• 日本

時差とか大変だが、僕の場合はアジア一人でもなんとかなっている。 主にやることをこの4つにして一人で自由にやっている。

1. Honoの開発
2. イベントの開催
3. イベントの登壇
4. 日本チームのサポート

ちなみによく「Honoの開発ってCloudflareの業務でやってるんですか？」と聞かれるが、業務でもやってるし、個人の趣味の時間でもやってる。 業務でやれる理由は3段論法的にこうだ。

1. HonoはCloudflareのアプリ作成を助ける
2. 私はHonoを開発している
3. ゆえに、私はCloudflareのアプリ作成を助長している

上記した通り、Honoの開発は変わらず続けている。イベントについては後述する。

やっていることに「日本チームのサポート」が入ってるのが興味深い。 つまりインターナショナルなDevRelチームとは別に、日本の顧客を対象とする日本の営業の人たちに協力することがある。 「開発者プラットフォーム」という開発者向けの製品の説明やワークショップをしたりする。 また、僕はいうても有名人なので、お客さんのミーティングにダマテンで参加すると驚かれることもあったりして重宝がられる。

日本チームでも活動することは良い面があって、インターナショナルなチームに加えて「日本」という居場所を作ることで、一方がダメになった時の保険を作ることになる。 また、政治的な意味合いでも味方を作ることは大事だ。 その結果、仲のいい同僚も増え、18時の飲み会から深夜まで一緒に遊ぶことなんてもある。

これらの活動はCloudflare的に大きなインパクトはあるのは確かだと思う。 僕のおかげでCloudflareを知って、イメージも良くなったと考えている人は少なからずいる。 ここ最近、DevRelチームの体制が変わったので、2026年は違う動きをしなくてはいけないかもしれないが、自由にやっていきたい。

Workers Tech Talks

今年は本当にイベントをたくさん開催した。

特に「Workers Tech Talks」というCloudflareの「Cloudflare Workers」をテーマにしたミートアップをたくさんやった。

1. 2025/1/23 - 東京
2. 2025/3/12 - 大阪
3. 2025/5/3 - 東京
4. 2025/7/22 - 京都
5. 2025/8/26 - 新潟
6. 2025/9/9 - 北海道
7. 2025/11/13 - 福岡

僕が一人で企画を立てつつ、会場を提供してくれる方々と協力してやるイベントだ。 東京の場合は100人近く、他の地域は30人程度まで参加する。 中身はその名の通りテクニカルなトークで構成されていて、トークが終わったら全員で集合写真を撮って、会場でピザをとったり、居酒屋に流れて懇親会をする。

入社した2023年からやっている試みだが、なかなかいい。 Cloudflareサイドの人が一方的に話すのではなく、ユーザーサイドの開発者がトークをするのが特徴だ。 トークの時間は休憩を挟んで2時間確保するのだが、飽きずに全部聴ける。 Cloudflareにはデータベースやオブジェクトストレージなど様々なプロダクトがあるのだが、それらを使った「Cloudflare Stack」を活用したリアルワールドの活用例を話す人が多くなっていたのが嬉しい。

トークの時間はスピーカーが主人公だ。 様々な人にフォーカスを当てることが出来たのはこのイベントをやっていてよかったこの一つだ。

Workers Tech Talks in Austin

Workers Tech Talksは今年7回、当初から合計すると11回やった。 そして、2025年12月。12回目にして、いよいよ日本を飛び出して海外でやることになる。「Workers Tech Talks in Austin」である。

12月頭にDevRelチームのミーティングがアメリカ・オースティンで行われることになった。 そこで以前、来日した時にWorkers Tech Talksに参加したことがあるチームメイトのKristianが提案してくれた。

Hey man! What do you think about doing a Workers Tech Talk in Austin in December while you’re in town?

このメッセージを受け取った時、僕は震えた。 「次は名古屋に行くかな」「会津大の学生が近くでやってくれって言ってたな」などと日本国内だけを考えていたのが（もちろん名古屋でも会津でもやりたい）、 急に世界に広がった。

日本のカンファレンスで話していた人が「海外カンファレンス登壇」するのならまだ分かる。それはなかなか経験できないことだが、チャレンジとして割とある話だ。 だけど、この場合は「日本でやっていたイベントを海外でやる」ってことだ。 珍しいことだし、想像に及ばないことだった。 もしくは冗談で言う類のものだった。それがKristianの一言で現実となる。僕は彼のメッセージに「Let’s do it」と返信した。

会場の手配、スピーカーのアサイン等、ほぼ全てをKristian含め他のメンバーがやってくれた。 僕はイベントのフォーマット、つまりトークは20分で5分のLightning Talks（LT）を入れるといいとかを指示するくらいだった。 そして、12月3日にWorkers Tech Talks in Austinが開催された。 参加者は65人と初めての試みとしては大満足の数字。 雰囲気はちょっとした緊張感。みんなはじっとスピーカーのトークを聴く。日本のWorkers Tech Talksと変わらない。「これこれー！」。

僕はせっかくだからとLTで話した。 「LTは5分」というセリフを要所要所で散りばめ、早口でまくし立てるという本気のLTをしてウケを取れた。

何よりもハイライトだったのは、最後に話したのがKentonだった。 KentonはCloudflare Workersの生みの親で、2017年にブラウザで動くV8のエンジンをサーバーサイドで動かしJavaScriptを実行可能とするというアイデアを実装した天才エンジニアである。 稀に見るワールドクラスだ。 僕はKentonに話してもらうようKristianにリクエストした。 曰く、声をかけた当初は「No」と言ったが、ひるがえってOKを出してくれた。

海外で初めてやったWorkers Tech Talksの最後をWorkersの生みの親であるKentonが締めくくるのは、いわゆる「エモーショナル」でとんでもなく嬉しい出来事だった。 Kentonを隣にして最後に撮った集合写真は僕の宝物である。

ミートアップ

Workers Tech Talks以外にもミートアップをいくつか開催した。

1. 2025/5/14 - AI Developer Meetup in Tokyo
2. 2025/2/19 - DevRel Talks! in Tokyo

どちらも100人弱の参加者で一人でやるミーティングとしては大きい規模である。 会場の協力のおかげもあって（サイボウズさん等々ありがとう！）、このレベルのイベントの企画と仕切りはお手のものになっている。 特にこの2つは、前者が元Eleven LabsのThor、後者が元VercelのLee Robinsonの来日に合わせて開催したのもあり、海外のゲストのハンドリングもうまくできる。 参加者の満足度も異様に高い。

最近気付いたのだが「それもそのはず」だ。 僕は少なくとも15年前の2010年の「Perl Casual」からこの手のイベントを自分で開催している。 経験がある。この経験を活かしてみんなが楽しいと思えるイベントを2026年もやれたらよい。

Hono Conference

2025年のハイライトの一つはHono Conferenceをやれたことだ。

今年のHono Conferenceは去年7月にやったものに引き続き2回目となり、10月18日に開催した。 去年は100人弱だったのが（それでもすごい数字だが）、今年は184人参加した。 4年前、一人デスクに向かい開発していたHonoが今や184人、しかもオフラインで人を集めたのは感無量である。

Hono Conferenceではやりたいことをやれた。 分かりやすくキャッチーな事実は「自分が作ったソフトウェアのカンファレンスで実行委員長をやってLTでドラを叩いた」ことだが他にもたくさんある。

まずはコントリビュータへの還元である。それをHono Awardsという形で影響を与えた3人のコントリビュータを表彰した。

次にヒーローを生むこと。 今回のヒーローはnakasyouだ。元中学生コントリビュータ・現高校生コントリビュータという強烈な肩書きに劣らず、nakasyouの視点は切れ味がある。 コントリビュータでありヘビーユーザーでもある。 第1回目のキーノートはusualomaさんに頼んだが、今回は真っ先にnakasyouに相談した。二つ返事でOKをもらった。

nakasyouのキーノートは素晴らしいものだった。本当にヒーローだった。参加者は彼に釘付けになった。 もちろんHonoがなくても彼はヒーローになる。だけども、Honoが少しでもnakasyouを持ち上げるきっかけになったら、それはすごく嬉しい。

トークはユーザートラックとディープトラックという括りにした。ユーザートラックはその名の通り、Honoユーザーのトーク。 ディープトラックは海外ゲストとプラットフォームサイドのトークで構成された。僕は主にディープトラックを聴いていたのだが、全部面白かった。 びっくりするほど面白かった。

参加者の評価が異様に高かった。アンケートの結果も高得点で例えば「満足度」は10点満点中10点が70%、5点以上に全員が収まっていた。 アンケートで興味深いのが、「普段のロールについて教えてください」という質問では「フロントエンド」と「サーバーサイド」が同数だったことだ。 これはなかなか珍しい。ある意味「Hono特有」のコミュニティが形成されてるのだと思う。

スポンサーが豪華だった。メディアスポンサーを合わせると22社。海外のスポンサーもいた。CloudflareとVercelが横並びするイベントは他にはないと思う。 これだけのスポンサーに対応するのは大変だ。特に海外のスポンサーは契約書を作ったり、請求書の方法が独特だったり、送金に時間がかかったりと難しいことばかりだ。 それでも、やってもらっただけの価値がとてもある。Honoに箔が付く。これだけの企業さんがHonoを支えてくれる。 そうした事実を作りたかった。

クロージング、「One More Thing」でHono CLIを発表した。Hono CLIの説明はここではしないが、とにかく「新しいこと」を発表した。 それまでは誰にも明かさなかった。いや、usualomaさんだけ知っていた。 2週間ほど前のスタッフとのミーティングで「One More Thingやりますか？」という話があって、当初はやる気がなかったのだが、以前からHonoにまつわるコマンドが欲しいとは思ったので、10日ほどでエイヤでusualomaさんと一緒に作った。 その日々は本当に楽しかった。イベントの準備しろって感じだが、久しぶりに新機能を開発するのは爽快だった。 早く誰かに話したくてしょうがなかった。それを素晴らしいイベントの一番最後に話せるのは、職権乱用と言われようが最高の体験だった。

去年はHono Conferenceをほぼ一人でやったが、今回はスタッフを集めてみんなでやった。みなさんイベント経験者で頼りになった。ここまで出来たのはみんなのおかげだ。 感謝している。

Hono Conferenceで言及するべき最後のことはAdityaだ。AdityaはHono関係のライブラリを作っていてHonoが大好き。Honoのエコシステムに影響を与えたとして、Hono Awardsを受賞してもらった。普段インドで活動しているのだが、5月にWorkers Tech Talksのために来日することがあった。その時に焼肉屋連れて行ったのだが、彼は執拗に「今年はHono Conferenceやらないのか？」「やるんだったらスポンサーする」と言ってきた。当時僕は全くHono Conferenceをやろうと思っていなかったので、最初は「面倒だな」なんて感じていたが、彼の熱意でやろうと決意し、スタッフを集めだした。そして当日、Adityaはゲストとして参加した。Adityaがいなかったらこの高みはなかった。ありがとう。

Hono ConferenceのコンテンツについてはメディアスポンサーのFindyさんの素晴らしいレポートがあるのでそちらを見て欲しい。

• Hono Conference 2025 ── 「Hono CLI」発表。AI時代に、コミュニティと進化するWebフレームワークの姿
• “You might not need Hono” 高校1年生のコントリビューターが語るHonoの未来

OSS開発者の憂鬱

「OSS開発者の憂鬱」は去年から温めていたネタだ。

元々は去年2024年10月に函館で行われたYAPC::Hakodate 2024のプロポーザルとして提出していたものだった。 ところが、その年の夏に半月板の手術をすることになり、流石に松葉杖で函館に行くのは大変だということで辞退していた。 採択結果が出る前だったので通過したかどうかは不明だが、fortee上で星をたくさん集めていたのでプロポーザルの時点で人気だったのは確かだ。

今年の11月25日、YAPC::Fukuokaでは同テーマでプロポーザルを提出し、採択。満を持しての発表となった。

YAPCは僕にとって最大限に大切なイベントである。 それが高じてCloudflareのマーケティングチームにスポンサーをすることをだいぶ強く訴えたくらいだ （その証拠にCloudflareはプラチナスポンサーとTシャツスポンサーをした）。

この発表に対する意気込みは異常に高かった。 YAPCだし、時間をかけたネタであるし、3度目となるベストスピーカー賞を取りたかった。 けれどもテーマがテーマだ。 Honoを開発する上で苦労した点をピックアップするというもの。 これは結構辛い作業だ。 当然だけど楽しいことを考えるより苦しいことを考える方がはるかに辛い。

OSSにおいては国や年齢、環境が違う見知らぬ人達がIssueやPRを投げてくる。 Honoの場合、扱う範囲は広く、Webの基礎技術からセキュリティ、ライブラリの活用までと多岐に渡る。 さらにコンテキストスイッチが毎回発生する（一連の問題を「登山すれ違い問題」と名付けた）。 中には心無いコメントをする人もいる。 ただただ辛い。まさに憂鬱だ。

それでも希望はあった。 今では、Issueに反応したり、FixのPRを作ってくれる仲間がいる。 Hono Conferenceもやった。コミュニティもある。 いろんな人たちが僕とHonoを称えてくれる。コントリビュータは600人を超えた。

そんなことを話した。 完璧に準備しただけあって、正確に伝わったと思う。 トークの最後の方は感動的な話なので、毎回練習をしていて泣けてきて、大丈夫かなと心配していたが、それもなく話せた。

クロージングのベストスピーカー賞の発表が楽しみだったが、逃した。 sosuke君の「一人で大規模OSSに立ち向かうには」が受賞した。 すごく悔しかったが、そのトークを前日に目の当たりにしており、あまりにもよかったので納得でもあった。

ところで、sosuke君とは最近何かと縁がある。 直前のHono ConferenceでもBunのことについて話してもらったし、去年のさくらじまハウスでも同じ登壇者だった。 他のイベントでもちょくちょく会って話をした。 「HonoをBun上で高速に動かすには」みたいなテーマでよく話す。 彼のテクノロジーに対する正確な知識とモチベーションは聴いていて痛快だ。 また、彼は（現Anthropicの）Bunに就職した。なので「海外の会社で働く」という共通点もある。 良し悪しじゃないが、それで言うとsosuke君の方がずっと先を行っている気もする。 久しぶりにロールモデルを見つけてちょっと嬉しい自分がいる。 ちなみに、この2025年振り返りはsosuke君が書いたエントリーに感化されて書いてる。

• 2025年の振り返り - sosukesuzuki.dev

OSS開発者の憂鬱の話に戻ると、この憂鬱は現在進行系で続いている。 少しでも憂鬱を晴らすアイデアはあると思う。2026年のテーマだ。

ワールドツアー

今年の中旬から日本各地、そして世界と色んなところに行った。ワールドツアーと名付けた。

• 7月 京都（Workers Tech Talks）
• 8月 甲府（Kofu.なんか）、新潟（Workers Tech Talks）
• 9月 北海道（Workers Tech Talks & フロントエンドカンファレンス北海道）
• 10月 東京（Hono Conference）
• 11月 福岡（Workers Tech Talks & YAPC::Fukuoka）、台湾（JSDC）
• 12月 USオースティン（Cloudflare DevRelミーティング）

果たしてやりきれるか不安だったけど、なんとか達成できてよかった。 その代わりすごく疲れた。なかなか「疲れた」とは人前で言わないたちなんだが、かなりぼやいた。 あまりにも疲れたので、1ヶ月間有給を取った。

言及していないイベントで印象に残っているのがJSDCである。 JSDCとは台湾で行われるJavaScriptの大きなカンファレンスである。 500〜700人参加するとのことで、蓋を開けると少し少ない気がするが、大きいことには変わりはない。

そのカンファレンスに僕は招待された。渡航費とホテル代を支給してくれるとのこと。 最初、この連絡をもらった時に受けるかどうかかなり迷った。 海外カンファレンスなので英語で話さなくてはいけないし、尺は40分だ。 それに、開催日の翌々日にはCloudflare DevRelチームのミーティングのためにアメリカに向かわなくてはいけない。 でも、せっかく招待してくれたしってことでエイヤで出ることにした。

トークはHonoをテーマにした。ある程度練習してたので、なんとかなった。 大変なのは、その後だ。AIをテーマにした。パネルディスカッションに参加することになってしまった。 断ればいいのに、ついOKしてしまっていた。 英語は得意ではないし、実はそもそもAIのディスカッションにはあまり興味がない。 結果はまぁ大変だった。

そんなJSDCだが、大収穫があった。TejasとEvan Youに会えた。

TejasはIBMの人だが、IBMのことは全く語らず、Reactの本を書いてるらしいが肩書がなんのかよく分からない。

Evan Youは言わずとしれたVueとViteの作者だ。

この2人はすごい。ワールドクラスだ。 何がすごいって、英語が上手くない僕でも10言えば、100理解してくれる。 何でも「Interesting」って言ってくれる。 だから会話が長く続く。 テクニカルなことじゃなくても、会話から彼らがワールドクラスであることが分かるのだ。

懇親会が終わって、ホテルが僕ら3人が一緒だったのだので同じタクシーで帰った。 「タピオカ」は英語なことについて。台湾の人がつけてる数珠について。日本における数珠の意味。 ドイツでは国教がないこと。日本にはトイレにも神様がいること。 中国の人が日本に来るモチベーションについて。浜崎あゆみの中国公演について。 その時に「自由にコミュニケーション出来てる」感じがとても楽しかった。

人と出会う

とにかく多くの人に出会った。

毎年多くの人に出会うのだが、例年にないのは、今年は海外の人とたくさん出会ったことだ。 「日本に行くから会おう」と言ってくる。 こうして日本で会ったのはこちらの人たちだ。Cloudflareの人だけじゃないのも面白い。

• Rishi - Codegiantというサービスをやっている。日本大好き。
• Lee Robinson - 元Vercel、現Cursor。Next.jsを広めた功労者である。
• Thor - 元Eleven LabsのDevRelっぽいことをしてる人。
• Ricky - 元Cloudflareの元僕のマネージャー。
• Michael - Cloudflare所属、元チームメイト。オーストラリアにいる。
• Tanmay - Cloudflare所属、コミュニティマネージャー。
• Aditya - Honoコントリビュータ。現Sentry。
• CJ - Syntaxの人。YouTubeをよくあげている。Hono大好き。
• Kristian - 同僚。親友。
• Kevin Yang - Cluelyというサービスをやってる人。
• James Snell - Cloudflare所属、JavaScriptのすごい人。

こういう話があると、だいたい東京駅近くにある新丸ビルの7階にある寿司バーに一緒に行く。 ここはすごい美味しい寿司を食べることができるが、すごく高くはない。なのでちょうどいい。 そして、食べ終わったら、バルコニーに出て、東京駅をバックにセルフィーを撮る。

みんないい奴でこちらも全力でもてなすので僕と日本を気に入ってくれる。 Rishiなんて、日本、とりわけ僕の地元である横浜が気に入って、3ヶ月も滞在したくらいだ。 その間、よくご飯を食べにいって、一番飯行ってる友達になった。

世界に友達ができるのは楽しい。

来るもの拒まず

Adityaからの言葉でHono Conferenceをやったことも、JSDCの登壇を引き受けたことも、海外からの人に会うことも、Workers Tech Talksをオースティンでやる時も、全て来るもの拒まずの結果である。「来るもの」には最初ビビる。例えば、海外から人が来ます。1対1で相手をしなくては。という時には多くの人は緊張するんじゃないだろうか。 でも、全部やった。 その結果、とんでもないところへ行けた。例えば、ワールドクラスに出会えたし、Workers Tech Talksでワールドクラスが話してくれた。

来るものを拒まなければ先にいけるのだ。それを体現できた2025年だった。

その代わり。能力が追いつかなくなることも知った。 例えば英語。今まで根性と度胸でなんとかやっていたのが誤魔化しが効かなくなる。いくら会話が成立してても、今のレベルだと思考が1歩、2歩遅れる。 すると大したことが言えない。 だから鍛えなくてはいけない。2026年やることが出来た。

料理

今年はたくさん料理をした。 2月頃かな？ファビオっていうイタリア人っぽい名前だけど、実物は優しい感じのお兄さんといった方がやっているYouTubeをひたすら見始めた。 ひたすらパスタを作るんだけど、見ていると作りたくなる。 料理はプログラミングと似ていて、完成したらすぐに評価することができる。 つまり、作ったらすぐ食べることができるのが気に入った。

僕はファビオを真似てパスタを、多い時は週5くらいで作った。 塩が味を決めることを知った。アーリオオーリオのオイルベースを作れば応用が効くことを知った。アルミのフライパンを買ったら、乳化が出来た。 そして、パスタを作るのが上手くなった。 今からプログラミングが上達することはあるにしろ、ここまで振れ幅はないだろう。

一方で、料理をするのは仕事にいい影響があると思う。 いい気分転換になる。パスタばっかり食べてたらヤバいが、パスタ以外にも健康的な物も作れる。 何よりも楽しい。 来年も料理をたくさんする。

健康

案外、元気である。 相変わらず中性脂肪と血圧は高めだが、大きな怪我もしないし、風邪だってひかない。 これはひとえに「物理的に」動いてるからだと思う。

まず筋トレとウォーキングをしている。 筋トレと言っても自重トレーニングってやつでスクワット、腕立て、プランク、クランチをほんの少しずつ。 ウォーキングは早歩きを4キロ。

あと、実は夕食後にカラオケに行ってる（笑）。 多い時は週4で行ってて、まねきねこの会員証がいつの間にか「ダイアモンド」になった。 歌うのは上手くなくて、人に聴かせるためのものではなく、ほんとにこれは自分で満足するためだけのもの。 ほんとに趣味。

一日でかなり動いている。激しい時はこんな感じだ。

• 朝起きる
• 仕事する
• 昼ご飯作る
• 昼寝する
• 仕事する
• 買い物する
• 筋トレ・ウォーキングする
• 夕ご飯作る
• カラオケに行く

身体を動かすと精神的にもいい影響がある。 よく、シャワーを浴びている時にアイデアが湧くというが、僕の場合ウォーキングをしている時にそれがよく起こる。 しかも歩くのは横浜の大さん橋というところで、ここが「横浜の景色が一番よく見える場所」であり、歩いていて本当に心地が良い。 やけにテンションが上がって、楽しくなる。悩んでいたことが消えて、やれるって思える。 だから、疲れている時こそ積極的に動く。

2025年、健康であれたことをありがたく思う。2026年も健康でいたい。

友達

本当に友達に恵まれている！ 先ほど紹介した通り、海外の友達もいるし、昔からの友達もいるし、新しくできた友達もいる。 界隈も違えば、住んでる場所も違う、付き合ってる年月も違う。相手は友達だと思っていないかもしれない。 それでも人に恵まれている。

幸運なことに10月25日のOasis再結成来日公演のチケットが当たっていた。 2枚持っていたが、一緒に行く人がいなかった。散々迷ったけど、やっぱり高木くんと一緒に行くことにした。 高木くんとは10年以上の仲だ。 彼と出会うずっと前。2002年。僕が大学3年生の頃。高木君が中学2年生だった頃。 僕はOasisライブを見るためにはるばる仙台まで行って、ライブを見ていた。 その頃仙台に住んでいた高木君はチケットが持っておらず、泣く泣く会場の外から漏れる音を聴いていた。 それが2025年、東京ドーム。再結成したOasisを隣り合って見ることになる。 一緒に見る相手としては最高の友達と見ることができた。

他にもたくさんエピソードはある。2026年も楽しい瞬間をたくさん作れたら嬉しい。

2026年へ

でかい話だが、生きることの価値ってのは「人生のハイライト」をいかにたくさん作れるかだと思う。 2025年はその瞬間がたくさんあった。 来年もこういうハイライトをたくさん増やせればいいなと強く思う。

シャトルシェフという調理器具があって、めちゃくちゃいいので、紹介する。 調理器具のことを話すが、シャトルシェフ以外詳しいわけではない。 圧力鍋やホットクックは使ったことないので、それらと比較をしたわけではない。 また、自分はとりわけ料理が得意なわけではない。 ご了承いただきたい。

シャトルシェフとは？

シャトルシェフとはサーモスが出している鍋である。2つの鍋で構成されてて、鍋の中に鍋がはいる。内側の鍋は普通の鍋で、外側が魔法瓶のようになっている。 普通の鍋で普通に調理して、外側の鍋に入れて蓋をすると、ずっと保温される。これを利用して火にかけることなく「じっくりコトコト」を実現する超頭のいい機器である。 つまり基本的には煮るためのもの。例えば、シャトルシェフでカレーを作ると、じゃがいもや人参が煮崩れせずに柔らかくなってめちゃくちゃ美味くできる。

外観。

中に普通の鍋が入ってる。

左が普通の鍋の内側の鍋。右が外側の鍋で魔法瓶みたいになってて内鍋を保温する。

シャトルシェフのいいところは、電気が必要ないこと。外側の鍋が保温するだけなので、必要ない。 すると取り回しがいいし、しまっておくのも楽だ。

いくつかの大きさが出てて、自分は3.0Lを使っていてそれだと3〜5人前となる。いわゆる家族向けだが、ひとりやふたり暮らしでもたくさんできるだけで別にそれで構わないと思う。 もっとでかいのだと8.0Lとかあって、業務に使える。シャトルシェフ好きとしてはいつか使ってみたい。

値段はすごい高くはなく、1万円弱から買える。プレゼントによくて、料理好きの親父にあげたらめちゃくちゃ喜んでいた。 他にもいろんな人に勧めてて、いく人かは「へぇ」と暖簾に腕押しだが、いく人かはほんとに買ってる。サンプルは多くはないが100%で満足してる。

シャトルシェフで作ったら美味しいものの代表がカレーである。 いつもと同じ要領で、普通のカレールーを使う。 野菜を切って、シャトルシェフの内側の鍋にいれる。 しっかり火が通るので野菜は大きめでよい。水は飛ばないので分量よりだいぶ少なめにした方がいい。 そして、煮るのだが、たった5分でよい。5分煮たら、外側の鍋の中に入れて蓋をしめて、1時間以上おく。 その後、内側の鍋を取り出しして、カレールーを溶かして混ぜればできあがり。 火を使って煮込むのは最初の5分間だけなので、その間は放置できるのがとても楽。例えば、外出前に仕込んで帰ってきた頃にはできてるとかできる。

5分間だけ煮る。

内鍋の蓋をして外鍋にいれる。

外鍋の蓋も締めて放置。

サーモスがレシピ集を公開しているので、それを見るとどんなものが作れるかが分かるし、その通りにやれば美味しいのができる。

このシャトルシェフを数年前から使っていて、めちゃくちゃ重宝している。それは「便利」という理由からだけではない。 シャトルシェフで作ったものはうまいのだ。カレーとか肉じゃががめちゃくちゃうまい。 それと、これまで作ったことのないものを作れる。スペアリブとか。料理の可能性を広げてくれるのだ。

というわけで、シャトルシェフの説明は済んだ。これは決してステマではない。

では以後これまでシャトルシェフで作った料理を写真で紹介する。 ちなみにこの記事は、シャトルシェフでクリームシチューを保温している間に書いている。

作ったもの

スペアリブ

シャトルシェフがなければ作らなかった料理「スペアリブの煮込み」が簡単でめちゃくちゃうまい。

スーパーでスペアリブ肉を買ってくる。

軽く焦げ目が付く程度焼いてから煮る。スペアリブが大量の場合はフライパンを使っているが、そこまで多くなければシャトルシェフの内鍋で炒めればよい。 とにかく甘い汁で煮たほうがいい。甘い方が柔らかくなる。マーマレードジャムとかはちみつをいれる。 焼き肉のタレをぶち込むのもよい。5分煮たら放置。長く置いた方が柔らかくなる。

これは3時間以上置いたもの。ホロホロになって完成！

豚の角煮

豚の確認も得意。ふわふわにできる。

肉じゃが

シャトルシェフで作った肉じゃががうまい！

牛肉で作るのが好き。スーパーでわりといい肉を買ってきて、最初に炒めて牛の旨味を出す。 これも5分煮るわけだが、途中で結びしらたきを入れる。肉じゃがの場合そんなおかなくていいけど、1時間もしくはそれ以上おいてる。

完成！とにかく人参が美味しい！形がそのままで、でも柔らかく、甘い味がでてくる。

カレー

普通のルーを使った普通のカレーでもシャトルシェフを使うとやたらうまい。写真は角煮を使ってみたやつ。 あー腹減ってきた。

無水カレー

最近のお気に入りがこの無水カレー。

玉ねぎ、ピーマン、ナス、あとはズッキーニとかを細かく切り、それにひき肉を入れて炒める。最後にトマトを入れる。水を入れずとも水分が出てくるので、ぐつぐつしたら外鍋に入れて保温。

1時間経ったら、市販のカレールーを溶かす。

完成！野菜のうまさが凝縮されてうまい！

クリームシチュー

当然シチューも得意。今夜はクリームシチューです。

ビーフシチュー

ビーフシチューもいい感じ。

牛肉たくさんでおいしい。

鶏チャーシュー

鶏もいける。もも肉買ってきて、鍋に入れて、タレを入れて5分煮て、外鍋に入れて放置。これが一番簡単かもしれない、鶏チャーシュー。 出来上がりはふわっとしてます。むね肉もいいね。

ぶり大根

ぶり大根なんてのもいける。

これは珍しくちょっと失敗。大根をもっともっと大きく切ればよかった！味がしみるので大きめにした方がいい。

いか大根

このいか大根は美味しかった！

参鶏湯

手羽元を使って参鶏湯も作った。また作ろう。

豚汁

豚汁なんかも内鍋で普通に作ればいいし、少しの時間でも保温したければ外鍋に入れればよい。

おでん

そう！おでんもいい感じにできた。

練り物以外にも大根、人参がちょうどいい。

塩味おでん

珍しいので塩味のおでんも作った。なかなかよかった。

スープカレー風煮込み

手羽元を材料にカレーパウダーを使うと「スープカレー風煮込み」ができる。

食欲をそそる香り！

その他

他にも作ったけど、いい写真がないから以上！

まとめ

以上、シャトルシェフについて紹介して、これまでシャトルシェフで作った料理写真を紹介した。 特にアフィリエイトとか貼らないので、気になる人はググってください。おすすめです！ 腹が減った。ちょうどシャトルシェフに入れたクリームシチューがいい感じになってるはず！

最後に最推しの料理スペアリブの煮込みの写真を御覧あれ。

フロントエンド？

ユーザーに近いところで実行されるという意味ではフロントエンドかもしれない。あと、VercelのNext.jsのように、フロントエンドフレームワークのファンクションがエッジで動くからフロントエンドでしょというのはある。そしてエッジのファンクションはたいていフロントエンドで使われているJavaScriptもしくはTypeScriptで書く。そうするとツールチェーンも、例えば「Vite」と聞いてそれが何であるか？を答えられる人はフロントエンドやってる人の方が多いだろう。

2つのユースケース

エッジには2つのユースケースがある。

1. CDNの機能を拡張する。オリジンありき。
2. サーバーレスコンピュート。オリジンそのものになる。

オリジンありき

これについては以前、Cloudflare Workersプロキシパターンという記事で、Cloudflare Workersを使った例をまとめた。

1. レスポンスヘッダの追加
2. CORS
3. Basic認証
4. ETagの追加
5. リダイレクト
6. オリジンの振り分け
7. キャッシュ
8. デバイス別のキャッシュ
9. HTMLタグの置換
10. ホットリンク禁止 - リファラ編
11. ホットリンク禁止 - SignedRequest編
12. 動的コンテンツのキャッシュ

クラシカルな人はお気づきかもしれないが、ApacheやNginxの設定でできることも含まれている。

Nginxでカスタムヘッダを追加するにはnginx.confにこう書けばいい。

add_header 'X-Message' 'Hello!';

一方、エッジとされるCloudflare Workersで書くとこうなる。

response.headers.add("X-Message", "Hello!");

おお、バックエンドやないかい！

オリジンそのもの

拙作のHonoは当初、エッジ環境で動かすことを想定してつくられた。Honoを使うとCloudflare WorkersやFastly Compute上でアプリをオリジンそのものとして動かすことができる。

import { Hono } from "hono";
const app = new Hono();

app.get("/", (c) => c.text("Hono!"));

export default app;

この文法をみて分かる通り、Node.jsのExpressやKoaの実装を参考にしている。はたまたRubyのSinatraや、PerlのMojoliciousがルーツにある。バックエンドやないかい！

Web標準

面白いのは、例えば、Cloudflare WorkersはエンジンがV8で、Chromeのタブが開くようなイメージで起動する。そうするとfetchに代表されるように、フロントエンドの人が触っていた技術がベースになると想像できる。

バックエンドの人がエッジをやると無双できる

つまりエッジとは、フロントエンドで多様されているJavaScriptもしくはTypeScriptとWeb標準の技術を使ってバックエンドを書くことだから、もともとバックエンドの人がフロントエンドの技術をかじれば無双できる。その結果がHonoである。

PlackとWeb標準

エッジの世界に入った時、Web標準のAPIを知って興奮した。Web標準のAPIって洗練されていて、こちとらPerlのWebのAPIがPSGIで標準化される模様をリアルタイムでみてたから、それがそもそもあるのが強い。

Plackを使ったPerlのコード。

use Plack::Request;
use Plack::Builder;

my $app = sub {
    my $env = shift;
    my $req = Plack::Request->new($env);
    my $message = $req->param('message')
    return [
        200,
        ['Content-Type' => 'text/plain'],
        [$message],
    ];
};

エッジで動くHonoのコード。

import { Hono } from "hono";

const app = new Hono();

app.get("/", (c) => {
  const message = c.req.query("message");
  return c.text(message);
});

export default app;

PerlはそれまでCGIやMVCフレームワークを含めてHTTPのリクエストをハンドルして、レスポンスを返す仕様と実装が標準化されていなかったんだけど、先行を行ってたRubyのRackとかPythonのWSGIを参考にPSGIが策定された。miyagawa++

なので、繰り返すけどそれがもともと組み込みのAPIであるJavaScriptのランタイムは素晴らしいなと。その上でフレームワークを作るのは、僕にとってはいとも簡単なことだし、だいぶMojoliciousに感化されたし、PerlのバックグラウンドがあるusualomaさんがRouter::Boomに（たぶん）インスパイアされて、RegExpRouterを作ったのはその流れがあって面白い。

みんなやろうぜ

で、何が言いたいかというと、エッジはフロントエンドの人もバックエンドの人も楽しめるので一緒にやろうぜ！ということ。ついでにいうとフロントエンドとバックエンドの境目も曖昧だろうし、Cloudflareではエッジという言葉は使わずに「Earth」を使うともなっているんだけれども。ひいきにしてるCloudflare Workersなんかはデプロイも速いし、コンテナいらなくなるし、APIは揃っているし、なによりもHono使えるしおすすめだよ！

その他

壮大な宣伝だったんだけど、8/1(木)にそのCloudflare Workersに特化した開発者向けのイベント「Workers Tech Talks in Tokyo」をやります。うちのCloudflareのDevRelチームからマネージャーのRickyと同じDeveloper AdvocateのKristianがゲストです。ぜひ来てください！

• Cloudflare Workers Tech Talks in Tokyo #3

あと、このテーマはaijiさんって人のフロントエンドカンファレンス北海道2024の「エッジはフロントエンドなのか？バックエンドなのか？について考えてみる by aiji」というプロポーサルに感化されました。

DevRelチームに所属し、Developer AdvocateとしてHonoの開発をメインに活動してきました。 41歳にして初めての会社員ですが、楽しい時間を過ごしています。今日はそのことについて書いてみます。

入社までの経緯

詳しいことは入社時のブログに書いたのですが、その経緯を再び。

2021年の12月にHonoというCloudflareで動くWebフレームワークをつくり始めて、それがだんだんと人気を得ていきました。

2022年の10月、CloudflareのエンジニアGlenが「Cloudflareで働くのに興味はないか？」と声をかけてくれました。当時UKに住んでいた彼が、地元のオーストラリアに戻りたいので、同じタイムゾーンのエンジニア仲間を探していたのです。ちなみに、GlenはCSS in JS「styled-components」の作者です。あとから知ってびっくり。

その後「一度オンラインで話してみないか？」と言われOKをすると、実はそれが面接で、それを5回くらいやって、しばらく音沙汰がなく、これは無理かなと思ったが、催促すると「2日待て」と言われて、2日後にはリクルーターから連絡があり、あらよあらよと事が進みめでたく入社となりました。

そういえば、社内のとあるチャットルームを遡ると「Honoの上でQwikを動かしたからCloudflare Pagesでも動くようになったぜ」という僕がTwitterに書いてるのをみて「We should employ that guy!」という発言があって、それを見てゾクゾクしましたね。

DevRelチーム

僕はDeveloper Advocateというロールで、Developer Relations、略してDevRelというチームにいます。それは「Emerging Technology and Incubation」、略してETIという部署の中のチームです。直訳すると「研究開発」みたいな意味合いになりますが、Cloudflareの場合「Cloudflare Workers」とその周辺のプロダクトを作っているところです。Glenをはじめとしたエンジニアがいて、DevRelチームは開発とものすごく近い場所にいることになります。僕にとっては、自分が大好きだったプロダクトの開発の裏側を知れて、めちゃくちゃ楽しい。

メンバーは個性派揃いです。

Developer Advocate以外に、Discordの管理をするロールもあります。また、「Educator」という聞き慣れないロールもあったりします。

住んでる場所もバラバラです。

• ロンドン
• アムステルダム
• リスボン
• メルボルン
• サンフランシスコ
• オースチン
• ニューヨーク
• 東京、というか神奈川

以下はまだメンバーが6人だった頃に場所と時間をプロットした図です。

そして、みんなユニーク。例えば、去年の年末に入ったEducatorのCraigは入ってきてからバリバリコードを書いて、チュートリアルを更新し、それだけではなく最近は「俳優」になっていて、先日公開された「Developer Week」を紹介するビデオではテンションの高いおじさんを演じています。これ、めちゃくちゃおもしろいのでみてください。

僕が入った時には6人だったのが、どんどん新しいメンバーも加わり、現在12人のチームとなりました。とても楽しい人達です。

寝て起きてコード書いて寝て起きてコード書く

たまに「入社して生活は変わりましたか？」みたいな質問をもらうんですが、あんまり変わってないです。入社前は業務委託で在宅が多く、比較的自由に時間を使えて、Honoの開発も空いた時間をみてやってました。寝て起きてコード書いて、寝て起きてコード書いて…を繰り返す毎日です。入社したあともHonoの開発がメインなので、その割合は違えど、寝て起きてコード書いて、寝て起きてコード書いて…は変わらない。なので、大きく変わった感じはしません。寝て起きてコード書いて、寝て起きてコード書いてます。

打ち合わせは2週に1回

定期的な打ち合わせは今はたった2週間に1回しかないです。というのも週1回でやってたころは日本時間で23時30分とかでさすがに辛いってことで、1週間ごとにヨーロッパフレンドリーな時間帯、アジアフレンドリーな時間帯とやることになり、つまり隔週だけのミーティングになりました。

それでも、DevRelチームはみんなやってることがバラバラなので、なんとかなります。逆にプロダクトの開発だとシンクしなくてはいけないのでやっていけないなと思います。

時差

昼間はチャットが静かですが、寝る直前の時間になってから盛り上がります。USのメンツの活動が活発になるからです。そうするとベッドに入りながらスマホでその様子をみたりしていて、もういつ起きていればいいのか分からない。

今の生活リズムははたから見ると大変なことになっていて一日3回寝てます。ミーティングの時間をずらしてもらったのですが、これだとどちらも出れますね。

• 0時〜3時 寝てる
• 3時〜7時 起きてる
• 7時〜9時 寝てる
• 9時〜13時 起きてる
• 13時〜15時 寝てる
• 15時〜0時 起きてる

でも、昔から昼に長く昼寝をする生活をしていたので、苦ではない。むしろ、自分は寝起きの時に集中力が高いので、そのタイミングが1日3回来ると考えれば効率がよいです。

そういえば、昨日僕が深夜作業しているのをCraigが知って、こうコメントしてました🔥

Burning the midnight oil with the flame of Hono

Hono

相変わらずHonoを作っています。Developer Advocateは自社のプロダクトと開発者をつなぐ役目なのですが、以下の三段論法でHonoをつくることは理にかなっています。

1. Honoを使うと、開発者はCloudflare Workersのアプリケーションを簡単に作れる。
2. 私がHonoを開発する。
3. 私は、開発者がCloudflare Workersのアプリケーションを作ることを手助けしている。

Honoはいまだ急成長をしており、GitHubのスターが今「14K」となっています。

また、これがすごい。各種フレームワークにはSvelteならcreate-svelte、Remixならcreate-remixというようにcreate-framework-nameというプロジェクトを初期化するためのCLIがあります。Honoにもcreate-honoというパッケージがあります。そのダウンロード数をグラフにするとcreate-honoがどんどん伸びていて、なんとcreate-solid、create-qwik、@angular/createを抜いている。

これからもガンガンいきます。

Workers Tech Talks

100%、Honoの開発をしているわけではありません。だいたい70%くらいで、残りの30%はイベントの開催、イベントの登壇、チュートリアルやデモ、ドキュメントの作成をしています。

その中でも「Workers Tech Talks」というイベントをやれたのは大きな成果です。これまで東京で2回、大阪で1回やりました。

Cloudflareの事業はセキュリティ、WAF、ゼロトラストなど多岐に渡るのですが、このWorkers Tech Talksは「Cloudflare Workers」及びその周辺のプロダクトに限った、開発者による開発者のためのイベントです。発表者は基本的に僕が声をかけます。彼らには事前に「『Cloudflare Workersとは？』という話はしないでください。聴いてる人を置いてけぼりにしてもいいです」と言います。一人あたりの時間は長くても20分。限られた時間の中で、初歩的な解説をいれるよりか、発表者が好きなことを好き勝手にしてもらった方が楽しいでしょ？置いてけぼりになった人には申し訳ないとはいえ「なんだか分からないが面白そう」という趣旨の感想をいくつかもらっており、企み通りです。

東京では1回目が100人、2回目が90人。大阪では25人の人が参加してくれてました。以下は大阪の時の写真です。

Ricky

去年の年末、東京でやった「Workers Tech Talks #2」に僕のマネージャーであるRickyがゲストとして参加しました。Rickyはちょうどアジア、オセアニアに出張で来ていて、そのタイミングに合わせてイベントを開催したというわけです。

Rickyと会うのは当然初めてです。しかもこれまでオンラインでもまともにふたりきりで話したことがない。そんな彼が東京へ来るとのことでもう会う前はめちゃくちゃ緊張してしまった。初対面の日にふたりでぎこちなく豊洲のチームラボプラネッツにいったのをよく覚えています。でも本当に会えてよかった！

以下はWorkers Tech Talks #2でみんなで撮ったお気に入りの写真です。

DevRel Team Summit

メンバーとは以前から「みんなで集まりたいね」と話していました。それがなんと先日叶いました！4月の頭に、USオースチンで「Developer Relations & Community Team Summit」が開催されたのです。他にもドキュメントチーム、開発よりのマーケティングメンバー、プロダクトマネージャー、エンジニアもいました。3日間、オフィスの会議室で話し合いをして、朝食にはタコスを食べて、コミュニティイベントに参加したり、ビデオを撮ったりしました。

とにかくみんなに会えてめちゃくちゃ楽しかった！それはそうです。1年間。人によっては入社前からオンラインで知ってる人たちにやっと会えたのですから！

マックフルーリー5つ

DevRel Team Summitの最終日の夜、一部のメンバーは「ディナー」に招待されていたのですが、Rickyを含めうちのチームのメンツ5人はあぶれてしまった。仕方ないので僕が「オースチンの寿司はうまいのか？」と言って寿司屋に行くことになりました。「KYOTO BEER」を頼んだら抹茶味のビールだったり、金目鯛になにかがぶっ刺さっていました。

その後、散歩しているとマクドナルドの話になりどうやらみんなマックフルーリーが好きらしいです。しかもオレオ味は世界共通。ところが、リスボンに住むベロニカが「ポルトガルのマクドナルドは緑色をしている。赤いマクドナルドを見たい！」と言います。そこで、みんなで車に乗り郊外にあるマクドナルドまで行きました。ドライブスルーで頼んだのは「マックフルーリー5つ」。みんなで車の中でマックフルーリーを食べるというシュールなことになり、そのエピソードが平和でとても気に入っています。

Sunil

4月5日にCloudflareはリアルタイムコラボレーションのプラットフォームをつくる「Party Kit」の買収を発表しました。

• Cloudflare acquires PartyKit to allow developers to build real-time multi-user applications

これは胸が熱い。

以前もCloudflareに所属し、Workersの開発環境であるWranglerのコードをバリバリ書いていたSunilは、Honoが無名だったころに「This looks like a pretty neat batteries-included framework for Cloudflare Workers! Nice work @yusukebe」とツイートしてくれて、それがとても励みになりました。

This looks like a pretty neat batteries-included framework for Cloudflare Workers! Nice work @yusukebe https://t.co/hnoknUIjds

— sunil pai (@threepointone) May 19, 2022

実はParty Kitを立ち上げた代表がそのSunilで、いよいよ同じ会社で働くことになったというわけです。

ドリームチーム

ETIのメンバーはみんな優秀だなーってつくづく思います。それはつまり優しくて、スキルがある。また、会ってみるとみんな想像していた以上に若く、ノリがよい。Cloudflareのプロダクトのアップデートはとても素早いのですが、このメンバーだからできることなんだと思います。そして、その一員でいれることを誇りに思います。

2年目も楽しんで働けそうです。

以下はDevRel Team Summitの時にオースチンの事務所で撮った写真。中の人っぽい！

すごい。数えてみたら21個のブログ記事がありました。各記事について雑な箇条書きをしてみます。

4/1 (月)

1. Welcome to Developer Week 2024

• https://blog.cloudflare.com/welcome-to-developer-week-2024
• まずはプロダクトディレクターのRitaから開始宣言
• Cloudflareのプラットフォームは200万人が使っている
• 5つの「Cloud」を提案する
• Full-stack Cloud、Connectivity Cloud、Experimentation Cloud、Demo to Production Cloud、Demo to Production Cloud - AI編

2. Making state easy with D1 GA, Hyperdrive, Queues and Workers Analytics Engine updates

• https://blog.cloudflare.com/making-full-stack-easier-d1-ga-hyperdrive-queues
• 1日目はデータベース周りのGA祭り
• D1、Hyperdrive、Workers Analytics EngineがGA！
• これでデータベース（D1、Hyperdrive）、オブジェクトストレージ（R2）、キュー（Queues）、Key-Value Store（KV）がプロダクションレディになりCloudflareの製品でフルスタックアプリが作れるようになった

3. Why Workers environment variables contain live objects

• https://blog.cloudflare.com/workers-environment-live-object-bindings
• Workersの中を作ってるKentonによるいわゆる「Bindings」についての超テクニカル記事

4. Building D1: a Global Database

• https://blog.cloudflare.com/building-d1-a-global-database
• D1のGAについての記事
• グローバルでパフォーマンスを発揮するためのリードレプリカ機能の提供
• 10GBのデータベース、バルクデータのインポート・エクスポート

4/2 (火)

5. Bringing Python to Workers using Pyodide and WebAssembly

• https://blog.cloudflare.com/python-workers
• 2日目はAI Day
• AIと相性のいいPythonでWorkersを書ける「Python Worker」の登場！
• これまでも自分でWASMを作ればよかったが、first-classでPythonをサポート。すべてのBindings、変数、Secretsを使える
• Fast APIやLangchain、httpxなども動く

つまりこのPythonコードが本当にWorkersで動きます！

from js import Response

async def on_fetch(request, env):
    # MY_KVというKVに値をput
    await env.MY_KV.put("bar", "baz")
    # 値をget
    bar = await env.MY_KV.get("bar")
    # Responseのボディに入れて返却
    return Response.new(bar)

6. Running fine-tuned models on Workers AI with LoRAs

• https://blog.cloudflare.com/fine-tuned-inference-with-loras
• Workers AI上でLoRAによるファインチューニング済みの推論が可能に
• LLlama2、Mistral、Gemmaのモデルが使える
• Hugging Faceのコレクションから互換性のあるLoRAアダプタを使うか、自分でアダプタを作る

7. Leveling up Workers AI: general availability and more new capabilities

• https://blog.cloudflare.com/workers-ai-ga-huggingface-loras-python-support
• Workers AIがGA！
• 各データセンターでGPUを導入しており、現在150都市以上に。今後も増える
• Hugging Faceと提携。Hugging FaceのWebサイトのモデルページから「Deploy to Cloudflare Workers AI」からコードをコピペできる
• LoRAを持ち込むことでファインチューンが可能に
• Python Worker！
• AI GatewayがAnthropic、Azure、AWS Bedrock、Google Vertex、Perplexityなどに対応

4/3 (水)

8. How Picsart leverages Cloudflare’s Developer Platform to build globally performant services

• https://blog.cloudflare.com/picsart-move-to-workers-huge-performance-gains
• オンライン写真エディタ「Picsart」がCloudflare WorkersとKVを使ってスケールした話

9. Data Anywhere with Pipelines, Event Notifications, and Workflows

• https://blog.cloudflare.com/data-anywhere-events-pipelines-durable-execution-workflows
• イベント・ドリブンのワークフローをWorkersで実現可能にしていく
• Pipelines - Apache BeamやFlinkなどのような大規模データをストリーミングで扱う。R2に書き込む。2024年の後半にオープンベータを提供する予定
• Workflows - Workers上で実行される耐久性のある（Durable Execution）ワークフロー。2024年第2四半期にはにオープンパブリックベータで提供したい

10. Improving Cloudflare Workers and D1 developer experience with Prisma ORM

• https://blog.cloudflare.com/prisma-orm-and-d1
• PrismaのDeveloper Advocateの人による寄稿記事
• PrismaがD1に対応！

11. R2 adds event notifications, support for migrations from Google Cloud Storage, and an infrequent access storage tier

• https://blog.cloudflare.com/r2-events-gcs-migration-infrequent-access
• R2の新しい3つの機能について紹介
• Event Notifications - R2のバケットの変更を自動的にWorkersにQueuesのキューで通知する
• Super Slurper for Google Cloud Storage - Google Cloud StorageからR2へ簡単に移行する
• Infrequent Access Private Beta - アクセスの少ないデータの支払いを少なくする

4/4 (木)

12. Cloudflare Calls: millions of cascading trees all the way down

• https://blog.cloudflare.com/cloudflare-calls-anycast-webrtc
• Cloudflare Callsがオープンベータ
• WebRTCを使って、リアルタイムのオーディオ・ビデオアプリケーションを構築可能になった
• Cloudflareネットワークを単一のSFU（複数のメディアを受信してどのストリームを転送するかを決定する）にすることで、複雑さを抽象化する
• これを使ったGoogle MeetsみたいなOrange Meetsというデモ

13. Announcing Pages support for monorepos, wrangler.toml, database integrations and more!

• https://blog.cloudflare.com/pages-workers-integrations-monorepos-nextjs-wrangler
• Pagesがモノリポをサポート！
• wrangler.tomlでPagesを設定できるようになった！これは地味に嬉しい
• Next on Pagesの改善

14. What’s new with Cloudflare Media: updates for Calls, Stream, and Images

• https://blog.cloudflare.com/whats-next-for-cloudflare-media
• Cloudflare Calls、Stream、Imagesのアップデートの紹介
• Cloudflare Calls - オープンベータ
• Cloudflare Stream - ビデオを再エンコードすることなくストリームからクリップをして共有できる「Live Clipping API」のオープンベータ
• Cloudflare Images - 少しのコードだけであなたのアプリと統合できるアップロードウィジェット。人の顔の画像を拡大縮小してトリミングし、リサイズすることができる「Face Cropping」。どちらもクローズドベータ

15. New tools for production safety — Gradual deployments, Source maps, Rate Limiting, and new SDKs

• https://blog.cloudflare.com/workers-production-safety
• Cloudflare Workersの運用のための新しいツールの紹介
• Gradual Deployments - いわゆるローリングデプロイメントがWorkersでも利用可能なった！オープンベータ
• ソースマップスタックトレース - Tail Workersでのトレースがソースマップに対応。wrangler.tomlでupload_source_maps = trueにする
• Rate Limiting API - Workersから直接レートリミットが可能に。ratelimitというBindingsになる。オープンベータ
• TypeScript、Python、Goの3つの言語でCloudflare API向けのSDKを提供
• WebSocketハイバネーションのGA

Rate LimitingをHonoのミドルウェアで使うにはこのように書ける。

app.use(async (c, next) => {
  const { success } = await c.env.MY_RATE_LIMITER.limit({ key: c.req.path });
  if (!success) {
    return c.body(`429 Failure - rate limit exceeded for ${c.req.path}`, 429);
  }
  await next();
});

ちゃんと動いて感動〜。

4/5 (金)

16. Community Update: empowering startups building on Cloudflare and creating an inclusive community

• https://blog.cloudflare.com/2024-community-update
• Workers Launchpadプログラム、Cohort #3の紹介。Cohort #4の募集
• Dev.toがWorkers AIを利用したアプリケーションを対象としたAI developer challengeを開始
• Discord、コミュニティフォーラムで利用されるCode of Contactの作成

17. We’ve added JavaScript-native RPC to Cloudflare Workers

• https://blog.cloudflare.com/javascript-native-rpc
• WorkerとWorker、WorkerとDurable Objectを通信するための新しいビルドインのRPCの紹介
• いわゆる「Bindings」のようにもう一つのWorkerを扱える
• Classを作って定義し、利用する側に型が提供される

このコード例だと右側がCalcっていうサービスで、左側がそれを利用する側。Calcは特化したの処理を行うWorkerになっている。 適切に設定してあげるとそれをenv.CALCといった他のBindingsと同じ方法でアクセスできる。 しかも、工夫次第でaddにTypeScriptの型が付く。

18. Blazing fast development with full-stack frameworks and Cloudflare

• https://blog.cloudflare.com/blazing-fast-development-with-full-stack-frameworks-and-cloudflare
• 各種フレームワークを使ってCloudflare Pages、及び周辺プロダクトでフルスタックアプリケーションをつろう
• これまでBindingsや変数をとることが難しかったがWranglerの新しいAPIのおかげでできるようになった

19. Cloudflare acquires PartyKit to allow developers to build real-time multi-user applications

• https://blog.cloudflare.com/cloudflare-acquires-partykit
• Cloudflareがリアルタイムマルチユーザーアプリを作るプラットフォーム「PartyKit」を買収！
• 個人的に胸熱
• PartyKitは元Cloudflareで以前のWranglerをバリバリ書いてたSunilが立ち上げてる会社。当時無名だったHonoのことを取り上げてくれてそれが励みになった。そんな彼らがCloudflareにジョインする！

20. Browser Rendering API GA, rolling out Cloudflare Snippets, SWR, and bringing Workers for Platforms to all users

• https://blog.cloudflare.com/browser-rendering-api-ga-rolling-out-cloudflare-snippets-swr-and-bringing-workers-for-platforms-to-our-paygo-plans
• Workersでヘッドレスブラウザが使える「Browser Rendering API」がすべてのWorkersのPaidカスタマーに開放！
• JavaScriptのショートピースでCDNの挙動を書けるCloudflare Snippetsが徐々に利用可能に
• Stale-While-RevalidateのComing soon

21. Cloudflare acquires Baselime to expand serverless application observability capabilities

• https://blog.cloudflare.com/cloudflare-acquires-baselime-expands-observability-capabilities
• ワンモアシング
• Cloudflareがオブザーバビリティプラットフォーム「Baselime」を買収！
• プライシングが「Completely Free」

連絡事項

自己紹介しておくと、僕はCloudflareのDeveloper RelationsチームにいてDeveloper Advocateをやってます。 一方で、HonoというCloudflareのみならずDenoやBun、Fastly等で動くWebフレームワークを開発してます。

Cloudflare Workersとは？

本題に入る前に、そもそも「Cloudflare Workersとは？」を簡単に紹介しておきます。

Cloudflare WorkersとはCloudflareのエッジで動くサーバーレス環境です。 基本的にJavaScript/TypeScriptでアプリケーションを書きます。 V8というJavaScriptエンジンの上でアプリを動かすのですが、これはWebブラウザのGoogle Chromeに搭載されているものです。 感覚としては、Chromeのタブが開く感じで、Workers上のアプリが立ち上がります。 JavaScriptと言ってもNode.jsではなく、ブラウザでも動く標準的なAPIを使います。 開発、デプロイにはWranglerというCLIを使います。

…というのがダイジェストです。

ではいってみよう！

Cloudflare Pagesとの統合

Cloudflare Workersの他にPagesというのがありまして、一般的にはNext.jsやAstroなどのフレームワークを用いて「フルスタック」なアプリケーションを作るプラットフォームです。 以前はWorkersとPagesは明確に分かれていたのですが、それが統合されつつあります。

Pagesはもともと静的なページをホストするのが主なユースケースだったのが、「SSR」というキーワードから分かる通り、ダイナミックな処理が増えてきました。 そのPagesのダイナミック処理はWorkersで動いているので、その境界線が曖昧になるんですね。

実際、ダッシュボードではWorkersもPagesも同じセクションになりました。

なので、我々がCloudflare Workersと呼ぶ時にはCloudflare Pagesも含むケースが多いです。

C3 - create-cloudflare-cli

C3というのができました。これは「Create Cloudflare CLI」の頭文字をとってC3です。 Cloudflareには以前から「D1」というSQLデータベース、「R2」というストレージを持っていて、今度は「C3」です。洒落ていますね！

これはCloudflare Workers/Pagesのアプリケーションを簡単に作れるCLIです。 「Hello World」のベーシックなものから、フレームワークを使ったものまで対応します。Honoも入っています。 使いたい方は以下を実行してみてください。

npm create cloudflare@latest

面白いのは、このC3は内部で各フレームワークの「create xxx」を実行していて、つまり「メタCLI」になっている点です。 例えばHonoでは「create-hono」というパッケージがあって、以下のコマンドで雛形を作成することができます。

npm create hono@latest

他にも、create-astro、create-next-app、create-solid、create-qwikなど各フレームワークにはたいてい「create xxx」があります。 それらをラップしつつ、Cloudflareならではの機能が入ります。面白いのは、プロジェクトを作成したあとに「デプロイしますか？」と聞かれることで、「Y」を選ぶといつの間にかデプロイできてしまうという素晴らしいCLIになっています。

使いやすく、ダウンロード数も伸びています（ありがたいことにcreate-honoも伸びてます！）。

Cloudflare Workers初めての人は触ってみてください！

30秒でデプロイまでできる！

Cloudflare Workersを触った人が一様に言うのが「デプロイが速い」です。 相変わらず速いです。

下のGIF動画はC3を使ってHello Worldのアプリをローカルでつくり、デプロイまでする様子です。 早送りなしの実速度です。 この方法が一番最短なんですが「30秒！！」でできてしまいます。

もう一度繰り返します。30秒でアプリケーションの作成からデプロイまでできます。 これはひいきなしにすごいと思います。

workers.new

Cloudflare WorkersをWebのUIで試して、デプロイまでできちゃうPlaygroundがあります。 これが素晴らしく、ライブラリが使えないという制約がありますが、簡単に試すには十分です。

で、実は「workers.new」というアドレスにアクセスするだけでそのPlaygroundが開きます。 オシャレでしょ？それもそのはずこれは僕が考案しました。はっはっは。

AIめっちゃ頑張ってる

AIめっちゃ頑張っています。

CloudflareのAIに関する製品は2種類あって、Workers AI（とVectorize）とAI Gatewayです。

Workers AI

Workers AIは、Cloudflare WorkersのアプリケーションからAIの推論ができてしまうという代物。 テキスト生成だとMeta社のLlama2やMistral 7Bなどのモデルが使えます。 興味深いのは、このAIを実行するために各エッジにGPUを載せているということです。 すでに日本を含むデータセンターに配置されて、その数は増えていく予定です。

AIを使うのは非常に簡単です。 Bindings（CloudflareのKV、R2、D1などのミドルウェア、もしくはWorkersをつなぐ概念）の一種として使えます。また@cloudflare/aiというパッケージもあります。

では実際に簡単なWorkers AIアプリを作ってみましょう。といっても3ステップです。

まずC3で作ったHonoのプロジェクトに@cloudflare/aiを追加します。

npm i @cloudflare/ai

次に、Wranglerの設定ファイルwrangler.tomlにBindingsの指定をします。

[ai]
binding = "AI"

あとはコードを書くだけ。以下の17行のコードで/にアクセスすると、Llama2のテキスト生成が走るWebアプリができました！

import { Hono } from 'hono'
import { Ai } from '@cloudflare/ai'

const app = new Hono()

app.get('/', async (c) => {
  const query = c.req.query('query') ?? 'Cloudflare'
  const ai = new Ai(c.env.AI)

  const response = await ai.run('@cf/meta/llama-2-7b-chat-int8', {
    prompt: `Describe about ${query}`
  })

  return c.json(response)
})

export default app

他にWorkersから操作できる「Vectorize」というベクターデータベースもあります。 バックエンドのストレージにR2とD1が指定できるので、Cloudflareならではのスタックを作れます。

AI Gateway

これも面白い製品です。 OpenAIやAmazon Bedrock、HuggingFaceなど、外部のAIプロバイダーへのアクセスのためのゲートウェイです。 これを経由すると、それらのプロバイダーへのAPIアクセスに、リアルタイムログやレスポンスのキャッシュ、レートリミットなどを追加することができます。

使い方は簡単で、例えばOpenAIの場合、SDKのベースパスにAI Gatewayのものを指定してプロキシさせればいいです。

const openai = new OpenAI({
  apiKey: c.env.OPENAI_API_KEY,
  baseURL: 'https://gateway.ai.cloudflare.com/v1/ACCOUNT_TAG/GATEWAY/openai'
})

例えば、AI系のAPIは叩くのに料金が高いという課題がありますが、このAI Gatewayのキャッシュやレートリミットは活きることでしょう。

ユースケース

Cloudflare Workersを使う企業も増えてきています。

Workersを導入しやすいのはオリジンありきのCDNの前段に置く、というユースケースです。 例えば、ヘッダを書き換えたり、パスによってオリジンを振り分けたり、署名付きURLを発行したりといったものが考えられます。

一方、Workersプラットフォームの進化とともにオリジン自体をエッジに置くところもでてきました。

例えば、その最たる例がchimameさんのケースで、GCP Cloud Runで運用していたGraphQLのAPIサーバーをCloudflare Workersに丸ごと載せ替えたというものです。

以下のスライドが詳しいです。

• https://speakerdeck.com/chimame/graphql-server-on-edge
• https://speakerdeck.com/chimame/graphql-server-on-edge-after-that

これによると、移行したメリットとしては

• コンテナに比べてデプロイの時間が8分前後から1分前後に短縮
• コールドスタート、最大5秒から200ミリ秒程度まで高速化
• サーバー費の低下

があったとのことです。

一方、デメリットとして

• Node.jsが動かないので、必要な場合は別途サーバーを用意しなくてはいけない
• ログを取るのが大変

などがあることです。

彼に直接話を聞くと概ね満足している様子です！

また、国内だとcodehexさんのところの「NOT A HOTEL」も事例として語られています。

他にも事例があるのですが、僕がまだ把握してきれてないものもたくさんあると思います。 見つけて「こんなこともできるよ」というのを発信していきたです。

getPlatformProxy()

具体的な実装の話を少し。 Cloudflare Workers/Pagesのアプリケーションを作るにあたって、開発環境でBindingsを再現するのは課題です。 特に、フレームワークを使うとそのフレームワークの開発サーバーを使うことになりますが、そこにBindingsを注入するのがなかなか難しいです。 これをCloudflareの中の人たちは問題視していて、向上しようとしています。 その一つがWranglerのgetPlatformProxy()という最近できたばかりのAPIです。 これを使うとこれまで、Wranglerで立ち上げたアプリでしか参照できなかったBindingsですが、Node.jsからアクセス可能になります。 例えば、以下のスクリプトをNode.jsで実行するとWorkers AIが動きます（と言いつつ、今バグがあるので動かないのですが、すぐに修正されて動きます！）。

import { getPlatformProxy } from 'wrangler'
import { Ai } from '@cloudflare/ai'

const proxy = await getPlatformProxy()
const ai = new Ai(proxy.env.AI)

const answer = await ai.run('@cf/meta/llama-2-7b-chat-int8', {
  prompt: 'What is the origin of the phrase Hello, World'
})

console.log(answer)

proxy.dispose()

すると何が嬉しいかというと、各フレームワークの開発サーバーで使えば、Node.jsベースの開発サーバーでもBindingsにアクセスできるようになります。

また、昨今フレームワークで多く使われている、開発ツールの「Vite」側のアプローチもあります。 Node.jsの環境しか提供していなかったのが、Cloudflareなどの外部のランタイムを持ってこれるようなRuntime APIというのができたのです。

この2つはなかなかでかい出来事で、開発者体験を一気に向上させることになります。

DevRelチーム

僕が所属しているのはDeveloper Relationsチームです。 日本ドメスティックなものではなく、マネージャーのRickyがニューヨーク、他のメンツはリスボン、アムステルダム、サンフランシスコ、オースティン、メルボルンと多岐に渡ります。 今はメンバーが10人になったのですが、以下の画像はちょっと前のものです。時差パネェ。

そのチームに去年の年末、ふたり「Educator」という新設されたロールのメンバーが入りました。 彼らの専門部やはずばりAIで、やはりそれだけAIに力を入れているし、入った途端、精力的に活動していて、成果がでるのが楽しみです。

DevRelチームは去年、僕が4月に入社する1ヶ月前にRickyが入ってチーム体制が整いました。 メンバーが点でバラバラのところにいるので会うのめちゃくちゃ難しかったのですが、ようやく次の4月にみんなが集う初めてのチームミーティングがオースティンで行われます！ 僕にとっては初めての海外出張になって、Rickyを除くメンバーは会ったことがないのでドキドキですが楽しみです。 このミーティングを期に我がチームの勢いも加速するでしょう。

イベント

最後に僕がやっているイベントについて。

「Workers Tech Talks」というCloudflare Workersに特化したイベントをやってます。 東京ではこれまで2回やって、上記したchimameさんのトークとか話してもらいました。 それぞれ100人弱の参加者で、大盛況です。今後も続けていきます。

さて、実は来週の月曜日2/26に「Workers Tech Talks in Osaka #1」と題し、大阪版を開催します！ ギリギリまだ参加者募集中なので、来たいという方は早めに以下のページから申し込んでください。

https://workers-tech.connpass.com/event/308872/

まとめ

以上、最近のCloudflare Workersについてざっくばらんに書いてみました。 もっと突っ込んだ話題を知りたければ、イベントなどで僕ができる紹介するし、他のCloudflare Workers使いの人たちからも有益な情報を得られるでしょう。 また、あなたがCloudflare Workersを使っていて、事例を持っているなら、教えてほしいです。 そして、まだCloudflare Workersを触ったことがない人はC3コマンドを使ってデプロイまでやってみてください！ きっと楽しいと思います。

ブログを書くまでがYAPC

ってことでYAPCを終わらせにかかります。ざっくばらんに書きます。

開催前

「最高の広島の夜にしようぜ！」

YAPCは素晴らしいので、どうせなら行ったことのない人に来てほしいと思っていた。 なので、いろんな人に声をかけた。何人か僕の紹介で来ていた。 アフィリエイトプログラムがあればバックをもらうべきだと思う。

誘う時の謳い文句に

最高の広島の夜にしようぜ！

って言いまくって、すごい良いフレーズだと思うんだけど、 すずきそうすけ君からは「怖い」と言われてしまったが、来てくれたのでよかった。

胃炎

YAPCに行く2日前の夜に途中起きたら異様にお腹張って、気持ち悪くなった。 「これはヤバい」とその日一日寝てても治らないし、ぜんぜんお腹減らないので「これはすげえヤバい」とより思って、病院に行った。「明後日のイベントいけますかね？」と先生に聞くと

ウィルス性じゃないからいけますよ。プレゼンやるんですよね。それストレス性の胃炎ですよ。

と言われた。ストレス性胃炎も胃炎もなったことがなかったのでよっぽどYAPC、もしくはHono v4のリリースが心理的負担だったのだ。もらった薬を飲んだら翌日にはすっかり治ってよかった。

0日目 - 前夜祭

Hono v4リリース

偶然にも前夜祭の2月9日はHono version 4.0.0のリリース日であった。 ホテルについたら早速リリースした。準備していたのでコマンド一発で済んだ。 このリリースはかなり話題を呼んで、Hackers Newsに載ったりした。 HonoXという新しいFile-basedルーティングのメタフレームワークも登場した。 まだアルファステータスで未熟で、使ってもらって早速不具合、改善点が多く報告されていてるので、対応していきます。

Hono Meetup #2

偶然にも前夜祭の直前に「Hono Meetup #2」が行われた。 11人登録で、11人が来たので、Honoコントリビューターもしくはユーザーは真面目だと思った。

前夜祭「Hono v4」

前夜祭の初っ端、自分の発表である。「Hono v4」という題目だ。

YAPCのプロポーザルはこのHonoのやつとエモめのトーク2つを提出していたのだが、落ちてしまった。 エモ目のは「狙いに行った感」が強くて反省をしている。 とはいえ、「Hono v4」のトークを前夜祭でやれて、それだと一番大きいホールでたっぷり人がいる中発表できたので結果的によかったのかもしれない。

今回のYAPCのテーマは「お好み」で、 偶然にも大好きなフレームワーク「Hono」を紹介するのはテーマに沿っていた。 特定のプロダクトについてのプレゼンだと興味がない人には全く響かない可能性があったが、なるべく「楽しそうに」話した。 内容もHonoの好きなところを矢継ぎ早に紹介できたので、自分としてはかなり濃いトークができたと思う。

感想は上々で、今まで使ったことがない人も使ってみようと思ったと言ってくれた。 これから懇親会で人と話すキッカケになった。

そーだいさん幹事

くしいさんプロデュース、そーだいさん幹事で数名とあなごしゃぶしゃぶができる料亭にいった。 力喜という店である。

くしいさん曰く、

もういい年なので、多少高めでもいいから美味いもん食いたい

というコンセプトが功を奏した。広島が地元のそーだいさんが広島在住の友達に聞いて見つけたという店はめちゃくちゃ美味かった。 あなごのしゃぶしゃぶを含め、あなごの刺し身、白子、意味わかんない牡蠣の天ぷら、コウネとめちゃくちゃ美味かった。

1日目 - 当日

会場

会場よかった。平和記念公園がその名の通りのんびりとしてて平和で好きな雰囲気だった。

セッションと廊下

あんまりセッションを真面目に聞いてなかったので、感想は割愛します。

廊下よかった。途中でビールが投入されたりYAPCっぽかった。

遺言パネルセッション

なおやさん、t_wadaさんと出演した遺言のセッションもよかった。

当初、「各自10分なんかしら発表する」時間があったんだけど、明らかにパネルセッションの価値が高いので、直前だったけど僕から「10分なしにしてフルフルでパネルやりましょう」とお願いしてそうなったのがよかった。

実はなおやさん、t_wadaさんと話す機会って少なくて、あの場で話せてよかった。

LT

「AI Webcam」という題目でLTした。詳しくは以下を参考にしてください。

https://yusukebe.com/posts/2024/ai-webcam/

見事、ベストLT受賞！

これで、

• ベストトーク賞 x 2
• ベストLT x 1

を獲ったことになり、もう手にいれてないものはない状態になった。はっはっは。

でも来年もどちらか、もしくはどちらも狙っていきたい。そーだいさんには負けない。 パネルでも「若者に登壇してもらいたい」みたいな趣旨の話しをしたくせに、おじさんが頑張ってるのウケる。

懇親会

懇親会すごいよね。300人が参加したらしい。 YAPCはこうでなくちゃってやつだ。

初参加の人が多かったので、その人たちがここで仲間をつくるといいなと思った。 知り合い同士で集まっていると知らない人と知り合うチャンスを不意にしてしまうので、なるべく知らない人と話す。

Honoユーザーがかなりいて、嬉しい。 今度大阪で、Workers Tech Talksをやるんだけど、そこで発表してもらう人をゲットできたのが印象的だ。

YAPCとは

「YAPCとは？」ってことをなんとなく考えてたんだけど、この2つだと思う。

• 仲間と会う場所
• 発表できる舞台

飯

飯うまかった。

AI Webcam

AI WebcamはWebcamでとった写真についてAIが音声で返答してくれるというものです。AIのキャラクターというか音声は指定可能です。また文章のプロンプトでどのように返答するかも指定できます。

例えば、アメリカの若い女性「レイチェル」に自分の容姿を褒めてもらった時の大爆笑映像はこちらです。

元ネタ

実は元ネタがあって、Wes Bosというポドキャスターがやってたのを真似てます。コードも公開されているので、それを使わせてもらってます。みなさんもできます。

YAPCでLT

あまりにも面白いので、先日のYAPC::HiroshimaのLTでこれを応用したものをデモしました。レイチェルだけを流しても尺が余るしインパクトにかけるので、YAPCっぽく「dankogai」さんと「papix」をAIにしました。

UIはこんな感じです。

例えば、「papix、私を褒めて！」というボタンを押すと、papixの音声でpapixのAIが僕のことを褒めてくれます。これ、すごいのはpapixもdankogaiさんも彼ららしい、言葉遣いをすることです。

模様です。uzullaさんが撮ってくれました。これ、dankogaiさんじゃなくてdankogaiさんのAIが喋ってます。まじで。

仕組み

流れです。

1. Webカムで写真を撮る
2. その写真とプロンプトをOpenAI「gpt-4-vision-preview」に送る
3. 返ってきたテキストをElevenLabsの「Text to Speech」に送る
4. 返ってきたオーディオファイルを再生する

簡単でわかりやすい仕組みです。

今回のLTでおもしろおかしくできた肝はdankogaiさんとpapixがかなり似てたことです。そのために2つのことをしました。

1. 音声をその人にする
2. プロンプトを調整する

1. 音声をその人にする

今回「Text to Speech」に使ったElevenLabsのAPIが面白いです。レイチェルの声は一般に公開されているもので、誰でも使えます。一方、dankogaiさんとdankogaiさんの声は自分で作りました。音声ファイルをアップロードするとそれを解析、学習してその人の「音声」になります。ありがたいことに彼らはイベントでよく登壇していてその動画がありますので、そこから音声を抽出します。アップできるファイル容量は10MBまでなので、5分くらいの動画がギリギリいい感じでした。そこで発行されたIDをAPIのリクエスト時に指定するとそれが使われる仕組みです。この「音声」は自分だけしか使えず、僕のダッシュボードには 「僕だけの」dankogaiさんとpapix の「音声」がいます。

これが学習時間が短いのに、相当似ています。

2. プロンプトを調整する

音声がその人になっただけでは、ちょっと物足りなかったです。なので、「Text to Speech」に渡すテキストをそれっぽくするために、OpenAIに生成させるためのプロンプトを調整します。

OpenAIの「gpt-4-vision-preview」では以下のようにAPIをコールすることになります。

const chatCompletion = await openai.chat.completions.create({
  max_tokens: 800,
  messages: [
    {
      role: 'system',
      content: voice.system
    },
    {
      role: 'user',
      content: [
        {
          type: 'text',
          text: voice.user
        },
        {
          type: 'image_url',
          image_url: image
        }
      ]
    }
  ],
  model: 'gpt-4-vision-preview'
})

このvoice.userのテキストがプロンプトにあたります。それをこのようにしました。まず、全部貼り付けます。

const prompts = {
  papix: {
    name: 'papix',
    system: `あなたは優秀なエンジニアです。あなたは写真の人物について褒めます。`,
    user: `あなたは写真の人物について説明します。彼の容姿の特徴について褒めてください。「超」と「すげー」「めっちゃ」「まじで」という言葉をたくさん使ってください。テンション高めに。`
  },
  dan: {
    name: 'dan',
    system: `あなたはベテランのエンジニアです。あなたは写真の人物についてたくさん褒めます。`,
    user: `あなたは写真の人物について説明します。彼の容姿の特徴について褒めてください。プレゼンをしているようにしてください。冒頭に「えー」という言葉、語尾に「はい」を使ってください。`
  }
}

ここでのポイントは

• papix - 「超」と「すげー」「めっちゃ」「まじで」という言葉をたくさん使ってください。
• dankogaiさん - 冒頭に「えー」という言葉、語尾に「はい」を使ってください。

ってところで、これが彼ららしくしています。

ベストLT賞とった

結果、大爆笑を誘い、結果、ベストLT賞をもらいました。

メガネもらいました。

分配

賞撮った時の挨拶でも言ったのですが、これはまじでdankogaiさんとpapixのおかげです。賞品を分配しないといけないです。

.@__papix__ が右目、ワシが左目、残ったフレームが @yusukebe のものってことで #yapcjapan https://t.co/iFXk0Z2DDZ

— Dan Kogai (小飼 弾) (@dankogai) February 10, 2024

備考

当然ですが、dankogaiさんとpapixには事前に許可をもらってました。

感想

これ、面白いのですが、ふたりのAIが喋ったのがコンテンツになってるのはある意味怖くて、発表してる最中に「俺何もしてないし、むしろdankogaiさんとpapixが頑張ってる」って考えてちょっとゾクゾクしました。

あとは受賞の時に言ってもらったのですが、昔僕がやってた「なんたらDetect」と似たように新しい技術をコミカルに応用できたというのはよかったのではないでしょうか。

誰かをAIにする場合は許可をとるなり考慮しつつ、みなさんも試してはいかがでしょうか。

Honoの「Initial commit」からおおよそ2年が経ちました。このプロジェクトは2021年の12月15日に始まりました。

当初、私はCloudflare WorkersのみのためにHonoを作りました。itty-routerはよかったものの、私が欲しかった多くの機能が欠落していました。また、私は勉強のためにTrie木構造のルーターを作りたかったのです。それがHonoの生まれた理由です。

それから多くのことが起こりました。私がCloudflareにいるのもHonoのおかがです！HonoはCloudflare開発者コミュニティで認知されていきました。Honoの人気が出ることで、DaneとGlenが私に連絡をくれました。Honoは私の人生を変えました。

しかし、今、Honoはとても多くの開発者のものとなっています。この記事では、Honoの現在の状況をまとめます。

Honoとはなにか？

Honoのキャッチフレーズはこれです。

速い, 軽い, Web標準

これがHonoの全てを表現しています。

HonoはCloudflare Workersのためのフレームワークの中で1番速いです。さらに、Cloudflare Workers、Fastly Compute、Deno、Bun、Node.jsといったどんなJavaScriptランタイム上で動きます。これらの環境でも他の高性能なフレームワークと比べても1番速いものの一つです。

備考1: Node.js上ではNode.jsのincoming/outgoing messagesをWeb標準のAPIを橋渡しするためのアダプタが必要になるために、オーバーヘッドが発生します。それゆえ、Node.js上ではHonoは遅くなります。例えば、速いとされているフレームワーク、Fastifyよりは遅いです。しかし、Expressよりは速いです。しかし、改善するための可能性はあり、HonoはFastifyに近づくかもしれません。

備考2: この記事を書いたのち、Node.jsアダプタで大幅は改善が行われました。ベンチマーク次第ではFastifyと同程度のパフォーマンスでるようになりました。また、Expressより3倍速くなりました。

HonoはMinifyしてバンドルしたサイズは20.7KB（2023年12月20日現在は21.7KB）とすごく小さいです。比較するとExpressは573KBです。

HonoはWeb標準のAPIのみを使っていて、それがサイズを小さくしています。また、このアプローチはHonoがFastlyやDeno、Bun、さらにはブラウザ（！）上で動くことを可能にしています。Web標準のAPIに注目したはHonoのとても興味深い一面です。

GitHubのスター

OSSソフトウェア、コミュニティにとってGitHubのスターは重要な指標です。Honoは他のフロントエンドのフレームワークには敵わないものの、いい位置につけています。Honoは8,700のスターを獲得しています（2023年12月現在では9,400）。比べるわけではありませんが、例えば、itty-routerは1,400スターです。しかし、他のフレームワーク、例えばRemixは25,000スターで、そのレベルに達していません。しかし、私達はそこへ近づくことができると思っています。

図は2023年12月20日のもの。

誰がHonoを使っているか？

今、多くの開発者がHonoを使っています。

一番最初は、cdnjsがAPIサーバーとしてCloudflare Workers上でHonoを使いだしました。似たようなJavaScriptファイルをCDNで配信するPolyfill.ioもFastify Compute上でHonoを使っています（現在はRustベースへ移行しました）。刺激的なのはDenoが公式のドキュメントサイトDeno DocsでHonoを使っていることです。一方、最近出てきたJavaScriptのランタイムBunではHonoをExpressやKoaと並ぶフレームワークとして、彼らのYouTubeビデオで紹介しています。

私はHonoのGitHub Discussionで「Who is using Hono in Production?」というアンケートのようなものをとりました。すると多くのユーザーがコメントしてくれました。

• Nodecraft
• Ponder.ly
• SticAI
• Skill Struck
• Reejs
• toddle
• LanderLab
• OpenStatus
• Loglib
• AI.LS
• Equator Analytics
• ExpenSee
• DolarApi.com
• UseScraper
• Say My Name

こんなにたくさん！これらはCloudflare Workers、そしてNode.js/Bun/Denoを使っています。作者冥利に尽きます。

備考: Cloudflare社内でもWorkers SDK他、D1でも使われています。

どこでも動くことはいいことだ！

あなたはこう思うかもしれない。

HonoはCloudflareだけのものじゃないの？なぜCloudflareの従業員が他のプラットフォームでも動くHonoを作っているの？

とてもいい指摘です。しかし、HonoがCloudflare Workers以外のランタイム上で動くことは大きな利点をもたらしています。私達がバージョン「2.0.0」をリリースする時、私はHonoをDenoに対応させるかという問題に直面しました。私達はDenoをサポートすることを選択し、それがとても有益でした。複数のランタイムで動くことはHonoを有名で安定したものにしました。多くの人に使われることで多くのバグを発見でき、ソフトウェアの品質を上げることになるのです。

v3.*の機能

Honoでは他のフレームワークにあるような一般的な機能を提供しています。例えば、ルーティング、リクエストとレスポンスの扱い、JSONやHTMLを返す、ミドルウェアをつかう、Bindingsや環境変数を扱う、などです。

それに加え、小さなサイズを保ちつつ、パフォーマンス劣化せずに、新しいユニークな機能を使うことができます。そこで今回は、今年の2月18日にv3.0.0として導入された機能から、現在の11月13日にリリースされたv3.10.0のものまでを紹介していきます（2023年12月20日現在はv3.11.8が最新）。

v3.0.0 - 2023/02/18

• HonoRequest
• RegExpRouter becomes the fastest router
• Good-bye StaticRouter
• New Validator
• RPC
• Adapter
• Multi-runtime CI Support
• Support WinterCG Runtime Keys
• create-hono
• @honojs to @hono

RegExpRouterは1番速いルーターになった

Honoの中で使われいてるルーターの一つRegExpRouterがJavaScript界で1番速いルーターになりました。

新しいバリデーター

とても薄くなりました。ZodやValibot、TypeBoxなどの外部のバリデーターを使うようにしました。賢いタイプヒントも提供しています。

RPCモード

クライントオブジェクトを作るためのhc()を導入します。サーバーサイドとクライントサイドでTypeScriptの型を「APIの仕様として」共有することができます。このアプローチはtRPCと似ていますが、それより気軽に実装することができます。

v3.1.0 - 2023/03/17

• Improve RPC-mode
• env() for getting environment variables for multi-runtimes
• AWS Lambda Adapter
• basePath()
• c.req.path
• Allow passing RequestInit to c.json() etc.

マルチランタイムで環境変数を取得するためのenv()

env()を使うとどのラインタイムで実行されているかを意識せずに透過的に環境変数を取得することができます。

v3.2.0 - 2023/05/19

• New Routers
• Presets: hono/tiny, hono/quick
• app.mount()
• Node.js adapter server v1.0.0 has been released
• Support for routing includes a hostname

新しい2つのルーター

新しい2つのルーターを導入します。まずLinearRouter。これはルーティングの登録が1番速いです。次に1番サイズが小さいPatternRouterです。

これにより我々は以下の5つのルーターを持つことになります。

• TrieRouter
• RegExpRouter
• SmartRouter
• LinearRouter
• PatternRouter

プリセット: hono/tiny、hono/quick

典型的なユースケースのために複数のルーターを組み合わせたプリセットを作りました。

• hono/tiny
  • PatternRouterのみを仕様
  • すごい小さい
  • アプリケーションのサイズはminifyして14KB
• hono/quick
  • LinearRouterとTrieRouterの組み合わせ
  • ルートの登録が1番速い

app.mount()

itty-routerやRemixなどを使ったfetch APIに基づくアプリケーションならどんなものでも、マウントできます。

Node.jsアダプタがv1.0.0に

Node.jsアダプタの最初のメジャーリリースです。Node.jsネイティブのWeb標準APIのみを使うようにしました。すると外部のfetchライブラリをポリフルしていた以前と比べて、非常に小さくなりました。

v3.3.0 - 2023/07/11

• Server-Timing Middleware
• Lambda@Edge Adapter

v3.4.0 - 2023/08/08

• Netlify Adapter
• Cookie Middleware supports Signed Cookies

v3.5.0 - 2023/08/21

• Secure Headers Middleware
• Introduce “Helpers”
• Zod OpenAPI Hono

ヘルパーの導入

ミドルウェアとはまた別でヘルパーは便利なメソッドを提供します。現在あるヘルパーは以下です。

• Adapter
• Cookie
• Factory
• html
• JWT
• Streaming
• Testing

備考: 2023年12月20日にはこれに加え、Devヘルパーがある。

Zod OpenAPI Hono

“Zod OpenAPI Hono"はOpenAPIをサポートするHonoのラッパーです。以下に使い方を紹介します。

1. Zodでスキーマを書く

2. ルートを作る

3. アプリにする

4. OpenAPI/SwaggerのドキュメントをJSONとして出力するようになる

5. Swagger UIミドルウェアと組み合わせることができます

v3.6.0 - 2023/09/11

• Introduce c.render()
• Introduce c.var
• FC for JSX
• $url() in Hono Client
• Vite dev-server for Hono
• Deprecate some properties in HonoRequest
• Replaced Jest with Vitest

c.render()の導入

レイアウトを使ってHTMLのレスポンスを簡単に返すことができます。

HonoのためのVite dev-server

hono/vite-dev-serverはHonoを開発するためのカスタムDevサーバーをViteのプラグインとして提供します。これを使うとフロントエンドも含んだ素早いリロードと共にHonoのアプリを開発できます。Cloudflare Bindingsもサポートしています。

v3.7.0 - 2023/09/21

• c.stream() and c.streamText()
• Testing Helper
• JWT helper

c.stream()とc.streamText()

Honoはストリーミングをサポートしました。これとOpenAIで使われているOpenAPIもあるので、Honoは"AI Ready"であると言えます。

v3.8.0 - 2023/10/19

• JSX Context API
• JSX Renderer Middleware
• Streaming Helper
• Factory Helper
• parseBody() supports multi values
• Improve path matching in the router

JSX Rendererミドルウェア

HonoのJSXを使ったレイアウトの定義を簡単にします。ReactのuseContext()と似たような機能、useRequestContext()を使ってContextオブジェクトにアクセスできます。

Streamingヘルパー

streamSSE()を通じてServer-Sent-Eventのレスポンスを簡単に返せるようになりました。

v3.9.0 - 2023/10/27

• Improving the Developer Experience for JSX
• Clerk Middleware
• New Starter Template for Cloudflare Pages

JSXの開発者体験の向上

HonoのJSXのタグに型が追加されました。これでエディタの自動補完と共にJSXを書くことができます。

Cloudflare Pagesのための新しいスターターテンプレート

Cloudflare Pagesのスターターテンプレートが@hono/vite-dev-serverを使った新しいものになりました。

v3.10.0 - 2023/11/13

• JSX supports Async Components
• Introduce Suspense and renderToReadableStream()
• JSX Renderer Middleware supports stream
• Support @jsx precompile for Deno

JSXが非同期コンポーネントをサポート

HonoのJSXコンポーネントの中でasync/awaitを使えます。

SuspenseとrenderToReadableStream()の導入

通常、非同期コンポーネントはfetchが終わるまで待ちます。新しいSuspenseとrenderToReadableStream()を使うと、最初にfallbackで指定した内容を表示して、Promiseが解決されたのちfetchの結果のコンテンツを表示します。

JSX Rendererミドルウェアがstreamをサポート

もしstream: trueをセットすると、レスポンスがストリーミングになります。

v4へ向けて

正直、v4に向けての具体的なプランはありません（現在はないわけではありません）。非推奨の機能を消したいという消極的な理由はあります。

ひとつ考えているのはファイルベースのルーティングです。この機能を導入すると、ユーザーは意識せずともベストプラクティスのプロジェクト構造でアプリケーションを作ることができるようになるでしょう。そして、IslandアーキテクチャとReactやPreactなどのUIライブラリを統合することで、動的なクライアントサイドの機能もサポートすることになります。

それが実現されれば、RemixやNext.jsとは違った新しいエッジに焦点をあわせたフルスタックなフレームワークとなるでしょう！

コントリビューター

我々には多くのコントリビューターがいます！Honoのコアリポジトリでは91人のコントリビューターがいます。他のリポジトリと合わせると100人以上でしょう！

備考: 2023年12月20日現在、Honoコアのリポジトリのコントリビューター数は100人。

特にTaku Amanoさんは革新的で賢いアイデアで重要な貢献をしています。彼なくしてはHonoの今はありません。ありがとう。

Daneとの約束

私がCloudflareに入る前、ちょうど1年くらい前（つまり2022年の10月頃）、DaneとTwitterのDMでやりとりをしました。私は彼がこんなことを言っていたのを覚えています。

HonoをRuby on RailsやDjangoのようなフレームワークにするつもりはないか？

今、HonoはまだRuby on RailsやDjangoのように大きくはありません。しかし、あるインフルエンサーは「Expressは新しいJQueryだ。それをHonoのことを考えていて思いついた」と言っています。おそらく、それは現実になりつつあります。そして私はそうであってほしいです。なぜなら、本当に素晴らしいものを作っているからです。私達の旅は続きます。

「速さはDX」

日本語がおかしいですが、ようは「速いことはDeveloper Experienceの向上につながる」という意味です。 それについて書きます。

Bun

「速さはDX」という標語はBunの作者のJarred Sumnerが似た趣旨のことをひたすらXでつぶやいていたのをみて思いつきました。 以下のそのひとつです。

performance is mostly about DX. Waiting for things costs time & focus

— Jarred Sumner (@jarredsumner) September 4, 2023

そう、誰だって「待ちたくない」です。

Bunのv1.0が出る前後にBunを使うユースケースとして「パッケージインストールするのにbun installが速いからCIでそこだけ使う」というものがありました。

Bunの使い道、パッケージインストールするのにbun installが速いからCIでそこだけ使う人がでてきた。

— Yusuke Wada (@yusukebe) September 11, 2023

• BunをCI（GitHub Actions）で使ってみた - Zenn

「や、pnpmだって速い」という議論は置いておいて、「速いことだけ」でも価値になるいい例です。

Cloudflare Workers

Cloudflare Workersの話。 これは僕が中の人だからっていうバイアスがあると思いますが、Cloudflare Workersを使った開発体験はよくて、その理由のひとつに「速さ」があります。

特にデプロイが速い。これはWorkersを始めた人はみんな口を揃えて言います。

以下のアニメーションGIFはWorkers Playgroundで簡単な「ラーメンアプリ」を作ってみて、デプロイする様子です。 全部で28秒の動画ですが、後半、「Deploy」ボタンを押してから15秒くらいで、全世界にデプロイされています。

速い。誰だって自分が作ったものが世の中でどう見られているかを早く確認したいはず。これは開発体験がよいです。

実用的な例だと、@chimame_rtさんがGraphQLのAPIサーバーをGoogle CloudのCloud RunからCloudflare Workersへ移行したという話があります。以下はWorkers Tech Talks #1での資料です。

彼によると移行したメリットのひとつとしてデプロイが「8分前後が1分未満に短縮」したことを上げていました。 Workersでここまで大きなアプリケーションを移行した事例は少なく、また、少々オーバーな例かもしれませんが、Cloudflare Workersの「速さ」がよく分かると思います。

開発サーバー

特に開発環境では速さが求められます。Jarredの言う通り、我々は書いたコードが実行されるまで待つ時間をなるべく短くしたい。

ViteはHMR = Hot Module Replacementを備えています。

幾つかのバンドラは HMR(ホットモジュールリプレースメント)をサポートしています: これにより、ページの変更に関係のない部分には影響を与えることなく、モジュールを「ホットリプレース」することができます。これは開発者体験を大きく改善します。

Vite では、HMR をネイティブ ESM 上で行います。ファイルが編集されたとき、Vite は編集されたモジュールと最も近い HMR バウンダリ間のつながりを正確に無効化することで(大抵はモジュール本体だけです)、HMR による更新はアプリケーションのサイズに関係なく一貫して高速で実行されます。

Vite を使う理由

使ったことがある方は分かると思いますが、これも「速さはDX」のよい例です。

Viteは個人的に、またCloudflare的にも注目しています。

HonoはCloudflare Pagesを開発するのにCloudflareのCLI、Wranglerを使うことを推奨していました。 しかしこれは（Wranglerも十分速いのですが）Viteと比べると遅い。 具体的には内部の開発サーバーで行うバンドルからリロードまでがViteと比べると遅いです（ただ、ViteでもSSRの部分はHMRが現状効きません）。 ではViteを使えばいいじゃないかとなりますが、一概にそうはいかない。というのはCloudflareのKVやR2、D1などのプロダクトへアクセスするためのBindingsが使えなくなるのです。

といってもViteを使いたいので、以下のような工夫をしています。

• Viteのカスタムサーバーを作る。これはNode.jsのAPIで作らなくてはいけない
• Honoで持っているNode.js AdapterはHonoのアプリとNode.jsを繋いでくれるのでそれをカスタムサーバーの中で使う
• Workersの環境をエミュレートするMiniflareにBindingsへアクセスできるAPIがある
• カスタムサーバー内でそのBindingsをプロキシさせてアプリからアクセス可能にする

これでViteを使いつつ、KVやR2、D1などのCloudflareプロダクトへアクセスすることができるようになりました。

以下がそのプラグインのあるリポジトリです。

Viteに限らず、各フレームワークの開発サーバーでBindingsを使えるようにしようとCloudflare社内でも動いています。 その1手としてNext on Pagesのnext devからBindings使えるようになりました。 以下の記事が詳しいです。

next devからCloudflare Bindingsが使えるよ

また、ViteではViteコミュニティからもWorkersやVercelなどのWeb standardsベースなアプリをネイティブで動かす試みが始まろうとしています。

Reducing inconsistency when developing for non-Node environment by emulating the environment · vitejs/vite · Discussion #14288

これは素晴らしいことで、少しでも協力できればいいと思っています。

このようにDXをよくしようと開発サーバーを「速く」しようという試みが行われてます。

まとめ

以上、「速さはDX」という題名でBun、Cloudflare Workers、Viteの「速さについて」紹介してきました。 「速いとDXがよい」のは当然のことですが、改めて考えるとああなるほどなと納得したのでまとめてみました。 「速いからDXがよい」例はみなさんの周りにたくさんあると思いますし、また「DXがいいと思ったら速いからだった」という発見もあるかもしれませんね。

8k

現在、HonoのGitHubスター数は8,000を超えた。

これはとんでもない数字なんだけど、もっと伸びるべきで、早く1万を超えなくはいけない。 npmのダウンロード数は週間「46,000」とこれは相対的に低く、こちらも伸びるべきである。

数字が全てではないが、こうした数字は昨今のOSSにとって「一番の」指標であることは確かだ。 だから戦うことはこの数字を伸ばすことである。

なぜ「戦う」のか

なんで「戦う」というおっかない言葉を使い、そして戦わなくてはいけないのか。 まぁ、単純に悔しいからだ。良いソフトウェアを作ってるのにそれが正しく評価されないことは悔しい。 いろんな人を巻き込んで、コントリビュートしてもらっているのになおさらである。

日本人であることや日本語を母国語とすることがその理由になっているのであれば、それはもったいない。

2つの側面

OSSに関わらずソフトウェアを作るには2つの側面がある。

1. よいソフトウェアを作る
2. 使ってもらう

幸いなことに「1」は日本人かどうかはほとんど関係ないと思う。

問題は「2」だ。例えば、次に話すのは「政治」の話である。 「1」だけに興味ある開発者にとってはたぶんすごく退屈なことだというのを予め伝えておこう。

OSSとインフルエンサー

この不利な状況は「英語ができない」から来ているのではない。それも多少あるとは思うが第一の理由ではない。 周りが日本語を喋っている状況で英語を喋らない（書かない）からである。

痛感したのはXを観察していてだ。 現在、OSS、特にフロントエンドを取り巻く大御所のやり取りはXでやり取りされている。

例えば、T3 Stackを提唱しているTheoや、 TypeScriptエデュケイターのMattは力がある。 Next.jsを扱うVercelは非常に巧みだが、所属するDevRelのLeerobの影響力は強い。 shadcnも最近参画した。 BunのJarredの発言は新興のランタイムの人気を支えるのに一役かっているだろう。 プロダクトで言うとDrizzle ORMは洒落が効いていて面白い。 htmxはふざけすぎてるがフォロワーが多い。

「これはインフルエンサーの話ではないか」。確かにそう。 しかし、残念ながら、声を上げることは昨今のOSSでは強力な戦闘力になる。 我々は、なかなかこの文脈に我々は入れない。 それは英語ができないからではない。日本語で話している環境の中で英語で発信しても力にならないからだと思う。

Honoのアカウント

興味深いのはXのHonoアカウント。 実はFollowingがメンテナ含め4人しかいないのに、フォロワーが今みたら「3,526」いる。

大したことは言っていない。けれど、

Wow, got 8k! Thanks😊

というポストをすると瞬く間にLikeがつく。

僕の個人アカウントはフォロワー「9,200」とそれでもかなり多い方だが、Honoのものと比べると明らかに世界への影響力が違う。 英語の文脈で英語で発言すれば、価値のあるアカウントに対して「世界的に」評価される。 このアカウントが日本語を話していたら、こうはならなかった。

blog.yusu.ke

この前、世界中の「ゆうすけ」が嫉妬するであろう「yusu.ke」という素晴らしいドメインを取った。 ちなみにkeはケニアドメインである。

あえてyusukebeというアイデンティティを捨ててblog.yusu.keというサブドメインで英語のブログを書くことにした。 会社のメンバーに見せる用途もあるが、実験をしてみたかった。まだ4本しか記事を書いていないがなかなか面白いことが起こった。

記事を書いたらそれをHonoのXアカウントでシェアするというのをやった。すると反響があったのだ。 例えば、「Hono + htmx + Cloudflare is a new stack」という記事はHackers Newsに掲載れて60ポイント集めている。

やればできる。

Express is the new JQuery

インフルエンサーがHonoを取り上げつつある。 自称「President of Whiteboards」のBenが「Express is the new JQuery」と発言し「Honoのことを思っていた」と語っている。 そして「ホワイトボード動画」をアップした。当然「Hono」も出てくる。

🌶️ Express is the new JQuery. Let me explain!#WhiteboardTheWeb edition 115 pic.twitter.com/73uM2xXIRW

— Ben Holmes (@BHolmesDev) July 17, 2023

Podcast SyntaxのWesは以前からHonoをピックアップしてくれている。 近々更新されるエピソードはCloudflare Workers特集らしく、そこでもHonoの話をする。

Bunの「1.0」の発表ではZodの作者でBunのDeveloper AdvocateのColinがHonoを紹介している。 驚くべきことにExpressとKoaより先に名前が出てくる。

Bun効果

Bunといえば、Bunの効果はすごい。Bunに早いうちから対応できたことで大きく成長できた。 詳しくは以下に書いた。

• BunとHono｜yusukebe

DenoFest

先日、DenoFestというイベントで話す機会をもらって行ってきた。 これはなかなかすごいイベントでDenoの開発チームが25人（！）日本に集まって、その人達が参加するという。 もちろんNode.jsとDenoの作者のライアン・ダールもいる。

嬉しかったのは彼はHonoことを知ってくれていて、発表の中で「Don’t use Express, use Hono」と発言する場面もあった。

DenoのDevRelのケビンが以前からHonoユーザーであることは知っていた。 なんといっても公式の「Deno Doc」ではHonoをDocusaurusのサーバーサイド、リダレクタとして使っている。 そのケビンとはよく話せた。また、彼の発表、クイズミリオネア形式の「The state of web frameworks in Deno」ではトップバッターにHonoが出てきた。

Who is using Hono in production?

他にも、HonoのGitHub DiscussionsにWho is using Hono in production?というポストを投げたら、 みんな書いてくれて、自分が知らないかなりの数の利用者がいることが分かった。

1. appwrite-funcover
2. Nodecraft
3. Ponder.ly
4. SticAI
5. Skill Struck
6. Reejs
7. toddle
8. LanderLab
9. OpenStatus
10. Loglib
11. AI.LS
12. Equator Analytics
13. ExpenSee

悪くはない

そう、悪くはない。ただ、逆に言うとこのくらいやらないと戦えない。大変だ。

では、どのように戦っているかを書いていく。

神対応

すごくシンプルで強力な戦い方がある。「神対応」だ。 Issueには素早く返信する。相手の環境の再現する努力をする。Feature requestを実現できないか熟考する。 「こっちはサポセンじゃないぞ」と嫌になることもあるし、GitHubの受信箱を見るのが億劫になることもあるが Issueテンプレートを用意したり、毎日の習慣化をしたりすればなんとかなる。

それよりもquickとかfastとかawesomeとか💯とか書かれるのがとても嬉しい。

その人とHonoというソフトウェアが繋がった感じがする。神対応に国籍、言語は関係ない。

GitHub

GitHub上の開発に関しては徹底して英語を使っている。 でも、自然とHonoのコントリビューターは日本人が多い。 これには特に深い意味はなく、僕が日本人だからだと思う。そして、それは悪いことではない。 日本人だからソフトウェアの品質が落ちることは決してない。

「グル化」しなければいいと思っている。 「日本人だけがやってるプロダクト」として見られるのが怖い。 これは杞憂かもしれない。なので、ほとんどの議論をGitHub上でオープンにすることを心がけている。

英語

いくらDeepLやChatGPTを使えるとしても、英語を書く、読むための「瞬発力」は必要になってくる。 Issueの返信を日本語で書くのと英語で書くのとでは作業の重さが違う。 また、Discordや社内のチャットでは文章を毎回添削をしていると時間がかかるし、フォーマルになりすぎる。 だから瞬発的に英語を書くその精度を上げるしかない。

ドキュメントとランディングページ

逆にAIを使えばドキュメントページはわりと書ける。 僕の場合、ブログを書くのは好きだが、英語、日本語に関わらずフォーマルなものを書くのは苦手なので、 その辺は頑張らなくてはいけないがなんとかなりそう。

課題はHonoにはランディングページがない。 OSSで戦うにはブランディングが大事なのだが、英語とか英語ネイティブなセンスが要求されるのも事実だ。 頑張って作ろう。

時差

Cloudflareに入社するまで時差というものを甘く見ていた。 これは結構キツい。

例えばうちのDevRelチームはヨーロッパとUSにメンバーがいるので、自然とアジアの僕が犠牲になる。 ミーティングが23時30分に設定される。下の図がかなり可笑しい。DevRelチームのメンバーのいる場所と時間をプロットした。

面白いのは、よく社内でチャットをする開発者がいるなーと思ったら、オーストラリアのGlenだった。それは当然である。 彼は僕をCloudflareに誘ってくれたひとりで、UKから地元のオーストラリアに帰って仕事をしたいから同じタイムゾーンの開発者を探していたのがキッカケである。 今となってはよく分かる話だ。

これは社内での話だが、OSSの件でも言えることだ。同期的なコミュニケーションがつらいのだ。

Discord

HonoにはDiscordがある。結構な人数がいて今見たら「212 Online」だ。

Discordの同期的なコミュニケーションでは上記の通り不利になることがある。 なので、なるべく非同期でことを終わらせられるようにしている。 そもそもDiscordだと質問攻めになるのが嫌ってのもあるんだけど、「Questions」はGitHubのDiscussionsでやってね、としている。

まぁそれでもDiscordでの会話の半分以上は質問なのだが、もう放置している。 最近だと、僕がいなくても返答をしてくれる人が出てきて、コミュニティっぽくなってきていて喜ばしいことだ。

コントリビューター

コントリビューターを増やすことが大事だと思っている。今のところ90人。これはもっと増えるべきだ。

自分の性格上、全部やってしまいがちなんだけど、なるべく任せるように心がけている。 例えば、Issueに上がったことでその人が解決できそうなものだったら、PRを作ってくださいと言う。 ソフトウェアに関わる人を増やすことが、より多くの人に使ってもらうことに繋がるはずだ。

エコシステム

Honoにはミドルウェアという仕組みがあって、

1. ビルトイン・ミドルウェア
2. カスタム・ミドルウェア
3. サードパーティ・ミドルウェア

の3つがある。この「3」は外部のライブラリに依存したり、文字通り第三者が作るミドルウェアのことである。 github.com/honojs/middlewareというモノリポで管理し、@hono/sentryといった名前空間で配信している …そのつもりだったが、最近では作者が各自のリポジトリで管理し、独自のパッケージ名で公開するミドルウェア、もしくは関連プロダクトが増えてきた。

• Remix + Hono https://github.com/sergiodxa/remix-hono
• Hono Storage https://github.com/sor4chi/hono-storage
• Hono for Durable Object https://github.com/sor4chi/hono-do
• Ultra（フレームワーク）- https://ultrajs.dev/
• Ree.js（フレームワーク） - https://ree.js.org/
• Hwy（フレームワーク） - https://hwy.dev/
• など

当初はあまり意図してなかったことだが、これはエコシステムが成長した証で、素晴らしいことだと思っている。

嫉妬

具体的には書かないが嫉妬されることもある。でもかなり少ない方だと思うし、わりと理にかなっている。 その辺をいなしたり、気にしない力も必要になってくるんだと思う。

OSSで戦うために

他にも語るべきことはある気がするが、ここらでまとめよう。

1. よいソフトウェアを作る
2. 使ってもらう

今回は主に「2」の話をしてきた。

我々のソフトウェアはもっと評価されるべきかもしれないし、 あなたのソフトウェアももっと評価されるべきかもしれない。 その時に日本人を言い訳にしたくはない。だからこそ、その差を自覚し、世界と戦っていく。

「戦う」という物騒な言葉を使ってきたので、最後にそれを濁すためにHonoのContribution Guideから以下を引用しよう。

Note: This project is started by Yusuke Wada (@yusukebe) for the hobby proposal. It was just for fun. For now, this stance has not been changed basically. I want to write the code as I like.

まぁ戦いたくないよね。

追記

一緒に作っているusualomaさんがこんなこと言ってました（タイポしてるのは気にしないでください）。感動しました。

神対応は @yusukebe さんがやってくれているのでほんとうに頭が上がらないのですが、hoonの初期の頃からのコントリビューターとして私がこの件（世界と戦うために）に関して言えるのは「憧れるのをやめましょう」かもと思いました。https://t.co/nsvmE6LALC

— Taku Amano (@usualoma) November 1, 2023

ワークショップ

ServerlessDay Tokyo 2023というイベントの一環で「Cloudflare WorkersとHonoのワークショップ」をやりました。 驚くべきことは「13時から17時」4時間という長丁場なことです。 未知です。 特にネタが尽きるの怖かったので、小粒な例題をいくつもつくっておきました。

想定外

いざ開始。 すると、別のワークショップとの会場が近く、声が通りにくいことが判明しました。 想定外のことですが、僕が移動したり、参加者の方々に前に来てもらって解決できました。

問題は次です。 CloudflareのR2というストレージ、D1というデータベースと、ChatGPTのプラグインを組み合わせたものを作ってもらおうと思ったのですが、 解決しようのない問題がおきました。 R2は無課金で使えるのですが、事前にクレジットカードの登録が必要。それをやってもらってなかった。 ChatGPTに至っては、有料プランでないとプラグインの機能が使えません。 どちらも当たり前のように使っていたので、気づかなかったのです。

切り替えて、事前に用意しておいた「ブログを作る」をやることにしました。

ブログを作ってもらう

R2は使わないものの、Cloudflare D1というデータベースを扱うことになり、体験としてはいい題材です。 データ構造はこちら。

• posts
  • id
  • title
  • content
  • created_at

これだけです。分かりやすくていいのですが、問題はできるものがWeb APIなので、地味です。JSONです。 辛うじて進みが早い人には、HTMLのガワをつけてもらったのですが、それでも地味です。

その時点で時間はもう16時になってました。うーん、このまま帰ってもらうのは悪いです。 なにか「沸く」ものをやらないと。

ChatGPTにそれを使わせる

そこで思いついたのが「ChatGPTにブログWeb APIを使わせる」でした。 ChatGPTのプラグインは事前にいくつか作ってあったので、コードを流用できます。 プラグインと今出来てるWeb APIを繋げたらなんとかなるのではないか。 参加者にやってもらうには時間と準備が足りないので、僕がその場でコードを書くことにしました。

ChatGPTのプラグイン

ChatGPTのプラグインは面白くて、ロジックさえあれば、以下の2つを用意するだけでよしなに繋がります。

1. マニフェスト
2. OpenAPIで書かれた仕様

ロジックはもうWeb APIで出来ています。なのでこの2つを作ればよい。

まずマニフェスト。これにはChatGPTに「このプラグインは何であるか？」を自然言語で書きます。 「Plug-ins for blogging」としました。全体は以下になりました。

export const aiPluginJson = {
  schema_version: 'v1',
  name_for_human: 'Blog',
  name_for_model: 'Blog',
  description_for_human: 'Plug-ins for blogging',
  description_for_model: 'Plug-ins for blogging',
  auth: {
    type: 'none',
  },
  api: {
    type: 'openapi',
    url: 'http://localhost:8787/openapi.json',
  },
  logo_url:
    'https://ss.yusukebe.com/a167950f7cab4b1a1b4a5afa199654363406aa91b8092b6b734b6df04e50ba68_800x603.png',
  contact_email: 'support@example.com',
  legal_info_url: 'https://example.com/legal',
}

logo_urlがミソです。時間がなかったのですが、ここはこだわりたかったのでブログっぽい画像にしました。 これです。

次にOpenAPIに取り掛かります。 今回使っているHonoという（僕が作っているフレーワーク）には「Zod OpenAPI」という拡張があって、 ルート定義をプログラムで書くとドキュメントを生成しつつ、各エンドポイントに適切な型を提供してくれます。

記事を追加するルートを書いてみます。 まず、Zodというバリデータで、入力値を定義します。

const schema = z.object({
  title: z.string().min(1),
  content: z.string().min(1),
})

Zod OpenAPIの素晴らしいところは、定義が、定義のみならず、実際のロジック内で検証するためにも使われるという点です。 逆に言うと、これまで作っていたロジックで使っていたZodのスキーマをそのまま流用できました。

そのschemaで定義したフォーマットで、POST /postsにJSONのリクエストが来ることを定義すると以下の通りです。

export const routeAddPost = createRoute({
  method: 'post', // <== メソッド名
  path: '/posts', // <== パス
  operationId: 'addPost',
  summary: 'Add a post',
  request: {
    body: {
      content: {
        'application/json': { // <= JSONのContent-Type
          schema: schema, // <== Zodのスキーマ
        },
      },
    },
  },
  responses: {
    '200': {
      description: 'OK',
    },
  },
})

あとはロジックです。これまでのコードにはPOST /postsのロジックが書かれているので…

app.post('/posts', zValidator('form', schema), async (c) => {
  const { title, content } = c.req.valid('form')
  const id = crypto.randomUUID()
  await c.env.DB.prepare('INSERT INTO posts(id, title, content) values (?, ?, ?)')
    .bind(id, title, content)
    .run()
  return c.jsonT({
    ok: true,
  })
})

それをOpenAPIのエンドポイントにして、値を受け取る元をformからjsonに変更するだけでOK。なはず！

app.openapi(routeAddPost, async (c) => { // <== app.post('/posts') を app.openapi(routeAddPosts) に変更
  const { title, content } = c.req.valid('json') // <=== 'form'だったのを'json'に変更
  // あとはおんなじ
})

これまたZod OpenAPIの素晴らしい点なのですが、上記のルート定義でContent-Typeがapplication/jsonのリクエストが渡ってくると書きましたが、 そうすると「これまでformから値をとってたけど、jsonでとらないとだめだよ」とエディタが教えてくれます。

これはだいぶ助かった。

これでChatGPTプラグインの実装はできた、はず！

動かす

さあ、いよいよChatGPTのプラグインとして登録してみます。 僕を含め、その場にいる誰も試したことのないことで、どのような結果になるかドキドキです。 「ワークショップをやって、楽しかったっていうブログを書いて」と入力します。

で、で、できたー。 ChatGPTがブログの記事を考えて、できたものをWeb APIに投稿してくれてます。

試しに記事を見たいと言うとちゃんとWeb APIを叩いて、リストを取ってきてます。 その証拠に当初サンプルで入れてた「foo」、「Hello」という記事も一覧の中にいます。

沸く

沸きました！ JSONを眺めるだけ終わるところが、ChatGPTにブログを書かせる、しかもそれがWeb APIと連携してDBに保存されている。 デプロイすればエッジで動かすこともできる。という夢のある話になったのではないでしょうか。

まとめ

以上、ワークショップをやって、ChatGPTにブログを書かせたらよかった話をしました。 参加者のみなさん、いたらぬところありまして、すませんでした。 Cloudflare WorkersとHono、ぜひ使ってみてください！

以下、ほとんどやりきれなかった資料です。

経緯

Hono

僕がユーザーとしてCloudflare Workersに触れたのは、一昨年、2021年の10月です。ブログ記事を書いています。

• Cloudflare Workers 面白い - ゆーすけべー日記

そして、同年の12月には、Cloudflare Workers向けのフレームワーク「Hono」の開発をスタートさせることになります。

Honoは現在でこそ、Fastly Compute@EdgeやDeno、Bunなどのランタイムで動きますが、もともとはCloudflare Workersがターゲットです。 例えば、Cloudflare Workersで動いてるcdnjsのAPIでHonoが使われています。 また、Cloudflare公式ブログの記事内でも利用されています。

Honoの開発は非常に楽しく、プログラミングを初めて20年程度立ちますが、「これほどまで熱中したことがない」ほどです。毎日、夕食が終わってから寝るまでの時間、コードを書いたり、IssueやPRをみたり、コメントしたりしていました。

Honoに限らずとも、Cloudflare WorkersやCloudflare Pagesに関する記事を書いていました。Cloudflareのコミュニティで認知されるようになります。

Cloudflareで働く、なんて考えたことある？

去年2022年10月。Workers/D1チームのGlenからTwitterのDMで声をかけてもらいました。

「Cloudflareで働く、なんて考えたことある？」

Workers/D1チームは開発者を探していました。特に、Glenはヨーロッパから地元のオーストラリアへ帰って仕事を進めるために同じタイムゾーンの仲間を探していたそう。それで声をかけてくれた。

僕はフリーランスで仕事をしていました。Cloudflareは好きですが、まさか自分がそこに入る、なんてことを考えたことがなかった。それを中の人、Glenが提案してくれた。火が付きました。「Cloudflareに入りたい」。ただそれはGlen曰く「レアケース」。アジアでWorkersのデベロッパーはいないし、日本人が日本にいながら、Workersチームと一緒にやるのは非常に難しいことです。そして、日本法人はまったく噛まずに、Cloudflare本体を説得していかなくてはいけません。

しばらく日があいて、こりゃもうだめかなって思った11月中旬。今度はWorkersチームでSVPのDaneに声をかけてもらいました。「Cloudflareで働くことに興味はないか？」と。その後、同チームのIgorと話すことになりました。最初はそれがインタビュー、つまり面接だとは思いませんでした。

• Igor
• Dane、Rita
• Glen
• Pete

と4回オンラインで話しました。みんな活動場所がバラバラなので面接時間帯が深夜になったり早朝になったりしました。Peteとはコードを一緒に書こうってことで「Wranglerのバグとりはどうか？」と事前に言われてました。でも、それじゃあ刺激的じゃないので、Honoの新しいRPCモードをデモして、一緒にエディタを覗いたりしました。Glenともそれで盛り上がりました。

それが、去年の年末にかけて起こったことです。まじで英語話せなかったのですが、IgorとDaneは前向きなことを言ってくれました。

ロール

初めてロールが明らかになります。通常のパスだと、ジョブディスクリプションとロールがありきで、そこへ志願者が応募することになります（ですよね）。僕の場合は後から知らされました。当時はてっきりWorkersの開発者だと思ったのですが、Developer Advocateと言われたのです。

そういえば、Daneに「開発とAdvocateとどちらがやりたいんだ？」と聞かれたことを思い出しました。その当時は Developer Advocateという役職があるのを知らずに「both」と答えていました。

Give me 2 days.

ここで、リクルーターから「ビジネス的は意味でブロックがかかってる」と言われました。モヤモヤします。ただ、Daneがちょくちょく連絡をくれてて、それが希望になりました。彼は「物静か」という印象ですが、なにか熱いものを感じます。

2月末になってもう待てないので、Daneに「Honoは大きくなっている、多くのWorkersのユーザーに使われてるんだ」と話すとこういってくれました。

「だいじょうぶ約束する。2日待ってくれ」

すると事が早く進んでいく。アジアチームと連携が取れたのでしょう。日本に住むリクルーターが担当してくれて一気に早くなりました。カルチャーフィットの面接、日本法人の佐藤社長との面接を終えて、ほぼ確定。ZatlynとのFinal C-callは緊張でした。電話は難しい！ そしてMatthewからのオファーレターにサイン！

半年間の就職活動が終わりました。

初めての会社員

2006年、大学院卒業後、父親と会社をつくり、2019年に廃業してからはフリーランスとして活動してきました。41年間生きてきて、初めての就職活動、そして初めての会社員です。

英語

英語が本当にできない。喋れない。もし普通に就活をしたら、英語力で速攻落とされます。だから今、必死にスタディサプリとDMM英会話をやって追いつこうとしています。ソフトウェアは世界的に発信できますが、しばらくは、スピーチやドキュメントは日本語が中心になりそうです。

トラベルブック

これまではトラベルブックに参加していました（厳密には4月末まで契約が残っています）。トラベルブックとは、2014年の創業時からの付き合いです。当時は技術顧問で関わっていて、途中ブランクがありつつ、2021年からはフルタイムに。現在まで開発をやっていました。「ぷっつり」切れるわけではないので、また飲みに行ったり、遊びに行きましょう。

Developer Advocate

Developer Advocateという言葉は聞き慣れない言葉です。ようは製品とそれらを使う開発者をつなぐ役目だと思っています。 エバンジェリストと違って、かなり「Developer」寄りです。自分でライブラリの開発もする。例えば、Zodの作者で、tRPCの初期バージョンのオーサーのColinがBunのDeveloper Advocateです。

Cloudflareには今年のはじめに亀田さんがエバンジェリストとして入りました。 亀田さんとは全く別スレッドで話が進んでいて、彼がCloudflareに入ったことは後から知りました。 また、僕が入社する、という話は亀田さんとは今までしていません。 紹介した通り、経緯が違いますし、開発者寄りという意味では、役割が分担されるかと思います。

Honoの今後

Honoの開発もやっていくことなると思います。ただ、決して HonoをCloudflare専門のフレームワークにするつもりは全くなく、これまで通り、Fastly Compute@Edge、Deno、Bun、Vercel、AWS Lambda、Node.js等のプラットフォームにプロダクションレディで対応させていきます。

その他

Hono以外にもやりたいことがたくさんあります。 例えば、Cloudflare Workersに超特化したフロントのフレームワークを作りたいとか、拙作のPicoをもっと使われるようにするとか。また、Workersには、KV、Durable Objects、R2、D1、Queueなど様々周辺のプロダクトがあり、それも増え続けています。これらを使ったアプリケーションを作って、新しいユースケースを示していく。開発者と知識を共有するなにかを作る。 やっていきたいです。

いよいよ入社

いよいよ今日からCloudflareでの仕事が始まります。まずは、ラップトップのセットアップをします！ みなさんに感謝です！

前日祭

• エレベーター乗ってて話しかけられたと思ったら、キーノートするはてな大西さんだった。
• uzullaさんを認識できなかった。
• moznionが来日してた。超久しぶりだったけどお知り触ってきて、テンションが変わってなくてよかった。

Hono Conference #1

• 前日祭のあとに記念すべき第1回「Hono Conference」を行った。
• というのも、HonoでRegExpRouterなど重要な機能をつくっている@usualomaさんも発表しにYAPCに来てて、物理では初遭遇。
• 僕の20分の発表の次に@usualomaさんの発表20分でどちらもHonoについて。Hono Tracks。
• さらにFirebase Auth Middlewareを作ってるへっくすさんとも初物理。これはHono Conferenceやるしかないでしょう。
• ちなみに、Hono Conferenceやるぜ！TwitterとHonoのDiscordで言ったら、CloudflareのRitaとか何人か海外の知り合いがリアクションしてて面白かった。「Virtual or physical?」って聞かれて「Physical」って答えたら「I’ll be there in spirit」って言われてうけた。
• 僕とusualomaさん、へっくすさんの3人くらいかなと思ったら、最終的には12人参加！11人個室の居酒屋を早めに予約しておいてよかった。
• akiymくんが参加してた。akiymくんは10年くらい前のYAPCで初めて合った時には高校生だったので、印象に残ってる。Honoのレビューしてよって言ったらしてくれるっぽい。
• @chimame_rtさんがYAPC参加してないのに、Hono Conferenceのために大阪から来てくれた。最高です！
• uzullaさんがいるといつの間にか会計してくれてたりしてて便利。

ノベルティ

• たくさんもらった。毎回ありがとうございます！
• 正論で殴るがよい。

Hono Hackathon

• YAPCの開催中に、僕とusualomaさんへっくすさんがそれぞれ1箇所ずつfixとrefactorをしてパッチバージョンをリリースできた。Hono Hackathonの実績解除。へっくすさんはHonoのコアに初コントリビュート。あと、akiymくんにPRのレビューをしてもらった。

発表「どこでも動くWebフレームワークをつくる」

• 発表した。
• Honoのマルチランタイムに焦点を当てた発表。その後の@usualomaさんはルーターについて。
• 20分じゃ収まらない量だったけど、なんとか収まってちょうどだった。タイムキーパーの人が「5分前」の札だしてなかったけど、こちらでストップウォッチ回しててよかった。
• 駆け足だとその分コンテキストを共有する時間がとれず、ちょっと置いてきぼりにする感になってしまったかなと反省してて、40分でじっくりやった方がよかったなとも思ったけど、面白いというリアクションが多くてよかった。
• dankogaiさんが来てくれた。突然「dan the comment」されても困るので、逆にこちらから質問するという作戦をとった。
• その後dankogaiさんには質問コーナーで「Ultrafast web framework for the Edge」なら「Edges」の方がいいじゃないか？と言われた。一瞬へんなリアクションしてしまったけど、すごいいいアイデアなので採用させてもらいます。

発表「Honoの3+1のルーターと、そこにつながるPRがプロジェクトにもたらしたもの」

• usualomaさんによるHonoのルーターの話。Honoについての話を自分以外の人が話てるのを聞く経験が初めてだったので、新鮮だった。寿司に例えてたのがすごいよかった。
• RegExpRouterはまじでJavaScript界で1番速いし、Honoの場合、それだけじゃなくて、RegExpRouterがカバーしきれないルーティングをTriRouterがうけとめる、それをSmartRouterが面倒みる、という「ルーターにここまでやる？」ってほどでとても面白いです。

ランチセッション

• お弁当豪華だった。Helpfeelさんありがとうございます！
• ChatGPTはいいよねー。

大西さんのキーノート

• 感動した。
• 僕も2010年のmiyagawaさんキーノートが印象に残っていて「コードを書くのに許可はいらない」ってのが好き。そして、それから12年以上経っているのが衝撃である。
• 「モブキャラ」という一貫したテーマで細かい笑いあり、感動あり、尺もちょうどよくテクニック的にもハイレベルな発表だった。

その他の発表

• songmuさんのOSSの話。ホットなトピック。これは個人的にもだし、リアクションからみるに世の中的にもそうなんだろうなって思った。最近のOSSプロジェクトってGitHubスター1,000を超えるくらいのだと、大なり小なり商業的なものが入るパターン多くて、それはいいことなんだけど、一昔とは情勢が違うのかな、とか考えたりした。songmuさんPR出した数とか半端なくてすごい。
• あらたまちゃんの話。ベストトーク取ってて、おめでとう！すごい興味深くて、ハッカーの呪縛を解くための方法が、ハッカーに近づいていくアプローチの僕とは真逆で面白かった。
• そういえば、裏でそーだいさんの発表があった。そーだいさんは裏の発表がベストトークとったことを悔しがっていた。僕も次回はベストトークをガチで狙いに行ってそーだいさんとかまこぴーとバチバチやろうと思う。よーしエモいのぶちこむぞー。
• moznionの廃墟の話。Hono作ってて一層この手の話に興味を持つようになった。そう、コードは書いた瞬間に負債もしくは廃墟になる。
• まこぴーのデプロイというかHTTPをどうハンドルするかの今昔物語、めちゃくちゃ好きだった。投票権あったら投票してた。デモもめっちゃいい。

papix

• papixが楽しそうでなにより。大西さんのキーノートのあとのクロージングでpapixまでエモくなっててよかった。

スピーカーディナー、はてな

• スピーカーディナーに呼んでもらって、居酒屋でわいわいしてたらいつの間にか23時だった。
• はてな社に移動してわいわいしてたら、いつの間にか1時だった。時間がバグる。
• mizdraさんとたくさん話した。HonoのRPCモードをデモしたりした。僕はフロントのUI作ってるわけじゃないけど、フロントの技術を今触っていて、それについて深く話せる存在は貴重だったりする。
• myfinderさんは盆栽をやればいいと思う。
• というかはてなさん、スタッフもたくさんあててもらってたらしく、ありがとうございます！

#yapcramen

• 新福菜館がまじうまかった。

まとめ

• めちゃくちゃ楽しかった。そしてみんなめちゃくちゃ楽しかったって言ってた。
• よーし広島いくぞー！