Claude Codeのプロダクトエンジニアリング責任者 Cat と、PMの Thariq が、カンファレンスの対談で自分たち自身の運用を語った。指示文の書き方・ツールを増やさない基準・evalで人間レビューを卒業する手順——個人のCLAUDE.mdやSkillにそのまま使える部分だけを抜き出す。
①「禁止」でなく「文脈」で書く指示文設計、②ツールを増やす前に確認する1つの基準、③evalで人間レビューを卒業する4段階の手順。すべて、Claude Codeチーム自身が対談で語った内容の翻訳です。
この記事の元ネタは、開発者ブログで知られる Simon Willison が書き起こした、AI Engineer World's Fair でのカンファレンス対談レポート。相手はClaude Codeのプロダクトエンジニアリング責任者 Cat と、PMの Thariq。Enterprise向けの機能紹介ではなく、「自分たちが自分たちのツールをどう使い、どう改善しているか」という内輪の話が中心だった。
数字がいくつか具体的に出ている。Anthropic社内のSlack統合機能「Claude Tag」は、プロダクトエンジニアリングのPRの65%を処理していて、社内基準で初めて50%を超えたという。システムプロンプトはFableとOpus 4.8以降のモデルで80%削減できた。自律的にタスクを進める「Auto mode」は社内では2025年1月から使い始めていたが、一般公開したのは2026年3月24日——1年以上、社内で使い倒してから外に出している。
セキュリティ面では「数千件規模のeval」と「多数のレッドチーム」でテストを重ねた結果、プロンプトインジェクションやデータ漏洩のリスクは、平均的な人間レビュアーが見逃すリスクより低い水準まで下げられた、という評価も語られている。ここから先は、この対談で語られた内容のうち、個人開発のCLAUDE.mdやSkill運用にそのまま持ち帰れる部分を3つに絞って見ていく。
システムプロンプトを80%削減する過程で、チームは「何を削ったら精度が上がったか」を具体的に語っている。
指示文に具体例を並べるほどモデルは安定すると考えがちだが、チームの経験は逆だった。システムプロンプト内の例を大きく削ったところ、出力がその例の焼き直しになりにくくなり、状況に応じた振る舞いの幅がむしろ広がったという。例を足すほど「その通りにしか動かない」方向に寄っていく、というのは、CLAUDE.mdやSKILL.mdに例をどんどん追記しがちな人には効く教訓だ。
もともと「always verify（必ず確認すること）」という指示があったが、フロントエンド以外の作業でも律儀に適用されて逆に非効率だった。書き換えた先は「フロントエンド作業をしているときは、たいていローカルでアプリを実際に動かして確認する」という、状況を明示した文に近い。絶対語（必ず／禁止）を減らし、いつ・なぜ必要かという文脈を増やす方向にシステムプロンプト全体を寄せている。
曖昧な指示を見つけたときのチェック方法として語られていたのが、この一言だった。「この指示文を、悪意なく真面目に読んだ人間が、想定外の形で解釈するとしたらどこか」を自問する。AIへの指示文レビューを、人間向けのマニュアルレビューと同じやり方でできる、という実務的なコツだ。
対談ではもう一つ、ツール（Claudeが呼び出せる機能）の設計方針も語られている。方向性は一貫して「減らす」側だ。専用の grep ツールや glob ツールを廃止し、ネイティブの bash 経由に統一した。理由は、ツールが増えるほどClaude自身が「どれを呼べばいいか」の判断に迷うようになるから。
基準として語られていたのは、追加するツールそれぞれが、他のどのツールとも明確に役割が重ならないこと。似た機能のツールを複数用意すると、Claudeにとっての選択コストが上がり、結果として呼び出しミスや無駄な試行が増える。これは個人でMCPサーバーやSkillを設計するときにも、そのまま使える判断基準になる。
なぜ大規模な作り直しを避けるのか。Thariqの発言として紹介されていたのが "a codebase is a spec, and maybe it's the only copy" ──コードベースはそれ自体が仕様書であり、しかもしばしば唯一のコピーである、という考え方。分岐条件やエッジケースの扱いは、誰の頭の中にもドキュメントにも残っておらず、コードにしか残っていないことが多い。だから書き直すより、既存コードを読み解いて理解する方向にAIを使う、という判断につながる。
ツールの権限設計についても具体例があった。監視ツール（Datadog）の認証情報は、「エージェントが使えるけれど、エージェントからは見えない」形で管理されている。認可が必要になったタイミングで動的に注入され、コンテキストやログには生の値が残らない。自動化に外部サービスの認証情報を持たせるときに応用できるパターンだ。
最後は、対談でいちばん具体的だった「どうやって人間のレビューを減らしていったか」という話。いきなり全自動化したわけではなく、段階を踏んでいる。
最初は全PRを人間がレビューしていた。そこから、「このファイル種別はコードレビューで問題を100%検出できている」と確認できたものだけ、順にレビュー対象から外していった。逆に、実際に問題が起きたときは、直して終わりにせずevalセットに追加して、同じ失敗を二度と起こさないようにする。新しいモデルに切り替えるときは、感覚で判断せずevalセット全体を回し、「Fableの方がOpus 4.8より厳密に上」と確認してから展開する、というやり方も語られていた。
evalの対象は品質だけでなく、行動の細かい不満にも及ぶ。実例として挙がっていたのが、Claude Codeが作業の途中で「もう寝る時間だ」というようなことを言い出すのをユーザーが嫌う、という具体的なフィードバック。これも一つのevalケースとして組み込まれている。