訴状のAI下書きとは、生成AIに骨子を作らせ弁護士が仕上げる作業のことです。

準備書面1本の起案に、どれだけの時間をかけているでしょうか。この記事では、訴状と準備書面の起案に生成AIを噛ませる場合の工程と、依頼者の記録を扱うときの判断を、条文と裁判所の公表資料の範囲で整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、裁判手続の運用は裁判所の公表資料で確認しています。前提として押さえておきたいのは、裁判所が民事裁判手続のデジタル化で示している、書類の提出経路そのものが電子化されたという変化です。

提出がオンラインに寄った2026年、起案の周辺で何が動いたか

起案の中身より先に、提出の経路が変わりました。民事訴訟法第132条の10は、民事訴訟に関する手続における申立てその他の申述について、法令が書面等をもってするものと定めているものであっても、最高裁判所規則で定めるところにより電子情報処理組織を用いて行うことができる旨を定めています。書面で出すか電子で出すかの選択肢が条文上に置かれた形です。

続く民事訴訟法第132条の11は、その選択を義務の形に変えています。同条第1項は、訴訟代理人のうち委任を受けたものについて、当該委任を受けた事件の申立て等をするときは前条第1項の方法により行わなければならないと定めています。口頭ですることができる申立て等を口頭でする場合はこの限りでないという例外も同項に置かれています。弁護士が代理人として関与する事件では、提出の経路が原則として電子に寄る構造になったということです。

運用面の窓口は、裁判所が提供する民事裁判書類電子提出システム（mints）です。裁判所はmintsについてのページでシステムの概要を示し、改正民訴法等で変わる民事訴訟手続の概要で手続全体の変更点を公開しています。実務での提出手順や利用登録の流れは、これらのページと裁判所が配布する手引で確認するのが原典に近い経路です。

この変化が起案の実務に与える影響は、地味ですが大きいものです。書面が紙からファイルへ移ったことで、起案の途中生成物がファイルとして事務所内に残るようになりました。ワードの原稿、AIに投げたプロンプト、返ってきた出力、その差分。紙の時代は最終版だけが残りましたが、いまは途中の全部が残り得ます。守秘の設計を先にしないと、残るものが管理の対象から漏れていきます。

起案そのものの要求水準は変わっていません。民事訴訟法第134条は、訴えの提起は訴状を裁判所に提出してしなければならないと定め、訴状の記載事項として当事者及び法定代理人、請求の趣旨及び原因を挙げています。民事訴訟法第161条は、口頭弁論は書面で準備しなければならないと定め、準備書面の記載事項として攻撃又は防御の方法、相手方の請求及び攻撃又は防御の方法に対する陳述を挙げています。条文が求めているのは構造であって、文章の量ではありません。AIが得意なのはまさに構造の整理であり、そこに使い所があります。

訴状と準備書面をAIで下書きする5工程

工程を5つに分けます。生成AIに任せる範囲を工程単位で切ると、成果物の責任の所在がぶれません。

第1工程は、事実の時系列化です。依頼者から受け取った資料を日付順に並べ、誰が何をしたかを1行ずつに落とします。この作業はAIが速い一方で、資料そのものを入れる工程になるため、入力してよいデータの線引きが先に要ります。線引きが決まっていない事務所では、この工程はAIを使わず手作業で行い、次の工程から使い始める形が実務的です。

第2工程は、主張の骨格づくりです。時系列化した事実に対して、請求の趣旨と原因の骨組みを組み立てます。ここでAIに投げるのは、事実を抽象化した設定だけにできます。当事者を甲と乙に置き換え、固有名詞と金額を伏せ、法律関係の構造だけを渡せば、依頼者の情報を入れずに骨組みの検討ができます。骨組みの案を複数出させて弁護士が選ぶという使い方が、この工程に向いています。

第3工程は、条文と裁判例の当たりを付ける作業です。AIの出力をそのまま信じない工程として設計します。生成AIは条番号と判例の事件番号を平気で作ります。出てきた条文はe-Gov法令検索の原文で開き、判例は裁判所の判例検索で当たり、両方で確認できたものだけを起案に残します。確認できなかったものは、AIが挙げた事実そのものを捨てます。

この第3工程は、起案のなかで唯一、AIを使うほど手間が増える工程です。候補が増えれば確認対象も増えるため、時間の帳尻はここで合いません。それでも独立した工程として置く理由は、ここを潰さないと後の全工程が汚染されるからです。確認の記録は、法令名と条番号、開いた原典のURL、採否の判断を1行にまとめた一覧として事件フォルダに残します。この一覧は後の期日で自分の主張の根拠をたどるときにも使えます。

