セキュリティ概要
最終更新: 2026-08-04
このページは、情報システム部門や導入検討者がフラクソンのセキュリティを確認するための概要です。
要点
フラクソンは、Remote MCP対応生成AIクライアントからkintoneを利用するための管理型MCPサーバーです。
セキュリティ上の基本方針は次の通りです。
- kintoneアクセスは利用者本人のkintone OAuth認可を使います。
- フラクソンはkintone権限を広げません。
- フラクソンはkintone権限の上に、アプリ利用制限、フィールド制御、レコード条件、件数上限を追加できます。
- 生成AIクライアントへkintone OAuth tokenを渡しません。
- Remote MCP tokenやkintone OAuth tokenの平文を保存しません。
- 監査ログには、原則としてレコード本文や実行クエリ本文ではなく、操作メタデータを保存します。
- 判断できない状態は許可せず拒否する設計です。
全体構成
生成AIクライアントはフラクソンに接続します。フラクソンは、利用者本人のkintone OAuth認可を使ってkintone APIを呼び出します。
生成AIクライアントがkintoneのtokenを直接持つ構成ではありません。
認証と認可の層
フラクソンでは認証・認可を3つに分けて扱います。
| 層 | 内容 | 主な目的 |
|---|---|---|
| フラクソンログイン | 利用者・管理者がフラクソン画面へログインする | テナント所属、ロール、MFA、利用者確認 |
| Remote MCP OAuth | 生成AIクライアントがフラクソンへ接続する | 生成AI接続ごとのBearer tokenとスコープ管理 |
| kintone OAuth | フラクソンがkintone APIへアクセスする | 利用者本人のkintone権限でアクセスする |
Remote MCPの実効権限は、ユーザー許可スコープと接続発行済みスコープの両方で判定します。
kintone権限との関係
フラクソンは、kintoneで許可されていない操作を許可するための仕組みではありません。
評価の考え方:
- 利用者本人のkintone OAuth認可があるか。
- kintone側で対象アプリ、レコード、フィールドへアクセスできるか。
- フラクソン側で対象アプリや操作が拒否されていないか。
- フィールド制御やレコード条件に違反していないか。
- 返却前に非表示・マスクなどのサニタイズを行う。
- 監査ログを記録する。
保存する情報
| 区分 | 保存する情報 | 目的 |
|---|---|---|
| テナント情報 | テナントID、名称、契約状態、kintoneサブドメイン | テナント分離、契約管理 |
| ユーザー情報 | フラクソンユーザー、所属、ロール、状態 | ログイン、管理権限、利用者管理 |
| kintone OAuth状態 | 認可状態、許可済みスコープ、暗号化済みtoken、期限、利用者が入力したkintoneユーザーID | 利用者本人のkintone権限でAPIを呼び出し、生成AIに「自分」を表すkintoneユーザーIDを伝える |
| Remote MCP接続 | クライアント名、接続状態、発行済みスコープ、token検証用ハッシュ、最終利用時刻 | 生成AIクライアント接続の認証と失効管理 |
| ポリシー設定 | アプリ制限、フィールド制御、レコード条件、件数上限 | 生成AI経由の利用範囲を制御する |
| 監査ログ | 誰が、どの生成AI接続から、どのツールで、どのアプリにアクセスしたか | 説明責任、調査、運用改善 |
保存しない情報
| 保存しないもの | 理由 |
|---|---|
| kintone OAuth tokenの平文 | kintoneへの権限を持つ秘密情報の漏えいを防ぐため |
| Remote MCP tokenの平文 | 生成AI接続用tokenを再利用されにくくするため |
| authorization codeの平文 | OAuth途中の秘密情報を残さないため |
| 監査ログ内のレコード本文 | 監査ログを業務データの二次保管場所にしないため |
| 監査ログ内の実行クエリ本文 | 条件式や値から機微情報が漏れることを避けるため |
| kintone APIの生エラー本文 | 内部情報やkintone由来の詳細情報を生成AIへ漏らさないため |
ただし、生成AIがフラクソンを通じて取得したkintoneデータは、MCPレスポンスとして生成AIクライアントに返ります。その後の会話履歴、保存、学習利用、管理者監査の扱いは、利用する生成AIサービス側の契約と設定も確認してください。
Remote MCPのセキュリティ
Remote MCPは、生成AIクライアントがHTTPS上のMCPサーバーに接続する方式です。
フラクソンでは次の考え方を採用します。
- HTTPSのRemote MCP URLを使う。
- OAuth Bearer tokenで生成AIクライアントからの接続を認証する。
- tokenはURLクエリに含めず、Authorizationヘッダーで扱う。
- public clientではPKCEを使う。
- redirect URIは登録済みURIとの完全一致で検証する。
- stateは予測不能、短期TTL、単回使用、開始セッション束縛にする。
- tokenはフラクソン向けに発行されたものだけを受け付ける。
- 生成AIクライアントから受けたtokenをkintoneへ渡さない。
フィールド制御
フラクソンのフィールド制御では、生成AIに返すフィールドを制限できます。
例:
- 会社名、ステータス、担当者は表示。
- 個人携帯番号は非表示。
- 社内評価コメントはマスク。
- ステータスだけ更新可。
- 金額や契約番号は更新不可。
フィールド制御は、kintone権限に加えて適用されます。kintoneで見えないものがフラクソンで見えるようになるわけではありません。
監査ログ
監査ログでは、次のような情報を確認します。
- 利用者。
- テナント。
- 生成AIクライアントまたはRemote MCP接続。
- 利用したMCPツール。
- 対象アプリ。
- 成功、拒否、失敗。
- 件数やrecordIdなどの最小限のメタデータ。
- エラー種別や拒否理由。
監査ログにレコード本文を保存しない方針にすることで、監査ログ自体が機微情報の集積場所になるリスクを下げます。
生成AIサービス側で別途確認すること
フラクソンはkintoneとの接続窓口を制御しますが、生成AIサービスそのものの管理設定は各生成AIサービス側の責任範囲です。
情報システム部門は次を確認してください。
- 利用する生成AIサービスの契約プラン。
- 会話履歴の保存設定。
- 学習利用の有無とオプトアウト条件。
- 管理者によるアプリ・コネクタの許可設定。
- 利用者ログ、監査、エクスポート機能。
- データ所在地やサブプロセッサ。
- 退職者・異動者のアカウント削除・停止手順。
導入時の推奨
- まず読み取りと集計から始める。
- 書き込み系操作は対象アプリとフィールドを限定する。
- 個人情報や機微情報を含むアプリは、利用拒否または強いフィールド制御にする。
- テスト利用者で制御が効いていることを確認する。
- 情報システム部門と管理者で、利用できる生成AIサービスを明確にする。