「部下の提出物」として受け取る
第1章では、LLMはパターンから言葉を組み立てているプログラムだという話をした。便利なのは間違いないが、出てきた答えがそのまま正しいとは限らない、というところまでが押さえどころだった。
ここから先、本書ではLLMが生成したものを「部下が出してきた提出物」のような感覚で受け取る、という見方をおすすめする。上司から部下に指示を出し、その成果物を確認する流れとほぼ同じだ。まだ現場に詳しくない新人が下書きしてくれた書類を、上司が一度目を通して、必要なら直して、自分の名前で出す。それと同じ手順を取るだけで、AIにまつわる事故の多くは未然に防げる。「AIに任せきりにしない」という当たり前の話だが、便利さに引っ張られて省略されがちなところでもある。
その上で、上司側にかかる手間には軽重がある。一言指示だけを出し、ほとんど直さずに済む仕事もあれば、骨格から組み直さないと使い物にならない仕事もある。本章ではそれを「基本」と「応用」という二つの言い方で整理する。境目をつかんでおくと、「これは任せても大丈夫そうだ」「これは丁寧に確認しないとまずい」という見当が事前につけやすくなる。
基本でうまくいきやすい仕事
基本に分類されるのは、扱う情報の範囲がはっきりしていて、整理の仕方も既に決まっている仕事だ。机の上に積まれた書類を、すでに用意された色別の付箋で分けていく作業に近い。何をどう並べるかの基準が手元にあるので、LLMはそれに沿って手を動かしてくれればよい、という構図になる。
具体的には、長い文章の要約、定型的なメールの下書き、誤字脱字の校正や言い回しの整え、箇条書きを文章にする・文章を箇条書きにするといった形式変換、外国語の文章のだいたいの意味を掴む程度の翻訳、このあたりが代表的だ。どれも「材料は目の前にあって、求められる出力の形もはっきりしている」点が共通している。
これらの作業は、LLMが大量の文章で学んだパターンとよく噛み合うため、無料版や軽量なモデルでもそれなりに動いてくれる場合が多い。日々の小さな手間を減らす、という意味で実感を得やすいのは、まずこの基本の領域だと言ってよい。
ただし、基本だからといって出てきた結果に目を通さなくていいわけではない、という点は前置きの通りだ。「短い要約だから問題ないだろう」と思って読み飛ばすと、章の終盤で触れる落とし穴が顔を出す。
応用には「パワー」が要る
応用に分類されるのは、判断や設計の要素が混じる仕事だ。あちこちの棚を回って資料を探したり、付箋の色から考え直したりしないと先に進まない。しかもそもそも、机の上の書類が足りないこと自体に自分で気づく必要がある。そんな状況が応用にあたる。
具体的に挙げると、報告書のように「何を書いて何を省くか」を決めなければならない文書、議事録から対外向けに出す要約のように「何を伝えて何を伏せるか」が問われる文書、社内マニュアルのように暗黙知をすくい上げないと書けない文書、専門知識が絡んで正確性チェックの手間が重い文書、複数のソースを統合して新しい分類基準を立てるような仕事、並べたデータから何が読み取れるかを解釈する仕事。このあたりがそうだ。
応用領域でつまずきやすいのは、LLMが「指示された範囲で動くのはうまいが、必要な材料を勝手に集めてくる動きは苦手」だからだ。検索ツールを併用できるLLMも増えてはいるが、それこそ前述の社内マニュアルの例で言う、「現場にあって資料には書かれていない暗黙のルール」はこちらが入力して教えない限りLLMの検索範囲にも引っ掛からず、当然出力にも入ってこない。出てきた文章だけを見ていると気付きにくいが、肝心な情報が抜け落ちたままもっともらしい体裁で仕上がる、ということが起きうる。
応用領域の仕事を任せるときは、提出物の点検も基本領域より時間と専門性を要する、と見込んでおいた方がよい。
応用のパワーはどこから出るのか
応用と基本の境目は、絶対的に決まっているわけではない。同じ仕事でも、扱い方を工夫すると基本側に寄せられる場合が多い。言い換えると、上司側にかかる手間を下げる手立てがいくつかある、ということだ。代表的なものを三つ挙げる。
一つ目は、聞き方の工夫だ。不慣れな部下に指示を出すときと同じで、漠然と「報告書を書いて」と頼むより、目的、読み手、含めるべき項目、外すべき項目を箇条書きで添えた方が、結果は安定する。指示出しの段階で少し手間を前倒しすると、点検の段階での直しがぐっと減る、という構図になる。応用に見える仕事も、入力の側で材料と判断基準を揃えてやると、LLMにとっては「基本」の作業に近づく。聞き方の具体的なコツは第3章でまとめて扱うので、ここでは「応用領域では聞き方の効果がはっきり大きくなる」とだけ押さえておきたい。
二つ目は、有料プランにコストを払うこと。これには二つの効果がある。一つは有料プランで使用できるようになる上位のモデルについてだが、こちらは部下の地頭が一段上がるイメージに近い。こちらが手取り足取り教えなくても意図を汲んでくれる確率が上がるため、長い文章を一度に読み込ませる作業や、複数の資料を突き合わせて判断する作業でも、落ち着いた答えを返してくることが多い。更にもう一つの効果として、有料プランでは一度に渡せるファイルの数や量の上限も緩むため、関係する資料を分けて何度も渡し直す、という段取りそのものも軽くなる。結果として、点検の手戻りも、書類の渡し直しも、まとめて減る。コストとの兼ね合いはあるが、応用領域に踏み込むときの選択肢としては有効だ。
三つ目は時間の話だ。今この本で「応用」と書いてある仕事の一部は、半年後・一年後には標準で動くようになり、誰が触っても基本のように扱える、という形に降りてきている可能性がある。要約や翻訳、更には検索ツールの併用も、かつては「ちょっと工夫が要る応用」の側にあったが、今では特別な工夫なしに通るところまで来ている。今は手間がかかる仕事も、しばらく経てば手間が下がる側にずれていく、ということだ。応用と基本の線は固定されたものではなく、時間と共に動くものだと思っておいた方がよい。
基本でも応用でも、共通して気をつけること
最後に、基本と応用のどちらにも共通する注意点を二つ取り上げる。どちらも「上司側の確認の手間」と直結する話だ。
一つ目は、入力していい情報かどうかは仕事の難易度とは別問題だ、という点だ。簡単な要約だから安心、応用だから危険、という話ではない。クラウド型のサービスに業務情報を流すときに何を入力してよくて何が駄目かは、章を改めて第4章でまとめて扱う。基本タスクであっても、入力の中身次第では立ち止まって考えるべき場面がある、というところだけ先に置いておきたい。
二つ目は、ハルシネーションと呼ばれる現象だ。LLMは知らないことについて「知らない」と答えるのが苦手で、それっぽい嘘を堂々と語ってしまうことがある。第1章で触れた「パターンから生成している」という性質の裏返しで、学習データに無かった内容や、混同しやすい固有名詞、最新の情報などで起きやすい。出てきた文章はもっともらしいので、内容に詳しくない人ほど見抜きづらいのが厄介な点になる。
ハルシネーションは応用タスクで目立つと思われがちだが、基本タスクでも油断はできない。長い文章を要約させたら、本文には書かれていない数字が混ざっていた、という事例はよく聞く。翻訳でも、原文にない補足が静かに足されていることがある。「形式変換だから事実は触っていないはず」という思い込みが一番危ない、と言ってよい。
対処の方向はシンプルだ。出てきたものを部下の提出物として一度受け止め、事実関係に関わる部分は元の資料や信頼できる情報源で確認する、という習慣を運用に組み込むことだ。完璧に防ぐ仕組みはまだ無いが、確認の習慣さえあれば、大きな事故にはなりにくい。急がば回れとの言葉が示す通り、最初から確認の手間を見込んでおく方が、後からトラブル対処に追われるよりは楽に済むことが多いだろう。
「部下の提出物としてチェック」という考え方は、章を進めても何度か顔を出す。確認の手間は無くせないが、見込んで運用に組み込むものだ、と覚えておくとよい。