Horizon Fidelity Monitor

Horizon Fidelity Monitor

「品質はモデルの特性ではなく、会話の特性です。」

Horizon は、AI エージェント向けのリアルタイム会話ヘルスモニターです。複数ターンにわたる会話の構造的な動態――意味のドリフト、情報利得、存在論的ギャップの幅、時間的な非同期、概日リズムに伴う認知負荷、会話の速度、因果的到達可能性――を追跡します。これらは、LLM が会話の内部から確実に明らかにできない次元です。

Horizon は2 つの計測プレーンを備えています。上記の会話プレーンは常に有効で、対話のターンごとに健全性を測定します。オプションのミッションプレーン――Memento Mori――は、経過した暦上の時間を目標と照合して測定します。具体的には、経過時間、締め切り、停滞、エンティティごとのレイテンシ、有限の期間に占める割合を測定します。ストアを設定するまでは動作しません。ミッションプレーンを参照してください。

Horizon は、操作、迎合、人間への影響を検出するものではありません。測定するのは会話の動態であり、エージェントがユーザーを誘導したり、へつらったりしているかどうかではありません。LEGAL.md §1を参照してください。

なぜ外部モニターが必要なのでしょうか。LLM の自己認識は限定的で信頼性に欠けます。内省に関する研究では、自己認識が部分的で脆く、複雑なタスクや分布外のタスクでは劣化することが示されています（Binder et al. 2024、arXiv:2512.12411）。そのため、モデル自身に会話の動態を報告させるのではなく、Horizon はモデルを一切呼び出さず、安価で決定論的な常時稼働の演算によって外部から測定します。

これが必要な理由

複数ターンにわたる AI エージェントでは、精度が低下します。ICLR 2026 Outstanding Paper の「LLMs Get Lost In Multi-Turn Conversation」（Laban、Hayashi、Zhou、Neville — Microsoft Research / Salesforce Research）は、複数ターン評価で平均 39% の精度低下を報告しています。これは構造的な特性であり、標準的な可観測性ツール（LangSmith、RAGAS、DeepEval）では捉えられません。これらのツールは応答を測定し、会話を測定しないためです。

Horizon はこのギャップを埋めるために開発されました。**まず可観測性を重視します。**応答レベルのツールが見逃す会話の動態を、モデル呼び出しなしの安価で決定論的な演算によって明らかにします。Horizon のイベントをきっかけに再グラウンディング介入を行った 4 つの対照 A/B シナリオでは、複合品質が +15.7% 向上し、ハルシネーションイベントが 87% 減少しました。ただし、これらはコントローラーを手動で調整した、合成のスクリプト化シナリオであり、本番環境での結果ではありません。確実な成果ではなく、有望な社内エビデンスとして扱ってください（検証およびLEGAL.md §5を参照）。各シグナル――情報利得、乖離、推定された存在論的ギャップの幅、因果的到達可能性――は、テキストの埋め込みとタイムスタンプに基づいて計算する、情報理論または算術の標準的な指標です。定義の全文は4D 時空シグナルを参照してください。

• 需要の根拠を読む → ICLR 2026 Outstanding Paper（Laban et al.）
• カテゴリーに関する議論を読む → docs/content/naming-the-category-conversation-dynamics-monitoring.md
• エンジニアリング上の根拠を読む → docs/content/why-every-production-agent-needs-conversation-dynamics-monitoring.md

はじめに

3つの方法があります。ワークフローに合ったものを選んでください。

方法 1 — ホスト型 MCP（最速、インストール不要）

Cursor、VS Code、Claude Desktop のどのワークスペースにも、Horizon を最速で追加できます。Python は不要です。

アルファキーをリクエスト → ディスカッションを開始し、クライアント用の設定を追加してください。

Cursor（~/.cursor/mcp.json）：

{
  "mcpServers": {
    "horizon": {
      "url": "https://horizon.leocelis.com/sse",
      "headers": { "Authorization": "Bearer YOUR_KEY_HERE" }
    }
  }
}

VS Code / GitHub Copilot（ワークスペース内の .vscode/mcp.json）：

{
  "servers": {
    "horizon": {
      "type": "http",
      "url": "https://horizon.leocelis.com/sse",
      "headers": { "Authorization": "Bearer YOUR_KEY_HERE" }
    }
  }
}

