Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
個人CLAUDE.md紹介と設定から学んだこと/introduce-my-claude-md
Search
shibayu36
September 01, 2025
Technology
0
310
個人CLAUDE.md紹介と設定から学んだこと/introduce-my-claude-md
個人のCLAUDE.mdに入っている内容をテーマに、なぜ入れたか・効果(感覚値)を説明
最後に設定を通して学んだことを紹介
shibayu36
September 01, 2025
Tweet
Share
More Decks by shibayu36
See All by shibayu36
詳しくない分野でのVibe Codingで困ったことと学び/vibe-coding-in-unfamiliar-area
shibayu36
1
280
今の生産性改善活動で大切にしている考え方
shibayu36
8
8.6k
エンジニアメンター制度の効果的な運用を目指して/improve-mentor-system
shibayu36
27
10k
グレードイメージ具体化のため昇格理由を公開する
shibayu36
8
5.9k
新機能作成時に開発ブランチに細かくmergeしていく戦略/merge-strategy-for-new-feature
shibayu36
6
17k
一から始めるJavaScriptユニットテスト/js-unit-test-from-scratch
shibayu36
8
33k
技術ブログを書くことについて/writing-tech-blog
shibayu36
17
27k
はてなと技術研修
shibayu36
1
6.5k
はてなブログチームの開発フローとGitHub
shibayu36
145
77k
Other Decks in Technology
See All in Technology
SOC2取得の全体像
shonansurvivors
1
330
いま注目しているデータエンジニアリングの論点
ikkimiyazaki
0
510
Oracle Cloud Infrastructure:2025年9月度サービス・アップデート
oracle4engineer
PRO
0
290
業務でAIの力を最大限に発揮するために #弁護士ドットコム
bengo4com
0
290
AIを導⼊しても、 開発⽣産性は"爆増"していない なぜ?
kinosuke01
4
3.5k
2重リクエスト完全攻略HANDBOOK / Double Request Handbook
shoheimitani
5
7k
組織観点からIAM Identity CenterとIAMの設計を考える
nrinetcom
PRO
1
120
about #74462 go/token#FileSet
tomtwinkle
1
250
入門 FormObject / An Introduction to FormObject #kaigionrails
expajp
2
1.4k
C# 14 / .NET 10 の新機能 (RC 1 時点)
nenonaninu
1
960
Goのビルドシステムの変遷 / The history of Go's build system
ymotongpoo
12
3.4k
“2件同時配達”の開発舞台裏 〜出前館PMが挑んだダブルピック実現に向けた体験設計〜
demaecan
0
140
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
513
110k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
GraphQLとの向き合い方2022年版
quramy
49
14k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
BBQ
matthewcrist
89
9.8k
Raft: Consensus for Rubyists
vanstee
139
7.1k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
114
20k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Automating Front-end Workflow
addyosmani
1371
200k
Transcript
個人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を調整してみてくだ さい
質疑応答