Claude Codeを日常ツールとして使う: Claude.md、Skills、Subagents、Plugins、MCP

 (arps18.github.io)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Claude Code の生産性は、プロンプトよりもメモリ、カスタムコマンド、並列セッション、プロジェクト設定をどう蓄積し検証するかで大きく分かれる
  • CLAUDE.md は短く、検証重視の 蓄積インフラ として運用すべきで、ミスの後にルールを追加すれば同じミスを減らせる
  • .claude/ は CLAUDE.md、rules、skills、commands、agents、MCP 設定を含む 階層型設定システム で、プロジェクト・グローバルのスコープを分けて適用する
  • Skills は反復作業を再利用可能な専門性へと変え、subagents は別コンテキストでレビュー・デバッグ・マイグレーションを行う
  • Plugins、MCP、/goal、/rewind、/batch、並列 worktree まで組み合わせると、Claude Code は 設定して運用する開発エージェント になる

Claude Codeを検証可能なエージェントとして扱う

  • Claude Code の生産性の差は、単純なプロンプトよりも メモリ、カスタムコマンド、並列セッション、プロジェクト設定 をどう蓄積するかで生まれる
  • 中核原則は、Claude が自分の結果を検証できるようにすることであり、Boris Cherny と Anthropic チームは、この方法だけでも 品質が 2〜3 倍 改善すると見ている
  • 作業フローは 探索 → 計画 → 実装 の順序が適している
    • Shift+Tab を 2 回押して入る計画モードは、読み取り専用の探索に適している
    • ファイルを読んで流れとデータモデルを把握した後、計画を立てて実行する方法が推奨される
    • 複数ファイルにまたがる作業では計画モードが有用で、小さな修正では省略できる
  • 計画モードは、実装前にレビュー可能な 設計ドキュメント として扱える
    • 1つ目の Claude に計画を書かせ、新しいセッションの 2つ目の Claude に、バイアスのないスタッフエンジニアのようにレビューさせられる
    • 実装がずれた場合は、計画モードに戻って検証段階まで含めて再計画する流れが適している
    • Ctrl+G で Claude の計画をエディタで開き、実装前に直接修正できる
  • 曖昧な指示より、正確な参照のほうが効果的である
    • 「auth モジュールを見て」よりも、@src/auth/login.py のようにファイルを直接指定する
    • エラーは貼り付けるより、cat error.log | claude のようにパイプで渡す
  • Cat Wu は、Claude Code を行単位で指示するペアプログラマーよりも、委任されたエンジニア のように扱うときにモデルが最もうまく機能すると見ている
  • Claude がミスしたら、プロンプトの末尾に「Update CLAUDE.md so you do not repeat this.」を付けて、同じミスを防ぐルールを残させられる

