AI Innovators Circle 第7回｜AI導入企業の88%が直面する「成果の壁」③
※このレポートは音声データを元にAIエージェントがライティングを行っております。
RAGの限界から、人を活かすAIへ――本番導入を支える技術と組織の条件
「AI Innovators Circle」第7回の最終セッションでは、「今後のAI技術の要所とDevRevの魅力」をテーマに、技術者によるパネルディスカッションが行われた。
登壇したのは、一般社団法人沖縄オープンラボラトリ理事の山崎里仁氏、クラスメソッド株式会社の越井琢巳氏、DevRevでソリューションエンジニアリングを担当する中嶋大輔氏。モデレーターはSynthesyのパートナーCTEO、白藤記央が務めた。
山崎氏は、クラウドコンピューティングやSDN、通信事業者の情報活用システムなどに長年関わってきた。先端技術を日本・東アジア市場で実用化し、活用できる人材を育成する立場から議論に参加した。
越井氏は、ゲーム会社でデバッグ関連の開発を経験した後、クラスメソッドへ入社。同社の技術ブログへ200本を超える記事を寄稿し、現在はClaude Codeなどを使った開発にも取り組んでいる。
中嶋氏は、HPE、Juniper Networksなどでネットワークエンジニアを務め、L7ロードバランサーやエッジコンピューティングの分野でも経験を積んだ。AIを企業ネットワークや業務データへ安全に接続する課題を追う中でDevRevへ参画したという。
技術の現場を知る登壇者が、RAG、マルチエージェント、セキュリティ、暗黙知の継承について率直に語った。
「失敗率95％」が示すもの
白藤は冒頭、エンタープライズ向け生成AI導入の多くが期待する成果へ至っていないという調査を紹介した。当日は「失敗率95％」という数字が示されたが、調査によって失敗の定義や対象が異なる点にも注意が必要だと補足した。
課題は大きく四つに整理された。
一つ目は、品質、サイロ化、レガシーシステムなどのデータ問題。二つ目は、ROIの不透明さ。三つ目は、ガバナンスとセキュリティ。四つ目は、スキル不足や変化への抵抗を含む組織の問題である。
この整理を起点に、議論は「なぜAI導入では、モデル以上にデータと組織が重要なのか」という問いへ進んだ。
ビッグデータ時代から残る「データの目利き」
口火を切った山崎氏は、AIの回答品質が、与えるデータに強く左右されることを端的に表現した。
「今のほとんどのAIは、ゴミを食べさせちゃうと、ゴミを吐いちゃうんですよね」
企業が現在「AIネイティブ化」と呼んでいる取り組みは、ビッグデータ時代に目指していたことと本質的には大きく変わらないと山崎氏は指摘した。
社内の情報を集め、分析し、意思決定へ活用する。しかし、当時も現在も、古い文書、重複ファイル、更新されていないルール、誤った記録が大量に存在する。
AIへデータを投入する前に、どの情報が有効で、どれがノイズなのかを判断しなければならない。
「僕はDevRevはAIの会社というよりは、データを整理することに関するスペシャリティな技術の会社だと思うんですよね」
AIモデルが高度化するほど、データの整理、関係付け、更新、権限管理の重要性が増す。モデルの能力に依存し、あらゆるデータを投入すれば何とかなるという発想には限界がある。
「LLMに何でもデータを突っ込んで何とかなりや作戦は、やめた方がいい」
重要なのは、AIへ与えるデータの量ではなく、業務上の意味と関係性を保ったまま利用できる状態をつくることである。
RAGの課題と、ナレッジグラフという選択
議論は、多くの企業が採用してきたRAGへ移った。
RAG（Retrieval-Augmented Generation：検索拡張生成）は、質問に関連する情報を外部データから取得し、生成AIへ渡す仕組みである。企業向けでは、文書を分割・ベクトル化し、意味的な類似性に基づいて検索する構成が広く使われている。
中嶋氏は、こうした構成の運用負荷について説明した。
「データが更新されると、初めからもう一回更新する必要がある。全部消して繰り返すので、すごく無駄も多いんです」
実際には、RAGの実装方法によって部分更新も可能であり、常に全削除・再構築が必要なわけではない。ただし、元文書の更新、チャンクの再生成、ベクトルインデックスとの整合性維持などが継続的な運用負荷になるという問題はある。
越井氏は、検索精度そのものにも疑問を投げかけた。
「本当にそれってRAGでちゃんと実現できるのっていうことが、議論が尽くされていないところがあると思っています」
ベクトル検索は、意味的に近い情報を取得する。しかし、似ていることと、業務上必要であることは同じではない。
検索結果から重要な情報が漏れていないか。古い文書と最新文書を正しく区別できるか。複数の似た事例を一つにまとめていないか。RAGを本番利用するには、精度だけでなく、完全性、鮮度、出典の確認も必要になる。
これに対し、中嶋氏はDevRevのアプローチを次のように説明した。
「取ってきたデータをベクトル化することは基本的にしません。オリジナルはそのまま。データ間のパスをつないであげているだけです」
DevRevでは、顧客、製品、チケット、バグ、担当者、文書などの関係性をナレッジグラフとして保持する。
元データの所在や出典を追跡でき、誤りが見つかれば、元データまたは関係性を修正する。利用を重ねることで、組織内の知識のつながりを充実させるという考え方だ。
「使えば使うほどどんどん賢くなっていく、ビジネスフレームワークが作れる」
例えば、CRMの顧客情報、Googleドライブの手順書、問い合わせチケット、製品の不具合情報を関係付ける。
経営者が投資判断に必要な情報を得る際、担当者へ個別に確認する代わりに、商談、製品、問い合わせ、対応状況の経路をたどって確認するという利用が想定される。
中嶋氏は、更新履歴や特定時点の情報を追跡できる点にも触れた。類似文書を検索して回答をつくるだけでなく、「その時点で有効だった情報」を扱えることが、業務システムでは重要になる。
情報を増やすほど、コンテキストは失われる
ローカル環境で大量の情報をAIへ与える場合、コンテキスト上限も問題になる。
長い会話や大量の文書を投入すると、AIツールが過去の情報を要約・圧縮することがある。その過程で、細かな例外や複数事例の違いが失われる可能性がある。
必要な情報をすべてプロンプトへ入れる方法は、データ量が少ないうちは機能する。しかし、対象が企業全体へ広がると、コストと情報欠落の双方が問題になる。
DevRevでは、関係性に基づいて必要なデータだけを取得し、すべての情報を一度にコンテキストへ入れない構成を取ると説明された。
PoCでは回答が得られても、データ量、更新頻度、利用者が増えたときに運用できるのか。RAGとナレッジグラフの比較は、検索方式の優劣というより、本番環境でデータをどう維持するかという論点を示していた。
マルチエージェントを誰が監督するのか
議論は、複数のAIエージェントを連携させるマルチエージェントへ移った。
越井氏は、自ら構築を試みた経験を率直に語った。
「まず個人的に構築しようとするの、めちゃくちゃ難しいですね」
複数のエージェントを動かすと、それぞれの役割、処理順序、データの受け渡し、失敗時の対応を管理する必要がある。
そこで、全体を監督するスーパーバイザー役のエージェントや制御レイヤーが必要になる。しかし、その仕組みを自前でつくるには、AIだけでなく、業務設計、ソフトウェア開発、権限管理の知識も求められる。
結果として、各エージェントへ個別の作業をさせ、最後は人間が結果を統合する運用に戻るケースも多い。
「エージェントを複数束ねるものを作るなんて、正直絶対やりたくないと思っていた。それがすぐ使える状態になるというのは、かなりありがたい」
DevRevでは、発注確認、在庫確認、例外処理、全体監督など、複数の役割を持つエージェントのワークフローを構成できると説明された。
本番導入では、個々のエージェントの賢さよりも、誰が処理を開始し、どのデータを使い、どこで人間が承認し、失敗時にどう戻すかという全体設計が重要になる。
MCPだけでは解けない「全量取得」の問題
MCP（Model Context Protocol）は、AIが外部システムやデータソースと連携するための仕組みである。
ただし、MCPを使ってデータへ接続できても、必要な情報を漏れなく取得できるとは限らない。
顧客情報からチケット、製品、マニュアルへと順番に検索する場合、途中の結果が要約されれば、複数存在する類似事例を一件として扱ってしまう可能性がある。
DevRevでは、「この顧客に関連するチケット」「このチケットに関連する製品とバグ」といった関係をグラフとして保持する。リンクをたどることで、対象となる情報の集合を取得するという考え方だ。
もっとも、グラフの関係性や元データが誤っていれば、結果も誤る。重要なのは、誤りの出典を確認し、元データやリンクを修正できることである。
企業導入の最後の関門は権限管理
エンタープライズAIでは、正しい回答を返すこと以上に、「見せてはいけない情報を見せない」ことが重要になる。
越井氏は、文書を分割・ベクトル化した後で、元文書と同じ細かなアクセス権を適用する難しさを指摘した。
中嶋氏は、DevRevが元システムの権限を継承する仕組みについて説明した。
「DevRevはGoogle Driveの権限情報をそのまま取り込みます。新しく権限を付与する必要はないんです」
DevRevでは、役割、所属、職位などの属性に応じてアクセスを制御するABAC（Attribute-Based Access Control）と、Googleドライブなど元システムの権限設定を活用するという。
AIの回答段階で情報を隠すのではなく、権限のない利用者は対象データを取得できない状態をつくることが基本となる。
また、誰がいつ、どの情報へアクセスしたのかを記録する監査機能も紹介された。
「オーディット機能があって、誰がいつアクセスしたかわかる」
AIが誤った回答をした場合も、参照データと操作履歴を確認できなければ原因を特定できない。
PoCでは後回しにされがちなアクセス権と監査こそ、本番導入を左右する条件である。
日本企業の「記録文化」は強みになるか
山崎氏は、日本企業がPoCで止まりやすい背景について、責任と利益の所在が曖昧である可能性を指摘した。
誰がAI導入の責任を持つのか。どの部門が効果を得るのか。どの事業をどう変えるのか。こうした筋道がなければ、実験はできても事業変革へ進めない。
一方で、日本企業が長年蓄積してきた手順書、業務記録、品質管理情報、顧客対応履歴は、AI時代の資産になり得るという見方も示した。
「日本の方が早くAIネイティブになるかもしれない」
これは山崎氏自身が推測として述べた見解である。
文書が残っているだけでは価値にならない。古い情報を見極め、関係性と権限を整え、実際の業務へ接続できれば、日本企業の記録文化が強みに変わる可能性がある。
トップセールスの暗黙知を共有する
議論は、技術から人と組織の活用へ移った。
山崎氏は、営業組織におけるAIの役割として、トップセールスの暗黙知を共有する可能性を挙げた。
成果を出す営業担当者の行動を、他の人がそのまま再現することはできない。しかし、提案資料の構成、連絡のタイミング、質問の仕方、顧客との関係構築など、再利用できる要素はある。
「自分がちょっと足りないところを、先輩とか同僚の営業ナレッジで補うことができるんです」
商談履歴や会議記録、提案資料をAIが参照し、「この顧客に対して過去の優秀な担当者は何をしたのか」を示すことができれば、AIは個人の作業を代替するだけでなく、組織のメンターとして機能する。
「あの先輩って、あのお客さんとどうしてあんなにいい関係を築けているのかな。それをDevRevがメンターとして、パートナーとして教えてくれるような使い方ができる」
先輩に何度も同じ質問をすることには心理的な負担がある。AIであれば、必要なときに繰り返し問い合わせられる。
重要なのは、個人の成果をコピーすることではなく、組織に残っている行動と結果の関係から、学べる要素を取り出すことである。
言語化できないノウハウを、組織に残す
越井氏は、自身のAI活用方法を他者へ説明する難しさを語った。
プロンプトや設定をローカルに蓄積していても、なぜその書き方をするのか、どの場面で有効なのかを言語化するのは難しい。
「次に入ってくる人たちが、すごくうれしいだろうなと思っています」
個人が使ってきたプロンプト、修正履歴、成功・失敗の記録をAIが整理し、再利用できる知識として残せれば、新しく入社した社員も過去の経験へアクセスできる。
人の退職や異動によって、組織の能力がリセットされることを防ぐ。AIによるナレッジ継承は、効率化だけでなく、採用後の立ち上がりや人材定着にも関わる。
AIは人を減らすためだけのものではない
中嶋氏は、DevRev自身のAI活用について説明した。
「弊社としてはAIを、人を減らすとか、コストのために使っているわけでは全くございません」
カレンダーや業務システムを連携し、マネージャーに必要な活動内容やアクションを自動で共有するため、自ら日報を書く必要がないという。
「報告書を書いたりするこの時間があれば、もう一件回りたいみたいなところでレベルを伸ばせる」
定型的な報告業務をAIへ任せ、人は顧客対応や提案へ時間を使う。
この発言が示したのは、AIの目的を単純な人員削減に置くのではなく、「人が何に時間を使うべきか」という観点から業務を再設計する必要性である。
AIを導入しても、従来の報告、承認、入力作業を残したままでは、仕事が増えるだけになる。人の業務を減らすのではなく、人が価値を出すための時間を取り戻すという考え方が重要になる。
暗黙知を、組織強化へ変える
セッションの最後に、白藤が議論を次のようにまとめた。
「そういった暗黙知をAIエージェントに取り込んで、問い合わせることで、学びながら組織を強化できる」
AIエージェントは、人員削減やコスト削減の手段として語られがちである。しかし、この日の議論が示したのは、組織強化と暗黙知の継承という別の可能性だった。
ベテランの経験や判断基準を、他の社員が必要なときに参照する。個人が持っていた知識を、組織の共通資産へ変える。
PoC止まりを打破するために必要なのは、より派手なデモではない。
個人で止めず、チームで使うこと。データを投入するだけでなく、関係性と権限を整えること。AIへ仕事を任せるだけでなく、止め方と戻し方を設計すること。そして、人を置き換えるのではなく、人の時間と能力を引き出すことである。
クローズドな場が生む、実装に向けた対話
セッション後は、ドリンクと軽食を囲んだネットワーキングが行われた。
「自社ではどの業務から始めるべきか」「トークンコストをどう管理するのか」「既存システムの権限をどう引き継ぐのか」といった具体的な相談が、登壇者と参加企業の間で交わされた。
完全クローズドの場だからこそ、各社が抱える課題や失敗事例も率直に共有できる。
公開セミナーでは語りにくい実装上の悩みを、当事者同士で議論できることも、AI Innovators Circleの価値の一つである。
次回のAI Innovators Circleへ
シンセシー株式会社は、CAIO（Chief AI Officer）を経営の中核に据え、AIドリブンな組織運営を実践している。
AI Innovators Circleは、最先端の現場で何が起きているのかを、実際に変革へ取り組む当事者の言葉を通じて共有する場として開催されている。
AIを取り巻く環境は、これまでにない速度で変化している。その変化を自社の強みに変えるには、技術だけでなく、業務、データ、人材、組織、ガバナンスを一体として考える必要がある。
次回の開催情報は、シンセシー株式会社の公式サイトおよび公式SNSで案内する。
主催：シンセシー株式会社
公式サイト：https://synthesy.co.jp/
※本レポートは当日の文字起こしをもとに構成しています。製品仕様や機能に関する説明は、登壇者による当日の発言に基づいています。また、山崎氏が推測として述べた内容は、事実ではなく本人の見解として記載しています。
