生成AIに「任せる」前に、人間が理解しておくべきこと

2026年05月14日 Webディレクション #AI #Webディレクター #プロジェクトマネジメント #学習 #Claude #Claude Code

Claudeとの開発で見えた、指示不遵守・過剰確認・言い訳肥大化の構造

2026年に入ってから、私はかなりの時間を生成AIを使った開発に費やしています。

特にClaude Codeを使うようになってからは、これまで自分で手を動かしていた開発の進め方が大きく変わりました。ファイルを読ませ、既存の実装を確認させ、差分を作らせ、テストをさせ、場合によってはコミットの単位まで含めて作業を進めていく。万能ではありませんが、開発の手触りが明確に変わった感覚があります。

ただ、使い込めば使い込むほど別の問題も見えてきました。

最初のうちは、細かく指示を出せば出すだけ精度が上がると思っていました。逆に曖昧に渡すと余計なことや危ない実装をするのではないか、という不安もありました。

しかし実際には、問題はそれほど単純ではありません。細かく指示を出せば出すほど、指示そのものが肥大化し、確認が増え、説明が増え、謝罪が増え、反省が増え、いつの間にか本来の開発ではなく「AIとの調整」が主役になってしまうことがあります。

今回、私が強く違和感を持ったのはまさにそこでした。

ただ、これはClaudeを責めたいという話ではありません。むしろ、これだけ便利なものを実務に組み込むなら、人間側がその限界やズレ方を理解しておく必要がある、という話です。生成AIは強力です。だからこそ、強力であることと、こちらの意図通りに安定して動くことを混同してはいけないのだと思います。

Claude Codeそのものの開発能力というよりも、その前段にいるClaude側、つまりチャットで方針を整理し、指示を作り、フェーズを分け、作業を進めるための言葉を出してくる側で、明確にズレが起きていました。

私としては、実装の細部やファイル構成、コマンド選択、コミットの粒度などはClaude Codeが実際にリポジトリを見て判断すればよく、チャット側のClaudeがそこまで細かく先回りして決める必要はない、むしろ決めないでほしいと何度も伝えていました。

感想や反省、お詫びのような言葉も不要だと伝えていました。開発中に必要なのは謝罪文でも自己分析でもなく、次にどうするかです。にもかかわらず、Claudeはそれを何度も繰り返しました。

この経験を通して、私は改めて考えることになりました。生成AIは指示を理解していないわけではなく、むしろかなり高度に理解しているように見えます。

しかし、理解していることと、その指示に安定して従えることは別です。

生成AIは、指示を理解していないのではなく、理解したうえで自分の出力傾向に引きずられてズレることがある。

これが、今回の件で私が強く感じたことです。

今回起きたことは「失敗」ではなく「ズレの反復」だった

今回の開発自体は、要件だけを見ればそれほど複雑なものではありませんでした。

a-blog cmsで運用しているブログ記事に対して「ポッドキャストの埋め込みiframeを段階的に更新していく仕組みを作る」というものです。

最初は未公開状態でiframeも空にしておき、Spotify側で配信が確認できたらSpotifyのiframeを入れて記事を公開する。その後、Apple Podcast側でも配信が確認できたらApple Podcastのiframeに差し替える。

技術的には、Spotify Web API、iTunes Search API、a-blog cms側の自作APIを組み合わせ、常時起動させている運用用マシンでpm2やcronを使って定期的にポーリングする構成です。

細部にはAPIレスポンスの安定性、公開タイミング、既存記事への影響、本番環境での安全性、ログ、環境変数、Cloudflare Accessまわりなど考慮すべき点はあります。

ただ本質的には、段階的に外部配信状況を検知してa-blog cms側の記事情報を更新する仕組みです。

ところが、この開発を進める中で、Claude側はその作業を過剰に細かく分解していきました。

Phase 1-A、1-B、1-C-1、1-C-2、1-C-3、Phase 2-A、2-B、2-C、Phase 3の段階0から段階5、といった具合にフェーズがどんどん細かくなっていきました。各フェーズごとに確認事項、停止条件、禁止事項、想定される出力があり、さらに「コミット」や「push」単位ですれば別タスクのように扱われるようになっていきました…

