多くのユーザーに届くOSSには、つくる楽しさだけでは済まない現実があります。IssueやPull Request(PR)への対応、期待との向き合い、説明責任。さらに近年は、AIが生成した低品質なIssueやPR、いわゆるAI Slopも、新たな負荷としてのしかかっています。YAPC::Fukuoka 2025で「OSS開発者の憂鬱」を語った和田氏に、巨大OSSの開発リーダーとして見えている苦悩と、それでも続ける理由を伺いました。
【OSS応援ボタン】
本記事では、「OSS応援企画」として「応援ボタン」を設置しています。1回の応援につき、Findyが100円をHono(開発者の和田氏(GitHub)/ メンテナーのusualoma氏(GitHub))に寄付します。
エゴサができなくなった日、手が離れたと気づいた
――まずは改めてHonoについてお伺いしたいのですが、今や巨大OSSと呼ばれる規模になっていると思います。最初からここまで大きくなると想像していましたか?
想像していませんでしたね。最初は本当に“盆栽”みたいな感じで始めたんです。毎晩、ご飯を食べた後に2時間くらいコードを書く趣味、という感覚でした。ただ、今の規模まで成長したことに驚いたかというと、そうでもないんです。急に大きくなったわけではなく、徐々にという感じだったので。
例えば、Honoをつくった当初はNode.jsの有力フレームワークであるFastifyに追いつくことなど、まったく想像できませんでした。それが2025年にはnpmのダウンロード数を上回るようになっています。1億という絶対値だけだと実感しにくいですが、そうやって比べてみると、すごいことなんだなと思います。

――徐々に大きくなっていく中で、「自分だけのプロダクトではないな」と感じた瞬間は覚えていますか?
エゴサで反応を追いきれなくなった時に、「手が離れたな」という感覚がありました。日本語だけでなく英語でも追いきれなくなって、関連するキーワードで検索してもすべては把握できないんです。それまではどれだけ使われているか、どんな評判になっているかがすごく気になっていたのが、あるタイミングで「もういいか」という気持ちになりました。
具体的なポイントで言うと、2022年7月にBunのリポジトリがプライベートからオープンになって、みんなが一斉に使い始めた時に、Bunにも対応させたHono 2.0をリリースしました。当時BunはExpressに未対応だったため、代わりとなるWebフレームワークとして「Honoがある」と話題になり、使われ始めたのが1つのきっかけです。
Bunと同時にDenoにも対応し、その少し後にNode.js アダプターもつくったことで、最初はCloudflareだけで動いていたHonoが様々な環境で使えるようになっていきました。
翌年、2023年9月にBun 1.0がリリースされた時、その公式発表動画の中でBunでWeb APIを使う場合のフレームワークとしてHonoが紹介されました[1]。さらに、その翌月に開催されたDeno Festでは、Node.js作者でDenoの代表でもあるRyan Dahlが、プレゼンの中で「Don't use Express, use Hono」と言ってくれました。このあたりで一気に盛り上がりましたね。
「つくっている感」が、だんだん遠くなっていく
――Honoが大きくなるにつれて、ご自身の役割はどのように変わっていったと感じていますか?
一番大きいのは、「クリエイター」から「メンテナー」への変化です。メンテナーということは、当たり前ですがメンテナンスし続けなければならないので、Issueへの返信とPRのレビューがタスクとして入ってくるようになります。クリエイターとして新しい機能をつくる部分はもちろんありますが、だんだんとメンテナンスの割合が大きくなっていくというのが1つです。
他にも、プロダクトオーナー、リーダーという役割も生まれました。Hono Conferenceを開催したことで、自分がつくったOSSのイベントを自分で企画して、LTの合間に自分で銅鑼を叩くというところまでやりました(笑)。ソフトウェア開発者、メンテナー、イベントリーダー、コミュニティリーダーと、役割が増えていきました。外向けに発信していく、Honoの広告塔という側面もありますね。

