FactVerse AI Agent コアコンセプト
FactVerse AI Agent は、産業データの上に自由なチャットを置いたものではありません。管理されたツールとコンテキストのレイヤーです。有効なワークフローは、テナントコンテキスト、アセットコンテキスト、scope、参照元、承認境界に依存します。
実行モデル
クライアントリクエスト
-> MCP endpoint
-> API key が tenant と scope を解決
-> 利用可能なツール
-> FactVerse Platform、DFS、Designer、Inspector、知識、またはシミュレーションサービス
-> 参照元コンテキストとガバナンス境界を持つレスポンス
クライアントは実行時に利用可能なツールを発見する必要があります。生成されたリファレンスはこのビルドの公開カタログを示しますが、実際に key が呼び出せるツールはデプロイ設定と顧客 scope によって決まります。
テナントとアセットコンテキスト
API key がテナントを解決します。クライアントは、認可の代わりとしてテナント識別子を送信しないでください。テナントが解決された後、各ワークフローは関連するアセット、サイト、施設、ライン、部屋、設備、またはシーンコンテキストを付与します。
良い Agent 出力には通常、次が含まれます。
- 対象のアセットまたはシーン；
- 使用した参照元システム；
- データの時刻または鮮度；
- 欠落している証拠または品質注記；
- 出力がドラフト、分析、推奨、承認済みアクションのどれか。
Endpoint、slice、scope
FactVerse は管理された slice を通じてツールを公開します。各 slice には独立した endpoint があります。Scope は呼び出せるツールを決めます。
| Slice | Endpoint | Scope 例 | 説明 |
|---|---|---|---|
| Base | /mcp/base/ | base.read, base.compute.run, base.action.write | 一般的なアセット read、知識、データ品質、シミュレーション、最適化、管理された write action。 |
| 予知保全 | /mcp/pdm/ | pdm.read | 設備健康度、サマリー、異常、コンポーネントインテリジェンス。 |
| 交通運用 | /mcp/trafficops/ | trafficops.read | 人流、車両、チェックポイント、交通運用ツール。 |
| 通信運用 | /mcp/telcoops/ | telcoops.read | ネットワーク健康状態と容量ツール。 |
| 半導体運用 | /mcp/semiops/ | semiops.read | クリーンルーム、ファブ、utility、SMT、環境ツール。 |
| 航空 | /mcp/aviation/ | aviation.analysis.read | 航空信頼性分析ツール。 |
廃止済みの physical endpoint は新しい作業に使用しません。Physical AI ワークフローでは現在の endpoint と Designer、SimReady asset、シミュレーションツールチェーンを使用します。
ツール呼び出しと参照元
ツール呼び出しは、データベースへの直接アクセスではなく、製品能力への管理されたアクセスとして扱います。ワークフローは、人間のレビュー担当者が Agent の出力理由を理解できるだけの参照元コンテキストを保持する必要があります。
例：
- 施設運用では、アセット、メーター、点検記録、ワークオーダーを引用する。
- 予知保全では、シグナル履歴、データ品質、アセット履歴、保全証拠を引用する。
- Physical AI では、シーンバージョン、アセットバージョン、シミュレーション仮定、検証メモを引用する。
データ準備状況
Agent の品質は参照元データの準備状況に制限されます。ワークフローを約束する前に、次を確認します。
| 領域 | 確認事項 |
|---|---|
| Platform アセット | アセット、場所、所有者、権限がモデル化されているか。 |
| DFS データ | 参照元システムが接続、変換、品質チェックされているか。 |
| Inspector 記録 | 点検、アラート、ワークオーダー、オペレーター注記が利用できるか。 |
| Designer シーン | シーン、アセット、関係がバージョン管理され、利用できるか。 |
| 文書 | マニュアル、SOP、手順が該当テナントと scope でアクセスできるか。 |
データが欠落している場合、Agent は根拠のない仮定で補わず、ギャップを報告する必要があります。
Read、compute、write の境界
調査には read scope を使用します。シミュレーション、最適化、予測、比較には compute scope を使用します。Write scope は、デプロイポリシーが管理されたアクションを許可する場合のみ使用します。
Write action には追加の制御が必要です。
- 分析ステップの中に隠さず、明示的に扱う；
- 顧客が自動化を承認していない限り、まずドラフトを作成する；
- Inspector または接続された運用システムに記録する；
- 責任あるオペレーターまたは管理者が承認できるだけの証拠を含める。
デジタルツインとシミュレーションコンテキスト
Agent ワークフローにおけるデジタルツインは、単なる視覚参照ではありません。空間コンテキスト、アセット関係、挙動の仮定、運用上の意味を持ちます。
Physical AI とシミュレーション指向ワークフローでは、次をバージョン管理します。
- Designer シーン；
- SimReady asset；
- 運用制約；
- シミュレーション設定；
- 検証結果；
- 現場フィードバック。
これにより高速なシミュレーションの価値を保ちつつ、確実性を過大に表現しないようにできます。実サイト変更には引き続きエンジニアリングレビューと顧客承認が必要です。
ガバナンスパターン
完全なワークフローは次のパターンに従います。
- テナント、アセット、endpoint、scope を解決する。
- 許可されたデータ、文書、シーン、ツールを取得する。
- 参照元と仮定を含む分析を生成する。
- Write action は承認と監査の下に置く。
- 完了した作業と現場フィードバックを記録する。
- フィードバックを後続分析の改善に使う。
今後ワークフローガイド、接続ガイド、トラブルシューティングページを書く際は、このパターンを基準にします。