生成 AI を「個人で使えている」と「組織で回っている」の決定的な差とは – 担当エンジニアに聞いてみた

個人が ChatGPT や Gemini などのツールを使って資料作成や情報収集を効率化できるようになるのは比較的簡単です。しかし、それが「組織の業務フローに組み込まれ、品質が担保された状態で誰もが使える」という状態になるのは、全くレベルの異なる話です。

「個人で使えている」は、いわばツールへのアクセス権があるというだけの状態です。「組織で回っている」状態には、精度の担保、データ整備、そして現場への展開設計という3つの要素がそろっている必要があります。KDDIアイレットの gaipack 本部では、この3つを揃えた状態を「AI 駆動開発（AIDD）」として実践しています。どれか一つでも欠けると、PoC は成功しても本番化・全社展開に至らないケースが多いと感じています。

実際の業務に使うためには、ハルシネーション（AI が事実と異なる情報を生成してしまう現象）への対策と、回答精度のチューニングが必要です。これを後回しにすると、現場が「使えない」と判断して本番環境に出せないまま終わります。

私たちが KDDIアイレットの新卒採用サイト向けに生成 AI チャットボットを開発した際も、精度向上に向けてさまざまな工夫をしました。よくある質問と回答のデータを網羅的に整備し、回答の根拠となる情報が見当たらない場合は「回答が見つかりません」と正直に返す仕組みを組み込むことでハルシネーションを抑制しています。具体的には、RAG の Retrieval 側で類似度スコアが一定の閾値を下回った場合に回答を拒否する設計を採用しており、AI が「知ったかぶり」をしない仕組みを担保しています。また、禁止ワードの設定や曖昧な表現を避けるプロンプト設計なども行ないました。

こうした取り組みを積み重ねながら、インフラ構築からバックエンド開発、UI/UX 設計を含むフロントエンド開発まで一気通貫で実施し、プロジェクト開始から2ヶ月で本番稼働まで持っていくことができました。

これは非常によくある誤解です。生成 AI が学習していない社内固有のデータを活用するためには、RAG（Retrieval-Augmented Generation：検索拡張生成）という仕組みが必要です。RAG を使うことで、生成 AI が事前学習していない社内データをもとに回答できるようになります。

そのためにまず必要なのが、社内のデータが AI に渡せる状態＝「AI-Ready」になっていることです。「データはあるが散在している」「手書きが多くてデジタル化できていない」「表形式で AI が読み取りづらい構造になっている」という状況では、RAG を構築しても精度は上がりません。AI-Ready とは単なるデジタル化ではなく、AI が正確に情報を取得・活用できる構造に整えることを指します。

データの「形」そのものを AI に合わせて最適化することが重要です。たとえば、社内規定に地域ごとの特例ルールが多い場合、従来の PDF の表形式のままでは生成 AI が正確に判断しづらいことがあります。

株式会社サニックスエンジニアリング様のプロジェクトでは、まさにこの「データ構造の最適化」がカギになりました。社内規定の表形式をリスト形式や JSON 形式に変換し、特例ルールを明確な記述に整理することで、RAG の検索精度を向上させ、ハルシネーションを低減することに成功しています。

AWS が提供するオープンソース「Generative AI Use Cases（GenU）」と Amazon Bedrock を連携させた社内専用 RAG チャットを構築した結果、全国の保守現場から寄せられる問い合わせへの対応工数を7割削減する成果につながりました。

あります。AI-Ready の考え方は、テキストや帳票だけでなく、映像データにも同様に適用できます。動画をそのまま AI に渡しても精度は上がりません。映像を「視覚情報（映像の状況説明）」「セリフ情報（音声の文字起こし）」「テキスト情報（テロップや字幕）」の3種類に分割し、それぞれに最適化した形でメタデータ化することで、はじめて AI が正確に検索・活用できる状態になります。

株式会社バンダイナムコエンターテインメント様では、膨大なゲームプレイ映像や PV 動画の中から目的のシーンを探し出す作業が、タイトルに詳しいメンバーの記憶や経験に依存する属人的なプロセスになっていました。Google Cloud の Gemini と Vertex AI Search を組み合わせ、映像データを AI-Ready な構造に変換する設計を採用することで、誰でも自然言語で目的のシーンを特定できる独自システム「ClipSearch」の PoC 開発を実現しました。

株式会社 IHI 機械システム様のケースがその典型例です。部門ごとに管理されている帳票や設計データが属人化しており、過去の事例を調査する際の検索に多くの時間がかかっていました。また、手書き帳票が多くそのままではデータ活用が困難な状況でした。

私たちは Amazon Bedrock を活用して手書き帳票を含む非構造化データをデジタル化・ナレッジ化し、Amazon Kendra による高精度検索と組み合わせることで、誰でも過去の問い合わせ履歴や設計不具合の情報を素早く検索できる仕組みを構築しました。さらに、ノーコードでユースケースを追加できる仕組みも導入しており、現場担当者自身が RAG を組み込んだアプリケーションを作成できる環境も整えています。「AI-Ready 化」と「現場での使いやすさ」を同時に実現したプロジェクトです。

これは非常に多いパターンです。DX 推進部門や IT 部門が開発したシステムであっても、現場が「どう使えばいいかわからない」「自分たちの業務には関係ない」と感じてしまうと、結局使われなくなります。

生成 AI の活用が「全社展開」まで到達するかどうかのカギは、社内での機運の醸成と、現場が主体的に使える仕組みづくりにあります。

加賀 FEI 株式会社様のプロジェクトがまさにそのケースでした。自社製品に関する問い合わせがベテラン開発者に集中し、新任エンジニアの習熟にも時間がかかっているという課題に対して、Vertex AI Agent Builder を活用した RAG 環境を構築しました。

このプロジェクトで特に意識したのは、技術的な成果だけで完結させないことです。開発過程で加賀 FEI 様のエンジニアの方々と密に連携し、生成 AI のトレーニング方法や解析手法に関する知見を社内に共有していきました。その結果、PoC を通じて生成 AI 活用への機運が全社的に高まり、専門部署の立ち上げというアクションにつながりました。これが「組織で回る」状態への確かな一歩です。

一言でいうと、「最初から組織展開を前提にして PoC を設計している」企業です。

PoC の目的を「動くかどうかを確認する」で終わらせるのではなく、「業務フローに組み込んで、誰が・どの業務で・どれくらい使うか」まで設計してからスタートしている企業は、本番化のスピードが全く違います。

また、私がプロジェクトで常に意識しているのは、「技術だけで完結させない」ということです。私が一番怖いのは、PoC で作ったものが誰にも使われずに枯れていくことです。動くものを作って終わりじゃなくて、現場の人が日常で触り続けてくれて、はじめて意味がある。そのために、現場のニーズを丁寧にヒアリングする時間を必ず設けるようにしています。

KDDIアイレットでは、PoC 段階での技術検証から、データ整備・精度チューニング・現場展開まで、一気通貫で支援しています。「まず試してみたい」という段階から、「PoC はやったが本番化が進まない」という段階まで、お客様の状況に合わせた進め方をご提案します。

AWS や Google Cloud の認定パートナーとして、Amazon Bedrock や Vertex AI、RAG 構築など最新技術の知見を持つエンジニアが、御社の業務課題に向き合います。生成 AI 活用にお悩みの方は、ぜひお気軽にご相談ください。