概要
Sakupa は、静的サイトの公開と運用を行うための MCP サーバーです。npm パッケージ @sakupa/mcp として配布されており、公式 MCP Registry のほか、Claude、Codex、Gemini のプラグイン市場にも掲載されています。MCP 対応の AI エージェントに接続すると、初期化、公開前チェック、公開、状態確認、独自ドメインの接続、メールフォームの導入といった運用作業を、対話からそのまま実行できます。
特徴は、アカウント登録も API キーも不要なことです。サイトの管理権限は、サーバーが利用者のマシン上でローカルに生成する認証情報で表され、~/.sakupa/credentials/ に保管されます。プロジェクト側の .sakupa/project.json と .sakupa/site.json は、その認証情報への参照を持つだけです。「ログインして使うクラウドサービス」ではなく、「自分の環境でサーバーを動かし、その環境自体が管理権限を持つ」という設計になっています。
本記事では、個人 AI エージェント Muse に接続する場面を念頭に、接続から基本の流れ、メールフォームの付け方、料金までを手順として整理します。
接続方法
起動コマンドは次の通りです。
npx -y @sakupa/mcp@latest
運用環境ではバージョンを固定しておくと挙動が安定します（例：@sakupa/mcp@1.6.3）。
接続時に重要なのは、対象プロジェクトのルートを指定することです。指定がないと、サーバーが操作対象のプロジェクトを特定できません。指定方法はエージェント側の仕組みによって異なります。
- カスタムコネクタとして登録できるエージェントでは、コネクタ設定の中でサーバーとプロジェクトルートを指定する
- 環境変数
SAKUPA_PROJECT_ROOTにプロジェクトの絶対パスを設定する - MCP Roots 対応のクライアントでは、Roots 経由でプロジェクトルートを渡す
接続できたら、まずツール一覧を確認します。ツールは全部で 18 個で、公開・運用（init、analyze、deploy、refresh、status、delete）、課金（plans、subscribe、billing、change、portal）、ドメインと引き継ぎ（bind、recover、rotate）、アプリ（apps）、支援（help、support、report）に分かれます。困ったときは、まず help（話題を diagnose に設定）で診断するのが公式の推奨手順です。
基本の流れ：init → analyze → deploy
1. プロジェクトの初期化（init）
対象フォルダで init を実行すると、.sakupa/project.json が生成されます。通信も課金も発生せず、冪等に実行できる、土台だけを用意する初期化です。
2. 静的ファイルの準備
公開対象は静的ファイルです。手書きの HTML 一式でも、フレームワークのビルド成果物（dist など）でも構いません。入口となる index.html が必要です。
3. 公開前のチェック（analyze）
analyze は、公開対象が静的サイトとして成立しているかを事前に検査するツールです。主なチェック項目は次の通り。
- フレームワークと静的成果物ディレクトリの検出
-
index.htmlの有無 - SSR、API ルート、データベース依存など、静的公開と相性の悪い要素の検出
- 秘密情報やアーカイブなど、公開に含めるべきでないファイルの検出
- サイズ制限の確認
4. 公開（deploy）
deploy には、公開対象ディレクトリを指定する outputDir が必須です（プロジェクト直下なら "."、ビルド成果物なら "dist" のように相対パスで指定します）。
初回公開では無料プレビューが作成され、https://{shortId}.sakupa.com という形式の URL が発行されます。有効期間は 30 日です。初回公開は「URL を知っている人が誰でも開ける公開」になるため、ツール側が処理を止めて本人の確認を求めます（後述）。
5. 公開後の運用
-
status：URL、無料／有料の種別、有効期限、独自ドメインなどの状態を確認する（読み取り専用） -
refresh：無料プレビューの有効期間を延長する -
deployの再実行：内容を更新して再公開する -
bind：独自ドメインを接続する。DNS へのレコード追加が必要で、有効化の判定はツール側の HTTP 200 チェックの結果による -
delete：サイトを削除する（実行前にプレビューと本人の確認が入る）
メールフォームの付け方（apps）
静的サイトには通常、送信を受け付ける仕組みがありません。Sakupa には現在、唯一のアプリとしてメールフォーム（email-forms）が用意されています。フォーム送信を指定したメールアドレスへ届ける仕組みで、送信前にボットの判別も行われます。
ページ側の実装条件（ページ契約）
apps の catalog を読むと、ページ側で守るべき実装条件が返ってきます。
- ページに一度だけスクリプトを読み込む
<script src="https://api.sakupa.com/v1/forms/embed.js" defer></script>
- フォーム要素に
data-sakupa-form="<フォーム名>"を付ける。フォーム名は、そのまま通知メールの件名になる - ハニーポットとして、画面に見えないテキスト入力を 1 つ置く。既定のフィールド名は
websiteで、type="hidden"ではなく CSS で視覚的に隠すこと。入力したボットは静かに除外される - フィールド名が
emailの項目に正しいアドレスが入っていれば、そのアドレスが通知メールの Reply-To になる - 項目は最大 20 個まで。ファイル入力は対象外（添付は非対応）
- フォームの送信先を別のサービスに向けてはいけない。送信はスクリプトが受け持つ
有効化の手順
-
appsのinstallを実行し、通知先メールアドレス（notifyEmail）を指定する（この操作も実行前に本人の確認が入る） - 指定したアドレス宛に 6 桁の確認コードが届く
- コードをエージェントに伝え、
appsのverifyを実行すると有効化が完了する -
appsのtestでテスト送信して確認する
送信内容はサーバー側にも 30 日間保存され（1 サイト最大 1,000 件）、apps の inbox で確認できます。
確認と安全の設計
Sakupa の操作には、エージェントが自律的に進める作業と、必ず人の確認を挟む操作が分かれています。
-
deployの初回公開やappsのinstallなど、外に影響が出る操作では、ツールが処理を止めて確認を求める。確認はpublicConfirmedやconfirmedといった明示的な引数で返す形になっている - 課金が関係する操作（
subscribe、changeなど）は、ツール側では Stripe の公式ページへのリンクを作成するだけにとどまる。支払い自体は、必ず利用者が公式ページで完了させる -
deleteや認証情報の再発行（rotate）のような取り返しのつきにくい操作には、事前の内容提示と本人の決定が入る。旧い認証情報を失効させるかどうかも、利用者が自分で選ぶ事項とされている - 別の環境へ管理を引き継ぐ場合は
recoverを使う（デバイス経由と DNS 確認経由の手順がある）
「内向きの作業は速く、外向きの決定は止まる」という線引きが一貫しているのが、設計上の特徴です。
料金
- 無料プレビュー：30 日間。フォームメールは月 5 通まで
- Water：月額 200 円。独自ドメイン 1 個、フォームメール月 50 通
- Personal：月額 500 円。独自ドメイン 3 個、フォームメール月 200 通
- Share：月額 1,000 円。独自ドメイン 10 個、フォームメール月 600 通
- Business：月額 2,000 円。独自ドメイン 50 個、フォームメール月 2,000 通
有料プランの契約中は、その間サイトがオンラインに保たれます。
向いている場面、向いていない場面
向いているのは、会社や店舗の案内ページ、ランディングページ、問い合わせフォーム付きの小規模なサイトなど、「静的で十分なのに、公開と運用の手間だけが重い」場面です。接続しておけば、文言の修正や再公開、期限の確認といった日常運用を対話で頼めます。
向いていないのは、サーバー側の処理が前提のサイトです。データベースやログイン機能、動的な API が必要な構成は、analyze の段階で対象外として検出されます。
まとめ
使い方は「接続して、初期化して、チェックして、確認して公開する」という素直な流れです。アカウントも API キーも用意せずに始められ、大事な判断の手前では必ず止まってくれるので、エージェントに運用を任せる最初の一歩として試しやすい構成だと思います。