「AIを使えば、WebサイトやLPが簡単に作れる」

最近、そんな発信をよく見かけます。
実際、Claude CodeやCodexなどを使えば、コードを書く作業そのものは以前より速くなりました。

• 文章を考える。
• デザイン案を出す。
• コードを書く。
• 不具合の原因を調べる。
• 複数の修正案を比較する。

これまで一人で時間をかけていた作業を、AIに手伝ってもらえるようになったのは間違いありません。
ただ、僕自身の制作時間が短くなったかというと、正直なところ、そうでもありません。
むしろ、以前より時間がかかるようになった部分もあります。
それはAIが使えないからではなく、AIによって「直せる場所」が増えてしまったからです。

AIによって、これまで諦めていた部分まで直せるようになった

これまで手を抜いていた、というわけではありません。
ただ、仕事として制作する以上、予算や納期には限りがあります。
その中で、

「ここまで整っていれば問題ないだろう」
「この違いは、そこまで成果には影響しないだろう」
「本当はもう少し調整したいけれど、今回はここまでにしよう」

と判断して、作業を終えることはありました。
これは単なる妥協というより、仕事として必要な線引きだったと思います。

ところが、AIを使うようになると、これまで時間の都合で諦めていた部分にも手が届くようになります。

• コードの構成を見直す。
• レスポンシブ表示を細かく調整する。
• 余白や文字サイズの違和感を詰める。
• 別の実装方法を比較する。
• 文章や画像も、より伝わる形に修正する。

一つひとつの作業は確かに速くなっています。
でも、その分だけ「もう少し良くできる場所」が見えるようになりました。
その結果、制作時間が減るどころか、作業量そのものが増えている。

AIによって制作が楽になったというより、以前なら諦めていた完成度まで追いかけられるようになった、という方が近い気がします。

AIは制作時間を減らすより、完成基準を上げている

以前なら80点で完成としていたものを、AIを使うことで90点、95点まで持っていける。
そう考えると、制作時間が変わっていなくても、生産性は上がっているのだと思います。

• 同じ時間で、以前より多くの検証ができる。
• 以前より細部まで整えられる。
• 以前なら実現できなかったことも試せる。

ただし、その分だけ自分の中の完成基準も上がります。

• AIを使う前なら気にならなかった部分が、気になるようになる。
• 直せると分かれば、直したくなる。
• 別案を出せると分かれば、比較したくなる。

AIは制作時間を短縮する道具というより、制作者が許容していた限界を押し広げる道具なのかもしれません。

デザインをAIで完全に再現できるのか

最近は、デザインデータからClaude CodeやCodexを使って、一気にコーディングする事例もよく見かけます。

確かに、シンプルなレイアウトであれば、かなり近いところまで再現できます。
ただ、僕が実際に使っている感覚では、デザインをそのまま完全に再現するのは、まだ難しいと感じています。

• 余白の取り方。
• 文字の詰まり方。
• 画像と文章の距離。
• 画面幅が変わったときのバランス。
• スマートフォンで見たときの印象。

コードとしては間違っていなくても、実際に画面を見ると、

「なんとなく違う」

ということがよくあります。
そして、この「なんとなく違う」を直すには、結局、人が見て判断しなければなりません。

デザインカンプに近い静止画を表示するだけなら、AIでもかなりできます。
でも、Webサイトは静止画ではありません。

• 文章量が変わる。
• 画像の比率が変わる。
• 画面の幅が変わる。
• クライアントが更新する。
• WordPressやフォームなど、別の仕組みとも組み合わさる。

そうした変化があっても、デザインの意図を保ち、使いやすさを損なわないようにする必要があります。
そこまで含めると、「デザインから一瞬でWebサイトが完成する」というほど単純ではないと思っています。

簡単に作れることと、良いものを作れることは違う

もちろん、シンプルなWebサイトやLPであれば、AIを使って短時間で形にすることはできます。

• イベントの告知ページ。
• 検証用のLP。
• 期間限定のキャンペーンページ。
• 社内向けの簡易ツール。

目的によっては、テンプレートに近い構成でも十分な場合があります。
必要以上に作り込まないことも、仕事では大切です。

だから、「AIで簡単に作れる」と言っている人に、制作物へのこだわりがないと決めつけるのは違うのかもしれません。単純に、目指している完成地点が違うだけという可能性もあります。

ただ、気になるのは、どの品質水準を完成と呼んでいるのかを説明しないまま、

