Anthropic が公開した ABC Legal の導入事例は、「エージェントを作れるか」ではなく「エージェントを組織として運用できるか」に踏み込んだ内容だった。従業員1,100名の法務書類配達企業が、散在していた自動化スクリプトを Claude Managed Agents に集約し、50体以上のエージェントを Git リポジトリで統治するに至った経緯が語られている。

特に面白いのは、非エンジニアが本番エージェントを作れるようにするために何を捨てたのか、そして Slack の絵文字リアクションを Pull Request に変換する自己改善ループをどう組んだのか、という2点だ。ハーネス設計をやっている立場から読むと、示唆が濃い。

散在したスケジュールタスクから、統治されたフリートへ

CTO の Brandon Fuller が Claude Enterprise を全社展開したところ、送達業務・電子申請・弁護士手配といったオペレーション部門に加え、マーケティング、コンプライアンス、財務まで、依頼されてもいないのに現場が自発的に業務自動化を始めた。コネクタとツールの手軽さに現場が飛びついた形だ。

ただし初期のエージェントは、作った人の個人デスクトップ上のスケジュールタスクとして living していた。これを個人マシンから引き剥がせば、無人で常時稼働させられるうえ、何が作られていて、いくらかかっていて、昨夜ちゃんと動いたのかを単一の画面で把握できる。この動機で Managed Agents の導入に踏み切っている。

指標（2026年7月時点）	数値
本番稼働エージェント数	50体以上
対象業務の人的コスト削減	最大 約50%（本格的な最適化前の段階で）
Claude を日常業務で使う従業員	約310名（全部門）

エージェントをコードとして扱う

Fuller はチームに、すべてのエージェントをコードとして定義させた。彼の理屈はシンプルで、エージェントとは要するに構造化されたテキスト、つまりプロンプトと設定の組み合わせであり、テキストであるならリポジトリに置いて全社でレビューし改善できる、というものだ。

プロンプト、ツールリスト、スケジュール、認証情報、メモリのすべてが設定ファイルとして、既存のアプリケーションコードと同じ Git リポジトリに入る。エージェントの変更は、誰かが承認した Pull Request 経由でしか起こらない。この一手で、バージョン履歴・コードレビュー・ロールバック・監査証跡がまとめて手に入る。

スターターキットの構築にかけたのは1週間。用意したテンプレートは2種類だけだ。

エージェント1体は1フォルダに対応し、構造は全体で統一されている。

main ブランチへのマージがそのままデプロイになる。ビルダー側の手順は、リポジトリを clone し、テンプレートをコピーし、Claude Code に「このエージェントは何をするのか」を伝えるだけ。config、プロンプト、認証情報ストア、メモリが一式返ってくる。ビルダーはソフトウェアを書かない。

非エンジニア15名を、1週間でビルダーにする

Fuller は財務・マーケティング・オペレーション・開発から15名の運営委員会を集めた。ソフトウェア開発者はひとりもいない。この全員にリポジトリを clone させ、Claude Code で Managed Agents を構築させた。

狙いは明確で、すべてのエージェントが開発チームを経由しなければならないなら、そのボトルネックが全社の移動速度の上限になるということ。安全にこれができたのは、彼らが書いていたのがソフトウェアではなく、設定とプロンプトだったからだ。ランタイムは Managed Agents 側が提供する。

業務プロセスの各段階に1体ずつ

ABC Legal は現在、法務申請プロセスとその周辺業務のほとんどの段階にエージェントを配置している。

Harvester と Tuner: リアクションを Pull Request に変える

ABC Legal のエージェントは人間の監督下で動き、やったこと・推奨することを Slack に投稿する。人はスレッドで返信し、絵文字でリアクションする。Fuller はこのリアクションデータが訓練シグナルとして捨てられていることに着目した。

ただしすべてのエージェントにこのシグナルが必要なわけではない。フリートの大半は出力を誰も採点しない単発タスク型で、それらは単独で動かしている。採点付きのフィードバックが実際に集まるエージェントに対してだけ、3ロール構成を適用する。

3体は同一のワークスペース・環境・認証情報 Vault を共有しつつ、それぞれ別のスケジュールで走る独立したエージェントとして構成される。

deliveries-as-code への応用

この発想を業務ルールそのものに適用したのが、姉妹会社 Docketly（50名規模）での deliveries-as-code だ。Docketly は業務をデリバリー単位で組み立てており、それぞれにルーティングと処理のルールセットがある。この約145件のルールセットを、管理画面上のレコードではなく Git 上の YAML ファイル1件ずつとして保持している。デリバリーのチューニングとは、ファイルを編集して Pull Request を開くことを意味する。