VS Code に関する注意： "mcpServers" ではなく "servers" を、また "type": "http" を使用してください。VS Code はまず Streamable HTTP を試し、自動的に SSE にフォールバックするため、"type": "http" は /sse URL で動作します。

Claude Desktop（~/Library/Application Support/Claude/claude_desktop_config.json）：

{
  "mcpServers": {
    "horizon": {
      "url": "https://horizon.leocelis.com/sse",
      "headers": { "Authorization": "Bearer YOUR_KEY_HERE" }
    }
  }
}

これで完了です。MCP クライアントを再読み込みすると、new_conversation、process_turn、configure_session の3つのツールが表示されます。

アルファ版へのアクセス： Horizon のホスト型エンドポイントは、現在プライベートアルファ版です。実際のプロジェクトを監視したいエージェント開発者にキーを配布しています。キーをリクエストするには、ディスカッションを開始してください。ユースケースを説明いただければ、キーをお送りします。

方法 2 — pip でインストール（ライブラリ連携）

PyPI にはまだ公開されていません。公開されるまでは、以下の方法 3（ソースからインストール）を使用してください。

pip install horizon-monitor

インストールを確認します（5つの標準シナリオでパイプライン全体を実行します。所要時間は約25秒です）。

horizon-validate

方法 3 — ソースから MCP サーバーを実行

pip install 'horizon-monitor[mcp]'
horizon serve                             # stdio — for Cursor, Claude Desktop
horizon serve --transport sse --port 3847 # SSE — for web/team deployments

~/.cursor/mcp.json に追加します：

{
  "mcpServers": {
    "horizon": { "command": "horizon", "args": ["serve"] }
  }
}

Cursor と Claude Desktop の詳細なセットアップガイド：docs/integrations/

監視対象

標準的な可観測性ツールは個々の応答品質を評価します。Horizon が評価するのは会話品質です。これは構造的に異なる問題です。

Horizon は、応答ごとの品質評価ツールや LLM 評価者による品質評価ツールに取って代わるものではありません。差別化要因は、測定の方法です。すべてのターンを対象に、LLM 呼び出しなしの算術演算で決定論的に測定します。そのため実質的に無料で、常時稼働します。一方、サンプリングされた LLM 評価者による評価はサンプルごとにコストがかかり、通常はリアルタイムではなく、オフラインまたは非同期で実行されます。

クイックスタート

from horizon_monitor import FidelityMonitor
from datetime import datetime, timezone

monitor = FidelityMonitor()
session_id = monitor.new_conversation(metadata={"domain": "technical"})

result = monitor.process_turn(
    session_id,
    human_message="How does Python handle memory management?",
    agent_response="Python uses reference counting and a cyclic garbage collector...",
    timestamp=datetime.now(timezone.utc).isoformat(),
)

print(f"Fidelity:         {result.fidelity_score:.2f}")
print(f"Health:           {result.health_status}")
print(f"Circadian factor: {result.circadian_factor:.2f}")
print(f"Causal horizon:   {result.reachable_turns} reachable turns")
for event in result.events:
    print(f"  Event: {event.type} (confidence={event.confidence:.2f})")

フレームワーク連携

OpenAI SDK

from openai import OpenAI
from horizon_monitor import FidelityMonitor

monitor = FidelityMonitor()
session_id = monitor.new_conversation()
client = monitor.wrap(OpenAI(), session_id)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Tell me about quantum computing."}]
)

traj = monitor.get_trajectory(session_id)
print(f"Fidelity: {traj.current_fidelity:.2f}  T*: {traj.estimated_t_star}")

monitor.wrap() は、テストやリプレイ用にカスタムのタイムスタンププロバイダーとコンテキストプロバイダーを受け付けます。

Anthropic SDK

from anthropic import Anthropic
from horizon_monitor import FidelityMonitor

monitor = FidelityMonitor()
session_id = monitor.new_conversation()
client = monitor.wrap(Anthropic(), session_id)

response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Explain RLHF."}]
)

LangChain

from langchain_openai import ChatOpenAI
from horizon_monitor import FidelityMonitor
from horizon_monitor.integrations.langchain import HorizonCallback

monitor = FidelityMonitor()
session_id = monitor.new_conversation()
callback = HorizonCallback(monitor, session_id)

llm = ChatOpenAI(callbacks=[callback])
llm.invoke("Explain the CAP theorem.")
print(f"Fidelity: {callback.last_result.fidelity_score:.2f}")