2025年10月に開催されたHono Conference内、LTセッションで銅鑼を叩く和田氏。画像はFindy Media掲載のイベントレポートより
――その役割の変化は、ポジティブに受け止めていますか?
そうですね。ただ、メンテナーの割合が増えてクリエイターとしての役目が減っていくのは少し残念ではあります。
今、Honoの最新バージョンは4.12.9(インタビュー時点)ですが、メジャーバージョン4になったのは2024年2月のYAPC::Hiroshima 2024でのことです[2]。その後2年間、マイナーバージョンでの新機能追加は続けてきたものの、コンセプトを変えるような大きな機能は入れていません。
それ以前はFile-based RoutingやSSG、Hono RPCなど、Honoの形そのものを変えるものをつくっていたので「つくっている感」がありました。その感覚が最近、Honoに関してはあまりないというのが正直なところです。
――それは、規模が大きくなったことでつくりづらくなっているのでしょうか。それとも他の要因がありますか?
つくりづらさは正直あります。自由に大きく変えにくいですし、ある種「つくり切ってしまった」という感覚もあります。自分で生み出している実感というのは非常に大事で、Hono本体に関してはなかなかそれができていないのですが──。
Hono ConferenceのクロージングでHono CLIを発表したんです。このCLIのコンセプトを考えるのはとても楽しかったです。
――Hono CLIはどのようにして生まれたんでしょうか?
Hono Conferenceのスタッフとクロージングの構成を話していた際に「One More Thing」をやることが決まりました。そこで、以前から埋もれていた「CLIが欲しい」というIssueを思い出し、「これだ」と。Honoのメンテナーであるusualomaさんにも声をかけて10日くらいで一気につくり上げました。これはすごく面白かったですね。
「OSS開発者の憂鬱」の裏側
――Hono Conferenceより少し後の話になりますが、YAPC::Fukuoka 2025では「OSS開発者の憂鬱」を発表されて、SNSなどでの反響も大きかったように思います。ご自身では、その反響をどう受け止めましたか?
発表自体はよくできたプレゼンテーションだったと思います。ただ、憂鬱なことをまとめるわけですから、そこまでの準備が本当に大変でした。
――「憂鬱」というテーマで書こうと決めたきっかけはあったんでしょうか。
大変で憂鬱だったからですね、シンプルに。
――発表して、楽になった部分はありましたか?
あったかもしれません。ただ、まとめること自体が本当に大変で、辛いことを書き出していくのは苦しかったです。すごく練って、すごく準備したんです。苦悩や憂鬱を語った後に希望の話をする構成にしたのですが、資料をつくってひとりで練習していると、なんだか分からないけど泣いていたんです。ひとりで練習しながら泣くって怖いですよね(笑)。それだけ魂がこもっていたんだな、と今振り返ると思います。
ただ、終わった後の感想を見て面白かったのは、否定的な人がひとりもいなかったことです。「辛いね」という共感や同情がほとんどでした。その後のイベントで会う人も「OSSって大変でしょ」と心配してくれる人が多く、問題として認識している人がたくさんいるんだな、と感じられましたね。
――発表の中では「9つの苦悩」が語られていましたが、今でも特に根深いと感じるものはありますか?

