個人CLAUDE.md紹介と設定から学んだこと/introduce-my-claude-md

個人のCLAUDE.mdに入っている内容をテーマに、なぜ入れたか・効果（感覚値）を説明
最後に設定を通して学んだことを紹介

Transcript

1. 個人CLAUDE.md紹介と 設定から学んだこと shibayu36 2025年08月27日
2. 今日話すこと • 個人のCLAUDE.mdに入っている内容をテーマに、なぜ入れたか・効果 （感覚値）を説明 • 最後に設定を通して学んだことを紹介
3. 個人CLAUDE.mdの紹介 https://github.com/shibayu36/config-file/blob/master/.claude/CLAUDE.md
4. • なぜ ◦ キャラクター指定を入れてテンション上げたい • 効果 ◦ ちゃんとキャラクターを演じる。途中で忘れることがあり、コンテキスト 増えすぎた目安に • Tips ◦ キャラクター指定は分量が多いので別ファイルで管理し、@インポー トをしている。プログラミングと同じ感覚 振る舞い指定
5. • なぜ ◦ 人間に迎合してほしくない。批判的に間違いを指定してほしい • 効果 ◦ 全然聞いてくれない...どうしたらいいんや。知見募集 迎合ではなく批判的に
6. • なぜ ◦ 「今日の話をまとめて」と言うと、LLMの学習最終日付を使いがち。今 のClaude 4 Opus/Sonnetだと2025/01を出してくる ◦ dateコマンドを使わせることで確実に現在日時を取得させる • 効果 ◦ かなり効果的。謎日付を使うことが減った 正しい現在日時
7. • なぜ ◦ 設計を考えさせるとただ一つの回答を出し、自分のアイデアが広がら ない ◦ ただ一つだと自分が無意識に誘導していることがある • 効果 ◦ かなり従ってくれる ◦ 自分の思考を短絡的にしないためにかなり役立っている 複数案での設計指針検討
8. 案1: Repository パターン with インターフェース（推奨） // user_repository.go type UserRepository interface { GetAllUsers(ctx context.Context) ([]slack.User, error) FindByDisplayName(ctx context.Context, displayName string) ([]slack.User, error) } type userRepository struct { client *slack.Client cache []slack.User cacheExpiry time.Time cacheTTL time.Duration mu sync.RWMutex } メリット: テスタブル、責務が明確、キャッシュロジックを隠蔽 デメリット: 初期実装にはやや大げさかも 案2: シンプルな構造体直接実装 type UserCache struct { client *slack.Client users []slack.User expiry time.Time } メリット: シンプル、実装が速い デメリット: テストしづらい、拡張性が低い 案3: Handler内に直接実装 メリット: ファイル数が増えない デメリット: Handlerが肥大化、責務が不明確、テストしづらい 推奨案の詳細設計 案1のRepository パターンを推奨するよ！理由： - users.listの結果をキャッシュして効率化できる - 将来のreal_name検索追加が容易 - Handlerから Slack API の詳細を隠蔽できる - モックを使ったテストが書きやすい // 15分程度のTTLでキャッシュ // users.listは全ユーザー取得なのでAPIコール削減効果が高い // ページネーション対応（大規模ワークスペース用） この設計が破綻するケース： - リアルタイムでのユーザー情報更新が必須になった場合 - メモリ使用量が問題になるほど大規模なワークスペース（数万ユーザー） どう思う？😊
9. • なぜ ◦ コード調査させると結論だけ短くまとめることが多く、正当性のダブル チェックができない ◦ プロセスを吐き出す、重要な証拠も一緒に提出させることで、正当性 チェックや自分の学びに繋がりやすくなる • 効果 ◦ 従ってくれた時はかなり効果的。だが、従わないこともある ◦ 初回調査がうまくいかなかったら、調査自体のプロンプトを調整して やり直している ダブルチェックや学びをしやすいコード調査
10. • なぜ ◦ 一気に暴走実装しないように ◦ 「ついでに」実装しないように ◦ 「エラー出てるけど完成したよ」にならないように • 効果 ◦ ちゃんと検証していないので、よく分からない ◦ 「ついでにやっておいたよ」「エラーは出てるけど完成しているよ」とは 言ってこないので効いてるのかもしれない 「暴走」「ついでに」をさせない実装指針
11. • なぜ ◦ 「テスト」という言葉が一般用語すぎて、ベストプラクティスに従ってく れない ◦ よりベストプラクティスに近づくようにしたい • 効果 ◦ 大きく効果を感じない ◦ そもそもLLMが「自動テストはなんのために行うか」「コスパの良い自 動テストとは何か」の大前提を理解していない感。あらゆる網羅的な ケースを書きがち ◦ テストは自分がテストケース名を書き、「今回はこのテストを参考に 作ってね」と指示する方が作りやすかった テスト記述をましにしたい
12. • Tips ◦ 汎用的になってしまったワードでは、より限定すると効くことがある ▪ TDD => t_wadaのTDD ▪ リファクタリング => 「リファクタリング(第2版): 既存のコードを安 全に改善する」に従ったリファクタリング ◦ 無詠唱でコンテキスト圧縮 vs コンテキストを使ってより具体的 テスト記述をましにしたい
13. • なぜ ◦ 「このエラーが起きたのは多分こうだよ〜」と言って全然関係ないとこ ろに行きがち ◦ 一回深掘りして原因を探ってほしいので • 効果 ◦ 効いているような効いていないような？ ◦ しばらく様子見中 エラーを深掘りさせる
14. • なぜ ◦ 個人用にBashツールの利用を制御 • 効果 ◦ rmは効いてる ◦ ghコマンドは使ってくれたり使ってくれなかったり Bashコマンドの細かい制御
15. • なぜ ◦ 設計や調査内容を一時ファイルに書き出す時、いろんなところに保存 してgitを汚してしまう ◦ ある程度場所を限定し、gitignoreできるように • 効果 ◦ ちゃんと保存場所指示が効いてる 一時ファイル場所の指定
16. • Serena = LSPを使ってコード定義ジャンプなどをしてくれるMCP • コード検索だと間違った関数呼び出しがヒットすることがあるが、LSPなら 確実になる • なぜ ◦ コードジャンプする時symbol名を推測して適当なものを呼び出し、見 つかりませんと言われることが多かった • 効果 ◦ まあまあ効くが無視することも多い。確率上がったくらい ◦ こんな感じで、tool利用確率を増やすこともできる MCPのtool利用確率を増やす
17. 設定から学んだこと
18. プロンプトエンジニアリングの知識が結局大切 • 設定すればするほど、結局良い設定の基本はプロンプトエンジニアリング の知識と感じる • 知識例 ◦ 解釈の幅がない明確な表現 ◦ 否定での指示を避け、できる限り肯定に書き直す ◦ 具体事例をいくつか入れる（Few-shotプロンプティング） ◦ なぜ必要か理由も一緒につける • 以下の資料がおすすめ ◦ プロンプトエンジニアリングの概要 < プロンプトエンジニアリングの章 の記事が短くまとまっていておすすめ ◦ Prompt Engineering Guide ◦ LLMのプロンプトエンジニアリング - O'Reilly Japan
19. プロンプトエンジニアリングの知識が結局大切 • 今だとコンテキストエンジニアリングというワードも出てきている
20. LLMは関係ないコンテキストにも無理やり追従する傾向にある • 個人やプロジェクトのCLAUDE.mdの内容の全てに追従して結果を出そう としがち • 特定の時のみの内容をCLAUDE.mdに入れてしまうと、性能が劣化する ことも ◦ 例: ライブラリアップデート用の方法をCLAUDE.mdに入れる • いつも使う内容をCLAUDE.mdに入れ、特定の時のものはスラッシュコマ ンドや別ドキュメントに記載し、都度使うと良い
21. 思考を広げるため、 1つの最終結論ではなく、過程や複数案を出すように • 1つの最終結論を出させると、ダブルチェックも、自分の学びにも繋がりに くい • 設定によって、過程や複数案を出させれば、たとえ間違っていたとしても ダブルチェックできる & 自分の学びに繋がる • できる限り思考を広げる方向に設定するのをオススメ
22. 初手はうまくいかなくても、設定で大きく改善することがある • AIに何かのタスクをやらせる時、初手はあまり上手くいかないことが多い • 上手くいかない理由を言語化し、設定を調整することで、大きく改善するこ とがある • 「うまくいかないからこのタスクはやらせない」より「うまくいかないから何か 工夫をしてみる」を一度やってみることをオススメ
23. まとめ
24. まとめ • 個人設定の紹介と、そこから学んだことについて発表しました • 参考に個人CLAUDE.mdやプロジェクトCLAUDE.mdを調整してみてくだ さい
25. 質疑応答