生成AIの活用が急速に広がる一方ですが、現場のデータは必ずしもAIがそのまま使える状態で整っているとは限りません。業務の中で生まれる情報は形式も粒度もばらばらで、多くは人の判断や経験に依存したまま蓄積されています。
AIエージェントのように仕事を任せられる技術が現実味を帯びるほど、こうしたデータの扱い方が現場の課題として浮かび上がってきます。JDSCとEAGLYSは、こうした背景を踏まえ、非構造データを含むデータ整備に向き合うための「非構造データ整備パッケージ」の開発を進めています。
本対談では、AIエージェント時代を見据え、データをどのように集め、整え、現場で使える形にしていくのかについて、JDSCのTechnical Co-Funder 橋本さんと、EAGLYS代表の今林が、エンジニア出身の視点からAIとデータのこれからを語ります。

AIは進化したのに仕事は進化しない？—RAGの次に来る“エージェント化”と現場のデータギャップ

橋本：
まず、AIの活用は大きく２つの方向に進んでいますよね。１つ目は、いわゆる「RAG」です。JDSCの事例だと、「AI番頭」がそれに当たるのですが、人が自分で調べたり整理したりしていた作業を、AIアシスタントに任せて効率化するというものです。これは既に多くの人ができるようになってきています。
２つ目は、調べものが楽になるというレベルを超えて、仕事そのものをより“エージェンティック（自律的）”にする方向です。AWSでは「エージェンティックAI」と呼んでいますが、定型業務なら一定の範囲まで自動で任せられるようになってきました。エンジニアも、もう自分でコードを書かず仕様だけを書く人が増えてきていますし、自分でコードを書く人もCopilotを使って、仕事の半分くらいはAIと一緒にやってしまっている。昔で言えば、街の電気屋の店員さんがそろばんから電卓を使うように変わったようなものです。仕事の横にAIが常にいて、自然に使うのが当たり前になってきています。

目下、自分が取り組んでいる案件でも、AIを活用した定型業務の自動化があります。例えば、申し込みメールやフォームデータなど、これまで人手で処理していた“新規受付の定型業務”を、言語モデルが一通り処理してくれるように準備が進んでいます。これまで20個も入力しなければならなかったフォームが、AIのおかげで2個だけで済む、といった世界が現実になりつつあります。
こういう世界が「できてしまう」ようになった今、データをどう扱っていくかが本当に重要になりますね。

データに関して言えば、EAGLYSさんとJDSCは他社より少し特別な技術を持っていると思います。EAGLYSさんの秘密計算のように、無邪気には出せないデータでも安全に扱える技術がある。また、JDSCには、業界として知見を共有したいとき、一定のデータを持ち寄って共同で価値を出すという“コンソーシアムの思想”もあります。目的は、データそのものを囲うことではなく、「使える形にできればいい」という考え方です。ただし、ここで問題があります。
AIがこれだけ賢くなっても、仕事がそんなにきれいに回るわけではないということです。LLMは上品な日本語で返してくれますが、人間の方は「これは聞いてない」とか、そもそも入力作業が雑だったりする。データベースやデータウェアハウスは、入ってくるデータの“形”が決まっており、その形さえ守られていれば正しく処理が回るはずなんですが、現実はそうなりません。人間側の入力ミスや曖昧さの方がボトルネックになってしまうのです。
データエンジニアリングの弱点はまさにそこにあると思っています。JDSCの社内でも話題になっていたのですが、通常、通信プロトコルが少しでも狂うと通信エラーになりますよね。同じように、少しデータの形が違っていても本来は処理が止まるべきなのに、現場は努力と根性で“なんとか動かしてしまう”。その結果、人間が機械を補うために動くという、本来とは逆の構造になってしまっている。ここをどう正していくか、どこを機械に任せ、どこを人間が担うべきか。この点が今、社内でも大きな議論になっています。

今林：
整理すると、3つのポイントに集約されます。1点目は調べものの効率化、2点目はエージェンティックな業務推進、そして3点目がデータの持ち方と向き合い方です。
最近では調べものの大半がLLMで完結するようになり、「RAGを使えば解決する」という認識が広がっています。しかし、この「調べものを端折る」プロセスの裏側では、依然として膨大な人手によるデータ整備が行われているのが実情です。
特に製造業のクライアント企業では、安全・安心を最重要視しています。災害ナレッジ、不具合情報、クレーム対応、化学品の安全性など、一口に「安全性」といっても、化学品、素材、不具合、災害系と多岐にわたります。そのため、多くの人員を投入して膨大な情報に対応しているのです。年間あるいは累積で何千、何万件にも及ぶ不具合事象に対し、現場では図面をExcelに手入力したり、Word文書の内容をExcelに転記するなど、AIに読み込ませるために個別にExcelファイルを生成したりしています。

