stackbook

← 作るもの

CLI・インフラツール

単一バイナリで配るツール

条件一般

推奨:Go

推奨

Go

  • 単一バイナリで配布しやすく、クロスコンパイルも簡単なGo(§2-9)

構成行を開くと詳細(乗り換える条件・根拠・費用・習熟度)

言語Go(Cobra、slog)

Go

公式サイト ↗

言語別の既定§2-2

選ぶ場面§2-10

  • Kubernetes・クラウドのコントロールプレーンを扱う
  • 中程度の常時接続+高スループットgoroutineで並行処理が簡潔に書け、運用も単純
  • サービス間のRPCProtocol Buffers周りのツールが充実し、単一バイナリで配りやすい

既定:CLIツール作成物ごとの言語の決め方

乗り換える条件

  • Rust起動時間・バイナリサイズ・処理速度を詰めたい
  • TypeScript(Bun)社内向けでnpmの資産を使いたい

既定:インフラ系ツール(Kubernetes Operator、Terraformプロバイダ等)作成物ごとの言語の決め方

代替:一般的なWeb API・SaaSのバックエンド作成物ごとの言語の決め方

既定は TypeScript(フロントと1言語に揃う)。3人以上で公開APIを長期運用するとき(§2-10 手順3) に乗り換える。

代替:開発者向けツール(Linter、フォーマッタ、ビルドツール、パーサ)作成物ごとの言語の決め方

既定は Rust。処理が軽く、開発速度を優先したいとき に乗り換える。

代替:データベース・検索エンジン等の基盤ソフト作成物ごとの言語の決め方

既定は Rust。GCの影響が許容できる分散系の制御部分 に乗り換える。

代替:スクリプト・社内の小さな自動化作成物ごとの言語の決め方

既定は TypeScript(Node.jsで直接実行、またはBun)。単一バイナリで配りたいとき に乗り換える。

採用の根拠§22-2

単一バイナリで配布でき、実行時の依存がない。メモリ使用量が小さく、同時接続に強い。Go 1互換性の約束により、長期間コードが壊れにくい。Docker、Kubernetes、TerraformなどインフラOSSの多くがGoで書かれている

「人材が少ないのでは」→ 言語仕様が小さく、他言語経験者なら短期間で読み書きできる

ケース別の構成§19

  • 自社SaaS(B2B)バックエンド:Go(net/http+sqlc+pgx)。少人数ならHono
  • toCサービス(Web+モバイル)バックエンド:Hono(またはGo)
  • リアルタイム系(チャット・通知・共同編集)同時接続が多い(Elixirを採用しない場合):Go(WebSocket)+Valkey Pub/Sub
  • インフラツール・CLI言語:Go(Cobra、slog)
  • 個人開発・MVPGo単体:Go+PostgreSQL+htmx

習熟度

Cobra

公式サイト ↗

既定:CLIGo

乗り換える条件

ケース別の構成§19

  • インフラツール・CLI言語:Go(Cobra、slog)

log/slog

公式サイト ↗

既定:ロギングGo

ケース別の構成§19

  • インフラツール・CLI言語:Go(Cobra、slog)
配布GoReleaser(GitHub Releases、Homebrew tap)

GoReleaser

公式サイト ↗

既定:リリースGo

代替:バイナリ配布Rust

既定は cargo-dist。Goと配布の仕組みを揃えたいとき に乗り換える。

ケース別の構成§19

GitHub Releases

公式サイト ↗

ケース別の構成§19

Homebrew

公式サイト ↗

ケース別の構成§19

性能が厳しい箇所Rust(clap、Tokio)

Rust

公式サイト ↗

言語別の既定§2-5

選ぶ場面§2-10

  • レイテンシの上振れが許容できない(p99で10ms未満が厳格に必要、§23-3)GCによる停止がない
  • CPU負荷の高い計算ネイティブ性能とメモリ効率

既定:開発者向けツール(Linter、フォーマッタ、ビルドツール、パーサ)作成物ごとの言語の決め方

乗り換える条件

  • Go処理が軽く、開発速度を優先したいとき

既定:ブラウザ内の重い処理(画像・動画処理、暗号、大量データの解析)作成物ごとの言語の決め方

乗り換える条件

既定:他言語から呼び出すライブラリ作成物ごとの言語の決め方

既定:組み込み・IoT・ファームウェア作成物ごとの言語の決め方

乗り換える条件

  • CベンダーSDKがCしかないとき

既定:データベース・検索エンジン等の基盤ソフト作成物ごとの言語の決め方

乗り換える条件

  • GoGCの影響が許容できる分散系の制御部分

代替:バイナリ配布Rust

既定は cargo-dist。Goと配布の仕組みを揃えたいとき に乗り換える。

代替:CLIツール作成物ごとの言語の決め方

既定は Go。起動時間・バイナリサイズ・処理速度を詰めたい に乗り換える。

代替:エッジ関数作成物ごとの言語の決め方

既定は TypeScript(Cloudflare Workers)。CPU負荷の高い処理がある に乗り換える。

代替:機械学習の学習・推論作成物ごとの言語の決め方

既定は Python。小さなモデルを単一バイナリで配りたいとき に乗り換える。

採用の根拠§22-2

GCがなく、C/C++並みの性能とメモリ効率を出しながら、メモリ安全性をコンパイル時に保証できる。WebAssemblyやネイティブ拡張として他の環境に組み込みやすい。近年の高速な開発ツール(Biome、Ruff、uvなど)の多くがRust製で、実用性が証明されている

「開発が遅くなるのでは」→ 性能・安全性が効く箇所に限定して使い、その他はGo・TypeScriptで書く(§2-10)

ケース別の構成§19

  • インフラツール・CLI性能が厳しい箇所:Rust(clap、Tokio)

習熟度

clap

公式サイト ↗

既定:CLIRust

ケース別の構成§19

  • インフラツール・CLI性能が厳しい箇所:Rust(clap、Tokio)

Tokio

公式サイト ↗

既定:非同期ランタイムRust

ケース別の構成§19

  • インフラツール・CLI性能が厳しい箇所:Rust(clap、Tokio)
CLICobra

Cobra

公式サイト ↗

既定:CLIGo

乗り換える条件

ケース別の構成§19

  • インフラツール・CLI言語:Go(Cobra、slog)
テスト標準 testing + go-cmp

testing

公式サイト ↗

既定:テストGo

乗り換える条件

  • testifyアサーションを簡潔にしたいチーム

go-cmp

公式サイト ↗

既定:テストGo

乗り換える条件

  • testifyアサーションを簡潔にしたいチーム
脆弱性チェックgovulncheck

govulncheck

公式サイト ↗

既定:脆弱性チェックGo

§19-10の構成を、選んだ条件に合わせて一部差し替えている

構成図 インフラツール・CLI

flowchart TB
  SRC["Go ソース"] --> GR["GoReleaser"]
  GR --> GH["GitHub Releases"]
  GR --> HB["Homebrew tap"]
  GR --> CR["コンテナイメージ"]

作り始める

共通の準備

# 言語・ツールのバージョン固定(使う言語だけ)
mise use node@lts pnpm@latest
mise use go@latest
mise use ruby@latest
mise use python@latest uv@latest

# Gitフックと依存更新
pnpm add -D lefthook && pnpm exec lefthook install
# renovate.json を置き、GitHubでRenovateアプリを有効化する

CLI(§19-10)

go mod init example.com/tool
go get github.com/spf13/cobra
goreleaser init

次に読む