プライベートAIは、3つの技術的課題を解決する。規制対象ワークロードのデータ主権の確保、従量課金制APIへの依存低減による推論コストの予測可能性、そして広域通信網（WAN）を経由しないことによる遅延の確定性だ。これらはインフラ面で重要な改善だが、業務ワークフローの複雑さを解消するものではない。

　オンプレミスのGPUクラスタで動くLLMは、クラウド上にあるときとなんら変わらない。業務の実行基盤と連携しなければ機能しない推論エンジンにとどまる。

　AIエージェントとして有用な処理を実行するには、モデルが以下の要件を満たす必要がある。

• 構造化データおよび非構造化データのコンテキストを取り込む
• 社内の複数のシステム間で認証を通す
• 暗黙の要求を明確な業務ルールに対応付ける
• 適切な外部ツールを呼び出す
• 複雑なRBAC（ロールベースアクセス制御）やABAC（属性ベースアクセス制御）の境界を順守する
• 対話の状態を管理する
• 企業内の多数の業務アプリケーションを横断するマルチホップワークフローを実行する

　エージェント型ワークフローが失敗する場合、プロンプトを理解する知能がモデルに不足していることはまれだ。大半はERPやCRMで処理を実行しようとした際に認証エラーが発生したり、未対応のAPIスキーマ変更に直面したり、コンテキストウインドーが時間切れになったりして失敗する。

オーケストレーション層の設計

　AI戦略がインフラの配置場所だけで始まって終わるなら、それはシステムの孤立状態を保護しているにすぎない。プライベートAIで成果を上げるには、関心をインフラ層からガバナンスの効いたオーケストレーション層へと移す必要がある。

　このオーケストレーション層は推論モデルと業務アプリケーション群の間に位置し、3つの技術的課題を解決しなければならない。

1．状態管理とマルチホップ実行

　LLMは本質的にステートレス（状態を保持しない）だ。一方、企業のワークフローは状態に強く依存する。AIエージェントが財務や人事、調達システムをまたいで請求書を照合する場合、自然言語のプロンプトだけで処理を完結させることはできない。全体目標を独立したサブタスクに分解し、実行状態を追跡し、APIエラー発生時に例外を処理し、安全にトランザクションをロールバックできる決定論的なオーケストレーション基盤が必要になる。

　例えば「更新期限が30日以内で、未解決のサポート案件があり、未払いが60日を超えている顧客を抽出し、営業担当者へ通知してCRMにタスクを作成し、年間経常収益（ARR）が10万ドルを超える取引先については財務部門へアラートを発行する」という要求を考える。

　要求を理解することは難しくないが、実行は容易ではない。エージェントはCRM、ERP、ITSM、電子メールの各システムで認証を通し、アクセス権限を適用し、顧客のIDを照合し、監査可能なワークフローを完了させる必要がある。LLMがMicrosoft Azure上で動いているか、オンプレミス環境か、NVIDIA製GPUのラック上にあるかでこの難しさは変わらない。複雑さの原因はモデル内部ではなくシステム間に存在するからだ。

2．動的な認可

　従来のID管理やアクセス管理（IAM）は、人間や有効期限の長いAPIキーを利用する静的なサービスアカウントを前提に設計されていた。AIエージェントが複数のSaaSツールをまたぎ、自律的かつ動的に実行経路を決定する環境で、広範で恒久的な静的認証情報をエージェントに渡すことは設計上の大きな破綻につながる。

　オーケストレーション層はエージェントでジャストインタイム（都度）の認可を強制しなければならない。個別のサブタスクが完了した瞬間に失効する、スコープを限定した短命の暗号化トークンを発行し、次のタスクへ進む前に確実に失効させる仕組みが必要だ。

　例えば、AIエージェントがERPから未払い請求書を取得して顧客に通知するケースを考える。エージェントに永続的なERPアクセス権を与えるのではなく、オーケストレーション層はその請求書照会だけに有効な読み取り専用トークンを発行する。このトークンは処理完了直後に失効するため、エージェントや外部の攻撃者がその認証情報を悪用し、給与データや取引先への支払い情報といった他の機密財務データへアクセスすることを防げる。

3．ロジックと実行の分離

　エージェントによる誤ったデータベース削除や、コンテキスト汚染による意図しないワークフローの起動といった非決定論的な挙動を防ぐには、推論と実行を分離しなければならない。プライベートLLMの役割は、実行すべきアクションの提案とペイロードの整形にとどめるべきだ。本番環境になんらかの変更が加わる前に、AIとは独立した厳格なゲートウェイが有効なポリシーに照らしてそのアクションを検証しなければならない。

CIOが押さえるべき本質

　インフラは基盤にすぎず、最終目的ではない。GPUの追加購入を承認する前に、CIOは自問する必要がある。「社内のAIは、各種業務システムをまたいで確実に処理を実行できる状態にあるか。それとも、孤立した推論処理を高速化しているだけなのか」と。