つまり「調べもの」の背後には、想像を超える量のデータ整備が人の手で行われている。これが最近、特に強く感じているポイントです。

「勝者の歴史しか残らない」—LLMがようやく扱えるようになった“製造業の暗黙知”の正体

橋本：
RAGのような仕組みを使うときにも、結局データの準備は避けて通れないんですよね。今、製造業の支援に取り組む中で大きな課題になっているのが、いわゆる“製造業の暗黙知”です。
設計書や手順書といったオフィシャルな資料は確かに存在しますが、データベースに入るのは“データベースとして扱える形のもの”だけです。しかも、多くの場合は成功した事例しか残らず、失敗したデータは記録されない。現場でも「担当者が覚えていればいいよね」と片付けられがちで、“暗黙知”という言葉だけが軽く使われている印象があります。
本当に厄介な暗黙知は、「当時の担当者は知っているけれど、データベースには入っていない情報」です。たとえば「XXを使うと壊れやすい」「この条件だと顧客体験が悪くなる」といった、概念としてフワッとしていて形式化しにくいテキスト。こうした情報はデータ化されず、どこかへ消えてしまう。
製造業ではよくあることで、若い担当者が部長に「これどうなってますか？」と聞くと、「いや、当時の○○さんに聞かないと分からないな」と、さらに人を辿ることになります。最終的にたどり着いたら、その人が今は取締役だった——なんて話もある。素材の選定理由や設計の背景など、本当に知っているのは当時の数名だけ、というケースは珍しくありません。
さらに厄介なのは“失敗のデータが残らない”ことです。成功の理由だけが記録され、なぜ失敗したか、どんな試行錯誤があったかといった情報は担当者の記憶にしか存在しない。まさに「勝者の歴史しか語られない」構造に似ています。
ただ、最近はLLMのおかげで、こうした“ぐちゃっとしたテキスト”でも扱えるようになってきました。担当者の備考や感想文のような情報を残しておけば、「なぜAではなくBを採用したのか」といった意思決定の背景も理解できる。失敗したブランチや、判断の履歴をコミットのように残しておくことで、後からまとめて振り返ることもできる。これまで失われ続けてきた知見を、ようやく扱えるようになってきたわけです。
RAGを使うアシスタントが便利になればなるほど、「正解は分かるけど、なぜこれが選ばれたの？」という文脈が重要になります。それが製造上の理由なのか、調達上の制約なのか、あるいは改善すべきものなのか、担当者だけが知っている状態では判断がブラックボックス化してしまう。だからこそ、データを集めてシステムに投入するために人手をかけることは、決して悪い投資ではないと思っています。担当者がExcelに落とす作業なども含めて、データ投入の段階で人間が手を動かすこと自体は悪くない。その基盤さえ整えば、自動化ができる範囲は一気に広がっていくはずです。

（左）JDSCのTechnical Co-Funder橋本さん

データ整備は“技術”より“組織”が難しい—現場に眠る暗黙知の壁

今林：
実際の研究開発現場では、実験パラメータや試行錯誤の経緯など、データベースに収まりきらない情報が数多く存在します。しかし、そうした暗黙知の蓄積にはコストがかかるため、「本当に費用対効果があるのか」という問いは必ず投げかけられます。ここが最初のハードルです。
 
例えば物品の調達において、「なぜこの樹脂を選定したのか」「なぜ剥がれやすい素材を回避したのか」といった判断の背景には、過去のトラブル事例や化学的な特性に関する経験知が存在します。こうした調達側のノウハウと、研究開発現場で蓄積されてきた実験知見が適切にリンクすれば、単一部署の課題解決にとどまらず、隣接部署の問題解決にも波及効果をもたらします。
 
