Anthropic社の方々が「Claudeをどう使っているのか」を発信されているものを8個にまとめてみました。
※本記事はAnthropic公式ブログ、Boris Chernyのポッドキャスト等に基づいています（詳細は末尾の参考リンク一覧）。
1. 「コンテキストエンジニアリング」— 指示の質より環境の設計、複利的エンジニアリングへ
2026 Agentic Coding Trends Reportでは、「 プロンプトエンジニアリングからコンテキストエンジニアリングへの移行 」というパラダイムシフトが起きていると指摘しています。プロンプトが「今回の指示」であるのに対し、コンテキストは「Claudeが判断に使えるすべての情報」を指します。
具体的には、以下のような要素がコンテキストを構成しています。
| コンテキスト要素 | 役割 | 効果 |
|---|---|---|
| CLAUDE.md | プロジェクトの規約・パターン・失敗事例を記録 | 毎セッション自動で参照される |
| カスタムコマンド | 頻出ワークフローをテンプレート化 | 指示コストが下がる |
| Hooks | ツール実行時に自動処理を差し込む | 品質チェックが確定的になる |
| Task Diary | セッション間の学びを記録・蓄積 | 知識が複利的に積み上がる |
ポイントは、これらが一回のプロンプトの工夫ではなく、 プロジェクト全体の「環境」として蓄積される ことです。調べていくうちに気づいたのは、これらのテクニックに共通するパターンがあるということ — ポッドキャストではこの考え方を「 複利的エンジニアリング 」（筆者訳、原文では compounding という表現）と表現していました。使えば使うほどClaudeが賢くなる構造だと言えそうです。
2. コードを書く前の戦略を使い分ける
Claude Codeに、いきなり「実装して」は効率が悪いとのことです。ただし、計画の立て方にも複数のアプローチがあり、 ゴールが明確なときと、何が必要かまだわからないときでは戦略が異なります 。
ゴールが明確なとき → Plan Mode
"If my goal is to write a Pull Request, I will use Plan mode, and go back and forth with Claude until I like its plan. From there, I switch into auto-accept edits mode and Claude can usually 1-shot it."
— Boris Cherny
Plan Mode（Claude Codeの計画モード）では、コードを一切書かずに計画だけを練ります。Chernyは計画に納得するまで何度もやり取りし、固まったらauto-acceptモードに切り替えて一発で実装しています。
# 例：Plan Modeでの進め方
1. "○○機能を実装したい" とClaude Codeに伝える
2. Plan Modeに切り替える（Shift+Tab）
3. Claudeが計画を提案 → "この部分は△△のほうがいい" とフィードバック
4. 計画が固まったら auto-accept モードで実装
何が必要かわからないとき → 使い捨てプロトタイプ
ゴールが曖昧なときは、逆にまずコードを書いてもらいます。
- 細かい仕様を決めずにClaude Codeに実装してもらう
- 出力を観察して「何が足りないか」を把握する
- その知見をもとに正式な仕様を書く
- 仕様を渡して本番の実装に取りかかる
最初の実装は破棄する前提です。目的はコードではなく、 「自分が本当に何を求めているか」を発見すること です。一見回り道に見えますが、最終的な品質が大幅に向上すると語られています。
どちらの場合でも → 成功基準で指示する
2026 Agentic Coding Trends Reportでは、Plan Modeでも使い捨てプロトタイプでも共通する原則として、「 成功基準の定義はステップごとの指示よりも重要 」と強調されています。「このファイルを編集して、この関数を追加して...」と手順を教えるよりも、「テストが全部通ればOK」「このAPIのレスポンスがこの形式になっていればOK」のように成功基準を与えたほうが良い結果が出ると紹介されています。
参考：Every.to Podcast Transcript、2026 Agentic Coding Trends Report
3. 並列セッション — 自分の分身を複数立ち上げる
1つのセッションで足りないなら、増やせばいい。Boris Chernyは日常的に ローカル5セッション + リモート5〜10セッション を同時に動かしています。
Chernyが語る並列セッションの運用はこうです。
- 各ローカルセッションは 独立したgit checkout を使う（branchやworktreeではなく）
- セッションの一部は途中で破棄される — それは想定内
- 競合を避けるため、物理的にディレクトリを分離している
# 例：セッションごとに独立したcheckout
~/projects/myapp-session1/
~/projects/myapp-session2/
~/projects/myapp-session3/
これは「自分の分身を複数立ち上げる」ような感覚とのことです。1つのセッションが行き詰まっても、他のセッションは進行し続けます。
4. カスタムスラッシュコマンド — 繰り返しの自動化
公式ブログによると、スラッシュコマンドを最も活用しているチームの一つが Security Engineeringチーム です。
Boris Chernyが毎日使うコマンド：
# .claude/commands/commit-push-pr.md の中身（概要）
- git statusを事前計算
- lintを実行
- コミットメッセージを生成
- pushしてPRを作成
- やり取りを最小化
"Claude and I use a /commit-push-pr slash command dozens of times every day."
— Boris Cherny
構成はシンプルです。
-
.claude/commands/ディレクトリにMarkdownファイルを配置 - 自然言語でワークフローを記述
-
$ARGUMENTSで引数を受け取る仕組み
コマンドのポイントは、git statusのような事前情報を含めておくことです。Claudeが自分で情報を取得するやり取りが減り、実行速度が上がります。
5. Hooks — Claudeの「うっかり」をゼロにする仕掛け
HooksはClaude Codeの動作の特定タイミングで、決められたコマンドを自動実行する仕組みです。
Boris Chernyが使っているPostToolUse Hook：
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [{
"type": "command",
"command": "bun run format || true"
}]
}
]
}
}
ファイルを書き込み・編集するたびに自動フォーマットが走ります。CIでのフォーマット不一致による失敗がなくなります。
Anthropic社内で使われている主なHook：
| Hook | タイミング | 用途 |
|---|---|---|
PostToolUse |
ツール実行後 | 自動フォーマット |
SessionStart |
セッション開始時 | 開発コンテキストの自動読み込み |
PreCompact |
コンテキスト圧縮前 | トランスクリプトのバックアップ |
Stop |
ターン完了時 | 「テストが通るまで続行」の強制 |
特にStop Hookは注目に値します。「テストが通らなければ作業を続行」というルールを設定すると、確率的なモデルから 確定的な成果 を引き出せます。Hooksはまだあまり知られていない機能ですが、Anthropic社内ではすでに実用的に使用されているようです。
6. Subagents — AIワーカーを並列で動かす
ここまでは「人間1人 + Claude 1セッション」の話でした。では、Claudeを複数同時に走らせたらどうなるか。
一部のAnthropicエンジニアは、まとまった規模のコード改修にSubagent（サブエージェント）パターンを活用しています。
基本パターン：タスクリスト → 並列実行
Main Agent:
1. マイグレーションのTodoリストを作成
2. Subagent A: CLAUDE.md準拠チェック
3. Subagent B: gitの履歴からパターンを検索
4. Subagent C: 明らかなバグをスキャン
5. Subagent D: 偽陽性のチェック
6. 結果を統合 → マイグレーション実行
上級パターン：対立検証（Opponent Processor）
タスク: アーキテクチャの意思決定
Subagent "Engineer": アプローチAを支持
Subagent "Auditor": アプローチAに異議、Bを推奨
Main agent: 議論を統合 → より良い判断
効果: 「非相関なコンテキストウィンドウ」→ 偏りの少ない結果
異なる視点を持つSubagentに意図的に議論させることで、単一の視点では見逃しがちなリスクを発見できます。以前書いた「性格で分けるAgent Teams」の考え方と繋がる部分があり、Anthropic社内で実務のまとまった規模の改修で運用されている点が興味深く感じました。
7. 検証フィードバックループ — Claudeに検証手段を与える
"I don't feel bad asking anyone to write tests anymore...probably close to 100 percent of our tests are just written by Claude."
— Boris Cherny
ポッドキャストで「最も効果の高いテクニック」として紹介されているのが、Claudeに検証手段を与える ことです。
Boris Chernyの実践：
- Claude Chrome拡張を使い、変更のたびにブラウザを開いてUIをテスト
- テストが通るまで自動的にイテレーション
- これだけで最終品質が2〜3倍向上
TDD（テスト駆動開発）との相性：
| ステップ | 担当 |
|---|---|
| 1. テストケースの設計 | 人間（期待する入出力を定義） |
| 2. テストコードの記述 | Claude |
| 3. 実装コードの記述 | Claude |
| 4. テスト実行・修正 | Claude（フィードバックループ） |
| 5. レビュー | 人間 |
人間がやるのは「何をテストするか決める」ことと「最終レビュー」だけ。Security Engineeringチームでは、以前の「設計→雑なコード→リファクタ→テスト諦め」というフローが、「擬似コード→TDD→信頼性の高いコード」に変わったと語られています。
8. Task Diary — セッションが終わっても知識が消えない方法
Claude Codeのセッションは、終了すればコンテキストが消えます。前回のセッションで学んだことを、次のセッションにどう引き継ぐか。
一部のAnthropicエンジニアが実践しているのが、タスク完了のたびにClaude Codeに「日記エントリ」を書いてもらう方法です。何を試みたか、何がうまくいったか、何が失敗したか、その理由は何か — これらを記録してもらいます。
蓄積された日記をエージェントに統合・分析してもらうことで、「観察結果（observations）」として昇華させます。CLAUDE.mdと組み合わせると、 複利的に知識が蓄積 されていきます。
セッション1: Task Diary → 学び3つ
セッション2: Task Diary → 学び2つ + 前回の教訓を活用
セッション3: 蓄積された学びをCLAUDE.mdに統合
→ 以降、全セッションが賢くなる
これはまさに冒頭で紹介した「コンテキストエンジニアリング」の具体的な実践です。セッションごとに消えるコンテキストを、意図的に蓄積・再利用する。ここはもっと深掘りしたいテーマだと感じました。
まとめ：Anthropicではこう分担しているらしい
Anthropic社員のテクニックに共通しているのは、「 Claudeをコード生成機ではなく、思考パートナーとして扱う 」という考え方ではないかと感じています。
Anthropicでは、こんな感じで人間とClaudeの役割を分けているそうです。
| 人間の仕事 | Claudeの仕事 |
|---|---|
| アーキテクチャの判断 | 実装 |
| 何をテストするか決める | テストコードの記述 |
| レビューと方向性の修正 | 調査・探索 |
| ビジネス要件の定義 | 繰り返しの多い作業 |
チームや状況によって正解は変わってくるとは思いますが、一つの参考にはなるのではないでしょうか。
コンテキストエンジニアリングで環境を整え、Hooksで品質を自動化し、Subagentsで並列処理し、Task Diaryでセッション横断の知識を蓄積する — すべてが相互に強化し合う「複利的エンジニアリング」の構造になっているように感じられます。
参考リンク一覧
公式ソース
- How Anthropic teams use Claude Code（公式ブログ）
- How Anthropic teams use Claude Code（PDF版）
- 2026 Agentic Coding Trends Report
- Claude Code Hooks Guide
- Claude Code Skills Documentation
Discussion