セキュリティ
最終更新日: 2026年8月29日
「小さな会社が作ったサービスは、セキュリティが不安で使えない」——もっともなご心配だと思います。
ZUBOLAND株式会社は、そのご不安に「大丈夫です」という言葉でお答えするのではなく、実際に何をどうやっているかを全部書くことでお答えします。できていないことも、隠さずに同じページへ記載します。ご判断はお客様にお任せします。
01
カード情報を1件も持っていません
決済はすべてStripeが処理します。当社のサーバーにカード番号は届きません。
02
データベースは日本国内
UNIシリーズ全製品のデータベースを東京リージョン(ap-northeast-1)で運用しています。
03
リリース前に何度も脆弱性監査
系統の異なる2つのAIレビューを、観点を変えて繰り返します(1つの機能に最多8回)。自動検査は、検査自体が動いているかを毎回確かめてから使います。
1. サーバーとインフラ
当社は自前のサーバーを一台も運用していません。すべて、第三者認証を取得した事業者のマネージド基盤の上で動いています。OSのパッチ適用、物理データセンターの管理、ネットワーク防御といった領域は、専門事業者の責任範囲となります。
| 領域 | 利用事業者 | 当該事業者の第三者認証 |
|---|---|---|
| アプリケーション実行基盤 | Vercel | SOC 2 Type 2 / ISO 27001 |
| データベース・認証基盤 | Supabase(PostgreSQL) | SOC 2 Type 2 / ISO 27001 |
| DNS・WAF・CDN | Cloudflare | SOC 2 Type II / ISO 27001 |
| 決済 | Stripe | PCI DSS Level 1 |
| メール配信 | Resend | SOC 2 Type II(基盤のAWSは ISO/IEC 27001 等を取得) |
※ 上記は各事業者が取得している認証であり、当社自身が取得しているものではありません(第8章をご覧ください)。
2. データの保管場所と暗号化
保管場所
UNIシリーズ全製品のデータベースは、すべて東京リージョン(ap-northeast-1)に配置しています。お客様が入力されたコンテンツ、アカウント情報、利用履歴は、この国内のデータベースに保存されます。
ただし、機能の性質上、一部の情報は外部の委託先で処理されます。メール配信(Resend)、決済(Stripe)、外部アカウント連携(Google / Apple / Meta / LINE)、およびAI機能(OpenAI等)をご利用の場合、当該処理に必要な範囲の情報が各社の基盤(日本国外を含む)で取り扱われます。詳細はプライバシーポリシーに記載しています。
暗号化
- 通信時:全ドメインでHTTPS(TLS)を使用します。平文のHTTP接続は自動的に暗号化通信へ転送されます
- 保存時:データベースおよびストレージはディスクレベルで暗号化されています(AES-256)
- パスワード:平文で保存していません。ソルト付きのハッシュ(bcrypt)として保存されるため、当社側からも元のパスワードを見ることはできません
バックアップ
データベースは基盤事業者による自動バックアップの対象です。
3. アカウントとアクセス制御
ログイン
認証にはSupabase Authを利用しています。メールアドレスとパスワードのほか、Googleアカウント・Appleアカウントでのログイン、メール内リンクによるログインに対応しています。パスワードを覚えていただく必要がない分、使い回しによる被害の連鎖を防ぐことができます。
データの分離(マルチテナント)
「他のお客様のデータが見えてしまう」事故を防ぐため、当社ではアプリケーションのコードだけに頼らず、データベース自身に行単位のアクセス制御(PostgreSQL Row Level Security)を設定しています。
これは、仮にアプリ側のコードに不具合があったとしても、データベースが「その組織の行以外は返さない」と拒否する仕組みです。アプリ層のチェックだけではAPIを直接呼び出された場合に迂回される可能性があるため、当社は最後の砦をデータベース側に置いています。
権限昇格の防止
管理者権限で動作するデータベース関数は、公開ロールからの直接呼び出しを明示的に禁止し、サーバー側からのみ実行できるよう制限しています。また「1回しか実行してはいけない処理」は、アプリ側の条件分岐ではなくデータベースの条件付き更新によって排他制御しています(同時に大量のリクエストを受けても二重に実行されません)。
レート制限
ログイン、新規登録、招待などの重要な入口には、短時間の大量リクエストを遮断するレート制限を設けています。
4. お支払い情報
クレジットカード情報は、お客様のブラウザからStripeへ直接送信されます。当社のサーバーを経由せず、当社のデータベースにも保存されません。当社が保持しているのは、Stripeが発行する顧客IDと、サブスクリプションの状態(有効/停止など)のみです。
したがって、万が一当社のデータベースから情報が流出したとしても、そこからカードが不正利用されることはありません。
5. 開発・リリースのプロセス
系統の異なる2つのAIで監査する
重要な機能変更やセキュリティに影響する変更については、リリース前に系統の異なる2つのAIレビュー(Anthropic Claude / OpenAI Codex)へ、それぞれ独立してコード監査を行わせています(緊急の障害対応など、事後の確認となる場合があります)。両者の指摘が重複しないケースが多く、片方だけでは見落としが発生することを実測で確認しているためです。
「2つ通して終わり」にはしません
実際の運用は、2系統を1回通して合格、ではありません。観点を変えて、新しい指摘が出なくなるまで同じ機能を何度も監査します。「権限の境界」「同時アクセスの競合」「表示と実装の一致」「監査で入れた修正そのもの」というように見る角度を変えると、そのたびに前の回では出てこなかった欠陥が出てくるためです。
| 社内の監査記録(2026年7月18日〜8月29日) | 件数 |
|---|---|
| 作成した監査報告書 | 61本 |
| 監査を実施した延べ回数 | 113回 |
| 同じ機能を2回以上監査したもの | 31本(報告書全体の半数以上) |
| 同じ機能を3回以上監査したもの | 10本 |
| 1つの機能に対する最多 | 8回(決済と権限付与の導線) |
最も回数を要した決済まわりの監査では、8回で通算38件を修正しました。この案件では、2つのAIの指摘はほとんど重なりませんでした(6回目の時点で、両者が独立に同じ欠陥へ到達したのは1回のみ)。片方だけで済ませていれば、残りは見逃していたことになります。
8回目に監査したのは、それまでの指摘を直すために書いたコードそのものです。そこからも新たな欠陥が見つかりました。修正は安全側に倒れるとは限らないため、「修正のための修正」も監査の対象から外していません。
この工程で、実際にアクセス制御の不備・競合状態・情報の露出といった問題を検出し、修正しています。「見つかっていないから安全」ではなく、「探して直している」状態を維持することを方針としています。
検査する道具そのものを、毎回検査します
人が読むレビューとは別に、脆弱性のパターン照合と、AIによるコード解析を自動で走らせています。変更した差分だけでなく、コードベース全体に当てます。
ただし当社は、この手の検査が返す「指摘0件」をそのままでは信用しません。検査の道具は、うまく動かなかったときにエラーを出さず、正常に「0件」と答えてしまうことがあるためです。そうなると「探して見つからなかった」と「そもそも探していなかった」が同じ結果に見えます。
そこで、わざと脆弱性を仕込んだコードを食べさせ、その道具が実際に検出できることを確かめてから、本物のコードに当てています。落ちるべきときに落ちない道具は、通ったことの証明になりません。
| 2026年8月29日に実際に起きたこと | |
|---|---|
| 自動検査の結果 | 指摘 0 件 |
| わざと脆弱性を入れたコードで確認 | やはり 0 件(=検査が動いていなかった) |
| 原因 | 認証情報が渡っておらず、道具がエラーを出さずに空の結果を返していた |
| 正しく動かし直した結果 | 仕込んだ脆弱性を 4 件とも検出 |
| 本物のコードに当てた結果 | 実在の不具合を検出 → 同日中に修正・本番反映 |
この日に見つかった不具合は、管理画面から登録するデザイン用のCSSを通じて、ページに意図しないコードを埋め込める余地があったというものです。修正後は、実際にブラウザ上で「修正前は動いてしまい、修正後は動かない」ことを確認したうえで公開しています。直したと書くだけでなく、直る前と後の両方を実機で測ります。
修正の方針
脆弱性を1件発見した場合は、同じ型の問題が他の経路にも存在しないかを全体検索で洗い出し、まとめて修正します。表面的な対症療法は行いません。
秘密情報の管理
APIキーやアクセストークンをソースコードへ直接記述することを禁止しています。すべて実行環境の環境変数として管理し、公開リポジトリには含めていません。
6. デスクトップアプリの安全性
KUZIRA・UNICREWなど、お客様のPCへインストールしていただくアプリについては、次の対応を行っています。
- コード署名:Windows版は「ZUBOLAND株式会社」の法人名義でデジタル署名しています。ダウンロードされたファイルが当社の配布物であり、途中で改ざんされていないことをOSが検証できます
- 公証(Notarization):macOS版はAppleの公証を通しています
- データの保存場所:閲覧履歴などのローカルデータはお客様のPC内に保存され、当社サーバーへは送信していません
- パスワードをお預かりしません:他社サービスのログイン情報を代行保管する機能は設けていません
- 接続端末の遠隔解除:PCを紛失された場合に備え、Webの管理画面から接続済み端末を無効化できます
7. 従業員と業務端末の管理
当社は少人数で運営しています。お客様のデータへアクセスできる管理者アカウントは限定し、すべて二要素認証を有効にしています(Supabase / Vercel / Stripe / GitHub / Cloudflare 等)。
お客様がサービスへ保存されたデータの中身を、サポート対応など明確な必要がないかぎり閲覧することはありません。
8. まだできていないこと
信頼していただくために、足りない部分も明記します。導入をご検討の際は、以下を前提にご判断ください。
| 項目 | 現状 |
|---|---|
| SOC 2 / ISO 27001 等の第三者認証 | 未取得です。当社が利用する基盤事業者は取得していますが、当社自身は取得していません |
| 外部専門機関によるペネトレーションテスト | 未実施です。現在は前述の反復的なAI監査と自主点検で代替しています |
| バグバウンティプログラム | 実施していません。ご報告は第9章の窓口で受け付けています |
| 24時間365日の有人監視 | 行っていません。基盤事業者の自動アラートによる検知と、営業時間内の対応となります |
| SAML SSO / SCIM 連携 | 未対応です。大企業のID基盤との統合が必須の場合はご利用いただけません |
| 災害復旧訓練(RTO / RPO の定義) | 数値目標としては未定義です |
| 稼働率のSLA保証 | 契約上の保証は行っていません |
これらは順次整備していく方針です。現時点で高度な統制が必須の用途(機微な医療情報の取扱い、金融の基幹業務など)には、当社サービスは適しません。
9. 脆弱性のご報告について
当社サービスに脆弱性を発見された場合は、公表の前にご一報ください。真摯に対応いたします。
対応の目安
- 受領のご連絡:3営業日以内
- 影響範囲の確認と初期回答:7営業日以内
- 重大な問題については、確認でき次第ただちに修正へ着手します
ご報告くださる方へのお約束(セーフハーバー)
以下をすべて守り、善意かつ必要最小限の範囲で行われた脆弱性調査について、当社は原則として法的措置を求めません。
- 他のお客様のデータを閲覧・改変・削除しない(ご自身のアカウント内で検証してください)
- サービスの可用性を損なう行為(負荷試験、DoS等)を行わない
- ソーシャルエンジニアリング、物理的侵入、当社従業員への攻撃を行わない
- 発見された内容を、修正が完了するまで第三者へ開示しない
※ 法令に違反する行為、第三者に被害を及ぼす行為、データの取得・改変・削除を伴う行為については、上記の対象外となります。
ご希望があれば、修正完了後に謝辞としてお名前を掲載いたします。金銭的な報奨金制度は現在ありません。
10. 問題が起きたときの対応
お客様の個人データに影響する事故が発生した場合、当社は次の対応を行います。
- 被害の拡大を止めるための緊急措置(該当機能の停止、アクセス遮断等)
- 影響範囲の特定
- 影響を受けた可能性のあるお客様への、把握でき次第の個別のご連絡
- 個人情報保護委員会への報告(法令で定められた場合)
- 原因と再発防止策の公表
「調査中だから何も言わない」という対応は取りません。二次被害の防止、証拠の保全、監督官庁や関係機関との調整に配慮したうえで、分かっている範囲を、分かった時点でお伝えします。
11. お問い合わせ
ZUBOLAND株式会社
セキュリティに関するご報告: security@zuboland.jp
その他のお問い合わせ: contact@zuboland.jp
所在地: 〒151-0051 東京都渋谷区千駄ヶ谷5-27-3 やまとビル8階
法人番号: 6011001177977
関連: プライバシーポリシー / 利用規約
改定履歴
- 2026年8月19日:初版を公開