米国の法務文書配信会社ABC Legalは、Claude Managed Agentsで50以上のエージェントを本番稼働させ、非技術部門の310人が日常的にエージェントを作る組織になった。仕組みの核はSlackの絵文字反応がプルリクエストに変わる3層の自己改善ループと、CTO自身が語る「本当のハードルはAIではなかった」という率直な失敗談。
Claude公式ブログの事例から、個人開発の自動化にもそのまま持ち込める「フィードバック収集→改善案PR化→人間承認」というループ設計と、非技術者を巻き込むときに実際につまずくポイントを整理したもの。
ABC Legalは従業員1,100人の米国法務文書配信会社。CTOのBrandon Fuller氏は2026年初頭にClaude Enterpriseを全社導入し、送達業務・eFiling・出廷弁護士の手配・マーケティング・コンプライアンス・財務など複数部門に浸透させた。転機は、バラバラに動いていた実験的な自動化を、Claude Managed Agentsという「共通のデプロイ構造・共有ワークスペース・単一の監査/課金基盤・常時稼働のクラウドエージェント」に統一したことだ。
2026年7月時点の数字は具体的だ。50以上のエージェントが本番稼働し、対象業務のコストは約50%削減、約310人が日常的にClaudeを使っている。中身も実務そのものだ——4つのコードベースのPRを解析するAIコードレビュアー、顧客記録の週次配信を自動化するEvidenceChain™配信エージェント、裁判所への提出却下を診断するeFiling却下診断エージェント、裁判所データベースと照合するJob検証エージェント、出廷弁護士の空き状況を管理するAttorney Coverageエージェント、入金消込を処理するAR-Remittanceエージェント、完了ジョブを98%のコンプライアンス精度でレビューするCharvis、滞留案件の一次レビューを担うService-Overdue-Nudgerと、部門をまたいで実運用に組み込まれている。
この規模を動かしたのは開発者ではない。Fuller氏は財務・マーケティング・オペレーションから15人の運営委員会を集め、1週間で15人全員が動くエージェントを作った。彼らがそれぞれのチームを教育し、1ヶ月で50以上のエージェントに到達した。Fuller氏自身の言葉が象徴的だ。「最初は彼らにPR（プルリクエスト）が何かを説明するところから始めた。今では、彼らが互いにPRを送り合っている」。
改善が継続的に必要なエージェントには、以下の3層構造を適用している。
実際の業務をリアルタイムでこなし、判断の監査証跡を記録する。ここまでは通常の自動化と同じ。
Slackの絵文字リアクションやスレッドの返信という、すでに人間が自然にやっている行動を、ラベル付きのフィードバックデータへ変換する。新しい入力フォームや評価UIを作らない点がポイントだ。
集まったフィードバックをもとに、プロンプトや設定の変更案をプルリクエストとして起票する。モデルの重みそのものを変えるのではなく、プロンプト・設定というテキストの改修に留めるのが要点。人間が承認して初めてマージされる。
狙いは1つ。「エージェントが、開発者がもともと使っているのと同じワークフロー（PRレビュー）を通じて改善される」という設計にすることで、モデルの再学習なしに継続的な改善ループを回せる。
Fuller氏のインフラ哲学は明快だ。「テキストにできるものは何でも、全社が見て・レビューして・改善できるリポジトリに置ける」。
実装は徹底している。エージェントのプロンプト・ツールリスト・スケジュール・認証情報・メモリまでGitリポジトリで管理し、イベント駆動型／スケジュール型という2種類のスターターテンプレートを用意。フォルダ構成もJSON設定・Markdownプロンプト・デプロイスクリプト・運用ドキュメントで標準化されている。mainブランチへのマージがそのまま自動デプロイになり、すべての変更にPR承認が必須——バージョニング・ロールバック・監査証跡がその仕組みだけで自動的についてくる。
姉妹会社Docketlyの"deliveries-as-code"はこの徹底ぶりを示す一例だ。145以上のルールセットをYAMLファイルとして管理し、絵文字リアクションをトリガーに1週間以内で改善が回る運用になっている。
この記事で一番率直なのは、Fuller氏が語る失敗談だ。「大変だったのは、AIそのものより、業務ユーザーにリポジトリのクローンやGit・プルリクエストに慣れてもらうことだった」。それでも15人の委員会は1週間で全員が動くエージェントを作り、1ヶ月で50以上に増えた。氏の助言はシンプルだ——「Gitのハードルを予期せよ、AIのハードルではなく」。
ABC Legalの規模はそのまま真似できないが、核にある設計思想は個人開発の自動化にも持ち込める。「フィードバック収集→改善案PR化→人間承認」というループは、別のAIに仕事を渡すプロンプトの書き方｜「ログの回収場所」を先に決めるで書いた「回収場所を先に決める」発想の延長であり、公開中の記事44本を壊さず一括更新する｜マーカーコメント＋dry-runの型で書いた「変更は単一の経路（マーカー＋dry-run）だけを通す」思想とも重なる。
そしてFuller氏の失敗談がそのまま効く教訓が1つ。非技術者を巻き込む自動化を作るなら、詰まるのはAIの精度より先に「変更履歴が見える形式」に慣れてもらう部分かもしれない——委任する相手が人間であれAIであれ、同じ壁が立つ。