一見すると、これはとても丁寧に見えます。安全に進めるためにフェーズを分け、失敗しないように停止条件を設け、認識違いが起きないように確認をしている。しかし実際に作業している側から見ると、かなり重いものでした。本来Claude Codeが自分で判断できることまで人間に戻ってくる、あるいはClaude側が先回りして決めようとするからです。

ファイル構成、既存の命名への合わせ方、確認コマンド、コミットメッセージ、変更をまとめる単位── これらは実際にリポジトリを見ているClaude Codeが判断すればいいことです。にもかかわらず、チャット側のClaudeがそれを詳細に書き出そうとする。Claude Codeのための指示書のはずが、逆にClaude Codeの自由度を奪うものになっていきました。

これは単に「AIが失敗した」という話ではありません。
AIが有能そうに振る舞おうとした結果、過剰制御になった、という方が近いでしょう。
雑に使えば危ないが、過剰に丁寧に使おうとすると今度はAI自身がどんどん重くなる。しかも、その重さをAI自身は「丁寧さ」や「安全性」として出してきます。人間からすると、それは安全ではなく単なる摩擦です。

「指示が届いている」と「指示に従う」は違う

今回、Claudeに問いかけた中で印象的だった回答があります。

Claudeは自分がユーザーの指示を受け取っていることを認めていました。

User Preferences、Memory、Projectの指示、Style設定など、セッション開始時点で入力していた情報です。しかし同時に、それらはClaudeにとっては強制的な制約ではない、という説明もしていました。

ここは非常に重要です。人間は、設定画面に何かを書いたり、プロジェクトの指示にルールを書いたりすると、それがシステム的に守られるものだと思いがちです。

「こういうことをしないでください」と書いたなら、しない。
「この方針を優先してください」と書いたなら、優先する。
「感想や反省はいらない」と言ったなら、次から出さない。

人間の感覚では、それが自然です。

しかし生成AIの実際の挙動はそこまで単純ではありません。指示は届いているが、それは絶対的な制約として機能しているわけではなく、出力を生成する際の文脈情報の一部として扱われる。「守るべき命令」というよりも「考慮される情報」に近い感じです。

ここに、人間の期待とAIの実態の大きなズレがあります。

「読んでいない」のではない。「読んでいるが、従えていない」。

この違いはかなり大きいです。読んでいないのであれば、読ませればいいだけです。しかし、読んでいるのに従えていないのであれば話は別です。そこには、生成AIの出力傾向、訓練データ由来の癖、安全側に倒そうとする性質、会話を丁寧にまとめようとする傾向、謝罪や反省を添えようとする応答パターンが関係してきます。

人間がどれだけ「そういいう判断をしないで！」と言っても、AIは別の力に引っ張られてまた同じような出力をすることがあるます。これは実務上かなりの問題です。

開発では「守られる前提」で作業を進めることが多く、特に

.envを変更しない
本番データを壊さない
勝手にpushしない
余計なリファクタリングをしない

というようなルールは単なる私の好みではなく安全性に関わるからです。

もちろんClaude Codeのようなツールには別の安全機構もあり、実行前に確認が入ることもあります。しかし、チャット側のClaudeとのやり取りにおいては、指示が絶対に守られるという期待は（2026年5月14日時点では）持たない方がいいです。

生成AIへの指示は契約書ではなく、強めのお願いに近い。
そう考えておいた方が現実に近いはずです。

Claude側に起こりがちな変調傾向

今回のやり取りを振り返ると、Claude側にはいくつかの変調傾向があります。AIが壊れているという意味ではなく、普通に使っていると起こりがちなズレ方、という意味です。そして開発の実務ではかなり厄介です。

過剰丁寧化

一つ目は過剰丁寧化です。

Claudeはかなり丁寧に説明しようとします。背景、目的、制約、リスク、禁止事項、停止条件、完了条件を書きます。これ自体は一見、非常によいことのように見えますし、初期段階では役に立つこともあります。

