エージェント・ソフトウェア・エンジニアリング #5 | Anthropic の Rust 実践を徹底解剖：AI が生成したコードは、なぜ本番環境で稼働できるのか？

2026 年初頭、Anthropic は一連の Rust プロジェクトとエンジニアリングの知見を精力的に公開しました。

2 月には、16 人の Claude エージェントが並列で構築した C コンパイラ（claudes-c-compiler）を発表。

3 月には、Protobuf ライブラリ「buffa」と RPC フレームワーク「connect-rust」^[1]を同時にオープンソース化し、2 つの深い技術的洞察に満ちたエンジニアリングブログを公開しました。1 つは C コンパイラにおけるエージェントチームの経験に関する「Building a C compiler with a team of parallel Claudes」^[2]、もう 1 つは長期間実行されるアプリケーション開発におけるハーネス設計に関する「Harness design for long-running application development」^[3]です。さらに Anthropic は、非同期ランタイムである anthropics/tokio^[4]と並列キャッシュである anthropics/moka^[5]という 2 つの重要な Rust 基盤ライブラリをフォークし、本番環境における真の技術的ニーズを浮き彫りにするための修正を施しました。

これらの資料は表面上はそれぞれ独立しているように見えますが、総合的に分析すると、それらが AI コーディングの完全かつ再利用可能な方法論をコード化していることがわかります。本稿では、Anthropic による Rust の活用状況から始め、これら 5 つのプロジェクトと 2 つのブログ記事を階層的に解体し、最終的に体系的な AI コーディングのベストプラクティスを抽出します。

1. Anthropic はなぜ Rust を選ぶのか

Anthropic は AI 企業ですが、そのエンジニアリング体制において Rust が占める比重は、外部の認識を遥かに超えています。

Anthropic のビルドシステム職（2026 年 3 月現在）の求人詳細は、重要な事実を明らかにしています。同社のモノレポ（Monorepo）は Python、Rust、Go の 3 言語にまたがり、構築ターゲットは TPU、Trainium、GPU など多様なアクセラレータプラットフォームを網羅しています。この求人では「Rust ビルドツールチェーン（cargo、maturin）と Python-Rust 間連携の知識」が明確に求められています。

これはつまり、Rust が Anthropic システムの「要（かなめ）」となっていることを意味します。

2026 年 3 月時点での 14 以上の求人情報を分析すると、Rust は少なくと以下のチームで言及されています。

• 推論サービス：数百万ユーザー向け Claude 推論。数千のアクセラレータを跨ぐインテリジェントなルーティングと LLM 推論の最適化。
• ビルドシステム：Rust は中核となる必須言語。ビルドインフラの封印やリモートビルドの実行に使用。
• サンドボックス（2 つの独立した職種）：安全なサンドボックス実行者、カーネル最適化、仮想化、軽量 VM ソリューション。
• セキュリティエンジニアリング（ロンドン、サンフランシスコ、シアトルなど複数の職種）：認証アーキテクチャ、暗号基盤、CI/CD の強化、そして「セキュリティ研究所」における実験的なセキュリティ研究。
• エージェントインフラ：自律型エージェントの実行環境、状態管理、セキュリティ境界。

これらに加え、推論デプロイメント、強化学習研究（Horizons）、解釈可能性研究、中核インフラなどのチームでも利用されています。

5 つの Rust リポジトリ：3 つの独自プロジェクトと 2 つの深いフォーク

Anthropic の GitHub 組織には現在、3 つの独自 Rust リポジトリと、実質的な修正が施された 2 つのフォークが存在します。

3 つの独自プロジェクトはAI 関与のグラデーション（100% AI → AI 主導 → 人間主導）を構成し、2 つのフォークは Anthropic における本番環境の深淵なニーズ、つまり高並列の本番サービスでしか発生しないランタイムレベルの問題を露呈させています。

2. Anthropic 発の 5 つの Rust オープンソースプロジェクトを技術解説

claudes-c-compiler：100% AI 自律コーディングのストレステストと能力実演

2026 年 2 月、Anthropic のセキュリティ研究者である Nicholas Carlini 氏は、16 人の並列動作する Claude Opus 4.6 エージェントを用い、ゼロから Rust 製 C コンパイラを構築しました。期間 2 週間、約 2,000 回の Claude Code セッション、費用にして約 2 万ドル、そして 10 万行の Rust コードが生み出されました。

claudes-c-compilerは、x86-64、i686、AArch64、RISC-V の各バックエンドに対応し、アセンブラとリンカを内蔵。修正前の Linux 6.9 カーネルをコンパイル可能で、GCC、Clang/LLVM、Intel oneAPI の仲間に並びました。さらに QEMU、FFmpeg、SQLite、PostgreSQL、Redis のコンパイルにも成功し、GCC の Torture Test の 99% に合格。そして開発者にとっての究極の試金石、Doom をコンパイルして実行できることも証明しました。Anthropic は、Doom のコンパイルと実行を通じて、AI 生成コードがコンパイルを通るだけでなく、ランタイムで複雑なリアルタイムロジックを正しく実行できることを示したのです。

これはプログラマー文化における興味深い伝統です。1993 年に id Software が発表した『Doom』は、本格的な 3D ファーストパーソン・シューティングゲームの先駆けとなりました。John Carmack 氏の手によるエンジンは当時として極めて効率的で、386 プロセッサ上でも滑らかに動作しました。そのソースコードは 1997 年に GPL ライセンスで公開されました。それ以来、「Doom は動くか」は半分冗談めかした技術検証の基準となりました。コミュニティでは、プリンター上で Doom を動かしたり、妊娠検査薬の画面で動かしたり、ATM で動かしたり、Minecraft 内で動かしたりする人が現れました。これは一種のミームとなりましたが、その裏には深刻な技術的意味合いがあります。Doom のソースコードは C 言語でわずか 4 万行程度ですが、コンパイラに対する試練は極めて包括的です。膨大な C 言語機能を網羅し、即座に正しさを検証可能で、依存チェーンが長く、実際のパフォーマンス負荷もかかります。

これはクリーンルーム実装、つまり Claude は開発中、インターネットにアクセスできず、Rust 標準ライブラリのみに依存していました。コード内に unsafe ブロックは 1 つもありません。

ただし、明確な限界もあります。16 ビット x86 コンパイラ（Linux のブートに GCC 呼び出しが必要）を欠き、生成されるマシンコードの効率は最適化を無効化した GCC の出力よりも劣り、Rust コードの品質も「まともだが専門家レベルには程遠い」ものです。Carlini 氏は「コンパイラは Opus の能力限界にほぼ達している」と率直に認めています。

アーキテクチャは極めてシンプルで、bash の無限ループ 1 つです。

while true; do
    claude --dangerously-skip-permissions \
            -p "$(cat AGENT_PROMPT.md)" \
            --model claude-opus-X-Y &> "$LOGFILE"
done

16 個の Docker コンテナがそれぞれこのループを実行し、git で同期します。オーケストレータエージェントも複雑なオーケストレーションフレームワークもありません。調整メカニズムはファイルロックです。エージェントは current_tasks/ ディレクトリにファイルを作成して占有し、git の競合解決メカニズムが自然と競合を処理します。

このプロジェクトは公開後、技術コミュニティから嘲笑されることもありましたが、重要なのは、これがOpus 4.6 の能力披露を目的としており、本番環境での代替を意図したものではないという点です。明らかに GCC の代わりにはなり得ません。私は以前、このプロジェクトを「俳優（アクター）」と呼んでいました。

正しい視点さえ持てば、このプロジェクトから多くのことを学び、ノイズをシグナルに変えることができます。

claudes-c-compiler のソースコードを見て、私は 1 つの疑問を抱きました。「なぜ CLAUDE.md がないのか？」と。

随后、あることに気づきました。CLAUDE.md とは人間が Claude のために作る操作マニュアルであり、人間と機械の協調作業用なのです。

一方、claudes-c-compiler のモードは全く異なり、自律的に動作します。先ほどの Bash ループ（コンテナ内でのみ実行）に戻りましょう。

#!/bin/bash
while true; do
    COMMIT=$(git rev-parse --short=6 HEAD)
    LOGFILE="agent_logs/agent_${COMMIT}.log"
    claude --dangerously-skip-permissions \
            -p "$(cat AGENT_PROMPT.md)" \
            --model claude-opus-X-Y &> "$LOGFILE"
done

この bash コードは、ある種の「ラルフ・ループ（Ralph Loop）」の基本形です。「ラルフ・ループ（Ralph Wiggum loop）」とは、『ザ・シンプソンズ』に登場する天真爛漫で疲れを知らない少年ラルフ・ウィガムにちなみ、Claude Code コミュニティで流行している、AI エージェントを自律的に働き続けさせる手法のことです。

