AI実装が社内で止まる理由 ―ベストプラクティスが会社ごとに違う理由と、AI-Readyから実装までの5つの要素―

たとえば、社内チャットボットに「出張の日当はいくらか」と聞くと、2年前に改定された規程の、改定前の金額が返ってくる。生成AIを導入した会社で、こうした場面はめずらしくありません。

ベンダーに問い合わせると、検索の設定は仕様どおりだという答えが返ってきます。仕様に誤りはありません。古い規程を参照の対象から外すかどうかが、要件に入っていないからです。

生成AIの導入が一巡したいま、私たちが受ける相談の多くは、この「導入はしたが、次に何を直せばよいかが社内で決まらない」状態から始まります。相談の中身は、回答の精度をどこまで上げればよいか基準がない、RAG（社内文書を検索して回答に使う仕組み）を組んだが何を足せば答えが良くなるか分からない、どのデータを信じてよいか判断できる人がいない、と様々です。どれも、何を直すかを社内で決める人がいない、という一点に行き着きます。

本記事では、AIを環境に入れて動かすところまでを「導入」、業務の判断に組み込み、精度を保ち続けるところまでを「実装」と定義します。導入と実装のあいだには、業務の中身を知り、データに直接触れ、AIの出力を見て「ここがずれている」と言える人の仕事があります。本記事ではその仕事を5つの要素に分け、誰が担うかの選択肢とあわせて整理します。

この記事で分かること

• ・AIを導入したあと、社内の推進が止まる構造
• ・AI実装のベストプラクティスが、会社ごとに大きく違う理由
• ・実装に必要な5つの要素と、それぞれで「データに触れる人」が担う仕事
• ・その役割を、採用・育成・外部の常駐のどれで埋めるかの考え方

01. 導入後に増える課題

AI導入の多くは、ベンダーへの発注から始まります。要件を伝え、環境を用意してもらい、PoC（概念実証）で手応えを確かめるところまでは、外部の力で進みます。

停滞しやすいのは、本番で使い始めてからです。冒頭の日当の例のように、要件定義の段階では見えなかった課題が、利用が増えるにつれて次々に出てきます。この回答は何を根拠にしているのか、古い規程を参照していないか、部署ごとに意味の違う用語をAIは取り違えていないか、出力が業務の実態とずれたとき直すのは誰なのか、など実際に多くのご相談を受けます。

いずれも仕様書の外にある問いです。ベンダーは渡された要件に対して、できる限りの構成を組みます。それでも、要件に書かれていない業務の事情までは知りようがありません。社内の担当者のほうは、業務には詳しくても、データの構造やAIの挙動まで踏み込んで原因を切り分けるには、時間も手段も足りないことが多いでしょう。こうして問いが両者のあいだに残り、AIは「入っているが、使われていない」状態に落ち着いていきます。

本記事でいう「データに触れる人」とは、こうした問いに対して、実物を開いて確かめられる人を指します。具体的には、参照されている文書の版を確認したり、データベースから該当するレコードを引いてきたり、AIの検索ログを読んで、どの文書のどの段落が回答に使われたかを追ったりする仕事です。職種でいえばデータエンジニアやデータアナリストに近いものの、肩書きより、業務の担当者と同じ画面を見ながら話せるかどうかで決まります。

プロジェクトが止まる場所を「始め方・進め方・終わり方」に分けて見ると、失敗の型はかなり絞り込めます。

02. ベストプラクティスが会社ごとに違う理由

AI実装には、すでに多くの型が出回っています。RAGの構成例、プロンプトの書き方、評価指標の置き方など、どれも参考になります。ただ、型をそのまま持ち込んで狙った精度が出た会社は、私たちが見てきた範囲ではそう多くありません。AIが答えを出すために必要な材料が、会社ごとに違うからです。

