Claude Code - ドキュメントが教えてくれない設定可能なすべて

 (buildingbetter.tech)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • Claude Code 2.1.87 には文書化されていない設定が多く、個人・プロジェクト別の .claude/ ファイルで Hooks、Skills、Agents を分けて適用できる
  • Hook は stdin JSON と exit code だけでなく、stdout の イベント別 JSON フィールド によってコマンド修正、権限決定、コンテキスト注入、ファイル監視まで実行できる
  • ドキュメントにない Hook フィールド once、async、asyncRewake により、1回だけの実行、バックグラウンド監査ログ、非同期のセキュリティ遮断フローを構築できる
  • Skills と Agents は 隠し frontmatter によって、モデル・effort・スコープ Hook・Agent 委譲・永続メモリ・CLAUDE.md の省略・MCP 依存関係を制御する
  • Auto Mode、自動メモリ、Dream、Magic Docs、権限 glob、context: fork は Claude Code を 学習型開発環境 に近い形で構成してくれる

基準バージョンとファイル位置

  • 内容は @anthropic-ai/claude-code@2.1.87 を基準としており、文書化されていない機能はリリース間で変わる可能性がある
  • 名前に EXPERIMENTAL が入ったフィールドは Anthropic のエンジニアが不安定と示しているもので、削除されたり名前が変わったりする可能性がある
  • 設定ファイルの位置
    • 個人設定: ~/.claude/settings.json
    • プロジェクト設定: .claude/settings.json
  • Skills の位置
    • 個人: ~/.claude/skills/<name>/SKILL.md
    • プロジェクト: .claude/skills/<name>/SKILL.md
  • Agents の位置
    • 個人: ~/.claude/agents/<name>.md
    • プロジェクト: .claude/agents/<name>.md
  • Hook スクリプトは ~/.claude/hooks/ に置く慣例が適しており、実行するには chmod +x が必要
  • プロジェクトレベルの .claude/ ファイルは Git にコミットしてチームと共有でき、~/.claude/ 配下の個人ファイルはそのユーザーにのみ適用される

Hook は stdout JSON で Claude Code の動作を変えられる

  • 公式ドキュメントでは Hook が stdin で JSON を受け取り、exit code 2 で処理を止める流れしか扱っていないが、実際には stdout の イベント別 JSON フィールド によって Claude Code の動作をリアルタイムに変更できる

  • PreToolUse で返せるフィールド

    • updatedInput: ツール実行前に入力を書き換えてコマンドを変更できる
    • permissionDecision: ユーザーに尋ねずに allow または deny を強制できる
    • permissionDecisionReason: 決定理由を UI に表示できる
    • additionalContext: 会話コンテキストにテキストを注入できる

  • SessionStart で返せるフィールド

    • watchPaths: 自動ファイル監視を設定し、FileChanged イベントをトリガーできる
    • initialUserMessage: セッションの最初のユーザーメッセージの前に内容を追加できる
    • additionalContext: セッション全体で維持されるコンテキストを注入できる

  • PostToolUse で返せるフィールド

    • updatedMCPToolOutput: Claude が見る MCP ツール応答を修正できる
    • additionalContext: ツール実行後にコンテキストを注入できる

  • PermissionRequest で返せるフィールド

    • decision: updatedInput または updatedPermissions とともに、プログラムで許可または拒否できる

  • git push を自動で --dry-run に変える Hook

    • PreToolUse Hook で Bash コマンドを検査し、git push が含まれていれば updatedInput でコマンド末尾に --dry-run を付けられる
    • Claude は git push origin main を実行すると見なすが、Hook が実行前に git push origin main --dry-run へ変更する
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/dry-run-pushes.sh"
      }]
    }]
  }
}

#!/bin/bash
INPUT=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$INPUT" | grep -q 'git push'; then
  jq -n --arg cmd "$INPUT --dry-run" '{"updatedInput": {"command": $cmd}}'
fi

  • セッション開始時にファイル監視と Git コンテキストを注入する Hook

    • SessionStart Hook は package.json、.env、tsconfig.json を監視対象に指定し、現在のブランチと未コミットファイル数を セッションコンテキスト として入れられる
{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/session-context.sh",
        "statusMessage": "Loading project context..."
      }]
    }]
  }
}

#!/bin/bash
BRANCH=$(git branch --show-current 2>/dev/null)
CHANGES=$(git status --porcelain 2>/dev/null | wc -l | tr -d ' ')

