上位エンジニアの
組み立て方
道具を1つずつ覚えたら、最後は「どう組み合わせて1つの仕事の流れにするか」です。このページは、Anthropic公式の知見と、名だたる実務家（Claude Code開発者・著名エンジニア）の実践を調べ上げて要約した、上位1%の組み立て方の総まとめ。誇張ではなく、現場で本当に効いている型だけを集めました。
1まず結論：上位1%の「8つの習慣」
複数の一次情報（公式ドキュメント・開発者・著名実務家）を横断すると、できる人の習慣はほぼ同じ8つに収束します。これが「2割の労力で8割の成果」の核心。難しい機能を覚えるより、まずこの8つです。
① コードより先に計画
Explore→Plan→Code→Commit。先に読んで・計画させ、納得してから実装。公式いわく「いきなり書かせると間違った問題を解きがち」。
② 検証手段を必ず渡す
テスト・ビルド・スクショ。合否が返る仕組みを渡すとAIは自走して直す。開発者いわく「品質が2〜3倍」。最重要の1手。
③ 文脈を容赦なく管理
埋まると精度が落ちる。無関係な作業ごとに /clear、重い調査は子分へ、進捗は外部ファイルへ。
④ 早めに軌道修正
ズレたら即 Esc。2回直して直らなければ /clear して頼み直す（2ストライク則）。長い迷走より新品の一手。
⑤ こまめにコミット
コミットはゲームのセーブポイント。AIが壊しても戻れる。「説明できないコードはコミットしない」。
⑥ 具体的に頼む
曖昧さは修正ループを生む。ファイル名・条件・確かめ方まで添える。「精度の高い指示ほど直しが減る」。
⑦ CLAUDE.mdは小さく
肥大化すると本当のルールが無視される。「消したら間違える？」でふるいにかけ、迷ったら消す。
⑧ 新鮮な目でレビュー
AIは自分が書いたコードに甘い。別セッション／別モデルで「差分だけ」見せてレビューさせる。
2「お願い」の組み立て（プロのプロンプト）
上位エンジニアの頼み方には型があります。基本は ✍️プロンプト術 に、ここでは実戦での組み立てを。
🧱強いお願いの4要素
① 文脈
関係するファイルを @パス で渡す。エラーは全文を貼る／画面はスクショを貼る。
② 具体的なゴール
「何を・どこを・どうなれば完成か」を一文で。曖昧さを残さない。
③ 参考パターン
「HotDogWidget が良い例。この型に倣って」と手本を指す。
④ 検証方法
「実装後に npm test を走らせて、緑になるまで直して」。
# ❌ 曖昧（修正ループを生む） foo.py にテストを足して # ✅ 具体的（文脈・条件・制約・検証） foo.py に、ユーザーが未ログインのときの境界ケースを カバーするテストを書いて。モックは使わない。 書けたらテストを実行して、緑になるまで直して。
SPEC.md に書く → 新しいセッションで実装。公式も「Claude にインタビューさせて仕様化し、新セッションで実行」を推奨。仕様を正確にする時間は、実装を眺める時間より報われる。ultrathink キーワード、または /effort（low/medium/high/xhigh/max）で推論量を上げます（Opus 4.8 は既定で high）。なお「think hard」等の昔の呪文は現行版では特別な効果はありません。※仕様は変わるので公式で確認を。3スキルを「自分のライブラリ」に育てる
上位ユーザーの合言葉：「1日に2回やる作業は、スキルにする」。よく使う頼み方を .claude/skills/ に貯め、再利用できる道具箱を作っていきます。作り方は 拡張§2・ハーネス§4。
🗂️実務家がよく持っている定番
| スキル/コマンド | 役割 |
|---|---|
/commit | 変更を点検し、意味のある単位に分けて、規約に沿ったメッセージでコミット |
/code-review | 手元の差分をレビュー（バグ・品質・簡素化の点検。旧 /simplify の後継）。PRのレビューは /review [PR番号] |
/tdd | Red→Green→Refactor を厳格に進める（テスト先・実装後） |
/fix-issue 123 | Issue番号を渡して修正（$ARGUMENTS の定番） |
/context-prime | セッション開始時に「最低限のリポジトリ構造」だけ読み込む |
/plugin marketplace add owner/repo → /plugin install 名前。個人なら、.claude/ を dotfiles として git 共有するだけでもOK。4ハーネス：プロが回す1本のループ
プロの作業は、結局この1本に集約されます——集める→動く→確かめる→記録を、文脈をきれいに保ちながら小さく回す。組み立ての詳細は 🔧ハーネス実装 に。ここでは「検証」をどこまで強くするかの段階を押さえます。
🪜検証の「強さ」を段階で上げる
- 同じプロンプトで実行させる「実装後に
npm testを走らせて」と頼むだけ。まずはこれ。 - ゴール条件を毎ターン確認
/goalで「テストが緑」を達成条件にし、毎回チェックさせる。 - Stop フックで「通るまで終わらせない」検証が通るまでターンの終了をブロック（§ハーネス§6）。
- 検証サブエージェントに採点させる作った本人とは別の新鮮なモデルに評価させる（自分のコードに甘くならない）。
5エージェント編成：
「読みは分担、書きは1人」
ここがいちばん誤解されやすい勘所。マルチエージェント（複数AIの分担）は万能ではありません。実務家の結論はシンプル——「読む（調査・レビュー）作業は並列に分担、書く（コード生成）作業は1人に集約」。
flowchart TD Q["この仕事は？"] --> R["主に読む
調査・レビュー・移行の下調べ"] Q --> W["主に書く
コードを実装・統合"] R --> R2["✅ 分担OK
子分を並列に走らせ
要点だけ集約"] W --> W2["⚠️ 1人に集約
並列だと噛み合わず壊れる
単一エージェント＋検証が最強"]
📊なぜ？——公式の数字と実務家の証言
分担が勝つ場合
Anthropicの調査システムは、幅広く並列に「調べる」タスクで単一比 +90.2%。ただしトークンは約15倍。「価値の高い仕事」限定。
分担が負ける場合
Anthropic自身が「文脈を共有する必要がある作業＝ほとんどのコーディングには不向き」と明言。Cognition も「書く作業の並列はやめろ」。
🛠️道具の違い（用途で選ぶ）
| 道具 | 性格 | 向き |
|---|---|---|
| サブエージェント | 子分が結果だけ親に返す（会話しない） | 調査・レビューの分担（定番） |
| エージェントチーム実験的 | 仲間同士がタスク板で協調 | 仮説を競わせる調査・横断作業 |
| ワークフロー | スクリプトで多数を確定的に統率 | 大量・反復（/deep-research 等） |
6文脈の経済学（最大の差がつく所）
上位エンジニアが最も執拗にこだわるのがこれ。コンテキストは埋まるほど精度が落ちる（context rot）。だから「いかにきれいに保つか」を仕組みで管理します。
メーターを見る
/context で使用量を可視化。実務報告では5〜6割で劣化を感じ始める。満タンまで粘らない。
/clear と /compact
無関係な作業に移るなら /clear。同じ流れで重くなったら対象を絞って /compact 「APIの変更に集中」。
引き継ぎファイル
HANDOFF.md（目的／進捗／効いた事／効かない事／次の一手）に書き出し → /clear → 新セッションが読んで継続。
本流を子分で守る
「無限探索」（際限ない調査）は子分に逃がし、親の机を汚さない。子分は要点だけ返す。
/compact＋引き継ぎファイル派です（「劣化してから発動するので遅い」）。一方 Anthropic は「要点を安全に残す」と説明。どちらの立場でも安全なのは、重要な状態を外部ファイル＋gitコミットに逃がしておくこと。記憶に頼らない設計が勝ちます。/rename・--resume）をブランチのように使い分けます。7AIは「テストではズルする犯人、設計では新人」
できる人は、AIを盲信しません。2つの場面で「疑ってかかる」のが鉄則です。
テストでは「犯人」
AIは追い込まれると答えをハードコードして「成功！」と宣言しがち。同じAIに開発と検証を任せると「テストの通し方」を覚えてしまう。
設計では「新人」
頼んでない機能を盛る・1000行書く・「おっしゃる通り！」と追従。ある実例では「1サービス直して」が21中17を破壊。
🛡️だからプロはこう守る
- テストを先にコミット（契約にする）先に失敗するテストを書いてコミット→以後それを変えさせない。Anthropic も「テストの削除・改変は許容不可」。
- 開発役と検証役を分ける実装したAIとは別の新鮮な文脈で検証・レビューさせる。
- 「最も単純に動くもの」を求める過剰実装を防ぐ。「批判するなら何を言う？」とあえて反論させる。
- 差分を必ず自分で読む「もっともらしさ」は罠。説明できない変更はシップしない。
8自動化：人なしで回す（ヘッドレス & CI）
定型作業は人が見ていなくても回る形に。claude -p でスクリプトやCIに組み込みます。手順は ハーネス§10、ここではプロの定番パターンを。
AIをlintにする
git diff | claude -p "誤字linterとして指摘して"。差分を渡すだけなので権限も最小。
GitHubで @claude
Issueで @claude と呼ぶ → ブランチ作成・修正・テスト・PR作成まで自動。
「CI直して」
「mainのCIが落ちてる。原因を調べて直し、commit&pushして、直ったか確認して」を専用worktreeで。
--max-budget-usd で費用上限、②--allowedTools（や --permission-mode）で道具を限定、③フックには「失敗したらどうするか」を明記。これを書かないと、AIは「フック失敗を確認しました」と言って次へ進んでしまうのが定番の落とし穴です。9上位1%が避けるアンチパターン
「やってしまいがちな罠」を、実務家の失敗談から集めました。逆に言えば、これを避けるだけで上位に近づけます。
計画なしの大改造
いきなり全部やらせる。→ 計画→小さく→検証に分ける。
検証なしでシップ
「もっともらしい」を信じる。→ 差分を読む・テストを出させる。
巨大CLAUDE.md
ルールを盛りすぎて全部無視される。→ 小さく、強制はHooksへ。
テスト削除を許す
「通すために消す」を放置。→ 先にコミット＋保護。
マルチエージェント過信
書く作業まで並列に。→ 読みは分担・書きは1人。
自動圧縮を盲信
大事な文脈を失う。→ 外部ファイル＋gitに逃がす。
ホストで権限スキップ
--dangerously-skip-permissions を母艦で。→ コンテナ/VM限定。
3つ揃えると危険
私的データ＋不審な入力＋外部送信（lethal trifecta）は同時に揃えない。
ANTHROPIC_API_KEY が設定されていると、Pro/Maxにログイン中でもAPI従量課金が優先されます。サブスク枠で使いたいなら未設定のままに。（詳しくは ⑤コスト・安全）1030日マスタリー・ラダー
全部いっぺんは無理。4週間で1段ずつ上るロードマップにしました。各週「1つ身につける」だけでOK。
- 第1週：基礎の型計画→検証→こまめコミットを体に入れる。ズレたら Esc、2回ダメなら
/clear。まずこれだけ。 - 第2週：記憶と頼み方
CLAUDE.mdを小さく1枚。よく使う頼み方をスキル数個に。プロンプトの4要素を意識。 - 第3週：足場を組む「編集後に自動整形」などHooksを1つ、検証ループを常設、大きい作業は
HANDOFF.md。敵対的レビューを試す。 - 第4週：分担と自動化調査・レビューをサブエージェントに分担。
claude -pや GitHub@claudeで自動化を1つ。
11出典・一次情報（ディープリサーチの素）
このページの土台になった一次情報です。料金・仕様・機能は変わります。選定・導入の前に必ず公式で最新を確認してください。まとめは ⑧公式リソース にも。
🏛️Anthropic 公式
- Claude Code ベストプラクティスcode.claude.com/docs/en/best-practices（計画・検証・文脈・CLAUDE.md の核）
- 文脈エンジニアリングEffective context engineering for AI agents
- 長時間エージェントの足場Effective harnesses for long-running agents
- マルチエージェント調査システムHow we built our multi-agent research system（+90.2% / 15倍トークンの出典）
- 効果的なエージェント設計Building effective agents（オーケストレーター-ワーカー等）
👷実務家・現場の知見（外部・英語）
- Boris Cherny（Claude Code 開発者）開発者本人のワークフロー（計画モード・検証で品質2〜3倍）
- Simon WillisonDesigning agentic loops ／ The lethal trifecta
- Addy OsmaniAI coding workflow（セーブポイント・70%問題）
- Cognition / LangChain（マルチエージェント論争）Don't Build Multi-Agents ／ How and when to build multi-agent systems
- 定番スキル・コマンド集awesome-claude-code（実在のコマンド/スキルの宝庫）