「planモード」という名の足枷
深夜2時、終わらないデバッグ作業の中で、AIエージェントの「planモード」に裏切られた経験はないだろうか。我々エンジニアがAIに期待するのは、単なるコードの生成ではない。複雑な依存関係が絡み合うスパゲッティコードの海を泳ぎ切り、アーキテクチャの整合性を保ちながら、最短距離でゴールに到達する「知的なパートナー」としての振る舞いだ。しかし、Claude Codeの初期から実装されていた「planモード」は、皮肉にもその知性を封じ込めるガードレールとして機能してしまっていた。
planモードの設計思想は、人間がAIの暴走を制御し、調査と実装を分離させるという、いわば「ウォーターフォール的な安全策」に基づいている。しかし、このアプローチは現代のLLMの進化速度を完全に過小評価していると言わざるを得ない。Anthropicが提唱する「Context Engineering」の新しいルールにもある通り、モデルが賢くなればなるほど、システムプロンプトでガチガチに振る舞いを規定することは、モデルの柔軟な推論能力を阻害するノイズに他ならない。我々がかつて必要だと思っていた「停止点」や「調査の強制」は、今やAIのポテンシャルを削ぐ足枷であり、モデルの賢さをスケールさせないためのボトルネックとなっているのだ。
実際に、NOT A HOTELのエンジニアリングチームが指摘するように、今のモデルは「全部良い感じにやってくれる」という前提で接する方が、結果として高いパフォーマンスを引き出せる。かつて我々が必死に書いた詳細な指示書や、厳格なステップバイステップのプロンプトは、もはやAIの「創造的な飛躍」を妨げるレガシーコードのようなものだ。技術の進化は、我々が「AIをどう管理するか」という問いから、「AIとどう対話するか」という問いへの転換を強制している。このパラダイムシフトを理解できないエンジニアは、今後、AIという強力な武器を手にしながら、その性能の10%も引き出せないまま、旧態依然とした開発手法に固執することになるだろう。
「案をください」という対話の革命
では、planモードを捨てた後に我々が取るべき最適解とは何か。その答えは極めてシンプルで、かつ人間味に溢れている。「案をください」という、極めて抽象的でありながら、AIの文脈理解能力を最大限に引き出す命令だ。これは単なる代替手段ではない。AIとの関係性を「命令と実行」から「議論と合意」へと昇華させる、Human-in-the-Loopの究極形である。
従来のplanモードが抱えていた最大の敗北は、AIが人間には理解不能な膨大な調査結果を一方的に出力し、人間がそれを「脳死で承認」してしまうという、形骸化したプロセスにあった。これは、コードレビューを形だけ通して、中身を理解せずにマージするのと何ら変わらない。これに対し、「案をください」というアプローチは、AIと人間が同じコンテキストを共有しながら、必要に応じて「(1)のロジックはなぜその実装なのか?」「この依存関係は将来的にデッドロックを招かないか?」といった対話を重ねることを可能にする。この往復こそが、AIを単なるツールから「チームの一員」へと変貌させる鍵だ。
以下の表は、従来のplanモードと、現代的な「対話型アプローチ」の決定的な違いを整理したものだ。我々が目指すべきは、AIの出力を鵜呑みにすることではなく、AIの推論プロセスを我々の認知の範囲内に引き込み、共に最適解を導き出すことにある。
| 比較項目 | planモード(旧来型) | 「案をください」メソッド(現代型) |
|---|---|---|
| 主導権 | AIの規定されたプロセス | 人間の意図とAIの推論の融合 |
| 介入のタイミング | 固定された停止点のみ | いつでも、何度でも可能 |
| 認知負荷 | 膨大な調査結果の精査 | 対話を通じた段階的な理解 |
| モデルの活用 | 制約による抑制 | 柔軟な対応による最大化 |
この手法の真の価値は、AIが早口で長文を吐き出す現代のモデルに対しても、人間側が「平たく説明して」と介入することで、情報の解像度をコントロールできる点にある。これは、シニアエンジニアがジュニアエンジニアを指導する際のメンタリングに近い。AIを「道具」として扱うのではなく、共にコードを書き、共に設計を議論する「パートナー」として扱う。この意識変革こそが、これからのAIネイティブな開発現場において、圧倒的な生産性の差を生むことになるはずだ。
エンジニアに突きつけられた問い
ここまで、Claude Codeにおけるplanモードの無効化と、対話型アプローチへの移行について論じてきた。しかし、我々エンジニアが真に直面している課題は、ツールやプロンプトのテクニック論ではない。それは、「AIが賢くなった世界で、我々人間のエンジニアの付加価値はどこにあるのか」という、極めて本質的で残酷な問いである。
もし、AIが「案」を出し、実装し、テストまで完遂できるようになったとき、我々がコードを書く時間は激減する。その空いた時間で、我々は一体何をすべきなのか。答えは明確だ。それは「問いを立てる力」と「コンテキストを定義する力」である。AIは答えを出すことには長けているが、何がビジネス上の真の課題であり、どの技術的負債を優先的に返済すべきかという「優先順位の決定」は、依然として人間にしかできない聖域だ。AIに「案をください」と投げかけるためには、まず我々自身が「何を解決したいのか」という明確なビジョンを持っていなければならない。
明日から、皆さんの開発現場で以下のことを実践してほしい。まず、AIを「自動化ツール」として使うのをやめ、隣に座っている優秀なペアプログラマーとして扱うこと。そして、AIの出力に違和感を覚えたら、即座に「なぜその判断をしたのか」と問い詰めること。AIの回答を鵜呑みにするのではなく、AIの推論プロセスを自分の脳内で再構築し、納得できるまで議論を尽くすこと。この「対話の質」こそが、これからのエンジニアの市場価値を決定づける。
最後に、自らに問いかけてみてほしい。あなたはAIに「作業」をさせているのか、それともAIと「共創」しているのか。もし、AIの出力結果をただコピー&ペーストしているだけなら、それはエンジニアリングではなく、単なる「AIのオペレーター」に過ぎない。技術の進化は、我々から「コードを書く作業」を奪うかもしれないが、それと引き換えに「より高度な設計と意思決定」という、エンジニアの本質的な役割を突きつけている。この変化を恐れるか、あるいは武器として使いこなすか。その選択が、あなたのエンジニアとしてのキャリアの寿命を決めることになるだろう。


コメント