公開までの順番で読む Sakupa の 18 ツール：analyze から bind、recover まで
はじめに明記しておきます。私は Sakupa の開発者ではありません。MCP サーバーを調べていて見つけ、公式サイトと公式マニュアルの公開情報だけを整理した紹介記事です。実際に使った体験談ではありません。
Sakupa は、アカウント登録なしで、AI エージェントから静的サイトを公開・運用できる MCP サーバーです。公式マニュアルには、18 個のツールが載っています。今回は、その一覧をグループ分けではなく、サイトを一度公開するまでの実際の流れの順番に並べ直して読んでみます。順番に並べると、どの段階で何を確認するのかが見えやすくなります。
第 1 段：出す前の準備と読み取り専用のチェック
流れの最初にあるのは、準備とチェックです。
| ツール | 役割 |
|---|---|
init |
初回準備（ローカルのみ、通信なし） |
analyze |
公開可否の読み取り専用チェック。不適切なファイルを警告 |
status |
接続状態・有効期限・ドメインの状態を表示（読み取り専用） |
init は、最初の一回だけ行う準備で、ローカルのみで動き、通信はしません。次に analyze が、公開してよいかどうかを読み取り専用で調べます。ここで不適切なファイルが見つかれば警告が出て、公開は進みません。status は、その時々の状態を確認するための読み取り専用の表示です。
この段階の共通点は、サイトにも契約にも何も変えないことです。出す前に、まず読んで確かめる。流れの入口が読み取り専用に切り分けられている点が、最初の特徴です。
第 2 段：公開する
チェックを通ったら、公開の段階です。
| ツール | 役割 |
|---|---|
deploy |
確認後にサイトを公開 |
refresh |
無料サイトの有効期限を延長 |
deploy は、確認を経てからサイトを公開します。頼んだらすぐ公開されるのではなく、公開前にプレビューと確認が入ります。refresh は、無料サイトの有効期限を延ばすためのツールです。無料プレビューは通常 30 日で、期限が来る前に延長できます。
公開は一度きりの作業ではなく、内容を変えるたびに同じ段取りを繰り返すものです。だからこそ、「確認を挟んでから出す」という手順が、公開のたびに入ります。
第 3 段：自分のドメインを付ける
サイトが公開できたら、次は自分のドメインを付ける段階です。
| ツール | 役割 |
|---|---|
bind |
独自ドメインの接続（DNS で確認し、active かつ HTTP 200 で初めて「公開」と案内） |
bind の条件は厳しめです。ドメインを付けただけでは「公開した」とは案内されず、DNS での確認が通り、状態が active で、かつ HTTP 200 が返ることを確かめてから、初めて公開と案内されます。「付けた」と「見られるようになった」を分けて扱う点が、この段階の特徴です。
第 4 段：契約と支払い、そして窓口を足す
公開とドメインが整ったら、契約と支払い、そして機能を足す段階です。
| ツール | 役割 |
|---|---|
plans |
料金プランの公開カタログ（読み取り専用） |
subscribe |
選んだプランの Stripe 申込みリンクを作成 |
billing |
実際の契約・更新予定・利用量の照合（読み取り専用） |
change |
プラン変更・期末解約の Stripe 管理リンクを作成 |
portal |
請求書・支払い方法の Stripe ポータルを開く |
apps |
アプリカタログ。第 1 弾はメールフォーム |
契約の流れは、plans で料金を見て、subscribe で申込みリンクを受け取り、契約後は billing で実際の契約や利用量を照合する、という分担です。料金プランの公開カタログと、実際の契約を突き合わせる二段の確認が用意されています。有料プランは月額 200 円からで、公式情報の範囲では、自動で上位プランに上がる仕組みではありません。契約の単位はサイトごとです。
支払いの共通点は、AI がカード番号を扱わないことです。申込みや変更、解約の手続きは、AI が Stripe のページへのリンクを作り、実際の操作は本人が Stripe のページで行います。請求書や支払い方法の確認も、portal が開く Stripe のポータルで本人が確認します。
apps は、サイトに機能を足すためのカタログです。第 1 弾はメールフォームで、プランごとに月あたりの送信通数が決まっています。問い合わせの窓口は、サイトを作り直すのではなく、後から一つ足すものとして扱われています。通知先を設定すると、6 桁の確認コードが送られ、照合して初めて有効になります。
第 5 段：困ったときの取り戻しと鍵の交換
最後の段階は、公開した後で困ったときのものです。流れの順番では最後に置きましたが、設計の上では欠かせない部分です。
| ツール | 役割 |
|---|---|
recover |
デバイス経路または DNS 経路でサイトを取り戻す |
rotate |
管理クレデンシャルの交換（プレビュー後、旧クレデンシャルはすべて失効） |
delete |
無料サイトの削除（プレビュー必須、復元不可） |
help |
ローカルのみで動く読み取り専用診断 |
support |
サポートチケットの起票（送信前に内容を本人が確認） |
report |
help が推奨した場合に限る障害報告（プレビュー後に送信） |
Sakupa にはユーザー登録がありません。そのため、パソコンを買い替えた場合にサイトをどう取り戻すかが問題になります。その答えが recover で、デバイス経路と DNS 経路の 2 経路が用意されています。旧クレデンシャルの失効可否は AI が代わりに判断せず、必ず本人が選ぶ仕様です。
rotate は、管理クレデンシャルを交換するツールです。プレビューで交換内容を確認してから実行し、交換後は旧クレデンシャルがすべて失効します。delete は、無料サイトの削除で、プレビューが必須で、復元はできません。取り返しのつかない操作ほど、手順が重くなっています。
困ったときの相談も、順番が決まっています。まず help がローカルのみで診断し、report による障害報告は help が推奨した場合に限って送れます。support は、送信前に内容を本人が確認してからチケットを起票します。いきなり報告を送るのではなく、診断を通してから、という流れです。
流れの順番で並べて見えてくること
18 個のツールを、公開までの流れの順番に並べると、3 つの原則が繰り返し出てきます。
-
出す前に、まず読んで確かめる。
analyzeやstatusなどの読み取り専用のチェックが、流れの入口に置かれています。 - 変える操作は、プレビューと確認を挟む。 公開も、鍵の交換も、削除も、確認を経てから実行されます。
- お金と権限の判断は、人に残す。 支払いは Stripe のページへ、旧クレデンシャルの失効は本人の選択へ。
ツールの一覧を、グループ分けではなく流れの順番で読むと、「次に何が起きるのか」が見えやすくなります。MCP サーバーを評価するとき、一覧をこうして時系列に並べ直してみるのも、一つの読み方だと思います。
注意点（公式情報の範囲で）
- 対象は静的サイトのみで、データベースやログイン機能のある Web アプリには使えません。
- 比較的新しいサービスです（npm の初公開は 2026 年 7 月、公式タイムラインより）。導入を検討する場合は、まず無料プレビュー（通常 30 日）で小さく試すのが無難だと思います。
リンク
- 公式サイト：https://sakupa.com/
- 製品ページ：https://sakupa.com/product/
- マニュアル：https://sakupa.com/manual/
- npm：
@sakupa/mcp