生成AIを仕事に組み込むとき、最初に決めるのは「どこまでをAIにやらせるか」です。ここを曖昧にしたまま進めた仕組みは、あとで正しさを確かめられなくなります。
チャットに質問すると、生成AIはすらすらと答えを返してきます。便利です。ただ、それを会社の仕組みとして人に出すとなると、話が変わります。
何が変わるのか。同じことを二回聞いたときに、同じ答えが返ってくるとは限らないという点です。
同じ問いに、違う答えが返る
生成AIは、次に来る言葉をそのつど選びながら文章を作ります。設定を調整すれば揺れは小さくできますが、ゼロにはなりません。
文章を書く道具としては、これは長所です。少し違う言い方ができるから、相手に合わせられる。
困るのは、その揺れが判断に乗ったときです。
たとえば、健康の記録をもとに声をかける仕組みを考えます。利用者が日々の数値を記録し、それを見て「このまま様子を見てよい」「早めに相談したほうがよい」「すぐ受診してほしい」のどれかを伝える。
この三択をAIに決めさせると、同じ数値でも日によって答えが変わりえます。しかも、なぜそう答えたのかを後から説明できない。これは、人に出せる状態ではありません。
線を引く場所
そこで、こう線を引いています。
| やること | 誰が決めるか | |
|---|---|---|
| 判断 | どの水準で人に行動を促すか | あらかじめ書いたルール |
| 言葉 | その結果を相手に伝わる文章にする | 生成AI |
判断はプログラムで書きます。「この値がこの範囲で、かつこの症状があるときは、この水準」という条件を並べて当てていく。ここには生成AIを一切入れません。
AIが受け取るのは、判断の結果です。「水準は2、理由はこれ」という確定した情報を渡し、それを読み手に伝わる日本語にしてもらう。言い回しは揺れてよい。判断は揺れない。
分けると、確かめられるようになる
この形にすると、正しさの確かめ方が変わります。
判断の側は、入力と期待する結果の組を並べておけば、機械的に全部通せます。条件を一つ足したときに、ほかの条件が壊れていないかがその場で分かる。数百件の確認が数秒で終わります。
言葉の側は、そういう合否の付け方ができません。「この文章は正しいか」は一つに決まらないからです。そこで測るのは別のことになります。判断の結果が文章の中で保たれているか。渡していない情報が混ざっていないか。読み手にとって分かりやすいか。
この二つを一つの箱に押し込むと、どちらの測り方もできなくなります。 出力が想定と違ったとき、ルールの書き間違いなのか、AIの言い回しの問題なのかが切り分けられない。分けておけば、どちらかを見ればいい。
テストの書き方はどう変わるか
判断側は、入力と期待する出力の対応表がそのままテストになります。条件を追加するたびに全件を回し、既存の判定が変わっていないことを確認する。いわゆる回帰テストです。実行が速いので、条件をいじりながら開発できます。
言葉側は合否が一意に決まらないため、評価の観点を先に決めておきます。よく使うのは「判断の結果が文中で保たれているか」「渡していない情報が混ざっていないか」の二つ。前者は結果の数値や区分が文章に現れているかを機械的に照合でき、後者は出典の突き合わせで検出できます。読みやすさだけは人が見ます。
この「機械で測れるもの」と「人が見るもの」を分けておくと、レビューに人手をかける場所が絞れます。
AIを入れる場所は、意外と小さい
こう整理していくと、生成AIが担当する範囲は当初の想像よりずっと小さくなります。判断はルール、根拠は外部の文書、安全は入口のチェック。残るのは「確定した内容を、相手に合わせた言葉にする」という一点です。
これは、生成AIを軽んじているのではありません。逆です。言い換えは、いまの技術がいちばん確実にこなせる仕事だからです。得意なところだけをやらせて、苦手なところは別の手段で固める。そうやって組んだ仕組みのほうが、結果として生成AIを長く使い続けられます。
デモの段階では、全部をAIに投げたほうが速く動きます。ただ、そのまま人に出す段になると、説明できない部分がそのまま残る。最初に線を引いておくほうが、後戻りが少ないというのが実感です。
次回は、AIが出す答えに根拠を持たせる話を書きます。
この記事で触れた設計や実装について、もう少し具体的に聞きたいという方は、お問い合わせからご連絡ください。案件の内容に応じて、お話しできる範囲でお答えします。
ご相談はこちら