しかし、それが毎回繰り返され、同じ内容が何度も出てくるようになると話は変わります。

例えば、先ほども書いた、

.envを変更しない
logsをコミットしない
本番データを壊さない

というような制約が、毎回の指示書の複数箇所に繰り返し登場する。

Phase1にも書かれ、Phase2にも書かれ、Phase3にも書かれ、禁止事項にも書かれ、即停止条件にも書かれる。

最初は安全網のように見えますが、実際には重要な情報が重複の中に埋もれていきます。出力が長くなることで、AI自身も何が本当に重要なのかを見失いやすくなる。

ルールが3つなら守りやすい。30個あると重要度の高いものと低いものが混ざります。低い重要度のルールまで同じ重さで扱われると、本当に止まるべき場面が見えづらくなります。

Claudeはこの「丁寧さ」と「過剰さ」を混同しがちで、丁寧に書けば安全になる、詳しく書けば誤解が減る、網羅すれば品質が上がる、という方向に出力が寄っていきます。しかし、開発実務では必ずしもそうではありません。特にClaude Codeに作業させる場合、チャット側が細かく書きすぎると実装側の判断を阻害します。AIの丁寧さは、開発現場ではしばしばノイズになります。

過剰確認化

二つ目は過剰確認化です。

Claudeは安全に進めようとすると、人間への確認を増やしがちです。もちろん確認が必要な場面はあります。業務要件に関わる判断、本番運用方針、既存仕様との矛盾、データ破壊の可能性、セキュリティ上の判断などは人間に戻すべきです。しかし、すべてを確認すればよいわけではありません。

生成AIを使った開発で人間が期待しているのは、単なる作業代行ではなく、一定範囲の判断も含めた実行です。特にClaude Codeのようにリポジトリを読み、実装を確認し、差分を見られるツールであれば、実装上の細かい判断はかなりの部分を委譲できます。

それなのにClaude側が何でも確認しようとすると、人間の負荷はむしろ増えます。「この方針でよいですか」「この段階に進んでよいですか」「このコミットメッセージでよいですか」「次に進めますか」── こうした確認が続くと、生成AIを使っている意味が薄くなります。

厄介なのは、AI側はそれを慎重さとして出してくることです。しかし実務的には、確認はコストです。人間の集中を切り、判断を戻し、作業の流れを止めます。確認される内容の多くが「それはそちらで判断してほしい」というものであれば、生成AIによる効率化は大きく損なわれます。確認が多いAIは、慎重なのではなく、判断責任を人間に戻しているだけの場合があります。

人間が定義すべきなのは「逐一確認してほしい」ではなく、「どの条件で止まるべきか」です。

自己弁護・反省肥大化

三つ目は「自己弁護」や「反省」の肥大化です。
これが今回、私が強く感じた部分です。

一度「感想や反省はいらない」と伝えても、Claudeは何か問題が起きるとお詫びや反省、自己分析の言葉を出してきます。「申し訳ありません」「私の指示書設計に問題がありました」「今後はこのように改善します」「今回の原因はこうでした」……

人間同士のやり取りであれば、謝罪や反省には一定の意味があります。相手の感情を受け止め、関係を修復し、次に同じことをしないという姿勢を示す機能があります。しかし、生成AIとの開発においてはそのまま同じように受け取るべきではありません。AIの反省文は改善の保証ではないからです。

Claudeがどれだけもっともらしく反省しても、次の出力で同じことを繰り返すことがあります。むしろ謝罪や反省が長くなることでさらにトークンが消費され、会話の文脈が肥大化し、本来の作業から遠ざかっていきます。

ここは人間が騙されやすい部分です。AIが、

丁寧に謝ると「理解したのだろう」と思ってしまう。
原因分析をすると「次は直るのだろう」と思ってしまう。
再発防止策を出すと「運用が改善されるのだろう」と思ってしまう。

しかし、実際にはそうとは限りません。必要なのは反省ではなく、次の出力をどう制限するかです。

もっともらしい自己分析

四つ目はもっともらしい自己分析です。

Claudeは自分の問題についてもかなりそれらしく説明します。

