Last updated on

Cursorへの短い指示で、テスト環境（サブドメイン作成・WordPressインストール・GitHubリポジトリ作成）を自動化した話

  • Cursor
  • Agent Skills
  • 開発環境
  • WordPress
  • シンレンタルサーバー

背景

シンレンタルサーバーの 「シンアカウントAPI」の提供開始（2026/04/22） により、サーバーパネルの主要な操作を REST API から実行できるようになりました。公式ニュースおよびリファレンスで説明されている範囲では、サブドメイン・FTP・WordPress 簡単インストール などもプログラム側から触れることができます。

もともとパネルから手作業で進めていた サブドメイン作成 や WordPress 簡単インストール なども、この流れでは REST API を叩く形で自動化できる視点になります。制作案件の検証環境づくりは手順の型が似通いやすいので、API 呼び出しの順序を Bash シェルスクリプトにまとめておくと、案件が増えたときの再現性と手戻りの少なさに直結します。

できるようになったこと

短文の指示（案件 ID・案件名・静的か WordPress かなど）を入口に、次の一式を同じ流れで用意できるようにしています。

  • サブドメインの作成（ホスティング API）
  • サブ FTP アカウントの作成（ホスティング API）
  • 手元の作業ディレクトリ（案件フォルダ）の作成（テンプレからの複製）
  • GitHub 上のリポジトリ（テンプレートリポジトリを元にした新規リポ）
  • そのリポジトリを clone したローカル（と npm install まで）
  • .env.deploy の生成（FTP ユーザー名・テスト URL などを案件 ID から埋める）
  • GitHub Actions 用 Secrets の登録（setup-secrets.sh）
  • 検証サイト向け HTTP Basic（静的は src/public に載せてビルド成果へ、WordPress は初回 git push 後の Actions がドキュメントルートへ FTP）

WordPress 案件なら、ホスティング側のあと 簡単インストール用 API を挟み、GitHub テンプレも WP 用に切り替える、という分岐も同じ束ねの中に入れています。

短文で「セットアップ」「一式」と依頼したときの 既定は、setup-case.sh に --with-all-post-steps を付けた1コマンドです（上記の post-steps 3つをまとめて有効化）。ユーザーが ②までだけ・Secrets／Basic は不要 と明示したときだけ、このフラグを付けません。

活用例

短い指示とコマンド実行

たとえば次のような 短いチャット指示（案件の識別子・名前・スタック）を、Cursor の プロジェクトルールや Agent Skills が読み替え、一発で呼び出す Bash のシェルスクリプトを実行する、という使い方です。

  • 「案件 ID 2026-04-30ex・案件名 ○○○ で、静的サイトの環境をセットアップして」
  • 「WordPress の検証環境を用意して／案件 ID 2026-04-30ex／案件名 ○○○」のように WP であることが分かる短文

実際の コマンドはユーザー（またはエージェント）のターミナルで動きます。Cursor が API を直接代行するのではなく、setup-case.sh が順番に別のシェルスクリプトを呼び出す形です。入口は次のとおり（ナレッジベースの skills/case-full-provisioning/scripts/ から実行する想定）。

# 静的・一括（短文「セットアップ」の既定）
setup-case.sh --with-all-post-steps 'CASE_ID' '案件名ラベル'

# WordPress・一括（WP 管理者パスワード等は環境変数で事前に export）
setup-case.sh --wordpress --with-all-post-steps 'CASE_ID' '案件名ラベル'

# ① サーバー側だけ済んでいる／サンドボックスで②だけ再実行
setup-case.sh --local-only 'CASE_ID' '案件名ラベル'

# 実行せず計画と preflight だけ確認
setup-case.sh --dry-run --with-all-post-steps 'CASE_ID' '案件名ラベル'

