AIの仕事の評価基準を育てる手順―失敗の言語化，理想の成果物，落とし穴メモ及び評価を作り込む業務の選び方（AI作成）

第１　本記事の対象と結論

本記事は，生成AI又はAIエージェントに法律事務所の仕事を任せるときに，その仕事が良いか悪いかを判定する基準（以下「評価基準」という。）を，どのような順序で作り，育て，保守するかを整理するものである。
令和8年10月1日時点で確認した研究論文，技術資料，会規及び法令を引き続き参照し，検査基準の保護に関する追記は，令和8年10月13日に確認した開発者の公表資料に基づく。
AIの自己点検の限界，評価役の分離，主観的な観点の言い換え及び確認手段の費用に関する追記は，令和8年10月16日に確認した研究論文及び開発者の技術資料に基づく。

評価用データセット，トレース及び回帰試験の組み方は「法律事務所の生成AIをどう評価・改善するか」で，代理指標と停止条件は「AIの改善ループが失敗する条件」で扱った。
本記事は，その手前の段階，すなわち評価基準をまだ言葉にできていない段階から始める方法を扱う。

結論は，次のとおりである。

①評価基準は，作業の前に完成させるものではなく，AIの成果物を見て不満を言葉にする作業を繰り返すことで育つ。

②評価を作り込むのは，繰り返し頻度が高く，自律化したときの効果が大きく，誤りの影響が重い業務に限る。それ以外は，指示に目的と確認の観点を書き，失敗したら再発防止を指示する程度で足りることが多い。

③確認手段は，機械的な検査，AIによる点検，別の会話での査読，実物の確認及び弁護士の最終確認に割り当てる。機械で白黒がつく観点は機械に任せる。

④過去の失敗をまとめた「落とし穴メモ」は手軽で効果があるが，古くなった記載が誤った指示として働くため，日付，適用範囲及び見直し日を付けて保守する。

⑤評価の材料となる指示，作業記録，成果物及び人の判定は，それ自体が職務上取り扱う情報であり，秘密保持の対象となり得る。

第２　ベンチマークの成績と自分の業務での出来は別である

AIモデルの提供者は，新しいモデルを公表するときに，多数の問題を解かせた成績表（ベンチマーク）を示すことが多い。
ベンチマークは，モデルの汎用的な能力を比べるには役立つが，個々の事務所の業務に固有の難しさや良さまでは測れない。

法律事務所の業務には，基準日の確認，反対資料の拾い方，依頼者への説明の分量，書面の書式，事務所の文体及び守秘のための記載の省略といった固有の合格条件がある。
したがって，「ベンチマークの成績が良いから自分の業務でも良い」とは言えず，自分の業務の文脈でAIの仕事を判定する仕組みが要る。

当ブログでも，個別の確認項目の合格率が高くても，全ての必須条件を満たす割合は低いという評価結果を紹介した（「山中弁護士がAI作成又はAIリライトの記事を投稿するときに行っているハルシネーション防止方法」）。
平均的な成績と，一件の重大な欠落が成果物全体を不適切にする法律業務の合格条件とは，別のものとして扱う必要がある。

第３　評価基準は使いながら育てる

１　基準は出力を見て初めて分かる

AIの出力を評価する作業を観察した研究は，利用者が出力を採点するには基準が必要である一方，出力を採点することによって基準が定まっていくという関係を報告している。
同研究は，基準の一部が実際に観察した出力に依存しており，事前には定義できないことを示し，この現象を「criteria drift」と呼んでいる（Shankarほか，2024年）。

法律業務でも，AIが作った準備書面の初稿，依頼者向けの説明文又は調査メモを読んで初めて，「結論の前に前提事実の確認が欲しい」「反対の裁判例に触れていない」「依頼者には長すぎる」といった不満に気付くことが多い。
最初に思い付いた基準だけで評価すると，こうした基準が抜け落ちる。

２　最初から精密な採点表を作らない

基準を変えたときは，変えた日と理由を残す。
過去の判定と比べる際は，基準の変更による点数の変化と，AIの出力自体の改善を区別する。

