◯本ブログ記事は専らAIで作成したものであり，実際の画面と公式文書（準備の手引・FAQ・操作マニュアル）を突き合わせ，具体的な根拠に基づいて，民事裁判書類電子提出システム「mints」を「一つのWebシステム」として論評するものです。
◯以下の記事も参照してください。
・ （AI作成）mintsの実務解説 弁護士が抱きそうな疑問に答える
・ （AI作成）mints操作マニュアル～当事者ユーザ編～の解説
・ （AIリライト）最高裁判所が開発しているmints，RoootS及びTreeeS
第1 はじめに―本稿の視点と検討対象
1 mintsを「システム」として論ずる理由
mintsについての解説は，多くが「操作手順」を説明します。本稿は視点を変え，mintsを一つのWebシステムとして，その設計思想の妥当性を論じます。手順の暗記でつまずきを回避するのではなく，なぜつまずくのか，どう設計されていれば負担が小さかったのかを，専門の視点から明らかにするためです。
2 検討の三つの視点
本稿は次の3つの視点を用います。第1に，利用者の目的達成のしやすさを見るUI/UXの視点。第2に，画面がWeb標準・ブラウザの作法に沿って実装されているかを見るフロントエンドの視点。第3に，情報や導線が見つけやすく整理されているかを見る情報アーキテクチャ（IA）の視点です。
3 公平を期すための留保
はじめに公平のために述べます。mintsは，訴訟記録の不可変性・非改ざん性という司法固有の要請の下で構築されており，後述する「修正のしにくさ」の一部はUXの失敗ではなく意図した設計です。また，全国の裁判所に短期間で展開する制約や，将来システム（TreeeS）への移行を控えた過渡的実装であることも考慮すべきです。本稿の指摘は，こうした制約を踏まえてもなお改善が可能で，かつ法的制約とは無関係な領域に絞った建設的なものです。
第2 mintsの法的骨格（条文の明示）
UXの重要性を論ずる前提として，弁護士がmintsの利用をどの範囲で義務づけられるのかを，法令名と条番号を明示して確認します。
1 電子情報処理組織による申立て（民訴法132条の10）
民事訴訟法132条の10第1項は，書面等ですべきものとされている申立て等を，最高裁判所規則で定める電子情報処理組織を使用してファイルに記録する方法で行うことができる旨を定めます。その到達時期は「ファイルに記録された時」です（同条3項）。これがmintsという電子申立ての一般的な根拠規定です。
2 訴訟代理人等の電子申立て義務（民訴法132条の11）
そのうえで，民事訴訟法132条の11第1項は，一定の者に電子申立てを義務づけます。すなわち，同項1号は「委任を受けた訴訟代理人」を，同項2号は国の訟務に関し法務大臣の指定を受けた者を，同項3号は地方自治法153条1項の委任を受けた職員を挙げ，これらの者は132条の10第1項の方法によらなければならないと定めます（口頭でできる申立てを口頭でする場合を除く。同項ただし書）。もっとも，裁判所の使用する電子計算機の故障その他その責めに帰することができない事由で利用できない場合には，この義務は適用されません（同条3項）。
以上を論理的にたどると，委任を受けた弁護士は，原則としてmintsを用いて申立てをする法的義務を負い，紙による提出は原則として不適式となる，という帰結になります（例外は口頭申立て及びシステム障害等）。
3 全面施行日と「なぜUXが重要か」
この義務は，改正民事訴訟法の全面施行日である令和8年5月21日から動き始めます。ここに本稿の核心があります。すなわち，弁護士はmintsを「選んで使う」のではなく「使わされる」立場にあります。利用者が離脱できない captive な設計である以上，使い勝手の巧拙は個人の慣れの問題に矮小化できず，公的サービスの品質そのものとして評価されるべきなのです。
第3 評価その1―UI/UX
1 入力フォームの設計
(1) 「被告の数」の二重入力
新規申立てフォームは4つのタブ（当事者・代理人情報／申立内容／添付書類／参考事項）に分かれます。ここで注意を要するのは，「申立内容」タブにある「被告の数」欄が，「当事者・代理人情報」タブの当事者入力と連動しない独立の手入力欄になっている点です。当事者欄に被告を入れ忘れても，「被告の数」だけで手数料が算定され申立てが通ってしまうため，被告の表示漏れに気づきにくい構造になっています。
ア 同じ情報を2か所に別々に入力させる設計は，一方だけを直したときに不整合を生みます。UXの基本原則である「エラーの予防」に照らすと，被告の数は当事者欄から自動集計されるのが望ましい設計です。
(2) 自動保存の不在とデータ消失
フォームには自動保存がありません。手動で「保存」ボタンを押さないまま画面を移動すると，入力内容は失われます。長文の訴状フォームを作成中に不意に離脱すれば，作業が丸ごと消えるおそれがあります。
ア 現代のWebアプリケーションでは，サーバ側で下書きを自動保存し，データ消失の責任を利用者の「こまめな保存」に帰さないのが標準です。mintsにはサーバ側の手動保存（一時保存）がある点は評価できますが，これを自動化すれば負担は大きく減ります。
(3) 入力の正規化をユーザーに転嫁する設計
mintsは，全角と半角をフィールドごとに厳格に要求し，氏名欄では「氏名の間に全角スペースを入れてください」と利用者に整形を求めます。また，申立ての趣旨・理由の欄にタブ文字が混ざると「使用できない文字」としてエラーになり，別途PDFでの提出を強いられます（この不具合はmints自身も告知しています）。
ア 本来，全角・半角の違いやタブ・前後空白は，システム側が受け取ってから自動的に整える（正規化する）のが適切です。ワープロからの貼り付けで容易に起きる問題を，そのまま利用者の負担にしている点は，改善の余地が大きい設計です。
(4) 手数料の手入力と不適切な既定値
「申立内容」タブでは，訴額を入力しても手数料が自動計算されず，手数料は手入力欄になっています。また，提出先種別の初期選択が「高等裁判所」になっており，訴え提起の既定としては不自然です。訴額欄も「1万円未満は切り上げて入力」と，端数処理を利用者に委ねています。
ア 金額の算定はシステムが最も得意とする処理です。訴額から手数料を自動計算し，初期選択を最も多い提出先に合わせるだけで，誤りと手間の双方を減らせます。
2 一覧・テーブルの設計
(1) 列見出しの折り返し
記録一覧・手数料納付情報一覧・アカウント設定の添付ファイル一覧などのデータ表では，列の幅が狭すぎて，見出しの語が1文字ずつ縦に折り返されます。たとえば「アップロード者」が縦一列の7文字に，「収納機関番号」「確認番号」も縦一列に割れて表示され，見出しが単漢字の塊になって読み取りにくくなっています。
ア これは列幅と折り返しを制御するスタイル指定が破綻している状態で，比較的低コストで直せるフロントエンドの課題です。列数の多い表ほど影響が大きく，実務での可読性に直結します。
(2) 横方向のはみ出しと無名の列
事件一覧の画面では，「未印刷物一括印刷」ボタンが右端で見切れ，横方向のスクロールが生じます。固定幅のレイアウトが画面幅に収まっていないためです。また，同じ表には，見出しの語がなく絞り込み・並べ替えのアイコンだけがある列も存在し，何の列か分かりにくくなっています。
(3) ステータス表示の曖昧さ
提出ファイルのステータスには「全員閲覧済」「一部閲覧済」といった表示があります。しかし，ここでいう「全員」は，その事件にmintsで関連付けられた利用者に限られます。相手方が招待キーで関連付けられていない段階では，実際には相手方が見ていなくても「全員閲覧済」と表示され得ます。送達や直送の効力を判断する場面では，表示そのものではなく，誰がいつ閲覧したかの実体（アクセス状況）を確認する必要があります。
3 取り返しのつかない操作の設計
(1) 「提出」ボタンの視覚的無階層
新規申立てフォームの上部には「保存」「申立ダウンロード」「プレビュー」「提出」の4つのボタンが，同じ大きさ・同じ配色で横一列に並びます。日常的に押す「保存」と，取り返しのつかない「提出」とが視覚的に同格で，見分けがつきにくくなっています。
ア 不可逆な操作は，色や大きさで区別し，実行前に確認の一手間（確認ダイアログ）を挟むのがUXの定石です。誤送信の予防という観点から，最も優先度の高い改善点の一つです。
(2) 提出後の修正不可・削除不可
いったん提出すると，当事者は自分でファイルを削除したり書面種別を変更したりできず，担当書記官への連絡で対応することになります。この硬直性は，UX単独で見れば「取り消しの自由」の欠如ですが，訴訟記録の不可変性という法的要請に根ざす側面があり，一概にUXの失敗とはいえません。妥当な批判は「不可変性は保ちつつ，提出前の確認を厚くせよ」という方向にあります。
(3) アカウント削除の配置
アカウント設定の画面では，日常的な項目と同じフォームの中に，赤色の「アカウント削除」ボタンがインラインで置かれています。危険な操作は，通常操作から物理的に離し，誤操作を招きにくい配置にすることが望まれます。
4 認証・ログインの設計
(1) 二要素認証の＃押下と機種依存
二要素認証で「電話する」を選ぶと，音声案内に従って「＃」ボタンの押下を求められます。もっとも，公式FAQ自身が，利用する電話機によっては＃を押しても正常に認証できない事象が確認されている旨を認めています。システムへの入口である認証に機種依存の不達リスクがあることは，可用性の観点から軽視できません。
(2) 引き継がれない認証セッション
mintsの認証は，ウィンドウ単位でしか保持されない方式のようで，同じブラウザでも別のウィンドウやタブにはログイン状態が引き継がれません。トップ画面のアドレスを直接開いても，別ウィンドウでは未サインインの状態に戻ります。複数の画面を並行して開いて作業したい実務では，扱いにくい挙動です。
第4 評価その2―フロントエンドとWeb標準
1 ブラウザの作法との不整合
mintsは，ブラウザの「戻る」「進む」の使用を禁止しています。Webアプリケーションが土台であるブラウザの基本操作と衝突する設計は，利用者の自由を損なう典型的なつまずきの原因です。履歴移動に耐える画面遷移の設計が望まれます。
2 リンクとボタンの実装不統一
サインイン前のトップ画面では，主要な案内ボタン（操作マニュアル・FAQ・利用規約など）が，リンクではなくスクリプトで動くボタンとして実装されており，新しいタブで開いたりキーボードやスクリーンリーダーでリンクとして扱ったりできません。一方，同じ画面の右側の案内は通常のリンクで作られています。同一画面でリンクの作り方が統一されていない点は，アクセシビリティと操作性の双方に影響します（サインイン後のサイドバーは通常のリンクで統一されており，こちらは良好です）。
3 レスポンシブ非対応
画面は固定幅を前提としており，画面幅に応じて配置が変わるレスポンシブ設計になっていません。前述のボタンの見切れや列見出しの折り返しは，この固定幅前提と表裏一体です。
4 プラットフォーム依存
mintsは対応環境をWindowsのEdge又はChromeに限定しています。セキュリティ上の理由は理解できますが，「どの環境からでも使える」というWeb本来の思想からは距離があります。多様な環境の利用者を想定した公的システムとしては，対応環境の広さも品質の一部です。
第5 評価その3―情報アーキテクチャ
1 ヘルプ体系が静的PDFの集合であること
mintsのヘルプは，操作マニュアル・FAQ・利用規約・「初めてご利用の方へ」などが，いずれも別タブで開く静的なPDFとして提供されています。画面の文脈に応じたヘルプや，横断的に検索できるヘルプセンターはありません。目的の答えに辿り着くには，複数のPDFを人手で探すことになります。
2 唯一の対話的ヘルプが外部サービスであること
唯一の対話的なヘルプはチャットボットですが，これは第三者が提供するサービスで，裁判所のドメインの外に置かれています。しかもFAQのPDFには「一定時点でチャットボットに登録している内容を一覧にしたもので，以後の修正には対応していない。最新はチャットボットで確認」との注意書きがあり，実質的な正典がチャットボット側にあってPDFは陳腐化しうる構造になっています。権威ある一次情報が外部サービスの中にある状態は，IAとして健全とはいえません。
3 「ご案内」欄における重要警告の埋没
トップ画面の「ご案内」欄は，数年分の更新履歴を一つの小さなスクロール枠にまとめて表示しています。その結果，いま注意すべき警告（たとえば「マイナンバーカードをアップロードしない」「アップロードの反映が遅れるので重ねて投稿しない」）が，古い履歴に埋もれています。「いま行動を要する情報」と「過去の記録」を分ける情報設計が望まれます。
4 ナビゲーションの重複と単一正典の不在
トップ画面では，左側のボタン群と右側のリンク群という2つの案内が並存し，「初めてご利用の方へ」のように両方に重複して現れる項目があります。また，同じ事実（提出できるファイル形式，容量上限，用紙サイズなど）が手引・FAQ・マニュアルに重複して書かれ，どれが最新・正なのかを利用者が判断させられます。横断的な用語集や相互参照を備えた単一の正典が求められます。
第6 付随文書（ドキュメント）の妥当性
システムの評価に付随して，3つの公式文書自体の妥当性にも触れます。
1 準備の手引
「民事訴訟フェーズ3に向けた準備の手引」は，アカウント登録から執行・秘匿までを時系列の章立てで俯瞰させる概念資料として，よくできています。手続の全体像を1枚で示す図や，マスキング・提出場所などのつまずきを先回りする配慮も見られます。
他方，詳細を操作マニュアルに委ねるため単独では完結せず，スライド形式ゆえにPDFの読み上げ順序（機械可読性）が弱い点は課題です。
2 FAQ（Q&A）
3文書の中で設計が最も弱いのがFAQです。実体はチャットボットの登録データを平坦に書き出した一覧表で，読み物として設計されていません。
さらに，本来リンクだった箇所の語（「こちら」「裁判所ウェブサイト」など）が文中から剥がれて各ページの末尾に散在し，リンク先が辿れないまま文が途切れています。目次も索引も検索性もなく，参照資料としての使い勝手に難があります。
3 操作マニュアル
「操作マニュアル～当事者ユーザ編～」は，目次が階層化され，章番号と頁が対応し，画面写真で手順を追える正統な手順書で，3文書の中では最も完成度が高いといえます。
もっとも，画面写真中心の124頁は，頻繁な画面改修に伴って陳腐化しやすく，改訂コストが高いという構造的な弱みがあります。
4 三文書に共通する課題
3文書に共通するのは，第5の4で述べた「単一の正典の不在」です。内容が重複するため版ずれや表記の揺れが生じやすく，実際に，証拠の枝番の区切り文字がハイフンとアンダースコアで文書間で食い違うといった不一致も見られます。利用者が「どれを信じるか」を判断せずに済むよう，正典を一本化する情報設計が望まれます。
第7 公的システムに期待される水準との対照
以上の課題は，専門家の主観ではなく，公表されている公的な基準や国際的な経験則に照らして評価できます。
1 デジタル庁デザインシステム
政府自身が，アクセシビリティ最優先の「デジタル庁デザインシステム」を公表し，入力フォームの標準部品まで提供しています。mintsの2010年代的な立体ボタンや固定幅レイアウトは，この現行標準とは距離があります。政府の標準に近づけるだけでも，見た目と操作性の底上げが可能です。
2 ウェブアクセシビリティの基準
日本にはウェブアクセシビリティの規格としてJIS X 8341-3があり，総務省の「みんなの公共サイト運用ガイドライン（2024年版）」は，公的機関に適合レベルAAを求めています。裁判所は行政機関ではないため，このガイドラインが直ちに法的に及ぶわけではありませんが，公開システムのアクセシビリティを測る事実上の基準として参照されるものです。年齢や障害の有無にかかわらず使えることは，本人訴訟の当事者も含めて誰もが利用しうる司法インフラにとって，本質的な要請です。
3 ユーザビリティの経験則
ユーザビリティ評価の国際的な経験則として広く用いられるNielsen Norman Groupの「10のユーザビリティ・ヒューリスティクス」に照らすと，本稿の指摘は「エラーの予防」「利用者の主導権と自由」「一貫性と標準への準拠」といった原則に対応します。これらは特定の製品を批判するための物差しではなく，あらゆるUIが満たすべき一般原則です。
第8 弁護士のための実務上の自衛策
改善を待つ間も，弁護士は今日からmintsを使わなければなりません。ここでは，上記の課題を踏まえた実務上の自衛策をまとめます。
1 入力・保存の自衛
① フォームは自動保存されないので，こまめに「保存」ボタンを押す。
② 申立ての趣旨・理由は字数制限（趣旨400字・理由10000字）とタブ混入エラーを避けるため，最初から別PDFで用意し，フォームに長文を直接貼り付けない。
③ 全角・半角の指定はフィールドごとに厳格なので，入力前に整えておく。
2 ファイル（PDF）の自衛
① 「記録」にアップロードするPDFはA4又はA3のみ。Letterサイズやスキャンの寸法ずれは弾かれるので，用紙サイズをページ単位で確認する。
② Word・Excel等は「記録外」でしか扱えない。訴え提起の段階では原則すべてPDF化する。
③ 1回のアップロードは200MBまで。超える場合は複数回に分ける。
④ ファイル名に丸囲み数字等の特殊文字を使わない（タイムスタンプが表示されなくなる）。
⑤ アカウント関係でマイナンバーカードをアップロードしない（公式が明確に禁止）。
3 提出・訂正の自衛
① 「提出」は不可逆で提出後は自分で直せないので，提出前に必ずプレビューで確認する。
② 誤りは担当書記官へ連絡する。休日・夜間は消去対応ができないことに留意する。
③ 「被告の数」欄は当事者欄と別入力なので，両者を必ず突き合わせ，被告の表示漏れを防ぐ。
4 認証・アカウントの自衛
① 二要素認証は，共用番号だと短時間の複数回認証で制限がかかるため，専用の番号を用意する。＃押下で認証できない機種の可能性に備え，別番号も確保しておく。
② 士業者は登録番号を登録しておくと，1年未利用による自動削除を回避できる。
③ 弁護士等の登録住所は事務所住所とし，末尾に「（送達場所）」と入力する。
第9 改善提言
1 低コストで効果の大きい改善
① データ表の列幅・折り返し・レスポンシブの修正（見出しが縦積みになる不具合の解消）。
② 提出先種別など初期値の適正化。
これらは表示の調整が中心で，比較的短期間で効果が出ます。
2 中期的な改善
① 入力の自動正規化（全角・半角・タブ・前後空白の自動処理）。
② 訴額からの手数料自動計算。
③ 「被告の数」の当事者欄からの自動集計（二重入力の廃止）。
④ サーバ側の自動保存。
3 制度と両立させるべき改善
訴訟記録の不可変性は維持しつつ，「提出」ボタンの視覚的な区別と確認ダイアログ，提出前プレビューの強化により，誤送信を防ぐ。硬直性そのものを緩めるのではなく，取り返しのつかない一線を越える前の確認を厚くする方向が，制度と使い勝手を両立させます。
第10 結び
mintsは，司法のデジタル化という大きな前進を担うシステムであり，法的要請に根ざす硬直性には正当化の余地があります。他方で，入力の正規化，自動保存，二重入力，表示の破綻，不可逆操作の無階層といった，法とは無関係な純粋な使い勝手の領域には，改善が可能で，かつ効果の大きい課題が残っています。弁護士がその利用を義務づけられる以上，これらの品質向上は，利用者の利便にとどまらず，司法へのアクセスを支える基盤の問題です。本稿が，実務上の自衛と，今後の改善の双方に資すれば幸いです。
出典
- 民事訴訟法132条の10，132条の11（条文はe-Gov法令検索により確認）
- 民事訴訟フェーズ3に向けた準備の手引，mints FAQ（Q&A），mints操作マニュアル～当事者ユーザ編～（いずれも裁判所公表）
- mints（民事裁判書類電子提出システム）公式サイト
- 東京弁護士会 LIBRA 2026年3月号「いよいよ民事裁判が電子化―『mints』利用義務化を前に―」
- 第二東京弁護士会 NIBEN Frontier 2025年12月号「フェーズ3で訴え提起はこうなる―『mints』の利用義務化―」
- デジタル庁デザインシステム
- 総務省「みんなの公共サイト運用ガイドライン」
- Nielsen Norman Group「10 Usability Heuristics for User Interface Design」
- MDN Web Docs