導入のご相談InfiniCloud® AIの
アーキテクチャ
InfiniCloud® AIは、企業の持つ知識や情報を「知恵」として学習可能にする国産プライベートAI基盤です。最小構成から導入できるアーキテクチャにより、大規模なパブリックAIでは扱えない局所的な課題を高精度に推論します。
知識は完全に隔離された環境で保存・運用され、外部AIとは接続しません。ランゲージモデルを中核に、データパイプライン、RAG／Fine-Tuneエンジン、OpenAI互換APIを統合し、実験ではなくプロダクション環境として動くことを前提に設計されています。
| 正規化 入力を統一形式へ正規化する | MHAS 文書を意味の通った断片へ分解する | RAG 必要な断片だけを検索して注入する | AutoDGIS → LoRA 頻出知識を学習可能な形へ変換し、モデルへ定着させる |
知識を「取り込む」「探す」「育てる」パイプライン
AIは、企業内の文書やWeb情報を検索して貼り付けるだけのAIではありません。文書を構造的に分解し、必要な知識だけを取り出し、継続的に使われる知識は学習データへ変換して定着させます。
正規化レイヤ
企業内の知識は、HTML・PDF・Word・画像・表・手順書と形式が揃っていないのが普通です。InfiniCloud® AIは、これらをそのまま扱うのではなく、まず共通的に処理しやすい形式へ正規化します。後続の分解・検索・学習を、入力形式に依存しない形で統一できます。
| 文書形式の違いを吸収しやすい | テキスト以外の入力も知識化しやすい | 後続処理を一貫したパイプラインで扱える |
MHAS ─ 文書を意味の通った断片へ分解する
Markdown-aware Hierarchical Adaptive Separation
文書を一定長で機械的に切り分けません。HTMLや文書の階層構造を見ながら、小さくても意味が通る断片へ分解します。見出し・リスト・表・注釈・リンク・深いネストを無視して切ると、断片が巨大になったり、同じ内容が重複したり、逆に文脈が失われます。MHASはこの問題を抑えます。
MHASの狙い
- 文書構造を保ちながら断片化する
- 重複を減らし、検索精度を下げにくくする
- 小さなチャンクでも意味のある知識単位にする
- RAGと学習データ生成の両方に使いやすくする
MHASが効く場面
- 深い見出し構造を持つマニュアル
- リストや表が多い技術文書
- ナビゲーションやテンプレートが混ざるWebページ
- 巨大なHTMLや複雑な社内文書
RAG ─ 必要な知識だけを取り出す
断片化された知識は、対話時に必要なものだけがモデルへ注入されます。最初から大きなコンテキストに全部入れるのではなく、必要な情報を必要な分だけ渡す設計です。コンテキストの浪費を抑えられるため、少ないコンテキストでもTop-kのkを増やせることを意味します。
| 質問に応じて関連知識を検索する | 必要断片のみを対話に注入する |
| 大量文書の中から局所的に知識を呼び出す | モデルに持たせなくてよい知識を外部化する |
AutoDGIS ─ 知識断片を学習用データへ変換する
Auto Document-Grounded Instruction Synthesis
RAGは有効ですが、何度も参照される安定知識まで毎回検索に頼るのは効率的とは限りません。AutoDGISは、文書断片から学習用データを自動生成します。文書をそのまま学習させるのではなくタスク形式へ変換するため、本文学習で起きやすい短答化や会話崩れを抑えられます。
| QA 文書知識を問答形式へ変換 | Extract 長文から重要記述を抽出 |
| Decompose 単一回答を段階的説明へ分解 | Decision 条件分岐を伴う判断問題へ変換 |
LoRA ─ 安定知識をモデルへ薄く定着させる
すべての知識をモデルへ埋め込むのではなく、RAGとLoRAを役割分担させます。この分離により、巨大なモデル再学習を行わずに、ドメイン単位で知識の再現性を高められます。AutoDGISは、このLoRAに適した学習データを自動生成する層として機能します。
RAG
必要時に検索して想起する知識。追加・更新が即時反映され、出典を明示できます。規程・手順書・頻繁に変わる情報に向きます。
LoRA
安定して使う知識を薄く定着させる手段。判断基準・文体・業務文脈がモデル側に反映されます。組織固有の暗黙知に向きます。
小コンテキスト最適化という設計思想
大きなコンテキストを持つモデルは便利ですが、プライベート運用では推論コスト・遅延・電力消費・ハードウェア制約が現実的な制約になります。
InfiniCloud® AIはコンテキストを無制限に増やすのではなく、知識を細かく整える／必要なものだけ探す／安定知識は定着させるという設計で、限られた資源でも実用性能を維持します。
この設計の利点
- ローカルLLMや私設環境に向く
- 推論コストを抑えやすい
- ドメイン特化を進めやすい
- 分散環境でも運用しやすい
中核技術
MHAS
文書構造を保ちながら、検索や学習に適した小さな知識断片へ変換する技術。
AutoDGIS
文書断片を、質問応答・抽出・分解・判断といった学習可能なタスクへ自動変換する技術。これらにより、単なる文書検索型AIではなく、知識を整え、探し、育てるためのPrivate AI基盤を実現しています。
※ MHASおよびAutoDGISの詳細な設計思想・方式については、別途テクニカルノートで公開予定です。
ハーネス・エンジニアリング
良いモデルを選べば良いAgentになる、わけではありません。LLMをAgentとして機能させるには、行動を制御する周辺基盤が不可欠です。
| ツール接続 外部APIや社内システムを呼び出す | 権限制御 誰が何をできるかを制御する |
| 出力検証 生成結果の正確性をチェックする | 自動リトライ 失敗時に自動で再試行する |
| 監査 誰が何をしたかを記録する | 状態管理 タスクの進捗を追跡・管理する |
AI Agentを動かす端末そのものが、リスクになりうる
オペレータ端末上のAIツールが社内DBを読み、外部のAIサービスへ内容を送信する構成では、ファイアウォールの内側にある機密データが域外サーバーへ渡ります。個人情報の越境移転、AIの判断によるDB書き込みの責任、事業者側でのデータ保持──いずれも運用ルールでは塞ぎきれません。InfiniCloud® AIは、Agentそのものを社内の統制下に置くことで、この論点を発生させません。必要な場合のみ、Web検索によるエビデンス確認だけを許可できます。
知能ドメイン単位で知識を扱う
知識の検索範囲とLoRAの適用範囲を、知能ドメイン単位で整理できます。全文書をひとつの塊として扱わず、必要な単位で分けて運用することで、精度・安全性・保守性を高められます。
- ユーザー / グループ / ロール（RBAC）─ 誰がどのドメインを使えるかを一元管理
- 共通基盤 ─ LLMプール / 管理UI / 監査ログ / マルチテナント制御
Private AIとローカルLLMの違い
LLMはランゲージモデルであり、重みの集合データです。LLMエンジンで動かすだけでできるのは、クエリに対する回答（APIで言えばcompletions）程度です。
ローカルLLMを立ち上げて「思ったより使えない」と感じるのは、この差によるものです。クラウド型のPublic AIは、データを運び、処理し、必要なロジックを持ち、LLMを1つのパーツとして動かすデータパイプラインを備えています。またLLMも1つではなく、目的ごとに異なるサブモデルを持っています。InfiniCloud® AIも同様に、複数のウェイトモデル（LLM／SLM／VLM）と、独自ツールチェイン、MCPを用いたサーバサイドツールチェインを備えています。パイプラインの中でモデルは使い分けられ、近傍検索・問題の分割・ツールへの振り分け・会話のライティングをそれぞれが担います。
公開用のサービスサポートエージェントを作るなら、さらに負荷分散・リソース制御・Web技術・コンテナ隔離・ハイパーバイザー技術の統合が必要になります。InfiniCloud® AIはこれらにも対応しています。
ベースモデルの考え方
ウェイトモデルは重みの集合データにすぎません。そこに手足と中枢を組み込むことでAIが形になります。とはいえLLMは、AIを構成する最も重要な部品でもあります。
オープンモデルへのリスペクトとTransfer Learning
InfiniCloud® AIは、乱数から事前学習した独自LLMを使っているわけではありません。作り上げられたベースモデルを最大限リスペクトし、それを起点にTransfer Learningを行う手法を採っています。ライティングを担うベースLLMには、OpenAI社のGPT OSS、Alibaba社のQwen、東京科学大学のSwallowなどのオープンランゲージモデルを用い、日本のビジネス慣習に沿うようファインチューンしています。
複数モデルの併用と継続更新
内部では1つのLLMだけでなく、画像解析・音声解析など用途に特化したモデルが同時に動作します。小型モデルはベースモデルのまま使われる場合もあります。新しいベースランゲージモデルが登場するたびにTransfer Learningを行い、アップデートしていく方針です。ベースモデルが更新されても、パイプラインに蓄えた知識とLoRA差分を引き継いで移行できます。
知識を「取り込む」「探す」「育てる」ためのアーキテクチャ
InfiniCloud AI は、企業内の文書やWeb情報を単に検索して貼り付けるだけのAIではありません。
文書を構造的に分解し、必要な知識だけを取り出し、さらに継続利用される知識は学習用データへ変換して定着させることで、小さなコンテキストでも実用性を維持しやすい設計を採っています。
このアーキテクチャは、主に以下の4つで構成されます。
- 入力を統一形式へ正規化する
- 文書を意味の通った断片へ分解する
- 必要な断片だけを検索して注入する
- 頻出知識を学習可能な形へ変換し、モデルへ定着させる
InfiniCloud AI では、入力された文書をまず正規化し、その後 MHAS により知識断片へ変換します。
その断片はRAG検索に利用されるだけでなく、AutoDGIS により学習用データへ再構成され、LoRA による知識定着にも利用されます。
正規化レイヤ
企業内の知識は、HTML、PDF、Word、画像、表、手順書など、形式が揃っていないことが一般的です。
InfiniCloud AI では、こうした異なる入力をそのまま扱うのではなく、まず共通的に処理しやすい形式へ正規化します。
これにより、後続の知識分解・検索・学習処理を、入力形式に依存しにくい形で統一できます。
特徴
- 文書形式の違いを吸収しやすい
- テキスト以外の入力も知識化しやすい
- 後続処理を一貫したパイプラインで扱える
MHAS: 文書を意味の通った断片へ分解する
InfiniCloud AI では、文書を単純に一定長で切り分けません。
独自の MHAS（Markdown-aware Hierarchical Adaptive Separation） により、HTMLや文書の階層構造を見ながら、小さくても意味が通る断片へ分解します。
文書には、見出し、リスト、表、注釈、リンク、深いネスト構造が含まれます。こうした構造を無視して切ると、断片が巨大になったり、同じ内容が重複したり、逆に文脈が失われたりします。MHAS はこの問題を抑えます。
MHAS の狙い
- 文書構造を保ちながら断片化する
- 重複を減らし、検索精度を下げにくくする
- 小さなチャンクでも意味のある知識単位にする
- RAGと学習データ生成の両方に使いやすくする
MHAS が効く場面
- 深い見出し構造を持つマニュアル
- リストや表が多い技術文書
- ナビゲーションやテンプレートが混ざるWebページ
- 巨大なHTMLや複雑な社内文書
RAG: 必要な知識だけを取り出す
断片化された知識は、RAG（Retrieval-Augmented Generation）によって検索され、対話時に必要なものだけがモデルへ注入されます。
InfiniCloud AI の考え方は、最初から大きなコンテキストに全部入れるのではなく、必要な情報を必要な分だけ渡すことです。この設計により、コンテキストの浪費を抑えつつ、知識探索の精度を高めやすくなります。具体的には、少ないコンテキストでもTop-kのkの数を増やすことができることを意味します。
RAG の役割
- 質問に応じて関連知識を検索する
- 必要断片のみを対話に注入する
- 大量文書の中から局所的に知識を呼び出す
- モデルに持たせなくてもよい知識を外部化する
AutoDGIS: 知識断片を学習用データへ変換する
RAGは有効ですが、何度も参照される安定知識まで毎回検索に頼るのは効率的とは限りません。
そこで InfiniCloud AI では、独自の AutoDGIS（Auto Document-Grounded Instruction Synthesis） を用いて、文書断片から学習用データを自動生成します。
AutoDGIS は、文書をそのまま学習させるのではなく、質問応答・抽出・分解・判断といったタスク形式へ変換します。これにより、単なる本文学習で起きやすい短答化や会話崩れを抑えつつ、知識をより実用的な形でモデルへ渡せます。
AutoDGIS の役割
- 文書知識を学習しやすい形式へ変換する
- 会話や判断に使える教師データを生成する
- 頻出知識や安定知識の定着を助ける
- RAGとLoRAの橋渡しを行う
生成される代表的なタスク
- QA: 文書知識を問答形式へ変換
- Extract: 長文から重要記述を抽出
- Decompose: 単一回答を段階的説明へ分解
- Decision: 条件分岐を伴う判断問題へ変換
LoRA: 安定知識をモデルへ薄く定着させる
InfiniCloud AI では、すべての知識をモデルへ埋め込むのではなく、RAGとLoRAを役割分担させます。
- RAG は「必要時に検索して想起する知識」
- LoRA は「安定して使う知識を薄く定着させる手段」
この分離により、巨大なモデル再学習を行わずに、ドメイン単位で知識の再現性を高めやすくなります。
AutoDGIS は、この LoRA に適した学習データを自動生成する層として機能します。
小コンテキスト最適化という考え方
InfiniCloud AI の重要な設計思想のひとつが、小コンテキスト最適化です。
大きなコンテキストを持つモデルは便利ですが、ローカル環境やプライベート運用では、推論コスト・遅延・電力消費・ハードウェア制約が現実的な制約になります。そのため InfiniCloud AI は、コンテキストを無制限に増やすのではなく、
- 知識を細かく整える
- 必要なものだけ探す
- 安定知識は定着させる
という設計で、限られた資源でも実用性能を維持しやすくしています。
この設計の利点
- ローカルLLMや私設環境に向く
- 推論コストを抑えやすい
- ドメイン特化を進めやすい
- 分散環境でも運用しやすい
知能ドメイン単位で知識を扱う
InfiniCloud AI は、知識の検索範囲やLoRAの適用範囲を、知能ドメイン単位で整理できます。これにより、部署・用途・業務・顧客ごとに知識の境界を持たせやすくなります。
知識を全部ひとつの塊として扱うのではなく、必要な単位で分けて運用することで、精度・安全性・保守性を高めやすくなります。
InfiniCloud AI の中核技術
InfiniCloud AI の知識基盤は、以下の独自技術に支えられています。
- MHAS
- 文書構造を保ちながら、検索や学習に適した小さな知識断片へ変換する技術。
- AutoDGIS
- 文書断片を、質問応答・抽出・分解・判断といった学習可能なタスクへ自動変換する技術。
これらにより、InfiniCloud AI は、単なる文書検索型AIではなく、知識を整え、探し、育てるためのPrivate AI基盤を実現します。
技術詳細について
MHAS および AutoDGIS の詳細な設計思想や方式については、別途テクニカルノートで公開予定です。
- MHAS: Markdown-aware Hierarchical Adaptive Separation
- AutoDGIS: Auto Document-Grounded Instruction Synthesis
Private AIとローカルLLMとの違い
LLMはランゲージモデルであり重みの集合データです。それを動かすためにLLMエンジンがあり、ローカルLLMを簡単に体験し、利用することができます。LLMとLLMエンジンだけでできることはクエリに対しての回答(APIで言えばcompletions)ぐらいなので、ローカルLLMを立ち上げても「思ったよりも使えないな？」と感じた方も多いでしょう。
一般的なクラウド型の「Public AI」は、データを運び、処理し、必要なロジックをもち、LLMを1つのパーツとして動かす為の、データパイプラインを持っています。またLLMも1つではなく、目的毎に異なるサブLLMを持っています。
InfiniCloud AIも同じように、複数のウェイトモデル(LLM/SLM/VLMなど)を持ち、独自のツールチェインと、MCPを用いたサーバサイドツールチェインを投入させることができます。
データパイプラインの中で、これらのウェイトモデル(LLM/SLM/VLMなど) は使い分けられ、データパイプラインを持ち、近傍を検索したり、複雑な問題を分割したり、ツールチェインに割り振ったり、会話を担当するライティングするLLMがいたりします。
また、特定分野(ドメイン)向けの知識を知恵に昇華させるため「ファインチューン(Fine Tune)」を行い、特定分野に特化したモデルに徐々に変容していきます。これは、Public AIにも難しい機能です。
あなたがもし、公開用の自社サービスサポートエージェントを作りたいなら、さらに負荷分散、リソース制御技術、Web技術、コンテナ隔離技術、ハイパーバイザー技術などを統合する必要があります。InfiniCloud AIはこれらの技術にも対応しています。
InfiniCloud AIは、「プロダクション」として「動く」ことに徹底的に拘り、実験ではなく「使える」Private AIエンジンなのです。
InfiniCloud AIでのウェイトモデル(LLM,VLMなど)の考え方
LLMやVLMなどのウェイトモデルは「重みの集合データ」で過ぎず「夢想する電子の脳」でしかありません。ここに手足や中枢が組み込まれていき、AIを作りあげられていきます。
しかしながら、LLMはAIを構成する最も重要なパーツであることも間違いありません。しかし残念ながら、現在のInfiniCloudのLLMは「乱数からプリ・トレーニングした純国産LLM」ではありません。ですから、InfiniCloud AIではLLMのベースモデルを、「作りあげられたopus」として最大限リスペクトし、これをベースにTransfer Learningする手法を採っています。
ライティングに使っているベースLLMは、OpenAI社のGPT OSSや、Alibaba社Qwen、東京科学大学のSwallowなど、オープンランゲージモデルを元に、InfiniCloudがTransfer Learningを行い、日本の社会人常識を備えるようにファインチューンされたLLMです(※)。このInfiniCloud LLMは、ランゲージモデルとして新しいベースランゲージモデルが出る度に、Transfer Learningを行い、アップデートされる予定です。
InfiniCloud AIの中には、実際には1つのLLMだけでなく、複数のLLMが動作しています。特定用途向けのLLMとして画像の解析や、音声の解析、その他、用途に特化したLLMも搭載しており、小型モデルはベースモデルのまま使われていることもあります。
※ ただし、残念ながら今現在のモデルは、データセット量がすくなく、ベースモデルから大きな違いはありません。
あなたの会社に入社したInfiniCloud AIは、あなたの会社がもつ情報で育ち、あなたの会社の従業員となり、ファインチューニングされ、いずれはエキスパートとなるでしょう。
そしてInfiniCloud LLMのベースモデルがアップデートされると、InfiniCloud AIのパイプラインから蓄えた記憶を引き継ぎ、新しいInfiniCloud AIに生まれ変わることもできます。
LLM-as-a-Serviceを実行するエンジン
LLMaaSを実現するスタックInfiniCloud AIは、LLM-as-a-Serviceを実現するために作られたオーケストレーション層です。
AIが、あなたの会社の中で学び、育つ。それがInfiniCloud® AIです。
社内ドキュメントから育てたドメイン特化AIを、OpenAI互換のAPIでそのまま呼び出せます。completions互換で既存エンジンに組み込みやすく、さらにassistants／responses対応で、次世代アプリにも柔軟に統合できます。
RAGやファインチューニングで育てたAIは、あなたの業務知識を白糸のように編み込み、Public AIにはない「組織固有の知恵」を返す存在に。
秘匿情報を安全に扱いながら、自社アプリやSaaSと連携し、AIサポートや社内自動化を思いのままに。
InfiniCloud AI ── Private LLMaaSの、開発者にやさしい進化形。
継続的拡張
昨今の進化の速いAI業界においても、ランゲージモデルの置き換えや、ミドルウェアのアップデートにも対応。InfiniCloud AIの根幹を担うソフトウェア「Shiraito」自体も継続的なアップデートが行われます。