同じ「社内ナレッジ検索」でも、製造業であれば、仕様書の版管理と型番の表記揺れが精度を左右します。人材サービスであれば、商談メモに残る顧客の事情や、求人票の書き方の社内ルールが精度に影響します。金融であれば、誰がどの情報を見てよいかという権限やセキュリティの線引きが、検索の設計より先に問われるでしょう。参照すべき文書、用語の定義、判断の例外、権限の範囲。この組み合わせまで同じ会社は、まずありません。

2024年には、株式会社ベネッセコーポレーションの國吉啓介氏と、メンバーズデータアドベンチャーカンパニーの元カンパニー社長の白井恵里の対談を公開しました。その中で白井は、汎用の生成AIを企業がそのまま業務に使ったときの手応えを「精度と実用性の観点では70点くらいの感覚」と表現しています。残りの30点は、モデルの性能が上がっても埋まりにくい部分です。自社の情報を、AIが理解できる形で渡せるかどうかにかかっています。

では、情報を多く渡せば補えるのでしょうか。そうとも限りません。スタンフォード大学などの研究チームは、長い入力の中ほどに置かれた情報を、モデルが冒頭や末尾の情報ほどには使いこなせない傾向を報告しています。社内文書を丸ごと渡す設計は、判断に必要な一文をかえって埋もれさせることがあります。

出典：「Lost in the Middle: How Language Models Use Long Contexts」（Transactions of the ACL）https://aclanthology.org/2024.tacl-1.9/（2026年10月26日に利用）

対談では、生成AIを社内に広げる順序や、経営層を巻き込むための「クイック・ウィン」の考え方にも話が及んでいます。

03. AI実装に必要な5つの要素

会社ごとに正解が違うなら、何を手がかりに進めればよいのか。ここでは5つの要素に分けてご紹介します。まず①を決め、②以降は行き来しながら厚くしていくと、後の手戻りが少なくなります。

03-1. 一つの意思決定から始める

AIは何にでも使えそうに見えるぶん、全社共通の基盤から入りたくなります。ところが対象が広がるほど、何をもって成功とするかが曖昧になり、改善の手がかりも失われていきます。

まずは「どの意思決定を、もっと良くしたいか」という目的の明確化です。営業の提案、需要予測、品質管理、採用、一つに絞れば評価の軸が決まり、軸が決まれば改善のサイクルが回り始めます。Google Cloudの実装ガイドは測定できる事業目標から始めるよう勧め、Anthropicの技術記事は、仕組みは単純なものから始め、必要になったときにだけ複雑にするよう勧めています。

出典：「Evaluate and define your generative AI business use case」（Google Cloud）https://docs.cloud.google.com/docs/ai-ml/generative-ai/evaluate-define-generative-ai-use-case（2026年10月26日に利用）

出典：「An Executive's Guide to Agentic AI」（Amazon Web Services）https://aws.amazon.com/executive-insights/content/an-executives-guide-to-agentic-ai（2026年10月26日に利用）

出典：「Building effective agents」（Anthropic）https://www.anthropic.com/research/building-effective-agents（2026年10月26日に利用）

ここで重要なのが、データに触れる人の目です。選んだ意思決定について、過去の判断の記録や、正解にあたるデータが社内に残っているか。たとえば「受注できそうな案件の見極め」を選ぶなら、過去の商談で何を根拠に判断し、結果がどうだったかが、どこかのシステムに残っている必要があります。残っていなければ、AIの出力が正しいかどうかを確かめる手段がありません。ユースケースの選定とデータの棚卸しを同じ人が同時に見ておくと、始めてから「評価できない」と気づく事態を避けられます。

03-2. 判断に必要な文脈を設計する

「社内文書を丸ごと渡せば、AIが読み解いてくれる」と期待したくなりますが、前章で解説した通り、量は精度を保証しません。

