LeapShark Ocean セキュリティ

最終更新日：2026年8月6日

実際の構成・適用範囲は、お客様環境および個別契約により異なります。断定的な「絶対的安全」を保証するものではなく、前提条件と運用を含めて成立する対策です。

1. セキュリティの基本方針

本サービスのセキュリティ設計は、次の原則に基づきます。

1. データ最小化：目的達成に必要な範囲でデータを取り扱う
2. ローカル優先：既定では社内／専用環境内で推論・検索を完結できる構成を重視する
3. 明示的な外部送信：クラウドLLM等へ送信する場合は、契約者の選択と設定に基づく
4. 最小権限：利用者・管理者・サービスアカウントに必要最小限の権限のみを付与する
5. 監査可能性：重要な操作とアクセスを追跡できる状態を維持する
6. 防御の多層化：認証、認可、ネットワーク、暗号化、監視を組み合わせる

2. オンプレミス構成

2.1 概要

本サービスは、お客様が管理するデータセンター、サーバルーム、プライベートクラウド等の企業専用環境に導入することを想定しています。マルチテナントの共有クラウド上で他社とデータを混在させる形態を前提としません。

2.2 構成上の利点

• 社内データを外部の生成AIサービスへ送信しない運用を選択できる
• お客様の既存ネットワーク区分、認証基盤、監査要件に合わせやすい
• 入退室管理、資産管理、障害対応を自社統制下に置きやすい

2.3 前提

オンプレミス構成の安全性は、お客様側の物理セキュリティ、ネットワーク管理、端末管理、運用体制と一体で成立します。当社は導入・設計支援を行いますが、お客様管理領域の最終責任はお客様にあります。

3. ローカルLLM

3.1 ローカル推論

ローカルLLMを利用する場合、プロンプトおよび参照コンテキストは、原則としてお客様環境内の推論基盤で処理されます。これにより、クラウド型生成AIへ業務文書を送信せずに文章生成・要約・検索応答等を行う構成が可能です。

3.2 モデル管理

• 利用モデルは、契約および技術要件に応じて選定します
• モデルファイル、実行環境、依存ライブラリは、更新手順と整合性を考慮して管理します
• 検証環境での確認後に本番適用する運用を推奨します

3.3 性能と安全の両立

ローカルLLMはデータ管理面で有利な一方、モデル性能・最新性・運用負荷は構成に依存します。必要に応じて、許可された範囲でクラウドLLMを併用するハイブリッド運用も選択できます。

4. データ保存場所

4.1 原則

契約者データ（アップロード文書、インデックス、会話履歴、設定、ログ等）は、原則として契約者が指定する環境内に保存されます。

4.2 保存対象の例

• ナレッジ文書およびベクトル／検索インデックス
• ユーザー・権限設定
• 利用ログ、監査ログ
• エージェント設定、API連携設定
• システム設定バックアップ

4.3 当社による保管

当社がお客様データを恒常的に自社クラウドへ複製して保管することは、原則として行いません。保守支援のために一時的なログ提供を受ける場合は、必要な範囲・期間に限定し、秘密保持のもと取り扱います。

5. 暗号化

5.1 通信時

管理画面アクセス、API通信、サービスコンポーネント間通信について、TLS等による暗号化を用いる構成を推奨・支援します。証明書管理はお客様ポリシーに合わせて設計します。

5.2 保存時

ディスク暗号化、ボリューム暗号化、バックアップ媒体の保護等を、お客様の基盤方針に応じて実装します。データベースやオブジェクトストレージの暗号化設定は、環境要件に合わせて検討します。

5.3 秘密情報

APIキー、トークン、接続情報等の秘密情報は、平文管理を避け、適切な秘密管理の仕組みで取り扱うよう設計します。

6. アクセス制御

6.1 認可モデル

本サービスは、利用者ごとに機能・データへのアクセス範囲を制御できるよう設計されています。ファイル検索や社内ナレッジ検索は、付与された権限の範囲で動作させる運用を前提とします。

6.2 推奨設定

• 部署・プロジェクト・機密区分に応じたロール設計
• 特権管理者の人数最小化
• 定期的な権限棚卸し
• 退職・異動時の即時無効化

6.3 サービス間アクセス

コンポーネント間・API間のアクセスも、必要最小限の認証情報とネットワーク到達性に制限します。

7. 認証

7.1 利用者認証