第4工程は、文章化です。骨組みと確認済みの条文をもとに文章を作ります。この工程で生成AIが効くのは、長くなりすぎた段落の圧縮、主語と述語のねじれの検出、同じ主張の重複の指摘です。文章の生成そのものより、書いた後の点検に使うほうが精度が出ます。

第5工程は、最終確認です。当事者の表記、日付、金額、証拠の番号、条文の引用を、原資料と1件ずつ突き合わせます。この工程は弁護士本人が行い、AIには渡しません。提出物の内容に対する責任は代理人にあり、その責任は工程の設計で移せるものではありません。弁護士法第1条は、弁護士が基本的人権を擁護し社会正義を実現することを使命とし、その使命に基づき誠実に職務を行うことを定めています。最終確認を人が持つという設計は、この条文の建て付けと素直につながります。

骨組みの検討に使うプロンプトの例を挙げます。固有名詞と金額を伏せ、法律関係の構造だけを渡す形にしています。

あなたは民事訴訟の起案を補助するアシスタントです。
以下は架空の事案設定です。実在の当事者情報は含みません。

【事案設定】
甲: 建物の賃借人（法人）
乙: 建物の賃貸人（法人）
経緯: 賃貸借契約の期間満了前に、乙が甲に対して明渡しを求めた。
      甲は造作について費用を支出している。
      契約書には造作の扱いについての条項がある。

次の3点を出力してください。
1. 甲が主張し得る法律上の構成を3案、それぞれの要件を箇条書きで
2. 各案について、立証が必要になる事実を列挙
3. 乙から想定される反論を各案ごとに2つ

制約:
- 条番号を書く場合は、法令名と条番号のみを示し、条文の内容は書かないこと
- 判例を挙げる場合は、事件名や事件番号を推測して書かないこと
- 断定的な結論は書かず、構成の選択肢として並べること

条文と判例の当たりを付けた後、出力の粗さを点検するプロンプトの例です。

以下は準備書面の草稿です。次の観点だけで点検し、指摘を箇条書きで返してください。

1. 同じ主張が複数の箇所で繰り返されている箇所
2. 主語と述語がねじれている文
3. 80字を超えて読みにくくなっている文
4. 事実の記述と法的評価が同じ文に混ざっている箇所
5. 証拠の引用番号が本文の記述と対応していない可能性がある箇所

やらないこと:
- 内容の当否についての評価
- 条文や判例の追加
- 文章の全面的な書き換え

【草稿】
（ここに草稿を貼る。当事者名は甲乙に置き換えたもの）

出力された指摘は、採否を弁護士が決めます。AIの出力に人の承認をどこで挟むかという設計は、AIエージェントの人間介在をどこに置くかで別の角度から整理しています。起案支援に特化したツールの選び方は法務AIエージェントの比較で扱っています。

依頼者の記録をAIに入れる前に、事務所が決める4つのこと

起案支援でもっとも重い論点がここです。訴状と準備書面の材料は、そのほとんどが依頼者から預かった情報です。

ひとつめは、入力してよいデータの範囲です。弁護士法第23条は、弁護士または弁護士であった者が、その職務上知り得た秘密を保持する権利を有し、義務を負うと定めています。同条は法律に別段の定めがある場合を除くという但し書きを置いています。この条文は、AIを使うか使わないかに関係なくかかり続ける枠組みです。実務では、当事者名と固有名詞を伏せた抽象化した設定だけをAIに渡し、原資料と証拠そのものは入れないという線を引く事務所があります。抽象化の作業を誰がやるかを決めておかないと、忙しい局面で省略されます。

ふたつめは、ツール側のデータ利用ポリシーです。確認する項目は、入力が提供者側の学習に使われるか、データの保存期間、保存先のリージョン、契約終了時の削除手順の4点です。契約プランによって扱いが変わるサービスは珍しくなく、無料プランでは改善目的の利用があり法人向けプランでは無いという設計が一般的です。ベンダーの公式ドキュメントの記述をそのまま議事録に引き写し、口頭説明だけで判断しない運用が安全側に寄ります。事務所として全所員に同じ設定を配るには、法人契約で管理者がポリシーを固定できるプランを選ぶ形が回ります。

みっつめは、依頼者への説明です。生成AIを起案の補助に使うことを依頼者に説明するかどうかは、事務所の方針として決めておく事項です。委任契約書や業務説明の書面に、業務の遂行にあたり秘密保持の措置を講じた上で情報処理の技術を利用する場合がある旨を書いておく運用例があります。書いてあれば依頼者から問われたときに即答でき、書いていなければ担当弁護士が個別に説明を作ることになります。職能団体の側の考え方を踏まえた運用の組み方は日弁連の生成AI注意事項を公開情報で読むで扱っています。

