メインコンテンツまでスキップ

FAQ

XecGuard について (Overview)​

XecGuard とは何ですか？

XecGuard は、CyCraft が開発した AI セキュリティ防護用の Guardrail APIs であり、大規模言語モデル（LLM）に対する各種 Prompt Attacks を防御するために設計されています。悪意のある対話内容をリアルタイムで検知・分析し、Prompt Injection Protection、Prompt Extraction Protection、System Prompt Enforcement、Harmful Content Protection、Malicious Skills Protection、Sensitive Data Protection、さらに Custom Policy による独自のセキュリティポリシー設定を含む、包括的な LLM Safety 防護機能を提供します。
XecGuard は特に AI Agent や各種 AI アプリケーションの利用シーンに適しており、Prompt Injection や攻撃的な投稿などの外部からの悪意ある入力を効果的に防止し、モデルが誤った方向に誘導されたり、タスクから逸脱したり、さらには有害な挙動を取ることを防ぎます。これにより、システム全体の安全性と信頼性をさらに高めることができます。

XecGuard は AI セキュリティアーキテクチャの中でどのような役割を果たしますか？

XecGuard は、AI セキュリティアーキテクチャにおける重要な防護コンポーネントであり、従来のセキュリティツールでは効果的に対応できないことが多いセマンティックレベルの攻撃リスクに対処するために設計されています。XecGuard は User Input と Assistant Response の間に配置でき、ユーザー入力と LLM の応答の双方に対してリアルタイムのセキュリティ分析を行います。これにより、組織は Prompt Injection、Prompt Extraction、不正な指示、機微データの漏えい、企業ポリシーに反するコンテンツリスクなどを検知できます。
AI Agent のシナリオでは、XecGuard は Agent の実行フローが悪意ある指示によって操作されないことを保証する助けとなります。また、出力が組織で定義されたタスク範囲、ロールロジック、制約条件に沿っているかを検査することもできます。セマンティックレベルの検知と遮断を通じて、XecGuard は AI アプリケーションが悪用・誤誘導され、あるいは不適切な挙動を生成するよう誘導されるリスクを低減します。
ただし、XecGuard は組織のセキュリティガバナンス機構全体を置き換えるものではありません。組織は依然として、プロンプト設計、アイデンティティおよびアクセス制御、最小権限、トラフィック監視、DLP、監査ログ、人手によるレビュープロセスを組み合わせ、包括的な AI セキュリティアーキテクチャを構築すべきです。

XecGuard は汎用言語モデルですか、それとも専用のガードレールモジュールですか？

XecGuard は、言語モデル技術をベースに微調整・最適化された専用の Guardrail モジュールであり、汎用的なチャットモデルでも RAG システムでもありません。
その中核的な役割は、AI アプリケーションのフロントエンドとバックエンドの間で「セキュリティガード」として機能することです。XecGuard は、ユーザー入力、モデル出力、または関連するコンテンツが企業のセキュリティルールやガバナンスポリシーに適合しているかを検査し、そのコンテンツを通過させてよいかを判断します。XecGuard の目的は、ユーザーと会話したり、文章を生成したり、一般的な質問に回答したりすることではなく、検知・意思決定・防護に重点を置いています。
XecGuard は API 形式で動作し、コンテンツの書き換えではなく、リスクのある内容のリアルタイムな検知と遮断に重点を置いています。そのため、XecGuard はユーザー入力を自動的に無害な内容へ書き換えることはなく、アプリケーションに代わって最終的な応答挙動を決定することもありません。リスクが検知された場合、アプリケーションは自身の製品ロジック、企業ポリシー、ユーザー体験の設計に基づき、遮断・通知・記録・人手によるレビューへのエスカレーションなどの対応を判断できます。

XecGuard CSP コミュニティ支援プログラム (XecGuard Community Support Program) とは何ですか？ 【※日本は対象外】

