Contriは「事業の数字」というセンシティブな情報をお預かりするサービスです。セキュリティは「実装している」だけでなく、お客様に「見える形で明示」してこそ意味があると考えています。
1. データ保護
暗号化
| 対策 | 方式 | 備考 |
|---|---|---|
| 通信暗号化 | HTTPS（TLS 1.3） | 全通信を暗号化 |
| 保存時暗号化（ディスク） | AES-256 | データベースのディスクレベル暗号化 |
| 外部サービストークンの暗号化 | アプリケーション層の暗号化 | MoneyForward 等の外部連携トークンを、ディスク暗号化に加えてアプリケーション側でも当社の鍵で暗号化する二重防御を採用しています |
| レシート画像の非保存 | AI サービスへの直送のみ | レシート画像は OCR (光学文字認識) 処理時のみ AI サービスに直接送信し、当社サーバーには永続保存しません。保存しないため、保存先からの流出や不要ファイルの残存といった経路を構造的に排除しています |
| パスワード | bcryptハッシュ | 復号不可能。当社スタッフも閲覧不可 |
アクセス制御
| 対策 | 詳細 |
|---|---|
| 利用者ごとのデータ分離 | データベースのすべてのデータに対し、ある利用者のデータには他の利用者が一切アクセスできないよう、システムレベルで分離しています |
| 二段階認証（2FA/MFA） | TOTP（Google Authenticator等）対応。設定画面から有効化できます |
| パスワードポリシー（オーナーアカウント） | NIST SP 800-63B Rev4 準拠。最低8文字、ASCII印字可能文字。MFA併用時の十分性確保を前提とし、複雑性ルール（記号必須等）の強制および定期変更の強制は行わない（NIST 最新推奨） |
| メンバーアカウントのパスワード要件 | タイムカード PWA のメンバーアカウントは最低 10 文字を要求。オーナーが招待時に強度の高いパスワードを設定することで、リスト型攻撃・推測攻撃に対する耐性を確保 |
| パスキー（WebAuthn） | 中期ロードマップとして対応検討中。フィッシング耐性を持つ FIDO2 認証への段階的移行を予定 |
| 漏洩パスワード検出 | HaveIBeenPwnedデータベースと照合し、過去に漏洩したパスワードの使用を防止 |
| 管理者権限を持つ処理の分離 | 管理者権限を持つ内部処理を、外部から任意のパラメータで呼び出せないよう構造的に分離し、他の利用者のデータを不正に読み取られるリスクを防止しています |
| Origin 検証（CSRF 多層防御） | データを変更する主要な操作について、リクエストの送信元を検証し、許可した送信元以外からのリクエストを拒否します。Cookie 単独に依存しない多層防御です |
| 外部サービス連携 | OAuth 2.0 による認可。なりすまし（CSRF）を防ぐ検証を行い、トークンはサーバー側のみで保持してブラウザには一切渡しません。読み取り専用の権限のみを使用します |
| パスワード変更時の再認証 | 最終ログインから24時間経過時は再ログインを要求（セッション乗っ取り対策） |
| パスワード変更時の現パスワード確認 | 変更時に現在のパスワード入力を必須化（攻撃者がセッションを盗んでも変更不可） |
| メンバーアカウントのセッション維持 | タイムカードのメンバーセッションは、有効期限を設けたトークンで管理します。トークンはそのまま保存せずハッシュ化して保管し、利用のたびに自動更新します。明示ログアウト時や不正検知時は、オーナーが全端末で即時無効化できます |
| 退会フローと論理削除管理 | Free ユーザーは設定画面の確認モーダルでチェックボックスに同意して退会し、退会完了メールで通知します。Pro / Ultra は Stripe Customer Portal で解約し、Free 降格後に退会します。退会後 30 日間は論理削除状態としてログインと通常アクセスを遮断し、support@contri.jp 経由で復元できます。30 日経過後は自動処理でデータを完全に削除します（レシート画像は当社サーバー上に永続保存しない設計のため、削除対象には含まれません） |
通信セキュリティ
| 対策 | 詳細 |
|---|---|
| Content Security Policy（CSP） | XSS攻撃を防止する厳格なポリシーを設定 |
| X-Frame-Options | DENY — クリックジャッキング攻撃を完全に防止 |
| X-Content-Type-Options | nosniff — MIMEタイプスニッフィングを防止 |
| Referrer-Policy | strict-origin-when-cross-origin — リファラー情報の漏洩を最小化 |
| Permissions-Policy | カメラ・マイク・位置情報へのアクセスを無効化 |
デプロイメント保護
| 対策 | 詳細 |
|---|---|
| Preview デプロイメント認証 | 本番以外のデプロイメント（開発中機能の確認URL）はVercel認証必須。第三者がURLを入手してもアクセス不可 |
2. インフラストラクチャ
| サービス | 認証 | データ所在地 |
|---|---|---|
| Supabase | SOC 2 Type II + ISO/IEC 27001:2022 | 東京 |
| Vercel | SOC 2 Type II | 東京 |
| Stripe | PCI DSS Level 1 | セキュアサーバー |
毎日自動バックアップ（7日分保持）。Point-in-Time Recovery（PITR）対応可能（必要に応じて有効化）。
ソースコード・シークレット管理
近年、同業の SaaS 事業者でも GitHub アカウントへの不正アクセス起因のインシデントが発生しています。当社はソースコードリポジトリと API キー・秘密鍵の管理を分離し、いずれか一方の流出だけでは本番データに到達できない設計としています。
| 対策 | 詳細 |
|---|---|
| 環境変数のSensitive保管 | 全APIキー・秘密鍵はVercel Sensitive Environment Variablesで格納。当社スタッフおよびVercelスタッフも閲覧不可。ソースコード内には一切ハードコードしない |
| GitHub組織のMFA必須化 | 当社GitHub組織の全メンバーに対してMFAを必須化。リポジトリへの直接 push は Branch Protection により制限 |
| シークレットスキャン | GitHub Secret Scanning による push 前検知、ならびに Dependabot による依存パッケージ脆弱性監視を有効化 |
| サーバー専用処理の分離 | データベース管理権限を持つ処理や決済処理を、お客様のブラウザ側から呼び出せないよう構造的に分離し、誤って公開される経路をビルド時に検知・防止しています |
| キーローテーション | 漏洩・不審兆候発見時は速やかに新キー発行・旧キー即時無効化。定期的なローテーションも実施 |
| 業界事例の継続監視 | 同業 SaaS のインシデント公表を常時参照し、適用可能な再発防止策を当社運用に取り込む |
エラーログの秘匿情報マスク
エラー監視ツールに送信される情報は、送信前に再帰的にスキャンし、秘匿情報を自動的にマスクします。マスク対象には、認証情報（トークン・Cookie 等）、API キー・秘密鍵、決済関連の機微情報、そしてお客様の金額・勘定科目名などの財務情報が含まれます。エラーメッセージの本文やお客様の操作履歴も対象です。開発者が意図せず機微情報を含めてしまった場合でも、送信前に構造的にマスクする設計です。
利用者を識別する必要がある場合も、送信するのは内部的な識別子のみに限定し、氏名・メールアドレス等の個人情報は送信しません。また、エラー発生時にお客様の会話内容や仕訳の生データ・データベースのエラー詳細を平文で残さず、エラーの種別を示す符号のみを記録します。万一これらの記録が第三者の手に渡った場合でも、財務情報や個人情報が読み取られないようにする、データ最小化の措置です。
3. AI機能のデータフロー
✓送信されるデータ
- 仕訳データ（金額、勘定科目名）
- お客様の質問文
- レシート画像（OCR利用時のみ、当社サーバーには永続保存せず AI サービスへ直接送信）
✕送信されないデータ
- パスワード
- メールアドレス
- クレジットカード情報
- 他のユーザーのデータ
Google・OpenAI・Anthropicともに、API経由で送信されたデータをAIモデルの学習に使用しません。AI機能の利用は任意です。
AIリサーチ機能の外部サービス
AIが業界情報・最新トレンド等の調査を必要と判断した場合、以下の検索・取得系APIを利用します。
Tavily（米国）
AI最適化されたWeb検索API
- 送信: 一般的な検索クエリのみ
- 非送信: 仕訳データ・個人情報
- APIキー認証による通信
Jina AI（シンガポール）
公開WebページのMarkdown変換API
- 送信: AIが選択した公開URL
- 非送信: 仕訳データ・個人情報
- HTTPS通信
これらのリサーチAPIには、ユーザーの仕訳データ・個人情報は送信されません。AIが質問から抽出した一般的な検索語（例：「SaaS業界 CPH 平均」）と、取得対象の公開URLのみを送信します。
AIセキュリティ対策（OWASP LLM Top 10 / IPA 10大脅威 2026 対応）
IPA 情報セキュリティ10大脅威 2026 において「AIの利用をめぐるサイバーリスク」が組織編 3 位に初登場するなど、生成 AI 利用に固有のリスクへの対応が事業者の責務となっています。当社は OWASP Top 10 for LLM Applications および OWASP Top 10 for Agentic Applications 2026 を設計時の参照基準とし、以下の多層防御を実装しています。
| 対策 | 詳細 |
|---|---|
| プロンプトインジェクション対策 | ユーザー入力とシステム側の指示を明確に分離し、ユーザー入力に含まれた指示で AI の動作方針が書き換えられない設計。AI の出力も検証します |
| 操作範囲のスコープ制限 | AI が扱えるのは、現在ログイン中のご本人のデータに対する操作のみに限定。他の利用者のデータには構造的に到達できません |
| AIリサーチの読み取り専用境界 | AIリサーチ機能は外部公開 Web の読み取りに限定。AI が外部サービスへ書き込みを行ったり、認証情報を持ち出したりすることはできない構造 |
| 送信前マスク | パスワード・メールアドレス・クレジットカード情報等は、AI へ送信する前にフィルタリングします |
| 応答品質の多層検証 | 複数の段階で AI 応答の品質と整合性を確認します |
| 濫用・経済攻撃対策 | AI 機能の濫用や、過剰な利用でコストを枯渇させる攻撃を防ぐため、利用状況に応じた上限を設定します |
| 会話履歴の検証 | AI に渡す会話履歴を検証し、攻撃者が不正な指示を混入して本来の動作方針を書き換えるインジェクション攻撃を防止します |
| 外部取得情報の扱い | AI が外部から取得した情報を、そのまま根拠にお客様のデータを勝手に書き換えることはできない設計を採用しています |
| 内部システム情報の漏洩防止 | AI 機能でエラーが発生した場合でも、サーバー内部の構造情報（ファイルパス・内部名称・技術的詳細）を、お客様画面や AI の応答に出さない多層防御を実装しています |
4. 決済セキュリティ
クレジットカード情報はStripeが直接処理します。当社のサーバーを経由しません。StripeはPCI DSS Level 1（決済セキュリティの最高基準）に準拠しています。
2025年3月31日以降、PCI DSS は v4.0 への完全移行が必須となりました。当社は Stripe Checkout を採用しており、カード番号・有効期限・セキュリティコードはお客様の端末から Stripe のセキュアサーバーへ直接送信され、当社のサーバーやデータベースを一切経由しません。当社が保持するのは Stripe から発行される顧客ID・サブスクリプションIDのみで、これは PCI DSS の SAQ A（最も低リスクなマーチャント区分）に該当する構成です。
無料トライアルの重複付与防止
初回登録時の 30 日無料トライアル（Pro 月額プラン）に対して、重複付与を防止しています。登録情報（メールアドレス。表記のゆれを平準化して照合します）と、決済事業者側のお客様・契約履歴の両面から、過去にトライアルを利用していないかを確認し、いずれかで検出された場合は再付与を行いません。この判定はすべての申込経路で共通に適用し、利用規約「アカウントの単一性」と整合した運用を実現しています。
さらに、定期的に、同一のお支払い手段が別のアカウントで重複して使われていないかを検知し、当社運用者へ通知します。是正は運用者の判断で行い、自動的な権限変更は行いません。判定に必要な確認ができない場合は、安全側に倒してトライアル付与を停止する設計とし、誤付与を防止しています。
5. メール認証（送信ドメイン認証）
| 仕組み | 目的 |
|---|---|
| SPF | 当社が contri.jp ドメインから送信するメールの送信元IPを認証DNSに公開し、なりすまし送信を防止 |
| DKIM | 送信メールに当社秘密鍵による電子署名を付与。受信側で改ざんとなりすましを検証可能 |
| DMARC | SPF・DKIMの検証結果に基づいて受信側に処理ポリシー（拒否・隔離・通過）を指示するDNSレコードを公開 |
contri.jp ドメインから送信される認証メール・通知メールは、これら3つの送信ドメイン認証技術により真正性が保証されています。
6. データベース内部処理のセキュリティ
データベース側で動く処理に対しても、以下の考え方で安全性を確保しています。
| 対策 | 内容 |
|---|---|
| 最小権限の原則 | 特別な権限が必要な処理は必要最小限にとどめ、処理のたびに「誰の操作か」を厳密に検証してから実行します |
| 実行範囲の固定 | 内部処理が意図しない範囲のデータにアクセスできないよう、実行範囲を明示的に固定し、権限昇格を狙う攻撃を防止します |
| 退会処理の安全な直列化 | 退会後の完全削除は、二重実行や競合が起きないよう排他制御のうえで実行し、途中で中断しても安全に再開できる設計です。時間がかかる稀なケースでは当社運用者が個別に対応します（レシート画像は当社サーバー上に永続保存しない設計のため、削除対象に含まれません） |
| 外部監査ツールの活用 | データベース基盤が提供するセキュリティ警告を定期的に確認し、指摘がある場合は速やかに是正します |
7. APIレート制限
不正な大量リクエストおよびコスト枯渇攻撃（Denial of Wallet）からサービスを保護するため、機能ごとに、利用状況に応じた上限を設定しています。AI チャット・レシート OCR・決済など、コストや不正リスクの高い操作には、それぞれ適切な回数上限を設けています。上限を超えた場合は一時的に制限し、再試行までの待機時間をご案内します。
8. セキュリティ運用（多段レビュー）
当社のセキュリティ実装は、単一の視点だけでは見落としが起こり得る前提で運用しています。重要な変更やセキュリティ改修の際は、内部レビューに加えて独立した第三者視点での検証を経てから本番へ反映する多段レビュー体制を採用しています。重大なセキュリティ改修については、この検証を経るまでリリースしません。
9. インシデント対応
万が一、セキュリティインシデントが発生した場合:
初動対応
影響範囲の特定と被害拡大の防止。必要に応じてユーザーセッションの即時無効化・漏洩したAPIキーのローテーションを実施
お客様への通知
影響を受けるお客様に、判明後72時間以内にメールで通知
原因調査
根本原因の調査と再発防止策の策定
監督官庁への報告
個人情報保護委員会への報告（法令に基づき必要な場合）