利用者認証は、お客様の要件に応じて、ID/パスワード、シングルサインオン（SSO）、多要素認証（MFA）等と連携する構成を検討します。対応方式の詳細は個別設計によります。

7.2 セッション管理

セッションの有効期限、再認証、異常ログイン時の対応方針をお客様と合意のうえ設定します。

7.3 サービスアカウント

バッチ処理、API連携、エージェント実行に用いるアカウントは、個人アカウントと分離し、用途を限定します。

8. 管理者権限

8.1 権限の分離

アプリケーション管理者、インフラ管理者、監査閲覧者等、役割を分離することを推奨します。単一アカウントへの権限集中は避けてください。

8.2 特権操作

ユーザー追加、権限変更、外部連携有効化、モデル入替、ログ削除等の特権操作は、承認と記録を伴う運用を推奨します。

8.3 当社サポート時のアクセス

当社が保守目的で管理者相当の作業を行う場合は、事前合意または依頼に基づき、必要最小限の時間・範囲で実施します。

9. ログ管理

9.1 取得し得るログ

構成に応じて、以下を記録できます。

• 認証・認可ログ
• 管理操作ログ
• ファイル／ナレッジへのアクセスログ
• 問い合わせ・生成リクエストに関する利用ログ
• システム・障害ログ
• API呼び出しログ

9.2 保存と保護

ログは改ざん・不正削除を防ぐため、アクセス制限と適切な保存期間を設定します。保存期間は、お客様の監査要件・法令・ストレージ制約に応じて決定します。

9.3 監視

重要イベントの検知、しきい値超過、連続認証失敗等について、監視・通知の仕組みを設計できます。

10. バックアップ

10.1 対象

設定、インデックス、メタデータ、必要に応じた文書ストア等をバックアップ対象として設計します。

10.2 運用

• 定期バックアップ
• 世代管理
• 保管先のアクセス制御
• リストア手順の文書化
• 重要環境における復旧訓練の実施推奨

RTO/RPOの目安は個別契約で定めます。

11. アップデート

11.1 方針

セキュリティパッチ、依存コンポーネント更新、アプリケーション更新を計画的に適用します。緊急度の高い脆弱性は、計画保守を待たず対応することがあります。

11.2 適用プロセス（推奨）

1. 情報収集・影響評価
2. 検証環境での確認
3. 本番適用窓の調整
4. 適用と動作確認
5. 問題時の切り戻し

11.3 モデル更新

LLMや埋め込みモデルの更新は、回答品質・互換性・インデックス再構築の要否を評価したうえで実施します。

12. 監査

12.1 お客様による監査

お客様は、権限設定、ログ、構成変更履歴等を用いて利用状況を監査できます。監査要件（内部監査、外部監査、規制対応）がある場合は、導入時に必要なログ項目と保存期間を定義します。

12.2 当社の点検

当社は、提供物および支援業務について、必要に応じた点検・改善を行います。第三者認証（ISO等）の取得状況は、時点により異なるため、必要な場合は個別にご確認ください。

13. インシデント対応

13.1 対応の流れ

1. 検知・申告：監視または利用者申告により認知
2. 初動：影響範囲の把握と拡大防止
3. 調査：原因、漏洩有無、期間の確認
4. 復旧：サービス回復と再発防止策の実施
5. 報告：契約・法令に基づく通知

13.2 連絡

重大なセキュリティインシデントが確認された場合、個別契約に定める連絡先・期限に従いお客様へご連絡します。お客様側でインシデントを発見された場合も、速やかにご連絡ください。

13.3 証拠保全

必要に応じてログ・設定・関連記録を保全し、原因分析と再発防止に活用します。

14. RAGの安全性

14.1 RAGとは

RAG（Retrieval-Augmented Generation）は、社内文書等を検索し、その結果を踏まえて回答を生成する仕組みです。社内ナレッジを活用する一方、権限設計を誤ると情報漏えいにつながる可能性があります。

14.2 主なリスクと対策

14.3 運用上の推奨

• 機密区分の高い文書は、必要部署のみ検索可能にする
• 回答を業務利用する前に参照元を確認する
• 定期的にインデックス対象を見直す

15. クラウドLLM利用時のデータフロー

15.1 基本データフロー（概念）

