Private AIの導入で確かめる項目一覧｜伏せ字の漏れを前提に

「問い合わせの記録を生成AIで要約したいが、顧客の氏名や電話番号をそのまま送るわけにはいかない」「伏せ字にする仕組みを入れれば大丈夫、と言われたが、本当に全部消えるのか分からない」——生成AIの社内利用を進める情報システム部門や、顧客データを扱うマーケの担当者から、立て続けに届く相談です。伏せ字の仕組みは、入れれば個人情報が消える装置ではありません。検出には必ず漏れがあり、伏せ字にしたせいで業務が壊れる場所もあります。この記事では、生成AIに渡す前に個人情報を見つけて伏せ字にする Private AI（現在の名称はリミナ）を例に、導入前に確かめる項目を順に整理します。

Private AI は、AIに渡す前に個人情報を見つけて伏せ字にする仕組み（現在の名称はリミナ）

Private AI は、文章や文書、画像、音声の中から個人を特定できる情報を検出し、伏せ字にしたり、別のそれらしい値に置き換えたりする製品です。2019年に創業した会社で、現在はリミナの名称で提供されています。公式サイトの組織情報は旧名の Private AI を別名として掲げており、技術文書にも「リミナは Private AI の製品」と記されています。国内では旧名で知られているため、この記事では Private AI の名前で扱います。

使い方の典型は、社内の文章を生成AIに送る手前に置くことです。問い合わせの記録や商談のメモから氏名や電話番号を見つけ、「［氏名1］」のような印に置き換えてからAIに渡します。AIの答えが返ってきたら、必要に応じて印を元の値に戻します。技術文書には、この流れを ChatGPT と組み合わせる手順が掲載されています。

オープンソースで同様の関所を作る方法もあり、その一般的な仕組みは別の記事で扱っています。この記事で絞るのは、商用の仕組みを使う場合に、提供の形・日本語の精度・業務への影響・漏れの扱いをどう確かめるかです。

確かめられる事実：対応言語・検出の種類・提供の形

技術文書によれば、検出できる情報の種類は50種類を超え、氏名、住所、電話番号、メールアドレス、生年月日、パスポート番号、銀行口座、クレジットカード番号、病名や薬の名前などに及びます。種類ごとに、どの法令の対象になるかの対応も示されており、日本の個人情報保護法の対象や、要配慮個人情報に当たるものの区分も載っています。

言語は、最も手厚い支援を受ける14言語と、拡張の39言語に分かれています。日本語は手厚い支援の14言語に含まれ、文章・音声・ファイルのすべてに対応すると記載されています。手厚い支援の言語は学習データの量と文脈の多様さで区別しており、精度が最も高いと説明しています。一方で、組織を識別する番号のように英語だけで完全に対応している種類や、英語でしか使えない試験中の種類もあります。

項目	公式の記載	導入前に確かめること
提供の形	クラウドのAPI、自社の環境で動かすコンテナ、主要なクラウドの販売窓口	どの形で契約するか、どの版を使うか
日本語	手厚い支援の言語。文章・音声・ファイルに対応	自社の文書での検出漏れと検出しすぎ
検出の種類	50種類超。種類ごとに有効・無効を指定できる	日本固有の番号や社内の識別子が含まれるか
置き換えの形	印、塗りつぶし、別の値への置き換え	AIに渡した後の答えが使えるか
元に戻す	AIの答えに元の値を戻す口がある	対応表をどこに置き、いつ消すか

なお、公式サイトには、約4万5千語の試験で汎用の道具が個人情報の13.8〜46.5％を見落としたのに対し、同社の見落としは0.2〜7％だったという記載があります。これは提供元が自ら行った比較であり、自社の文書で同じ結果が出る保証ではありません。数字は候補を絞る参考にとどめ、判断は次の章以降の確認で行います。

使いどころ：効く業務と、効きにくい業務

導入を考える前に、どの業務に効くかを見極めます。効きやすいのは、個人情報が文章の一部に混ざっているが、業務の目的は個人ではなく内容にある業務です。例えば、問い合わせの記録を要約して製品の改善点を拾う、アンケートの自由記述を分類して傾向をつかむ、商談のメモから競合の名前や失注の理由を集める、といった業務です。これらは氏名や連絡先を伏せても、目的の情報はほとんど失われません。

