ユーザーペルソナ: 金融サービスの実務担当者

プロフィール: 銀行、融資、保険、資産運用 — 顧客とのやり取り、稟議書、保険金請求の記録、約款、規制関連の資料。 主な目標: 大規模モデルの速さを活かしつつ、顧客データをあるべきでない場所に置かないこと。

問題は文章を書くことではありません。あなたが書く対象のほとんどに、誰かの氏名、口座番号、生年月日が含まれているということです。このガイドは、それらがご自身のマシンに留まるように Rephlo を設定するためのものです。

Rephlo はツールであり、コンプライアンスプログラムではありません。 慎重に業務を進めるための技術的な制御 — ローカル処理、秘匿化(レダクション)、ルーティング — を提供します。しかし、あなたや所属組織をいずれかの規制に適合させるものではなく、ここに書かれている内容は法的助言でもありません。実際の顧客データを AI ツールで扱う前に、社内でデータ方針を所管する部門に設定内容を確認してください。

推奨される設定

プロバイダー

• 顧客データを含まない日常業務(社内向けの下書き、一般的な調査、書式の整形): GPT-5.4 または Claude Sonnet 4.6。
• 顧客データ・口座データ: 秘匿化を有効にしたクラウドモデル(下記参照)、または何もマシンの外に出したくない場合はオンデバイスモデル。
• 企業のデータ所在地要件: OpenAI-Compatible を自社の Azure OpenAI エンドポイントに向けることで、リクエストを自組織のテナントとリージョン内に留められます。

注記: Azure OpenAI は OpenAI-Compatible プロバイダータイプ経由で接続します — OpenAI-Compatible を選び、Azure のデプロイエンドポイントを Base URL に、デプロイ名を Model Name に入力してください。

最初に有効化する設定

Settings ▸ Privacy を開き、最初の実務に取りかかる前に次の 3 点を設定してください。

1. Scrub PII Before Cloud — 検出された個人情報を、リクエストがクラウドプロバイダーに届く前に取り除きます。
2. Also detect dates & addresses (on-device AI) — この業務で最も重要なカテゴリを追加します。どの層が何を捉えるかは下表のとおりです。
3. Block send if redaction is uncertain — 検出器がすべてを捉えたと確信できない場合、Rephlo はそのまま送信せずにリクエストを保留します。規制のある業務では、この設定こそが秘匿化を「たいていは効く」から「効かなければ止まる」に変えます。

秘匿化の層	捉える対象	必要なもの
パターンマッチング(常時有効)	メールアドレス、電話番号、社会保障番号、クレジットカード情報一式(番号、有効期限、セキュリティコード)	なし — ダウンロード不要
端末内 AI(任意)	氏名、生年月日、住所、およびその他の身分証番号 — 運転免許証、パスポート、国民ID、納税者番号、銀行口座番号	約 1.16 GB のモデルを一度だけダウンロード

銀行口座番号、納税者番号、生年月日はいずれも第 2 層に含まれます。このダウンロードを省略した場合、これらは秘匿化されません。その際 Rephlo は該当カテゴリを「利用不可」と表示し、黙って読み飛ばすことはありません。

Knowledge Spaces

• Space: Product & Policy Terms(金利表、約款、商品説明資料)。
• Space: Regulatory Guidance(通達、監督当局からの文書、社内の解釈メモ)。
• Space: Templates & Approved Language(重要事項説明、謝絶通知の文言、苦情対応のテンプレート)。
• 顧客固有の資料は共有 Space に入れないでください。そうしたファイルは単一の会話に添付します。会話に添付すれば送信時に秘匿化され、インデックスとして保持されることもありません。

主要なコマンド

1. "Plain-Language Explainer"

   • プロンプト: "この条項を、金融の知識がない顧客にも理解できるように書き直してください。重要な条件、手数料、期限はすべてそのまま残してください。義務を弱めたり、原文にない安心材料を加えたりしないでください。"
   • 使い方: 約款の条項、融資条件、重要事項の段落を選択します。

2. "Complaint Response Draft"

   • プロンプト: "この顧客からの苦情に対する回答案を作成してください。指摘された具体的な論点に触れ、確認できた事実を述べ、次の手順を日付とともに示してください。中立かつ事実に即した文体で — 責任を認める表現や、原因についての推測は書かないでください。"
   • 使い方: 秘匿化が有効であることを確認したうえで、苦情の本文を選択します。

3. "Credit Memo Skeleton"

   • プロンプト: "これらのメモを、構成された稟議書にまとめてください: 借入人の概要、資金使途、返済原資、主要なリスク、リスク軽減要因、および結論。メモに記載のない事項は推測せず、「記載なし」と明記してください。"
   • 使い方: 担当者の未整理のメモや面談記録を選択します。

4. "Claims Note Summary"

   • プロンプト: "この保険金請求ファイルを次の形式で要約してください: 何が起きたか、日付、引用されている補償条項、金額、未処理の事項、次のアクション。数値はすべて正確にそのまま保ってください。"
   • 使い方: 請求に関する往復文書や査定担当者の記録を選択します。

