メインコンテンツへスキップ
  1. ホーム /
  2. AI・リーガルテック /
  3. mints /
  4. システムとしてのmintsの論評～UI/UXデザイン，フロントエンドエンジニアリング及び情報アーキテクチャ（IA）の視点から～（AI作成）
       
             

システムとしてのmintsの論評～UI/UXデザイン，フロントエンドエンジニアリング及び情報アーキテクチャ（IA）の視点から～（AI作成）

◯本ブログ記事は専らAIで作成したものであり，実際の画面と公式文書（準備の手引・FAQ・操作マニュアル）を突き合わせ，具体的な根拠に基づいて，民事裁判書類電子提出システム「mints」を「一つのWebシステム」として論評するものです。
◯以下の記事も参照してください。
・　mints（ミンツ）とは―料金・対象事件・登録・ログイン・提出・送達の実務Q&A（AI作成）
・　（AI作成）mints操作マニュアル～当事者ユーザ編～の解説
・　（AIリライト）最高裁判所が開発しているmints，RoootS及びTreeeS

第1　はじめに―本稿の視点と検討対象

1　mintsを「システム」として論ずる理由

mintsについての解説は，多くが「操作手順」を説明します。本稿は視点を変え，mintsを一つのWebシステムとして，その設計思想の妥当性を論じます。手順の暗記でつまずきを回避するのではなく，なぜつまずくのか，どう設計されていれば負担が小さかったのかを，専門の視点から明らかにするためです。具体的な画面操作ではなく認証上の問題を確認する場合は，mintsにログインできない場合の対処法を参照してください。

2　検討の三つの視点

本稿は次の3つの視点を用います。第1に，利用者の目的達成のしやすさを見るUI/UXの視点。第2に，画面がWeb標準・ブラウザの作法に沿って実装されているかを見るフロントエンドの視点。第3に，情報や導線が見つけやすく整理されているかを見る情報アーキテクチャ（IA）の視点です。

3　公平を期すための留保

はじめに公平のために述べます。mintsは，訴訟記録の不可変性・非改ざん性という司法固有の要請の下で構築されており，後述する「修正のしにくさ」の一部はUXの失敗ではなく意図した設計です。また，全国の裁判所に短期間で展開する制約や，将来システム（TreeeS）への移行を控えた過渡的実装であることも考慮すべきです。本稿の指摘は，こうした制約を踏まえてもなお改善が可能で，かつ法的制約とは無関係な領域に絞った建設的なものです。

令和８年８月３１日の見直しでは，手数料計算とFAQの説明を現行公表資料と照合した。

画面表示，認証の実挙動，原因となる実装及び修正費用については，公表資料の説明，条件付きの評価及び未確認事項を区別し，認証後の全機能を実地検証したものとは扱わない。

第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)　手数料の自動計算と入力上の留意点

操作マニュアル２．３版３９頁～４０頁〔PDF４２頁～４３頁〕は，「申立内容」タブの被告の数と訴額を入力すると，手数料が自動計算され，手入力で訂正できると説明している。

ただし，被告の数又は訴額に０を入力した場合は空欄となり，申立種別「その他」の手数料も手入力である（同４３頁〔PDF４６頁〕）。

したがって，自動計算機能が存在しないという評価は適切でない。

改善を検討するなら，自動計算の対象・例外，訴額の入力単位及び手入力で訂正する場面を分かりやすく示すことが考えられる。

訴額の１万円未満の切上げという入力ルールと，提出後に裁判所が登録する納付情報も区別する必要がある。

提出先種別の既定値の適否は，現在の画面，申立種別及び操作条件を確認して評価すべきであり，資料の画面例だけから全ての利用場面の初期値を断定しない。

2　一覧・テーブルの設計

(1)　列見出しの折り返し

データ表の列見出しが１文字ずつ折り返される場合，列の意味を読み取りにくくなり，実務上の確認負担が増える。

もっとも，表示の検証には，確認日時，ブラウザ，画面幅，拡大率及び対象画面を記録する必要がある。

令和８年８月３１日の本記事見直しでは，認証後の現行画面を実操作して再現性を確認したものではないため，全利用者に同じ表示が生じることや，原因が特定のCSS指定にあることは断定しない。

列幅，折り返し及び狭い画面での表示を検証し，読める状態を確保することは改善の検討事項であるが，費用・工期は実装の確認なしには判断できない。

(2)　横方向のはみ出しと無名の列

事件一覧でボタンが画面外にはみ出す場合は，画面幅，拡大率及び横スクロールによって操作可能かを確認する必要がある。

画面例だけから固定幅レイアウトが原因と断定せず，現行画面での再現条件と実装を分けて検証する。

見出しの語がなくアイコンだけで意味を示す列については，表示ラベル又は説明によって役割を判別できるかが評価対象となる。

本記事の見直しでは，これらの表示を認証後の現行画面で再現する検証までは行っていない。

(3)　ステータス表示の曖昧さ