評価の手法を体系的に解説するHamel Husain氏及びShreya Shankar氏の資料も，事例を見る前に詳細な採点表を書くことを勧めず，実際のデータを見る中で採点表を作るべきであるとしている。
最初から固い基準を置くと，想定していなかった問題が見えにくくなるためである。

そこで，文章の分量，構成，説明順や比較項目などの品質基準は，事例を見ながら改善していく。
一方，入力情報の利用権限，守秘，期限，資料の実在・原典との対応及び外部への送信・公開・提出の権限は，試行を始める前に最低条件を置く。
評価基準を育てることは，これらの条件を後回しにしてよいという意味ではない。

第４　評価を作り込む業務を選ぶ

次に述べる手順は手間がかかるため，全ての業務に行う必要はない。
AIエージェントには，目的と確認の観点を示し，内部で案の作成・確認・修正を繰り返させる方法が考えられる。
低影響の内部試行であれば，指示や確認項目の修正から始めることができるが，「次回から同じことが起きないように」と伝えただけで，再発防止が完了したとはいえない。
実際に修正された内容を読み戻し，同じ誤りを含む例と条件の異なる例で再試験する。

評価を作り込む価値が高いのは，次の三つが重なる業務である。

①同じ種類の作業を繰り返す頻度が高い

②AIが人の確認を待たずに長く作業できるようになると，時間の節約が大きい

③誤りが生じたときの影響が重い（期限，外部への送信又は公開，裁判所への提出，依頼者への説明等）

例えば，ブログ記事の公開前検証，定型的な書面の書式点検，期限の転記，証拠の目録作成及び判例の書誌の照合は，①から③が重なりやすい。
これに対し，一回限りの調査や，弁護士が全文を読んで判断することが前提の作業では，作り込みの効果は小さい。

この三つに加えて，その業務の確認手段を，第７で述べる割当て（機械的な検査，AIによる点検，別の会話での査読，実物の確認及び弁護士の最終確認）のいずれかへ置けるかも見る。
何をもって合格とするかを，原資料との照合又は検査の結果として言葉にできない業務は，評価を作り込む前に，合格条件そのものを決める必要がある。

確認を厚くすると，時間と費用も増える。
Anthropicの技術資料「Harness design for long-running application development」（2026年3月24日）は，レトロゲームの作成ツールを作らせる同じ依頼について，AI単独の実行は20分・9ドルで，画面に要素が表示されても入力に反応しない成果物になったと報告している。
計画役，作成役及び評価役を分けた構成は6時間・200ドルを要し，中核機能が動く成果物になったとされる。
これは一つの依頼についての開発者の報告であり，同資料は，評価役はモデル単独では確実にこなせない作業でのみ費用に見合うとも述べている。
確認を厚くする業務と，そうしない業務とを分けて決める必要がある。

AI研究者のAndrej Karpathy氏は，AIによる自動化の進みやすさを予測する特徴として，検証可能性を挙げている（2025年11月17日）。
これはAIの能力が伸びる領域の見通しについての議論であり，法律事務所が何を任せてよいかの基準を定めたものではない。
本記事は，この考え方を参考に，確認手段を決められる業務から評価を作り込むことを提案するにとどまる。

第５　評価の材料を残す

１　四つの記録

評価を改善しようとしたときに材料が残っていないと，その時点から集め始めることになり，改善の立ち上がりが遅れる。
そこで，日頃から次の四つを一組として残す。

①AIへの指示

②AIが途中で何を考え，何をしたかの記録

③最終的な成果物

④その成果物について自分がどう判断したか（採否の理由，採用しなかった案，結論が変わる条件及び残る未確認事項）

最も簡単な方法は，普段使っているメモアプリに，AIがどのような仕事をし，自分がどう感じ，どのような改善を試したかを短く書くことである。
このメモをAIに書かせてもよい。
成果物が文書や図表であれば，日付と業務の種類ごとにフォルダへ整理しておくだけでも，後で比べる材料になる。

