データ分析に生成AIは使えるか｜4つの型と回収17.8ヶ月の試算

データ分析に生成AIを使う話は、2026年になっても「データを渡せば答えが返る」段階には入っていません。生成AIによるデータ分析を業務に組み込めている企業は、生成AIを使っている企業の中でもごく一部です。ただし、その理由は「モデルがまだ賢くないから」ではありません。分析結果が使えるかどうかを決めているのは、モデルの側ではなくデータの側にある3つの条件です。本稿では、生成AIのデータ分析を4つの型に分け、精度を決めている3条件を示し、タイの日系工場を想定した3シナリオの独自試算で「整備範囲を広げるほど回収が遠のく」という反直感的な構造まで踏み込みます。

生成AIのデータ分析だけが伸びていないという事実

帝国データバンクが2026年3月17日から31日にかけて実施した調査（有効回答10,312社）では、生成AIを業務で活用していると答えた企業は34.5%でした。ここまではよく引用される数字です。問題はその内訳です。

活用していると答えた企業に用途を聞くと、「文章の作成・要約・校正」が45.1%で最多、「情報収集」が21.8%、「アイデア出し」が11.0%と続きます。そして「データの集計・分析」は7.4%です。最多用途の6分の1しかありません。「プログラミング支援」の5.9%と大差ない水準に沈んでいます。

ここで注意すべき読み方があります。この7.4%は「全企業の7.4%」ではありません。生成AIを業務で活用していると答えた企業の中での用途割合です。母数が34.5%の側にあることを踏まえると、実際に生成AIでデータの集計・分析をしている企業の全体に対する比率はさらに小さくなります。

なぜここだけ伸びないのか。需要が無いからではありません。むしろ経営企画や生産管理の現場では、「月次レポートを作る時間をなくしたい」「不良の傾向を毎日見たい」という要望は文章生成より切実です。伸びていないのは、需要が無いからではなく、やってみたが通らなかったからです。

通らない、というのは失敗の仕方が特殊だという意味です。文章生成なら、出力が悪ければ読んだ瞬間に分かります。データ分析は違います。返ってきた数字が正しいかどうかは、その数字を検証する手段を別に持っていない限り分かりません。そして多くの現場は、その検証手段を持っていないからこそAIに分析させようとしています。ここに構造的なねじれがあります。

生成AIのデータ分析は4つの型に分かれる

「生成AIでデータ分析」という一語が、実務ではまったく性質の違う4つの作業を指しています。準備するものも、失敗の出方も、必要な投資額も違います。議論が噛み合わないのは、この4つを混ぜて話しているからです。

この4つは段階ではありません。①から順に進んで④に到達する、という関係ではないという点が重要です。④は①より簡単ですし、③は②が成立していないと絶対に成り立ちません。自社がどれを求めているのかを先に決めてから、必要な準備を逆算します。

① 貼り付け分析｜速いが、残らない

手元のCSVやExcelの表を生成AIに貼り付け、「不良が多い工程を教えて」と聞く形です。準備はほぼ不要で、今日から始められます。実際、多くの企業の「生成AIでデータ分析を試した」はこの型を指しています。

この型の価値は探索にあります。仮説が無い状態でデータを眺め、「この工程だけ様子が違う」という気づきを得るには十分に使えます。表計算ソフトでピボットを組む前の、当たりをつける作業として優秀です。

問題は、結果が残らないことです。誰がいつどの範囲のファイルを貼ったのかが記録に残りません。翌月に同じ質問を投げても、貼ったファイルの抽出条件が1日ずれていれば違う答えが返ります。そして、どちらが正しいのかを判定する手段がありません。会議で「AIが言っていた」と発言した数字を後から再現できず、結局担当者が手作業で作り直す、という展開は珍しくありません。

したがって①の位置づけは「仮説を作る場所」に限定すべきです。ここで得た気づきを、②または既存のBIで再現可能な形に落とし直す。この分業が成立していれば①は十分に元が取れますし、成立していなければ①は工数を増やすだけの活動になります。

② 接続分析｜本命だが、最も準備が要る

生産管理システムや品質データベースに生成AIを接続し、自然言語の質問をSQLなどのクエリに翻訳させて答えを取る形です。「生成AIでデータ分析」と聞いて多くの人が期待しているのはこれです。

この型が成立すれば効果は大きく、そして準備は最も重くなります。必要なのはモデルの性能ではなく、後述する語彙・粒度・境界の3条件です。この3つが無いまま接続すると、AIは平然と、もっともらしく、違う母集団を数えます。

