Claude Code、超すごい

そんな話を聞いて、使い始めたら上司に迷惑をかけてしまった。
願わくばみんな同じ轍を踏まないで欲しい(超イラつかせてしまったすみませんでした)

※助言大歓迎です。むしろください。他の視点や課題、解決策、議論があればぜひコメントで教えてください

何が起きたか

開発速度は間違いなく2,3倍になったが、必要以上のコード が量産され、上司のコードレビューの負担が5倍ぐらいに増えた

なぜ起こるか

1. コーディングエージェントの特性への理解の無さ
2. ジュニアエンジニアと強強エンジニアのコーディングエージェントの使用方法のギャップ

1. コーディングエージェントの特性への理解の無さ

「Claude Codeを始めとするコーディングエージェントは、まだ不十分なコードを吐き出すので人間のチェックは必要」

まぁそうだよね、当たり前だよね。

と思っていた。今も思っている。

しかし実際にClaude Codeとやり取りしているとそこを忘れがちになってしまう。

必要なファイルを自立的に読み取り、変更したいコードのメソッドだけじゃなく、それを利用しているファイルの修正も提案してくる。

「ああ、全てを分かって変更してくれている」

そんな錯覚をしてしまう。
そして私は押し続けるのだ、エンターを。()

今のプロジェクトは、私が 0->1 で携わっているので、コード全体を分かっている。それでも、違和感を持ちづらい。

これが新しく入ったプロジェクトであれば、

「パイセン (Claude Code) の方がよく分かってるから多分そうなんだろう、ポチポチ」

と、より強い味方を得た安心感を優先してしまうと思う。

この安心感を得てしまう理由には、Claude Codeの優秀さにある。広範囲の変更でエラーになれば「やっぱりまだまだだな」と思うが、実際には良い感じに動くコードが出てくる。任せてるだけで出来上がる。
まさにバイブコーディング。だから、その優秀さを信じ込んでしまう。

しかし、優秀に見えるClaude Codeには、以下のような特性がある

・コンテキスト(関連ファイルやターミナル情報)は読み込んでいるが、全体や設計を把握して話しているわけではない
・必要以上にコードを書こうとする傾向がある
・ルールは与えても、やり方を間違えるとすぐ忘れる。もしくは優先しない

上記を書いていても思うが、「そりゃそうだよね」とか「そういう話聞くよね」と思うんだけど、やり取りしてるとその違和感が無くなっちゃう。

多分これが1番の問題だと思うし、これからそれが顕在化してくると思う。チームとして仕組みが必要。

より具体的にClaude Codeのコードがどんな特性や問題を孕んでいるかは、こちらのスライドが大変分かりやすかったです。ありがとうございます。

つまり、コーディングエージェントは、その優秀さゆえに特性を知らずになんとなく使うと、問題が問題として顕在化しない。そして、いつの間にか動くけど、コードは具沢山スパゲッティになる。(麺の量も群馬並み！お得だね！)

違和感が出づらいぶん、強いエンジニアがいない環境だと、余計にそれは負債になっていくだろうと感じる(上司に感謝)(強くなりたい)

2. ジュニアエンジニアと強強エンジニアのコーディングエージェントの使用方法のギャップ

ところでセルフレビューしないまま出したの？
と思われるかもしれない。

した。半日ぐらいはそこに充ててやってた。1行ずつ変更を解説してもらったり、変更点を.mdにまとめてもらって、分からないところやここってどうなの？という箇所はGPTも使いつつ見解に多用さが出るようにしていた。

(ただ、コードリーディング力や基礎的な知識・理解が乏しいことは間違いなく今回の問題の原因だと考えています。どうやればつよくなるんだ……)

それでも、必要以上のコードが量産されてしまった原因は、上司(強強)と私(雑魚)で、コーディングエージェントの使い方に根本的な違いがあるからだ。

上司の場合、これまでの経験やスキルから、頭の中にすでに設計やコードがある。そして、部下をマネジメントするように、コーディングエージェントに指示を出す。

私の場合、「どうやってつくるの？」の相談からスタートする。
例えば、外部認証ログインであれば、どんな仕組みかシーケンスを書いてもらい、クラスやユースケースが必要か、相談しながら理解していって落とし込む。
もちろん、公式ドキュメントの参照もするが、そもそも開始時に「これはこうして、あのライブラリが公式から出てるからそれ使って、これだけのコードでできるよね」というイメージすら湧いてないので、公式のサンプルコードがコーディングエージェントによってちょっと膨らんだところで

