2025年の初め、僕はClineというツールに出会った。

それまでAIコーディングといえば、コードの候補を提案してくれるもの。GitHub Copilotが「次の1行」を予測してくれる世界。でもClineは違った。「この関数をリファクタして」と言えば、ファイルを読んで、変更して、テストまで走らせる。AIが「提案する」から「実行する」に変わった瞬間だった。

あの衝撃から約1年。僕はClaude Codeに完全移行して3ヶ月が経つ。

そして気づいたことがある。このツールは魔法じゃない。でも「型」がある。その型を知っているかどうかで、Claude Codeが日常のOSになるか、ただの高級オートコンプリートで終わるかが決まる。

今日は、僕が3ヶ月で見つけた3つの型を共有したい。

最初の1ヶ月は「魔法」だと思っていた

小学生の頃、雑誌に載っていたBASICのプログラムを必死に打ち込んだことがある。何百行もあるコードを1文字ずつ入力して、RUNを押す。画面に「Syntax Error」と表示される。どこが間違っているのかわからない。もう一度最初から見直す。結局、動かなかった。

あの原体験があるから、「コードを書いてくれるAI」に出会ったとき、これは魔法だと思った。

Claude Codeを使い始めた最初の1ヶ月もそうだった。「まずClaude Codeにやらせてみよう」が口癖になり、何でも投げた。結果はまちまちだった。長い会話を続けるとコンテキストが汚染されて的外れな提案が増える。1つのセッションでリサーチも設計も実装もやらせようとして、途中で何の話をしていたか見失う。

魔法を期待していたから、うまくいかないときにどうすればいいかわからなかった。

転機は、うまくいったケースとダメだったケースを比べたとき。うまくいったときには共通のパターンがあった。事前にプロジェクトの情報を整理していたとき。探索と実装を分けていたとき。1つのタスクに集中させていたとき。

これは魔法じゃない。型だ。

型その1：CLAUDE.mdは「プロジェクトの地図」

失敗パターンを分析して最初に行き着いたのが、CLAUDE.mdの重要性だった。

CLAUDE.mdは、プロジェクトのルートに置くMarkdownファイル。Claude Codeがセッションを開始するたびに自動で読み込む。いわば「プロジェクトの地図」を渡すようなもの。この地図がないと、Claudeは毎回ゼロからプロジェクトを理解しようとする。それがコンテキストの無駄遣いにつながる。

Anthropic公式のベストプラクティスでは、CLAUDE.mdに書くべき内容として以下が挙げられている。

  • プロジェクトの技術スタック・構成
  • ビルド・テストのコマンド
  • コーディング規約
  • アーキテクチャの決定事項

ただし注意点がある。UX Planetの分析記事によると、CLAUDE.mdの実質的な「指示予算」は150〜200行程度。それを超えると遵守率が下がる。しかも、CLAUDE.mdの指示は約70%の確率でしか守られない。

この「70%問題」を知ったとき、最初はがっかりした。でも考え方を変えた。70%でいいルールはCLAUDE.mdに書く。100%守らせたいルール（本番DBに直接書き込まない、mainブランチにpushしない、など）はHooksで強制する。

Hooksは、Claude Codeのライフサイクルイベントにスクリプトを仕込む仕組み。Gitのpre-commit hookのClaude Code版と思えばいい。たとえばBashコマンド実行前にスクリプトを走らせて、危険なコマンドをブロックできる。

僕のCLAUDE.mdは今、だいたいこんな構成になっている。

  • プロジェクト概要（5行）
  • ディレクトリ構成（10行）
  • 技術スタック（5行）
  • ビルド・テストコマンド（10行）
  • コーディング規約（15行）
  • やってはいけないこと（5行）
  • @import でテスト方針や設計原則を外部ファイルから読み込み

合計で50〜60行。残りの予算は@import先のファイルに分散している。@path/to/import構文を使えば、メインのCLAUDE.mdをコンパクトに保ちつつ、必要に応じて詳細な指示を読み込ませられる。

ポイントは「これがないとClaudeは間違えるか？」と1行ずつ自問すること。Claudeが自力で正しくやれることは書かない。書くほどノイズが増えて、本当に大事な指示が埋もれる。

