このサイト自体が、AIネイティブ開発の成果物です。

背景と課題：受託開発会社が、まず自分たちで証明する

Harry& は、AIを前提とした受託開発（AIネイティブ受託開発）を専門とする会社です。

お客様に「AIを使えば、これだけ速く・安く・しっかり作れます」とお伝えする以上、まずそれを自分たちの本番サイトで実証する必要がありました。

一般的に、コーポレートサイトや事業紹介のWebサイトは制作会社へ外注し、数週間から数ヶ月の期間と相応の費用がかかります。

さらに公開後の更新や問い合わせ管理の仕組みづくりに、別途コストが積み上がっていくのが通例です。

このサイトは、その「当たり前」をAIネイティブな開発体制で作り直したらどうなるかを示す、検証案件として位置づけました。

私たちが解こうとした課題は3つでした。

第一に、営業活動の受け皿となるサイトそのものが存在せず、せっかくの問い合わせや紹介を取りこぼしていたこと。

第二に、無料相談・資料請求といった「次の一歩」へ進んでもらう動線と、その反応を計測する仕組みがなかったこと。

第三に、非エンジニア＋AIという体制で、本当に本番品質のサイトを短期間・低コストで作れるのかが未検証だったことです。

これを放置すれば、どのチャネルからどれだけ反応があったのかが分からないまま、勘で営業を続けることになります。

受け皿が弱いと、流入が増えても商談につながらず、広告や記事への投資が回収できません。

「作れるかどうか分からない」状態のままでは、お客様にも自信を持って提案できません。

なぜ自社で・解決の中身：丸投げにせず、非エンジニア＋AIで作りきる

外注すれば早く形にはなりますが、それでは「AIネイティブで作れる」という肝心の証明になりません。

一方で、エンジニアを雇って内製する体制も今はありません。

そこで第三の道として「非エンジニアの代表＋AI＋自社で組み上げた開発ハーネス（仕組み）」で作りきる、という選択をしました。

ここで大切にしたのは、AIに丸投げしないことです。

何を作るか・どんなコピーで・どんな体験にするかという意思決定は人間（代表）が担います。

調査・設計・実装・検証の実作業はAIが担う——この責務の分担を、最初から構造として決めました。

人が決める箇所を「人間ゲート」として明示し、判断が必要なところで必ず立ち止まる進め方です。

さらに、作って終わりにしないために、設計→実装→評価を繰り返す内製の反復プロセス（Evaluator-Optimizer ループ）を回しました。

一度作った成果物を別の視点で評価し、必要な箇所だけ直す——この往復が、勢いまかせではない品質を支えています。

まず、受託事業を伝えるランディングページ（/jutaku）を、課題提起から実績・選ばれる理由・安心材料・サービス全体像・問い合わせまでの一連のセクションとして構築しました。

会社の顔となるトップページ（/）と会社概要（/about）も実装しました。

トップでは three.js を使った3Dのブランド表現（記号「&」のモチーフ）とスクロール連動の演出を、サイト全体で常に背景に表示する設計にしています。

見た目の世界観を統一しつつ、文字の可読性も両立させました。

問い合わせ・資料請求フォームは、送信されたら自社のデータベース（Supabase）に保存します。

社内通知と申込者への自動返信メール（Resend）を送り、同時に計測イベントを発火させる——この一連の流れを自前で組みました。

予約は外部ツールの埋め込みで対応しています。

計測面では、Google Analytics 4 と Microsoft Clarity を入れました。

問い合わせ・資料ダウンロード・予約完了の主要な反応を、流入経路を軸に追える状態にしています。

個人情報は計測イベントには載せず、自社データベースにのみ保存する設計で、プライバシーにも配慮しました。

技術スタックは Next.js（App Router）／TypeScript／Tailwind を中核にしています。

コンテンツは外部CMSを使わずリポジトリ内のMarkdownで管理（Velite）し、ホスティングは Vercel です。

記事は所定の場所にMarkdownを置くだけで公開でき、外部サービスへの登録作業が要りません。

