Figma MCP と Stitch MCP、どちらを繋ぐか — 「画面がすでにあるか」で決める線引き

新しいアプリの設定画面を組む前の晩、私は MCP の一覧を眺めたまま手が止まりました。Figma のサーバーも Stitch のサーバーも、すでに登録してあったのです。どちらも「画面をコードに起こす」ための道具で、どちらを使ってもそれらしい SwiftUI は出てきます。それでも、片方を選んだ日は手戻りが少なく、もう片方を選んだ日は夕方に全部書き直していました。

その差は、道具の出来ではありませんでした。画面の正解を、先に誰が持っているか。 分かれ目はそこにありました。

最初にお伝えしたい結論

Figma MCP は、すでに存在する画面を読みにいく道具です。Stitch MCP は、まだ存在しない画面を起こす道具です。

デザイナーが（あるいは過去の自分が）Figma に仕上げた画面があるなら、Figma MCP を繋ぎます。コード側に求められるのは、決まった寸法や色、コンポーネントの構造に忠実であることだからです。逆に、頭の中に「こんな画面」というおぼろげな像しかないなら、Stitch MCP の出番です。プロンプトから画面の案を出してもらい、気に入った案をコードの出発点にできます。

個人開発では、この二つの状況が同じ週に交互にやってきます。だからこそ、使い分けの基準を言葉にしておくと、夜中に迷う時間がかなり減りました。

二つのサーバーが返してくるものの違い

迷う原因の多くは、「どちらも画面情報を返してくれる」という見かけの似かたにあります。実際には、返ってくるものの性格が違います。

観点	Figma MCP	Stitch MCP
入力の前提	Figma 上に確定した画面（フレーム）がある	画面はまだない。文章や参考画像から起こす
返ってくるもの	レイアウト・色・タイポグラフィなどのデザイン情報とスクリーンショット	生成された画面の案と、それをコードへ渡す情報
コード側に求められる姿勢	寸法・トークンへの忠実さ	案から取捨選択する判断
失敗の出かた	デザインとコードが数ピクセルずれる	毎回違う案が出て、基準が定まらない
向いている場面	デザインが固まった後の実装、既存アプリの改修	最初の叩き台づくり、方向性の探索

表の「失敗の出かた」の行が、私にはいちばん効きました。Figma 側のずれは、正解があるので差分として数えられます。Stitch 側の揺れは、正解がそもそもないので数えようがありません。揺れを楽しむ段階か、揺れを止めたい段階かで、選ぶ道具が変わるのです。

判断の線引きを三つの問いに落とす

私は、次の三つの問いに順に答えることにしています。

一つ目は、「正解の画面が Figma に存在するか」です。あるなら Figma MCP で決まりで、ここで終わります。二つ目は、「存在しないなら、いま欲しいのは案か、実装か」です。案が欲しいなら Stitch MCP で画面を起こし、気に入った一枚を残します。実装が欲しいのに画面がないなら、先に案を一枚決めるほうが近道でした。三つ目は、「その画面は今後も更新されるか」です。更新が続くなら、Stitch の案を一度 Figma へ置いて正解にしてしまうと、以降は Figma MCP 一本で回せます。

この三つを、迷ったときに機械的に通すためのスクリプトを置いておきます。判定だけを返す小さなものですが、夜中の判断を肩代わりしてくれます。

# choose_design_source.py
# 画面をコードに起こす前に、どちらの MCP を有効にするかを決める。
# 使い方: python3 choose_design_source.py --has-figma-frame yes --need proposal --keeps-changing yes
import argparse
 
 
def choose(has_frame: bool, need: str, keeps_changing: bool) -> tuple[str, str]:
    """(使う MCP, 理由) を返す。"""
    if has_frame:
        return "figma", "正解の画面が Figma にある。寸法とトークンを読みにいく。"
    if need == "implementation":
        # 画面がないのに実装を急ぐと、案の揺れがそのままコードの揺れになる
        return "stitch", "画面がない。先に Stitch で案を一枚に絞ってから実装する。"
    if keeps_changing:
        return "stitch→figma", "Stitch で案を作り、決まったら Figma に置いて正解にする。以降は figma。"
    return "stitch", "案の探索段階。揺れを許容して、気に入った一枚だけ残す。"
 
 
