— 実装、レビューからHarnessの整備、そしてHarnessを評価するEvalsへ
1. はじめに
こんにちは、開発本部開発1部デリッシュキッチン開発部所属の西本（@daikon265）です。
6月11日に開催されたCode w/ Claude: Extended Tokyoに参加してきました。参加して感じたのは、Claude Codeの活用が「どうコードを書かせるか」から、「Claudeが安全に働ける環境をどう作り、どう改善し続けるか」に移っていることでした。
これまでClaude Codeの活用では、Harnessを使ってClaudeをうまく制御する話が中心だったと思います。
一方で今回のカンファレンスでは、そのHarness自体をどう評価し、どう育てるかという視点も強く出ていました。
Anthropicのエンジニアとの1on1で、私は次のような質問をしました。
モデルが進化するにつれて、
今のHarnessはだんだん形骸化して、
むしろ邪魔になっていくのではないか？
返ってきた答えは印象的でした。
その直感は正しい。モデルが賢くなるにつれて、Harnessの重要性は下がっていく。Anthropic社内では、新しいモデルを定量評価し、その結果に基づいて、CLAUDE.mdを小さくするか、Skillsがノイズになっていないかを判断している。
Anthropicの中ではすでに、Evalsを使ってHarnessを評価し、必要なものを残し、不要になったものを削る運用が回っているということです。
本稿では、この考え方を抽象論に留めず、実際の開発フローに落とし込んで考えます。
大きくは、次の3つのフェーズで整理します。
1. 実装フェーズ
1-1. Plan：実装前に何を具体化するか
1-2. Implementation：サブエージェントにどう実装を分担させるか
2. レビュー・マージフェーズ
2-1. PRで何を見せるか
2-2. Claudeと人間でレビューをどう分担するか
3. 運用・改善フェーズ
3-1. マージ後に何を観察するか
3-2. 学びをどうHarnessに戻すか
それぞれのフェーズで、カンファレンスで語られていた内容を紹介しつつ、自分たちの開発に取り入れるならどういう形になりそうかを整理していきます。
2. 実装フェーズ
実装フェーズは、さらに Plan と Implementation に分けて考えます。
ここでいうPlanは、実装前に仕様判断、実装判断、検証判断を具体化する工程です。自分も以前から、Claudeにいきなり実装させる前に、まず計画を作らせることはしていました。
ただ、その計画の立て方や粒度は曖昧になりがちです。
どこまでClaudeに質問させるのか。
どこまで仕様を固めるのか。
どの時点で検証条件を決めるのか。
どの情報を残しておけば、後続の実装やレビューで使えるのか。
今回のワークショップで分かりやすかったのは、まさにこの「Planをどう具体化するか」でした。
2-1. Plan：実装前に何を具体化するか
2-1-1. まずClaudeに質問させる
「How we Claude Code」ワークショップでは、エージェントが長時間自律稼働できるようになってきたことで、ミスのコストが上がっているという問題意識が語られていました。そこで紹介されていたのが、コードを書かせる前にClaudeへユーザーをインタビューさせ、曖昧さやエッジケースを引き出す方法です。
たとえば、次のような依頼は危険です。
友達用の割り勘アプリを作って
この依頼だけでも、Claudeはそれらしいものを作れます。
しかし、保存方法はどうするのか、精算はアプリ内で行うのか、通貨は複数対応するのか、誰が誰にいくら払うべきかをどう最小化するのか、といった判断をClaudeが勝手に埋めることになります。
ワークショップで紹介されていたのは、次のようにClaudeに質問させる進め方です。
いくつか確信が持てない点があります。
まず私にインタビューして、仕様の曖昧なところを整理してください。
質問は一度に多くしすぎず、重要なものから聞いてください。
回答をもとに、実装前に合意すべき仕様をまとめてください。
デモでは、Claudeが用途、分割方法、保存方法、精算方法、通貨、共有方法などを質問し、回答に矛盾があれば追加で確認していました。その結果として、実装に入る前に詳細なspecが生成されていました。
ここで大事なのは、Claudeに質問させることで、実装前に判断が必要なことを表に出すことです。
2-1-2. 検証条件を先に決める
Planで特に重要なのが、検証条件を先に決めることです。
検証に関するデモでは、実装前に Fixture、Invariant、Probe を決めることが強調されていました。
| 項目 |
意味 |
| Fixture |
検証時に再現する状態 |
| Invariant |
常に成り立っていてほしい性質 |
| Probe |
検証時に観測するポイント |
たとえばTo Doアプリなら、こうなります。
| Fixture |
Invariant |
Probe |
| 完了済みのTodoが1件ある |
完了状態のデータと画面表示が一致している |
DOM上の状態属性、取り消し線の表示 |
| 非常に長いテキストのTodoがある |
レイアウトが崩れない |
表示領域、折り返し、スクロール |
| Todoが0件 |
空状態が表示される |
empty stateの文言、追加ボタンの表示 |
この考え方があると、Claudeも人間も「何をもって正しいと判断するのか」を共有できます。
2-1-3. Probeを実装上で観測できるようにする
Fixture / Invariant / Probe を決めても、実装上でその状態を観測できなければ検証はしづらくなります。
このデモで特徴的だったのが、アプリの状態をDOMにスタンプする方法です。たとえばTodoが完了済みであれば、DOMに次のような属性を出します。
<li
class="todo-item todo-item--done"
data-verified-done="true"
>
oat milk
</li>
未完了であれば、data-verified-done="false" になります。
ここで見たいのは、内部状態と画面表示の一致です。
data-verified-done="true"
かつ
画面上も完了状態として表示されている
Reactの内部状態を直接見に行く方法もありますが、実装依存になりやすく、検証のたびに扱いが面倒になります。そこで、検証したい状態をDOM属性として外に出しておくことで、Claudeや検証スクリプトが確認しやすい観測点を作ります。
つまりDOMスタンプは、Probeを成立させるための仕込みです。
これにより、内部状態としては完了済みなのに、画面上では完了済みに見えない、といったズレを検出しやすくなります。ワークショップでも、Reactのメモリ上ではTodoが完了済みなのに、画面に取り消し線が出ないケースを、この考え方で検出していました。
2-1-4. 自分たちのPlanでは何を残すか
ここまでの内容を自分たちの開発に落とすなら、Planでは次の3つを残します。
| ファイル |
対応する考え方 |
書くこと |
spec.md |
インタビューで固めた仕様 |
作るもの、作らないもの、制約、未決事項 |
plan.md |
実装の進め方 |
参照すべき既存実装、変更順序、実装方針 |
verification.md |
Fixture / Invariant / Probe / 観測点 |
再現する状態、守るべきルール、観測するポイント、コード上の観測点 |
verification.md には、単なる「テストする」で終わらせず、次の形で残します。
| Fixture |
Invariant |
Probe |
実装上の観測点（追加） |
| 完了済みのTodoが1件ある |
完了状態のデータと画面表示が一致している |
DOM上の状態属性、取り消し線の表示 |
data-verified-done |
| 非常に長いテキストのTodoがある |
レイアウトが崩れない |
表示領域、折り返し、スクロール |
Storybook / Playwright snapshot |
| Todoが0件 |
空状態が表示される |
empty stateの文言、追加ボタンの表示 |
empty state selector |
Planのゴールは、Claudeが実装に入る前に、仕様判断・実装判断・検証判断を分離して、後から追える形にすることです。ドキュメントは、その判断を残すための手段として扱います。
2-1-5. Bunの実装ガイドを一般化する
「Rewriting Bun in Rust」では、ClaudeにBunをZigからRustへ書き直させ、約11日で巨大なPRをマージした事例が紹介されていました。
この事例で参考になるのは、実装に入る前に、複数のClaudeが同じ判断基準で動けるように、事前にルールを作っていた点です。
Bunでは、最初にClaudeと約3時間対話し、Zigの書き方をRustではどう表現するかを整理しました。その結果をポーティングガイドとしてまとめ、以後のClaudeインスタンスが必ず参照する資料にしています。さらに、Bunコードベース内の構造体やフィールドを調査し、ライフタイムに関する情報も共通資料として使っていました。
「ZigのパターンをRustにマッピングする」と言うと少し分かりにくいですが、要するにこれは 変換ルール集 です。
Bunの例
- Zigのこの書き方は、Rustではこう書く
- メモリ管理はこの方針にする
- crate分割はこの考え方にする
- ライフタイムが複雑な箇所はこの資料を参照する
これを自分たちの開発に置き換えると、次のようになります。
自分たちの例
- 古いAPI呼び出しは、新しいclientに置き換える
- 独自UIは、design system componentに寄せる
- 古いhooksは、新しいhooksに統一する
- DB更新は、このmigration方針に従う
- エラーハンドリングは、この形式に揃える
普段の開発では、これを implementation-guide.md として扱えばよさそうです。
| 変更の種類 |
作るもの |
| 小さな修正 |
spec.md / plan.md / verification.md |
| 複数箇所に同じ方針を適用する変更 |
implementation-guide.md を追加 |
| 複数のClaudeを並列に動かす変更 |
implementation-guide.md をほぼ必須にする |
複数のClaudeを並列に動かす場合、全員が同じ判断基準を持っていないと、ファイルごとに実装スタイルがばらつきます。
implementation-guide.md は、そのばらつきを抑えるための共通ルールです。
コラム：HTMLプロトタイプはプロトタイプ開発で使える
ワークショップでは、Planができた後にHTMLプロトタイプを作る方法も紹介されていました。
背景にあるのは、Anthropicの “Demos, not memos” という考え方です。Markdownの仕様書はClaudeには読みやすい一方で、人間が直感的に判断するには弱い。人間は、文字だけで仕様を読むより、触れるものを見たほうが「ここが違う」「この方向性は好き」と反応しやすい。そこで、ClaudeにHTMLで軽量なプロトタイプを作らせ、触りながら方向性を固める、という流れです。
自分でこれを取り入れるなら次のような感じがいいと考えています。
初期探索
- エンジニアがClaudeとHTMLプロトタイプを作る
- 最低限触れる状態にして公開する
- ユーザーや市場の反応を見る
ブラッシュアップ
- 反応が良ければ、Figmaでデザイナーに詳細を詰めてもらう
- デザインシステムに載せる
- 本格的に磨く
この進め方は、今後増えていくと思います。
2-2. Implementation：サブエージェントに実装を分担し、失敗を再配布する
Planができたら、実装に入ります。
ある程度の規模のタスクでは、複数のサブエージェントに分担させて並列に進めることが増えてきていると思います。
ここで参考になるのが、Bunの実装方法です。
Bunの事例では、並列実行時の制御も重要でした。重い操作や競合しやすい操作を各エージェントに任せきりにしないようにしていました。複数のClaudeがそれぞれbuildやtest、git操作を実行すると、同じ確認を重複して行ったり、同じworktree内で互いに干渉したり、全体の進行を遅くしてしまうからです。
そのため、build / test / git操作のような重い処理は、メイン側のワークフローで管理します。サブエージェントは実装や修正に集中し、メインエージェントが結果を集約して、失敗ログを分類し、担当するサブエージェントへ再配布します。
このループでは、役割を大きく3つに分けます。
| 役割 |
担うこと |
| Main Agent |
spec.md / plan.md / verification.md を読み、作業を分割する。実装結果を集約し、build / test / lint / typecheck をまとめて実行する。失敗ログを分類し、必要なサブエージェントへ再配布する。 |
| Sub Agents |
割り当てられた範囲を実装する。必要に応じて、実装担当とレビュー担当を分ける。レビュー担当は diff や spec を読み、仕様違反、バグ、テスト不足を探す。 |
| Human |
仕様判断、設計判断、本番リスクを確認する。特にクリティカルな変更では、AIの検証結果だけでなくコードや動作も見る。 |
各サブエージェントに任せる範囲は絞ります。各サブエージェントがそれぞれ build や test を走らせ、個別に判断し始めると、重い処理が重複し、失敗ログの扱いもばらつきます。
そのため、検証と再配布は Main Agent 側に集約します。Main Agent が失敗ログを見て、次に誰へ戻すかを判断します。
| 失敗の種類 |
戻し先 |
| build failure |
backend 担当の Sub Agent |
| UI regression |
frontend 担当の Sub Agent |
| test failure |
test 担当、または該当実装担当の Sub Agent |
| migration error |
DB 担当の Sub Agent |
| spec とのズレ |
実装担当の Sub Agent |
| 横断的な設計ミス |
Main Agent が plan を見直す |
このループの本質は、検証結果を次のタスク分配の入力にすることです。失敗を検出したら、原因ごとに担当へ戻します。さらに同じ失敗が繰り返されるなら、プロンプト、ルール、verification、implementation-guide 側に戻して、生成プロセス自体を直します。
3. レビュー・マージフェーズ
レビュー・マージフェーズで重要なのは、検証結果を人間が判断しやすい形で見せることです。
3-1. PRでは検証結果を証拠として見せる
PRには、変更概要や影響範囲だけでなく、動作確認や検証結果を載せます。
特にUIやワークフローが関わる変更では、スクリーンショットや動画が有効です。実際にどう動いたか、どの状態で確認したかが見えると、レビュアーは判断しやすくなります。
PRでは、最低限次の情報を揃えます。
| PRに載せるもの |
目的 |
| 変更概要 |
何を変えたかを短く把握する |
| 影響範囲 |
どの画面・機能・APIに影響するかを見る |
| 検証結果 |
どのFixture / Invariant / Probeを確認したかを見る |
| スクリーンショット・動画 |
実際の動作やUIの崩れがないことを見る |
| レビュアーに見てほしい箇所 |
判断が必要な点を明確にする |
3-2. 検証ダッシュボードで状態と結果を見える化する
検証ダッシュボードのデモで特徴的だったのは、検証用のダッシュボードを作っていた点です。
通常のテストログでは、どのテストが通ったかは分かります。ただ、UIやワークフローの検証では、それだけだと「どの状態で、何を確認したのか」が見えにくい。そこで、検証ダッシュボード上に、どの画面・コンポーネントを、どのfixtureで、どのinvariantに対して検証したのかを表示します。
たとえば、次のような情報が見える状態です。
| 見えるもの |
例 |
| 対象 |
画面、コンポーネント、ワークフロー |
| Fixture |
空状態、長いテキスト、大量データ、権限なしユーザー |
| Invariant |
レイアウトが崩れない、状態と表示が一致する、権限外操作ができない |
| Probe |
DOM属性、表示テキスト、APIレスポンス、エラー表示 |
| 結果 |
pass / fail、必要に応じてスクリーンショットや録画 |
これは、テストを増やす話というより、検証結果をレビューできる形に変換する話です。Claudeも人間も、同じ証拠を見ながら「何をもって正しいと判断したのか」を確認できます。
3-3. レビューはClaudeと人間で見る観点を分ける
レビューでは、Claudeと人間の役割を分けます。
| 見る人 |
主に見ること |
| Claude |
specとのズレ、テスト不足、エッジケース漏れ、権限・セキュリティの問題、既存挙動の破壊 |
| Human |
実際の動作、仕様解釈、設計判断、ユーザー影響、本番リスク |
Anthropicのエンジニアとの1on1では、社内ではすべてのPRに対してClaudeによる自動コードレビューが走り、その後に人間のレビュアーがハイレベルな観点で確認すると聞きました。
チーム内の運用イメージとしては、Claudeが細かいロジックやspecとのズレを拾い、人間が動作、設計、リスクを判断する形です。クリティカルな変更では、人間もコードを読みます。
4. 運用・改善フェーズ
マージ後も観察と改善は続きます。
むしろ、マージ後に何を観察し、何をHarnessに戻すかが、Claude Codeをチーム開発に組み込むうえで重要になります。
4-1. マージ後も検証を増やす
「Rewriting Bun in Rust」では、テストスイートを通してマージした後も、品質強化が続いていました。マージ後にも別の角度から壊れ方を探す検証を増やしていたことが印象的でした。
たとえば、次のような検証です。
- セキュリティ上の問題を機械的に探す
- ランダムな入力を大量に与えてクラッシュを探す
- メモリリークのような実行時の問題を探す
- テストでは通らなかったコード経路をさらに踏みに行く
講演で語られていた思想は、「動くことを信用したくない。動くことの実証的な根拠を持ちたい」というものでした。
マージ後に検証を増やすことは、次の開発ループを強くするための投資です。
4-2. EvalsでHarnessを育てる
Evalsは、実装・レビュー・運用を回した後に、Harnessを改善するための仕組みとして効いてきます。
「Evals for taste: Hill-climbing a slide-generation agent」では、Evalsは「成功とは何か」を定義し、エージェントが改善しているかを確認するためのものだと説明されていました。最適化対象はプロンプトだけでなく、モデル選択、ツール設計、エージェントのアーキテクチャにも広がる、という話もありました。
「Tool, skill, or subagent? Decomposing an agent that outgrew its prompt」でも、Evalsを改善の絶対的な指針にすることが最大のメッセージとして語られていました。評価結果が上がることを確認できたからこそ、ツール、Skills、サブエージェント構成を改善できたという話です。
冒頭で触れた1on1の話に戻ると、モデルが賢くなれば、以前は必要だった細かい指示が不要になる。場合によっては、古いCLAUDE.mdやSkillsがノイズになる。だからこそ、Anthropic社内では新しいモデルを定量評価し、その結果に基づいて、CLAUDE.mdを小さくするか、Skillsがノイズになっていないかを判断しているそうです。
Harnessは作ったあとも、Evalsによって評価され、必要なら削られる。つまり、EvalsはClaudeの出力を採点しながら、Harnessを育てるための仕組みでもある。
自分たちも、Evalsによって「これはまだ効いているか」「もうノイズになっていないか」を見ていく必要があります。
4-3. 失敗をどこに戻すか
マージ後に観察するものは、次のHarness更新の材料として見ます。
| 観察するもの |
Harnessに戻す先 |
| 本番で出たバグ |
eval / verification |
| 繰り返し出るレビュー指摘 |
review skill / checklist |
| 仕様の取り違え |
specの作り方 |
| テスト漏れ |
verifier / contract test |
| 不要になった指示 |
CLAUDE.md / Skill の削除候補 |
Skillsは、関連するタスクのときだけロードされる手順書として使うのが本質です。「Tool, skill, or subagent? Decomposing an agent that outgrew its prompt」でも、長いプロンプトをオンデマンドのSkillsに分解し、必要なときだけコンテキストをロードする考え方が紹介されていました。
Harnessを育てるほど、余計なものを削る視点も必要になります。
| 増やすもの |
削るもの |
| tests / evals / verifiers / CI / monitoring |
古いCLAUDE.mdの指示 / ノイズになったSkill / 自明すぎるルール |
「Evals for taste: Hill-climbing a slide-generation agent」では、evalスコアが飽和したらgrader自体を見直すべきだという話もありました。見た目は明らかに改善しているのにスコアが上がらないなら、評価側の解像度が足りない可能性があります。その場合は、graderの評価基準を具体化する価値があります。
Claudeの出力とあわせて、評価そのものも育てる。そのループがあると、Harnessの改善が感覚頼みから評価駆動に変わります。
5. 自分たちの開発に落とすなら
ここまでの内容を実務に落とすなら、次の4段階で始めるのがよさそうです。
| フェーズ |
やること |
残すもの |
| Plan |
仕様、実装方針、検証条件を分けて整理する |
spec.md / plan.md / verification.md |
| Implementation |
Main Agent が作業を分割し、Sub Agents が実装する。検証結果は Main Agent が分類して再配布する |
失敗ログ、修正タスク |
| Review / Merge |
PRでは検証結果や動作の証拠を見せる。Claudeは詳細、人間は仕様・設計・リスクを見る |
検証ログ、スクリーンショット、レビュー結果 |
| Post-merge |
本番やレビューで出た失敗を、その場限りにせずHarnessへ戻す |
eval、verification、skill、checklist |
このフローでは、判断基準、検証可能性、レビュー可能な証拠、Harnessへのフィードバックを揃えることが大事です。
anthropic-dev-loop
この流れは再利用できるように、Skillとしても整理しました。Claude CodeやCodexで同じ流れを使いたいときは、このSkillを読み込ませることで、Plan、実装分割、検証、レビュー、Harness更新までを一連の手順として扱えます。
https://github.com/nishimoto265/anthropic-dev-loop
6. おわりに
今回は、Code w/ Claude Tokyo / Extended Tokyoで紹介されていたAnthropicの開発手法を、自分たちの開発フローに落とし込むならどうなるのか、私なりの知見を交えながら整理しました。
Code w/ Claude Tokyo / Extended Tokyoの中で特に印象的だったのは、やはり Evals です。
私自身、評価関数があり、それに基づいてエージェントや開発フローが将来的には自動で改善されていくのではないかと考えていました。その考え方が Evals に現れており、Harnessを評価し、必要なものを残し、不要なものを削っていく手法は、今後さらに重要になっていくと感じています。
今後もAnthropicのエンジニアの手法を参考にしながら、Claude Codeを前提にした開発フローを自分たちなりに改善していきたいと考えています。