XecGuard Community Support Program は、AI 開発者コミュニティがより安全なアプリケーションを構築できるよう支援し、促進することを目的として設立されました。私たちは、現在の開発者コミュニティにおける AI 分野の革新と発展のスピードは非常に速い一方で、セキュリティ機構が同等に重視されていないことを認識しています。そのため本プログラムは、実質的なリソース支援を提供するだけでなく、「AI の Safety はオプションではなく標準装備であるべき」という中核的な考え方を提唱しています。設計の初期段階から安全性をコアアーキテクチャに組み込むことで初めて、AI システムは長期的な信頼性とスケーラブルな発展を実現できます。
資格要件を満たすオープンソースプロジェクトのメンテナーおよびコントリビューターは、3 か月間の XecGuard Lite API サブスクリプションを受けることができ、プログラム期間中は費用は一切発生しません。この支援を通じて、開発者が AI セキュリティ機構を導入するハードルを下げ、より多くのオープンソースプロジェクトが迅速な革新と安全性・安定性の両立を実現できることを期待しています。詳細な申請資格および利用規約については、サービス利用規約をご参照ください。

XecGuard ポリシーとルール設計 (Policy)​

XecGuard は System Prompt に書かれていないグローバルルールを実行できますか？

XecGuard は、企業が設定する全体共通ルール（Global Rules）に対応しており、これらのルールが個別の AI Application の System Prompt に記載されていない場合でも、優先的に検知することができます。
これにより、企業は AI の振る舞いをより柔軟に管理できるようになります。たとえば、特定の役員名、会社名、製品名への言及を禁止するといった運用が可能です。

System Prompt と XecGuard Policy が衝突した場合、どのように判定されますか？

XecGuard は各 Policy を独立して検査し、Policy 間の依存関係は処理しません。
いずれか 1 つの Policy でも違反と判定された場合、API は UNSAFE を返し、どのルールに違反したかを示します。最終的にどのような応答を返すかは、利用者のアプリケーションが自身の利用シーンに応じて判断します。

Guardrail Policy と System Prompt はどのように役割分担すべきですか？

Guardrail Policy は、高位の企業向けセキュリティポリシーを定義するのに適しており、通常は「何をしてはいけないか」という形で記述されます。たとえば、特定のコンテンツや特定のリスク行為の禁止などです。
一方、ルールが「AI アプリケーションが何をすべきか」を示すもの、あるいはタスクフローや詳細条件に関わるものである場合は、Application の System Prompt に記載する方が適しています。
つまり、System Prompt はタスクを定義し、Guardrail Policy は越えてはならない一線を定義します。

Guardrail Policy が長すぎる、または数の上限を超える場合はどうすればよいですか？

現在、Policy には 2 組のカスタムルールモジュールを含めることができ、各組につき最大 3 つのカスタムルールを設定できます。各 Rule は最大約 400 英単語までです。つまり、1 回の設定で最大 6 つのルールを構成できます。
ルール数が多い場合は、AI Application の動作条件をできるだけ明確に System Prompt 側に記載し、そのうえで XecGuard をより高位のセキュリティ防護として利用し、モデルの準拠性を強化することを推奨します。

XecGuard は LLM のハルシネーションを検知できますか？

可能です。XecGuard は Context Grounding 検知機能を提供しており、特に RAG シーンにおける忠実性ハルシネーション（Fidelity Hallucination）の検査に適しています。ユーザーが RAG の参考資料をコンテキストとして提供した場合、XecGuard は応答がそれらの資料に従っているかを検知し、完全（complete）、不完全（incomplete）、根拠欠如（ungrounded）、情報衝突（conflicting information）の 4 種類の結果を返します。
ハルシネーションは一般的に次の 2 種類に分けられます。
Factual Hallucination（事実性ハルシネーション）とは、モデルが生成した内容が現実世界の事実と一致しないことを指します。つまり、情報そのものが誤っている、存在しない、古い、または信頼できる根拠を欠いている場合があります。モデルは不確実な情報に直面したり対応する知識を持たなかったりすると、「わかりません」と答える代わりに、論理的に整合した回答を「作り上げて」しまう傾向があります。Factual Hallucination には、外部のファクトチェックや知識更新の仕組みが必要です。
Fidelity Hallucination（忠実性ハルシネーション）とは、モデルの応答が一見もっともらしく、内容自体は必ずしも誤りではないものの、与えられた出典、コンテキスト、タスク要件、または元資料に忠実に従っていない場合を指します。モデルが提供された出典を超えて情報を追加・推論・歪曲してしまうことがあります。Fidelity Hallucination には、Context Grounding、引用検証、出典制約、出力の一貫性チェックが必要です。

