@podhmoのXスレッドを読んでいて、面白い指摘を見つけた。Claude Codeの使い方を Claude自身に聞こうとすると、必然的にカットオフ後の知識が必要な質問になる。 つまり実質的にweb_searchとweb_fetchの性能を求めることになり、 ノイズの多いWeb検索の品質に依存してしまう。
カットオフ前の知識については適切な入力を工夫すれば良い結果が得られやすい。 ただし一度きりの雑な確認ならWeb検索で十分、という使い分けもある。
ヘルプドキュメントが同梱されてアップデートのたびに更新される仕組みとして、 Claude CodeにはHaikuで動くsub agentが用意されているらしい。 参考: https://code.claude.com/docs/en/sub-agents#other
Claude Codeの習得が他のツールと違う理由として、学習対象が確率的なシステムだという点がある。
従来のツールは「このコマンドを打てばこうなる」と正解が一意に決まる。 Claude Codeは「このプロンプトを打てばだいたいこうなる」であり、正解が分布になっている。
このことが見落とされて、ほとんどのレクチャーがハッピーパスの紹介になってしまいがち。
「こう書けばうまくいく」より「こう書くとこう失敗する」のほうが記憶に残り、 判断力が育つ。意図的に失敗する課題を設計するのが効きやすい。
混ぜて教えると何が効いたかわからなくなる：
- プロンプト設計（何を、どう言うか）
- コンテキスト管理（Claudeが何を知っている状態か）
- タスク分解（何を頼むか）
並列実行の前に「何をもって成功とするか」を言語化させる。 テストが通るか、変更行数が少ないか、修正回数が少ないかなど。 これなしの試行錯誤は印象論になってしまう。
正解が明確なタスク（自分が答えを知っている） ↓ 機械的に検証できるタスク（テストが通る） ↓ 判断が必要なタスク（コードレビューが必要）
この順序を崩さないのが大切らしい。
Claudeへの指示書としてではなく、「自分がこのプロジェクトで学んだこと」の記録として 書く習慣をつけると、次のランのスタートラインが上がる。
うまくいったとき、それがなぜうまくいったかを説明できなければ再現性がない。 「今のプロンプトのどの部分が効いたと思うか」を問い返す習慣が、 試行錯誤を本物の経験値に変える。
@podhmoのスレッドで出てきた比喩が的確だった。Claude Codeの習熟はローグライトゲームに似ている。
- 毎回少し違うランになる：同じタスクでもプロンプトの微差、プロジェクトの状況、 セッションの状態が変わると出力の質や失敗パターンが大きく変わる
- 死（失敗）から学ぶ：/clearでリセットして改善したプロンプトで再挑戦
- ビルド（進行）：成功したパターンをCLAUDE.mdや自作Sub Agentに積み上げていく
- 多様な敵（状況）：さまざまなタスク種別で同じパターンを試すことで汎用的な勘所が育つ
- 並列プレイ：複数のセッションを並列で走らせて差分を比較する
「ベストプラクティスに書かれたプロンプトを手に入れること」と 「そのプロンプトが機能すること」の間には溝がある。
この溝を埋めるのに有効なのが、差分を用意した並列実行。 複数のプロンプト変種を用意して並列実行し、出力の分散を見る。
- 差分が小さい（どの変種でも似た良い結果）→ そのパターンは安定して機能する
- 差分が大きい（ばらつき大）→ プロンプトのロバスト性が低い
単一セッションでの反復修正とは本質的に違うアプローチで、 文脈汚染を避けながら複数の仮説を同時に検証できる。
実際に使っているプロンプトの例：
現状の状態を把握したい
- 今回何をしたか教えて
- どのようなアクシデントに遭遇したのか教えて
- どのような見込み違いに遭遇したのか教えて
- どのような知識を把握したのか教えて（次回のプロンプトのために）
- 残りのタスクを教えて（TODO.mdを見る必要はない。現在抱えてるものすべて）
「何をしたか」と「何が起きたか」を分けているのがポイント。 さらにアクシデントと見込み違いを分けているのも有効で：
- アクシデント：外部要因、環境、予測不能なこと
- 見込み違い：自分の前提・モデルが間違っていたこと
この2つは原因が違うので、次のランへの対処が変わる。
「次回のプロンプトのために」という一言も効いている。 知識の記録を今回の振り返りではなく次回の入力として位置づけている。
プロンプト自体の評価は意図的に省いている。 モデルにプロンプトを評価させると、その評価から事後的に判断しがちになるため。 真の評価対象は生成されたコードと結果。
日報の出力をもとにCLAUDE.mdを更新する作業を自動化したい、 CIのように回したいという感覚は自然だが、詰まる部分がある。
プロンプト改善のループが自動化しにくい理由は、評価関数が言語的だから。 コードのテストは機械的に通過/失敗が出る。 「このプロンプトが良かったか」の判断は、今のところ人間の目が必要になる。
現実的な半自動化の方向としては、日報の出力をもとにCLAUDE.mdへの差分を 提案させて人間が承認するだけにする、という摩擦の削減がある。
別モデルにチェック項目で判定させる設計も使えそうで、 同じモデルに自己評価させると甘くなるため、 HaikuあたりにSonnetの出力を採点させる非対称な構造が効きやすい。
チェック項目の設計が鍵になり、機能しやすい条件として：
- yes/noで答えられる
- 判定者が結果を見るだけで答えられる（文脈依存しない）
- タスク種別に依存しない汎用項目とプロジェクト固有項目を分ける
複数エポック回すとCLAUDE.mdが肥大化していく。 「追加するより整理する」フェーズが必要になり、それ自体もエポックの一種として 設計に組み込めると綺麗かもしれない。
モデルの出力を直通させると、意味は正しくても粒度と量が人間の管理単位を超える。 結果としてCLAUDE.mdがモデルの文体に侵食されていく。
人間が一行ずつ追加するのは遅く見えて、実際には：
- 追加した理由を自分が覚えている
- 後で「これ何で入れたっけ」が起きない
- CLAUDE.mdが自分の思考の外部化になっている
という意味で、理解を伴った蓄積になっている。
ここに至って最初の話に戻る。
「なぜ機能したかを説明できなければ再現性がない」
チェック項目もCLAUDE.mdも、モデルに生成させると速いが自分の理解が伴わない。 自分で一行追加する遅さの中に、熟達に必要な何かが宿っている。
レクチャーのガイドラインとして言えば、 「自動化できる部分と、あえて手動にすべき部分を区別する」 というのが一つの柱になりそう。
さらにkimiと対話
Click the link to view conversation with Kimi AI Assistant https://www.kimi.com/share/19d9001e-b092-83a3-8000-0000ce34cf01