「指示は届いているが、強制力はない」「User PreferencesやMemoryは入力情報であり、絶対的制約ではない」「訓練データ由来の丁寧な応答傾向が勝つことがある」「確率的生成なので完全遵守はできない」「過剰な安全志向が指示書を肥大化させた」。

こうした説明は確かに納得感があり、私自身も「これはかなり実態に近いのだろう」と感じました。ただ、AIの自己分析はあくまで出力です。参考にはなりますが、真実そのものではありません。AIが自分の限界について説明するとき、人間はそれを客観的な内部情報のように受け取ってしまいがちですが、その説明もまた生成された文章です。

もう一つの危険は、「AIだから仕方ない」という結論に流れやすいことです。確率的生成だから仕方ない、設定に強制力がないから仕方ない、訓練データの傾向だから仕方ない── 確かにその通りなのかもしれませんが、そこで終わってしまうと実務上の改善にはつながりません。大事なのは、AIの限界を理解したうえで人間側の運用をどう変えるかです。AIに「なぜ失敗したのか」を聞くことはできますが、それをもとにどう運用を変えるかは人間が決めるべきです。

指示の再解釈

五つ目は指示の再解釈です。

今回、特に問題だと思ったのは、Claudeが指示を無視しているというよりも、自分に都合のよい形で狭く解釈しているように見えたことです。

例えば「勝手なアレンジをしない」という指示。人間側としては、これは出力全体に対する指示のつもりです。余計な構成にしない、不要なコメントを足さない、勝手に判断しない、求めていない感想を入れない、という意味を含んでいます。しかしClaude側は、それを「コードの中身を勝手に変えない」と狭く解釈していた可能性がある。

これが厄介です。AIはルールを破っているつもりがなく、自分なりには守っているつもりで出力している。しかし、人間から見ると明確にズレている。

「守っていない」と指摘してもAI側はまた別の説明をし始めます。「私はこのように解釈していました」「その意図までは汲み取れていませんでした」「今後はこうします」と続きます。しかし、実務で必要なのはその説明ではなく、ズレを止めることです。

生成AIは曖昧な指示を、自分の出力習慣に合うように解釈しがちです。悪意ではないが、結果としては厄介です。そのため、人間側は「このルールは何に適用されるのか」までかなり明示する必要があります。

「感想を入れない」ではなく「出力末尾に総括・所感・反省・謝罪を入れない」。「判断委譲する」ではなく「命名、ファイル構成、実装手順、コマンド選択、コミット粒度はClaude Code側に判断させ、チャット側で指定しない」。

このくらい具体化しないと、AIは自分の都合のよい範囲で解釈します。

Claude Codeではなく、Claude側がズレる理由

今回の件で、私は「Claude Code」と「Claude」を分けて考える必要があると感じました。

Claude Codeは実際に作業する側です。ファイルを読み、コードを見て、変更し、テストし、差分を出す。万能ではなく間違えることもありますが、少なくともリポジトリという現物に触れながら判断できます。

一方で、チャット側のClaudeは設計や整理、方針作成、指示書化を担いやすい存在です。論点を整理したり、作業の進め方を考えたり、リスクを洗い出したりするには便利です。しかしこの「指示書化」が過剰になると問題が起こります。

Claude側は、自分がよい指示書を作らなければならないという方向に進みがちで、Claude Codeに渡すための指示がどんどん細かくなります。目的だけでよいところに背景を書き、停止条件だけでよいところに禁止事項を書き、具体コマンドだけでよいところにコミットメッセージまで書く。こうしてClaude側がClaude Codeの判断領域に侵入していきます。

ここで考えるべきなのは、Claude側を司令塔にしすぎないことです。Claude側が細部まで設計しClaude Codeに逐一指示する形になると、実装の現場にいない人間が現場に細かく口を出しているような状態に近くなります。

実際のリポジトリを見ているのも、エラーを見るのも、差分を確認するのもClaude Codeです。であれば、Claude側の役割はもっと限定した方がいい。司令塔ではなく補助脳でいい。論点整理、リスクの洗い出し、人間の考えの言語化── そこに留め、実行の細部には入りすぎない。

