個人CLAUDE.md紹介と 設定から学んだこと shibayu36 2025年08月27日 

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

個人CLAUDE.mdの紹介 https://github.com/shibayu36/config-file/blob/master/.claude/CLAUDE.md 

● なぜ ○ キャラクター指定を入れてテンション上げたい ● 効果 ○ ちゃんとキャラクターを演じる。途中で忘れることがあり、コンテキスト 増えすぎた目安に ● Tips ○ キャラクター指定は分量が多いので別ファイルで管理し、@インポー トをしている。プログラミングと同じ感覚 振る舞い指定 

● なぜ ○ 人間に迎合してほしくない。批判的に間違いを指定してほしい ● 効果 ○ 全然聞いてくれない...どうしたらいいんや。知見募集 迎合ではなく批判的に 

● なぜ ○ 「今日の話をまとめて」と言うと、LLMの学習最終日付を使いがち。今 のClaude 4 Opus/Sonnetだと2025/01を出してくる ○ dateコマンドを使わせることで確実に現在日時を取得させる ● 効果 ○ かなり効果的。謎日付を使うことが減った 正しい現在日時 

● なぜ ○ 設計を考えさせるとただ一つの回答を出し、自分のアイデアが広がら ない ○ ただ一つだと自分が無意識に誘導していることがある ● 効果 ○ かなり従ってくれる ○ 自分の思考を短絡的にしないためにかなり役立っている 複数案での設計指針検討 

案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コール削減効果が高い // ページネーション対応（大規模ワークスペース用） この設計が破綻するケース： - リアルタイムでのユーザー情報更新が必須になった場合 - メモリ使用量が問題になるほど大規模なワークスペース（数万ユーザー） どう思う？😊 

● なぜ ○ コード調査させると結論だけ短くまとめることが多く、正当性のダブル チェックができない ○ プロセスを吐き出す、重要な証拠も一緒に提出させることで、正当性 チェックや自分の学びに繋がりやすくなる ● 効果 ○ 従ってくれた時はかなり効果的。だが、従わないこともある ○ 初回調査がうまくいかなかったら、調査自体のプロンプトを調整して やり直している ダブルチェックや学びをしやすいコード調査 

● なぜ ○ 一気に暴走実装しないように ○ 「ついでに」実装しないように ○ 「エラー出てるけど完成したよ」にならないように ● 効果 ○ ちゃんと検証していないので、よく分からない ○ 「ついでにやっておいたよ」「エラーは出てるけど完成しているよ」とは 言ってこないので効いてるのかもしれない 「暴走」「ついでに」をさせない実装指針 

● なぜ ○ 「テスト」という言葉が一般用語すぎて、ベストプラクティスに従ってく れない ○ よりベストプラクティスに近づくようにしたい ● 効果 ○ 大きく効果を感じない ○ そもそもLLMが「自動テストはなんのために行うか」「コスパの良い自 動テストとは何か」の大前提を理解していない感。あらゆる網羅的な ケースを書きがち ○ テストは自分がテストケース名を書き、「今回はこのテストを参考に 作ってね」と指示する方が作りやすかった テスト記述をましにしたい 

● Tips ○ 汎用的になってしまったワードでは、より限定すると効くことがある ■ TDD => t_wadaのTDD ■ リファクタリング => 「リファクタリング(第2版): 既存のコードを安 全に改善する」に従ったリファクタリング ○ 無詠唱でコンテキスト圧縮 vs コンテキストを使ってより具体的 テスト記述をましにしたい 

● なぜ ○ 「このエラーが起きたのは多分こうだよ〜」と言って全然関係ないとこ ろに行きがち ○ 一回深掘りして原因を探ってほしいので ● 効果 ○ 効いているような効いていないような？ ○ しばらく様子見中 エラーを深掘りさせる 

● なぜ ○ 個人用にBashツールの利用を制御 ● 効果 ○ rmは効いてる ○ ghコマンドは使ってくれたり使ってくれなかったり Bashコマンドの細かい制御 

● なぜ ○ 設計や調査内容を一時ファイルに書き出す時、いろんなところに保存 してgitを汚してしまう ○ ある程度場所を限定し、gitignoreできるように ● 効果 ○ ちゃんと保存場所指示が効いてる 一時ファイル場所の指定 

● Serena = LSPを使ってコード定義ジャンプなどをしてくれるMCP ● コード検索だと間違った関数呼び出しがヒットすることがあるが、LSPなら 確実になる ● なぜ ○ コードジャンプする時symbol名を推測して適当なものを呼び出し、見 つかりませんと言われることが多かった ● 効果 ○ まあまあ効くが無視することも多い。確率上がったくらい ○ こんな感じで、tool利用確率を増やすこともできる MCPのtool利用確率を増やす 

設定から学んだこと 

プロンプトエンジニアリングの知識が結局大切 ● 設定すればするほど、結局良い設定の基本はプロンプトエンジニアリング の知識と感じる ● 知識例 ○ 解釈の幅がない明確な表現 ○ 否定での指示を避け、できる限り肯定に書き直す ○ 具体事例をいくつか入れる（Few-shotプロンプティング） ○ なぜ必要か理由も一緒につける ● 以下の資料がおすすめ ○ プロンプトエンジニアリングの概要 < プロンプトエンジニアリングの章 の記事が短くまとまっていておすすめ ○ Prompt Engineering Guide ○ LLMのプロンプトエンジニアリング - O'Reilly Japan 

プロンプトエンジニアリングの知識が結局大切 ● 今だとコンテキストエンジニアリングというワードも出てきている 

LLMは関係ないコンテキストにも無理やり追従する傾向にある ● 個人やプロジェクトのCLAUDE.mdの内容の全てに追従して結果を出そう としがち ● 特定の時のみの内容をCLAUDE.mdに入れてしまうと、性能が劣化する ことも ○ 例: ライブラリアップデート用の方法をCLAUDE.mdに入れる ● いつも使う内容をCLAUDE.mdに入れ、特定の時のものはスラッシュコマ ンドや別ドキュメントに記載し、都度使うと良い 

思考を広げるため、 1つの最終結論ではなく、過程や複数案を出すように ● 1つの最終結論を出させると、ダブルチェックも、自分の学びにも繋がりに くい ● 設定によって、過程や複数案を出させれば、たとえ間違っていたとしても ダブルチェックできる & 自分の学びに繋がる ● できる限り思考を広げる方向に設定するのをオススメ 

初手はうまくいかなくても、設定で大きく改善することがある ● AIに何かのタスクをやらせる時、初手はあまり上手くいかないことが多い ● 上手くいかない理由を言語化し、設定を調整することで、大きく改善するこ とがある ● 「うまくいかないからこのタスクはやらせない」より「うまくいかないから何か 工夫をしてみる」を一度やってみることをオススメ 

まとめ 

まとめ ● 個人設定の紹介と、そこから学んだことについて発表しました ● 参考に個人CLAUDE.mdやプロジェクトCLAUDE.mdを調整してみてくだ さい 

質疑応答