第１ この記事の対象と結論
１ 短くすればよいわけではない
生成AIが作る法律文書は，短ければよいわけではない。
削るべきなのは，同じ結論の反復，判断に影響しない一般論，機械的に埋められた定型見出し及び実質的な差のない代替案である。
反対材料，例外，根拠の強弱，未確認事項及び次の確認行動まで削ると，読みやすく見えても法的判断には使いにくくなる。
本記事では，読み手が判断するために必要な情報の割合を「意思決定密度」と呼ぶ。
これは法令上又は学術上の用語ではなく，本記事における業務設計上の呼称である。
以下では，本文を結論先行で短くしつつ，確認経路を失わないよう，本文と証拠台帳を分ける方法を説明する。
２ 短縮の対象と残すべき情報を分ける
生成AIが作った法律文書を短くするときは，文章量そのものではなく，読み手の判断を変える情報かどうかで採否を決める必要がある。
本文には，原則として，次の事項をこの順で置く。
①結論
②主要な理由
③結論を変え得る反対材料又は留保
④実質的な代替案
⑤未確認事項
⑥次に行う確認
同じ結論の言い換え，争点と関係の薄い背景説明，自明な長所・短所及びファイル一覧のような作業報告は，読み手の判断に必要でなければ削る。
他方，一次資料の書誌，確認箇所，検索範囲，採否理由及び確認履歴は，本文から消すのではなく，証拠台帳又は検証記録へ分ける。
本文を短くすることと，裏付けを捨てることは同じではない。
３ 実務で使う六つの順序
最初の指示は，次の六項目まで短くできる。
①目的――誰が何を判断するための文書か
②結論――現時点の推奨又は暫定結論
③主要根拠――結論を支える重要度の高い根拠
④留保――不利益資料，例外，反対説及び未確認事項
⑤代替案――結論を変え得る現実的な案だけ
⑥次の行動――誰が何を確認すれば判断が進むか
守秘，権限，保存先，判例検索範囲，引用方法又は公開確認などは，作業に応じて追加する部品とする。
全ての小作業に長い共通テンプレートを貼る必要はない。
第２ 生成AIの文書が長くなる四つの型
１ 重要度を選別せずに並べる
生成AIは，関連している事項を多数挙げることは得意であるが，読み手の判断を変える順に絞るとは限らない。
主要な根拠と周辺事情が同じ粒度で列挙されると，項目数が増えても判断は進まない。
２ 結論を最後まで遅らせる
背景，定義，一般論及び比較を順に説明した後で結論を書く型は，結論が分からないまま長い文章を読ませることになる。
法律文書でも，結論を先に置き，必要な理由をその後に示す方がよい場面がある。
ただし，結論が暫定的である場合は，その旨と結論を変え得る条件を同時に示す。
３ 定型見出しを内容の有無にかかわらず埋める
「背景」「用語」「メリット」「デメリット」等の見出しがあると，生成AIは内容が薄くても各欄を埋めがちである。
見出しは網羅性の保証ではなく，必要な情報へ到達しやすくする道具である。
その見出しを削っても判断過程が変わらないなら，削除又は統合の候補になる。
４ 実質的な差のない代替案まで両論併記する
代替案は，採否によって費用，期限，立証，リスク又は手続が変わる場合に有用である。
単なる言い換えや，現実には採り得ない案まで同じ分量で比較すると，重要な選択肢が埋もれる。
比較する場合は，判断軸を先に示し，差が見える表又は短い対比にする。
第３ 公開された比較例から確認できたこと
１ 比較の素材
検討の端緒は，take-yoda氏のQiita記事「生成AIが書いたドキュメントを読みたくない」である。
同記事は，同じカート割引の実装課題について，簡潔さを特に指示しないSkillと，結論先行，Non-goals及び不要な定型節の抑制等を指示したSkillの成果物を比較している。
本記事では，公開されているIssue #4，Before側のPull Request #5及びAfter側のPull Request #6を確認した。
２ 原資料から確認した差
GitHub上の比較対象を取得して確認したところ，Before側とAfter側の実装コード及びテストコードは同一であり，差があったのはSkillの指示文とDesign docであった。
双方のPull Requestの説明文には，24件のテストが通過した旨が記載されている。
Design docは，Before側が284行・8521文字（改行を含む。）・見出し32個であったのに対し，After側は41行・1239文字（同）・見出し6個であった。
行数及び文字数は，約7分の1である。
この比較は，同じ実装要件でも，出力の規律によって説明文の量と構成が大きく変わり得ることを示す原資料である。
３ この比較からはいえないこと
この比較は，複数の読み手を無作為に割り付けて，理解度，疲労，見落とし又は判断時間を測定した実験ではない。
したがって，文章が約7分の1になれば読解の負担も同じ割合で下がる，法律文書でも同じ効果が出る，又は四つの型が疲労の原因であると実証された，とはいえない。
また，Pull Requestの本文は後日編集され得る。
公開ページの現在の文字数と記事掲載時の数値が一致しない場合があるため，本記事では，取得した比較対象のDesign docとテスト結果を中心に扱う。
第４ 法律文書で削ってよいもの，削らないもの
１ 削除又は統合の候補
削除又は統合の候補は，次のとおりである。
①同じ結論を見出し，冒頭，段落末及び小括で言い換えた反復
②争点との接続が示されていない一般論
③根拠のない評価語を重ねた文章
④実質的な差のない代替案
⑤意思決定者に不要な作業ログ又はファイル一覧
⑥本文にない内容を補うためだけの定型見出し
２ 短縮時にも残す事項
短縮するときにも，次の事項は残す。
①結論の前提となる重要事実
②適用条文，基準時及び経過措置
③結論に不利な裁判例，反対説，例外及び証拠
④根拠の強さ及び確認の程度
⑤確認できなかった事項及び検索範囲
⑥期限，停止条件及び人へ戻す判断
とりわけ裁判例調査では，候補数を絞ることと不利益裁判例を隠すことを混同してはならない。
重要な反対材料は通常候補の件数上限とは別枠で表示し，裁判所ウェブサイトに見当たらないことだけから不存在と結論しない扱いが必要である。
第５ 本文と証拠台帳を分ける
１ 本文の役割
本文は，読み手が判断するための画面である。
結論，主要根拠，重大な留保，実質的な代替案及び次の行動を，重要度順に示す。
証拠台帳に情報があることを理由に，本文から重大な反対材料を消してはならない。
２ 証拠台帳の役割
証拠台帳には，少なくとも，主張又は確認事項，資料名，発行主体，日付又は版，該当頁，原文確認の有無，確認手段，反対材料，未確認事項及び最終確認日を記録する。
裁判例であれば，裁判所名，裁判年月日，事件番号，本文の所在及び引用命題との対応を加える。
AIの回答，検索結果の断片，解説記事又はSNS投稿は，論点発見には使えても，それだけで法的命題の裏付けにはならない。
本文に採用する前に，法令，裁判例本文，公的資料又は原著等へたどる。
３ 本記事の裏付けの範囲
本記事は，生成AIの出力設計と公開されたソフトウェア比較を扱うものであり，特定の法令解釈又は裁判例の判旨を主張するものではない。
このため，e-Gov法令検索，裁判所ウェブサイトの裁判例検索及び判例秘書による判例検索は実施していない。
これは，関連する裁判例が存在しないことを意味しない。
第６ 生成AIへの短い指示例
１ 法律調査メモ
法律調査メモを作らせるときは，例えば次のように指示する。
「最初に暫定結論を示し，次に結論を支える主要な一次資料を重要度順に示してください。
不利益な裁判例，反対説，例外，経過措置及び未確認事項は削らず，通常候補とは別枠にしてください。
同じ結論の反復，争点と関係の薄い一般論及び実質的な差のない代替案は省いてください。
本文は意思決定用に短くし，書誌，検索式，確認頁及び採否理由は証拠台帳へ分けてください。」
２ 裁判所提出書面のレビュー
裁判所提出書面のレビューでは，例えば次のように指示する。
「指摘は，①提出前に必ず直す事項，②実質判断を要する事項，③表現上の改善の順にしてください。
各指摘について，原文の逐語引用，該当頁，根拠資料，放置した場合の影響及び最小限の手直し案を示してください。
確認できない事項は推測で補わず，未確認と表示してください。
同じ結論の言い換え及び争点と関係の薄い一般論は，指摘件数に含めないでください。」
３ ブログ記事
ブログ記事では，例えば次のように指示する。
「冒頭に，読者の疑問に対する結論，資料の性質及び裏付けの限界を置いてください。
削除しても結論又は判断過程が変わらない見出しは設けないでください。
本文にない断定をAI要約へ追加しないでください。
一次資料，原典，論点発見資料及び筆者の提案を区別してください。」
第７ 短縮の効果を測る
１ 文字数だけで評価しない
測定の候補は，次のとおりである。
①本文の文字数
②結論へ到達するまでの文字数
③主要な判断材料の数
④重複箇所
⑤不要箇所
⑥重大な欠落
⑦一次資料の確認時間
⑧読了又はレビューの時間
⑨修正後の手戻り
短くなっても重大な反対材料の欠落が増えたなら，成功とはいえない。
逆に，証拠台帳が長くても，本文から必要な根拠へ到達しやすく，本文の判断経路が明確であれば，総文字数だけで失敗とはいえない。
２ 一つの例を一般化しない
前記の比較は，Skillの変更と成果物の差を追える点で有用であるが，一つの公開例にとどまる。
法律事務所で採用する場合は，同種の文書について，重大な欠落，不要箇所，確認時間及びレビュー時間を導入前後で記録し，自らの業務で確かめる必要がある。
第８ 既存記事との関係
候補を作る前の件数制御及び中断後の再開記録は，AIを使うほど仕事が増える理由－法律実務で使う生成前フィルタと中断後の再開カードで説明している。
本記事は，候補を作った後に，本文を意思決定用へ圧縮する工程を扱う。
目的，コンテキスト，権限及び完了条件の分け方は，法律事務所のAIエージェント業務設計－目的・コンテキスト・権限・完了条件をどう分けるかで整理している。
裁判所提出書面における，確度と重要度による指摘の分類，生成AIに特有の型の点検及び手直し案の逐語照合は，山中弁護士がClaudeコードを使って裁判所提出書面を作成するときに行っているハルシネーション防止方法を参照されたい。
裁判所内部の文書作成について，平易かつ簡潔な表現，決裁事項の明確化及び案件ごとの記載量の判断は，司法行政文書の書き方（９訂）の解説で扱っている。
第９ 出典・確認資料
１ 論点発見資料
take-yoda「生成AIが書いたドキュメントを読みたくない」（Qiita）（比較の解釈及びSkill設計に関する執筆者の説明）
２ 比較の原資料
Taketo-Yoda/Qiita Issue #4（比較課題の要件及びNon-goals）
Taketo-Yoda/Qiita Pull Request #5（Before側）
Taketo-Yoda/Qiita Pull Request #6（After側）
３ 公的資料
文化審議会「公用文作成の考え方」（令和４年１月７日建議）
最高裁判所事務総局秘書課「司法行政文書の書き方（９訂）」（令和６年１２月）