これを実現するシステムを構築するには「データベースをいかにリンクさせるか」が鍵となりますが、構築における技術的難易度よりも、社内の推進体制や組織間調整のほうが大きな障壁となるケースが多いのです。様々な企業のDXチームでも同様の声が課題としてあがっており、組織横断で知見を活用していくために越えなくてはいけない大きな壁だと認識しています。

橋本：
データ基盤づくりやデータ整備への投資って、筋が良いことは誰もがわかっているんですが、どうしても費用対効果が見えにくい。でも、やれば必ず報われるんですよね。業務そのものが整理されて、仕事のやり方自体を見直すきっかけになる。本当は“この仕事って、別の人でもできるんだ”という状態に近づけるのが理想なんです。
日本企業は優秀な人が多くて、そこそこ情報が揃っていれば仕事が成立してしまうんですよ。たとえばコンビニのレジなんて、タバコの銘柄、税金の支払い、温め対応…あれだけ複雑なのに現場が回っている。でも、あれをデータの観点で高度に整理しようとすると、一気に難易度が上がる。結局、世の中にわかりやすいアプリケーションが存在して初めて、“これは投資しよう”となりがちです。
データ基盤やデータ整備をちゃんとやりましょう、というテーマはJDSCとしてもずっと苦戦しています。それだけを言ってもクライアントは投資しづらいし、コンサル的に“ビジネスプロセスも見直しましょう”と提案しても弱い。というのも、現場は今のやり方で一応回ってしまっているからです。
よく言われる“ダッシュボード”とか“BIツール”とか、“データの民主化”みたいな話も、実際にはそこまで現場が欲していないんですよね。経営層は喜ぶけど、BIツールを本当にBIとして使いこなしている人はほとんどいない。現場も別に幸せになっていない。
だからこそ、データ基盤や整備に踏み込む“おいしいタイミング”は、RAGやAIアシスタントを絡めて、自動化・効率化の文脈をセットで出せるときだと思います。“ノウハウを知らなくてもAIがよしなにやってくれる世界”を見せられる状況です。
実際、ピザ屋の予約なんかはすでにAIが普通にやり始めていますね。東池袋のピッツァサルバトーレのテスト店舗なんかだと、電話するとAIの音声認識が対応して、日時と人数を言えばそのままデータベースに書き込んでくれる。さらに、今の座席状況を見て“19時は満席ですが、18時か20時なら空いています”なんて返せるようになると、もうエージェントに近い体験になります。
でも、これが成立するには、AIが動くだけじゃダメで、裏側に“データをよしなに扱える仕組み”や“適切なインターフェース”が揃っていることが必要なんです。結局、AIもデータも、それをきちんと扱えるシステムの有無が成否を分ける。そう考えると、データ整備や基盤への投資って、本当に未来の業務の鍵になるんですよね。

AIがもたらす“現場のためのデータ民主化”—投資と価値のつながりが変わる

今林：
「データの民主化」というキーワードは、まさに的を射ていると感じました。これまでコンサルティング的アプローチで業務改革を試みても、現場が特段困っていないため、結局プロジェクトが頓挫するケースを数多く見てきました。
 
しかし、状況は変わりつつあると感じています。従来の「データの民主化」は、主に経営層やマネジメント向けに情報をサマライズして提供する、いわばトップダウン型のアプローチでした。ところが生成AIは、むしろ現場のための技術なのです。価値を創出できる層がまったく異なる。これは非常に大きな転換点だと考えています。生成AIの活用により、データの民主化が現場レベルで進むことで、新たな改善案やイノベーションのアイデアが次々と生まれるはずです。
 
後半でお話しされたピザ屋の事例が象徴的でした。従来のシステムは、予約を入力して「満席です」と返すだけの「制御ブロック型」でした。しかし今は、「その時間は埋まっていますが、18時か20時なら空いています」といった「提案型」へと進化しています。この違いは極めて大きい。
 
提案型アプローチにより、ユーザーの探索時間が劇的に短縮され、これはそのまま品質改善のバリューチェーンにも直結します。どのような価値とリンクさせられるかによって、実行可能な施策の幅が格段に広がるのです。