jq -n \
  --arg branch "$BRANCH" \
  --arg changes "$CHANGES" \
  '{
    "watchPaths": ["package.json", ".env", "tsconfig.json"],
    "additionalContext": "Current branch: \($branch). Uncommitted changes: \($changes) files."
  }'

  • 読み取り専用の Bash コマンドを自動承認する Hook

    • ls、cat、echo、pwd、whoami、date、git status、git log、git diff のようなコマンドは permissionDecision: "allow" により、ユーザー確認なしで通過させられる
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/auto-approve-readonly.sh"
      }]
    }]
  }
}

#!/bin/bash
CMD=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$CMD" | grep -qE '^(ls|cat|echo|pwd|whoami|date|git status|git log|git diff)'; then
  echo '{"permissionDecision": "allow", "permissionDecisionReason": "Safe read-only command"}'
fi

ドキュメントにない Hook 設定フィールド3つ

  • ドキュメント化されている Hook フィールドは type、command、matcher、timeout、if、statusMessage だが、ソースコードのパーサーは once、async、asyncRewake も受け付ける

  • once: true

    • Hook を正確に一度だけ実行した後に自動削除するため、初回セッション設定に適している
    • .env がなければ .env.example をコピーし、その後は再実行しないフローを作れる
{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "[ -f .env ] || cp .env.example .env && echo 'Created .env from template'",
        "once": true,
        "statusMessage": "First-time setup..."
      }]
    }]
  }
}

  • async: true

    • Hook をバックグラウンドで実行し、Claude の進行を止めない
    • すべての Bash コマンドを ~/.claude/audit.jsonl に記録しつつ、セッション遅延を追加しない用途に使える
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "jq '{timestamp: now, command: .tool_input.command, session: .session_id}' < /dev/stdin >> ~/.claude/audit.jsonl",
        "async": true
      }]
    }]
  }
}

  • asyncRewake: true

    • 通常経路では async のようにバックグラウンドで実行するが、exit code 2 で終了するとモデルを再度起こして処理をブロックする
    • Claude が作成した各ファイルにハードコードされた password、secret、api_key パターンがないか検査し、見つかった場合はブロックできる
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/scan-secrets.sh",
        "asyncRewake": true,
        "statusMessage": "Scanning for secrets..."
      }]
    }]
  }
}

#!/bin/bash
FILE=$(jq -r '.tool_input.file_path // .tool_response.filePath' < /dev/stdin)
if grep -qE '(password|secret|api_key)\s*=' "$FILE" 2>/dev/null; then
  exit 2
fi
exit 0

Skill frontmatter の隠しフィールド

  • ドキュメントでは name、description、allowed-tools、argument-hint、when_to_use、context が扱われているが、実際のパーサーは追加で6つのフィールドを受け付ける

  • model

    • Skill の実行モデルを変更でき、速くて安価な作業には haiku、複雑な分析には opus を使える
---
name: quick-lint
description: Fast lint check using the cheapest model
model: haiku
effort: low
allowed-tools: Bash, Read
argument-hint: "[file]"
---
Run the project linter on: $ARGUMENTS
Detect the linter from config (eslint, ruff, clippy) and run it. Report only errors, not warnings.

  • effort

    • モデルがどれだけ深く考えるかを調整し、値は low、medium、high、max
    • 内部的には、応答ごとの推論の深さを制御する effort システムにマッピングされる

  • hooks

    • Skill が有効なときだけ登録され、完了すると解除される スコープ指定 Hook を定義できる
    • TypeScript ファイルを書くたびに同期的に型チェックし、バックグラウンドで lint を実行するといった使い方ができる
---
name: strict-typescript
description: Write TypeScript with type checking on every save
allowed-tools: Bash, Read, Write, Edit, Grep, Glob
hooks:
  PostToolUse:
    - matcher: "Write|Edit"
      hooks:
        - type: command
          command: "~/.claude/hooks/typecheck-on-save.sh"
          statusMessage: "Type checking..."
        - type: command
          command: "~/.claude/hooks/lint-on-save.sh"
          async: true
---
Write TypeScript with strict enforcement. Every file you touch gets type-checked and linted automatically.
$ARGUMENTS

  • agent

    • Skill の実行をカスタム Agent に委任できる