効きにくいのは、個人そのものが業務の対象になる業務です。特定の顧客への返信文を作る、担当者ごとの対応履歴をまとめる、といった業務では、伏せ字にした後に元に戻す処理が必須になり、確認項目6で見る対応表の管理が重くなります。また、名刺や申込書の画像のように、ほぼすべてが個人情報の文書は、伏せ字にすると何も残りません。伏せ字にしても目的の情報が残る業務から始めると、効果と手間の釣り合いが取りやすくなります。

音声やファイルにも対応しているため、録音した通話やPDFの文書を処理する使い方もあります。ただし、試用枠では文字のファイルは250キロバイト、その他は4メガバイトまでという上限があり、長い録音や大きな文書の評価には別の契約が要ります。複数の短い文章を一つのまとまりとして扱い、文をまたぐ情報（「電話番号は」と「0312…」が別の行にある場合など）を検出する設定も用意されています。

確認項目1　クラウドのAPIか、自社で動かすコンテナか

最初に決めるのは、文書をどこで処理するかです。公式には二つの道があります。一つは提供元のクラウドのAPIに文章を送る形で、技術文書の日本語の手引きでは、無料の鍵を取得してすぐに試せる手順が案内されています。もう一つは、提供元が配るコンテナを自社のクラウドや社内のサーバーで動かす形で、技術文書は本番の運用には Kubernetes を推奨しています。

クラウドのAPIでは、伏せ字にする前の生の文章が提供元に渡ります。料金ページでは、データは保存も記録もされず処理後すぐに破棄されると説明していますが、個人情報を伏せ字にするために、伏せ字にする前の個人情報を社外に送るという構図になる点は変わりません。顧客データを扱う業務で使うなら、この点を個人情報の担当者に説明し、委託の整理が要るかを確認します。

コンテナは、生の文章が自社の環境から出ない形です。GPUがなくても一般的なCPUのサーバーで動くと案内されています。その代わり、サーバーの用意、版の更新、負荷に応じた台数の調整を自社で担います。試用はクラウドのAPIで架空のデータを使い、本番の顧客データはコンテナで処理する、という分け方も現実的な選択肢です。

このほか、公式サイトは主要なクラウドの販売窓口（Azure や Snowflake など）からの提供も案内しています。すでに契約しているクラウドの中で動かせれば、新しい委託先を増やさずに済む場合があります。企業向けの区分では、使う版を固定できることや、地域を選んだ配置、複数の地域や複数の基盤での運用が挙げられています。日本の顧客データを国外で処理したくない会社は、どの地域で処理されるのかを、契約の区分ごとに確かめてください。

確認項目2　コンテナでも外に出るもの：認証と利用量の送信

自社で動かすコンテナなら何も外に出ない、と考えるのは早計です。技術文書の紹介では、データが環境の外に出ることはないと書かれていますが、よくある質問を読むと、コンテナは起動時に認証のための通信を行い、処理があった間は5分ごとに利用量の統計をまとめて送ると説明されています。特定の版からは、利用量の集計を行う外部の計測サービスにも送られるようになったと記載されています。

送られる統計の例として示されているのは、APIの呼び出し回数、処理した文字数と語数、設定の区分などで、文書の中身ではありません。それでも、外向きの通信の宛先を社内のネットワークで許可する必要があることは、閉じた環境で運用したい会社にとって大きな確認事項です。外への通信を一切許さない環境で使えるかは、契約の形によって異なる可能性があるため、提供元に直接確認してください。

• 外向きの通信の宛先と頻度は版によって変わります。版を上げるたびに、技術文書のよくある質問の記載を確認する運用にしておきます。
• 利用量の統計に文書の中身が含まれないことは、提供元の説明に基づきます。必要なら、検証環境で実際の通信を観察して確かめます。

確認項目3　日本語の固有名詞の検出精度を自社の文書で測る

日本語が手厚い支援の言語であっても、自社の文書で精度が出るとは限りません。日本語の固有名詞には、英語にない難しさがあります。人名と地名と社名が同じ字面になること（例えば「松本」は人名にも地名にもなる）、敬称の「様」「さん」が付いたり付かなかったりすること、社内の略称や部署名、商品名が人名のように見えることなどです。

検出の結果には、それがどの種類だと判定されたかと、その確からしさの数値が付いてきます。これを使えば、どの種類の情報が漏れやすく、どの種類で消しすぎが起きるかを数えられます。漏れ（検出すべきものを見落とす）と消しすぎ（個人情報でないものを伏せ字にする）は、分けて数えるのが大事です。前者は情報の流出につながり、後者は業務の役に立たない文章を生むからです。