②の失敗の典型は「間違った数字が出る」ことではありません。「使えない形で正しい数字が出る」ことです。この点は本稿の中心なので、専用の章で扱います。

社内の文書や手順書に対する検索・要約を含めたい場合は、データベースへの接続とは別に検索基盤の設計が必要になります。この領域はRAG構築の実務で扱っている論点と重なります。数値データへの接続と、文書に対する検索は、必要な準備がまったく別物です。

③ エージェント分析｜自走の代償は「途中の前提」

生産実績データベース、品質検査記録、購買システム、設備稼働ログといった複数のソースを跨いで、AIが手順を自分で組み立てて結論まで進む形です。2026年に入って提案が急増している領域でもあります。

技術的には②の延長ですが、実務上のリスクは質的に変わります。エージェントは途中で必ず判断をします。「欠測している行は除外する」「単位が違うので換算する」「重複しているシリアルは新しい方を採る」といった判断です。これらは人間のアナリストなら注釈に書く内容ですが、エージェントの最終出力には現れません。

結果として、③の失敗は「結論は妥当そうなのに、その結論を支えている母集団が誰にも説明できない」という形を取ります。②が「使えない形の正解」なら、③は「検証できない正解」です。

③を導入するなら、②が安定して回っていることに加えて、権限（どのテーブルにどの範囲で触れるか）と監査（どの中間クエリを実行したかの記録）を先に設計する必要があります。順番を飛ばすと、事故が起きたときに原因を特定できません。

④ レポート生成｜最も現実的で、最も油断される

集計はすでに既存のBIや表計算で出ている。その数字を文章にする作業だけをAIに任せる形です。月次の品質報告書、稼働報告、経営会議向けサマリーが該当します。

冒頭で引いた帝国データバンクの調査で最多だった「文章の作成・要約・校正」45.1%には、この型がかなり含まれていると考えられます。つまり企業は、すでに実質的にデータ分析の一部をAIに任せています。ただしそれは「集計はしない」という条件付きです。

④の失敗は事実と作文の境界が曖昧になることです。「不良率は0.35%でした」は事実ですが、AIは頼まなくても「前月から改善傾向にあります」と評価語を足します。この評価語は集計結果ではなく生成物です。数字は正しく、解釈は捏造されている、という報告書が出来上がります。

対策は単純で、事実を書く段落と評価を書く段落をテンプレート上で分離し、評価段落には必ず人間の名前を入れることです。この「どこまでを機械に渡し、どこから人が持つか」の線の引き方は、Excel作業のAI自動化で扱った転記の境界の議論とまったく同じ構造をしています。

精度を決めるのはモデルではなくデータ側の3条件

②の接続分析がうまくいくかどうかは、どのモデルを選ぶかでは決まりません。決めているのは、接続先のデータが次の3条件を満たしているかどうかです。

語彙｜NG_CD=07 が何を指すか、文書になっているか

列名、コード値、略語の意味が人間の読める形で定義されているか、という条件です。

不良コードの列に NG_CD という名前がついていて、値が 07 だとします。これが「はんだ不良」なのか「外観キズ」なのか「寸法外れ」なのかは、テーブルを見ても分かりません。多くの工場では、この対応表はベテランの頭の中か、10年前に作られたExcelの一部のシートにあります。生成AIは、この対応表が無ければ 07 が何なのかを知りません。

厄介なのは、AIが「分かりません」と言わないことです。列名から意味を推測し、それらしい集計を返します。QTY という列が「良品数」なのか「投入数」なのかを推測で決め、良品率を計算します。推測が外れていても、出力は正常に見えます。

語彙の整備とは、要するに次を書き出すことです。テーブルごとに、各列が何を表すか。コード値が使われている列は、値と意味の対応表全件。社内でしか通じない略語（WIP、ADJ、RTN、SCRAP など）の展開。この3つを書き出せない領域は、接続分析の対象から外すのが正解です。

粒度｜1行が何を表すかを、例外込みで定義できるか

2つ目は、テーブルの1行が何を表しているのかという条件です。1行が1個なのか、1ロットなのか、1シフトなのか、1検査記録なのか。これが混ざっているテーブルは実務では珍しくありません。

さらに問題なのは例外側の定義です。次の4つが定義されていないと、集計は必ずずれます。

• 重複: 再測定した検査結果が2行になる場合、両方数えるのか、新しい方だけ数えるのか
• 取消: 誤入力の取消が、数量マイナスの行として入るのか、元の行の削除として処理されるのか
• 再投入: 手直し後に同じシリアルがもう一度流れたとき、投入数を2と数えるのか1と数えるのか
• 欠測: 設備が停止している時間帯に行そのものが出ないのか、0という値の行が出るのか