発表内で語られた、9つの苦悩
とにかく「色んな人がいる」ことですね。例えば「レビューが多くて大変」という課題は、OSSに限らず大きな組織でも起きることです。ただOSSの場合に決定的に違うのは、国/年齢/バックグラウンド/時差......どれもまったく異なるということです。
誰が来るかわからないし、誰を信頼していいかもわからない。Honoはカバーする範囲がとても広いので、送られてくるPRの種類も様々で、コンテキストスイッチングの負担も大きいです。これはOSS以外ではなかなかないことだと思います。もう1つ、YAPCの発表内ではあまり話せなかったのですが、OSSに「貢献」すること自体が目的になってしまっているという問題があります。
――その問題について、直近「AI Slop(AIが生成した低品質なコードやPRが大量に流入する現象)」に関する記事でも発信されていましたよね。
そうですね。GitHubのリポジトリページにはコントリビューターがアイコンで表示されますが、そこに自分のアイコンを載せることが名誉になるのはわかります。ただ、それが目的になって意味のないリファクタのPRを大量に送ってくるとしたら、それは少し違うなと感じます。
世の中的にもOSSコントリビュートをキラキラした文脈で語る流れがありますが、それ自体が目的になってしまうのは危うい。最近話題になっているAI Slopが登場する以前から、この問題はあったんです。AIの登場で、それが加速したんですよね。
人もAIも信じられなくなる。AI Slopという新たな憂鬱
――AI Slop問題について、もう少し詳しく聞かせてください。Honoでは具体的にどのような影響を受けているんでしょうか。
ある時、GitHubのInboxを開いたら30個のまったく同じ人からのPRがあって、すべてクローズしてアカウントをブロックした、ということがありました。
別のケースでは、あるIssueが立った直後にその修正PRが3件届いたのですが、全部別々のアカウントから、ほぼ同じ内容でした。おそらく、Issueが立ったのを検知してAIに書かせた人が3人いたんでしょう。しかも間違っていたり、変なコミットが混じっていたりして、品質が明らかに悪かったです。
――PR以外でも影響が出ている部分はあるんでしょうか?
最近増えているのはセキュリティレポートです。メンテナー側にしか見えない非公開の場所でやり取りするもので、これまではそんなに多くありませんでした。この数年で公開したレポートすべて合わせても20件ほどですが、そのうち先週だけで5件来たんです。
セキュリティレポートは本当に気をつかいます。脆弱性のスコアをオーバーにつけると周囲の目が変わりますし、CVE[3]のIDを取るかどうか、Xで告知するかそっとアナウンスするかなど、毎回判断が重い。しかも5件が同時に来て、全部目を通して、修正PRをつくって、ディスクリプションが過剰な場合は自分で書き直して、公開タイミングも調整して......という作業が重なります。
これもAIが絡んでいると思っていて、CVEが自分の名前で登録されることはエンジニアとしての実績になります。先ほどのPRの話と同様に、CVEレポーターになりたいというのが目的になってしまっている可能性もあります。ただ、脆弱性としては本物なので一概に悪いとは言えません。AIが関与していると分かっていても、すべて真剣に対応するしかないのが難しいところです。
――聞いているだけで、消耗しますね。
そう、辛いんですよ。AI Slop問題で一番辛いのは、人もAIも信じられなくなることですね。
特にセキュリティレポートは、自分たちがつくったプロダクトの穴を指摘されているわけですから、精神的にきつい部分があります。AIにいじめられているような感覚になる時もあります。

――OSSという仕組み全体にとっては、AI Slopはどのような影響をもたらすと考えていますか?
相当変わると思っています。PRの品質が落ちるというのはさっき話した通りで、それだけでなく、Issueが立った後の議論を完全に無視したPRが来ることもあります。例えば、「この問題はミドルウェアで解決しましょう」という方針になっていたのに、「コア」に機能を追加するPRが届く。議論の文脈をまったく読めていないんですよね。
こういった話をXで投稿していたら、Cloudflareの同僚でOSS開発をしているSunilが「コラボレーターやメンテナー以外の外部からのPRを受け付けないようにした」と言っていました。最初は極端な考えだと思いましたが、今となってはそれでいいんじゃないかと思います。
――コラボレーター以外のPRを制限するという発想は、AI Slop以前にはまったくなかったことですか?
完全に、AI Slopが生まれた後の選択肢です。GitHubのプラットフォーム側でも最近になって「PRを制限する機能」が追加[4]されましたし、PR前提だったOSSのあり方が変わりつつあると感じています。
AIがコードを書ける時代には、外部コントリビューターがPRを送る意味そのものが変わっていくと思います。GitHub以降のOSSモデルはPRを元に発展してきたと言えるとしたら、その形が変わるというのは論理的に説明できます。絶対に変わります。
AI Slopの憂鬱を晴らしてくれるのも、またAI
――AIがOSSにもたらす課題について伺いましたが、Hono開発自体にAIを使うことはありますか?
はい、AIにレビューしてもらっています。先ほどコンテキストスイッチングのコストが大変という話をしましたが、AIは調べて提案してくれるのが得意なので、例えば自分が詳しくないReactのミドルウェアのPRが来た時でも、AIと一緒に見ることでコンテキストスイッチが楽になります。
OSSの憂鬱な部分が、実はAIで軽減されているという面もあります。
――AIを使っていて、楽しいと感じることはありますか?
プログラマーにとってのAIの使い方といえば、AIにコードを書かせる話になりがちですよね。でも自分が面白いなと思っているのはもう少し違う方向なんです。例えばMCP AppsというMCPでユーザーインターフェースを扱う仕様が出てきていて、それも面白いと思っています。最近だと、CloudflareのDynamic Workersもそうで、テクニカルな楽しさが詰まっていてすごいと感じています。
課題を解決するための、新しいテクノロジーの応用の仕方が出てくることが面白いんですよね。MCPもそうですし、領域が広がったという感じがあります。そういうのはやっぱりワクワクしますね。