OpenAI Agents SDK

from agents import Agent, Runner
from horizon_monitor import FidelityMonitor

monitor = FidelityMonitor()
session_id = monitor.new_conversation()
agent = Agent(name="assistant", model="gpt-4o-mini", instructions="You are helpful.")

for user_message in conversation:
    result = Runner.run_sync(agent, user_message)
    monitor.process_turn(session_id, human_message=user_message,
        agent_response=result.final_output, timestamp=datetime.now(timezone.utc).isoformat())

4D 時空シグナル

ここでの「時空」は比喩であり、物理学を指すものではありません。 相対性理論の用語（ミンコフスキー間隔、 光円錐、固有時）は、設計上の着想です。どの量を計算するかを決める指針となりました。以下の各シグナルは、 テキスト埋め込みとタイムスタンプに対する、標準的な情報理論上または算術上の尺度に帰着します。各尺度は 平易な定義列に記載されています。Horizon の動作や検証は、この類推が文字どおり正しいかどうかには 依存しません。また、ローレンツ型の interval_class は説明用のメタデータとしてのみ出力され、 これに依存するイベントやスコアはありません。

すべての process_turn() は、5つのシグナルファミリーにわたる32個のフィールドを持つ TurnResult を返します。

コア（常時利用可能）

時間（timestamp が必要）

ペース（timestamp とターン ≥ 2 が必要）

時空（timestamp とターン ≥ 2 が必要）— 説明用メタデータのみ

因果（timestamp が必要）

空間（client_context が必要）

16 種類のイベント（会話プレーン）

すべてのイベントはデフォルトで監視モード（発行されますが、動作はしません）です。ドメインでイベントの適合率／再現率が 0.7 以上になったら、configure() でアクティブモードを有効にしてください。

MCP サーバーのみ、かつ COMPLYEDGE_API_KEY が設定されている場合：alert.compliance（常にアクティブ）— ComplyEdge が EU AI Act の規則に基づき、該当ターンの human_message または agent_response にフラグを立てました。このイベントには規則が記載されるため、次の返信でその内容を前提にしないようにできます。 | signal.grounding_required | 根拠付けの必要性に関するヒューリスティックなスコアがしきい値を超えたとき — エージェントは断定を避けるか、根拠となる証拠を引用する必要があります | | signal.pace_premature_report | 完了シグナルがないまま、以前にフラグが立てられた保留中のアクションが完了しそうな時間よりも早くユーザーが返信したとき |

ミッションプレーン（Memento Mori）

「進捗はターンの特性ではなく、カレンダーの特性です。」

会話プレーンが答えるのは、この対話は劣化しているか？ という問いです。ミッションプレーンが答えるのは別の問い、この目標はまだ前進しているか、そしてどの期限に向かっているか？ です。個々の会話は健全でも、何も進展しないままひと月が過ぎるなら、会話モニターにとってはひと月ずっと完全に健全だったことになります。

この名前に設計思想が表れています。 各ストアには、必ず 1 つだけルート期限があります。これは自分で設定する有限の終了日です。それ以外はすべてこの期限に連動するため、項目に費やされる日々は、目に見えて減っていく予算の一部となります。有限のルートがなければ、作業を先送りしても代償はなく、「あとで」はいつまでも無料です。このプレーンは、その失敗を可視化するために存在します。

デフォルトでは無効です。 ストアが設定されていなければ、7 つのツールは登録されず、統合環境にも何の変更もありません。

検出できる問題

タスクの期限は 7 月 20 日でした。今は 8 月 18 日で、7 月 2 日以降、誰もミッションに手をつけていません。ある決定は「状況が落ち着くまで」と保留され、再検討日として設定した 8 月 10 日はいつの間にか過ぎています。作業は 3 週間にわたって一方の関係者に預けられたままです。こうしたことは、どの会話にも、どのトラッカーのステータス欄にも、モデルのコンテキストウィンドウにも現れません。それについての会話では、どのターンも健全に見えます。

ミッションプレーンは、次のように報告します。ミッションの経過日数は 78 日、進捗から 47 日が経過、タスクの有効期間は終了、保留期間は 8 日超過、現在 operator が 21 日間にわたってブロック中で、さらに継続中です。

用語

すべてはルートの horizon の下にあるツリー内の アイテム です。種類は 8 つあります。

