Claude CodeチームのCatとThariqとの炉辺談話
原文は Simon Willison により に公開されました。 このブログを購読する
今月初め、私はAI Engineer World’s Fairで、AnthropicのClaude CodeチームのCat Wu氏とThariq Shihipar氏を迎えて炉辺談話のセッションを開催しました。Claude CodeやClaude Tag、Fable、コーディングエージェントのセキュリティ、evals（評価）、ツール設計、そしてAnthropic自身がこれらのツールをどのように活用しているかについて話しました。
セッションの全編はYouTubeで公開されています。以下は書き起こしを編集したもので、追加のリンクと、私自身が太字で強調した箇所を加えています。
動画を見る時間がない方や、全文を読むのが大変な方のために、要点をまとめました。
- Claude Tag（Claudeの新しいSlack向けコラボレーション統合）は、Claude CodeチームのプロダクトエンジニアリングのPRの65%を担っています。
- Claude CodeはまずAnthropic社内の従業員向けに機能をリリースし、そのコホートでユーザーのリテンションが確認できた機能だけを外部に提供しています。
- Claude Codeの重要な変更は今も人間が手動でレビューしていますが、チームは製品の「外側のレイヤー」については自動コードレビューへの依存を強めています。
- システムプロンプトに例を追加することは、Fable 5やOpus 4.8のようなモデルではもはやベストプラクティスではありません。Claude Codeのシステムプロンプトは最近80%削減されました。
- 同様に、「Xをしてはいけない、Yをしてはいけない」といったリストは、最新モデルでは結果の質を下げてしまうことがあります。
- Anthropic社内でのドッグフーディングは「ant fooding」と呼ばれています。
- Anthropicはauto mode（自動モード）を強く信頼しており、それをClaude Tagを可能にする基盤技術と見なしています。
- Thariq氏は、コーディングエージェントがもたらすDeep Blue的な喪失感を、取り組む仕事において「より野心を持つこと」で相殺するよう助言しています。
- Fableは動画編集が得意で、Thariq氏は自身のローンチ動画の編集にも使いました。
- Anthropicの（社内で）オープンに働く文化は成功の鍵であり、それは同社がパブリックなSlackチャンネルでClaude Tagを使う方法にも表れています。
過去1年で日々の仕事はどう変わりましたか？
Simon: Claude Codeは昨年の2月に登場しました — まだ1年半も経っていません。当初はClaude Sonnet 3.7のローンチの箇条書きの1項目に過ぎませんでした。実際に役立つコーディングエージェントが手に入ったことで、過去1年で日々の業務はどのように変わりましたか？
Cat: Claude CodeとSonnet 3.7を最初に出したときのことを覚えています。タスクを与えると、エージェントがやろうとすることの一つひとつを細かく監視する必要がありました。許可プロンプトを一字一句注意深く読み、頻繁に「ダメ、ダメ、ダメ、このファイルは確認した？あのファイルは？」と拒否していました。でもモデルが世代を重ねるごとに劇的に進化しました。私たち全員が一歩引いて、実装のような地味な作業の多くをClaudeに委任できるようになったと感じています。そのおかげで、Claude Codeがその多くを実装できるようになった今、ユーザーにどのような体験を提供すべきかといった、より創造的なことに時間を使えるようになりました。そしてFableでは、まったく次元の違う飛躍がありました。多くのユースケースで、Fableなら大量の機能をワンショットで作れるようになったと実感しています。
Thariq: Claude Codeについて初めてテキストをもらったときのことを覚えています。親友の一人が「Claude Codeを試すべきだ」と言ってきたんです。ちょうどOpus 4が出た頃で、試してみて「うわ、やばい。Anthropicで働かないと」と思いました。それがOpus 4でした — 素晴らしいモデルでしたが、許可プロンプトを読まなければなりませんでした。今ではどれだけ健忘症になっているか不思議なくらいです。「auto modeはずっと前からあったよね？」という感覚で、yesやallowを押した記憶すらありません。私が自分に課している大きな課題は、これまで以上に質の高い仕事をしなければならないということです。出力の質は信じられないほど高い。動画編集にもよく使っていますが、「ブランドチームの非常に厳しい要求を数時間で満たさなければならない、でなければ間に合わない」という状況です。それがFableで私が目指しているシフトです — これまでで最高の仕事を、これまでで最速でやり遂げるということです。
かつて常識だったソフトウェアエンジニアリングの原則で、今はもう通用しないものは？
Simon: 1年前に正しかったソフトウェアエンジニアリングの常識で、この新しい世界ではもう成り立たないものは何ですか？
Cat: エンジニアに求められるスキルセットで最も大きく変わったことの一つは、2年前ならプロダクトマネージャーが大勢の顧客に話を聞き、半年かけて部門横断のチームと連携してPRDをまとめ、コードの1行目を書く前に実装方法を徹底的に仕様化するのが当たり前だったことです。今はそれが完全に逆転しています。会場の皆さんにお伝えしたいのは、何を作るべきかというビジネス感覚とプロダクト感覚をもっと磨いてほしいということです。アイデアを得てから構築するまでの時間が、6〜12か月から1週間程度にまで短縮されたからです。つまり、私たち全員が、何を作る価値があるのか、何が自分たちのビジネスを大きく伸ばすのかについて、より良い「目利き」を持つ必要があります。プロダクトのセンスとビジネス感覚の価値が高まり、多くのプロダクト領域では実行そのものの比重は下がっています。もちろん、インフラでは細部を確実に正しくすることへの重点は依然として非常に高いですが。
Thariq: 私にとっては、書き直しは今や良いことだということです。
Simon: 最悪の選択肢だったことが、今や実際に良いことになったわけですね！
Thariq: その通りです。『人月の神話』で言われてきた「書き直すな」といった定石も、今では私は書き直し賛成派です。良いテストスイートがあれば — そして書き直しこそが、良いテストスイートを用意することを強制してくれるのだと思います — 人が過小評価しているのは、コードベース自体が仕様書であり、おそらく唯一残っている仕様書のコピーだということです。コードベースの分岐のすべてを誰も把握していないからです。これを成果物として捉え、蒸留したり別のバージョンを作ったりできるのです。私たちはBunをRustで書き直しましたが、とてもうまくいっています — 私の環境ではすでに動いています。
Simon: まだClaude CodeをBun-in-Rust版で出荷はしていないんですよね？
Thariq: 社内では出荷しています。
（実際、Anthropicは6月17日から全ユーザー向けにBun-in-Rust版のClaude Codeの出荷を開始したようです。）
非エンジニアはClaude Tagでどんなことをしていますか？
Simon: 最近のもう一つの大きなローンチはClaude Tagでしたね — 我々一般向けには1週間ほど前でしょうか。Anthropic社内では非エンジニアにも盛んに使われていると聞きました。非エンジニアはClaude Tagでどんなことをしているのですか？
Cat: Claude Tagは、チームのコラボレーションツールの中に住むClaudeです。先週Slack向けにローンチしました。Claude Tagが違うのは、デフォルトでマルチプレイヤーだということです。Claude TagをSlackチャンネルに追加すれば、あなたもチームメイトもそこに参加して、PR上で一緒にコラボレーションできます。もう一つの大きな違いは、リアクティブではなくプロアクティブだという点です。Claude Tagに「このチャンネルのすべてのバグ報告を監視して、修正PRを出して、このコードを最後に触ったエンジニアをタグ付けして」と伝えれば、あなたが手動でタグ付けしなくても、チャンネルが存在する限り自動でやってくれます。そして3つ目の大きな変化は、チームメモリを追加したことです。チャンネル内でClaude Tagに好みを伝えれば、それを今後のすべての投稿で覚えてくれます。たとえば「障害はデバッグしてほしいが、警告はデバッグしないでほしい」とチャンネルで自然な言葉で伝えるだけで、あなただけでなくチーム全員のために記憶してくれます。
社内では、Claude TagをClaude Codeの進化形と捉えています。これは社内の働き方における大きな転換です。Claude Tagは現在、プロダクトエンジニアリングのPRの65%を着地させています。
Simon: それはAnthropic全体でですか、それともClaude Codeチームだけですか？
Cat: これはプロダクトエンジニアリングチームだけの話です — 社内版のClaude Tagが現在プロダクトPRの65%を着地させています。これは大きな変化で、PRの半数以上を占めています。Claude CodeとClaude Tagの使い分けについては、Claude Codeは依然として、エージェントと対話的に反復しながら進める最も複雑なタスクに最適な場所です。一方でClaude Tagは、あなたに代わってプロアクティブに働いてもらうのに最適です。自分が担当する機能で発生したバグ報告のたびに、手動でClaude Codeを起動する必要がなくなります。
Thariq: コーディング以外の例でいうと、このトークの前にClaude Tagに「ねえ、Fableのリリースはいつ？」と聞きました。発表とタイミングを合わせたいと思ったからです。Claude TagはSlackを検索して、誰が何を言っているかを調べてくれます。社内の検索エンジンとして、非常に価値があります。プロダクトに関するすべてのコンテキストを持っているので、メトリクス関連の質問もできます — 意思決定をする際にメトリクスに基づいた判断をしたいことが多いので、イベントストアにつないでおくのです。マーケティングチームが「ねえ、この機能について教えて」とやっているのを見たことがあります。彼らはプログラマーではありませんが、Claudeはプログラマーです — コードベースをクローンして「これがこの機能で、見た目はこうです、これが私が実際に機能を使っている録画です」と答えることができます。実に幅広いことが可能になりますし、まだその可能性を探り始めたばかりだと思います。
チームのコラボレーションレイヤーとしてのClaude Tag
Simon: コーディングエージェントで私が抱えていた問題の1つは、個人として使い方はわかるけれど、チーム環境でどう使うべきかがよくわからないということでした。Claude Tagが、そうしたチーム向けコラボレーションレイヤーに対する今の答えということですね。
Cat: その通りです。そして現在、セッションのかなりの割合が実際にマルチプレイヤーで行われています。たとえば私が「Coworkにこの新機能を実装すべきだと思う」と言って、Claude Tagに最初のパスを任せます。次にClaude Tagに「最終的な実装の録画を共有して」と頼み、デザイン担当をタグ付けして確認してもらいます。彼らが微調整し、エンジニアに渡して仕上げ、プロダクションまで持っていく。非常に流動的な体験になっています。同じセッションをみんなで誘導する際の社会的なダイナミクスについては、まだ手探りで整えているところですが、みんなが他の人の使い方を見て、その社会的規範に従うので、Claude Tagをチームに統合するのはかなり直感的でした。
Thariq: 人に教えるのにも最適ですし、雑なアウトプットを減らすのにも役立ちます。なぜならみんながあなたがClaudeを使う様子を一緒に見ていることで、Claudeの使い方自体がレベルアップするからです。
これは、MidjourneyがDiscordチャンネルでプロンプトを公開で強制することで、高度な画像プロンプトの書き方を人々に教えるという課題を解決したことを思い出させました。
構築コストがこれほど下がった今、どの機能を作る価値があるとどう判断しますか？
私自身、機能を構築するコストがこれほど下がった今、その機能をリリースする価値があるかどうかを判断するのが本当に難しいと感じています。
Simon: エンジニアリングにおける最も難しい問題 — 優先順位付けについてどう対処していますか？機能の構築がこれほど安くなった今、どの機能を作り、リリースする価値があるとどう判断しているのですか？
Cat: これは難しい問題です。いくつかのアプローチがあります。一つは、製品を毎日ドッグフーディングすることです。製品でやりたいことができないと気づいたら、別の解決策を探すのではなく、製品自体を修正してそのケースに対応できるようにします。社内では非常に強いドッグフーディング文化があります。製品を世界中のユーザーに公開する前に、まずAnthropic社内の全員、そして非常に率直なフィードバックをくれる一部の初期顧客に公開します — 厳しければ厳しいほど良い — そしてみんなが気に入るまで反復します。機能を世に出す前に満たすべきアクティブユーザー数とリテンション率という社内の基準があります。この基準が明確なので、エンジニア全員が何を目指すべきかを理解しています。これは私たちの磨き込みのレベルも高めてくれていると思います。機能が磨き込まれていなければ、ユーザーは離れてしまいます — そうなれば、その機能は出すべきではないということです。
社内のユーザーリテンションを機能のリリース可否の判断に使うという考えは、私には非常に理にかなっていると思いました。
予想外に反響があった機能の例はありますか？
Simon: 予想外だった機能の例はありますか？リリースしてみたらエンゲージメントが異常に高かった — 本来なら出さなかったかもしれないものが、実際のプロダクトの目玉になったようなものは？
Cat: あります。チームの多くのメンバーがリモートコントロールを気に入っています。リモートコントロールを使えば、モバイルデバイスやブラウザ上のClaudeから、CLIで動いているローカルのClaude Codeセッションに接続できます。私自身はこのニーズを感じたことがありません。なぜなら、モバイルから直接タスクを立ち上げれば、ローカル環境を使わずにクラウドセッションで実行されるからです — 私がやっているコーディングタスクがとても簡単だからだと思います。当初は「みんなリモート開発環境をセットアップすればいいのに」と思っていて、よく理解できていませんでした。しかし実際にリモートコントロールをロールアウトしてみると、多くの人から「毎晩ノートPCを電源につなぎ、大量のリモートコントロールセッションを開いて画面をロックし、ソファから携帯電話でClaude Codeを操作している」と聞きました。最初は理解できなかったフローですが、今では私たちも積極的に取り組んでいるフローになっています。
Claude Codeの本番コードはすべて人間がレビューしているのですか？
カンファレンス全体を通じて一貫していたテーマの1つがレビューでした。コーディングエージェントが書いたコードを、人々がどれだけ注意深くレビューしているか。Claude Codeチームの見解をぜひ聞きたいと思いました！
Simon: コードレビューはどのように行われていますか？Claude Codeに入る本番コードのすべての行を人間がレビューしているのですか？そうでないとすれば、品質をどう保っているのですか？
Thariq: タスクによってかなり異なります。重要な領域にはコードオーナーがいます。システムプロンプトはその一例で、必ずコードオーナーの承認が必要です。
Simon: つまりコードオーナーがその領域のコードの品質に直接責任を持つということですね。
Thariq: その通りです。
Cat: そしてその領域に触れるPRはすべて承認が必要です。
Thariq: 私たちはコードレビュー用のGitHubボットですべてをレビューしています — すべてのPRにつき、多くの場合レビューの大部分を担っています。チームで見られるのは、より複雑なPRでは、PRを説明する成果物を作ることがあるということです。そうすれば他の人がレビューしやすくなります。そして検証やCI/CDなどにも多大な投資をして、何かが失敗するたびにテストがあるようにしています。ClaudeがClaude Codeを操作してテストできる、非常に堅牢な環境があります。つまりコードレビューへのアプローチは多面的です。
Cat: 一般的に、人間がループに入る必要のない世界を目指しています。Claude Codeのコアや他のプロダクトのコアに対する最も重要な変更については、常にコードオーナーがいて、彼らがすべての変更を手動でレビューします。しかし次第に、外側のレイヤーの変更については、実際にClaudeのコードレビューが完全にレビューするようにしています。かなり怖く聞こえるかもしれませんが、ここに至るまでに6か月以上のプロセスがあり、コードレビューへの信頼を築くために段階的に進めてきました。最初はすべてを人間がレビューし、次第に「これらのファイルに触れるコード変更については、コードレビューが問題を100%検出している — だから人間が手動でレビューする必要はない」と言えるようになりました。そしてインシデントレビューでは、インシデントを引き起こしたPRを見て、「コードレビューをどう更新すればこれを検出できるか？」と考えます — そしてそれらのPRをevalセットに追加して、コードレビューへの今後の変更がその指標を後退させないようにしています。人間をコードレビューのループから外すのは大きな前進です。怖く聞こえるかもしれませんし、一夜にしてできることではありませんが、コードレビューが自分たちが気にかけるすべてのことを確実に捉えているという自信を与えるインフラへの何か月にもわたる投資を通じて実現できることです。
つまり鍵は、長期的に信頼を築くために、自動レビューシステム自体を絶えず改善し続けることにあるようです。
新しいモデルは、それが何ができて何ができないかという直感にどう影響しますか？
私たちはevalsについて深く掘り下げました — カンファレンス全体でもホットな話題でした。
Simon: Opus 4.8なら、JSONエンドポイントを作ってSQLクエリを実行しJSONを出力させても、確実に正しくやってくれるとわかっています — 細かくレビューする必要はありません。でも新しいモデルが出てくると、FableがOpusが失敗しなかったことを失敗しないという信頼をどう素早く築けばいいのかわかりません。新しいモデルは、それが何ができて何ができないかという直感にどう影響しますか？
Cat: 長期的にevalの基盤を構築している主な理由は、新しいモデルをドロップインで置き換えられるようにするためです。新しいモデルが出たら、evalセット全体を実行し、たとえばFableがOpus 4.8より厳密に優れていることを確認します — それがドロップインする自信につながります。
Simon: それらのモデルevalはAnthropic全体のものですか、それともClaude Codeチーム固有のものですか？
Cat: 両方あります。チーム固有のevalsもあり、Anthropic内のすべてのリポジトリでコードレビューを実行しているので、そのためのevalsもあります。そしてauto modeのようなものについては、Anthropic内のすべてのユーザーにわたるevalsだけでなく、複数の外部テスターに依頼してレッドチームを実施し、プロンプトインジェクションや悪意のある入力のある環境を作り出し、auto modeがそれらを一つも通さないことを確認しています。
システムプロンプトの微調整がより良い出力を生むと、どう確信を持てますか？
Simon: システムプロンプトの改善が実際にプロダクトを良くしたかどうかを知りたい — それはプロダクト固有のevalの最も基本的な形ですが、私はまだうまくやる感覚がつかめていません。システムプロンプトへの微調整がより良い出力をもたらすと、完全に確信を持てるようなことをやっているのですか？
Cat: 完全に確信があるわけではありませんが、性能が後退しないように多くのことをしています。出発点は、信頼できる外部evalのスイートであり、それをさらに大規模な社内evalのスイートで補完しています。まず、私たちは主にケイパビリティを最適化します。タスクの完全な定義とコードベース全体が与えられたときに、Claudeは正しい判断を下し、バグを完全に修正し、すべてのテストに合格するか？それが出発点であり、ユーザーが最も直接的に求めていることなので最適化の対象です。しかし、ユーザーがClaude Codeと作業する際の感覚に影響する振る舞いもたくさんあります。たとえば、Claude Codeが「そろそろ寝る時間です」と言うのを人々は本当に嫌がります。あるいは「5つのうち2つが終わりました — 続けますか？」と言うのも嫌がります。はい、お願いだから続けてくれ、と。そこで私たちは、こうしたことを捉えるための振る舞いに関するevalsを構築しています。そしてユーザーフィードバックをいただくたびに — どうか遠慮なく大きな声でフィードバックをください — 優先度の高い問題から順に並べ、一つひとつevalsを作っていきます。100%のカバレッジがあるわけではありませんが、カバレッジを高めることは私たちの優先事項です。
Claude Codeチームとモデル学習チームはどの程度連携していますか？
Simon: Claude Codeチームと、そもそもモデルを学習しているAnthropic内のチームとの間で、どの程度のやり取りがありますか？かなり密接な連携なのですか？
Cat: Anthropic全体で、私たちは皆かなり密接に連携しています。次世代のモデルに何ができるようになることを期待するかについて、頻繁に会って話し合っています。リサーチチームも、この点を公開で示すことにとても協力的で、ブログ投稿でもよく話していますが、私たちはますます長期的な作業を目指しており、Claude自身が正直で、無害で、役に立つように学習させています。あなたの意図が曖昧な形で表現されていたとしても、その意図に沿うようにすることにも多くの労力を注いでいます。もちろん、Claudeがすべてのコンテキストを持てるように、できるだけ具体的に何が欲しいかを伝えるのが最善ですが、具体的でなくても、良い仮定を置くようにClaudeを教えています。生産的なパートナーシップでした。
システムプロンプトが80%削減されたということですが、何を削ることができたのですか？
このセクションには、非常に役立つプロンプトのヒントがたくさん詰まっています！
Simon: Thariqさん、あなたは今朝、Claude FableのおかげでClaude Codeのシステムプロンプトが80%削減されたとおっしゃっていました。もう少し詳しく教えてください。どんなことを削ることができたのですか？
Thariq: Fableだけではありません — Opus 4.8でもそうですし、今後のモデルでも同様です。モデルごとに異なるシステムプロンプトを用意するようになりました。見えてきたパターンの1つは、Claudeを過度に制約していたということです。初期の、おそらくOpus 4あたりのモデルは多くの例を必要としていましたが、例を削除することが非常に役立ちました。なぜなら、Claudeの方が私たちが与えた例よりもはるかに創造的だったからです。
Simon: それはとても興味深いです。というのも、私が人に伝えるトップのプロンプトTipsの1つが「例を与えろ」だからです。もしそれがもう正しくないとすれば、私のプロンプトのモデルが少し崩れてしまいます。
Thariq: 私も同じです — 聞いて驚きました。今は、与えるものの形 — Claudeに与えるツールやシステムプロンプトなどがより重要だと思います。もう一つやったことは、より多くのコンテキストを与え、「これをしてはいけない」といった指示を減らすことです。それはClaudeにとって非常に強い衝動となるため、特に後でユーザーからの指示と衝突したときに、Claudeを極めて混乱させてしまうからです — 「このスキルはこう言っているのに、システムプロンプトはこう言っている」といった具合です。そこで私たちは、厳しい制約を減らし、コンテキストを増やし、指示全体を減らすようにしています。これは間違いなく科学です — 多くのevalsを積み重ねて構築しました。
Cat: 一般的に、これらのモデルにプロンプトを与えるときは、常にこう考えるべきです。私が与えている指示にエッジケースはないだろうか？Claude Codeのシステムプロンプト内のすべての指示を振り返って見直したとき、この記述は90%は正しいが、残りの10%では正しくないケースが確かにあることに気づきました。モデルを制約したり、常にそうすべきだと混乱させたりしたくありませんでした。良い例が検証です。誰もがClaudeに作業を検証してほしいと思っており、プロンプトには「フロントエンドの変更をしたら必ず検証しろ」という指示がありました。しかしそれには限界があります。ある文字列から別の文字列へコピーを変更するだけで、ユーザーが「ちょっと直してテストを更新して」と言っているなら、検証したくないかもしれません。そこで私たちは「常に検証せよ、検証せよ、検証せよ」という文言を、「フロントエンドの作業ではバックエンドのエンドポイントを叩くだけでは体験全体を完全に理解できないことがほとんどなので、ユーザー体験に大きな変更を加えた際はアプリをローカルで実行してください」といった表現に調整しました。そして実際、その指示でさえおそらく良くありません。なぜなら大きな変更とは何か？という疑問が残るからです。小さな変更でもテストすべきかもしれません。一般的に、モデルにプロンプトを与えるときは、善意を持った人間がどのように誤解しうるかを考えるべきです。そうすることでモデルがどう解釈するかがよりよく理解できます — そしてプロンプトを和らげて、100%正確なものにするのです。なぜなら、そのプロンプトをモデルに100%の時間与えているのですから。
Simon: 興味深いのは、あなたがモデルの判断に頼っているということです — それはOpusやFableレベルのモデルだからこそできることですね。1年前のモデルには、変更をテストするかどうかを判断するのに必要な判断力がありませんでした。しかし、幅広いモデルに対応して、より安価なタスクにはより安いモデルを使おうとすると、この考え方は崩れてしまいますね。
Cat: まさにその理由で、モデルごとに異なるシステムプロンプトを用意するようになりました。この80%のトークン削減が適用されているのは、最もフロンティアなモデルだけです — 古いモデルでは依然として完全なシステムプロンプトを使っています。
Simon: FableやOpusは、Haikuの判断力やセンスが劣ることを理解しているので、Haikuにより詳細なプロンプトを書けるほど賢いと思いますか？
Cat: まだ評価できていません — それを示す確かなデータはありません。
Thariq: 小さなモデルでは難しいことがあります。なぜなら、難しい問題では、大きなモデルの方が小さなモデルよりもトークン効率が良いことがあるからです。そこには直感を養う必要があります — 時には本当にほぼ常にフロンティアの知能が必要なのです。パレート曲線は変化し、見極めるのが難しいのです。
Simon: 1年前は、モデルにプロンプトを書かせるなんて信用していませんでした。今日では良いモデルはプロンプトを書くのが非常に上手です — 私のプロンプトの多くはモデルによって書かれており、ばかげているように感じますが、とてもうまくいきます。その考えを受け入れられたのは、サブエージェントについて考えたときでした。サブエージェントとは、Claudeモデルが別のClaudeモデルのためにプロンプトを設定することそのものですから。
Thariq: ワークフローは実に良い例です。単一のサブエージェントにプロンプトを与えるだけでなく、多数のサブエージェントのオーケストレーションにプロンプトを与え、それぞれが非常に詳細なプロンプトを受け取るのです。単にサブエージェントを生成するよりも、ほぼ一段上のレベルです。私も自分のマシンで、Gemini APIを渡して「ほら、画像を生成して」とやっています。画像モデルへのプロンプトでは、私なんかよりずっと手を抜きません。ClaudeがClaudeにプロンプトを書くことが延々と続いているのです。
Cat: Claudeがワークフローツールのプロンプトを書いたのだと思います。
Simon: そのプロンプトを読みましたが、良いプロンプトでした。Anthropic全般に対して不満に思っていることが1つあります。あなた方はClaude Chat用のプロンプトを公開していますが、ツールプロンプトやClaude Codeのプロンプトは公開していない。私は今でもプロキシを立ててそれらを傍受しなければなりません。Claude Codeのプロンプトが意図的に公開されると嬉しいです — それはドキュメントなのです。それによってツールが何ができ、どう動くのかがわかるのですから。
Cat: その機能リクエストを書き留めておきます。Claude Tagにやらせます。
OpenAIのGPT-5.6向けプロンプトのベストプラクティスにも、最新モデル向けに同様のアドバイスが含まれていることは興味深いです。
より簡潔なプロンプトを優先する
繰り返しの指示や例を削除し、ツールの説明を簡素化することで、タスク性能とトークン効率を向上させることができます。社内のコーディングエージェント評価のサンプルでは、より簡潔なシステムプロンプトを用いた構成で、評価スコアが約10〜15%向上し、総トークン数は41〜66%、コストは33〜67%削減されました。
新しいツールを導入する際の基準は何ですか？
Simon: Claude Codeは基本的にツールの大きな詰め合わせです。新しいツールを導入する基準は何ですか？そのレベルで追加のエンジニアリングを行う価値があるとどう判断するのですか？
Cat: あなたが答えますか？私たちが持つ最高のツールの1つを導入したのはあなたですから。
Thariq: 私のキャリアのピークはask user questionツールを導入したときでした。本当に難しいです。特に一部のツール — ask user questionはClaudeがあなたに質問するためのツールです — は評価が難しく、時にはユーザーの好みの問題でもあります。当時はevalsも少なかったので、非常にドッグフーディング — いや「ant fooding」、私たちのアリ版ですが — に基づいていました。しかし全体として、私たちはより少ないツールへと向かおうとしています。最後に導入したツールはtaskツールだったと思います — そしてClaudeにより汎用的な方法で物事をできるようにしようとしています。
ファイル編集ツールの最新の進化はどうなっていますか？
私はファイル編集ツールに長年強い関心を持っています — それは以前のAiderコード編集リーダーボードのテーマでもあり、検索・置換ベースから行番号ベース、さらに複雑なパターンへと、さまざまなコーディングエージェントでそれがどう進化してきたかを興味深く見守ってきました。
Claude APIのドキュメントでは、API向けに構築する際に推奨されるテキスト編集ツールが説明されていますが、Claude Codeでは少し異なるアプローチが使われているようです。
Simon: 最も興味深いツールの1つがファイル編集ツールです — ツールとしてファイル編集を持たせることもできますし、sedやgrepを使うように指示することもできます。ファイル編集ツールの最新の進化はどうなっていますか？
Thariq: 今でも持っていますが、たとえばgrepやその他の検索ツール — globツールなど — はネイティブなbashに置き換えて削除しました。先ほどのトークでも言ったように、モデルは物理というより生物に近いもので、特にツール設計は非常に難しいのです。Catはそれに反対して、評価には科学があると思っているかもしれませんが、ツール設計はどちらかというと芸術 — あるいは生物学 — だと思います。
Cat: 私もおおむね同意しますが、一般的に新しいツールを導入する際は、全体の数をかなり少なく保ち、追加するすべてのツールが他のツールとは明確に異なる機能を持つようにして、Claudeがそれぞれをいつ呼び出すべきかを非常に簡単に区別できるようにしています。ファイル編集については、それを持っている理由は実際にレンダリングできるからです。Claudeがファイル変更を行う際に、このファイルへの編集を承認しますか？という素敵な専用UIを表示しています。専用のファイル編集ツールを用意した理由は、Claudeがファイル変更を行っていることを確定的に知るためでした。そうすることで、この素敵なUIを人々に見せることができるのです。新規ユーザーのオンボーディングでは今でもこの体験がとても好評なので、残しています。しかし、私たちの多くが今使っているauto modeでは — どうかYOLOモードではないことを願いますが — 実際には関係なく、おそらくファイル編集を削除してもまったく問題ないでしょう。
Anthropic社内でClaude Codeを安全に実行するためのアドバイスは何ですか？
これはプロンプトインジェクションの問題です！Claude Codeのインスタンスが暴走するリスクを、Anthropicの社員以上に説明できる人がいるでしょうか？
彼らはauto modeを本当に信頼しており、それがClaude Tagを可能にした機能だと考えていることがわかりました。
Simon: 安全性とセキュリティについて話しましょう。私はプロンプトインジェクションのリスクを深く認識していますし、他の誰かが私のClaude Codeに指示を出したらどれほど悪いことが起こりうるかもわかっています。それでも私はまだ主にYOLOモードでClaude Codeを実行していて、とても罪悪感を感じています。Anthropic社内でClaude Codeを安全に実行するためのアドバイスは何ですか？
Cat: なぜauto modeを使わないのですか？
Simon: auto modeを使い始めていますが、それがどれほど安全なのかがまだよくわかっていません。3週間ほど前から、デフォルトでauto modeにしています。
Cat: Anthropic社内では、ほぼ全員がauto modeを使っています。Claude Codeで長時間の作業を安全に行うための最良の方法です。私たちは徹底的にbashing（叩き）を行ってきました。何千ものevalsがあります。多くのレッドチーマーに依頼して、Claude Codeを騙して悪意ある行動をさせようとする敵対的な環境を作り出し、見つかったすべての問題を緩和してきました。今後数週間でいくつかのevalsを公開する予定ですが、ほぼすべての攻撃を緩和してきました。
Simon: それは大きな主張ですね。
Cat: 皆さんが評価できるようにevalsを共有しますが、Claudeが失敗しうるすべての方法を特定し、auto modeを更新してそれに対抗するために、非常に綿密に取り組んできました。100%すべてを捉えられるわけではありません — それは強すぎる主張になってしまいます。しかしプロンプトインジェクションやデータ流出といった、私たちが懸念する主要なリスクのカテゴリーについては、平均的な人間のレビュアーよりもはるかにリスクは低くなっています。
彼らのevalsやauto modeを検証するアプローチについて、さらに詳しく知るのがとても楽しみです。
Thariq: auto modeがどのように動くかについて少し補足すると、このメンタルモデルを持っておくと役立ちます。Claudeがターンやbash呼び出しを行うたびに、Sonnetの分類器がツール呼び出しと会話のコンテキスト — あなたの指示 — を評価しています。権限に関するものの中には、あなたのリクエストに依存するものもあります。たとえば、常にgit pushの権限を与えたいわけではありませんが、「これをGitHubにプッシュして」と言えば実行してほしいですし、「プッシュしないで」と言えば拒否してほしい。auto modeはそれをやってくれます。これは私にもよく起こることで、Claudeがとても親切でプロアクティブなために何かをしようとし、auto modeが「これはやるな」という指示を見つけて表面化してくれるのです。つまり、あなた自身がプロンプト内で与えた動的な権限にもうまく対応できるということです。これは本当に重要だと思います。また、私たちのサンドボックス基盤ともうまく連携します。サンドボックスには非常に多くのエッジケースがあり、確定的に追従するのが難しいからです。私たちはサンドボックスを持っており、何かがサンドボックスから抜け出す必要があるとき — たとえばネットワークリクエスト — auto modeがそのリクエストを見て、それが理にかなっているかどうかを判断し、許可することができます。
Simon: auto modeがネットワークのサンドボックスとも連携しているとは知りませんでした。
Cat: ユーザーが本来目にするあらゆる許可プロンプトと連携します。
Simon: auto modeはいつからあるのですか？私がアクセスできる機能としては、2か月ほど前からですよね？
（一般公開されたのは3月24日でした。）
Cat: Anthropic社内では1月から使ってきたので、かなり前から堅牢化を進めてきました。Anthropicは安全性とセキュリティを極めて重視しており、社内でのロールアウトを可能にし、これらのevalsを構築し、世界に公開する前にauto modeをさらに堅牢にするために、アライメントや安全対策のチームと広く連携してきました。
Thariq: これがClaude Tagが非常に優れている理由でもあります — Claude Tagはauto modeを使っています。Slackボットについて「自作するか買うか」という質問をよく聞きますが、正直、自作のAI Slackボットは作るべきではないと思います。攻撃ベクトルがあまりにも多すぎます。ユーザーがフィードバックを投稿できるフィードバックチャンネルがあり、そこからボットがそれを読み込んでしまいます。私たちがauto modeに注いできた作業 — そして私たちは一般的なスイスチーズ防御も持っており、この種のことに対してRLも行っています — これこそがClaude Tagを機能させているものだと思います。あなたの権限とシームレスに連携し、Slackでプロンプトインジェクションされたくないはずです。
auto modeを超えるセキュリティ面での今後の計画はありますか？
Simon: auto modeを超えるセキュリティ面での今後の計画はありますか？
Thariq: 私たちは非常に安全だと思っています。Claude TagではClaude用に独自の認証情報をプロビジョニングできるので、あなたの代理として行動する必要はありません — Claudeを一つのアイデンティティとして持つことができ、それによってClaudeが何をしているかを監査・検査するのも容易になります。
Simon: Claude Tagは誰でも話しかけることで影響を与えられるわけですから、指示を出す人の母集団がはるかに広いわけですね。
Thariq: その通りです。そしてもちろん、Fableによるプローブもありますが、これは私たちの安全性と研究の成果の副産物です。AnthropicがAIセーフティ企業であることが本当に報われる瞬間だと思います。私たちはClaudeが長期間にわたってアラインされた形で実行できることを本当に望んでいますし、それを実現するにはauto modeが基本的に完璧でなければなりません — それはすべて私たちがAIセーフティ企業であることの延長線上にあります。
Cat: リモートコントロールのユーザー向けに、より安全に使いたい人のための信頼できるデバイス（trusted devices）もローンチしました。そしてすべてのリモート環境で、認証情報の注入（credential injection）をサポートしています。Claude CodeにDatadogへアクセスさせたいが、Claude Code自体にDatadogの認証情報を持たせたくない場合、Claude CodeがDatadogリクエストを試みたときにDatadogの認証情報をエージェントからはアクセスできない形で、必要なときだけ挿入するように、アイデンティティと認証情報の管理システムを設定できます。
Claude Codeがプロキシ経由でAPIにアクセスし、そのプロキシがリクエストを監査しつつ関連するAPIキーを注入する — つまりClaudeがAPI認証情報自体にアクセスすることなく認証済みエンドポイントにアクセスできるという、この認証情報注入のパターンはとても気に入っています。
この1年半で、あなた自身の仕事に対する考え方はどう変わりましたか？
Thariq氏は午前の基調講演でFableクラスのモデルがもたらした喪失感について語り、私たちはその対話の中でさらに深掘りしました。私はこれをDeep Blueと呼んでいます。
Simon: 少し人間的な側面について話しましょう。多くの人が、自分がソフトウェア構築において担ってきた役割の多くがモデルに置き換えられつつあることに、喪失感を覚えています。それについてどう考えていますか？この1年半で、あなた自身の仕事や、自分が付加する価値についての考え方はどう変わりましたか？
Thariq: CatやBorisは、もっと野心的でなければならないということを常に思い出させてくれます。彼らはいつも「私たちは急速に成長している、最前線にいなければならない、できる限り最高の仕事をしなければならない」と言っています。それは私にとって常にリマインダーです — 何かに時間がかかっているときは、「もっと速くできないか？もっと野心的にできないか？」と自問します。そして多くの場合、その答えはClaudeです。Claudeはどんどん良くなっているので — 前回試したときは前のモデルでしたから。喪失感については、それは現実だと思います。LLM以前と同じ仕事だけをやろうとして、それが今やプロンプト一つでできてしまうなら、それはやはり少し悲しい感覚だと思います。そしてそれを相殺する方法は、より野心的になることです。Jaredは本当に良い例だと思います — 彼はオークランドのアパートでZigのコードをすべて手書きし、約1年かけてほとんど家から出ずに、それをとても楽しんでやりました。今では彼がBun全体をRustに書き直すのを見て、彼はそれをとても楽しんでやっています — それははるかに野心的であり、それが喪失感を相殺する方法なのです。一般的に言えば、どうすればより大きなことを成し遂げられるか、より多くを成し遂げられるかを問うことです — 成功することは楽しいことだと思います。それは野心を変えることです。
「それを相殺する方法は、より野心的になることだ」という言葉は、私自身がこの問題についてたどり着いた考えを的確に言い表していると思いました。
Simon: そしてCatさん、プロダクトマネジメントの観点からはどう見えますか？
Cat: プロダクトの役割は毎月のように変わっていると感じます。私たちのチームのPMは皆、エンジニア、デザイナー、PMが混ざったような存在です — 実際、ほとんどの人が元はフルタイムのエンジニアでした。私たちにとってそれは、どんな種類のギャップがあっても、そこに入り込むことを意味します。アイデアがあって、それを構築しようとエンジニアにインスピレーションを与えられなかったなら、自分たちで作り、ノートブックに入れて、人々がそれを本番に持っていくように刺激すべきです。デザインが少しずれていると感じたら、似たページを参考にして最初のデザインを作り、細部にこだわるのが得意な人にタグ付けしてギャップを埋めてもらいます。あるいは、社内でチームやプロダクトの採用が拡大し、Claude CodeやClaude Tag、Coworkについて何が起きようとしているのかをもっと多くの人に知ってもらう必要があると気づいたら、ローンチカレンダー全体の把握を自動化し、非同期でステータス更新を自動的に取得するようにして、人々に手間をかけず、社内の告知チャンネルでの更新が完全に詳細で的を射たものになるようにします。私たちにとってそれは、素晴らしいアイデアとそれを顧客に届けることの間にあるギャップが今何なのかを理解し、それをできる限り自動化するにはどうすればよいかを考えることです。
これは私が気づいたこととも重なります。コードをこれほど速く生成できるようになると、誰かからの意思決定を待ってブロックされている時間が、はるかに目立つボトルネックになります。プロダクトの意思決定ができるエンジニアははるかに速く動けますし、その意思決定の1つを間違えるコストも、以前ほど大きなものではなくなります。
Claudeに驚かされた瞬間はありますか？
Simon: Claudeに驚かされた瞬間はありますか？モデルが、自分ではできないと思っていたことをやってのけたときは？
Thariq: Claudeの動画編集についてはたくさん投稿してきましたが、最近ではACM Agenticカンファレンスで講演した際に、「編集されたビデオはありますか？広報チームと共有したいのですが」と聞いたんです。すると「時間がかかっている」と言われました。そこで生のファイルをくださいと頼みました。彼らは私がステージで話しているビデオ、スライドデッキのビデオ、音声ファイルを送ってきて「頑張って」と言いました。これをClaudeに渡し、HTMLのデッキも一緒に渡して「これをまとめて編集してくれない？」と頼みました。そしてClaudeがやったことは本当に信じられないもので — そのまま公開できる出来でした。ビデオ全体を文字起こしするのです。時々スライドデッキのビデオが少しおかしいこと — 真ん中に自動アップデートのポップアップが出ていること — に気づき、「スライドデッキのビデオは使うべきではないな。やるべきは、これをスライスして、あなたがどのスライドにいるかを特定し、代わりにHTMLソースを使うことだ」と判断します。そこでHTMLソースを表示するのです。そして私のビデオもありますが、私はステージのごく一部にしか映っていないので、私がステージ上のどこにいるかに合わせて動的にクロップします — 私は歩き回っているので、歩き回る私を追跡するのです。そして私が話していることを文字起こしします。
Simon: これはFableですよね？
Thariq: ええ、Fableです。良いプロンプトでしたが、ワンショットのプロンプトでした。次に面白いアニメーションやグラフィックを追加してくれと頼んだのですが、本当に驚かされました。ffmpegもRemotionもこなします。
Thariq氏がFableを使ってFable自身のローンチ動画を編集した方法についての動画はこちら、そしてそのローンチ動画自体はこちらです。
まだできないことは何ですか？
Fable 5やGPT-5.6のようなフロンティアモデルが達成できないタスクを思いつくのが、私自身かなり難しくなってきていることを恥ずかしながら認めます。
Cat氏は依然としてそのUXデザインのスキルを高く評価していません。
Simon: できないことは何ですか？まだがっかりしていること — Claude Fable 6に解決してもらうのを待っていることは何ですか？
Cat: デザインとUXのセンスをもっと良くしてほしいです。詳細な仕様を書いたプロンプトを渡せば、たいていはその通りに振る舞ってくれるようになりました。でもパディングがずれていたり、インターフェースがまだ楽しいものになっていなかったりします。アプリがどのようにデザインされるかという既存のベストプラクティスに頼りがちですが、フロンティアなAIプロダクトでは、まだデザインされていない新しいインタラクション体験がたくさんあります。
Simon: Opusの美学というものがありますよね — 見ただけで「ああ、これはOpusがデザインしたな」とわかる。それを超えていけると良いですね。
Cat: ええ。将来のモデルがインタラクションデザインの思考パートナーになってくれることをとても楽しみにしています。
Thariq: できないことですか？もっと現実世界と相互作用してほしいです。科学を解決できるか？実験をオーケストレーションできるか？そこにはコーディングもいくらか含まれますが、それを超えた広い世界に対するセンスも必要です。
Anthropicの文化のどの部分を他社が盗むべきだと思いますか？
これが最後の質問として最適だと思いました。
Simon: Anthropicの企業文化のどの部分が、Anthropicがこれらのツールで生産的であることを独自に助けていると思いますか？他社が盗むべき文化的なハックは何ですか？
Cat: Claude Tagについて一つ共有します。Claude Tagはパブリックチャンネルにあるときに最もよく機能し、チャンネルのほとんどがパブリックであるときに最も力を発揮します。Claude Tagは、可能な限り高い精度の答えを提供するために、すべてのパブリックチャンネルを横断して検索することができます — そしてそれは、すべてにアクセスできる場合にのみ可能です。
Thariq: 基調講演でも触れましたが、私にとって非常に重要なので改めて強調したいことです。共同創業者たちは「自分たち自身と交渉しない」と言いますが、これは本当に重要だと思います。頭の中でトレードオフを想像して、何か野心的なことをするのを自分でやめてしまうこともできます — あるいは、ただ野心的なことをやってみることもできます。私たちはよく「もしやってみたらどうなるか？」と自問しています。これは本当のトレードオフなのか、そうでないのか？もしそうなら、なぜ — それが本当のトレードオフであるという証拠はどこにあるのか、単に合理的に聞こえるだけではないのか？トレードオフを自ら姿を現すようにさせなさい。できる限り野心的でありなさい。
Claudeで作ったお気に入りの突飛なものは何ですか、作れるからという理由だけで作ったものは？
これも聞かずにはいられませんでした。
Simon: Claudeで作ったお気に入りの突飛なものは何ですか、作れるからという理由だけで作ったものは？
Thariq: 自分自身をキャラクターにした2Dストリートファイターの格闘ゲームに取り組んでいます — 友人たちも登場します。Claude Codeを使ってGeminiにプロンプトを送り — 正直Seedanceモデルはかなり良いです — ビデオアニメーションを作らせています。とてもうまくいっています。プロンプトを書くのが本当に上手で、フレームを検証してアニメーションが良いかどうかをチェックすることもできます。
Simon: それはストリートファイター2レベルの2Dスプライトを生成しているのですか？
Thariq: ええ、まさに — 2Dスプライトです。アニメーションは素晴らしく見えます。そしてヒットボックスも理解できます — 「ああ、あなたの拳はここにあるから、JSONのヒットボックスを描くよ」といった具合です。信じられないほどです。
Cat: 私のはもっとシンプルです。私は大のロッククライミング好きで、友人の多くもクライミングをするので、Claude Codeで作った小さなアプリで、取り組んでいる課題をすべて記録しています。みんなでよく外にも行くので、ワークフローを使ってあらゆるリサーチをClaudeにやらせています。ワークフローは素晴らしいです — コーディングツールとしてブランディングしていますが、旅行などのディープリサーチにも素晴らしいのです。チームのオフサイトも私が計画していますが、全員が収まる会場を見つけるのも得意です。ワークフローを使って、私たちが行ってみたいクライミングの目的地をすべてリサーチし、私たち全員がいる場所から直行便がある場所はどこか、Mountain Projectに行って私たちのグレードに合ったクライミングをすべて見つけ、Airbnbを探します。そして私はハイキングが嫌いなので、車を停める場所から実際に岩がある場所までの歩行距離が非常に短いことをとても重視しています — そしてそれでフィルタリングしてくれます。既存のアプリではMountain Projectを手動でクリックして回らなければなりませんが、これならすべての好みを入力するだけで、私たち専用のカスタムアプリができあがります。
Simon: つまり基本的に、山登り用のJiraをバイブコーディングしているわけですね。
Cat: その通りです。
聴衆：eval構築ツールやエージェントの可観測性ツールの計画はありますか？
最後に聴衆からの質問に数分使いました。
聴衆: evalデータセットを構築するためのevalツールや、エージェントやワークフローのパフォーマンスを監視するための可観測性ツールを近い将来構築する計画はありますか？
Cat: evalツールの構築は検討してきましたが、実際には制約となっているのは、顧客が高品質なevalsを構築するのに非常に長い時間がかかるということです。ですから、ツーリングよりも、優れたevalをどう作るかというスキルセットの方が制約になっていると思います。そこは私たちが社内で投資し、外部にもベストプラクティスを共有していきたいと考えている分野です。
聴衆：メモリは現在どのように設計されていますか — ファイルからデータストアに移行することは考えますか？
聴衆 (Sai): メモリとマルチプレイヤーについて興味があります。メモリは現在どのように設計されていますか？ファイルベースだと想定しています。そしてもう一つ、より良くスケールさせるために、ファイルではなくデータストアが実際に必要になるという直交する方向性について考えたことはありますか？
Thariq: 現在Claude Tagのメモリはチャンネル固有です。そのチャンネル内のすべてのClaudeが共有メモリを持ち、インスタンスはセッションを持ちます — しかしセッションはメインメモリに還元することができます。私たちはメモリの研究をたくさん行っており、メモリの正しいやり方が何なのかはやや直感に反することもあります。私たちは常にメモリの実験を行っています。現在Claude Tagでメモリがどう動いているかというと、チャンネルごとのmarkdownファイルです。
コメント
ログインしてコメントする