Anthropic クロードコードチームが語る AI エンジニアリング

今月初め、私は「AI Engineer World's Fair」(2026 年開催) で、Anthropic の Claude Code チームに所属する Cat Wu 氏と Thariq Shihipar 氏を招き、フアイアサイド・チャットを開催しました。議論のテーマは、Claude Code や Claude Tag、Fable といったツール、コーディングエージェントのセキュリティ、評価手法 (evals)、ツールの設計思想、そして Anthropic 自身がこれらのツールをどう活用しているかについてでした。

セッションの完全な動画は現在 YouTube で公開されています。以下に、追加リンクや私の強調を加えた編集版 transcript を掲載します。

*

もし動画視聴や全文の読み込みが難しい場合のために、主要なポイントをいくつかまとめました：

Claude Tag（Claude の新しい共同作業用 Slack 統合機能）は、現在 Claude Code チームの製品エンジニアリングにおける PR の 65% をカバーするまでに成長しました。

Claude Code では新機能がまず Anthropic 社員向けにリリースされ、そのユーザー層での定着率が確認されたものだけが一般公開されます。重要な変更点は依然として手動レビューの対象ですが、製品の「外側」のレイヤーについては自動化されたコードレビューへの依存度が高まっています。

Fable 5 や Opus 4.8 のような最新モデルにおいて、システムプロンプトに例を追加することが最良の方法ではなくなりました。Claude Code のシステムプロンプトは最近、サイズが 80% 削減されています。同様に、「X をしない」「Y をしない」といった禁止事項のリストを列挙することも、最新のモデルにおいては結果の質を下げる要因となり得ます。

Anthropic 社内での自社製品活用は「ant fooding（アリ食い）」と呼ばれています。Anthropic は自動モードに強い信頼を寄せており、これを Claude Tag の基盤技術と捉えています。

Thariq は、コーディングエージェントによる深い没入感（Deep Blue）に対抗するためには、「取り組む仕事に対してより野心的であること」が重要だとアドバイスしています。

Fable は動画編集にも対応しており、Thariq 自身が Fable を使って製品発表用の動画を編集しました。

社内での作業を公開する文化こそが Anthropic の成功の鍵であり、その象徴として公共の Slack チャンネルで Claude Tag を活用している様子が示されています。

Simon: クロード・コードは昨年 2 月に登場しました。まだ 1 年半も経っていない新しいツールですが、当初は Claude Sonnet 3.7 の発表の項目の一つに過ぎませんでした。実際に私たちをサポートするコーディングエージェントが誕生した今、日々の業務はどのように変化しましたか？

Cat: クロード・コードと Sonnet 3.7 を初めてリリースした頃を思い出します。その頃はタスクを与えると、一つ一つの動作を細かく監視する必要がありました。私はすべての権限プロンプトに非常に慎重に対応し、「いいえ」と答えることも頻繁でした。「このファイルを確認しましたか？」「あのファイルも確認しましたか？」と。しかし、モデルのバージョンが上がるにつれて劇的に改善されました。私たちは皆、些末な実装作業をクロード・コードに任せることで一歩引く機会を得ました。これにより、クリエイティブな仕事に集中する時間が大幅に増えました。「クロード・コードなら多くの機能を実装できる」という前提のもと、「ユーザーにどのような体験を提供すべきか」を考える時間です。そして Fable の登場は、さらに一段階大きな飛躍をもたらしました。Fable を使えば、多くのユースケースで一度の指示だけで多数の機能を構築できるようになりました。

Thariq: Claude Code に関する最初の連絡を覚えています。親友の一人から「Claude Code を試す必要があるよ」と言われたんです。Opus 4 がリリースされた頃の話で、実際に使ってみて「おっと、これはヤバい。Anthropic で働くべきだ」と思ったものです。あの Opus 4 は素晴らしいモデルでしたが、それでも許可プロンプトを読み込む必要がありました。

自動モードが昔から存在していたかのような錯覚に陥るほど、私たちは記憶を失っているのかもしれませんね。自分が「はい」や「許可」を押したことをさえ覚えていないのです。私自身、今特に力を入れているのは、これまでにない高品質な仕事をする必要があるという点です。出力の質は非常に高いですが、私は動画編集に頻繁に使っています。ブランドチームが求める極めて厳格な基準を数時間でクリアできなければ、プロジェクトは成立しないのです。

これが私が Fable で目指している変化です。これまでで最良の仕事を、これまで以上に速く成し遂げることです。

