私はAIの専門家ではない。でも、AI案件をやっている
少し前まで、コールセンター向けのAIチャットサービスを作る案件に参加していた。
ChatGPT、Bedrock、Geminiと連携して、オペレーターの回答を支援するシステムである。
期間は1年半ほど。
いわゆる「生成AI案件」だ。
こう書くと、AIの専門家のように聞こえるかもしれない。
先に白状しておく。
私は、AIの専門家ではない。
統計は専門的に学んでいない。
機械学習のモデルを自分で訓練したこともない。
論文を読んで最新のアルゴリズムを追いかけているわけでもない。
データサイエンティストと名乗ったら、本物のデータサイエンティストに叱られる。
では、そんな人間がAI案件で何をしていたのか。
今日はその話をしたい。
AI案件の中身は、ほとんどAIではなかった
参加する前は、私も少し身構えていた。
数式が飛び交う世界だったらどうしよう、と。
実際に入ってみると、様子が違った。
やることの9割は、見慣れた仕事だったのである。
APIの設計。
認証の仕組み。
Lambdaの実装。
ElasticSearchでの検索。
CloudWatchでのログ監視。
CDKでのインフラ構築。
つまり、普通のシステム開発である。
真ん中に鎮座しているのがLLMというだけで、その周りに必要なものは、この30年作ってきたものと大差なかった。
LLMは確かに賢い。
しかし、LLM単体では仕事にならない。
問い合わせを受け取る口がいる。
社内データを検索する仕組みがいる。
回答をオペレーターに届ける画面がいる。
落ちたときに気づく監視がいる。
賢い頭脳に、手足と目と耳を付けてまわる。
私がやっていたのは、そういう仕事だった。
「分からないものを扱う」経験だけはあった
とはいえ、従来のシステム開発と違う点も、はっきりある。
LLMは、同じ入力に同じ出力を返すとは限らない。
昨日うまくいったプロンプトが、今日は微妙な答えを返す。
テストで「正解」を定義しようとすると、そもそも正解が一つではない。
長年、入力と出力が一対一に対応する世界で生きてきた人間には、これはなかなか気持ちが悪い。
ただ、考えてみると、似た経験はあった。
10万台のIoT端末は、こちらの想定通りには動かなかった。
大量のPOSデータには、仕様書にない値が平気で混ざっていた。
本番のトラフィックは、負荷試験の想定を軽々と裏切ってきた。
現実の入力は、いつだって確率的だったのである。
LLMが特別に気まぐれなのではない。
世界がもともと気まぐれで、LLMはそれに少し似ているだけだ。
そう思えるようになってから、この技術との付き合い方が楽になった。
完璧な出力を求めるのではなく、外れたときに困らない仕組みを周りに作る。
やっていることは、結局いつもの防御的な設計である。
専門家ではない、という立ち位置
案件の中で、一度だけ肩書きについて考えたことがある。
お客様との会議で、「AIの専門家として、どう思われますか」と聞かれたのだ。
私は正直に答えた。
「AIの専門家ではないので、モデルの中身については分かりません。ただ、このシステムを止めずに動かす方法なら分かります」
我ながら、身も蓋もない回答である。
しかし、これで信頼を失った感じはなかった。
むしろ、話が早くなった。
モデルの精度の話は、それが得意な人に聞く。
システムの話は、私に聞く。
役割がはっきりしたからだと思う。
30年やってきて思うのは、「何が分かるか」と同じくらい、「何が分からないか」を言えることに価値がある、ということだ。
分からないことを分からないと言うのは、少し勇気がいる。
特に、AIのような流行りの分野では。
でも、そこを曖昧にしたまま進むと、あとで自分が苦しくなる。
30年前も、同じことをしていた
最近ふと、1996年のことを思い出す。
私が最初に入った会社で触っていたのは、インターネットだった。
当時、インターネットの専門家など、ほとんどいなかった。
みんな手探りで、本を読み、動かして、失敗しながら覚えた。
私はインターネットの専門家ではないまま、インターネットの仕事をしていた。
その後も同じである。
クラウドの専門家ではないまま、クラウドを触り始めた。
サーバレスの専門家ではないまま、サーバレスを組んだ。
そして今、AIの専門家ではないまま、AIの案件をやっている。
新しい技術が来るたびに、専門家は最初、どこにもいない。
いるのは、専門家ではないまま手を動かし始める人たちだけである。
そのうちの何人かが、あとから専門家と呼ばれるようになる。
私はたぶん、これからも専門家にはならない。
その代わり、次の「専門家がまだいない何か」が来たら、また性懲りもなく手を動かし始めるのだと思う。
30年間、ずっとそうやってきたのだから。