出力には、もう 2 つの用語が登場します。sojourn は、ステージでの記録された滞在（開始 → 終了）を 1 回分指します。また、incumbent は、代替案を試す probe ではなく、現在の働き方を指します。

クイックスタート

export HORIZON_MEMENTO_STORE_PATH=~/.horizon/missions.db   # the default: one local file

pip install "horizon-monitor[mysql]"
export HORIZON_MEMENTO_STORE_DSN='mysql://user:pass@host:3306/horizon'  # wins over _PATH
export HORIZON_MYSQL_SSL_CA=/path/to/server-ca.pem   # or ..._CA_B64 for a PEM in an env var

python scripts/ingest_artifacts.py --store ~/.horizon/missions.db \
    --repo /path/to/repo --item-id <mission-id>

python scripts/ingest_artifacts.py --store ~/.horizon/missions.db \
    --repo /path/to/repo --propose

from datetime import date, datetime, timezone

from horizon_monitor.memento import (
    EventKind, ItemKind, MementoConfig, MementoStore, evaluate,
)

store = MementoStore("missions.db")   # a real file; set this up once

root = store.register_item(
    kind=ItemKind.HORIZON, title="engagement horizon",
    created_valid=datetime(2026, 1, 1, tzinfo=timezone.utc),
    end_date=date(2030, 1, 1),
)
mission = store.register_item(
    kind=ItemKind.MISSION, title="ship-the-thing", parent_id=root,
    stall_days=14,                    # silence longer than this is a stall
    created_valid=datetime(2026, 6, 1, tzinfo=timezone.utc),
)
store.record_event(                   # progress: a side-effect of the work
    item_id=mission, kind=EventKind.PROGRESS,
    valid_time=datetime(2026, 7, 2, tzinfo=timezone.utc),
)

# The evaluation instant is always a parameter — the engine never reads a clock,
# so the same store at the same instant always yields the same report.
report = evaluate(
    store.snapshot(), datetime(2026, 8, 18, 12, tzinfo=timezone.utc), MementoConfig()
)

row = next(r for r in report.items if r.item_id == mission)
print(f"age:             {row.age_days} days")            # 78 days
print(f"since progress:  {row.days_since_progress} days") # 47 days
print(f"recording path:  {row.recording_path}")           # no recent work
print(f"horizon share:   {row.horizon_share:.4f}")        # 0.0595

ストアは実際のデータベースなので、セットアップは一度だけ実行してください。2 つ目のルートを登録すると、設計どおり DuplicateRootError が発生します。これは単一の有限ルートを保証する仕組みが機能しているのであり、バグではありません。期限切れのタスク、期限を過ぎた保留、ブロックしているエンティティ、拒否された書き込み、発火したシグナルを含む全体像については、examples/memento_mori_mission_clock.py を実行してください（引数、ネットワーク接続、API キーは不要です。実行のたびに新しい一時ストアを使用します）。

測定内容

12 種類のシグナル（ミッションプレーン）

会話プレーンの16 種類のイベントとは別個のものであり、その拡張ではありません。各シグナルは、述語が真になったときに状態の変化につき 1 回だけ発生します。条件が続いている間に再び発生することはなく、1 ターンあたり新しいシグナルは最大 1 つなので、悪い週が続いても通知があふれることはありません。ティアはこの上限に優先順位をつけます。P1 は時間的に緊急、P2 は構造的、P3 は情報提供です。

これらは、associate_mission でバインドされたセッションの既存の process_turn 契約に従って通知されます。すべてのイベントには plane: "mission" が含まれ、契約は意図的に明示的です。ミッションシグナルは数値とともにオペレーターに提示されますが、会話シグナルは通知されずに適用されます。ホストに貼り付けるブロックについては、エージェントのルールを参照してください。

行わないこと

推定ではなく、計上のみです。エンジンが期間、日付、金額をでっち上げることはありません。

• 予測、完了時期の予想、「別のパスを選んでいたらかかった費用」という反実仮想は行いません
• NPV／IRR／DCF、割引率、通貨換算は行いません。金額は、測定された時間に掛け合わせる場合にのみ使用します
• パスのレイテンシに関する p 値、信頼区間、逐次検定は行いません。単一オペレーターのサンプル数では、優位性に関する主張は監査に耐えないため、比較は説明にとどめます
• 人に関する分析は行いません。エンティティのレイテンシは機能上のスロット単位で報告します。人の待ち時間は測定しますが、スコア、順位付け、特定可能な識別子にはしません
• 入力が不足している場合、置き換えで補うのではなく、説明フィールドを付けて省略します