従来のソフトウェアエンジニアリングのどの常識がもはや通用しないのか？

3:39

Simon: 一年前までは真実だったとされる、従来のソフトウェアエンジニアリングにおける「常識」で、新しい世界ではもはや通用しないものはありますか？

Cat: 私たちが今、エンジニアリングのスキルセットにおいて最も大きな変化として感じていることのひとつは、2 年前と現在では状況が逆転している点です。かつては、プロダクトマネージャーが顧客に直接話を聞き、6 ヶ月かけて横断的なチームと合意形成を図り、コードを一行も書かれる前に「どのように実装するか」を詳細に記した仕様書を完成させるのが一般的でした。

しかし現在は状況が全く逆です。私がこの場にいるエンジニアの皆さんにお勧めするのは、私たちが何を構築すべきかについて、ビジネス感覚やプロダクト感覚をさらに磨いてほしいということです。アイデアから実装までのタイムラインが劇的に短縮されたからです。6 ヶ月〜12 ヶ月かかっていたものが、今ではわずか 1 週間程度で済むケースもあります。

つまり、私たちが何を構築する価値があるのか、実際に事業にどのような影響を与えるのかについて、より優れた「味覚（センス）」を持つ必要があるのです。多くのプロダクト領域では、「実行力」よりも「プロダクトの味覚とビジネス感覚」の重要性が増していると言えます。もちろん、インフラ分野では、細部まで正確であることの重視という点は依然として変わりません。

Thariq: 私にとって重要なのは、リワーク（書き直し）がもはや悪いことではないということです。

Simon: かつては最悪の行為とされていたことが、今や許容されるようになっているのです。

Thariq: その通りです。『ミステリアス・マン・マンス』の教訓にある「書き換えはするな」という考え方は、今は否定します。むしろ私は書き換えを支持しています。良いテストスイートがあればこそ——実は書き直しを行うことで、良いテストスイートを整える必要性に気づかされるのだと思います。ただ、人々が過小評価しているのは、コードベースそのものが仕様書であるという点です。場合によっては、それが唯一の仕様書の写しになることもあります。なぜなら、誰もコードベースのすべての分岐を完全に把握しているわけではないからです。このコードベースを一つの成果物として捉え、要約したり、別のバージョンを作成したりすることも可能です。実際にBun を Rust で書き直した事例がありますが、これは非常にうまく機能しています——私自身も現在、これを実環境で利用しています。

Simon: Claude Code はまだ Bun in Rust 版としてリリースされていないんですよね？

Thariq: 社内では既に展開済みです。

(実際には Anthropic は、6 月 17 日付で一般ユーザー向けに Claude Code の Bun in Rust 版の提供を開始したようです。)

エンジニア以外の人は Claude Tag で何をしているのか？

6:36

Simon: この他にも最近大きな話題となったのが、Claude Tag です。少なくとも一般ユーザーにとっては、すでに一週間以上が経過しています。Anthropic 社内ではエンジニア以外の社員も Claude Tag を非常に活用しているとのことです。具体的に、エンジニア以外の人は Claude Tag でどのようなことをしているのでしょうか？

Cat: Claude Tag は、チームの協働ツールに常駐する Claude です。先週、Slack 内で公開しました。Claude Tag の最大の特徴は、デフォルトでマルチプレイヤー対応している点です。Slack チャンネルに Claude Tag を追加すれば、あなたも参加でき、同僚も参加できます。そして共同でプルリクエスト（PR）に取り組むことができます。

もう一つ大きな違いは、受動的ではなく能動的であることです。「このチャンネルのすべてのバグ報告を監視し、修正用の PR を作成して、そのコード部分を最後に更新したエンジニアにタグ付けして」と指示すれば、チャンネルが存続する限り、毎回手動で呼び出すことなく自動的に実行してくれます。

3 つ目の大きな変化は、チームメモリ機能を追加した点です。チャンネル内で Claude Tag にあなたの好みを伝えれば、今後の投稿でもそれを記憶します。「障害のデバッグはしてほしいが、警告のデバッグは不要」といった設定を自然言語でチャンネル内に伝えるだけで、あなたとチームメンバー全員のためにその設定を覚えておいてくれます。

社内の見解では、Claude Tag は Claude Code の進化形です。これは社内での働き方における大きな転換点だと捉えています。現在、Claude Tag が処理するプロダクトエンジニアリングの PR 比率は 65% に達しています。

Simon: それは Anthropic 全体の話ですか？それとも Claude Code だけの話ですか？

