この記事は、著者が司会を務めた Anthropic の Claude Code チームのメンバー 2 人とのファイアサイドチャットの書き起こしを編集し、リンクと著者自身によるハイライトを加えたものである。冒頭には書き起こし全体を読みたくない読者向けの要点メモがあり、それが記事の重点のありかをよく示している。チーム自身の仕事がどう変わったか、システムプロンプトに対して何をやめたか、そしてコードレビューをどこまで人間の手から移したか、である。
記事には 2 つの流れが貫かれている。1 つ目は組織に関するものである。チームは、Slack 常駐エージェントである Claude Tag が現在プロダクトエンジニアリングのプルリクエストの 65% をマージまで持っていっていること、機能は外部に出荷される前に社内のアクティブユーザー数とリテンションの基準をクリアしなければならないこと、そして 6 か月以上に及ぶと彼らが述べるプロセスを経て、すべてを人間がレビューする体制から、プロダクトの外側のレイヤーについては完全に自動化されたレビューへと移行し、中核部分にはコードオーナーを残していることを報告している。彼らがその要因とする仕組みは反復的なものである。インシデントが起きると原因となったプルリクエストを調べ、それを検出できるようにコードレビューをどう更新すべきかを問い、そのプルリクエストを eval セットに追加して指標が後退しないようにする。
2 つ目はプロンプティングに関するものであり、記事の中で最も密度の高い部分である。彼らは最も高性能なモデル向けに Claude Code のシステムプロンプトを 80% 削減したと報告し、2 つの具体的な方針転換を説明している。例を取り除いたことは非常に有効だった。モデルは与えられた例よりも創造的だったからである。また、「X をするな」という長い指示のリストは、特にユーザーの後からの指示と矛盾する場合に出力品質を下げうる。彼らが示す一般化は、あらゆる指示についてエッジケースを探し、つまり 90% だけ正しい記述を見つけ出して、それを和らげるというものである。その根拠は、プロンプトはモデルに 100% の頻度で与えられるという点にある。著者は、これがモデルの判断力に頼ることに等しく、それはフロンティアモデルの水準でしか得られないと指摘しており、チームは現在モデルごとに異なるシステムプロンプトを運用していることを認めている。
要点
- チームは、社内版の Claude Tag がプロダクトエンジニアリングのプルリクエストの 65% をマージまで持っていっていると報告しており、これを Claude Code の進化形であり、社内での働き方の大きな転換だと位置づけている。
- 報告されている役割分担は、人間が対話的に反復する最も複雑なタスクには引き続き Claude Code が最適な場であり、Claude Tag は毎回起動しなくてもエージェントに能動的に働かせるためのものだというものである。
- 機能は世界に公開される前に、社内で測定されるアクティブユーザー数とリテンションの基準をクリアしなければならない。彼らは、基準が非常に明確であることで、すべてのエンジニアが何を目指しているのかがわかると述べている。
- その基準についての彼らの理由づけには完成度も含まれる。機能が磨き上げられていなければ人は離脱し、その場合その機能は出荷すべきではないと結論づけている。
- プロダクトの中核に対する最も重要な変更には、すべての変更を手作業でレビューするコードオーナーが必ずおり、そうした領域の例としてシステムプロンプトが挙げられている。
- 外側のレイヤーへの変更については、人間をループに入れずに Claude のコードレビューに完全にレビューさせていると報告している。そこに至るまでには、段階的に信頼を築く 6 か月以上のプロセスを経たという。
- 彼らが説明する信頼構築の方法はファイル単位のものである。自動レビューが問題を 100% 検出していたコード変更を特定し、それらのファイルについては人間のレビュアーを外す。
- インシデントのループはレビュー品質に直接フィードバックされる。インシデントの原因となったプルリクエストを調べ、それを検出するためにコードレビューをどう更新すべきかを問い、そのプルリクエストを eval セットに追加して、今後の変更で指標が後退しないようにする。
- 時間をかけて eval の基盤を積み上げる目的は、新しいモデルをそのまま差し替えられるようにすることだと述べている。eval セット全体を実行し、新しいモデルが厳密に上回った場合にのみ採用する。
- あるシステムプロンプトの調整がプロダクトを改善するかどうかについて完全な確信はないと報告しており、主に能力を最適化しつつ、ユーザーが嫌がることについては別途振る舞いの eval セットを構築していると説明している。
- Claude Code のシステムプロンプトはフロンティアモデル向けに 80% 縮小された。これは特定のリリースではなくそれらのモデルに起因するものとされ、古いモデルでは完全なプロンプトが維持されている。
- システムプロンプトから例を取り除いたことは非常に有効だったと報告されている。その理由として、モデルが提供された例よりも創造的だったことが挙げられ、以前のベストプラクティスからの転換として提示されている。
- 「X をするな」という指示のリストは、モデルにとって非常に強い衝動になり、ユーザーの後からの指示と矛盾する場合に混乱を招くと説明されている。そのためチームは、ハードな制約を減らし、コンテキストを増やし、指示全体を減らす方向に移った。
- 彼らがそこから一般化するプロンプティングのヒューリスティックは、指示が 90% しか正しくないエッジケースを探し、善意の人間がそれをどう誤読しうるかを想像し、100% の場合に正確になるよう文言を和らげるというものである。
- その具体例は検証である。フロントエンドの変更を常に検証せよという指示は、ユーザー体験に対する比較的大きな変更ではアプリをローカルで実行するという、より柔らかい記述に置き換えられた。ただし何が大きな変更にあたるかが定義されていないため、それでも不完全だと彼らは指摘している。
- 彼らはモデルごとに異なるシステムプロンプトを運用していると報告しており、著者はこれを、指示を和らげることはそれを適用する判断力をモデルが持っていることに依存するという事実と結びつけている。
- ツール設計について示されている方向性はツールを減らすことであり、新しいツールにはそれぞれ他のすべてと異なる機能を持たせ、どのツールをいつ呼ぶべきかをモデルが容易に判断できるようにする。
- 独自の grep と glob の検索ツールをネイティブの bash に置き換えて削除した一方、ファイル編集専用のツールは表示上の理由で残していると報告している。ファイル変更が行われていることを決定論的に把握でき、それに対する承認 UI を表示できるからである。
- そのうちの 1 人は、auto モードのユーザーにとってはファイル編集ツールはおそらくもはや重要ではなく、削除できる可能性が高いと述べている。
- チームが表明するセキュリティ上の立場は、承認の判断をモデルに委ねるパーミッションモードである auto モードに依拠している。数千の eval、敵対的な環境を構築する複数の委託レッドチーム、そして発見されたすべての問題を緩和したことを報告しつつ、攻撃を 100% 検出するというより強い主張ははっきりと避けている。
- 彼らの比較によれば、懸念する主要なリスクカテゴリ、とりわけプロンプトインジェクションとデータ持ち出しについては、リスクは平均的な人間のレビュアーよりはるかに低い。
- 彼らは独自の AI Slack ボットを構築しないよう勧めている。ユーザーが投稿できるフィードバックチャネルは、ボットが読み取る入力になるからである。そしてこれが、自分たちのパーミッションに関する取り組みこそが Claude Tag を成立させている理由だとされる。
- さらに 2 つの隔離の仕組みが説明されている。1 つは Claude Tag において Claude に独自の認証情報を付与し、Claude が独自のアイデンティティとして行動し監査できるようにすること。もう 1 つは認証情報の注入であり、プロキシがエージェントのリクエストに認証情報を挿入することで、エージェントはそれにアクセスできないまま利用できる。
- 人間の側については、1 人が、以前の仕事が今ではプロンプト 1 つで済んでしまう開発者たちの間に本当の喪失感があると報告しており、その感情に異を唱えるのではなく、より野心的になることをそれを補う方法として提示している。
- もう 1 人は、プロダクトの役割がエンジニア、デザイナー、プロダクトマネージャーを混ぜ合わせたものに収束しつつあり、その仕事はアイデアと出荷された変更の間にあるあらゆる隙間を埋めることだと述べている。
- モデルにまだできないことを問われて、彼らはデザインとインタラクションのセンス（1 人は、フロンティアの AI プロダクトにはまだ設計されていないインタラクション体験が必要だと指摘している）と、物理世界とのやり取りを挙げている。
- 他社が真似できる文化的実践として 2 つが挙げられている。エージェントはアクセスできるものしか検索できないため、ほとんどの Slack チャネルを公開にしておくこと。そして、自分自身と交渉しないという原則、すなわち野心的な仕事を自ら思いとどまるのではなく、トレードオフに自らを証明させることである。
- 社内でのドッグフーディングは「ant fooding」と呼ばれていると報告されている。
- Claude Tag のメモリは現在、チャネルごとの Markdown ファイルであり、そのチャネル内のすべてのインスタンスで共有され、セッションからメインのメモリに書き戻すことができると報告している。
- eval のツールについては、構築を検討したものの、制約要因は利用可能なツールではなく良い eval を書くスキルだと判断したと報告している。
背景
この記事は著者が自ら編集し、リンクを張り、ハイライトを付けた書き起こしであるため、枠組みは著者のものであり、主張は話し手たちのものである。記事の実質的な内容のほぼすべては、ベンダーが自社のプロダクトと社内の実践について語ったものであり、著者はそれが重要になる箇所に印をつけている。セキュリティに関する主張については話し手に面と向かって「大きな主張だ」と述べ、他者が評価できるよう eval を公開するという返答を記録し、それを見るのを楽しみにしていると書いている。プルリクエストの 65%、プロンプトの 80% 削減、数千の eval といったいくつかの数字は報告された数値であり、外部による検証は示されていない。著者はまた、プロンプトこそがドキュメントであるという主張に基づき、チームにプロンプトを公開してほしいという以前からの要望を改めて表明する場としてもこの記事を使っている。記事が会話の外に言及する場合、それは測定のためではなく裏付けのためである。著者は競合ベンダー自身が公開しているプロンプティングのガイダンスを、同じ方向を向いた助言として付け加えているが、それはそのベンダーの主張でありチームの主張ではなく、ここでは確認されていない。自動レビューのテーマはエージェント型コードレビューで、それとトレードオフの関係にあるレビュー能力はレビューのボトルネックで、それぞれ独立したテーマとして扱われている。セキュリティの議論の要となる auto モードはパーミッションモードで扱われている。