1. 利用者が本サービスにプロンプト／ファイルを入力
2. 必要に応じて社内RAGで関連文書を検索（ローカル）
3. クラウドLLM接続が有効な場合のみ、プロンプトおよび必要なコンテキストを外部APIへ送信
4. 外部モデルの応答を受け取り、利用者へ表示
5. 設定に応じて利用ログをローカルに記録

15.2 重要な前提

• クラウドLLM接続は、契約者が有効化した場合に動作します
• 送信先事業者の利用規約、保持ポリシー、学習利用の有無、提供地域を確認してください
• 機密度の高いデータは、クラウド送信前にマスキングまたは送信禁止とする運用を推奨します

15.3 責任分界

外部モデル提供者のセキュリティ管理は当該事業者の責任範囲です。当社は、接続設定・通信経路・利用制御の設計支援を行いますが、第三者サービスの内部管理まで保証するものではありません。

16. ネットワーク構成

16.1 推奨される考え方

• 本サービス構成要素を用途別にセグメント分割する
• 管理平面とデータ平面を分離する
• 必要な通信のみを許可する（デフォルト拒否）
• 管理アクセスはVPN、踏み台、IP制限等で保護する

16.2 典型的な通信

構成により異なりますが、一般に以下を設計対象とします。

• 利用者端末 → 管理画面／API
• アプリ → 推論基盤（GPUサーバー）
• アプリ → 検索／ベクトルDB／文書ストア
• アプリ → お客様IdP（SSO利用時）
• アプリ → 外部LLM API（有効時のみ）

16.3 閉域運用

外部通信を極力制限した閉域構成も選択できます。その場合、モデル更新やパッチ配布の経路を別途設計します。

17. GPUサーバー

17.1 役割

GPUサーバーは、ローカルLLMの推論を高速に実行するための計算基盤です。当社は、契約に基づきGPUサーバーの提供、構成支援、保守支援を行う場合があります。

17.2 セキュリティ上の要点

• 物理設置場所の入退室管理
• OS／ドライバ／コンテナ実行環境の硬化
• 不要サービスの停止
• 管理ポートの露出最小化
• リソース監視（異常負荷、障害）
• ファームウェアおよびセキュリティパッチの管理

17.3 可用性

GPUハードウェア障害時は、部品交換や冗長構成の有無により復旧時間が変動します。重要な業務では、冗長性や代替手順を事前に検討します。

18. 外部通信

18.1 既定の考え方

ローカルAI運用では、業務データが外部へ送信されないよう、外部通信を制限した設計が可能です。

18.2 発生し得る外部通信

お客様の選択により、以下が発生し得ます。

• クラウドLLM API
• 外部認証（SaaS IdP）
• ソフトウェア更新・コンテナイメージ取得
• 監視・ライセンス確認（導入構成による）
• サポートのための遠隔接続（合意時）

18.3 制御

外部通信は、許可リスト、プロキシ、TLS検査方針、ログ取得等により可視化・制御することを推奨します。

19. APIセキュリティ

19.1 認証・認可

API利用には、APIキー、トークン、相互TLS等、合意した認証方式を用います。発行した認証情報は利用者・システムごとに分離し、ローテーション可能とします。

19.2 保護策

• HTTPS必須
• スコープ／権限の最小化
• レート制限、異常検知
• 入力検証
• 監査ログの取得
• 不要な管理APIの外部公開禁止

19.3 連携先管理

社内システムやAI開発ツール（例：コーディング支援ツール）と連携する場合も、トークン漏えい対策と最小権限を徹底してください。

20. 導入時の推奨事項

本サービスをより適切に運用するため、以下を推奨します。

1. 機密区分とRAG対象文書の棚卸し
2. SSO／MFAの導入検討
3. 管理者権限の分離と棚卸し周期の設定
4. クラウドLLMへ送信してよいデータの社内ルール策定
5. ログ保存期間と監査手順の定義
6. バックアップとリストア試験の実施
7. AI利用教育（ハルシネーション、個人情報、著作権）
8. インシデント連絡体制の事前合意

21. お問い合わせ

セキュリティに関するご質問、構成相談、資料請求は、以下までご連絡ください。

• 事業者名：株式会社LeapShark
• 所在地：〒101-0024 東京都千代田区神田和泉町１−６−１６ ヤマトビル 405
• メールアドレス：info@leap-shark.com

脆弱性の報告については、責任ある開示の趣旨に沿い、詳細を上記窓口までご連絡ください。

以上