ループを構成するのは4体。1体目が週次の判定を Slack に投稿し、Harvester がリアクションをラベルに変え、Tuner が YAML に対して Pull Request を開き、4体目がマージ済みの設定を本番データベースへ反映する。4体目は人間がすでにレビューして承認したものしか実行しない。

結果として、誤ルーティングを指摘する絵文字リアクションが、その週のうちにルーティングルールのマージ済み変更になる。ループの中で手動なのはレビューだけだ。

Managed Agents を選んだ理由と責任分界

Fuller は複数のフレームワークを評価したうえで Managed Agents を組織のエージェントハーネスに据えた。評価軸は具体的で、バージョニング、観測可能なセッション、ワークスペース単位の課金、モデル選択、メモリプリミティブ、MCP 配線、そして最も重要なものとしてお守りが必要なインフラが存在しないことを挙げている。

Anthropic 側が持つもの	ABC Legal 側が持つもの
実行ループ、セッション、メモリ、コンソール、モデルそのもの	プロンプト、ツールリスト、トリガーロジック、監査証跡、成果のフィードバックループ

スケールしてから効いた機能として挙げられているのは以下。

効率比と J カーブ

ABC Legal は AI 支出の全額を、ベンダー・ツール・チーム・ユースケース単位に分解してトラッキングしている。フリートが立ち上がった春には支出が増え続けたが、7月には利用量が伸びたまま支出が減少に転じた。

コストに対する方針は意図的で、リターンが測定可能な垂直・業務特化型のツールとエージェントに支出を寄せ、水平的なチャットや発想用途の利用は広く保ちつつコストは抑える、という配分をとっている。

追っている指標は効率比、つまりエージェントが生む価値をその運用コストで割ったものだ。すべての Managed Agent が実行のたびに、自身の価値を時間とドル建てでデータウェアハウスに報告する。

human-in-the-loop からの卒業条件も、この計測フレームワークに紐づいている。ほとんどのエージェントは人間の確認を挟むところから始まり、ジョブ画面のバナーか Slack チャンネルで推奨を提示する。人間の受諾・却下の応答が良し悪しのラベル付きデータセットを形成し、それが Harvester と Tuner に供給され、同時に eval の作成とフロンティアモデル横断のベンチマークを可能にする。その特定タスクにおいて人間と同等以上だと証明できて初めて自律実行モードに移り、移行後も同じ計測の枠内に留めて性能の変化を監視する。

運用7原則

原則	内容
すべてをコードとして考える	コードは構造化テキスト、LLM はテキストエンジン。プロンプト、スキーマ、振り分けルール、通知テンプレート、業務設定をリポジトリに載せるほどレバレッジが効く
人間をループに入れて始める	すべてのエージェントは推奨の提示から始まり、人間の判断と一貫して一致することを示して初めて単独行動の権利を得る
Pull Request を制御面にする	エージェントを意思決定に関与させたいなら、その意思決定を Pull Request の形にする。行単位コメント、承認ワークフロー、不変の監査証跡がバージョン管理から無料でついてくる
フィードバックループに投資する	Harvester と Tuner のパターンにより、再学習なしにエージェントが改善する
スケジュールタスクの寄り道を飛ばす	ABC Legal は Managed Agents がベータ直後だったためローカルのスケジュールタスクを先に作り込み、その工数を無駄にした
AI の壁ではなく Git の壁を想定する	速く進んだが、それでも Git は実在するハードルだった
すべてのタスクがエージェントに値するわけではない	コストは現実に発生する。価値対コストで考え、これはエージェント化に値しないと言える必要がある

ハーネス設計の視点から

自分でエージェントハーネスを組んでいる立場で読むと、刺さる点が3つあった。

1つ目は Harvester と Tuner の分離。品質ゲートで敵対的レビューをかける設計は「その場で品質を上げる」ためのもので、「経験を蓄積する」設計ではない。ABC Legal の構成は、監査証跡を後から別スケジュールのエージェントが読み、プロンプトと設定への変更提案に変換する。つまりゲートを「その場の判定」と「後からの学習」の2層に分けている。この分離は自前ハーネスにも移植できる。

2つ目は Tuner の権限制約。モデルの重みではなくプロンプトと設定を変える、ドラフトのみでマージは人間、という二重の制約が自己改善ループを安全側に倒している。SubAgent に自己改善を許すなら、書き込み先を設定層に限定し、適用に Pull Request 相当のゲートを挟むのが素直な解に見える。コードで縛れるものはコードで縛る、という原則そのものだ。

3つ目は 効率比と J カーブ。ハーネスの評価指標は品質側に寄りがちだが、「価値÷コスト」を各ループが自己申告する設計は真似できる。しかも J カーブを前提にしているぶん、導入直後の赤字を失敗と判定しない評価タイミングの設計が要る。ここは品質中心の eval が持っていない視点だった。