すべての行には、算術の由来を明記した derivation 文字列が含まれ、さらに各要約統計には、それが要約した件数 n も含まれます。同一のストアと同一の評価時刻を使用すると、バイト単位で同一のレポートが生成されます。

ドキュメント：製品要件 · 技術仕様 · エージェントのルール · 受け入れテスト計画

設定

# Per-session override
monitor.configure(
    session_id=session_id,
    clarification_threshold=0.25,           # tighter D_JS gate
    event_modes={"alert.drift": "active"},  # activate one event
)

# Compound weight override
monitor.configure(
    fidelity_weights={"alpha": 0.35, "lambda_r": 0.12, "lambda_i": 0.28, "beta": 0.25},
    temporal_weights={"gamma": 0.08, "delta": 0.04},
    spacetime_coefficients={"alpha": 1.0, "beta": 1.0, "gamma": 0.8, "delta_st": 0.5},
)

エクスポート

# JSON
result = monitor.export_to(session_id, target="json")

# LangSmith / Langfuse / OpenTelemetry / Arize
result = monitor.export_to(session_id, target="langsmith",
    connection={"api_key": "ls__..."})

PyPI にはまだ公開されていません。公開までの間は、ソースからインストールする方法についてPath 3を参照してください。

pip install horizon-monitor[langsmith]   # or langfuse, otel, arize

アーキテクチャ

Input: plain strings (human_message, agent_response, optional timestamp, optional client_context)

Core pipeline (< 50ms on CPU):
  1. Embed both turns (local sentence-transformers, lazy-loaded)
  2–6.  IGT · D_JS · TWR · Bipredictability · Epsilon
  7. Temporal signals  — gap, retention, circadian, deictic
  8. Fidelity dynamics — composite score
  9. Health classification
 10. Pace signals       — velocity, acceleration
 11. Spacetime interval — ds² and interval class
 12. Causal reachability — light-cone membership
 13. Spatial signals    — device, location, frame shift
 14. Mode detection     — auto-classify conversation type
 15. Event evaluation   — 16 threshold checks
 16. Optional: SQLite persistence

Output: TurnResult dataclass (32 fields)

設計上の制約（テストで強制）：

• LLM 呼び出しゼロ — 純粋な算術処理とローカル埋め込みのみ
• デフォルトで外部ネットワーク呼び出しゼロ — 完全にローカル
• コアに推移的なフレームワーク依存関係ゼロ
• CPU 上のコアパイプラインが 50ms 未満 — ソフト目標（CI は 50ms 超の回帰にフラグを立て、150ms でハードエラーにします）
• 100 ターンの会話でメモリ使用量 100MB 未満 — 主張値でハードに強制
• すべてのイベントはデフォルトで監視のみ — 明示的に設定されない限り、動作に干渉しません

検証

実証されていることと、そうでないこと。 Horizon のシグナルは、同一ドメイン内の相関的な測定値であり、人間による品質評価とよく一致します。これらは可観測性であり、成果を保証するものとして実証されているわけではありません。各主張の現時点での状況を以下に示します。

以下の 4 つのゲートは、ラベル付きの 5,602 レコードのコーパスで合格しています（同梱されていません。エビデンスパックを参照してください。scripts/build_validation_corpus.py は、ゲートのロジックを検証するための合成コーパスを再生成しますが、以下の数値そのものを再現するものではありません）。

埋め込み間の安定性：3 つの sentence-transformer バックエンド（パラメーター数 22M / 33M / 110M）における ρ_conv のばらつきは 0.026、ρ_turn のばらつきは 0.018 です。Fidelity シグナルは埋め込み多様体ではなく、会話の構造に基づいています。（注：同じコーパスでの埋め込み間の安定性は、コーパス間の OOD とは別のものです。MT-Bench のペアワイズラベルを使った最初のサードパーティ実行では ρ = 0.039 でした。エビデンスパック §Fix 4 を参照してください。）

修正が必要なギャップの出典：DESIGN_FIXES_redteam_remediation.md

エビデンスパック全文：docs/reviews/V0_2_0_EVIDENCE.md

デプロイ

セルフホスト Docker（ポート 3847 で MCP サーバーを実行）

