- 『一律50万円』にてご要望のアプリ/システムの土台開発!
- Click・Larkを活用したノーコード開発
代表 西澤志門との無料相談の予約
- ノーコード開発のご相談
- どのノーコードツールが最適なのか知りたい
- 補助金の活用相談 など
是非ともざっくばらんにお話ししましょう!お気軽にご相談ください。
結論:クラウド鍵を“自社で握る”+運用ガバナンスを徹底すれば、実務上のリスクは十分抑え込める。
ビジネスツールの選定において、機能性やコストパフォーマンスと並び、セキュリティは最重要項目の一つです。特に「Lark」のように海外に開発拠点を持つSaaSに対して、「中国の法律が関連するのでは?」という懸念を持つ方も少なくありません。
しかし、Larkは以下の画像の一覧にあるように、既に国土交通省やAWSなどをはじめとする幅広い業界から国際的な認定を受けています。
この記事では、国際的な認定を受けている理由、Larkが提供する具体的なセキュリティ機能、そしてリスクを管理しながら安全に活用するための実践的なフレームワークまでを、公開情報を基に網羅的に解説します。

1. はじめに:なぜ“中国産SaaS”が懸念されるのか
この問題の核心には、中国独自の法律が存在します。
1‑1 国家情報法・サイバーセキュリティ法の基礎
特に注目されるのが、2017年に施行された中国国家情報法です。その第7条は「すべての組織・個人は、法に基づき国家の情報活動に協力する義務を負う」と明記しています。
この「協力」の範囲は曖昧で、政府からの要請があれば、中国企業は海外子会社や海外サーバーに保管されているデータに対してもアクセスを提供する義務が生じる可能性が議論されています。これが、「親会社が中国籍=データが抜かれるのでは?」という懸念の根強い理由です。
1‑2 LarkとFeishuは“法人もインフラも別物”
では、Larkはこの懸念にどう応えているのでしょうか。
最も重要なのは、私たちが利用するグローバル版の「Lark」と、中国本土版の「Feishu(飛書)」は、運営法人もインフラも完全に分離されているという事実です。
比較項目 | Lark(海外版) | Feishu(中国本土版) |
運営法人 | Lark Technologies Pte. Ltd.(シンガポール) | Beijing Feishu Technology Co., Ltd. |
データ保管 | AWS 東京 & シンガポール | 中国本土 IDC/アリクラウド |
適用法域 | シンガポール法・GDPR・APPI(個人情報保護法)等 | 中国本土法 |
ポイントは、Larkのデータは日本(AWS東京リージョン)及びシンガポールのAWSリージョンに限定して保管され、中国本土へ物理的にコピーされない設計になっている点です。
(出典: Lark公式サイト「Data Security and Compliance」)
とはいえ、親会社がByteDanceであることは事実です。法的な分離だけでは拭えない懸念を解消するには、技術的な鍵管理と厳格な運用ガバナンスが欠かせません。
2. Larkを“安全”たらしめる数々の仕組み
Larkは、法的な分離に加え、技術的な多層防御によってデータの安全性を担保しています。その代表的な仕組みを見ていきましょう。
2‑1 AWS基盤+ISO / SOC 認証
Larkのサービスは、信頼性の高いAWSの東京(ap‑northeast‑1)およびシンガポール(ap‑southeast‑1)リージョンで冗長化運用されています。 さらに、ISO 27001 / 27018 / 27701、SOC 2 Type II、SOC 3 といった多数の国際的な第三者認証を取得済みです。これらの証明書は公式の「Trust Center」で公開されており、Larkがグローバル基準のセキュリティ管理体制を維持していることが客観的に証明されています。
2‑2 多要素認証・RBAC・AI監視
認証セキュリティはゼロトラストの考え方が前提です。パスワードレスを実現するPasskey(FIDO2)やワンタイムパスワード(TOTP)による多要素認証に標準で対応し、不正アクセスを入り口で防ぎます。(出典: Larkヘルプセンター)
また、アクセス権限管理(RBAC)は、単なる役職ベースではなく、ドキュメントやデータベースの個々のオブジェクト単位まで細分化して設定可能です。 加えて、AIによる異常検知モデルがユーザーの行動パターンを常時スキャンし、不審な動きを検知した際は管理者に通知する仕組みを備えています。
2‑3 BYOKと鍵の定期ローテーション
データ暗号化はセキュリティの最後の砦です。LarkのPro/EnterpriseプランではBYOK(Bring Your Own Key)に対応しており、暗号化の鍵そのものを顧客が管理する自社のAWS KMS(Key Management Service)内に保管できます。この仕組みにより、Lark側ですら顧客データにアクセスできない状態を作り出せます。
(出典: Lark管理者ガイド) デフォルト設定の場合でも、暗号鍵はLarkのポリシーに基づき年次などで定期的にローテーション(更新)され、証跡が管理されています¹。
¹ BYOK利用時、鍵の作成・ローテーション・失効といった操作の証跡は、顧客が管理するAWS CloudTrailのログで詳細に追跡できます。Larkのデフォルト鍵に関する詳細なログ取得の仕様は、個別にご確認ください。
2‑4 AI異常検知とSIEM連携
Larkは、AIを活用した異常検知(Anomaly-based detection)の仕組みを備えています。これは、ユーザーの操作ログ、アクセスパターン、ネットワーク指標などを分析し、普段と異なる振る舞いを検知すると管理者にアラートを通知するものです。
さらに、検知したセキュリティ関連のイベントは、外部のSIEM(Security Information and Event Management)ツールと連携させることが可能です。これにより、組織全体のセキュリティ監視体制にLarkのログを統合し、一元的なインシデント管理を実現できます。(出典: Lark公式サイト)具体的な連携方法や設定手順については、公式の管理者向けドキュメントをご確認ください。
2‑5 フル粒度監査ログ+国際監査報告
万が一のインシデントに備え、追跡可能性を担保する監査ログは非常に重要です。Larkではプランに応じて詳細なログを提供しています。
項目 | Starter | Pro | Enterprise |
監査ログ保持期間 | 90日 | 365日 | 365日+延長オプション |
(出典: Lark公式サイト プラン比較ページ)
Pro以上のプランでは、APIアクセスログを含めたより詳細なログを最大365日間(Enterpriseでは延長も可)保持できます。
また、SOC 2 (Type II) や ISO 27701 といった外部機関による監査レポートは、LarkのTrust Centerから申請・取得することができ、自社の監査対応にも利用可能です。
2‑6 セキュリティサポート & SLA
セキュリティは24時間365日の問題です。Larkでは、エンタープライズ契約の顧客に対して、専任のサポート体制を提供しています。具体的な対応時間やインシデント発生時の初動目標については、契約時に個別にご確認ください。
また、サービスの安定稼働を保証するSLA(Service Level Agreement)も提供されます。具体的な稼働率の数値(例: 99.9%など)は契約書に準拠しますが、これは一般的なクラウドサービスで提供される水準に沿ったものとなります。
2‑7 透明性ポリシー:ホワイトペーパーの公開
Larkはセキュリティやプライバシーに関する取り組みを積極的に情報公開しています。詳細な「Security Whitepaper」がPDF形式で公開されており、誰でもその内容を確認し、Larkのセキュリティアーキテクチャやデータ管理ポリシーを深く理解することができます。(出典: Lark公式サイト)
Larkに関する資料請求はこちら!
「Larkについて詳しく知りたい」「まずは話を聞いてみたい」といった方はお気軽にご請求ください。
- 資料内容
- Larkとは
- 導入事例
- 主要機能と特徴
- 導入メリットと効果 など!
3. 中国法リスクはゼロにできるか?
これだけの技術的対策を講じても、「それでも親会社が中国企業である限り、中国政府からの要請リスクは残るのでは?」という疑問は残ります。この点について、リスクシナリオを分解して考えてみましょう。
3‑1 データ越境シナリオを可視化する
データが中国当局の手に渡るシナリオは、大きく3つに分類できます。
- 物理的越境:データが中国本土のデータセンターに複製されるケース。
→ Larkでは設計上発生しません。 データは日本/シンガポールのAWSに限定されます。 - 論理的越境:中国の親会社(ByteDance)が、海外子会社(Lark)に対してデータへのアクセスを命令するケース。
→ このリスクは理論上残存します。 これが最大の懸念点です。 - 法的越境:将来の法改正や国際情勢の変化により、AWSのようなクラウド事業者が中国政府に鍵やデータの提出を求められるケース。
→ これはLark固有ではなく、グローバルなクラウドサービス共通の地政学リスクです。
3‑2 親会社アクセス要請リスクの現実
上記のうち、最も現実的な懸念は「論理的越境」です。国家情報法第7条を根拠に、ByteDance本社がLark社に対してデータアクセスを要請する可能性は、理論上はゼロではありません。
しかし、ここで効いてくるのがBYOKです。
暗号鍵を顧客自身のAWS KMSに保管し、Lark側には鍵が存在しない状態を維持すれば、たとえLark社の従業員がデータにアクセスしようとしても、その内容は暗号化されており意味のある情報として復号することは極めて困難です。これが、アクセス要請リスクに対する最も強力な技術的対抗策となります。
4. リスクを最小化する4つの実践策