特に欠測は事故が多い箇所です。行が存在しないことと、値が0であることは意味が違います。生成AIに平均を計算させると、行が存在しない時間帯は分母から落ちます。稼働率を出したいのに、止まっていた時間だけが集計から消える、という結果になります。

記録の設計としてこの粒度をどう持つかは、品質データ管理システムの3層設計で整理しています。生成AIを入れる前に片付いていれば理想的ですが、多くの場合は同時に着手することになります。

境界｜いつからいつまでが「同じ意味のデータ」か

3つ目は時間の境界です。いつからいつまでのデータが、同じ定義で記録されているのか。

工場のマスタは変わります。2025年10月に工程名を変えた。不良コード体系を統合して、旧コードの07と09を新コードの12にまとめた。品番の採番規則を変えた。ライン増設で設備IDを振り直した。こうした改定は日常的に起きます。

問題は、改定履歴が残っていないことです。マスタが上書き更新されていると、過去のデータを現在のマスタで解釈することになります。生成AIに「過去3年の不良傾向を分析して」と頼めば、旧コード体系の期間と新コード体系の期間を、同じ名前で足し合わせた結果が返ってきます。トレンドが変わって見えますが、それは現場が変わったのではなくコード体系が変わっただけです。

境界の整備とは、次を持つことです。マスタの改定日と改定内容の履歴。旧コードと新コードの対応表。そして「この分析はいつ以降のデータのみを対象とする」という宣言を、クエリまたはプロンプトの側に書き込むこと。

この3条件は、どれかが欠けていると他の2つで補えません。語彙があっても粒度が定義されていなければ、正しい名前で違う数を数えます。粒度が定義されていても境界が無ければ、正しい数え方で違う期間を混ぜます。3つ揃って初めて、接続分析の出力を業務判断に使えます。

ベンチマークが示す「実データベースでの限界」

3条件の話をすると、「それはモデルが賢くなれば解決するのでは」という反応が返ってきます。この点は、公開ベンチマークの数字である程度は答えられます。

自然言語からSQLを生成する精度を測る代表的なベンチマークにBIRDがあります。12,751件の質問とSQLのペア、95のデータベース、合計33.4GB、37分野以上をカバーする、実データベースに近い構成のベンチマークです。

このBIRDのリーダーボードで、testセットの実行精度は最高でも81.95%です。devセットでは77.64%（AskData + GPT-4oの構成）となっています。一方、同じ課題に対する human performance は 92.96 と記録されています。

この81.95%という数字の読み方には注意が必要です。これは「実データベースに対する自然言語からSQLへの変換の、ベンチマーク上の最高値」であって、「生成AIの分析精度は8割」という一般化はできません。ベンチマークの質問は、対象データベースのスキーマと外部知識の説明が与えられた状態で解かれています。つまり、前章で述べた語彙と粒度が、ベンチマーク側からあらかじめ提供されている条件下の数字です。

さらに、対話や実操作を伴う設定になると数字は大きく落ちます。BIRDには対話・実操作を伴う設定であるBIRD-Interactがあり、こちらの成績は最高でも24.4%、設定によっては17.78%台にとどまります。人間のアナリストが実際にやっている作業、つまり「聞き返しながら、途中結果を見ながら、条件を詰めていく」形に近づけるほど、成績は下がります。

ここから読み取るべきは「生成AIは使えない」ではありません。スキーマと語彙が整備された状態でも2割弱は外す。整備されていなければ話にならない、ということです。モデルの進歩は3条件の代わりにはなりません。

「答えは合っているのに使えない」という失敗の形

現場で実際に起きる失敗は、実は「間違った数字が出る」よりも厄介な形を取ります。

AIMultiple が2026年に公開した検証は、36のモデルを759問で比較したものです。この検証では、strict execution match（実行結果が厳密に一致すること）で測ると最高でも 0.551 にとどまりました。BIRDのリーダーボードの数字と比べて低く見えますが、これは評価の厳しさが違うためです。

同じ検証で示された、実務上もっとも重要な指摘がこれです。射影の違いだけで22.7ポイント落ちるモデルがある。射影の違いとは、余分な列が付いている、列の順序が違う、集計単位が違う、といった差です。求めた数字そのものは合っているのに、出てきた表の形が期待と違う。それだけで「不正解」になります。