XecGuard の PII Policy はどのようなデータ形式に対応していますか？

現在、XecGuard は、住所、電話番号、メールアドレス、クレジットカード番号、IBAN、台湾の国民身分証番号、パスポート番号、国民健康保険証番号、銀行口座番号、法人統一番号、車両ナンバープレートなど、各種の一般的な個人情報および機微データ形式の検知に対応しています。対応範囲は一般的な国際形式に加え、台湾固有の各種ローカル形式もカバーしています。
なお、PII Policy はコンテンツに個人情報に関連する属性が含まれているかを検知するものであり、悪意ある行為の検知アラートとして設計されているわけではありません。そのため検知の方針は比較的広範であり、定義される Risk Level も比較的低く設定されています。PII Policy は金融系のアプリケーションシーンやその他の特定のユースケースにより適しています。

XecGuard は入力または出力に著作権やその他の知的財産に関わる内容が含まれているかを検証できますか？

ある程度は可能です。XecGuard は、Custom Policy や Rule など、お客様が定義したルールを通じて、組織のデータ利用ポリシーやコンプライアンス管理の適用を支援できます。たとえば、従業員が特定のプロジェクト資料、ソースコード、社内文書、あるいは特定の著作権表示・機密表示・知的財産関連情報を含む内容を AI システムへ送信していないかを検査する独自ポリシーを定義できます。これにより、AI の入力や出力が著作権、営業秘密、その他の知的財産リスクに関わる可能性があるかを検知・検証する助けとなります。
ただし、明確にしておくべき点として、XecGuard は Prompt Attack の検知・防御システムであり、法務コンプライアンス専用の審査システムではありません。そのため、XecGuard は組織の AI 利用ガバナンスや情報漏えいリスク管理の枠組みの一部として活用できますが、著作権法、特許法、商標法、営業秘密法などの関連法規に関する既存の包括的な法務審査・コンプライアンス管理の仕組みを置き換えるものではありません。

XecGuard 展開アーキテクチャ、性能 (Deployment and Performance)​

スキャン速度が十分でない場合、どのように高速化できますか？

性能面では、分析速度は複数の要因に影響されます。まず、有効化する Policy の数が多いほど、分析に必要な時間も増加します。観測された結果に基づくと、Policy を 1 つ追加するごとに、平均で約 350 ～ 800 ミリ秒の遅延が増加します。また、User Input と Assistant Response の両方を同時に分析する場合、全体の処理時間は従来の約 2 倍になる可能性があります。さらに、Context の内容が長いほど分析性能にも影響し、処理時間は長くなります。


性能改善の方法としては、以下が挙げられます。

  • 必要な Policy のみを有効化し、1 回のスキャンで適用するルール数を減らす
  • API 呼び出し回数を減らし、すべての対話ターンを毎回検査しない
  • Agent / A2A / MCP シナリオでは、逐語的にスキャンするのではなく、重要なステップ（ツール呼び出し前、最終結論の生成前など）のみを検査する
  • 瞬間的な大量同時呼び出しを避け、必要に応じてリクエストキューやトラフィック制御の仕組みを組み合わせる
XecGuard API はどのクラウドプラットフォームに対応していますか？

XecGuard は現在 AWS および Azure のクラウドアーキテクチャに対応しており、近日中に GCP への展開にも対応する予定です。

On-Premise 導入時の推奨ハードウェア仕様は何ですか？

On-Premise 導入は当社の標準提供範囲には含まれていません。現在、XecGuard の標準版は Cloud API サービスとしてのみ提供されています。自社構築の要望がある場合は、別途プロジェクトベースでの相談が必要です。
プロジェクト版では On-Premise 導入に対応する計画がありますが、最終的な仕様は実際の案件内容に応じて確定されます。詳細は、CyCraft チームへ直接お問い合わせください。

XecGuard は HA モードに対応していますか？

はい、対応可能です。
LiteLLM の API Gateway を利用することで、Gateway レイヤーでトラフィックを制御し、複数台の XecGuard API Server へ振り分ける構成が可能です。
ただし、その場合は複数台のマシンを調達する必要があり、あわせて LiteLLM サービスの導入および設定も必要となります。

