クライアントに「ここを直しましょう」と説明する。相手は忙しい。話は聞いてくれるが、テキストの提案書を読んでイメージを組み立てる余裕はない。「で、どうするの？」と返されて終わる。上司への改善案も同じだ。見せるものがなければ、話は次に進まない。

相手が求めているのは説明ではなく、「実物」だ。

この記事では、Claude・Geminiの2つのAIを自分だけの「チーム」として使い、提案の実物を短時間で作る方法を紹介する。実際にtechtech.clubのクライアントワーク（Webまわりの支援）でも使っているフローを、自社ページを題材にデモとして再現する。

この記事でできるようになること

30分後の状態：

  • 自分の提案テーマに対して、AIの役割分担と指示の出し方が決まり、提案の骨格（文章＋ビジュアルモック）ができている。

最終的な完成状態（1時間後）：

  • 改修提案の実物（ブラウザで表示できるHTMLモック＋提案ドキュメント）が完成し、相手に「見せて合意を取る」ところまで持っていける状態。

こんな場面で使える：

  • クライアントにWebサイトの改修を提案するとき
  • 社内で「このページ、こう変えたい」を通すとき
  • 営業資料やLPの改善案を、実物付きで上申するとき
  • 新規事業のプロダクトを「まず見せる」とき

結論

Claude・Gemini・人間の3体制で「提案の実物」を作る方法は、一人で回している人間や人が少ないスタートアップにとって実用的な手段だ。

デザイナーに依頼すれば数日〜数週間かかるモック作成が、1時間で終わる。クオリティは専門家には及ばないが、「合意を取る」という目的には十分すぎる。

向いている人：

  • クライアントや上層部に提案を通す必要がある人
  • 社内にデザイナーやライターがいない、またはいるが手が回らない、自分が兼務している人
  • 「実物がないと話が進まない」場面に頻繁に直面する人

向いていない人：

  • 実装するページのデザイン精度が求められる場面（本番実装には不向き）
  • 「なぜそこを直すのか」の答えを自分で持てていない段階の人（まず課題の特定から始めるべき）

一番重要なこと：

正直に書く。ClaudeやGeminiを使えば、提案資料は簡単に作れる。ページの改修案も簡単に出せる。だが、それは手段の話だ。

「なぜ今ここを直すのか」「なぜこのページなのか」「どんな目論見があって、実効性はあるのか」── この思考がなければ、どれだけきれいな提案書を作っても意味がない。AIが加速してくれるのは、あくまで「考えた結果を形にする」部分だ。考えること自体は、自分の仕事として残る。

この記事で伝えたいのは、その「考えた結果」をいかにスピーディーに形にして、相手の合意を取るかという部分だ。

最終アウトプット

今回のデモでは、techtech.clubのページ改修を題材に、以下の2つを作成した。

  • 改修内容の整理ドキュメント（Markdown） ── Claudeと議論して作成
  • 改修後のページモック（HTML） ── Geminiで生成。ブラウザで開けば実際のページのように表示される
「で、どうするの？」を言わせない ── AIの使い分けで提案の実物を作り、見せて決める技術
改修方針を整理したドキュメント
「で、どうするの？」を言わせない ── AIの使い分けで提案の実物を作り、見せて決める技術
既存デザインを踏襲した改修案のモックページ

相手にはこの2つをセットで見せる。「なぜここを直すのか」はドキュメントで、「直したらどうなるのか」はモックで。言葉と実物の両方で提案する。

具体的な使用方法と手順

前提：「なぜここを直すのか」は自分で決める

手順に入る前に、一つだけ。

今回のフローに入る時点で、「何が課題で、どこを直すべきか」はすでに決まっている状態を想定している。

課題の洗い出し、優先順位づけ、インパクトの評価──つまり「目的は何か」「現状はどうか」「理想と現実のギャップは何か」「そのギャップを埋めるために何ができるか」という思考は、このフローの前段階で済ませておく必要がある。

この前段階の思考プロセスは奥が深く、それだけで独立した記事になるテーマだ。今回は「直すべきことが決まった後、いかに速く形にするか」に集中する。

Claudeと議論する（補佐役）

このステップでの目的は、頭の中にある改修案を言語化し、提案ドキュメントとしてまとめること。きれいなドキュメント作成や資料を作ることはAIに任せればいい。人間がやることは「思考」だ。

Claudeとチャットで議論しながら、改修の方向性を固める。自分の考えをぶつけて、Claudeに整理してもらう。ここでのClaudeの役割は「賛成してくれるイエスマン」ではなく、「本当にそこを直すべきか？」を一緒に検証する壁打ち相手だ。

またClaudeを使う一番の理由は、迎合せず、本来の目的や核心をついてくれるから。「問い合わせページを改修したい」と言っても、「それは今じゃない、こっちをやるべき」と反論できるのがClaudeの良いところ。

