フランスのテック企業 Marmelab がブログに投稿した「Claude Code Tips I Wish I'd Had From Day One」（2026/04/24）が開発者コミュニティで話題になっている。実際に使い込んで気づいたことをまとめた記事で、公式ドキュメントには載っていない「使って分かること」が詰まっている。主要ポイントを日本語で整理した。
/rewind か /clear で即リセットClaude がおかしな方向に進み始めたとき、多くの人がプロンプトで修正しようとしてしまう。これが罠だ。
「間違った応答が会話に残ると、以降のやり取りがすべて汚染される」
/rewind** — 直前のチェックポイントに戻る（Esc × 2 でオーバーレイを開く）/clear** — 会話コンテキストをまるごとリセット少し戻ったほうが結果的に速い、というのが実感として語られている。
Claude がバグを出したとき、自分でパッチを当てたくなる気持ちはわかる。でも、こうするほうがいい：
「このバグを調査して、原因を CLAUDE.md または
docs/bugs.md にドキュメント化してから修正して」ドキュメントはセッションをまたいで残る。次回同じパターンのバグが出たとき、Claude は記録を参照して再発を防げる。「会話は消えるが、ファイルは残る」という原則の応用だ。
/simplify と /review を走らせるClaude は過剰なエラーハンドリング、過剰な抽象化を入れがちだ。レビューに出す前に：
/simplify # 過剰設計を削ぎ落とす
/review # 自己レビューでよくある問題を検出この2コマンドで「Claude が自分で直せる問題」を事前に潰しておくと、人間のレビュー時間が劇的に短くなる。
セッションの最後に「今日何を学びましたか？」と聞いて、その回答を保存する。Marmelab チームはこれを以下に分類して蓄積している：
| 保存先 | 内容 |
|---|---|
CLAUDE.md |
ビジネスコンテキスト・ドメイン知識 |
| Skills（スキルファイル） | 繰り返す手順の自動化 |
docs/adr/ |
アーキテクチャ決定記録（ADR） |
「Claude は毎回白紙で起動する。学習させるのは人間の仕事」という視点は、長期プロジェクトで特に刺さる。
@ と ! のショートカットを使いこなすあまり知られていないが便利な2つ：
# @ でファイルを直接参照（Claude が即座にコンテキストに読み込む）
@src/components/Button.tsx を修正して
# ! でシェルコマンドを直接実行
!npm test
!git diff HEAD特に @ は「Claude に読んでほしいファイルを明示する」のに有効で、ハルシネーションを減らす効果がある。
Claude がライブラリの API を調べるとき、古い情報や存在しないメソッドを返すことがある。Context7 プラグインはこれを解決する：
next.js@15 や react@19 のような最新バージョンを使っている場合、特に効果が出る。
gh CLI を Claude から使わせるGitHub CLI（gh）を入れておくと、Claude が以下を自分でできるようになる：
gh pr create --fill # PR を自動作成
gh issue comment 123 -b "…" # Issue にコメント
gh run view --log-failed # CI ログを読むレビューコメントへの対応や CI 失敗の調査を Claude に丸投げできるようになる。チームのレビューサイクルに組み込むと効果大だ。
Marmelab の記事では「やめたこと」も率直に書かれている：
ツールを増やしすぎる — 各ツールは Claude の判断を複雑にする。本当に使うものだけ入れる
Opus + 100万トークンコンテキストをデフォルトにする — 40万トークン超えると効果が落ちる傾向がある。通常のコンテキストで 95% のタスクはこなせる
**/batch でまとめて並列実行** — デバッグの粒度が消える。問題が出たとき何が原因か分からなくなる
worktree を増やしすぎる — 並列セッションは魅力的だが、コンテキストスイッチが増えて品質が下がる
これらのTipsに共通するのは「Claude を賢く使う」より「自分のワークフローを設計する」という視点だ。Claude は強力だが、ガイドしてやらないと迷走する。リセットの方法・学習の蓄積方法・ツールの絞り方を決めておくことで、はじめて本来の生産性が出る。