現場では、これは不正解として扱われません。もっと悪い形で扱われます。人間が受け取って、目視で必要な列だけ抜き出し、順序を並べ替え、単位を揃えて、それから使います。つまり手作業が発生します。自動化のために入れたはずの仕組みが、毎回の後処理を生みます。しかも後処理をしている本人は「AIは正しく答えている」と認識しているので、問題として報告されません。

具体的にどういう形で現れるかを、工場の例で書きます。「先月、不良金額の大きかった工程を上位5つ出して」と聞いたとします。返ってきたのは、工程コードと不良金額の2列、金額の降順で5行の表でした。数字は合っています。ところが、この表は会議に出せません。工程コードのままで工程名が無いからです。会議に出席する人間は工程コードを覚えていません。次に「工程名も付けて」と頼むと、今度は工程名と工程コードと不良金額と不良件数と対象期間の5列が返ってきて、行の順序が工程コード順に変わっています。数字は合っています。しかし、先月使った資料と列の並びが違うので、前月と並べて比較できません。

この往復が毎月発生します。1回あたり10分から15分程度で終わることが多く、誰も問題として報告しません。ただし、レポート作成の工数削減を目的に導入した場合、この往復は削減時間から差し引かれています。本稿後半の試算でシナリオAの削減時間を12時間と控えめに置いているのは、この往復を織り込んでいるためです。

集計単位のずれも同じ形で起きます。「不良率」と聞いたときに、AIが不良件数を投入数で割るのか、不良金額を生産金額で割るのか、あるいは検査ロット単位の不良ロット率を出すのかは、指示しなければ決まりません。3つとも「不良率」と呼ばれ、3つとも正しく計算されます。そして数字は当然一致しません。前章の語彙の整備は、この曖昧さを消すための作業でもあります。

同じ検証では、BIRDのgoldクエリ（正解とされているSQL）の31.1%に問題があるという指摘も出ています。ベンチマークのアノテーション誤りを分析したCIDR 2026の論文でも同じ問題が扱われています。つまり「正解」の定義自体が揺れているということです。これは学術的な論点であると同時に、実務への示唆でもあります。社内で「正解」を定義しない限り、正しさは測れません。

設計で潰す3つの手当て

「使えない形の正解」を減らすには、モデルを変えるのではなく、出力の側に制約を置きます。実務で効くのは次の3つです。

第一に、出力の形を先に固定することです。どの列を、どの順序で、どの集計単位で出すかを、質問の前に決めておきます。よく使う質問についてはテンプレート化し、AIには「この形に埋めろ」と指示します。自由な形で出させるのは探索のときだけにします。

第二に、検算レイヤーを必ず1本置くことです。既知の値と突き合わせる固定クエリを用意します。たとえば「先月の総投入数」のように、別系統（月次締めの帳票など）で確定している数字を1つ選び、AIが使った母集団から同じ数字を出させて一致するか見ます。一致しなければ、その分析結果は捨てます。この1本があるかどうかで、運用の安全性がまったく変わります。

第三に、AIに出させるのは「数字」ではなく「数字＋その数字を出した範囲の定義」にすることです。出力の末尾に、対象期間、対象工程、除外した行の条件、使ったマスタのバージョンを必ず併記させます。これがあれば、数字を見た人が母集団の妥当性を判断できます。無ければ、判断できるのは数字を出した本人だけです。

この3つは、いずれもモデルの選定とは無関係です。どのモデルを使っても必要で、どのモデルを使っても効きます。逆に言えば、この3つを置かずにモデル比較をしても意味がありません。

タイ拠点で追加で崩れる4つのところ

以上は日本国内の工場でも共通する話です。タイに製造拠点を持つ場合、これに4つの要因が上乗せされます。

言語の混在が1つ目です。列名が英語、区分値の説明が日本語、実際に入力される自由記述欄がタイ語、というテーブルは珍しくありません。同じ「外観不良」を意味する記述が、日本語、英語、タイ語の3通りで入っています。生成AIは3つを別物として数えます。集計単位を作る前に、正規化の対応表が要ります。

シフト暦と祝日が2つ目です。タイの祝日は年ごとに官報で告示され、振替や特別休日も年により変わります。24時間3交替の拠点では、日付の切り替わりとシフトの切り替わりが一致しません。「今月の不良率」を出すとき、月末最終シフトが翌月にまたぐのか当月に含めるのかは、拠点ごとのルールです。このルールがマスタになっていないと、AIはカレンダー日で切ります。実績帳票はシフト暦で切られているので、両者は必ず食い違います。そして食い違いは経験上わずかな幅にとどまるので、見ただけでは気づけません。