「で、どうするの？」を言わせない ── AIの使い分けで提案の実物を作り、見せて決める技術
Claudeとのチャット

今回のデモでは、techtech.clubのページ改修を題材にした。

 

ステップ1：現状と課題を共有する

まず、改修したいページの現状をClaudeに伝える。スクリーンショットがあれば添付し、課題を箇条書きで共有する。

プロンプト例：

このページ（※）を改修したいと考えている。
添付したスクリーンショットが現状のデザインと構成。

目的：
現状の課題：
– [課題1]
– [課題2]
– [課題3]
制約条件：

これについて議論を深めながらやる・やらないの判断から、具体的にどうやっていくか議論したい。

 

ここでのポイントは、自ら手の内を明かさないこと。「この案があるんだけどどう思う？」とAIに伝えると、その案に引っ張られて会話が進んでしまう。だからあえて最初から自分が持っている案は出さずに俯瞰して議論を進めることをおすすめする。

また人間は「本当に良いアイデア」ではなく、「自分のアイデアを肯定してほしい」という承認欲求や「このアイデアが一番良い」というイケア効果などのバイアスが働くことがある点はAIを使う上で知っておきたい。

 

ステップ2：改修案を議論する

Claudeが提案してきた改修案に対して、採用・不採用・修正を判断する。ここが「指揮官」としてのあなたの仕事だ。

Claudeの提案を鵜呑みにしない。自社プロダクトや事業、社内事情、クライアント、業界知識など理解をもとに、取捨選択する。

 

ステップ3：ドキュメントとして出力する

議論ができ、方向性が見えてきたらClaudeに改修内容をドキュメントとしてまとめてもらう。

プロンプト例

議論で決定したことをマークダウンでドキュメントとして整理してほしい。
ページ改修において改修する目的、改修内容、改修理由も記載。

これで改修すべき箇所と、その理由、具体的な掲載文言がまとまったドキュメント（Markdown）が完成する。マークダウンにする理由は、AIがドキュメントの読み込み精度を上げるため。

「で、どうするの？」を言わせない ── AIの使い分けで提案の実物を作り、見せて決める技術
今回はデモで上記を使用

 

注意点：

Claudeは議論相手であり、最終判断者ではない。「AIがこう言ったから」は提案の根拠にならない

背景情報（業界、社内、クライアントの状況など）を、Claudeのプロジェクトのナレッジとして入れておくと、議論の質が上がる。だからいきなり「ページ改修をしたいからどうしたらいい？」と聞いても意味がない。

対人間と思って、情報を共有して仕事を進めること。

Claudeとのやりとりはドキュメント化まで。ビジュアルはこの後のGeminiで行う。

Geminiでビジュアルモックを作る（作業員役）

方向性が見えてきたら、次は改修後のページを「実物」として可視化する。

GeminiのCanvas機能を使い、改修後のページモックを生成。既存ページのデザインを維持しつつ、工程1で決めた要素を追加してもらう。

Geminiを使う理由は、既存ページのデザインを限りなく維持できるため。またCanvas機能が使いやすため今回はGeminiを使っている。

 

ステップ1：現状のページを読み込ませる

改修対象ページのスクリーンショットをGeminiに渡し、まずは現状を把握させる。

プロンプト例

（※対象のサイトとページ）を改修したいです。
添付した画像が現状のページデザインと構成です。
まずは添付画像をよく確認して、デザインや構成を確認・理解してください。

今回行いたいのはデザインのリニューアルではなく、要素の追加です。
確認後、どのような要素を追加したいのか共有します。
まずは現状のキャッチアップに努めてください。

いきなり改修指示を出さない。まず現状を理解させてから次に進む。これにより、既存デザインの再現精度が上がる。

「で、どうするの？」を言わせない ── AIの使い分けで提案の実物を作り、見せて決める技術

 

ステップ2：改修内容を渡す

工程1でClaudeと作成したドキュメントをそのまま渡す。

プロンプト例

以下に改修後に掲載したい内容（文言やパーツ）を共有します。
既存デザインを維持しつつ、新しい要素を追加してください。
作成したものはCanvasでプレビューできるようにしてください。

—
（ここにClaudeで作成したドキュメントをペースト）

「で、どうするの？」を言わせない ── AIの使い分けで提案の実物を作り、見せて決める技術

 

ステップ3：アウトプットを確認する

以下がGeminiが作成したアウトプット。既存デザインを踏襲した形で新しい要素を追加してくれている。

「で、どうするの？」を言わせない ── AIの使い分けで提案の実物を作り、見せて決める技術

「で、どうするの？」を言わせない ── AIの使い分けで提案の実物を作り、見せて決める技術

これは完成形ではない。あくまで方向性をスピーディーに確認するための資料の一部だ。