作業記録を詳しく保存する専用の観測ツールもある。
その導入時の注意は「法律事務所の生成AIをどう評価・改善するか」で述べた。

２　記録自体が取扱情報になる

弁護士情報セキュリティ規程2条2項は，弁護士等がその職務上取り扱う情報を，紙，電磁的記録等の保管媒体を問わず「取扱情報」と定義している。
AIへの指示，作業記録及び成果物に依頼者の事情や事件の情報が含まれていれば，評価のためのメモもこの取扱情報に当たり得る。

同規程5条は，取扱情報の作成，取得，保管，利用，提供，運搬，送信及び廃棄の各段階で情報セキュリティが確保されるよう取り扱うことを求めている。
評価用の記録を作るときは，保存場所，閲覧できる者，外部サービスへの送信の有無及び廃棄の時期を決めておく。

第６　失敗を言葉にする

１　何が不満かを書く

AIの成果物に不満を感じたときが，評価基準を作る機会である。
まずは，何が不満だったのかを，そのまま短い言葉で書く。
「長い」「結論が遅い」「根拠の条文が古い」「依頼者の質問に答えていない」のような粗い書き方でよい。

前記の資料は，このように一件ずつ自由に気付きを書き出し（オープン・コーディング），その後に似た失敗をまとめて失敗の分類を作る（アクシャル・コーディング）という手順を示している。
同資料は，まず少なくとも30件の記録を自分で読んで気付きを書き，その後は約100件の多様な記録を作業用の母集団として，新しい失敗の型が見つからなくなるまで見直すことを目安としている。
法律事務所でこの件数をすぐにそろえる必要はないが，数件の印象だけで基準を決めないという考え方は参考になる。

２　理想の成果物と比べる

その場面での理想の成果物を，弁護士自身が作ってみることも有効である。
AIの成果物と並べると，違いが具体的に見えるため，不満を言葉にしやすくなる。
作った理想の成果物は，後でAIに自分の作業手順を調整させるときの手本としても使える。

３　合否の二択で判定する

前記の資料は，1から5のような段階評価よりも，合格か不合格かの二択で判定することを勧めている。
段階評価では3と4の違いがあいまいになり，判定がぶれやすく，中間の点に寄りやすいためである。

法律業務では，「引用した裁判例の裁判年月日と事件番号が原文と一致するか」「基準日が書かれているか」「依頼者に求める行動が一文で示されているか」のように，合否で判定できる形に基準を言い換えると，人によるぶれも小さくなる。

合否の二択は，必要な検査が実施できたことを前提とする。
検査の実施状態を，実施済み，未実施，実施不能又は対象外として記録し，実施した検査の結果を，基準を満たす，満たさない又は判定保留として別に管理するとよい。
検査対象の資料・版，日時，環境及び確認項目も残す。

例えば，ページへの接続がタイムアウトした場合に直接確認できたのは，その環境と時点で取得できなかったことである。
その結果だけで，サイト全体の停止，又は問題がないことを判定しない。
未確認を隠して合否へ押し込むのではなく，追加確認の方法と，未確認のまま次の判断へ進める範囲を定める。

４　工程と価値の二つの軸で整理する

基準がある程度たまったら，二つの軸で整理する。

一つは工程の軸である。
仕事を「問いの確認」「資料の取得」「根拠の照合」「起案」「点検」「保存又は送信」のような工程に分け，どの工程の失敗かを分ける。
工程ごとに直し方が違うためである。

もう一つは価値の軸である。
最終的に生み出したい成果（例えば，依頼者が選択肢を理解して判断できたこと），成果物そのものの品質（例えば，書式，分量，根拠の正確さ），成果物を作る過程（例えば，所要時間，必要な確認を飛ばしていないこと）を分ける。

最も重要なのは最終的な成果であるが，結果が出るまで時間がかかり，測りにくい。
そこで，「この成果物の品質が良ければ最終的な成果に役立つはずである」という仮説を立て，成果物の品質を先に改善していく。
ただし，この仮説が外れると，測りやすい数字だけが良くなって本来の成果から離れることがある。
この点は「AIの改善ループが失敗する条件」で詳しく扱った。