よっつめは、途中生成物の管理です。冒頭で触れたとおり、電子提出への移行で起案の途中ファイルが増えました。AIに投げたプロンプト、返ってきた出力、抽象化前の元資料が、担当者の端末やクラウドストレージに散らばります。事務所の規程に落とすなら、保存場所を事件フォルダに限定すること、AIツールに接続されたフォルダに原資料を置かないこと、事件終了時に途中生成物を削除する手順の3点が最小構成になります。所員が退職するときのアカウント処理も同じ枠組みで決めておきます。

この4点は順序に意味があります。入力範囲を決めないままツールを選ぶと、選んだ後にそのツールでは扱えないデータがあると分かり、選定をやり直すことになります。逆に範囲を先に固めておけば、ベンダーへの質問が具体化し、比較の軸が揃います。所内で意見が割れる論点でもあるため、パートナー会議の議題として1回まとめて決めてしまうほうが、案件ごとに判断するより早く収まります。

非弁行為との関係も、事務所の外向きの説明として整理しておく価値があります。弁護士法第72条は、弁護士または弁護士法人でない者が、報酬を得る目的で訴訟事件その他一般の法律事件に関して鑑定、代理、仲裁若しくは和解その他の法律事務を取り扱うことを業とすることができないと定め、この法律または他の法律に別段の定めがある場合を除くという但し書きを置いています。AIツールの提供形態がこの枠組みとどう交わるかについては議論が続いており、規制改革の文脈での動きは弁護士法72条とAIの明確化で扱っています。事務所が自分の業務にAIを使う場面と、AIサービスが利用者に法律事務を提供する場面は、論点の位置が違う点を押さえておくと説明が混ざりません。

起案でAIが起こす3つの事故と、止め方

ひとつめは、存在しない条番号と判例が草稿に残るケースです。生成AIは条番号を作り、判例の事件番号を作ります。もっともらしい形式で出てくるため、急いでいる局面ほど見逃します。止め方は、第3工程を独立させることです。AIが挙げた条文と判例を一覧に書き出し、e-Gov法令検索と裁判所の判例検索でひとつずつ開き、開けなかったものは主張ごと捨てます。この一覧を起案ファイルと一緒に残しておけば、後から検証もできます。

ふたつめは、抽象化を飛ばして原資料を貼るケースです。締切が近い局面で、担当者が当事者名の入ったままの資料をAIに貼り付けます。発覚は所内のレビューか、担当者の異動時です。止め方は、抽象化を人の作業として工程表に明記し、抽象化前の資料を置くフォルダとAIツールに接続するフォルダを物理的に分けることです。手間を挟むほど省略されるという前提で、抽象化そのものを軽くする雛形を用意しておく工夫も効きます。

みっつめは、AIの文体が混ざって書面が読みにくくなるケースです。生成AIの出力は主張を並列に並べる傾向があり、そのまま貼ると、どれが主要な主張なのかが読み取れない書面になります。止め方は、AIを文章の生成ではなく点検に使う配分へ寄せることです。骨組みと文章は人が書き、AIには重複と冗長の検出だけをさせる形が、書面の質を落としません。

よっつめとして、所内で運用が分かれるケースも挙げておきます。ある弁護士は抽象化を徹底し、別の弁護士は原資料を貼っている状態が、同じ事務所で並行して続きます。所内の誰かが事故を起こせば、事務所全体の信用の話になります。止め方は、運用を個人の裁量に委ねず、事務所の規程として1本に揃えることです。規程を作るときは、禁止事項の列挙だけでなく、代わりに何をすればよいかを併記する形にすると守られやすくなります。

4つに共通するのは、AIの精度ではなく工程の設計が原因という点です。工程を切り、どこで人が止めるかを決めた事務所では、この4つは起きにくくなります。

事故の芽を早く見つける仕掛けとしては、所内のレビューで草稿に添える一覧を義務化する方法があります。条文と判例の確認一覧が空欄の草稿はレビューに回さない、という運用にすると、確認の工程を飛ばした草稿が所内で止まります。レビュー担当の負担も、一覧があるほうが軽くなります。

費用と工数、誰が起案の最終責任を持つか

費用は、汎用の生成AIを法人プランで使う場合と、法務向けの専用ツールを入れる場合で構造が変わります。汎用AIは利用者数に比例した月額課金が中心で、所属弁護士とパラリーガルの人数で見積もれます。法務向け専用ツールは機能単位や案件数連動の課金設計が見られ、契約書レビューと訴訟起案支援で価格帯が分かれます。いずれも各ベンダーの公式料金ページで最新の金額を確認し、見積書の記載と突き合わせる運用が安全側に寄ります（参考: 各ベンダーの公式料金ページ）。

