--- title: "go-blueprintの使い方｜createの全フラグとGoプロジェクト雛形の生成手順【v0.10.11】" url: "https://www.issoh.co.jp/tech/details/2698/" published: 2024-06-21 updated: 2026-10-20 categories: ["自動化"] publisher: "株式会社一創" --- # go-blueprintの使い方｜createの全フラグとGoプロジェクト雛形の生成手順【v0.10.11】 go-blueprintは、Goのプロジェクト構成をコマンド一本で用意するCLIツールです。フレームワークとデータベースドライバを選ぶと、cmd/internalに分かれたディレクトリと、ビルド用のMakefile、テスト、必要ならDocker Composeの定義までまとめて書き出されます。ただしネット上の解説には、実在しないサブコマンドやオプションを載せたものが少なくありません。この記事は2026年8月19日にv0.10.11を導入し、コマンドを実行して得た出力と生成物だけを根拠に、使えるコマンドと生成されるファイルを整理します。 ## まとめ - サブコマンドは`create`・`version`・`completion`・`help`の4つだけです。`init`や`new`、`build`、`run`といったサブコマンドは存在しません。 - 導入は`go install github.com/melkeydev/go-blueprint@latest`です。リポジトリのURL表記は大文字のMelkeydevですが、モジュールパスは全部小文字で、大文字のまま指定するとインストールが失敗します。 - `create`のフラグは`--name`・`--framework`・`--driver`・`--advanced`・`--feature`・`--git`の6つ。フレームワークは7種、ドライバは7種、追加機能は6種から選びます。 - 生成したプロジェクトのビルドと実行はMakefileが担当します。`make build`・`make run`・`make test`などが最初から入っています（ターゲット数は選んだドライバと追加機能で6〜10と変わります）。 - フラグを全部渡してもプロンプトが消えるだけで、`create`は最後まで端末を必要とします。CIコンテナで実行するなら擬似端末の割り当てが必須です。 以下、それぞれの根拠と実行結果を順に見ていきます。 ## go-blueprintのインストールとバイナリの置き場所 ### go installでの導入とPATH設定 go-blueprint本体はGoで書かれており、配布はgo install経由が基本です。次のコマンドで最新版が入ります。 ``` go install github.com/melkeydev/go-blueprint@latest ``` 導入できたかは`version`サブコマンドで確認します。2026年8月19日時点の最新リリースはv0.10.11で、公開は日本時間2025年7月11日（GitHubのpublished\_atは2025-07-10T19:44:34Z）です。出力は次の通りです。 ``` $ go-blueprint version Go Blueprint CLI version: v0.10.11 ``` ここで`command not found`になる場合、原因はインストール失敗ではなくPATHです。go installはバイナリを`$GOBIN`、未設定なら`$GOPATH/bin`（既定は`$HOME/go/bin`）へ置くだけで、シェルのPATHには自動で追加されません。`go env GOPATH`で場所を確認し、シェルの起動ファイルに以下を追記します。 ``` export PATH=$PATH:$(go env GOPATH)/bin ``` ### 大文字のMelkeydevを指定したときのインストール失敗 GitHubの表示名はMelkeydev/go-blueprintですが、リポジトリのgo.mod 1行目は`module github.com/melkeydev/go-blueprint`と全て小文字で宣言されています。Goのモジュールパスは大文字小文字を区別するため、表示名どおりに大文字で指定するとダウンロードは通ってもモジュールパス検証で弾かれます。 ``` $ go install github.com/Melkeydev/go-blueprint@latest go: github.com/Melkeydev/go-blueprint@latest: version constraints conflict: github.com/Melkeydev/go-blueprint@v0.10.11: parsing go.mod: module declares its path as: github.com/melkeydev/go-blueprint but was required as: github.com/Melkeydev/go-blueprint ``` エラー文面が「version constraints conflict」で始まるためバージョン指定の問題に見えますが、直すべきはURLの大文字です。公式READMEのインストール手順も小文字表記になっています。 ## v0.10.11のコマンド体系 ### createとversionを中心とした4サブコマンド `go-blueprint --help`が列挙するサブコマンドは4つです。 | サブコマンド | 役割 | | ---------- | ------------------------- | | create | Goプロジェクトの雛形を生成する | | version | go-blueprint自身のバージョンを表示する | | completion | シェル補完スクリプトを出力する | | help | 各コマンドのヘルプを表示する | 実作業で使うのは事実上`create`だけです。プロジェクト生成後のビルドやテストを担うサブコマンドはgo-blueprint側に用意されておらず、その役割は生成物のMakefileへ移譲されています。ルートコマンドのフラグは`-h, --help`と`-t, --toggle`の2つのみです。 ### createで指定できる6フラグと許可値 `go-blueprint create --help`の出力そのままの一覧です。許可値はリポジトリの`cmd/flags/`配下で定義されている値と一致します。 | フラグ | 短縮形 | 許可値 | | ------------- | ---- | ------------------------------------------------------------ | | `--name` | `-n` | 任意のプロジェクト名 | | `--framework` | `-f` | chi・gin・fiber・`gorilla/mux`・httprouter・standard-library・echo | | `--driver` | `-d` | mysql・postgres・sqlite・mongo・redis・scylla・none | | `--feature` | （なし） | react・htmx・githubaction・websocket・tailwind・docker | | `--advanced` | `-a` | 真偽値（追加機能の選択プロンプトを出す） | | `--git` | `-g` | commit・stage・skip | ヘルプ表示用の`-h, --help`を除くと、指定に意味があるのはこの6つです。許可値以外を渡すとその場でエラーになり、有効な値の一覧が返ります。`--feature`だけは短縮形が無く、複数指定するときはフラグを繰り返します。ただし`--feature`は`--advanced`と併用しないと読み取られません。上流の`cmd/create.go`では`--feature`の値を取り出す処理が`--advanced`が真のときだけ走るブロックに入っており、単独で渡すとエラーも警告も出ないまま無視されます。 フラグの組み合わせをGUIで選んでコマンド文字列を組み立てられる公式のWeb UI（Blueprint UI）と、公式ドキュメントサイトも用意されています。手元で`create --help`を確認しつつ、選択肢の意味はドキュメント側で読む使い分けが実用的です。 ## Goプロジェクト作成の手順と端末要件 ### プロンプト消去と端末要件の切り分け `go-blueprint create`をフラグ無しで叩くと、フレームワークやドライバを矢印キーで選ぶ対話画面が立ち上がります。次のようにフラグで全項目を埋めれば、この選択画面は出ません。EchoとPostgreSQLの組み合わせで、Gitの初期化はしない指定です。 ``` go-blueprint create --name my-api --framework echo --driver postgres --git skip ``` ただし「プロンプトが出ない」と「端末が要らない」は別です。v0.10.11の`cmd/create.go`は、フラグが揃っているかどうかに関係なく生成中のスピナーをBubble Teaで起動します。このスピナーが`/dev/tty`を直接開くため、端末が割り当てられていない環境では上のコマンドでも失敗します。 ``` $ go-blueprint create --name my-api --framework echo --driver postgres --git skip < /dev/null Error: open /dev/tty: device not configured ``` 失敗しても何も残らないわけではありません。プロジェクト名のディレクトリだけが空のまま作られるので、リトライ前に削除が要ります。CIジョブやDockerコンテナで生成するなら、擬似端末を割り当ててください。`docker run`なら`-t`、シェルスクリプトからなら`script`コマンドで包む形です。 ``` script -q /dev/null go-blueprint create --name my-api --framework echo --driver postgres --git skip ``` 成功すると`cd my-api`を促すメッセージが出て、カレントディレクトリ直下にプロジェクトが展開されます。 ### 生成されるディレクトリ構成とドライバによる差分 まず最小構成として`--framework standard-library --driver none`で生成した場合のファイル一覧です。 ``` minimal-api/ ├── .air.toml ├── .env ├── .gitignore ├── Makefile ├── README.md ├── cmd/ │ └── api/ │ └── main.go ├── go.mod ├── go.sum └── internal/ └── server/ ├── routes.go ├── routes_test.go └── server.go ``` エントリポイントは`cmd/api/main.go`の1本だけで、HTTPサーバの組み立てとルーティングは`internal/server/`に分離されます。テストの雛形（`routes_test.go`）とホットリロード用の`.air.toml`が最初から入っている点が、手書きの雛形との差になります。ドライバ無しでも`.env`は作られますが、中身は`PORT=8080`と`APP_ENV=local`の2行だけです。 ここにドライバを付けると差分が出ます。`--driver postgres`を指定した先ほどのmy-apiでは、上の構成に加えて次の3ファイルが増えました。 - `internal/database/database.go`：接続と疎通確認の実装 - `internal/database/database_test.go`：testcontainers-goで実DBを立てる統合テスト - `docker-compose.yml`：`postgres:latest`イメージの定義 依存も連動して増え、Echo＋PostgreSQLのgo.modには`github.com/labstack/echo/v4 v4.15.4`、`github.com/jackc/pgx/v5 v5.10.0`、`github.com/joho/godotenv v1.5.1`、`github.com/testcontainers/testcontainers-go v0.44.0`が並びます。ドライバはpgxのような低レベルドライバが直接入る構成で、ORMは含まれません。クエリを構造体にマッピングしたい場合は、生成後に[GORMジェネリクスAPIを活用した基本的な実装パターン](/tech/details/7062/)のようなORM層を自分で足すことになります。 なお生成されたgo.modの`go`ディレクティブには、実行したマシンのGoバージョンがそのまま書き込まれます。検証環境のgo1.26.5では`go 1.26.5`となりました。チームで版を揃えたい場合は生成直後に書き換えてください。各版の変更点は[Go 1.27の新機能・変更点まとめ｜最新バージョンの確認方法と移行ガイド](/tech/details/10416/)で確認できます。 ## 生成後のビルド・実行・テストを担うMakefile ### Makefileのターゲットと選択による増減 go-blueprintにbuildやrunのサブコマンドが無いのは、その役割を生成物のMakefileへ渡しているからです。ターゲットの本数は固定ではなく、選んだドライバと追加機能で変わります。下表は`--driver postgres`を指定したときの9ターゲットです。 | ターゲット | 実行内容 | | ------------- | --------------------------------------- | | `all` | buildとtestを連続実行 | | `build` | `go build -o main cmd/api/main.go` | | `run` | `go run cmd/api/main.go` | | `test` | `go test ./... -v` | | `itest` | `go test ./internal/database -v`（統合テスト） | | `docker-run` | `docker compose up --build` | | `docker-down` | `docker compose down` | | `clean` | ビルド成果物のmainを削除 | | `watch` | airによるホットリロード起動 | 追加機能を付けずにドライバを`none`にすると`docker-run`・`docker-down`・`itest`が消えて6ターゲットになります。ただし`docker-run`と`docker-down`の有無を決めるのはドライバだけではありません。`--driver none`でも`--feature docker`を付ければこの2つは残り、欠けるのは`itest`だけの8ターゲットになります。逆にtailwindとhtmxを足すと`templ-install`と`tailwind-install`が加わり、`build`がこの2つに依存する形へ書き換わります。表の内容をそのまま前提にせず、生成後のMakefileを一度開いてください。 最小構成のプロジェクトで`make build`を実行すると9,250,192バイト（約9.2MB）の`main`が出力され、`make test`では雛形のTestHandlerがPASSします。生成直後に一度回しておくと、環境側の不備を先に潰せます。 細かい配慮も入っています。`docker-run`と`docker-down`は`docker compose`を先に試し、失敗したら`docker-compose`へフォールバックする二段構え。`watch`はairが未導入なら「インストールするか」を対話で尋ね、承諾すると`go install github.com/air-verse/air@latest`を走らせます。この対話も端末を要求するため、CIで`make watch`は使えません。 ### .envのBLUEPRINT\_DB\_接頭辞とdocker-composeの連動 ドライバを指定すると`.env`に接続情報が書き出されます。PostgreSQLの場合は次の内容です。 ``` PORT=8080 APP_ENV=local BLUEPRINT_DB_HOST=localhost BLUEPRINT_DB_PORT=5432 BLUEPRINT_DB_DATABASE=blueprint BLUEPRINT_DB_USERNAME=melkey BLUEPRINT_DB_PASSWORD=password1234 BLUEPRINT_DB_SCHEMA=public ``` 環境変数名がプロジェクト名ではなく`BLUEPRINT_`接頭辞で固定される点は、既存の設定管理と衝突しやすいので最初に確認してください。ユーザー名やパスワードは作者由来の既定値がそのまま入るため、公開リポジトリへ上げる前に必ず差し替えます。`internal/database/database.go`はこの変数名を直接参照しているので、名前を変えるなら両方の修正が必要です。 この`.env`は`docker-compose.yml`からも読まれ、`make docker-run`で立ち上がるコンテナの初期ユーザーとデータベース名になります。Compose側の記法を整理したい場合は[docker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説](/tech/details/13282/)が参考になります。 ## advancedモードで追加できる6機能と生成物の差分 ### featureフラグによる非対話での機能指定 `--advanced`を付けると追加機能の選択に進みます。選択画面を出さずに回すなら`--feature`で明示します。指定できるのはreact・htmx・githubaction・websocket・tailwind・dockerの6つです。前述のとおり`--feature`は`--advanced`とセットでなければ無視されるので、両方渡してください。 ``` script -q /dev/null go-blueprint create --name adv-api --framework chi --driver sqlite --advanced \ --feature docker --feature githubaction --feature tailwind --feature htmx --git skip ``` ### 生成される追加ファイルとCIでの落とし穴 この4機能を有効にすると、基本構成に対して次のファイル群が上乗せされました。 - `Dockerfile`：`--feature docker`が置くコンテナイメージの定義 - `.github/workflows/go-test.yml`・`.github/workflows/release.yml`・`.goreleaser.yml`：この3つはいずれも`--feature githubaction`由来（上流の`cmd/template/advanced/gitHubAction.go`が3テンプレートを埋め込んでいます） - `cmd/web/`：`base.templ`・`hello.templ`・`efs.go`など、Templによるサーバサイドレンダリング一式 - `tailwind.config.js`と`cmd/web/styles/input.css`、それに空ファイルの`cmd/web/assets/css/output.css`（中身は`make build`時に生成されます） - `cmd/web/assets/js/htmx.min.js`：HTMX本体を同梱（CDN参照ではない） ビルド系に足される2ターゲットには落とし穴があります。`tailwind-install`はダウンロードURLに`tailwindcss-macos-x64`を決め打ちしており、Linux上のCIで`make build`を回すとmacOS用バイナリを取得して実行に失敗します。`templ-install`のほうはtempl未導入時に`read -p`でインストールの可否を尋ねる作りで、こちらも端末が無ければ停止。tailwindやhtmxを有効にしたプロジェクトをCIへ載せるなら、Makefileのこの2ターゲットを先に書き換えるのが前提になります。 htmxとtailwindはTemplを前提にした組み合わせで、片方だけ選んでも成立しますが、フロントを持たないAPIサーバならどちらも不要です。githubactionは雛形のワークフローを置くだけなので、実行時間の課金設計まで面倒を見てくれるわけではありません。無料枠と超過単価は[GitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準](/tech/details/16698/)で先に確認しておくと、生成直後にワークフローを絞り込む判断がしやすくなります。 ## go-blueprintを採用しないほうがよい場面 1コマンドで動く組み合わせを試せる一方、向かない使い方もはっきりしています。 第一に、社内標準のディレクトリ規約が既にある組織には勧めません。go-blueprintの構成は`cmd/api`と`internal/server`に固定されており、出力先を変えるフラグはありません。既存規約に寄せるには生成後に手で移動することになり、それなら最初からテンプレートリポジトリをcloneしたほうが速く済みます。 第二に、独自テンプレートを配りたい場合も対象外です。v0.10.11の`create`にはテンプレートを外部から指定するフラグが存在せず、雛形はバイナリに埋め込まれた内蔵テンプレートのみです。組織固有の雛形を配布したいなら、テンプレートリポジトリかcookiecutter系のツールを使ってください。 第三に、CLIツールそのものを作りたい人の道具ではありません。go-blueprintが生成するのはHTTPサーバのプロジェクトで、サブコマンドや引数解析の雛形は出てきません。CLIを自作するなら、go-blueprint自身も採用しているCobraを直接使うのが素直です。 逆に、Goを触り始めた段階で「どのフレームワークとドライバの組み合わせが動く形になるのか」を短時間で確かめたい、あるいは検証用のAPIサーバを何本も立てたい、といった用途では有効です。7種のフレームワーク×7種のドライバを、依存の食い合わせを調べずに試せる点が実利になります。 ## よくある質問 ### go-blueprintでCLIツールそのものを自作できますか？ できません。生成されるのはHTTPサーバのプロジェクトで、サブコマンドやフラグ解析の雛形は含まれません。CLIツールを自作する場合は、go-blueprint自身が使っているCobraを直接導入してください。 ### go-blueprint newやgo-blueprint initは使えますか？ 使えません。v0.10.11の`--help`が示すサブコマンドはcreate・version・completion・helpの4つだけで、newやinit、build、run、testは実装されていません。これらを載せた解説が複数ありますが、実行すると`unknown command`になります。プロジェクト生成はcreate、ビルドと実行は生成物のMakefileという分担です。 ### go installしたgo-blueprintコマンドが見つかりません PATHの問題です。go installはバイナリを`$GOBIN`、未設定なら`$GOPATH/bin`へ置きます。`go env GOPATH`で場所を調べ、その配下のbinをPATHに追加してください。加えて、モジュールパスを大文字のMelkeydevで指定していた場合はインストール自体が失敗しているので、小文字で入れ直します。 ### 生成したプロジェクトのGoバージョンはどこで決まりますか？ 実行したマシンのGoバージョンが、生成されるgo.modの`go`ディレクティブへそのまま書き込まれます。go1.26.5の環境では`go 1.26.5`になりました。CIと開発機で版を揃える必要がある場合は、生成後にgo.modを編集してください。 ### 独自のテンプレートを読み込ませられますか？ v0.10.11ではできません。`create`のフラグ一覧にテンプレート指定用のオプションは無く、雛形はバイナリに埋め込まれたものだけが使われます。フレームワーク・ドライバ・追加機能の組み合わせで構成を変える設計です。 ## 関連記事 - [Go 1.27の新機能・変更点まとめ｜最新バージョンの確認方法と移行ガイド](/tech/details/10416/) - [docker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説](/tech/details/13282/) - [GORMジェネリクスAPIを活用した基本的な実装パターン](/tech/details/7062/) - [GitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準](/tech/details/16698/) - [Go開発者が知るべきcmuxの役割と接続マルチプレクサの基本動作原理](/tech/details/11492/) --- 出典: [go-blueprintの使い方｜createの全フラグとGoプロジェクト雛形の生成手順【v0.10.11】]()（株式会社一創）