ClaudeとWeWebを連携する方法 — ノーコードの画面づくりを会話で進める

ClaudeからWeWebを操作するとは

WeWeb MCPは、ノーコードのWebアプリ開発ツールWeWebのプロジェクトを、外部のAIクライアントから操作するためのリモートMCPサーバーです。サーバーのURLは https://ai-api.weweb.io/v1/mcp で、ClaudeのほかChatGPT、Cursor、Codexなども同じサーバーに接続できます。

エディタ内蔵のWeWeb AIとは別の入口です。使い慣れたClaudeの会話から、ページの作成、バックエンドの管理、ワークフローの編集、プロジェクトの調査までを自然言語で頼めます。

向きが一般的なチャット用コネクタと逆な点は押さえておくとよいところです。WeWebが外部サービスを呼ぶのではなく、Claude側のエージェントがWeWebの中に入って作業します。

Claudeのコネクタ一覧では「Anthropic verified」の表示つきで掲載されており、サインインが必要です。一覧には125個のツールが並びます。

つなぎ方はClaude DesktopとClaude Codeで違う

接続方法はクライアントごとに分かれています。Claudeの2つの入口では次のとおりです。

Claude Desktopはコネクタを追加するだけ

URLの貼り付けも設定ファイルの編集も要りません。手順は4つです。

追加できたら、ワークスペースとプロジェクトの一覧を出すよう頼みます。一覧が返れば接続できています。

Claude Codeは1コマンドで登録する

Claude Codeではサーバー名を WeWeb として登録します。

claude mcp add --transport http WeWeb https://ai-api.weweb.io/v1/mcp

最初にWeWebのツールを使う場面で認証が促されます。WeWebにサインインして、Authorizeでアクセスを承認します。JSONで登録したい場合はclaude mcp add-jsonの手順が使えます。MCPサーバー全般の考え方はClaude CodeのMCPサーバーガイドにあります。

どちらの場合も、認証のたびに承認画面が出ます。承認前に、要求されている権限の内容と、サインイン中のWeWebアカウントが正しいかを確かめてください。承認するまでは、エージェントはWeWebのツールを呼べません。

料金と前提条件は先に確かめる

接続できても、使い続けるにはプランの条件があります。

トライアルが始まるのは、接続した日ではありません。クライアントが初めてWeWebのツールを呼んだ日からです。接続の確認だけなら、プロジェクト一覧の取得より前に ping を呼ばせる手があります。ただし ping がトライアルの開始に数えられるかどうかは、ドキュメントに記載がありません。

Partnerプランで顧客のワークスペースに入る場合は、顧客側が少なくともProプランである必要があります。

もう1つの前提がバックエンドです。テーブル、テーブルビュー、認証、環境変数、バックエンドワークフロー、ストレージの各ツールは、プロジェクトにWeWeb Backendモジュールが入っていて初めて動作します。エージェントは getWeWebBackendStatus で導入状況を確かめ、未導入なら installWeWebBackendUrl でインストール用のURLを案内します。

何を任せられるか — 作業別のツール早見表

WeWebのツールは、エディタで触る部品と対応しています。ツールの名前を覚える必要はなく、やりたいことを日本語で伝えればエージェントが選びます。作業と主なツールの対応は次のとおりです。

このほか、ポップアップや再利用コンポーネントの作成、アイコン、環境変数、コード付きコンポーネントのためのツールもあります。Claudeのコネクタ一覧に出る名前と、WeWebのドキュメントの名前には一部ずれがあります。一覧にはテーブル行の追加が addRowToWeWebTable として載り、列の追加は addWeWebTableColumn です。名前の違いを気にせず、頼み方の側を整えるほうが実用的です。

エージェントは、作業前に getWeWebDocumentation で機能の仕様を引けます。出力がおかしいときは、該当機能のドキュメントを読むよう頼むと、次の試行が直ることが多いと案内されています。

公開だけはエージェントがしない

エージェントはサイトを公開しません。公開を頼むとプロジェクトのエディタへのリンクが返り、右上のPublishボタンを自分で押すよう案内されます。

公開した内容はアプリの利用者にすぐ見えます。データベースのマイグレーションを含むことがあり、その承認は本人にしかできないからです。この線引きがあるので、会話の流れで本番に反映されてしまう心配は減ります。

頼む順番はバックエンドが先、画面が後

複数の領域にまたがる依頼では、順番が結果を左右します。ドキュメントの推奨は、テーブルとバックエンドワークフローを先に作り、それに依存する画面をあとから作ることです。データが先にあれば、画面の部品をそこに結びつけられます。

次の流れが、問い合わせ管理の小さなアプリを作るときの頼み方の例です。内容は筆者が組んだ例で、ドキュメントに載っている文面ではありません。

1. WeWebのワークスペースとプロジェクトの一覧を出して。対象は「問い合わせ管理」。
2. このプロジェクトのバックエンドの導入状況を確認して。未導入ならURLだけ教えて。
3. まず問い合わせ用のテーブルを作って。列は氏名・メール・本文・状態(未対応/対応済み)。
4. 一覧表示用のテーブルビューを作って。状態で絞り込めるようにして。
5. ここまでの変更を一覧で報告して。画面づくりはそのあとにするから待って。

最後の「待って」が効く場面があります。バックエンドの結果を人が見てから画面に進めると、取り違えを早い段階で止められます。

プロジェクトを指定する手順も重要です。エージェントは最初に getMe を呼び、ワークスペースとプロジェクトを取得します。「いま開いているプロジェクト」という状態は持たず、呼び出しごとに指名されたプロジェクトを対象にします。作業を始める前に、狙ったプロジェクトが選ばれているかを確かめてください。

