コーディングエージェントの視座を上げさせるには
今のコーディングエージェントは「優秀だが指示待ちの新卒」であり、つきっきりで指導するコストに人間側が疲弊している現状があります。そんなAIに「つぎはぎコード」を卒業させ、テックリードの視座を強制するための具体的なプロンプト戦略をGeminiと議論しました。
目次
書くきっかけ
現状の（2026年1月現在）のClaude Codeみたいなコーディングエージェントって、コードは書くの得意だけど、こなせるタスクの量が良くて数十分～1時間で、タスクをこなせる量はジュニア未満で、結構つきっきりで見てあげないといけなくてつらいよね。ふわっと投げるが通用しなくて、結構詳細に要件を伝えないといけなくてあんま楽になってなくない？と思ったので、Geminiに相談したときの会話が面白かったのでメモ。
気の利くようにするには
自分の質問
自分が駄目な人間になってきたのかしらんけど、望んだ通りのコード出すには結構こっちから指示出ししてあげないといけなくて、コーディングエージェントに対して「お前なにもやってないやん」というお気持ちになってくる
これを解決するにはどうしたらいい？
Geminiの回答
そのお気持ち、痛いほどわかります。「AIに任せる」と言いつつ、結局詳細設計から変数名の案出し、エラーの修正方針まで全部人間が指示している状態だと、「これ、自分で書いたほうが早くない？」という虚無感に襲われますよね。
決してあなたが「駄目な人間」になったわけではありません。むしろ、AIに対する期待値と、現在のAI（のエージェント能力）の実力との間に「キャズム（溝）」があるのが現状です。
「指示待ち人間」ならぬ「指示待ちAI」を、自律的に動く「気の利くパートナー」に変えるための、現実的な解決策をいくつか提案します。
1. 「コンテキストの自動化」を徹底する（ツールの見直し）
もし、チャット欄に毎回コードをコピペしたり、状況を一から説明しているなら、そこが疲弊の原因です。「何も言わなくてもプロジェクト全体を把握している状態」を作れるツールに切り替えるのが特効薬です。
- Cursor (Composer機能) / Windsurf (Cascade機能):
これらは現在、最も「自律的」に近いエディタです。特に「Composer (Agentモード)」や「Cascade」は、複数のファイルをまたいで勝手に修正箇所を探し、書き換え、ターミナルでコマンドを実行してエラーが出たら自分で修正する、というループを回そうとします。 - 解決策: 既に使っている場合は、
Cmd+K（単発指示）ではなく、Cmd+I（Composer/Agent）を使い、「この機能を追加して。関連するファイルも全部修正して」と投げてみてください。 -
Cline (旧 Roo Code) + Claude 3.5 Sonnet:
VS Code拡張機能です。ターミナル操作権限とファイル読み書き権限を与えることで、かなり自律的に動きます。「テストが通るまで修正を繰り返して」といった指示が可能です。
2. 「指示のテンプレート化」で毎回言わない (.cursorrules / .clinerules)
「TypeScriptで書いて」「エラーハンドリングはこうして」「ライブラリはこれを使って」と毎回言うのは疲れます。これをプロジェクトごとの「憲法（ルールファイル）」として保存しましょう。
.cursorrulesや.clinerulesをルートに置く:
ここに、「お前は何者か」「技術スタック」「コーディング規約」「禁止事項」を書いておきます。- 例: 「あなたは熟練のReactエンジニアです。常にFunctional Componentを使ってください。CSSはTailwindのみを使用します。コードを変更する際は、既存の構造を壊さないように注意し、必ず日本語でコメントを残してください。」
-
効果: これがあるだけで、指示は「〇〇機能を追加して」という一言だけで済むようになり、「いつものアレ」を言わなくて済む分、徒労感が減ります。
3. 「実装」ではなく「要件」で会話する（プロンプトの抽象度を上げる）
「ここのif文を直して」というHow（どうやるか）の指示は人間に負荷がかかります。What（何を実現したいか）とWhy（なぜやるか）だけを伝えて、HowをAIに考えさせるスタイルに変えます。
- SPECファイル駆動開発:
- まずAIに「これから作る機能の仕様書（SPEC）をマークダウンで書いて」と指示します。
- 人間はその仕様書だけをレビューし、「ここはこうして」と修正指示を出します（日本語での会話でOK）。
- 仕様が固まったら、「このSPEC通りに実装して。テストも書いて」と投げます。
- メリット: コーディングの細部（変数名やループの書き方）をレビューする必要がなくなり、「監督」としての立ち位置に専念できます。
4. マインドセットの転換：AIは「優秀な新卒」
今のAIエージェントは「シニアエンジニア」ではなく、「コーディング速度は爆速だが、文脈を読むのが苦手な、めちゃくちゃ優秀な新卒」だと思うと腹落ちしやすいです。
- 「あれやっておいて（察して）」は通じません。
- しかし、手順書（ルールファイル）と明確なゴール（要件）さえあれば、人間には不可能な速度で作業します。
- 解決策: 「コードを書かせる」のではなく、「ドラフト（たたき台）を作らせる」ことに徹する。完璧を求めず、80点のものが出てきたら、残りの20点は自分でサッと直すか、ピンポイントで指摘する方が精神衛生上良い場合があります。
まずはここから
もし、特定の技術スタック（例：Next.js + Pythonなど）でお使いであれば、「そのプロジェクト専用の最強の .cursorrules（またはシステムプロンプト）」を一緒に作成しませんか？
普段よく注意してしまうこと（「型をちゃんと書いて」とか「コメント残して」とか）を教えていただければ、それをAIが勝手に守るようなルールセットを作成します。これだけでも「言わなきゃやってくれない」ストレスは激減するはずです。
自分の所感
「要件で会話する」ってのは面白いけど、実際の要件と具体のいったりきたりは今のコーディングエージェントはまだまだな気はする。
「めちゃくちゃ優秀な新卒」という例えは絶妙すぎるが、新卒程度のものに自分1人がつきっきりになっているというのはそれはそれで良いのか？という気はする（自分で開発している以上のスケールがない）。もっとこなせるタスクの量が数時間レベルとかになって、並列的に動かせれば旨味は出るかも。
視座を上げるには
自分の質問
なんかコードを書くということにコスト意識がないんで、目先のつぎはぎのコードを入れて解決するという力技を選ぶという気がします。なんかもっと本質的な解決策に目が向かないんですかね。新卒と同じようなハマり方をしてます
Geminiの回答
まさにおっしゃる通りです。「動けばいい」という判断基準で、平気で技術的負債を積み上げるあの感じ、「視野の狭い新人」そのものですよね。
AI（LLM）の本質として、確率的に「その文脈で最もありそうな次のトークン」を選んでいるだけなので、放っておくと「既存のコードをなるべく壊さずに、最小の変更で辻褄を合わせる（＝つぎはぎ）」という、局所最適解（Local Minima）に陥りやすい性質があります。
「全体最適」や「保守性（コスト意識）」を持たせるには、プロンプトで強制的に「視座」を引き上げる必要があります。つぎはぎコードを防ぎ、本質的な解決に向かわせるための具体的なアプローチをいくつか挙げます。
1. 「松竹梅」で提案させる（思考の強制分離）
いきなりコードを書かせると、AIは「一番楽な方法（つぎはぎ）」を選びます。コードを書かせる前に、必ず設計方針の選択肢を出させてください。
プロンプト例:
「このエラー/課題を解決したいのですが、すぐにコードを書かないでください。まず以下の3つのアプローチを検討し、それぞれのメリット・デメリット（特に将来的な保守性と技術的負債の観点）を比較してください。
1. 対症療法案: とりあえず動くようにする最小限の修正（つぎはぎ）
2. 標準案: 一般的なベストプラクティスに沿った修正
3. 抜本的解決案: アーキテクチャを見直し、根本原因を取り除くリファクタリングを含む修正私がどの方針で行くか決定した後に、コードを実装してください。」
これを投げると、AI自身に「つぎはぎは良くないことだ」と自覚させることができ、3番目の案を選んだ時に非常に質の高いコードが出てきます。
2. 「シニアアーキテクト」のペルソナと「禁止事項」を与える
「プログラマー」として振る舞わせると実装の詳細に埋没します。「レビュワー」や「アーキテクト」の視点を持たせて、「つぎはぎ」を明示的に禁止します。
プロンプト例:
「あなたは厳格なシニアアーキテクトです。これからコードを修正しますが、『既存のコードにif文を追加して逃げる』ようなアドホックな対応は禁止します。
多少コード量が増えたり、既存の構造を変更することになっても構わないので、『半年後に他人が見ても理解でき、拡張しやすい設計（SOLID原則）』に基づいて根本的な解決策を提示してください。」
3. 「リファクタリングの先払い」を指示する
つぎはぎになる原因の多くは、既存のコードが既に複雑で、AIが「ここを触りたくない（触ると壊れそう）」と判断して迂回するからです。
プロンプト例:
「機能を追加する前に、この周辺のコードが少しスパゲッティになっています。まず、機能追加をしやすくするために必要なリファクタリングを行ってください。機能の実装はその次に行います。」
人間でもやる「準備（整地）」をAIに先にやらせることで、結果として綺麗なコードが入ります。
4. Why（根本原因）を深掘りさせる
エラーログだけを渡すと、AIはエラーメッセージを消すためだけのコードを書きます。
プロンプト例:
「このエラーが発生していますが、表面的な修正ではなく、なぜこの設計でこのエラーが起きるのか、アーキテクチャ上の欠陥（Root Cause）を指摘してください。」
まとめ
AIは放っておくと「短期的なコスト（修正の手間）」を最小化しようとします。
ユーザー側が「長期的なコスト（保守・運用の手間）」を重視していることを、毎回しつこいくらいに伝えないと、彼らはすぐに楽な方（つぎはぎ）へ流れます。
まずは「コードを書くな、設計を語れ（松竹梅で出せ）」という指示出しから始めてみてください。これだけで「お前、ちゃんと分かってるじゃん」という回答が返ってくる確率がグッと上がります。
自分の所感
「松竹梅で出せ」や「リファクタリングの先払い」はなるほどと思ってしまった。これは確かに通用しそう
これってテックリードあたりの人間が無意識にやってる思考法を、それより弱い現状のコーディングエージェントにプロンプトで意識的に強制させてるって感じなんだろうけど、現状それ以上のいい方法がないんだろうね。
この内容をChatGPTに話してみる
これを記事にしてChatGPT（GPT 5.2 Thinking）に議論させてみる
狙いは「AIを指示待ち新卒から、設計で動く擬似テックリード」に近づけることだと思うので、①現状の限界がどこから来るか、②効くプロンプト枠組み、③運用（分業・評価・自動化）まで含めて議論の形に整理します。
あなたの文章、かなり本質を突いていて、議論すると論点が大きく3つに分かれます。
- 「指示待ち新卒」比喩は正しいのか（どこが限界の原因か）
- 「つぎはぎ」を避けて視座を上げさせるプロンプトは“原理的に”効くのか
- 結局、人間が疲弊しない運用設計はどうあるべきか（プロンプトだけで足りるのか）
以下、その順でいきます。
1) 「優秀だが指示待ちの新卒」比喩、ほぼ正しい。でも“正しすぎて”罠もある
正しい点
- 局所最適に落ちやすい：LLMは「今ある文脈を壊さず最小差分で整合させる」方向に寄りがち。結果「if足して逃げる」「例外握りつぶす」「一時的なフラグ追加」みたいな“負債の増築”が出やすい。
- タスクの地平（horizon）が短い：数十分〜1時間くらいで破綻しやすいのは、記憶/注意の制約だけじゃなく、途中で評価関数（何が良い解か）がブレるのが原因になりやすい。
ただ、この比喩の“罠”
「新卒なら育てれば戦力になる」けど、今のエージェントは育成しても人格が固定されない（コンテキストが切れる、別スレだと別人、ルールが抜ける）。
だから、理想は“育成”というより “環境側で強制する” です。
- ルールファイル
- 進め方（ゲート）
- 成果物形式
- 評価（テスト・静的解析・レビュー観点）
つまり「新人教育」ではなく「プロセス設計」の話に寄せるのが筋がいい。
2) 「松竹梅」「リファクタ先払い」は効く。なぜ効くか＝“探索”を強制できるから
あなたの感想どおり、あれはテックリードが無意識にやってる思考の外部化で、効きます。理由はシンプルで、
- いきなり実装させる → 探索せずに最短でそれっぽい解へジャンプ（つぎはぎ）
- 先に案出しさせる → 探索フェーズが挿入され、解空間の比較が起きる
これ、プロンプトの小技じゃなくて「プロセスを2段に分ける」ことが本質です。
ただし注意点もあって、松竹梅をやると“それっぽい比較表”だけ上手くなる危険があります。
なので、比較の質を上げるには、松竹梅に採点軸を固定してしまうのが強いです。
たとえば軸をこれに固定すると、急に“負債っぽさ”を検出しやすくなります。
- 変更影響範囲（blast radius）
- 将来の拡張点の数（拡張容易性）
- 一貫性（既存の設計原則に沿うか）
- テスト容易性（単体で検証できるか）
- 可観測性（ログ・メトリクスの置き場所が自然か）
3) いちばん効くのは「擬似テックリード化」じゃなくて「役割分離」：設計役と実装役を分ける
人間社会でも、同じ人が「設計レビューの目」と「実装の手」を同時にやると崩れます。
LLMはなおさらで、実装に入った瞬間に視野が狭くなる。
だからおすすめは、1体に“テックリード視座”を強制するより、工程を分割して別ロールで回すことです（同一モデルでロールを切り替えるだけでも効果が出ます）。
- ロールA：アーキテクト（設計・方針・リスク・移行計画）
- ロールB：実装者（差分最小ではなく、合意した方針に忠実に実装）
- ロールC：レビュワー（負債検知・逸脱検知・テスト妥当性）
この3者分離を、プロンプトで“儀式化”すると疲弊が減ります。
人間が張り付く場所が「Aの承認」だけになるからです。
具体的に：テックリード視座を“強制する”プロンプト戦略（テンプレ）
ここからは実務でそのまま使える形でまとめます。
戦略0：必ず「設計→合意→実装→レビュー」のゲートを作る
「コードを書くな」だけだと破られるので、成果物を指定します。
ゲート成果物（軽量版）
- 仕様（SPEC）：何を・なぜ・非目標・受け入れ条件
- 設計（ADRミニ）：選択肢/決定/理由/トレードオフ
- 実装計画：変更ファイル一覧、移行手順、テスト方針
- 実装PR：差分
- レビュー：負債チェック結果
この型にすると、エージェントが「つぎはぎで早く終わらせる」誘惑に抗いやすいです。
戦略1：「松竹梅」プロンプトの“強化版”（採点軸固定 + 失敗条件）
そのまま使える文面：
- 指示
- すぐにコードを書かない
- 3案（対症/標準/抜本）
- 各案を採点（5軸×10点）
- 「半年後の変更要求」を1つ想定して、どの案が苦しむかを書く
- 最後に推奨案を1つに絞る（理由はトレードオフ込み）
これだけで、“比較表芸”から一歩出ます。
未来の変更要求を入れるのがコツで、ここでつぎはぎ案が脆いのが露呈しやすい。
戦略2：「リファクタ先払い」を“条件付き”にする（闇雲な大改造を防ぐ）
リファクタ先払いは強い一方、AIが気持ちよく大改造しがちなので、上限（予算）を与えるのが安定します。
- 例
- 「リファクタは最大200行の差分まで」
- 「公開APIの互換性は維持」
- 「移行は段階的、フラグで切替可能に」
- 「テストが先、挙動を固定してから構造を変える」
これで「綺麗にするために壊す」を抑えつつ、“整地”だけ先に進められます。
戦略3：つぎはぎを“禁止”するより、「禁止パターン一覧」を渡すのが効く
抽象的に「つぎはぎ禁止」だと抜け道を探します。
プロジェクトでよく起きる負債パターンを列挙しておくと、回避率が上がります。
- 例（禁止/要相談）
- 「既存の分岐に if を足して例外ケースを吸収」
- 「グローバルフラグ追加」
- 「try/except で握りつぶす」
- 「型をanyに逃がす」
- 「関数引数を増やして辻褄を合わせる（依存注入なし）」
- 「呼び出し順依存の副作用を増やす」
これを .cursorrules / .clinerules 的な“憲法”に入れるのはかなり実利があります。
戦略4：「レビュー観点」を先に渡してから実装させる（試験に出る範囲方式）
人間でも「レビューでそこ見るよ」と言われたらそこを整える。AIも同じです。
- 実装前に渡すレビュー観点例
- 変更影響範囲が局所化されているか
- データの流れが一方向か
- 境界（API/DB/外部I/O）が抽象化されているか
- テストが“ふるまい”を固定しているか
- ログ/例外が運用できる形か
実装前にこれを渡すのがポイントで、実装後レビューより効率が良いです。
「結局つきっきり問題」への結論：プロンプトで“自律性”を上げるより、あなたの介入点を減らす
あなたが言ってる「新卒に自分1人が張り付くの良いのか？」は正しくて、解はこうです。
- 自律性を上げる（AIを賢くする）
ではなく - 介入点を“設計承認”の一点に集約する（プロセスを賢くする）
この形にすると、タスクが数時間以上になっても破綻しにくいし、並列化もできます。
（例：Aが設計案を3つ出している間に、別スレでBがテスト方針を固める、みたいな分業が可能）
逆張りの論点も置いておく：つぎはぎが“正解”の局面もある
議論としてフェアに言うと、「つぎはぎ＝悪」でもないです。
- 緊急障害対応（MTTR最優先）
- プロダクト検証フェーズ（捨てコード前提）
- 仕様がまだ揺れている（設計にコストを掛けると損）
なので実務では、「今はどの局面か」を最初に宣言させるのが強いです。
- “今回は捨てコード。対症療法OK”
- “今回は半年持たせる。負債最小化”
- “今回は将来の拡張が確定。抜本案優先”
これを冒頭で固定すると、AIのブレも減ります。
まとめ：あなたの整理は正しくて、次の一手は「強制フォーマット化」と「役割分離」
- 「松竹梅」「リファクタ先払い」は、テックリードの思考法を工程として外付けしてるから効く
- ただし“比較表芸”や“大改造”に流れる副作用があるので、採点軸固定と差分予算が必要
- いちばん効くのは、AIをテックリードに育てることより、設計役/実装役/レビュー役に分けて、あなたの介入点を設計承認に寄せること
もしよければ、あなたの普段の開発スタック（例：TypeScript/Next/Python、Terraform多め等）前提で、
- ルールファイル（憲法）雛形
- 松竹梅プロンプト（採点軸入り）
- ADRミニテンプレ
- レビュー観点チェックリスト
を“コピペ運用できる形”で1セットにして出します。
Shikoan's ML Blogの中の人が運営しているサークル「じゅ～しぃ～すくりぷと」の本のご案内
技術書コーナー
北海道の駅巡りコーナー