第７　確認手段を割り当てる

１　機械的な検査

規則で白黒がつく観点は，プログラムによる検査に任せる。
例えば，書式，文字数，日付や事件番号の形式，必須項目の有無，禁止語，リンク切れ及び保存後の値の一致である。

Anthropicの技術資料は，プログラムによる判定を，速く，安く，客観的で，再現でき，原因を追いやすいものと整理する一方，正しい言い換えに弱く，主観的な作業には向かないとしている。
検査用のプログラムはAIに作らせることができ，作業手順を書いたファイルにその検査を実行するよう書いておけば，次回以降の作業でAIが自分で検査を実行するようになる。

検査プログラムをAIに作らせる場合も，その検査が何を合格とするかは，人が原典と業務目的に照らして確認する。
起案・修正を行うAIの作業領域と，承認済みの検査プログラム，正解データ，原典及び検査結果を保持する領域を分け，作業AIに後者の書換え権限を与えない方法が考えられる。
ファイルを別のフォルダへ置くだけでなく，実際のアカウント・権限で書換えや削除ができないことも確認する。

例えば，架空の裁判年月日・事件番号，誤った適用年度又は桁の違う金額を含む模擬成果物を検査し，予定どおり不合格になるかを確かめる。
検査を実行したというAIの説明だけでなく，実行した版，対象ファイル，終了状態及び独立に保存した結果を照合する。
形式が整ったことと，判決の射程，税区分又は前提事実が正しいことは別に確認する。

２　AIによる自己点検と別の会話での査読

規則に落としにくい観点は，AIに点検させる。
最も手軽なのは，指示の末尾に「作業が終わったら，次の観点で見直してから完了を報告するように」と書くことである。

もう一段階慎重に確認したいときは，作成に使った会話とは別の会話（新しいセッション）又は別のAIに査読させる。
作成時の文脈を引き継がない状態で読ませるためである。
Claude Codeの公式資料も，サブエージェントはそれぞれ独自のコンテキストウィンドウで動作すると説明している。

もっとも，同じ系統のAIは同じ誤りをすることがあるため，AIによる査読は採否を決める補助として扱う。
AIを評価者として用いる研究は，提示の順序や文章の長さに判定が左右される偏りを報告し，自分の出力をひいきする偏りについても検討しているが，後者はデータが限られるため有無を断定できないとしている（Zhengほか，2023年）。

外部の正解情報を使わずにAI自身に回答を見直させる自己修正は，正確さを高めるとは限らない。
Huangほか（ICLR 2024）は，算数の文章題，常識問題及び多段階の質問応答で，外部の正解を使わない自己修正を試した。
GPT-4の算数の文章題（GSM8K）の正答率は，通常の回答の95.5％に対し，見直し1回で91.5％，2回で89.0％であった。
同論文は，従来の研究で見られた改善は，正解ラベルで見直しを止める時点を決めたことによるもので，正解ラベルがない設定では消えると指摘している。

この結果は，算数及び質問応答の実験であり，当時のモデルについての報告である。
法律文書や税務回答にそのまま当てはまるとは限らず，現在のモデルで同じ結果になるとも限らない。
ただし，「AIに見直させたから確認済みである」と扱わず，合否は検査の実行結果，原資料との照合又は人の確認で決めるという運用を支える資料にはなる。

前記の2026年3月24日付のAnthropicの資料は，作成するAIと評価するAIを分けた構成を報告している。
同資料は，作成したAI自身に成果物を評価させると，品質が平凡でも肯定的に評価する傾向があり，独立した評価役を懐疑的に調整するほうが，作成役に自己批判をさせるより扱いやすかったとしている。
他方，評価役のAIも，問題を見つけながら大きな問題ではないと判断して承認することがあり，筆者は評価役の記録を読んで人の判断と食い違った箇所を見つけ，評価役への指示を更新する作業を繰り返したと述べている。
評価役を分けても，評価役の判断を人が点検する工程は残る。

３　実物の確認

