リョーワが実践する「AIオーケストレーション開発」の中身
はじめに ― なぜ「1体」ではなく「96体」なのか
世間でいう「AIに開発させる」は、たいてい1体のAIにチャットで指示を出すスタイルです。これはこれで便利ですが、複雑なシステムを作ろうとすると一気に破綻します。指示が長くなる、文脈が混ざる、品質がブレる。人間が1人で要件定義から設計・実装・テスト・レビューまですべて抱えるのと同じ、構造的な無理があります。
リョーワのR-VISION AI事業部では、ここを根本から変えました。「1体の万能AI」ではなく「96体の専門エージェントが分業して同時並行で動くチーム」 として開発を回しています。人間の開発組織をそのままAI上に再現したイメージです。これが今回お伝えしたい先進性の核心です。
1. そもそも「エージェント」とは何か ― チャットとの決定的な違い
経営者目線でまず押さえていただきたいのは、「エージェント」＝「目的を渡せば自分で考えて手を動かし続ける存在」 という点です。
| 従来のAIチャット | AIエージェント | |
|---|---|---|
| 指示の粒度 | 1問1答 | 「この機能を完成させて」レベルの目標 |
| 動作 | 答えを返して終わり | 計画→実行→検証→修正を自走 |
| ツール利用 | 基本なし | ファイル編集・コマンド実行・検索を自分で使う |
| 人間の役割 | 都度指示 | 方針提示と承認(レビュー) |
チャットが「優秀な相談相手」だとすれば、エージェントは「タスクを任せられる部下」です。この違いがあるからこそ、複数体を束ねる意味が生まれます。
2. 96エージェントの全体像 ― 役割で階層化する
96体をバラバラに動かしているわけではありません。人間の開発会社と同じ「組織構造」 を持たせているのが要点です。大きく4つの層に分かれます。
① オーケストレーター層(指揮系統)
全体を統括する司令塔。経営でいう「プロジェクト責任者」にあたります。 ユーザーの要求を受け取り、タスクを分解し、どの専門エージェントに振るかを判断します。リョーワが特許化した クエリ分解・専門LLM割当の仕組み(TaskOrch) がここで効いてきます。要求を適切な単位に割り、最適な担当に配る頭脳です。
② 設計・アーキテクト層
システム設計、API設計、データモデリング、技術選定(ADR作成)を担います。 「Kafkaか、それともマネージドキューか」といった技術判断を、トレードオフを並べて文書化してから動く。後から「なぜこの構成にしたのか」を追える状態を作る層です。
③ 実装・専門職層(ここが頭数の大半)
実際に手を動かす職人集団。さらに専門が細分化されています。
- バックエンド実装(Go / Node.js)
- フロントエンド実装(React / HTML・Canvas)
- データ層(PostgreSQL・pgvector / Qdrant / BigQuery)
- インフラ・デプロイ(GCP / Cloud Run の環境分離)
- AIプロバイダ連携(Claude / Gemini / Ollama の振り分け)
R-VISIONの製品では、ここで 機密レベルに応じてLLMを振り分ける仕組み(DynScope) が動きます。社外に出してはいけない情報はローカルLLM(Qwen3など)、一般的な処理はクラウドの高性能モデル、と自動で経路を変える。セキュリティと性能を両立させる肝の部分です。
④ 品質・検証層(ここが差別化の本丸)
作ったものを誰が信用するのか、という問いに答える層です。
- コードレビュー(セキュリティ・性能・N+1・例外処理の穴を点検)
- テスト戦略・テスト実装
- デバッグ(再現→切り分け→診断→修正)
- そして、ハルシネーション抑制エージェント
最後のものが最も重要です。リョーワの 特許第7691787号(LLMのハルシネーション抑制) をエージェント化したもので、他のエージェントが出した成果物を「根拠があるか」「事実と整合しているか」で検証します。AIの出力をAIが審査する 構造を、特許技術として正式に保有しているのが強みです。さらに 信頼度を層分離して出力する仕組み(TrustLayer) により、「これは確実」「これは要確認」を明示します。
3. 実際の開発はどう流れるのか ― 1つの機能ができるまで
四国計測工業様向けの「AI自動査定エージェント」を例にすると、流れは次のようになります。
[要求] 「査定ロジックを a→d→b→c の順で判定して書き戻したい」
↓
① オーケストレーター: 要求を5つのサブタスクに分解
↓
② アーキテクト層: 2段階査定アーキテクチャを設計、ADR作成
↓ (判定フラグ A/B/C/D、ステータス 10/20/30 を定義)
③ 実装層が並行作業:
├ Goバックエンド担当 → 判定ロジック実装
├ データ層担当 → BigQueryスキーマ・JustDB書き戻し
└ LLM連携担当 → Vertex AI経由のモデル振り分け
↓
④ 品質層:
├ コードレビュー → 抜け漏れ指摘
├ テスト → 境界値で検証
└ ハルシネーション抑制 → 査定根拠の整合性チェック
↓
[人間] 顧客・社内で承認 → リリースポイントは ③が同時並行で走る ことです。人間1人なら直列でしかできない作業を、専門エージェントが並列でこなす。だから速い。そして ④で必ず品質ゲートを通す ため、速いだけで雑にならない。
4. 経営者が注目すべき3つの価値
① スピードと品質の両立(トレードオフの解消)
通常、「速さ」と「品質」はトレードオフの関係にあります。しかし分業×並列×品質ゲートの構造にすると、速度を上げながら品質も上げられる。属人化した「あの人にしか作れない」も解消されます。
② 「説明できるAI開発」という資産
なぜこの設計にしたか(ADR)、どこで品質を担保したか(レビュー・テスト記録)がすべて残ります。顧客監査や補助金審査、特許まわりの説明責任に対して、プロセスそのものが証拠になる。製造業のお客様を相手にする場面では、この「トレーサビリティ」が効いてきます。
③ 特許に裏打ちされた信頼性
ハルシネーション抑制(7691787)を中心に、TaskOrch・DynScope・TrustLayer・CARI といった特許ポートフォリオが、それぞれエージェントとして実装に組み込まれています。「自社のAIは信頼できます」を、概念ではなく特許という形で証明できる ことは、提案の場で他社が真似できない差別化になります。
おわりに ― AIに「させる」から、AIチームを「経営する」へ
96エージェント開発の本質は、技術自慢ではありません。開発という仕事を、AIの組織に対する「経営」として捉え直した ことにあります。人間は指示係から、方針を決めて承認する「経営側」へ回る。
リョーワが目指しているのは、この仕組みを製造業のお客様にそのまま届けることです。視覚検査、遠隔保守、知識管理 ― どの現場でも「速くて、説明できて、信頼できるAI」が必要とされます。その答えが、この96エージェントによるオーケストレーション開発だと考えています。
コメント