Claude Code Setup Playbook / 2026-03-08

Claude Code は、機能を盛る前に「薄い土台」を作る。

X上で実務家が繰り返し勧めているのは、MCPやHooksを最初に全部つなぐことではありません。まずは CLAUDE.md を短く書き、1本の実タスクで評価し、繰り返す作業だけを slash command や hooks に落とす。これが2026年3月8日時点で最も再現性の高い構築パターンです。

最小構成を見る構築手順を見る出典を見る

01最初は薄く

CLAUDE.md は百科事典ではなく、重要な制約だけを書く。

021本で評価

最初の30日は1つの実タスクだけで構築の良し悪しを測る。

03自動化は後から

slash command、hooks、MCP は繰り返しが見えてから増やす。

04コンテキストを守る

サブエージェントや /compact で主会話の文脈を細く保つ。

Verdict

Xで共通して推されている結論は、かなりシンプルです。

Claude Code構築で最も重要なのは、設定量ではなく順番です。最初に足すべきなのは「短い共有文書」と「評価タスク」で、HooksやMCPはその後です。

1. `/init` で始める

まずはプロジェクトの初期メモリを作り、手書きで短く直します。自動生成のまま肥大化させないのが重要です。

Anthropic公式最初の一歩

2. `CLAUDE.md` を薄く保つ

主要コマンド、重要ファイル、禁止事項、Definition of Doneだけを書く。細部は別ドキュメントへ逃がします。

Xで最頻出Minimal Context

3. 繰り返す作業だけ command 化する

毎日同じ依頼をしているなら .claude/commands/ に切り出す。最初から大量の command は不要です。

slash commands定型化

4. 実行状態を見せる

ログを積み増すだけより、例外・変数・実行時状態を見せる方が精度が上がる、という意見がXで強いです。

Real Debugging運用改善

Blueprint

Claude Code の推奨最小構成

初期構成は驚くほど小さくて構いません。X上で評価が高いのは、「何もかも繋いだ環境」より「意図が分かる環境」です。

ファイル構成

repo/
  CLAUDE.md
  README.md
  docs/
    01-product.md
    02-architecture.md
    03-runbook.md
  .claude/
    commands/
      fix-bug.md
      review-pr.md
    agents/
      code-reviewer.md
  scripts/
    format.ps1
    test.ps1

`CLAUDE.md` の最小テンプレート

# Mission
- このリポジトリは何を作るか

# Commands
- test: npm test
- lint: npm run lint
- format: npm run format

# Important Paths
- app/: 本体
- docs/02-architecture.md: 設計
- docs/03-runbook.md: 運用

# Guardrails
- 依存を増やす前に理由を書く
- 変更理由と影響範囲を要約する
- main への直接変更は禁止

# Definition of Done
- テスト実行
- 変更理由の要約
- ロールバック手順を残す

Steps

構築はこの順番が最も失敗しにくいです。

Claude Codeは何でもできるように見えますが、最初の設計順を間違えると文脈を失い続けます。Xで評価が高い構築法は、機能を足す前に「読む順」を整えています。

Step 1

ターミナルを整える

/terminal-setup で改行環境を整え、/doctor で状態確認。ここを飛ばすと最初から操作ストレスが出ます。

Step 2

`/init` してから手で削る

/init で出した内容をそのまま膨らませず、必要な制約だけに削る。X上ではこの「削る作業」が一番重要視されています。

Step 3

毎日使う依頼だけ command 化する

バグ修正、PRレビュー、テスト説明など、1日に何度も使う依頼だけを Markdown command に切り出します。

Step 4

hooks は安全用途から始める

自動整形、危険コマンドのブロック、通知など低リスク用途から。Anthropic公式も hooks は任意のコマンドを実行できると警告しています。

Step 5

MCP は必要な日にだけ接続する

GitHub、Slack、Jira など全部を常時つなぐのではなく、今日使うものだけ接続する。Xではこれが「思考スペースを守る」方法として推奨されています。

Step 6

重い探索だけ subagent に分ける

/agents で専門サブエージェントを用意し、レビューや調査だけ分離。主会話を実装に集中させます。

What To Add

何を追加するかは、用途で決めます。

機能を全部積むのではなく、困りごとに対応して追加するのがClaude Code流です。

slash commands

