アイデアを1コマンドで本番公開する - Claude Code の自作 Skill でサブドメイン立ち上げを自動化した話

「このアイデア、とりあえず形にして公開してみたい」。そう思ったとき、実際に立ち上がるまでの手数の多さで腰が重くなることはないでしょうか。雛形を作り、サブドメインを切り、リバースプロキシを設定し、TLS 証明書を取り、プロセスを起動し、疎通を確認する——アイデアそのものより、その周辺作業のほうが面倒です。

そこで、この一連の作業をコマンド一つで終わらせる Claude Code の自作 Skill を作りました。名付けて printemps-launch。「◯◯ で立ち上げて」と頼むだけで、ローカルの雛形生成から本番公開・証明書発行・疎通確認までを無人で完走します。

この記事は、その Skill の紹介と、なぜ Skill 化したのか・設計で何に気をつけたのかという体験談です。具体的なホスト名やポートなどの環境固有の情報は伏せ、考え方を中心に書きます。

何ができる Skill なのか

printemps-launch は、新しいアイデア ◯◯ を ◯◯.example.tokyo のようなサブドメインとして、ローカルの雛形生成から本番有効化まで通しで立ち上げる Skill です。「◯◯ で立ち上げて」「サブドメインを作って」のような自然な依頼で起動します。

やっていることを分解すると、だいたい次の10ステップです。

要するに「アイデア名を渡す」だけで、その名前の付いた本番サイトが1つ増える。手作業なら数十分かかり、手順を一つ飛ばすと詰まる作業が、待っているだけで終わります。

雛形は「最小構成」に振り切る

立ち上げの土台になる雛形は、あえて最小構成にしています。

{
  "dependencies": {
    "next": "16.1.6",
    "react": "19.2.3",
    "react-dom": "19.2.3"
  },
  "devDependencies": {
    "tailwindcss": "^4",
    "typescript": "^5",
    "eslint": "^9"
  }
}

Next.js 16 + React 19 + Tailwind CSS v4 + TypeScript だけ。狙いは「立ち上げの速さ」と「あとから何にでも育てられる余地」の両立です。最初から盛り込みすぎると、アイデアごとに不要な依存を抱えることになります。立ち上がってから、その用途に応じて App Router で作り込んでいけばいい、という割り切りです。

プロセス管理は PM2 を使い、サブドメインごとに自動採番したポートで next start する構成にしています。

module.exports = {
  apps: [
    {
      name: "◯◯",
      script: "node_modules/.bin/next",
      args: "start --port ◯◯◯◯",
      env: { NODE_ENV: "production" },
    },
  ],
};

なぜ Skill 化したのか

この種の作業は、一度シェルスクリプトにまとめることもできます。実際、危険な操作（証明書発行や Web サーバのリロード）はスクリプト側に寄せています。それでも全体を Skill にしたのには理由があります。

1. 自然言語で起動でき、文脈に応じて判断できる

「◯◯ で立ち上げて」と書くだけで起動します。さらに、立ち上げの途中で「このサイトはこういう用途だから page.tsx をこう作っておいて」といった追加の作り込みも、同じ会話の流れで頼めます。固定のスクリプトでは難しい「文脈に応じた分岐」を、Skill なら自然に挟めます。

2. 手順書とロジックを1か所に同梱できる

Claude Code の Skill は、SKILL.md（手順）と、それが使う bin/（スクリプト）や templates/（雛形）を1つのディレクトリに自己完結させられます。printemps-launch も、手順・デプロイスクリプト・Next.js 雛形・ポート台帳をすべて Skill のフォルダに同梱しています。

printemps-launch/
├── SKILL.md              # 手順（10ステップ）
├── bin/
│   ├── setup-subdomain.sh    # vhost生成・ポート採番
│   └── vhost.template.conf
├── templates/
│   └── nextjs-min/           # 最小 Next.js 16 雛形
└── PORT_REGISTRY.md      # ポート台帳（人間用ミラー）