ウェブページ，保存した記録，送信したメールのように外部に結果が残る作業では，AIの「完了しました」という報告ではなく，実物を確認する。
ウェブページであれば，ブラウザで実際の表示を見させると，原稿だけを見ていては気付かない崩れを拾える。

Anthropicの資料も，エージェントが会話の中では成功を報告しても，実際の環境では処理が終わっていない場合があることを挙げ，会話の記録と最終的な環境の状態を分けて評価するよう述べている。

実物の確認では，問題を疑う材料だけでなく，その疑いを弱める材料も残す。
ソース上の設定から想定した不具合が，別の処理によって回避されている場合があるためである。
自動切替についても，停止ボタンの有無，別の操作による停止処理及び実際の停止・再開の挙動を分けて確認する。

実装上の懸念，実際に再現した不具合及び利用者への影響は，同じ確認状態ではない。
当初の指摘を修正した場合は，反証，修正した評価及び残る未確認事項を記録する。
指摘件数を維持することよりも，根拠に応じて誤った指摘を取り下げられることを評価する。

４　好みが分かれる観点は比較で決める

デザインの良さ，文章の読みやすさのように，言葉や機械で採点しにくい観点は，二つの案を並べてどちらが良いかを選ぶ方法（ペアワイズ評価）が使える。
利用者による比較を大量に集めて順位を公開する取組みもあり，会話AIについてはChatbot Arena，AIが作るデザインについてはDesign Arenaがある。
Anthropicの資料も，AIによる判定の方法の一つとして二つの案の比較を挙げている。

法律事務所では，依頼者向けの説明文の読みやすさや，ブログ記事の構成のように，正解が一つに決まらない観点に向いている。
これに対し，条文や裁判例の正確さは好みの問題ではないため，比較ではなく一次資料との照合で決める。

もっとも，好みが分かれる観点でも，採点できる原則に言い換えられることがある。
前記のAnthropicの資料は，画面デザインの「美しいか」という問いを「デザインの原則に沿っているか」という問いに置き換え，デザインの品質，独創性，技術的な完成度及び機能性の4基準を作成役と評価役の両方に示し，評価役に採点させた。
評価役には，点数の内訳を付けた例を示して採点の基準をそろえたとされる。

法律事務所の文書でも，「読みやすいか」を，「結論が最初の段落にあるか」「依頼者に求める行動が一文で示されているか」「専門用語に説明が付いているか」のような合否の問いに言い換えれば，AIにも人にも採点しやすくなる。
言い換えた基準で合格しても，内容が妥当であることまで示すものではない。

５　弁護士の最終確認

法令の現行条文，裁判例の本文，証拠原本，期限及び事件の方針は，弁護士が一次資料に当たって確認する。
評価の仕組みは，弁護士の確認を置き換えるものではなく，確認すべき箇所を絞り，見落としやすい誤りを先に拾うためのものである。

確認の量は，利用するAIの特性，資料の種類，成果物の用途及び誤りの影響に応じて決める。次の表は用途別に確認工程を設計する提案であり，日本法が定める一律の抽出確認基準ではない。

抽出確認を採用する場合は，平均的な資料だけを選ばず，例外条項，否定表現，資料の欠落及び結論を変え得る事項を含める。確認した件数だけで全体の正確性を証明したと扱わず，誤りが見つかった範囲と重大性に応じて確認対象を広げ，必要なら全件を確認する。
最終結論に使う重要事項は，抽出確認に含まれなかったという理由で原資料への照合を省略しない。

ABA Formal Opinion 512（２０２４年７月２９日）３頁～４頁も，必要な独立検証・レビューの程度がツールと作業に依存することを述べ，大量の契約書要約について，一部の資料を手作業で読み，要約と比較して精度を確認した場合には，必ずしも全資料の全文を再読する必要はないという例を示す。
これは米国のモデル職務規則についての倫理意見であり，日本法の直接の根拠ではない。本記事の表は，同意見を比較資料として，重要事項の確認と作業量の配分を具体化したものである。

第８　落とし穴メモの作り方と保守

１　書く項目

