Claude Code でWEBサイトのコーディングはどう変わる？【WEBサイト実装編】

Claude Code を導入したきっかけは何でしたか？

少し前の社内では、もともとエンジニアは Cursor を使っていました。AI 支援のある開発環境は早い段階から標準化していて、生産性も十分に上がっていた。開発責任者としては、これ以上の効率化を急いで追う必要はないかな、と一度は落ち着いていたんです。

ただ、自分自身も開発に携わることが多いため、自分もエンジニアも常に最新のツールには目を通していました。その中で Claude Code を知ったとき、「これはもう一段階、開発のレイヤーが変わる」と直感したんですね。

もちろん、「Cursor でも Agent モードがあるし、ルール機能もあるし、同じようなことはできるのでは？」とよく聞かれます。正直、機能の並びだけを見ると重なる部分は多いです。ただ、実際に使い込むと、向いている"使い方の軸"がかなり違うと感じています。

そもそも、弊社のチームが最初に Cursor を選んだのには理由があります。当時はまだ AI の精度に波があって、コードの細部まで人間が目を通しながら進めないと危なかった時期だった。だからこそ、エディタに統合されていて、人間が常に隣で監督しながら AI と並走できる Cursor は、あの時点での最適解だったんです。

そこから1〜2年で、AI モデルそのものの能力が大きく上がりました。指示の解釈精度、コードの一貫性、プロジェクト全体を踏まえた提案力——どれも実務で任せられる場面が増えてきた。そうなると、"常に人が横で監督する" という前提自体を見直せる。ある程度まとまった単位で任せて、結果を人間が確認する、というワークフローが現実的になってきたわけです。

Claude Code自体は以前から存在していましたが、このタイミングでその価値が一気に高まったと感じています。人間がエディタを開いてAIと一緒に書くというより、AIにある程度まとまった実装を任せる開発スタイルとの相性が非常によかったからです。一方で、Cursorはエディタに統合された「対話しながら書くための環境」として依然として優れており、チームでは用途に応じて引き続き活用しています。

Claude Code のほうは、CLI を起点にプロジェクト全体を扱えるぶん、まとまった実装タスクを委ねるシーンに強い。大きめのタスクを投げて進める、シェルや自動化パイプラインに組み込む、複数のサブエージェントを並列で走らせる、といった使い方が自然にはまる。僕の感覚では、Cursor は "AI と並走するモード"、Claude Code は "AI に委譲するモード" の道具、という住み分けに近いです。

だから、どちらかを選ぶというより、用途で使い分けるほうが合理的だと判断しました。インタラクティブに書きたいときは Cursor、まとまった単位で任せたいときは Claude Code。AI が賢くなった今だからこそ、この二段構えが機能します。両方を入れることで、チームとしての選択肢が明確に増えました。

試しに自分で触ってみると、想像以上に実務へ入り込める感覚がありました。"実装の初速を上げてくれるメンバーが増えたような感覚" です。もちろん人間のレビューは必要ですが、同じ人数でも着手できるタスクの量が明らかに増える。開発責任者として、まず現場で試す価値は高いと判断しました。

最初に社内でのテストケースに選んだのは、Venture Quest のコンポーネント実装です。プロジェクトのデザイントークンやルールを明文化した上で、エンジニアに「これを Claude Code に読ませて、記事カードの初期実装を作ってみてほしい」と依頼した。上がってきたアウトプットを見て、これはWEBサイトのコーディング体制を見直すきっかけになると感じました。

日常の開発で、具体的にどう使っていますか？

チームでは大きく4つのパターンで使っています。これは僕自身が現場を見ながら「この工程は AI の得意領域だな」と切り分けて、運用ルールとして落とし込んだものです。

1. 新規ページ・コンポーネントの実装

一番頻度が高いのがこれです。Venture Quest はデザインルールをきっちり明文化していて、ルールは Claude Code が読み取れるようドキュメントに集約してあります。その上で、エンジニアには「新しいページを作るときは、まず Claude Code に初期実装計画を書かせる」という運用を基本にしてもらっています。