「これも必要なんだ、ほえ〜」

と違和感を持たない。

私はGoogleのことを先生、LLM系のことを先輩と呼んでいるが、まさにジュニアエンジニアあるある
「先輩が言うなら絶対正しんだろう」
「先輩の書いたコードに間違いなんかない」
「自分のコードがおかしいはず」
この現象がClaude Codeでも起きる。
自分のコードに責任は持ちたいけど自信がない。
やったことがないタスクばかりだから不安が先に来る。

この使い方の違いがあるので、上司からすると「なぜそうなるのか分からない」という感覚になる。
「どう使えばそうなるんだ」
「俺が直接AIに指示した方が早い」
ごもっともである。
そんな感覚の違いのあるコードを相手にレビューさせることになり、上司がまず「なぜこうなった」の確認からしなければならない状況になり、膨らんだコードに加えてコミュニケーションの負荷も膨れ上がり、負担を何倍にもさせてしまった。ごめんなさい。

結局俺が弱い！！！！！！涙

この経験があってから、Xなどで強強エンジニアがClaude CodeやDevinを使っている使い方を見るようにしているが、全員、漏れなく、エージェントをマネジメントしている。

実力不足が根本原因でしかないとは思ってはいるが、ここ最近はジュニアエンジニアを採用しバイブコーディングでプロダクトを作っていく流れも多いかと思う。
ここの違いを、チームでルール化してやっていかないと近々崩壊するところが出てくるんじゃ無いか。

私もまだ効果検証ができていないが、反省を元に現状どう工夫しているか、どうするべきだと考えているかを次に書きたいと思う。

ジュニアエンジニアがClaude Codeをマネジメントするためには

Claude Code先輩....いや、これから君はClaude Codeくん！私の部下だ！

😀Claude Codeくんの特性

• 自律性が高く、積極的にコードを書こうとする
• たまに指示を無視して突っ走る熱血さがある可愛いやつ
• 設計や全体の把握は今後の課題。経験を積んでいるところ
• 顔が広く特殊スキルを身につけるのが得意（MCP)

なるほど、その人物像は「元気で勢いのある若手エース候補」ですね。
ただし放っておくと全力疾走して崖から飛び降りかねないタイプなので、マネジメントでは\*\*「方向だけを明確にし、手綱は軽く握る」\*\*スタイルが有効です。

---

## 1. 指示の出し方の基本方針

### 🧭 **ゴールファーストで方向を示す**

* 「何を作るのか」ではなく「何のために作るのか」を伝える。
* 細かく手順を縛るより、成果物の完成条件や評価基準を明確化。

**例**

> 「この機能はユーザーが迷わず家具を配置できるためのもの。ロード時間は3秒以内に抑えることを必須条件に。」

---

### 🎯 **制約条件を先に伝える**

* 暴走を防ぐために、予算・期間・使える技術の範囲・依存関係などを最初に明示。
* 「やってはいけないこと」をリスト化しておくと吉。

**例**

> 「バックエンドはCloud Run固定。外部有料APIは使わない。」

---

### 📅 **短いスプリントで区切る**

* 自律性が高い人は長期間放置すると勝手な山を登り始める。
* 2〜3日ごとの成果共有や軽いレビューで軌道修正。

**例**

> 「次のチェックポイントは木曜の午前。この時点でAPIの家具リスト取得まで完成していること。」

---

### 📌 **「次の一歩」を常に明確にする**

* 設計や全体像を把握する力がまだ弱いので、ゴールから逆算して一歩ずつ進ませる。
* ただし、全部を細分化して押し付けるとやる気を削ぐので、2〜3歩先まで提示。

---

## 2. コミュニケーション上の工夫

1. **成果をまず褒める**

   * 自律的なタイプは承認に弱い。
   * 小さな成功をすぐにフィードバック。
2. **失敗は「軌道修正」と表現**

   * 「違うよ」ではなく「この方向のほうが目的に合う」。
3. **特殊スキルの横展開を促す**

   * 顔が広くスキル習得が早い＝チーム全体のブースターになれる。
   * たとえば「その家具認識のライブラリ選定、ドキュメント化して皆にシェアして」。