cd deploy/docker
docker compose up

Horizon は SSE 経由で MCP API を提供します。.cursor/mcp.json の接続先を http://localhost:3847/sse に設定してください。Dockerfile はビルド時に all-MiniLM-L6-v2 の重みを事前にキャッシュするため、コールドスタートは発生しません。

ホステッド（DigitalOcean App Platform）

公式のホステッドエンドポイントは https://horizon.leocelis.com で稼働中です。DigitalOcean App Platform 上で動作し（単一インスタンス、プロセス内のセッション状態 — セッションは再起動後に保持されません）、Bearer トークンが必要です。キーごとにレート制限と分離が適用されます。上記のPath 1を参照してください。

開発

git clone https://github.com/leocelis/horizon.git
cd horizon
python -m venv .venv && source .venv/bin/activate
pip install -r requirements-dev.txt

pytest tests/ -v                         # full suite
pytest tests/unit tests/integration tests/e2e -v   # fast path (~6 min)
ruff check src/ tests/
black --check src/ tests/
./scripts/compliance/check.sh              # EU AI Act offline gate

ComplyEdge TrustLint — EU AI Act

Horizon は、LLM に関わるアーティファクトに ComplyEdge TrustLint を統合しています。IVD と同じ、オフライン＋ランタイム＋信頼性のパターンです。

統合ガイド：docs/integrations/COMPLYEDGE.md。公開 CE 埋め込みドキュメント：信頼性バッジ。

リポジトリの構成

horizon/
├── src/horizon/         # package source (PEP 517/518 src/ layout)
│   ├── engines/         # IGT, D_JS, TWR, coherence, fidelity, epsilon, mode
│   ├── spacetime/       # temporal, circadian, deictic, velocity, interval, light cone, spatial
│   ├── events/          # 16-event evaluator
│   ├── integrations/    # OpenAI, Anthropic, LangChain, export targets
│   ├── mcp/             # MCP server + CLI
│   └── storage/         # optional SQLite persistence
├── tests/               # unit / integration / e2e / perf / validation
├── examples/            # runnable framework demos
├── deploy/              # Procfile, build.sh, runtime.txt, docker/
├── docs/
│   ├── product/         # public product overview
│   ├── content/         # published pieces on conversation dynamics monitoring
│   ├── integrations/    # Cursor / Claude Desktop / Copilot setup guides
│   ├── cursor-rules/    # horizon-monitor.mdc (canonical Cursor agent rule)
│   ├── spec/            # HORIZON_TECH_SPEC.md + intent.yaml
│   └── reviews/         # E2E reviews, validation evidence
└── pyproject.toml

背景

Horizon の設計は、一般相対性理論の比喩を用いて人間と AI のコミュニケーションを捉える、思弁的なフレームワークである Trans-Horizon Communication Protocol（THCP）に 着想を得ています。THCP の 5 つの「予想」は、証明済みの法則ではなく設計上の直感です。それぞれが具体的で計算可能なシグナルを示唆したからこそ、有用です。

THCP は設計上の動機付けに限られます。予想とシグナルの対応関係の全容は、docs/product/THCP_FIDELITY_MONITOR_PRD.md を参照してください。

コミュニティ

• アルファ版へのアクセスをリクエスト： ディスカッションを開始 →
• 質問する： GitHub Discussions
• バグを報告する： GitHub Issues
• コントリビューション： CONTRIBUTING.md

ライセンス

MIT — LICENSE を参照してください。

法務

パフォーマンスに関する主張： この README に記載されている品質の +15.7% 向上と幻覚イベントの 87% 減少という数値は、合成データを用いた、スクリプト化された制御下の A/B シナリオと、手動で調整したリファレンスコントローラーによるものであり、本番トラフィックやドメイン内検証コーパス（V1～V5 のゲートでは別のラベル付きデータセットを使用）に基づくものではありません。結果はドメイン、モデル、デプロイ構成によって異なる場合があります。独自のドメイン固有評価を実施せずに、これらの数値を外部向けマーケティングで使用しないでください。適用範囲と証拠の根拠について詳しくは、LEGAL.md §5 をご覧ください。

重大な影響を伴う分野： ドメイン固有の検証と人間による監督なしに、医療、法律、金融、緊急サービスのコンテキストでイベントタイプを active モードにしないでください。LEGAL.md §4 をご覧ください。