勉強会：『GopherのためのCLIツール開発』最新事情 LTに参加してきました

こんにちはid:bikun_bikunです。最近はGoからちょっと遠ざかっていたのですが、面白そうな勉強会を発見し参加してきました。

勉強会： https://findy.connpass.com/event/362163/findy.connpass.com

LT会で1つの発表は5分程度でしたが、CLIに特化したお話でなかなか楽しい勉強会でした。発表のアーカイブ、資料については上記イベントページからリンクを辿れるためそちらをご参照いただければと思います。

下記それぞれの発表で思ったことなどをまとめていきたいと思います。

それCLI フレームワークがなくてもできるよ

発表者：kuniwakさん

CLIツールを書くうえでフレームワークを使わない選択肢もあるよと言うお話

メリット：

利用しているライブラリのDependabotの指摘を受けることが少ない
妥協すれば数十行の短いコードと標準ライブラリで実装できる
年単位でメンテフリーが実現できることもある

機能が少ないと物足りず、機能が多いとフレームワーク的な感じになってしまう。上記メリットを活かすためにはちょうどいい機能群にすることが良いよ、そのためにどうしていくと良いか。という発表でした。

フレームワークのいいところ、フレームワークを使わないことで発生するいいところそれぞれあるよね。ということを改めて考えることができました。

Cursor & Devinで楽ちん！初めてのGo CLI開発

発表者：Rubitaさん

業務で小さな課題、毎回書いてるようなコードがあった。そんななかCursorが台頭してきたため週末プロジェクトでCLI化してみようと思い立った、機能追加でDevinしてみたというお話

AIエージェントを活用した例、小さなスコープ、小さな業務改善ですが取っ掛かりとしてはとても良さそうだなと思いました。私も個人開発でAIでの開発を少しづつ始めていますが、もっと踏み込むにはどうしたらよいか？というところで良いヒントが得られたと思います。

Go製CLIをnpmで配布する方法

発表者：syumaiさん

なんでGoのツールをnpmでpublishするの？というお話

ツールの対象ユーザの範囲を広げたい。 JSエコシステム向けのツールをGoで作るため。

有名どころで言うとesbuildがGo製になりましたね発表では配布方法2種（wasm, osbuild済みバイナリ）のメリット・デメリット npmへpublishする方法を詳しく説明されていました。

私の知らない世界のお話で話についていくので精一杯でしたがメリット・デメリットの話であったり注意点的なtipsがあり面白いお話でした。

GoでCLIを開発するTips 2025

発表者：Shunsuke Suzukiさん

GoでCLIを作ってきた中で培ってきたtipsのお話

loggerにツールのバージョン情報をいれる
- 問い合わせ対応のときにいちいちバージョンを聞かなくてもlogを貼ってもらうだけでバージョンがわかる
よく実装する機能をライブラリ化する
- 毎回書くのではなく切り出してしまうことでそこをメンテするだけで良くなる。
CIなども共通化してしまう
- 毎回CI書くのめんどいよね。簡単に実装できるようになるよ
CLIの設定ファイルのJSON Schemaを生成しておく
- JSON Schemaがあるとエディタでリアルタイム補完してくれるようになったりして便利
GoModuleのライセンスも配布しましょう
- お作法のお話
- go-licensesを使うといい感じに生成してくれる

細かめのtips集なお話でしたが、OSSを公開するときに忘れがちなところであったり全体の開発効率を上げるようなお話中心で「そうだよなぁ...」と思うことが多く基本に立ち返るような内容でした。

玄人向けツールknifeをClaude向けツールにした話

発表者：tenntennさん

自分用に作ったツール（コード補完をあまり使わない派、型情報などをテンプレートに乗せて吐けるツール）誰が使うんだろう（玄人向け）？みたいな使い方が難しいツールになった。 ClaudeCodeなどが出てきて、使うのが難しいツールだけどMCPサーバにして生成AIに使ってもらったらどうだろう？というお話