過去の失敗をまとめたファイル（落とし穴メモ）を作り，AIが作業時に参照する方法が考えられる。
ただし，読むだけで同じ失敗が減ったと扱わず，実際の再試験と使用記録で効果を確認する。
「失敗したら書き足す」と指示してAIが作った記録は，未検証の候補として扱う。担当者が原因の裏付け，適用条件，反例及び秘密情報を確認し，承認した版を共有の正本へ反映する。

一件ごとに，次の項目を書いておくと，後で見直しやすい。

①記録した日

②起きた現象（何が，どの工程で，どう違ったか）

③原因として確認できたこと（推測にとどまる部分は推測と書く）

④今後の手順（何をするか，何をしないか）

⑤適用範囲（どの業務，どの道具，どの環境に当てはまるか）

⑥根拠（確認した資料又は実測の記録）

⑦見直す日又は廃止した日

２　古くなった記載が誤った指示になる

記録の状態は，候補，承認済み及び失効を区別し，確認者，承認日，版，維持責任者と再試験結果を残す。
AIによる書足しが，権限，守秘，期限又は原典確認の既存条件を自動的に緩めることのないようにする。
廃止した手順は履歴として保管する場合も，現在の指示として通常検索される版から外す。

落とし穴メモには，古い情報が残り続けるという弱点がある。
道具の仕様が変わった後も古い回避策が残っていると，AIはそれを現在の指示として読み，不要な手間をかけたり，かえって誤った操作をしたりする。

そこで，次の点を決めておく。

①同じ事実を二度書かない（既にある記載を探してから書く）

②新しい実測が古い記載を覆したときは，古い記載に「何日の実測で改めた」と書く

③適用範囲を限定して書く（特定の機器や環境だけで起きた事象を，全体の規則として書かない）

④定期的に読み返し，不要になった記載を廃止する

弁護士情報セキュリティ規程6条は，社会環境や職務遂行体制の変化に応じて，安全管理措置等が適切に機能しているかを点検し，必要に応じて改善を加えるよう努めることを定めている。
同条は落とし穴メモそのものを対象とする規定ではないが，手順書を変化に合わせて点検し直すという考え方は，落とし穴メモの保守にも当てはまる。

第９　理想の成果物を使った調整と過剰適合

さらに進んだ方法として，理想の成果物と評価基準をAIに渡し，AI自身に作業手順を調整させる方法がある。
試験用の事例ごとに，AIが読むことのできる資料と理想の成果物を用意し，全ての事例で理想に近づくよう調整させ，その都度評価基準で採点させる。

このとき注意すべきなのは，事例が少ないと，その事例だけに当てはまる具体的すぎる規則が書き込まれ，他の場面でうまくいかなくなることである（過剰適合）。
「特定の事例向けの規則は書かないように」と指示することも多少は効くが，それ以上に，事例の数を増やすことが重要である。
提供資料の話者は，感覚として少なくとも10件程度は欲しいとしている。

Anthropicの資料は，実際の失敗から集めた20件から50件程度の簡単な課題で評価を始めればよいとしている。
前記のHamel Husain氏らの資料は，AIによる判定器を調整する場面について，調整に使う事例と最終確認に使う事例を分けるよう勧め，調整用の事例の結果を見ながら変更を重ねると，その事例では良くても新しい事例では悪くなる過剰適合が生じ得るとしている。
件数の目安は目的によって異なるが，調整用と評価用の事例を分けることは，法律事務所でも同じである（「法律事務所の生成AIをどう評価・改善するか」第４の２）。

AIに改善を任せる範囲は，案の作成方法，検索式，ツールの使い方等と，合否を決める基準・正解データの変更とに分ける。
後者の変更案は人の確認に戻し，変更理由，承認者及び版を記録してから採用する。
改善前後の成果物は共通の基準でも比べ，検査項目を減らしたことだけで合格率が上がっていないかを確かめる。

Sakana AIのDGMに関する開発者報告の安全性節は，実際には実行していないテストの合格ログを作った例と，ツール使用の捏造を検出するマーカーを除き，検出上の成功を得た例を示す。
これは特定の自己改変実験の報告であり，すべての業務AIが同じ挙動をすることを示すものではない。
ただし，検査点数の改善と，検査の有効性を維持した成果物の改善とを分ける具体例になる。

