Kimi | Claude改善策

note-20260415-064933.txt

TXT 6.49 KB

note-20260415-064943.txt

TXT 26.36 KB

note-20260415-070730.txt

TXT 16.08 KB

# 対話履歴 → 技術記事変換プロンプト会話の最初から最後までの対話履歴を、未来の自分向けの技術的な備忘録として出力する。 ## 出力形式 - Markdown で出力する - 太字（`**...**`）は使わない - 文字数制限なし（10,000字超でも可） - 出典 URL はそのままリンクとして残す - 理解を助ける図・表があれば抽出または引用する ## 内容の扱い方 - 要約しない。対話で触れた内容を省略しない - 文脈独立性を保つ（その記事単体で意味が通るように書く） - 対話中に訂正・修正があった場合は、訂正後の内容だけを記述する - 対話の存在を示唆しない ## 文体 - 「であった・である」調ではなく、「〜だった」「〜らしい」「〜と分かった」などの調子で書く - 「〜だった」の連続は気持ち悪いので避ける。 - 重要性・有用性を主張しない。断言を避ける - 発見・確認・気づきの記録として書く - 「勉強になった」みたいな表現は不要。これらを意識してドキュメントを出力してほしい

Claude Code学習戦略と限界

ユーザーは、3つのアップロードされたテキストファイル（Claude Codeに関するXのスレッドの内容を含む）を参照し、これらの対話履歴を「技術的な備忘録」としてMarkdown形式に変換してほしいと依頼しています。

要件を整理すると：

出力形式:
- Markdown形式
- 太字は使用しない（**...** を避ける）
- 文字数制限なし
- URLはそのままリンクとして残す
- 図・表があれば抽出・引用する
内容の扱い方:
- 要約しない、省略しない
- 文脈独立性を保つ（単体で意味が通るように）
- 訂正・修正があった場合は訂正後の内容のみ記述
- 対話の存在を示唆しない（「ユーザーは」「AIは」などの表現を使わない）
文体:
- 「であった・である」調ではなく、「〜だった」「〜らしい」「〜と分かった」など
- 「〜だった」の連続は避ける
- 重要性・有用性を主張しない、断言を避ける
- 発見・確認・気づきの記録として書く
- 「勉強になった」などの表現は不要

内容の構成：

ファイル1（note-20260415-064933.txt）: podhmoさんのXスレッドとGrokによる回答。Claude Codeの学習方法について、特に「ローグライト的練習」について。
ファイル2（note-20260415-064943.txt）: スレッドの要約と、Claude Codeの学習方法に関する詳細な回答（知識の習得と理解の正しさの確認の分け方）。
ファイル3（note-20260415-070730.txt）: 対話履歴。日報プロンプトの設計、学習方法、CI的な自動化の試みなど。

これらを統合して、技術的な備忘録として再構成する必要があります。

ポイント：

「対話の存在を示唆しない」ため、「私は」「あなたは」「ユーザーは」といった表現を避ける
主張ではなく記録として書く
訂正があった部分（並列実行の重要性、反復的改善ではなく差分を見る視点など）は正しい内容に統合する
「〜だった」調を使いつつも、繰り返しを避けるためのバリエーションが必要

構成案：

Claude Codeの学習における根本的課題（確率的システムとしての性質）
効果的な学習アプローチ（ローグライト的練習と並列実行）
プロンプト設計と検証の分離
学習の記録と振り返り（日報プロンプトとCLAUDE.mdの活用）
自動化の限界と手動による判断の価値

これらを自然な流れで記述し、対話形式を排除して記録形式に変換する。

Claude Codeの習熟において、対話型AIの確率的な性質が根本的な学習上の課題となっている。従来の開発ツールと異なり、同じプロンプトでも実行タイミングや文脈により出力が変動するため、「正解がある」というより「分布を理解する」ことに近い熟達が必要とされる。

ベストプラクティスに記載された手法と、実際にそれが機能することの間には溝が存在する。プロンプトが書かれている通りの動作をすることを確認するには、単一セッション内での反復的な改善ではなく、複数のプロンプト変種を並列実行し、その分散を観察するアプローチが有効に見える。これはローグライトゲームに類似した学習パターンで、毎回少し異なる「ラン」を通じて失敗から学び、勝ちパターンを蓄積していく形となる。