権限を絞って、変更を確認しながら進める

WeWebのツールには、作成・編集だけでなく削除系(deleteSection、deleteElement、deleteWeWebAuthUser など)が含まれます。本番のプロジェクトにつなぐなら、Claude側で呼び出しの条件を絞っておくと安心です。

Claude Desktopはツールごとに許可を選ぶ

Settings → Connectorsで、WeWebのコネクタを開きます。Tool permissionsで、ツールまたはツール群ごとに、自動実行・承認制・禁止のいずれかを選べます。

Claude Codeは権限ルールで止める

Claude Codeでは、MCPツールを mcp__<サーバー名>__<ツール名> の形で権限ルールに書けます。上の登録コマンドではサーバー名を WeWeb にしたので、次のように書けます。サーバーを別の名前で登録した場合は、その名前に読み替えてください。

{
  "permissions": {
    "deny": [
      "mcp__WeWeb__deleteSection",
      "mcp__WeWeb__deleteElement",
      "mcp__WeWeb__deleteComponent",
      "mcp__WeWeb__projectEditorBackup"
    ],
    "ask": [
      "mcp__WeWeb__alterWeWebTable",
      "mcp__WeWeb__deleteRowFromWeWebTable"
    ]
  }
}

この例では、画面の部品を消す系のツールと、バックアップのロールバックを含むツールを丸ごと禁止し、テーブルの構造変更(テーブルの削除を含む)と行の削除は毎回確認に回しています。projectEditorBackup はバックアップの一覧・保存・ロールバックを1つのツールで担っていると読めるため、禁止にすると保存もできなくなります。それが不都合なら ask に移してください。

この設定は筆者が選んだ線引きの例です。ツール名はWeWebのドキュメントの表記で、Claudeのコネクタ一覧では名前が異なる場合があります。設定した後は /mcp などで実際のツール名を確かめ、合わない名前は直します。

ロールバックを使うときの注意が1点あります。バックアップへの巻き戻しは、エディタの現在の内容をすべて置き換えます。バックアップ以降の作業は消えます。ただしエージェントは巻き戻しの直前に現在の状態をバックアップとして保存するので、巻き戻し自体も取り消せます。手動バックアップの保存はそれを含むプランが必要で、含まないプランでは保存を飛ばして依頼を続けます。

つまずきやすい点

プラグインのアクションは使えない

WeWeb MCPは、プラグインのアクションを公開していません。XanoやSupabaseのプラグイン経由で組まれたワークフローを、エージェントが新しく作ったり編集したりはできません。

回避策は、プロバイダに対応するIntegrationへ切り替えることです。XanoにもSupabaseにもIntegrationがあり、切り替えればエージェントが通常どおりアクションを組めます。

プラグインのままで進めたい場合の回避策も紹介されています。手で組んだワークフローをエディタからJSONとしてコピーし、AIに例として渡して、全文のJSONを返してもらい、貼り戻す方法です。ドキュメントはこれを非公式の暫定策と位置づけ、貼った後にエディタで開いて確認するよう求めています。

モデルはOpusが推奨されている

WeWebは、WeWebのツールをより確実に扱い、出力の質も高いという理由で、基盤モデルにClaude Opusを推奨しています。Sonnetなど他のモデルで試して結果が荒れたときは、モデルを替える選択肢があります。Opusの世代による違いはOpus 5.5とSonnet 5.5の違いで比べています。

先に探索させると依頼の取りこぼしが減る

複数のアプリにまたがる依頼では、依頼文に書かれていない場所に前提が置かれていることがあります。WeWebでも、既存のデザイントークンやクラスが決まっているプロジェクトに新しい部品を足すなら、先に既存の設計を調べさせたほうが揃います。探索を促す一文の書き方は複数アプリを先に探索させる一文で扱っています。

デザインシステムのガイドライン(命名やフォルダ、パレットのルール)は getDesignSystemGuidelines で読めます。新しい部品を作る前にこれを読ませる指示を入れておくと、既存の命名規則から外れにくくなります。

不具合を見つけたらその場で報告できる

wewebFeedback というツールがあり、ツールやドキュメントへの意見をWeWebのチームに直接送れます。出力が期待と違ったときは、状況をその場でエージェントに書かせて送れます。

どんな画面づくりに向くか

WeWebのドキュメントが示す範囲から言えるのは、会話で動かせる対象が「エディタで人が触る部品のほぼ全域」だということです。ページ、要素、デザインシステム、変数と数式、フロントとバックエンドのワークフロー、テーブル、認証、連携、コード付きコンポーネントが含まれます。

そのうえで、向きそうな場面は次の3つです。これらはツールの一覧から導いた筆者の見立てで、WeWebが保証する用途ではありません。

• 社内ツールの初期構築: テーブルとビューを先に作り、一覧と入力フォームを後から載せる流れ。上の頼み方の例がそのまま当てはまります
• 繰り返しの多い整備作業: 同じ形の部品を複数ページに足す、トークンやクラスを作って揃える、ページごとのSEO設定を直すといった作業
• 既存プロジェクトの棚卸し: getPageSemantic で構造を読み、変数やワークフローの一覧を出させて、どこに何があるかを把握する用途

反対に、プラグイン依存のプロジェクト、公開前の最終確認、データベースのマイグレーションの承認は、人が持つ判断として残ります。会話で組み、エディタのPreviewで確かめ、Publishは自分で押す。この分担が、ドキュメントの設計とも合っています。