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 まで）
検証サイト向け HTTP Basic の設定（静的サイトはビルド成果に載せてデプロイ、WordPress はドキュメントルートへ配置する運用など、スタックで切り替え）

WordPress 案件なら、上記のホスティング側のあと 簡単インストール用 API を続けて呼ぶ、という分岐も同じ束ねの中に入れています。

活用例

短い指示とコマンド実行

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

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

実際の コマンドはユーザー（またはエージェント）のターミナルで動きます。Cursor が API を直接代行するのではなく、まとめられたシェルスクリプトが、順番に別のシェルスクリプトを呼び出す形です。

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

秘密の値（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）とを 別 Skill／別のシェルスクリプトにしておき、再利用しやすくする。
案件一式のように両方続けてやるときは、それ専用の まとめ用 Skill が 上記を Scenario として順に呼ぶイメージ（「単発は細かい Skill、一式は束ね」の二段）。
Wiki は背景・運用メモ・API の読み方、シェルスクリプト は再現優先の手順の正本、Skill と Cursor ルールは 実行順・トリガー語・短文入力の解釈 に寄せて重複を減らす。

セキュリティ上の懸念点

API キーや FTP パスワード・WP 管理者パスワードなどは、チャットに貼らない前提で、実行環境の 環境変数側に載せる設計にしている。
ニュースにあるとおり API キーに IP 制限が付けられるようになったので、キー流出時の被害を縮める選択肢も増えている（運用側で許可 IP の設計が必要）。
エージェント経由でターミナルを叩くとき、ワークスペース外への書き込み制限など実行環境の差で失敗することがあり、そのときはユーザー自身のシェルで同じシェルスクリプトを実行する、といった Operation not permitted への退避もセキュリティ／運用の境界として意識しておく。

今後の課題

API キーや運用パスワードの保管場所をさらに整理する（1Password／OS のキーチェーン／シークレット用のプロファイルのみ source など、環境ごとに最適化）。
HTTP Basic 認証を検証サイトに載せたいときの自動化や、配置ルールとの整理（現在の一式の外に置きがち）。
サブドメインの準備が完了したタイミングで通知を飛ばす（Slack／メールなど）— API の応答だけでは「ブラウザで見える」「証明書が効く」とはずれがあるため、人手確認と組み合わせたい。
（既存どおり）外向き 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 をプログラムから呼べるようになったことが、パネル作業を 再利用可能なコマンド列に落とし込みやすい外因になりました。その上で 短文からシェルスクリプトへ と Cursor の Skills／ルールで束ねると、案件ごとの検証環境づくりの負担をかなり下げられる一方、秘密の持ち方と 反映待ちの現実は別問題として残ります。

デプロイ用 .env.deploy の記入や GitHub Actions 用シークレットの登録など、自動化のあとも手が要るステップはわざと残しているので、その前提で運用すると安全です。