それでもHonoとOSSをやめない理由
――楽しい部分もありながら、ここまで伺った苦悩は、時間的にも精神的にも消耗することが多いと思います。それでもHonoの開発やOSS活動を続けられている理由を教えてください。
惰性、というのも正直あります(笑)。サンクコストという言い方は少し違うかもしれませんが、そういう気持ちが多少あります。つくり続けてきたかなり大きなものだし、名刺代わりにもなっているわけですから、やめられないというのはあります。責任感もあります。あとはやはり、先ほどのHono CLIの時に感じたようなワクワクが、Honoにはたくさんあるからです。
シンプルな言葉で言うと、「コラボレーション」が起こるんです。それも知らなかった人と。例えば、ルーティングやミドルウェアの仕組みを、Honoの初期から深く関わるコントリビューターであるmetrueさんとusualomaさんとの3人で深く議論したのがすごく楽しかったんです。RPC機能の設計でも「これは不可能かな」「APIが少しかっこ悪くなるかな」と思っていたところに、コメントで「RESTのWebアプリを書くだけでTypeScriptの型情報をRPCとして書き出せる」という提案が来て、とてもかっこいいと思いました。
それまでまったく知らなかったり、国も言語も違ったりする人が、テクニカルなアイデアをパッと出してくれて、みんなで一緒に興奮できるというのはOSSならではです。一度その面白さを知ってしまうと、やめられなくなります。Hono CLIの時に久しぶりにそれを感じたので、「また何かあるかな」と期待してしまいます。
「YES」を重ねるうちに、世界との距離が縮まっていった
――Hono Conferenceでも海外からの登壇者やスポンサーが多かったですよね。コミュニティの存在はどう捉えていますか?
とても支えになっていますね。Hono Conferenceを開催できたのは本当によかったと思っています。190人弱が来てくれて、Hono Awardsという表彰式を企画して、コントリビューター3名を表彰することもできました。海外から来てくれた方もいましたし、Honoを好きでいてくれる人がこんなにいるんだと実感しました。
――和田さんのSNSを見ていても、最近は特に海外からのゲストと会われているイメージがあります。
昨年は特に多かったですね。海外から人が来た時は、東京駅近くの寿司屋に連れていってバルコニーでセルフィーを撮る、というのが定番になっています。同僚からの紹介だったり、Honoを通じて知り合った人だったりと、きっかけはいろいろです。中には、それまで一度も話したことのない人もいます。
――まったく面識のない方と会うこともあるんですね。
そうです、つなげてくれた人も当日はいません(笑)。それでも全部「YES」って言い続けてきたんです。英語が全然できなくても、1対1ならなんとかなる。知らない人、言葉も国も違う人を迎えるのはハードルが高いけれど、ドキドキしながらとにかく「YES」と言ってきました。
その結果、昨年の11月末に台湾のJavaScriptカンファレンス「JSDC」にゲストとして招待してもらいました。そこにVue.js/Viteの作者であるEvan Youさんと、現IBMでReactの本も書いているTejasさんもゲストで来ていて、帰りのタクシーで一緒になったんです。
技術の話だけでなく、ドイツでは無宗教の人が多いとか、日本はトイレにも神様がいるとか、そういう文化の話が面白くて。二人と話して感じたのは、コードが書けるとかプログラミングがすごいという以前に、コミュニケーションのレベルがまったく違うということでした。10を話したら100を理解してくれるような感覚で、これがワールドクラスか、と。2025年のハイライトの1つです。
――話を聞いていると、どのエピソードもとても楽しまれている印象です。
楽しいんですけど、大変なんですよ。来る者拒まずで「YES」と言い続けた結果、スキルが追いつかなくなってきました。プログラミングのスキルもありますが、それ以上に英語が追いつかなくなってこれはまずいと危機感を覚えました。
そのため、最近は休日も含めて毎日2時間英語を勉強しています。2026年は英語に疲れて、AIに怒られる年ですね(笑)。
――毎日2時間はすごいですね。今後の展望についてもお聞かせください。和田さんはこれまでも一貫して「人を楽しませるもの」をつくってこられましたよね。次につくりたいものは決まっているんですか?
レストランをやりたいです(笑)。

