AIで楽をするつもりが、374プロンプト。会社サイトを作ってわかった5つのこと

7月に創業した株式会社Eldipaのコーポレートサイトを公開しました。

今回AIネイティブ体制で作ってみようということで、Claude Codeを使い、私とエンジニア1名の2人体制で約3週間で制作しました。デザイン案は11案、ヒーロー動画の比較は55本、デザイン制作を通じて投げたプロンプトは374本のデザイン制作でした。※エンジニア側の実装プロンプトは含みません。

「1プロンプトですごいサイトができました」という話ではありません。

始める前は、神プロンプトを流用したりして、AIで楽に作れるかもと少し期待していましたが、結果的には374プロンプトも書くことになってしまいました。そんな夢みたいなことはこの世にないのです。

私（Eldipa代表）はコンテンツの精査・ライティング・デザインの意思決定を担当し、エンジニアは最終実装、検証・本番環境の構築と、AIが成果物を壊さないためのガードレールの設計を担当しました。

世の中には「こんな簡単なプロンプトでこんなサイトが！」という記事が溢れていますが、ああいう記事は驚きに特化しており、途中の実用的な工程がほとんど書かれていません。

今回は企業の実サイトを実務として作ったので、実際に使ったプロンプト原文と検討資料を見せながら、やり方を5つに絞って紹介できればと思います。使ったのは主にClaude Codeです。
※プロンプトは原文なので誤字等はそのまま残してあります

このブログが良いなと思ったら、noteやXをフォローしてくれると嬉しいです。

■なぜ自分で作ったか？

そもそもなぜ自分で作ったのかというと、理由は3つあります。

1つ目は現実的な話で、ネット銀行以外で法人口座開設しようと思うとコーポレートサイトがないと開設すらできないところがほとんどだからです。今後のデット調達などを考えると、ネット銀行＋地銀・信金・メガバンク等の複数の銀行と取引している方が良いので、それに向けてサイトを作る必要がありました。

2つ目は、AIの導入・実装支援・活用を掲げる会社として、最初の実務として自社サイトをAIで作ってみるのが筋だろうと考えたからです。やはり実務でやってみないとわからないことはたくさんあります。

流行りの「1プロンプトですごいサイトができる」というのを試して驚いても、実務でやろうと思うと細かいところが気になってそう簡単でなかったりすることも多々あります。今回はまさにそういう実務でないとわからないところを実際にやってみて拾っていこうと考えました。

3つ目は、人に依頼しても結局確認工数は同様に発生し、必要な文章等も自分で考えなければいけないからです。まだ事業が立ち上がってるわけでもなく、過去のコーポレートサイトがあるわけでもなく、何を書くか、どういうデザインにするかは経営者の頭の中にしかありません。

それを人を介してAIとやり取りするなら、直接自分でAIとやり取りしたほうがフィードバックループの回る速度が劇的に早くなり、クオリティも上がるだろうと考えたからです。

■やり方1：要件はファイルに書き、AIには「不明点」を挙げさせる

ビジネスサイドの人とAIの話をしていると良くあるのが「AIと話すとすぐ作業を始めて心配」「スレッドが長くなりすぎて全体が掴めなくなる」ということです。この原因はチャットだけでAIとやり取りをしているからです。

この解決方法として、自分の場合は、まずやりたいことなどの要件をマークダウン形式でファイルに書き出し、それをAIと一緒に詰めていく、というやり方を取っています。

このプロンプトのポイントは、「作って」ではなく「不明な点をリストアップして」というところです。これならAIが勝手に作り始めてしまうということはありません。

README.mdに書いているのは次のような項目です。概要、現状の整理、ターゲット、目的、デザインの方向性、グローバルナビゲーション構成案、Eldipaの事業内容・サービスラインナップ、参考情報などです。実物を見たい方は下記からDLしてみてください。

このプロンプトとREADME.mdに対してClaudeは18項目の疑問点・検討すべきことを提示してくれました。具体的にはドメイン、更新体制、フォーム実装をどうするか、モリサワは有償フォントである旨の指摘や、カラーコードの誤りなどです。

制作会社のディレクターがヒアリングで揃えてくれる論点が数十秒で出てくる感覚です。システム的な仕様についての質問などもあったため、それらは除外し、答えられるものはマークダウンファイルに追記し、下記のような感じでClaudeに戻します。

マークダウンをベースにClaudeに不明点を出してもらう。不明点を人間が埋め、決定をmdに書き戻す。マークダウンファイルが正、チャットは使い捨て、というやりかたです。会社内や制作会社とのやり取りが、ドキュメントと議事録で回るのと同じアナロジーです。