同じ指示を何度も打っているなら追加。固定テンプレートがあるタスク向きです。

例: /review-pr例: /fix-bug

hooks

整形、通知、危険操作ブロックのように「人が忘れがちな手順」を強制したいなら追加します。

formatguardrail

MCP

GitHubレビュー、Jira起票、Sentry確認のように外部サービスへ入る必要が出てから接続します。

GitHubJiraSentry

Latest Recommended Stack

2026年3月時点で、追加価値が高いもの

X上の実務知とAnthropic公式を合わせると、Claude Code では IDE 統合、PostToolUse hooks、project-scoped MCP、subagents の4つが優先度高めです。

IDE 統合

最新のおすすめは VS Code / Cursor / Windsurf の統合ターミナルで claude を起動し、必要なら JetBrains plugin を使う構成です。外部ターミナルからは /ide で接続できます。

VS CodeCursorWindsurfJetBrains

# IDE 内ターミナルで起動
claude

# 外部ターミナルから接続
/ide

PostToolUse hooks

最初の hook としておすすめなのは formatter / linter 実行です。編集や保存のあとにだけ走らせると安全で、効果も分かりやすいです。

formatlintnotify

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "$CLAUDE_PROJECT_DIR/scripts/format-and-lint.ps1"
          }
        ]
      }
    ]
  }
}

project-scoped MCP

おすすめは GitHub と Sentry のような毎日使うサービスだけを project scope で共有する方法です。チーム共有なら .mcp.json に保存します。

GitHubSentryJiraSlack

# project-scoped MCP を追加
claude mcp add github --scope project -- cmd /c npx -y @modelcontextprotocol/server-github

# 一覧確認
claude mcp list
/mcp

subagents

Reviewer、Debugger、Docs Writer の3種が最新の定番です。主会話を実装に集中させ、レビューや調査だけを別コンテキストに逃がします。

ReviewerDebuggerDocs

project-level subagent
- role: reviewer
- tools: Read, Grep, Bash(test only)
- goal: 差分レビューとリスク抽出に限定

How To Configure

設定はこの3ファイルで足りることが多いです。

いまのおすすめは、CLAUDE.md に文脈、.claude/settings.json に権限と hooks、.mcp.json に共有MCPを分ける構成です。

`CLAUDE.md`

何を作るか、どの docs を読むか、禁止事項だけを書く。

`.claude/settings.json`

permissions と hooks を定義する。危険コマンドの deny と formatter が主用途です。

`.mcp.json`

GitHub や Sentry のような project-scoped MCP を共有する。

Mistakes

Claude Code 構築で外しやすい点

X上で特に多い失敗例を、そのまま構築チェックリストにしています。

最初から全部つなぐ

MCP、hooks、subagentsを最初から全部入れると、何が効いているか分からなくなります。

`CLAUDE.md` を太らせる

長い説明書はタスクそのものを押し出します。要点だけ残し、詳細は docs へ分ける方が安定します。

ログだけでデバッグする

実行状態を見せずにログだけ増やすと、エージェントは静的推測に戻ってしまいます。

X Summary

Xの実務知を一言でまとめるとこうなります。

Claude Codeは「多機能エージェント」ではなく「薄い文脈を守る実装器」として作ると強い、という見方が主流です。

まず目的と全体像を作る。次に短いメモリを書く。繰り返しが出てから command / hook / MCP を足す。これが Claude Code 構築の勝ち筋です。

Sources

参照した X と公式ドキュメント

2026年3月8日時点で確認できたものだけを使っています。Xの内容は要旨を整理し、機能の事実関係はAnthropic公式で裏取りしています。

X / Community

Claude Code の構築で参照した投稿

Matt Van Horn on X : lean CLAUDE.md と progressive disclosure
Shubham Saboo on X : minimal effective context
Marktechpost on X : ETH Zurich study summary
ユニコ on X : Hooks/MCP より先に目的と全体像
Yann on X : plan mode, slash commands, subagents, verification loops
Bruno Borges on X : real debugger を使う
camsoft on X : project-specific MCP の実例

Official Docs

機能確認に使った Anthropic 公式

Next Action

Codex 側の構築も、思想が少し違います。

Claude Code が「薄い文脈と段階的拡張」なら、Codex は harness engineering と並列運用が主役です。

Codex 構築ページへ総合ガイドへ戻る