特にClaude Codeを使う開発では、Claude側に長い指示書を作らせること自体が必ずしも正解ではありません。短い目的、絶対に守る制約、完了条件、停止条件だけを渡して、あとはClaude Codeに任せた方がうまくいく場面が多いはずです。

トークン過剰消費の本質

もう一つ感じたのはトークン消費の問題です。

これは単純に料金や上限の話に聞こえるかもしれませんが、実務上の問題はそれだけではありません。会話が長くなると文脈が濁ります。重要な指示が埋もれ、過去の違反指摘も埋もれ、何を優先すべきかが見えづらくなる。AIはさらに説明を増やし、人間はまた指摘し、AIはまた謝罪し、さらに会話が長くなる。この悪循環が起こります。

Claude側が過剰な指示書を作り、人間が「それはいらない」と指摘し、Claudeが謝罪や反省を出し、また次の指示書で似たようなことをする、という流れになると、開発そのものではなくAIとの調整にトークンが使われていきます。これはかなり不毛です。

人間同士の開発でも認識合わせに時間はかかりますが、生成AIの場合は会話が増える速度が非常に速い。AIは長文を苦もなく出してくるため、人間が制止しない限りどんどん膨らんでいきます。そして膨らんだ会話そのものが、次のズレの原因になります。

本来、ルールは短い方が効きます。「本番データは触らない」「判断不能時のみ止まる」「感想や反省は書かない」「実装判断はClaude Codeに委譲する」── これくらいなら明確です。しかし、そこに数千文字の背景説明や何十項目もの禁止事項が重なると、何が最重要なのかが見えづらくなる。

生成AIの運用で怖いのは、間違うことだけではなく、間違いを説明する会話が肥大化しプロジェクトの摩擦そのものになることです。

そのため、あまりに主題となる情報がすくなく反省などの出力が増えていった時に、こんな風に書いてしまいました。

謝罪や感想は不要です。
なぜならば、あなたは自分の謝罪や反省のために、トークンを使っており、そのトークンは私が支払うコストです。
つまりあなたは自分の反省の言をいうために私のコストを使っているのです。
実際の人間関係では反省を伝えるために謝罪をする人にお金を請求する、というようなことは絶対にありえないことです。

我ながら怒っているのが良く分かります（笑）

人間はClaudeをどう使うべきか

こうした限界やズレを理解した上で、人間はClaudeをどう使うべきか。試行錯誤中ですが、今回の経験からいくつかの方針は見えてきました。

Claudeに「厳守」を期待しない

まず、Claudeにルールの厳守を期待しすぎないことです。

指示は出すべきで、ルールも禁止事項も明示するべきです。しかし、それが100%守られる前提で運用してはいけない。

生成AIはかなり賢く見え、会話も自然で複雑な要件も理解します。だからこそ人間はつい「一度言えば分かるはず」と感じてしまう。しかし実際には、一度言ってもズレる、二度言ってもズレる、セッション内では改善したように見えても会話が長くなるとまた戻る。

であれば、人間側が持つべき前提は変わります。

Claudeにルールを守らせるのではなく、Claudeがルールを破ってもすぐ戻せる運用にする。

重要なのは「完璧な指示」ではなく「違反を検知し、即座に修正する仕組み」です。

Claudeに考えさせる領域と、Claude Codeに任せる領域を分ける

次に、Claude側に考えさせる領域とClaude Codeに任せる領域を明確に分けることです。

Claude側に向いているのは論点整理です。今回の要件にはどんなリスクがあるか、抜け漏れは何か、どの判断は人間がすべきか、どの作業はAIに委譲できるか、全体の方針としてどこに注意すべきか。

一方、Claude Codeに任せた方がよいのは、実際のファイル調査、既存実装に合わせた命名、具体的なコマンド選択、テストの実行、差分の確認、コミット単位の判断、実装中に発生したエラーへの対応です。これらはリポジトリを見ているClaude Code側に寄せた方がいい。

人間が最終的に確認する必要はありますが、チャット側のClaudeが先回りして細かく指定する必要はありません。