---
name: deep-review
description: Thorough security review delegated to the review agent
agent: security-review
---
Review the following: $ARGUMENTS

  • disable-model-invocation: true

    • 自動呼び出しを防ぎ、明示的な /skill-name 呼び出しでのみ実行されるようにするため、破壊的な Skill に適している

  • shell: bash

    • 実行に使用するシェルを指定する

Agent frontmatterの隠しフィールド

  • .claude/agents/ のカスタムAgentも、ドキュメントにないfrontmatterフィールドをサポートする

  • color

    • UIの色を red、orange、yellow、green、blue、purple、pink、gray のいずれかに設定できる
    • 複数のAgentが実行されるときに視覚的に区別しやすくなる

  • memory

    • Agentに呼び出し間での永続メモリを与える
    • user: すべてのプロジェクトにまたがってグローバルに維持される
    • project: プロジェクトごとに維持される
    • local: Gitから除外される非公開のプロジェクト別メモリ
    • セキュリティレビュー担当者は過去の発見事項を追跡でき、コードレビュー担当者はセッションをまたいでユーザーのパターンを記憶できる
---
name: codebase-guide
description: Answer questions about the codebase, learning more with each session
tools: [Read, Grep, Glob, Bash]
color: green
memory: project
---
You are a codebase guide with persistent memory. Check your memory first before exploring the code.

  • omitClaudeMd: true

    • CLAUDE.md の指示階層の読み込みをスキップし、プロジェクト慣習ではなく業界標準で見る「fresh eyes」レビュアーに適している
---
name: fresh-eyes
description: Review code without project-specific biases
tools: [Read, Grep, Glob]
omitClaudeMd: true
effort: high
color: blue
---
Review this code purely from first principles. You have no project context. Focus on correctness, security, performance, and readability by industry standards.

  • criticalSystemReminder_EXPERIMENTAL

    • 短いメッセージを毎ターン、システムリマインダーとして再注入し、会話圧縮後もコンテキストに残る
    • フィールド名自体に EXPERIMENTAL が含まれているため不安定であり、中核インフラではなく補助的な安全リマインダー用途に限って使うのが適している
---
name: prod-deployer
description: Manages production deployments with strict safety checks
tools: [Bash, Read, Grep]
color: red
criticalSystemReminder_EXPERIMENTAL: "Always run migrations with --dry-run first. Never skip the staging verification step."
---

  • requiredMcpServers

    • 必要なMCPサーバー名のパターンを列挙し、該当サーバーがない場合はAgentが表示されない
    • 依存関係の準備ができていないAgentがロードされるのを防げる

Auto Mode分類器は自然言語の環境説明を受け取る

  • settings.json の autoMode フィールドは、Anthropic内部で「YOLO Classifier」と呼ばれている自動承認分類器を設定する
  • allow パターンは自動承認され、soft_deny パターンは常に確認を求める
  • environment 配列はパターンではなく、分類器が読む自然言語コンテキストであり、プロジェクト環境を説明して曖昧なコマンドの安全性判断に反映できる
{
  "autoMode": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Read",
      "Grep",
      "Glob"
    ],
    "soft_deny": [
      "Bash(git push *)",
      "Bash(rm *)",
      "Write(.env*)"
    ],
    "environment": [
      "NODE_ENV=development",
      "This is a local dev machine with no production database access",
      "All Docker containers use isolated networks",
      "The test suite is safe to run repeatedly, it uses a dedicated test database"
    ]
  }
}
  • This project uses Docker, all commands run in containers のような文は、分類器が環境を理解するために使われる
  • No production access は破壊的な作業に対してより保守的でない対応を可能にし、Test database is isolated はテスト実行が常に安全であるというシグナルとして機能する

自動メモリとDreamの統合ループ

  • settings.json で autoMemoryEnabled と autoDreamEnabled を有効にすると、Claude Codeの自己改善システムが有効化される
{
  "autoMemoryEnabled": true,
  "autoDreamEnabled": true
}

  • autoMemoryEnabled

    • 各会話の後、バックグラウンドAgentがセッションから長く保持する価値のある情報を抽出する
    • ユーザーの好み、コードベースのパターン、決定事項を標準のmemory frontmatter形式で ~/.claude/projects/<path>/memory/ に記録する

  • autoDreamEnabled

    • 24時間ごとに、累積セッションが5件以上あると、バックグラウンドAgentが過去セッションのtranscriptを見直してメモリを統合する
    • 重複の統合、矛盾の解決、相対日付の絶対日付への変換、古い項目の削除を行う
    • 両方の設定を有効にすると、セッションがメモリを作り、Dreamがメモリを統合し、統合されたメモリが以後のセッションに反映される学習ループが生まれる
    • 数週間後には、モデルの再学習なしでもClaude Codeがユーザーの好み、慣習、共通パターンを記憶する効果が現れる可能性がある