細かいところは実装するときに調整すればよい。これでコミュニケーションスピードは格段にアップするし、忙しい方々からの評価も上がるだろう。もちろん提案の方向性が合っている必要はあるが。

 

ステップ4：微調整する

修正があればGeminiに指示する。大きな構成変更やセクション追加はGeminiに指示を出す。

テキストの微修正や画像差し替えなど細かい部分は、生成されたHTMLコードを直接いじったほうが早い。

修正指示のプロンプト例

「こんな企業に選ばれています」のセクションについて修正をしてほしい。ロゴが多数表示される可能性があるため横スクロールさせてほしい。表示はゆっくりと、ロゴが人間の目で確実に視認できるスピードとする。

「で、どうするの？」を言わせない ── AIの使い分けで提案の実物を作り、見せて決める技術
Geminiが修正したデザイン

Geminiは、既存ページのデザインを95%は再現しつつ、新しい要素が追加されたHTMLファイルが完成する。

スクショやキャプチャで見せたり、ページを見せるならソースコードをコピーして、「.html」ファイルで保存。ファイルをブラウザにドラッグアンドドロップすれば実際のページのように表示できる。

 

注意点：

再現精度は95%程度。これは本番実装用ではなく、あくまで「合意を取るためのモック」として使うこと。それを必ず伝えることも忘れないように。

そしてGeminiのCanvas機能をオンにしないとプレビューができないので注意。

提案として仕上げる（指揮官の仕事）

ここまできたら、あとはドキュメントとモックをセットにして、相手に「見せて決められる」状態にする。

工程1のドキュメント（なぜここを直すのか）と工程2のモック（直したらどうなるのか）を組み合わせて提案を仕上げる。

具体的には：

  • ドキュメントに最終的な目を通し、相手に合わせて情報量を調整する
  • モックの最終確認。明らかな破綻がないか、見せたときに誤解を生む箇所がないか
  • 「このモックは方向性の確認用であり、本番デザインとは異なります」と一言添える

ここで重要なのは、相手の時間を奪わないこと。

忙しい相手は「読む」より「見る」ほうが速い。だからモックを見せて「こういう方向で進めていいですか？」と聞く。合意を取る、それだけでだ。

評価

項目 評価 コメント
コスト ★★★★☆ (4/5) 各AIの無料枠でも実行可能。だが有料プランで試行回数と精度を高めるのが良い
クオリティ ★★★★☆ (4/5) 合意形成には十分。本番実装用ではない点を理解して使う
使いやすさ ★★★☆☆ (3/5) 2ツール間の受け渡しに慣れが必要。2回目以降はスムーズ
汎用性 ★★★★☆ (4/5) Web改修に限らず「見せて通す」場面全般に応用可能
難易度 ★★★★☆ (4/5) 1時間で完了。デザイナー依頼と比較すれば圧倒的に手軽

使用ツール・コスト / 所要時間

  • コスト: 追加料金なし
  • 所要時間: 約 60 分

編集者あとがき

実際にこのフローを回してみて思ったのは、「見せる」と「説明する」では、相手の反応が全く違うということだ。

テキストベースの提案書を送ると、相手は「読む」という負荷を背負う。読んだ上で頭の中にイメージを構築して、それが正しいかを判断する。忙しい人ほど、この認知コストを嫌う。

一方、実物のモックを見せると「これでいい？」「ここをこうして」という具体的な会話が始まる。合意までの距離が一気に縮まる。

 

もう一つ。このフローの本質は「AIを自分の組織のように使う」という考え方にある。Claudeは補佐として議論を整理してくれる。Geminiは作業員としてビジュアルを形にしてくれる。自分は指揮官として判断に集中する。一人なのに、チームで動いているような感覚がある。

ただし、何度でも繰り返すが、AIが加速するのは「実行」だ。「なぜそこを直すのか」「なぜ今やるのか」という戦略的な思考は、自分の（人間の）頭でやるしかない。この部分を省略してAIに丸投げすると、きれいだけど的外れな提案ができあがる。

次に試したいのは、さらにこの業務フローを仕組み化して、誰でも行えて、アウトプットまでの時間を短縮すること。そうすれば思考に時間が使える。

あなたが次に「これ、こう変えたほうがいい」と思ったとき、説明する前に見せるものを作ってみてほしい。1時間で、相手の反応が変わるはずだ。

ジョン

Author

ジョン

techtech.club 編集長。メディアで起業し、元はスタートアップのプロダクトマネージャー。一度テクノロジーに賭けて挫折した。その経験がいまの生き方や考え方、事業の起点になっている。ここで書くのは答えではない。投資・キャリア・事業など専門家でなくても自分の頭で判断するための材料と視点。読者に教えるのではなく、一緒に考える側にいたい。

関連記事