マークダウンへの記述は、人間がやることもあれば、Claudeにお願いして追記・修正してもらうこともあります。マークダウンファイルを元に共同作業するイメージです。

決定事項が文書に固定されるので、後から人間もAIも「あれってどうなったっけ？」にならず、日が空いた後にも人間もAIも同じ地点から再開できるようになります。

■やり方2：デザインは「方向性ごと実物HTML」で比較する

コーポレートサイトを作る際には、やはりデザインは重要です。とはいえこのプロジェクトで一番最初にClaudeに投げたプロンプトは下記のしょうもないプロンプトでした。

frontend-design（実装時に読み込む）とrunで十分、dataviz等は不要との回答で、スキルよりREADMEの情報の質が重要と指摘があったため、やり方１のREADME.mdを真面目に作りました。

デザインに入る前に、一通りのサイトの構成や文章、コピー等はREADME.mdで固めたうえでデザインフェーズに入りました。この時点で、企業ロゴはすでに制作済みで、ロゴを作る際にコーポレートカラー、ブランドトーンなども定めていました。

デザインフェーズでは、1案を磨き込むのではなく、方向性ごと比較しました。

デザインの方向性は事前にREADME.mdで「シンプルでモダン」「明朝をつかう」というようなことを書いていました。画像がないと映えないので、一旦手持ちの東京の町並みが写った動画を渡してデザインを依頼し、出てきたのが下記の3案。（ネーミングはClaudeによるもの）

デザインの方向性は当初README.mdに記載していましたが、方向性をいくつか検討し、後戻りもできるようにしたかったので、デザインは方向性ごとにDESIGN_0*.mdという感じで方向性ごとの基調、配色、背景の解釈、タイポグラフィ、レイアウトなどをまとめてもらいながら、パターンを作ってもらうことにしました。

初稿の3案は良いような気もしたのですが、もう少し別案も見たかったので、下記のように別の方向性を検討してもらいました。

社名の由来（北極星）が最も映えるのは夜空という論拠でダーク基調を提案されました。合わせてゴシック系のフォントのものも見てみたかったので、DESIGN_02.mdにそれを追記しデザインサンプルを作ってもらいました。

うーん、ダークトーン＆ゴシック体は全体的にいまいちです。これだったらDESIGN_01系のほうが良さそうなので、そちらをベースにヒーローエリアの動画を決め、そこから全体のデザイントーンをまとめていく形に方向転換することにしました。

■やり方3：素材は「全部入れて」から選ぶ＋AIに任せられなかった事

Claudeはこの質問に対し、「安く見える原因は素材より意味と処理」と整理し①現行空撮の磨き込み、②夜景空撮、③コード生成の星の日周運動、④代表実写、⑤動画なし、の5案を提示してきましたが、明らかにイマイチな提案です。

ちげーんだよ、求めてたのはそういうんじゃなくて「Adobe Stockで良さそうな動画を10案探してきました、どれが良いでしょうか。」みたいなやつです。

荒ぶりつつも「そうか、Adobe Stockで探してくれば良いのか」と気がついたので、自ら動画を探すことに方向転換しました。

現状の生成AIは動画や画像系はまだトークンコストが高く、生成や解析にも時間がかかるので、色んなパターンを一覧でどんどん出してくるとか、大量の画像からこれが合いそうだとピックアップするなどは苦手分野です。なので人手でやるしかありません。

地道にAdobe Stockで動画を探して、サンプル動画をダウンロードしてHTMLに埋め込んでもらい確認するみたいなことをしているうちに、結果的にAdobe Stockで70動画ほど選定し、そのうち55動画をHTML組み込んで確認するという形になりました。

素材候補が大量になったので、制作管理用のページもClaudeに作ってもらい、使う場所や購入済みかどうかや、購入ページへの導線なども整備してもらいました。デザイン制作会社が作ってくれる素材管理表をHTML化したようなものです（下記）。

結果的に採用した動画は4K版を9本購入。内容の密度が薄いサイトは会社まで薄く見えやすいので、外注しない分、素材には一定のコストをかける方針としました。

今回デザイン制作パートで何に一番時間がかかったかというと、この動画の選定作業でした。デザイン制作パートの実働は5日ほどでしたが、約1.5日をこの動画探しに費やしました。

何が難しく、時間がかかったかと言うと、会社の抽象的イメージから、検索ワードへの変換部分です。AIの会社なのにトップページの動画が森の空撮、魚群、月の映像である理由は次のような思考の変遷によるものです。

