顧客名をAIに渡さずに業務を回す — 入力欄の設計から考える

前回「士業事務所のAI利用ルールが「気をつける」で終わってしまう理由」では、AI利用の対策の多くが「送ったあとにどう扱われるか」に依存していること、そのなかで「そもそも送っていない」だけが事務所側の設計で完結する説明になることを整理しました。

今回はその「送らない」を実装するための設計案を扱います。入力項目があらかじめ決まっている業務を想定した例であり、ShigyoAIが実在事務所へ導入して効果や安全性を検証した報告ではありません。

なお本記事は業務設計の一般的な考え方の紹介であり、個別事案の適法性判断ではありません。実際の運用は、所属士業会の最新指針や顧問弁護士の見解、AIベンダーの最新の利用規約とあわせてご確認ください。

自由入力欄では入力内容を技術的に限定しにくい

最初に、入力欄の制約を検討します。

自由入力欄は用途を広げられる一方、許可する文字や項目を固定した入力フォームより、入力内容を技術的に限定しにくくなります。利用規程や研修だけでは、顧客名や相談メモの誤入力を完全には防げません。

外部文書や第三者入力を自由文として取り込む構成では、プロンプトインジェクションも脅威モデルに含めます。固定項目にすればすべての攻撃を防げるわけではありませんが、不要な自由文を受け取らないことで入力経路を狭められます。

選択肢の一つは、対象業務に不要な自由入力欄をなくすことです。

自由入力欄をなくせば、その欄から自由文が入る経路はなくなります。ただし、選択肢の値、添付ファイル、外部連携、サーバー側で組み立てる指示文など、別経路の検証は必要です。

制約は当然あります。 想定していない業務には使えません。「どんな相談にも答えるAI」にはなりません。登記申請・許認可申請・給与計算に関連する補助業務でも、入力項目を列挙できる部分があります。法的判断を生成AIへ任せてよいという意味ではなく、固定項目で表現できる工程だけを対象にします。

もう一つの検討対象が、事業場名・顧客名の扱いです。

氏名や屋号は表記の幅が広く、機械的な検出では取りこぼしが残ります。設計案として、次の形が考えられます。

1.受け取った名称を、内部の記号 (「事業場A」など) に置き換える 2. AIには記号のまま渡す 3.返ってきた文章の記号を、元の名称に戻してから画面に出す

置換処理が正しく実装され、他の入力やログに名称が含まれなければ、モデルへ送る本文上は記号だけにできます。置換後の復元処理、ログ、監視、例外時の送信内容は別途検証が必要です。

この形でも、名称欄の値がモデル送信、ログ、エラー通知、分析基盤のいずれにも流れないことを実装と通信記録で検証する必要があります。本記事には、その検証を完了した自社実装の記録はありません。

名称以外の個人情報について、形式を限定できる項目は送信前に検出・除去する設計を候補にできます。ただし誤検知と見逃しがあるため、検出対象と限界を明示します。

ここで大事なのは、落としたことを画面に出すことです。黙って書き換えると、職員は自分が何を入力したのか分からなくなります。「この部分を除いて処理しました」と見えている方が、事務所として説明できます。

そして、この処理で氏名や屋号が拾えるとは言えません。形がないからです。だからこそ、名称は前段の「渡さない」設計で守る、という二段構えになります。

自分の事務所で使うツールを見るとき、この記事の観点はそのまま確認項目になります。この4点を1枚のメモにして、今使っているツール、あるいは検討中のツールに一つずつ当ててみてください。

確認すること	望ましい答え
自由に文章を書ける欄があるか	無い、または業務に必要な範囲に絞られている
顧客名は外部に送信されるか	送信されない (置き換えている)
個人情報を入力したとき、どうなるか	除いたことが画面に表示される
除ける情報の種類は何か	答えられること自体が重要。「すべて」と答える相手は確認していない可能性がある

4つ目が実務では効きます。できないことを答えられるかどうかが、確認の質を映します。この点は連載の4本目で改めて扱います。

自由入力欄を無くすと、当然できることは減ります。この判断が向くのは、次のような業務です。

対象物件・当事者・登記原因など項目が定義されている工程は、この設計を検討できる候補です。内容が毎回異なる相談対応や調査業務では、必要な文脈を固定項目だけで表せない可能性があります。業務ごとに向き不向きがあるため、架空データで送信内容、出力品質、例外処理、所要時間を測って判断します。

次回は、「そもそも生成AIを使わなくてよい部分」の切り分けについて書きます。法令で決まっていることは計算で答えが出るため、生成AIに任せる必要がありません。