チームで Google Stitch のプロンプトを共有する仕組みを作った話

2026.04.12

Google Stitch を個人で使っていると、「あの時のプロンプト、どう書いたっけ」が繰り返し起きる。同じ種類のUIを作るたびにゼロからプロンプトを考え直す。うまくいったプロンプトを次に活かせない。この非効率さが気になり始めたのが、チームでの仕組み化を考えたきっかけだった。

今回は、5人のデザインチームで「プロンプトライブラリ」を構築・運用した記録を書く。何を作ったか、どう使っているか、導入後に変わったことを整理する。

結論から言うと

プロンプトライブラリを作ることで、「初めてその種類のUIを作る人でも、ライブラリを参考に質の高い初稿を出せる」状態になった。チーム全体の Stitch の習熟速度が上がり、新しいメンバーのオンボーディングコストも下がった。一方で「ライブラリの鮮度を保つこと」が継続的な課題になった。

なぜプロンプトを共有しようと思ったか

きっかけは、同じチームの2人が同じ種類の画面（SaaSのオンボーディング画面）を別々に作ったとき、片方がすごく良いUIを出してもう片方が凡庸だったことだ。違いを聞いてみると、プロンプトの書き方が全然違った。良いUIを出した人は、ユーザーの課題・サービスのコンセプト・視覚的なトーンを丁寧に書いていた。そうでない人は「オンボーディング画面」だけだった。

このプロンプトの差が、アウトプットの差になっていた。良いプロンプトを書ける人の知識をチームで共有できれば、全員のアウトプットが底上げされる。そう思ってライブラリ作りを始めた。

プロンプトを「資産」として扱う発想

デザインシステムでは、コンポーネントを「資産」として共有・再利用する。これと同じ考え方をプロンプトに適用できないか——というのがライブラリ構築の基本発想だ。一度良いプロンプトを作ったら、それを消費して終わりにするのではなく、チームの共有財産にする。毎回ゼロから考えなくていい状態を作る。

プロンプトライブラリの必要性を感じた場面

ライブラリ構築の必要性を最も強く感じた場面が3つある。①新しいメンバーが入ったとき（Stitch の使い方をゼロから教えるコストがかかる）、②チームでプロダクトの一貫性を保ちたいとき（異なるプロンプトから作られたUIが統一感を欠く）、③複数プロジェクトを並行しているとき（プロジェクトごとのUIの方向性をプロンプトで管理したい）。この3つが重なったとき、ライブラリを作ることを決めた。

プロンプトライブラリの構造

ライブラリはNotionで管理している。構造は大きく3層に分かれている。

第1層は「ブランドプロンプト」。プロジェクト・クライアントごとのブランドアイデンティティを記述した定型文だ。ターゲットユーザー、ブランドトーン、カラーパレット、避けるべきスタイルを含む。新しい画面を作るとき、必ずこのブランドプロンプトを冒頭に置く。

第2層は「画面タイプ別プロンプト」。ダッシュボード、ランディングページ、フォーム、オンボーディング、設定画面、通知など、画面の種類ごとに効果的なプロンプトのひな形を用意している。各ひな形には「ここを変えるだけで使える」という可変部分がハイライトされている。

第3層は「実例コレクション」。実際に使ったプロンプト＋生成されたUIのスクリーンショット＋評価（何点か・どこが良かったか）を記録したページだ。成功例だけでなく失敗例も残しており「このプロンプトパターンはうまくいかない」という知見も共有している。

プロンプトの「テンプレート化」の方法

ひな形を作る際に気をつけたのは「汎用性と具体性のバランス」だ。汎用的すぎると「結局どう書けばいいかわからない」になり、具体的すぎると「特定のプロジェクトでしか使えない」になる。

解決策として「固定部分と可変部分の分離」を採用した。例えばダッシュボードのひな形は「[ターゲットユーザー]向け、[サービス種別]の管理ダッシュボード。[主要データ種別]の概要を一目で確認できるレイアウト。[カラートーン]の配色。[必須コンポーネント]を含む」という構造で書く。括弧の中だけを変えれば使えるので、初めての人でも質の高いプロンプトが書ける。

Notionでの管理フロー

Notionのデータベース機能を使い、各プロンプトエントリに「画面タイプ」「プロジェクト名」「評価（5段階）」「最終更新日」のプロパティを設定した。フィルターで「ダッシュボード × 評価4以上」のような絞り込みができるため、目的のプロンプトをすぐ見つけられる。