必要なのは、判断に使う分だけの文脈です。ここでいう文脈とは、その意思決定の目的、優先順位、データの意味、評価基準、例外や制約を指します。Anthropicが2024年に公開した検証では、文書を分割した断片ごとに「この断片が文書全体のどこにあたるか」という短い説明を添え、2つの検索方式を組み合わせました。その結果、上位20件の検索失敗率は5.7%から2.9%へと、ほぼ半分に下がっています。文書を増やさなくても、断片に位置づけを一言添えるだけで結果が変わった、ということです。

出典：「Introducing Contextual Retrieval」（Anthropic）https://www.anthropic.com/news/contextual-retrieval（2026年10月26日に利用）

実務でいえば、RAGのチューニングの多くはこの作業にあたります。どの文書を参照の対象に入れどれを外すか、古い版をどう扱うか、社内の略語や部署によって意味の違う用語をどこで定義するか。冒頭の日当の例も、ここで「改定前の規程は参照から外す」と決めておけば防げた問題です。どれも実際の文書を開き、AIの検索結果と一件ずつ突き合わせないと決められません。モデルの設定画面だけを見ていても、答えにはたどり着けない作業です。

文書に添える「説明」の土台になるのが、メタデータです。意味と種類は、以下の記事で解説しています。

03-3. データは、使いながら整える

AIのためのデータ整備は欠かせません。ただ、整備の完了を待っていると、AI活用はなかなか始まりません。何が足りないかは、使ってみるまで分からないことが多いからです。

そこで、先に一つの意思決定でAIを使い、出力に現れる違和感を手がかりに、足りないデータや文脈のありかを突き止めます。分類や整備の手順はAIに提案させ、妥当性は人が確かめます。この違和感から原因を切り分ける作業は、データに触れる人がいないと進みません。答えがずれた理由は、参照データが古いからか。用語の定義が部署で違うからか。そもそも必要な情報がシステムに入っていないからか。原因が分かれば、整備の優先順位はおのずと決まります。

整備の手順そのものは、こちらの記事で詳しく解説しています。

03-4. 評価と統制のループを回し続ける

AIが動き始めると、データマネジメントは後回しにされがちです。範囲が広く、成果も見えにくいためです。その結果、しばらく経ってから、データや仕組みの作り直しが発生することになります。

回し続けたいループは2つあります。一つは、利用結果からデータを直し、評価し直す「活用のループ」。もう一つは、リスクを検知し、ルールを更新し、監視を続ける「統制のループ」です。Anthropicは2026年1月に公開したAIエージェントの評価に関する技術記事で、評価の仕組みを「継続的な手入れと明確な責任者を要する、生きた成果物」と位置づけ、実際の失敗をテストに変えるほど開発は速くなると述べています。

出典：「Demystifying evals for AI agents」（Anthropic）https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（2026年10月26日に利用）

現場から上がった「この答えはおかしい」を一件ずつテストケースに変え、次の改修で同じ誤りが出ないかを確かめる。地味な手入れですが、私たちの見てきた範囲では、精度が保たれるか、少しずつ落ちていくかは、この手入れを続けたかどうかでおおよそ決まります。

ルールを決めて、そのルールで運用を続けるための仕組みが、データガバナンスです。定義から立ち上げの手順までは、以下の記事で詳しく解説しています。

03-5. 業務を知る人と、データに触れる人が組む

AIの専門家を一人アサインし、ほかの部門は完成を待つ。よくある体制ですが、仕上がったAIが業務に合わず、使われないまま終わることも珍しくありません。

6業界・17課題でAIエージェントのデータ分析力を比べたベンチマーク研究（AgentDS、2026年）では、AI単独の結果は参加チームの上位4分の1に届かず、最も良い成果は人とAIの協働から生まれました。Anthropicが2026年4月に受賞者を発表したハッカソンでは、受賞者5人のうち、実に4人がプロの開発者ではなく、弁護士、循環器内科医、道路・インフラの専門家、電子音楽家でした。

出典：「AgentDS Technical Report: Benchmarking the Future of Human-AI Collaboration in Domain-Specific Data Science」（arXiv）https://arxiv.org/abs/2603.19005（2026年10月26日に利用）

