VTI Japanで講演しました：AIを「回答ツール」から「知識と意思決定の基盤」へ

Books: Enterprise Al Gateway: Amazon Bedrockで実現する RAG・GraphRAG・AIガバナンス実装ガイド

Books: 生成AI時代のラピッドプロトタイピング: Streamlitで学び、Dockerで育てる AI業務システム

先日、VTI Japanにて、「AIを『回答ツール』から『知識と意思決定の基盤』へ」というテーマで講演する機会をいただきました。

生成AIやRAGの活用が広がるなか、多くの企業がまず取り組むのは、社内文書を検索し、質問に回答するAIです。これは非常に有効な入口です。既存の手順書、FAQ、仕様書、過去の報告書を活用し、一次回答を素早く用意できるようになります。

一方で、実際の業務で使い続けるためには、「答えが出る」だけでは足りません。

その回答は、どの資料の、どの記述に基づくのか。
どの条件なら適用でき、どの例外では専門家に確認すべきなのか。
誰が最終的に判断し、実行し、後から改善できるようにするのか。

講演では、こうした問いを起点に、RAG・LLM・Agentを単なる技術要素としてではなく、業務の知識と意思決定を支える構成要素として捉える考え方を共有しました。

通常のRAGは有効な出発点である

通常のRAGは、企業内に散在する文書を活用するうえで非常に実践的です。

短期間で試作できる。
既存資料を活かせる。
問い合わせや調査の初動を速くできる。

しかし、現場の文書には、条件、例外、改定履歴、担当範囲、略称や別名が含まれています。固定的な文字数で文書を分割して検索するだけでは、重要な条件や例外が回答から抜け落ちる可能性があります。

そこで重要になるのが、AIを一度に大きく作り変えることではなく、必要な能力を段階的に追加していくことです。

回答AIを業務AIへ育てる5つの要素

講演では、通常のRAGを土台に、次の要素を必要に応じて加えていく構成を紹介しました。

まず、Semantic Chunkです。
単に文章を一定の長さで区切るのではなく、「対象」「条件」「手順」「例外」「根拠」を意味として完結した単位で扱います。これにより、回答とともに適用範囲や注意点を示しやすくなります。

次に、Ontologyです。
企業では、同じ設備、部品、製品、工程が、部署や文書ごとに異なる名称で呼ばれることがあります。別名や略称、階層、属性を共通の概念に結びつけることで、検索精度だけでなく、企業固有の知識を再利用可能な資産へ変えていけます。

さらに、Graph RAGです。
業務で必要なのは、似た文書を見つけることだけではありません。設備、部品、手順、例外、担当者、改定履歴、過去の障害など、業務上必要な関係をたどる必要があります。Graph RAGは、その関係を探索し、回答に必要な文脈を組み立てるための考え方です。

そして、DSLとDecision Runtimeです。
安全、品質、承認、エスカレーションに関わる判断を、AIの自由な推論だけに委ねるべきではありません。どの条件で追加確認を求めるか、どの条件で専門家へ引き継ぐか、どこで停止するかを、検証可能なルールとして定義します。

最後に、Decision Traceです。
AIが何を参照し、どの候補を出し、人がどこを修正し、最終的に何が実行され、どんな結果になったのか。その履歴を残すことで、単なる監査ログではなく、次の改善に使える組織の記憶になります。

AIに任せる範囲は「Act / Ask / Stop」で考える

業務AIの設計では、すべてを自動化することが目標ではありません。

AIが回答候補を示してよい領域。
追加情報や人の確認を求めるべき領域。
専門家へ引き継ぎ、AIが停止すべき領域。

この境界を明確にすることが、現場で安心して使えるAIにつながります。

特に、安全性、品質、権限、顧客への影響が関わる業務では、「正しそうな回答」よりも、「どの条件で誰が判断するか」を明確にすることが重要です。

速い開発とは、速くコードを書くことではない

もう一つのテーマは、ラピッドプロトタイピングです。

速い開発とは、コードを速く書くことだけではありません。顧客や現場が、次の投資判断をできる状態を速くつくることです。

そのためには、最初から全社展開や大規模連携を目指すのではなく、対象業務と利用者を絞り、代表ケースで試作します。そして、実際のケースで価値、データ、判断責任、運用上の境界を確認します。

試作の結果は、次の三つに整理できます。

• Act：条件がそろったため、限定的な本番設計へ進む
• Ask：追加のデータ整備や検証、関係者との合意が必要
• Stop：価値や実現条件を見直し、対象を変更する

このように、試作を「完成品を急いで作る活動」ではなく、「次の判断を確かにする活動」として設計することが重要です。

再利用可能な業務AIのために

顧客ごとの業務課題は異なります。しかし、知識の取り込み、意味単位への整理、検索、用語の統合、ルール評価、人による確認、判断履歴の記録といった部品には、再利用できる部分が多くあります。

個別案件ごとに巨大なアプリケーションを作るのではなく、必要な能力を組み合わせ、顧客固有の知識と再利用可能な部品を分けて設計する。そうすることで、短期間で検証しながら、より信頼できる業務AIへ発展させていくことができます。

今回の講演を通じて改めて感じたのは、AI活用の中心は「どのモデルが最も賢いか」だけではない、ということです。

企業でAIを使うためには、知識をどう整え、どの根拠に基づき、誰がどこまで判断し、その結果をどう改善へ戻すのかを設計する必要があります。

AIを回答ツールとして導入することは、重要な第一歩です。
そこから、知識と意思決定の基盤へどう育てていくか。これからも研究と実装の両面から考えていきます。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance