企業の AI アプリ基盤をまず自社管理ランタイムにすべき理由

企業が AI を導入するとき、モデルの性能に注目しがちです。コンテキスト長、推論品質、速度、生成能力。

しかし AI がチャットを超えて、顧客、注文、契約、チケット、承認、社内ファイルを読み始めると、より重要な問いが出てきます。

データはどこで動くのか。誰がアクセスできるのか。ログはどこに残るのか。鍵は誰が管理するのか。問題が起きたら誰が止められるのか。

これが、自社管理の AI アプリケーション基盤が重要になる理由です。

最初に自社管理すべきものは、必ずしもモデルではありません。AI アプリケーションのランタイムです。

モデルは外部でもローカルでも構いません。しかし業務オブジェクト、権限、フロー、Agent ツール、監査証跡を持つランタイムは、企業が管理するインフラで動くべきです。モデルは推論します。ランタイムは、何を読めるか、何を実行できるか、何に承認が必要か、どの証跡を残すかを決めます。

自社管理はインストールだけではない

自社管理を単なるインストーラーやプライベートデプロイと考えるのは不十分です。

重要なのは責任境界です。

• 業務レコードは自社データベースに残る。
• ファイルは自社ストレージに残る。
• ID と権限は自社 SSO、組織、ロールから来る。
• 監査ログは自社のログ・コンプライアンス基盤へ流れる。
• 鍵、ネットワーク、バックアップ、アクセス方針を自社で管理する。
• 外部モデル接続は明示的に設定し承認する。

すべての業務コンテキストをベンダークラウドへ送る必要があるなら、IT チームはデータ所在地、監査、契約、退出コストを説明しにくくなります。

自社管理の価値は、クラウドや外部モデルを拒否することではなく、最後の制御権を保つことです。

ランタイム、ローカルモデル、プライベート SaaS は別物

よく混同されるものが三つあります。

自社管理ランタイム: オブジェクト、権限、ワークフロー、Agent ツール、承認、監査が企業管理インフラで動く。

ローカルモデル: モデルや推論サービスが企業内部で動く。隔離、コスト、遅延、規制対応のために使われる。

プライベート SaaS: 専用環境はあるが、運用、ログ、アップグレード、データ処理はベンダー主導。

最初に確認すべきはランタイム境界です。業務データは自社のオブジェクト層に入るのか。Agent は自社の権限を継承するのか。監査証跡は自社ログへ残るのか。

ランタイムが外部管理なら、ローカルモデルを使っても業務権限を迂回する可能性があります。ランタイムが自社管理なら、外部モデル API を使う場合でも、承認済みの最小コンテキストだけを送れます。

AI アプリは通常の SaaS より強い境界が必要

通常の SaaS は一つのアプリのデータを扱います。AI アプリ基盤は複数システムを接続します。

• CRM の顧客と商談;
• ERP の注文と在庫;
• チケットシステムのサービス履歴;
• 契約金額、条項、承認;
• 添付、レポート、社内文書;
• ID システムのユーザー、ロール、組織。

Agent がこれらを横断して読み、操作できるなら、その基盤は業務実行層になります。

その層が完全に外部で動くと、どのデータがどこへ送られたか、既存権限をどう継承するか、Agent 行動を社内監査へどう残すかが難しくなります。

本当に評価すべきことは、AI が業務システムへ接続できるかではなく、接続後も運用境界が企業の管理下にあるかです。

自社管理ランタイムが持つべきもの

能力	ランタイム内に置く理由
業務オブジェクト層	顧客、注文、チケット、契約、設備を管理されたオブジェクトとして表現する。
権限層	ID、ロール、レコード権限、フィールド権限を継承し、Agent をユーザー境界内で動かす。
ツール層	クエリ、アクション、ワークフローを制御されたツールとして公開する。
承認層	危険な操作をモデルの直接書き込みではなく、人の承認へ回す。
監査層	Agent が読んだ、提案した、呼んだ、承認した、変更した内容を記録する。
接続層	DB、ERP、CRM、ID、ファイルに接続しつつ、ネットワークと鍵を管理する。

これらがランタイム内にあることで、AI はガバナンスを迂回せずに実業務へ近づけます。

外部モデルサービスも使える

自社管理はローカルモデルだけを意味しません。

外部モデル API、プライベートクラウドモデル、ローカルモデル、用途別モデルの組み合わせが可能です。

重要なのは、モデルが直接データベースへ接続しないこと、業務システムの資格情報を持たないことです。ObjectOS のようなランタイムから、承認済みの最小コンテキストだけを受け取るべきです。

たとえば「この顧客の過去 90 日の未解決チケットを要約し、次の対応を提案して」とユーザーが尋ねた場合、ランタイムはまずアクセス権を確認し、フィールド権限で機密項目を隠し、必要最小限のコンテキストだけをモデルへ渡します。実行は再び権限、承認、監査を通ります。

自社管理には運用責任もある

自社管理は無償ではありません。企業はデプロイ、アップグレード、ネットワーク分離、バックアップ、ID 連携、鍵管理、可用性、セキュリティ基準、脆弱性対応、内部監査を担います。

だから自社管理基盤は明確である必要があります。複雑さを単に顧客へ渡すのではなく、オブジェクト、権限、フロー、ログ、接続の境界を明示すべきです。

自社管理が買うのは便利さではなく、制御です。

自社管理が必要になる場面

データが特定地域、VPC、ローカルネットワークを出られない場合、契約上第三者ホスティングや学習利用が制限される場合、内部 ERP や DB と接続する場合、完全な監査チェーンが必要な場合、社内 ID と権限を再利用する場合、ローカルモデルや隔離ネットワークが必要な場合、AI が実業務操作を起こす場合、自社管理は重要になります。

AI が実業務へ近づくほど、デプロイ境界は明確でなければなりません。

ベンダーに聞くべき質問

1. 業務データはデフォルトでどこに保存されるか。
2. Agent は企業 ID と権限を継承するか。
3. オブジェクト、レコード、フィールド、アクション権限を扱えるか。
4. モデルは DB に直接アクセスするか、制御されたツールだけか。
5. 外部モデル API へ送るコンテキストを最小化できるか。
6. 危険な操作に承認、ロールバック、自動停止があるか。
7. Agent の読み取り、提案、ツール呼び出し、書き込みを社内監査へ送れるか。
8. 隔離ネットワークやベンダー障害時にも中核業務アプリは動くか。

答えが曖昧なら、その基盤は本番の企業層ではなく AI デモ層かもしれません。

ObjectOS の設計方針

ObjectOS は、企業データを新しいクラウドへ移して AI を動かすことから始めません。

企業インフラ内で動く業務実行層として、既存システムを接続し、オブジェクトとしてモデル化し、権限、ワークフロー、API、監査、Agent ツールを統一します。

データ、ID、ファイル、監査証跡は企業の管理下に残ります。AI は制御されたツールで問い合わせ、操作できますが、ランタイム境界を迂回できません。