提出ファイルのステータスには「全員閲覧済」「一部閲覧済」といった表示があります。しかし，ここでいう「全員」は，その事件にmintsで関連付けられた利用者に限られます。相手方が招待キーで関連付けられていない段階では，実際には相手方が見ていなくても「全員閲覧済」と表示され得ます。送達や直送の効力を判断する場面では，表示そのものではなく，誰がいつ閲覧したかの実体（アクセス状況）を確認する必要があります。

3　取り返しのつかない操作の設計

(1)　「提出」ボタンの視覚的無階層

新規申立てフォームの上部には「保存」「申立ダウンロード」「プレビュー」「提出」の4つのボタンが，同じ大きさ・同じ配色で横一列に並びます。日常的に押す「保存」と，取り返しのつかない「提出」とが視覚的に同格で，見分けがつきにくくなっています。

ア　不可逆な操作は，色や大きさで区別し，実行前に確認の一手間（確認ダイアログ）を挟むのがUXの定石です。誤送信の予防という観点から，最も優先度の高い改善点の一つです。

(2)　提出後の修正不可・削除不可

いったん提出すると，当事者は自分でファイルを削除したり書面種別を変更したりできず，担当書記官への連絡で対応することになります。この硬直性は，UX単独で見れば「取り消しの自由」の欠如ですが，訴訟記録の不可変性という法的要請に根ざす側面があり，一概にUXの失敗とはいえません。妥当な批判は「不可変性は保ちつつ，提出前の確認を厚くせよ」という方向にあります。

(3)　アカウント削除の配置

アカウント設定の画面では，日常的な項目と同じフォームの中に，赤色の「アカウント削除」ボタンがインラインで置かれています。危険な操作は，通常操作から物理的に離し，誤操作を招きにくい配置にすることが望まれます。
アカウント削除と登録情報の変更の具体的な手順は，mintsアカウントの登録情報を変更・削除する方法を参照されたい。

4　認証・ログインの設計

(1)　二要素認証の＃押下と機種依存

二要素認証で「電話する」を選ぶと，音声案内に従って「＃」ボタンの押下を求められます。もっとも，公式FAQ自身が，利用する電話機によっては＃を押しても正常に認証できない事象が確認されている旨を認めています。システムへの入口である認証に機種依存の不達リスクがあることは，可用性の観点から軽視できません。

(2)　認証セッションの引継ぎの確認

別のタブ又はウィンドウを開いたときの認証状態は，開き方，ブラウザの設定及び操作時点によって区別して確認する必要がある。

別画面で再認証が求められたという観察だけから，mints全体が「ウィンドウ単位でしか認証を保持しない方式」であるとまでは判断できない。

本記事の見直しでは，認証後の現行画面を操作して認証状態の引継ぎ条件を再検証していないため，具体的な保存方式又は全てのタブでの挙動は未確認である。

実務上は，入力中の内容を保存し，公式の操作手順に従って画面を開くことが必要である。

5　権限（ロール）の設計―補助者アカウント

(1)　補助者に与えられる権限の広さ

mintsには，弁護士等の事務職員が弁護士を補助するための「補助者アカウント」があります。事務職員が誰でも自由にアクセスできるものではなく，弁護士が事務職員のIDを自分のアカウントに登録して初めて紐づく仕組みです。もっとも，いったん補助者として設定されると，その権限は限定されていません。補助者は，新規申立て，ファイルのアップロード，閲覧・ダウンロード，印刷，受領書の作成のいずれも行うことができ，しかも補助者の行った操作は，親ユーザである弁護士本人が行ったものとみなされます。
補助者アカウントの登録，権限，上限及び退職時の解除は，mintsの補助者アカウント―登録方法・権限・上限と退職時の解除を参照されたい。

ア　閲覧だけを許すといった，権限を役割ごとに絞り込む階層がないため，事務職員が弁護士とほぼ同一の操作をでき，その一つ一つが弁護士本人の行為として扱われます。誰に，どこまでの操作を許すかを役割に応じて制御するという，アクセス管理の基本（最小権限の原則）からは距離がある設計です。

(2)　閲覧・ダウンロードが送達の効力を生じさせること

とりわけ注意を要するのは，補助者がシステム送達された電子判決書等を閲覧し，又はダウンロードすると，その時点で送達の効力が生じ，控訴期間などが進行してしまう点です。取り返しのつかない法的効果が，権限の絞られていない補助者の何気ない操作によって発生し得ます。

ア　これはUX単独の失敗というより，権限の設計と法的効果とが直結していることに由来するリスクです。閲覧しただけで期間が進行する設計である以上，誰の，どの操作に，どこまでの効果を結び付けるのかを役割ごとに整理し，利用者に明示することが望まれます。

(3)　後継システムでの改善の予定

なお，後継システムであるTreeeS（ツリーズ）では，権限をアカウントの種別ではなく事件ごとの立場（肩書）に応じて定める方向での見直しが予定されているとされます。権限がフラットであるという現在の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・マニュアルに重複して書かれ，どれが最新・正なのかを利用者が判断させられます。横断的な用語集や相互参照を備えた単一の正典が求められます。

5　外部送信情報の透明性と確認限界

