【後編】企業向けオンプレミスAIの実装方法：UbiGPT × UbiCode × UbiWork の三層アーキテクチャ
26-08-26
Author: Isaac, AI and Cybersecurity R&D Director | Editor: Helen, Deputy MKT Manager
はじめに：「なぜ自社運用か」から「どのように実装するか」へ
前編では、オープンウェイトモデルの能力が徐々に「納品可能」な水準を超えつつあるなかで、企業がAIを導入する際の核心的な問題は、もはやモデルが十分に強いかどうかだけではないと述べました。重要なのは、データを自社の境界内に留められるか、推論コストを予測できるか、そしてAIを本当に日常業務フローへ組み込めるかです。
企業にとって、On-Premise AIの価値は単に「モデルを自社のデータセンターに置くこと」ではありません。契約書、売上データ、プロジェクトのソースコード、社内文書、インフラ情報を、社内ネットワークから出すことなく、AIに安全に読み取らせ、分析させ、実行させることにあります。データ主権、コスト構造、利用への信頼が企業の手に戻ることで、AIは単発のQ&Aツールから、ガバナンス可能で、拡張可能で、継続的に最適化できる内部基盤へと進化する可能性を持ちます。
しかし本当の課題は、企業がこれをどのように実装するかです。
本番環境で利用できるOn-Premise AIシステムは、単に一つのモデルサービスを立ち上げるだけでは不十分です。また、共用API Keyをチームに配るだけでも不十分です。モデル推論、本人認証、キー管理、Agentの実行環境、部門横断の協働インターフェース、利用記録、コスト配賦、セキュリティ監査を同時に扱う必要があります。
そのため本後編では、ソリューションアーキテクチャから入り、Ubitusが UbiGPT、UbiCode、UbiWork の三層プラットフォームを通じて、On-Premise AIを概念から企業が実際に導入できる協働システムへと変換する方法を解説します。
四、ソリューションアーキテクチャ：三層分解
三層は標準プロトコルのみで通信します。UbiCodeとUbiWorkはいずれも、OpenAI互換APIを通じてUbiGPTにアクセスします。
この設計には二つの利点があります。第一に、基盤となるモデルをいつでも差し替えられることです。今日Aモデルを動かし、次の四半期により強力なBモデルへ切り替えても、フロントエンドのユーザーは違いを感じません。第二に、同一エンドポイントの背後に複数のモデル階層を同時に配置できるため、上位レイヤーはタスクの性質に応じて最適なモデルを選択できます。これこそが、次節で述べる役割化されたAgentを成立させる基盤です。
五、推論層：UbiGPT
多くのチームがLLMを自社運用する際、最初のバージョンは「モデルサービスを立ち上げ、共用API Keyを全員に配る」形になりがちです。これはPoC段階では機能しますが、本番環境に入るとすぐに三つの問題に直面します。誰が使っているのか分からない、退職者の残留キーを止められない、そして各チームへのコスト配賦を算出できないという問題です。
UbiGPTは「モデルサービス」と「企業のIDガバナンス」を一つの層に統合します。これが単に推論コンテナを立ち上げるだけの場合との違いです。
5.1 モデルサービス
- OpenAI互換エンドポイント — 上位ツールは改修なしで接続でき、既存のSDK、CI script、サードパーティプラグインなどのエコシステムをそのまま利用できます。
- マルチモデルルーティング — 同一endpointの背後に、軽量高速、標準、高度推論、マルチモーダルなど複数階層のモデルを配置できます。チーム、プロジェクト、またはAgentの役割に応じてルーティングできます。高機密プロジェクトは強制的に社内モデルを利用し、特定の非機密プロジェクトのみ外部プロバイダーへの接続を許可する、といった集中管理が可能です。これは第六章の「役割ごとに適切なモデルを割り当てる」設計が実現する前提です。
- 長文脈対応 — Agentic codingでは、一般的なQ&Aよりはるかに長い文脈が必要です。実務上、128Kは出発点になります。
- プレフィックスキャッシュ — Agentは各ラウンドで、ほぼ同一のsystem promptとプロジェクト文脈を持ちます。そのためキャッシュヒット率が非常に高くなります。これは自社運用環境において費用対効果が非常に高い最適化であり、スループットに数倍の影響を与えることがあります。
5.2 企業認証：既存ディレクトリへすぐ接続可能
UbiGPTの認証層は、主流のIdP標準を基盤として設計されています。企業がAIを導入するために既存のIDアーキテクチャを変更する必要はありません。
実務上最も重要なのはAD同期です。ユーザーの部門、グループ、在職状態は会社既存のADから直接取得されます。退職アカウントが無効化された瞬間、そのユーザーのすべてのAPI Keyも同時に無効化されます。これにより、自社運用AIサービスで最もよく見られるセキュリティホール、つまり各人の.envに散らばり、期限切れにならない共用キーの問題を解決できます。
5.3 API Keyの発行と利用量ガバナンス
- キーのライフサイクル管理 — ユーザーまたはサービスアカウント単位で発行でき、有効期限、プロジェクト紐付け、随時失効を設定できます。
- 利用量統計とコスト配賦 — 各呼び出しについて、ユーザー、モデル、token数、タイムスタンプを記録します。部門、プロジェクト、個人単位でレポート化できます。自社運用が固定費であっても、内部配賦とROIの証明にはこのデータが必要です。
- クォータとレート制限 — 失控した単一の自動化タスクが、クラスター全体のスループットを消費し尽くすことを防ぎます。
- 監査ログ — 集中化された呼び出し記録により、セキュリティ監査とコスト分析の両方の要求を満たします。
5.4 会話記録の保存：利用履歴を企業資産へ変える
UbiGPTは、任意で有効化できる会話記録保存機能を提供します。この機能は表面的には監査用途ですが、本当の価値は別のところにあります。
人間がAIに与える訂正とフィードバックは、モデルを微調整するうえで最良のデータの一つです。
公開データはモデルに一般知識を教えられますが、「自社がどのように仕事をするか」は教えられません。エンジニアがAIに対して「違う、ここはオープンソースのものではなく、社内コンポーネントを使う」と訂正するたび、法務担当者がAIの条項提案を書き換えて理由を残すたび、シニアアーキテクトが一見合理的な設計を却下するたび、それらはすべて、実際の業務文脈において領域専門家が作り出した高品質なラベル付きデータになります。
このデータには特殊性があります。
- ペアになっている — すべての訂正は自然に「不十分な回答 → より良い回答」という対照を形成します。これは選好微調整に必要なデータ構造そのものです。
- 理由を含んでいる — 人間が訂正するときは、通常なぜそうするのかを説明します。これは単純な正誤ラベルよりはるかに価値があります。
- 購入できない — 汎用のプログラミングデータセットは購入できますが、「自社内部フレームワークの正しい使い方」や「特定の契約条項に対する自社の標準立場」はどこにも売っていません。
- 自然に生成される — 追加のラベリング予算は不要です。チームの日常業務の副産物として生まれます。
保存された記録には三つの使い道があります。
- 領域特化モデルの微調整 — 社内フレームワーク、コードスタイル、業務用語、意思決定慣行を本当に理解する専用モデルを訓練できます。これは内部自社開発ツールチェーンに特に価値があります。外部モデルがどれほど強力でも、自社の内部システムを読んだことはありません。
- 内部評価セットの構築 — 過去に訂正されたケースを回帰テスト用の問題集に整理できます。次にモデルを切り替える際、まずこのセットを実行します。実際に踏んだ落とし穴で検証するほうが、公開ランキングよりはるかに信頼できます。
- ルールとプロンプト資産への抽出 — すべての改善に再訓練が必要なわけではありません。高頻度で現れる訂正は、プロジェクトルールファイルや役割プロンプトに直接書き込めます。低コストで即効性があります。
プログラミング領域では、このデータにはもう一つの出どころがあります。それがgit履歴です。UbiCodeはcommit metadataに出力元を記録します（6.6節参照）。そのため、「AI生成後に人間が修正した」変更を自動的に抽出できます。これは追加ラベリングなしで得られる既成の訓練シグナルです。
これによりフライホイールが形成されます。使えば使うほど訂正が蓄積し、訂正が蓄積するほどモデルはその会社を理解し、モデルが使いやすくなるほど、さらに多く使われるようになります。競合他社が同じオープンソースモデルから始めたとしても、貴社が蓄積したこのデータは複製できません。
これは自社運用環境でしか実現できません。第三者APIを使う場合、完全なインタラクション記録を取り戻すこともできず、自社専用モデルの訓練にそのデータを使うこともできません。データの流れの方向が逆なのです。あなたのフィードバックは、他社のモデルを強くするために使われます。自社運用環境では、記録はもともと自社データベースに存在し、訓練も自社GPU上で実行されます。データチェーンは、生成、保存、訓練の全工程で会社の外へ出ません。
もちろん、この機能にはガバナンスが必要です。デフォルトでは無効にし、チームまたはプロジェクト単位で選択的に有効化し、利用者に明示し、資格情報などの機密情報を自動でフィルタリングし、保存期限を設定し、訓練に含める前に匿名化を完了する必要があります。詳細は第九章で扱います。
六、Agent層：UbiCode
6.1 「一人の万能アシスタント」から「分業するAIチーム」へ
初期のcoding agentの多くは、一つのモデル、一つの役割で、最初から最後まで処理するものでした。やや進んだものでは「計画」と「実行」を分けることもあります。しかし実際の開発作業は二分法ではありません。「三千個のファイルの中から、このAPIを呼んでいる箇所をすべて探す」ことと、「このアーキテクチャを分割すべきか判断する」ことは、まったく異なる性質のタスクです。それにもかかわらず、同じモデルに処理させられがちです。
これは両面で非効率です。高階推論モデルを広範なファイルスキャンに使うことは、最も高価な計算資源を最も機械的な作業に使うことです。一方で、軽量モデルにアーキテクチャ判断を任せると、一見合理的でも深く検討すると耐えられない回答が出てきます。
UbiCodeは、役割化されたAgentチームを採用します。各役割には明確な責務、専用system prompt、利用可能なツール範囲、そしてそれぞれに適したモデル階層があります。総合調整役がタスクを分解し、適切な専門家へ並行して割り当て、最後に結果を統合します。
6.2 役割構成
役割表で最も重要なのは「利用特性」の欄です。Explorerは通常token消費の大部分を占めますが、そのタスクは実際には軽量モデルで十分です。Oracleは一回あたりのコストが最も高いものの、1日に数回しか呼ばれないかもしれません。
各役割にちょうど十分なモデル階層を割り当てることで、「すべてを最強モデルで処理する」場合に比べ、全体コストは数倍変わります。一方で出力品質への影響はほとんどありません。場合によっては、専用プロンプトのほうが汎用プロンプトより正確であるため、むしろ品質が向上します。
これこそがUbiGPTのマルチモデルルーティングの意義です。同じ社内エンドポイントの背後に異なる階層のモデルを配置し、UbiCodeが役割に応じて自動選択します。軽量モデルは低コストの推論リソースプールに配置し、高階モデルは少数の高性能ノードに集中させることで、GPU利用効率を大きく高められます。
6.3 調整と協働方式
- バックグラウンド並行実行 — 調整役は「先にスケジュールする」作業モードを採用し、複数の専門役割をバックグラウンドタスクとして同時に実行します。それぞれの進捗を追跡し、収束後に次の段階へ進みます。これにより、探索、文書検索、既存テストの読み込みといった本来依存関係のない作業を本当に並行化できます。
- 手動指名 — ユーザーは特定の役割を直接呼び出せます。たとえば、
@oracleに対して「このロック設計にrace conditionはあるか」と尋ねることで、調整フローを飛ばし、最も強い推論能力を重要箇所に集中できます。 - マルチモデル会議 — 重要な意思決定点では、会議モードを起動し、複数のモデルに同じ問題を個別に回答させます。その後、システムが共通点と相違点を統合します。自社運用環境では限界費用が低いため、重要な判断に追加推論を使いやすくなります。
- 構造化された長いワークフロー — 大規模変更に対して、棚卸し、計画、検証経路設計、実装、収束といった多段階の作業フローを提供します。Agentに最初から最後まで一気に書かせるわけではありません。
- 切り替え可能なモデルプリセット — 同じ役割構成に異なるモデル組み合わせを紐付け、実行時にワンクリックで切り替えられます。日常開発では経済的な組み合わせ、重要リリースでは高性能な組み合わせを使えます。モデル更新時はpresetを更新するだけで、ユーザー側の変更は不要です。
6.4 能力と権限：役割単位で制御
役割化のもう一つの利点は、権限をより細かく切れることです。UbiCodeのSkillとMCPツールは、いずれも役割単位で認可されます。
- SkillとMCPアクセスはホワイトリスト制で、ワイルドカード認可（*）や明示的な拒否（!skill-name）で個別調整できます。
- Explorerと知識検索役割は、そもそもファイル書き込み能力を持ちません。これはプロンプトによる制約ではなく、ツール層で開放していないということです。
- 変更をトリガーできるのは実装役と調整役のみです。破壊的コマンドは常に人間の承認を通します。
- データベース照会系のMCPはOracleのみに開放し、高頻度実行役割には開放しないことができます。
「一人の万能Agentに禁止事項を長く並べる」よりも、役割本来の責務境界で能力を制限するほうが、より信頼性の高いセキュリティモデルです。
6.5 実行環境：軽量VMサンドボックスにより「任せる」ことを現実的にする
役割権限は「Agentがどのツールを使えるか」を解決します。しかしもう一つの問題があります。Agentが実行するコマンドは誰のマシンで動き、どのファイルに触れられるのかという問題です。
UbiCodeのクライアントはDocker imageとして提供され、Windows、macOS、Linux上で標準環境が完全に一致します。Agentの実際の実行は、ユーザーのホスト上ではなく、軽量VM内で行われます。
必要なファイルと権限のみを開放します。
- 現在のタスクに必要なプロジェクトディレクトリのみをマウントします。それ以外のファイルシステムはAgentから見えません。ホームディレクトリ、SSHキー、ブラウザ設定、他のプロジェクトは見えません。
- ネットワークアクセスはホワイトリスト制で、外部接続はデフォルトでブロックされます。内部パッケージmirrorとUbiGPTエンドポイントのみを許可します。
- システムレベルの操作はVM内部に制限され、ホストマシンには影響しません。
これにより四つの実質的な利点が得られます。
- 爆発半径が制限される — モデル判断の誤り、コマンド引数のミス、悪意ある内容によるprompt injectionのいずれであっても、最大の被害は、いつでも捨てて再構築できるVMを壊すことに限定されます。
- 環境が完全に一致する — 「自分のマシンでは動く」という古典的な問題が消えます。エンジニアのローカル、同僚のマシン、CI runnerのすべてが同じimageを使うため、Agentの出力は再現可能になります。
- 新人が1日で使い始められる — 3時間かけて開発環境を構築する必要はありません。imageを取得するだけで完全な作業環境が手に入ります。
- 本当に任せられる — ここが最も重要です。
第4点は詳しく述べる価値があります。Agentの効率は連続実行から生まれます。ファイルを読み、変更し、テストを実行し、結果を見て、再修正する。この一連の流れを止めずに行うことが重要です。しかし、shellコマンドごとに人間が「承認」を押す必要があるなら、このフローは非常に遅いチャットボットに退化します。エンジニアは承認に使う注意力のほうが、自分で作業するより多くなるかもしれません。
するとチームは二つの選択肢で悩みます。全面開放は怖いが、全面管理では意味が失われる。
サンドボックス化はこの問題を解きます。実行環境そのものが隔離され、破棄可能であるなら、「Agentを自動で連続実行させる」ことは勇気のいる決定ではなく、合理的なデフォルトになります。ユーザーはタスクを任せ、別の仕事をし、戻って結果を確認できます。
これは6.4節の役割権限と合わせて、二層の防御を構成します。それぞれ別の問題を管理します。
どちらか一方だけでは不十分です。役割権限だけでは、誘導された実装役がホストマシンに影響を与える可能性があります。サンドボックスだけでは、Agentがプロジェクトディレクトリ内で不適切なことを行う可能性があります。二層を重ねることで初めて、「任せて走らせる」ことを支えられます。
6.6 出所の追跡：git metadataで人間とAIの産出を記録する
AIが大量にコードを生成し始めると、新しい問題が現れます。半年後に振り返ったとき、どの行が人間によるもので、どの行がAIによるものか分かるでしょうか。
多くのチームの答えは、分からない、です。そしてこれは、監査時、事故時、そして「AIが実際にどれくらい有効だったのか」を評価するときに問題になります。
UbiCodeは出所情報をgit metadataに書き込みます。commit trailerとgit notesを利用し、各変更の生成元と必要な文脈を記録します。
- 誰が生成したか — 人間が書いたのか、AIが生成したのか、AI生成後に人間が修正したのか。三つ目が実際には最も一般的です。
- どの役割とモデルか — 実装役の産出なのか、Oracleの産出なのか、どのモデルとバージョンを使ったのか。
- どの審査を通ったか — 自動reviewを通過したか、誰がmergeを承認したか。
重要なのは、これらの情報がmetadata層に書かれることです。commit messageを汚さず、diff内容を変えず、既存のgit blameやcode reviewワークフローにも影響しません。既存ツールチェーンを変更する必要はなく、情報は静かに蓄積されます。
なぜこれを行う価値があるのか。
- コンプライアンスと納品時の申告 — 顧客契約や入札で、AI生成内容の範囲開示を求めるケースが増えています。場合によっては、AI産出物を特定成果物に含めることを明示的に制限することもあります。commitごとの出所記録があれば、これは
git log一行で確認できます。なければ考古学になります。 - 事故調査に痕跡が残る — 本番で問題が起きたとき、「このコードはどのモデル、どのバージョン、どの文脈で生成され、当時人間のレビューを受けていたか」を即座に答えられます。これにより、一行のコードを直せばよいのか、同じ誤りを複製し続けるプロセスを直すべきなのかが決まります。
- データで信頼境界を決める — AI産出物のrevert率、reviewで修正要求された割合、対応モジュールの後続欠陥密度を統計化できます。そのデータに基づき、どのタスクは任せてよく、どのタスクは厳しく管理すべきかを決められます。これは「AIを信頼できるか」を直感で議論するより建設的です。
- 知的財産リスクの範囲特定 — ライセンス紛争が発生した場合、影響範囲を明確に特定できます。repo全体が不確実性に巻き込まれることを避けられます。
- モデルへのフィードバック — これは5.4節と連動します。「AI生成後に人間が修正した」commitのdiffは、それ自体が既成の訓練シグナルです。左側はモデルの出力、右側は専門家が正しいと判断したバージョンであり、commit messageには理由が書かれていることもあります。追加ラベリングは不要で、git履歴そのものがデータセットになります。
第5点は特に重要です。前述の通り、人間の訂正は最良の微調整データです。git metadataにより、これらの訂正を自動的に識別できます。システムは、どのdiffが「人間がAIを修正したもの」なのか、どれが通常の反復開発なのかを把握できます。出所記録がなければ、この最も価値あるデータは数十万件のcommitに埋もれ、取り出せません。
6.7 共通能力
どのインターフェースを使っても、UbiCodeの基礎能力は共通です。
- LSP深度統合 — Language Serverを通じて実際の型情報とシンボル定義を取得します。単なる文字列照合ではありません。大規模プロジェクトでは、修正精度に大きな影響を与えます。
- MCP拡張 — issue tracker、GitLab、内部API文書、データベースの読み取り専用照会などの社内システムを標準プロトコルで接続し、Agentが社内ネットワークを離れずに企業文脈を取得できます。
- プロジェクトルールファイル — チームのアーキテクチャ慣例、命名規則、禁止パッケージ、テストコマンドをrepo内のルールファイルに書き込み、バージョン管理に含めます。これは「チームのエンジニアリング規範の実行可能版」となり、各エンジニアのAgent動作を一致させます。
- Git worktree分離 — 長時間または高リスクのタスクを独立した作業ツリーで行い、現在のブランチに干渉させません。
- HeadlessモードとSDK — 非対話環境で実行でき、CI pipelineに直接組み込めます。PR作成時の自動review、nightlyでの自動テスト補完、CI失敗時の自動修正試行などに対応します。
6.8 TUI：エンジニアのローカル戦場
端末インターフェースはエンジニア自身のマシン上で動作し、既存のshell、git、エディタワークフローとシームレスに接続します。
- 役割は@役割名で直接呼び出すことも、調整役に自動割り当てさせることもできます。バックグラウンドタスクの進捗は同じ画面で追跡できます。
- モデル組み合わせをワンクリックで切り替え、コストと品質のバランスを即時調整できます。
- shellとgitに近く、スクリプト化でき、CI runnerにも組み込めます。
- 機能開発、debug、テスト実行、pre-commit検査など、分単位の対話型反復に適しています。
6.9 WebUIとネイティブApp：チームの協働とレビューの場
ブラウザインターフェースとデスクトップ／モバイルのネイティブAppは、TUIが本質的に得意ではないこと、つまりデバイス横断の継続、長時間タスク、チームレベルのレビューを扱います。
- Session Goals — 目標を設定すると、Agentは作業を継続します。ウィンドウを閉じたり別のデバイスに切り替えたりしても中断しません。大規模移行、フレームワークアップグレード、モジュール横断リファクタリングなど、数時間から数日かかるタスクに適しています。
- 複数案の並行探索 — 会議メカニズムとは異なり、ここでは複数モデルが同じ要件に対してそれぞれ完全な実装を行います。独立したsessionまたはgit worktreeで同時に進め、最後に各バージョンの最良部分を融合して新しいsessionにします。自社運用環境では限界費用が低いため、「複数案を走らせて最良のものを選ぶ」ことが可能になります。token課金モデルでは躊躇する使い方です。
- 役割産出の可視化追跡 — 各役割のバックグラウンドタスク状態、相互依存関係、段階ごとの成果物を同一画面に表示します。Tech Leadは端末に入らず、AIチーム全体が何をしているか把握できます。
- Changes Walkthrough — 大規模diffをAIによる案内に変換し、論理単位でグループ化し、各変更の関係を説明します。これはAI支援開発における最大のボトルネック、つまり出力速度が人間のレビュー速度を大きく上回る問題に正面から対応します。
- リアルタイムプレビュー — 会話の横に実行中のアプリケーションを直接表示し、画面要素と対応するコード変更を照合できます。
- バージョン管理プラットフォーム統合 — issueやPRから完全な文脈を持って作業セッションを開けます。失敗したCIチェックやreview commentをAgentに返し、インターフェース上でPRを更新またはmergeできます。
- デバイス横断アクセス — Windows、macOS、Linuxのデスクトップ、ブラウザ／PWA、IDE拡張、iOS、Androidに対応し、作業セッションはデバイス間で継続します。
- 複数の接続方式はセキュリティポリシーで決定 — これはon-premise導入で特に注意すべき設定点です。
最後の方式は最も便利です。ファイアウォールポートを開ける必要も、固定IPも不要で、QR codeを読み取るだけでスマートフォンから社内の作業セッションに接続できます。しかし同時に、トラフィックが第三者のエッジノードを経由することを意味します。接続自体は暗号化されていますが、この経路が貴社のセキュリティポリシーに適合するかは、セキュリティチームが実際に評価して決定すべきであり、開発チームが独自に有効化すべきではありません。
実務的な推奨は、トンネル機能をデフォルトで無効にし、LAN/VPNを標準接続方式とすることです。ネットワークをまたぐアクセスが本当に必要な場合のみ、プロジェクトの機密等級に応じて個別承認し、有効化状態を定期監査項目に含めます。この機能の存在自体が問題なのではありません。「誰がどの状況で有効化できるのか」の明確な規定がないことが問題です。
- スケジュールタスク — cronまたは日次／週次の間隔で反復タスクを設定できます。
作業追跡とコスト可視化 — sessionをフォルダ単位で整理し、メモ、To Do、再利用可能なプロジェクトアクション、承認要求、token使用量、コストを一目で確認できます。
6.10 二つのインターフェースの選び方
実務上は、両方を同時に導入し、同じアカウントとsessionを共有することを推奨します。エンジニアは自分のマシンでTUIを使って日常開発を行い、Tech LeadはWebUIでチーム全体のAgent産出とコストを確認します。出張中はモバイルAppで長時間タスクの進捗を確認できます。
七、協働層：UbiWork——コードを書かない人のためのAI同僚
AI導入を語るとき、話題はほとんどの場合エンジニアを中心に回ります。しかし研究開発部門から視線を外すと、会社の中で最も多い反復的な文書作業は、実は研究開発にはないことが分かります。
法務は毎週、似た形式の契約書を何件も確認します。営業は毎月、同じレポートを異なる視点で再整理します。財務は複数のスプレッドシート間で数字を照合します。HRは大量の履歴書や定型告知を処理します。PMは会議の逐語録を仕様書や週報に変換します。これらの作業には三つの共通点があります。反復性が高い、明確な形式がある、そして非常に時間がかかることです。
そして、これらの人たちは最もツールに支援されていない層でもあります。エンジニアにはIDE、CLI、さまざまなagentがあります。一方で、これらの同僚が持っているのはOfficeとチャット画面だけです。貼り付けられるものには限りがあり、機密情報は貼り付けられません。
UbiWorkは、この層を対象にしています。設計の前提は、ユーザーがエンジニアリング背景を持つ必要も、prompt技術を学ぶ必要も、背後でどのモデルが動いているかを知る必要もないことです。
7.1 設計上の三つの重要な決定
一、出力はファイルであり、チャットメッセージではない。
これはUbiWorkと一般的なAIアシスタントの最大の違いであり、「本当に使われるか」を決定する重要点です。AIがチャットボックスに10個の提案を並べると便利に見えます。しかしユーザーが次に行うことは、Wordを開き、提案を一つずつ移し、書式を調整し、コメントを追加することです。この移し替え作業は、思考そのものより時間がかかることがあります。
UbiWorkは、直接納品可能なファイルを生成します。変更履歴とコメント付きのWord、書式とグラフが整ったExcel、トランジション付きのプレゼン資料です。確認すればそのまま送付でき、途中に移し替え作業はありません。
二、ファイルを入れて、中国語で依頼する。
pipelineを先に作る必要も、BIシステムに取り込む必要も、数式を書く必要もありません。契約書、レポート一式、逐語録をドラッグし、日常言語で何が必要かを説明します。非技術ユーザーにとって、「使えるかどうか」は意欲の問題ではなく、最初のステップのハードルが高いかどうかの問題であることが多いのです。
三、役割を内蔵し、ユーザーにprompt作成を求めない。
システムには、契約レビュー、プレゼン作成、レポート分析、文書作成など、複数の専門役割テンプレートが内蔵されています。ユーザーは役割を選ぶだけで開始でき、有効なpromptの書き方を研究する必要はありません。
7.2 能力
- 複数Agent協働（Team Mode） — 複数のAI役割が分業し、並行して実行します。単一アシスタントが順番に処理するのではありません。たとえば提案書の場合、一つの役割がデータを整理し、一つがコピーを書き、一つがプレゼンに整えます。
- Office文書生成 — プレゼン資料（トランジション付き）、Word文書、Excelスプレッドシート（自動書式設定とグラフ付き）を生成し、複数の専門役割テンプレートを内蔵します。
- ファイルとデータ処理 — 一括リネーム、自動アーカイブ、スマート分類、ファイル結合、Excelデータ分析、レポート生成に対応します。
- 24/7スケジュール自動化 — 週次レポート、月次照合、定期的なデータ健全性チェックを一度設定すれば継続実行でき、管理者は朝一番に最新要約を受け取れます。
- 複数形式プレビューと複数タブ — PDF、Word、Excel、プレゼン、Markdown、画像、HTML、Diffを同一画面でプレビューでき、複数タブで同時比較できます。「旧契約と新契約を並べて見る」ような作業に特に有効です。
- リモートアクセス — WebUIは社内サーバーに導入し、全社で共有できます。企業が既存の社内コミュニケーション基盤を持つ場合、モバイル端末からのタスク指示を支援する連携を検討できます。厳格なon-premiseポリシーを採用する場合、外部通信チャネルはすべてセキュリティ評価後に有効化する必要があります。
- データのローカル保持 — すべての作業セッションとファイルはローカルに保存され、外部サーバーにはアップロードされません。
7.3 非研究開発部門へ導入する際の三つの注意点
研究開発チームと比べ、非技術部門への導入は「人」の部分で止まりやすくなります。私たちの経験では、次の三点が重要です。
- 標準形式の反復作業から始める — 契約初期レビュー、月報整理、レポート分析などは、正誤基準が明確で、ユーザーがAIの出来をすぐ判断できます。信頼の構築も早くなります。逆に、最初のシーンが創意発想や外部向けコピーの場合、評価が主観的で議論になりやすく、初期段階で支持を失いやすくなります。
- 人間確認の関門は省けない — AIは初期レビュー担当であり、意思決定者ではありません。契約条項、財務数字、外部向け文書はすべて、名前のある人間が承認する必要があります。この点は研究開発以外の部門でより重要です。これらの産出物は直接外部に出ることが多く、外に出た後は取り戻せないからです。
- 出力形式が採用率を決める — 繰り返す価値があります。そのまま送れるファイルだけが継続的に使われます。もう一度人間が移し替える必要のある提案リストは使われません。導入時には「AIの答えが正しいか」ではなく、「出力を直接使えるか」をまず問うべきです。
第三章の契約初期レビューと売上データ分析は、UbiWorkの社内での実際の使い方です。ユーザーは法務と営業の担当者であり、どちらのシーンにもエンジニアは関与していません。これこそが、この層が存在する意義です。AIの効果は研究開発部門だけに留まるべきではありません。
八、導入対照：部門の日常業務からSDLCまで
8.1 非研究開発部門の日常業務
この表の共通点は、各項目の出力が会話ではなくファイルであることです。これが、第七章で「納品可能なファイル出力」を設計上の第一の重要決定とした理由でもあります。
8.2 研究開発：SDLC各段階
九、ガバナンス：自社運用は自動的な安全を意味しない
モデルを機械室へ移すことで「データ流出」は解決できます。しかし「内部での濫用」や「出力の暴走」は解決されません。さらに、利用者が研究開発から法務、営業、財務へ広がるにつれて、ガバナンスの重点も変わります。エンジニアが扱うのは自社のコードですが、法務や営業が扱うのは顧客のデータであり、相手方の契約条項が適用されます。
以下の仕組みを同時に整備する必要があります。
- データ分類と利用可能範囲 — どの種類のデータをAIに渡せるのか、どれは先に匿名化すべきか、どれは完全に禁止かを明確に定義します。これは導入前に行うべきであり、事故後に補うものではありません。個人情報や顧客識別情報を含むファイルには特に注意が必要です。すべて社内ネットワーク内で完結していても、個人情報保護法や顧客契約の制約を受けます。「外部に出ていない」ことは「自由に使ってよい」ことを意味しません。
- 最小権限を役割単位で適用 — UbiCodeの役割権限ポリシーにより、探索・検索系の役割はツール層で書き込み能力を持たないようにします。変更をトリガーできるのは実装役と調整役だけです。破壊的コマンド、production資格情報、外部ネットワーク要求はすべてデフォルトでブロックし、高リスク操作は人間の承認を通します。責務境界で能力を制限することは、promptで注意書きをするより信頼できます。
- IDとキーの集中管理 — すべての推論トラフィックは「人」に追跡可能な資格情報を持ち、UbiGPTによって一元的に発行・失効されなければなりません。あらゆる形の共用長期キーは禁止すべきです。
- Secrets分離 — Agentの作業ディレクトリに本物の資格情報を含めてはいけません。secret managerで注入し、機密ファイルがignore listに含まれるようにします。
- 実行環境のサンドボックス化 — Agentは常に軽量VM内で実行し、現在のタスクに必要なディレクトリのみをマウントします。これにより、認可ミスの結果をセキュリティ事故からコンテナ再構築へと格下げできます（6.5節参照）。
- egressのデフォルト遮断 — Agent実行環境の外部ネットワークはデフォルトで閉じます。必要な外部リソース、たとえばパッケージリポジトリや文書は、内部mirrorまたはホワイトリストproxyを通します。これはprompt injectionによるデータ外部送信経路も同時に遮断します。
- リモートアクセス経路の明文化 — UbiCodeのトンネル接続やUbiWorkの外部通信連携のように、「便利だが内網を出る」機能には、明確な有効化条件と承認プロセスが必要です。定期監査にも含めるべきです。デフォルトでは無効にします。
- 会話記録の通知と浄化 — 5.4節の記録保存を有効にする場合、どのプロジェクトが保存されるのか、保存期間はどれくらいかを明確に知らせる必要があります。資格情報、個人情報、顧客識別情報を自動検出して除去し、訓練データに含める前に匿名化と人間によるサンプリング確認を完了します。自社データでモデルを訓練できることは利点ですが、その前提はデータ自体がクリーンであることです。
- 監査ログの集中化 — 誰が、いつ、どのモデルで、どのタスクを実行し、どれだけtokenを消費したかをすべてローカルに保存します。これはセキュリティ監査とコスト分析の両方に役立ちます。
- 出力元の全工程記録 — コードはgit metadataで人間またはAIによる産出を記録します（6.6節参照）。文書系の出力も、ファイル属性または内部バージョン記録に同様の印を残します。これは「AIが大量にコンテンツを生成すること」と「そのコンテンツがなおガバナンス可能であること」の間の境界線です。
- 外部向け出力は必ず人間承認を経る — AI生成の契約修正、顧客提案、外部告知、財務数値は、送付前に必ず名前のある人間が確認します。研究開発のmergeはrevertできますが、送ったファイルは回収できません。この関門はコード側の関門以上に価値があります。
- 人間が最後の関門である — merge、送付、外部公開のいずれにおいても、AgentはPRを開き、文書を生成できますが、最終判断は人間が行う必要があります。変更導覽やリスクマーキングは人間のレビューを速くするためのものであり、レビューを置き換えるものではありません。
十、導入ロードマップ
第1段階：PoC（2〜4週間）
単一GPUノードにUbiGPTを導入し、会社のADに接続してSSOを完了します。3〜5名のシニアエンジニアがUbiCodeのDocker imageを取得すれば接続できます。PoCのためにクライアント側で誰かのローカル環境を変更する必要はありません。そのため、試して合わなければまとめて削除することも容易です。
目標は「AIが役に立つか」を検証することではありません。自社のcodebase上でモデルが実際にどのように動くか、スループットの上限がどれくらいかを測定することです。同時に、現行ソリューションの実際の月額支出とtoken使用量をbaselineとして確立します。
第2段階：試験導入（1〜2か月）
単一チーム、10〜20名程度へ拡張します。UbiCode WebUIを導入してsession管理とcode reviewを行い、最初のプロジェクトルールファイルを作成し、UbiGPTの部門別利用量統計を有効化します。
この段階の重点は、役割とモデルの対応を調整することです。実際の利用データに基づき、どの役割をより軽量なモデルへ下げられるか、どの役割は強化すべきかを見極めます。そして貴社に適したデフォルトのモデル組み合わせとして固定します。この段階で、実際の損益分岐点も見え始めます。
第3段階：展開
負荷テスト結果に応じて推論ノードを拡張し、UbiWorkを導入して非エンジニア職にも提供します。毎日のlog分析、週報、CI失敗時の自動修正などのスケジュールタスクを常態化します。この時点で、SLA、監視、モデル更新プロセスを正式化する必要があります。
ハードウェアに関する概念的な参考として、現在主流のオープンウェイトのコードモデル、MoEアーキテクチャを含むものでは、プレフィックスキャッシュを有効にした8 GPUノード1台で、通常は数十名のエンジニアの日常的なagenticトラフィックを支えられます。ただし、同時実行スループットはモデルサイズ、文脈長、タスクタイプに大きく依存します。必ず自社ワークロードで実測し、他社の数値をそのまま適用しないでください。
十一、よくある懸念
Q：自社運用モデルの能力は追いつくのか？
これは最もよくある質問であり、変化が最も速い質問でもあります。大規模なアーキテクチャリファクタリングのような最も難しいタスクでは、現在もトップ商用モデルに優位性があります。しかし差は縮まっており、その方向は一方向です。日常業務の大半、たとえば既存コードの理解、テスト補完、ファイル横断のリネーム、CIエラーに基づく修正、契約書の通読、レポート分析については、現在のオープンウェイトモデルで安定して対応できます。
役割化アーキテクチャは、この問題により精密な解法を与えます。能力差は主にOracleという役割に集中し、それ以外の役割は社内モデルで十分です。実務的にはハイブリッド導入が有効です。デフォルトではすべて社内モデルを利用し、指定された非機密プロジェクトでのみ、高階推論役割を外部プロバイダーへ放行します。これはUbiGPTのルーティングポリシーで集中管理し、各エンジニアが個別に決めるものではありません。
なお、この質問は半年ごとに再検討する価値があります。過去2年間のオープンウェイトモデルの進展速度を考えると、今日外部プロバイダーが必要な小さな部分も、来年には不要になる可能性があります。そのとき、アーキテクチャがすでに準備されており、ルーティング設定を一行変更するだけで済むことをありがたく思うでしょう。
Q：運用コストが節約分を食いつぶさないか？
一部は消費します。そのため試算時には、MLOps人員、データセンター、電力をすべて含める必要があります。だからこそ、小規模チームが無理にon-premiseへ進むべきではありません。損益分岐点は、おおむね利用量が安定し、継続的に成長する規模にあります。
Q：モデル更新はどうするのか？
これこそが「上位層は標準プロトコルだけを見る」設計の価値です。新モデルが出たら、stagingノードで自社の回帰テストセットを実行します。通過後、該当役割のモデルpresetを更新すればよく、ユーザー側の変更は不要です。
さらに役割化により、アップグレードは段階的に検証できます。まずExplorerのモデルだけを置き換えて1週間観察し、その後Fixerを置き換えるか判断できます。全体を一括で切り替えるよりリスクははるかに低くなります。内部のプログラミングタスク評価セットを維持することを推奨します。これはどの公開ランキングよりも実際のニーズを反映します。
Q：三層すべてを導入する必要があるのか？
必ずしもそうではありません。ただし、少なくともUbiGPTから始めることを推奨します。認証、キー管理、利用量ガバナンスは、すべての後続AIアプリケーションの共通基盤です。この層を正しく整備すれば、その後どのようなAIアプリケーションを追加しても、同じIDと監査の仕組みを利用できます。ツールを一つ追加するたびに、制御不能なAPI Keyが増える状況を避けられます。
結語
冒頭の線に戻ります。オープンウェイトモデルの能力がインターンから修士・博士級のフルタイム社員へと進化したとき、「自社運用は妥協である」という前提は成立しなくなります。能力面で妥協する必要がなくなれば、残る問題は一つだけです。このフルタイム社員を、誰のオフィスに座らせるのか。
On-Premise LLMは、コスト削減のための技術的後退ではありません。AIアシスタントを「外部サービス」から「内部基盤」へ変えるものです。推論、ID、Agent実行、協働インターフェースがすべて自社境界内に置かれることで、得られるものは四つあります。他社の条項に依存しないデータ主権、高頻度利用を罰しない予測可能なコスト曲線、モデルとツールチェーンの長期的な選択権、そして何より、チームが日々蓄積する専門的判断を、自社のモデル能力として本当に定着させられることです。それは他社の訓練データへ流れ込むものではありません。
UbiGPTは、モデルとIDガバナンスを社内ネットワークにしっかりと置きます。UbiCodeは、AIアシスタントを「万能だが高価な何でも屋」から、明確に分業され、それぞれに適したモデルを割り当てられたAIチームへ変えます。そしてエンジニアとTech Leadに、それぞれ最も使いやすいインターフェースを提供します。UbiWorkは、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