スクリーンショットの添付は必須にした。文字だけのプロンプトより、生成されたUIの画像が一緒にある方が「使えるかどうか」の判断が格段に速い。プロンプトを追加するときは「スクリーンショット1枚以上必須」というルールにした。

ライブラリ運用で起きた課題

構築してから3ヶ月が経過し、想定外の課題が2つ出てきた。

プロンプトの「陳腐化」問題

Stitch 自体が定期的にアップデートされるため、3ヶ月前に「これは効く」と思ったプロンプトが今は効かない、というケースが出てきた。ツールの性能が上がったことで、以前は細かく書かないと出なかったUIが、シンプルなプロンプトでも出るようになった。逆に、以前は通じた書き方が新バージョンでは違う解釈をされるケースもあった。

対策として「最終更新日」プロパティを活用し、3ヶ月以上更新がないプロンプトには「要確認」タグをつけるルールにした。定期的に古いプロンプトを実際に試し、現在も機能するか確認するメンテナンス作業が必要になった。

「追加はするが更新しない」問題

ライブラリに新しいプロンプトを追加するメンバーは多いが、既存のプロンプトを更新・改善するメンバーが少なかった。結果として「似たようなプロンプトが複数ある」状態が生まれた。どれが最新の推奨バージョンかわからなくなった。

解決策として「推奨プロンプト」を1つだけピン留めできる構造に変更した。同じ画面タイプのプロンプトが複数あっても「現在の推奨はこれ」を明示することで、迷わず使える状態に戻した。

ライブラリ導入で変わったこと

3ヶ月の運用を経て、変化した点を整理する。

新メンバーのオンボーディング速度：以前は「Stitch を一人で試行錯誤する」期間が1〜2週間あった。ライブラリを渡すことで、初日から質の高いUIを出せるケースが増えた
初稿のクオリティのばらつき：チームメンバー間の「初稿の質の差」が縮まった。プロンプト力の個人差に依存しなくなった
「あのプロンプト何だっけ」の消失：個人のメモや記憶に依存していたプロンプトが検索可能な資産になった
プロンプトについての議論が増えた：「このプロンプトの書き方、こうした方がもっと良くない？」という会話が自然に生まれるようになった

よくある質問（FAQ）

Q1. プロンプトライブラリはどのツールで管理するのが良いですか？

A. チームが日常的に使っているツールが最適です。私たちはNotionを使いましたが、Confluence、Google Docs、Slackのピン留め機能でも機能します。最も重要なのは「全員がアクセスできる」「検索できる」「スクリーンショットを添付できる」の3点です。

Q2. プロンプトライブラリを作るための最低限の内容は何ですか？

A. 最初は「画面タイプ別ひな形」5〜10個から始めることをすすめます。よく作る画面（ダッシュボード、フォーム、LP、設定画面など）のひな形を用意するだけで、日常業務への効果がすぐ出ます。完璧なライブラリを作ろうとせず、小さく始めて使いながら育てることが大切です。

Q3. プロンプトの著作権や機密情報の取り扱いはどうすれば？

A. 特定のクライアント名や機密情報をプロンプトに含めないことが原則です。ライブラリに保存するプロンプトは「一般化した形」に書き直してから追加するルールにしています。「A社のダッシュボード」ではなく「BtoB SaaSのダッシュボード」として保存する、という方法です。

Q4. プロンプトライブラリの更新を誰が担当するか決めた方が良いですか？

A. 最初は「誰でも追加できる、でも更新担当者を1人決める」形が機能しやすかったです。更新担当者（「プロンプトオーナー」と呼んでいました）を置くことで、陳腐化と重複の管理ができます。チームが大きければ画面タイプごとにオーナーを分けることも有効です。

Q5. プロンプトライブラリの効果はいつ頃から実感できましたか？

A. 15〜20個のプロンプトが蓄積された1ヶ月目頃から「あ、これ探せば似たのある」という場面が出てきました。蓄積量が少ない最初の2〜3週間は効果を実感しにくいですが、20個を超えたあたりで「ライブラリを開いてから作り始める」習慣が自然に生まれました。

Q6. リモートチームでのプロンプト共有で気をつけることはありますか？

A. 「追加・更新の通知をSlackで共有する」ルールが機能しました。ライブラリを更新したとき、SlackのデザインチャンネルにNotionのリンクと「こういうプロンプトを追加しました」という一言を投稿するだけで、チーム全員がライブラリの動きを把握できます。ライブラリは作って終わりでなく、「更新を共有し続ける」ことで生きた資産になります。