Cat: これは製品エンジニアリングチーム向けの話ですが、社内で使っているバージョンの Claude Tag は、現在、製品のプルリクエストの 65% を処理しています。これは大きな転換点で、全 PR の半数以上を占めるようになりました。Claude Code と Claude Tag の役割分担については、以下のように捉えています。最も複雑なタスクや、エージェントと対話しながら反復して作業する際には、依然として Claude Code が最適です。一方で、Claude Tag は「自分たちの代わりに積極的に作業させる」のに適しています。これにより、開発中の機能で発生するバグ報告に対して、いちいち手動で Claude Code を起動する必要がなくなります。

Thariq: コーディング以外のケースでも活用できます。例えば今回のトークの前、私たちは Claude Tag に「Fable のリリース日はいつですか？」と尋ねました。発表に合わせて準備を整えるためです。Claude Tag は社内の Slack を検索し、誰が何を発言したかを確認します。これは企業内における検索エンジンとして非常に価値があります。製品に関する文脈をすべて把握しているため、数値に関する質問にも答えることができます。意思決定をする際、その根拠となるデータを提示してほしい場合が多いからです。そのため、イベントストアに接続して活用しています。マーケティングチームでは、「この機能について教えてください」といった使い方もしています。彼らはプログラマーではありませんが、Claude はプログラマーとして振る舞い、コードベースをクローンした上で「これがその機能で、こんな見た目です私が実際に使っている様子を録画しました」と説明できます。これにより非常に多様な活用が可能になり、私たちはまだその可能性を探り始めたばかりだと考えています。

チームでの協働を担う Claude Tag

10:06

Simon: コーディングエージェントを使う際、個人で使う方法なら理解できても、チーム環境でどう活用すればいいかについてはまだ明確にできていないという課題があります。Claude Tag は、まさにそのチームでの協働を担うレイヤーとしての回答ではないでしょうか。

Cat: その通りです。実際、セッションの多くがマルチプレイヤー形式で行われています。例えば「Cowork に新機能を追加すべきだ」と提案し、Claude Tag をタグ付けして第一ラウンドを担当させます。その後、「最終的な実装結果を記録として共有してほしい」と指示し、さらにデザイン担当者をタグ付けしてレビューしてもらいます。デザインチームからのフィードバックを受け取った後、エンジニアリングチームに引き継がれて完成まで進められ、本番環境へリリースされます。非常にスムーズな体験です。同じセッションをどう操るかという社会的なダイナミクスについてはまだ整理中ですが、人々は他者の使い方を観察し、そのノーム（慣習）に従う傾向があります。Claude Tag をチームに組み込む際も、直感的で問題なく受け入れられています。

Thariq: 人を教えるのにも役立ちますし、「スロップ（雑多な作業）」を減らす効果もあります。全員が一緒に Claude を使っている様子を目にするという事実自体が、Claude の使い方をレベルアップさせるからです。

これは、Midjourney が Discord チャンネルでパブリックにプロンプトを入力することを義務付けることで、高度な画像生成のプロンプト技術を普及させた事例を思い出させます。

ビルドコストが劇的に下がった今、どの機能に投資すべきかどう決めるのか？

11:41

私自身も非常に難しいと感じているのが、「コストが下がりすぎてしまった今、どの機能をリリースする価値があるのか」を見極めることです。

Simon: エンジニアリングにおける最大の難問である「優先順位の付け方」について、どうお考えですか？特に、機能の開発コストがこれほど安価になった現在、どの機能に投資し、リリースすべきかをどのように判断されているのでしょうか？

Cat: これがまさに難しいところです。私たちが取り組んでいるアプローチはいくつかあります。まず一つ目は、製品を毎日社内で実際に使い倒す「ドッグフーディング」です。社内製品で実現したい機能がない場合、代替手段を探すのではなく、その機能をサポートできるように製品自体を改善します。私たちは社内に非常に強いドッグフーディング文化があります。 世界中のユーザーに公開する前に、まずは Anthropic の全社員と、率直なフィードバック（できれば厳しい意見）を提供してくれる初期顧客に共有し、人々が本当に気に入るまで何度も改良を重ねます。製品を世に出すには、一定数のアクティブユーザー数やリテンション率という社内基準を満たす必要があります。 この基準が明確であるため、すべてのエンジニアが目指すべきゴールを理解しています。このプロセスは製品の完成度を高めることにもつながります。なぜなら、機能が洗練されていないとユーザーは離れてしまうからです。もしそうなれば、その機能はまだリリースするべきではないのです。

