Claude Codeの魔法の言葉+Cluade CodeとCursorを同時使いながらの感想

Claude CodeおすすめのPrompt

1. 深い推論のための魔法の言葉

• think / think hard / ultrathink
• 用途：アーキテクチャの選定、アルゴリズムのトレードオフ比較、リファクタリング前のプラン比較
• 一文例：
  「think harder、A/Bキャッシュ方式における書き込み増幅、運用複雑性の違いを比較し、その上で移行手順を提示してください。」

2. コンテキストの注入

• 便利な使い方：リポジトリのルートに CLAUDE.md というファイルを置き、チームの規約や起動スクリプトを記述します。
• 例：
  a. リポジトリのルートディレクトリに CLAUDE.md を作成し、コーディングスタイルや起動スクリプトなどを記述します。
  b. 対話の中で # 覚えて：テストの前にまず make typecheck を実行して と入力すると、Claudeはこの指示を自動で CLAUDE.md に書き戻します。
  このように CLAUDE.md を継続的に更新していくことが、長期的なプロンプトを改善していくことになります。

3. よく使うワークフローの組み合わせ

• コード探索： read <ファイル> + do not write code yet
• 大規模な機能開発： make a plan + think
• TDDプロセス： write tests + commit
• PRの自動作成： commit + create PR
• バッチスクリプト： --dangerously-skip-permissions （一時的なコンテナと組み合わせれば、安心して実行できます）

4. スラッシュコマンド

• .claude/commands/ ディレクトリに fix-github-issue.md のような手順書を作成します。
• 対話の中で /project:fix-github-issue 1234 と一言入力するだけで、チーム内でワンクリックのワークフローを共有できます。

5. その他の頻出キーワード

• explain：コードを一行ずつ解説
• refactor：構造的な書き直し
• add type hints：型ヒントの追加
• generate docs：ドキュメントの自動生成
• compare：ファイルの差分を要約

Cluade Codeの感想

最近、CursorとClaude Codeをよく使うので、使用感をまとめてみます。

CursorであろうとClaude Codeであろうと、その中核は実は以下のいくつかのことを行っています。

1. ユーザーの要求を解釈し、プログラミング計画を立てる
2. 修正が必要なファイルを見つける
3. コードを修正し完成させる

製品間の違いは複雑さの問題だけであり、本質的なフローは実は変わっていません。

現在、修正するファイルを見つけるのが最も得意なのはCursorです。独自のcodebaseを使ってファイルを素早く見つけます。

Claude Codeも見つけることはできますが、毎回様々なファイルを比較して、どれを修正すべきかを判断する必要があります。

---

そのため、Claude CodeがCursorよりも作業効率が低い原因はここにあります。主に「ファイルを探す」という段階で差がついています。

1と3の項目（計画とコード修正）における両者の違いは実はそれほど大きくありません。結局のところ、どちらも主力はClaudeモデルだからです。しかし、2の項目（ファイル検索）に違いがあるのです。

複雑なプロジェクトでClaude Codeに指示を出そうとすると、指示が不明確だと大量のバグが発生し、まるでインターンに仕事をさせるような感じです。その点、Cursorの方が少しマシです。

プログラマーではないユーザーの視点から見ると、私はコードのアーキテクチャやIDEの画面にはあまり関心がありません。私が気にするのはただ一つ、「私が要求を出し、AIがどのような結果を出すか」ということです。

将来のAIプログラミングは、おそらく1、2、3のステップをより深く統合していくでしょう。この領域において、人間が深く関与する価値はますます低下していくと考えられます。

AIは間違いなく急速に進化します。人間は、要求を発掘し、要求を明確に説明することに、より多くの精力を注ぐべきです。実利的な観点から見れば、コードを学ぶこと自体の価値はあまりなくなるでしょう。