Claude Codeの学習を進める上で、以下のような実践的なフレームワークが考えられる。

まず、知識の習得と理解の正しさの確認を分離して考える。公式ドキュメントや体系的なガイド（Zennの本など）で基礎を固めつつ、実際に機能するかどうかの検証は別のループで行う。検証にはClaude Code Guide（Haikuベースのビルトインサブエージェント）を活用する方法や、実際に小さなタスクで試す方法がある。

プロンプトが機能することを確認する具体的な手法として、明確な成功基準（verification criteria）をプロンプトに組み込み、即座に実行して観察する方法がある。例えば「この関数を実装したら、以下のテストケースを実行して結果を報告せよ」といった具合だ。成功すればそのプロンプトパターンは機能していると判断し、予期せぬ動作やハルシネーションがあればプロンプトを調整して再試行する。

並列実行による検証では、同じタスクに対して複数のプロンプト変種を別セッションで同時に走らせ、出力の差分・テスト通過率・速度を比較する。プロンプトA（公式ベストプラクティスそのまま）、プロンプトB（Sub Agentを明示的に並列指定）、プロンプトC（CLAUDE.mdを強く参照）といった具合に差分を用意し、どの変種が最も安定して良好な結果を出すかを観察する。これにより、特定の状況においてどのパターンが強いかという知見が得られる。

学習の記録にはCLAUDE.mdを活用するが、これを単なる設定ファイルではなく「学習ログ」として扱うと良さそうだ。検証して機能したと分かったパターンや、特定の状況での失敗パターンを記録し、次回のスタートラインを上げるための素材として積み上げていく。

また、日報プロンプトを設計して、セッション終了時に以下のような問いを投げかける形も有用に見える。

今回何をしたか
どのようなアクシデントに遭遇したか（外部要因、予測不能なこと）
どのような見込み違いに遭遇したか（自分の前提・モデルが間違っていたこと）
どのような知識を把握したか（次回のプロンプトのために）
残りのタスクは何か

アクシデントと見込み違いを分けることで、原因の特定と次回の対処が明確になる。知識の記録を「今回の振り返り」ではなく「次回の入力」として位置づけることで、確率的なシステムに対する適切な認識が保たれる。

この学習プロンプトの出力をCLAUDE.mdに蓄積する際、人間が一行ずつあるいは1観点ずつ追加して遷移を見る方法が現実的な落とし所のようだ。モデルの出力をそのまま蓄積すると粒度と量が管理単位を超えて肥大化しやすい一方、人間が追加した理由を自分で覚えている状態で一行ずつ追加することで、CLAUDE.mdが自分の思考の外部化として機能する。

完全な自動化（CIのような継続的改善ループ）を望むこともできるが、プロンプト改善の評価関数が言語的で機械的判断が難しいため、現実的には半自動化が妥当に見える。日報の出力を構造化してCLAUDE.mdへの差分として自動提案させ、人間が承認・却下する形で、評価は人間が行いつつ反映の手間を減らす方法がある。

これらを踏まえると、Claude Codeのレクチャーやガイドライン作成においては、成功例より失敗例から始める、3つのスキル（プロンプト設計、コンテキスト管理、タスク分解）を分けて教える、「測定基準を先に決める」を習慣化させる、検証可能な小タスクから段階的に広げる、そして「なぜ機能したか」を説明させることで再現性を高める、といった原則が有効そうだ。

Claude CodeのSub Agents機能（.claude/agents/のMarkdownエージェントやbuilt-inのExplore・Claude Code Guideなど）については、Haikuを指定して高速・低コストでread-onlyタスクを任せるパターンや、並列検証に活用する方法が考えられる。Sub Agentsのドキュメントは https://code.claude.com/docs/en/sub-agents#other で確認できる。

あなたならさらにどのようなアドバイスをしますか？