実際MCPサーバにして見たらあまり使ってくれないという事になった。
使わないのはなぜか？とかどういう物があると使ってくれるのか？というところをユーザインタビュー（ClaudeCodeに向けて）して改善していった。
結局CLAUDE.mdに使えというものを書いて使ってもらう感じになった。
ドキュメントの生成は人間がやると大変なので生成AIにやってもらうと楽だった（ただし嘘をつくので注意が必要）

ツールに関してというお話よりも生成AIを使った開発やどのように生成AIに使ってもらうかみたいなtipsでした。どのような設定にしていったらいいか？であったり、ドキュメントにどういう物があるといいか？というところが聞けたのでとても良かったです。

CLIツールをGoライブラリとして再実装する理由

発表者：ktrさん

go-fuzzyfinderというfzfのようなあいまい検索ができるライブラリを作ったお話

CLIツールとしてではなくライブラリとして再実装
なぜ再実装したのか？
- fzfなど外部コマンドを実行するようなものだと利用者にインストールしてもらわないといけない
- CLIツールの多くがライブラリ的な利用は想定されていない作りになっている
単純に作ってみたかった
調べていて面白かったのは設計思想であったり、スコアリングアルゴリズムを覗けたりした

再実装というお話を聞くと車輪の再発明的なお話が出てくることがありますが、私は再実装結構好きだったりします。自分で作ってみて元のツールはどんな実装だったんだろうと見比べてみたり、実装に詰まったときにどんな実装になっているかを確認するのが楽しいなと思います。発表者の方もそういったところがあったというお話を聞けて同じ考えの人がいてちょっと嬉しくなりました。

普段遣いのGo CLI

発表者：mattnさん

mattnさんが普段Goをどのようなところで使っているか、シェル辛い、Goのいいところというお話

Goの使い所
- ほぼほぼ普段使いしてしまっている
シェルを避ける理由
- ちょっとしたものを書くのは便利だけど...いろんな問題が出てくる
- 型が無いため数値を扱うのが苦手
- 中で呼び出しているコマンドが同梱されない...などなど
なぜGoで書くか
- シェルを避ける理由の逆になる
- 型があり安心
- シングルバイナリ（コンテナイメージが小さい）
- クロスプラットフォーム対応が楽...などなど

戻り値の型がわかりやすかったり、エラーはドキュメント読めばわかりやすいみたいなお話は確かにそうだよなぁ...というところと、まとめの中でちょっとしたものをGoで書いていると示唆になりあのときあんなこと書いたなぁみたいな振り返りができるというところがなるほどな〜と思いました。

次世代バリデーションツールgovalid

発表者：sivchariさん

ご自身で作っているgovalidというvalidationツールの紹介

既存のvalidationツールの問題点
- reflectベースでパフォーマンスが悪い
- structのバリデーションだとネストしてくるとその分時間がかかっちゃう...などなど
govalid
- 型安全にバリデーションコードを自動生成する
- 型の中で落とせるようなコードを生成する
結果
- 他のツールに対して圧倒的な処理速度になった

自分ひとりで作っていたが、コントリビュータが増えてきて世界中の人からプルリクエストが来るようになった。ブラジルなどからプルリクエストが来ると12時間単位でやり取りが発生してしまい、あまりうまくないという問題が出てきた。コンフリクトが起こらないような施策をし、diffで+だけが出るような仕組みを作っていき、やり取りが簡素になった。

プルリクエストをわかりやすくする工夫などコントリビュータが増えてきたからこその施策内容のお話などとてもためになりました。

alecthomas/kongはいいぞ

発表者：fujiwaraさん

フラグパーサライブラリalecthomas/kongの紹介

structにflagやサブコマンドを定義しておくことでkong.Parseに食わせるだけでフラグのパースをしてくれる。また、os.Getenvは実行時でないとわからない（奥深いところでGetenvしていると実行時じゃないとわからない）が、kongはパース時点でエラーを吐いてくれる。フレームワークではなくライブラリなので、パース以外の部分は自由に書けるので窮屈さがない。

godotenvなどを使うことが多いですが、引数、環境変数まとめてパースしてくれるのは便利な気がします。今度自分つくるツールで採用してみようかなと思えるパッケージに出会えました。