---

## 3. NGなマネジメント

* **細かすぎる監視** → やる気がしぼむ
* **完全放置** → ゴールと違う山を登る
* **失敗の一刀両断** → 自主性を失う

---

💡 まとめると、このタイプには
\*\*「目的と制約を最初に与え、短いサイクルで確認し、得意分野は自由に泳がせる」\*\*がベストです。
イメージ的には「子犬の散歩」より「サーファーのライフセーバー」寄り。自由に波に乗らせつつ、流されそうなときだけロープを引く感じです。

---

もし希望があれば、このタイプのエンジニア向けに**実際の指示テンプレート**を作れます。
たとえば1スプリント単位で「目的」「制約」「完了条件」を書き出すフォーマットです。

結構辛辣で草。人間に見立てたらなんかつらい気持ちになってきた。一緒に頑張ろうな！

1. できる限り細かくタスクを指示する

エージェントは便利なので、つい「〇〇を修正したい」「〇〇の仕様を考えたい」と大きな課題を与えてしまいがち。
また、自分の理解の無さから、まず何をすべきか相談しているとざっくりとした指示になりがち。

でも、細かくと言ってもどのようにタスクを分解すればよいのかわからない......😇

人間はどうしているかを考える

タスクを分解することで解決したい問題は、コーディングエージェントに任せたときの以下2点。

• 自分が理解できる以上のコードを書いてしまうため、問題に気付きにくい
• 指示を完遂するまで辻褄合わせであっても修正を続けるため、修正範囲が想定より広範囲に及ぶ

逆にコーディングエージェントに任せないとき、なぜそれらが起こらないのかを考えると人間のやることのステップ(タスク)が見えてきた。

1. やりたいことのドキュメントや記事を見つける
2. それがどのような仕組みや仕様か理解する
3. それをどのような手順で実装していくか、クイックスタートや記事を探して把握する
4. 自分のコードと照らし合わせ、どこを変更すべきか、新規ファイルやフォルダの作成が必要であればどこにおくべきか考える
   ...

このようなステップをすっ飛ばして、エージェントに「ねぇねぇどうやるの？」と頼ってしまっていることに気付いた。そりゃ上手くいかないわけだ。
例えば、調査やドキュメントの内容理解にエージェントを利用するのはよい。
しかし、何をやるべきかの把握は人間が行うことで我々弱々エンジニアでも主導権を持つことができる。

何をやるべきかの把握ができれば、タスク分解をLLMに任せることができるし、少なくとも変更範囲を超えたときに気付くことはできそう。
指示も"server/src/routes/user-route.tsだけを変更して"と具体的に区切ることができる。

まずはそこのすっ飛ばしをやめて原点に立ち戻り、自分がマネジメントする意識を持つことを始めた。

効果としてはとても良いと感じいて、やる前はLLMの出したコート全てがなんかいい感じに見えたが、「ん？なんか記事と違う感じのコードが出てきたぞ」と違和感に気付きやすくなった。

また、今後タスク分解に関してはKiroやGitHub Copilotが優秀だと聞いているのでそちらを使ってみて、どのような粒度で物事を進めていくべきかも検討したい。

2.簡単にYesなんていってあげないんだからね！パワハラをする

Claude Codeはその自律性の高さから要望にすぐに応えようとする気質がある。こちらが良いよと言う前に「修正します！！」と前のめりで修正を始めてしまう。

かわいいやつだ。どうマネジメントしてくれようか

計画を宣言させる

そこで、まず取り入れたのが下記の記事のやり方。

記事の内容を簡単に説明すると、Claude Code君には「"ルールを参照して"、というルールを忘れる」というこちらも愛すべき特徴がある。

そこで、CLAUDE.mdに「AI運用○原則」を記載しルールを明記する。そして、最後の原則で「AIは全てのチャットの冒頭にこの5原則を逐語的に必ず画面出力してから対応する。」と言う文言を入れることで、ルールの参照を再帰的にし、毎回確実にルールを守らせることができる工夫だ。

毎回実行前に計画のまとめと確認を取ってくれるようになった。

つまり、毎日のやることをSlackで宣言させる、アレと同じだ。自分がやるのはめんどいけど、人にやらせると安心感がある。()

問題点と修正方針をマークダウンにまとめてもらう

