仕事で生成AIを活用しようとするとき、以前は「自社データとの連携」が最初のハードルでした。自社データに繋がなければ、汎用的すぎて業務には使えなかったからです。
しかし今、その技術的ハードルはずいぶん下がっています。AIチャットアプリと最初から連携できるソフトウェアは増えましたし、弊社のCData Connect AIのようなサービスを使えば、あっという間に生成AIと自社データを接続できます（セキュリティなど内部統制のハードルはまだ残りますが、それは別の話として）。
ところが、繋いでみたら全部うまくいくかというと、そうでもない。そして、ふと思う。「自分でやった方が早くない？」と。
私自身、何度もあります。頭のいいはずのAIが、的外れな答えを返す。データを読ませたはずなのに、ズレた数字を出してくる。
そんなトンチキな出力を訂正しつづけるうちに、「AIなんてこんなものか」と思いそうになります。
でも、立ち止まって考えてみると、それってAIのせいでしょうか？
私はデータ連携製品のカスタマーサクセスエンジニアとして、日々お客さまのデータ環境についてお話を聴いています（だいたい年間600件ぐらい）。自分が現場に入って手を動かす立場ではありませんが、だからこそ、たくさんのお話をお伺いすることができ、その結果共通する課題やパターンに気づくことがあります。
そこで見えてきたのは、AIの出力の質を左右しているのは、AI自体の性能よりも「その周りの条件」ではないか、ということでした。
この記事は、日々現場でAIと格闘している方に向けて書いています。「思ったように動かない」「結局自分でやった方が早い」——そう感じている方にこそ、読んでほしい。AIに振り回される側から、AIをうまく操縦する側に回るための条件を、整理してみたいと思います。
生成AIだけでもダメ、データを繋ぐだけでもダメ
「AIなんてこんなものか」と感じるまでには、2つの段階があるように思います。
最初の段階は、「生成AIを入れてみたけれど、汎用的すぎて業務に使えなかった」というもの。ChatGPTやClaudeをそのまま使っても、自社の商品名も顧客名も知らないのですから、当然の結果です。
次の段階は、「じゃあ自社データを繋ごう」と、社内のデータベースやドキュメントをAIに接続する。「これで解決するはずだ」と期待した方も多いのではないでしょうか。
ところが、繋いでみると別の問題が起きる。
たとえば、私の場合。AIにSFA（営業支援システム）を繋いでみました。自分がお客さまに送った情報、チームメンバーが送った情報、サポートチームが送った情報——それらを全部踏まえて、状況に応じた適切な案内がしたかったからです。案内済みの情報をまた伝えてしまったり、他チームの連絡に返事がない状況で私からも連絡してしまったり。そういうコミュニケーションのズレは、自分がお客さまの立場だったら嫌ですから（ちなみに、今まではあっちのページを開いて、こっちのページを開いて、と情報をかき集めていました）。
さて、繋いでみると、AIは自信満々にサマリを出力してきました。
でも、どうも情報が足りていない気がする。何を参照したのか聞くと、「EmailMessage」だという。それなら妥当なデータを見ているように思えました。
ところが、AIと対話を重ねるうちに、実際に送付したメールは「EmailMessage」だけでなく「Task」というオブジェクトにも入っていることがわかったのです。参照先にTaskも含めるよう変えたら、出力のクオリティが上がりました。
他にも、これまで参照できていたデータが突然消えていることもありました。おそらくSFAの管理者が、ストレージ容量を削減するために過去データを削除したのでしょう。
このように、AIは一見すると適切な情報を必要十分に参照しているかのように見えます。そして実際は情報が足りていないにも関わらず、流暢に、自信たっぷりに回答してくる。それをそのまま受け取ってしまうと、「AIなんてこんなものか」になってしまいます。
つまり、AI活用において自社データとの接続はゴールではなく、スタートラインです。
では、どうしたら「AIなんてこんなものか」に陥らずに済むのでしょう。
私の例を振り返ると、まずデータに問題があったことがわかります。ですが、「出力に違和感を持てたこと」「AIに参照先を聞いたこと」——これらがなければ、問題の存在にすら気づけなかったはずです。AIへの聞き方、任せ方、チェック体制……「AIなんてこんなものか」の背景には、いくつかの問題が複合的に絡み合っています。
その複合的な問題とは何なのか、次のセクションで整理してみます。
「AIなんてこんなものか」の裏側にある4つのこと
私自身の体験、そして日々のお客さまとの会話を通じて見えてきたのは、AIがうまく活用できない原因が大きく4つに分かれるということです。
4つの原因
原因1.データ構造が整っていない
自社データは基幹システムやその周辺システムに入っていることと思います。
日本企業の多くは、システムをそのままの形で導入するのではなく、自社の業務に合わせてカスタマイズして導入することが長らく一般的でした（いわゆる「Fit to Standard」の文脈で語られる問題ですね）。
その結果、次のようなことが起こります。
たとえば、あるSaaSの標準データモデルでは「顧客」は1つのマスタで管理される設計でした。しかし導入時に、営業部門は「商談先」として、サポート部門は「問い合わせ元」として、それぞれ別のカスタムオブジェクトを作った。つまり「顧客」というまったく同じ意味のデータが、「商談先」「問い合わせ元」という異なるラベルで存在している状態です。
そこにAIが登場します。「この顧客との取引状況と問い合わせ履歴をまとめて」と頼んでも、AIは「商談先」と「問い合わせ元」が同じ顧客だと認識できず、それっぽい答えを返すことしかできません。
業務を円滑にまわすために行った善意のカスタマイズが、データ構造を複雑にし、AIの視点から見ると混乱のもとになっている。その結果、出力の質に影響してしまうというわけです。
ここで挙げた例は少し極端かもしれませんが、似たような状況、ないでしょうか？
原因2.聞き方の問題
たとえば、こんなこと、ないでしょうか？
営業チームの全員が同じ社内データに接続したAIを使っているのに、出してくる数字がバラバラだった。調べてみると、あるベテラン社員は「先月の売上実績を税込・返品控除後・確定ベースで教えて」と聞いていて、若手社員は「先月の売上いくら？」とだけ聞いていた。当然、返ってくる数字が違います。
ベテランが正確な数字を出せていたのは、AIが優秀だったからではなく、そのベテランの頭の中にある業務知識がプロンプトに反映されていたからです。AIにはその暗黙知がありません。
聞き方に前提条件が含まれていなければ、AIはそのたび異なる解釈をします。「人によって違う答えが出る」のはAIの問題ではなく、聞き方が属人化している問題です。
原因3.任せてはいけないところを任せている
たとえば、取引先の名寄せ作業。AIが得意そうな作業に思えますよね。
しかし、やったことがある方ならわかるはず。取引先の名寄せって、法人番号のようなユニークな情報がある場合はともかく、企業名だけしかないと調査や検証、そして判断を要求される作業です。
「ABC株式会社」「エー・ビー・シー株式会社」という取引先が登録されていたとき、これが同一企業か異なる企業かを検証・判断するのは、人間でも難しい作業ですよね（Webサイトややり取りしているメールアドレスのドメインを見たり、Google検索したり、担当営業に聞いたり……）。
つまり、「これは同一企業ではないか？」と当たりをつける作業はAIに任せてもよいけれど、「これは同一企業である」と判断するのはAIに任せるべきではないタスクなのです。
ちなみに、うっかり任せると、AIは間違えても「流暢に間違える」ので、出力だけ見ても気づけません。違う会社に誤って請求書を送付する、入金してしまう……なんてことになったら、「AIなんてこんなものか」ではすまない話です。
原因4. 出力を誰もチェックしていない
たとえば、AIにさまざまな集計を任せている方。その集計結果、データソース上のデータと照らし合わせてチェックしていますか？
私も日々の活動を振り返るためにいろんな数字を集計してもらっているのですが、あるとき売上金額が想定より大きく出ていることに気づきました。ダッシュボード画面と見比べて「あれ？」と思い、AIと対話してみたら、翌年の売上（予定）まで含まれていた、なんてことがありました。
人間だって集計ミスはするものです。だからこそ、レビューのプロセスがあるわけで。
最近「AIが言うには」という枕詞をよく見かけるようになりました。なんとなく「AIが作ったから正しいだろう」という暗黙の信頼で、チェックの仕組みを省略してしまっている方、多いのではないでしょうか。
この4つは、同時に起きている
このように、「AIなんてこんなものか」の裏側には、データの構造、聞き方、任せる範囲、チェック体制——この4つの問題が絡み合っているように思います。
皆さまの現場ではいかがでしょうか。思い当たるもの、ありましたか？
AIを活かすための3つの条件
ここからは、先ほどの4つの問題に対応する形で、AIを活かすための条件を整理してみます。
一つ先にお伝えしておくと、これから挙げる条件には「まず1から順番に」といった優先順位はありません。例えば、原因1（データ構造の問題）を解決するには時間がかかりますし、できるところから手をつけるのが現実的だと思っています。
3つの条件
条件1. データ構造を整える —— Fit to Standard
「原因1.データ構造が整っていない」への処方箋です。
Garbage In, Garbage Out——入力がゴミなら出力もゴミ。古典的な原則ですが、生成AIにおいても変わりません。最近は「AI-ready data（AIに渡せる状態のデータ）」という言葉もあります（なお、AI-ready dataは本来LLMの学習データなども含む広い概念ですが、この記事では「AIに渡す入力データ」——つまり、私たちが日々の業務で扱う自社データに絞ってお話しします）。
では、AIにとって活用しやすいデータとはどのようなものでしょう。3つの要素があると考えています。
意味が一意であること：「売上」の定義が全社で統一されている
形式が統一されていること：日付・通貨・コード等が揃っている
バリデーションが守られていること：数字入力欄に文字が入力できる等、ルール違反を許さない仕組みがある
「でも、AIは曖昧な入力でも補完してくれるじゃないか」と思うかもしれません。確かに、生成AIは表記ゆれや多少の曖昧さを吸収してくれます。しかし、先ほどの名寄せの例のとおり、「ABC株式会社」「エー・ビー・シー株式会社」が同一顧客かどうか——こうしたデータ間の関係性までは、AIは補完できません。そして補完には常に推測が入る以上（プロンプトで推測を禁止するなどしない限りは）、「流暢に間違える」リスクがつきまといます。
この3つを自然と満たすアプローチが、Fit to Standardです。「業界標準として設計された業務フロー、機能、そしてデータの意味・形式・ルールに合わせる」という考え方で、特定の製品の話ではなく、どのシステムを使っていても適用できる設計思想です。
もちろん、全業務を標準に押し込めるのは現実的ではありません。競争優位の源泉となるプロセスだけカスタマイズし、それ以外はFit to Standard——このバランスが良いように思います。
とはいえ、「そんなのすぐには無理だよ」という声が聞こえてきそうです。そうですよね。全社のデータモデルを一気に作り直すのは非現実的です。しかし、「次にシステムを入れ替えるとき」「次にカスタム項目を追加するとき」に標準に寄せる判断をするだけでも、だいぶ変わってきます。一気に直すのではなく、これ以上標準から離れないようにする——それだけでも前進です。
そしてもう一つ。Fit to Standardで整ったデータは、AI活用うんぬん以前に、経営判断の質を上げるものです。たとえば「売上」の定義が部署ごとに違う会社では、AIを使わなくても経営判断を間違えるリスクがある。データ構造を整える投資は、AIがどう進化しても無駄にはならないのではないでしょうか。
条件2. 聞き方を設計する —— プロンプト設計
「原因2. 聞き方の問題」への処方箋です。
データ構造が整っても、AIへの指示が曖昧なら出力は期待通りになりません。
従来のシステムなら不正な入力にはエラーが返りました。生成AIは、曖昧な指示でもそれらしく答えてしまう。「曖昧な入力 → 流暢な出力（実は誤り） → 誤りに気づかないまま使う」というサイレントな劣化が起きます。
「自分でやった方が早かった」の多くは、実はここに原因があるのではないでしょうか。
自分でやるときは頭の中に業務の文脈がある。しかしAIに任せるとき、その文脈を伝え損ねている。「原因2. 聞き方の問題」のベテラン社員の例がまさにそれです。あのベテラン社員がやっていたことは、高度なプロンプトエンジニアリングではなく、業務の前提条件を言語化していただけです。
業務ごとにプロンプトのテンプレートを設計する、出力形式を指定する、期待する粒度を明示する。これらは個人のセンスの問題ではなく、組織・チームとして「聞き方の型」を設計する話だと思います。
なお余談ですが、KGIやKPIなど皆でモニタリングする数字は、BIツールなどでダッシュボード化しておく方が適切だと個人的には思っています。AIは、その数字の深掘りに使うと便利です。
ただ、こうした「聞き方の型」を作る話をすると、「プロンプトはすぐに陳腐化する。AIが賢くなれば不要になるのでは？」と疑問に思う方もいらっしゃるかもしれません。確かにAIの能力は日々向上しています。しかし、たとえば売上集計の場面で「税込か税抜か」「確定値か速報値か」といった業務固有の前提条件は、AIがどれだけ賢くなっても、与えない限りは知り得ません。
また、プロンプト設計の本質は、巧みな呪文を書くことではなく、業務の暗黙知を言語化することだと考えています。そしてそれは、AIが進化しても価値が残る作業ですし、条件1と同様、AI活用とは関係なく組織のナレッジマネジメントとして意味があるのではないでしょうか。
条件3. 任せる線引きとチェック体制 —— Human in the Loop
「原因3. 任せてはいけないところを任せている」「原因4. 出力を誰もチェックしていない」への処方箋です。この2つは根っこが同じなので、まとめて考えます。
AIにどこまで任せるかを見極めるポイントは、「正解が一意に決まるかどうか」です。
たとえば、先ほどの名寄せの例。法人番号のようなユニークキーがあれば、AIは正確に名寄せできます。集計、整形、要約といった作業も得意です。しかし「ABC株式会社」と「エー・ビー・シー株式会社」が同一企業かどうか——こうした判断は、Webサイトを調べたり、担当者に確認したり、外部の情報や文脈に依存します。これはAIが苦手な領域です。
だからといって「AIに任せない」のではなく、任せ方を変えるという発想が大事だと思います。AIには「同一企業の可能性がある候補」を出させて、最終判断は人間が行う。AIを「判断者」ではなく「下調べ役」として使うイメージです。
大事なのは「最終判断は人間が行う」、ここです。任せた後のチェック体制が欠かせません。
原因4で触れたとおり、AIは間違えても「流暢に間違える」ので、出力だけ見ても気づけないことがあります。人間だって集計ミスをする。だからレビューのプロセスがある。AIも同じです。
こうした「AIの作業工程のどこかに、必ず人間が入る」仕組みを、Human in the Loop（ヒューマンインザループ）と呼びます。最終判断、承認、レビュー——チェックポイントを設計しておく。「AIが言うには」で終わらせず、「AIが出した結果を、誰がどうチェックするか」まで決めておく、ということです。
任せる範囲を決め、チェック体制を設ける。この2つはセットで考えると、AI活用の安心感がぐっと上がるのではないでしょうか。
実際、AIとの親和性が高い会計の分野では、多くのシステムがこのHuman in the Loopを取り入れているそうです。
会計はルールが明確で、正解が一意に決まる作業が多い——つまりAIが得意とする分野です。仕訳などはほぼ間違いなく行えるレベルに到達しています。それでも、最終的な承認は人間が行う。なぜか。会計の数字は、間違えたときの影響が大きいからです。税務、監査、経営判断——一つのミスが連鎖する。だから「高精度でも人間を通す」という設計が、コストに見合うと判断されている。
会計では「承認」がそのチェックポイントです。皆さまの業務でも、同じように「ここだけは人間が確認する」というポイントを決めておく。全部を見るのではなく、要所を押さえる設計というのがポイントです。
3つの条件は、どこからでも始められる
この3つに「まず1から」という順序はありません。データ構造を直すには時間がかかるかもしれませんが、聞き方のテンプレートを作ることは今週できます。AIに任せる範囲を決め、レビュープロセスを追加することは明日からでもできます。
大事なのは3つ揃うことであって、揃える順番ではありません。できそうなところからはじめてみるのはいかがでしょうか。
おわりに -- 使おう。でも、振り回されるのはやめよう
生成AIだけ入れてもダメ。自社データを繋ぐだけでもダメ。
前提条件を整え、AIに振り回される乗客ではなく、操縦するパイロットの側に回る。それがこの記事で伝えたかったことです。
「AIなんてこんなものか」と感じたとき、AIの利用を諦めるのではなく、3つの条件のどこが欠けているか——あるいは他に欠けているものがないか——考えてみてください。そして、できるところから対応すれば、AIは少しずつ本来の力を発揮し始めるはずです。
なお、「条件1. データ構造を整える —— Fit to Standard」については、CData製品がお役に立てる部分がかなりあります。詳しくは下記の記事にまとめましたので、ぜひご覧ください。
Fit to Standardと4つの課題｜CData製品でできること