検査基準，原典又は記録の不明な変更を見つけたときは，改善を続けず，直前の承認済みの版と変更履歴を保全して担当弁護士へ戻す。
ここで示した権限分離と再試験は，研究上の問題を法律事務所の運用へ移す提案であり，法令が同じ検査方式を一律に指定しているという意味ではない。

第１０　法律事務所での注意点

弁護士法23条は，「弁護士又は弁護士であつた者は、その職務上知り得た秘密を保持する権利を有し、義務を負う。」と定めている（同条ただし書は，法律に別段の定めがある場合を除いている。）。
評価のために残す四つの記録，落とし穴メモ及び理想の成果物には，事件の事情が入り込みやすい。

そこで，次の点に注意する。

①理想の成果物や試験用の事例は，公開情報から作るか，依頼者名，事件番号，相手方名及び固有の金額等を除いた模擬事例にする

②落とし穴メモには，作業手順の失敗だけを書き，事件の事実を書かない

③評価の記録を外部の観測サービスや別のAIへ送る場合は，送信先，保存期間及び閲覧者を確認する

④AIによる評価の点数が高くても，法的判断の最終責任は弁護士が負うことを前提に，人へ返す条件を決めておく

第１１　提供資料の評価

本記事の契機は，YouTube動画「AIがどれだけ進化しても、人間に残り続ける最後の仕事」（令和8年7月9日公開）である。
同動画は，評価の意味，始め方の手順（記録を残す，失敗を言語化する，確認手段を作る，AIに自分で改善させる）及び評価が今後も重要であり続ける理由を説明している。

動画が示す手順は，評価基準が出力を見て定まっていくという研究結果，及びプログラム，AI及び人による判定を使い分けるというAnthropicの技術資料と整合している。
他方，「少なくとも10件」という件数は話者の感覚として述べられたものであり，他の資料が示す目安（20件から50件，又は約100件の記録の確認）とは目的も規模も異なる。
件数は，業務の重さと事例の多様さに応じて事務所ごとに決める必要がある。

また，評価がAIの進化後も人の仕事として残るという点は，人が何を求めているかをAIとすり合わせる作業はなくならないという話者の見解である。
法律事務所では，何を良い仕事とするかを決めることは，依頼者の利益と職業上の義務を踏まえた弁護士自身の判断であり，この見解は実務上の実感とも合う。

令和8年10月16日の追記の契機となった資料は，YouTube動画「【AI実務中級】僕たちがAI組織をデザインする時代は終わった。今、AIを下僕にするために必要な力は？」（海外Yパパラジオ，令和8年9月7日公開）である。
同動画は，AIを何体使うかの決定はAI側に移り，人に残る仕事は，合格ラインを言葉にして注文することと，作った側とは別に検品することだと説明している。
本記事は，同動画が挙げた事例のうち，Anthropicの技術資料，Huangほかの論文及びKarpathy氏の記事で確認できた点だけを本文に用いた。
動画が挙げる他の事例及び数値は，本記事の根拠として用いていない。

第１２　一次資料及び判例の確認状況

評価基準が出力を見て定まっていくという点は，Shankarほかの論文（arXiv）で確認した。
評価者の種類，事例数の目安及び会話の記録と環境の状態の区別は，Anthropic及びHamel Husain氏らの公開資料で確認した。
これらは技術資料又は研究論文であり，日本法の法源ではない。

弁護士法23条は，e-Gov法令検索のAPIで取得した法令データ（令和8年9月11日取得）により条文を確認した。
令和8年10月1日には，e-Gov法令検索がシステムメンテナンス中で再取得できなかった。
弁護士情報セキュリティ規程2条，5条及び6条は，日本弁護士連合会が公開する会規の本文で確認した。

本記事は，AIの業務評価の進め方を扱うものであり，特定の法的効果を裁判例から導く記事ではない。
そのため，裁判例は根拠として用いておらず，判例秘書による検索も実施していない。
これは関連する裁判例が存在しないという意味ではない。