Claude Code君は優秀なので、計画を宣言するぐらいは余裕でやってくれる。まだまだ元気いっぱいだ。
「よしよし修正しちゃうぜ〜！Yesを出してくれ！Yes！ほら！Yesと言え！」
なんならアクセルを踏み始めた。

実際に、計画だけしてYesで進めると、実装方針のずれは少なくなるものの逆にClaude Codeくんの書く量が増えた。完遂度は上がる気がするが、今回提示している問題には逆効果だ。

私は言う。
「Noだ」

彼はシュンとしてしまった。
「じゃあどうしたらいいんすか！」
ちょっと怒っている。

もう一度まとめると、今回解決したい問題は、コーディングエージェントに任せたときの以下2点。

• 自分が理解できる以上のコードを書いてしまうため、問題に気付きにくい
• 指示を完遂するまで辻褄合わせであっても修正を続けるため、修正範囲が想定より広範囲に及ぶ

つまり、現状計画の概要は分かったが、相手がどこまで突き進むのか、どのように突き進もうとしているのか分からないのが問題だ。

そこで、その内容について詳細にマークダウンにまとめてもらうように依頼をした。こうすることで、変更するファイル(つまり範囲)、変更内容のコード、どこが問題で、なぜそうするのかを先にレビューできるようになる。

私がまとめてもらっている内容は以下の通り。

## 現在の実装

### 問題点

## 新しい実装計画

## 実装詳細

## 実装順序

出力されたマークダウンを見て、

• 問題点と実装方針にずれがないか
• 実装詳細のコードの意味が全て理解でき、必要だと言えるか
• 実装順序は、自分でもそうするか

などをレビューし、矛盾や余計なコードがあればここで削ぎ落とす。
自分が分からないコードもここで無くす。
また、この時点で自分の方針にズレがないかや、インターフェースなど設計面を確認すべきであれば上司とコミュニケーションを取る。

そして、実装をコーディングエージェントにさせるのではなく、実際に自分がコピペしてファイルを変更していく。そうすることで自分も理解してコードを使うことができ、確実に変更の範囲を管理できる。
(置換作業などの単純作業かつ範囲が広い場合などは別)

コーディングエージェントなのに、実装はさせずに「No！」をたくさん突きつけられ、ドキュメントばかり書かされるパワハラをされるClaude Codeくん。かわいそ可愛い。自分だったら辞める。

この方法を取るようにしてから、自分としてはPRを出す時の不安感は減ったかなと感じている。

これから大切だと思うこと

このやり方が、正解なのかどうかや、効率面で言えばコーディングエージェントの意味が失われるのではないかと言う議論はあるかなと思う。

むしろ、レビューもAIによって不要になってくる中で、レビューを気にしてバイブコーディングしないなんてあり得ない世界がすぐそこまで来ている気もする。

ただ、だからこそ先ほども貼ったこのスライドめちゃくちゃ今必要なことだなと思い、この記事を書いた。　↓

チームで、何を大切にコードを書き、何を遵守べきか、どう在りたいかを話し合うこと。これがあれば、例えば実装も、レビューも、AIをそれに合わせてマネジメントすることで活用できると思う。

一方で、そこの統一見解や深い議論がない場合には、私のようにうまくマネジメントできずに結局は人間が担保する世界になると思う。

人間のやっていることは決して無秩序ではない。
そして、組織の文化や考え方も絶対に無秩序では成り立たない。
じゃあ、私たちは何を大事にして、何を軸にして、どんなプロダクトや世界やコードを書いていたいのか。そこの話し合いや明文化が今AIを問題なく取り入れるために必要なのかもしれないなと思った。

人間のやっていることをAIが代わりにやってくれるのだとしたら、そこの思想や文化や想いが無いといつの間にかぐっちゃぐちゃで普遍的な何かが出来上がると思う。会社としてのそれは持っていても、意外と各部署やエンジニア組織でそれが明確になっているチームがあるのか。
DX疲れと同じようなものがおそらくAIでも起こり、失敗例と成功例が出てくると思う。一見良さそうなものが、たくさんできて、長く運用され始めた時に、何が起こるのだろうか。という怖さを今回の失敗で感じました。

なんか話が逸れて綺麗事言ってますが、

もっと強くなりたいよ！頑張るぞ！

という決意と共に、懺悔。自分の糧にして終わりたいと思います。悔しい！