・AIによってルーチン的な仕事は減っていく
　↓
・人間は創造的でありたい
　↓
・創造力の源泉はプリミティブな探究心・好奇心
　↓
・機械より、自然に触れることでの発見や好奇心の喚起
　↓
・森の空撮・魚群・月などの動画

これらは文字的な連想からのロジックで出したというより、自分が気になった動画を探し、HTMLにはめ込んでみて、メインコピーとともに見てみた時にしっくり来るか、という作業を繰り返していくうちに見えてきた構造でした。

色々探してはめ込んでみると何故か機械っぽいもの、AIっぽいものよりも、自然っぽいもののほうがはまるし、創造性が解き放たれる感じがあるよな、ということに気が付き、上記のようなロジックに収斂していきました。

55本の動画をコピーと一緒に眺めて差し替えるうち、「Eldipaっぽい」「違う」の判断を55回繰り返し、結果的にやりたい会社の輪郭がよりはっきりしてきました。

メインビジュアルの部分は、前職のコーポレートサイトリニューアルでもデザイナーと大いに悩んだ部分です。ただこのプロセスをきちんとやると意思決定する側の解像度が上がるため、その後のデザインの判断も早くなるし、経営の意思決定においても軸が定まるためブレが少なくなると感じます。

こういうのはウォーターフォール形式だったり、制作会社とやっていると難しかったように思います。自分でやるか、隣にデザイナーがいるかみたいな体制でないと難しいように思います。

動画が確定したあとに、新たなデザイン案：DESIGN_03「ボールドエディトリアル・トーンブロック」を出してもらい、それをベースにDESIGN_01の要素と統合した最終版につながっていきました。

フォントも少し遊びを入れてみたものの、フォントはやはり最初のDESIGN_01 の明朝のほうがよかったのでそちらに戻すことにしました。一方文字組みは縦組みより横組みがよく、動画は全面に出てるDESIGN_03 D案がよかったので、それらを組み合わせることにしました。

これで出来たのが最終版のDESIGN_04「シネマティック・エディトリアル」です。（もちろん上記の指示の後に色々細かい調整が入っています。）

■やり方4：色は「検証ツール自体」を作らせて追い込む

今回AIを使っていて良かったなと思うのは、比較検討の材料だしや、複数パターンの検討などの意思決定のための材料を多く出せたことですが、一番AIっぽかったのは色の検証ツールを作ってもらったことかもしれません。

サイトのアクセントカラーの一つ「ルビーレッド」の色味が、制作の終盤になってもどうもしっくり来ませんでした。

序盤に差し色の検討でアクセントカラーのライムイエローと、アラート色の赤色として何案かだしてもらい、ルビーレッドに決めていました。

しかし、このブランドカラーシステムをパワーポイントにも展開して資料を作ったところ、いまいちこのルビーレッドがしっくりきませんでした。そこでルビーレッドの微調整をすることにしました。

従来ならここでデザイナーに「もう少し赤みをお願いします」などと伝え、「えっ、このタイミングですか？ 結構なページ数作ってますがまだモックでCSS共通化してないので全部やり直しですよ、マジですか…。まいったな、また徹夜か…。」などと言われながら数パターン出すのに数日待つ、の繰り返しです。

今回は相手はAIなので、人間であれば色調整のためにこんな実装はしないであろう、という提案をしてみました。サンプル見せてもらって→違う、みたいなやり取りは時間がかかるので、ルビーレッドを使ってるHTMLの色味を直接RGBスライダーで調整してベストな色味を探せるツールを作ってもらいました。

出来たのがこちら。上部のRGBスライダーをいじると下部のHTMLサンプルの色がリアルタイムで変わるようになっています。

また同じページで色覚多様性での見え方のパートも作ってもらいアクセシビリティのチェック等も行いました。

自分がデザイナーだった頃を思い出すと、「全パターン見せて」「やっぱり色を変えて全部直して」は、一番来てほしくない依頼でした。工数を思うと、頼む側も遠慮してしまいます。

AIによって製造コストは劇的に下がったため、意思決定の質を上げるためのツールやパターンだしにAIを使うというのは非常に理にかなった使い方に感じます。本来やったほうが質は上がるが、人間がやるとコストが高すぎて無理、というものをAIでやらせると、コストを低く抑えたたまま質を高められるなと感じました。

今回実際に作った検討資料は下記です。内容を全部解説しているとボリュームが半端ないので資料名だけ。

• ブランドカラーシステム検討

• 色彩設計比較（ライム色の役割分担）

• マーカー☓背景色の組み合わせ確認

• ルビーレッド微調整（RGBスライダー検討）