ユーザーは、すでにClaude Codeの習熟について深い洞察を持っている（メモリから、多層的な文書構造を好み、専門用語を使った圧縮層を土台にしたいという志向が読み取れる）。現在の対話で触れた「並列実行による分散観察」「ローグライト的学習」「日報プロンプト」「CLAUDE.mdへの一行ずつの蓄積」などは、すでにかなり洗練された方法論だ。

「あなたならさらにどのようなアドバイスをしますか」という問いに対して、単に一般的なベストプラクティスを並べるのは不誠実。ユーザーの既存のアプローチを拡張・深化させるような、よりメタな視点や、まだ言語化されていない可能性のある「次の段階」を提示すべきだ。

考えるべき方向性：

「並列実行」のコストと認知負荷の問題
- 並列は良いが、比較対象が増えると人間の認知がボトルネックになる
- 「何を見るか」の選択的注意力の設計が必要
CLAUDE.mdの「圧縮層」としての進化
- 現在は「学習ログ」として使っているが、記憶の圧縮率を高める構造が考えられる
- 専門用語やパターン言語の導入
セッション間の「状態」の問題
- ローグライトで言う「ビルド」の持ち越し方
- CLAUDE.md以外に、セッションを跨いで保持すべき「状態」とは何か
評価の「相対化」
- 絶対的な良し悪しではなく、自分の過去のプロンプトとの相対比較
- 時系列での劣化・改善の可視化
「熟達」の定義の再検討
- 現在は「安定して良い結果を出す」が目標だが、次の段階は何か
- 「予測可能な失敗」の利用とか？
ツールの「透明性」の問題
- Claude Codeの内部動作（コンテキストウィンドウの使用状況、どのファイルが参照されているかなど）を可視化する方法
- 観察対象を拡張する
社会的・分散的な学習
- 一人での並列実行だけでなく、他者の「ラン」の結果をどう取り込むか
- コミュニティの知見を自分のCLAUDE.mdに変換する方法
「メタ認知」の外部化
- 自分がどう判断しているかを観察する仕組み
- 日報プロンプトをさらに深化させる方向

これらを踏まえて、具体的かつ実践的なアドバイスをいくつか提示する。既存の議論を否定するのではなく、さらに深掘りする形で。現状の議論をさらに深めるなら、以下のような視点が考えられる。

1. 並列実行の「比較コスト」への対処

並列で複数のプロンプト変種を走らせると、出力の差分を見る認知負荷が無視できなくなる。3つなら比較できるが、10になると人間の短期記憶がボトルネックになる。

この認知負荷を下げる方法として、「比較のためのプロンプト」を別途設計する手がある。複数のセッション出力を投げ込んで、「これらの違いを3つの観点で整理して」「最も保守的な実装はどれか」といった問いを投げかける。人間がdiffを目で追うのではなく、Claudeに比較を委ねて、判断材料を絞り込む形だ。

さらに極端に言えば、「比較用のSub Agent」を自作しておき、毎回のラン終了後に自動的に過去の出力とdiffを取る仕組みを入れても面白いかもしれない。

2. CLAUDE.mdの「圧縮言語化」

現在は「学習ログ」として一行ずつ追加しているが、ある程度のパターンが蓄積した段階で「圧縮層」を設けると良さそうだ。具体的には、自分専用の略語やパターン名を定義する。

例えば「このプロンプトはVCP（Verification-Centric Prompt）パターンに該当する」や「ここは探索段階なのでExplore-first戦略を取る」といった具合に、繰り返し現れる構造に名前を与える。これによりCLAUDE.mdが自己言及的になり、次のセッションで「いつものVCPで」という参照が可能になる。

メモリにある「専門用語をふんだんに使った圧縮層」という志向と合致する形だ。

3. 「失敗の予測可能性」を指標にする

現在のフレームワークは「成功を定義して測定する」が中心だが、並列実行の分散を見る際に「どのパターンがどこで予測可能に失敗するか」を記録するのも価値がある。

