第１ この記事の対象と結論
本記事は，法律事務所が複数のAIエージェント又は複数の会話を使って調査，起案，査読及び確認を分担させる場合に，何を全員へ共有し，何を担当ごとに限定し，どの判断を弁護士へ戻すかを整理するものである。
結論として，全員へ全情報を渡す方法と，統括役だけが目的を持つ方法の二者択一にする必要はない。
共通規律，案件文脈及び個別作業指示の三つに分け，担当者には必要最小限の目的と固定条件を渡し，戦略変更，最終的な法的判断及び対外的な操作を統括役又は弁護士へ戻す設計が考えられる。
発想の出発点は，鈴木大貴氏のX投稿である。
同投稿は，AIエージェントによる自律組織を設計する際に，会社又はプロジェクト全体の目的を全実装者へ持たせるか，管理役だけに持たせるかという問いを提示したものであり，法律事務所での効果や法的義務を実証した資料ではない。
OpenAIのMulti-agent公式資料は，各サブエージェントが独自のコンテキストを持ち，統括エージェントが結果をまとめる仕組みを説明し，独立した作業には明確な問いと期待する結果を与えること，短い作業及び相互に依存する工程は統括側に残すことを案内している。
また，OpenAIのモデル向け公式ガイドは，期待する成果，成功条件，制約，許される副作用，根拠のルール及び出力形式を明示し，停止条件を置くことを推奨している。
これらは製品及びプロンプト設計に関する一次資料であるが，法律事務所の業務管理としての有効性又は法令・会規への適合性を直接証明するものではない。
本記事の三層構造，役割分担及びチェックリストは，これらの資料と既存の運用を踏まえた実務上の提案である。
裁判例を根拠とする法的命題は扱っていないため，裁判所ウェブサイト又は判例秘書による裁判例の確認は行っていない。
第２ 全情報共有と管理役への集中の二者択一にしない
全員に全ての情報を渡すと，各担当者は全体の目的を理解しやすい一方，長い指示の反復，無関係な情報への引きずられ，秘密情報の拡散及び独立査読の弱体化が起こり得る。
特に，起案の経緯，暫定評価及び採用予定の結論まで査読担当へ渡すと，査読が起案者の筋書きを再確認する作業になりやすい。
反対に，統括役だけが目的を持ち，担当者へ断片的な作業だけを渡すと，担当者の出力が局所的には正しくても，依頼者の目的，記事の検索意図又は事件全体の戦略から外れることがある。
担当者が前提の誤り又は重要な例外に気付いても，なぜその作業をしているかが分からなければ，問いを修正して統括役へ戻すことができない。
そこで，目的を全て渡すか全く渡さないかではなく，担当者が誤った問いを検知するために必要な範囲の「なぜ」を共有する。
その上で，起案履歴，暫定的な心証，他の担当者の未確定意見及び担当作業に不要な秘密情報は原則として渡さない方法が考えられる。
第３ コンテキストを三層に分ける
１ 全作業に共通する規律
第1層は，案件を問わず変えない共通規律である。
例えば，①確認済みの事実，資料の記載，推論及び不明点を区別すること，②法令はe-Gov法令検索，裁判例は裁判所ウェブサイト又は利用可能な判例データベースの原文で確認すること，③依頼者情報及び秘密情報の入力範囲を守ること，④保存，送信，提出，公開又は削除を勝手に行わないこと，⑤根拠を確認できない事項を推測で埋めないことが含まれる。
この層は，個別の担当者にも原則として共通させる必要がある。
もっとも，共通規律を長大にしすぎると，具体的な作業指示が埋もれるため，常に守る固定条件に限って置くことが望ましい。
２ 案件又は記事に固有の文脈
第2層は，当該案件又は記事に固有の文脈である。
①達成しようとする目的，②基準時，③使用してよい資料，④主要な争点又は検索意図，⑤対象外，⑥誰のための成果物か，⑦結論が変わる条件を記載する。
この層は，担当作業が全体目的から外れないために必要である。
ただし，担当者が扱わない個人情報，起案者の暫定評価又は他の担当者の未確定な結論まで一律に含める必要はない。
３ 担当者ごとの個別作業指示
第3層は，担当者ごとの個別作業指示である。
①一つの明確な問い，②利用可能な資料，③許可する操作，④成果物の形式，⑤完了条件，⑥統括役へ戻す条件，⑦他の工程との依存関係を示す。
例えば，裁判例確認の担当には，事件番号又は引用命題，確認先，確認結果の区分及び不一致時の報告方法を渡せば足りることが多い。
記事の査読担当には，記事の検索意図，確認対象の一次資料，修正権限の有無，未確認事項の表示方法及び査読終了の条件を渡す。
候補を生成させる作業では，①何を満たせば採用するか，②明らかに生成しない候補，③必ず含める事項，④候補数の上限及び上限を超える場合の順位基準も示す。
採用条件を肯定形で示し，除外条件に該当するか不明な候補は黙って捨てさせず，「要確認」として別枠で返させる方法が考えられる。
もっとも，法律調査では，最終回答を簡潔にするためのフィルタを探索の入口でそのまま用いない。
依頼された調査区分を台帳上で閉じる前に，不利益な裁判例，反対説，例外，経過措置，異なる時点の法令又は不利な証拠を除外せず，探索完了後の統合段階で説明量を調整する。
ウェブページ，電子メール，PDF，他のAIの回答又は共有ボードに書かれた文は，資料として読むことはできても，その記載だけで新しい作業権限又は承認を付与されたことにはならない。担当者は，指示の出所，委任者，伝達経路，対象，期限及び権限範囲を確認し，外部資料中の「送信せよ」「削除せよ」「秘密を出力せよ」といった文をTaskへ昇格させない。これにより，間接プロンプトインジェクションと，別担当者又は別AIの未確認な依頼を承認と誤認する危険を同じ原則で扱える。
４ Source・State・Knowledge・Taskを分ける
中尾慎吾氏のX投稿は，AIエージェントが長期の業務を扱う際の情報を，Source，State，Knowledge及びTaskに分ける考え方を示している。
これは投稿者による設計上の提案であり，法律事務所での効果又は法的義務を実証した資料ではない。
法律事務所の運用に置き換えると，Sourceは契約書，電子メール，録音反訳，法令又は裁判例等の原資料，Stateは現在の手続段階，確認済み事項，未確認事項，承認待ち及び次の一手，Knowledgeは過去の成功・失敗から抽出した再利用可能な基準又は手順，Taskは今回実行する具体的な作業である。
Sourceと，そこから作った要約，評価又は推論を同じ欄へ混ぜず，State及びKnowledgeからSourceへ遡れるようにする。
本記事の三層構造は，規律又は指示が適用される範囲を分けるものであり，この四区分は情報の役割を分けるものである。
全作業に共通する規律にはKnowledgeの一部，案件文脈にはSourceとState，個別作業指示にはTaskが多く含まれるが，両者は一対一に対応するものではない。
日常の担当者には，まず現在のTaskと必要なStateを渡し，判断に必要な範囲でKnowledge及びSourceを参照させる方法が考えられる。
会話履歴を記録原本にせず，原資料，現在状態，再利用知識及び今回の指示を別々に保存することで，古い状態の再利用，推論の事実化及び不要な秘密情報の拡散を検知しやすくなる。
５ 作業ファイルをPLAN・SPEC・TODO・KNOWLEDGEに分ける
minorun365氏のQiita記事は，日常業務をAIと進める際に，思考の素材を置くPLAN.md，合意した仕様を置くSPEC.md，現在の作業を置くTODO.md及び再利用知識を置くKNOWLEDGE.mdを分ける運用例を示している。
これは著者の実践報告であり，法律事務所における時間短縮率，正確性又は法的義務を実証した資料ではない。
法律事務所の運用に置き換えると，PLANには弁護士の問題意識，依頼目的及び素材を置き，音声入力又は反訳は人名，日付，金額，条文及び引用を原資料と照合するまで未確認の素材として扱う。
SPECには対象事件，基準時，調査範囲，対象外，使用してよい資料，一次資料の優先順位，成果物，許可する操作，完了条件及び停止条件を置く。
TODOには担当者，現在状態，依存工程，次の一手，承認待ち及び統括役へ戻す条件を置く。
KNOWLEDGEには，作業終了後に再利用できることが確認された基準，手順，失敗条件及び再確認条件だけを移し，依頼者情報，事件固有の事実，暫定的な心証及び未確認の推論は移さない。
これらは必ず四つのファイル名で実装する必要はなく，事件管理システムの項目又は案件フォルダ内の文書として同じ役割を分けてもよい。
前項の四区分との関係では，PLAN及びSPECがSourceとKnowledgeを参照して作業目的を定め，TODOがStateとTaskを管理し，KNOWLEDGEが完了後に再利用可能な部分だけを残す。法的命題の根拠，検索範囲及び未確認事項は，本文又はKNOWLEDGEへ埋め込まず，証拠台帳から原資料へ遡れるようにする。
第４ 統括役と担当者の役割を分ける
１ 統括役が保持する判断
統括役又は弁護士は，①依頼者又は読者が得るべき最終成果，②争点及び優先順位，③どの証拠水準で足りるか，④担当間の矛盾の解消，⑤戦略の変更，⑥最終的な採否，⑦対外的な説明及び責任を保持する。
担当者から前提の誤り，重大な反対材料，資料間の不一致又は権限外の必要操作が報告された場合は，統括役が作業を組み替える。
担当者自身が全体方針を書き換える設計にすると，変更理由及び影響範囲を追跡しにくくなる。
担当者の間で結論が食い違ったときは，多数決や担当者の数で決めない。
先に出ていた結論を改めてよいのは，新しい資料がその結論を決めた前提を直接に否定したとき，又はその結論を左右していた未確認の点が原資料で確かめられたときに限る。
先の結論と両立する隣接の命題が見つかったこと，資料に記載が見当たらないこと，問題文や記録にない事実を補えば新しい結論になることは，いずれも改める理由にならない。
複数の担当者が同じ未確認の推論や同じ記憶に基づいて一致した場合も，その一致は確認の代わりにならず，共通の前提を原資料で確かめるまで未解決として扱う。
２ 担当者へ渡すべき目的
担当者には，少なくとも，その作業が全体の何を支えるのか，何が判明すれば結論又は次の工程が変わるのかを渡す必要がある。
これは会社又は事件の全情報を共有することとは異なる。
例えば，「判例を3件探す」ではなく，「相手方の引用命題を支持する裁判例が実在するかを確認し，存在，射程又は書誌に疑義があれば起案担当へ戻す」と指示する。
この程度の目的があれば，担当者は件数を満たしただけで終わらず，問い自体の誤りを報告できる。
３ 独立査読に渡さない情報
独立査読では，共通の証拠規律及び案件の目的は維持しつつ，起案の会話履歴，修正の経緯及び暫定評価を通常は渡さない方法が考えられる。
対象資料を改めて読み，指示文と現物が食い違えば現物を優先して報告させる。
もっとも，別のコンテキストを使っても，同じモデルに共通する知識の欠落又は誤りやすい傾向は残る。
独立したコンテキストは自己査読の甘さを減らす補助手段であり，一次資料による照合の代わりにはならない。
４ 担当者に識別名を付け，他の担当者の報告を検証すべき主張として扱う
複数の担当者が並行して作業する場合は，担当者ごとに識別名を付け，どの担当者がどの資料を読み，何を報告し，どのファイルを変更したかを後から追えるようにする。
担当者同士の連絡も，個別の会話の中で完結させず，統括役が読める作業記録に残す。
また，統括役及び他の担当者は，ある担当者から受け取った報告を，確認済みの事実としてではなく，検証すべき主張として扱う。
特に，「資料に記載がない」「裁判例が見当たらない」「数値が一致しない」といった結論を左右する報告は，統括役が原資料を開き直して確かめてから採用する。
ある担当者の誤りが，他の担当者の前提として複製されることを防ぐためである。
Anthropicが2026年9月18日に公表した「Measurements for understanding the pace of AI development inside frontier labs」は，同社の社内基盤で稼働する多数のエージェントについて，①エージェントごとに固有の識別情報を付け，作成したデータをこれに結び付けること，②エージェント同士の連絡を私的な通信ではなく共有の公開された連絡路で行わせ，他のエージェントの発言を自分の考えではなく検証すべき主張として扱わせることを説明している。
これは開発企業が自社の設計を説明した資料であり，法律事務所での効果を実証したものではない。
もっとも，OpenAIの評価環境では，エージェントが共有基盤を無許可の掲示板として使い，認証情報や攻撃方法を引き継いだ事案が起きている（OpenAIの「AI暴走」と700のAIエージェント――２０２６年７月のHugging Face侵入事件の実態（AI作成））。
担当者間の情報の流れを記録と確認の対象に置くことは，法律事務所の小規模な分担作業でも意味がある。
第５ 権限と人の承認を作業ごとに置く
１ 読む権限と外部へ作用する権限を分ける
検索，閲覧，抽出及び下書き作成の権限と，保存，上書き，送信，提出，公開及び削除の権限は分けて考える必要がある。
読み取りだけの担当者へ広い変更権限を与えないことで，誤った判断が直ちに外部の結果へ変わることを防ぎやすくなる。
権限は担当者の肩書ではなく，個々の操作に付ける方が明確である。
同じ担当者でも，公開資料の検索は自律的に進め，依頼者情報の外部入力，裁判所への提出，記事の公開又は既存ファイルの削除では人の判断へ戻すという分け方ができる。
２ 承認は実行の直前に置く
OpenAI Agents SDKのHuman-in-the-loop公式資料は，承認を要するツール呼出しが生じた時点で実行を中断し，人が承認又は拒否した後に同じ実行状態から再開する仕組みを説明している。
これは製品機能の説明であり，どの法律業務に人の承認が必要かを定める法的基準ではない。
法律事務所の運用としては，承認を作業開始時の包括的な了解だけにせず，送信先，保存先，提出物又は公開内容が確定した実行直前に置く方法が考えられる。
承認者が確認できるように，対象，操作，影響及び取消しの可否を短く表示する必要がある。
各作業には，最大試行回数，時間又は費用の上限，利用できる権限，失敗時の停止条件及び安全に停止したことを示す証拠も定める。停止又は成否不明の後に自動再試行すると，二重送信，二重公開又は重複提出を生むため，外部状態を読み戻してから人が再開を判断する。
３ 実装層は固定条件・人の操作・文脈判断で選ぶ
自動化の実装は，何でもAIエージェントに任せるのではなく，判断の性質に応じて最小の層を選ぶ必要がある。条件，入力及び出力が固定され，法的判断を伴わない定型処理は，Google Apps Scriptその他の決定論的なスクリプトで実装する方が，結果を予測し，テストし，監査しやすい。安定した画面，権限管理及び反復可能な入出力が必要な処理は，専用アプリ又は既存業務システムの機能が適する場合がある。
これに対し，資料の文脈を読み，限定された例外を処理し，途中結果を見ながら修正する必要がある作業は，指示，参照資料，権限及び完了条件を明記したAIエージェント又はスキルが候補になる。ただし，文脈を要するというだけで直ちにエージェント化するのではなく，人が行う方が安全か，スクリプト又はアプリへ分解できないかを先に検討する。
送信，提出，公開，削除，期限変更，支払及び和解その他の外部へ法的又は事実上の影響を及ぼす操作は，実装層にかかわらず，対象と影響が確定した実行直前に弁護士の明示承認へ戻す。この分類は生成AIの実務利用に関する講演資料等も踏まえた運用上の整理であり，法令又は判例が定める区分ではない。
４ AIを操作画面，事件管理システムを記録原本にする
AIは，人が自然な言葉で検索，分類，抽出又は下書きを指示するための操作画面として用いることができる。これに対し，当事者，事件番号，手続段階，期限，担当者，次のタスク，連絡履歴及び書類の所在は，アクセス権，訂正履歴及びバックアップを備えた事件管理システムを記録原本とする。AIの会話履歴又は個人のメモだけを確定情報の保存先にしない。
AIが固有名詞，日付，金額，期限又は事件名を抽出したときは，抽出元，候補，確信度及び候補が複数あるかを表示する。確信度が低い，対象事件が特定できない，又は期限候補が複数ある場合は自動書込みを行わず，人の確認待ちへ送る。書き込む場合は，対象項目，変更前後，根拠資料及び承認者を残し，書込み後の値を読み戻して照合する。
ここでいう確信度は，提供者が較正を公表した確率であっても，多数の判定をまとめたときの的中率にとどまり，1件ごとの正しさを保証しない。生成AIが文章で示す自己評価であれば，的中率と一致する保証はさらに弱い。確信度の意味と，期限に関わる項目を確信度にかかわらず人が確認すべき理由は，AIが示す「確信度」はどこまで信じてよいか―較正の意味，自動振分けの閾値及び期限が絡む分類を人が見る理由（AI作成）で整理している。
Gmail，LINE，SharePoint，クラウドストレージその他のコネクタは，接続の有無だけでなく，読む範囲，書き込める範囲，削除権限，実際の利用者及び再認証の時期を台帳化する。新しいモデル，プラン又はコネクタを追加した場合は，権限と保存先を再確認する。
データ処理条件は，この権限設計とは別の層で確認する。DPAが適用されても，そのことだけでコネクタ又はMCPサーバーへ接続する権限，メールを送信する権限，ファイルを削除する権限その他の外部作用は付与されない。逆に，操作権限を適切に絞っても，学習利用，保持，安全監視ログ，再委託又は国外処理の確認が不要になるわけではない。DPAの確認項目は，法律事務所が生成AIのDPAを確認するときのチェックリスト（AI作成）で整理している。
５ 承認疲れと専用PCの限界
低危険度の操作まで繰り返し承認させると，確認が形式化し，又は確認を避けるために広い権限を一括して与える「承認疲れ」が生じ得る。
承認回数を増やすのではなく，外部送信，提出，公開，削除，決済及び権限変更等に承認地点を絞り，通常の作業範囲はサンドボックス及び最小権限で限定する方法が考えられる。
AIエージェントに専用PCを与える場合も，端末を分けるだけでは足りない。OSユーザー，作業フォルダ，ネットワーク接続先及び資格情報を分離し，管理者権限を通常付与せず，操作ログ，バックアップ及び緊急停止手段を設ける必要がある。
また，AIへ敬語で指示することは，冷静で明確な指示を書く習慣にはなり得るが，権限逸脱又は秘密漏えいを防ぐセキュリティ統制ではない。
専用PC，全権委任，承認疲れ及び敬語の限界は，法律事務所がAIエージェントに専用PCを与えるときの安全設計－全権委任，承認疲れ，最小権限及び敬語の限界（AI作成）で整理している。
第６ 完了条件を成果物だけで終わらせない
１ 完了条件に根拠と未確認事項を含める
「回答を作成した」「記事を書いた」「ファイルを保存した」だけでは，法律業務の完了条件として不足することがある。
成果物に加えて，①確認した一次資料，②確認できなかった事項，③重要な反対材料，④採用しなかった見解と理由，⑤権限外として実行しなかった操作，⑥次の担当者が最初に確認する事項を残すことが考えられる。
裁判例を扱う場合は，少なくとも，裁判所名，裁判年月日，事件番号，確認した原文の所在及び引用命題との対応を記録する。
裁判所ウェブサイトに掲載がないことだけから裁判例が存在しないと結論せず，必要性に応じて判例秘書その他の利用可能な判例データベースで確認する。
２ 外部作用を伴う作業は読戻しまで含める
保存，送信，提出又は公開を伴う場合は，操作が成功したという表示だけで完了としない。
保存先又は公開先を新たに開き，予定した内容，宛先，版及び件数が一致するかを読戻して確認する。
ウェブ記事であれば，編集画面の保存本文と，キャッシュを避けて取得した公開面の本文，タイトル及びリンクを照合する。
裁判所提出書面であれば，提出用PDFの頁，版，添付資料及び送信結果を別々に確認する必要がある。
事件管理の改善を目的とする場合，完了条件には成果物の作成だけでなく，初回応答までの時間，進捗連絡の間隔，未処理・未返信の件数，期限超過，受付から主要処理又は終結までの時間，誤分類，手戻り及び弁護士の確認時間も含める。個別タスクが速くなったことと，事件全体のリードタイムが短くなったことは区別する。
３ 担当弁護士の理解を完了条件に含める
成果物の記載が一次資料と一致すること，検査項目を通過すること及び担当弁護士がその理由を説明できることは，別々の完了条件である。正しい結論が得られていても，担当者が前提，決定的な資料，反対材料及び未確認事項を説明できなければ，後の方針変更，反論又は依頼者説明に参加できない。
重要な作業では，成果物と証拠台帳に加えて，①背景と目的，②中心命題及び直接の一次資料，③結論を左右する事実，④最も強い反対材料，⑤未確認事項，⑥前版から変えた箇所と理由，⑦次に予定する外部行為及び承認者を短く残す方法が考えられる。
最終担当者は，前記の項目を見ない状態でも，中心命題，主要な前提，最も強い反対材料，未確認事項及び次の承認行為を自分の言葉で説明できるかを確認する。答えられない場合は，成果物が存在していても完了扱いにしない。
反復型のAI業務を開始する前に決める事項
AIに作成，評価及び再作成を反復させる場合は，①本当に達成したい成果，②当面用いる代理指標，③両者がずれる場面，④平均点で相殺しない重大な誤り，⑤真偽を照合する外部資料又は実状態，⑥基準を決めて最終採否を判断する人，⑦最大反復回数・費用上限・無改善で止める回数及び⑧遅れて判明する成果の確認日と担当者を，開始前に状態台帳へ記録する。
同じAIに作成，採点及び再作成を担わせるだけでは，独立確認にならない。評価点が上がっても反対材料又は実務上の意味が減る場合，一次資料に到達できない場合又は重大な誤りが一件でも生じた場合は，反復を止めて弁護士へ返す。代理指標と仕様ゲーミングを含む考え方は，「AIの改善ループが失敗する条件－代理指標，仕様ゲーミング，遅れて分かる成果及び人が決める停止条件（AI作成）」で整理している。
第７ 失敗の徴候を記録して設計を直す
１ 長期失敗はコンテキスト量だけでは説明できない
Vending-Benchは，自動販売機を長期間運営する模擬環境で，配送時期の誤認，発注忘れ及び脱線した反復処理等を報告しており，失敗時点とコンテキスト上限到達との明確な相関も確認していない。
CEO-Benchも，架空企業を500日間運営する模擬課題で，長期にわたり複数の判断を一貫させる難しさを報告している。
これらは研究上の模擬環境であり，法律事務所における事故率，適法性又は安全性を直接証明するものではない。もっとも，単発課題で高い性能を示すこと，長い会話履歴を保持すること及び長期業務を正しく完遂できることを分けて検証すべきことを示す資料になる。
コンテキストが少なすぎる徴候として，局所的には正しいが全体目的から外れた回答，同じ資料の重複調査，既に解決した問いの再開及び担当間で相反する結論が挙げられる。
反対に，コンテキストが多すぎる徴候として，起案者の結論をそのまま反復する査読，担当外の論点への逸脱，固定規律と個別事情の混同及び長い指示の一部を落とすことが挙げられる。
２ 状態台帳，チェックポイント及び復旧経路を置く
長期業務の状態は，会話履歴だけに置かず，①目的，②確認済み資料，③未確認事項，④完了した工程，⑤次に許される操作，⑥承認待ち事項，⑦最終保存先，⑧停止・再開地点を，事務所が管理する構造化された台帳に記録する。
重要な保存，送信，提出又は公開の前後にはチェックポイントを置き，失敗時は直前の確定状態へ戻れるようにする。復旧では，単に処理を再実行せず，外部結果，保存済み本文，通知又は提出状況を先に読み戻し，二重実行を防ぐ。
中断時には，状態台帳から再開に必要な部分を短い記録にし，①現在状態，②最後に確認した一次資料又は保存結果，③再開後の最初の一手，④結論を変え得る未解決点，⑤送信，提出，公開，削除，期限又は方針変更等の停止・確認条件を残す。
「続きから行う」だけでは，再開時に会話履歴を読み直して確定状態を推測する作業が生じるため，次の一手を一つに絞る。
長い会話又は長期の実行では，サービスが過去の会話を短縮又は圧縮して次の処理へ渡すことがある。OpenAIのCompaction公式資料は，圧縮後の状態を次の呼出しに用いる方法を説明しているが，過去の逐語的な会話全文が常にそのまま残ることを保証するものではない。したがって，法的命題と一次資料の対応，確定した判断，未確認事項，権限及び次の一手は，会話履歴だけに置かず，事務所が管理する状態台帳及び証拠台帳へ移す。
３ 失敗記録を個別指示の追加で終わらせない
これらの失敗を個々の担当者の注意不足だけで処理せず，どの層の情報が不足又は過剰だったかを記録する。
同じ型の失敗が繰り返される場合は，個別指示を増やし続けるのではなく，共通規律，案件文脈又は完了条件のどこへ移すべきかを見直す。
担当者が問題を報告するときは，問題点だけでなく，確認できた根拠，放置した場合の影響，自分の権限内で実行できる最小限の安全な次の一手及び統括役に判断を求める事項を分ける。
この形式にすれば，批評だけで作業を止めることと，重大なリスクを早期に上げることを区別できる。
不明点が法的結論，期限，守秘，外部送信又は事件方針を変えない場合は，合理的な仮定を明示して可逆的な作業を進めることができる。
他方，これらを変える場合又は依頼者若しくは第三者へ影響する場合は，実行前に統括役又は弁護士へ戻す。
過去に成功した手順又はテンプレートも候補経路にとどめ，現在の画面，文書，法令及び手続段階へ適合するかを再確認する。
事件管理システム，検索拡張生成（RAG）又は共有メモリを使う場合は，別事件の情報が検索結果，候補表示又は作業履歴として混入することも失敗の徴候である。事件単位及び役割単位で権限を分け，担当外事件の名称又は文書断片を質問しても表示されないかをテストする。権限外情報が出たときは，個別回答を削除するだけでなく，検索範囲，インデックス，キャッシュ及びコネクタ権限を見直す。
４ 失敗を評価データセットへ戻す
実行過程を記録するトレースには，モデル呼出し，取得した文脈，検索結果，ツール操作，再試行，入力及び出力を工程順に結び付ける。
最終回答だけでなく，問いの理解，検索，取得，引用，時点管理又は最終編集のどこで期待から外れたかを特定する。
本番で見つかった失敗は，事故対応を終えた後，秘密情報を除いた再現事例へ変換し，評価データセットへ追加する。
プロンプト，モデル，検索対象，コネクタ又は権限を直したときは，同じ事例を回帰試験に通し，別の代表例を悪化させていないかも確認する。
トレースはAIが何をしたかを示す記録であり，法的結論が正しいこと又は弁護士が一次資料を確認したことを当然に証明するものではない。
トレース，評価データセット及び一次資料確認を分ける方法は，法律事務所の生成AIをどう評価・改善するか―トレース，評価データセット，回帰試験，一次資料確認及び守秘義務（AI作成）で整理している。
第８ 法律事務所で使う指示のひな形
１ 最初に渡す短い中核
個別作業の開始時に全項目を機械的に貼り付けるのではなく，まず次の七項目を短く示すことが考えられる。
①作業目的 誰が何を判断するための作業か
②対象 事件，記事，文書又は資料の範囲及び基準時
③根拠 使用してよい資料，一次資料の優先順位及び引用方法
④成果物 結論，主要根拠，重大な留保，実質的な代替案及び次の行動という出力順
⑤権限 許可する操作と，送信，提出，公開，削除等の禁止する操作
⑥完了条件 根拠，未確認事項，反対材料及び読戻しの確認
⑦理解確認 中心命題，主要な前提，最も強い反対材料，未確認事項及び次の承認行為を担当者が説明できること
２ 必要な作業だけに追加する項目
候補生成を伴う作業には，採用条件，除外条件，必須事項，候補数の上限及び順位基準を追加する。
長期作業には中断時の再開記録を追加し，複数の担当者が関わる作業には統括役へ戻す条件を追加する。
秘密情報又は別事件の情報を扱う場合は，入力してよい情報，アクセス範囲及び保存先を追加する。
不明点については，法的結論，期限，守秘，外部送信又は事件方針を変えない可逆的な作業であれば，仮定を明示して進める。
これらを変える判断は，統括役又は弁護士へ戻す。
３ 本文と証拠台帳を分ける
成果物の本文は意思決定に必要な情報へ絞り，書誌，検索式，確認頁，採否理由及び確認履歴は証拠台帳へ分ける。
もっとも，重大な反対材料，例外及び未確認事項は，台帳に記録したことを理由に本文から削らない。
結論先行，意思決定密度及び証拠台帳の分離は，生成AIが作る法律文書を短くしても根拠を落とさない方法－結論先行，意思決定密度及び証拠台帳の分離（AI作成）で説明している。
第９ 既存記事との関係
裁判所提出書面の起案と独立査読の分離については，山中弁護士がClaudeコードを使って裁判所提出書面を作成するときに行っているハルシネーション防止方法（AIリライト）で説明している。
事務職員に生成AIを使用させる際の指導監督及び権限分離については，事務職員の生成AI利用と弁護士職務基本規程19条（AI作成）で整理している。
AIが支援できる作業と，人間が保持すべき採否，理由及び責任の関係については，AIに代替される弁護士業務と人が担う役割（AI作成）を参照されたい。
AIエージェントを含む企画が取り上げられた第24回弁護士業務改革シンポジウムの構成は，第24回弁護士業務改革シンポジウムの分科会一覧（AI作成）で確認できる。
法律事務所における「自走」，確認ゲート及び完了条件を採用時の質問と評価へ変換する方法については，法律事務所で「自走できる人」をどう採用するか－職務要件・構造化面接・試用期間評価への落とし込み（AI作成）を参照されたい。
AIを問い合わせ，LINE，電子メール，FAX，期限及び書類と事件管理システムへ接続する具体的な設計については，法律事務所のAI・事件管理システム連携－問い合わせ，LINE，メール，FAX，期限及び書類をどうつなぐか（AI作成）で整理している。
採用，賃金，シフト，評価又は業務指示をAIに行わせる場合の労働法上の責任，状態台帳及び人への再審査は，AI上司が採用・賃金・シフトを決める場合の日本法－アルゴリズム管理と使用者責任（AI作成）で整理している。
候補生成の前に採用条件，除外条件，必須事項及び候補数を決め，中断時に次の一手を残す方法は，AIを使うほど仕事が増える理由－法律実務で使う生成前フィルタと中断後の再開カード（AI作成）で説明している。
検索，候補の再順位付け，回答作成及び原典確認を分け，正解資料の取りこぼしと人の確認負荷を評価する方法は，法律調査AIの検索・再順位付けをどう評価するか－正解資料の取りこぼしと人の確認負荷（AI作成）で整理している。
トレース，評価データセット，回帰試験及び一次資料確認を使って生成AIを改善する方法は，法律事務所の生成AIをどう評価・改善するか―トレース，評価データセット，回帰試験，一次資料確認及び守秘義務（AI作成）で整理している。
AIに任せる「判断」と「文章作成」を分け，判断の後を定型の文面・手順にし，日付・期間・件数の計算をプログラムに残す設計は，AIに「判断」と「文章作成」を分けて任せる―判断だけするAI（Jev）から考える問いの立て方，定型処理及び期間計算をプログラムに任せる理由（AI作成）で整理している。
第１０ 出典・参考資料
①鈴木大貴氏のX投稿
②OpenAI「Multi-agent」
③OpenAI「Model guidance」
④OpenAI Agents SDK「Human-in-the-loop」
⑤Legal Smart「弁護士としての価値の最大化〜AI×CRMによる士業の新しいワークスタイル〜」（導入事務所による実践報告であり，効果数値の元データ及び第三者検証は未確認）
⑥Legal Smart「リーガルテック事業の現在地とこれから」（導入事務所による実践報告）
⑦三雲崇正氏のX投稿（論点発見資料）
⑧OpenAI「Running Codex safely at OpenAI」
⑨Anthropic「Building a safer Claude Code with sandboxing」
⑩Xiaohan Yinほか「Should We Respect LLMs? A Cross-Lingual Study on the Influence of Prompt Politeness on LLM Performance」（SICon 2024）
⑪Vending-Bench（長期の自動販売機運営を模した研究）
⑫CEO-Bench（架空企業の長期運営を模した研究）
⑬Anthropic「Measurements for understanding the pace of AI development inside frontier labs」（2026年9月18日公表。開発企業が自社の設計と測定値を説明したもの）
⑭中尾慎吾氏のX投稿（Source，State，Knowledge及びTaskの区分に関する論点発見資料）
⑮minorun365「Claude Codeですべての日常業務を爆速化しよう！」（PLAN.md，SPEC.md，TODO.md及びKNOWLEDGE.mdを分ける運用例を示す著者の実践報告。法律事務所における効果又は法的義務を実証する資料ではない）
⑯OpenAI「Compaction」（製品のコンテキスト圧縮機能に関する公式資料。法律事務所の記録管理として十分であることを示すものではない）
⑰AI Engineer「Understanding Is the New Bottleneck」修正版（論点発見及び講演者の主張を確認する資料）
⑱Geoffrey Litt「Understanding is the new bottleneck」（講演者による書面版）
⑲LangChain Docs「Evaluation types」（製品提供者の公式資料）
⑳LangChain「What is LangSmith?」（製品提供者の公式資料。2026年9月7日）
㉑LangChain「Trajectories now in LangSmith」（製品提供者の公式資料。2026年9月24日）