1. インタビュー一覧（中心ソース）
Boris Cherny — Claude Code 共同生みの親 / Head of Claude Code
| タイトル | 出演先 | 日付 | リンク |
|---|
| Building Claude Code with Boris Cherny | The Pragmatic Engineer | 2026-03-04 | YouTube / 全文 |
| Inside Claude Code With Its Creator | Y Combinator Startup Podcast | 2026-02-17 | YouTube |
| Head of Claude Code: What happens after coding is solved | Lenny's Podcast | 2026-02-19 | Lenny's |
| Claude Code: Anthropic's Agent in Your Terminal | Latent Space | 2025-05-07 | Latent.Space |
| Agentic coding with Claude Code creator | Bessemer Venture Partners | 2025-08-18 | YouTube |
参考: howborisusesclaudecode.com（Boris 自身による 13 の実践 Tips）
Dario Amodei — Anthropic CEO / 共同創業者
| タイトル | インタビュアー | 日付 | リンク |
|---|
| #452 Anthropic CEO on Claude, AGI & Future | Lex Fridman | 2024-11-11 | lexfridman.com |
| How Claude Code Was Actually Developed | Dwarkesh Patel | 2026-02-17 | rosetta.to |
| AI Is Closer Than You Think | Nikhil Kamath | 2026-03-02 | 要約 |
Anthropic 公式ドキュメント（裏付け）
2. Boris Cherny が繰り返し強調する 3 つの核心メッセージ
A. Coding is Solved — 競争優位は「検証・意思決定・アーキテクチャ判断」へ
"100% of my code is written by Claude Code. I haven't edited a single line by hand since November."
— Lenny's Podcast (2026-02-19)
Boris は「エンジニアリングのスキルセットが根本的に変わっている」と複数番組で繰り返す。手書きコードの能力よりも「何を Claude に任せ、何を自分で判断するか」の設計が重要。Boris 自身は 1 日 20–30 PR を AI 100% で生成。
B. Build for the frontier — 6 ヶ月先のモデルを前提に作れ
"We build for the model 6 months in the future. That's my advice to founders building on LLMs."
— Y Combinator (2026-02-17)
Claude Code 初期、Claude のコード生成能力は 10% しかなかったが、Boris は「6 ヶ月後に良くなると信じて」CLI を作り続けた。今の苦手領域こそ将来の強者領域。
C. Claude Code は Unix 的な汎用ツール — グラフィカル UI を作らなかった理由
"Claude Code is not a product as much as it's a Unix utility."
— Latent Space (2025-05-07)
ターミナル第一の理由: Bash / Git / ファイルシステムとの自然な統合。カスタム skill / hook / MCP で各チームが自分のワークフローを組める拡張性を最優先。
3. Boris の具体的ベストプラクティス（実践レベル）
CLAUDE.md 運用
- git にチェックインし、週に複数回更新する。 Claude が誤った直後に CLAUDE.md に追記する習慣
- 200 行以下に保つ（プロジェクト固有ルールのみ）。共通知識は別ファイル（
knowledge/ 等）へ
- 例: 「bun を使う（npm ではない）」「enum 禁止、string literal union を使う」
- 公式ガイドはさらに厳しく 100 行が理想、300 行が上限（毎セッション読み込まれるため）
並列エージェント運用（最大の生産性ロック解除）
- 3〜5 個の git worktree を同時実行
- 各 worktree に独立セッション（同じ CLAUDE.md を参照）
- Branch 分離で context 汚染なし
- 1 日 20–30 PR が現実的（全て AI 生成）
Plan Mode + One-shot 実行
- 複雑タスクは 必ず Plan Mode（Shift+Tab）で開始
- Plan が良ければ「One-shot execution」で完了率が大きく上がる
- 検証可能性が Plan の品質を 2–3 倍改善する
Sub-agents は「特化型」にせよ
- 一般的な肩書（"QA engineer" "backend engineer"）ではなく、タスク特化型に分けると効果が出る
- 例:
code-simplifier / verify-app / build-validator / code-architect
- Sub-agent で検証 → main agent の context 圧迫なし
検証ループが品質の最大因子
- テスト / UI 確認 / コンソール確認の 決定論的ループを Claude に与える
- Claude が自動検証 → フィードバック → 修正の 3 段回路
- 個別検証より 2–3 倍の品質向上
Permissions / MCP 活用
- Pre-approve で permission prompts を削減（ls / git status 等は白リスト、rm / DROP は都度確認）
- Chrome DevTools console を MCP で見える化
- 背景検証 + ユーザー質問（AskUserQuestion tool）の並列処理
4. Dario Amodei が語った Claude Code / LLM 活用論
Claude Code 誕生の経緯（Dwarkesh Patel, 2026-02-17）
"Around the beginning of 2025 I said I think the time has come where you can have non-trivial acceleration of your own research if you're an AI company by using these models. But we need an interface, we need a harness to use them."
社内利用 → Product-Market Fit 観測 → 外部公開、というフローで誕生。「自分たちが開発し、自分たちが最も使うため、フィードバックループが回る」ことを優位性として強調。
プログラマー職の未来（Nikhil Kamath, 2026-03-02）
"Coding is going away first. The broader task of software engineering will take longer.
The elements of design, knowing what the demand is, managing teams of AI models. Those things may still be present."
"If AI handles 95% of your job, the 5% you contribute gets amplified because you're directing 100% of the output."
LLM の「正しい使い方」
| 推奨される姿勢 | Dario の発言 |
|---|
| セットアップが結果を分ける | "People who set it up properly are getting dramatically different results than people who treat it like a chatbot." |
| 判断力が長期的価値 | "Judgment that evaluates AI output" は今後も必要 |
| 残る仕事 | "Work that requires touching the physical world / Roles built on real human trust and relationships" |
タイムライン的見通し
- 既に進行中: AI が 90% のコードを書く状況
- 1–2 年以内: 100% の end-to-end SWE タスクを AI が処理
- 生産性向上: Anthropic 内部で 6 ヶ月前は 5%、現在 15–20%、6 ヶ月で倍増ペース
5. Anthropic 公式ドキュメントのベストプラクティス
CLAUDE.md / プロジェクトメモリ
- 100 行以内が理想、300 行以内が上限
- 含めるべき: Bash コマンド、コード規約（デフォルト以外）、アーキテクチャ境界、検証ステップ
- 含めない: チュートリアル、自明な実践、言語の説明
- Git にチェックイン、Claude が間違える度に追記
Subagents / コンテキスト管理
- 調査タスクをサブエージェントに委譲（検索結果・ログ・ファイル内容がメイン会話を汚さない）
- Worktree で 3–5 セッション並列
- サブエージェントは独立コンテキスト → 親に返すのはサマリーのみ
Hooks / 安全性
- PreToolUse / PostToolUse フックで実行時ポリシー適用
- サーバー側で実行されるため、絶対に無効化されない
- 危険なコマンド（
rm / DROP TABLE / .env 上書き）を自動拒否可
Workflow: Explore → Plan → Code → Verify
- Plan Mode で読取専用探索 → 実装前に計画を精密化
- 探索 → 計画洗練 → auto-accept で実装 → 自動検証
- Claude に「検証方法を用意する」 — テスト・型チェック・ビルド
Verification（最優先・公式が明言）
"もし単一のベストプラクティスを 1 つだけ採用するなら、検証を選べ"
- テスト・型チェック・ビルド確認を毎回自動実行
- Claude が失敗時に自己イテレーション
Permissions / Extended Thinking / Context
/permissions で事前許可リスト → 実行時プロンプト削減- ワイルドカード対応:
Bash(bun run *) / Edit(/docs/**)
- 複雑なアーキテクチャ決定では
thinking_mode: high または max
- コンテキスト 70% 超で
/compact を実行
- MCP / Skills は progressive disclosure（必要時のみロード）
6. ユーザー環境への当てはめ（参考）
すでに整備済みの実践
- Reference-First ルール（MEMORY.md 索引参照）
- Multi-Verify（静的 → 整合性 → 動的）
- Plan Mode の必須化（複数ファイル変更時）
- 4 エージェント並列 code-review（worktree 隔離）
- Skill のプログレッシブ開示（healthcare-dev / webapp-deploy 等）
整合性が取れていない可能性のある点
- CLAUDE.md が長くなりがち（公式は 100–300 行推奨）→ 共通ルールを
rules/ に分離する現運用は正しい方向
- Sub-agents の特化度（一般的な肩書ではなくタスク特化）→ 既存エージェントの命名（planner / architect / tdd-guide）はおおむね特化済み
7. Patterns / Notes
Patterns（n 次的観察）
- Boris の「6 ヶ月先のモデルを前提にビルドせよ」は、ユーザーの現在の悩み（コンテキスト管理 / use-server 違反等）が 6 ヶ月後には自動解決される可能性を示唆。今は仕組み投資より「Claude が成長したら陳腐化する仕組み」を作りすぎないバランスが重要
- Dario の「正しくセットアップした人と、チャットボットとして扱う人で結果が劇的に違う」は、ユーザーが既に投資している
rules/ skills/ hooks/ の方向性を強く支持する内容
- 「検証ループが品質の 2–3 倍因子」は、ユーザーの Multi-Verify ルール（
rules/multi-verify.md）の正当性を再確認させる
Notes（ユーザー業務との関連）
- 医療 DX / SaaS 開発のユーザーにとって、Boris の「Plan Mode → One-shot 実行 → 検証ループ」は、Supabase RLS / Firestore Rules のような 整合性確認が必須な領域で特に効果が高い
- ユーザーの
confirmed_count >= 3 昇格フローは、CLAUDE.md を 200 行以下に保つ Boris の運用と整合的
Source: Exa Search × 4 サブエージェント並列調査 / 公式ドキュメント裏付け / 2026-04-28 作成
Markdown 全文: ~/work/exa-results/claude-code-best-practices-interviews-2026-04-28.md