はじめに
私たちは普段、お客様のデータをこちら側で直接さわることはほぼありません。SaaS 事業者として、お客様自身がアプリケーションで操作する形が基本だからです。
それでも、サポートの中で「どうしても再現できない不具合」「数字が 1 円ズレるが原因が分からない」といった場面は現実に起こります。そのときに、お客様から実データを受領して、私たちの環境で再現を試みる場面が生じる可能性があります。
このとき、お客様の同意を取ったから OK で済ませてはいけないと考えました。
なぜなら、会計データには お客様の取引先の個人情報・取引情報 が含まれているからです。お客様がご自身のデータを我々に開示することにご同意くださっても、お客様の取引先が「私の会社名と取引額が niyase に渡る」ことに同意したわけではない、という構造的な問題があります。
この記事では、ベータリリース直前に整備した「顧客データ受領フロー社内 SOP」を、対外的にも公開します。社内文書をそのまま公開する意図は、お客様に確認していただける形にすること自体が信頼の担保になる と考えるからです。
なぜ会計データは「特別に重い」か
個人情報を扱う SaaS はたくさんあります。多くの場合「お客様の同意があれば、お客様の情報をいただいて作業できる」というロジックで動きます。
ところが会計データは違います。
「お客様の会計データを 1 ファイル受領する」ということは、同時に以下も受領していることを意味します。
- お客様が取引している 取引先 (株式会社 A、合同会社 B 等) の社名・取引金額・取引日付
- お客様が雇用している 従業員の給与額・氏名
- お客様の 取引銀行・口座情報
- お客様の取引先が発行した 適格請求書番号 (T+13 桁)
つまり 1 ファイルが、お客様 1 社 × その関係者数十社 × 関係者の従業員 × 取引履歴、という多重の個人情報・営業秘密の塊です。
お客様ご自身が「我々に渡すことに同意」できても、お客様の取引先や従業員が「お客様の会計ソフト事業者 (niyase) に自分の情報が渡る」ことに同意しているとは限りません。実際には、契約条項の中で「ベンダーへの開示は法的にカバーされている」ことが多いですが、それでも 私たちがそのデータを保持し続けたり、不用意に外部 (LLM 等) に流したりすれば、その契約の枠を簡単に超えてしまいます。
この感覚を社内全員が持つために、SOP を文書化しました。
11 のルール (要約)
1. まず実データを受け取らない方法を探す
最優先は「お客様の実データを受領しないで済む方法」です。
- 匿名化済みのサンプルで再現を試みる
- お客様の画面共有 (録画なし、コピー禁止) で目視確認のみ行う
- お客様自身に手元で検証していただく
これらで解決すれば、そもそも個人情報の所在が移動しません。
2. NDA 締結と顧客同意の二段確認
それでも実データが必要な場合、
- NDA 締結済 であることの確認
- お客様への 書面 (Slack ログ等で残る形式) での同意取得
- 取得した同意の内容には「貴社の取引先データも含まれることをご了承いただいている」「貴社の責任で開示いただける契約上の整理ができている」を明示
3. 暗号化チャネル経由でのみ受領
許可: Signal (E2E 暗号化) / GPG 暗号化メール / お客様環境のリモート画面共有
禁止: パブリックな共有リンク (S3 / GCS) / Gmail 平文添付 / Slack のパブリックチャンネル / GitHub の Issue や PR / SNS 系メッセンジャー
4. ローカルマシン上の隔離フォルダに配置
Git のバージョン管理対象から除外されるフォルダ (.gitignore 配下) に固定配置。iCloud / Dropbox 等のクラウド同期は OFF にしておきます。
5. 24 時間以内に匿名化版を生成
受領後 24 時間以内に、お客様の情報を含む実データから、取引先名・個人名・摘要内容 を機械的に置換した匿名化版を生成します。以降の作業は基本この匿名化版で進めます。
匿名化は SHA256 ハッシュベースの決定論的置換で、復元不能 に設計しています (詳細は別記事で書きます)。
6. 匿名化版でも再現できない場合の追加ルール
特定の取引先名や摘要文字列に依存するバグの場合、匿名化版では再現できないケースがあります。このときのみ実データを直接見ますが、以下を守ります。
- 作業はローカルマシンのみ (共有サーバ・共有 VM 禁止)
- スクリーンショット撮影禁止 (Mac の Screenshots フォルダや iCloud Photos に残る)
- 画面共有禁止 (録画されると永続化する)
7. LLM (Claude Code 等) の取り扱い
これが現代特有の重要ルールです。
- LLM への prompt に実データを コピー & ペースト しないこと
- 必要な場合は匿名化版を投入する
- 機密文字列を含む prompt は AI 提供事業者の session log に残る可能性があります
社内では Claude Code を日常的に使っていますが、実データを置いた作業ディレクトリを LLM の参照範囲から外し、LLM が読み取れるディレクトリを明示的に絞る、というルールを徹底しています。
8. 最大保管期間 30 日
受領日から 30 日が最大保管期間です。バグ修正完了次第、それより前でも即破棄します。
9. securely delete + 顧客通知
破棄は単純な rm -rf ではなく、ローカルの Trash も emptied して復元不能化します。完了後、お客様にチケットを通じて「破棄完了報告」を行います。
10. 監査ログを 90 日保持
受領日・破棄日・担当者・データ種別・お客様同意取得の記録 (Slack URL 等) を社内ログに記録します。本人特定情報ではなく メタデータ のみで、90 日で自動削除されます。
11. 顧客が同意しない場合の代替案
お客様が「他社事業者にデータを渡すことに同意できない」とおっしゃる場合、私たちが匿名化ツールをお客様自身の手元で実行いただける形にすることで、機密情報を含まない再現データだけを共有いただく選択肢を用意します。
これでも再現できなければ、私たちは 「再現不能のため修正困難」と正直にお伝えします。虚構の修正よりも、誠実な報告のほうを選びます。
なぜここまでやるのか
技術的には、もっと簡単な運用も組めます。「同意があれば受領、作業後は削除」程度のシンプルな SOP でも、多くの会社は問題なく回っているはずです。
それでも私たちが 11 ステップに細かく分けて明文化した理由は、お客様の取引先・お客様の従業員という、私たちとは直接接点のない方々の情報を扱っている という事実を、社内で誰一人忘れないようにするためです。
niyase は「責任ある経営」を哲学の中心に据えています。これは大企業特権ではなく、規模を問わず、振る舞いとして体現できる方針です。受領 SOP の細かさは、その振る舞いの 1 つの現れです。
おわりに
このフローを使う場面が来ないことが、私たちにとっても、お客様にとっても、お客様の取引先にとっても最善です。
それでも、もし発生したときに「ちゃんと考えられたルールに沿って扱われる」と信頼していただける状態を作っておきたい。それが本記事の意図です。
社内 SOP の本体は社内ドキュメントとして保管しており、必要に応じて詳細をご確認いただけます。ご相談はサポート窓口までお寄せください。
ISO 27001 / SOC 2 Type II の認証取得を準備中ですが、認証以前に、こうした日々の運用の質を積み上げていくことを大切にしたいと考えています。