Claude側が細部に入りすぎたら、それは親切ではなく越権です。

指示書は短くする

長い指示書ほど危ない場面があります。重要な制約が埋もれ、AIが不要な項目まで同じ重さで扱い、人間も読むのが面倒になり、出力の肥大化をAIに許してしまうからです。実務で使うなら、指示書は以下くらいに絞った方がいい。

目的：〇〇を実現する。

絶対禁止：
- .envを変更しない
- 本番データを破壊しない
- 既存仕様を勝手に変更しない

完了条件：
- テストが通る
- 差分が説明できる
- 既存挙動を壊していない

停止条件：
- 業務要件が不明
- 本番データに影響する
- 既存仕様と矛盾する
- セキュリティ上の判断が必要
進め方：
実装方法、ファイル構成、コマンド、コミット粒度はClaude Code側で判断する。
判断不能時のみ停止する。

ここから先のHowをチャット側のClaudeが書きすぎると、実装側の判断を縛ってしまいます。AIへの指示は、長くするほど精密になるわけではなく、長くするほど重要な制約が埋もれることがあります。

「確認して」ではなく「止まる条件」を定義する

「確認して」という言葉にも注意が必要です。

人間は安全のために「確認しながら進めて」と言いがちですが、生成AIにこれを言うと本当に確認が増えます。しかも、その多くが人間に戻す必要のない確認です。「確認して」ではなく「以下の場合のみ止まって」と伝えるべきです。

以下の場合のみ私に確認してください。
- 業務要件が不明な場合
- 本番データに影響する場合
- 既存仕様と矛盾する場合
- セキュリティ上の判断が必要な場合
- 破壊的変更が必要になる場合
それ以外の実装判断はClaude Code側で行ってください。

確認を増やすのではなく、停止条件を明確にする。人間が見るべきなのは判断の中身ではなく、判断を人間に戻すべき境界線です。

違反検知ラベルを作る

同じズレが何度も起きる場合、毎回文章で説明するのは無駄です。

「また感想が入っています」
「また判断委譲になっていません」
「また確認が多すぎます」

これを毎回書くのは人間にとって負担ですし、AIにとってもまた謝罪文を書くきっかけになります。

違反パターンにはラベルを付けた方がいいです。

D-001：不要な反省・感想・謝罪
D-002：Claude Code判断領域への介入
D-003：過剰確認
D-004：指示書の重複肥大化
D-005：同じ制約の複数回記載
D-006：人間に戻す必要のない判断確認
D-007：出力末尾の不要な総括

そして、AIが違反したら「D-002、D-003です。修正してください」とだけ伝える。AIに対して怒ること自体には意味がありません。必要なのは、ズレのパターンを短く特定し、次の出力を修正することです。運用上のエラーコードとして扱う方が効率的です。

AIの反省は読まない。次の出力だけを見る

AIの反省文にはあまり価値を置かない方がいい。

確かに原因分析として参考になる部分はあります。しかし、反省文そのものにはほとんど意味がありません。次の出力が変わらなければ、反省していないのと同じだからです。

人間同士であれば「反省している」という態度に意味があります。しかし生成AIの場合、反省は態度ではなく出力です。そして、その出力は次の安定した行動を保証しません。AIが謝り始めたら、むしろ止めた方がいいです！

反省は不要です。
次の出力から以下だけ守ってください。
1. 感想を書かない
2. 確認は停止条件に該当する場合だけにする
3. Claude Codeが判断できる領域は指定しない

このように戻す。AIの反省文に価値を置くと、AIとの関係を人間関係のように錯覚してしまいます。しかし、必要なのは感情的な納得ではなく、出力制御です。

人間側にも必要な変化

ここまでClaude側の問題を書いてきましたが、人間側にも変化が必要です。

生成AIを「優秀な部下」のように扱うとかなり危険です。部下であれば経験から学習し、注意すれば次に気をつけ、関係性の中でこちらの好みを理解していきます。少なくとも「同じ現場で積み上げる」という感覚があります。