例えば「長いコンテキストでのExploreは3回に1回見落としが起きる」「CLAUDE.mdを参照させると過去の失敗に過敏になりすぎて保守的になる」といった、特定の条件下での予測可能な挙動を見つけ出す。これを「予測可能な失敗リスト」としてCLAUDE.mdに積むと、次のランでその失敗を回避するための戦略を立てやすくなる。

4. セッション状態の「チェックポイント」設計

ローグライトのアナロジーをさらに進めると、/clearや/rewindの使い方に戦略性が生まれる。単に「失敗したらリセット」ではなく、意図的に「ここで分岐を作りたい」という意識を持つ。

具体的には、あるタスクの途中で「ここまでの文脈は良い感じだ」と判断したら、手動でCLAUDE.mdに「チェックポイント：この時点の文脈は〇〇の判断に有効」というメモを残す。次に同じようなタスクに取り組む際に、そのチェックポイントからスタートするプロンプトを設計できる。

これは「文脈の再現性」を高める試みで、Claude Codeの確率性に対する別のアプローチとなる。

5. 「自分の判断の記録」を追加する

日報プロンプトは「何が起きたか」を記録するが、並列実行の結果を見て「どれを選んだか」の判断プロセスも記録すると面白いかもしれない。「AとBの間で迷ったが、保守性を優先してBを選んだ」といった具合に、自分の価値判断の変遷を追える。

これを蓄積すると、後から「自分はいつ保守性を優先しがちか」「どのような状況でリスクを取るか」といった自己認識が生まれ、次のランでの判断が速くなる。

6. ツールの「透明性」を上げる観察

Claude Codeの内部状態（どのファイルがコンテキストに入っているか、トークン使用量の推移、どのツールをどの順序で呼んだか）を可視化する方法を探る。現状ではこれらは暗黙的だが、これを明示的に記録することで「なぜこの出力になったか」の説明可能性が上がる。

例えば「このセッションでは予期せぬファイルがコンテキストに入っていたため、回答がそれに引きずられた」といった分析が可能になる。これはデバッグのための観察として、日報プロンプトに追加する価値があるかもしれない。

これらはいずれも、すでにある程度確立している方法論を「さらにメタに」または「さらに構造化して」拡張する方向だ。特に「圧縮言語化」と「予測可能な失敗の記録」は、既存の「一行ずつ追加」という慎重なアプローチと親和性が高いように見える。

良いですねまたランにおけるオブザーバビリティを上げるという方法もありそうです。

ユーザーは「ランにおけるオブザーバビリティを上げる」という観点を挙げている。これは、Claude Codeのセッション（ラン）の内部状態をより詳細に観察・記録し、後から分析できるようにするという方向性だ。

これは非常に興味深いポイントで、単に「結果を比較する」のではなく「プロセスを観察する」というメタな視点。ソフトウェア開発における「オブザーバビリティ（可観測性）」の概念を、Claude Codeの使用プロセス自体に適用するという発想。

考えられる具体的なアプローチ：

ツール呼び出しのトレース
- Claude Codeがどのツールをどの順序で呼んだか
- ファイル読み込み、編集、コマンド実行のシーケンス
- これを可視化すると「なぜこの結果になったか」の説明可能性が上がる
コンテキストウィンドウの使用状況
- どのファイルが参照されたか
- トークン使用量の推移
- コンテキストがいつ切り替わったか
思考プロセスの外部化
- Claudeの「内部独白」を引き出すプロンプト
- なぜその判断をしたかの言語化
時間的・因果的な追跡
- セッション内での意思決定の依存関係
- 「この編集は、先に読んだファイルXに基づいている」
構造化ログの生成
- 日報プロンプトをさらに構造化して、機械的に解析可能に
- 後から検索・集計できる形式
リアルタイム vs 事後分析
- セッション中に観察する vs 終了後に分析する

これらを整理して、実践的なアドバイスとして提示する。その観点は鋭い。ソフトウェアシステムのオブザーバビリティを、Claude Codeの使用プロセス自体に適用するという発想だ。

ランにおけるオブザーバビリティを上げる具体的な方法として、以下が考えられる。

ツール呼び出しのトレース記録