5. "Regulatory Change Impact"

   • プロンプト: "この規制改正を読み、次を挙げてください: 何が変わったか、誰に適用されるか、施行日、そして当社のどの業務プロセスに影響しそうか。原文に書かれていることと、あなたが推測していることを分けて示してください。"
   • 使い方: 通達や解釈指針を選択し、Regulatory Guidance の Space を添付します。

6. "Figure Check"

   • プロンプト: "この文書に出てくるすべての数値を、項目名と単位とともに列挙してください。文書内で矛盾しているもの、他の箇所で異なる値として記載されているもの、対象期間の記載がないものを指摘してください。"
   • 使い方: 対外的に出す前の報告書ドラフトを選択します。

ワークフロー例: 顧客の苦情に回答する

1. 確認: Privacy タブで、秘匿化が有効であることと端末内モデルがダウンロード済みであることを確認します。
2. 添付: 苦情のファイルは Space に追加せず、チャットに添付します。
3. 要約: "Claims Note Summary" を実行し、事実関係と日付を確定します。
4. 起案: "Complaint Response Draft" を実行します。
5. 復元: 実際の氏名や口座番号は、自社の正式なシステム上でご自身が入れ直します。秘匿化は送信時にそれらを取り除いています。モデルは最初から受け取っていないため、返すこともできません。
6. 確認: 人が承認します。必ず。

ワークフロー例: スキャン文書と取引明細

届く資料の多くはスキャンです — 署名済みの申込書、撮影された明細、FAX で届いた請求書。

1. 言語設定を確認: Settings ▸ Privacy ▸ Scanned document language は、アプリではなく文書に合わせます。日本語や韓国語のページを誤った設定で読み取ると、使い物にならないテキストになります。
2. スキャンを添付: Rephlo はお使いのコンピューター上でテキストを認識します — 認識のために何かがアップロードされることはありません。長いスキャンは 200 ページを上限にインデックス化され、Partial OCR と表示されます。
3. 画像にも秘匿化が適用されます: 添付画像に個人情報が含まれる場合、その画像は画像のままではなく、秘匿化されたテキストに置き換えられて送信されます。
4. 限界を理解する: OCR が読むのはテキストです。顔、署名、読み取れない手書き文字は捉えられません。それが問題になるスキャンでは Block send if redaction is uncertain を有効にしておけば、Rephlo は読み取れないものを保留します。

リクエストをどこで実行するか

扱う対象	推奨される設定	理由
市場コメント、社内プロセスの下書き	任意のクラウドモデル	顧客データが関与しない
顧客とのやり取り、請求記録	クラウドモデル + 秘匿化 + block-if-uncertain	モデルの性能を活かしつつ、識別子はローカルで除去
未公表の重要情報、案件ファイル	オンデバイスモデル、または Force Local for Sensitive	あなたのコンテンツは一切マシンの外に出ない
大量のポートフォリオデータ、多数の口座番号	ツールの選択を見直す	秘匿化はリクエスト単位であり、データ処理基盤ではない

知っておく価値のある組み合わせ

規制のある業務で多くの人が行き着く設定は、ローカルで秘匿化してからクラウドの大規模モデルを使うというものです。個人を識別する情報はご自身のマシンで取り除かれ、リクエストの残り — つまり本当に高性能なモデルを必要とする部分 — は引き続き大規模モデルに送られます。識別子を渡すことなく、推論の品質だけを最先端モデルから得られます。

もう一方の選択肢、すべてをオンデバイスモデルで実行する方法は、コンテンツをすべてローカルに留められる代わりに、明らかに小さなモデルを使うことになります。何を手放すことになるのかの率直な比較は、オンデバイスモデルとクラウドモデルをご覧ください。

金融サービス向けの実践的なヒント

秘匿化は、あなたの側から元に戻せません

秘匿化はリクエストを保護するものであり、対応表を返してくれるわけではありません。上記のパターンで進めてください: 秘匿化して送信し、構造化された結果を受け取り、識別子はご自身のシステム上で入れ直す。

数値や出典をモデルに創作させない

モデルは、流暢で誤った数値や、実際にはそう書かれていない規制への自信ありげな言及を生成します。すべての数値と出典は、原典と突き合わせるまで未検証として扱ってください。"Figure Check" は矛盾を見つける助けにはなりますが、正しさを保証するものではありません。

履歴の保持期間は意識して決める

Settings ▸ Privacy ▸ History retention では Forever、90 日、30 日、Immediate を選べます。履歴はいつ作業したかを示す有用な記録であると同時に、入力内容の写しでもあります。既定のままにせず、所属組織の保存規程に合う選択肢を選んでください。

エクスポートに鍵は含まれません

Export Data は、コマンド、テンプレート、Spaces、利用履歴を含む ZIP を生成します。API キーや暗号化された秘密情報は意図的に除外されるため、監査に提出したりバックアップとして保管したりしても安全です。

---

次のペルソナ: 法務・コンプライアンス向け、またはビジネスプロフェッショナル向けに戻る。

関連ページ

• プライバシーとデータ — 秘匿化とルーティングの全設定
• オンデバイスモデルとクラウドモデル — ローカルモデルに何ができ、何ができないか
• Rephloがファイルを読み取る仕組み — 添付ファイル、Spaces、スキャン、画像