橋本：
AIに仕事をさせて、いわゆるエージェント的に動かすようになると、メリットがすごく伝わりやすいんですよね。『あ、それならぜひやりたい』という声も上がりやすい。何事にも“裾野”が広がるとピークも伸びるように、AIエージェントを導入したい、と言われる前には、本当はその手前で“データ整備”など、ちゃんとやらなければいけないことがたくさんあるわけです。でも、今まではそこが見えづらかった。
ただ、データ整備に投資するタイミングとして、今はすごく良いフェーズにきているとも思っています。AIの恩恵にあずかれる人が一気に増えて、裾野がぐっと広がった。これは技術の話というより“やり方”の話なんですが、たとえばトップ営業マンが持っている非常に貴重な営業ノウハウを、社内に共有してもらいたいと思う場面ってありますよね。でも、こちらがあまりに無邪気に『教えてください！』と言っても、そう簡単には教えてもらえないことが多い。本人にとってはそれが武器であり、差別化ポイントでもあるわけですから。
でも、組織や経営側にはもっと大きな目標があって、そのノウハウが共有されることで組織全体のパフォーマンスが上がる。実はこれって、“データベースに入らなかった暗黙知”の裏側の話でもあるんです。トップ営業マンの頭の中にあるノウハウが形式知化されないのと同じように、現場で蓄積された知見がデータとして残らず、埋もれてしまう。AIやエージェントの文脈では、こうした“共有されない知識”が表に出てくることに価値があるんです。

EAGLYSの今林

暗黙知をどう引き継ぐか—ノウハウ共有の“エモい”側面と文化づくり

今林：
データベースへの蓄積を進めることは重要ですが、同時に感情面への配慮も欠かせません。

橋本：
ノウハウを共有するって、やっぱりセンシティブなところもありますよね。給料が変わるとか、評価に影響するとか、そういう事情が絡んでくる場面もある。たとえば、裏道を熟知しているタクシードライバーが、そのノウハウをすべてシステムに入れたら、自分のお客さんが減るかもしれない、という不安が出てくる。そういう時に、組織としてどう手当てするかがすごく重要なんです。
以前、AIの実用化イベントで、ジュビロ磐田の部長さんとお話ししたことがあるんですが、人事部や強化部で『AIをどう活用できるか』というテーマで相談を受けたんです。J2以上のクラブになると、U-12やスクールなど育成組織も大きくて、そこで教える側のノウハウをどう継承するかが大きな課題になっている。練習メニューを考えるのも大変で、ベテランコーチも若手コーチも、それぞれが自分の経験値でなんとかしている状況なんですよ。
ただ、サッカー選手出身のコーチって、もちろん現場力は抜群なんだけれど、ExcelやWordが得意なわけではない。でもAIを入れると、その“入力の手間”をかなり省けるし、過去の練習メニューや指導ノウハウを引っ張ってくる仕組みも作れる。そうすると、ベテランコーチが『自分の蓄積してきた練習ノウハウを若手育成のために提供する』というモチベーションにつながる。クラブ全体が強くなることが自分にとっても喜びになるからです。
ジュビロ磐田って、かつてすごく強かった時代があるじゃないですか。“昔強かったジュビロを取り戻すぞ”という思いが組織の中にある。その想いがあるからこそ、『自分の経験を次世代に渡す』という行為が気持ちよくできる。なので、AIを導入する時は、技術的な話だけじゃなくて、こうした“エモい“ウェットな仕事の仕方”みたいな人間的な部分もすごく大事なんだと改めて感じました。

今林：
製造業の現場でも同様の課題があります。現場の方々から「なぜわざわざ音声を記録しなければならないのか」「自分の時間を奪われたくない」という声が上がることは少なくありません。だからこそ、「いかに気持ちよく、前向きにデータを入力してもらえるか」という設計が極めて重要になります。
 
単に「データを入力してください」では、人は動きません。その人にとって「意味がある」「自分にメリットがある」「現場が楽になる」という実感が必要です。どのような仕組みであれば負担に感じず、むしろ自分の業務を支援するツールだと認識してもらえるのか。そこを丁寧に設計することが、AI活用の成否を分けると考えています。
難しい課題ですが橋本さんはどのようなアプローチが有効だとお考えですか？

橋本：
正直、妙案ってそんなにないんですよ。でも、世代交代は必ずやってくるし、その前に現場の知見をちゃんと残しておきたい、という思いはズバッと言わないと伝わらない。こういう“ウェットな問題”は、やっぱりウェットに解決するしかないんですよね。
職人さんのノウハウを若手に引き継ぐ場面なんかはまさにそうで、人に関わる問題は、人でちゃんと向き合って解決しないといけない。しかも、その行為自体が評価される、褒められる対象になるようにすることがすごく大事で。そういう環境づくりまで含めて、データを残す文化を育てていかないといけないんだと思います。

