Claude Codeの前と後。やり始めたこととやめたこと
こんにちは、しば田です。
ちょっと俗っぽいですが、以前にこんな記事を書きました。
これの続編的な感じです。（こういうのがあってもいいだろうと...。）
この時から考えると未だにやっていてよかったことともうやってないなぁみたいなのが混在します。
備忘録も兼ねて書き記します。
※記事の対象者は Claude Codeを使ってプログラミングしている人/使い始めた人を想定しています。
※メンタルモデル的な話、生存戦略的な話は出てきません
宣伝
こちらのイベントでLTします。まだClaude Codeを使ったことがない人向けに布教します！
（すでにClaude Codeに関するいい資料がありすぎて資料作りが難しい・・・）
Claude Codeを使い始めてからやり始めた良さげなこと
こまめに/clear
必須。コンテキスト長が埋まると、auto-compactionが走るので、それまでのやり取りが圧縮されてしまいます。その他、ファイルの編集等もが下手になるし時間かかるような気がします。
Iterm2を使い始めた
今日から使い始めました。（macOS用）
私は、コンペ形式の同じ内容の並列ではなくて、依存関係のないタスクを並列で行うことが多かったり（個人プロジェクトなど緩くないとできないと思いますが...）、全然別のプロジェクトを2,3同時に進めることが多いのでgit worktreeは時々しか使ってません。（worktreeを使うときはclaude squadを使っています。）Iterm2のいいところは、⌘+Dで横分割、⌘+shift+Dで縦分割が一瞬でできるのが気に入っています。このような画面が一瞬で作れます。
Iterm2はコマンドの認証が必要な時と実装完了時にデスクトップ通知をくれます。
通知音MCP（後述）が鳴らせないのがきついかもと思いましたが、この機能がかなり助かってます。
DevContainerの使用
claude --dangerously-skip-permissions を気兼ねなく実行可能。
このサンプル実装と同じファイルを置くだけ。（anthropic親切。ありがとう...）
これが動画の冒頭（本当に一番頭）で流れを説明してくれていて分かりやすいです。
通知音MCPを使う
並列実行なので、ほんと人間のスピードがボトルネックです。
また、Claude Code自走性能高いので気づいたらぼーっとしてたりもします。
なので、通知音かなり助かってます。
遠い昔にCursorに通知音がなかった時代に通知音を鳴らしてくれるMCPサーバを作りました。
これをGlobalのClaude.MDで鳴らすように書いてます。毎回鳴らしてもらうのはちょっとチューニングが必要でした。こんな感じで書いてます。
- 毎回の返答の最後に、必ずsound-notification-mcpを使用して音声を再生してください。
- タスクの完了時だけでなく、ユーザーとの各やり取りで音声通知を行ってください。
- 各メッセージの返答後、必ずsound-notification-mcpでdefaultサウンドを再生してください。
- ユーザーにコマンドの承認を求める際は、まず最初にsound-notification-mcpでdefaultサウンドを再生してから確認ダイアログをユーザーに表示してください。必ず守ること。
terminal操作のコマンドを少しだけ覚えた
たくさんは無理そうだったのでこれだけ覚えました。まあまあ便利になりました。
-
^A・・・行頭に移動
-
^B・・・1文字前に戻る
（AとBセットで使う） -
^E・・・行末に移動
-
^F・・・1文字後に戻る
（EとFセットで使う） -
^J・・・改行（一番大事かも）
VSCodeだと、⌥+Enterでもいけるけど、iTerm2は^Jのみ有効。なので汎用性のあるに^Jに統一しました。 -
^W・・・deleteよりも早く消せる。
Claude Codeの特有コマンド(?)を覚える
-
esc1回押し・・・入力されている文を全部消せる
-
esc2回押し・・・戻りたいメッセージに戻れる。
-
claude --resume・・・セッションの復元
-
claude --dangerously-skip-permissions・・・許可不要モード
think, think hard, ultrathink
必須。結構変わる気がします。
基本、なんかミスリそうだと思ったらとりあえずultrathinkをつけてます。
AllowList, DenyList
ちょっとテキトーにやってたのですが、
この記事を見てしっかりやらねばということでDenyListは登録しました。
最近のアプデで、settings.local.jsonも自動で作られるようになりましたね。
AllowListは、開発の過程で許可すれば勝手に育っていくのでDenyListが大事な気がしています。
CLAUDE.md
あまり積極的にはメンテしてません。
既存案件が多いので、/initを1発したらそんなにそこからはいじらないです。何度も同じミスされた時だけ「このルールを追加しといて」と追加します。
キャラクターや語尾を指定して可愛くしたりは今でもしています。
新規だと、1本自分で書いてみてから/initとかするとうまくルールを拾ってくれるとかそうでないとか。/initなので最初だけと思いきや、定期的にやるといいと教えてもらったのでやってみようと思います。
/model
デフォルトはSonnetにしています。Opusは温存してここぞという時に投入しています。
私は100USDの方なのですぐにOpusはlimitきます。
カスタムスラッシュコマンド
元々はカスタム指示が書かれたMDファイルを直接食わせて使ってました。これは特定のツールにロックインされないためにやってました。暫くはこれを都度@でメンションしてやってましたが、カスタムスラッシュコマンドの方が流石に全然早かったです。基本はプロジェクト共通が多いのでglobal（~/.claude/commands/~~~.md）で作っています。
よく使うのは、
- /adddevlog （実装ログを残す）
- /commit （このセッションの作業内容のみをコミット）
- /createIssueLocal（ローカルでのissueの起票）
- /createIssueGh（ローカルで作ったissueをGitHubでも起票）
- /starttask（タスク開始時）
- /revert （このセッションの作業内容のみをリバート）
あたりな気がします。
Ex-Roo loverとしては、/orchestrator も最近取り入れて試しています。
また、余談ですが、claude codeの気に入っている点の1つに、自身の設定ファイル系をいじれるというのがあります。カスタムスラッシュコマンドも全部作ってもらってます。
（cursorが.cursor/rulesをいじれないのって、結構個人的には不満でした）
Plan Mode
結構いい計画を作ってくれるので使っています。
タスクの難易度によってはOpusを召喚。
Claude Codeを使い始めてからやめたこと
毎回関連ファイルを全て@で与える
Claude CodeはAgentic Searchと巧みな検索コマンド群の使用のおかげか、関連ファイルを明示的に渡さなくても見るべきファイルをきちんと探し当ててくれます。なので、mentionするよりも探してもらって足りなければ追加する方が早いという結論に至りました。
公式のBest Practicesに書いてあるお勧めワークフローである、 Explore, plan, code, commit を意識してます。Claude Codeに探検（Explore）させたほうが早いし楽です。
タスクリストを用意する
Claude Codeが自身で作ってくれて2重になるのでやめます（近日予定、多分やめます）
Claude Codeは自身が作ったタスクリストを消化するシステムプロンプトが強くて、私が作ったタスクリストはチェックしてくれなくて別でチェックさせるのが面倒なのでやめました。
作業中のAIの常時監視
目grep。やめました。並列で作業するようになってから物理的に無理になりました。
英語での指示だし
Claude Code全然関係ないですが・・・。
これまで約1年間、プロンプトは8割英語で音声入力してきました。
流石に母国語の方が使いやすいかつ、最近パッと単語が出てこないことが増えたので、日本語に変えてみました。今のところ、正直、そんなに変わらない気がしてます。
ただ結構TLには、日本人、外国人含め、英語至上主義を多く観測しているので、自信ないです。
深呼吸
減りました。Claude Codeになってストレスだいぶ減りました・・・！！！
それでも、うまくいかない時は深呼吸して休憩するか別の作業をします。
Claude Code時代前からやっていて今もやっていること
一部のみ
詰まったら全部消す
修正ループはClaude Codeでもまだまだハマる。
サンクコストは気にせず、ガツンと消します。LLMはガチャなので！
実装ログを残す
これはまだ大事な気がしている。こまめな/clearでセッション分けてもすぐにキャッチアップさせられるし、自分も昨日何やったかを思い出せる。
音声入力
最近、SuperWhisperからAqua Voiceに変更してみましたが正解だった気がします。
テキストとして入力されるまでのスピードが上がったのと、fnキーのみで始められる手軽さが気に入ってます。（英語と日本語どっちで話すか指定いらないのもいい）
TDD
並列になってレビューがボトルネックなので、もっといいテストを書きたい欲があります。
（ちょっと雰囲気でやっていた部分あるので再度これ見て勉強しなおしています）
プロンプトは丁寧に
簡潔に、詳細に。
凝りすぎず長すぎず（NEW）
否定系の命令を避ける
ピンクの像問題。「〜するな」の不使用はまだ結構意識しています。
Xフォロー待ってます
もしよければフォローお願いします！
Discussion