CLAUDE.mdはGitにコミットしてチームで共有する。時間とともに「このプロジェクトでClaudeをどう使うか」の知見が蓄積されて、価値が複利的に増えていく。

地図を渡したら、次は作戦を立てる番。

型その2：Plan Modeで「考えてから動く」

CLAUDE.mdでプロジェクトの地図を渡したら、次のステップはPlan Mode。

Claude Codeには2つのモードがある。通常モード（すぐにコードを書き始める）とPlan Mode（まず計画を立ててから実行する）。Shift+Tabで切り替えられる。

最初の頃、僕はPlan Modeを使っていなかった。「早くコード書いてよ」と思っていた。でもこれが落とし穴だった。

Plan Modeなしでマルチファイルの変更を指示すると、Claudeは自信満々に「間違った問題」を20分かけて解く。計画に数分かけるだけで、その20分が節約できる。

InfoQの記事によると、Claude Codeの創始者チームのBoris氏は、常にPlan Modeから開始する運用をしている。しかも計画を別のClaudeに「スタッフエンジニアとして」レビューさせるという。計画の質が実装の質を決めるという考え方。

僕なりのPlan Modeの使い分け基準はこう。

Plan Modeを使うとき

  • 3ファイル以上にまたがる変更
  • 初めて触るコードベースの作業
  • アーキテクチャに関わる設計判断
  • バグの原因が不明なデバッグ

通常モードで十分なとき

  • 1ファイルの小さな修正
  • テストの追加
  • リネームやフォーマット調整

ワークフロー計画のイメージ Photo by Bluestonex on Unsplash

もう1つ重要なのが、作業のフェーズ分け。1つのセッションでリサーチも設計も実装もやらせると、コンテキストがどんどん膨らんで品質が落ちる。

効果的なのは3フェーズに分けること。

  • フェーズ1：探索（/exploreやTaskツールで調査）
  • フェーズ2：計画（Plan Modeで設計）
  • フェーズ3：実装（通常モードで集中コーディング）

フェーズ間で/compactを使ってコンテキストを圧縮するか、/clearでリセットする。これだけで、長いセッションでも品質を維持できる。

ただし2026年2月、Claude Codeに品質リグレッションが発生した。thinking contentのredaction（削減）により、複雑なタスクでの品質が低下したという報告がGitHubのIssue #42796に上がっている。17,871のthinkingブロックの分析で、thinking深度の低下がresearch-first行動からedit-first行動への変化を引き起こしたことが確認された。

この事例は「Plan Modeの重要性」を裏付けている。thinking深度が下がるとClaudeは考える前に手を動かす。だからこそ明示的にPlan Modeで「まず考えて」と指示する意味がある。

計画を立てたら、次は「任せる」。

型その3：サブエージェントで「任せて、戻す」

ここまでCLAUDE.mdとPlan Modeを見てきたけど、3つ目の型は「任せ方」に関するもの。

Claude Codeにはサブエージェント（Taskツール）という機能がある。メインの会話から独立したエージェントにタスクを委任できる仕組み。

なぜこれが重要かというと、メインセッションのコンテキスト汚染を防げるから。大きなコードベースを探索させると、そのファイル読み取りや検索の履歴がメインのコンテキストを埋めていく。サブエージェントに探索を任せれば、結果だけがメインに戻ってくる。途中の試行錯誤はサブエージェントの中で完結する。

2026年2月5日にはAgent Teams機能がOpus 4.6と同時にローンチされた。サブエージェントとの違いはこう。

  • サブエージェント：ワーカー同士が通信しない。ボスに報告して終わり。独立したタスクに最適
  • Agent Teams：チームメンバーが発見を共有し、お互いの前提をチェックできる。横断的な作業に向く

僕がClaude Codeで特に気に入っているのは、プログラミング以外にも活用できること。OpenAIのCodexも試したけど、Codexはコーディングに特化している。Claude Codeはエージェントワークフローの構築、ブラウザ操作（Computer Use）、ファイル管理まで守備範囲が広い。

たとえば僕のSNS投稿パイプライン。リサーチ用エージェント、ライティング用エージェント、投稿用エージェントをClaude Codeで組んでいる。コードを書くだけじゃなく、ワークフロー全体を自動化する「OS」として機能している。