機能のリリース可否を、内部ユーザーの定着率という指標で判断するのは、私には非常に理にかなっていると思います。

驚いた機能の事例はありますか？

12:54

Simon: 驚いた機能の事例はありますか？リリースした当初、想定外のほどにエンゲージメントが爆発し、本来ならリリースされないだろうと見られていたものが、実際に製品として定着したようなケースです。

Cat: 確かに一つあります。チームの多くの方が リモートコントロール を愛用していますね。この機能を使えば、モバイル端末や Web ブラウザ上の Claude から、ローカル環境で CLI 上で動作している Claude Code セッションに接続できます。

私自身は、この機能が必要になることがありませんでした。というのも、私は簡単なコーディングタスクを直接モバイルで起動し、ローカル環境を使わずにクラウドセッションで実行するからです。そのため当初は「みんながリモート開発環境を設定すればいいのに」と思っていました。

しかし実際には、リモートコントロール機能をリリースした後に多くのユーザーにお話しすると、彼らが毎晩行っているのは、「ラップトップを充電器に繋ぎ、複数のリモートコントロールセッションを開き、画面をロックしてソファからスマホで Claude Code を操作する」という流れでした。これは私が当初理解していなかった、今ではチームが力を入れているワークフローなのです。

クロード・コードの生産環境コード、全行を人間がレビューしているのか？

14:20

今回のカンファレンスで繰り返し語られたテーマの一つに「レビュー」がありました。コーディング・エージェントが生成したコードを、人間がどの程度厳密にチェックしているかという点です。私はぜひとも、Claude Code の開発チームの考えを伺いたかったのです。

Simon: コードレビューはどのように行われているのでしょうか？生産環境にデプロイされる Claude Code 内の全行コードについて、人間によるレビューは必須となっていますか？ もしそうではない場合、你们はどのような対策を講じて品質を維持しているのでしょうか？

Thariq: タスクの内容によって対応は異なります。重要な領域については「コードオーナー」を設けています。 システムプロンプトがその好例です。ここには明確なコードオーナーがおり、変更には必ず承認が必要です。

Simon: つまり、コードオーナーはその領域の品質に対して直接責任を負うわけですね。

Thariq: その通りです。

Cat: したがって、該当するコードに触れるプルリクエスト（PR）については、必ずそのオーナーの承認を得る必要があります。

Thariq: 私たちのチームでは、コードレビュー用の GitHub ボット がすべての PR をチェックしています。このボットはあらゆる PR に適用され、実際にはレビューの大部分を担っています。私がチームで目にするのは、より複雑な PR の場合、他のメンバーがレビューしやすいように「PR 解説用のアーティファクト」を作成するケースです。また、何かが失敗した際に必ずテストが実行されるよう、検証や CI/CD への投資にも力を入れています。Claude が Claude Code を制御してテストできる、非常に堅牢な環境も用意されています。つまり、コードレビューには多角的なアプローチを採用しているのです。

Cat: 一般的に、私たちは人間がループ（プロセス）に参加する必要のない世界へ移行しようとしています。Claude Code のコアや他のプロダクトのコアに対する最も重要な変更については、常にコードオーナーが存在し、すべての変更を手動でレビューします。しかし次第に、外側のレイヤーにおける変更については、Claude がコードレビューを完全に担当するようになりました。これは一見恐ろしく聞こえるかもしれませんが、ここに至るまでには 6 ヶ月以上ものプロセスがありました。コードレビューへの信頼を築くためには、小さな一歩（ベビーステップ）を踏むことが必要です。当初はすべての変更を手動でレビューしていましたが、次第に「このファイルに触れるコード変更については、コードレビューが 100% の問題を捕捉している」と判断し、「人間による手動レビューは不要だ」という方針へと移行していきました。

インシデント発生時のレビューでは、原因となった PR（プルリクエスト）を確認し、「どのようにしてコードレビューを改善すれば、同様の問題を検出できるか」を検討します。そしてその PR を評価セットに追加し、将来のコードレビューへの修正がその指標を低下させないことを保証しています。人間をコードレビューのループから外すことは大きな前進ですが、一晩でできることではありません。しかし、コードレビューが重要なすべての問題を捕捉しているという確信を得るために、インフラストラクチャに数ヶ月をかけて投資することで実現可能な道です。

つまり鍵となるのは、自動化プロセスを絶えず反復改善していくことです。