たとえば「スライダーを作る。仕様はこう」と伝えれば、コンポーネント、データ取得、スタイル、アクセシビリティ対応まで含めて、かなり完成度の高い初期実装が上がってくる。これを土台にエンジニアが仕上げる、という流れです。

2. リファクタリングとコード品質の改善

既存コードの改善も積極的に任せています。「このコードのパフォーマンス効率を下げている記述をみつけて改善してほしい」「このコンポーネントを型安全にしてほしい」といった指示で、影響範囲の説明付きで修正案が返ってくる。

特に経営的に助かっているのは、コーディング規約との整合性チェックを AI に先に実施してもらっていることです。人間のレビュー工数が目に見えて減りました。人間はルールを忘れるけれど、AI は毎回チェックしてくれる。これは品質管理の観点で非常に大きい。

3. デバッグ

ビルドエラーやランタイムエラーが出たら、エラーメッセージを貼って原因を聞くだけで、解決の糸口がかなり早く見つかる。プロジェクトのファイル構成や依存関係を踏まえて、「ここが原因ではないか」と返してくれる。

以前は調査だけで数十分かかっていた問題が、いまは数分で片付く。この差は、時間単価で換算すると相当なものになります。

4. SEO / AIO / アクセシビリティの実装

Venture Quest は SEO と AIO（AI Optimization）に力を入れています。構造化データ、メタ情報、AI クローラー向けの設定など、地味だけど重要な要素が山ほどある。こうしたチェックも、ルールをドキュメント化した上で Claude Code に確認させ、効率化を図っています。

昔は人間がひとつずつ潰していた作業ですが、いまはエンジニアが「このページのチェックをして」と一声かけるだけで、抜け漏れを洗い出してくれる。開発責任者として SEO・AIO は最重要の投資領域の1つなので、ここが仕組みで担保できるようになったのはかなり大きいです。

CLAUDE.md の設計がカギだと聞きました。どんな工夫をしていますか？

これは本当に重要です。Claude Code の出力品質は、ルール設計にかなり左右されると考えています。だからこそ、CLAUDE.md のような「AI への指示書」の整備は、僕自身が開発責任者として深く関与するようにしています。ここを現場任せにするとブレるので、方針と禁止事項は開発責任者としてレビューする、というスタンスです。

Venture Quest では、プロジェクトルートの CLAUDE.md をエントリーポイントに、役割ごとのルールファイルへ参照を飛ばす構造にしています。具体的なファイル構成や切り分け方はプロジェクト固有のノウハウなので詳細は伏せますが、「概要」「規約」「実装ガイド」のレイヤーを意識して分けている、というのが大枠のイメージです。

設計のポイントは3つあります。

まず、ルールは具体的に書く。「アクセシビリティに配慮して」ではなく、数値やコード例で書く。曖昧な指示は曖昧な出力を生みます。これは経営でいう KPI 設計と同じで、測定できる形に落とし込まないと機能しない。

次に、「やってはいけないこと」を明示する。禁止事項を書いておくと、Claude Code がそれを踏まえたコードを出しやすくなります。ただし、CLAUDE.md はあくまで指示であって強制設定ではないので、本当に止めたい操作は権限設定やフックなど別の仕組みでもガードする。人を雇うときの就業規則と入退室管理を分けるのに近い発想ですね。

最後に、ガバナンスルールを入れる。「新しい依存を勝手に追加しない」「本番デプロイを自動実行しない」「main ブランチに直接コミットしない」。AI に自律性を与えるほど、ガードレールが重要になる。これは開発責任者として一番気を遣っているところです。

導入前後で、開発のスピードや品質はどう変わりましたか？

開発責任者として一番関心のある指標ですね。社内の体感として、新規ページやコンポーネントの初期実装にかかる時間はかなり短くなりました。以前は1ページの土台づくりに丸2日近くかかることもありましたが、条件が揃っているページなら半日〜1日でレビュー可能な状態まで持っていけるケースが出ています。もちろん、これはページの複雑さや要件の固まり具合によって変わります。

