「この1年、機械学習モデルに一度も触れていない」
海外の掲示板Redditのデータサイエンス系コミュニティで、こんな投稿が話題を集めていました。
投稿したのは、米国の銀行で働くデータサイエンティストです。
仕事の中心が、すっかり「LLMを使ったタスク自動化の仕組みづくり」に移ってしまったといいます。
この投稿には、現場のエンジニアやデータサイエンティストから多くのコメントが寄せられました。
そこには、AI時代の仕事の変化がリアルに映し出されています。
変化1：仕事の中心が「モデル開発」から「LLMの組み込み」へ
投稿者の状況は、決して特殊ではありませんでした。
多くのコメントが、同じ変化を報告しています。
ある人は、こう述べています。
モデルの学習に費やす時間は大幅に減った。
代わりに、パイプラインの構築、出力品質の評価、エラー処理、社内システムとの連携に時間を使うようになった。
コードを書く量自体は減っていない。
しかし、書くコードの種類が完全に変わった、と。
投稿者の銀行では、リスク管理の領域でこの変化が起きていました。
パワーポイント資料やニュース記事といった非構造化データをLLMに読み込ませます。
そして、コンプライアンス上のリスクや業務リスクの兆候を抽出するのです。
従来、この業務は年1回の手作業でした。
それを、常時監視の仕組みに置き換えようとしているそうです。
興味深いのは、その設計思想です。
各処理ステップには、小さな役割だけを与えます。
例えば、テキストを「コンプライアンス系か業務系か」といった単純な分類をさせるだけです。
だから、高価な大規模モデルは不要です。
安価な小型モデルで、十分に回るといいます。
変化2：「コードを書く人」から「コードを検証する人」へ
コメント欄で最も共感を集めていたのが、この変化です。
コーディング作業を、すべてAIエージェントに任せるようになった。
その結果、自分の役割は「ロジックを書くこと」から「出力を検証すること」に移った。
そう語る人が、何人もいました。
中には、AIが作成したプルリクエストのレビューが仕事の中心になった、という人もいます。
ただし、これは楽になったという話ではありません。
むしろ、逆です。
こんな指摘がありました。
バグの発生コストは、ほとんど変わっていない。 以前は人間がバグを書き込み、今はエージェントが持ち込む。 だから、コードレビューの価値はむしろ上がった
AIのコード品質については、「中堅から若手のソフトウェアエンジニア並み」という評価が多数派でした。
定型的なコードは、十分に書けます。
しかし、弱点もあります。
- 2000行を超える巨大なクラスを平気で作る
- 設計パターンの適用に一貫性がない
- セキュリティやDevOpsへの配慮が抜け落ちがち
つまり、全体のアーキテクチャ設計と綿密なレビューは、依然として人間の仕事です。
これが、現場の共通認識でした。
変化3：分析そのものをエージェントに任せる動き
コード生成の先を行く事例も、報告されていました。
あるチームでは、ビジネスユーザーが自然言語で質問できる仕組みを運用しています。
質問を受けると、エージェントがデータウェアハウスへのクエリを計画し、実行します。
そして、その過程も含めて回答を提示するのです。
注目すべきは、精度向上の中身です。
まず、よくある質問ごとに手順書を用意しました。
どの指標を見るか、どの軸で切るか、結果を信じる前に何を除外すべきか、という内容です。
これにより、エージェントが毎回同じ手順で動くようになります。
さらに、正解が分かっている実際の質問50問で評価セットを組みました。
初回の正答率は、約80%でした。
しかし、ビジネス上の文脈情報を追加すると、98%まで上がったそうです。
失敗のほとんどは、SQLの誤りではなく文脈の不足が原因でした。
一方で、分析の丸投げには慎重な声もあります。
「エージェントにファイルを直接読ませて分析させることはしない。信用していないからだ」と明言する人がいました。
エージェントに書かせるのは、あくまでコードまで。
なぜなら、コードなら人間が検証でき、分析を再現できるからです。
この線引きは、示唆に富んでいます。
変化4：地味だが確実な効率化の積み重ね
派手な事例ばかりではありません。
日常の小さな効率化を挙げる声も、目立ちました。
例えば、定型的なSQLやPythonのdocstringの生成です。
また、誰もやりたがらないドキュメントの更新にも使われています。
さらに、トラブルシューティング時の相談相手としても活躍します。
Stack Overflowで検索する代わりに、AIに聞くという使い方です。
面白い工夫もありました。
Excelファイルを、直接AIに作らせるのではありません。
「Excelファイルを生成するPythonスクリプト」を書かせるという方法です。
後から修正したいときは、スクリプトを修正させれば済みます。
しかも、Gitで管理すれば過去バージョンにも戻れます。
AIの出力を再現可能な形で残す、賢いやり方だと感じました。
BIツールの領域でも、変化が起きています。
あるチームは、データベースの指標定義をAIに連携させました。
その結果、Power BIのレポートを自然言語だけで作れるようになったそうです。
もう、ドラッグ&ドロップの操作を覚える必要はないといいます。
変化5：新しいリスクへの気づき
スレッドで最も鋭いと感じた指摘を、紹介します。
「LLMを使ったワークフローは実質的にモデルなのに、誰もモデルとして扱っていない」というものです。
機械学習モデルを本番投入するときは、検証用データを確保します。
そして、性能の劣化を監視するのが常識でした。
ところが、LLMのワークフローは違います。
デモで上手く動いたプロンプトが、そのまま本番に入りがちです。
この人のチームでは、実際に事故が起きました。
ベンダーのモデル更新で、出力形式が変わったのです。
その結果、数日間も入力を誤読し続けたそうです。
しかも、異常に気づいたのは監視ダッシュボードではなく、ビジネスユーザーでした。
評価とドリフト監視。
モデル開発で培ったこの感覚こそ、LLM時代にむしろ強く求められるスキルなのかもしれません。
もうひとつ、依存への懸念も挙がっていました。
スピードを求められるあまり、チーム全員がAIなしでは仕事が回らない状態になっている、という声です。
投稿者自身も、不安を率直に吐露していました。
自分のコアスキルである統計や機械学習の力が、衰えていくのではないか、と。
銀行でもここまで使えるのか
「銀行がデータをLLMに通すことを許可しているのか?」という驚きの声もありました。
投稿者の回答は、明快です。
大手AI企業と直接契約を結び、モデルは自社のデータセンター上で稼働している。
だから、データは外部に共有されない。
コンプライアンス部門が消極的なのではなく、むしろ先を行っている、と。
医療業界も同様に企業契約でヘビーに使っている、という補足コメントもありました。
規制の厳しい業界だからAIは使えない。
そんな思い込みは、もう通用しないのかもしれません。
まとめ
このスレッドから見えてきたのは、データサイエンティストという仕事の重心移動です。
コードを書く力の価値は、下がりつつあります。
代わりに、価値が上がっているものがあります。
何を解くべき問題として設定するか。
AIに何を知らせるべきか。
そして、出力をどう検証し続けるか、という判断力です。
ただし、冷静な視点も忘れてはいけません。
スレッドには「LLMなしでも従来の自然言語処理技術で同等のことが安くできたのでは」という指摘もありました。
投稿者は、正直に認めています。
費用対効果の分析はしていない、と。
それでも、1か月でプロトタイプを作り、関係者の期待を超える成果を出せました。
まず動くものを速く届け、コストが問題になったら最適化する。
この割り切りも、ひとつの現実解でしょう。
あなたの職場では、どんな変化が起きていますか。
海外の現場の声は、数年後の自分の働き方を考えるヒントになるはずです。