「AIなら簡単にプロ品質のWebサイトが作れる」

という言葉だけが広がっていることです。

• ページが表示される。
• ボタンが動く。
• デザインに似た画面ができる。

そこまでを完成とするなら、確かにAIで簡単に作れるようになりました。

でも、読みやすさ、使いやすさ、更新しやすさ、保守性、表示速度、信頼感、成果へのつながりまで含めれば、完成までにはまだ多くの判断が必要です。

簡単に作れることと、良いものを作れることは同じではありません。

クオリティは高ければ高いほど良いのか

僕はこれまで、

「同じようにクライアントの要望を満たしているなら、クオリティが高い方が、よりクライアントの要望に応えられる」

と考えていました。
今も基本的には、その考えは変わっていません。

• 見やすい。
• 分かりやすい。
• 使いやすい。
• 信頼感がある。
• 成果につながりやすい。

こうした品質は、制作者の自己満足ではなく、クライアントにとっての利益でもあるからです。

ただし、少し違う見方も必要だと思うようになりました。
完成度95点でも公開が1か月遅れるサイトと、80点でも予定どおり公開できるサイト。
案件によっては、80点の方がクライアントにとって価値が高いこともあります。

制作者が考える品質と、クライアントが必要としている品質が、必ずしも同じとは限りません。
美しいコードや細かな余白調整に時間をかけても、ユーザーにもクライアントにも、ほとんど影響がない場合もあります。

つまり、品質は高ければ高いほど無条件に良いわけではない。
予算、納期、目的、運用方法まで含めて、必要な品質を見極めることが大切なのだと思います。

納期を守ることも品質。
更新しやすいことも品質。
予算内で完成させることも品質です。

AIによる品質向上と、終わりのない修正は紙一重

AIを使うことで、制作物の品質を高められるのは間違いありません。
ただ、ここには少し危険な部分もあります。

AIは何度頼んでも疲れません。

もう一案。
もう少し調整。
別の方法も比較。
この部分も整理。
ついでにここも修正。

そうやって、いくらでも作業を続けられます。
これは品質向上でもありますが、単に終わりどころを見失っているだけかもしれません。
直せる場所があることと、直す価値があることは同じではありません。

AIによって作業能力が上がったからこそ、

• 「どこまでやるべきか」
• 「どこから先は自己満足なのか」
• 「今回の目的に、本当に必要な修正なのか」

を判断する力が、以前より重要になっている気がします。

AIが平均点を出す時代に、人は何をするのか

ちなみに、自分自身を、デザイナーやコーダーとして特別にレベルが高いとは思っていません。
デザインもコーディングも文章も、一通り平均点くらいまでは形にできる。
自分ではそのくらいの立ち位置だと思っています。

ただ、AIはまさに、この平均点を出すことが得意です。
文章もデザインもコードも、ある程度整ったものを短時間で出してくれます。
そうなると、これから価値になるのは、平均点のものを作る能力だけではないのかもしれません。

AIが出したものを見て、

「使えないわけではない。でも、このままでは出したくない」

と気づけること。

• 何が足りないのか？
• どこに違和感があるのか？
• 何を直せば目的に近づくのか？

それを判断し、言葉にして、完成に近づけていくこと。
AI時代に求められるのは、平均点を作る能力よりも、平均点から何が足りないかを判断する能力なのだと思います。

AIは仕事を簡単にした。でも、完成まで簡単にしたわけではない

AIによって、Web制作は確実に変わりました。

• コードを書く時間は短くなった。
• 調査も速くなった。
• 修正案も増えた。
• 一人でできることも広がった。

その意味では、制作は簡単になったと思います。

でも、完成度にこだわる人の仕事まで、簡単になったわけではありません。
むしろ、できることが増えたことで、以前なら見えなかった改善点まで見えるようになった。

見えてしまえば、直したくなる。
だから、AIを使っているのに、制作時間が減らない。
場合によっては、以前より時間がかかる。

ただ、それはAIによる効率化に失敗しているのではなく、同じ時間で作れるものの質が上がっているということなのかもしれません。

AIを使えば簡単に作れる。

それは間違いではありません。でも、

「簡単に作れること」と「良いものを完成させること」は違う。

そして、AIによって制作のハードルが下がった今だからこそ、どこを完成とするのかという、人間側の判断が、これまで以上に重要になっている気がします。

• « Claudeを使わない、というより「使おうと思えない」理由