よくある質問

Speculum AI は The AI Runtime Company です。モデル、プラットフォーム、導入環境を問わず、本番環境の AI のための独立したランタイムレイヤーを構築しています。製品ファミリーは、AI Runtime Stability を担う Mirror OS と、AI Runtime Efficiency を担う Mirror Token の2つです。私たちが注目するのは、AI が稼働し始めた後に起きること。AI がどう振る舞い、どう制御され、どのような証跡を残し、どこで回避可能な実行を減らせるのかです。

AI ランタイムとは、AI ワークロードが実際に入力を処理し、ツールを使い、システムとやり取りし、アクションを実行している運用フェーズのことです。意図された振る舞いが現実の運用条件と出会う場であり、組織にとって可視性、制御、証跡が必要になる場でもあります。

モデル、ポリシー、評価、導入前のテストだけでは、実環境で何が起きるかを完全には規定できません。ランタイムレイヤーは、承認された境界を運用上の制御に変えます。AI の稼働中に振る舞いを観測し、問題となる逸脱を特定し、承認された対応を適用し、証跡を保全します。

Speculum AI は、AI エージェント、オーケストレーション、エンタープライズ AI、AI ファクトリー、ロボティクス、フィジカル AI、自律システムなど、実際の業務フローで AI を運用する組織のために設計されています。適合性と導入範囲は、カテゴリー名から推定するのではなく、実際のワークロード、環境、運用境界に照らして評価します。

Mirror OS は、AI Runtime Stability のための Speculum AI の製品ファミリーです。合意した運用境界を起点に、Observe → Detect → Govern → Enforce → Evidence という、承認に基づく段階的な進行を支えます。導入は観測と証跡から始めることができ、より強い制御は承認された場合にのみ導入されます。

Mirror Token は、AI Runtime Efficiency のための Speculum AI の製品ファミリーです。必要な結果と運用上の制約を保ちながら、ランタイムにおける回避可能な実行を特定し、削減するよう設計されています。単なるトークン価格のツールやモデルルーターではなく、Mirror OS の一機能でもありません。

Mirror OS は AI の振る舞いを統制し、Mirror Token は AI によるランタイム資源の消費を統制します。両者は同じランタイム基盤の上に構築された別々の製品ファミリーで、異なる運用上の課題に対応します。ワークロードに応じて、どちらか一方、または両方を利用できます。

Mirror OS の3つの導入ラインです。

• Mirror Shield は、既存の AI ワークロードにランタイム制御を加えるための、エンタープライズグレードの導入カテゴリーです。
• Mirror Runtime は、プラットフォーム、オーケストレーション層、エッジ環境への、より深い統合を提供します。
• Mirror Foundry は、Mirror OS のランタイム基盤を、ドメイン固有の運用要件と証跡要件に合わせて構成します。

どのラインが適切かは、ワークロード、運用境界、そして必要な統合の深さによって決まります。

Mirror Shield Agent Edition は、対応する AI エージェントおよび AI エージェント・オーケストレーション環境のための、Mirror Shield 内の専用の導入パスです。RSE や FDE を必要とせずに決定論的なランタイム判断を行う、スタンドアロンなローカル意思決定プレーンを提供します。独立した製品ファミリーではなく、Mirror Shield の一部です。現時点での対応範囲と導入範囲は、案件ごとに確認します。

AI Runtime Stability とは、本番環境の AI を合意した境界に照らして運用できる状態を指します。振る舞いは観測可能で、制御の判断は承認されており、ランタイムで起きた事象は証跡によって裏付けられています。AI が決して失敗しないという意味ではありません。不確実性や逸脱を、黙って許容するのではなく、特定し、対処できるという意味です。

レッドチーミングは、システムがどのように失敗しうるかを検証します。ガードレールは、定義されたやり取りを制約します。ガバナンスは、ポリシー、責任、説明責任を定めます。Mirror OS は AI の稼働中に機能することで、この3つすべてを補完します。稼働中のワークロードを観測し、合意した境界からの逸脱を特定し、承認された制御を適用し、証跡を保全します。評価、サイバーセキュリティ、ガバナンス、人による監督に取って代わるものではありません。

オブザーバビリティは、システムが何をしているかを説明し、何が起きたかを診断するのに役立ちます。Mirror OS は、承認されたオブザーバビリティデータをランタイムシグナルとして利用できます。そのうえで、関連する振る舞いを運用境界に照らして評価し、ランタイムの判断を支え、証跡を保全し、承認されている場合には制御を適用します。オブザーバビリティを置き換えるのではなく、補完するものです。

いいえ。Mirror OS は、組織がすでに運用している AI 環境と組み合わせて機能するよう設計されています。既存のモデル、クラウド、プラットフォーム、エージェントフレームワーク、オーケストレーション、インフラを補完します。統合の深さはワークロードに応じて選択するため、AI 環境を作り直す必要はありません。

導入は、ワークロードの意図された機能、許可されたアクション、終了条件、ポリシー、関連する運用上の制約を整理することから始まります。より深い統合では、任意の FDE 評価によって環境と必要な証跡シグナルを洗い出し、ランタイムの境界と構成をお客様の確認用に提案できます。導入は観測と証跡から始めることができ、制御は承認された段階を経てはじめて導入されます。Mirror Shield Agent Edition は、対応する AI エージェントおよび AI エージェント・オーケストレーション環境に、RSE や FDE を必要としないスタンドアロンなローカル意思決定プレーンを提供します。

Mirror OS は、パブリッククラウド、プライベートクラウド、セルフホスト、ソブリン、オンプレミス、エッジの各環境を想定して設計されています。実際の互換性、対応範囲、統合は、個々のワークロードと導入環境に照らして確認するものであり、あらゆる環境で一律に成り立つものとして示すべきではありません。

はい。対象を絞ったワークロードは、運用境界を定め、必要なシグナルを特定し、適切な導入パスを決めるうえで、最もわかりやすい出発点です。同じ組織の中でも、ワークロードごとに異なる Mirror OS の導入形態を使うことができます。

Mirror OS は、導入の対象範囲にあるランタイム事象と、承認された制御判断について、構造化された証跡を保全するよう設計されています。合意した構成に応じて、運用レビュー、調査、ガバナンスに役立てることができます。実際に得られる証跡は、承認されたシグナル、保持ルール、データの境界によって異なります。ランタイムの証跡だけで、規制への準拠が包括的に保証されるわけではありません。

顧客情報、機密データ、テレメトリ、そしてデータを外部に出す範囲は、導入ごとに定義します。Speculum AI は、顧客データへの無制限のアクセスを前提としません。必要なシグナル、その処理場所、証跡の保持方法は、統合の前に明示的に合意する必要があります。

Mirror Token の効率は、必要な成果と運用上の制約を保ったまま、ワークロードごとに合意したベースラインに照らして評価します。トークン、計算資源、エネルギー、キャパシティ、金銭的価値は、それぞれ別に測定する必要があります。ひとつが減っても、ほかが同じだけ減るとは限りません。削減の余地はワークロードによって異なるため、Speculum AI は一律の削減率を公表していません。