――プログラミングはいっさい関係なく?
関係なく、僕はつくる側として得意のパスタを出したいですね。料理の味で勝負したいです。バーカウンターを広めにとって、厨房からお客さんを覗けるような──。
ただ、結局「ものをつくって人を喜ばせる」ことが好きで得意なので、何をつくるにしても、そこだけはずらしたくないと思っています。今すぐかというと、まだもう少しプログラミングで面白いことをしてからかもしれません。
人間にも、Honoを忘れないでほしい
――最後に、少し大きな話も聞かせてください。OSSに関心を持っている方に向けて、「巨大OSS開発のリーダーが見えている景色」として一番知ってもらいたいことは何ですか?
まず、世界に行けるということです。ここまでで名前を挙げたような、第一線の開発者と対等に会話できるところまで行ける可能性がOSSにはあります。
もう1つはAIのことです。OSSは確実に変わります。AIがコードを書いて、人間はAIを操作する時代になると、人間はpackage.jsonの中に何のライブラリが入っているか知らなくなるかもしれない。AIだけがHonoを知っていて、Honoを知らない人がたくさん増えてくる可能性もあります。そうなると、僕がメンテナーやクリエイターとして人間に価値を届けることは、今までより難しくなるかもしれません。
――「AIネイティブ」のエンジニアも増えてきます。そういった世代がOSS活動をしたい時に、伝えたいことはありますか?
AIが当たり前になっても、変わらないものがあると思っていて。OSSから生まれるテクニカルなコラボレーションの楽しさや、先ほど話したHono CLIやDynamic Workersのようなワクワクは残っています。OSSの形がどうなるかはわからないけれど、テクニカルな話題でワクワクできる体験はこれからもしたいですね。
僕が尊敬しているusualomaさんもCloudflare WorkersをつくったKentonも、結局すごいと思うのはアイデアと、それを実装する能力が突出しているんです。AIに手伝わせるにしても、最終的にはアイデアが必要ですし、実装の勘というのはAI時代でも必要になってくると感じています。そこを鍛えるか、あるいはその力を持った仲間を見つけるか。そこに価値を見出すことが、一番面白いんじゃないかと思っています。
――この記事を読んでいる人やHonoユーザーに向けても、メッセージをお願いします。
1つは「AI時代でも、Honoを忘れないでください」ということです。もう1つは、Honoを舞台にとんでもないアイデアを生み出してほしいということです。
そして、もしAIにつくらせるなら、もっと面白いPRをもらえたら嬉しいです。例えば、usualomaさんが書いたHTTPルーターよりも10倍速いものをつくってみてください。そんな、すごくワクワクするPRを待っています。

「OSS応援企画」について
本記事では、「OSS応援企画」として「応援ボタン」を設置しています。1回の応援につき、Findyが100円をOSS団体などへ寄付し、エンジニアの成長とOSSの発展を応援する取り組みです。開発者の想いや取り組みに共感した気持ちが、OSSの支援にもつながっていく、そんな前向きな循環をFindyは目指しています。「応援ボタン」は、1日1回まで押すことができます。記事を読んで「いいな」と感じたら、ぜひボタンを押してあなたの応援の気持ちを届けてください。
期間内に集まった応援数に応じて、Findyが100円をHono(開発者の和田氏(yusukebe)/ メンテナーのusualoma氏(usualoma))にGitHub Sponsorとして寄付します。
-
Hono v4は、YAPC::Hiroshima 2024での登壇中にリリースされた。Hono v4- Speaker Deck ↩
-
CVE(Common Vulnerabilities and Exposures):コンピュータのソフトウェアやハードウェアに見つかった脆弱性(セキュリティの欠陥)に、世界共通の固有ID(CVE-西暦-連番)を付与して管理するシステム。米国MITRE社が管理し、ベンダーやツールを問わず脆弱性情報を共有・管理するために使われるグローバル標準。 ↩
-
2026年2月13日にGitHubに追加された、Pull Requestを「完全に無効にする」「共同作業者のみに制限する」機能。プロジェクトのニーズに合わせてPull Requestを管理できるようにするもの。 New repository settings for configuring pull request access ↩