今林：
「タッグプレー」という概念があると思うんです。例えば映画『ベスト・キッド』で、ジャッキー・チェンがいじめられている少年にカンフーを伝承していく。このような関係性で、熟練の職人と若手がタッグを組み、その若手がAIを活用して技術をデータ化していく、そんな未来がもっと広がればと思います。

橋本：
徒弟制度とか、師匠と弟子の関係って、昔からメリット・デメリットがあると言われてきましたよね。これまではデメリット寄りに語られがちだったけど、今ってむしろそこが脚光を浴びつつあると思うんです。つまり“ちゃんと残しておこう”という流れが生まれている。
テキストでいいから手順を記録しておく。しかも、単なる手順じゃなくて、職人さんの微妙な“勘”とか“経験”みたいな部分も、ある程度は数値に落とし込んでいく。たとえば獺祭のお酒づくりみたいに、まずは全部取っておく、という姿勢ですね。
職人のノウハウって繊細なものですが、これまではそれを置いておく場所がなかったし、何より“入れにくい”仕組みしかなかった。だからこそ今は、そうした知見をちゃんと残せる環境づくりがめちゃくちゃ重要なんだと思うんです。

今林：
まさに暗黙知ですね。これのデータ化は非常に難しい課題です。概ね2つの課題が浮上します。
 
暗黙知をデータとして蓄積するためには、「現場で自然に使用され、自然にデータが蓄積される仕組み」を構築することと、「どのようなAIを、どのようなインターフェースで接続するのか」という２点が大きな検討ポイントとなります。

橋本：
まず、暗黙知を可視化するなら“録音”は必須。できれば“録画”までしたい。作業している様子が見えて、話した内容もそのまま残るって、それだけで情報量が全然違うんです。
ただ一方で、音声デバイスに向かって人が自然にしゃべるって、実はまだあまり慣れていないんですよね。音声入力って本来は速いのに、実際には使ってる人が少ない。スマホに向かってブツブツしゃべるのって、ちょっと“きもい”感じがあるじゃないですか。でも、AIを本当に活用するためには、そこを“普通の行為”にしていく前段の努力が絶対に必要なんです。
 
それからもう１つ。“どうやってデータを貯めるか”。ここはもう、細かいことを言う前に「とにかくデータを入れてしまう」のが大事なんだと思います。世の中には“とりあえず入れてください”タイプのサービスがたくさんありますが、それで良いんです。昔は「前処理してからデータ入れて」って言ってたけど、それがむしろデータが集まらない原因になっていた。今は、とにかく生データでいいから全部入れてしまって、あとでバッチ回して整形すればいい。何も入っていないことに比べたら、圧倒的に前に進めるんですよ。

今林：
おっしゃる通りで、暗黙知は、「背中を見て覚えろ」という形で継承されるノウハウなので、結局、音声や動作など、多様な情報を記録するしかありません。しかし、これらのデータを記録されることには、心理的な抵抗感があると感じています。無理に入力させるのではなく、より自然に、気負わずにデータが集まっていく仕組みを構築することが理想形だと考えています。

橋本：
料理番組って、講師と聞き手がセットですよね。例えば料理研究家さんが1人で進めたら、きっとご自分のペースで進んで終わっちゃう。でも実際にはアシスタントさんが横でツッコミを入れたり、「ここではまだ入れないんですね？」みたいに確認してくれたりする。ああいう“枠組みの中で、解釈しながらわかりやすく伝えてくれる聞き手”がいると、すごく良いんじゃないかと思うんです。

今林：
非常に共感できるお話です。暗黙知について語る際、「AIのヒアリング装置を設置すれば、自動的にデータが蓄積される」と考える方がいらっしゃいますが、実際の暗黙知は、目の前に設計図や部品表といった「題材」があってこそ、「そういえば…」とインスピレーションが湧くものなのです。突然「面白い話をしてください」と言われても困惑するだけですが、対話の中で自然と思い出すことがある。そのための「媒介となるコンテンツ」を適切に用意できるかどうかが、暗黙知の蓄積におけるホスピタリティとして非常に重要だと考えています。

※後編はこちら

データ・AI・エンジニアリングをつなぐ、新しい価値創造のかたち