なぜ Starfort か: AI リスクの階層
Starfort が存在するのは、AI リスクが単一の均質な問題ではないからです。AI リスクは 3 つの階層に区分され、それぞれ異なる方法で扱われます。この順序づけこそが「中央で適用し、ローカルで最適化する」という考え方の根拠になります。
これは 2 チームによる責任分担に対応します。セキュリティチームが AI セキュリティリスクを担い、AI ガバナンスチームがサービス／品質リスクを担い、規制リスクは両チームが共同で担います。Starfort はまさにこの協働を支援するように設計されています。最も重要なポリシーは中央から適用される一方、各チームは品質をチューニングする自由を保持します。
Starfort の使い方
3 つのエントリーポイントがあり、それぞれ異なる制御レベルを提供します。これらは同じ Guardian エンジンとポリシーを共有します。API — サービスレベル
社内／社外サービス（バックエンド、チャットボット）が、モデルの前後で Guard API を呼び出してガードレールを組み込みます。
Desktop Agent — デバイスレベル
従業員が日常的な AI ツールを利用する間、Desktop Agent（Windows）がエンドポイント上でポリシーを透過的に適用します。
Proxy Server — インフラレベル
外部サービスのサーバーサイドのエントリーポイントで行われる AI 呼び出しを、Starfort 経由でルーティングします。
Guardian がリクエストに対して行うこと
すべてのコンテンツは、お客様の Guard Policy に照らして評価され、アクションが割り当てられます。アクションの種類はポリシータイプによって異なります。PASS
コンテンツは変更されずにそのまま通過します。
MASK
機微な箇所がトークン（例:
[PHONE_NUMBER_1]）に置き換えられます — PII ポリシー。BLOCK
リクエストは AI サービスに到達する前に停止されます。
中核となる概念
Guardian
コンテンツを検査し、アクションを決定するエンジンです。
Guard Policy
Guardian が適用する PII および Topic のルールです。
組織階層
Company › Organization › Project、および Guardian がプロジェクトにどのように紐づくか。
用語集
本ドキュメントで使用されるすべての Starfort 用語の定義。
v1.3 の新機能
- Forge — 本番トラフィックに触れる前にポリシーをテスト — Project Guardian ごとに Test Dataset（入力と期待判定値のペア）を登録し、選択したポリシーバージョンで Experiment を実行して、PASS / MASK / BLOCK の精度を測定します。失敗ケースがどのポリシーを修正すべきかを示し、再実行で改善を確認できます。ポリシーのテスト (Forge)を参照してください。
- Opticon フェイルセーフ (Fail-Open / Fail-Closed) — 判定は下されたものの監査トレースの記録が最終的に失敗したリクエストの扱いを、プロジェクト単位で選択できるようになりました。従来どおりそのまま返す（Fail-Open、デフォルト）か、リクエストをブロックする（Fail-Closed）ことで、コンプライアンスが重要な運用における監査ギャップを解消します。トレースの監視 (Opticon)を参照してください。
本ドキュメントは Starfort v1.3 を対象としています。製品名 — Starfort、Guardian、Guard Policy、Guard API、Opticon、Control Profile — はすべての言語で英語のまま維持されます。