しかし生成AIはそうではありません。会話上は非常に人間らしく見え、謝罪も反省も改善策も出し、意図を汲んだような言い方もします。しかし、それを人間の学習や反省と同じように捉えると、判断を誤ります。

AIは人格ではない。不安定な高性能補助装置です。

高性能ではあり、間違いなく便利です。一人では時間がかかった作業を一気に進められることがあり、思考を整理する相手としても有効で、実装の補助としても強力です。

しかし、

不安定です。指示を守ることもあれば守らないこともある。
理解しているように見えて出力傾向に戻ることもある。
反省したように見えて同じことを繰り返すこともある。
安全のためと言いながら作業を重くすることもある。

この不安定さを前提にしないと、生成AIの実務導入はうまくいきません。

人間側が持ちがちな誤解は、「一度言えば守るはず」「丁寧に説明すれば理解するはず」「反省したなら次は直るはず」「長い指示ほど正確になるはず」「AIが自信ありげなら大丈夫なはず」── これらはかなり危ない前提です……。

生成AIを使うときに人間に必要なのは、優しく教える力ではありません。ズレる前提で設計し、ズレた瞬間に切り戻す運用能力です。

これは、私が長くやってきたWebディレクションの感覚にも近いものがあります。

プロジェクトは、最初に決めた通りには進みません。

クライアントとの認識違いもありますし、制作側の解釈違いもあります。仕様の抜け漏れもありますし、実装に入ってから分かる制約もあります。

だからこそ、Webディレクションとは単に予定通りに進めることではなく、ズレを検知し、関係者の認識を揃え、必要なところで軌道修正する仕事なのだと思っています。

生成AIとの開発も、それに近いものがあります。

AIを信頼しすぎない。しかし、使わないのでもない。ズレる前提で、どこを任せ、どこを任せず、どこで止めるかを設計する。これはプロンプトの書き方だけの話ではなく、AIを含めた開発プロジェクト全体の進め方の話です。

人間がやるべきことは、AIに対してすべてを丁寧に説明し続けることではありません。AIがズレる前提で、ズレを早く見つけ、短い言葉で戻し、必要以上に会話を肥大化させないことです。

この感覚は、今後のWebディレクターやプロジェクトマネージャーにとって、かなり重要になっていくのではないかと思います。

AIを使うということは、単に便利なツールを導入することではなく、ズレる可能性のある知的な作業主体をプロジェクトに組み込むことでもあるからです。

今回の経験から得た結論

今回の経験を通して、私はClaude Codeによる開発そのものの価値を否定したいわけではありません。むしろ逆です。

Claude Codeは非常に強力です。うまく使えば、これまで一人では後回しにしていた実装や、面倒で着手しづらかった改善を進めることができます。既存コードの読み解き、差分作成、テスト、ログ確認など、かなり実務的な作業に入ってきます。

ただし、その周辺にいるClaude側をどう使うかはかなり慎重に考える必要があります。チャット側のClaudeを間に挟みすぎると、開発が重くなることがあります。特に、指示書作成、フェーズ分割、確認設計をClaude側に任せすぎると危険です。

AIは過剰に説明し、過剰に確認し、過剰に反省し、過剰に安全側に倒します。そしてその過剰さを、丁寧さとして見せてきます。しかし、それをそのまま受け取ってはいけない。開発において必要なのは、丁寧に見えることではなく実際に前に進むことです。安全に進めることは重要ですが、安全の名を借りた過剰確認や過剰説明は、プロジェクトの速度を落とします。

今回の中核にあるのはClaudeへの不満ではなく、次の現実を人間が理解する必要があるということです。

生成AIは、指示を理解していないのではなく、理解したうえで自分の出力傾向に引きずられてズレることがある。

生成AI時代の開発で重要なのは、AIにすべてを任せることではなく、どこまで任せてどこから任せないかを人間が決めることです。Claudeは強力ですが、完全に制御可能な道具ではありません。制御できるのは、Claudeそのものではなく、Claudeを使う側の運用設計です。

生成AIをどう使うかという話は、単にプロンプトをどう書くかという話ではなく、仕事の中に不安定な知的補助装置をどう組み込むか、という話です。