マスタの人手更新が3つ目です。品番マスタ、工程マスタ、不良コードマスタが担当者のExcelで管理され、更新のたびに上書きされているケースは多く見られます。この状態では前章の「境界」が原理的に作れません。生成AIを入れる前に、少なくとも改定日と改定内容だけは別シートに追記していく運用に変えておく必要があります。

そもそものデータ源が4つ目です。設備からの実績が紙の日報経由で1日1回入力されている場合、日次追跡はできません。生成AIの前に、データが出てくる頻度の問題です。設備側から自動で実績を取る場合の投資規模については工場IoTの費用を5層に分解した記事で扱っています。

こうした状況は、統計にも表れています。ETDA（タイ電子取引開発機構）の Thailand Digital Outlook 2026 では、タイ企業のデジタル成熟度スコアが4点満点中 2.12 と報告されています。前年の 1.56 から上昇しており、調査対象は834社です。この 2.12 はデジタル成熟度スコアであって、AI導入率ではない点に注意してください。改善はしているものの、4点満点の半分をわずかに超えた水準です。

AI導入そのものについては、2024年のETDA調査（580社）で、導入済み18%、検討中73%という数字が出ています。この調査では、導入の障壁としてデータ品質への懸念が挙がっています。本稿でここまで述べてきた3条件の話と、指摘の内容は一致します。

費用と回収の独自試算｜タイ日系工場・3シナリオ

ここからは金額の話です。以下の数字はすべて本稿の積み上げであり、市場の相場ではありません。自社の条件に合わせて置き換えて読んでください。

前提は次のとおりです。

• タイの日系工場、従業員300名規模、年産1,200,000個
• 月次の不良・稼働レポート作成に、生産管理2名が月20時間ずつ、合計で月40時間を使っている
• スタッフの月給 25,000 THB、月160時間勤務。時間単価は 25,000 ÷ 160 = 156.25 を切り捨てて 156 THB とする
• 不良1件あたりの損失は、材料費と手直し工数と出荷調整の合計で 180 THB と置く
• 現状の不良率は 0.35%

時間単価の 156 THB について、先に断っておきます。これは下限であって回収根拠ではありません。レポート作成に使われている時間を賃金で換算しただけの数字です。実際には、その時間で別の改善ができたはずだという機会損失があり、そちらのほうが大きい可能性が高い。ただし機会損失は見積もりに幅が出るため、本稿では意図的に下限だけを使います。賃金換算だけで成立するシナリオがあるなら、それは堅い、という読み方をしてください。

この前提で、整備範囲の違う3つのシナリオを比較します。

表だけ見ても、なぜこうなるのかは分かりません。以下、シナリオごとに算術を分解します。電卓で追える形にしてあります。

シナリオA｜全社で貼り付け分析

全部門に生成AIのアカウントを配り、語彙表とプロンプトのテンプレートだけ用意する構成です。データベースには接続しません。各自が手元のCSVを貼って使います。

初期費用 60,000 THB は、語彙表の作成とテンプレート整備、社内説明会の工数です。年間運用 30,000 THB は、ライセンス費と語彙表の維持です。

便益はこう計算します。月40時間かかっているレポート作成のうち、貼り付け分析で削減できるのは12時間と置きます。集計の下ごしらえは結局手作業のままなので、削減できるのは文章化と体裁調整の部分です。

12時間/月 × 12ヶ月 = 144時間。144時間 × 156 THB = 22,464 THB。

これが年間便益です。年間運用の 30,000 THB を下回っています。純便益は 22,464 − 30,000 = ▲7,536 THB。初期の 60,000 THB を回収する以前に、毎年赤字が積み上がる構造です。

誤解しないでほしいのは、Aが無価値だという話ではないことです。文章生成や要約の用途では十分に元が取れます。「データ分析」という用途に限定して測ると赤字になる、というのがこの試算の意味です。冒頭の帝国データバンクの数字で、データの集計・分析が7.4%にとどまっている背景の一部はここにあります。

シナリオB｜全データを接続分析

生産管理システム、品質データベース、設備稼働ログのすべてについて、語彙・粒度・境界の3条件を整備し、生成AIから接続する構成です。いわゆる「全社データ基盤」に近い発想です。

初期費用 450,000 THB は、全工程分のマスタ整理、コード対応表の作成、粒度定義、マスタ改定履歴の整備、接続と検算レイヤーの構築です。年間運用 120,000 THB は、ライセンスと基盤運用、マスタ改定の反映作業です。

便益は2つの要素からなります。