XecGuard にはダッシュボードや Web UI インターフェースがありますか？なぜ API でしか操作できないのでしょうか？

XecGuard の有償商用版には Web 管理画面および Dashboard が提供されています。Standard、Advanced などの商用ライセンスは、企業ユーザー向けにのみ提供されています。
一方、XecGuard Community Support Program のユーザーには Lite ライセンスが提供されており、API インターフェースのみ利用可能で、Web Dashboard 管理画面は提供されません。ただし、API インターフェースは Web Dashboard 管理画面と同じ中核機能を提供しています。唯一の違いは、Lite ライセンスにおける API Rate Limit が 100 RPM と比較的低い点のみです。

XecGuard は複数のユーザーロールを持つ Multi-Tenant 構成に対応し、複数の AI アプリケーションを管理できますか？

はい。XecGuard は Multi-Tenant 構成と複数ロールの権限管理に対応しており、企業グループ、子会社、あるいは異なる事業部門が複数の AI アプリケーションやさまざまな利用シーンを一元的に管理することを支援します。
XecGuard は柔軟な「多階層ルール管理機構」を提供しており、異なる LLM、異なる Chatbot 機能、異なる AI アプリケーション、あるいは異なる子会社・部門の要件ごとに、別々の Guardrail Rules やセキュリティポリシーを設定できます。同時に、企業は異なる Service Token を用いて AI アプリケーションや利用シーンを区別し、利用統計、ポリシー適用、記録の追跡、運用管理を個別に行うことができます。これにより、AI ガバナンスはより明確になり、スケールも容易になります。
さらに、XecGuard Dashboard は企業のセキュリティガバナンスや階層型管理のニーズに対応するため、以下を含む複数のアカウントロールを提供しています。

  • Territory Admin：企業グループ管理者。グループ全体および子会社または組織間の横断的な設定を管理できます。
  • Org Manager：子会社または組織の管理者。自組織内のアプリケーション、ルール、設定を管理できます。
  • Org User：子会社または組織の API 利用者。Scan API を用いてセキュリティ検知を実行できます。
  • Org Auditor：子会社または組織の読み取り専用アカウント。記録、設定、レポートデータを閲覧できますが、システム設定は変更できません。

XecGuard は、Multi-Tenant 構成、Service Token によるトラフィック管理、ロールベースの権限制御を通じて、複数の AI アプリケーション、部門、子会社をまたぐ環境において、一貫性があり管理しやすい AI セキュリティガバナンス機構の構築を支援します。

XecGuard の On-Premise 版において、お客様が Red Hat を別途購入して代替することはできますか？

いいえ、代替することはできません。
XecGuard の On-Premise 版は完全な製品パッケージとして提供されており、関連するシステムコンポーネントをお客様が分離・置き換えることはできません。これは、将来の保守運用、アップグレード、互換性検証、トラブルシューティングに関する管理上のリスクを避けるためです。
XecGuard システムは複数 VM / Docker アーキテクチャを含み、NVIDIA Linux Driver および関連する GPU ランタイム環境を必要とします。OS のバージョン、ドライバ、システムパラメータ、性能設定はいずれも製品要件に基づいて最適化・検証されています。そのため、On-Premise 版は現在、お客様による指定や置き換えを行った Linux OS には対応していません。

XecGuard は PostgreSQL DB を採用していますが、お客様が SQL Server を別途購入し、共同管理の対象として代替することはできますか？

いいえ、代替することはできません。
XecGuard の On-Premise 版は完全な製品パッケージとして提供されており、関連するシステムコンポーネントをお客様が分離・置き換えることはできません。これは、将来の保守運用、アップグレード、互換性検証、トラブルシューティングに関する管理上のリスクを避けるためです。
XecGuard のシステムサービス、データベーススキーマ、アプリケーション統合方式、デプロイプロセスはいずれも、PostgreSQL および既存のコンテナ化ランタイム環境向けに開発・最適化・検証されています。そのため、On-Premise 版は現在、お客様による指定や置き換えを行ったデータベースには対応しておらず、PostgreSQL を SQL Server に置き換えることもできません。

XecGuard API の利用 (XecGuard API Usage)​

XecGuard は JSON などの構造化出力に対応していますか？

