実務ブリッジ — 知財 × エージェント設計
MOKUMOKU GUIDE
MOKUMOKU GUIDE ・ 実務ブリッジ

設計パターンを、
知財実務に接続する

Anthropic「Building Effective Agents」の 7 つの型のうち、04 オーケストレーター & ワーカー05 評価者 & 最適化者は、我々にとって理論ではない。特許の品質分析パイプラインで、すでに手を動かして回している構造だ。抽象パターンと現場実装を、一枚ずつ重ねていく。

元記事「効果的なAIエージェントの作り方」に戻る

パターンを「知っている」ことと、自分のドメインで動かしていることの間には距離がある。この距離を詰めた分だけ、パターンは武器になる。以下は、特許実務という具体ドメインで 04 と 05 がどう立ち上がるか——そして 05 の核心にある「作る側」と「評価する側」の非対称性が、なぜ効くのかの記録。
01 / 04 Orchestrator-Worker

オーケストレーターが、その場で仕事を割り振る

元記事の 04 は「中央 LLM が入力に応じて動的にタスクを分解し、ワーカーへ委任、結果を統合する」型。破線=実行時に決まる、が肝。特許品質分析では、これがそのまま骨格になる。

記事の型
中央 LLM が動的に分解 → ワーカー群へ委任 → 統合。手数は事前に決めない
現場の実装
1 件の特許を入れると、請求項の構成要素を起点に「どの要素をどこまで調べるか」をオーケストレーターがその場で分解し、専門ワーカーへ配る。
特許 Orchestrator 専門家 ×N(並列) 批判役(DA) 精緻化 統合 Report — — 破線=実行時に割当が決まる

請求項要素で動的に分解 → ティア別ワーカーへ委任 → 上位モデルで統合

並列化との違い

形は「並列化(03)」に似ているが、決定的に違うのは柔軟性。調べる要素・攻める観点・掘る深さは入力の請求項次第で毎回変わる。オーケストレーターが実行時に配分を決めるから、手数を予測できない案件に耐える。

なぜワーカーを「階層化」するか

全部を最上位モデルに投げると高くつく。広く速い一次探索は廉価モデル、攻めと精緻化は中位、最終統合だけ上位——役割にコストを合わせると、品質を落とさずに費用を大幅圧縮できる。

Tier 1 ・ 広い一次探索
廉価・並列
複数の専門家役を同時に走らせ、請求項要素と先行技術の当たりを広く取る。
Tier 2 ・ 攻めと精緻化
中位モデル
批判役(Devil's Advocate)が弱点を突き、別ワーカーが論点を詰める。
Tier 3 ・ 統合
上位モデル
ワーカーの結果と証拠を束ね、判断とレポートに落とす。ここだけ最上位を使う。
メタ・オーケストレーション

もう一段上の応用として、安価なモデルに「作業スクリプトそのもの」を書かせ、親プロセスが実行するやり方がある。オーケストレーターが指示だけでなく手続きを生成し、実行は別レーンに委ねる——大量バッチをコストを抑えて回すときの定石。

02 / 05 Evaluator-Optimizer

生成と評価を、別々の役に分けてループさせる

元記事の 05 は「一方が生成し、もう一方が評価とフィードバックを返す」型。人の推敲プロセスに似たループ。特許実務では、これが Reflexion(反省ループ)対戦検証の二段構えになる。

請求項 生成役 評価役 確定 飽和→Accept

生成役 ⇄ 評価役のループ。評価役が「これ以上は変わらない(飽和)」と判断したら確定

Reflexion — 反省を回す

生成役が請求項の解釈や主張を作り、評価役が「その解釈、ここが甘い」と批評を返す。これを複数ラウンド回すと、単発の出力より確実に精度が上がる。元記事の適合サイン——①言語化された批評で出力が良くなる ②モデルがその批評を出せる——を、特許論点はきれいに満たす。

停止も、評価役が決める

肝は「いつ止めるか」。証拠が積み上がり、これ以上ラウンドを回しても結論が変わらない飽和を評価役が判定して打ち切る。元記事の「さらに検索すべきか評価者が判断する」——それを特許調査でやっている。

二段目:対戦検証(Battleground)

Reflexion で磨いた論点を、今度は役割を割り当てた三者でぶつける——審査官役が拒絶で攻め、出願人役が反論し、判定役が評決する。生成と評価の非対称を、疑似的な審査プロセスとして立ち上げる構造。単なる「良し悪し判定」より、実務の勝ち負けに近い出力が得られる。

03 ・ 核心

なぜ「作る側」と「評価する側」を分けると効くのか

05 の本質は「ループ」ではなく非対称性にある。生成役と評価役は、そもそも最適化している目的関数が違う。だから別々の誤りを捕まえる。ここが、自分の業務に移すときに一番効く洞察だ。

CREATOR 作る側

目的は「もっともらしい成果を生む」こと。文脈に沿い、筋の通った出力を作る方向に最適化される。だが自分の前提の穴・見落とした先行技術・希望的観測には構造的に気づきにくい。作った本人が自分を採点しても、同じ盲点を持ち越す。

REVIEWER 評価する側

目的は「粗を見つける」こと。成果を守る立場を持たず、反証・弱点・反例を探す方向に最適化される。作る責任から解放されているからこそ、創作者には見えない失敗モードを突ける。批判が仕事なので、遠慮なく攻められる。

運用原則に落ちている

この非対称性は、日々のエージェント運用のルールそのものだ——「執筆(writer)パスと検証(verifier / reviewer)パスは別レーンにする。同一コンテキストで自己承認しない」。同じ文脈のまま「作って、自分でOKを出す」と、創作時の盲点がそのまま検証をすり抜ける。だから承認は必ず別の役・別のパスに渡す。特許の品質分析で評価役やDA・審査官役を分離するのも、コードのレビューを作者と別レーンにするのも、根は同じ一つの原理だ。

失敗の形

非対称を崩すと何が起きるか——自己レビューの追認。生成役に「これで良い?」と聞けば、多くは「良い」と答える。目的関数が「作る」に寄ったままだからだ。評価を意味あるものにするには、役・プロンプト・(可能なら)モデルまで分け、"反証せよ" と敵対的に振る必要がある。

04 ・ 実務者への含意

自分の知財 / リーガル業務にどう移すか

特別なツールがなくても、この二つの型は今日の業務に移植できる。要点は「動的に分ける」「別の役で評価する」の二つだけ。

1

タスクを「請求項要素」や「論点」で動的に切る

案件を丸ごと一発で投げず、構成要素・争点ごとに分解して配る。分解の粒度は案件次第で変えてよい——それがオーケストレーター型の柔軟性。

2

コストを役割に合わせて階層化する

広い一次調査は速く安いモデル、攻めと精緻化は中位、最終判断だけ上位。全部を最上位でやらない。

3

生成と評価を、別の役として分離する

草案を書いた本人・同一文脈に承認させない。批評役・DA・レビュー役を立て、"反証せよ" と敵対的に振る。ここを分けた瞬間に品質が変わる。

4

「いつ止めるか」を評価側に判断させる

ラウンドを回しても結論が動かない=飽和を評価役に検知させ、そこで打ち切る。無限に磨かず、証拠が固まった時点で確定する。

抽象パターンは、ドメインに接地して初めて武器になる。04 と 05 は、特許実務ではすでに動いている——請求項要素で動的に分け、作る役と評価する役を分離し、飽和で止める。同じ骨格は、契約レビューにも、明細書ドラフトにも、先行技術調査にも移せる。作る側と評価する側を、意識して別にする。それだけで、出力の信頼度は変わる。