特に確かめたいのは、社名の扱いです。社名は個人情報ではありませんが、検出の種類の中に組織名があり、既定では有効になっています。顧客企業の社名まで伏せ字になると、営業やマーケの文書の要約はほとんど意味をなさなくなります。社名を伏せるかどうかは、精度の問題ではなく業務の判断なので、測った結果を見ながら決めます。

日本語への対応の手がかりとしては、技術文書に日本語の手引きが用意されていること、公式サイトの日本語版が日本の個人情報保護法を対応する規制の一つに挙げていることがあります。公式サイトには、ある多国籍の保険会社が日本語のデータで他社の道具を試して失敗し、同社の仕組みでは期待した精度が出たという紹介もあります。ただし具体的な数値は示されておらず、どんな文書で試したのかも分かりません。日本語の手引きがあることは、問い合わせや設定のしやすさの材料にはなっても、自社の文書での精度の裏付けにはならない、と分けて受け止めます。

測り方の手順：正解付きの小さな試験データを作る

精度を測るには、正解の付いた試験データが要ります。大がかりな評価は不要で、業務で実際に扱う文書から少数を選び、人が正解を付けるところから始めます。

技術文書のよくある質問には、検出の改善を依頼する場合、改善したい点ごとに5〜10件の例が要ると書かれています。この試験データは、そのまま提供元に改善を相談するときの材料にもなります。測った結果は、導入の可否を判断した根拠として記録に残しておくと、後で監査や見直しをするときに役立ちます。

確認項目4　伏せ字の形を選ぶ：印・塗りつぶし・別の値への置き換え

見つけた情報をどう置き換えるかは、AIの答えの使いやすさに直結します。公式に用意されているのは、種類と番号の付いた印に置き換える形、記号で塗りつぶす形、そして別のそれらしい値に置き換える形です。

印に置き換える形は、同じ人物には同じ番号が振られるため、AIが文脈を追えるのが利点です。「［氏名1］さんから見積もりの依頼があり、［氏名2］さんに引き継いだ」という文章なら、要約しても誰が何をしたかの関係は保たれます。塗りつぶしは、誰が誰か区別できなくなるので、要約や分類には向きません。

別の値への置き換えは、AIにとって自然な文章になる反面、注意が要ります。技術文書には、インドの国民識別番号のように、置き換えに対応していない種類で置き換えを有効にすると、番号が漏れるおそれがあると明記された例があります。置き換えを使うなら、対応していない種類が自社の文書に含まれていないかを先に確かめる必要があります。迷ったら、印に置き換える形から始めるのが安全です。

確認項目5　伏せ字で業務が壊れる場所

伏せ字は、個人情報を守る代わりに、文章の情報を減らします。業務によっては、それが致命的になります。導入前に、AIに渡す予定の業務を一つずつ見て、伏せ字にしたら何が起きるかを確かめます。

• 顧客ごとの問い合わせ傾向を分析したいのに、社名まで伏せ字にして顧客を区別できなくなる
• 日付をすべて伏せ字にした結果、対応の遅れや期限の判断ができなくなる
• 職種や役職を伏せ字にして、商談の相手が決裁者かどうかをAIが判断できなくなる
• 住所の都道府県まで伏せ字にして、地域別の集計ができなくなる
• 元に戻す処理を入れ忘れ、顧客への返信の下書きが印だらけのまま送信の直前まで進む

こうした問題は、検出の種類を細かく選ぶことで多くが避けられます。種類ごとに有効と無効を指定でき、例えば氏名と連絡先だけを伏せ、社名と日付は残す、といった設定ができます。ただし、残した情報を組み合わせると個人が特定できる場合があることにも注意します。技術文書も、単独では特定できない情報の組み合わせが特定につながると説明しています。小さな会社の担当者で、役職と部署と日付がそろえば誰か分かる、という場面です。

確認項目6　AIの答えに元の値を戻す扱い

AIに渡すときに伏せ字にしても、答えを使う人には元の名前が必要な場面があります。返信の下書きや、担当者ごとの対応の一覧などです。Private AI には、伏せ字にしたときの対応表を使い、AIの答えの中の印を元の値に戻す口が用意されています。

