私は開発者ではありません——これらの8つの原則のうち、すぐに始めるべきものはどれですか？
Claude.aiの標準チャットのみを使用している場合、最もすぐに適用できる3つは：
原則3（コンテキスト汚染）：長い会話でClaudeが無関係な答えを出し始めたり、あなたが言ったことを忘れたりしたら、同じ会話で追い続けないでください。新しい会話を始め、重要なコンテキストを1段落にまとめてから始めましょう。この変化はほぼ即座に効果が出ます。
原則2（ツールを与える）：Claudeにリアルタイムのデータを検索させたり正確な計算をさせたりする必要がある場合は、Claude.aiのウェブ検索をオンにしてください。記憶から「現在の為替レートは？」と聞いたり正確な数値計算を求めたりしないでください——正確な答えにはツールが必要です。
原則4（動く前に診断する）：Claudeに何かを修正または改善させたい場合は、まず「問題はどこにあると思いますか、どうするつもりですか？」と聞いてから、計画を確認し、「では進めてください」と言いましょう。この小さな変化で、誤解を早期に発見できます。
「コンテキスト汚染」はどのくらい深刻ですか？会話はどのくらい長くなると問題になりますか？
「X メッセージ後」という正確な閾値はありません。コンテキスト汚染はメッセージ数だけに関係するわけではなく、各メッセージの内容にはるかに大きく依存するからです。
コンテキスト汚染を加速させる要因：
感覚的なヒューリスティック：会話が20〜30ターン（1つのプロンプト＋1つの応答＝1ターン）を超え、内容が密度が高い場合は、新しい会話を検討する価値があります。前に言った重要なことをClaudeが無視し始めたり、すでに完了した作業を繰り返したりするのを感じたら、それは明確なシグナルです。
簡単な予防の習慣：新しい会話の始まりに、タスクに飛び込む前に「この会話の目的とコンテキスト」段落を30秒で書くことです。
「生成→評価→修復」アーキテクチャは、Claudeに自己修正させているように聞こえます。単に修正を頼むことと根本的にどう違うのですか？
これは核心的な点に触れています。表面上、どちらも「Claudeが生成して、それから修正する」ように見えますが、背後のメカニズムはまったく異なります。
同じClaudeに修正を求める問題：同じコンテキストで同じClaudeが、答えを生成し、自分でチェックし、自分で修正します。問題は：答えを生成したとき、ある程度その方向性に「コミットした」ことです。自己レビュー中は、コンテキストにすでに「自分の解決策」があるため、本当にゼロから自分を疑うことが難しいです。自分が書いた文章を自分で校正するようなものです——自分の盲点を見つけるのは非常に難しい。
生成→評価→修復が異なる理由：評価を担当するエージェントは独立したコンテキストを持っています——「この答えを生成した」という重荷がありません。それは1つのことだけを担当します：明示的なルールチェックリストに基づいて問題を見つけること。同時に生成ロジックを理解する必要はなく、出力がルールを満たすかどうかを確認するだけです。
これがAnthropicが言う「新鮮な目」効果です——Claudeが賢くなったのではなく、役割分離により各モデルが同時にすべてを行うのではなく、1つの容易に検証可能なことだけを担当します。
「Claudeに毎日文章を書く手伝いをしてもらう」という私の日常的な使い方に、これらの原則はどんな具体的な示唆がありますか？
たくさんあります——そして直接適用できます。日常のライティング作業への具体的な翻訳：
プロンプトは長いほど良くない（原則1、8）：「ライティングガイドライン」が長い場合は、最も本質的な要求だけに縮小してみましょう。余分なルールは役に立たないだけでなく、Claudeが「ルールAに従う」と「ルールBに従う」の間で揺れ動く可能性があります。最善のテスト：このガイダンスを賢い人に話して、すぐに何が望まれているかを理解してもらえますか？長くて複雑な説明が必要なら、プロンプトも簡素化が必要かもしれません。
段階的なアプローチが一発で完璧を狙うより良い（原則4、8）：「完全な分析レポートを書いて」の代わりに：「まずアウトラインをください」→「この構造に問題がありますか？」→「では、このアウトラインに従って最初のセクションを書いてください」。各ステップで方向を確認でき、Claudeに一度に1つの明確なタスクを与えます。
長い会話→新しい会話（原則3）：今日Claudeと記事の構造について議論した場合、明日続ける際は昨日の会話を続けないでください——新しく始めて、確認された構造を背景コンテキストとして貼り付けます。
こんな経験はないでしょうか：より新しいClaudeモデルにアップグレードしたら、逆に使いにくくなった？以前は動いていたワークフローが壊れ始め、どんどん長くなるプロンプトがどんどん効果なくなり、バグを修正するよう頼んだら3つ新しいバグが生まれた。
AnthropicはロンドンでのCode with Claudeイベントで、エンジニアたちが丸一日かけてこの問題に答えました。核心的な結論は一言で言えます：Claudeのパフォーマンスが低い場合、多くはモデルの問題ではなく、私たちが置いた環境の問題です。
以下はそのイベントから整理した8つの原則です。技術的なドキュメントではなく、Claudeと一緒に作業するすべての人が直接適用できる実用的な思考フレームワークです。
Anthropicは多くの人が経験してきたパターンを説明しました：モデルが間違えるたびにプロンプトにルールを追加します。時間が経つと、プロンプトは役割定義、ポリシールール、データ、出力フォーマット、旧モデルの動作パッチがすべて詰め込まれた雑多な集合体になります。
問題は：より優秀な新しいモデルに切り替えると、指示をより忠実に従います——そのもはや意味をなさない古いルールも含めて。モデルが強ければ強いほど、あなたが蓄積した矛盾をより忠実に実行します。
モデルは馬鹿になっていません。あなたが与えたコンテキストがモデルの能力を発揮できなくしているのです。
Anthropicは、ほとんどのチームがプロンプトを「感覚で」調整していることを観察しました：変えて、試して、良くなった感じがすれば続ける。問題は、何の変更が効果あったのか、何が静かに他の部分を壊したのかがわからないことです。
より良いアプローチ：まず評価指標（Evals）を構築します：
プロンプトの編集やモデルの変更のたびに評価を再実行します。何が実際に改善され、何が静かに劣化したかを知る唯一の方法です。
Anthropicは通信カスタマーサービスボットで示しました：混在したプロンプトをXMLタグで「ロール」「ポリシー」「データ」に分けるだけで、モデルを変えず新しいルールを追加せずに、一部のテストスコアがすぐに改善されました。
プロンプトはClaudeに何をすべきかを伝えられますが、Claudeが持っていない能力を与えることはできません。
Anthropicの例は直接的です：カスタマーサービスボットが月中のプラン変更後の日割り請求を計算する必要がありました。プロンプトは何度も「正確に計算しなければならない」と書いていましたが、モデルは常にあいまいな暗算の過程を示すばかりで、安定した正確な数値を出せませんでした。
解決策は「もっと正確に」と言い続けることではありませんでした。入力、公式、出力フォーマットが明示的に定義された計算ツールを追加することでした。ツールがあれば、モデルは推測をやめてツールを呼び出します。
この原則は確定的な答えが必要なすべてのことに適用されます：データベースのクエリ、コードの実行、大きなファイルの読み込み、注文の作成。テキストコンテキストですべてを記憶・処理するようモデルに依頼することは、通常、適切なツールを与えるよりもうまくいきません。
Claude Codeが長い作業セッション中にパフォーマンスが低下する場合、最も一般的な原因はコンテキストがいっぱいになることです。
Claudeは作業中にファイルを読み、コマンドを実行し、会話を蓄積し続けます。大きなコンテキストウィンドウがあっても、もはや無関係な古いメッセージ、実行出力、コードスニペットでいっぱいになる可能性があります。重要な情報がノイズに埋もれると、Claudeは以前のリクエストを無視し、すでに完了した作業を繰り返し、古い情報に基づいてコードを変更し始めます。
2つの対応策：
同じ原則はCLAUDE.mdにも適用されます：プロジェクト構造、テスト方法、長期ガイドラインに適していますが、長すぎるか古いモデルのパッチでいっぱいなら、毎回のスタートアップでコンテキストを汚染します。モデルのアップグレード後は見直して、不要なルールを削除する価値があります。
複雑なバグには、「このバグを修正して」から始めないでください。
より効果的なシーケンス：コードベースを検索し、考えられる根本原因を特定し、修正計画を概説するよう依頼します——ただし変更はまだしないで。計画を確認し、方向が正しいことを確認してから実行させます。
これが機能する理由：システムを本当に理解する前に大きなコード変更を行うモデルは、しばしば新しい問題を引き起こします。最初に計画を得ることで、大量の時間が無駄になる前に間違った方向を早期に発見できます。
Anthropicはこれを「よりスマートなVibe Coding」と呼んでいます：AIを自律的に動かしながらも、頻繁な小さな確認ステップ、コードレビュー、コミットを通じて回復可能な安全境界を維持します。鍵は「中断できること」——終わるまで待って後片付けするのではなく。
エージェント設計のAnthropicの核心原則：まずエージェントに人間が仕事で使う基本的な能力を与えます。
従業員は使います：ファイルシステム、ターミナル、ブラウザ、検索、コード実行環境、API。エージェントはまずこれらの汎用ツールから始めるべきで、タスクごとに狭く固定されたカスタムツールを構築するよりも良いです。
Anthropicは在庫管理エージェントを示しました：元々約400行のシステムプロンプト、12のツール。機能が増えると奇妙な問題が現れ始めました——モデルは正しいプロモーション倍率3.1倍を読んでいるにもかかわらず、1.35倍で計算していました。
診断：モデルの能力ではなく——システムプロンプトが長すぎてルールが競合し、モデルが雑然としたコンテキストで間違って推測していました。解決策：400行を50行に縮小し、すべてのタスクに必要な核心だけを残す；在庫ルール、予測ルール、報告ルールはSkillsに分割して、実際に必要なときだけロード。
これは多くの人の直感に反します。
一般的なアプローチ：CSVファイル全体や大量のデータをコンテキストに貼り付けてClaudeに直接読んで分析させます。Anthropicは、これが1つのタスクで20万トークンを超える可能性があり、結果が悪いことを示しました——モデルにデータセット全体を「頭に入れて」おかせることは最も得意なことではありません。
より良いアプローチ：ファイルシステムとコード実行能力を与え、Pythonを書いてデータをフィルタリング、集計、整理させ、コードが生成した重要な出力だけを読み取ります。トークン使用量が大幅に減り、実行時間も短縮されます。
拡張原則：すべての操作にMCPツールを作成する必要はありません。1つのエージェントだけが機能を必要とするなら、ローカルツールを構築します。コードでAPIを呼び出せるならコードで呼び出します。複数のエージェントまたはクライアントが同じ標準化されたツールセットにアクセスする必要がある場合のみ、MCPサーバーとしてラップする意味があります。
サブエージェントは2つの状況に適しています——それ以外では無理に分割しないでください：
タスクが単純なシーケンシャルプロセスであれば、無理にサブエージェントに分割するとコンテキスト転送と調整のオーバーヘッドが増加します。サブエージェントが作業を正確に完了しても、メインエージェントに結果を渡す過程で情報が歪む可能性があります。
Anthropicのガイダンス：マルチエージェントシステムのように見えるために、すべてをサブエージェントに分割しないでください。
Anthropicはすべての改善を1つの核心原則にまとめました：Claudeのパフォーマンスを向上させる鍵は、より長いプロンプトを書くことではなく——正しい情報を、正しい時間に、正しい形式でモデルに届けることです。
複雑なタスクには、Anthropicは生成→評価→修復アーキテクチャを示しました：
従業員のスケジューリングのケースで：長いプロンプトを持つ単一モデルはすべての制約を安定して満たせませんでした。より強力な推論モデルに切り替えると動作しましたが、トークン使用量と遅延が大幅に増加しました。3つのステップに分割すると：すべてのテストをパスし、トークン使用量と遅延の両方が減少しました。
理由は明確です：各モデルは1つの明確で容易に検証できるタスクを担当しており、同じClaudeにルールの理解、回答の生成、エラーのチェック、自己修正を同時に要求するのではありません。
これらの8つの原則のほとんどは、開発者でなくても適用できます。日常のClaude使用に翻訳すると：
Anthropicがイベントの最後に言った言葉は覚えておく価値があります：Claudeを「賢くする」ことは、魔法のプロンプトを見つけることではありません。モデルが雑然として矛盾したコンテキストの中であなたが本当に望むことを推測しなくて済むようにすることです。