出典：「Meet the winners of our Built with Opus 4.6 Claude Code hackathon」（Claude）https://claude.com/blog/meet-the-winners-of-our-built-with-opus-4-6-claude-code-hackathon（2026年10月26日に利用）

解くべき問いと、結果が妥当かどうか。この2つを決められるのは、業務を知る人です。データの構造化や接続、評価、監視の実装は、データとAIの専門家が受け持ちます。

採用だけでは担い手が埋まらない理由と、育成の設計については、別の記事でまとめています。

03-6. 5つの要素を、4つのステップで回す

5つの要素は「何を揃えるか」、ここで示す4つのステップは「どの順で回すか」にあたります。5つを一度に揃える必要はありません。メンバーズでは、次の4つのステップを繰り返しながら、要素を一つずつ厚くしていきます。

スモールかつクイックに始めることで、その過程で整えるべき情報が見つかり、品質改善の対象が決まり、次に広げる先も見えてきます。

04. データに触れる役割を、誰が担うか

5つの要素を並べると、共通点が見えてきます。どの要素も、業務の言葉とデータの言葉の両方を扱える人がいないと、前に進みません。

事業部門は、ビジネスへの影響やデータの意味に詳しい一方で、データの構造やシステムの制約までは把握しきれません。IT部門やベンダーは、仕様や基盤には詳しくても、業務上の意味や現場での使われ方には踏み込みにくい立場にあります。この2つのあいだは、外から助言するだけでは埋まらないことがほとんどです。実際のデータを開いて確かめ、AIの出力と業務の実態を突き合わせる作業を、業務の内側で続ける役割が必要です。

この役割の埋め方は、大きく3つあります。

3つのどれか一つに決める必要はありません。立ち上げの時期は外部の手を借りて一つ目の事例を早く回し、そのあいだに社内で担い手を育て、足りない部分を採用で補う。そうやって時期ごとに組み合わせを変えていくのが、現実的な進め方でしょう。

メンバーズデータアドベンチャーカンパニーは、このうち3つ目の役割を担っています。データ・AIの人材が常駐。業務の内側に入り込み関係者のあいだに立って用語の定義と判断基準を揃え、現場の違和感を早いうちに拾い、実行できる改善策に落とし込みます。データ基盤の構築からBIでの可視化、AIの実装まで、現場で直接手を動かします。

表に書いたとおり、外部の人材が常駐する方法には、知見が外に溜まりやすいという弱点があります。そのため私たちは、整理した定義やルールを、人にもAIにも参照できる形で社内に残すところまでを、常駐の仕事に含めています。担当者が替わっても、データと文脈が組織に残るよう、立ち上げの時期は私たちが部門のあいだをつなぎ、最終的には部門同士がデータで直接つながる状態をつくります。

特定のツールを持たない立場であることも、この役割の助けになっています。Azure OpenAIやAzure AI Search、Google Vertex AI、Amazon Bedrock、Difyなど、どの基盤が入っていても、既存の環境を前提に進めることができます。直近のAI活用支援110件のうち、記録上、約8割が本番運用の段階に到達しました。

05. モデルケース｜AIの違和感を、改善の課題に変える

5つの要素が、実際の業務でどう動くのか。ここでは、私たちが想定しているモデルケースを一つ紹介します。特定の一社に限らない、想定のケースです。

対象は、大手人材サービス企業の営業企画部門と法人営業部門です。提案書の作成、求人票の改善、顧客企業の分析、商談の準備にAIを使い、顧客情報、求人データ、営業履歴、商談メモ、提案資料、業界のナレッジを参照させている、よくある構成です。

こうした現場で起こりやすいのが、AIの出力に対する違和感です。「業界の理解が浅い」「過去の提案と合わない」「顧客の状況とずれている」。原因は、参照データの古さか、用語の定義のずれか、顧客の文脈の不足か、あるいは権限の範囲やメタデータの不足かもしれません。原因の特定と改善がされないままでは、現場はAIの出力をそのまま使えません。