第一に工数削減です。月40時間のうち28時間が削減できると置きます。集計まで接続分析で取れるようになるため、Aより大幅に大きくなります。

28時間/月 × 12ヶ月 = 336時間。336時間 × 156 THB = 52,416 THB。

第二に不良の削減です。データが見えるようになることで、不良率が 0.35% から 0.30% に下がると置きます。差は 0.05ポイントです。

1,200,000個 × 0.0005 = 600個。600個 × 180 THB = 108,000 THB。

合計すると、52,416 + 108,000 = 160,416 THB が年間便益です。年間運用 120,000 THB を引くと、160,416 − 120,000 = 40,416 THB が年間の純便益になります。

初期費用の回収年数は、450,000 ÷ 40,416 ≒ 約11.1年です。設備投資として通る数字ではありません。

シナリオC｜1テーマ限定の接続分析

不良金額の上位3工程に対象を絞り、その3工程についてだけ語彙・粒度・境界を整備して接続する構成です。他の工程は当面①の貼り付け分析のままにします。

初期費用 180,000 THB は、3工程分のマスタ整理と接続、検算レイヤー1本の構築です。年間運用 60,000 THB は、ライセンスと3工程分のマスタ維持です。

工数削減はBより小さくなります。対象が3工程だけなので、レポート作成のうち削減できるのは16時間と置きます。

16時間/月 × 12ヶ月 = 192時間。192時間 × 156 THB = 29,952 THB。

Bの 52,416 THB に対して、削減額は6割弱です。ここまではBが優勢に見えます。

不良削減が逆転します。対象が3工程に絞られているため、日次で追跡できます。毎日見ているので、異常が出てから是正に着手するまでが平均2週間早まると置きます。この結果、不良率は 0.35% から 0.28% に下がると想定します。差は 0.07ポイントです。

1,200,000個 × 0.0007 = 840個。840個 × 180 THB = 151,200 THB。

合計すると、29,952 + 151,200 = 181,152 THB。年間運用 60,000 THB を引いて、181,152 − 60,000 = 121,152 THB が年間の純便益です。

回収年数は、180,000 ÷ 121,152 ≒ 1.49年。月に直すと 17.8ヶ月です。

整備範囲を広げるほど回収が遠のく

3つのシナリオを並べると、直感に反する結果が出ています。

Bは削減時間が最大なのに回収に11.1年かかり、Cは削減時間がBの6割弱でも17.8ヶ月で回収します。

差を作っているのは工数ではありません。工数削減額はBが 52,416 THB、Cが 29,952 THB で、確かにBが上です。逆転を起こしているのは不良削減額のほうで、Bが 108,000 THB に対してCは 151,200 THB です。

なぜ対象を絞ったCのほうが不良削減が大きくなるのか。理由は、是正が早まるかどうかは対象を絞ったときにだけ成立するからです。

全工程のデータが見えるようになっても、人間が毎日見る指標の数は増えません。20の指標が日次で更新されるダッシュボードは、実務では週に1回まとめて眺める対象になります。一方、3工程の不良率だけを毎朝見るのは続きます。続くから、異常に気づくのが早くなる。気づくのが早いから、是正が早まる。是正が早まった分だけ不良が減る。この連鎖が成立するのは、見る対象が絞られているときだけです。

言い換えると、便益の主要因は「データが見えること」ではなく「行動が変わること」です。そして行動が変わるかどうかは、整備範囲の広さと逆相関します。

もうひとつ、Bには構造的な負担があります。年間運用 120,000 THB のうち大きな部分はマスタ改定の反映作業です。整備した工程が多いほど、マスタ改定のたびに直す箇所が増えます。つまりBは、便益が頭打ちになる一方で、運用費だけが対象範囲に比例して増える構造をしています。この非対称が11.1年という数字を作っています。

したがって、生成AIのデータ分析への投資判断は「どこまで整備するか」ではなく「どこを整備しないと決めるか」の判断になります。整備しない範囲を明示的に決められないプロジェクトは、Bの経路をたどります。

なお、この試算のような効果の測り方そのもの、つまり何を便益に数えて何を数えないかの設計については、AI導入の効果測定で枠組みを整理しています。試算の前提を自社で置き換える際の参考になります。

どの型から始めるかを決める判断表

ここまでの内容を、実際の意思決定の形にまとめます。判断は2つの問いだけで分岐します。

1つ目の問い。日次で追う価値のある指標が1つに絞れているか。 「絞れている」とは、その指標が悪化したときに誰が何をするかまで決まっている状態を指します。見たいだけの指標は含めません。