ただ、誤解してほしくないのは「AI が全部やってくれるから速い」わけではないということ。正確には、「AI が初期実装を高速に出してくれるので、エンジニアがレビューと品質調整に集中できるから速い」んです。人間の仕事が "ゼロから書く" から "判断して仕上げる" に寄ってきた、という表現のほうが近い。

品質面では、むしろ向上しました。理由は2つ。

1つは、ルールを文書化して Claude Code に読ませることで、規約違反に気づきやすくなったこと。これは開発マネジメントの視点で大きい。品質のバラつきは、人数が増えるほど管理コストになりますが、AI を標準化の補助線にすることで、その問題を小さくできる。

もう1つは、実装の一貫性。同じデザイン、同じ設計パターンを全ページで揃えやすくなった。複数人で開発していると「この人のコードだけ微妙に違う」ということが起きがちですが、Claude Code をベースラインにすることで、属人性を減らせました。

コスト面でも、これは開発体制への投資判断として筋が良かった。エンジニアを増やすだけではなく、いまいるメンバーがより多くの実装とレビューを回せる状態を作る——その方向に賭けた、ということです。

逆に、うまくいかなかったケースや失敗談はありますか？

もちろんあります。

一番ヒヤッとしたのは、AI の出力を深く確認しないまま、危うく本番に反映しかけたケース。 レビュー体制が整っていなければ、そのまま公開してしまうところでした。

初期のある時期、チームが AI のスピードに甘えて、確認が浅いままマージに進みかけたことがありました。レビューで一度立ち止まって見直したら、デザインルールから外れたハードコードが混ざっていたり、対応漏れがあったり。AI の出力は「だいたい合っている」ので油断するんですが、"だいたい" と "公開してよい品質" の間には差がある。そしてその差は、そのまま出ていればサイトの印象に直結していたはずです。

その事例を受けて、AI の出力はマージ前に人間が総合的に見直す運用を、チーム全体のルールとして徹底しました。変更箇所だけでなく、「本当に意図どおりの設計か」「既存のルールから外れていないか」「周辺への影響は出ていないか」まで、少し引いた視点で確認する。AI が生成したコードは、部分的には正しくても、プロジェクト全体の文脈から見ると微妙にズレていることがあるからです。

開発責任者として学んだのは、スピードが上がるほど、品質を担保する仕組みも一緒に強化しないと事故が起きるということ。アクセルとブレーキは同じだけ磨く、という発想です。

もう1つは、コンテキストの限界。

プロジェクトが大きくなると、AI が参照すべきファイルが増えて、情報が抜け落ちることがある。存在しない設定値を勝手に作ってしまう、といった事故ですね。これは AI の宿命的な弱点なので、人間側で「重要な情報はドキュメントに集約する」という運用で対処するしかない。この整備も、開発責任者として継続的に投資しています。

「AI に任せること」と「人間が判断すること」の線引きはどうしていますか？

チーム全体でかなり明確に分けています。これは開発責任者として最初に決めた線引きで、運用ルールとして共有しています。

AI に任せること（=エンジニアが AI に投げる領域）:

• 定型的なコード生成（コンポーネントの初期実装、データ取得クエリ、構造化データ）
• ルールベースのチェック（SEO・AIO 要件、アクセシビリティ、コーディング規約）
• リファクタリングの実行（方針は人間が決める）
• エラーの原因特定と修正案の提示

人間が判断すること（=エンジニア・経営者が担う領域）:

• 設計判断（このコンポーネントを分割すべきか、この Props 設計で良いか）
• UX 判断（このレイアウトはユーザーにとって直感的か）
• ブランド判断（このトーンは Venture Quest らしいか）——ここは代表や経営陣が最終判断する領域だと考えています
• 優先順位の決定（何を先にやるか）——これは経営判断そのもの
• 文章表現のリライト・調整（AI が書いた文章は、どうしても "AI っぽさ" が出ることがある。記事のコピー、UI 上の説明文、メタディスクリプションなど、読み手の印象に直結する部分は、人間の感覚で自然な表現に書き直す必要がある。ここを怠るとサービス全体の質感が一段下がるので、チームにも「AI 出力の文章は必ず人間が整える」と徹底してもらっています）