問題は、この対応表がそれ自体個人情報の塊だという点です。どこに置き、誰が読め、いつ消すかを決めないと、伏せ字にした意味が薄れます。よくある質問は、元に戻す仕組みは暗号化や一時的な保存の層で実現できると説明しつつ、元に戻せる仕組みを作ると規制上の要件に反するおそれがあるので、安全や法令の担当と検証するよう勧めています。

実務では、元に戻すのは画面に表示する直前だけにし、対応表は処理が終わったら消すのが基本です。AIの答えを元に戻した状態で別のシステムに保存するなら、その保存先は元の個人情報と同じ扱いになります。元に戻す必要のない業務（傾向の分析や分類など）では、そもそも対応表を残さない設計にします。

確認項目7　検出漏れを前提にした運用：残る漏れを誰が拾うか

どれほど精度の高い検出でも、漏れはゼロになりません。提供元の自己評価でも見落としは0.2〜7％とされており、自社の文書ではそれより多いこともあり得ます。だから運用は、漏れが起きたときに被害が小さくなるように組み立てる必要があります。

一つ目は、送ってよい文書の範囲を決めることです。マイナンバーや健康の情報、採用の候補者の情報のように、漏れたときの影響が大きい文書は、伏せ字の仕組みがあってもAIには渡さない、と決めます。伏せ字は二重の守りの一枚であり、送ってよいかの判断を代わりにしてくれるものではありません。

二つ目は、渡す先のAIの契約です。伏せ字をすり抜けた情報があっても、法人向けの契約で学習に使われず、保存期間が短い先に送っていれば、影響は限られます。三つ目は、抜き取りの点検です。月に一度、伏せ字にした後の文章を一定数取り出し、人が漏れを探します。漏れを見つけたら、その書き方を試験データに足して測り直す、という循環を作ります。

確認項目8　対象外にする情報、追加する情報

検出の調整には、許可の一覧と拒否の一覧が使えます。許可の一覧は、個人情報のように見えても伏せ字にしない語を登録するもので、自社の社名、商品名、部署名、営業所の地名などが候補です。拒否の一覧は、検出の仕組みが見落としがちな語を必ず伏せ字にするもので、社内の顧客番号や社員番号の形式を、決まった型として登録できます。

日本の会社でよく必要になるのが、社内独自の識別子です。顧客番号、案件番号、社員番号は、外から見れば単なる英数字ですが、社内の名簿と突き合わせれば個人にたどり着きます。技術文書には、英数字の識別番号を検出する種類もありますが、自社の番号の形式を拒否の一覧に入れておくほうが確実です。

一覧は放置すると古くなります。新しい商品名や組織改編で、許可すべき語が増えていきます。一覧の管理者を一人決め、変更の履歴を残し、四半期に一度は試験データで測り直す運用にしておきます。

費用の増え方と、試用枠で分かること

料金ページによれば、無料の試用枠は1日75回、1分あたり10回までのAPI呼び出しで、扱えるファイルの大きさにも上限があります。大量の一括処理向けの区分は量に応じた見積もり、企業向けの区分は利用量を約束する形の個別の見積もりで、版の固定や地域を選んだ配置、専任の担当者などが含まれると案内されています。料金は処理するデータの量と提供の形で決まると説明されています。

試用枠は、架空のデータで仕組みを理解するには十分ですが、精度の評価には向きません。本物に近い文書を使った評価は、コンテナでの試用や、評価用の契約を相談して行うのが筋です。公式のよくある質問には、CPUで動かす典型的な構成の費用は月に数百ドル程度という目安も書かれていますが、自社の処理量と構成で見積もりを取り直すことが前提です。

費用が増える要因は、処理する文書の量、音声やファイルの処理、そしてコンテナを動かすサーバーの台数です。AIに渡す文書が増えるほど処理量も増えるため、生成AIの利用拡大の計画と、伏せ字の処理量の見積もりをひとまとめにして予算を組むと、後から費用が膨らむのを防げます。

コンテナで動かす場合は、処理の速さと台数の関係も見積もりに入れます。よくある質問では、同時に処理する数の目安をCPUのコンテナで1、GPUのコンテナで16としており、音声は1台あたり一度に1件ずつしか処理しないため、台数を増やして対応すると説明しています。問い合わせの記録を毎晩まとめて処理するのか、社員がAIに質問するたびにその場で処理するのかで、必要な台数は大きく変わります。後者のようにその場で処理する使い方では、伏せ字の待ち時間がそのままAIの応答の遅れになるので、試行の段階で体感の速さも確かめておきます。

