事業をAIプロバイダー1社に依存させない

AIワークフローは、モデルのふるまい、プロンプト、ツール呼び出し（Tool Calling）、埋め込み（Embedding）、安全フィルター、出力の料金体系と結びついています。APIが似ていても、モデルを替えれば結果が変わることがあります。評価の仕組みがない会社は、品質が上がったのか下がったのかを判断できません。そのため、テストをやり直すのを恐れて、いまのベンダーに留まりがちです。

分類、抽出、簡単な下書きには、小型で高速なモデルを使います。複雑な分析には推論モデル、画像や音声、特定の分野には専門モデル、データやレイテンシの条件が求めるときはオンプレミスやプライベートのモデルを使います。いちばん高価なモデルをデフォルトにしてはいけません。

リスク、複雑さ、言語、予算に応じてルーティングします。ポリシーなしにエージェントが自分でモデルを選ぶことは認めません。プロバイダーが停止したときやレート制限にかかったときのフォールバックを用意し、どの結果にどのモデルを使ったかを記録します。

業務ワークフロー、プロンプトと指示、モデルゲートウェイ、ナレッジ、ツール、オブザーバビリティを分けます。共通のインターフェースは、必要な機能に限って使います。特別な機能をすべて隠してしまうと、その利点まで失うことがあるため、ベンダー固有の機能はアダプターの中に閉じ込めておきます。

元の文書、メタデータ、評価、業務ルールは、モデルのシステムの外に保管します。書き出しにはオープンな形式を使い、プロンプトとエージェントの設定はバージョン管理します。認証情報はシークレットマネージャーに置き、ワークフローに埋め込みません。

認証、ルーティング、レート制限、ログ記録、機密情報のマスキング（Redaction）、コスト管理を担うモデルゲートウェイを作ります。これでプロバイダーを部分ごとに切り替えられるようになります。ただし、ゲートウェイ自体が新たなロックインにならないよう注意が必要です。設定を書き出せるようにし、社内のAPI標準を決めておきます。

標準的なケース、例外、タイ語、リスクの高いケースを含めて、実際の案件からデータセットを作ります。正確さ、網羅性、出典の示し方、ポリシーの遵守、レイテンシ、コストといった指標を決めます。判断が要る部分は人がレビューし、ルールで確かめられる部分は自動チェックにします。

切り替える前に、候補のモデルをシャドーモードで本番と並べて動かします。結果は平均点1つで判断せず、セグメントごとに分けて見ます。少量のトラフィックでカナリアリリースを行い、ロールバック用のバージョンも残します。変更のたびに、なぜそれを選んだかを意思決定の記録に残します。

安いモデルでも、再試行やレビューが何度も必要になれば、結果的に高くつくことがあります。モデル、ツールとAPI、インフラ、人のレビュー、エラー、停止時間をすべて数えます。そのうえで、成功した成果1件あたりのコスト（Cost/Successful Outcome）と、事業単位あたりのコストを計算します。

ワークフローごとの予算、キャッシュ、バッチ処理、プロンプトとコンテキストの最適化を使います。成果1件あたりのコストがずれ始めたらアラートを出します。わずかな節約のために、重要な業務の品質を下げてはいけません。処理量が10倍になったときのシナリオも試算しておきます。エージェント型のワークフローは、1件の取引でモデルを何度も呼び出すことがあるからです。

認証情報と請求は会社名義で管理し、開発ベンダーがすべてを握るアカウントを経由させません。モデルやオープンソースのライセンスと、商用利用の制限を確認します。重要なワークフローについては、年に1回、撤退の訓練（Exit Drill）を行います。

業務を重要度で区分します。優先度の低い業務は待たせても構いません。顧客向けの業務には、予備のプロバイダーか手作業の経路が必要です。お金に関わる業務はフェイルクローズにし、基準を満たさないモデルの回答は外に出しません。サービスが戻ったときのために、キューと冪等性（Idempotency）を保ちます。

障害のパターンをテストします。タイムアウト、出力の途中切れ、誤ったツール呼び出し、価格の急騰、リージョン単位の障害などです。ダッシュボードでは、プロバイダー側の問題と、データやワークフロー側の問題を分けて表示します。サービスの水準を落として運用している場合は、顧客にそのことを率直に伝えます。