プランモードは終了しました

それに、計画や決定の監査トレイルを残すこともできない（デフォルトではね）。私のプロンプトのほとんどは、「変更Xのための計画を提案してファイルYに書き込む」とか、「ファイルYからステップM-Nを実行する」みたいな感じ。この記事についてだけど、このプロセスがなぜフォローする価値があるのかは、時間と注意を無駄にして初めてわかると思う。会話形式での構築は、無駄に向かう特急列車みたいだよ。何を作りたいのか理解してないなら、Claudeと話す意味がわからないな。

誤用の可能性が低くなったからって、サンドボックス対策を実装しないのは賢明じゃないと思う。

それに同意するよ。プランモードは、以前のモデルが自由すぎて好き勝手にやってたから生まれたんだ。今のモデルは指示に従うのが上手くなったから、別のモードは必要なくなった。でも、実行よりも計画のために別の賢いモデルを使う価値はまだあるし、完了時に監査のために残しておくのもいいと思う。もしプランモードを使うなら、https://plannotator.ai/ がいいかも。私は通常、デフォルトモデルと会話して計画を正しい方向に向けさせてから、賢いレビュアーと一緒に反復して欠陥を見つけるんだ。

これは役に立つよ。モデルが実装する前に、どんな決定を下すかを見ることができるから。モデルは今は賢くなったけど、私の意図を間違って推測したら、アンダースペシフィケーションの問題は解決しないんだよね。

こんにちは、投稿の作者です。基本的には、私が言いたいのはこの違いです。歴史的に見ると、プランモードは2つの役割を果たしてきました。1つ目は、エージェントの指示を実行できるくらい具体的にすること。2つ目は、人間が何が起こるかを理解する手助けをすることです。エージェントが進化するにつれて、#1はあまり必要なくなってきていると思います。#2は逆に重要度が増してきていて、モデルがより多くのことを自分でできるようになると、より複雑な作業が増えてきます。私が考えを変えたのは#2のインターフェースについてです。私は、インタラクティブで反復的なワークフローの方が、人々が実際に理解を深める方法に近いと思うようになりました。特に、自分が作成していない長い生成文書を渡されるよりも。人間の理解の問題は本当に深刻ですけどね。

プランモードの初期バージョンでは、承認するとチャット履歴が消えて、新しいセッションの始まりとしてプランが提示されていた。あれが懐かしいな。すごくうまく機能していて、文脈がきれいに保たれていた。

これはしばらくうまくいっていたけど、数ヶ月前に初期バージョンのFableを使っているとき、プランモードを使わなくなったことに気づいた。モデルが理解してくれるようになったからだし、ますます複雑な作業を頼むと、計画がインタラクティブで反復的になったから。Opus 5.5では、Opusもその段階に達したと感じている。私にとっては逆で、Claude Codeのプランモードはほとんど不十分だ。個人的には、Claudeにプランを書いたマークダウンファイルを作成させて、それをplannotatorでレビューして、行ったり来たりする（大抵はコメントが問題で、コードじゃない）。それから新しいセッションを始めて、プランを元に種をまいて、Claudeに曖昧さや摩擦点、見落としを見つけさせて、それを解決してから実装する。再度plannotatorでレビューして、行ったり来たりしてからPRを送る。かつて想像された「バイブコーディング」ではないかもしれないけど、これでコードとアーキテクチャ、品質を完全に把握できるし、長期的な劣化も防げる。

モデルが理解しているという主張には反対だね。最近Fable 5.1で試した実例を紹介するよ。「証明書を使ってリモートシステムとの安全な通信を確立するためのGo関数を書いて。短く、単一の関数にして、使い方を説明して。」ってプロンプトを与えたんだ。出力は、どこにも要件として指定されていないのに、ファイルに保存された秘密鍵を使うことを強制してきた。Claudeが書いた関数は、秘密鍵ファイルの引数を取って、秘密鍵ファイルが必要なGolangの関数（tls.LoadX509KeyPair）を呼び出すんだけど、GoにはHSMやKMSのような他の形態の秘密鍵をサポートできるcrypto.Signerがあるのにね。「理解している」人（セキュリティにある程度経験がある人）は、これが機能するために秘密鍵の材料を必要としない選択をするはずだと思う。ちなみに、これはClaudeに特有のことじゃないよ。ChatGPTやGeminiも同じことをするけど、それぞれに独自の癖がある。ChatGPTは、サーバー認証のためにCAファイルも受け入れる唯一のものだったから、追加点をもらったよ。誤解しないでほしいけど、LLMはソフトウェア開発の未来（もしかしたら現在）だけど、完全に手放しで使えるようになるにはまだ道のりがあると思う。デザインを修正しなきゃいけないことがあるし、プランモードはその助けになってくれる。もちろん、Claudeの仕事に感謝してるよ。 :)

プランモードは、コードベースのメンタルモデルを更新しやすくしてくれるし、必要な変更のメンタルオーバーヘッドが本当にやる価値があるのかを判断するのにも役立つ。これが今、一番の制約要因になってるんだ（コードの差分を読むのはもうスケールしないからね）。

プランモードは役に立っていたけど、今は役に立たない。 > Claude Codeでは、プランモードは「プランモードにいるので、まだコーディングしないでください」というちょっとしたリマインダーをユーザーメッセージに追加するだけだよ。プランモードが役に立たないというのは、Claude Codeの実装が不足しているからだと思わざるを得ない。仮にそうだとしても、他のハーネスではプランモードがワークフローを安定させるのに役立っているよ。実際にコードを合成するのはプロセスの一部に過ぎなくて、ワークアイテムをエンドツーエンドでプロダクションに持っていくには多くのことが関わっているし、プランモードはこの流れに構造を与えてくれる。それ以上に、変更をコミットする前に再集結する機会でもあるんだ。プロセスを持続可能でスムーズなリズムに遅くすることで、結果的にプロセスを加速させるんだ。だから、Claudeのプランモードがコードの回転を早めるために設計されている一方で、例えばOh My Piのように戦略的に設計されているなら、ここでの認識の違いが説明できるかもしれない。無理に使う必要はないけど、このモードをループから切り離すつもりなら、可能性のある副作用に注意してね。