理論上のリスクを限りなくゼロに近づけるためには、Larkの機能を活用した具体的な運用ルールを定めることが不可欠です。
以下に、最低限実施すべき4つの実践策を挙げます。
# | 施策 | 具体アクション |
1 | BYOK +追加 E2E 暗号化 | Pro/Enterpriseプランで自社専用のKMS CMKを設定。特に機密性の高いチャットは、外部のE2E(エンドツーエンド)暗号化ツールを併用し、二重に保護する。 |
2 | 共有リンク既定値の引き締め | テナント全体のデフォルト設定を「社内のメンバーのみ閲覧可」に変更。意図せず公開リンクが生成されるのを防ぎ、週次などで公開リンクを棚卸しする。 |
3 | SCIM連携で退職アカウント即時無効化 | Azure ADやOktaといったIdPとSCIMで連携。人事情報と同期して退職者アカウントを即時に無効化・権限剥奪する設定を有効化する。 |
4 | 外部アプリのスコープ制御 | Larkと連携する外部アプリ(OAuth)のアクセス許可スコープ(権限)を必要最小限に絞る。また、承認されたアプリのみ利用を許可するホワイトリスト方式を導入する。 |
5. プラン別セキュリティ機能マトリクス
これまで解説してきたセキュリティ機能は、契約プランによって利用可否が異なります。公開情報に基づき、特に重要な機能を比較したのが以下の表です。
セキュリティ観点 | Starter | Pro | Enterprise |
監査ログ保持 | 90日 | 365日 | 365日+延長オプション |
SSO / SCIM | ― | ◯ | ◎(自動プロビジョニング) |
BYOK(鍵持ち込み) | ― | ◯ | ◎ |
AI異常検知 | 基本的な検知 | ◯ | ◎ |
SLA(サービス品質保証) | 契約に準拠 | 契約に準拠 | 契約に準拠 |
セキュリティサポート | 営業時間内の問合せ | 強化されたサポート | 専任のサポート体制 |
選び方の軸
プラン選択に迷った際は、以下の3軸で判断するのが合理的です。
- ユーザー数が20名を超えるか、または500名を超えるか。
- 暗号鍵を自社で管理する必要があるか(BYOKが必須か)。
- 監査ログを1年以上保管する法的・社内的な要件があるか。
この3つの問いに答えることで、自社にとって最適なプラン(Starter → Pro → Enterprise)がほぼ決まります。
6. 判断フレーム:採用して良いケース/避けるべきケース
機能やリスクを理解した上で、最終的に自社でLarkを採用すべきか否かを判断するためのフレームワークを提示します。
6‑1 データ機微性と法規制の照合
取り扱うデータの種類によって、Larkの採用可否や必要なセキュリティレベルは変わります。
データ分類 | 主な例 | Lark採用可否 |
① 公開〜社内機密 | 営業資料、KPIレポート、議事録 | ◎:Starter〜Proプランで十分対応可能 |
② 個人情報(APPI/GDPR) | 顧客名簿、採用候補者の履歴書 | ◯:Proプラン以上でBYOKを適用することが強く推奨される |
③ 高度機密・政府情報 | 防衛関連技術、国家機密情報 | △:Lark単体ではなく、追加のE2E暗号化を重ねるか、専用の別SaaSを検討すべき |
6‑2 追加統制コスト vs 代替SaaS移行コスト
セキュリティを強化するにはコストがかかります。BYOKや監査ログの運用には、初期設定や月々の運用に一定の工数が見込まれます。
一方で、Larkの代替としてより高セキュリティを謳う他のSaaSへ移行する場合、ライセンス費用が大幅に増加するケースも少なくありません。
多くの中堅・中小企業にとっては、「Lark Proプラン + BYOK + 四半期ごとの権限棚卸し」といった運用が、コストパフォーマンスの最適解になることが多いでしょう。
6‑3 GO / NO-GO チェックリスト
最終判断として、以下の項目がすべてYESになるかを確認してください。
- ✅ BYOKを有効化し、暗号鍵を自社のKMSに格納できる体制か?(Pro以上)
- ✅ 共有リンクのテナント既定値を「社内限定」に変更済みか?
- ✅ SCIM連携により、退職者アカウントが即時無効化される仕組みが整っているか?
- ✅ 連携する外部アプリは、承認ベースのホワイトリスト方式で管理しているか?
→ 全項目が “YES” なら、自信を持って採用GOと言えます。
7. まとめ:安全に使い倒す3つの鍵
本記事で解説してきた内容を、Larkを安全に使いこなすための3つの鍵としてまとめます。
- 鍵を握る:Proプラン以上でBYOKを有効化し、データの暗号鍵を自社管理下に置く。これがセキュリティの根幹です。
- 共有を締める:リンクの既定値や権限テンプレートを最小権限の原則で見直し、意図しない情報漏洩を防ぐ。
- 運用で守る:四半期ごとの権限棚卸しと監査ログの定期レビューを業務プロセスに組み込み、継続的に安全な状態を維持する。
結論
「中国製=危険」と一括りにして思考停止するのではなく、Larkが提供するグローバル基準のセキュリティ機能を正しく理解し、「鍵管理+運用ガバナンス」で残存リスクを主体的にコントロールするアプローチが、現代のSaaS活用においてはるかに実践的かつ有益です。
上記3つの鍵を徹底すれば、Larkは多くの企業にとって、業務効率を飛躍的に向上させる安全な業務基盤となり得ます。
ノーコード開発に関するご相談はソウゾウまで!
ソウゾウでは、数多くのノーコード開発実績より、お客様のプロジェクトの目的ごとに最適なノーコードツールのご提案〜設計〜デザイン〜実装〜リリース〜保守運用まで一貫してサポートさせていただいております。
・ノーコードを活用し、アプリ・システムをマルっと構築して欲しい
・アプリ/システムの土台の構築依頼とその後の運用の内製化(開発人材の内製化)までやってほしい
・ノーコード人材/開発人材/IT人材を内製化してほしい など
上記のようなご要望をお持ちの方は、下記よりお気軽にご相談ください。
最後までご覧いただき、ありがとうございました!
代表 西澤志門との無料相談の予約
- ノーコード開発のご相談
- どのノーコードツールが最適なのか知りたい
- 補助金の活用相談 など
是非ともざっくばらんにお話ししましょう!お気軽にご相談ください。
参考リンク
コンプライアンス一覧(Trust Center)
https://www.larksuite.com/ja_jp/trust/compliance
取得認証(ISO 27001/SOC 2 Type Ⅱ ほか)や、AWS リージョンの説明
料金プラン比較(Starter/Pro/Enterprise)
https://www.larksuite.com/hc/ja-JP/articles/497171699982-lark-料金プランの紹介
ユーザー数上限・監査ログ保持期間など各プランの機能差
Lark BYOK(独自鍵)ソリューション解説
https://www.larksuite.com/hc/ja-JP/articles/033683440349-lark-独自の鍵-byok-ソリューションの紹介
鍵管理の仕組みと導入手順、対応プラン
Lark セキュリティ概要ページ
https://www.larksuite.com/ja_jp/security
暗号化方式、ゼロトラスト設計、データセンター冗長化 など
管理者向け:Lark セキュリティ機能の紹介
https://www.larksuite.com/hc/ja-JP/articles/730703751635-管理者-lark-セキュリティ機能の紹介
アカウント保護・アクセス制御・ログ監査などの詳細設定ガイド
管理者向け:Lark コンプライアンス機能の紹介
https://www.larksuite.com/hc/ja-JP/articles/820012051228-管理者-lark-コンプライアンス機能の紹介
GDPR/APPI 対応やデータ保持ポリシーの設定方法