前編では、AI活用の現状と課題、そして現場データの取り扱いについて対談しました。AIは調べものや定型業務を効率化する一方で、仕事の本質や暗黙知の蓄積までは進化していません。特に製造業を例にして、成功事例しか残らず、失敗や試行錯誤の情報は暗黙知として個人に依存している現状があります。こうした知見を扱いやすい形で蓄積・共有するためには、単なる技術よりも組織文化やデータ整備の仕組みが重要です。AIエージェントを効果的に活用するには、現場の負担を減らしつつ自然にデータを集める環境設計が鍵であり、人間の知識とAIが協働する“橋渡し”のあり方が議論されました。
橋本：
ラクするためには最初にちゃんと頑張らないといけないんですよね。本来データって“約束事が守られている”前提で扱うものなのに、現場ではプロトコルが守られないまま無邪気にデータをやり取りしてしまう。ヘッダーが一つズレているだけで本来は受信できないはずなのに、システムがギリギリ受け取ってしまうことだってある。じゃあ、その曖昧さを人間側がどう扱うのか、という問題が出てくるわけです。
先日JDSCでは、ここを『データ契約』という概念で盛り上がったんですよ。プロトコルやインターフェース定義なら“守らなければ動かない”で話が終わるんだけど、ビジネスの現場って、微妙に形や内容が違うデータが普通に飛んでくる。それを前処理で吸収し続けるのが当たり前になってしまう。でも本当は、完全なルールではなくても、“データをやり取りするならお互いに契約がある”という構造にして、不履行をした方が悪いというスタンスで臨むべきだ、とデータエンジニアリングの観点から議論が盛り上がったんです。
今林：
なるほど。理解できます。AIにとって「どのようなデータを参照したのか」を明確にすることは非常に重要で、そこにはデータ品質の問題が付随します。AIの回答ではなく、そもそも参照したデータについて、誰に責任があるのかを明確にする必要がある。曖昧なまま「なんとなく動作してしまう」状態を許容するのではなく、データのやり取り自体に責任の所在を明確化しようという世界観ですね。
橋本：
データのやり取りって、単に“できる・できない”の話じゃないんですよね。訳のわからないデータを使ってしまった時に、送った側が悪いのか、使ってしまった側が悪いのか——そこを最初から決めておくと、お互いちゃんと気をつけるようになる。まさに契約みたいに約束事を決めていくイメージです。
じゃあ、それはプロトコルと何が違うのかというと、プロトコルほどカチッとした仕様ではなく、もう少し柔らかい“合意”に近い。データエンジニアリングやデータ分析を進めるときに必要な考え方で、これはうちのデータサイエンティストの受け売りなんですけどね。
今林：
人間の世界で当たり前に行われているやり取りや約束事を、そのままデータの世界でも再現する様なアプローチですね。
橋本：
そうなんですよ。仕様や要件を決めるって、結局はいろんな人が“不確実性と戦いながら”仕事しているということです。だから、仕様を最初に全部決めきるのって本当に難しい。でも決まりきる前に動き始めなきゃいけない場面が多い。家を建てるみたいに“後戻りできない”仕事なら別ですが、データを扱うとか、プログラムを書くとか、システムを作る領域では、むしろ“作りながら直す”のが正しいやり方なんですよね。直すコストもそこまで大きくないし、その柔軟性こそが価値になる。
今林：
非常に興味深いですね。とはいえ、目先の対応としてはどうすべきでしょうか。
橋本：
目先の話でいえば、これまで“とりあえずよろしく”と雑に渡していたデータに、ちょっと気を遣うだけでも全然違うんですよ。データエンジニアリングの現場って、雑に投げられたデータを何とか調整して受け取ってきたけれど、本当はお互いが気持ちよく、効率よく仕事できるように“契約”として約束していくべきなんですよね。
一方で、物を作る現場にはもっと硬いプロセスがあって、それはそれで必要。でも、そのプロセスを今までより扱いやすくしてくれる技術が言語モデルなんです。製造業の現場だと“フィジカルAI”とか、広く言えば物理シミュレーションも進化してきて、ようやく使えるようになってきた。ただ、すごい成果がドンと出るかというと、そういう派手なものではないんですよ。新幹線の鼻の形が流体力学シミュレーションで革新された、みたいな例はあるけど、ああいうのは本当にレアケースだと思います。
現実には、機械学習やデータサイエンスって“新しい何かを発見する”よりも、“持っている仮説が合っていそうかどうかを検証する”ために使われることの方が圧倒的に多い。『なんとなくこれが正しそう』を確かめるとか、事故を劇的に減らすとか大きな発見というよりも、仕事の進め方そのものがAI込みでもう少し良くなる、そんな地味だけど確実な改善が近い将来に起きるだろうな、と感じています。大きな効果につながるというより、“日々の仕事の質がじわっと良くなる”イメージですね。
今林：
先ほどのお話から連想したのですが、最近起きている「SaaS疲れ」は本当に象徴的だと感じています。近年、ERPの様な大型システムでカバーしきれない業務の細かなところを解決するSaaSが多くあり、当社でも様々なサービスを導入しています。SaaSは、単体の業務を安価に解決できるので非常に導入しやすいのですが、採用管理は向上してもオンボーディングはスコープ外であったり、別途労務管理システムが必要になったりと、SaaS単位でシステムが個別化してしまい、業務と業務の「つなぎ目」を、結局ヒトがカバーしてしまい、全体の負荷は高まってしまうケースが多く発生していると感じています。
この「つなぎ目」をAIエージェントであれば埋めていくことができると考えています。
橋本：
製造業の中でも、業務システムが個別に進化しすぎた結果、結局この橋渡しにめちゃ課題が起きていますね。
今林：
システム毎の境界の「曖昧さ」をAIエージェントであれば補完していくことができると見ています。
橋本：
仲介者としてのエージェント技術って、結局 “やりたいことはあるのにコードを書くのが面倒” とか “微妙に書き方がわからない” といったときに、言語モデルがスッと書いてくれる感じに近いんですよね。つまり、一定の決まった要素を持ちながら、入力システムのアウトプットを受けシステムのインプットへとシステマチックに変換してくれる存在。広い意味では、CADのように人とシステムの間をつないでくれる仲介レイヤーだと思っています。
橋本：
業務全体を見渡せることが大前提なんですけど、そのうえでアプローチは大きく2つあると思うんです。最近よく聞くFDE（フォワード・デプロイド・エンジニア）的な動きで、名前がつく前から実はそういう働き方をしていたエンジニアっていましたよね。クライアント側に寄り添って、デモを自分で作って渡しながら、実装も設計もやる、いわばプリセールスとテックリードが同居したような人たち。もうひとつは、インターフェースまわりのコーディングに特化するタイプで、全体の中で“どこを担うか”がはっきりした役割、アーキテクトとかエヴァンジェリストみたいなポジションです。
今林：
FDEは非常にトレンディな領域ですね。そこにいる人たちの「出自」が多様であることが私は面白く感じています。エンジニア出身の人もいれば、PM出身の人もいますし、業務コンサルから参入してきた人もいる。本当に様々なバックグラウンドを持つ人が混在していてこの領域の形成しており、キャリアとしての注目度の高さを感じています。
橋本：
どうしても“ユニコーン探し”みたいになりがちですけど、本質的にはまずエンジニアであることが大事だと思います。サッカーで言えば、監督じゃなくてプレーヤーであることが大事で、その上でいろんなポジションができる人─長谷部選手みたいに整っていて、大体なんでもこなせるタイプ、ああいう存在が理想なんです。
ただ実際には、「大体なんでもできる人」って実装だけできないことが多かったり、逆に実装がしっかりできる人はめちゃ専門に寄っていたりする。だから、ビジネスができる人に一回実装させてみて、できる人を伸ばしていく、みたいな育て方もありだと思っていて。
結局、仕様を決められて、Codexを動かせて、システムとしてどこに当てるか見極められて、最終的に“入と出”がどうつながるかを実装レベルで理解している。その状態まで行ける人が、本当に強いんだよね。
今林：
おっしゃる通りで、エンジニア出身で業務も理解している人材が理想ですが、採用と考えると実際にはそこにギャップが存在しますよね。ただ、私は、結果的にはキャッチアップしていくものとも考えていまして、かつて「文系からSEになる」というキャリアパスがあったように、現在は「業務コンサル出身からFDEになる」というキャリアの転換も十分あり得ると考えています。
業務コンサル出身の方は、そもそも業務理解に強みを持っています。その上で、現在のAIの力を活用すれば、ある程度はエンジニア的なスキルを保管できます。つまり「業務に強い」×「AIで手を動かせる」という組み合わせでFDEへと移行していくルートは、これからは自然な流れだと考えています。
橋本：
プログラミングができる人って、別に理系に限らないですよね。できる人は本当にできる。そもそも、これまで“プログラミング”とか“実装”って、上位の仕事として扱われてこなかったところがあります。でも本来、設計している段階で試作とかスケッチがあるべきで、もっと簡単なプログラミングでもいいから自分で検証しながら設計したほうがいいと思っていて。
だから、実装がちゃんとできる人が、ポジションにかかわらず“動くもの”“見えるもの”に手を入れる、それこそが、本来のソフトウェアエンジニアなんじゃないかなと感じているんです。実際、（プログラミング言語のPerlを開発した）ラリー・ウォールだって理系というより言語学者だったわけで、バックグラウンドが何かより、結局“作れるかどうか”なんですよね。
今林：
あくまで設計と実装がつながっていて、むしろ継続的に実装に触れ続けているべきだ、というお話ですよね。業務コンサル出身でエンジニアリング経験がなくても、業務プロセスを設計し、インターフェースのイメージを描き、そのまま自分で実装まで持っていく様な方は、現在のAI時代において、これまで以上に力を発揮できるタイミングなのだと考えています。
橋本：
結局、実装まで含めて設計に責任を持て、ということなんですよね。図面だけ描いて「はい終わり」じゃなくて、自分が考えたものがちゃんと動くところまで付き合う。その往復をしないと、本当に意味のある設計にはならないし、今の時代はそこまで踏み込める人が求められていると思います。
今林：
前編、後編を通じて、AI活用とデータ整備について多角的に議論してきましたが、ここで改めて整理すると、3つの階層で課題と解決策が見えてきたと感じています。
まず第1層は「技術と業務の間のギャップ」です。橋本さんがおっしゃった「データ契約」という概念は非常に示唆的でした。現場では曖昧なデータのやり取りが許容されてしまい、結果として人間がシステムを補う逆転現象が起きている。この問題は、単にシステムを導入すれば解決するものではなく、データそのものに対する責任の所在を明確化する、いわば「データをやり取りする際の約束事」を組織として確立することが不可欠です。
第2層は「暗黙知の扱い方」。製造業における失敗データの欠如、ベテランの頭の中にしか存在しないノウハウ、これらは従来のデータベースでは捕捉できませんでした。しかし生成AIの登場により、ようやく「ぐちゃっとしたテキスト」も価値として蓄積できる時代が来ています。ここで重要なのは、データを入力する側の感情面への配慮です。ジュビロ磐田の事例が象徴的でしたが、「次世代のために自分の経験を残したい」という前向きな動機をいかに設計できるか。技術的な仕組みと同時に、組織文化としてのホスピタリティが求められます。
そして第3層は「システム間のつなぎ目」です。SaaS疲れという言葉に象徴されるように、個別最適化されたシステムが増えた結果、業務と業務の境界を人間が埋める負荷が高まっています。ここにこそAIエージェントの真価があると考えています。CADが人とシステムの間をつないだように、AIエージェントはシステムとシステムの間、あるいは部門と部門の間で「仲介レイヤー」として機能する。これは単なる効率化ではなく、これまで可視化されなかった価値—部門を越えた知見の連携や、調達ノウハウと研究開発現場の接続—を顕在化させる投資なのです。
今回、特に印象的だったのは、橋本さんが繰り返し強調された「作りながら直す」という姿勢です。完璧な仕様を最初から定義するのではなく、柔軟に修正しながら価値を生み出していく。このアプローチは、データ整備そのものにも当てはまります。完璧なデータが揃うまで待つのではなく、「とりあえず入れてしまう」ことで前に進める。そして、そのデータを組織全体で活用可能にすることが、次世代のエンジニア像である“FDEのような業務理解と技術力を融合させた人材”の育成にもつながると思いますね。
最後に、弊社EAGLYSが取り組む秘密計算についても触れさせてください。これは、データ活用における「信頼性の担保」という課題への一つの解です。人事情報のようなセンシティブなデータをどう安全に扱うか。機密性を保ちながら価値を引き出す技術は、データを投資対象として捉える時代において、ますます重要性を増すでしょう。
本日の対談を通じて、データ整備は技術論だけでは語れない、組織・文化・人間理解を統合した総合的な取り組みであることを改めて認識しました。橋本さん、ぜひ次回は、より具体的な実装事例について、さらに深く議論させてください。本日はありがとうございました。