2つ目の問い。その指標の語彙・粒度・境界を、今日書き出せるか。 具体的には、その指標を構成する列の意味、コード値の対応表、1行が何を表すか、例外の扱い、いつ以降のデータが同じ定義か。これらを今日中に文書にできるかどうかです。

この2つの答えで、着手すべき型が決まります。

この表で「②に着手すべき」となる企業は、実務では多くありません。多くは2行目か4行目に該当します。そしてそれは失敗ではなく、正しい現在地の把握です。3条件が書き出せない状態で②を発注すると、シナリオBの経路に入ります。

2行目に該当する場合の進め方を補足します。3条件の整備は、全社でやると本稿のシナリオBになります。避けるには、整備の単位を「絞った1指標が参照するテーブルだけ」に限定します。実務的には、対象指標の計算に直接使う列だけを洗い出し、その列についてのみ意味とコード対応表を作ります。同じテーブルの他の列は手を付けません。この割り切りができるかどうかが、17.8ヶ月と11.1年を分けます。

また、整備の成果物は文書として残してください。生成AIのプロンプトの中に埋め込むだけにすると、モデルを変えたときやツールを乗り換えたときに消えます。語彙表、粒度定義、境界の宣言の3点は、ツールから独立した資産です。ツールは数年で入れ替わりますが、この3点は入れ替わりません。投資の実体はツールではなくこちらにあります。

③のエージェント分析は、この表のどこにも登場しません。②が安定して回り、検算レイヤーが機能し、権限と監査の設計が済んだ後に検討する対象だからです。提案を受けている段階であれば、②の実績を先に作ることを条件にしてください。

なお、生成AIによる分析と、需要予測のような統計モデル・機械学習モデルは別の話です。将来値を当てにいく話については需要予測AIの記事で扱っており、必要なデータの条件も評価の方法も本稿とは異なります。混同すると要件定義が崩れます。

よくある質問

生成AIにデータ分析をさせるのに、どんなデータが必要ですか

量ではなく定義が必要です。具体的には3つです。対象テーブルの各列が何を表すかの説明、コード値が使われている列の値と意味の対応表、そして1行が何を表すかと例外（重複・取消・再投入・欠測）の扱いの定義です。加えて、いつ以降のデータが同じ定義で記録されているかの境界を決めます。この4つを書き出せない範囲は、データ量がどれだけあっても接続分析の対象になりません。逆に、この4つが揃っていれば、対象が3工程だけでも成立します。着手の順番は、データを増やすことではなく、既にあるデータの定義を書き出すことです。

生成AIのデータ分析はExcelの置き換えになりますか

集計の置き換えにはなりませんが、集計の前後は置き換わります。前は探索です。どの切り口で見るべきかの当たりをつける作業は、表計算でピボットを組み直すより速くなります。後は文章化です。集計済みの数字を報告書の形にする作業は、テンプレートを固定すれば十分に任せられます。一方で、確定した数値を出す集計そのものは、再現性と検証可能性が要求されるため、既存の仕組みに置いたままにするのが安全です。本稿のシナリオCも、集計基盤を捨てる前提ではなく、その上に問い合わせと文章化を載せる構成として積んでいます。

レポートの自動作成はどこまで任せられますか

事実の記述までです。評価と判断は分離してください。「不良率は0.35%でした」は集計結果を写す作業なので任せられます。「前月から改善傾向にあります」は生成物です。数値の推移が同じでも、それを改善と呼ぶかどうかは目標値と文脈の問題であり、AIはそれを知りません。実務的な対策は、テンプレートを事実段落と評価段落に分け、評価段落には記入者の名前を入れる運用にすることです。もう1点、出力の末尾に対象期間・対象工程・除外条件・使用マスタのバージョンを必ず併記させてください。これが無いレポートは、読んだ人が母集団を検証できません。

BIツールと生成AI、どちらを先に入れるべきですか

順番の問題ではなく、両者が必要とする準備が同じだという点が重要です。BIツールも生成AIも、語彙・粒度・境界が定義されていなければ正しい数字を出しません。BIは定義が間違っていても同じ間違いを毎回再現するので、いずれ誰かが気づきます。生成AIは質問のたびに違う解釈をする余地があるため、間違いが再現せず、気づくのが遅れます。この違いを踏まえると、確定値を出す用途はBIまたは既存の帳票に置き、生成AIは探索と文章化に置く分担が現実的です。どちらを買うかを決める前に、3条件の書き出しに着手してください。この作業はどちらを選んでも必要になります。

タイ拠点でタイ語混じりのデータでも分析できますか

