
# AI駆動インテントベースルーティングエンジンによるリアルタイムベンダーアンケート協働

ベンダーのセキュリティアンケートは、成長の速い SaaS 企業にとってボトルネックとなっています。新しい顧客からのリクエストがあるたびに、手作業の受け渡しが連鎖的に発生します。セキュリティアナリストが最新ポリシーを取り出し、法務レビューが文言を検証し、プロダクトエンジニアが技術実装を明確化し、最終的な回答が PDF にまとめられます。この断片的なワークフローは **長いターンアラウンドタイム、一貫性のない回答、監査リスクの露出** を引き起こします。

プラットフォーム自体が *なぜ* 質問がされるのか、*誰が* 最適に回答できるのか、*いつ* 回答が必要かを理解し、リアルタイムで正しい人物に自動的にリクエストをルーティングできたらどうでしょうか？ そこで登場するのが **AI 駆動インテントベースルーティングエンジン (IBRE)** です。Procurize AI プラットフォームのコアコンポーネントであり、**ナレッジグラフセマンティクス**、**検索強化生成 (RAG)**、**継続的フィードバック** を組み合わせて機械速度でアンケート回答の協働をオーケストレーションします。

> **主なポイント**
> - インテント検出により、生のアンケートテキストが構造化されたビジネスインテントへ変換されます。
> - 動的ナレッジグラフがインテントと所有者、証拠アーティファクト、ポリシーバージョンをリンクします。
> - リアルタイムルーティングは LLM ベースの信頼度スコアとワークロードバランシングを活用します。
> - 継続的学習ループにより、提出後の監査からインテントとルーティングポリシーが洗練されます。

---

## 1. テキストからインテントへ – セマンティックパーシング層

IBRE の最初のステップは、自由形式の質問（例: *「データを保存時に暗号化していますか？」*）をシステムが実行できる **標準インテント** に変換することです。これには 2 段階のパイプラインを使用します。

1. **LLM ベースのエンティティ抽出** – 軽量 LLM（例: Llama‑3‑8B）が主要エンティティ（*暗号化*、*保存時データ*、*スコープ*、*コンプライアンスフレームワーク*）を抽出します。  
2. **インテント分類** – 抽出されたエンティティをファインチューニング済み分類器（BERT ベース）に渡し、**約 250 のインテント**（例: `EncryptDataAtRest`, `MultiFactorAuth`, `IncidentResponsePlan`）のいずれかにマッピングします。

