まだAIを使い始めたばかりの頃、AIに「いい感じにトップページ作って」と投げました。
返ってきたのは、グラデーション過多のランディングページ。
クライアントのコーポレートサイトなのにこれでは。
丁寧にプロンプトを書き直して、参考URLも添えて、もう一度。
今度はBootstrapテンプレートそのままの出力。
3回目でやめました。
「AI、仕事では使えないな」。最初はそんな感じでした。
それから、丸っとお願いするのでなく、部分的に活用したり、コンテキストを渡してだったりと色々工夫していきました。
その間にいろんなモデルのアップデートも行われ、AI自体の進化もありました。
今では、Claude Codeで1日のコーディング時間を4割近く短縮しています。
物によっては9割近いものもあるかもしれません。
当時から大きく変わったのは、プロンプトの書き方ではありません。
タスクの渡し方です。
この記事では、Claude CodeでWeb制作のクライアントワークを回した記録を、成功も失敗も数字つきで具体的に公開します。
なぜこれを試したのか
きっかけは、あるデータでした。
ハーバード大学とBCGの共同研究で、AIを使った知識労働者は作業速度が25%上がり、品質が40%以上向上したという結果が出ています。
ただし条件があって、「AIの能力境界の内側のタスク」に限った話です。
境界の外側では逆効果になったと。
一方で、経験豊富なオープンソース開発者246タスクを対象にしたランダム化比較試験（MERC AI, 2025年）では、AI使用群の完了時間がむしろ19%増加しています。
開発者自身は「24%速くなるはず」と予測していたのに。
つまり、同じAIを使っても、結果が真逆になります。
この差はどこから来るのか。
Web制作の仕事を抱えていた自分にとって、これは切実な問題でした。
ChatGPTのプロンプト集も試した。
Claude Codeも導入済み。
でも「仕事が回る」実感はゼロ。
すごい人のXポストを見ては「自分のやり方が悪いのか」と思う日々。
だから試してみることにしました。
1週間、Claude Codeだけで実際のクライアントワークを回す。
何がうまくいって、何がダメだったか、全部記録する。
なぜ「プロンプト集」では仕事が回らないのか
実験の前に、1つ整理しておきます。
プロンプト集は「良い質問の型」です。
それ自体は有用。
でも、仕事の現場ではプロンプトの前にやることがあります。
たとえば「コーポレートサイトのトップページを作って」という依頼。
これをそのままAIに投げると何が起きるか。
AIは「トップページ」の平均値を返します。
ヒーローセクション、特徴3カラム、CTAボタン。テンプレート的には正しい。
でもクライアントが求めているのは「既存の採用ページとトーンが揃っていて、代表メッセージが上部にあるトップページ」かもしれません。
この情報はプロンプト集のどこにも書いていません。
以前、バイブコーディングで挫折した3ヶ月の開発体験でも同じ構造に気づきました。
仕様を分解しないままAIに渡すと、コードの品質がどんどん劣化していきます。
AI業界でも、2025年後半から「プロンプトエンジニアリング」の限界が指摘され始めています。
Andrej Karpathyは「コンテキストエンジニアリング」という言葉を提唱しました。
プロンプトの精度を上げることより、AIに渡すコンテキスト全体の設計が重要だと。
Amazon Scienceの研究では、タスクを分解して小規模なモデルに渡すだけで、大規模モデルと同等の品質を維持しながらコスト70-90%削減を達成しています。
問題は、プロンプトの書き方じゃなかった。AIに何を、どう分けて渡すか。
その設計です。
Claude Codeで1週間Web制作を回した記録
ここからが本題です。
クライアントワークでClaude Codeを使った5日間の記録。
Day 1 — いきなり全部渡して撃沈
渡したタスク: 「コーポレートサイトのトップページをHTML/CSSで作って。参考URLはこれ。」
結果: 2時間かけてプロンプトを調整し続けたけれど、使える出力はゼロ。結局、自分でゼロから書きました。
所要時間: プロンプト調整2時間 + 自力コーディング3時間 = 5時間（通常は3.5時間）
正直、初日で心が折れかけました。
何が問題だったか。
振り返ると、渡したタスクが大きすぎた。
「トップページを作って」は人間のディレクターに渡すなら通じます。
文脈を共有しているから。でもAIには文脈がない。
Day 2 — タスクを分解して渡したら変わった
前日の失敗を踏まえて、同じトップページの作業をこう分解しました。
- 既存の採用ページのHTML構造を分析して、使っているクラス名とレイアウトパターンを抽出して
- 競合3社のトップページの構成要素をリストアップして
- セクション構成を5つ提案して（代表メッセージ、事業内容、実績、採用導線、お問い合わせ）
- セクション1「代表メッセージ」のHTML/CSSを、既存サイトのスタイルに合わせて書いて
- セクション2「事業内容」を同じトーンで書いて
ステップ1から順にClaude Codeに渡しました。
結果: ステップ1-3は期待以上。
既存サイトのコード分析は人間より速かった。
ステップ4-5もベースとして使えるレベル。
微調整は必要だったけれど、ゼロから書くより明らかに速い。
所要時間: タスク分解30分 + AI作業・微調整2時間 = 2.5時間（前日は5時間）
ぶっちゃけ、最初からこれをやっていればよかった。
プロンプトの精度を上げることに2時間使うより、タスクの分解に30分使うほうが結果は劇的に変わりました。
Day 3-5 — 分解の粒度を調整していく
Day 3からは、タスクの分解精度を上げることに集中しました。
Day 3: 下層ページ5枚のコーディング。
各ページを「ヘッダー」「メインコンテンツ」「フッター」の3パーツに分解して渡しました。
- 成功: レイアウトの骨格は全ページAI出力をそのまま採用
- 失敗: レスポンシブの微調整はAIの出力が不安定で、手動修正が必要だった
- 所要時間: 4.5時間（通常8時間、約44%短縮）
Day 4: JavaScriptのインタラクション実装（ハンバーガーメニュー、スムーススクロール、アコーディオン）。
- 成功: 定型的なJS実装はほぼ完璧。アコーディオンのアクセシビリティ対応まで含めてくれた
- 失敗: スクロール連動アニメーションは要件が曖昧で、3回やり直した
- 所要時間: 2時間（通常3時間、約33%短縮）
Day 5: WordPress化。静的HTMLをテーマファイルに変換する作業。
- 成功: header.php、footer.php、front-page.phpの分割はほぼ一発で決まった
- 失敗: カスタムフィールド（ACF）との連携部分は、プロジェクト固有の設計があるため人力で対応
- 所要時間: 3時間（通常5時間、約40%短縮）
1週間の数字まとめ
| 項目 | 通常 | AI活用 | 差分 |
|---|---|---|---|
| Day 1（分解なし） | 3.5h | 5h | +43%（悪化） |
| Day 2（分解あり） | 3.5h | 2.5h | -29% |
| Day 3 下層5ページ | 8h | 4.5h | -44% |
| Day 4 JS実装 | 3h | 2h | -33% |
| Day 5 WordPress化 | 5h | 3h | -40% |
| 合計 | 23h | 17h | -26% |
Day 1を除けば、平均で37%の時間短縮。Day 1を含めても26%減。
ただし、この数字には「タスク分解にかけた時間」を含んでいます。分解作業そのものは、1タスクあたり15-30分。従来なかったコストです。でも、そのコストを払って余りあるリターンがありました。
見えてきた境界線 — AIに渡せるタスクと渡せないタスク
1週間やってみて、境界線が少しずつ見えてきました。
渡せたタスク
- 既存コードの分析と構造化: HTMLの解析、クラス名の抽出、レイアウトパターンの言語化
- 定型的なコーディング: セマンティックHTML、CSS Grid/Flexboxのレイアウト、基本的なJS
- 繰り返しの多い作業: 下層ページのテンプレート展開、WordPress化の機械的な部分
- リサーチと要約: 競合サイトの構成分析、技術仕様の確認
渡せなかったタスク
- クライアントの曖昧な意図の解釈: 「もうちょっとスタイリッシュに」を具体的なCSSに変換する作業
- デザインの文脈判断: 既存ブランドとの一貫性を保つ余白やカラーの微調整
- プロジェクト全体の優先順位: 「この部分は後回しにして、まずここを仕上げる」という判断
- レスポンシブの細かい調整: ブレイクポイントごとの要素の並び替えや非表示切り替え
この線引き、全部自動化しようとして疲れた話と「半自動化」という選択で書いたこととつながっています。
全部をAIに渡すのではなく、「ここはAI、ここは自分」と線を引く。
その線引きの精度が、AI活用の成果を決めます。
ハーバード×BCGの研究では「Jagged Frontier（ギザギザの最前線）」という概念が提唱されています。
AIが得意な領域と不得意な領域の境界は、直線ではなくギザギザだと。
タスクごとに確認するしかありません。
1週間の実験で実感したのは、まさにこれでした。
「コーディング」という大きな括りでは判断できない。
「既存サイトのスタイルに合わせたセクションのHTML」は渡せるけど、「レスポンシブの余白調整」は渡せない。
粒度を細かくして初めて、境界線が見えます。
次に試すこと — タスク分解の再現フレーム
この1週間の実験から、自分なりの「タスク分解フレーム」ができました。
ステップ1: 仕事を5-10の工程に分解する
「トップページを作る」ではなく、「既存サイトの分析 → 構成案 → セクション別コーディング → レスポンシブ調整 → CMS連携」のように。
ステップ2: 各工程に「入力」と「出力」を定義する
- 入力: このタスクには何の情報が必要か（参考URL、既存コード、デザインカンプ）
- 出力: 何が出てくればOKか（HTML/CSSファイル、構成案テキスト、分析レポート）
ステップ3: AIに渡すか自分でやるか判断する
判断基準は3つです。
- 入出力が明確か: 入力と出力の仕様が言語化できるなら、AIに渡せる可能性が高い
- 文脈が必要か: クライアント固有の暗黙知や過去の経緯が必要なら、自分でやる
- 品質基準が定量化できるか: 「正しいHTMLか」は判断しやすい。「スタイリッシュか」は難しい
このフレームがどこまで他の仕事に使えるかは、まだわかりません。
Web制作という領域での1週間の結果です。
ただ、以前Claude Codeで失敗した5つのパターンと学んだ使い方を書いたとき、「期待の置き方」が問題だと気づきました。
今回の実験で、その「期待の置き方」が具体的なフレームになった感覚があります。
次の仮説は「分解の粒度をさらに細かくすれば、Day 3のレスポンシブ調整もAIに渡せるようになるのでは」です。
入力をもっと明確にすれば、境界線はもう少し内側に動くかもしれません。
まとめ — プロンプトより分解。AIは「聞き方」より「渡し方」
1週間の実験で見えたことを整理します。
- プロンプトの精度を上げることに時間を使うより、タスクを分解する30分のほうが効果が高かった
- AIに「いい感じに」と渡すと失敗する。入力と出力を定義して渡すと成功する
- 渡せるタスクと渡せないタスクの境界線は、やってみないとわからない。だから記録する
- Day 1の大失敗がなかったら、この発見はなかった
日本の生成AI利用率は26.7%（総務省, 2025年）。まだ多くの人が手探りの段階です。
プロンプト集を試してうまくいかなかった経験があっても、それは全然おかしくありません。
プロンプト集が悪いのではなく、プロンプト集がカバーしているのは問題の一部だったということです。
AIは「聞き方」より「渡し方」で結果が変わります。
この実験は、開発時間を8割→6割に減らしてAI活用で時間配分を変えた記録の続きでもあります。
時間配分を変えた先に、「何をAIに渡して、何を自分がやるか」という問いが待っていました。
まだ1週間です。
でも、プロンプトを磨くフェーズは終わりました。
これからは分解の精度を上げる実験に入ります。
参考文献
- Navigating the Jagged Technological Frontier（Harvard Business School × BCG研究）
- Measuring the Impact of AI on Developer Productivity（arXiv, 2025）
- How task decomposition and smaller LLMs can make AI more affordable（Amazon Science）
- AI Doesn’t Reduce Work—It Intensifies It（Harvard Business Review, 2026年2月）
- 総務省 令和7年版 情報通信白書 — 生成AI個人利用率
- Claude Codeを3ヶ月使ってわかったこと（GIG）
AI時代の不安を構造で分解するシリーズ
AI時代の不安・焦り・パフォーマンス低下を「構造」で分解し、対処の糸口を見つけるシリーズです。