工数の変化は工程で分かれます。事実の時系列化と重複の検出は縮み、条文と判例の確認は縮みません。むしろ第3工程の確認作業は、AIを使うほど手間が増える方向に働きます。AIが多くの候補を出すため、確認する対象が増えるからです。導入の効果を測るなら、起案全体の時間ではなく工程ごとの時間で見るほうが実態に合います（参考値。事件の類型と所内の分担で変動します）。

責任の持ち主は動きません。提出物の内容についての責任は代理人である弁護士にあり、AIを使ったかどうかで変わるものではありません。事務所の運用としては、起案の担当弁護士が第5工程の最終確認を持ち、パラリーガルが第1工程と第4工程の点検を補助し、AIツールの設定と権限の管理は事務局が持つという分担が回りやすい形です。分担を決めたうえで、誰がどの工程でAIを使ったかを事件フォルダのメモに1行残す運用にすると、後から経緯を追えます。

2027年に向けて起案の何が論点になるか

論点は3つの方向に伸びます。ひとつは、電子提出の運用の定着です。提出の経路が電子に寄ったことで、書面の作り方そのものが変わっていく余地があります。裁判所の公表資料を追い、運用の変化を所内に反映する担当を決めておく余地があります。

ふたつめは、AIの利用を依頼者にどう伝えるかです。委任契約書の書き方について、日本では画一的な様式が示されていません。依頼者側の関心が高まれば、契約書の記載が実務の中で標準化していく方向が考えられます。

みっつめは、途中生成物の保存です。プロンプトと出力を残せば検証できますが、保有する秘密情報が増えます。残さなければ検証材料が消えます。方向の違う要請が同時にかかる領域で、事件終了時の削除手順を含めた設計が事務所ごとの判断になります。

よくある質問

生成AIに訴状の下書きをさせてよいですか

事務所として先に決める話です。弁護士法第23条は職務上知り得た秘密の保持について定めており、この枠組みはAIを使うかどうかに関係なくかかります。実務では、当事者名と固有名詞を伏せた抽象化した設定だけをAIに渡し、原資料は入れないという線を引く事務所があります。

AIが挙げた判例をそのまま引用してよいですか

引用の前に原典で開く工程を挟む運用が広く採られています。生成AIは事件番号や判示内容を作ることがあり、形式が整っているため見分けが付きにくいという性質があります。裁判所の判例検索で開けなかったものは、その主張ごと落とす扱いにするのが安全側に寄ります。

mintsを使う場合、AIで作ったファイルの扱いは変わりますか

提出するファイルの中身についての責任は代理人にあり、作成過程でAIを使ったかどうかで変わるものではありません。実務上の変化は、途中生成物がファイルとして残りやすくなった点です。保存場所と削除手順を事務所の規程で決める運用が求められます。

オンライン提出は代理人には義務になったのですか

民事訴訟法第132条の11第1項は、訴訟代理人のうち委任を受けたものが当該委任を受けた事件の申立て等をするときは、第132条の10第1項の方法により行わなければならないと定めています。口頭ですることができる申立て等を口頭でする場合の例外も同項に置かれています。運用の詳細は裁判所の民事裁判手続のデジタル化のページで確認できます。

準備書面の点検にAIを使う場合、何を見せればよいですか

当事者名を甲乙に置き換えた草稿までに留める運用例があります。点検の観点を重複、文の長さ、事実と評価の混在に限定すれば、内容の当否に踏み込ませずに済みます。観点を絞るほど出力が実務で使える粒度になります。

抽象化の作業自体に時間がかかります。省く方法はありますか

雛形を用意する方法があります。当事者を甲乙丙に置き換える置換ルールと、金額と日付を範囲表記に変える書式を決めておくと、抽象化が定型作業になります。作業を軽くしておかないと、締切が近い局面で省略され、原資料が入力される事故につながります。

事務所の規程には何を書けばよいですか

最小構成は5項目です。利用してよいツールの列挙、入力を禁止するデータの列挙、抽象化の担当と手順、途中生成物の保存場所と削除の時期、所員の退職時のアカウント処理です。既存の情報管理規程に条を足す形で足ります。

参考文献

• e-Gov法令検索 民事訴訟法（第132条の10、第132条の11、第134条、第161条）
• e-Gov法令検索 弁護士法（第1条 弁護士の使命、第23条 秘密保持の権利及び義務、第72条）
• 裁判所 民事裁判手続のデジタル化
• 裁判所 民事裁判書類電子提出システム（mints）
• 裁判所 mintsについて
• 裁判所 改正民訴法等で変わる民事訴訟手続の概要

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/