OSS as a Hono User

Transcript

1. Honoユーザー としてのOSS
2. いや、マジで ⾔いたいんだけど
3. このイベントにおける私って「ここ」では無くない？ 3
4. 許可は得たので好きに話すのですが (最近Honoのリポジトリ ⾏けてないな...) 「Honoユーザーとしての OSS」でオナシャス！ > テーマは⾃由ですので、 今いちばん話したいことを お話しいただければと 思っています。 4
5. なんかヤバそうなこと⾔うとヤバそう(語彙⼒ゼロ) - いまHonoコミュニティで OSSの話題してええん か？？？？？？ (超訳)プルリク⼤杉で キツいんので外部からの 受付を辞めまっす！ 5
6. 本⽇の期待値調整 - 話すこと - ポジション‧近況 - ⾃分が取り組んでいるOSS - いろいろな「Why」 - 話さないこと - カッコいいこと - ためになること 6
7. About Me watany(渡邉 洋平) - AWS Ambassadors(2024〜) - JAWS-UG東京(AWSコミュニティ) 運営 - 寄稿：Software Design, CodeZine 2026年5月2日（土）発売 https://www.sbcr.jp/product/4815636593/ 7
8. 趣味：インディーズの驚き屋活動 8
9. Hono関連 - Contribute - Adaptor(Lambda、Lambda@Edge) - Middleware(Secure Headers、Timeout) - Helper(SSG、Streaming - SSE) - Blog 9
10. 私のコントリビュートスタイル - モチベ - AWS上でもHonoをめちゃ便利にする - 「Expressで良くね？」を無くす - 沢⼭Contributeしてると凄そう - ⽅法 - 欲しい機能をPull Requestで提案 - 書くの難しそうなとこはCline,Claude Codeに⼒を借りる 10
11. マズそうな要素が沢⼭ある！？！？！？！？ - モチベ - AWS上でもHonoをめちゃ便利にする - 「Expressで良くね？」を無くす - 沢⼭Contributeしてると凄そう - ⽅法 - 欲しい機能をPull Requestで提案 - 書くの難しそうならCline, Claude Codeに⼒を借りる 11
12. ま、まあ、今更やろ…… ✅Cloudflare DevRelへ競合 (Lambda@Edge)対応を送付 - ✅Honoユーザー代表⾯で デブサミ座談会に参加 - ✅AI Slopで困ってる⼈に AIの書籍を送り付ける - 12
13. ワイのHono関連の活動が ⽌まってないか問題
14. 率直な気持ち - これ⾜そう！のモチベが落ち着いた - いい意味で「枯れて」いる - 普通に仕事のモックサーバとかHonoで建てている - Hono on Lambda@Edgeも商⽤乗せられるとこだった - (⾊々あり別案に) - 趣味の驚き屋活動にリソースを取られていた - 書籍のハンズオンにHono⼀章載せてるので許して。。。 - ⾃分でOSSを公開した⽅がいい気持ちになってきた 14
15. 趣味の驚き屋活動にリソースを取られていた - Agentic Codingのバックエンドを Honoで書くハンズオン - 何と単著だと技術スタックを 私物化してよい - とは⾔え採⽤が不⾃然だと読者が 着いて来ないが、Honoだと安⼼ - マルチランタイム - 軽量‧⾼速 15
16. 「⾃分でOSSを公開した⽅がいい気持ち」 - 2024/01にv4のSSGを提案して、コミッタ－2⼈＋コントリビュー タ3⼈でわちゃわちゃ作った。 - 最初に提案したのは私（たぶん）。「アレ俺」感があった - でも、みんなで作ったコードべースで、冷静に何かそういうの違 うなって気持ちに - ⾃分で「アレ俺」と⾔えるものを作りたくなった - (サマーウォーズの例の画像) 16
17. 「アレ俺」への道のり
18. ⾃作OSS - 「⾃分が欲しいものを作る」編 • • • Mohua ◦ Amazon SageMaker AIのリソースの稼働状態を⼀覧するGo製CLI ◦ コスト管理⽤（≒停⽌忘れ防⽌）のツール ◦ ちょうどいいList APIや、⼀覧⽤のコンソールがない Anhinga ◦ EBSボリュームと⽉額ストレージ費⽤を⼀覧するGo製CLI ◦ ボリュームの種類‧容量‧リージョンから費⽤を概算 ◦ ボリュームごとの費⽤と合計を、表‧CSV‧JSONで確認 Hawkling ◦ IAMロールの利⽤状況を確認‧整理するGo製CLI ◦ 指定期間使われていないロールを抽出 ◦ dry-runと確認付き削除で、不要なロールの整理を補助 18
19. Appendix. 元ネタ クラフトビール(Inkhorn Brewing)の銘柄 19
20. ⾃作OSS - 振り返り1 • 放置されている ◦ バイナリを公開しているので今でも動く • 理由 ◦ ツールの役割が⼩さい。LLMに作業イメージをSkillで渡せばいい ◦ 導⼊したり使い⽅を覚える⽅が⾯倒 • 特定の作業を簡単にできたが、実施頻度が低ければエージェントに指⽰ してしまえば⼗分 ◦ 参照動作のシンプル化だとエージェントに負けがち ◦ 課題の捉え⽅が良くないと、⾃分以外使わないし、続かない。 20
21. ⾃作OSS - 「⾃分が欲しくて、みんなも欲しいんじゃないか？」編 • • • Lecs ◦ ECSタスク定義をローカル実⾏するRust製CLI ◦ Docker‧Podmanを使い、デプロイ前に動作確認 ◦ Terraform‧CDKの定義にも対応し、起動順序やヘルスチェックを扱う Raptor ◦ GitHub Actionsをローカル実⾏するGo製CLI ◦ git pushの前に、CIの処理を⼿元で検証 ◦ 「act」と違ってCIのコマンドをローカルで叩くだけ gokui ◦ Agent Skillを導⼊前に隔離‧検査するGo製CLI ◦ Skill⼀式を未信頼データとして扱い、来歴とポリシーを確認 ◦ スクリプトだけでなく、Markdown内の指⽰も検査対象 21
22. どうなった？→上位互換が出た • • • Lecs ◦ ECSタスク定義をローカル実⾏するRust製CLI ◦ Docker‧Podmanを使い、デプロイ前に動作確認 ◦ Terraform‧CDKの定義にも対応し、起動順序やヘルスチェックを扱う Raptor ◦ GitHub Actionsをローカル実⾏するGo製CLI ◦ git pushの前に、CIの処理を⼿元で検証 ◦ 「act」と違ってCIのコマンドをローカルで叩くだけ gokui ◦ Agent Skillを導⼊前に隔離‧検査するGo製CLI ◦ Skill⼀式を未信頼データとして扱い、来歴とポリシーを確認 ◦ スクリプトだけでなく、Markdown内の指⽰も検査対象 22
23. ⾃作OSS - 振り返り2 • 「誰ひとり きみの代わりは いないけど 上位互換が 出回っている」 by 宇野なずき ◦ LLMパワーで作れる速度が概ね同じなので、勝つのが⼤変 ◦ 差別化 or 諦めない⼼が⼤切 ◦ それはそうとドパオジなので⼀旦凍結 23
24. ちょっと飽きてくるので Honoを使った製品達
25. ⾃作OSS - Honoを使う • kantan-ui ◦ UIを作れるTypeScript版Streamlit ◦ ⼊⼒欄‧グラフ‧チャットなどを宣⾔的なAPIで構築 ◦ HonoとWeb標準を基盤に、複数ランタイム対応が特徴 25
26. ⾃作OSS - Honoを使う 26
27. kantan-uiの今 • • 作ってみたものの、⾃分で使っていない ◦ 元のStreamlitの⽬的：フロントエンドのフレームワークわからん⼈でも簡単 に書けて、どこでも動く。楽に読めて⾯倒⾒やすい 私が想定していた前提が間違っていた気もする ◦ Easyにしたいフレームワーク＝LLMで楽に書いて、⼈間が楽に読む ◦ 実際のシチュエーション＝LLMで楽に書いて、⼈間が(あまり)読まない ▪ 「読まないなら普通にReact(Vue)使えばいい」がClaudeCodeで成⽴する 27
28. ⾃作OSS - Honoを使う • kumihan ◦ Markdown原稿を組版 プレビューするTypeScript製 ツール ◦ A4‧2段組‧Web記事の表⽰ と、静的HTMLへの書き出し ◦ Gitの変更箇所を、組版した ⾒た⽬のまま確認 28
29. kumihanの今 • • 上位互換が普通に出たけどひとまず 使う予定 悩んでるところ ◦ Honoの開発スタイルを参考に 「Web標準」「低依存」を⽬指し たら「Hono外したら？」って エージェントに⾔われる ◦ 「⾞輪の再発明」時代で皆さん どうしてますか 29
30. バイブコーディング 多作期を抜けて
31. ⾊々作った - Vibe Codingパワーで⾊々作った - 副次的なAI駆動開発のノウハウが読まれたりした - 作るのは楽しいのだけど、作り⽅⾃体が⽬的化してきた - HonoにContributeしてた時より情熱が薄い - エンジニアリングのためのソフトウェアを作りたくなってきた - ⾃家中毒と⾔えばそこまでなんだけど - エンジニア(⼈)とエージェント(AI)がどちらも使えるといい 31
32. Honoは私が諦めた地点を越えていた - ⼩さいコア部分であっても、組み合わせて⼤きな存在感を - 競合が居ても突き進み、有名フレームワークに - Honoから学び、もう少し腰を据えて物を作るべきなのでは 32
33. ハーネスエンジニアリング 33
34. ハーネスエンジニアリング 34
35. ⾃作OSS - ハーネス⽤途のOSS ここからは今まじめに取り組んでいるプロダクトです • 静的ガードレール(ptuf) • Github Actionsリンター(zghalint) • Pythonのデッドコード検出(chokkin) ←New！ 35
36. ptuf(Pre ToolUse Filter) • こういうのをコーディングエージェントのHookで⽌める 36
37. ptuf(Pre ToolUse Filter) • Honoポイント：複数エージェント対応 ◦ 現在８種類に対応。Claude Code, Codex, GitHub Copilot, Kiro CLI, Cline, Cursor, Pi, OpenCode ◦ Hookってマジでみんな思い思いに実装しててウケる ▪ 興味あったら実装読んでみてください • npm i -g @watany-dev/ptuf でインストールできます！ 37
38. zghalint • オールインワンGithub Actions⽤リンター ◦ actionlint + zizmorみたいな ◦ GitHub Actions、危なくなりましたからね • 最初はZig＋バイブコーディングのお試しで作っていたが、どうも actionlintの開発が⽌まってるらしく真⾯⽬に完成させることに 38
39. zghalint • Honoポイント：速い ◦ メモリアロケーションとかが⿁のように改善されている 39
40. chokkin • Python⽤のゼロコンフィグ‧デッドコード検出 ◦ npx knip みたいにuvx chokkinができます！ ◦ 疑陽性‧過検出の沼と戦っているが終わりが⾒えてきた • Honoポイントは特にないけど使ってくれ 40
41. HonoユーザーとしてのOSS • • • ⽬的をもってコントリビュートしようぜみたいな話しようとしてたんだよ Honoを組み込む ◦ 単に実装サボるだけにHonoを導⼊するといつか剝がれてしまう ◦ Honoの強みを活かして導⼊しよう Honoの魂を引き継ぐ ◦ 勝⼿に引き継ぐな ◦ マルチランタイム‧標準‧ゼロ依存‧⾼速‧最軽量は、全てコーディン グエージェント時代でも有効 ◦ ワイの作ったのも、良いと思ったら使ってください！ 41