モデルよりアーキテクチャ重視、実践 AI の考え方

Rackspace の Chief AI Officer（CAIO）である Chetan Gupta 氏は、企業における AI 戦略の転換点として、「どのモデルを使うか」から「どのようにシステムを設計するか」というアーキテクチャ重視へのシフトを指摘します。特定のモデルに固執するのではなく、状況に応じてモデルを交換可能な柔軟なシステムを構築し、データ主権やガバナンスを確保することが重要だと Gupta 氏は主張しています。

AI の能力は「ジャギッド（不均一）」：タスクに応じた適切な選択が必要

Gupta 氏が強調するもう一つの重要な点は、AI の能力がタスクによって偏りがあるという事実です。彼はこれを「ジャギッド（不均一）」な性質として表現しています。

「コード生成は得意でも、メール作成が苦手など、タスクによって AI の性能に偏りがあり、用途に応じた適切なモデル選択が必要である」

具体的には、AI はソフトウェアのコーディングにおいては非常に高い能力を発揮しますが、ビジネス文書やメールの作成においては、人間の方がより自然で効果的な文章を書ける場合があるといいます。また、AI が生成するメールが冗長であったり陳腐であったりするケースも報告されています。

この「ジャギッド」な性質を踏まえ、企業は以下の 3 つの問いを立てる必要があります。

1. このタスクには AI を使うべきか？
2. 使う場合、コスト効率の良いローカルモデルで十分か、それとも大規模モデルが必要か？
3. 知的財産（IP）を保護するために、どのようなガバナンス層を設けるべきか？

単に「AI でできること」を探すのではなく、「どのタスクに AI が最も適しているか」を見極め、アーキテクチャの中で適切なモデルを配置する必要があります。

データ主権とガバナンス：外部依存のリスクとオンプレミスの重要性

企業が AI を業務に組み込む際、最大の懸念事項の一つがデータ主権です。Gupta 氏は、外部の大規模言語モデル（LLM）へデータを送信することは、企業の知的財産を失うことと同義であると警鐘を鳴らしています。

「外部 LLM へのデータ送信による知的財産の流出リスクを避け、オンプレミスやローカルモデルを用いたガバナンス層の確立が不可欠である」

企業が AI を運用する際、以下のリスク管理が必要です。

• データの機密性: HR 問い合わせのような機微なデータを外部サービスに送信しないよう、内部環境（オンプレミス）やローカルモデルで処理する仕組みが必要です。
• ガバナンスと保証: 自社で開発・デプロイしたモデルが規制に従って安全に動作しているか、あるいは外部の AI を利用する際にも、企業独自のガードレール内で適切に振る舞うかを担保する必要があります。
• トークンエコノミクス: コスト効率を最大化しつつ、価値あるデータを保持するための設計が必要です。

Gupta 氏は、特定のモデルファミリー（例：Anthropic や OpenAI など）に「結婚」して依存するのではなく、アーキテクチャの考え方自体にコミットすべきだと説きます。地政学的な要因や商業的な理由でモデルが入れ替わる可能性を常に想定し、柔軟なシステム設計が求められます。

自社評価層（Evals）の構築：ベンチマークではなく実ワークロードに基づく検証

AI モデルの評価において、一般的なベンチマークスコアに頼ることは危険であると Gupta 氏は指摘します。ベンチマークはあくまでガイドラインであり、企業の具体的な業務ワークロードにおける性能を保証するものではありません。

「一般的なベンチマークではなく、自社の具体的なワークロードに基づく評価データを保有し、それに基づいてモデルを比較・選定する必要がある」

Gupta 氏は、従来の産業用 AI の開発において「ゴールデンデータセット（顧客が検証に使用する標準的なデータ）」を用いていたことを思い出させます。現代の生成 AI においても同様に、自社独自の評価層（Evals）を構築することが不可欠です。

この評価層をアーキテクチャの一部として組み込むことで、以下のメリットが得られます。

• 一貫した顧客体験: ベンチマーク結果ではなく、実際の業務成果に基づいてモデルを選定・交換できるため、サービス品質の安定性が保たれます。
• コストと性能の最適化: 評価結果に基づき、より安価で軽量なモデルや、安全性が高いモデルへスムーズに切り替える判断が可能になります。

Rackspace の実践：「ミラー組織」による内部実装から外部提供へ

最後に、Gupta 氏は Rackspace が取り組んでいる独自の戦略として、「ミラー組織（Mirror Org）」の構築を明かしました。これは、社内で AI ソリューションを実証し、その成功を裏付けとして外部顧客へ提供するアプローチです。

「自社の内部実装を外部顧客へ提供する『ミラー組織』の構築や、ベンチマークではなく自社ワークロードに基づく評価層（Evals）の重要性についても言及している」

この戦略には以下のような意図があります。

1. 実証による信頼: 社内の実際の業務で成功したソリューションこそが、顧客に対して最も説得力のある提案となります。
2. disciplined な開発: プロジェクトを単なる実験や「捨てプロジェクト」とせず、最終的に外部提供可能な製品として完成させることを前提に設計します。
3. 包括的な設計: アーキテクチャ、ガバナンス、オーケストレーションの 3 つの層を統合し、主権（ソブリン）、安全性、信頼性を兼ね備えた AI 環境を提供することを目指しています。

Gupta 氏は、企業が AI に取り組む際、単なるプロンプトエンジニアリングやモデル選定に終始するのではなく、データ主権を確保し、ガバナンスと評価層を組み込んだシステムアーキテクチャ設計へリソースをシフトさせるべきだと結論付けています。これにより、AI の実装リスクを低減しつつ、持続可能なビジネス価値を創出する基盤が整います。