生成されるインテントオブジェクトは以下を含みます。  
- `intent_id`  
- `confidence_score`  
- `linked_policy_refs` (**[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)**、**[ISO 27001](https://www.iso.org/standard/27001)**、内部ポリシー ID)  
- `required_evidence_types`（設定ファイル、監査ログ、サードパーティ証明書）

**インテントが重要な理由**  
インテントはアンケート内容と下流ワークフロー間の *安定した契約* です。表現が変わっても（「保存時にデータを暗号化していますか？」 vs. 「データが保存時に暗号化されているか？」）同じインテントが認識され、ルーティングの一貫性が保たれます。

---

## 2. コンテキスト基盤としてのナレッジグラフ

**プロパティグラフデータベース**（Neo4j または Amazon Neptune）には以下のリレーションが保存されます。

- **インテント** ↔ **所有者**（セキュリティエンジニア、法務顧問、プロダクトリード）  
- **インテント** ↔ **証拠アーティファクト**（ポリシードキュメント、構成スナップショット）  
- **インテント** ↔ **規制フレームワーク**（**SOC 2**、**ISO 27001**、**[GDPR](https://gdpr.eu/)**）  
- **所有者** ↔ **ワークロード & 可用性**（現在のタスクキュー、タイムゾーン）

各ノードのラベルは二重引用符で囲まれ、後の Mermaid 可視化に対応します。

```mermaid
graph LR
    "Intent: EncryptDataAtRest" -->|"owned by"| "Owner: Security Engineer"
    "Intent: EncryptDataAtRest" -->|"requires"| "Evidence: Encryption Policy"
    "Intent: EncryptDataAtRest" -->|"complies with"| "Regulation: ISO 27001"
    "Owner: Security Engineer" -->|"available"| "Status: Online"
    "Owner: Security Engineer" -->|"workload"| "Tasks: 3"
```

このグラフは **動的** です。新しいアンケートがアップロードされるたびに、インテントノードは既存ノードとマッチングされるか、必要に応じて作成されます。所有権エッジは、専門知識、現在の負荷、**[SLA](https://www.ibm.com/think/topics/service-level-agreement)** 期限を考慮した **二部マッチングアルゴリズム** によって再計算されます。

---

## 3. リアルタイムルーティングの仕組み

アンケート項目が到着したときの流れ：

1. **インテント検出** がインテントと信頼度スコアを出力。  
2. **グラフ検索** が候補所有者と関連証拠を取得。  
3. **スコアリングエンジン** が以下を評価  
   - **専門性適合度** (`expertise_score`) – 過去の回答品質に基づく。  
   - **可用性** (`availability_score`) – Slack/Teams のプレゼンス API から取得。  
   - **SLA 緊急度** (`urgency_score`) – アンケート締め切りから算出。  
4. **合成ルーティングスコア** = 重み付き合計（ポリシー・アズ・コードで設定可能）。  

合成スコアが最も高い所有者に、**自動生成タスク** が Procurize に送信され、以下が事前入力されます。  
- 元の質問  
- 検出されたインテント  
- 最も関連性の高い証拠へのリンク  
- RAG からの回答スニペット提案  

信頼度スコアが閾値（例: 0.65）未満の場合は、**ヒューマン・イン・ザ・ループレビューキュー** に回され、コンプライアンスリードがインテントを検証してから割り当てます。

### 例：ルーティング決定

| 所有者 | 専門性 (0‑1) | 可用性 (0‑1) | 緊急度 (0‑1) | 合成スコア |
|-------|--------------|--------------|--------------|------------|
| Alice (Sec Eng) | 0.92 | 0.78 | 0.85 | **0.85** |
| Bob (Legal) | 0.68 | 0.95 | 0.85 | 0.79 |
| Carol (Prod) | 0.55 | 0.88 | 0.85 | 0.73 |

Alice が即座にタスクを受領し、システムは監査可能なログにルーティング決定を記録します。

---

## 4. 継続的学習ループ

IBRE は固定されたものではありません。アンケート完了後、プラットフォームは **提出後フィードバック** を取り込みます。

- **回答正確性レビュー** – 監査人が回答の関連性を採点。  
- **証拠ギャップ検出** – 参照された証拠が古い場合、ポリシーノードをフラグ。  
- **所有者パフォーマンス指標** – 成功率、平均応答時間、再割り当て頻度。

これらのシグナルは二つの学習パイプラインにフィードバックされます。

1. **インテント改善** – 誤分類が検出されると、半教師あり再トレーニングが行われます。  
2. **ルーティングポリシー最適化** – 強化学習 (RL) が専門性、可用性、緊急度の重みを更新し、SLA 遵守率と回答品質を最大化します。

結果として、**自己最適化エンジン** が各アンケートサイクルで向上し続けます。

---

## 5. 統合エコシステム

IBRE は **マイクロサービス** として設計され、既存ツールにプラグインできます。

| 統合先 | 用途 | 例 |
|--------|------|----|
| Slack / Microsoft Teams | リアルタイム通知・タスク受諾 | `/procure assign @alice` |
| Jira / Asana | 証拠収集のためのチケット作成 | 複雑な証拠収集用に *Evidence Collection* チケットを自動生成 |
| ドキュメント管理 (SharePoint, Confluence) | 最新ポリシーアーティファクト取得 | 最新暗号化ポリシーバージョンを取得 |
| CI/CD パイプライン (GitHub Actions) | 新リリース時のコンプライアンスチェックトリガー | 各ビルド後にポリシー・アズ・コードテストを実行 |

すべての通信は **相互 TLS** と **OAuth 2.0** 上で行われ、機密アンケートデータが安全な境界外に漏れないようにします。

---

## 6. 監査可能なトレイルとコンプライアンス効果

すべてのルーティング決定は不変のログエントリとして生成されます。

```json
{
  "question_id": "Q-2025-437",
  "intent_id": "EncryptDataAtRest",
  "assigned_owner": "alice@example.com",
  "routing_score": 0.85,
  "timestamp": "2025-12-11T14:23:07Z",
  "evidence_links": [
    "policy://encryption/2025-09",
    "artifact://config/production/db"
  ],
  "confidence": 0.93
}
```

この JSON を **追記専用レジャー**（例: Amazon QLDB やブロックチェーンバックドレジャー）に保存することで、**SOX** と **GDPR** のトレーサビリティ要件を満たします。監査人は各回答の背後にあるロジックを正確に再現でき、**[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)** 監査時の証拠要求サイクルを大幅に削減できます。

---

## 7. 実際の効果 – 簡易ケーススタディ

**企業**：FinTech SaaS 「SecurePay」 (シリーズ C、従業員 200 名)  
**課題**：アンケートの平均ターンアラウンドは 14日、SLA 達成率 30％ 未満。  
**導入**：200 ノードのナレッジグラフを構築、Slack と Jira と連携した IBRE を展開。  
**90日パイロット結果**：

| 指標 | 導入前 | 導入後 |
|------|--------|--------|
| 平均応答時間 | 14 日 | 2.3 日 |
| SLA 遵守率 | 68 % | 97 % |
| 手動ルーティング工数 (時間/週) | 12 h | 1.5 h |
| 監査時の証拠ギャップ数 | 5 件/監査 | 0.8 件/監査 |

ROI は **6.2 倍** と算出され、主に取引速度低下の防止と監査是正コスト削減によるものです。

---

## 8. 今後の展開

1. **クロステナントインテント連携** – 複数顧客がインテント定義を共有しつつデータ分離を保つ、フェデレーテッドラーニングの活用。  
2. **ゼロトラスト検証** – 同型暗号とインテントルーティングを組み合わせ、ルーティングエンジン自体が質問内容を平文で知ることなく処理可能に。  
3. **予測 SLA モデリング** – 時系列予測で製品リリース後のアンケート急増を予測し、ルーティング容量を事前にスケールアウト。

---

## 9. IBRE の始め方

1. **Procurize の設定 → AI モジュール** で「インテントエンジン」を有効化。  
2. **インテントタクソノミー** を定義（既存のデフォルトをインポート可能）。  
3. **所有者のマッピング** – ユーザーアカウントとインテントタグを紐付け。  
4. **証拠ソースの接続**（ドキュメントストレージ、CI/CD アーティファクト）。  
5. **パイロットアンケート** を実行し、ルーティングダッシュボードで結果を確認。

**Procurize ヘルプセンター** の *AI‑Driven Routing* セクションに、ステップバイステップのチュートリアルが用意されています。

---

## <span class='highlight-content'>参照</span> もご覧ください
- [AI‑駆動自動化のためのゼロトラストアーキテクチャ – NIST SP 800‑207](https://csrc.nist.gov/publications/detail/sp/800-207/final)