「まずClaude Codeにやらせてみよう」が口癖になったのは、この守備範囲の広さがあるから。コードだけじゃなく、「この調査やっておいて」「このファイルをこのフォーマットに変換して」「この手順書を作って」——あらゆる開発周辺タスクを任せられる。

Cursor・Codexとの棲み分け——全部使ってわかったこと

型を身につけた上で、他のツールとの使い分けも大事。Claude Code、Cursor、Codexを全部使って比較した。

3つのツールは根本的に違うアプローチを取っている。

  • Cursor：VS Codeベースの IDE統合型。タブ補完が強力で、学習コストが一番低い。日常のコーディングでサクサク使える
  • Claude Code：ターミナル対話型。Opus 4.6で1Mトークンのコンテキストウィンドウに対応し、大規模コードベースの分析に強い。Plan Mode、Agent Teams、Hooksなど自動化機能が充実
  • Codex：クラウド非同期型。タスクを投げたらクラウドVMで自律的に作業してPRを作ってくれる。ただし月額$200（ChatGPT Pro必須）

トークン効率の差は大きい。builder.ioの検証によると、Claude Code（Opus）は同一ベンチマークタスクを33Kトークン・エラーゼロで完了。Cursorは同じタスクに5.5倍のトークンを消費した。

コンテキストウィンドウの実効サイズも違う。Cursorは200Kトークンを謳っているけど、複数のフォーラムスレッドで実効70K〜120Kという報告がある。Claude Codeは200Kをフルに使え、Opus 4.6では1Mトークンのベータも利用できる。

僕の使い分けはシンプル。

  • 深い分析・リファクタ・マルチファイル作業 → Claude Code
  • 日常のコーディング・小さな修正 → Cursor
  • バックグラウンドで自律的にやらせたいタスク → Codex

多くのプロフェッショナルがこの併用スタイルに落ち着いているようだ。ツールに「最強の1つ」はなくて、ワークフローの場面ごとに使い分けるのが現実解。

それでもClaude Codeは完璧じゃない

良いことばかり書いてきたけど、正直に言うと課題もある。

2026年2月のアップデート以降、複雑なタスクでの品質低下が報告されている。Anthropicの需要がGPUキャパシティを上回っていて、2026年3月には使用量制限がさらにタイトになった。重い作業の途中で制限に引っかかるとフラストレーションがたまる。

The Registerの記事（2026年4月13日）では、Claude自身に品質低下を検証させるという皮肉な実験まで行われた。

それに、個人的にはプログラムをほとんど自分で書かなくなったことへの不安がある。AIに任せる比率が上がるほど、自分のスキルが錆びていくんじゃないか。。特に他の部署を見ていると、まだ生成AIの活用が進んでいないところもある。自分だけ先に進みすぎて、チームとのギャップが広がるリスクも感じている。

ただ、ここで思い出すのが「型」の話。品質が不安定なら、Plan Modeで計画を明確にしてからコードを書かせる。出力に不安があるなら、別のClaudeにレビューさせる。制限に引っかかるなら、/compactでコンテキストを圧縮して効率化する。

課題があるからこそ、型が活きる。道具の限界を知っているから、使いこなし方が見えてくる。

まとめ：型を持てば、AIに振り回されない

Claude Codeを3ヶ月使って気づいた3つの型。

  • 型その1：CLAUDE.mdは「プロジェクトの地図」 — 150〜200行の予算で、Claudeに地図を渡す。70%で守られるルールはCLAUDE.mdに、100%必須のルールはHooksに
  • 型その2：Plan Modeで「考えてから動く」 — Shift+Tabで切り替え。探索→計画→実装のフェーズ分けでコンテキストをクリーンに保つ
  • 型その3：サブエージェントで「任せて、戻す」 — メインコンテキストの汚染を防ぎ、プログラミング以外のタスクにも活用を広げる

小学生の頃、雑誌のプログラムを打ち込んで動かなかったとき、僕は「魔法が壊れた」と思った。本当は、型を知らなかっただけだった。1文字の打ち間違い、1つのセミコロンの欠落が原因だった。

Claude Codeも同じ。魔法を期待すると振り回される。でも型を身につければ、このツールは毎日の開発を支えるOSになる。

まずは今のプロジェクトにCLAUDE.mdを1ファイル書いてみてほしい。20行でいい。それが型の第一歩になる。

参考リンク