• Webフォント比較

• フッターレイアウト比較

• SPナビ（ハンバーガーメニュー）比較

• トップページサービス紹介面の背景動画

またガイドライン系の資料の整備も通常後回しになりがちで、作らなかったりもしますが、制作中にどんどん整備していきました。作りながらこれらも更新していくのは人間だと難しいですがAIだとすぐできるし、これらがあると判断もしやすくなり非常に良かったです。

• Webビジュアルスタイルガイド

• UIコンポーネントカタログ

• ブランドカラーシステム決定稿

■やり方5：原稿は、たたき台を出させて、自分で書き切る

最後に文章の話です。

文章は普段からよく書いている方ではあるので苦手ではないですが、トップメッセージのベストプラクティスはよくわからず、ベースとなるものがほしかったので一旦叩きをClaudeに出してもらいました。

特に何案か出せとは指示しなかったものの、私のプロフィールや会社のミッション、ビジョン等をみてA案、B案をだしてきたので、A案を選んだ上で、B案の良いところも盛り込む形で修正させました。

ただし、やはりClaudeに書いてもらったものだとミッション・ビジョンのくりかえしだったり、思いがのってない感じなので、参考にはしつつ全面的に書き換えしました。あたりまえですが経営者の想いや会社の物語は、AIには書けません。

仕上げのレビューはもう一度AIに依頼をしました。

AIはなんか聴くと必ず応えようとするクセがあるので「無理に論点を作る必要はありません」という指示をあえてしています。

この校正では誤字4件に加えて、本文中の「解決率75%」という数字が出典と食い違っている（正しくは70%）ことが検出され、実際裏取りしてみると70％が正しいことがわかりました。こういうところまで見てくれるのは非常に助かります。

■おまけ：AIに作業をさせない「語尾」の使い分け

374本のプロンプトを集計してみると、実装指示以外の言葉がかなりの割合を占めていました。

• 「意見をください」……24本（変種に「実装せずに意見をください」）

• 「〜はどうでしょうか？」……22本

• 「何案か出してください」……13本

• 「Fixとします／確定します」……28本

型化するのであれば次のような手順になります。
①質問する→②意見をもらう→③自分の案をぶつける→④複数案を出させる→⑤検討して提案させる→⑥実装させる→⑦確定を意思決定し宣言する。

発散から収束まで、段階ごとに語尾を使い分けるイメージです。AIがすぐ作業を始めて困っている方は、まず「実装せずに意見をください」から試してみると良いと思います。

■まとめ：作業より、まず検討材料を作らせる

5つのやり方に共通することは次の3つです。

1. 要件と決定はマークダウンに固定する
   チャットは使い捨てとしてつかう

2. AIにはいきなり作業ではなく、まず検討材料を作らせる
   案、比較ページ、検証ツール

3. 実物を見て、人間が選ぶ
   意思決定は必ず人間が行い、意思の反映と一貫性を保つ

AIに丸投げして「作らせる」ことも可能ですが、そうすると一見よくできていても、自社のことをきちんと語れるものにはなりません。よく見ると「なんだコレ？」というものになりがちです。

AIには「想像で勝手に作らせる」をやらせるのではなく、「不明点や必要な情報」をあげさせ、そのうえで「検討材料を作らせ」こちらの意思・意図を明確化させるのに使うのが重要だと思います。

今回AIをフル活用したにもかかわらず、実は私自身の作業時間は、従来の作り方とほぼ同じでした。3〜6ヶ月の外注案件で定例と宿題に費やしていた時間を集めると、今回の1週間とだいたい同じなのです。

速くなったのに、時間は減っていない。これが何を意味するのかは、反響があれば次回、「意思決定の構造」の話として書きたいと思います。

補足として、サイトの中身、特にコラム欄を支えているのはこの1年間で書きためた60本超のnote記事です。器は3週間で作れましたが、中身の密度は3週間では作れないので、そこは一定の時間とコストが必要です。

最後までお読みいただきありがとうございました。続編を書くかどうかは反響を見て決めるので、続きが読みたい方はスキ（♡）で教えてください。noteアカウントがなくても押せます。

株式会社Eldipaでは、HR領域におけるAIの導入やAIエージェント開発に課題感のある企業の方のお話を聞かせていただいています。興味のある方はコーポレートサイトやXのDM等からお気軽にご連絡ください。

なお今回は、私の担当範囲に絞って書きました。検証・本番環境や、AIが成果物を壊さないためのガードレールといったエンジニア側の設計は、それ単体で記事が1本書けるボリュームなので、今回は割愛しています。

関連記事