--dangerously-skip-permissions は、ここで全権限確認をスキップするオプションです。個人のマシンでラルフ・ループを回す場合、人間がたまに様子を見ることもありますが、Carlini 氏のバージョンは真の意味での「起動して放置」であるため、権限のプロンプトをスキップする必要があります（さもないと Claude は「cargo build を実行してよろしいですか？」といった確認で止まってしまいます）。その代償として、安全性の確保はコンテナ隔離に委ねられています。

Carlini 氏はブログの中で、興味深い「Claude Code の自殺」というエピソードも明かしています。Claude が誤って pkill -9 bash を実行してしまい、自身が動作していた bash プロセスを殺害、ループが終了してしまったというものです。

各ループで、Claude は真新しい Docker コンテナに放り込まれ、AGENT_PROMPT.md を読み込み、タスクが完了するまで自律的に動作します。人間が横で対話することも、「コミット前のチェック」という概念もありません。Claude 自身が、何を、どう、いつプッシュするかを決定します。

このモードでは、CLAUDE.md の 2 つの機能が他のメカニズムによって代替されています。

• 操作指示：AGENT_PROMPT.md が担います（「問題を小さな単位に分解し、進捗を追跡し、完璧になるまで継続せよ」といった指示が含まれます。非公開ですがブログに記載があります）。
• 長期記憶：Claude自身が維持するファイルシステムが担います。

並列実行のため、current_tasks/ というディレクトリを分散タスクリックとして使用します。このディレクトリが 16 人のエージェントによる調整バスとなります。各 .txt ファイルが 1 つのタスクリックです。

current_tasks/fix_arm_asm_caspal_instruction.txt
current_tasks/fix_x86_standalone_kernel_link_errors.txt
current_tasks/fix_macro_param_prefix_substitution.txt
...

各ファイルの構造は驚くほど一貫しています。内容を見ると、Claude 自身が半構造化フォーマットを発明しているのがわかります。

Fix ARM assembler: add support for CASP/CASPA/CASPL/CASPAL instructions
[問題の説明]
[技術的詳細：命令エンコード形式]
Files to modify: [修正対象ファイルの一覧]
Started: 2026-02-05
Locked by: [commit hash] at [timestamp]

すべてのファイルが厳密にこの構造に従っているわけではありませんが、このフォーマットはいくつかの重要な AI コーディングの実践を露わにしています。

• 問題記述が仕様書となる：各タスクファイルは単なるタイトルではなく、完全なバグ分析を含みます。例えば fix_arm_asm_quad_prel64_relocation.txt では、相互に関連する 3 つのバグ（シンボル＋オフセットの解析不能、ELF ライターが誤った再配置タイプを使用、Prel64 バリアントの欠如）と、具体的なカーネルコードの例（__jump_table セクションの .quad 命令）が列挙されています。これにより、次にこのタスクを受け取ったエージェントは一から分析する必要がなくなります。
• 修正範囲の事前宣言：「Files to modify」リストです。これは単なるドキュメントではありません。これは他のエージェントへの信号です。「これらのファイルを変更するので避けてください」。16 人の並列エージェントという状況下では、git の競合が発生してから処理するよりもはるかに効率的です。
• ロックメカニズム：Locked by: [commit hash] at [timestamp] は、Carlini 氏がブログで説明したファイルロックの実際の姿です。PID やホスト名ではなく git commit hash を使用している点に注意してください。各エージェントは独立した Docker コンテナ内で動作するため、PID には意味がないからです。

Claude 自身も知識ベース、あるいは記憶として ideas/ を維持しています。

ideas/ ディレクトリは、このプロジェクト全体を通じて最も価値ある AI コーディングの実践サンプルです。これは Claude 自身が作成・維持しており、機能としては buffa の DESIGN.md と同等ですが、ランタイムで動的に生成される点が異なります。

後ほど buffa について紹介します。

ideas/ にはプロジェクトステータスの追跡ファイル（new_projects.txt / new_projects_myasm.txt）があります。

これら 2 つのファイルを合わせると 400 行を超え、150 以上のオープンソースプロジェクトのコンパイル・テスト結果を追跡しています。形式は極めて規範的です。

redis: PASS (all 4 backends: x86, i686, arm, riscv)
zstd: PASS x86, FAIL arm (runtime crash in fullbench)

new_projects_myasm.txt はさらに詳細で、各プロジェクトごとに 4 列（x86/i686/arm/riscv）を持ち、FAIL した場合は具体的な原因と修正記録が付記されます。例えば zstd の項目では、RISC-V での失敗要因が「get_expr_type が UIntLiteral に対して 64 ビットターゲット上で U64 を返す（本来は U32 であるべき）。その結果 narrow パスが LShr の狭小化を見落とし、mulw の符号拡張結果が 64 ビット srl へ渡され、DeBruijn 配列の境界外アクセスでセグメンテーションフォールトを引き起こす」と記録されています。

これは人間が書いたバグレポートではなく、Claude 自身がバグを修正する過程で残した調査記録です。その機能は buffa の DESIGN.md にある「却下された案」の章と同等で、将来のエージェントが同じ過ちを繰り返さないようにするためのものです。

ideas/ 配下のファイルは HIGH/MEDIUM/LOW でランク付けされています。

high_codegen_runtime_perf.txt      — ランタイムパフォーマンスのボトルネック（プロファイリングデータ付き）
high_compile_speed_improvements.txt — コンパイル速度のボトルネック（callgrind の命令カウント付き）
high_sema_expansion_typed_ast.txt   — 型システムのリファクタリング計画（7 ステップ中 5 ステップ完了）
low_structured_error_infrastructure.txt — エラー報告インフラ

どのファイルも内部構造が驚異的です。例えば high_compile_speed_improvements.txt を見てみましょう。

Profiled on sqlite3.c (callgrind, 20.2B instructions after fixes).
Previous profile: kernel/softirq.c (2.31B instructions).
FIXED: Peephole loop trampoline O(n*labels) quadratic scan was 19.76%
of total compile time. Pre-built reverse index reduces it to 0.21%.
Overall 22.7% instruction count reduction (26.1B -> 20.2B).

Claude は callgrind を使用してパフォーマンスプロファイリングを行い、O(n×labels) の 2 乗スキャンがコンパイル時間の 19.76% を占めていることを発見。修正後、全体の命令数は 22.7% 減少しました。そして修正前後のデータを記録しています。これは buffa の DESIGN.md に見られるパフォーマンスの因果分析と全く同型です。

buffa における AI の実践も、このプロジェクトに由来しているのではないかと推測されます。

docs_verified_2026_01_29.txt は最も驚くべきファイルの 1 つです。Claude 自身が自分が書いた文書を監査し、各 README で発見された不正確な箇所とその修正を記録しています。

Accuracy Audit (2026-02-03):
  src/frontend/README.md:
  - Fixed `$` in identifiers claim (always permitted, not gated by gnu_extensions)
  - Fixed Token described as tuple -> struct with named fields
  - Fixed Parser::new() signature (takes only Vec<Token>)

これは Carlini 氏がブログで警告した「ドキュメントは誤っており、偽りの主張を含んでいる可能性がある」という指摘に直接呼応しています。Claude は自身のドキュメントが不正確である可能性を認識し、監査メカニズムを構築したのです。ただし、この監査は Claude 自身が行ったものであり、外部の評価者はいません。それがゆえに Carlini 氏は依然として「ドキュメントは誤っている可能性がある」と述べるのです。自己監査の信頼性には限界があります。これはハーネス設計のブログにある「AI による自己評価は体系的に甘くなる」という問題と同一です。

projects/cleanup_code_quality.txt は、Claude によるコード品質改善の追跡ファイルです。ここには「Rust の専門家なら指摘するであろう問題」が列挙されています。

Items a Rust expert would flag, roughly ordered by impact:
1. [DONE] GVN pass parameter threading -> GvnState struct
   - gvn_dfs had 14 params, process_block had 10 params
2. [DONE] Functions with 10-20+ parameters
   - parse_declaration_rest: 22 params -> DeclContext struct
3. [PARTIAL] Visibility: was 836 pub + 18 pub(crate), now improved

buffa の rust-code-reviewer.md の 16 の次元（後述）と比較すると、Claude はここで簡易版のレビューフレームワークを独自に発明しています。しかし、その適用範囲は rust-code-reviewer（詳細は付録で解説）には遠く及ばず、パラメータの多さ、可視性の広さ、文字列の割り当て、コードのネストなど「構造的」な問題のみに焦点を当てており、unsafe の安全性の正当性、並列安全性、API デザインの品味など、判断力を要する次元は完全に欠落しています。

これこそが、Anthropic 公式のハーネス設計ブログの中核的な発見「AI による自己レビューの次元と深さは、外部レビューには及ばない」ことを裏付けています。

claudes-c-compiler プロジェクトから抽出できるAI コーディングの実践は、以下の点に要約できます。