要するに、「What（何を作るか）」と「Why（なぜ作るか）」は人間——特に経営者——が決めて、「How（どう実装するか）」を AI とエンジニアに委ねるという分担です。

ただ、Claude Code はただの実行役ではなくて、設計上のリスクや改善提案もくれる。その意味では、判断の壁打ち相手としても機能していて、エンジニアにとっても僕にとっても、思考を整理する際の助けになっています。

スタートアップや少人数チームに Claude Code を勧めるとしたら、最初の一歩は？

経営者や開発責任者仲間からよく聞かれる質問なので、5つに整理してお答えしています。

1つ目。ルールを言語化することから始めてください。 ツールを入れる前に、自社のプロジェクトの前提・規約・禁止事項を言語化する——これだけで開発の質は確実に上がります。CLAUDE.md のような "AI への指示書" を書くプロセスは、実は開発責任者や経営者が自社の仕組みを棚卸しする作業でもあります。「うちのプロダクトはどうあるべきか」「何を禁止するか」を文章化してみると、自分でも意外と決めきれていない領域が見えてきて、それ自体が経営上の気づきになる。AI のためだけでなく、人を新しく採用するときの受け入れ資料にもなるので、一石二鳥です。

2つ目。小さいタスクから導入する。 いきなりプロダクト全体の設計を任せるのではなく、限定的なスコープから始める。最初は「このコンポーネントだけ」「この改修だけ」と区切って、エンジニアと一緒にアウトプットを確認する。小さく試して信頼関係を積み上げていく、という発想です。経営でいうところの試験運用と同じで、いきなり全振りしないのが鉄則。

3つ目。AI の出力は人間の目で確認する運用を徹底する。 これが一番大事です。AI は優秀なジュニアエンジニアだと思ってください。速くて勤勉で、言われたことはかなりの範囲で形にできる。でも文脈の理解やビジネス判断は人間がリードする必要があるし、レビューを怠ると品質は簡単に崩れます。特に、文章やコピーに関しては "AI っぽさ" が残ったまま世に出てしまうとサービス全体の印象が一段下がってしまう。「コードも文章も、最後の一筆は人間が入れる」——このルールはチーム全体で共有しています。

4つ目。ガードレールを先に作る。 AI に自律的に動いてもらうほど、「やってはいけないこと」を明示する重要性が増します。本番環境への自動デプロイは禁止、main ブランチへの直接コミットは禁止、依存関係の勝手な追加は禁止——こうした禁止事項を先に設計しておく。開発責任者の判断として、スピードを出す前にブレーキを整える、という発想です。これをやらないと、事故が起きたときに取り返しがつかない。

5つ目。AI を「もう1人のチームメンバー」のように扱い、その立ち上げには経験者を入れる。 Claude Code は単なるツールとして雑に使うより、前提を共有して、相談しながら進めて、アウトプットにフィードバックするほうが機能します。ただ、この運用を最初から自社だけで設計するのは意外と難しい。だから導入初期は、AI 開発に強い専門家にチームへ入ってもらい、ルール整備、タスク設計、レビュー運用、ガードレール作りを一緒に進めるのがいいです。人を採用・育成するときと同じように、最初のオンボーディング設計がその後の成果を大きく左右します。

最後に、開発責任者として伝えたいことを1つ。少人数のスタートアップほど、Claude Code のような AI エージェントを導入する経営的なリターンは大きいです。うちもそうですが、1人のエンジニアが設計・実装・SEO・AIO・アクセシビリティ・デプロイまで幅広く見ないといけない局面が多い。そこに "初期実装とチェックを手伝う力" が増える。これは従来の採用・組織論だけでは到達しにくかった生産性の向上です。

もし導入を迷っているなら、まず1週間、自分のチームで本気で試してみてほしい。僕は開発責任者として、これを導入した判断はかなり ROI が高かったと感じています。