HTML未経験から約1.5ヶ月でBtoBサイトを自作し、検索経由で受注まで届いた話
製造業のいちエンジニアが、HTML をまともに書いたことがない状態から、約 1.5 ヶ月で自社の技術部門サイトを単独で立ち上げました。 そして公開から数ヶ月後、そのサイトは「検索で見つけてもらう、問い合わせが来る、商談する、受注する、新規の取引口座が開く」という一連の流れを、最初から最後まで通しで生み出しました。
この記事は、その制作の経歴とこだわった点、実際の手順を、あとから再現できる「型」として言語化したものです。 技術者向けの部分もありますが、「専門外の人間が AI を相棒にどこまでやれるのか」という関心で読んでもらってもかまいません。
会社名やサイトの URL、取引先の固有名などは、公開範囲に配慮してぼかしています。作り方と考え方に注目してもらえればと思います。
まず、何が効いたのか
先に結論めいたことを書いておきます。 うまくいった要因は、「コードが書けるようになったこと」ではありませんでした。 書けるようには、なっていません。
効いたのは、誰に何を届けるかの設計と、成果を数字で見る習慣のほうでした。 技術は、その設計を形にするための手段です。 必要なぶんだけ、AI に肩代わりしてもらった。 その感覚がいちばん近いです。
私は何者か — 未経験だが、無知ではなかった
「未経験から」と書くと、ゼロからの独学美談に聞こえるかもしれません。 正直に言えば、コーディングはたしかに未経験でしたが、Web 集客そのものは初めてではありませんでした。 ここを正確に書いておかないと、再現しようとした人が前提を見誤ります。
前職は小売の販売でした。 全国の個人売上ランキングで上位に入ったこともあり、「人が何を見て、どこで迷い、何で決めるのか」を店頭でずっと観察してきた時間があります。 これが後々、Web の導線設計にそのまま効いてきました。 棚の前で客が立ち止まる場所と、ページで読者が離脱する場所は、驚くほど似た理屈で動きます。
もうひとつ、個人でゲーム系のブログを運営し、月間 3 万 PV まで伸ばした経験があります。 そこで SEO（検索で上位に出すための工夫）と CVR（訪問者が問い合わせなどの行動に至る割合）を、自分の手で計測しながら回していました。 「検索で上位を取る」「取ったあとに行動してもらう」という二段構えの感覚は、ほぼこの時期に作られたものです。
数字を毎日見て、タイトルを変え、離脱の多いページを直す。 その反復で、「何を変えると、人がどう動くか」の勘が身につきました。 今回の技術サイトで効いた判断の多くは、この時期の手応えの延長線上にあります。
つまり私は、コードは書けないが、集客の文法は知っているという状態からスタートしました。 ここが「本当のゼロ」との決定的な違いです。 逆に言えば、この文法さえあれば、コードの部分は AI に任せて成立させられる時代になった、というのが今回いちばんの実感でした。
会社での立ち位置も補足しておきます。 入社してから、マーケティング資料と会社サイトを一から作り直し、改善提案を規定の何倍もの数で出し（採用率は 100% でした）、外部コンサルより先に自社サイトのセキュリティ上の弱点を指摘する、といったことをやってきました。 社内で実質的に「デジタル周りを一人で見る人間」になっていたので、新しい技術サイトを立ち上げる話が来たときも、自然と自分の手元に落ちてきました。
店頭で学んだことが、そのまま効いた
少しだけ、前職の話を続けさせてください。 Web と関係なさそうに見えて、いちばん効いた経験だからです。
店頭では、客がどの棚で立ち止まり、何を手に取り、どこで戻して去っていくかを、毎日見ていました。 売れる売り場には、共通の理屈があります。 迷わせないこと。 そして、選ぶ理由を、目に見える形で置いておくこと。
これは、Web ページでまったく同じでした。 どこで読者がスクロールを止め、どこで離脱するか。 その場所は、棚の前の客とそっくりの理屈で決まります。 人が迷う場所と決める場所を知っていること。それが、コードの知識より先に効きました。
何を作ろうとしたのか
作ったのは、精密な断面研磨と分析を手がける技術部門のサイトです。 顧客は自動車部品や電子部品のメーカーで、要するに「削って、断面を見て、不良の原因を突き止める」という試験と分析のサービスを、必要としている技術者に見つけてもらうためのサイトでした。
BtoB の技術サービスは、検索する人の数こそ多くありませんが、一件一件の重みが大きい世界です。 「部品の断面で樹脂に割れが入る」「基板の実装部を綺麗に研磨したい」といった、具体的な症状を抱えた技術者が、ピンポイントで解決策を探しています。
一件の受注が、そのまま長い取引に育つこともあります。 だからこそ、数の多いキーワードを追うより、困っている当事者にまっすぐ届くことのほうが、はるかに価値を持ちます。 この世界では、訪問数の多さより、刺さり方の深さが勝負でした。
だから、なんとなく綺麗なコーポレートサイトを作るのではありません。 「症状で検索している人に、まっすぐ答えるサイト」を作る、という方針を最初に決めました。 この方針は、最後まで一本の軸として通っています。 デザインの判断も、コンテンツの優先順位も、構造化データの入れ方も、すべて「症状で来た人を、迷わせず、行動まで運ぶ」という一点から逆算しました。
技術構成と、その選び方
道具立ては、Next.js（React ベースの枠組み）と TypeScript、それに Tailwind CSS という見た目を整える道具を選びました。 配信の仕方も工夫しています。 アクセスのたびにサーバーでページを組み立てるのではなく、あらかじめ完成した HTML として書き出しておく方式（いわゆる「静的」な作り）にしました。 そのうえで、既存の会社サイトの一区画（サブディレクトリ）に、間借りするように置いています。
未経験者がいきなり React を選ぶのは、背伸びに見えるかもしれません。 ただ、選定の理由は「流行っているから」ではありませんでした。
第一に、静的に配信できることを最優先しました。 BtoB の技術サイトは、派手な動きより「速くて、落ちなくて、検索エンジンに正確に読まれる」ことのほうが何倍も重要です。 完成品として書き出せば、サーバー側の複雑さが消え、表示は速く、攻撃される面も小さくなります。
既存のコーポレートサイトと共存させる必要もありました。 独立した塊として置ければ、本体に手を入れずに増改築できます。 新しく作るサイトが、既存の資産を壊さない。 この安心感も、静的な構成を選んだ理由の一つでした。
第二に、AI と組んで開発することを前提にした選定でした。 TypeScript（書いたコードの間違いをチェックしてくれる仕組み）を使っておくと、AI が書いた間違いを、動かす前に見つけやすくなります。 部品を組み合わせて作る React は、「一部分ずつ作って、確かめて、次へ」という進め方と相性がよく、未経験者が AI と二人三脚で積み上げるのに向いていました。 ひとつのページを丸ごと理解できなくても、部品単位なら判断できる。 この状態を作れたのが大きかったです。
AI との実際の進め方
「AI を相棒に」と書くと、魔法のように聞こえるかもしれません。 実際は、もっと地味な習慣の積み重ねでした。 効いたやり方を、5 つに整理しておきます。
ひとつめは、部品単位で頼むことです。 ページ全体を一度に作らせると、どこが良くてどこが悪いのか判断できません。 「この見出しブロックだけ」「この表だけ」と小さく区切って作り、確かめてから次へ進みました。
ふたつめは、計画を先に出させることです。 いきなりコードを書かせず、「まずどう作るか、方針だけ教えて」と一度立ち止まらせます。 方向がずれていれば、この時点で正せます。
みっつめは、エラーをそのまま貼ることです。 英語のエラー画面が出ても、まるごとコピーして渡せば、原因と直し方が返ってきます。 「意味の分からない赤い文字」で心が折れる場面を、これで何度も越えました。
よっつめは、型（TypeScript）に助けてもらうことです。 生成されたコードの間違いが、動かす前に表面化します。 未経験者にとって、間違いを早く教えてくれる仕組みは、何よりの保険でした。
いつつめは、決めごとを一箇所に集約することです。 配色のルールも、書き方の約束も、一つのファイルにまとめておく。 そうすると、AI にも自分にも、同じ土台の上で作業してもらえます。
制作の流れ — 5 つのフェーズ
実際の進め方を、あとから再現できるように段階で切り出します。 当時はここまで綺麗に区切って進んだわけではありませんが、振り返ると自然とこの順序になっていました。
基盤を、静的サイトとして固める
まず、中身を作り込む前に「速くて壊れない箱」を用意することに時間を使いました。 静的に書き出し、既存サイトの配下に収まるようにパスを整え、まっさらな状態で表示速度とビルドの安定を確認する。 ここが緩いと、あとでコンテンツをいくら足しても土台から崩れます。
この段階で早めにつまずいたのが、URL の正規化まわりの不具合でした。 同じページに複数の入り口ができてしまい、検索エンジン（とくに Bing）が正しく登録してくれない状態になっていたのです。 これはかなり後になって気づいて直したのですが、本来はもっと早く潰しておくべきものでした。 「箱を固める」段階で、検索エンジンから見た URL の見え方まで詰めておくべきだった、という反省点として残っています。 （同じ URL 正規化の落とし穴は、末尾スラッシュの話 でも具体的に解説しています。）
逆に言えば、この失敗があったからこそ、土台の大切さが骨身にしみました。 華やかなコンテンツより先に、地味な土台の正しさを固める。 順番を間違えると、あとで積み上げるほど、土台のひずみが効いてきます。 最初にここへ時間を使う判断は、遠回りに見えて、結局いちばんの近道でした。
コンテンツクラスターを設計する
箱ができたら、次は「何について、どれだけ深く書くか」の設計です。 ここが今回の成否を分けた中心でした。
顧客が実際に抱える症状を洗い出し、テーマのかたまり（コンテンツクラスター）として束ねていきました。 中心に据えたのは二つです。 ひとつは「割れ（クラック）」、もうひとつは「樹脂埋めと硬化」。 断面研磨の現場で、技術者が最も頻繁に困るのが、この二つだからです。 そして実際に、この二つがのちにトラフィックの主要な入り口になりました。
加えて「削りにくい部品」のような、扱いが難しく相談が来やすいテーマも深掘りしました。 狙いは一貫しています。 浅く広くではなく、特定の症状について「ここが一番詳しい」と思われる濃さを作ることです。 検索する技術者は目が肥えているので、表面的な説明ではすぐ離脱します。 逆に、現場の温度感で書けている記事は、少ない訪問数でも高い確率で問い合わせに変わります。
たとえば「割れ」のクラスターなら、どんな部品で、どんな条件のときに割れが出るのか、断面でどう見えるのか、どう対処するのかまで踏み込みます。 一般論の「割れとは」で終わらせません。 現場で実際に検索される言葉と症状に沿って書く。 そこまでやって初めて、目の肥えた技術者の信頼に届きます。
この濃さがあれば、大手の検索連動広告と正面から競わなくても勝負になります。 広告費で殴り合うのではなく、深さで選ばれる。 小さな組織が BtoB の検索で戦うなら、これがいちばん現実的な戦い方でした。
SEO と GEO の構造を実装する
コンテンツの中身と並行して、それが検索エンジンと生成 AI の両方から正しく読まれるよう、構造を整えました。
SEO 側では、タイトルと説明文（メタディスクリプション）を一つひとつ書き直し、クラスターを継続的に深掘りし、画像も検索されるように整備しました。 画像は軽い形式（WebP）に変換し、ファイル名を内容が伝わるものにし、代替テキスト（alt）も丁寧に書く。 地味な作業ですが、BtoB の技術画像は「この断面写真そのもの」を探している人がいるので、画像経由の流入は馬鹿になりません。
検索エンジンは、機械が読める形で情報を渡すほど、正確に理解してくれます。 だから、人が読む文章と、機械が読む構造の、両方を整えました。 片方だけでは足りない、という感覚は、副業ブログの頃から変わっていません。
GEO は、生成 AI 経由での見つけられやすさ（Generative Engine Optimization）を指します。 まだ手法が固まっていない領域ですが、早い段階から意識して仕込みました。 具体的には、こんなことをしました。 「よくある質問」を、機械が読める形（構造化データ）でページごとに置く。 記事には、内容を機械に伝えるための印（JSON-LD という書式）を付ける。 今いる場所を示す道しるべ（パンくずリスト）で、サイトの構造をはっきりさせる。 狙いは、ChatGPT のような生成 AI が回答を組み立てるときに、自社のページを情報源として拾いやすくすることです。
正直、仕込んだ時点では手応えがありませんでした。 効いているのか分からないまま、それでも「これからは生成 AI 経由の発見が無視できない」という読みで、先に張っておいた。 その賭けが当たったことは、あとの成果のところで書きます。
計測して、改善を回す
公開後は、アクセス解析（GA4）で流入を追いました。 すぐに見えてきたのは、平日に流入が集中するという、はっきりとした BtoB らしいパターンです。 休日はほとんど動かず、業務時間帯に技術者が調べている様子が数字に出ていました。 これは「誰に届いているか」の裏づけとして、安心材料になりました。
問い合わせフォームを成果地点として計測し、どのページから、どんな検索から成約に近づいているかを見ながら、タイトルや説明文、クラスターの深さを継続的に手直ししていきました。 作って終わりではありません。 計測して、仮説を立てて、修正する。この輪を回し続けたのが、このフェーズです。
とくに役立ったのは、「どの検索語から来た人が、問い合わせまで進んだか」を見ることでした。 アクセスの多いページと、成約に近いページは、必ずしも一致しません。 数は少なくても成約に強いページを見つけたら、そのテーマをさらに深掘りする。 数字は、次にどこを厚くすべきかを、いつも指し示してくれました。
堅牢性を、外部の目で固める
最後に、技術的な堅牢さを第三者の視点で点検しました。 外部の監査を入れ、セキュリティ設定の整備や、代表的な脆弱性の観点でのレビューを済ませています。 表示速度の指標は 94〜100 の水準に収まりました。 先ほどの URL 正規化の不具合を直したのも、この前後です。
プロジェクトの記録やルールは、一つのドキュメントに集約しました。 あとから自分が見返すためでもあり、「自分がいなくても回る」状態に寄せていくためでもあります。 この「引き継げる形で作る」という発想は、私の仕事全般に共通する癖です。
一人で作ると、どうしても属人化します。 でも、ルールと記録を残しておけば、未来の自分や、いつか引き継ぐ誰かが動けます。 仕組みは、作った瞬間よりも、続いた年月で価値が出るものだからです。 だから「今動く」だけでなく、「あとで困らない」形を最初から意識しました。
つまずきと、その乗り越え方
順調な話ばかりに見えるかもしれませんが、つまずきは何度もありました。 代表的なものを、正直に残しておきます。
いちばん尾を引いたのは、さきほど触れた URL の正規化です。 同じ内容に複数の入り口ができ、検索エンジンが混乱していました。 原因は設定の噛み合わせで、気づくのが遅れたぶん、登録の回復にも時間がかかりました。 教訓は単純です。 土台の段階で、検索エンジンから見た URL の姿まで確かめておく。
次に多かったのが、環境づくりのつまずきです。 最初の準備、いわゆる開発環境のセットアップは、初心者が最初にぶつかる壁でした。 ここも、エラーをそのまま AI に見せることで、一つずつ解いていきました。
そして、いちばん痛かったのが、過信による失敗です。 AI の言うとおりにしたのに、動かない。 そういう場面で学んだのは、最後は自分で確かめる、という当たり前でした。 AI は速く手を動かしてくれますが、正しさの最終責任は、いつも人間の側にあります。
AIっぽくない、意図のあるデザインへ
デザインでは、いくつかの原則を自分の中で決めていました。
ひとつは、情報の優先順位から視線の流れを設計することです。 「まず何が目に入り、次に何と比較し、最後にどう行動するか」を、一見、比較、行動の順で組み立てます。
もうひとつは、役割ベースの配色です。 ブランド、行動を促すボタン、状態、警告といった役割ごとに色を割り当て、ひとつの色に複数の意味を兼任させないようにしました。 色が意味とひもづいていると、ユーザーは説明を読まなくても操作の見当がつきます。
そして装飾は、足すのではなく削ることで完成度を出す、という方針を取りました。 機能してほしいものを目立たせるには、それ以外を静かにするのが、結局いちばん効きます。
最近考えているのは、その先の話です。 AI に任せて作ると、どうしても平坦で均質な、いかにも「AI が出しました」という顔になりがちです。 それが嫌で、あえて崩す。 たとえば意図的に文字を小さくするような、人間のデザイナー特有の「揺れ」を、どう仕込むか。 規範ファイルに全部を従わせるのではなく、意図した不均一さをどう残すか。 ここはまだ、答えが出ていません。
エッジケースまで、デザインの一部として
見た目の美しさだけでなく、壊れにくさにもこだわりました。
長い文章が入ったとき。 データが欠けているとき。 検索結果がゼロ件のとき。 同じ項目が重複したとき。 こうした例外的な場面で崩れないことを、デザインの完成度の一部として扱いました。
派手さはありません。 けれど、BtoB のサイトでは、この地味な堅牢さが信頼にそのまま直結します。 表示が速く、落ちず、どんな入力でも崩れない。技術者は、そういう静かな安定感をちゃんと見ています。
成果 — 数字と、一気通貫の一件
さて、成果です。
公開からおよそ 2 ヶ月の時点で、最初の問い合わせが 5 件、そのうち 3 件が受注になりました。 成約率にして、約 60% です。 母数は小さいので数字を過大に語るつもりはありませんが、公開直後の若いサイトから、この確度で受注に繋がったのは十分に手応えのある結果でした。
ある時期を境に、検索の表示回数（インプレッション）の下限が一段跳ね上がる転換点もありました。 おおよそ 6.5 倍です。 ここを境に、サイトが「たまに見つかる」状態から「継続的に見つかる」状態へ変わった感覚があります。 主要な入り口になったのは、狙い通り「割れ」と「樹脂」のクラスターでした。 設計した通りにトラフィックが動いてくれた、という意味で、この転換は特に嬉しいものでした。
そして、いちばん象徴的だったのが、この一件です。
検索で見つけてもらい、新規の問い合わせが入り、初回商談に進み、受注が決まり、新規の取引口座が開く。 この流れが、途中で人的なコネや既存の関係に頼ることなく、最初から最後まで一本で繋がりました。 相手は、誰もが名前を知る大手電機メーカーグループの、日本の研究開発法人です。 半導体パッケージや次世代ディスプレイ、電池材料などの研究開発を手がける組織でした。
自分が一から作ったサイトが、検索という入り口だけで、この規模の新規口座を開くところまで運んでくれた。 これは、サイトが「作品」ではなく「営業する仕組み」として機能したことの、いちばん分かりやすい証拠でした。
GEO についても、実地の裏づけが取れました。 問い合わせのうち少なくとも 1 件は、ChatGPT 経由でたどり着いたことが確認できています。 生成 AI が自社のページを情報源として拾い、そこから人が動いた。 仕込んだ構造化が、机上の空論ではなかったと確認できた瞬間でした。
その後も受注は続いています。 今は、サイト掲載用に本物の断面サンプルの撮影を準備しているところです。 コンテンツを「本物の写真」で強くしていく、地道な作業の途中にいます。
半導体パッケージや次世代ディスプレイ、電池といった領域は、今後コンテンツを厚くしていく戦略的な拡張先として位置づけています。 一件の受注は、ゴールではありません。 次のクラスターを育てるための、入り口でもあります。
1.5 ヶ月という期間について
「未経験から 1.5 ヶ月」と書くと、才能の話に聞こえるかもしれません。 そうではありません。
本業のかたわら、少しずつ積み上げた 1.5 ヶ月です。 一日で大きく進んだ日もあれば、エラーひとつに半日溶けた日もありました。 それでも前に進めたのは、毎日「今日はここまで動いた」という小さな確定を残せたからです。 大きな完成を一度に目指すと、遠すぎて足がすくみます。 今日ひとつだけ前に進む。その積み重ねが、気づけばサイト一つ分になっていました。
振り返り — 再現できる型として
最後に、この経験を「一回きりの幸運」で終わらせないために、再現できる型として抽出しておきます。
第一に、コードより先に、誰に何を届けるかを決めること。 技術スタックの選定も、デザインの判断も、すべて「症状で来た人を迷わせず行動まで運ぶ」という一点から逆算しました。 軸が先にあると、AI に任せる部分の指示もぶれません。
第二に、箱を固めてから、中身を作ること。 速くて壊れない土台を先に用意し、URL の正規化まで詰めておく。 ここを飛ばすと、あとでコンテンツを足すほど不具合が積み上がります（Bing の登録問題が、私の授業料でした）。
第三に、浅く広くではなく、症状ごとに深く書くこと。 検索ボリュームより、当事者への刺さり方です。 少ない訪問でも高い確率で問い合わせに変わる濃さを、限られたテーマに集中して作ります。
第四に、検索と生成 AI の両方に読ませること。 王道の SEO に加えて、構造化データで GEO を仕込む。 手応えは薄くても、ChatGPT 経由の問い合わせという形で返ってきました。
第五に、作って終わりにせず、数字で回すこと。 流入と成約を追い、仮説を立てて直す輪を止めない。 「作品」ではなく「営業する仕組み」として育てる意識が、成果と自己満足を分けます。
第六に、引き継げる形で作ること。 ルールを一箇所に集約し、自分がいなくても回る状態に寄せる。 属人化させないことが、仕組みの価値を長持ちさせます。
これから始める人へ
もし同じように、専門外の領域で足踏みしている人がいたら、伝えたいことがあります。
完璧な計画より、まず今日動く小さな一歩を。 分からない言葉は、その場でやさしく言い換えてもらう。 エラーは敵ではなく、次のヒントとして、そのまま相談する。 そして、最後は自分の目で確かめる。
大事なのは、コードの知識ではありません。 「誰に、何を届けたいか」を、自分の言葉で持っていること。 それさえあれば、実装の壁は、AI が一緒に越えてくれます。
おわりに
コードが書けるようになったから受注できたのではありません。 集客の文法を持った人間が、コードの壁を AI で越えられるようになった、というのが正確な総括です。
専門外だからと諦めていた領域が、いま急速に地続きになりつつあります。 この記事が、同じように「作れないから」と足踏みしている誰かの、最初の一歩の後押しになればうれしいです。
本記事は制作の記録をもとに再構成したものです。会社名・URL・取引先名などの固有情報は、公開範囲に配慮して一般化しています。