概要
この記事では、昨今様々な議論がなされている生成AIがもたらす利益と懸念をまとめることを通して、生成AIをうまく使いこなし、道具としていくために凡人がとるべき姿勢について論じています。
まず生成AIの議論が行われている際の背景について簡単に説明した後、ポスト生成AIの世界でどのような懸念があるかをまとめます。次に、その懸念を払拭し、ポスト生成AIの世界で業務効率を高めていくための指針を論じています。最後に、現状存在している実際の生成AIサービスを利用した実感をおまけ的にまとめています。
はじめに：生成AIを取り巻く邪悪なものたち
Transformer論文以降、OpenAIのChatGPTやGoogleのGemini、WindowsのCopilotなど、様々な生成AI（LLM）が目覚ましい成長を遂げ、多くの人にとって驚くべきツールとして普及しています。今や、上司や取引先への謝罪文作成、時候の挨拶、今晩の献立など心理的にめんどくさいタスクの負担が、急速にAIへ移行されつつあります。
一方で、生成AIの副作用への懸念も多く存在し、SNS上で活発な議論という名の炎上を高頻度で引き起こしているように思います。これは個々人が異なる文脈（仕事を奪われたくない、自己防衛本能、マウントをとりたい、人を騙したい、などなど）を持ちながら、それを共有せずに議論するために起こると考えられます。
しかし、一般論としては人類は生成AIの存在を受け入れ、共存していく道を探り、武器として最大限利用していくべきだと思います。そしてそのガイドラインを作り、広めていくことが今できる最善手でしょう。
一方、現状では生成AIについての記事は情報商材系のしょうもない記事が多く（個人の感想）、使用感を伴わないものが目立ちます。そこで、この記事では様々な生成AIを使用してみた感想と、どう向き合っていけばいいのかをまとめます。ただし、トークン数や学習データ範囲等のオフィシャルスペックには一切触れません。あくまで、ユーザとしてどのように感じたかのみをまとめます。
ポスト生成AIの世界の懸念
真偽はわかりませんが、「ダグラス・アダムスの法則」というものがあります。これは、「人間は35歳以降に現れたテクノロジーを、物事の自然の摂理に反したものと感じる」という主張です。生成AIの出現時、すでに35歳以降だった人にとって、生成AIはそもそも生理的に受け入れがたく、「なんかキモイな～」程度の直感を得てしまっている可能性があります。ネット上には、このような直感を無理やり論理的なものにみせかけているだけでは？という意見もまま見受けられます。
とはいえ、事実として、生成AIによって人々がよくない方向に進んでしまうのではないかという懸念が多いからこそ、生成AIの使用に反対する人、慎重な姿勢を見せる人が少なくないのだと思います。以下に、実際に生成AIを使っている中で感じた懸念をまとめます。
周辺知識取得機会の減少
生成AIは、これまでのどんな情報源とも異なり、特定の問題に対する解を直接与えることができます。具体的なイメージを得るために、「点$A_1, A_2,...,A_9$とそれをつなぐ辺からなるグラフについて、ある点から出発し、すべての点をちょうど1度ずつ通って始点に戻る道筋は存在するか？」という問題を考えましょう。
- 従来のアプローチ
これまではこの問題の解を探すとき、以下の手順のアプローチを行っていたでしょう。
- 与えられた問題が何に分類されるかを考え、特定する。今回は「ハミルトン閉路」である
- ハミルトン閉路に関する書籍や資料を集め、理解する
- ２で得た知識を応用し、演繹的に与えられた問題を解く
- ポスト生成AIのアプローチ
生成AIを使用してもよい場合、以下のアプローチをとる可能性が高いです。
- 問題のスクリーンショットを取り、生成AIにアップロードする
- 解を得る
後者は非常に早く解を得られる一方、一般に応用できる知識を得られません。また、かなり能動的な姿勢を持っていない限り、この問題が何に分類されるのかすら知ることもないでしょう。
一方で前者は精神的にも困難なプロセスです。何がわからないかすらもわからないところからスタートする場合もあり、挫折してしまうかもしれません。ただ、まっすぐには答えを得られない一方、周辺知識獲得の機会が多く、問題を通して「ハミルトン閉路問題」を体系的に理解するところまでたどり着ける可能性は高いでしょう。
妄信
生成AIが与えた回答を、真実だと妄信することです。人間はそもそも「考える」というめんどくさい行為が好きではないです。見たものをそのまま信じてしまうのは、疑ってかかるよりもとても低コストです。生成AIが返してくれた答えをろくに検証することもなく信じることで、業務レベルの問題やコミュニケーション上の軋轢が生じる懸念があります。
例えば、現場の新人がようわからんコードを書いてきて、何を考えてこの設計にしたの？と聞いたとき「ChatGPTがこう返してくれたんで」と言われたらイラっと来ますよね。そしてこれを修正するのは骨が折れます。これは十分懸念すべき事象です。
課題解決能力の低下
自分でも感じるのは、生成AIが信用できる答えを返してくれなかったとき「あれ？次どうしたらいいんだ？」と思ってしまう恐怖です。インスタントに解が返ってくる経験が、これまで何の苦も無く行っていた「理解に時間をかける」ことを忌避させるようになってしまうのではと感じてしまいます。
対策：生成AIとどう付き合うか
とはいえ、懸念やデメリットがあるからと言って新しいテクノロジを拒否したり適応することを諦めるのはもったいないことです。
ハルシネーションへのテクニカルな対策
ハルシネーションを避けるように前もって指示する
ハルシネーションとは、それっぽいウソ情報を並べてくることです。幻覚という意味のhallucinationという単語から来ています。例えば「ピグレット効果」という存在しない概念についての説明を求めると
というだいぶほんとっぽいことを並べてきます。が、ピグレット効果(piglet effect)という概念は存在しません。
しかし、ハルシネーションは「わからない場合はわからないといって」と指示することでかなり防げます。例えば、先ほどと同じ質問をしても
のように、ちゃんとわからないと答えてくれます。プロンプトテクニックの類はあまり好きではないですが、対人関係上でもこのようなテクニックは有効なので仕方ないでしょう。
妄信への対策
懐疑心を高める
人間はそもそも人を疑うのが得意ではありません。いつも懐疑的な姿勢をとっていると人に嫌われるので、自然と懐疑心をしまいこむ癖を身に着けてしまっているのかもしれません。
ただ、人を疑うのが好きな人にとって生成AIは素晴らしいツールです。彼らはどれだけ疑おうと敵愾心を向けてこないので、いくらでも対話的にリーズニングさせることができます。この過程で、表面的な理解にとどまるリスクを減らせます。
加えて、一般論的に、生成AIの出現によって、人間の主たる仕事は「理解し、検証すること」に移っている可能性があります。答えを教えてくれるツールとして使用するのではなく「今から検証するのが自分の仕事だ」という姿勢で使用するようになってからうまく付き合えるようになった感覚があります。理解にかける時間はこれまでにも増して重要になっているのだと思います。
怠惰への対策：課題解決能力を落とさないために
力の入れどころと抜きどころを謙虚に把握する
現代社会では、専門分野が細分化され、全てを深く理解することは不可能です。そのため、どの分野でも「深く理解すべきこと」と「概要だけ把握すればいいこと」の2種類があります。
生成AIを使用すると、理解せずともショートカットできることが増えます。
- 理解したほうがいいからちゃんと理解に時間を使うこと
- 些事なのでざっとでいいこと
を謙虚に振り分けられないと、最終的に何も理解できないままになってしまうだろうなという恐怖を感じます。精神論的ですが、力の入れどころと抜きどころを謙虚に理由付けして線引きし、必要なものには腰を据えて理解に時間をかけるという、自律の精神がより重要になるのではないかと思います。
結論
現状のTransformerベースの生成AIは完璧ではありませんし、多くの誤謬をもたらす点で害もなし得ます。さらにセキュリティの問題もあり、情報漏洩のリスクを徹底的に検査しなければ、コンフィデンシャルな情報を生成AIで扱うのは難しいでしょう。
一方で、現状の生成AIの特性を理解し、システマチックな対策を十分に行えば、多くの業務をより効率的かつ効果的に進められるようになるのも事実です。これまで以上に誠実に理解と検証を行っていくという指針の下、無駄な業務、めんどうなタスク、自分の苦手なタスクを心的負担なく素早く完了させられます。それだけでなく、主たる業務に関しても少なくとも効率的に、運が良ければ効果的に進められるでしょう。ある意味で、AIの台頭により、逆説的に、より人間性が試されるようになるのかもしれません。
おまけA：各生成AIの実感
画像生成については対象としません。私が全く知らないからです。実際に私が使ってみたのは
- ChatGPT
- Copilot
- Claude
- GitHub Copilot
です。まずはこれらの強みや特徴をまとめていきます。ざっとまとめると以下のような感じです。
| ChatGPT | Copilot | Claude | GitHub Copilot | |
|---|---|---|---|---|
| 正確さ | ○ | △ | ◎ | ○ |
| 文脈の考慮 | ○ | △ | ◎ | ○ |
| マルチモーダル | ○ | △ | ◎ | × |
| 金額 | ○ | ○ | △ | △ |
| ひとこと | バランス〇 | 一歩足りない | 高価だが最高精度 | IDE連携！ |
ChatGPT
良い点
- 画像を何度でも使用できる
- API利用でなければ定額無制限利用可能
- 比較的安い
マルチモーダル（文書や画像など様々な形式の情報を受け入れられること）は生成AIの大きな特徴です。例えばOCRされていないPDFファイルも、マルチモーダル機能を備えた生成AIに入れれば文字起こしができるのは非常に便利です。
私の思うChatGPTの最も優れた点は、画像を同一チャット内に何度も入力し、文脈をとらえながら回答スクリプトを出力してくれる点です。
悪い点
- 精度はClaudeに劣る
- 文脈や設定を忘れがち
感覚でしかありませんが、ハルシネーション（知ったような口をきいて、でたらめを並べること）を含む可能性は、Claude対比高いです。また、1つのチャットが長くなるほど、以前に説明したことを忘れがちで、同じことを2度説明しなくてはいけなかったり、そもそも正確性に欠ける回答しか得られないという場合が多くなる実感があります。
Copilot
良い点
- Microsoft Officeとの連携
CopilotはWindowsのサービスなので、Officeにも連携されていることがありがたいです。例えばWordだと、文脈から次に来そうな単語を推測して提案してくれるため、時間と文章を考えるコストを節約できます。
悪い点
- 精度が低い
同じ問いを与えても、正確な答えを得られる可能性がChatGPT、Claude対比かなり低いです。エンジンはGPT-4のようなので、これはもしかしたら勘違いかもしれません。
Claude
良い点
- 精度が高い
- 文脈を忘れない
- 生成速度が速い
感覚的には、Claudeが最も精度が高く感じます。また、回答やリーズニングも丁寧で、正確である可能性が高いです。さらに、文脈を長いこと忘れずにいられるのもよい点です。また、生成速度が速いのも特徴です。GPT-4よりも高精度に思われる回答を、GPT-4oと同程度の速度で吐き出してくれます。
悪い点
- 1つのチャットに張れる画像の数が限られる
- 高い
Claudeが文脈を保持できるのは、過去の情報を次のスクリプト生成にしっかりと使っているためであり、おそらくこの計算資源はほかのサービス対比でもかなりかかっていると思います。それを反映してか、Claudeはチャットが長くなるほど利用制限がかかる可能性が高くなります。さらに、1つのチャットには5枚までしか画像をアップロードできないという制限もあります。
加えて、ほかのサービスの倍くらいの価格設定なので、ちょっと手が出しづらい部分があります（とはいえ、Netflixと同じくらいの金額なのでNetflixを我慢すればいいのですが）。
GitHub Copilot
良い点
- コーディングに特化している
- IDEと連携できる
GitHub Copilotは、GitHubの情報を重点的にインプットした生成AIです。コーディングに関する知識に特化しており、コード生成能力は高いです。さらに、プラグインとしてIDEと連携して使用するため、
- プロジェクトの中身を一部参照しながら回答してくれる
- コード補完を行ってくれる
というメリットがあります。例えば「euclideanA」まで入力すればユークリッドの互除法を実装してくれたり
「set」まで入力すればクラスの内容に沿ったセッターを書いてくれたりします。
これらだけ見ると大した機能ではないですが、セッターのような単純な機能に限らず、次に実装したいものを精度高く提案してくれます。さらに認知負荷と手間、ミスの可能性を削減できるのは積み重ねると結構大きいです。
悪い点
- 高い
- マルチモーダルに対応していない
GitHub CopilotはClaudeよりは若干安いですが、月2000円程度なのでちょっと高いです。また、マルチモーダルに非対応である点は少しだけ不便です。また、単にコードの精度という点でも、そこまで大きな差はないという上で、GitHub Copilot ≦ Claudeであるように思います。
おまけB：タスクごとの生成AI親和性
生成AIの使用が適切な領域
生成AIが得意な分野は、ざっくり言えば
- ハルシネーションによる被害の可能性が低い領域
- 実行は面倒だが、検証は簡単なタスク
- 自分が苦手なタスク
といえるのかもしれません。エンジニア的にはこんな便利な使い方があるよ！という良記事
があります。加えて、個人的に感じた具体例をいくつかあげます。
プログラミング
プログラムは実行してみれば正しく動くかはわかるため、ハルシネーションの被害を受ける可能性が比較的低いです。ただし、現状ではまだ生成AIが吐き出してくれるコードはとりあえず動くというレベルです。ソフトウェア工学的には「動けばいい」が通用しない場面もあり、そのような局面では積極的にコードを修正したり、そもそも生成AIに頼らないという選択も不可欠です。
正確な答えを必要としていないアイディア出し
例えば「旅行したいんだけどどこ行けばいい？寒いところは嫌で、期間は1週間、予算は10万」などの0から1を生み出す作業は人間が苦手とする分野である一方、生成AIはこの類のタスクが非常に得意です。しかも、そもそも人間は生成された返答をそのまま使うわけではないのでハルシネーションは気になりません。
ラバーダック・デバッグ
一人でいくら悩んでもわからなかったのに、人に説明するとなぜかすぐ自己解決してしまうという経験は誰にでもあると思います。たとえば
Aさん「このコード、なんで動かないかわからないんだよね」
Bさん「どうやって動くべきコードなの？」
Aさん「まずこのTCPClientクラスが外部のサーバーを呼んで、…あれ呼べてないじゃんここ」
Bさん「よかったね」
このようなものをラバーダック・デバッグといいます。生成AIはこの相手として非常に適しています。というのも生成AIに問題を説明しようとするとき、
- 文脈からしっかりと説明しようとする
- 相手が人間でないと無意識に自覚しているので、丁寧かつロジカルに説明しようとする
からではないかと思います。また、いくら相談しても相手に負担はないので、気軽に壁打ち相手にできるというのも大きなメリットです。
翻訳
英語を読むのは何歳になってもつらいです。ただ、ざっくり理解できてしまえば、原文を見ながら正しい理解なのか容易に検証できます。マルチモーダル機能によって、英文のスクショでも簡単に和訳してくれるので、うわー読むの面倒！という場合でも、スクショをぶち込んでざっと内容を理解すると重い腰が簡単に上がります。
図のコード化
個人的に、UML図を作るのが苦手です。コードを書きながらだと図に意識がいかず、どうしたかったんだっけ？と路頭に迷いがちです。一方で、先にシーケンス図などを紙に書くと、わざわざUMLで清書するのめんどくさいなあと思ってしまい、手が止まります。
こういった際、紙に書いたUML図の写真を生成AIに張り付けると、かなりの精度で正しいコードを返してくれます。多少の修正が必要なケースは多いですが、一度正しいものができてしまえばそこからは容易に付け足し・編集ができるのが非常に便利です。
生成AIの使用に向かない領域
逆に、生成AIを使うとあまりよくなさそうな分野も存在します。これはさっきの裏返しで以下のようなタスクです。
- ハルシネーションによる被害の可能性が高い領域
- 検証が難しいタスク
正当性を検証できない分野の情報収集
例えば私はブランド物に興味がないので「プラダとヴィトンではどっちが高級ですか？」と問うたとて、その返答の正当性を評価する手段を持ちません。
こう言われたら私は「ふーん、ヴィトンのほうが高級なんだね」と思わざるを得ませんし、検証も不可能です。これを自分の知識としてしまうのは危険です。
参考