止め方・やめ方と、版の固定

止め方は、置き方によって違います。クラウドのAPIなら、呼び出しの鍵を無効にすれば止まります。コンテナなら、自社でコンテナを止めます。どちらの場合も、止めた瞬間に伏せ字の処理がなくなるので、伏せ字の処理が止まったら、AIへの送信も止まるように組んでおくことが重要です。伏せ字が失敗したときに、生の文章がそのままAIに流れる作りになっていないかを確認します。

版の管理も大事です。技術文書は、コンテナの版を固定して使うことを推奨しています。版が変わると検出の結果が変わり、前に測った精度が当てはまらなくなるからです。新しい版に上げるときは、試験データで測り直してから本番に入れます。

やめるときは、別の仕組みへの移行を考えます。オープンソースの検出の道具に切り替える場合も、試験データと許可・拒否の一覧があれば、同じ物差しで比べられます。試験データと一覧は、特定の製品に依存しない形で自社に残すことが、やめ方の準備になります。

移行のときは、印の形式の違いにも注意します。後続の処理が「［氏名1］」のような印の形を前提に組まれていると、別の仕組みに替えた途端に印の書き方が変わり、元に戻す処理や集計が動かなくなります。印の形式を自社の処理の側で一度変換してから使う作りにしておけば、検出の仕組みを替えても後続の処理はそのまま使えます。

導入前のチェックリスト

ここまでの確認項目を、導入の判断の前に通す一覧にまとめます。すべてに答えが出ていない項目があれば、その項目を確かめてから次に進みます。

• AIに渡す業務と文書の種類を一覧にし、渡さない文書（マイナンバー、健康、採用など）を決めた
• クラウドのAPIかコンテナかを決め、生の文章がどこで処理されるかを個人情報の担当者に説明した
• コンテナの外向きの通信（認証と利用量の送信）の宛先を、ネットワークの担当者と確認した
• 自社の文書から作った正解付きの試験データで、漏れと消しすぎを種類ごとに数えた
• 社名・日付・役職など、伏せ字にしない情報を業務ごとに決めた
• 置き換えの形を決め、置き換えに対応していない種類が含まれないことを確かめた
• 元に戻すための対応表の置き場所、読める人、消す時期を決めた
• 許可と拒否の一覧の管理者と、見直しの周期を決めた
• 伏せ字の処理が止まったときにAIへの送信も止まることを確かめた
• 使う版を固定し、版を上げるときに測り直す手順を決めた

この一覧は、導入の稟議に添付する資料としても使えます。確認した日付と、確認した人の名前を各項目に残しておくと、後から設定を変えたときに、どの前提が崩れたかを追えます。

AIに任せる範囲と、人が決める範囲

Private AI のような仕組みが行うのは、文章の中から個人情報らしい箇所を見つけて置き換えることです。そこまでは機械に任せられます。しかし、どの文書をAIに渡してよいか、どの情報を残すか、漏れが見つかったときにどう対応するかは、人が決めることです。

特に、検出の確からしさの数値を、送ってよいかどうかの合否の線に使うのは避けます。数値が高くても誤りはあり、低くても正しい場合があります。数値は点検の優先順位を付ける材料として使い、送信の可否は文書の種類で決めるのが安全です。

また、伏せ字の仕組みを入れたことを理由に、AIの利用の規程を緩めないことも大切です。「伏せ字にするから顧客データを何でも入れてよい」という運用は、漏れが起きたときに説明がつきません。伏せ字は、規程を守ったうえでの二重の守りとして位置づけてください。

まとめ

Private AI（現在の名称はリミナ）は、生成AIに渡す前に個人情報を検出し、印や別の値に置き換える仕組みで、日本語は最も手厚い支援の言語に入っています。ただし、提供元の精度の数字は自社の文書での結果を保証しません。クラウドのAPIかコンテナか、コンテナでも外に出る通信、日本語の固有名詞の精度、伏せ字の形と業務への影響、元に戻す対応表の扱い、検出漏れを前提にした点検を、導入前に一つずつ確かめてください。伏せ字は送ってよいかの判断を代わりにしてくれるものではなく、人が決めた範囲を守るための二重の守りです。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。