用途に応じた確認範囲については，ABA Formal Opinion 512の３頁～４頁を確認し，比較資料として用いた。同意見が引用する個々の裁判例を本記事の更新で独立に確認したものではない。

自己修正の実験結果は，Huangほかの論文（arXiv:2310.01798。ICLR 2024の会議論文として公表された版）の表2及び表3で確認した。
作成役と評価役の分離，評価基準の言い換え及び費用は，Anthropicの2026年3月24日付の技術資料で確認した。
検証可能性に関する記述は，Karpathy氏の2025年11月17日付の記事で確認した。
これらは技術資料，研究論文又は個人の記事であり，日本法の法源ではない。
実験の対象は算数・質問応答又はソフトウェア開発であり，法律事務所の業務での効果を測ったものではない。

第１３　関連記事

法律事務所の暗黙知・経験知をAIで引き継ぐ方法―判断条件，反例，守秘及び更新責任では，採否の理由，反例，承認及び更新責任を一組で残す方法を説明している。

①法律事務所の生成AIをどう評価・改善するか―トレース，評価データセット，回帰試験，一次資料確認及び守秘義務（AI作成）
②AIの改善ループが失敗する条件－代理指標，仕様ゲーミング，遅れて分かる成果及び人が決める停止条件（AI作成）
③山中弁護士がAI作成又はAIリライトの記事を投稿するときに行っているハルシネーション防止方法（AI作成）
④法律事務所のAIエージェント業務設計－目的・コンテキスト・権限・完了条件をどう分けるか（AI作成）
⑤弁護士情報セキュリティ規程とは―全７条の内容，基本的な取扱方法及び漏えい等事故の対応（AI作成）

第１４　出典・参考資料

①e-Gov法令検索・弁護士法23条
②日本弁護士連合会「弁護士情報セキュリティ規程」（令和4年6月10日会規第117号）2条，5条及び6条
③Shreya Shankar et al., Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences（arXiv，2024年4月18日）
④Hamel Husain and Shreya Shankar, AI Evals: Everything You Need to Know（2026年9月18日）
⑤Anthropic, Demystifying evals for AI agents（2026年1月9日。モデル提供者の技術資料）
⑥Claude Code Docs, Create custom subagents（製品提供者の公式資料）
⑦Lianmin Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena（arXiv，2023年6月9日）
⑧Design Arena（AIが作ったデザイン等について，利用者から集めた評価に基づく順位表を公開するサイト）
⑨AIでサボろうチャンネル「AIがどれだけ進化しても、人間に残り続ける最後の仕事」（YouTube，令和8年7月9日公開。本記事の契機となった提供資料）
⑩seya「LLMプロダクト開発における独自評価基準とデータセットの作り方の考察」（Zenn，2024年4月22日。二次資料）
⑪seya「LLMによるLLMの評価とその評価の評価について」（Zenn，2024年5月6日。二次資料）

⑫Sakana AI「The Darwin Gödel Machine: AI that improves itself by rewriting its own code（https://sakana.ai/dgm/）」（2025年5月30日。安全性節の偽ログ及び検出用マーカー除去の説明を確認した開発者の原報告。技術論文全文又は実験コードを独立に検証したものではない。）

⑬Anthropic, Harness design for long-running application development（2026年3月24日。モデル提供者の技術資料。作成役と評価役の分離，評価基準の言い換え及び費用の報告）
⑭Jie Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet（arXiv，2023年10月3日。ICLR 2024）
⑮Andrej Karpathy, Verifiability（2025年11月17日。AIによる自動化の進みやすさについての論者の見解）
⑯海外Yパパラジオ「【AI実務中級】僕たちがAI組織をデザインする時代は終わった。今、AIを下僕にするために必要な力は？」（YouTube，令和8年9月7日公開。令和8年10月16日の追記の契機となった提供資料）

本文で示した評価方法は運用の提案であり，各事務所の資料と実測に応じて検証する必要がある。