AIアシスタントを自社データセンターへ移す時代が到来 UbiGPT × UbiCode × UbiWork：オンプレミス型企業AI協働ソリューション
26-08-26
Author: Bull, BD & MKT Director | Editor: Helen, Deputy Marketing Manager
オープンウェイトモデルの能力は、今も急速に進化し続けています。2年前、それは一行ずつ確認しなければならないインターンのような存在でした。しかし現在では、修士号・博士号レベルの能力を持つフルタイム社員に近づきつつあります。モデル能力がもはやボトルネックではなくなると、「モデルを誰のマシン上で動かすのか」は、単なる技術的な好みではなく、セキュリティとコストの核心的な問題になります。AIアシスタントを自社の機械室へ移す時代は、すでに到来しています。
はじめに：モデル能力は一つの境界を越えた
ここ数年、自社運用型AIに反対する理由として最も強かったものの一つは、「オープンソースモデルはまだ十分に強くなく、節約したコストは品質低下で失われる」というものでした。
しかし、この前提は崩れ始めています。しかも、その速度は多くの人が予想していたよりも速いものです。
この進展を比喩で表すと、2年前のオープンウェイトモデルはインターンのような存在でした。タスクを十分に細かく分解し、文脈を十分に与える必要があり、出力後も一行ずつ確認しなければなりませんでした。多くの場合、確認にかかる時間は、自分で作業するよりも長いほどでした。1年前には、新卒社員くらいのレベルに近づきました。明確な仕様がある仕事はこなせますが、仕様に書かれていない部分に出会うと、止まったり、推測で答えたりしていました。
そして現在の世代のオープンウェイトモデルは、すでに修士号・博士号を取得したフルタイム社員に近い能力を持つようになっています。
- 最後の一文に反応するだけでなく、全体の文脈を理解できます。
- 曖昧な要求を自ら実行可能な手順に分解し、作業に入る前に重要な前提を確認できます。
- 自分の出力を判断する力があり、どこに自信がなく、どこを検証すべきかを理解できます。
- 誤りを指摘されたとき、全体を運任せで書き直すのではなく、問題点に応じて修正できます。
この4つが組み合わさることで、質的な変化が生まれます。出力は「人がもう一度やり直す必要があるもの」から、「そのまま使えるもの」へと変わり始めています。
この違いがコストにもたらす意味は、モデルのベンチマークスコアよりもはるかに重要です。AIの出力にまだ人が時間をかけて仕上げる必要があるなら、実際に節約できているのは工数ではありません。作業が「書く」から「直す」へ移っただけです。しかし、出力をそのまま使えるようになれば、そこで初めて本当の意味での削減になります。
そして今、三つの線が交差しています。
- モデル能力が「納品可能」な水準を超え、自社運用が妥協ではなくなったこと。
- 推論フレームワークとハードウェアが成熟し、中堅企業でも実用的なスループットを負担できるようになったこと。
- AIが読み取るデータがますます機密性を帯びるなかで、データ主権への要求が急速に高まっていること。
最初の二つは、自社運用における技術的・コスト的な障壁を取り除きました。そして三つ目は、自社運用を「検討可能な選択肢」から「実行せざるを得ない選択肢」へと変えています。AIアシスタントを自社の機械室へ移す時代は、まさにこの交差点で到来しています。
本稿で扱うのは、この時代が到来した後の実務的な問題です。なぜデータを自社の境界内に留めなければならないのか、私たち自身が社内でどのように活用しているのか、法務・営業・研究開発・インフラを横断する五つの実例、そして完全な自社運用ソリューションがどの三層で構成されるのかを解説します。
一、問題は「AIを使うかどうか」ではなく、「データがどこへ流れるか」
過去2年間、多くの企業におけるAI導入の方法はほぼ似通っていました。法務部門は契約書をチャット画面に貼り付け、営業部門は売上レポートをアップロードし、エンジニアはクラウドIDEプラグインをインストールしてAPI Keyを入力し、プロジェクトのソースコードを読ませる。この流れ自体は動きます。しかし細かく分解すると、いくつかの問題が見えてきます。
- 有用にするには、完全な文脈を与える必要があります。AIが断片しか見られなければ、返ってくる答えも断片レベルにとどまります。本当に価値のあるタスク、たとえば契約書を一通まるごと読むこと、1年分の売上データを分析すること、既存システムを理解することは、本質的に「大量の読み取り＋反復的な推論」です。一つのタスクで数百個のファイルや未公開文書全体を読み込む可能性があり、それらの内容はすべて社内ネットワークの外へ出ていきます。文脈の深さは、そのままデータ流出面の大きさになります。
- 「学習には使用しない」は、条項であってアーキテクチャではありません。多くの商用APIの規約では、企業向けプランの顧客データは学習に使用しないと明記されています。しかしこれは契約上の約束です。規約のバージョンが更新されたり、アカウントが誤って個人向けプランに設定されたり、トラフィックが別の中間gatewayを経由したりすれば、制御権は自社の手を離れます。条項は変えられますが、ネットワークトポロジーは自動では変わりません。
- コストは利用規模に比例して膨らみ、予測しづらくなります。Token課金モデルでは、「真面目に働く」AIほど高くつきます。AIが自動でスケジュールを組み、繰り返し確認し、修正を反復し始めると、一つのタスクのtoken消費量は、人間が手動で質問する場合の数十倍になることがあります。月末の請求額を事前に見積もることは困難です。
- コンプライアンス審査が最前線で立ちはだかります。金融、医療、ゲーム運営、政府入札、あるいはNDAを締結したあらゆる協業案件では、「この文書やコードを第三者サービスに送信してよいのか」という一点だけで、導入計画全体が法務会議室で止まってしまう可能性があります。
この四つの問題に対する共通の解決方向は一つだけです。モデル推論、本人認証、そしてAIの実行環境を、すべて自社が制御できる境界内へ戻すことです。
二、On-Premiseの四つの実質的な効果
1. プライバシー境界がネットワーク境界になる
推論サービスが社内ネットワークのGPUノード上で動作すると、「データが外に出ない」ことは信頼に頼る必要がなくなり、ファイアウォールルールで検証できるようになります。AIが読む契約書、見積書、売上明細、社内Wiki、プロジェクトソースコード、本番環境logは、すべて同一VLAN内で流れます。監査時に提示できるのは、ベンダーのコンプライアンス白書ではなく、ネットワークトポロジー図とegress遮断ルールです。
2. 機密データが学習データになることを確実に防げる
自社運用モデルの重みは静的です。自分たちでfine-tuning pipelineを起動しない限り、どの会話もモデルへ逆流することはありません。ここで重要なのは主語です。「学習に使うかどうか」は自分たちの選択肢になり、ベンダー規約の問題ではなくなります。後続の第5.4節では、この選択権をどのように優位性へ変えるかを扱います。
これは特に三種類の資産にとって重要です。
- まだ特許出願していない技術実装。これが第三者モデルの学習データになった場合、先行技術、つまりprior artの認定リスクは定量化しにくくなります。
- 顧客NDAで保護された文書と成果物。契約書、仕様書、統合コードなどが含まれます。顧客に対する守秘義務は、「当社のベンダーは使わないと言っている」という説明だけで転嫁できるものではありません。
- 特許も著作権保護もない営業秘密。価格戦略、コスト構造、顧客リスト、交渉上の底値などです。この種の資産の価値は、「他社が知らない」ことに完全に依存しています。一度流出すれば回復できず、権利主張も困難です。
3. コストが変動費から固定資産へ変わる
これは最も見落とされやすい点です。商用APIは変動費であり、「AIをうまく使えているか」と正の相関があります。チームが熟練し、自動化が多く走るほど費用が増えます。これは正しい利用行動に課税しているのと同じです。自社運用の推論は固定費です。GPUを導入した後、タスクを一つ多く実行する限界費用は、ほぼ電気代に近づきます。
説明用の概算試算です。実際には、自社の負荷テストと見積もりに置き換えてください。
重要なのは「どちらが必ず安いか」ではなく、コスト曲線の形が違うということです。小規模チームや低利用量では、APIのほうがほぼ確実に合理的です。しかし損益分岐点を超え、利用量が成長し続ける場合、自社運用の限界的な優位性は拡大し続けます。そしてチームに対して「もっと使ってよい」と安心して言えるようになります。
なお、上記の表では、すべてのタスクを同じモデルで処理する前提になっています。これは実は最も非効率な使い方です。後ほど、性質の異なる作業を異なる階層のモデルへ割り当てることで、さらに大きくコストを下げられることを説明します。
4. 可用性と遅延を自社で制御できる
第三者のrate limitはありません。海外リージョンとのRTTもありません。ベンダーのサービス品質低下によって全社作業が止まることもありません。社内ネットワークでの推論は、first-token latencyがクロスリージョンAPIより明確に優れることが多くあります。一つのタスクで数十回のやり取りを行う自動化ワークロードでは、この累積差はかなり大きくなります。
三、実戦検証：Ubitus社内の実際の活用シーン
以上の四点が理論にとどまるだけでは、説得力は十分ではありません。そこでアーキテクチャの話に進む前に、まず一つ明確にしておきたいことがあります。このシステムは、Ubitus社内ですでに全面的に使われています。
これは外部販売のために作ったデモではなく、私たち自身が毎日運用している基盤です。しかも研究開発部門だけではありません。以下の五つのシーンは、法務、営業、ソフトウェア開発、インフラ調整を横断しており、すべて社内ネットワーク内で完結しています。文書、データ、コードは一切社外ネットワークへ出ていません。
この五つのシーンに共通する特徴に注目してください。どれも「AIが提案し、人間がもう一度作業する」ものではありません。AIが直接、利用可能な成果物を出しています。これこそが、冒頭で述べた境界線です。もしモデルがまだ一行ずつ確認しなければならない段階にあるなら、この五つのどれも採算が合いません。
3.1 法務：契約の初期レビューと変更履歴付き修正
契約書は、おそらく企業内で「クラウドAIに最もアップロードしにくい」文書の一つです。そこには顧客名、ライセンス条件、価格構造、違約条項が含まれ、さらに別のNDAで制約されていることも多くあります。第三者AIサービスで契約書をレビューすることは、コンプライアンス上、ほぼ議論するまでもなく却下されることが多いでしょう。
自社運用環境では、この制約が消えます。そのため、私たちはUbiWorkを法務の第一防衛線として活用しています。
- 初期レビューとリスクのマーキング：AIが契約書全体を読み、双方の権利義務を条項ごとに比較し、明らかに不均衡な条項を特定します。たとえば一方的な無期限守秘義務、非対称な責任上限、一方のみを拘束する解除条件、恣意的に解釈できるほど曖昧な検収基準などです。
- 修正案の提示：各指摘箇所について、「ここは当社に不利です」と言うだけではなく、具体的な書き換え方向を提示します。
- 人間による確認：法務担当者がAIの判断を一つずつ確認し、採用、修正、または却下します。このステップは省けません。AIは初期レビュー担当であり、意思決定者ではありません。
- 送付可能なファイルを直接出力：確認後、変更履歴とコメント付きのWordファイルを直接生成します。形式は人間が修正した場合と完全に一致しており、そのまま相手方の窓口へ送付できます。
第4ステップこそが、このプロセス全体の本当の鍵です。市場にある多くのAI法務ツールの出力は「提案リスト」です。法務担当者はその後、自分でWordを開き、一条ずつ修正を移し、さらにコメントを手動で追加しなければなりません。この移し替え作業は、レビューそのものより時間がかかることがあります。直接納品可能なファイルを出力できて初めて、本当に工数が削減されます。
UbiWorkの実画面：AIが乙方の視点で契約書を読み、支払い・検収基準、中間報告のスケジュール、保証および侵害責任の上限、沈黙を同意とみなす条項などについて、コメントを推奨する条項と理由を一つずつ列挙します。確認後、変更履歴付きのWordファイルを直接出力できます。
3.2 営業：売上データ分析とインサイト
二つ目のシーンも研究開発部門ではありません。売上データのExcelファイルをUbiWorkに渡し、分析とインサイト、提案を求めるというものです。
この作業のハードルは、通常、分析そのものではなく前処理にあります。従来であれば、まずデータエンジニアがpipelineを構築し、データをBIシステムに取り込み、ダッシュボードを設計する必要がありました。一つの一時的な質問に答えるだけでも、2週間待たされることがあります。現在のフローは、ファイルを入れて、そのまま質問するだけです。
実際の用途には、トレンドや季節変動の解釈、異常値の特定と原因候補の分析、製品ライン別・地域別のクロス比較、それに基づく具体的なアクション提案が含まれます。スケジュール機能を組み合わせれば、毎週自動実行するよう設定し、管理職が朝一番に最新の分析要約を受け取ることもできます。
売上データの機密性について、詳しく説明する必要はないでしょう。収益構造、顧客貢献度、価格戦略は、競合他社が最も知りたがる情報です。それらを安心してAIに分析させられる唯一の理由は、モデルが自社の機械室で動いているからです。
3.3 研究開発：CI統合により、commit後にテストが自動生成される
私たちはAI AgentをCI pipelineに直接接続しています。エンジニアが git commit すると、Agentが今回の変更内容を自動で分析し、対応するunit testを補完します。
この価値は、実際の工数構造の中で見なければ分かりません。ソフトウェア開発では、およそ半分の時間がテスト作成に費やされます。そしてそれは、エンジニアが必要だと認めながらも、最も達成感を得にくい半分でもあります。新機能は生みませんが、それがなければリファクタリングは誰も怖くてできず、リリースは祈りに頼ることになります。
今、この半分の時間をAIが節約してくれています。
さらに重要なのは、チーム行動を変えることです。以前は、プロジェクトが忙しいときに「今回はテストを書かず、あとで補う」という妥協がよく行われました。そしてその「あとで」は通常やって来ません。テストを補うコストが限りなくゼロに近づくと、テストカバレッジは規律だけで維持するものではなく、プロセスの自然な産物になります。
3.4 研究開発：自動初期レビューでshift-leftを本当に最初の一歩へ
同じpipeline上で、Agentは変更に対して初期code reviewも行います。
成果は非常に直接的です。すでに何度も、人間が手書きしたコードのbugを見つけています。注意すべき点は、これはAIが書いたコードではなく、人間が書いたコードだということです。これらの問題が捕捉されなかった場合、最良の場合でも同僚がcode reviewで見つけ、二人分の時間を消費します。普通の場合はQA段階に入り、一つのテストサイクルを無駄にします。最悪の場合は本番で爆発し、チーム全体の夜を奪います。
shift leftについては長年語られてきました。しかし本当の難しさは考え方ではありません。「早く検査するほどコストは低い」と「早く検査するほど人手がない」という矛盾にあります。commitの瞬間に、すべてのエンジニアのコードを一行ずつレビューする専任のシニアエンジニアを置けるチームはありません。
AI Agentが補うのは、まさにこの位置です。疲れず、時間を選ばず、すべてのcommitを平等に扱います。欠陥はライフサイクルの第一歩で捕捉され、災害は災害になる前に消えます。
UbiCodeによるGitLab MR #12の自動レビュー結果では、重要度別に分類し、ファイルと行番号を一つずつ指摘しています。その中で cert.py:25 は、SSL検証失敗時に自動的に検証なしへ降格していました。このような「動いているように見えるが、実際にはTLS検証を無効化している」書き方は、人間のreviewで最も見落とされやすいものの一つです。
3.5 研究開発：「意見がなくなるまでレビューする」品質ループ
これは、私たちがon-premiseの価値を最もよく示す実践の一つだと考えているものです。
私たちはAIにコードをレビューさせます。そのコードがAI自身によって書かれたものか、別のモデルによって書かれたものかは問いません。問題を見つけたら自動で修正し、再びレビューします。これを繰り返し、レビュー担当がこれ以上の修正提案を出せなくなるまで続けてから、成果物を出します。
このループは技術的には複雑ではありません。難しいのはコスト構造です。一つのタスクで十数回、二十回近い推論を実行することもあります。token課金モデルでは、このやり方は月末の請求書を前に、ほぼ確実に止められます。チームは「このタスクにもう一回推論を回す価値があるのか」と自己検閲を始め、品質はまさにその計算の中で犠牲になります。
自社運用環境では、この懸念が丸ごと消えます。GPUはすでに機械室にあり、十回余分に回す限界費用は電気代にすぎません。だからこそ、私たちはチームに対して堂々と言えます。tokenを燃やすことを恐れず、良くなるまで回せ、と。
その結果、出力品質は全体的に向上します。そして実際的な変化も生まれます。AIが出してくるものは、「そのまま使える成果物」であり、「人間がさらに時間をかけて仕上げる必要のある下書き」ではなくなります。この差こそが、AI支援開発が本当に時間を節約しているのか、それとも作業を「書く」から「直す」へ移しただけなのかを分けます。
3.6 インフラ：AIにAI自身の推論エンジンを調整させる
最後のシーンは少し特殊です。私たちはAIにUbiGPT自身の推論エンジンを最適化させています。
モデルデプロイを経験したことがある人なら分かるように、「モデルをサービスとして起動する」ことと、「モデルサービスを最速に調整する」ことは別物です。後者の探索空間は非常に大きく、tensor parallelismの分割方法、batch size、KV cache構成、量子化戦略、context長の上限、スケジューリングパラメータなど、各要素が互いに影響し合います。そしてすべてのワークロードに対して最適な単一のパラメータセットは存在しません。
従来の方法は、シニアエンジニアが手動で試すことです。パラメータを一組変え、デプロイし、benchmarkを実行し、結果を待ち、記録し、また次の組み合わせを試す。問題は難しさではありません。この作業が「非常に時間がかかる」うえに「非常に機械的」であることです。エンジニアの大半の時間は、benchmarkの完了を待ち、その数字をスプレッドシートに書き写すことに費やされます。
現在、この作業はAIによる多段階の自動反復に任せています。
Agentは自分でデプロイし、自分で負荷テストを行い、自分でデータを読み、夜通し無人で動き続けます。
Agentは自らデプロイし、負荷テストを行い、データを読み、次に試すべきパラメータを判断し、再実行します。一晩走らせると、翌朝には各ラウンドの実測データに裏付けられた、完全なパラメータ探索結果と最適構成の提案が得られます。
このシーンの効果は複利的です。調整によって得られたスループット向上は、各推論のコストを直接下げます。そして下がったコストは、前述の高頻度利用シーンをさらに経済的にします。AIでAIの基盤を最適化し、節約した計算資源を再びAIへ戻す。これは自己加速する循環です。
3.7 小結：五つのシーン、二つの共通前提
この五つのシーンを振り返ると、部門も業務性質もまったく異なります。しかし二つの前提を共有しています。
前提一：最も機密性の高いデータは、社内ネットワークでなければAIに渡せない。
これらの仕事をAIに任せられるのは、ベンダーの規約を信頼しているからではありません。データがそもそも機械室から出ていないからです。
前提二：推論コストが予測可能であり、高頻度利用を罰しないこと。
- commitのたびにテストを自動補完する → 高頻度で発火し、使用量が非常に大きい。
- commitのたびに自動reviewする → 高頻度で発火し、使用量が非常に大きい。
- 反復的な自己レビューと修正 → 単一タスクあたりの使用量が非常に大きい。
- 多段階のパラメータ探索と負荷テスト → 夜通し連続計算する。
これらのどれか一つでも従量課金モデルに置けば、すぐに「利用頻度を制限すべきか」という議論になります。しかし自社運用環境では、この議論自体が不要です。
だからこそ、私たちはon-premiseを保守的な選択肢ではなく、AIが本当の価値を発揮するための前提だと考えています。
次回の記事では、UbiGPT、UbiCode、UbiWorkがそれぞれ推論ガバナンス、研究開発Agentチーム、部門横断のAI協業にどのように対応し、完全なOn-Premise企業AIソリューションを構成するのかをさらに分解して解説します。
ユビタスについて
ユビタスは、NVIDIA から出資を受けた台湾初のテクノロジー企業であり、高度なGPU仮想化技術およびクラウドストリーミング技術において、世界的に高い評価を受けており、さまざまな産業分野に向けて、世界水準のクラウドおよび AI ソリューションを提供しています。
また、台湾大学（National Taiwan University）や東京大学（The University of Tokyo） などのトップ大学と連携し、繁体中国語および日本語に対応したローカライズ大規模言語モデル（LLM）の研究・開発を推進しています。
ユビタスは以下を含む多様なAIGC（AI生成コンテンツ）サービス を展開しています。
- UbiArt：AI画像生成ソリューション
- UbiONE：AIバーチャルキャラクターソリューション
- UbiAnchor：AI搭載バーチャルニュースアンカー
- Ubi-chan（AI VTuber）生成AI技術を体験する公式ブランドアンバサダー
さらに、クラウドゲーム分野のパイオニアとして、ゲームスタジオ向けにクラウド対応を実現するエンドツーエンドのソリューションを提供するとともに、通信事業者による独自クラウドゲーミングサービスの構築を支援しています。同技術は、インタラクティブコンテンツやVRを含むマルチメディア配信にも活用されています。
お問い合わせ先
TEL : +81-3-6435-3295 (東京)
+886-2-2717-6123 (台北)
メディアに関するお問い合わせ : pr@ubitus.ai
事業に関するお問い合わせ : contact@ubitus.ai
Webサイト: www.ubitus.ai