mintsの公開トップページのHTMLには，令和８年９月１４日現在，Google Tag Manager（GTM）のコンテナ識別子を含む記述がある。
ただし，HTMLに識別子があること，外部サービスへのリンクがあること及び利用者の端末から情報が現実に自動送信されることは，それぞれ別の事実である。

同日のJavaScript有効環境で通常表示を確認した範囲では，一般的なGTM読込み用スクリプトは確認できなかったが，この限定的な観察だけで，ログイン後画面，別の動作条件又は将来の設定を含めて外部送信がないと断定することはできない。
また，最高裁判所は，GTMによる外部送信情報に関する利用者向け案内文書と，GTMのタグ及びトリガーの設定変更手順について，存否を明らかにせず不開示とした。利用者向けには，秘密性の高い設定情報と切り分けた上で，送信先，送信情報の区分及び利用目的を説明することが望まれる。詳しくは，mintsのGoogle Tag Manager（GTM）と外部送信情報―最高裁の存否応答拒否，電気通信事業法27条の12及び確認できた範囲（AI作成）を参照されたい。

第6　付随文書（ドキュメント）の妥当性

システムの評価に付随して，3つの公式文書自体の妥当性にも触れます。

1　準備の手引

「民事訴訟フェーズ3に向けた準備の手引」は，アカウント登録から執行・秘匿までを時系列の章立てで俯瞰させる概念資料として，よくできています。手続の全体像を1枚で示す図や，マスキング・提出場所などのつまずきを先回りする配慮も見られます。

他方，詳細を操作マニュアルに委ねるため単独では完結せず，スライド形式ゆえにPDFの読み上げ順序（機械可読性）が弱い点は課題です。

2　FAQ（Q&A）

裁判所のFAQは，令和８年４月時点のチャットボットの質問回答を一覧にした全１５頁の資料であり，その後の修正・追加を含まないと明記されている。

利用時には，取得日と回答の収録時点を区別し，現行のマニュアル及びチャットボットも確認する必要がある。

PDFのテキスト抽出では，「こちら」等のリンク文字の読取順序が乱れ，頁末に分離したように見える場合がある。

しかし，令和８年８月３１日に原PDFの１頁・９頁のリンク注釈を確認したところ遷移先情報があり，９頁では本文中のリンク表示も確認できた。

したがって，抽出テキストの乱れを根拠に，原PDFのリンク先をたどれないと断定することはできない。

参照資料としては，原本表示とリンク先を併せて確認し，目的別の索引から必要な質問へ移れるようにすることが有用と考えられる。

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年未利用による自動削除を回避できる。
③　弁護士等の登録住所は事務所住所とし，末尾に「（送達場所）」と入力する。

5　補助者（事務職員）の運用の自衛

①　補助者に操作を任せる場合でも，補助者が電子判決書等を閲覧・ダウンロードした時点で送達の効力が生じ，控訴期間などが進行することを，事務所内で共有しておく。
②　補助者は弁護士とほぼ同一の操作ができ，その操作は弁護士本人の行為とみなされるため，誰が・いつ・どのファイルを扱うかの運用ルールをあらかじめ定めておく。
③　補助者が不要になった場合（事務職員の離職等）は，速やかに自分のアカウント設定から補助者IDの登録を解除する。

第9　改善提言

1　優先して検討する改善

①データ表の列幅，折り返し及び画面幅に応じた表示を，条件をそろえて検証する。

②提出先種別等の初期値が，対象となる申立てに適切かを確認する。

これらは優先して検討できる表示・入力上の課題であるが，改修費用，工期及び他の機能への影響は，現行実装を確認した上で判断する必要がある。

2　中期的な改善

①　入力の自動正規化（全角・半角・タブ・前後空白の自動処理）。
②　手数料の自動計算が適用される場面と例外，手入力による訂正方法の案内。
③　「被告の数」の当事者欄からの自動集計（二重入力の廃止）。
④　サーバ側の自動保存。
⑤　補助者アカウントの権限を役割に応じて分ける（閲覧のみを許すなど，ロールの導入）。

3　制度と両立させるべき改善

訴訟記録の不可変性は維持しつつ，「提出」ボタンの視覚的な区別と確認ダイアログ，提出前プレビューの強化により，誤送信を防ぐ。硬直性そのものを緩めるのではなく，取り返しのつかない一線を越える前の確認を厚くする方向が，制度と使い勝手を両立させます。

第10　結び

mintsは，司法のデジタル化という大きな前進を担うシステムであり，法的要請に根ざす硬直性には正当化の余地があります。他方で，入力の正規化，自動保存，二重入力，表示の破綻，不可逆操作の無階層といった，法とは無関係な純粋な使い勝手の領域には，改善が可能で，かつ効果の大きい課題が残っています。弁護士がその利用を義務づけられる以上，これらの品質向上は，利用者の利便にとどまらず，司法へのアクセスを支える基盤の問題です。本稿が，実務上の自衛と，今後の改善の双方に資すれば幸いです。

ここで挙げた課題を踏まえた事務所内の運用ルールはmintsを安全に使うための事務所内チェックリストに，自動保存の不在への具体的な対処はmintsの一時保存とセッションタイムアウトに，それぞれまとめている。

出典