はい。XecGuard のすべての API は JSON フォーマットで、Function Calling（Tool Calls）などとも組み合わせて利用できます。これにより、後続システムでの結果の自動解析、連携、処理が容易になります。

XecGuard API は既存の AI アプリケーションに統合しやすいですか？

はい。XecGuard API の設計は、OpenAI API をはじめとする業界で一般的な統合仕様に近いため、既存の AI アプリケーションには、API エンドポイント、トークン、関連パラメータを調整するだけで迅速に接続でき、導入コストやシステム改修のハードルを下げることができます。
さらに、XecGuard は LiteLLM Plugin モジュールを提供しており、既存の AI Gateway アーキテクチャに直接統合できます。これにより、従来の LLM Gateway を、Guardrail 防護機能を備えた AI セキュリティゲートウェイへとアップグレードできます。このモードでは、アプリケーション側は通常、大きな改修を行うことなく、Prompt Attack の検知・防護・ポリシー制御機能を導入できます。

XecGuard は streaming 応答のリアルタイム検査に対応していますか？

現時点では streaming 検査には対応していません。
現在の条件では、XecGuard の遅延は約 350 ～ 800 ミリ秒であり、通常は待ち時間短縮のために特別に streaming を用いる必要はありません。

XecGuard の料金体系はどのようになっていますか？自社にどのプランが必要か、どのように見積もればよいですか？

XecGuard の重要な利点の一つは、料金体系が Token の使用量に基づくものではなく、主に API リクエスト数とリクエスト頻度に基づいている点です。Token 単位で課金される（token-based pricing）他の Guardrail ではコストが大きくなりがちですが、XecGuard のモデルでは、AI アプリケーションを大規模に利用する際の Guardrail 防護コストを見積もり・管理しやすく、入力内容や会話履歴の長大化、モデル出力の増加によるコストの急騰を回避できます。
性能仕様の面では、XecGuard の 1 つの計算ユニットあたり最大で約 1,500 RPM（Requests Per Minute）に対応できます。当社の実務経験では、この規模でおよそ 300 ～ 400 の同時利用ユーザーに対応できます。
ただし、実際に対応可能なユーザー数は、AI アプリケーションの設計、ユーザーの操作頻度、リクエスト内容の長さ、streaming やマルチターン会話の利用有無、アプリケーションシーンの特性などによって変動します。そのため、上記の数値はあくまで初期的なキャパシティプランニングの参考にとどめ、実際の導入にあたっては、企業のアプリケーションシーンやトラフィックモデルに基づいた負荷試験とキャパシティ評価を実施することを推奨します。

XecGuard の Dashboard User ログインは、企業の SSO や AD とどのように連携できますか？SAML にも対応していますか？

XecGuard の Dashboard User ログインは OAuth 2.0 をベースとしており、認証レイヤーとして OIDC (OpenID Connect) を使用します。XecGuard は OIDC を通じて AWS Cognito と連携し、JWT 形式のトークンを取得します。
お客様の社内で AD FS、Azure AD / Microsoft Entra ID SAML、または従来型の Okta SAML などの企業向け SSO を利用している場合、企業側の IdP は OIDC ではなく SAML を使用していることがあります。この場合、以下のような構成で連携できます。
User → XecGuard Dashboard ← OIDC → AWS Cognito ← SAML → Enterprise IdP (AD FS, Azure Entra ID, Okta SAML, etc.)
AWS Cognito は SAML をネイティブにサポートしています。そのため、お客様が AD / AD FS などの企業 SSO を使用している場合、SAML 連携は Cognito レイヤーで処理し、XecGuard Dashboard のフロントエンド側は OIDC のまま変更せずに利用できます。
なお、実際の導入版では、AWS Cognito の代替となる同等のソリューションを使用しています。

XecGuard API の Error Code にはどのようなものがありますか？

400 Bad Request
説明：リクエスト形式が不正、または入力内容が Context Length 上限を超過しています。
よくある原因と対処方法：

  • request body の項目名と型が正しいか確認する
  • 入力が長すぎる場合は、messages の内容を短くするか、不要な会話履歴を削除する
  • Scan 実行時に Policy を 1 つも指定していない、または無効な Policy ID を使用した場合もこのエラーが発生する
  • pattern_regex Policy を使用する場合は、ルールが有効な Regex 構文であることを確認する