そこで、違和感そのものを集めることから始めます。集めた違和感を、品質・定義・文脈・権限・メタデータの観点で分類し、データマネジメントの改善課題としてバックログに積んでいきます。

たとえば「過去の提案と合わない」という声を追っていくと、提案資料のフォルダに、受注した提案書と失注した提案書が区別なく入っていた、というケースが考えられます。AIから見れば、どちらも同じ重みの「過去の提案」です。この場合に手を入れるのはモデルの設定より、資料に「受注／失注」「業界」「提案時期」といったメタデータを付け、参照の優先度を分けるほうでしょう。一件の違和感が、要素②の文脈設計と、要素③のデータ整備の課題に変わります。

改善は一度で終えず、利用者の声をもとに回し続けます。狙いは、「なんとなく使えない」を、直すべき課題の一覧に変えることです。確認や修正の手戻りが減れば、営業の現場は提案や顧客分析にAIを使いやすくなります。

05-1. 実際の支援事例から

ここでは実際の事例をご紹介します。生成AIを使った社内ナレッジ検索の導入では、既存システムの制約と、特定ベンダーへの依存（ベンダーロックイン）の論点を整理したうえで、既存の資産を捨てずに運用できる構成を設計しました。PoCで止めず、半年以内の本番展開を見据えたロードマップを引いています。

イベントプラットフォームを運営する企業では、氏名・会社名・メールアドレスが中心だった会員情報に、外部APIで業種や企業規模を付け足しました。会社名の表記揺れも正規化し、分析に使えるデータへと整えています。

2つの事例を含め、部署別の取り組みは以下の記事で詳しく解説しています。

06. 自社の現在地を測る3つの問い

最後に、自社の状況を確かめるための問いです。答えに詰まった問いがあれば、そこが次に手をつける場所の可能性が高いです。

問い1｜どの意思決定を、もっと良くしたいですか。

営業、マーケティング、需要予測、人事、財務経理、品質管理、法務。AIで良くしたい判断を一つ挙げられるかどうかが、出発点です。

→ 一つに絞れない場合は、要素①から。評価に使える記録が残っているかも、あわせて確かめてください。

問い2｜その意思決定で、どんな文脈が足りていませんか。

マニュアルにない判断の例外か、部署ごとに違う用語の意味か、古い版の文書か。

→ 挙げられない場合は、AIの出力への違和感を集めるところから（要素②③）。挙げられる場合は、その文脈を書き足しながら（要素②）、誰が直し続けるかを決める段階に来ています（要素⑤）。

問い3｜データ整備は、いまどの段階にありますか。

未着手、予定している、着手中、かなり進んでいる。

→ どの段階からでも始められます。整備の完了を、AI活用の開始条件にしないことです。整備がかなり進んでいる会社は、整えた範囲が実際の判断に使われているかを、要素④の評価で一度確かめておくとよいでしょう。

07. 編集後記｜正解は、自社のデータの中にある

AI実装の議論は、どうしても「どのツールを選ぶか」「どの型にならうか」に寄りがちです。けれども自社にとっての正解は、自社の業務とデータに触れてみて、初めて見えてきます。他社の成功事例をなぞっても同じ結果が出にくいのは、そのためです。

正直に言えば、最初の意思決定を選ぶ段階で、何が有効かを見通せている会社はほとんどありません。私達も、データを開いてみるまで分からないことのほうが多いのが実情です。だからこそ、早くデータに触れ、早くずれを見つけることを、進め方の中心に置いています。

メンバーズデータアドベンチャーカンパニーは、特定のツールに縛られない立場から、データ・AIの専門人材が業務の内側に入り、事業部門とIT部門のあいだに立ってAI実装を進めます。以下の記事では、本記事に続きAI導入の効果をどう測り、社内の合意にどうつなげるかを取り上げます。