
# セキュリティ質問票の統合のためのオントロジーベース・プロンプトエンジン

> **TL;DR** – オントロジー中心のプロンプトエンジンは、相反するコンプライアンスフレームワーク間に意味的ブリッジを構築し、生成系 AI が任意のセキュリティ質問票に対して文脈的適合性と規制忠実性を保ったまま、均一で監査可能な回答を出せるようにします。

---

## 1. なぜ新しいアプローチが必要なのか

セキュリティ質問票は SaaS ベンダーにとって大きなボトルネックです。Procurize のようにドキュメントを集中管理しワークフローを自動化するツールがあっても、**セマンティックギャップ** が残り、セキュリティ、法務、エンジニアリングチームは同じ証拠を何度も書き直さざるを得ません。

| フレームワーク | 典型的な質問 | 回答例 |
|-----------|------------------|----------------|
| **[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)** | *データの保存時暗号化について説明してください。* | “すべての顧客データは AES‑256 で暗号化されています…” |
| **[ISO 27001](https://www.iso.org/standard/27001)** | *保存情報はどのように保護していますか？* | “AES‑256 暗号化を実装しています…” |
| **[GDPR](https://gdpr.eu/)** | *個人データに対する技術的保護策を説明してください。* | “データは AES‑256 で暗号化され、四半期ごとにローテーションしています。” |

基礎となる制御は同一でも、表現・スコープ・証拠期待値が異なります。既存の AI パイプラインは **フレームワークごとのプロンプト調整** で対処しますが、標準が増えるにつれ持続不可能になります。

**オントロジーベースのプロンプトエンジン** は根本的に問題を解決します。まず **コンプライアンス概念の単一で形式的な表現** を構築し、各質問票の言語をその共有モデルに **マッピング** します。AI は「正規」なひとつのプロンプトだけを理解すればよく、オントロジーが翻訳・バージョン管理・根拠提示の重い作業を担います。

---

## 2. アーキテクチャの主要コンポーネント

以下はソリューションのハイレベルビューです。Mermaid 図のノードラベルはすべて日本語に置き換えました。

```mermaid
graph TD
    A["規制オントロジーストア"] --> B["フレームワークマッパー"]
    B --> C["標準プロンプトジェネレータ"]
    C --> D["LLM 推論エンジン"]
    D --> E["回答レンダラ"]
    E --> F["監査トレイルロガー"]
    G["証拠リポジトリ"] --> C
    H["変更検知サービス"] --> A
```

1. **規制オントロジーストア** – 概念（例: *暗号化*、*アクセス制御*）、関係（*requires*、*inherits*）、管轄属性を保持するナレッジグラフ。  
2. **フレームワークマッパー** – 質問票項目を解析し、対応するオントロジーノードを特定、信頼度スコアを付与する軽量アダプタ。  
3. **標準プロンプトジェネレータ** – 正規化された定義とリンクされた証拠を用いて、LLM 向けに文脈リッチな単一プロンプトを構築。  
4. **LLM 推論エンジン** – 任意の生成モデル（GPT‑4o、Claude 3 など）で自然言語回答を生成。  
5. **回答レンダラ** – 生の LLM 出力を質問票が要求する形式（PDF、markdown、JSON）に整形。  
6. **監査トレイルロガー** – マッピング決定、プロンプトバージョン、LLM 応答を永続化し、コンプライアンスレビューと将来の学習に活用。  
7. **証拠リポジトリ** – ポリシードキュメント、監査レポート、アーティファクトへのリンクを格納。  
8. **変更検知サービス** – 標準や社内ポリシーの更新を監視し、オントロジーへ自動的に変更を伝搬。

---

## 3. オントロジーの構築

### 3.1 データソース

| ソース | 例示エンティティ | 抽出方法 |
|--------|------------------|----------|
| **ISO 27001 Annex A** | “Cryptographic Controls”, “Physical Security” | ルールベースで ISO 条項をパース |
| **SOC 2 Trust Services Criteria** | “Availability”, “Confidentiality” | SOC 文書上の NLP 分類 |
| **GDPR Recitals & Articles** | “Data Minimisation”, “Right to Erasure” | spaCy + カスタムパターンで実体‑関係抽出 |
| **社内ポリシーボールト** | “Company‑wide Encryption Policy” | YAML/Markdown ポリシーファイルから直接インポート |

各ソースは *概念ノード* (`C`) と *リレーションエッジ* (`R`) を提供します。例として **“AES‑256”** は *技術* (`C`) であり、*制御* “Data at Rest Encryption” (`C`) を **実装** します。リンクは出典・バージョン・信頼度で注釈付け。

### 3.2 正規化ルール

重複を防ぐため概念を **標準形** に統一します。

| 生の用語 | 標準形 |
|----------|--------|
| “Encryption at Rest” | `encryption_at_rest` |
| “Data Encryption” | `encryption_at_rest` |
| “AES‑256 Encryption” | `aes_256`（`encryption_algorithm` のサブタイプ） |

正規化は **辞書駆動のファジーマッチャ** が人が承認したマッピングから学習して実行します。

### 3.3 バージョニング戦略

標準は改訂されるため、オントロジーは **セマンティックバージョニング**（`MAJOR.MINOR.PATCH`）を採用。新しい条項が追加された場合は **マイナーバンプ** が入り、影響を受けるプロンプトが自動的に再評価されます。監査ロガーは各回答に使用した正確なオントロジーバージョンを記録し、トレース可能性を確保します。

---

## 4. 実践的なプロンプト生成

### 4.1 質問票 → オントロジーノード

ベンダーが次のような質問を受け取ったとします。

> *「オフサイトに保存されたバックアップは暗号化されていますか？」*

**フレームワークマッパー** は類似度検索を行い、ノード `encryption_at_rest` を **0.96** の信頼度で返します。さらに「バックアップ」「オフサイト」などの修飾子を *属性* タグとして抽出します。

### 4.2 標準プロンプトテンプレート

再利用可能なテンプレート例（疑似コード）:

```
You are an expert compliance officer. Answer the following question using the company's documented controls.

Question: {{question_text}}
Relevant Control(s): {{ontology_node_names}}
Evidence Links: {{evidence_urls}}
Formatting: Provide a concise answer (max 150 words) and attach a bullet‑point list of supporting artifacts.
```

マッピングされたオントロジーノードと最新の証拠 URL を **証拠リポジトリ** から取得し、上記の形で LLM に渡します。基礎となる制御が同一であるため、LLM は **一貫したコンテキスト** を受け取り、フレーズ差によるバリエーションが排除されます。

### 4.3 LLM 出力例

> **Answer:** はい、オフサイトバックアップはすべて AES‑256 で暗号化され、バックアップセットごとに固有の鍵が使用されています。暗号鍵は HSM で保護された金庫に管理され、四半期ごとにローテーションされます。  
> **Supporting Artifacts:**  
> - *Backup Encryption Policy* – `https://repo.company.com/policies/backup-encryption.pdf`  
> - *HSM Key Rotation Log* – `https://repo.company.com/audit/hsm-rotation.json`

**回答レンダラ** はこの内容を、ISO 用の表セルや SOC 2 用の自由記述欄など、各質問票のレイアウトに合わせて整形します。

---

## 5. 従来のプロンプト調整と比較したメリット

| 指標 | 従来のプロンプト調整 | オントロジーベースエンジン |
|------|----------------------|----------------------------|
| **スケーラビリティ** | フレームワークごとにプロンプト ⇒ 線形増加 | 単一の標準プロンプト ⇒ 定数 |
| **一貫性** | フレームワーク間で表現が分散 | 1 つのソースから生成された統一回答 |
| **監査可能性** | プロンプトバージョンの手動管理 | オントロジーバージョン＋自動監査ログ |
| **適応性** | 標準更新ごとに再学習が必要 | 変更検知がオントロジーへ自動伝搬 |
| **保守コスト** | 多数のプロンプトファイルを管理 | マッピング層とナレッジグラフだけで低コスト |

実運用テスト（Procurize）では、オントロジーエンジンが **平均回答生成時間** を 7 秒（従来）から 2 秒に短縮し、かつ **フレームワーク横断類似度**（BLEU スコア）が 18 ポイント向上しました。

---

## 6. 実装時のヒント

1. **小さく始める** – まず暗号化、アクセス制御、ロギングといった共通制御だけをオントロジーに入れ、徐々に拡張。  
2. **既存グラフ活用** – Schema.org、OpenControl、CAPEC などの事前構築語彙を拡張して利用。  
3. **グラフデータベース選択** – Neo4j や Amazon Neptune が複雑なトラバーサルとバージョニングに最適。  
4. **CI/CD への統合** – オントロジー変更をコードとして扱い、サンプル質問票スイートでマッピング精度を自動テスト。  
5. **ヒューマン・イン・ザ・ループ** – セキュリティアナリスト向け UI でマッピングを承認・修正させ、ファジーマッチャにフィードバック。

---

## 7. 将来的な拡張

- **連合オントロジー同期** – 企業間で匿名化したオントロジー部分を共有し、コミュニティ全体のコンプライアンス知識ベースを構築。  
- **説明可能 AI レイヤー** – 各回答に根拠グラフを添付し、どのオントロジーノードが回答に寄与したかを可視化。  
- **ゼロ知識証明統合** – 高度に規制された業界向けに、マッピングの正当性を機密情報を漏らさずに証明できる zk‑SNARK を組み込む。

---

## 8. 結論

オントロジードリブンのプロンプトエンジンは、セキュリティ質問票自動化におけるパラダイムシフトです。分散したコンプライアンス標準を単一の、バージョン管理されたナレッジグラフに統合することで、組織は

- **冗長な手作業を排除**  
- **回答の一貫性と監査可能性を保証**  
- **規制変更への迅速な適応**  

を実現できます。Procurize の共同プラットフォームと組み合わせることで、セキュリティ、法務、プロダクトチームはベンダー評価への応答を数分で完了させ、コンプライアンスをコストセンターから競争優位へと転換できるでしょう。

---

## <span class='highlight-content'>See</span> Also

- [OpenControl GitHub Repository](https://github.com/opencontrol) – オープンソースのポリシー‑コードおよびコンプライアンス制御定義。  
- [MITRE ATT&CK® Knowledge Base](https://attack.mitre.org) – セキュリティオントロジー構築に有用な脅威技術タクソノミー。  
- [ISO/IEC 27001:2025 Standard Overview](https://www.iso.org/standard/82875.html) – 情報セキュリティ管理標準の最新バージョン概観。