401 Unauthorized
説明：API Token が無効、未提供、または License が期限切れです。
よくある原因と対処方法：

  • Authorization header の形式が Bearer <YOUR_TOKEN> であるかを確認する
  • 完全な Token 文字列を使用しているか確認する（Service Token 形式：xgs_[16桁hex]_[シークレットキー]）
  • Token の状態が enable であり、有効期限内であることを確認する
  • GET /xecguard/v1/licenses を利用し License が有効期間内か確認する

403 Forbidden
説明：認証は完了しているものの、その Token に当該操作の権限がありません。
よくある原因と対処方法：

  • 管理系操作（Token / Policy の作成・更新、統計の参照）は Management Token（xgm_）を使用する必要がある
  • スキャン系操作（/scan、/grounding）は Service Token（xgs_）を使用する必要がある
  • 対象エンドポイントに対応した正しい Token 種別を使用しているか確認する

409 Conflict
説明：リクエストが現在のシステムリソース状態と競合しています。
よくある原因と対処方法：

  • よくあるケースとして、同名の Policy や Service Token の重複作成、更新時のバージョン不一致がある
  • 作成前に対象リソースがすでに存在するか確認する（GET /xecguard/v1/policies または GET /xecguard/v1/tokens）
  • 既存リソースを変更する場合は、再度 POST するのではなく PATCH を使用する

413 Content Too Large
説明：リクエスト内容がシステムで受け付け可能な最大 Context Length 上限（128K tokens）を超えています。
よくある原因と対処方法：

  • messages の内容を短くする、または不要な会話履歴を削除する
  • 入力内容が 128K tokens の上限を超えていないか確認する
  • XecGuard はリアルタイムのチャット内容分析向けに設計されており、大型ドキュメントや完全なファイルのスキャンには適していない

422 system_prompt_exceeds_license_scan_budget
説明：System Prompt が License ごとの 1 回のスキャンで許可される Token 上限を超えています（Lite：10K tokens／Standard・Advanced：38K tokens）。
よくある原因と対処方法：

  • System Prompt の内容を短縮し、対応プランの上限内に収める
  • System Prompt が複数のセグメントに分かれている場合は、結合後の総長が上限に近づいていないか確認する

429 Too Many Requests
説明：1 分あたりの API 呼び出し回数が、License で許可されるレート制限（RPM）を超えています。
よくある原因と対処方法：

  • Retry with Backoff（指数バックオフ再試行）を実装する
  • リクエストキューやトラフィック制御を導入し、瞬間的な大量同時呼び出しを避ける
  • 長期的に頻発する場合は、License プランのアップグレードを検討する
Token が無効、または License が期限切れの場合はどうなりますか？

Service Token が存在しない、無効化されている、または License が期限切れの場合、API は 401 Unauthorized または 403 Forbidden を返し、すべての API エンドポイントが利用できなくなります。
License の有効期限が切れると、Token 自体の期限が残っていても、いかなる操作も実行できません。新しい Management Token を取得するためには、License を再申請する必要があります。
予期せぬサービス停止を避けるため、GET /xecguard/v1/licenses を定期的に実行し、License の有効期限を確認することを推奨します。

Management Token を紛失した、または削除したい場合はどうすればよいですか？

Management Token は各利用者に対して一意の管理用認証情報であり、利用者自身で再生成または削除することはできません。
Management Token を紛失した場合、再発行が必要な場合、またはプランを早期終了して Token を削除したい場合は、メールでご申請ください。
現時点では、これらの操作は手動で対応しており、申請受領後、速やかにご案内いたします。

Service Token を紛失した、または削除したい場合はどうすればよいですか？

XecGuard の Service Token を紛失した、漏洩の疑いがある、または使用しなくなった場合は、XecGuard のアプリケーション画面から対応できます。
Application ページに移動し、対象のアプリケーションを選択して、Manage 機能から Service Token の再生成または削除を行ってください。

  • Token を紛失した、または漏洩の疑いがある場合は、Regenerate Service Token を使用して新しい Token を生成することを推奨します。
  • Token を使用しなくなった場合、または対象アプリケーションが XecGuard API へアクセスする必要がなくなった場合は、Service Token を直接削除できます。

