オンプレミスでLLMを動かすことは、最初の一歩に過ぎません。
AIによるスプレッドシート分析を目的とする場合、モデルのエンドポイントだけでは不十分です。ビジネスユーザーは、内部の推論サーバーに生のJSONを送信したいわけではありません。彼らが求めているのは、ワークブックをアップロードし、質問を投げ、信頼できる回答を得て、チャートを作成し、そしてその数値がどこから来たのかを確認できる環境です。
そのためには、モデルを中心とした堅牢なアーキテクチャが必要になります。
このガイドでは、オンプレミスAIスプレッドシートシステムの主要なコンポーネントについて解説します。
リファレンス・アーキテクチャ
実践的なオンプレミスAIスプレッドシートのアーキテクチャは、以下のようになります。
構成の順序は多少前後する場合がありますが、原則は一貫しています。LLMは「推論と説明」を担当し、制御されたシステムが「データアクセス、計算、セキュリティ、監査可能性」を処理すべきであるという点です。
アイデンティティとアクセス制御
まずはアイデンティティ（本人確認）から始まります。
AIによるすべての回答は、ユーザー、ワークスペース、ファイル、および権限設定に紐付けられていなければなりません。
エンタープライズ環境での導入には、通常以下が必要となります。
- SAMLまたはOIDCによるSSO（シングルサインオン）
- ロールベースのアクセス制御（RBAC）
- IDプロバイダーからのグループマッピング
- ワークスペース単位の権限管理
- ファイル単位の権限管理
- データセットの許可リスト（アローリスト）
- 管理者用コントロール
システムがデータベースやオブジェクトストレージに接続する場合、既存の権限設定をバイパスしてはなりません。AIがガバナンスを回避するための「近道」になってはいけないのです。
ワークブックの取り込み（インジェスチョン）
スプレッドシートの取り込みは、見た目以上に複雑です。
実際のワークブックには以下のような要素が含まれます。
- 複数のシート
- 非表示のシート
- 数式
- 結合されたセル
- 不統一なヘッダー
- 名前付き範囲
- コメント
- 意味を持つ書式設定
- 保護されたシート
- チャートとピボットテーブル
- 外部リンク
- マクロ
プロダクションシステムは、モデルがデータを誤認しないよう、これらの構造を十分に解析する必要があります。
セキュリティの観点から、マクロ有効ファイルは慎重に扱うべきです。システムが何らかのコードを実行する場合は、必ずサンドボックス内で行う必要があります。多くの導入事例では、マクロは実行するのではなく、スキャンしてブロックするか、メタデータとして扱うのが一般的です。
スプレッドシートの理解
取り込み後、システムはワークブックの有用な表現（メタデータ構造）を構築する必要があります。
これには以下の内容が含まれます。
- シートの概要
- テーブルの境界
- 列名と推論されたデータ型
- サンプル行
- 数式の依存関係マップ
- 検出されたメトリクス
- 日付範囲
- 欠損値
- 異常値
- シート間またはファイル間のリレーションシップ
モデルが最初に参照すべきなのは、この構造化された表現です。ワークブック全体をそのままプロンプトに流し込むのは、多くの場合、リソースの無駄でありリスクも伴います。
目標は、モデルにファイル全体を暗記させることではなく、次のステップを計画するのに十分なコンテキストを与えることです。
確定的計算レイヤー（Deterministic Compute Layer）
スプレッドシートAIにおいて、これは最も重要なコンポーネントの一つです。
モデルが内部で重要な数値を計算してはいけません。代わりに「ツール」を呼び出すべきです。
計算レイヤーには以下が含まれます。
- スプレッドシートの数式
- SQL
- DuckDB
- pandas
- Polars
- ウェアハウスへのプッシュダウン
- チャート生成
- バリデーションチェック
例えば、ユーザーが「売上上位の顧客」を尋ねた場合、モデルは正しいフィールドを特定してクエリを生成します。計算レイヤーがそのクエリを実行し、モデルはその結果を説明します。
この分離により、正確性、速度、および監査可能性が向上します。
プライベートモデルのサービング
モデルレイヤーの提供には、いくつかの方法があります。
vLLM は、高スループットなセルフホスト推論によく使用され、OpenAI互換のサーバーを提供します。
KServe は、Kubernetesネイティブなモデルサービングや標準的な推論サービスを求める組織に適しています。
NVIDIA NIM は、NVIDIAで加速されたインフラストラクチャ向けに最適化された推論マイクロサービスを提供します。
Ollama は、パイロット運用やローカルテストに便利ですが、本番環境ではより強力なスケーリング、アクセス制御、オブザーバビリティが必要になることが多いです。
モデルレイヤーは内部インフラとして扱うべきです。
- 認証済みであること
- バージョン管理されていること
- モニタリングされていること
- ネットワーク制御により隔離されていること
- 明確なデータ保持ポリシーが設定されていること
- モデルのアップグレード前に評価が行われること
AIオーケストレーション
オーケストレーションレイヤーは、システムがモデルとツールをどのように使用するかを決定します。
以下の処理を担当します。
- プロンプトテンプレートの管理
- モデルの選択
- ツールの選択
- コンテキストの構築
- ユーザーへの確認質問
- クエリのバリデーション
- コードのサンドボックス化
- リトライロジック
- レスポンスのフォーマット
多くの安全制御はこのレイヤーに実装されます。
例えば、モデルがSQLを生成した場合、システムはそのSQLが読み取り専用であり、許可されたテーブルの範囲内であり、コストが高すぎないかを検証する必要があります。モデルがPythonを生成した場合は、明示的に許可されない限りネットワークアクセスを無効にしたサンドボックスで実行すべきです。
監査可能性（Auditability）
本格的な導入において、監査ログはオプションではありません。
有用なログには以下を含めるべきです。
- ユーザー名
- タイムスタンプ
- アクセスされたワークブックまたはデータセット
- プロンプトの内容
- モデル名とバージョン
- 生成されたクエリ、数式、またはコード
- ツールの出力結果
- 最終的な回答
- 権限判断の記録
- エラーとフォールバックの記録
これは、すべての機密データを永久に保存しなければならないという意味ではありません。保持期間は設定可能であるべきですが、レビュー、デバッグ、およびコンプライアンスのために十分な追跡可能性が必要です。
オブザーバビリティ（Observability）
技術チームは、インフラの状態と回答の品質の両方を監視する必要があります。
インフラメトリクス：
- レイテンシ
- GPU使用率
- キューの深さ
- トークン使用量
- モデルエラー
- ツールの実行時間
- ストレージ使用量
品質メトリクス：
- 回答の正確性
- 引用の質
- 数式の妥当性
- クエリの成功率
- ユーザーによる修正
- ハルシネーションの報告
- 確認質問の失敗
オブザーバビリティがなければ、AIアナリストが改善されているのか、あるいは密かに信頼性の低い結果を出しているのかを判断できません。
よくある落とし穴
モデルをスプレッドシートエンジンとして扱う
これは合計値のハルシネーションや脆弱な回答につながります。計算には必ずツールを使用してください。
取得してからフィルタリングする
権限の適用は、コンテキストがモデルに到達する前に行う必要があります。
ワークブックの複雑さを無視する
CSVでのデモが成功しても、実際のExcelファイルを処理できる証明にはなりません。
機密データをログに記録しすぎる
監査可能性は重要ですが、ログも保持ポリシーやプライバシー規則に従う必要があります。
特定のモデルに依存した構築をする
モデルの進化は速いです。モデルを簡単に入れ替えられるようにワークフローを構築してください。
段階的な導入計画
現実的な導入は、以下のステージを経て行われます。
- サンプルデータや秘匿化されたスプレッドシートでプロトタイプを作成する。
- 一般的な分析タスクと失敗ケースを検証する。
- すべての数値計算に確定的計算レイヤーを追加する。
- 実際のファイルを使用する前に、アイデンティティと権限を接続する。
- vLLM、KServe、NIM、または承認されたスタックを通じてプライベートモデルエンドポイントをデプロイする。
- 監査ログとモニタリングを追加する。
- 財務、運用、営業レポートなどの特定のチームでパイロット運用を開始する。
- 拡大前に、既知の正解データと照らし合わせて出力を評価する。
これにより、ガバナンスレイヤーが整う前にモデルのデモをそのまま本番システムにしてしまうという、よくある間違いを避けることができます。
RowSpeakの役割
RowSpeakは、プライベートモデルエンドポイントと管理されたデータ実行環境の上の「ワークフローレイヤー」として機能します。
モデルサーバーが「推論」を提供し、RowSpeakが「スプレッドシート体験」を提供します。具体的には、ワークブックのアップロード、自然言語による質問、チャート作成、要約、レポート、そして週次売上レポートのようなユーザー向け分析フローなどです。
オンプレミス導入において、この分離は非常に価値があります。IT部門はモデルとインフラを制御でき、ビジネスユーザーは生のAPIコールではなく、AIダッシュボードや財務レポートの作成に適したインターフェースを通じて業務を行うことができます。
最後に
オンプレミスのLLMエンドポイントは「インフラ」です。一方、オンプレミスのAIスプレッドシート・アナリストは、「製品体験」と「ガバナンス」を組み合わせたものです。
モデル自体も重要ですが、その周囲のアーキテクチャこそが、システムが信頼されるかどうかを決定します。モデル固有の例については、RowSpeakのためにDeepSeekをセルフホストするガイドを参照してください。
出典および詳細情報
- vLLM OpenAI互換サーバー: https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
- KServe: https://kserve.github.io/website/
- NVIDIA NIM: https://www.nvidia.com/en-us/ai-data-science/products/nim-microservices/
- Ollama ライブラリ: https://ollama.com/library
- llama.cpp: https://github.com/ggml-org/llama.cpp
