Claude code（Sonnet 4）雑感6：コンテキストクリアを恐れない方が良い

仕様を先に校正して貰う仕様駆動開発ベースで続けてたやつの後日談。まだ当初の目的はクリアしてないのだけど、一つ大きな山を乗り越えつつあるぐらいにはなってきました。

現時点で10万行ぐらい。ただしこれにはかなり無駄なコードが多く、その多くは雑感1で書いた「ハードコーディング」「場当たり的処理」でスパゲッティコードになっています。同じ処理を際実装し直すのもかなり多い。必要なデータ取得できなかった場合のフォールバック処理書いてくることも多く、あれこれ組み合わさった結果として何が悪さしてるのか分からん状態に。自動編集許可しまくりでどこまでいけるか試してみたんだけど、ダメダメな結果に。指示不足も合ったと思うけども。

そんなこんなでここ数週間は延々とリファクタリングしてました。最初はそれ自体もClaude code任せで「出力のここがおかしい、要因特定して修正考えて」みたいにやってたんですが、これではダメ。既にスパゲッティコードになってる状態ではデバッグ用print埋め込もうが「それに辿り着かない」みたいな状況が多発しまくってて要因特定自体ができないという。それでも意図的に限界確認するついでだと割り切って試してたら

⏺ Phase 20.7.28.26が完了し、現在はPhase 20.7.28.27として完全なシミュレーション実行を監視しています。

みたいな状態に。どこまでフェーズ続いてるんだよって感じですが。気にせず同一セッション続けてると、最終的には「実行してないのに実行したかのように振る舞う」「存在しないファイルがあるかのように振る舞う」「編集していないのに編集したかのように振る舞う」ような挙動するようになりました。限界。

改めてセッション立ち上げ直し、現状を整理して報告し、ハードコーディングやらフォールバック箇所を虱潰しに潰していくこと数日。今回は編集意図が理解できない場合には説明させたりもしつつ、編集案を毎回チェックするようにしました。その結果どうにかスッキリしてきて、一定の動作をするようにはなってきました。セッション立ち上げ直しでコンテキストリセットするの大事ですね。素直に /clear するなりしろという話なんだろうけど、目処付く前にリセットしたくなかったのと、どこまでやれるかを体感したかったから仕方ない。

それにしても「場当たり的な修正を見抜くような力」って、どうやって教えたら良いんだろう。そのうちそれも気にしなくて良くなるのかもしれないけども。

P.S. 今のプロジェクトはそのまま続ける予定だけど、別途予定してる新規プロジェクトではKiroの仕様書駆動開発プロセスをClaude Codeで徹底的に再現したを試してみたい。

• 場当たり的な修正ではなく根本的な要因を探り、報告してください。
• 修正方針は処理ロジックのシンプルさとFail-Fastを優先します。
• （擬似コードを書いて）このぐらいとてもシンプルなロジックで実現できると思うのですが、何故要因を特定できないのでしょうか。現状の処理ロジックを調査し、報告してください。
• 時刻指定のデバッグ出力はシナリオを生成し直す度に修正することになりそうです。単純に時刻をハードコーディングするのでは無く、シナリオから読み出す形にしてはどうですか。また、デバッグ出力はデバッグ出力用フラグを指定したときのみ出力するようにしてはどうですか。