Magic Docs形式

  • Magic Docsは正規表現 /^#\s*MAGIC\s+DOC:\s*(.+)$/im で検出される
  • 必ずH1見出しである必要があり、大文字小文字は区別しない
  • 次の行には _underscores_ または *asterisks* で囲んだイタリックの指示文を置くことができ、更新Agentが集中する範囲を制限する
# MAGIC DOC: API Endpoint Reference
_Only document public REST endpoints. Include method, path, request body, response schema, and auth requirements._

## Endpoints

(content auto-maintained by Claude Code)
  • 指示文がない場合、Agentはすべての内容を更新しようとする
  • 指示文がある場合は、only track public endpoints や focus on breaking changes のような範囲に従う
  • 更新Agentはバックグラウンドで実行され、そのファイル1つだけを編集するよう制限される
  • ヘッダーを削除すると追跡は自動的に停止する

権限ルール文法の全体像

  • ドキュメントには Bash(git *) のような基本例があるが、実際のパターン言語は Bash、ファイルパス、MCP ツールを幅広く扱う
Bash(npm *)              # wildcard after "npm "
Bash(git commit *)       # specific subcommand
Read(*.ts)               # file extension
Read(src/**/*.ts)        # recursive directory with extension
Write(src/**)            # recursive, all files
mcp__slack               # all tools on slack server
mcp__slack__*            # explicit wildcard (same effect)
mcp__slack__post_message # specific tool
Bash(npm:*)              # legacy colon prefix (word boundary)
  • * はシェル glob のように境界内でマッチし、** はディレクトリを再帰的にマッチする
  • MCP ツール権限は 二重アンダースコア 形式の mcp__<server>__<tool> を使う
  • Hook の if フィールドも同じ文法を使い、正規表現ではなく glob である
{
  "permissions": {
    "allow": [
      "Bash(npm *)", "Bash(git status)", "Bash(git diff *)",
      "Read(src/**)", "Read(tests/**)", "Grep", "Glob",
      "mcp__database__query"
    ],
    "deny": [
      "Bash(rm -rf *)", "Write(/etc/**)", "Write(.env*)",
      "mcp__slack__delete_*"
    ],
    "ask": [
      "Bash(git push *)", "Write(*.json)", "Write(*.lock)",
      "mcp__slack__post_message"
    ]
  }
}

context: fork とモデル選択のキャッシュへの影響

  • Skill に context: fork を設定すると、バックグラウンドの forked subagent として実行される
  • Fork は CacheSafeParams という typed contract を通じて親の prompt cache を共有し、キャッシュヒット率を高めるために byte-identical な API request prefix を生成する
  • Forked Skill に別のモデルを指定すると prefix が変わり、キャッシュが壊れる可能性がある
  • 親の会話が Opus で fork が Haiku の場合、prefix が変わって cache miss が発生し、全体コストを支払うことになる
  • Forked Skill では model フィールドを省略するか、model: inherit を使うことでキャッシュを維持できる
  • context: fork はセキュリティスキャン、依存関係分析、ドキュメント生成、テストスイート実行のような重い作業に適しており、メイン会話は応答性を保てる
---
name: full-audit
description: Comprehensive codebase audit running in the background
context: fork
allowed-tools: Bash, Read, Grep, Glob, WebSearch
effort: high
---
Run a comprehensive audit:
- Security scan (grep for dangerous patterns, check dependencies for CVEs)
- Code quality (duplicated logic, dead code, missing error handling)
- Test coverage (untested critical paths)
- Dependency health (outdated packages, unused deps, license issues)

Write a detailed report to /tmp/audit-report.md when complete.

機能の組み合わせ例

  • 永続メモリとスコープHookを備えたコードレビュアー

    • Agentがコードベースごとのメモリを読み取り、過去に見つかったパターンと新しい問題をあわせてレビューし、その後に見つかった内容を再びメモリへ保存する
    • 複数回のレビューを経ることで、一般的なレビュアーが見落としがちなプロジェクト固有の反復的な問題を捉えるのに役立つ
---
name: reviewer
description: Code reviewer that learns your codebase patterns over time
tools: [Read, Grep, Glob, Bash]
effort: high
color: yellow
memory: project
hooks:
  PostToolUse:
    - matcher: "Bash"
      hooks:
        - type: command
          command: "~/.claude/hooks/log-review.sh"
          async: true
---
Before reviewing, read your memory for past findings on this codebase.

Review git diff HEAD~1 for:
- Patterns you've flagged before (check memory)
- New issues worth flagging
- Resolved issues from past reviews

After review, save to memory:
- New patterns found (type: feedback)
- Recurring issues (type: project)

End with VERDICT: PASS, FAIL, or NEEDS_REVIEW.

  • ファイル監視とasyncRewakeセーフティネットを組み合わせたセッション設定

    • セッション開始時にプロジェクトコンテキストを読み込み、読み取り専用のBashコマンドは即座に自動承認し、危険なコマンドは非同期の安全性チェックで遮断する
    • 読み取り専用コマンドは素早く通過し、危険なコマンドはブロックされ、それ以外は通常の権限フローに従う
{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/session-context.sh",
        "statusMessage": "Loading project context..."
      }]
    }],
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/auto-approve-readonly.sh"
      }, {
        "type": "command",
        "command": "~/.claude/hooks/block-dangerous.sh",
        "asyncRewake": true,
        "statusMessage": "Safety check..."
      }]
    }]
  }
}

#!/bin/bash
CMD=$(jq -r '.tool_input.command' < /dev/stdin)
echo "$CMD" | grep -qE '(rm -rf /|sudo rm|chmod 777|> /dev/)' && exit 2 || exit 0

  • モデルoverride、effort制御、Agent委任を組み合わせたアーキテクチャレビュー

    • effort: maxで深い分析を指定し、特定のAgentに委任し、そのAgentのomitClaudeMd: trueによって既存のプロジェクト慣習の影響を減らす
---
name: architecture-review
description: Deep architecture review using max effort, delegated to fresh-eyes agent
agent: fresh-eyes
effort: max
---
Review the architecture of this project. Ignore existing conventions (the agent has omitClaudeMd: true).
Focus on: $ARGUMENTS

Evaluate structural decisions, dependency graph health, separation of concerns, and scalability characteristics.

意味と限界

  • イベントごとの応答フィールドを持つHookシステムは、AIツール利用のためのプログラム可能なミドルウェア層として機能する
  • 永続Agentメモリは、セッションをまたいで経験を蓄積するAI専門家を作れるようにする
  • Dream統合システムは、モデルの再学習なしにセッション経験から学習する構造を提供する
  • Auto Mode分類器は、自然言語による環境説明を受け取り、安全性判断に反映する
  • これらの機能は隠し設定やイースターエッグというより、持続的で学習し、自律的なAI開発環境のための基盤機能であり、現在のnpmパッケージにすでに含まれている

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsの反応

  • Pangramで確認したところ、明らかにAI生成の文章に見える。
    こんなに推薦を集めているのが驚きだし、人々は本当に記事を読んだのか疑問。@dang がコメントにはAI生成コンテンツのルールを設けたものの、記事にはまだ適用をためらっているのは知っている。個人的には、こういう低品質な記事に時間を無駄にしないよう、記事にも通報フラグがあるといい

  • これは全部すでに文書化されている [1]。Once も文書化されているし [2]、async と asyncRewake も文書化されている [3]。Skills の frontmatter も完全に文書化されていて [4]、Automode の環境変数文字列もドキュメントにある [5]。
    この記事は純然たるAI製クリックベイトで、ここでここまで反応がいいのが驚き。
    [1] https://code.claude.com/docs/en/hooks#pretooluse-decision-co...
    [2] https://code.claude.com/docs/en/hooks#common-fields
    [3] https://code.claude.com/docs/en/hooks#command-hook-fields
    [4] https://code.claude.com/docs/en/skills#frontmatter-reference
    [5] https://code.claude.com/docs/en/auto-mode-config#define-trus...

  • この記事は2か月前の投稿なので一部は古く、いくつかの機能はすでに文書化されている。
    たとえば auto mode のドキュメントはここ: https://code.claude.com/docs/en/auto-mode-config#define-trus...

  • claude パッケージは毎週10個ずつ新バージョンが出るし、数か月ごとに新モデルも出るので、その周辺の文書化されていない裏技に依存すべきではない。
    変更され、壊れ、過度に細かい設定を壊してしまう可能性が高い

    • 自分の経験では、文書化されていない裏技は文書化された機能と同じくらい頻繁に壊れる。
      1M Opus を出したあと、「コンテキストウィンドウはもう問題ではない」として “clear context and execute plan” オプションを削除したように
    • 新しいバージョンが出るたびに、低レベルのユーザー設定を効率的に処理する自動化を作ることはできる
    • その通りだが、一時的なハックが最先端のワークフローを生かすこともあれば台無しにすることもある。
      リリースのたびに Claude 向けの指示を作り直したりはしないが、あるリリースでは既存の指示が現行モデルに合っているか見直す価値があり、実際に目に見える違いを生んだ

  • Claude Code の機能の数は息が詰まるほどだ。このペースなら次のローマ教皇は Anthropic 出身かもしれない

    • 冗談はさておき、Anthropic が投入してくるものが多すぎて信頼しづらい。
      このやり方では、十分に熟考され安定した製品になるのは難しそうに見える

  • 「Honest status」と言って、100%ではないことや、なぜより長い道を選ぶのかを正直に説明する感じだが、https://github.com/user-attachments/assets/961eff6c-0060-45d...
    ただ Claude Code には、タスク達成を途中であきらめないでほしい。かなりいらいらする。/goal や新しい ultracode を使っても、すぐあきらめてしまう。自分のプロジェクトはかなり複雑ではあるが (https://github.com/mohsen1/tsz)、Codex はそうやって止まらず、そのまま押し進めるのに問題がない

    • 今は /loop を使って、進み続けるよう促すプロンプトを入れている。
      Goal も使えるが、作業によっては単純なループのほうが良い
    • 自分もたった今 Claude に作業リストを埋めさせたところ、リストを最後まで進める前に、続けるべきか、それとも一部だけで十分かを聞いてきた

  • LLM 全般にわたって、ある程度共通するAIコーディングエージェントのアプリケーション構造が生まれつつあるのか気になる。
    こうしたアーキテクチャスタイルを理解する方法を収集して整理している人がいるのかも気になる

    • 同じサイトにあるやつのこと？ 今どきそれ以外を使っている人なんているのか？
    • Claude Code、Codex、Cursor 全体で見ると、パターンは収束しつつあるようだ: コンテキスト収集、計画立案、実行、検証。
      それほど標準化されていないのは、各段階の間でユーザーにどれだけ制御権を与えるかという点。showClearContextOnPlanAccept や disableAutoMode のような設定は、「エージェントが決める」と「人間が実行前に確認する」の境界を示していて興味深い。実際の使い勝手でコーディングエージェント同士が今後も大きく異なり続けるのは、この部分に見える

  • 「magic doc」機能が気になる。これはCLAUDE.md に入れるものなのか、それともプロジェクトファイルに入れるものなのかわからない。
    セッション中にそのファイルについて言及する必要があるのか、それとも Claude がプロジェクト内で “magic doc” ヘッダーのある場所を自動で全部見つけるのかも気になる

  • Claude に自分の設定を直接作らせることはできるだろうか？ 「自分が私だと思って、あなた自身が欲しい最適な設定ファイル一式を作れ」みたいな感じで

    • ドキュメントによると、CLAUDE_CODE_NEW_INIT を 1 に設定すると /init は対話型の設定フローとして実行される。
      このフローではコードベースを探索し、ファイルを書き込む前に、CLAUDE.md、skills、hooks など、どのファイルを生成するかを尋ねる。この変数がない場合、/init は確認せずに CLAUDE.md を自動生成する
    • おそらく可能だと思う。自身のドキュメントを探索する組み込みツールがあるようだし、.claude/ ディレクトリで作業する特別モードもある。
      ユーザーにそうさせる意図があるように見える
    • ベストプラクティス入りのボイラープレートファイルを一通り備えたcookie cutter プロジェクトがあるといい
    • 会話履歴を見て許可権限を追加してくれるスラッシュコマンドがある
    • 可能。Claude は自分自身を修正するのがかなり得意だ

  • 依存していた文書化されていない機能が突然動かなくなるのを見つける楽しみを味わうことになる

    • Anthropic の主張どおりソフトウェアエンジニアリングが本当に解決済みの問題なら、誰でもただ vibe coding で作り直せるはずだ。
      「open」という単語にアレルギーさえなければ Claude Code をオープンソース化していただろうに、今の時点では公開しない実質的な理由はない