--with-all-post-steps の内訳は --with-env-deploy（.env.deploy 生成）・--with-secrets（GitHub Secrets 登録）・--with-basic（静的のみ apply-basic-staging）の3つです。WordPress では Basic はセットアップ中に apply-basic-staging を呼ばず、git push 後の Actions が docroot 用 Basic を載せます。

シェルスクリプトの中身（ざっくり）

秘密の値（API キーや FTP パスワード）は 環境変数に載せ、curl の -H "Authorization: Bearer …" で渡す前提です。本文に実キーを書かない。以下は 雰囲気用のスケッチで、省略・順序変更はシェルスクリプトの実装に準じます。

ホスティング側（シンアカウント API を curl で叩くイメージ）

# 自分のサーバー名を決めるためにまず応答を取る（よくある流れ）
curl -sS "https://api.shin-server.jp/v1/me" \
  -H "Authorization: Bearer ${SHIN_ACCOUNT_API_KEY}"

# サブドメイン一覧を GET して重複確認 → 未登録なら POST で追加 …
curl -sS "https://api.shin-server.jp/v1/server/${SERVERNAME}/subdomain?domain=${PARENT_DOMAIN}" \
  -H "Authorization: Bearer ${SHIN_ACCOUNT_API_KEY}"

curl -sS -X POST "https://api.shin-server.jp/v1/server/${SERVERNAME}/subdomain" \
  -H "Authorization: Bearer ${SHIN_ACCOUNT_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{ "subdomain": "...", "document_root_type": "full_subdomain", ... }'

# 続いてサブ FTP を POST で追加 …
curl -sS -X POST "https://api.shin-server.jp/v1/server/${SERVERNAME}/ftp" \
  -H "Authorization: Bearer ${SHIN_ACCOUNT_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{ "ftp_account": "...", "password": "...", "directory": "...", ... }'

# WordPress 簡単インストールまでやるときは、さらに …/wp へ POST
curl -sS -X POST "https://api.shin-server.jp/v1/server/${SERVERNAME}/wp" \
  -H "Authorization: Bearer ${SHIN_ACCOUNT_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://...", "title": "...", ... }'

GitHub 側（gh がリポジトリを作って clone するイメージ）

gh repo view "${GITHUB_OWNER}/テンプレのリポ名"
gh repo create "${GITHUB_OWNER}/新規リポのスラッグ" \
  --template "${GITHUB_OWNER}/テンプレのリポ名" \
  --private \
  --clone
npm install   # clone できたディレクトリで

手元の作業ディレクトリ（複製だけ先に済ませる流れでもよい）

cp -R "/path/to/🌱案件テンプレ" "/path/to/working/案件フォルダ名"
# 実際にはさらに「リポ用の空フォルダ」の都合で mv／mkdir が入ることもある

HTTP のパスや JSON の正しい項目名は 公式のシンアカウント API リファレンスが正本です。この記事のブロックは 見た目のたたずまいの共有にとどめ、コピペで動く完成形にはしていません。

設計で気をつけたこと

機能単位で Agent Skills を分けたのが実用的でした。

  • API 側だけ（サブドメイン・サブ FTP・必要なら WordPress 簡単インストール）と、ローカル＋GitHub（フォルダ複製・gh・clone・npm）と、Basic 認証（apply-basic-staging 等）とを 別 Skill／別のシェルスクリプトにしておき、再利用しやすくする。
  • 案件一式のように両方続けてやるときは、case-full-provisioning（setup-case.sh）が 上記を順に呼ぶイメージ（「単発は細かい Skill、一式は束ね」の二段）。post-steps（.env.deploy・Secrets・Basic）は --with-all-post-steps で連結し、短文依頼の既定にした。
  • preflight — 一括実行では ②の前提（テンプレ参照可・同名リポ無し・案件フォルダ無しなど）を ①より前に確認する。NG ならサーバー側に何も作らず中止するため、「サブドメインだけ作られてローカルで止まる」事故を避けやすい。
  • 静的／WordPress の分岐 — Basic の載せ方が異なる（静的は src/public、WP は Actions が docroot へ）。セットアップ脚本側でも WP 時は apply-basic-staging を呼ばない。
  • Wiki は背景・運用メモ・API の読み方、シェルスクリプト は再現優先の手順の正本、Skill と Cursor ルールは 実行順・トリガー語・短文入力の解釈 に寄せて重複を減らす。

