「業務」から組み立てる。「AI」からではなく。

プラットフォームの五つのコンポーネントは、どんな扱い方でも同じです。各コンポーネントの内側の判断が、アーキテクトがビジネスアプリケーションを内側から知っている場合、違って見えます。

1. ビジネスアプリケーションのデータモデルを尊重するサービス契約。すべてのAI能力が安定したバージョン管理されたAPIで公開されます。契約は、AIチームのデータモデルを消費者側に押し付けない。消費アプリケーション側のデータ形を話します。現代の契約は、structured outputs、function calling、tool-useをネイティブにサポートします ── プロトコルの責任はプラットフォーム側にあり、各アプリケーション側ではありません。ここで重要なアーキテクチャ判断は、契約が「何を隠し、何を公開するか」です。業務起点で構築されたプラットフォームは、モデルベンダー固有の詳細を隠し、業務的セマンティクスを公開します。

2. ビジネスアプリケーションのリリースサイクルと整合する中央集約のモデル管理。モデル、プロンプト、ナレッジベース、評価ルーブリックは中央で管理されます ── プラットフォーム方針に従ってバージョン管理、評価、廃止されます。これには評価パイプライン、ハルシネーション制御、AIリグレッションテストが含まれます ── アプリケーションごとではなく、プラットフォーム全体で運用されます。業務起点のひねりが入ります ── プラットフォームのリリースケイデンスが、それが奉仕するビジネスアプリケーションのリリースケイデンスと整合するように設計されている、ということです。四半期ごとにリリースするCRMアプリケーションは、月次で壊れるAIサービスを消費できません。ビジネスアプリケーションの運用テンポが、プラットフォームの運用テンポを形作ります。

3. 設計段階からのガバナンス ── 業務プロセス監査に立脚し、汎用コンプライアンスに立脚せず。認証、認可、データ所在地、監査ログ、レート制限、個人情報の取り扱い ── これらはプラットフォームの関心事であり、アプリケーションの関心事ではありません。日本のエンタープライズにおいては、これは経済産業省の「AI事業者ガイドライン」とプラットフォームを整合させることを意味します ── ポリシー文書としてではなく、設計時からのガバナンスとして。グローバルに事業展開するOEMにおいては、プラットフォームのガバナンス姿勢はEU AI法がAIシステムの欧州市場での販売・利用に及ぼす影響も予期しておく必要があります。これらのガバナンス特性をプラットフォーム側に一度組み込むコストは、AI導入ごとに別々に組み込むコストよりも、明確に低くなります。業務起点のプラットフォームは、ガバナンスを、ビジネスアプリケーションが監査証跡を扱うのと同じ仕方で扱います ── 一次データクラスとして、後付けではなく。

4. 推論コストだけでなく業務成果も追跡する可観測性。どのAI呼び出しが、誰によって、どの入力で、いくらのコストで、どの結果を返しているか ── プラットフォーム全体で、リアルタイムで。これがなければ、企業のAIコストとAIリスクは、両方とも可視化されません。業務起点の追加要素 ── 可観測性は、AI呼び出しごとに業務成果も追跡します。意思決定の遅延短縮、上書き頻度、ワークフロー完了 ── これらは後付けではなく、第一級の可観測性ディメンションです。

5. 実際の消費パターンに立脚した組み合わせ可能性。AI能力は組み合わせ可能です ── RAGサービス、ML予測サービス、エージェント・オーケストレーション・サービス ── 個々の組み合わせがカスタム統合になることなく。複利効果はこの性質に宿ります。業務起点で構築されたプラットフォームは、ワークフローを知っているからこそ、どの組み合わせが最も重要かを「知っています」。ビジネスアプリケーションの内側から構築されていないプラットフォームは、正しい組み合わせを実験的に発見しなければなりません。内側から構築されたプラットフォームは、設計時点でそれを知っています。