私のLLMとの付き合い方

ChatGPTに代表されるLLMが数年前から急速に普及し、もはや生活の一部になったと言っても過言ではないでしょう。

私はITエンジニアやプログラミングスクール講師としてLLMに触れる機会が多いです。

情報がまとまった書籍もいくつか出版されてきたのでそれらを読み、自分なりのLLMとの付き合い方が見えてきたので、ここにまとめます。

１．LLMをどう捉えるか

（１）教科書的な説明

AIに関しては楽観論から悲観論まで幅広い意見が分布していますが、LLMの実像を正確に捉えることが何よりも重要です。

LLMは、コンテンツを生み出すAIである生成AIのうち、言語に特化したものです。

LLMを含むAIは、魔法のように推論や創造をしているように見えますが、コンピュータによる計算結果です。

およそどのLLMの解説本にも書いていますように、LLMは、インターネット上のテキストを学習して、与えられた単語（トークン）の次にはどの単語（トークン）が続きやすいかを確率的に判断して文章を生成します。

「吾輩は」と来たら「猫である」と続く確率が高いといった判断です。

LLMはこれに尽きます。

LLMは記号接地しておらずサールの中国語の部屋のようであるという、記号接地問題～AIは言葉の意味を理解できるのか？～｜NTS Journalで示唆されている見解に私も賛同します。

（２）私個人の捉え方

個人的には、LLMを、インターネット上の知識を備えたワープロのようなものだと捉えています。

ワープロが出始めた頃に活字の価値が急速に下がった違和感と、LLMが出始めた頃に流暢な文章の価値が急速に下がった違和感が似ているからです。

ワープロ登場以前の活字といえばしっかりとした重要な内容であること請け合いでしたが、ワープロが普及するとくだらない内容でも簡単に活字にすることができるようになり、混乱した記憶があります。

それと同じように、LLM登場以前は流暢な文章は内容も優れているだろうと推測できましたが、LLM普及後は流暢な文章でも内容の伴わないものが目立つようになりました。

その最たる例がハルシネーション（幻覚）と呼ばれる事実に基づかない内容です。

ワープロの普及期に活字の価値を補正したように、メールやレポートが流暢だからといって内容が伴っているとは限らないと流暢さの価値を補正しなければなりません。

ITエンジニア（プログラミング）の世界に限定すると、アセンブリ言語→コンパイラ言語→スクリプト言語と高水準の記述ができるようになってきた延長線上にLLM言語を位置づけています。

スクリプト言語が普及してもアセンブリ言語やコンパイラ言語がなくならなかったように、LLM言語が普及してもスクリプト言語はなくならないと読んでいます。

（３）LLMに適した仕事

インターネット上の情報を見放題で無限の時間を使えばできるような仕事がLLMに適しています。

アイデア出し、翻訳や要約など文章やフォーマットの整形、感情や分野の分類、定型的なプログラミングコードの生成などです。

司法試験の合格水準に達したと聞いても驚きはないです（インターネット上の情報を見放題で無限の時間を使えば司法試験に合格できると思うので）。

LLMは数学や推論が苦手だというのも、上記のLLMの捉え方からすると頷けます。

２．「正しさ」について

（１）一般論

上記のLLMの特性からすると、LLMが出力する内容が正しいとは限りません。

ハルシネーション（幻覚）は言うに及ばず、誰かが確かにそのような内容をインターネット上に書いているという事実水準では正しいとしても、その内容が正しい（真である）とは限りません。

よって、出力結果を見て自分で正しさを判定できない場合にLLMを利用するのは危険であると私は考えます。

推論や判断、政治学や経済学のような人文社会科学がそれに該当します。

逆に、出力結果を見て自分で正しさを判定できる場合には、安心してLLMを利用できます。

度忘れしてしまったけれども見たら再認できる内容や、文章に書かれた内容を表形式に変換するといった作業です。

プログラミングと、翻訳などの言語的なタスクについては微妙な点があるので以下で個別に論じます。

（２）プログラミング

プログラミングも動かしてみればすぐに結果がわかるので、基本的には出力結果を見て自分で正しさを判定できる場合に含まれると考えて差し支えないでしょう。