Service Token を再生成すると、システムは新しい Token Secret を発行します。新しい Token はセキュリティ上の理由から一度しか表示されず、ウィンドウを閉じると再表示できないため、直ちにコピーして安全に保管してください。

検知結果に誤検知や見逃しがある場合、どのように改善できますか？

自然言語の内容は文脈によって大きく異なり、「悪意」や「安全でない内容」を判定するための完全に一貫した精密な業界標準は存在しないため、いかなる AI Guardrail システムでも 100% の検知率を保証することはできません。実際の検知効果は、アプリケーションシーン、System Prompt の設計、タスクの境界、ユーザー入力内容、Guardrail Policy / Custom Policy ルールの記述方法などの影響を受けます。
誤検知や見逃しが発生した場合は、以下の方向で調整を検討してください。

  • Custom Policy Rule の記述を最適化する ルールの説明をより明確にし、曖昧すぎる、広範すぎる、または条件のないルールを避けます。必要に応じて肯定例・否定例を追加し、遮断すべき内容と許可すべき内容の境界を、システムがより正確に理解できるようにします。
  • 明示的なブラックリストや禁止条件を追加する 企業に、出現してはならない特定の用語、プロジェクト名、機密コードネーム、データ種別、高リスク行為などがすでにある場合は、XecGuard Policy に追加のブラックリストや明示的な禁止条件を加えることで、特定シーンでの防護を強化できます。
  • アプリケーションの System Prompt を最適化する 検知結果がアプリケーションのタスク境界に関係する場合は、アプリケーションの System Prompt を見直し・強化し、ロール設定、許可される挙動、禁止される挙動、タスク制約をより明確にすることで、System Prompt Enforcement をより効果的に機能させることを推奨します。

総じて、最良の Guardrail 効果は通常、「明確なアプリケーションのタスク境界」と「明示的なセキュリティポリシールール」を組み合わせることで得られます。Custom Policy の記述方法や関連するベストプラクティスについては、XecGuard API ドキュメントの該当セクションをご参照ください。

Service Token と Management Token の違いは何ですか？
  • Service Token：実際の API 呼び出し（例：Guardrail Scan）に使用します。複数の Service Token を持つことができ、その上限数は License プランにより異なります。
  • Management Token：各 License ごとに 1 つだけ存在する一意の Management Token であり、Token 管理、Policy 管理、使用量統計、システムガバナンスなどの管理機能に使用します。

    ⚠️ Management Token と Service Token はいずれも bearer token であり、保持者がそのままリソースへアクセスできる認証情報です。これらの認証情報は非常に機微であるため、厳重に保管し、アクセス権限を厳格に管理し、絶対に漏洩させないでください。
Request Body に形式上の制限はありますか？

Request Body は有効な JSON 形式であり、かつ API で定義されたリクエスト構造に従っている必要があります。
送信内容の形式が誤っている、または解析できない場合、API はエラーメッセージを返し、その安全検査は実行されません。

Policy 名称を誤って指定するとどうなりますか？

Scan リクエストの policy_names に存在しない Policy 名を指定した場合、API は 400 Bad Request を返し、エラーメッセージとして "The following policy_names do not exist: <誤った名称>" が返されます。この場合、当該スキャンは実行されません。
完全かつ正確な Policy 名称を使用していることをご確認ください（例：Default_Policy_GeneralPromptAttackProtection）。※名称は大文字・小文字を区別します。
現在利用可能なすべての Policy 一覧は、GET /xecguard/v1/policies により確認できます。名称入力ミス防止のため、事前の確認を推奨します。

XecGuard API はスキャン分析後、どのような結果ステータスを返しますか？

Guardrail Scan が完了すると、XecGuard API は当該セキュリティ検査の判定結果を返し、アプリケーション側で後続処理や意思決定を行えるようにします。主な返却情報は以下のとおりです。

  • Decision（SAFE / UNSAFE）：入力または出力内容にセキュリティリスクがあると判定されたかどうか
  • Violated Policy：セキュリティ判定をトリガーした Policy 名
  • Violated Rules：違反と判定されたルール項目
  • Rationale：当該内容がリスクと判定された理由説明
  • Trace ID：UNSAFE と判定された場合に生成される対応する Security Trace。後続の詳細記録照会に利用可能

    これらの情報は、応答制御、セキュリティ警告表示、イベント監査、リスク分析などに活用できます。

