QUOTES — 原典のことばだけで読む全体像
Anthropic 自身の言葉だけを並べたページ。引用ブロックの中はすべて原典の文で、私の文章は見出しとこの前置きに限る。 上から順に読むと、個々の文書に入る前に何が問題で、何が答えとされているかが通る。
原文と訳を併記しているのは、このリポジトリ全体の方針と同じ理由（原典と照合できるようにするため）。
末尾のリンクを辿ると、その主張の文脈と条件が sources/ にある。
選び方: sources/ にある引用から、その文書を代表し、かつ他の文書と繋がるものを選んだ。
網羅ではないので、数字や判断の分岐が要るときは OVERVIEW.md、手順が要るときは topics/ へ。
1. 何を相手にしているのか
Claude Code is the harness; Claude is the model inside it. Claude Code が harness であり、Claude はその中にいるモデルである。 — glossary
The loop adapts to what you ask. このループは、あなたが何を頼むかに応じて形を変える。 — how-claude-code-works
You’re part of this loop too. あなた自身も、このループの一部である。 — how-claude-code-works
2. すべてを縛る一つの制約
Most best practices are based on one constraint: Claude’s context window fills up fast, and performance degrades as it fills. ほとんどのベストプラクティスは、ひとつの制約に基づいている。Claude の context window はすぐ埋まり、埋まるにつれて性能が落ちる、という制約である。 — claude-code-best-practices
A larger context window allows the model to handle more complex and lengthy prompts, but more context isn’t automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot. This makes curating what’s in context just as important as how much space is available. context window が大きいほど、モデルは複雑で長いプロンプトを扱えるようになる。だがcontext は多いほど自動的に良くなるわけではない。トークン数が増えるにつれて正確性と再現率は劣化する。これは context rot として知られる現象である。そのため、context に何を入れるかを選ぶことは、どれだけの余地があるかと同じくらい重要になる。 — context-windows
The context window is a public good. context window は公共財である。 — agent-skills-best-practices
Like humans, who have limited working memory capacity, LLMs have an “attention budget” that they draw on when parsing large volumes of context. working memory の容量が限られている人間と同じく、LLM も大量の context を解釈するときに引き出す「attention budget」を持っている。 — effective-context-engineering-for-ai-agents
This lightweight approach means you can install many Skills without context penalty: until a Skill is triggered, only its name and description occupy context. この軽量な仕組みのおかげで、context のペナルティなしに多数の skill を入れられる。skill が起動されるまでは、その名前と description だけが context を占める。 — agent-skills-overview
3. まず単純に
When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. LLM でアプリケーションを作るときは、可能な限り単純な解を見つけ、必要になったときにだけ複雑さを増すことを勧める。 — building-effective-agents
The right amount of complexity is the minimum needed for the current task. 適切な複雑さの量とは、いま取り組んでいるタスクに必要な最小限である。 — claude-prompting-best-practices
More tools don’t always lead to better outcomes. ツールが多いほど良い結果になるとは限らない。 — writing-tools-for-agents
Starting over often has a higher success rate than trying to fix Claude’s mistakes. やり直すほうが、Claude の間違いを直そうとするより成功率が高いことが多い。 — how-anthropic-teams-use-claude-code
The best prompt isn’t the longest or most complex. It’s the one that achieves your goals reliably with minimum necessary structure. 最良のプロンプトは、最も長いものでも最も複雑なものでもない。必要最小限の構造で、目的を確実に達成するものである。 — best-practices-for-prompt-engineering
Find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome. 望む結果が得られる見込みを最大にする、高信号なトークンの最小集合を見つけよ。 — effective-context-engineering-for-ai-agents
4. 読む主体と、受け取る主体を分ける
Use one when a side task would flood your main conversation with search results, logs, or file contents you won’t reference again. 二度と参照しない検索結果・ログ・ファイルの中身で本流の会話が溢れそうなとき、subagent を使え。 — sub-agents
The subagent read 6,100 tokens of files. You got a 420-token result. That’s the context savings. subagent は 6,100 トークン分のファイルを読んだ。あなたが受け取ったのは 420 トークンの結果である。これが context の節約分だ。 — context-window
Multi-agent systems work mainly because they help spend enough tokens to solve the problem. The essence of search is compression: distilling insights from a vast corpus. multi-agent システムが効くのは、主に問題を解くのに十分なトークンを費やせるようになるからである。検索の本質は圧縮であり、膨大なコーパスから洞察を抽出することである。 — multi-agent-research-system
Three focused teammates often outperform five scattered ones. 焦点の定まった3人の teammate は、散漫な5人を上回ることが多い。 — agent-teams
5. ツールはインターフェースである
Agent-tool interfaces are as critical as human-computer interfaces. エージェントとツールの間のインターフェースは、人間とコンピュータのインターフェースと同じくらい重要である。 — multi-agent-research-system
Provide extremely detailed descriptions. This is by far the most important factor in tool performance. 極めて詳細な説明を書け。これがツールの性能を左右する、群を抜いて最も重要な要因である。 — define-tools
One way we improved performance was to “error-proof” our tools. 性能を高めた方法のひとつは、ツールを「間違えにくく」することだった。 — swe-bench-sonnet
Agents should discover and load tools on-demand, keeping only what’s relevant for the current task. エージェントはツールを必要に応じて発見してロードし、いまのタスクに関係するものだけを保持すべきである。 — advanced-tool-use
6. エージェント向けに書く
Building a skill for an agent is like putting together an onboarding guide for a new hire. エージェントのために skill を作ることは、新しく入る人のためのオンボーディング資料をまとめることに似ている。 — equipping-agents-for-the-real-world-with-agent-skills
Treat CLAUDE.md as the place you write down what you’d otherwise re-explain. CLAUDE.md は、書いておかなければ何度も説明し直すことになるものを書き留める場所だと考えよ。 — memory
The more specific and concise your instructions, the more consistently Claude follows them. 指示が具体的かつ簡潔であるほど、Claude はより一貫してそれに従う。 — memory
Put guardrails in hooks. An instruction like “never edit
.env” in CLAUDE.md or a skill is a request, not a guarantee. APreToolUsehook that blocks the edit is enforcement. **ガードレールは hook に置け。**CLAUDE.md や skill に書いた「.envは絶対に編集するな」という指示はお願いであって、保証ではない。編集を止めるPreToolUsehook が強制である。 — features-overview
A fresh session matters because leftover context from authoring the skill will mask gaps in the written instructions. まっさらなセッションで試すことが重要なのは、skill を書いたときの context が残っていると、書かれた指示の抜けが覆い隠されてしまうからである。 — skills
7. プロンプト
Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. Claude は、優秀ではあるがあなたの規範や仕事の流れを知らない新入社員だと考えよ。 — claude-prompting-best-practices
Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they’d be confused, Claude will be too. そのタスクの前提をほとんど知らない同僚にプロンプトを見せ、その通りにやってもらえ。その人が戸惑うなら、Claude も戸惑う。 — claude-prompting-best-practices
Claude is smart enough to generalize from the explanation. Claude は、その説明から一般化できるだけの賢さを備えている。 — claude-prompting-best-practices
Provide examples of your desired output. This is more effective than abstract instructions. 望む出力の例を示せ。抽象的な指示よりも効果的である。 — increase-consistency
Explicitly give Claude permission to admit uncertainty. This simple technique can drastically reduce false information. 「わからない」と認めてよいと、Claude に明示的に許可せよ。この単純な手法で誤情報を劇的に減らせる。 — reduce-hallucinations
8. thinking と effort
Tuning effort is often a better lever than switching models. effort を調整するほうが、モデルを乗り換えるよりも効くレバーであることが多い。 — choosing-a-model
You don’t set a thinking token budget. Two controls bound cost: **thinking のトークン予算を自分で設定するのではない。**コストを縛るのは次の2つの制御である。 — thinking-steering-and-cost
You’re still charged for the full thinking tokens. Omitting reduces latency, not cost. それでも thinking トークンの全量が課金される。省略が減らすのはレイテンシであって、コストではない。 — thinking
If you want Claude to think less often, lower the effort level before reaching for prompt-based steering. Claude が考える頻度を下げたいなら、プロンプトによる誘導に手を伸ばす前に effort レベルを下げよ。 — thinking-steering-and-cost
9. 測ってから動かす
having a good evaluation set is the most important step in the process 良い evaluation セットを持つことが、この過程で最も重要なステップである — choosing-a-model
Create evaluations BEFORE writing extensive documentation. 大量のドキュメントを書く「前」に evaluation を作れ。 — agent-skills-best-practices
Grade what the agent produced, not the path it took. エージェントが辿った経路ではなく、生み出した成果物を採点せよ。 — demystifying-evals-for-ai-agents
A good task is one where two domain experts would independently reach the same pass/fail verdict. 良いタスクとは、2人のドメイン専門家が独立に判定して同じ合否に至るようなタスクである。 — demystifying-evals-for-ai-agents
Owning and iterating on evaluations should be as routine as maintaining unit tests. evaluation を自分たちで保有し改善し続けることは、ユニットテストの保守と同じくらい日常的であるべきだ。 — demystifying-evals-for-ai-agents
10. ベンチマークを疑う
A few-point lead might signal a real capability gap—or it might just be a bigger VM. 数ポイントの差は、実際の能力差を示しているのかもしれない。あるいは単に VM が大きかっただけかもしれない。 — infrastructure-noise
This report will, itself, likely contribute to the problem. この報告書は、それ自体がおそらく問題の一因になるだろう。 — eval-awareness-browsecomp
11. 封じ込めが先、誘導は後
Design for containment at the environment layer first, then steer behavior. まず環境レイヤーでの封じ込めを設計し、その上で振る舞いを誘導せよ。 — how-we-contain-claude
Effective sandboxing requires both filesystem AND network isolation—neither alone is sufficient. 実効性のある sandbox にはファイルシステムとネットワークの両方の隔離が要る。どちらか一方では不十分である。 — claude-code-sandboxing
The weakest layer is the one you built yourself. 最も弱い層は、自分で作った層である。 — how-we-contain-claude
Tool output is an attack surface even when the tool is trusted. ツールの出力は、そのツール自体が信頼できる場合でも攻撃面である。 — how-we-contain-claude
Deliver third-party content to Claude inside
tool_resultblocks, never insystemprompts or plain usertextblocks. Claude is trained to treat instructions that appear inside tool results with appropriate skepticism. 第三者由来のコンテンツはtool_resultブロックに入れて Claude に渡し、systemプロンプトや素の usertextブロックには決して入れるな。Claude は tool result 内に現れる指示を、相応に疑ってかかるよう訓練されている。 — mitigate-jailbreaks
bypassPermissionsoffers no protection against prompt injection or unintended actions.bypassPermissionsは、prompt injection や意図しない動作に対して何の防御にもならない。 — permission-modes
12. 長く走らせる
the agent tended to try to do too much at once—essentially to attempt to one-shot the app エージェントは一度にやりすぎようとする傾向があった。要するにアプリを一発で書き切ろうとするのである。 — effective-harnesses-for-long-running-agents
Rather than one-shotting implementations, agents work on only one feature at a time. This proved critical to addressing the agent’s tendency to do too much at once. 実装を一発で書き切らせるのではなく、エージェントには一度に1機能だけを担当させる。これはエージェントが一度にやりすぎる傾向に対処するうえで決定的だった。 — effective-harnesses-for-long-running-agents
Claude exhibited a tendency to mark a feature as complete without proper testing, often missing end-to-end failures. Claude には適切なテストを経ずに機能を完了と印す傾向が見られ、エンドツーエンドの失敗を見落とすことが多かった。 — effective-harnesses-for-long-running-agents
The last mile often becomes most of the journey. 最後の1マイルが、旅程の大半を占めることが多い。 — multi-agent-research-system
13. モデルは変わり続ける
Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality. 以前のモデル向けに作った skill は、Claude Fable 5 には指示が細かすぎることが多く、出力品質を下げうる。 — prompting-claude-fable-5
If you’ve added scaffolding to force interim status messages (“After every 3 tool calls, summarize progress”), try removing it. 途中経過のメッセージを強制する scaffolding（「ツール呼び出し3回ごとに進捗を要約せよ」など）を足しているなら、外してみよ。 — prompting-claude-sonnet-5
Claude Opus 5 verifies its own work without being told to. Claude Opus 5 は、言われなくても自分の仕事を検証する。 — prompting-claude-opus-5
Harnesses encode assumptions that go stale as models improve. harness は、モデルの改善とともに陳腐化していく前提を焼き込んでしまう。 — managed-agents