正しいプログラミングは動作するプログラミングです。しかし、逆は必ずしも真ならずで、動作するプログラミングが正しいプログラミングであるとは限りません。

例えば、動作はするけれども副作用があるプログラミングや、動作はするけれども非常に読みにくいプログラミングは、正しいとは言い難いです。

よって、LLMに頼り切るのではなく、LLMの出力を理解して微調整して使うべきだと私は考えます。

（３）言語的なタスク

多くの人が使っていてそれっぽく見える表現は正しいのだと割り切ってしまえば、言語的なタスクでLLMは大活躍します。

２つの似たような表現をGoogleで検索してヒット数の多い表現が正しいとするような考え方です。私は大学生のときに言語学関係の授業でそのような考え方に触れて衝撃を受けました。

英語（外国語）でビジネスメールを書くときにLLMに添削してもらい、あまり使われない表現をよく使われる表現に直してもらうといった使い方ですね。

他方で、出現頻度は高くないけれどもより適した表現があるのではないかという場面ではLLMに頼るのは避けたほうがよいでしょう。

親密な間柄でのメールや、内容を理解した上で英語（外国語）から日本語（母国語）へ翻訳する場合などは、出現頻度が高くても正しいとは限らないので、LLMの出力結果を丸ごと採用することにはならないでしょう。

３．自分がLLMを使う場合

この記事でのここまでの記述から想像できますように、私がLLMを使うのは、プログラミングでインターネットを検索して調べる手間を省きたい場合や形式の変換をしたい場合、一般的によく使われる言語表現を知りたい場合です。

具体的には、Pythonで日付のフォーマットを調整したいときや名前とメールアドレスのダミーデータがほしい場合、英文ビジネスメールで妥当な表現を知りたい場合などです。

私は実際にコードを書く時間がさほど多くないので、AIコーディングエージェントは使わず、ブラウザからChatGPTやGeminiを呼び出して使っています。

業務のうちで調査や設計、教育指導の占める割合が高く、LLMの恩恵をまだそこまで受けられていない（LLMに仕事を奪われない）印象です。

４．顧客にLLMを使ってもらう場合

顧客にLLMを使ってもらう場合は、API経由でLLMを呼び出すコードを書くのが私の仕事であることが多く、その点ではLLM登場以前の業務と同じです。

顧客はLLMを魔法のように何でも解決してくれるツールだと捉えていることが多いので、そうではないと説明するのも私の仕事です。

顕著なのはリアルタイムの情報で、普通にLLMを使うとリアルタイムの情報は使えないことを説明し、ブラックボックスではありますがAPIでオプションを設定することによりリアルタイムの情報を得るか、従来型のプログラムで情報を取得してからプロンプトに盛り込む（RAG）かを提案します。

顧客あるいはプログラミングスクールの受講生がLLMでプログラミングコードを生成したのはいいけれども、思うように動かなくて困ったと相談を受けることも多いです。そういうときは概念を整理しながら解決していきます。

現実的に妥当な設計をしてからLLMを利用するとたいていうまくいきますが、設計が曖昧なままLLMへの質問を繰り返すと道に迷いがちです。どれだけがんばってもHTMLだけでは本格的なウェブアプリは作れませんし、スマホ利用を想定するからといってSwiftとJavaで開発するのが最適解とは限りません。

ローカル環境だけでプログラムを書いたら、そのローカルPCの電源が入っていないときにプログラムの実行はできませんし、ほかのユーザーがインターネット越しにそのプログラムを呼び出すこともできません。

プログラムが小さい段階ではLLMの出力結果をよくわからないまま貼り付けても動いたのだけれども、プログラムが大きくなるにつれてコードがぐちゃぐちゃになり手が付けられなくなったという状況を目にすることもあります。変数名をわかりやすくして同じ処理は一箇所にまとめて繰り返さないといった、プログラミング学習にまつわる雑感（コーディング原則本等の自分なりのまとめ）で書いた内容を念頭にリファクタリングするのが私の仕事になることもあります。

ある程度の一般的なリファクタリングであればLLMに任せることもできるでしょうが、ビジネスに固有の命名であったり自分にとって最高にわかりやすい整理などは人力でしなければならないのではないかと感じます。