AiGen-One — AIを「個人のツール」から「会社の業務」に変える、エンタープライズLLMプラットフォーム
いま、どのチームにもAIがあります。こっちにChatGPT、あっちにGemini、誰かのブラウザには個別のエージェント。個人は確かに速くなった。でも会社は、なぜか速くなっていないんです。
時間がどこに消えているかをよく見ると、AIの処理そのものではないことが多い。結果を次のツールへ手で転記する。ファイルを手で移動する。そして「どのデータをどのAIに入れていいか」を、誰かがその場の判断で決めている。
公開のLLMサービスには、もう1枚の壁があります。AIを本当に役立たせる書類——契約書、社内仕様書、顧客情報——は、まさに公開チャットに貼れないものだからです。
AIは動いている。業務がつながっていない。このプラットフォームが埋めに行ったのは、その溝です。
僕たちはクライアントのシステムを作る会社です。そしてAIの時代になって、はっきりしてきたことがあります。「作れます」は、もう以前ほどの差別化ではない。コード生成が「作れること」を安くしたからです。残るのは、作ったものの周りにあるものでした。
会社に本当に必要なのは、AIの能力が蓄積されていく場所です。業務システム、データ接続、権限、運用の知見——プロジェクトのたびに消えるのではなく、積み上がっていく場所。それを僕たちは、自分たちで作ることにしました。ホーチミンの自社エンジニアリングチームで、社内開発として。提案資料のためのデモではなく、今日プラグインが実際に動いていて、クライアント向けと同じ作法——Git、レビュー、マイグレーション、監査——で作られたプラットフォームです。
AiGen-Oneは、業務アプリの生成ツールとして始まりました。そこから広がって、1つの基盤の上に3種類の能力を載せるものになりました。スクラッチ開発する業務システム。チームをまたいで再利用できるAIスキル。そして、人の確認を挟みながら複数工程を回すエージェントです。
その全体を支えるのが、4層のコントロールプレーンです。人が入ってくるPortal。共通の文脈を持たせるProjects。実行を担うSkills・Agents・Plugins。そしてデータベース・API・本番システムが属するCustom Appsの層。設計の力点は、層と層の「接続部」に置きました。エンタープライズAIが壊れるのは、たいていそこだからです。
正直に言うと、モデルは簡単なほうでした。難しかったことのほとんどは、その周りにあります。誰が何を接続していいのか。変更はどうやって本番に届くのか。そして後から、何を証明できるのか。
最初の画面はAI機能ではありません。会社の仕事です。管理者からのお知らせ、社内掲示、今日の予定、承認待ち、最近使った業務。AIチャットはその画面の中に置きました。「別のAIツールを開くのを覚えておいてもらう」設計は、まず使われません。だからAIは、1日の始まりの場所に住まわせています。
どの会社にも、プロンプトが異様にうまい人が1人います。そしてそのノウハウは、たいていチャットログの中で死んでいく。AiGen-Oneでは、プロンプトをSkillとしてパッケージします。何をするか、指示文、動作確認、呼び出し例。「良い使い方を説明して広げる」が「呼び出せる機能を配布する」に変わります。汎用性の高い機能はプラグインとして業務メニューに配ります——提案書生成、仕様書生成、Gmail問い合わせ対応、多言語チャットなど、今日7本が動いています。
エージェントは、Skill・プラグイン・API・MCP接続・データベース操作をつないで、実際の作業フローにします。設計ルールはシンプルです。どの工程にも「実行前に人の確認を要求できる」こと。判断のために立ち止まれない自動化に、業務は預けられません。
接続——API・MCP・OAuth・Git・データベース——は個人のトークンに散らばらせず、1か所で管理します。変更はAIレビュー、エンジニアレビュー、マイグレーション管理を通ってから本番に届き、すべての操作が監査ログに残る。スクラッチ開発したシステムも同じ流れで出荷します。生成コード、Git、プルリクエスト、マイグレーション、リリース。最初の一筆を書いたのが人でもAIでも、パイプラインは1本です。
プロンプト研修も、別のAIツールもありません。お知らせや承認で毎日開いているポータルから、チャットでSkillやAgentを呼ぶだけ。この提案書を下書きして、このスレッドを要約して、このチェックを回して。専門知はSkillの中に詰めてあるので、品質が「誰が聞くか」に依存しないんです。
利用状況・権限・プロジェクトが1つの画面に揃います。どのチームが何を使っているか、何が承認待ちか、実際に使われているのは何か。うまくいったパターンは、噂で広がるのを待たずに、業務メニューへ配って意図的に展開できます。
新しいモデルも、外部連携も、スクラッチ開発も、運用改善も、全部同じ基盤の上に積まれます。「また1つ、つながらないツールが増える」にならない。コードは人が書いてもAIが書いても、Git・プルリクエスト・マイグレーション管理・監査を通って出荷されます。エンジニアリング組織にとってこれは、蒸発するプロジェクトと、複利で積み上がる能力の分かれ目なんです。
| Before | After | ||
|---|---|---|---|
| AIの居場所 | 個人アカウントとブラウザのタブの中 | → | 1日が始まる場所——会社のポータル |
| 良いプロンプト | 1人のノウハウ。チャットログに埋まる | → | Skill——パッケージ済み・検証済み・誰でも呼べる |
| 複数工程の仕事 | ツール間のコピペを、人が手で | → | 流れはAgentが回し、関所は人が締める |
| 統制と監査 | 「誰が何を使った？」に答えがない | → | 権限・レビュー・全操作の監査ログ |
AiGen-Oneはいま、リノエッジ社内で動いています。提案書生成から多言語チャットまで、稼働中のプラグインは7本。入口・Skill・Agent・ガバナンスが揃い、企業がPoCを始められる段階まで来ました。それが今の、正直な現在地です。
リノエッジ
プラットフォームの設計・構築・運用 — ホーチミン
使えます。鍵は、モデルへのアクセスを自社の環境の内側に置き、外に出るものを管理することです。AiGen-Oneでは、ドキュメントは会社のナレッジベースに留まり、検索（RAG）は自社データに対して走ります。LLM本体を含む外部接続はすべて、管理された認証情報・権限・監査ログを通ります。社員は個人アカウントではなく会社のポータルから使うので、社内文書を公開チャットに貼る必要がそもそもなくなります。
4つの層です。お知らせ・タスク・AIチャットが同居する「入口」（ポータル）。ドキュメント・ナレッジ・課題を束ねる「文脈」の層（プロジェクト）。実際に仕事をする「実行」の層（Skill・Agent・プラグイン）。そしてデータベース・API・権限・監査・本番運用の「企業システム」の層。価値はこの4層がつながっていることにあります。止まっているAI活用の多くは、実行の層しか持っていないんです。
ほとんどの場合、RAGからです。AiGen-Oneを設計したとき、社内ナレッジにはファインチューニングではなく検索（RAG）を選びました。基盤は約1週間で立ち上がり、元のドキュメントは後から確認でき、知識の更新に再学習が要らないからです。ファインチューニングは、パターンの安定した狭い大量タスクが見えてから検討する話で、最初の一歩ではありません。
「モデルが行儀よくしてくれること」には頼らず、チェックポイントを設計で入れます。AiGen-Oneのエージェントは明示的な工程の連なりでできていて、どの工程にも実行前の人の確認を要求できます。システム変更は人が書いたコードと同じ関所——エンジニアレビュー・Git・マイグレーション管理——を通り、すべての操作が監査ログに残ります。「AIが何かしたが追跡できない」という事故を防ぐために、ガバナンス層の全体があります。
自社ドキュメントの上に非公開のRAG基盤を立ち上げるまでが、約1週間です。その先は正直なところ「最初に回したい業務による」が答えになります。業務アプリとそのデータ接続・承認工程は、本物のエンジニアリングだからです。だからロールアウトは段階制にしています。まず入口、次に1業務、それから再利用、最後に全社標準です。
不要です。これは願望ではなく設計判断です。良いプロンプトはSkillとしてパッケージされます——目的・指示文・検証済みの呼び出し例を持つ、名前のついた機能です。誰でもチャットから呼べます。上手な人は自分のノウハウを一度だけ資産化すればよくて、会議で説明し続ける必要がなくなります。
合いません。必要なのがWebサイトのチャットボット1つなら、プラットフォームは過剰です。スコープを絞った個別開発のほうが安くて速い。この形が合うのは、AIの用途がすでに複数あり、データガバナンスの制約が現実にあり、AIが触るべき社内システムを持っている会社です。まだそこにいないなら、小さく始めるほうがいい。プラットフォームの話は後からでも間に合います。