成果：フルAI体制で、本番品質のサイトを内製できた

最大の成果は、非エンジニアの代表＋AI＋ハーネスという体制で、企画から設計・実装・検証まで本番品質のサイトを一通り作りきれたことです。これにより、お客様への提案が「できます」という言葉ではなく、「現にこのサイトを作りました」という実物に裏づけられたものになりました。

構成をシンプルにできたことも成果です。外部CMS・高額なSaaS型のCRM・専用サーバーを採用せず、Markdown・Supabase・Vercel・Resend の組み合わせで、本番品質を保ちながら運用の複雑さとコストを抑えています。

加えて、問い合わせ・資料請求といったお客様の反応を、流入経路ごとに計測できるデータ基盤が整いました。

今後どのチャネルに力を入れるべきかを、感覚ではなく数字で判断できる土台ができています。

——ここから先は、上の数値の前提を明示しておきます。

このページに記載した工期・コスト・構成は、すべて自社プロジェクトの実データに基づくものです。

「約3日」とは、要件と設計を固めたあとのコア部分（主要ページと機能）の構築スプリントを指します。

実際には、要件の確定や、設計→実装→評価を繰り返す反復品質チェック、公開準備までを含めると、これに前後の作業期間が加わります。

それでも、従来の外注と比べて圧倒的に短い時間で本番品質に到達できた、というのが要点です。

公開後の訪問者数・流入・問い合わせ件数といった運用実績は、計測が始まってから確定する性質のものです。

現時点では確定値としては掲載していません。

また、このサイトは初回の事例です。

同じ体制を他のお客様の案件にどこまで再現できるかは、案件ごとに条件が異なるため、一律のお約束はいたしません。

だからこそ、最初に有料の診断・設計で見極めてから本開発に進む進め方をおすすめしています。

私たちがここで迷ったこと：外注するか、自分たちで証明するか

このサイトを作るにあたって、私たちの前には複数の選択肢がありました。

制作会社に外注すれば形は早く整います。エンジニアを採用して内製する体制も検討しました。

選択の岐路は「何のためのサイトか」という問いに戻ったときに決まりました。

私たちが伝えたいのは「AIネイティブな体制で、速く・安く・本番品質のものを作れる」ということです。

それを外注で作ったサイトで説明しようとすれば、言葉と実物が食い違います。

第三の道を選んだのは、それが唯一「実物で証明できる」方法だったからです。

作る過程で起きた問題とその解決は、そのままお客様の案件への知見になりました。

内製ではなく外に出す価値：意思決定する人と実装する人を分けると、品質の詰め方が変わる

このサイトは、意思決定を代表者（非エンジニア）が担い、実装・検証・品質チェックの実作業をAIが担う分業で作っています。

自分でコードを書きながら何を作るかを決めようとすると、「なぜそう作ったか」の判断が「どう実装するか」の選択と混ざります。

すると本来の目的から外れていくことがあります。

意思決定者と実装担当を分けると、「これは本当に必要か」という問いを実装の途中でも立て直しやすくなります。

私たちがお客様の案件で伴走するときも、この構造を前提にしています。

作る側が設計の「なぜ」まで説明できる状態を保つことが、作って終わりにしない品質のベースになります。

どんな会社に向く事例か：AIで速く・安く作れることを、実物で確認してから判断したい方

この事例が参考になりやすいのは、AIを使ったWeb制作・開発を検討しているが、どの程度のものが作れるかイメージが掴めていない場合です。

スピードや品質を「言葉」ではなく「実物」で見てから発注を判断したい——そうした方に向きます。

このサイトそのものが、その判断材料になるよう設計しています。

逆に、すでにエンジニアチームが社内にいて実装の体制が整っている企業には、この事例の主な示唆は直接は当てはまりにくいかもしれません。

また、このサイトは最初の一事例です。

同じ体制を他の案件にそのまま再現できるかは案件ごとに条件が異なるため、一律にはお約束できません。

まず診断で見極めてから進める、という流れはここでも同じです。