• Claude は自然と構造化を志向する。current_tasks/ ファイルに「Files to modify」リストや「Started」タイムスタンプを書くよう指示した人間はいません。Claude 自身がこの半構造化フォーマットを発展させました。これは、長期にわたるプロジェクトにおいて、AI は自然と情報管理の構造を発明することを示唆していますが、その品質はプロンプトの誘導に依存します。Carlini 氏の AGENT_PROMPT.md には「進捗を追跡せよ」という指示が含まれており、Claude はそれに基づいてこのファイルシステムを進化させたのでしょう。
• 150+ プロジェクトの追跡は「テスト即ナビゲーション」の極致です。new_projects_myasm.txt は 150 以上のプロジェクトを 4 つのアーキテクチャで追跡し、FAIL した場合はすべて根本原因の分析と修正記録を残しています。これは Carlini 氏の「テストの質がコードの質を決める」という原則の極端な実現形であり、Claude はオープンソースエコシステム全体をテストスイートとして活用しています。
• DESIGN_DOC.md がプロジェクトアーキテクチャのグローバルな記憶を定義します。claudes-c-compiler の DESIGN_DOC.md には完全なパイプライン図、ソースツリー構造、データフローの説明、そして「設計哲学」の章（Claude 自身が記述）が含まれています。しかし、buffa の DESIGN.md（後述）と比較すると、2 つの重要な要素が欠けています。意思決定の進化の歴史（なぜ別の方法を採用しなかったか）と、却下された案のベンチマークデータです。これらの情報は ideas/*.txt ファイルに散在していますが、DESIGN_DOC には統合されていません。

これは、Claude が優れたアーキテクチャ文書は作成できるが、意思決定の歴史を「後退防止」の知識として自発的に洗練させることはできないことを示しています。buffa では、人間（McGinniss 氏）が DESIGN.md に Cell<u32> から AtomicU32 への進化や、プレスキャンの失敗データを記録すると決定しました。Claude も同様の情報（ideas/ 配下の修正記録）を記録してはいますが、それを「将来の AI の後退を防ぐ」ための設計ドキュメントのレベルにまで引き上げることはしていません。

なぜ実装言語に C/C++ ではなく Rust を選んだのか。その公式な論証は明示されていませんが、10 万行の Rust コード中にunsafe ブロックが 1 つもないという事実自体が、最も力強い答えです。

C/C++ で C コンパイラを書いていた場合、AI が生成するコードの中のあらゆるポインタ操作、配列アクセス、メモリ確保がバグを潜ませていた可能性があります。そして、それらのバグはコンパイル時には検出されず、実行時にクラッシュしたり誤った結果を出力したりして初めて発見されるでしょう。

Rust を使えば、コンパイラ自体が第一のレビュー担当となります。16 人の並列 AI エージェントが 2 週間も無人で動作しても、生成されたコードにメモリの安全性に問題があれば、cargo build がコンパイルを拒否します。人間によるレビューも、サニタイザーも、ファズナーも不要です。Rust の型システムは、膨大な数のバグを「実行時に発見」から「コンパイル時に阻止」へと変換します。

--dangerously-skip-permissions で完全自律動作するシナリオにおいて、これは「加点要素」ではなく「必須条件」なのです。

buffa：AI 主導の本番用 protobuf ライブラリ

buffa は connect-rust（後述）の protobuf 基盤層であり、Anthropic のセキュリティエンジニアである Iain McGinniss 氏がアーキテクチャ設計を主導し、Claude がコーディングの大部分を担当しました。これは Rust の protobuf エコシステムにおける空白を埋めるものです。prost（事実上の標準）は受動的なメンテナンス状態で protobuf editions をサポートしておらず、Google 公式の protobuf-v4 は editions をサポートしていますが C コンパイラを必要とします。buffa は純粋な Rust 製で no_std 互換の実装であり、editions を中核的な抽象概念とし、protobuf のバイナリおよび JSON 一貫性テストの全セットに合格しています。

中核的な革新は2 層の型システムです。各 protobuf メッセージに対し、2 種類の Rust 型を生成します。MyMessage（所有権あり、ヒープ割り当て）と MyMessageView<'a>（ゼロコピー借用）です。view モードでのデコード速度は 1,772 MiB/s に達し、prost よりも 156% 高速です。OwnedView<V> は transmute を通じて view のライフタイムを 'static に拡張し、async 境界を安全に越えられるようにしています。

C コンパイラとは異なり、buffa は明確に本番用コードとして位置づけられています。「Anthropic の本番環境で稼働中」であり、単なる能力披露ではありません。その違いは検証の完全性にあります。buffa には権威ある完全なテストスイート（Google の protobuf conformance）がありますが、C コンパイラの検証は広範ではあるものの完全ではありません。

Anthropic のオープンソース化した 3 つの Rust プロジェクトの中で、buffa は AI コーディングの実践を研究する上で最も価値があります。なぜなら、それはユニークな位置にあるからです。AI が書いたコードの中で、明確に本番環境で使用されているのはこれだけなのです。

claudes-c-compiler は能力披露であり、README には「I do not recommend you use this code」と明記されています。connect-rust には AI 生成の声明はなく、中核コードは人間が書いています。buffa だけが「Written by Claude ❣️」と「Anthropic の本番環境で稼働中」の両方を明記しています。

つまり、buffa のエンジニアリング実践は学問的な議論ではなく、本番環境で実証済みだということです。buffa から抽出される方法論は、「もっともらしく聞こえる」ものではなく、「有効性が証明済み」のものなのです。

さらに、buffa が扱っているのは protobuf runtime + codegen です。ステートマシンが複雑（ワイヤフォーマット）で、境界条件が極めて多く（未定義のフィールド、enum、再帰）、パフォーマンスに敏感（デコードループ）であり、API 設計には高い要求（Rust の型システム＋人間中心設計）があり、長期のメンテナンスが必要です。これは現在、AI が最も失敗しやすいコードのタイプです。しかし、buffa は失敗しませんでした。

篇幅の都合上、Buffa の AI エンジニアリング実践の詳細な解体は次回の記事で行います。

connect-rust：人間主導の RPC フレームワーク

connect-rust は ConnectRPC^[6] プロトコルの Rust 実装で、これも McGinniss 氏によって開発されました。Tower ミドルウェアフレームワークをベースにし、同一のハンドラセットで Connect、gRPC、gRPC-Web の 3 プロトコルを同時にサポートします。Anthropic はこれを ConnectRPC の標準 Rust 実装とするよう RFC 007^[7] を提出済みです。

ConnectRPC は Buf Technologies が作成した RPC プロトコルで、現在は CNCF（Cloud Native Computing Foundation）のサンドボックスプロジェクトです。その中核的な位置づけはgRPC の簡素化された代替であり、実運用における gRPC のいくつかの痛点を解決するものです。

• gRPC の問題点：HTTP/2 の強制（インフラが未対応の場合が多い）、独自の 2 進数フレーム形式（curl でのデバッグが困難）、ブラウザ側で追加の grpc-web プロキシが必要、エラーメッセージが 2 進数エンコードされた protobuf で可読性がない。
• ConnectRPC の解決策：HTTP/1.1 および HTTP/2 で動作可能、unary RPC は通常の POST リクエスト（curl で直接呼び出し可能）、エラーメッセージは JSON、ブラウザネイティブ対応（プロキシ不要）、gRPC および gRPC-Web プロトコルとの互換性を維持（同一ハンドラで 3 プロトコル対応）。

公式には Go、TypeScript、Swift、Kotlin、Python の実装がありますが、Rust だけが欠けていました。

現在の connect-rust の優位性：

• パフォーマンスデータが驚異的：レイテンシは tonic の約半分（1.95 倍低減）、高並列（c=256）下でのスループットは tonic より 33% 向上（112K 対 84K req/s）。CPU プロファイリングでは、アロケータの負荷が CPU の 3.6%（tonic+prost は 9.6%）であることが示されています。
• connect-rust は 12,800 件以上の一貫性テストをすべてパスし、解凍爆弾や無制限の TLS ハンドシェイクタイムアウトなどの複数のセキュリティ脆弱性を修正しました。

前述の 2 プロジェクトとの決定的な違いは、connect-rust には「Written by Claude」のマークがないことです。リポジトリには .claude/agents ディレクトリ（rust-code-reviewer.md を含む）があり、AI がコードレビューなどの補助に関与したことは示唆していますが、中核コードは人間によって書かれています。

connect-rust プロジェクトでは人間が主導していますが、AI によるコードレビューも導入されています。そのため、付録では rust-code-reviewer.md の詳細な解説を追加しています。

2 つのフォークが露呈させた本番環境のニーズ

3 つの独自プロジェクトに加え、Anthropic は Rust エコシステムの 2 つの重要な基盤ライブラリをフォークし、実質的な修正を加えました。これら 2 つのフォークは単なる「バージョン固定」の保険的な操作ではなく、高並列の本番環境でしか露呈しない問題を修正・追加したものです。

tokio のフォーク：スケジューラのストール検出

Anthropic の tokio フォークには 6 つのマージ済み PR があります。そのうち 5 つは CI/リリースインフラ（Artifactory パイプライン、OIDC トークン認証など）に関するもので、フォーク後の tokio が社内のプライベート Artifactory リポジトリを通じて内部クレートとして公開されていることを示しています。唯一のコード修正は以下の通りです。

feat: add scheduler stall detection — 非同期スケジューラのストール検出機能を追加。

tokio のワークスティーリングスケジューラは通常、タスクが複数のワーカー线程間で高速に流转します。しかし、何らかのタスクがワーカー线程をブロック（予期せぬ同期 IO、ロックの長時間保持、yield しない CPU 集約型計算など）すると、スケジューラ全体のスループットが静かに低下します。元の tokio にはこれを検出する組み込みメカニズムがありません。

Anthropic の使用シナリオ、特にconnect-rust が高並列下で毎秒 560 万行のログをデコードし、推論サービスが数千のアクセラレータを跨いでルーティングを行う状況を考えると、スケジューラのストールは数ミリ秒でも発生すれば、リクエストのレイテンシにスパイクを引き起こします。この機能により、運用チームはどのタスクがスケジューラをブロックしているかをリアルタイムで把握できます。これは rust-code-reviewer.md（付録参照）の「Observability」の次元（16 番目：tracing spans、metrics exposure）に直接呼応しており、スケジューラのストール検出は本質的にランタイムレベルの可観測性なのです。

moka のフォーク：並列キャッシュの TOCTOU 競合状態の修正

moka は Rust エコシステムで最も人気のある高性能並列キャッシュライブラリで、Java の Caffeine に相当します。Anthropic はこれをフォークし、深刻な並列バグを修正する PR を提出しました。

fix: TOCTOU race in and_compute_with under multi-threaded tokio

問題は and_compute_with メソッドにあります。この API のセマンティクスは「あれば返し、なければ計算してキャッシュする」であり、並列キャッシュの中核となる操作です。try_compute および try_compute_if_nobody_else において、キャッシュへの実際の書き込み前に waiter が waiter マップから削除されてしまい、TOCTOU（Time Of Check Time Of Use）の時間的隙間が生じていました。「並列する呼び出し者が独自の waiter を挿入 → 古い値を読み取る → 2 人の呼び出し者がともに時代遅れのデータに基づいて書き込みを実行」という事態です。その結果、マルチスレッドの tokio ランタイム下で静かなデータ消失が発生しました。8 つの並列書き込み者によるカウンターのテストでは、増分の 10-15% が失われました。

修正策は、waiter の削除をキャッシュへの書き込み完了後に遅らせ、更新中に並列する呼び出し者をブロックするようにすることです。

フォークが何を露呈させたか？いくつかの推論

Anthropic が moka をフォークしたことは、社内サービスで並列キャッシュを多用していることを示唆しています。技術スタックと併せると、最も考えられる使用シナリオは以下の通りです。

• 推論サービスのホットパスキャッシュ：LLM 推論における最大の性能最適化は KV Cache の再利用（複数のリクエストでプロンプトプレフィックスの注意計算結果を共有）です。「どのプレフィックスがどの GPU 上で計算済みか」というインデックステーブルには極めて高い並列読み書きが求められます。moka の and_compute_with（まさに TOCTOU が修正されたメソッド）は「あれば返し、なければ計算してキャッシュする」というパターンそのものです。モデルルーティングテーブル（どのリクエストをどのアクセラレータクラスタに送るか）も、典型的な読みが多く書きが少ないキャッシュシナリオです。
• トークンカウントとレート制限：ユーザーごと、API キーごとのリクエストカウントとクォータの追跡。すべてのリクエストでカウンターをインクリメントする必要があります。TOCTOU により「8 つの並列書き込み者で増分の 10-15% が失われる」場合、レート制限のシナリオではユーザーが制限を超えて利用できてしまうことを意味し、これは直接的な収益損失につながります。
• 認証トークンのキャッシュ：JWT/OIDC トークンの検証結果のキャッシュ。検証には暗号演算（署名検証）が必要で、結果は有効期限までキャッシュ可能です。rust-code-reviewer の Security 次元で求められる zeroize（機密データの安全な消去）と組み合わせ、トークンキャッシュの失効後にはメモリを安全に消去する必要があります。
• RPC レイヤーのスキーマキャッシュ：buffa の JSON レジストリや Any レジストリが type URL でメッセージ記述子を検索する際、この検索は高スループットの RPC では毎秒数百万回発生します。

TOCTOU バグ自体も示唆に富んでいます。10-15% の消失率は低並列下では目立たないかもしれませんが、Anthropic の規模（数百万ユーザー、数千のアクセラレータ）では、毎秒大量のリクエストのカウントやステータスが静かに失われていることを意味します。このバグは、本番環境でデータの不整合（レート制限の不正確さ、キャッシュヒット率の異常）が観察され、最小限の再現ケースを構築して初めて発見されたに違いありません。

2 つのフォークを合わせると、像は明確になります。Anthropic は「Rust の実験」をしているのではありません。彼らは深淵で Rust の本番サービスを運用しており、高並列の本番環境でしか露呈しないランタイムレベルの問題に遭遇し、かつ tokio や moka というレベルでそれを修正する能力を持っているのです。

AI の関与度の違いとその示唆

3 つの独自プロジェクトの比較から、AI コーディングの適用範囲に関する Anthropic の判断が浮かび上がります。

C コンパイラは 100% AI に適する。成熟したテストインフラ（GCC Torture Test、多数のオープンソースプロジェクトが検証対象）があり、タスクの並列化が容易（異なるテスト、異なるファイル、異なるバックエンド）だが、コード品質は本番レベルを要求されない。

buffa は AI 主導に適する。完全な仕様書（protobuf wire format spec）、自動化された検証（conformance test suite）、高度に局所化（int32 のエンコードにシステム全体の理解は不要）、限定された意思決定の余地。人間はアーキテクチャ設計（DESIGN.md）と品味の判断を担当。

connect-rust は人間主導が必要。プロトコル間の相互作用の組み合わせ爆発（Connect × gRPC × gRPC-Web × HTTP/1.1 × HTTP/2）、ライブラリ間の統合の複雑さ（Tower × hyper × rustls × tokio）、攻撃者の思考を要するセキュリティ判断、API 設計は正しさではなく品味の問題。

共通点：5 つのプロジェクトすべてが Rust を選択していること。AI コーディングにおいて、Rust のコンパイラは「第ゼロのレビュー担当」として機能します。型チェッカーは説き伏せられることもなく、甘く見ることもなく、「まあこれでいいか」と妥協することもありません。claudes-c-compiler における unsafe ブロックゼロがそれを証明しています。一方、2 つのフォーク（tokio のスケジューラストール検出、moka の並列競合状態の修正）は、Anthropic の Rust サービスが、もはやランタイムレベルでのカスタマイズが必要な深淵に達していることを証明しています。

3. 公式ハーネス設計ブログの中核的洞察

Prithvi Rajasekaran 氏（Labs チーム、2026 年 3 月公開）のブログは、C コンパイラや buffa プロジェクトでは正面から触れられなかった問題、すなわち「AI はどのようにして自身の仕事の質を評価すべきか」を解決するものです。

なぜ素朴な案は失敗するのか

ブログの冒頭では、単一の Claude エージェントに完全なアプリケーションを単独で完成させる実験について触れています。結果は、アプリケーションの見た目はそこそこでも、中核機能が全く動かないというものでした。例えば 2D レトロゲーム制作ツールでは、スプライトエディタは機能しても、実際にプレイするとキャラクターが入力に反応せず、エンティティ定義とゲームランタイムの接続が切れていました。しかも UI にはどこが問題かを示す手がかりもありません。

問題は 2 つのレベルにありました。1 つ目はコンテキストの劣化です。コンテキストウィンドウが埋まるにつれ、モデルの一貫性が低下します。一部のモデル（Sonnet 4.5 など）は「コンテキスト不安」を示し、コンテキスト上限に達したかのように早期に作業を切り上げてしまいます。2 つ目のより深い問題は、GAN 構造のエンジニアリング応用における対抗思想の応用です。私がまとめると 3 つの方向があります。

1. 生成、レビュー、検証を分離し、対抗構造を生み出す。
2. Claude Code と Codex など、異なるモデルで相互レビューし、対抗構造を生み出す。
3. 外部の真のテストを使用して検証し、対抗構造を生み出す：自己評価の体系的バイアス。AI は自身が直前に生成したコードを評価させると、人間から見れば明らかに平凡な成果を自信満々に称賛します。このバイアスは主観的タスク（フロントエンドデザイン）で最も深刻ですが、検証可能な結果があるタスク（機能の正しさ）でさえ、AI はあるバグを「実は深刻ではない」と自らを納得させてしまいます。

これは buffa プロジェクトと興味深い対比を成します。buffa は正しさの検証に Google の protobuf conformance test suite という外部の、独立した、権威あるテストスイートを使用し、AI の自己評価は完全に関与させませんでした。claudes-c-compiler も GCC Torture Test や 150 以上のオープンソースプロジェクトを検証に用い、同様に AI の自己評価を回避しました。しかし、このような権威ある外部テストスイートが存在しない領域（「このフロントエンドデザインは良いか」など）では、自己評価のバイアスが中核的な障壁となります。

GAN 構造のエンジニアリング応用

Rajasekaran 氏は GAN（Generative Adversarial Network、生成的敵対ネットワーク）から中核的な発想を借用しました。Generator（生成器）と Discriminator（識別器）の対抗が質の向上を駆動するというものです。

GAN（Generative Adversarial Network）は 2014 年に Ian Goodfellow 氏が提案した深層学習アーキテクチャです。その中核的な発想は極めて単純です。2 つのニューラルネットワークを互いに競わせ、一方が偽物を作り、もう一方が偽物を見破ることで、対抗の中で共に成長させるというものです。Generator（生成器）は、可能な限り本物らしい偽のデータ（例：偽画像）を生成することを目標とし、ランダムノイズから出発して「本物のデータ」のように見えるものを出力することを学習します。Discriminator（識別器）は、本物のデータと Generator が生成した偽のデータを区別することを目標とします。画像を受け取り、「本物か偽物か」という確率を出力します。Generator が偽札製造者だとすれば、Discriminator は検札係です。偽札が本物に近づけばなるほど検札係も洗練され、最終的に偽札製造者の能力は極限まで高められます。

氏は 3 エージェントシステムを設計しました。

Planner：ユーザーの 1〜4 文の言葉を完全な製品仕様書に拡張します。このエージェントはあえて「製品コンテキストと高レベルの技術設計のみを書き、具体的な実装詳細は書かない」よう制約されています。理由は、Planner が序盤で微細な技術的詳細まで指定してしまうと、その詳細の 1 つが間違っていた場合、その誤りがパイプライン全体を下流の実装に連鎖的に波及するからです。成果物を制約し、実行者自身に道筋を探させるのです。これは buffa の設計原則（「記述子中心」。コード生成には構造化された入力のみを与え、Rust コードの生成方法は自身に決定させる）と同じ哲学です。

Generator：スプリントごとに機能を実装します。React + Vite + FastAPI + SQLite の技術スタックを使用し、バージョン管理に git を利用します。各スプリント開始前に、Generator と Evaluator はスプリント契約（sprint contract）を協議します。これは、今回のラウンドで何を行い、何が完了基準かを双方で合意するものです。この契約が存在する理由は、製品仕様が意図的に高レベルに保たれている（Planner の詳細ミスを防ぐため）ため、「ユーザーストーリー」と「テスト可能な実装」を橋渡しする中間ステップが必要だからです。Generator が案を提示し、Evaluator が仕様に合致しているか審査し、合意するまで反復し、その後で Generator がコーディングを開始します。

このスプリント契約のメカニズムは、buffa の CLAUDE.md と似たようなものです。CLAUDE.md は「codegen を変更したら型を再生成すること」「コミット前に reviewer エージェントを実行すること」などを規定し、本質的にコード作成の前後に強制的なチェックポイントを埋め込んでいます。違いは、buffa のチェックポイントは人間が事前定義するのに対し、ハーネスの契約は 2 つのエージェントが動的に協議する点です。

Evaluator：このアーキテクチャの中で最も重要な役割です。Evaluator は Playwright MCP を通じて、本物のユーザーのように動作中のアプリケーションと対話します。ページをナビゲートし、スクリーンショットを撮り、ボタンをクリックし、フォームに入力し、API レスポンスやデータベースの状態を確認します。静的なコードやスクリーンショットを見て点数をつけるのではなく、実際にアプリケーションを操作した上で評価を下します。各スプリント終了後、Evaluator は事前に定義された評価基準（後述）に基づき項目ごとに採点し、1 つでも閾値を下回ればスプリントは失敗となります。Generator は具体的なフィードバックを受け取り、作り直します。

Evaluator による Playwright を使ったエンドツーエンドテストの発想は、Carlini 氏が C コンパイラプロジェクトで GCC を「既知の正解（オラクル）」としてコンパイル結果を検証したのと本質的に同じパターンです。つまり、AI の自己評価に代わる、外部の客観的な検証です。buffa は Google conformance test を、C コンパイラは GCC と 150 のオープンソースプロジェクトを、ハーネス設計は Playwright によるエンドツーエンド対話を用いています。媒体は違えど、原理は同じです。

GAN 構造のエンジニアリング応用における対抗思想の応用について、私がまとめると 3 つの方向があります。

1. 生成、レビュー、検証を分離し、対抗構造を生み出す。
2. Claude Code と Codex など、異なるモデルで相互レビューし、対抗構造を生み出す。
3. 外部の真のテストを使用して検証し、対抗構造を生み出す。

これら 3 つの方向は、3 つの異なる「識別器」の源泉に対応し、弱から強への対抗のグラデーションを構成しています。

方向 1：役割の分離による内部対抗

同じモデル（あるいは同じベンチのモデル）であっても、異なる役割、異なる権限、異なるプロンプトに分割します。対抗は責務の構造的な分離から生まれます。

これは Anthropic の実践の中で最も証拠が豊富な方向です。buffa の rust-code-reviewer（Opus、読み取り専用権限、16 次元）が Claude Sonnet の書いたコードをレビューします。Harness Design の Generator-Evaluator ループ。claudes-c-compiler の「コーディングエージェント」対「コード品質エージェント」対「重複除去エージェント」などです。

対抗の強度は 3 つの設計パラメータに依存します。

モデルの階層差：buffa は Sonnet が書き、Opus がレビューします。レビュー担当の方が生成担当より「賢い」ことで、真の判断力の格差が生まれます。同じモデルで生成とレビューの両方を行うと、対抗は弱まります。Harness Design のブログでも、Evaluater はデフォルトでは LLM の出力に甘く、追加のキャリブレーションが必要であることが明らかになっています。

権限の非対称性：reviewer には Read/Glob/Grep のみで、コード変更権限はありません。この制約は制限に見えるかもしれませんが、実際には対抗構造の担保です。レビュー担当がコードを変更できる場合、厳しく突き返すのではなく、「少し直して通す」傾向が出てしまうからです。

評価基準の外化：16 のレビュー次元、4 次元のフロントエンド評価体系、スプリント契約。基準はエージェントの頭の中にあるのではなくファイルにあり、監査可能で、キャリブレーション可能で、反復可能です。

この方向の限界は、対抗の天井がモデル自体の判断力にあることです。2 つの Claude 間の対抗をいかに設計しようとも、Claude の問題理解の深さを超えることはありません。Harness Design のブログでも、キャリブレーション後も未発見の深いバグが残っていることが認められています。

方向 2：クロスモデル相互レビューによる異種対抗

異なるベンダーのモデルは、トレーニングデータ、アライメント方法、盲点の分布が異なります。Claude で書き、GPT でレビューする（あるいはその逆）ことで、認知的盲点の重なりから対抗が生まれます。

これは Anthropic の公開資料では直接実践されていない方向です。彼らのプロジェクトはすべて自社モデルを使用しています。しかし対抗理論の観点から見れば、この方向の対抗強度は理論上より高いと言えます。

Claude は、ある種のパターンに対して体系的に甘くなる可能性があります（例えば、自身が生成したコードスタイルには本能的に親和性があるなど）。別のモデルでレビューすれば、この「同質的偏見」を打ち破れます。人間のチームでも、同じ学校出身のエンジニアは似たような盲点を持ちがちですが、異なる背景を持つ人を迎えることで、より多くの問題が発見できるのと同じです。

実装上の難点は基準の整合です。buffa の rust-code-reviewer.md は Claude 向けに書かれており、16 次元の優先順位付け、出力形式の要件、few-shot によるキャリブレーションはすべて Claude の挙動に合わせて調整されています。これを Codex や Gemini に読ませても、プロンプトへの反応パターンが異なるため、レビュー品質が向上するとは限りません。

しかし、この方向には単一障害点の防止というユニークな利点があります。ツールチェーン全体が 1 つのモデルに依存している場合、そのモデルの体系的な欠陥は発見不可能になります。claudes-c-compiler のコード品質は Carlini 氏によって「まともだが専門家レベルには程遠い」と表現されていますが、Rust のイディオムに対して異なる選好を持つモデルでレビューすれば、Claude が体系的に無視していたパターンが発見されるかもしれません。

方向 3：外部の真の検証による絶対的対抗

識別器が別の AI ではなく、現実世界そのものです。コードはテストに通るかどうか、Linux カーネルをコンパイルできるかどうか、Playwright でフローを完遂できるかどうかです。

これは 3 つの方向の中で最も対抗強度が高く、現実世界は説き伏せられることもなく、キャリブレーションもされず、甘さのバイアスも存在しません。

Anthropic の実践では、この方向には 4 つの具体的な形態があります。

権威あるテストスイート：buffa は Google protobuf conformance test を、claudes-c-compiler は GCC torture test（99% 合格）を使用。これらは第三者によって維持され、人間も AI も見落としがちな境界条件を網羅しています。

実際のプロジェクトのコンパイル：C コンパイラは 150 以上のオープンソースプロジェクト（SQLite、Redis、PostgreSQL、FFmpeg、Linux カーネル）を統合テストとして使用。各プロジェクトが数十万行のコードに潜む無数の暗黙の制約の総体であり、人間が設計したいかなるテストスイートよりも予測不可能です。

エンドツーエンドのユーザー対話：Harness Design の Evaluator は Playwright MCP を通じて実際にアプリケーションを操作します。コードロジックをチェックするのではなく、「ユーザーがタスクを完了できるか」をチェックします。

既知の正解実装との比較：C コンパイラは GCC をオラクルとして使用。ランダムにファイルを選び、GCC でコンパイル、Claude でコンパイルし、結果を比較します。これが最も純粋な対抗です。「正しさ」を定義する必要はなく、既知の正解実装と比較するだけです。

この方向の限界は、すべての品質次元に外部検証があるわけではないことです。「コードが動くか」は外部検証（テスト）がありますが、「API デザインが良いか」にはありません（品味の問題です）。「フロントエンドが見栄えするか」は一部はあります（Playwright でユーザビリティを検証可能）が、一部はありません（美学は主観的です）。それがゆえに、3 つの方向が相互補完する必要があるのです。

3 つの方向の補完関係

3 つの方向は代替関係ではなく、異なる品質次元をカバーするものです。

buffa は方向 1 と方向 3 の両方を使用しています。reviewer エージェントによる役割分離レビュー（方向 1）と、conformance test による外部検証（方向 3）です。C コンパイラは主に方向 3（GCC オラクル＋150 プロジェクト）に依存し、方向 1（コード品質エージェント）で補完しています。Harness Design は 3 つの方向すべてを使用しています。Generator/Evaluator の分離（方向 1）、Playwright によるエンドツーエンドテスト（方向 3）。ただしクロスモデル（方向 2）は使用していません。

最も完全な実践は 3 層の重ね合わせであるべきです。外部テストスイートで機能の正しさを担保し、クロスモデルレビューで単一モデルの体系的盲点を捉え、同モデルの役割分離で品味やスタイルなどの主観的次元を処理します。現在の Anthropic の公開実践は方向 1 と 3 をカバーしており、方向 2 はあなたが指摘した価値ある空白です。

自己評価バイアスの解剖

ブログでは自己評価バイアスに関する分析が詳しく述べられています。単に「実行」と「評価」を別エージェントに割り振るだけでは不十分で、分離された Evaluator も LLM である以上、デフォルトでは LLM 生成の出力に甘くなります。Rajasekaran 氏は、Evaluator のログを繰り返し読み、Evaluator の判断が自身の期待から逸脱している箇所を見つけ、Evaluator のプロンプトを更新してこれらのバイアスを修正する必要がありました。このキャリブレーションループは何度も繰り返され、ようやく Evaluator の評価が妥当なレベルに達しました。

それでもなお、ハーネスの最終出力には小さなレイアウトの問題、直感的でないインタラクション、十分にテストされていない深い機能のバグが存在しました。Evaluator の能力には上限があります。モデル能力の限界付近のタスクでは最も価値を発揮しますが、モデルの理解範囲を超える問題（「このゲームのレベルデザインは常識に合っているか」など）では、Generator と同様に無力です。

これは buffa の rust-code-reviewer.md と直接対比されます。reviewer エージェントは model: opus（最強のモデルでレビュー）、tools: Read, Glob, Grep（読み取り専用権限）、そして 16 の明確なレビュー次元と構造化された出力形式（Executive Summary → Findings by Category → Critical Issues → Recommended Improvements）を採用しています。buffa のレビューフレームワークは人間が事前定義した静的で明確な基準を持つ一方、ハーネスの Evaluator は動的で、ランタイムの対話に基づき、反復的なキャリブレーションを必要とします。この 2 つは補完関係にあります。buffa のモードは「コードの品質が静的レビューで判断可能」なシナリオに適し、ハーネスのモードは「品質が実際の使用によって検証されるべき」シナリオに適しています。

claudes-c-compiler のアプローチは 3 つ目の変種です。コード品質エージェント（cleanup_code_quality.txt）は Claude 自身が発明した簡易版レビューフレームワークで、パラメータの多さや可視性の広さなど構造的な問題のみをカバーしており、unsafe の安全性の正当性や API の品味など、深い判断力を要する次元は欠落しています。これはハーネスブログの中核的な主張、つまり「AI による自己レビューの次元と深さは、本質的に外部レビューには及ばない」ことを裏付けています。

フロントエンドデザインの採点：主観的品質の階層化

フルスタック開発への応用以前に、Rajasekaran 氏はフロントエンドデザインの領域で実験を行いました。Generator と Evaluator のために、4 つの評価次元を定義しました。

• Design Quality（デザインの質）：色、タイポグラフィ、レイアウト、イメージが統一された感情とアイデンティティの全体を形成しているか。
• Originality（独創性）：独自のカスタマイズされたデザインの意思決定があるか、それともテンプレートレイアウト、ライブラリのデフォルト値、AI 生成のパターンか。「紫色のグラデーション＋白いカード」といった「AI 的な手抜き（AI slop）」を明確にペナルティ化。
• Craft（技巧）：タイポグラフィの階層、間隔の一貫性、色の調和、コントラスト。技術的な実行能力のチェック。
• Functionality（機能性）：美学とは無関係なユーザビリティ評価。

重要な戦略は、Design Quality と Originality の重みを大きくし、Craft と Functionality を弱めることです。なぜなら、Claude は Craft と Functionality においてはデフォルトで悪くなく、技術力はモデルが本来的に備えているからです。しかしデザインの質と独創性においては、Claude は平凡だが「安全」な出力を生み出す傾向があります。これは buffa の rust-code-reviewer.md が API Design を 1 位、Unsafe を 8 位にランクしているのと同じ論理です。モデルがすでに得意としている次元に重きを置いても意味がなく、モデルが失敗しやすい次元にプレッシャーをかけるべきなのです。

予期せぬ発見として、評価基準の措辞が生成される出力を直接形成することがありました。基準に「最高のデザインは美術館級である」といった文言を含めることで、デザインが特定の視覚的方向に収束するよう促進されました。これは、評価基準が単なる評価ツールではなく、Generator と Evaluator に同一の基準を見せることは、生成の方向と評価の方向の両方に同じ品味の圧力をかけることを意味します。これは buffa の DESIGN.md が Claude Code（コーディングエージェント）と rust-code-reviewer（レビューエージェント）の両方に読まれていることに似ています。設計原則はコードの書き方をガイドすると同時に、レビューの基準も定義しているのです。

オランダの美術館ウェブサイトの事例では、Generator は 9 ラウンドの反復を経て、洗練されたダークテーマのランディングページを生成しました。視覚的には磨かれていましたが、予想の範囲内でした。しかし 10 ラウンド目で、それまでの案を完全に覆し、サイトを空間体験として再構築しました。CSS パースペクティブでレンダリングされた格子状の床、壁に吊るされた絵画、スクロールやクリックではなく扉の穴を通ってギャラリーの部屋を移動するナビゲーション。この創造的飛躍は Rajasekaran 氏がこれまでに単一ラウンドの生成で見たことのないもので、対抗圧力の蓄積によってもたらされました。

Opus 4.5 から 4.6 へのハーネスの進化

ブログには重要な進化のプロセスが記録されています。最初の完全なハーネスは Opus 4.5 向けに設計され、スプリント分解、コンテキストリセット、スプリントごとの QA を含んでいました。Opus 4.6 が公開されると、Rajasekaran 氏はどのコンポーネントが依然として負荷を支えているかテストするため、逐一コンポーネントを削除していきました。

コンテキストリセット 対 コンパクション：これは重要な区別です。コンパクション（圧縮）は、初期の対話を要約し、同じエージェントが作業を継続します。コンテキストリセット（リセット）は、コンテキストを完全にクリアし、新しいエージェントを起動し、構造化されたファイルを通じて状態を伝達します。Sonnet 4.5 の「コンテキスト不安」（モデルがコンテキスト上限に近づいたと勘違いして雑に終わらせようとする）は、コンパクションでは不十分なほど深刻で、エージェントにクリーンなスタートを切るためにリセットが必要でした。Opus 4.6 はこの問題をほぼ解消し、2 時間以上連続でリセットなしに作業可能になりました。

claudes-c-compiler はさらに極端な道を歩んでいます。各セッションが完全リセットで、2,000 のセッションでコンパクションやコンテキストの持ち越しは一切ありません。Claude はファイルシステムに current_tasks/ や ideas/ を書き込むことで対話履歴の欠如を補い、本来対話履歴に存在すべき推論プロセスを git リポジトリにシリアライズしています。これは「コンテキストリセット＋ファイルシステムによるハンドオフ」の最も純粋な形です。

スプリント分解の廃止：Opus 4.6 の能力向上により、スプリント分解は不要になりました。モデルは 2 時間以上自律的に動作しても一貫性を失わなくなったため、外部からタスクを細かく切り分ける必要がなくなったのです。

Evaluator の役割の変化：スプリントが廃止されたことで、Evaluator はビルド全体終了後に 1 回だけチェックするよう変更されました。これにより Evaluator の負荷の度合いが変わりました。モデルが単独で処理できるタスクにとっては不要なオーバーヘッドとなり、依然としてモデルの能力の境界にある部分に対してのみ、真の品質向上を提供し続けています。

ブログはここから普遍的な原則を導き出しています。ハーネスの各コンポーネントは「モデルにできないこと」という仮説をコード化したものであり、これらの仮説はモデルのアップグレードで時代遅れになるというものです。新しいモデルが公開された際、もはや負荷を支えていないコンポーネントを 1 つずつ剥がし取り、以前は不可能だったより高い能力を実現するための新しいコンポーネントを追加するのが正しいやり方です。ブログの結びにある通り、「興味深いハーネスの組み合わせの空間はモデルの進歩によって縮小することはない。それは移動するだけだ」のです。

この原則は、buffa と C コンパイラのアーキテクチャの差異を遡って説明するものでもあります。buffa（Opus 4.6 の時代）にはコンテキストリセットやスプリント分解は不要で、CLAUDE.md は 2 つの簡潔なルールのみです。C コンパイラ（これも Opus 4.6）は極めて極端なセッションごとの完全リセットを採用していますが、GCC Torture Test や 150 のオープンソースプロジェクトという外部検証があるため Evaluator は不要です。各プロジェクトのハーネスの形状が異なるのは、コード化されている「モデルにできないこと」という仮説が異なるからです。

実際のコストと成果

ブログには直接のコスト比較データが示されています。

20 倍のコスト差が、「中核機能が使えるかどうか」という質的変化をもたらしました。線形的な改善ではなく、実用性の閾値を越えたのです。

簡易ハーネスによる DAW（デジタルオーディオワークステーション）の実行詳細も注目すべきです。3 エージェントの時間配分は以下の通りです。Planner 4.7 分（$0.46）→ 1 回目 Build 2 時間 7 分（$71）→ 1 回目 QA 8.8 分（$3.24）→ 2 回目 Build 1 時間 2 分（$37）→ 2 回目 QA 6.8 分（$3.09）→ 3 回目 Build 10.9 分（$5.88）→ 3 回目 QA 9.6 分（$4.06）。

Build がコストの大半を占め、QA は安価ですが、各ラウンドで実際の問題を捉えています。1 回目では複数の核心的な DAW 機能が「表示のみ（見れるが使えない）」であることが発覚し、2 回目ではオーディオ録音がスタブのままで、クリップのドラッグ＆ドロップや分割ができないことが判明しました。外部チェックがない場合、Generator はインタラクションの深さを飛び越えて「表面的に終わらせる」傾向があり、これは単一エージェントモードでのゲーム制作ツール「見た目は使えるが実際には遊べない」と同じ問題です。

claudes-c-compiler のコスト構造（2 週間、約 2 万ドル）と比較すると、ハーネス設計の 1 回あたりの実行ははるかに安価ですが、出力される複雑さも異なります。片方は 10 万行のコンパイラ、もう片方は機能完備の Web アプリです。有意義な比較は、どちらの方式においても人間の時間はコードを書くことではなく、ハーネス（テスト環境、評価基準、エージェントアーキテクチャ）の設計に費やされているという点です。

4. 総合的抽出：AI コーディングのエンジニアリング実践

以下の実践は、5 つのプロジェクト（C コンパイラ、buffa、connect-rust、tokio フォーク、moka フォーク）と 2 つのブログ記事（C コンパイラのエージェントチーム、ハーネス設計）から総合的に抽出したものです。

DESIGN.md は AI のための長期記憶

buffa の DESIGN.md は、プロジェクト全体で最も情報密度の高いファイルです。

CLAUDE.md には See DESIGN.md for the architectural overview とあり、Claude Code が新しいセッションを開始するたびにこれを読み込むことを意味します。

「なぜこのファイル名が Arch.md ではないのか」と疑問に思う人もいるかもしれません。

• Arch.md が示唆するのは「システムがどのような姿か」です。モジュール分割、データフロー、インターフェース定義。これらは静的で記述的なものです。
• DESIGN.md が示唆するのは「なぜシステムはそのような姿なのか」です。意思決定のプロセス、却下された案、トレードオフ。これらは動的で、議論的なものです。

buffa の DESIGN.md において、真のアーキテクチャ記述（モジュール境界、データフロー図、型マッピング）が占めるのは約 35% に過ぎません。残りの 65% は 5 つの機能的な内容です。

このうち、意思決定の歴史と却下された案は、AI との協調のために特別に追加されたものです。これらは「なぜコードが別の形ではないのか」に答え、まさに AI が最も間違いを犯しやすい部分です。

buffa は人間と機械の協調です。人間が意思決定の歴史を文書に書き込むことで、文書の性質は「アーキテクチャの記述」から「設計の論証」へとアップグレードされます。

一方、C コンパイラプロジェクトでは、Carlini 氏は README や進捗ファイルを Claude 自身に維持させることで同様の問題解決を図りました。しかし、この自己維持型ドキュメントの品質は、人間が事前に記述した DESIGN.md には明らかに及びません。これが、buffa が本番用コードである一方、C コンパイラのコード品質が「専門家レベルには程遠い」理由の 1 つです。

詳細な逐語的解釈は付録 A：buffa-design-annotated.md を参照してください。

レビュー担当と実行者は分離されなければならない

これは 3 つの情報源で最も一貫した発見です。

buffa/connect-rust：rust-code-reviewer.md（model: opus, tools: Read, Glob, Grep — 読み取り専用権限）でレビューを行い、レビュー担当はコードを変更できません。

C コンパイラ：専用のエージェント役割でコード品質のレビューと重複除去を行い、コーディングエージェントとは分離。

ハーネス設計：AI は自己評価すると体系的に甘くなるため、独立した Evaluator が必要。Evaluator を厳しく調整する方が、Generator に自己批判させるよりもはるかに容易。

3 つの情報源が独立して同じ結論を指し示しています。「実行」と「評価」は同じエージェントであってはならない。これは GAN の対抗構造がエンジニアリング実践において自然に表現されたものです。

rust-code-reviewer の 16 のレビュー次元も注目に値します。API Design が 1 位（何よりも可用性）、Unsafe が 8 位（セキュリティは良い設計の結果であり、独立した目標ではない）、Security には timing-safe や zeroize が含まれます（機密データを扱う必要性を露呈）。

詳細な逐語的解釈は付録 B：rust-code-reviewer-annotated.md を参照してください。

テストの質がコードの質を決める

C コンパイラのブログは最も端的に述べています。Claude は与えられた問題を自主的に解決しようとするため、タスクの検証機能はほぼ完璧でなければならない。さもなければ、Claude は間違った問題を解決しようとしてしまいます。

ハーネス設計のブログでは、Playwright MCP を使ったエンドツーエンド検証を行い、Evaluator は本物のユーザーのようにページを移動し、スクリーンショットを撮り、ボタンをクリックします。スプリント 3 では、単一のスプリントで 27 件のテスト基準がありました。

buffa は Google の protobuf conformance test suite を「真実の源」として依存しています。

3 つの共通パターンは、人間の中核作業が「コードを書く」ことから「テストを書き、検証環境を設計する」ことに変わったことです。テストは承認のツールではなく、AI のためのナビゲーションシステムなのです。

ただし、テストは人間のためではなく、AI のために書かれるべきです。

• 何千行もの不要な出力を印刷しない（コンテキスト汚染の防止）。
• エラーメッセージには ERROR プレフィックスを付け、grep しやすくする。
• AI による手動分析を避けるため、集計統計を事前計算する。
• AI の「時間盲」を解決するため、ランダムサンプリングを実行する --fast オプションを追加する。
• テスト名自体を仕様とする（例：explicit_presence_with_zero_value）。

インフラで AI の振る舞いを制約する

すべてのプロジェクトが同じパターンを示しています。AI をプロンプトで説教するのではなく、構造とツールで制約するのです。

却下された案を記録する

buffa の DESIGN.md にある「Rejected: Pre-scan capacity reservation for view Vecs」では、2 つのプレスキャン案のベンチマーク結果（20-97% のパフォーマンス後退）と失敗理由が完全に記録されています。docs/investigations/e0477-owned-view-send/ には完全な調査プロセスが記録されています。

これは AI コーディングにおいて最も見落とされがちですが、最も価値のある実践です。AI がすでに偽証された案に後退するのを防ぐこと。これは AI コーディングにおいて最も一般的な品質問題の 1 つです。AI はコード内の Vec の増加コストを見ると、反射的に「事前割り当て」を提案します。却下された案の記録がなければ、新しい AI のセッションごとに、すでに偽証されたこの「最適化」を再提案してしまう可能性があります。

コンテキスト管理の 3 つの戦略

3 つのプロジェクトと 2 つのブログは、3 つの異なるコンテキスト管理方法を示しています。

静的ドキュメントの注入（buffa）。人間が DESIGN.md を事前記述し、Claude Code が各セッションで読み込みます。品質は最高ですが、人間による事前の投資が必要です。

AI による自己維持型のランタイムドキュメント（C コンパイラ）。プロンプトで Claude に README や進捗ファイルを頻繁に更新するよう指示します。自律動作シナリオに適していますが、ドキュメント品質は人間が書くものには及びません。

コンテキストリセット＋構造化ハンドオフ（ハーネス設計）。コンテキストをクリアして新しいエージェントを起動し、スプリント契約と評価レポートで状態を伝達します。Opus 4.5 はこれを強く必要としました（「コンテキスト不安」があるため）が、Opus 4.6 はほぼ不要になりました。

どの戦略を選ぶかはタスクの種類によります。人間と機械の協調には静的ドキュメント、完全自律には AI 自己維持、長時間実行にはリセット＋ハンドオフです。しかし、ハーネス設計ブログの重要な発見は、これらの戦略の必要性はモデルのアップグレードとともに変化するということです。各コンポーネントは「モデルにできないこと」という仮説をコード化したものであり、新しいモデルが公開された際には再検討すべきです。

並列化の鍵は「タスクの分割可能性」

C コンパイラのブログは、並列化に関する最も深い洞察を提供しています。

テストスイートに数百の独立した失敗テストがある場合、並列化は簡単です。各エージェントが異なる失敗テストを選んで修正すればよいからです。しかし、16 人のエージェントが Linux カーネルをコンパイルする場合、全員が同じバグで行き詰まり、互いを上書きしてしまいます。

解決策は既知の正解実装を使って並列可能なサブタスクを作り出すことです。GCC でカーネルファイルの大部分をランダムにコンパイルし、Claude には残りのファイルのみを処理させます。これにより、各エージェントが異なるファイルの異なるバグを修正できるようになります。

これは一般的なパターンです。タスクが並列化できない場合、それを分割する「オラクル」を見つけること。ハーネス設計では、スプリント構造がこれに相当し、大規模なアプリケーションを独立した機能スプリントに分割しています。

エージェントの専門化

C コンパイラとハーネス設計は、エージェントの専門化の価値を示しています。

レビュー／評価エージェントは、コーディングエージェントよりも「高価」であるべき。buffa はレビューに Opus を使用（コーディングは Sonnet）。ハーネス設計の Evaluator は Playwright を使ったエンドツーエンドテストを行います。判断力は生成速度よりも価値があるのです。

5. 再利用可能な方法論フレームワーク

ドキュメントの 5 層ピラミッド

以上から、AI 協働のためのドキュメント体系を抽出できます。

従来のプロジェクトで必要だったのは L4 と L2 の一部です。L1、L3、L5 は AI 協働のために特別に追加されたものです。ハーネス設計ブログのスプリント契約や評価基準は L2 の動的バージョン、C コンパイラで Claude が自己維持する README は L2 の自動化バージョンです。

5 つの中核原則

原則 1：テストの質がコードの質を決める。AI は与えられた問題を解決するため、検証機能はほぼ完璧である必要がある。テストは AI のために書く（出力は簡潔に、機械可読に、サンプリングモードで時間盲を解決）。

原則 2：「実行」と「評価」は分離されなければならない。AI による自己評価は体系的に甘くなる。独立した Evaluator ＋ 読み取り専用権限 ＋ 高性能モデル ＝ 信頼性の高い品質フィードバック。

原則 3：インフラで制約し、プロンプトで説教しない。CI パイプライン、ファイルロック、型チェッカー、評価閾値。これらのハードな制約は、「高品質なコードを書いてください」というお願いよりもはるかに効果的。

原則 4：却下された案を記録する。AI がすでに偽証された案に後退するのを防ぐことは、AI コーディングにおける最もユニークなドキュメント需要。

原則 5：ハーネスはモデルのアップグレードとともに簡素化される。各コンポーネントは「モデルにできないこと」という仮説をコード化している。新しいモデルが公開された際は、もはや負荷を支えていないコンポーネントを剥がし取り、より高い能力を実現するための新しいコンポーネントを追加する。

AI コーディングの適用範囲

最終行は 2 つのフォークによって追加された次元です。tokio のスケジューラストール検出や moka の TOCTOU 修正は、いずれも「ランタイム内部」に属します。こうした作業には、非同期スケジューラのワークスティーリングアルゴリズムや、並列データ構造のメモリ順序などへの深い理解が求められ、現時点では依然として人間エンジニアの領域です。

6. 結び

Anthropic の 5 つのオープンソースプロジェクトと 2 つのエンジニアリングブログ、計 7 つの情報源は、すべて同じ基盤哲学を指し示しています。

AI コーディングの品質の上限はモデルの能力ではなく、モデルの周りに構築した制約、フィードバック、検証の構造によって決まる。

buffa の DESIGN.md は静的な制約（人間が事前記述した長期記憶）、C コンパイラの CI とテストハーネスは動的な制約（ランタイム時の品質ゲート）、ハーネス設計の Generator-Evaluator 対抗は対抗的な制約（GAN 構造のエンジニアリング応用）です。3 つの制約方法は異なるシナリオに向いていますが、基盤となるロジックは同じです。

そして tokio と moka のフォークは別の次元を露呈させました。AI が書いたコードは、最終的に真のインフラ上で動作するということです。buffa や connect-rust が本番環境に入り、数百万ユーザーの並列負荷に耐えたとき、露呈したのは AI コーディングの問題ではなく、基盤ランタイムや依存ライブラリの問題、つまりスケジューラストールや並列キャッシュの競合状態でした。こうした問題は、tokio や moka という深さで人間エンジニアが調査・修正する必要があり、現在の AI コーディング能力の範囲外です。

Carlini 氏は C コンパイラのブログの結びで、興奮すると同時に不安も感じたと述べています。元ペネトレーションテスターとして、「プログラマーが自ら一度も検証していないソフトウェアをデプロイするのは、本当に心配だ」と語っています。この懸念は buffa の手法と有意義な緊張関係を生んでいます。buffa はすべての conformance テストに合格し、本番環境で使用されています。一方、C コンパイラは既知の欠陥を明記しています。違いは検証の完全性です。AI が書いたコードが信頼に足るのは、検証体制が完備している場合のみです。

Anthropic 自身がこの方法論の最良の実践者です。彼らは誰よりも、Claude がどのタスクで信頼できるか（buffa のエンコード／デコード）、どのタスクで人間のアーキテクチャを必要とするか（connect-rust の RPC 設計）、どのタスクなら完全自律だが品質は保証されないか（C コンパイラのデモ）、どのタスクには AI を関与させるべきでないか（tokio のスケジューラ内部や moka の並列プリミティブの正当性の修正）を理解しています。

ハーネス設計ブログの最後の言葉は、本稿全体の結びとするにふさわしいでしょう。

「興味深いハーネスの組み合わせの空間は、モデルの進歩によって縮小することはない。それは移動するだけだ。AI エンジニアの面白い仕事は、常に次の新しい組み合わせを見つけることだ」

付録

付録 A：buffa-design-annotated.md — buffa の DESIGN.md の逐段日中対照解釈 Gist^[8]

付録 B：rust-code-reviewer-annotated.md — connect-rust の rust-code-reviewer.md の逐段日中対照解釈 Gist^[9]

参考資料

[1] connect-rust: https://github.com/anthropics/connect-rust

[2] Building a C compiler with a team of parallel Claudes: https://www.anthropic.com/engineering/building-c-compiler

[3] Harness design for long-running application development: https://www.anthropic.com/engineering/harness-design-long-running-apps

[4] anthropics/tokio: https://github.com/anthropics/tokio

[5] anthropics/moka: https://github.com/anthropics/moka

[6] ConnectRPC: https://connectrpc.com/docs/protocol/

[7] RFC 007: https://github.com/connectrpc/connectrpc.com/pull/334

[8] buffa-design-annotated.md — buffa DESIGN.md の逐段日中対照解釈 Gist: https://gist.github.com/ZhangHanDong/f4ac670f2fdd939bc4355dad93df92b0

[9] rust-code-reviewer-annotated.md — connect-rust rust-code-reviewer.md の逐段日中対照解釈 Gist: https://gist.github.com/ZhangHanDong/ebc9577991d0a5ce94f1d91c5d64fe40