JetStream Securityは2026年2月27日に3,400万ドル（約34億円、1ドル=100円換算）のシード調達を発表し、AIガバナンスを「監査文書」ではなく「実行時制御」に引き上げる設計を提示した。注目点は、AI Blueprints™を静的台帳ではなく動的グラフとして扱い、エージェント、モデル、データ、ツール、アイデンティティを同一面で追跡する点である。本稿は、Shadow AIの可視化と統制を実装するための、企業向けアーキテクチャを技術レベルで整理する。

JetStream調達の本質: 「AI利用」ではなく「AI運用責任」への資本移動

JetStreamの資金調達ニュース（2026年2月27日、同社発表。2026年3月4日、SecurityWeek報道）が示すのは、企業AIの論点が「導入可否」から「誰が、どの権限で、どのコストとリスクを負うか」へ移ったことである。同社はCrowdStrikeやSentinelOne等の出身者を含むチームで、AI Blueprints™を中核に据えた運用統治を打ち出している。

同時に、Smartsheetの2026年1月8日公表データでは、業務運用担当者の70%が社内ポリシー対象外のAI利用を認めている。これは「全企業の70%」を直接示す値ではないが、現場起点でShadow AIが常態化していることを示す重要指標である。したがって、統治は禁止中心ではなく、実行パス全体を観測可能にする設計が前提となる。

AI Blueprints™を動的グラフとして実装する最小構成

JetStreamの公開情報では、Blueprintはエージェント、モデル、データセット、ツール、アイデンティティ（人間・エージェント・NHI）間の関係を実行時に追跡する「運用契約」と定義される。実装では、次の5ノード・6エッジを最小単位にすると運用しやすい。

ノード: Agent, Model, DataAsset, Tool/MCPServer, Identity

主要エッジ: invokes, uses_model, reads/writes, delegates_to, paid_by, approved_by

この構造により、単なるAPIログでは失われる「なぜその呼び出しが成立したか」を復元できる。特にapproved_byを明示すると、変更管理と監査証跡を同じグラフ上で扱えるため、運用品質が安定する。

MCP Server統合とエージェント間通信可視化の設計

MCPは、LLMアプリケーションと外部データ・ツール接続を標準化するプロトコルである。JetStreamのプラットフォーム説明でも、検出対象としてMCPサーバーが明示され、Runtime Governanceは「Blueprintとの差分検知」を前提にしている。したがって、MCP統合は「便利なプラグイン接続」ではなく、統治対象の標準化層として扱うべきである。

実装上は、次の順で進める。

1) Tool/MCPServerごとに許可スキーマ（入力制約、出力分類、保持期間）をBlueprintへ登録する。
2) エージェント間ハンドオフをdelegates_toエッジで逐次記録し、呼び出しチェーンをDAGとして保存する。
3) 各チェーンにIdentityとcost_centerを付与し、セキュリティイベントとFinOpsイベントを同一IDで相関させる。

これにより、エージェント間通信の可視化は「通信の存在確認」から「責任帰属と制御可能性の証明」へ進化する。

Kill Switchを壊さずに効かせる: Key Broker中心の停止設計

JetStream公開情報には、Identity BrokerとKey Brokerにより、コード変更なしで鍵ローテーション・レート制御・アクセス停止（kill access）を実行できる設計思想が示されている。企業実装では、これを3段階の停止機構に分解するのが実務的である。

L1: Session Kill - 実行中セッションのみ停止（短時間障害に有効）
L2: Capability Kill - 危険ツール呼び出し権限だけ剥奪（業務継続性を維持）
L3: Identity Kill - NHI/Agentキーを無効化し全ワークフロー停止（侵害時の最終手段）

ポイントは、Kill Switchをネットワーク遮断ではなく「鍵と権限の可逆制御」として実装することである。これにより、停止後のフォレンジックと段階的復旧が可能になる。

データリネージ追跡を統治に接続する運用設計

Shadow AI対策で失敗しやすいのは、データリネージをDWH監査の範囲に閉じることである。AIガバナンスでは、リネージを「推論時コンテキストの出自追跡」に拡張しなければならない。具体的には、以下の4イベントを必ず記録する。

INGEST（どのデータを取り込んだか）
GROUND（どの根拠文書を参照したか）
ACTION（どのツールを実行したか）
Egress（どこへ結果を送信したか）

この4イベントをBlueprintノードに紐づけることで、「どのモデルが誤ったか」だけでなく「どのデータ系統と権限委譲が事故を生んだか」を再現できる。結果として、EU AI Act対応、内部監査、インシデント対応を別システム化せず、一つの統治基盤で運用できる。

実務上の導入順は、(a) 可視化、(b) 逸脱検知、(c) Kill Switch、(d) コスト統制、(e) 監査自動化である。JetStreamの提案価値は、この順序を製品機能として束ね、導入初期の設計負債を減らす点にある。

FAQ

Q1. Shadow AIの「70%」は企業全体の比率を意味するか？

本稿で参照したSmartsheet（2026年1月8日）は、業務運用担当者調査において70%が社内ポリシー外AI利用を認めたという結果である。したがって、厳密には「全企業の70%」ではなく「調査対象実務者層での比率」と解釈するのが妥当である。

Q2. AI Blueprints™はCMDBや台帳と何が違うのか？

違いは実行時性である。静的台帳は構成を記録するが、Blueprintは実行中のエージェント挙動、権限委譲、コスト、逸脱を同一モデルで扱う。監査用途だけでなく、リアルタイム制御に使える点が本質である。

Q3. MCP Server統合で最初に起きる失敗は何か？

最も多い失敗は、接続可否だけを管理して入力・出力スキーマ制約を管理しないことである。MCPは接続標準であり、統治は別途Blueprint側で定義しなければならない。

Q4. Kill Switchは全面停止しか選べないのか？

全面停止だけではない。鍵・権限を粒度別に管理すれば、セッション停止、機能停止、ID停止を段階的に実行できる。業務継続性と封じ込め速度の両立が可能である。

参考文献