def main() -> None:
    p = argparse.ArgumentParser()
    p.add_argument("--has-figma-frame", choices=["yes", "no"], required=True)
    p.add_argument("--need", choices=["proposal", "implementation"], required=True)
    p.add_argument("--keeps-changing", choices=["yes", "no"], default="no")
    a = p.parse_args()
    tool, why = choose(a.has_figma_frame == "yes", a.need, a.keeps_changing == "yes")
    print(f"使う MCP: {tool}\n理由: {why}")
 
 
if __name__ == "__main__":
    main()

判定の中身は単純です。それでも、「画面がないのに実装から入ろうとしていないか」を毎回問われる効果は大きく、私は二度ほどここで足を止められました。

両方を常時つなぐと、何が起きたか

「迷うなら、両方つないでおけばいい」と考えた時期が、私にもありました。結果は芳しくありませんでした。

MCP サーバーは、繋いだ数だけツールの説明がエージェントの文脈に載ります。画面を起こす系のツールが二系統あると、エージェントは依頼文の言い回しひとつで、どちらを呼ぶかを変えてしまいます。「この画面をコードにして」と頼んだつもりが、Figma のフレームを探しにいったり、存在しない画面を Stitch で新しく作り始めたりしました。道具が多いほど正確になるわけではなく、むしろ、選択を私の代わりにエージェントがしてしまうのです。

いまは、使う側だけを有効にして、もう片方は定義を残したまま無効にしています。CLI の mcp サブコマンドなら、設定ファイルを開かずに切り替えられます。

# 一度だけ登録しておく（URL・トークンは自分の環境のものに置き換える）
agy mcp add figma --type http https://mcp.figma.com/mcp
agy mcp add stitch --type http --header "Authorization: Bearer ${STITCH_TOKEN}" YOUR_STITCH_MCP_URL
 
# 今日は Figma に正解がある日
agy mcp disable stitch
agy mcp enable figma
agy mcp list     # 有効なのが一つだけか、必ず目で確かめる
 
# 明日は画面を探る日
agy mcp disable figma
agy mcp enable stitch

Stitch の接続先 URL と認証方式は、公式の手順に出てくるものをそのまま使ってください。ここに書いた YOUR_STITCH_MCP_URL は、あえて空欄にしてあります。Figma 側も認証の取り方（ブラウザでの承認など）が環境で変わりますので、初回の接続だけは公式の案内を見ながら進めるのが安全です。

切り替えのたびに agy mcp list を実行する習慣は、地味ですが効きました。無効にしたつもりのサーバーが有効のまま残っていた朝が、一度ありましたので。

Stitch から Figma へ「正解を移す」場面

三つ目の問い、更新が続く画面の扱いについて補足します。

案を出すのは Stitch が得意でも、出てきた案を何か月も保守していくには、画面の正解がコードの外にも必要です。デザインを確認する相手がいる場合はなおさらで、「いまの正解はこれ」と指させる場所が要ります。私は、Stitch で気に入った一枚が決まったら、それを Figma のフレームとして置き直し、そこから先の変更は Figma 側で行うようにしています。

置き直す作業は手間に見えます。ところが、その後の実装で Figma MCP が寸法とトークンを読んでくれるため、ここで払った手間は二回目の画面から回収できました。案は Stitch で探し、正解は Figma に置き、コードは正解だけを見ます。 この一文を、自分への約束にしています。

判断がつかないときの、いちばん小さな試し方

三つの問いに答えても迷う日は、サーバーの切り替えより先に、既存の画面を一枚だけ試してください。たとえば、すでに実装済みの画面の Figma フレームを Figma MCP に読ませ、いまのコードとの差分を出してもらいます。差分が出るなら、その道具は「正解を読む」用途で信頼できるという目安になります。

Stitch 側は逆に、同じ依頼文を二回流して、出てくる案がどれくらい揺れるかを見ます。揺れの幅が許せるなら探索に向いていますし、許せないなら、その画面はすでに Figma で正解を決めるべき段階にあるのだと思います。

次にやること

まず agy mcp list を実行して、いま有効になっている画面系のサーバーが一つだけか確かめてください。二つ並んでいたら、今日の画面に「正解があるか」を自分に問い、答えに合わない側を agy mcp disable で外すところから始めていただければ幸いです。私も、この一手間だけは、どんなに急ぐ日でも省かないようにしています。