Claude Codeがセッション内でどのツールをどの順序で呼んだかを記録し、後からそのシーケンスを分析する。ファイル読み込み → 編集 → コマンド実行の流れを可視化することで、「なぜこの結果になったか」の因果関係が追える。

現状ではこれらのツール呼び出しは暗黙的だが、プロンプトで「実行したツールとその理由をログとして出力せよ」と指示することで、自己言及的な記録を残せる。これにより「この編集は先に読んだファイルXに基づいている」といった依存関係が明示化する。

コンテキストウィンドウの使用状況の可視化

どのファイルが参照され、いつコンテキストに入り、いつ切り替わったかを追跡する。Claude Codeは自動で関連ファイルを読み込むが、この「読み込みの決定」自体が出力に影響を与えている。

セッション終了時に「今回どのファイルを参照したか、参照順序はどうだったか」を問いかけるプロンプトを追加することで、予期せぬファイルがコンテキストに入っていたことによる「引きずられ」現象を検出できる。

思考プロセスの外部化

Claudeの推論過程をより詳細に言語化させる。単に「何をしたか」ではなく「なぜその方針を選んだか」「どの選択肢を検討し、なぜ却下したか」を出力させる。

これには「ステップバイステップで考えて」に近いが、より構造化された形式を要求する。「判断の分岐点で、選択肢AとBがあり、Xという理由でAを選んだ」という記述を強制することで、後から「この判断パターンはどのくらい再現性があるか」を分析可能にする。

構造化されたラン・ログの設計

日報プロンプトをさらに進化させ、機械的に解析可能な形式（JSONやYAML）で出力させる。例えば以下のような構造だ。

yaml

Copy

run_id: 2026-04-15-001
task: 機能Xの実装
tools_used:
  - type: read
    target: src/utils.ts
    timestamp: 0:05
  - type: edit
    target: src/feature.ts
    based_on: [src/utils.ts]
    timestamp: 0:12
decisions:
  - point: 実装方針
    options: [Aパターン, Bパターン]
    chosen: Aパターン
    reason: テスト容易性のため
accidents: []
expectation_gaps:
  - 想定: 10行の変更
    実際: 50行の変更
    原因: 依存関係の複雑さを過小評価

これを蓄積していくと、複数のランを横断して「どのような状況でツール呼び出しが増えるか」「判断の迷いが生じるパターンは何か」といった分析が可能になる。

リアルタイム観察と事後分析の使い分け

オブザーバビリティには「セッション中に確認する」と「終了後に分析する」の2モードがある。リアルタイムでは「今どのファイルを見ているか」を確認し、予期せぬ参照を検出。事後分析では複数ランのパターンを比較する。

リアルタイム用のプロンプト例として「次に何をするか決める前に、今コンテキストに入っている情報を列挙して」と挟むことで、Claudeの「今の視野」を可視化できる。

観察データの蓄積とCLAUDE.mdへの還元

収集したオブザーバビリティ・データをどうCLAUDE.mdに還元するかが課題になる。生のログをそのまま貯めると肥大化するので、「このパターンではツール呼び出しが多くなる」「このタイプのタスクではファイルXを先に読むべき」といった圧縮された知見だけを抽出して蓄積する。

これにより、次のランでは「前回の同様のタスクではこういう参照順序だった」という予測が立てやすくなり、オブザーバビリティが予測可能性に繋がる。

仮説をもって検証するのは良いでしょう。コンテキストに乗り切れてない肥大化。無駄な探索をした。コンテキストに含まれるべき情報が含まれなかった。ここでclearするべきだった。ツールの呼び出しが行われた。行われなかった。

ユーザーは、オブザーバビリティを上げることで検証すべき具体的な仮説を列挙している。これらはClaude Code使用時の典型的な問題点で、観察によって検証・改善可能なものだ。

コンテキストに乗り切れてない肥大化（コンテキストウィンドウの限界）
無駄な探索をした（ツール呼び出しの効率性）
コンテキストに含まれるべき情報が含まれなかった（重要な情報の欠落）
ここでclearするべきだった（セッション管理のタイミング）
ツールの呼び出しが行われた / 行われなかった（期待通りのツール使用）