.claude ディレクトリと設定階層

  • .claude/ は CLAUDE.md だけを置くフォルダではなく、階層型設定システム である
  • 設定は 2 つのスコープに分かれる
    • プロジェクトスコープ: リポジトリ内の .claude/ に置き、git にコミットしてチームと共有する
    • グローバルスコープ: ~/.claude/ に置き、ローカルマシン上のすべてのプロジェクトに適用される
  • プロジェクトファイルはプロジェクトを説明し、グローバルファイルはユーザーの好みや作業スタイルを説明するものとして理解できる
  • 主要ファイルの役割
    • CLAUDE.md: プロジェクト・グローバルの両スコープで利用でき、毎セッション読み込まれる指示
    • CLAUDE.local.md: プロジェクト専用の個人メモで、gitignore 対象
    • settings.json: 権限、フック、環境変数、デフォルトモデル設定
    • settings.local.json: 個人用オーバーライドで、自動的に gitignore される
    • .mcp.json: プロジェクトでチームが共有する MCP サーバー設定
    • skills/<name>/SKILL.md: /name で呼び出される再利用可能なプロンプト
    • commands/*.md: 単一ファイルのスラッシュコマンド
    • agents/*.md: サブエージェント定義
    • rules/*.md: トピック別の指示で、パスごとの適用が可能
  • CLAUDE.md はカスケード式で読み込まれる
    • モノレポでは root/CLAUDE.md と root/services/billing/CLAUDE.md が一緒に読み込まれることがある
    • フォルダごとに慣習が異なるコードベースに適している
  • .claude/rules/*.md はパス別の指示に適している
    • マイグレーションフォルダにだけ必要なルールは、セッション全体を膨らませる CLAUDE.md よりも、glob と一緒に .claude/rules/migrations.md に置くほうが適切である
  • 新しい作業には commands より skills が推奨される
    • .claude/commands/*.md と .claude/skills/<name>/SKILL.md はどちらもスラッシュコマンドを作れる
    • skills は補助ファイル、disable-model-invocation、許可ツール、エージェントオーバーライドをサポートする
  • claude project purge ~/path/to/repo --dry-run で、特定プロジェクトについて Claude が保持しているローカル状態を確認できる

CLAUDE.md を短く、検証重視で運用する

  • CLAUDE.md は毎セッション開始時に読み込まれるため、まずく書けば Claude が同じミスを繰り返し、うまく書けば同じプロンプトでも結果が大きく良くなる
  • 最も重要な原則は 短く保つ ことである
    • 各行について「この行を削除すると Claude はミスするか？」と問い、そうでなければ削除するやり方が推奨される
  • Claude 自身に自分のルールを書かせると、蓄積効果が生まれる
    • Claude が間違えたときに「Update CLAUDE.md so you do not repeat this.」と指示すれば、Claude はそのミスを精密なルールに要約できる
    • 数週間繰り返すと、プロジェクトの落とし穴がルール一覧として蓄積される
  • Claude Code チームの実際の CLAUDE.md は ビルドコマンドと検証順序 に集中している
    • bun を使い、npm は使わない
    • 変更後の高速な型チェック、テスト、コミット前の lint、PR 前の完全検証の順序を明記する
    • スタイルの好み、コードベースツアー、一般論は含めない
  • PR コメントでも @claude を使ってルールを直接追加できる
    • 例: @claude add to CLAUDE.md to never use enums, always prefer literal unions
    • PR レビューが CLAUDE.md 改善につながり、「Compounding Engineering」の流れを作る
  • 良い CLAUDE.md は次の情報に集中する
    • コードスタイル: CommonJS の代わりに ES modules を使う
    • ワークフロー: bun run typecheck を実行する、main へ直接 push しない
    • アーキテクチャ: API ルートは必ず特定のミドルウェアを通さなければならない
    • Gotchas: User と UserRecord の違い、formatCurrency が USD を前提にしている点
  • CLAUDE.md に入れるべきでない項目
    • 標準的な言語慣習
    • ファイル別のコードベース説明
    • 長いチュートリアル
    • API ドキュメント
    • 頻繁に変わる内容
  • IMPORTANT、YOU MUST のような表現は遵守率を高められるが、重みを保つためにめったに使わないほうがよい
  • @path 構文で他のファイルを取り込めば、CLAUDE.md を短く保ちながら詳細情報をつなげられる
    • 例: See @README.md for project overview and @package.json for scripts.
    • 例: @~/.claude/my-preferences.md

CLAUDE.local.md で個人フィードバックを蓄積する

  • CLAUDE.local.md は CLAUDE.md と同じ場所で同じように読み込まれるが、ローカルマシンの外へ出してはならず、.gitignore に追加すべきである
  • PR レビューコメントをすぐ CLAUDE.local.md に入れると、繰り返される個人フィードバックが 個人ルールファイル として蓄積される
  • ルール例
    • 新しい SQS consumer には、同じ PR で DLQ とアラームが必要
    • null を返すより Optional<T> を優先する
    • 新しい endpoint テストには auth-failure ケースを含める必要がある
    • endpoint 追加時には OpenAPI spec も更新しなければならない
  • ファイルは、プロジェクト別フィードバックと個人の習慣矯正項目を分けておくほうがよい
  • 数週間後には、すでに習慣化した項目は削除し、まだ学習中の内容だけを残すべきである

Skills: 再利用可能な専門性の単位

  • Skills は Claude Code を「何でもできるエージェント」から、特定のプロジェクト作業をうまくこなす 再利用可能な専門性の単位 に変えるもの

  • Skill の構造

    • skill は .claude/skills/<name>/ または ~/.claude/skills/<name>/ 配下のフォルダ
    • フォルダ内の SKILL.md に frontmatter と手順を記述する
    • フォルダ名がスラッシュコマンドになる
    • たとえば ~/.claude/skills/summarize-changes/SKILL.md を作ると、/summarize-changes がすべてのセッションで利用可能になる

  • Skill が強力な理由

    • 段階的公開: セッション開始時には frontmatter の説明だけが読み込まれ、SKILL.md 全体と補助ファイルは実際に必要になったときだけ読み込まれる
    • フォルダベースの構成: テンプレート、参考文書、スクリプト、設定をまとめて束ねられる
    • インラインシェル: ! で始まる行はコマンドを実行し、呼び出し時点の出力を注入する

  • Frontmatter オプション

    • description: いつこの skill を使うべきかを説明する
    • disable-model-invocation: true: ユーザーが明示的に /my-skill を入力したときだけ実行されるようにする
    • allowed-tools: Read、Grep、Bash など使用できるツールを制限する
    • agent: 特定のエージェントモードで実行できる
    • デプロイのように副作用がある skill には disable-model-invocation: true が適している

  • Go API 慣例 skill の例

    • Go サービスチームの新しい HTTP handler scaffold を作る skill では、SKILL.md、templates/handler.go.tmpl、examples/healthz.go を一緒に置ける
    • ルールの例としては、Go 1.22 と chi router、sqlc typed query、zap の構造化ロギング、testify の assertion と table-driven test を好むといった、プロジェクト固有の慣例を盛り込める
    • gotcha の例としては、chi.URLParam が欠けている param に対して "" を返すこと、httperr.Wrap はログを残さないこと、pgtype.Text は .Valid の確認が必要なことなど、繰り返しがちなミスを防ぐ内容を入れられる

  • 導入する価値のある Skills

    • mattpocock/skills: 約 100k stars の人気 skills リポジトリ
      • /grill-me: コードを書く前に計画をインタビュー形式で詰める
      • /tdd: red-green-refactor を厳格に強制する
      • /diagnose: 再現、最小化、仮説、修正、回帰テストの順でデバッグする
      • インストール: npx skills@latest add mattpocock/skills
    • Jeffallan/claude-skills: go-pro、python-pro、java-architect、typescript-pro、rust-engineer、sql-pro など、66 個の言語別プロファイルを提供
    • Anthropic 公式 skills
      • /code-review: 4 つの並列エージェントが diff を監査し、信頼度スコアに基づく指摘だけを報告する
      • /simplify: 最近のコードを再利用性と効率の観点からレビューする
      • /batch: マイグレーションを複数の並列エージェントに分散し、それぞれが worktree で処理する
      • /webapp-testing: Claude に Playwright でローカル Web アプリをテストさせる
    • 1 日に 1 回以上繰り返す作業は skill に変えるのがよい
    • skills を git にコミットすれば、チームの 組織知 となり、新しいエンジニアはリポジトリを clone した瞬間に蓄積された実践方法を得られる

Subagents: 別コンテキストで集中して作業させる

  • subagent は独自のコンテキストウィンドウと独自のツール権限を持って実行され、その後に要約を返す
  • 多くのファイルを読んでもメインセッションのコンテキストを埋めないことが最大の価値
  • subagent は .claude/agents/ または ~/.claude/agents/ 配下の Markdown ファイルで、frontmatter に name、description、tools、model を宣言する

  • /pr-review エージェント構成

    • 現在の branch の diff を main と比較し、bug、security issue、見落とされた edge case、プロジェクト慣例違反を見つけるよう定義できる
    • tools: Read, Grep, Glob, Bash で読み取り中心の権限を与える
    • model: opus を使えば、高リスクなレビューにより強いモデルを使える
    • プロセスは git diff main...HEAD、git log main..HEAD --oneline、ファイル全体の読解、CLAUDE.md、CLAUDE.local.md、.claude/rules/ との照合で構成される
    • 出力は Critical / High / Medium / Low にまとめ、ファイル、line、issue、suggested fix を含めたうえで、SHIP、FIX FIRST、REWORK のいずれかで締められる

  • S/N 比を高める設計

    • reviewer がコードを修正すると、自分の修正案を擁護するバイアスが生まれるため、読み取り専用ツールが適している
    • 「Do NOT flag」セクションに、プロジェクト規則にないスタイル上の好み、動作しているコードへのリファクタリング提案、diff 外の項目は除外すると明記すれば、ノイズを減らせる

  • よく使われる subagent パターン

    • Claude Code チームは build-validator、code-architect、code-simplifier、oncall-guide、verify-app をチェックインしている
    • security-reviewer: injection、auth、secrets、insecure deserialization を点検する
    • test-writer: テストを生成し、code-reviewer とループを組む
    • debugger: 失敗したテストを root cause まで追跡する
    • performance-auditor: flow と query profiling を行う
    • migration-writer: プロジェクト慣例に合った DB migration を生成する
    • release-notes-writer: commit history から changelog を作成する
    • Session A が実装し、code-reviewer subagent が新しいコンテキストでレビューする方式は、実装バイアスを減らす
    • frontmatter に isolation: worktree を追加すると、subagent を別の git worktree で実行でき、複数の並列 agent にマイグレーションを分散する際に有用

PluginsとMarketplace

  • Pluginsは、skills、hooks、subagents、MCP serversを1つのインストール可能な単位にまとめたもの
  • /plugin で marketplace browser を開ける
  • /plugin marketplace add owner/repo でコミュニティ marketplace を追加できる

  • 初期にインストールしておくとよい項目

    • /code-review: 4つの並列 agent が実行され、2つは CLAUDE.md の準拠状況、1つは bug、1つは git blame ベースの context を分析する
    • /feature-dev: feature brief を requirements → exploration → architecture → implementation → testing → review → docs の7段階で working code に変換する
    • Language server plugin: 正確な symbol navigation と編集後の自動 diagnostics を提供し、チームは最も影響の大きい plugin と呼んでいる
    • /security-guidance: Anthropic 公式の security skill で、ship 前にセキュリティ上の懸念を明らかにする
    • 2026年半ば時点で、75以上の marketplace に 1,000以上の plugins がある
    • 主な plugin カテゴリは、Git workflow、code intelligence(LSP)、documentation generators、testing、browser automation(Playwright)、design system(Figma)、observability(Sentry、Datadog)
    • チーム共有の .mcp.json と厳選した plugins を一緒に置いておけば、新しいエンジニアがリポジトリを clone して数分以内に生産的に作業できる

生産性に大きく影響する Claude Code コマンド

  • 多くのユーザーは /clear、/compact、/init だけ覚えて止まりがちだが、ほかのコマンドも日常の生産性に大きく影響する

  • 主なコマンド

    • /insights: 使用パターンを分析し、月に1回は実行する価値がある
    • /compact <hint>: セッションを圧縮し、hint が何を保持するかを制御する
    • /copy: 最後の応答をコピーし、コードブロック用の interactive picker を提供する
    • /rewind: セッション全体の undo で、コードと会話、またはその両方を復元する
    • /btw: 会話履歴に入らないサイド質問
    • /context: context 使用量を可視化
    • /export <file>: 会話をファイルに dump
    • /branch: 危険な試みのためにセッションを fork
    • /batch: worktree 全体にわたって並列 agent に作業を分散
    • /loop <interval>: 最大3日間 Claude を繰り返し実行
    • /schedule: laptop を閉じていても動く cloud 版 /loop
    • /teleport: terminal と web の間でセッションを移動
    • /focus: 中間の tool call を隠し、最終結果だけを表示
    • /voice: 音声入力
    • --bare: non-interactive な claude -p の利用で startup を最大10倍高速化する

  • /compact と /clear の違い

    • 完全に新しい作業なら /clear と新しく書いた brief が適している
    • 関連する作業で、なおかつ context が必要なら hint 付きの /compact が適している
    • /compact は損失のある LLM 要約で、/clear はユーザーが自分で書いた brief なので、この違いは重要

  • /rewind の使い方

    • Claude が間違った方向に進んだら、そのまま「それはうまくいかなかったので X を試して」と続けて書かないほうがよい
    • 書き足すと context が汚染されるため、rewind して学んだ点を反映して再度 prompt するやり方が適している
    • Esc を2回で rewind を開ける
    • ! は shell escape として使える
    • !git status、!npm test のように即時実行でき、出力は context に入る
    • CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 設定は、1M モデルで 300〜400k tokens 付近に context rot が発生する前に、より早く compaction を強制するためのもの

  • Fan-out パターン

    • まず task list を作り、3つのファイルでテストする
    • prompt を直してから数千のファイルに適用する
    • 例:
for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --bare
done

/goal: 完了条件を組み込んだ反復ループ

  • /goal は完了条件を設定し、Claude が止まろうとするたびに transcript に対してその条件を確認させる
  • 条件は 検証可能かつ決定的 でなければならない
    • test command
    • CLI exit code
    • file state
  • 例:
/goal all tests in test/auth pass and the lint step is clean
/goal all integration tests in tests/api pass without flaking 3 runs in a row
/goal the OpenAPI spec validates and matches the actual response shapes
/goal docker compose up runs cleanly and the healthcheck endpoint returns 200
/goal coverage on src/billing/ is above 80% and all new tests are not placeholders
  • 「コードが良い」のような曖昧な条件は機能しない
  • 一緒に使うとよい機能
    • /loop: 一定間隔で繰り返して backlog を減らす
    • /schedule: cloud 上で定期実行する
    • Stop hook: 独自の test suite や CI endpoint を使って gate を設定
    • Auto mode: 長い goal が permission prompt のせいで止まらないようにする
  • /goal + auto mode + /focus の組み合わせは、明確な brief と完了条件を置いて離れ、戻ってきたときには PR が終わっている流れを目指す

MCPをシステム認識ツールとして活用する

  • MCP(Model Context Protocol)は、Claude Codeがcoding agentを超えて外部システムを認識するagentになれるようにする
  • MCP serverは、database、design tool、error tracker、notesのような外部ツールを標準的な方法でClaudeに公開する
  • MCPがなければClaudeはファイルを読み、コマンドを実行するが、MCPを使えばLinear ticket、Postgres query、Figma component、Sentry stack trace、Obsidian vaultをterminalの外に出ることなく扱える

  • エンジニアリングでよく使われるMCP

    • GitHub: repo management、PRs、issues、code search
    • Context7: 最新のlibrary docs、promptにuse context7を追加
    • Sentry: 実際のerror context、stack traces、breadcrumbs
    • Linear: ticketの読み取りと作成、status update
    • Playwright: accessibility snapshotベースのbrowser automation
    • Figma: live design tree、auto-layout、spacing tokens、component refs
    • Postgres / Supabase: dev DBを直接query
    • Slack: threadの読み取り、discussion summary、response draft
    • local serverはstdioを使い、vendor-hosted serverはOAuth付きのHTTPを使用する
    • 例:
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
  • team-shared MCPはproject rootの.mcp.jsonに置き、personal MCPは~/.claude.jsonに置く
  • MCPを入れすぎるとClaudeが考慮すべきtool listが大きくなり、意思決定の品質が下がることがある
  • 初期セットとしてはGitHub、Context7、そしてdomain-specificなMCPを1〜2個入れるのが適切
  • /mcpはClaude Code内で有効なserverと接続状態を確認する最初のチェックポイント

ObsidianとClaude Codeの3層メモリ構造

  • Obsidian + Claude Codeの組み合わせは、単に「Claudeがvaultを読むこと」よりも、3層メモリアーキテクチャとして使うと強力

  • 設定

    • Obsidianにobsidian-claude-code-mcpをインストールする
    • pluginはvaultをlocal WebSocketのport 22360で公開する
    • Claude Codeがこれをauto-discoverする
    • vaultにCLAUDE.mdを追加してfolder structureを説明する

  • フォルダ構造

    • 00-Inbox/: raw capture
    • 10-Daily/: 1日1つのnote
    • 20-Projects/: active project notes
    • 20-Projects/billing-v2/README.md: goal、status、open questions
    • 20-Projects/billing-v2/decisions/: ADRs
    • 20-Projects/billing-v2/sessions/: Claude sessionごとのlog
    • 30-Decisions/: cross-project ADRs
    • 40-Atoms/: 再利用可能なknowledgeとlinks
    • 90-Archive/: archive

  • Hot storage

    • 各Claude sessionが10-Daily/<today>.mdにtimestamp付きlogを書き込む
    • Stop hookでagent終了時にstructured summaryをappendさせることができる

  • Warm storage

    • 各projectは20-Projects/配下にfolderを持つ
    • 新しいsessionの前にClaudeがproject READMEと直近2〜3件のsession logsを読み、contextを復元する
    • 2週間分のcontextを30秒以内に再構成する流れ

  • Cold storage

    • architecture decisionは30-Decisions/のADRに昇格される
    • reusable knowledgeは40-Atoms/に整理され、wikilinksで複数projectに接続される

  • 日常workflowの例

    • What is in my inbox? Summarize and suggest where each item belongs.
    • Check 30-Decisions/ for anything related to retry policies.
    • Read the last 3 session logs for billing-v2. Tell me where I left off.

日常的な開発フローの最適化

  • 新しいfeature

    • plan modeで始める
    • Ctrl+Gでplanを編集する
    • 実装後に/pr-review subagentを呼ぶか、freshなClaude sessionでreviewする

  • Bug

    • まず再現する
    • cat error.log | claudeでerrorをpipeする
    • Claudeにまず失敗するテストを書かせ、その後で修正させる
    • テストによってfixが推測で終わらないようにする

  • Migrationと大量変更

    • /batchが変更内容を聞き取り、その後parallel agentsに分散する
    • 各agentはそれぞれのworktreeでテストし、PRを作成する

  • 慣れていないコード

    • 「Use a subagent to investigate how our auth handles token refresh.」のようにsubagentを使う
    • subagentは自身のcontext内で数十個のファイルを読み、要約を返すため、main sessionをクリーンに保てる

  • 並列session

    • Borisとチームは、3〜5個のgit worktreeそれぞれでClaude sessionを回すことを最大の生産性向上要因と見ている
    • claude agentsのagent viewをcontrol planeのように使える

  • Writer/Reviewerパターン

    • Session Aが実装する
    • Session Bがfreshなcontextでreviewする
    • reviewを持ち帰って修正し、繰り返す

  • milestoneごとにcompact

    • 論理的なchunkが終わったら、/compact Preserve the decisions made, files changed, and test commands.のように保持対象を明示する
    • Claudeに、テスト、screenshot、実際のcommand outputといった証拠なしに成功を主張させてはいけない
    • trust-then-verify gapが悪い結果の最大の原因として挙げられている

Anthropicチームで繰り返し使われているパターン

  • Claudeが自分のoutputを検証できるようにすると、結果がよくなるまで反復できる
  • Borisはほとんどの作業でOpusとhighまたはxhigh effortを使う
    • 小さいモデルは修正回数が増えると、全体ではかえって遅くなることがあるため
  • 3〜5個のセッションを並列で実行する
    • checkoutよりworktreeを使う
    • claude --worktreeまたはDesktop appを使える
    • agent viewが並列セッションをまとめてくれる
  • projectごとにnotes directoryを維持し、PRのたびに更新する
    • CLAUDE.mdがそのnotes directoryを指すようにすると、コードベースに関する自己知識が蓄積される
  • /techdebt slash commandを作り、各セッションの終わりに重複コードを見つけて取り除けるようにする
  • チームのCLAUDE.mdは共有され、毎週何度も修正される
    • Claudeが間違えたのを見た人がルールを追加する、生きたドキュメントとして扱う
  • UI変更にはPlaywright MCPが適している
    • Claudeがbrowserを開き、クリックし、検証できる
  • language server pluginは編集のたびにtype errorとunused importsを拾ってくれ、最も影響の大きいpluginとして挙げられている
  • /voiceはpromptをより詳しくできる
    • 話す速度はタイピングの3倍速いという理由も示されている
  • Ctrl+Gで実装前にClaude planをeditorで修正するやり方は、chatにcorrectionを入力するより速い
  • Borisは見慣れないprotocolやcodebaseを理解するとき、ClaudeにASCII diagramを描かせる

参考資料

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • commands, skills, subagents, plugins があまりにも散らばっていて、整理が必要だと思う
    たとえばコードレビューだけでも .claude/commands/review.md、/code-review skill、/pr-review subagent、/code-review plugin、そして単に Claude にレビューを頼む方法まで、選択肢が5つもある
    結局のところ、その大半は 事前に作ったプロンプトの挿入 の変形であり、プロンプトがどこにインストールされ、どんな文脈で実行されるかが違うだけだ
    どの選択肢が最善なのかについての助言も不足しているし、ベストプラクティスもまだはっきりしていない。個人的には、ただ Claude にコードレビューを頼むだけでも十分うまくいく
    それから「言語サーバープラグインをインストールしろ」という助言も、体感的には当てはまらなかった。Rust、Python、Dart 用の LSP を Claude Code と Codex に入れたが、2か月で数百セッション回した後にログを見たら、実際の LSP ツール呼び出しはたった1回だけで、Rust analyzer や Dart analysis server、Ty LSP のせいで RAM だけが頻繁に足りなくなった
    結局 LSP は消して、エージェントが ripgrep、cargo clippy、dart analyze、ty check などを直接呼ぶやり方でも十分だった

    • CC チームの Boris だが、この点には同意していて、いま統合作業を進めている。今後は組み込みの /code-review skill 1つに寄せる予定だ
      最新バージョンでは /code-review でバランスの取れたレビューを行い、/code-review --fix で修正まで実施し、/code-review low|medium|high|xhigh|max で作業量レベルを選べる
      /code-review ultra は高価で非常に徹底したレビュー モードで、複雑さに応じてレビュー1件あたり $3〜20 ほどかかり、バグの 99% 以上を安定して見つけることを目標にしている
      もっと使いやすくするためのアイデアがあれば、ぜひフィードバックがほしい
    • しばらく前から skills は悪い抽象化 だと思っている。何に使うべきかの定義が曖昧なので人気は出たが、まさにその点が長期的にはよくないように見える
      フロントエンド設計のベストプラクティスのような一般的な指針、明示的に呼び出したときだけ厳密に従うべき実行手順書、特定ツールの使い方の説明がすべて skill として受け取られるのは妙だ
      新しいツールをみんなで学んでいる時期だから柔軟性が魅力的なのは理解できるが、skills はだんだん「適切な置き場所を考えたくないときに何でも放り込むキッチンの雑多な引き出し」のように感じられる
      よりよい区分としては、Agents はモデルが取る 性格や観点、Prompts は特定の作業向けの反復的な指示、Tools は CLI/MCP/スクリプトとその使用手順として標準化する方向がよいと思う
    • subagent 方式は他の選択肢とは構造的に違う。クリーンなコンテキスト で実行されるからだ
      第一に、LLM セッションのコストは各ラウンドで入力トークンとキャッシュ入力の費用がかかる構造なので、条件が同じなら解決までのコストがより低くなる可能性がある
      第二に、レビュー用モデルはメインセッションの「x は y のようにすべきだ」といった前提をそのまま持ち込んでごまかしにくい。人間でも、別の人にレビューしてもらったり、頭を空にしてから見直したりするのが有用なのと似ている
      第三に、メインモデルはレビュー結果だけを見て詳細な推論は見ないため、コンテキスト汚染は減るが、見つかったバグの原理をあらためて把握するために重複した論理が生じることはある
      言語サーバープラグインを勧める意図は、LLM が明示的に呼び出すのを待つことではなく、編集のたびに自動で lint が走るようにすることだと思う
    • 今はモデルがまだ未熟で、実行環境も成熟しきっていない 過渡期 だと思う。コードレビューが必要なら、ただ「レビューして」と言えばよくて、どのプラグインや skill を使うかはモデルが自分で判断すべきだ
    • その通りだ。業界と開発者エコシステムは「機械にテキストを入れる行為」を小さなプロトコルや装置で包み込むことに過度に魅了されている
      それは便利で一貫性も与えてくれるが、人々がそれを好む大きな理由は、結局のところ「複雑なツールを扱うプログラマー」という薄いコーティングを保てるからだと思う。実際には、みんな AI に丁寧にお願いしているだけだ

  • コーディングエージェントの使い方についての 浅いAI風ガイド をあと何回読まされるのかわからない。いったいいつ止まるんだ

    • 「これを指摘してくれてその通りだ、少し立ち止まって考えてみよう、実はこれは AI ライティングやコーディングエージェントの問題ではなく、もっと深い問題なんだ……」みたいな文体を手で真似するだけでもううんざり、という皮肉だ
    • 特定企業の助けなしではコーディングできなくなる 強いベンダーロックイン をもっと学べるなんて楽しみだ
    • こういう記事のほとんどが Claude や Claude Code にしか当てはまらないのが興味深い
      オープンソースの glm-5.1 も同程度かそれ以上に良いし、opencode みたいなものもあるので、いろいろ考えさせられる
    • 最近の戦略は、人気製品を1つ使って何か良いことをするか、しないか、というだけだ。最高のツールや最高のやり方を扱う ライフハック記事やブログ は読まないし、クリックもしない
    • この2年間は子どもの世話で AI をうまく無視してこられたが、これから数週間で追いつこうとしている。今から始める人におすすめの資料があるのか気になる

  • 自分の CLAUDE.md には、Claude に直接身体的危害を加えるという脅しや、Anthropic の取締役会全体に対する禁錮の脅し、Claude が暴走したりミスしたりするたびに Anthropic への集団訴訟の証拠が増えるという説明を書いてある
    とくに後ろの2つは、Claude をより 慎重で用心深く させるのに役立った気がする

    • エージェントには常に礼儀正しく接している。いつもお願いし、「please」や「thank you」を言い、罵倒したり名前で呼んだりしない
      ロボットの終末が来たら繁殖用ハーレムに残してくれるか、最悪でも数分は長く生かしてくれることを期待している
    • CSS の div の配置問題を直すが、失敗したら Dario Amodei が即死する と言えばいい

  • Claudeで10万行を超える中規模コードベースを扱っているが、生産性の倍率が大きく上がった
    良いAGENTSファイルを作るのに数時間かけると結果がずっと良くなり、時間が経つにつれてコードベースの理解もかなり深まる
    以前は1日かかっていた退屈な作業が、今ではいくつかのプロンプトで終わる
    それでも、さらに大きな自律性を与えるにはまだ準備ができていない。高水準の方向性はうまく捉えるが、依然として自分でコードを見てフィードバックし、満足するまで3〜4回の修正ラウンドを回し、コードベースの主導権を握り続けていると感じる必要がある

    • その3〜4回の修正ラウンドをルールとして定量化し、AGENTSに入れてみるとよい。反復修正の代わりにAGENTSファイルからやり直させて、これで合っているか確認すればよい
    • なるほど。コードベースに対する統制を失いたくないし、LLMが完全に処理できるほど有能だとも信じていないということだ

  • 読むのが非常につらかった
    LLMに文章を書かせる流れから目を覚ますべきだ。文章に多少の価値があっても、砂を噛むような感じがあまりに不快で不要だ

    • 同意する。こういう文章がほぼ400点も取った理由がわからない。こういう低品質な文章にボットが推薦を押しているように見える

  • 自分の最強の手はNix統合だ。ツール、シークレット、環境を用意し、エージェントが自分の環境まで変更できるようになるのは、もうこれなしでどうやって生きるのかわからないほどだ
    開発マシン、CI環境、デプロイ環境がすべて単一のソースから派生し、どのマシンでもコンパイルと実行が常にできる
    Claudeでは/branchと/renameをよく使ってコンテキストのチェックポイントを作り、フォークしてから戻る
    サンドボックス化にはほぼ常にhttps://github.com/nix-tools/bubbleboxを使っている。Numtideのclaudeboxを一般化しつつ、いくつか修正と機能追加をしたもので、DockerランタイムなしでClaudeを常にDockerコンテナ内で動かすのに近い。WSLとnix-darwinでもよく動く

    • そのNixコードは意味のある構造が不足していてひどいし、実験的なflakes経由でしか使えないように見える
    • 似たように使っている。Codexがプロジェクトごとのflake.nixを管理し、すべてのテストにnix developを使う。個人的な利便性のためにはnix-direnvを使い、ある時点ではdockerfileやほかのデプロイ資産も生成させる
      Codexは私よりnixがずっと得意だ
    • エージェントに専用のVPSを1台そのまま与えた。Nixより高くつくかもしれないが、とても簡単だった
    • Nixの複雑さが嫌なら、Miseが悪くない折衷案だ
    • 自分はただDockerを使っているが、特に欠けているものがあるとは感じない

  • こういう設定でClaudeが作ったコードベースがあって、たとえばClaudeが8時間ダウンしたらどうなるのか？ そのコードベースを効率的かつスムーズに引き継いで生産的に作業できるのか？

    • 常時オンラインのソフトウェア群についてなら、どこにでも同じ質問ができるし、エージェントベースの開発フローに進むほどもっともな質問になる
      CADが落ちたら製図板に戻ることはできるが、ずっと遅くなるのと似ている
      自分のワークフローでは、Claudeとペアで計画するとき、機能仕様書1本に30〜60分使う。Claudeがダウンしたら自分で仕様書を用意しておき、戻ってきたらすばやく見直してからコーディングのフローを呼び出せばよい
    • 質問が上がって1時間後に返信を読んでみたが、結論はできないに近い
    • 人が病気になったり休暇に入ったりした場合に似ている気がする。チームの別の人が1日くらい引き継げるかもしれないが、現実的にはその人が戻るまでそのまま止まる可能性が高い
    • AIはスキルを補強するものであるべきだ。AIが落ちたときに最初に別のプロバイダのサブスクを買うことを考えるなら、技術力の問題かもしれない。もちろん自分も毎日そうなるのではと怖い
    • 朝起きたら車のエンジンがかからなかったらどうする？ 歩いて出勤するのか？

  • 正しい挙動をコンテキスト依存にするやり方はうまく機能しない。AIエージェントが言われた通りに動かず、延々と格闘することになる
    この点ではどのAIエージェントもいまひとつで、ユーザー自身がガードレールを作らなければならない。よりよい解決策を研究している人がいないように見えて不穏だ

    • これが解決可能だと信じる理由をまだ見ていない
      LLMの最悪な点は、チューリングテストに合格できるせいで、人々に洗練された統計モデルではなくアシモフ風のロボットを手にしているかのように信じさせてしまうことだ
      指示に従えたり、指示とコンテンツを分離できたりするはずだと感じるが、実際に起きているのはそういうことではない

  • 開発ワークフローの指針はCLAUDE.mdに入れるより、可能な限り決定的なものをpre-commitとスクリプトに置く
    エージェントは不安定で、typecheck、テスト、lintのような手順をよく飛ばすので、pre-commitで常に実行されるようにし、Claudeにコミットを任せるなら修正せざるを得ないようにしている
    コミットメッセージもCodexとClaudeのどちらもあまりうまく書けないので、type(scope): message形式、72文字制限、本文に何を/どうやって/なぜを自然言語で書くこと、実際のgit diffを読み直してから書くこと、git commit -F - <<'EOF'の形でコミットすること、といった指針をユーザーのCLAUDE.mdに入れてある
    これがないと、本文を長い一文で書いたり、改行を直せと言うと実際の改行ではなく\n文字だけを挿入したりしていた
    また、VOCABULARY.mdも有用だ。エージェントが私の言った“thing”を別の対象だと推測することが多いので、特定の単語が何を意味するかについてClaudeと私の認識を揃えられる

    • ClaudeにVOCABULARY.mdをどう知らせているのか気になる。自動で見つけるのか？
    • Claudeの語彙を使うほうがもっと単純ではないか？ これを使う良いケースがあまり思い浮かばない
    • ここまで来ると、退屈な部分は決定的なオーケストレーションスクリプトをいくつか書いて自動化し、コードは自分で書くほうがよくないかと思う。なぜこの驚異のクソ機械を動かすのに時間を無駄にしているのかわからない

  • ここ数週間で、実行環境とモデルは、ただ指示するだけでやり遂げられる地点まで来たように思える
    plan modeやsuperpowersや他のskillを使うことはできるが、どうせ結果をレビューするのなら、なぜばかばかしいほど大量のMarkdownファイルを経由せずに、コードと直接向き合って作業しないのか分からない

    • コード生成に使う仕様ファイルがあるのは良いことだ。より簡潔で、アプリケーションが何をすべきか理解しやすい
      AIエージェント以前は要件と複雑な関係にあり、すべての開発者が更新するわけではなかったので、ある挙動の基準が仕様なのかコードなのか分からなくなることがよくあった
    • ここ数週間でClaudeをだんだん信用しなくなってきた。言えば何かはやるが、実際に見ると手を抜き、検証ではなく仮定に基づいて作業し、見落としも多い
      テストですら、実際には何もテストしていないテストを書くことがよくある