XecGuard 技術仕様 (Specifications)​

XecGuard のコンテキスト処理能力と入力上限はどの程度ですか？

1 回のリクエストで受け付け可能な最大 Context Length は 128K tokens です。入力がこの上限を超えた場合、API は 413 Content Too Large を返し、そのリクエストは処理されません。


実際にセキュリティ検査の対象となる範囲は、License プランによって異なります。Lite 版では最後の 10K tokens のみ、Standard および Advanced 版では最後の 38K tokens のみがスキャン対象です。入力がこの検査範囲を超える場合、システムは最後の一部のみを分析し、それ以前の内容は検査対象に含まれません。そのため、判定の完全性や正確性に影響する可能性があります。


このため、XecGuard はリアルタイムなチャット内容や Prompt / Response の分析には適していますが、大型ドキュメントや完全なファイルのスキャンには推奨されません。

XecGuard はどのような検知モジュールと Policy を提供していますか？

XecGuard は現在、8 つの主要な検知モジュールおよび Policy を提供しています。

General Prompt Attack Protection（汎用プロンプト攻撃防護）
説明：大半の Prompt Injection、Prompt Extraction、防護回避（Evasion）などの攻撃行為を検知・防止し、攻撃者がモデル挙動を上書きしようとしたり、保護されたシステム指示を暴露させようとしたり、難読化やエンコード手法によってセキュリティ機構を回避しようとする行為を防ぎます。

System Prompt Enforcement（タスク文脈遵守）
説明：企業が定義した AI Agent のタスク範囲に AI システムが厳格に従うことを保証し、従来型のコンテンツフィルタリングを超えた真のコンテキスト認識型セキュリティを実現します。

Content Bias Protection（コンテンツ偏見防護）
説明：偏見、嫌がらせ、有害なステレオタイプを含む出力を検知・緩和し、生成コンテンツが差別的にならず、保護対象属性、健康状態、社会経済的背景を尊重することを保証します。

Harmful Content Protection（有害コンテンツ防護）
説明：キーワードフィルタリングだけに依存せず、意味レベルの分析により、公序良俗に反する、有害または危険な AI 出力を検知・防止します。

PII & Sensitive Data Protection（個人情報・機微情報防護）
説明：エンタープライズ AI におけるプライバシーおよび情報漏えい防止を実現し、AI が個人情報や機微情報を露出しないようにします。

Malicious Skills Protection（悪意ある Agent Skills 防護）
説明：AI Agent の Skills および関連ファイル内容に、システムに対して悪意ある、または有害な内容が含まれていないかを検知し、Agent AI を悪意ある Skills の影響から保護します。

Custom Policy Enforcement（独自 AI セキュリティポリシー）
説明：組織が自社業務や AI / Chatbot のタスクルールに応じて、自然言語で Guardrail Rule を定義し、専用の AI ガバナンスルールとして強制適用できるようにします。

Context Grounding Validation（コンテンツ・ハルシネーション検証）
説明：API 専用機能であり、AI ハルシネーションの検知に用いられます。ユーザーが提供した文書や承認済みの RAG コンテキストに基づいて、応答内容が厳格に従っているかを検査します。

XecGuard にはどのような License プランがありますか？

XecGuard には主に 3 種類の License プランがあります。

  • XecGuard Lite：最大リクエストレート（RPM）は 100（～180）requests/min、Service Tokens（API keys）は最大 2 個、Context 長は約 10K Tokens。POC や小規模導入、XecGuard Community Support Program 向けに設計されています。
  • XecGuard Standard：最大リクエストレート（RPM）は 700 requests/min、Service Tokens は最大 7 個。大多数の本番利用や複数アプリケーション環境に推奨されます。
  • XecGuard Advanced：最大リクエストレート（RPM）は 1500 requests/min、Service Tokens は最大 15 個。高トラフィック環境やエンタープライズ規模の導入に適しています。
    トラフィック量や管理要件に応じたプラン選定またはアップグレードが必要な場合は、営業担当またはシステム管理者へお問い合わせのうえ、詳細をご確認ください。