これにより、どの作業ディレクトリから呼んでも同じように動きます。特定プロジェクトの中に置いたスクリプトと違って、「あのスクリプトどこだっけ」が起きません。

3. 「進捗監視下での無人実行」を明示的に許可できる

私のグローバル設定には「AI による自動デプロイは絶対にしない」という鉄則があります。本ブログの記事公開でも、本来はデプロイ前に確認を挟む方針です（トークンとコストの記事などはこのフローで公開しています）。

一方で、この Skill は環境構築を依頼している＝自分が進捗を見ている状況なので、SKILL.md の中で「この Skill は鉄則に対する明示的な例外であり、無人で通してよい」と宣言しています。Skill という単位があることで、「普段は確認、この作業だけは無人」という例外を安全にスコープできるのが効いています。例外を会話のたびに口頭で許可するのではなく、Skill の定義として固定できるわけです。

設計で気をつけたこと

無人で危険な操作（本番デプロイ・証明書発行）まで走らせる以上、設計はかなり慎重にしました。

各ステップで必ず成否を検証し、ハードエラーでは即停止

「失敗を無視して先に進まない」を最優先にしています。ビルドが落ちたらサーバには進まない、採番に失敗したら中断、証明書発行が成功文字列を返さなければ止めて状態を報告する——というように、各ステップに検証と停止条件を置いています。set -euo pipefail の記事で書いた「失敗したら止まる」の思想を、Skill 全体のレベルでも徹底した形です。

冪等性と再開可能性

途中で止まっても安全に再開できるように、各ステップを冪等寄りに設計しています。サブドメイン採番スクリプトは既存の vhost があれば自動中断し、リポジトリ作成は既存でも概ね無害。失敗時には「どのステップで・何が既に作成済みで・どこから再開すればよいか」を具体的に報告させるようにしています。

副作用を正直にログへ出す

この構成では、証明書を共有方式で再発行する都合上、発行のタイミングで他のサブドメインにも一時的な影響が出ます。こうした避けられない副作用は、隠さずログに明記する方針にしました。無人実行を許可しているからこそ、「何が起きたか」を後から追える透明性が重要です。

使ってみての所感

一番効いたのは、アイデアと公開の間の「摩擦」が激減したことです。これまでは「立ち上げが面倒だから後でいいや」と寝かせていた小さなアイデアが、思いついた流れのまま形になります。立ち上げの定型作業がゼロコストに近づくと、試す回数そのものが増えます。

もう一つは、手順が劣化しないこと。手作業だと「前回どうやったっけ」を毎回思い出す必要がありますが、Skill にしておけば手順は SKILL.md に固定され、改善も一箇所に集約されます。自分専用の「立ち上げボタン」を持っている感覚です。

まとめ

• printemps-launch は、アイデア名を渡すだけで雛形生成から本番公開・証明書発行・疎通確認までを無人で完走する自作 Skill
• 雛形は Next.js 16 + React 19 + Tailwind v4 の最小構成に振り切り、立ち上げの速さとあとから育てる余地を両立
• Skill 化の利点は「自然言語起動」「手順とロジックの自己完結」「無人実行の例外を安全にスコープできる」こと
• 危険操作を無人で走らせる分、各ステップの検証・即停止・冪等性・副作用の明記を徹底
• 効果は「アイデアと公開の摩擦が激減」「手順が劣化しない」。自分専用の立ち上げボタンになる

繰り返し発生する定型作業で、かつ「自分が見ている前提なら無人でいい」ものは、Skill 化の好相性です。あなたの環境にも「毎回同じ手順でやっている立ち上げ／セットアップ」があるなら、一度 Skill にまとめてみる価値があります。

参考リンク

• Claude Code スラッシュコマンド リファレンス（当ブログ）
• Claude Code Setup プラグイン 徹底解説（当ブログ）
• Bash の set -euo pipefail 解説（当ブログ）
• Next.js App Router の基礎（当ブログ）