これらを「仮説」として扱い、オブザーバビリティデータで検証するというアプローチは良い。これをさらに具体的な観察指標に落とし込むと良いだろう。その仮説たちは、オブザーバビリティで検証すべき核心的な問いだ。それぞれを観察可能な指標に落とし込むと、以下のような検証方法が考えられる。

コンテキスト肥大化の検出

仮説：コンテキストに乗り切れていない観察指標：トークン使用量の推移、参照ファイル数の累積、ファイル間の関連性の薄さ

検証方法：セッション中に「現在のコンテキストサイズと、含まれているファイルの一覧を出力せよ」と問いかける。ファイル数が増え続け、かつ直近の編集と関連の薄いファイルが含まれている場合、肥大化を疑う。CLAUDE.mdに「このタスクでは通常Nファイルを超えると性能が低下する」という閾値を記録しておき、超えたら警告を出す仕組みを入れることもできる。

無駄な探索の特定

仮説：無駄な探索をした観察指標：同一ファイルの繰り返し読み込み、編集なしの読み込みの連続、目的から外れたファイルの参照

検証方法：ツール呼び出しのシーケンスを時系列で見て、「読み込み→読み込み→読み込み→編集なし」というパターンを検出。あるいは「Aを読んでBを読んでAに戻る」という循環的な参照も無駄を示唆する。これらを「探索パターンの無駄」としてタグ付けし、次のランでは「ファイルXは既に読んでいる」という前提を明示的にプロンプトに入れることで削減を狙う。

情報欠落の検出

仮説：含まれるべき情報が含まれなかった観察指標：重要ファイルの未参照、編集対象と関連ファイルの非接続

検証方法：タスク開始時に「このタスクで参照すべきファイルは何か」を予測させ、セッション終了後に「予測したファイルと実際に参照したファイルの差分」を確認。予測に含まれていたのに参照されなかったファイルは、コンテキストの「漏れ」として記録。これはCLAUDE.mdの「このタスクでは必ず確認すべきファイル」リストの精度向上に繋がる。

clearタイミングの最適化

仮説：ここでclearするべきだった観察指標：文脈の切り替わり、タスクの位相変化、性能の低下パターン

検証方法：セッション内で「今の作業が前の作業と文脈が異なるか」を自己評価させ、そのタイミングを記録。後から「文脈切り替わりを検出したがclearしなかったセッション」と「clearしたセッション」を比較。前者で失敗や無駄が多い場合、仮説が裏付けられる。/clearの「ベストタイミング」のパターンを学習し、次回は「ここでclear推奨」というプロンプトを挟む。

ツール呼び出しの有無

仮説：ツールの呼び出しが行われた / 行われなかった観察指標：期待されたツールの実行確認、不要なツールの実行検出

検証方法：プロンプトに「以下のツールを使うこと：read, edit, bash(test)」と明示した場合、それらが実際に呼ばれたかを確認。逆に「使うなと言ったツール（例：git commit）」が呼ばれていないかも確認。これは「指示の遵守率」として記録でき、プロンプトの明確さと相関を取ることで、どのような指示の出し方が遵守されやすいかを学習できる。

これらの統合的な観察フレームワーク

これらの仮説検証を統合するには、セッション終了後に以下のような問いを投げかける形が考えられる。

plain

Copy

今回のセッションにおいて：
1. コンテキストは肥大化したか（ファイル数、トークン量から判断）
2. 無駄な探索はあったか（同一ファイルの繰り返し読み込みなど）
3. 重要な情報の欠落はあったか（参照すべきだったファイルが未参照など）
4. clearすべきタイミングはあったか（文脈の切り替わりを検出できたか）
5. 指示したツール呼び出しは適切に行われたか、不要な呼び出しはなかったか

それぞれについて、検出した場合はタイミングと理由を記述し、
次回の同様のタスクで改善するための具体的なプロンプト調整を提案せよ。

これを構造化された形式で出力させ、CLAUDE.mdの「検証済みの仮説」セクションに蓄積していく。オブザーバビリティが、単なる記録から「次のランの設計」に繋がる。