2026.02.13

Google Stitchを活用したアプリのUIデザイン──Manus・Claude Codeとの使い分け

by Nishimoto

Stitchとは

Googleが提供するAIベースのUIデザインサービスで、アプリやWebサイトのインターフェースを生成してくれるツールです。

いわゆる「UIデザインのたたき台」を作るためのサービスですが、実際に使ってみると想像以上に完成度が高く、そのまま開発のベースとして十分に使えるレベルでした。

私はこれまで、UIデザインの初期段階にManusを活用していました。Claude Codeに直接UIを作らせるよりも、Manusの方が「それっぽい」デザインで出力されるためです。

ワークフローとしては、Manusにある程度デザインを編集させて見た目が整った段階でClaude Codeに引き継ぐ、という流れで進めていました。

機能面の実装はClaude Codeの方が得意なので、役割分担としては理にかなっていたと思います。

ただし、大きな問題がありました。トークン消費量です。

Manusは利用コストが高く、月に$100ほど支払っていました。ちょっとした修正を重ねるだけでもトークンがどんどん削られていくため、コストパフォーマンスの面で常に気になっていたのが正直なところです。

結論から言えば、UIデザインのたたき台としてはStitchの方がはるかに使いやすいです。

まずコスト面。StitchはGoogle AIプランに含まれているため、もともと契約していた私にとっては追加費用がかかりません。

Manusに毎月$100支払っていたことを考えると、この差は大きいです。

デザインの品質も優秀で、Manusと遜色ないどころか、UIの整い方という点ではStitchの方が安定している印象を受けます。

そして何より嬉しいのが、MCPに対応していることです。これがワークフローを大きく変えてくれました。

Manusを使っていた頃は、まずClaudeとプロジェクトの仕様や要件を相談し、そこからManusに渡すプロンプトを作成していました。

しかし、この「Claudeで相談→プロンプト生成→Manusで実行」という流れの中で、どうしても定義漏れが発生します。

漏れに気づいて修正を指示するたびにトークンが消費されるため、コスト面でも精度面でも課題がありました。

StitchはMCPに対応しているため、Claude側からStitchのデザインを直接生成・確認することができます。

微調整もClaudeに指示を出すだけで済みますし、デザインの方向性についてアドバイスを求めることもできます。

つまり、Claudeとの方針のすり合わせが一つの流れの中で完結します。

「別のツールにプロンプトを渡して、結果を持ち帰って確認して……」というやり取りが不要になったのは、体感としてかなり大きな改善です。

Stitchに切り替えたからといって、Manusが完全に不要になったわけではありません。

ManusにはManusの強みがあり、特にUXの確認用モックとしての役割が残っています。

私のワークフローでは、まずStitchとClaudeを使ってUIのイメージを十分に煮詰めます。

デザインの方向性が固まったら、そこからプロンプトを生成し、Manusに機能としてのモックを作らせます。このモックをExpo Goで実機に表示し、実際に触って操作感を確かめるという流れです。

実機で触ってみると、画面上では気づかなかった「こうしたい」が見つかるものです。このフィードバックを得るためにManusのモックは非常に有用です。

なお、Manusが出力するデザインが多少気に入らなくても問題ありません。最終的なデザインはStitch側のものを採用するため、Manusのモックは純粋にUXの確認に専念できます。

この割り切りができるようになったことも、Stitchを導入した大きな収穫の一つです。

UIデザインのたたき台作成において、StitchはManusに代わる有力な選択肢です。

コストの削減、デザインの品質、そしてMCPによるClaudeとのシームレスな連携──これらを総合すると、個人開発者にとってはかなり実用的なツールだと感じています。

一方で、UXの実機確認にはManusを併用するなど、ツールごとの得意分野を見極めて使い分けることが大切です。

すべてを一つのツールに集約するのではなく、それぞれの強みを活かしたワークフローを組むことで、開発の効率と品質を両立できるのではないでしょうか。