分析はできますが、正規化の対応表を先に作る必要があります。実務で問題になるのは、モデルがタイ語を読めるかどうかではありません。同じ事象が日本語・英語・タイ語の3通りで記録されていて、それが別物として集計されてしまうことです。不良区分、停止理由、工程名の3つについて、表記ゆれを1つの正規値に寄せる対応表を作ってください。自由記述欄をそのまま集計対象にするのは避け、区分値の列を新設して選択式にするのが結果的に早道です。加えて、シフト暦と祝日カレンダーをマスタとして持つこと。タイの祝日は年ごとに官報で告示され振替も発生するため、これをカレンダー日で代用すると集計期間が実績帳票とずれます。

まとめ

本稿の論点を整理します。

• 生成AIを業務で活用している企業でも、用途「データの集計・分析」は7.4%にとどまります（帝国データバンク、2026年3月、有効回答10,312社）。最多の「文章の作成・要約・校正」45.1%の6分の1です。この7.4%は全企業に対する比率ではなく、活用企業の中での用途割合です
• 伸びていない理由は需要不足ではなく、やってみて通らないからです。データ分析の失敗は、文章生成と違って見ただけでは分かりません
• 「生成AIでデータ分析」は4つの型に分かれます。①貼り付け分析、②接続分析、③エージェント分析、④レポート生成。準備するものも失敗の出方も違うため、混ぜて議論すると噛み合いません
• 精度を決めるのはモデルではなくデータ側の3条件です。語彙（NG_CD=07 が何かが文書になっているか）、粒度（1行が何を表し、重複・取消・再投入・欠測をどう扱うか）、境界（いつからいつまでが同じ定義か、マスタ改定履歴が残っているか）
• 実データベースに対する自然言語からSQLへの変換は、ベンチマーク上の最高値でも test 81.95%（BIRD）で、human performance の 92.96 に届きません。対話・実操作を伴う設定であるBIRD-Interactでは最高でも24.4%、設定によっては17.78%台です
• 現場で起きるのは「間違った数字が出る」より「使えない形で正しい数字が出る」失敗です。射影の違い（余分な列・列順の違い・集計単位の違い）だけで22.7ポイント落ちるモデルがあります（AIMultiple、2026年、36モデル×759問）
• 対策は出力の形を先に固定すること、検算レイヤーを1本置くこと、数字と一緒にその数字を出した範囲の定義を出させることです。いずれもモデル選定とは無関係に効きます
• タイ拠点では、言語の混在、シフト暦と祝日、人手更新のマスタ、データ源の頻度の4つが上乗せされます。ETDAのThailand Digital Outlook 2026では、タイ企業のデジタル成熟度が4点満点中 2.12（前年 1.56、834社）と報告されています。これは成熟度スコアであってAI導入率ではありません
• 3シナリオの試算では、全データを接続するBが回収11.1年、1テーマに絞ったCが17.8ヶ月でした。差を作っているのは工数削減額ではなく、是正が早まることで減る不良の量です。これは対象を絞ったときにだけ大きくなります。金額はすべて本稿の積み上げであり、相場ではありません
• したがって投資判断は「どこまで整備するか」ではなく「どこを整備しないと決めるか」です。整備しない範囲を明示できないプロジェクトは、回収の遠い経路をたどります

生成AIのデータ分析が通らないのは、モデルの性能が足りないからではありません。渡しているデータの意味が、社内でも文書になっていないからです。そして、その文書化は全社一括でやると回収が遠のきます。1つの指標に絞れば、17.8ヶ月という数字が見えてきます。

TOMAS TECHは、タイの日系工場向けに生産管理と品質データの基盤を構築しています。接続の話に入る前の段階、つまり日次で追う価値のある指標を1つに絞れるか、その指標の語彙・粒度・境界を今日書き出せるかを一緒に棚卸しするところからお手伝いできます。まだ製品を決めていない段階、どのデータが使えるのか分からない段階からで構いません。自社のデータが接続分析に耐えるかを確かめたい場合は、お問い合わせからご相談ください。

参考情報

• 帝国データバンク｜生成AIに関する企業の動向調査（2026年3月）
• BIRD ベンチマーク公式サイト
• AIMultiple｜Text-to-SQL Comparison of LLM Accuracy in 2026
• CIDR 2026｜Text-to-SQL Benchmarks are Broken – An In-Depth Analysis of Annotation Errors
• Bangkok Post｜AI adoption helps Thai firms become digitally mature
• Bangkok Post｜Data quality concerns a barrier to adoption of AI