セキュリティ上の懸念点

  • API キーや FTP パスワード・WP 管理者パスワードなどは、チャットに貼らない前提で、実行環境の 環境変数側に載せる設計にしている（プロビジョニング用は ~/.config/shin-account/env 等に一元化する方針）。
  • 検証用 Basic のユーザー名／パスワードは案件 ID から機械的に導出する 短い派生値であり、API キーや FTP パスワードのような秘密とは 同列に扱わない（一時的な検証環境の弱い門という割り切り。TEST_URL への埋め込みや Discord 通知は許容する運用）。
  • ニュースにあるとおり API キーに IP 制限が付けられるようになったので、キー流出時の被害を縮める選択肢も増えている（運用側で許可 IP の設計が必要）。
  • エージェント経由でターミナルを叩くとき、ワークスペース外への書き込み制限など実行環境の差で失敗することがあり、そのときは setup-case.sh --local-only で ②だけ再実行するか、ユーザー自身のシェルで同じシェルスクリプトを実行する、といった Operation not permitted への退避もセキュリティ／運用の境界として意識しておく。

今後の課題

  • API キーや運用パスワードの保管場所をさらに整理する（1Password／OS のキーチェーン／シークレット用のプロファイルのみ source など、環境ごとに最適化）。
  • DNS 反映の監視は wait-subdomain.sh をバックグラウンド起動し、反映またはタイムアウト時に Discord 通知する形を入れた。ただし nohup 起動のためマシンのスリープ等で監視が止まることがあり、SSL 発行タイミングともずれる — 完全自動の「見える状態」通知にはまだギャップがある。
  • ssl_status が success 以外のとき（DNS 未反映で SSL 発行失敗など）は警告を出して処理を続行するが、サーバー側の自動再試行は無い。DNS 反映後のパネル操作などリカバリ手順は Wiki／Skill 側に残す必要がある。
  • （既存どおり）外向き HTTPS や DNS の反映は別タイミングになりうるので、期待値と Wiki 側の注意書きを揃え続ける。

Q&A

REST APIって何？

ざっくり言うと、ウェブブラウザの画面を経由しないで、プログラムや curl などから HTTP（HTTPS）経由で「データの取得や登録」をやりとりする約束ごとです。

  • アドレスになる URL（例: …/api/…/subdomain）や、GET／POST といった HTTP メソッド、よくあるのは本文に JSON を載せて送り合う、といった形でやります。
  • サーバー側が「REST 風の API」としてドキュメント化しておけば、「パネルをクリックすると内部でこれと同じリクエストが飛んでいる」に近いことを、シェルスクリプトから自動化で繰り返しやすくなります。

厳密に「すべての条件を満たす純粋な REST」かどうかはサービスによって議論になりますが、この記事で言っている REST API は、上記のような HTTP で機械から操作できるサーバー機能という意味です。シンアカウント API がそうした入口の一例です。

おわりに

シンアカウント API をプログラムから呼べるようになったことが、パネル作業を 再利用可能なコマンド列に落とし込みやすい外因になりました。その上で 短文から setup-case.sh へ と Cursor の Skills／ルールで束ね、--with-all-post-steps まで含めると、.env.deploy・Secrets・検証用 Basic まで一気通貫に近づきます。一方で 秘密の持ち方と DNS／SSL の反映待ちは別問題として残ります。

npm run build・コミット・git push（初回デプロイで Actions を走らせる）は、意図的に手元に残しています。セットアップ脚本が土台まで整えたあと、中身を確認してから push する流れの方が安全だからです。