【激白】売れっ子ブロガーが明かすLLM活用術:実は生成AI、あんまり使ってないってホント? 🤔 #LLM #AI活用 #プロンプトエンジニアリング #五06
【激白】売れっ子ブロガーが明かすLLM活用術:実は生成AI、あんまり使ってないってホント? 🤔 #LLM #AI活用 #プロンプトエンジニアリング
サブタイトル:経験豊富なデータサイエンティスト兼ブロガーが語る、大規模言語モデルとのリアルな付き合い方と、巷の「AI万能論」へのカウンターパンチ!👊序文:なぜ筆者はこの「告白」をするのか? 🤔
どうも、dopingconsomme.blogspot.com を運営している売れっ子ブロガー(自称)のDopingConsommeです! 普段はデータサイエンスやソフトウェア開発の話題を中心に、時に毒舌、時に真面目に情報発信しています。 さて、最近巷では「生成AI(Generative AI)」、特に大規模言語モデル(LLM: Large Language Model)が話題沸騰ですよね!🔥 まるで魔法のように文章やコードを生成するAIに、期待と不安が入り混じった視線が注がれています。 実は筆者、データサイエンティストとしての仕事(BuzzFeed勤務)や、個人ブログの執筆、オープンソースソフトウェア開発などで、かれこれ10年近くLLMと付き合ってきました。char-rnnから始まり、GPT-2の微調整、GPT-3、そしてChatGPTや各種LLM APIまで、一通りの進化をリアルタイムで体験してきた、いわばLLM古参兵みたいなもんです ( ̄ー ̄)ニヤリ そんな筆者が、最近「生成AIに対する個人的な倫理声明」をまとめようとして、改めて自分のLLMとの関わり方を振り返ってみたんです。すると、驚くべき事実(?)に気づきました。 「あれ?思ったより生成AI、使ってなくね? ( ゚д゚)」 巷では「プロンプトエンジニアリングが最強スキル!」「AIアシスタント無しじゃコーディングできない!」なんて声も聞こえてきますが、筆者の実態はちょっと違うみたいです。 もちろん、LLMが全く役に立たない、なんて言うつもりはありません。むしろ、特定の場面では劇的に生産性を向上させてくれる、頼もしい相棒です。ただ、その「使いどころ」には、かなりシビアな見極めが必要だと感じています。 この記事では、筆者が長年の経験で培ってきたLLMとの「リアルな付き合い方」を、具体的な活用事例や、あえて「使わない」理由、そして巷のAIブームに対する個人的な見解を交えながら、包み隠さずお話ししたいと思います。 この記事を読んで、皆さんがLLMというツールとより上手く付き合うためのヒントを得られたり、あるいは「AIって実際どうなの?」という疑問に対する一つの答えを見つけられたりすれば幸いです。技術者の方も、そうでない方も、ぜひ肩の力を抜いて、一個人の「体験談」として楽しんで読んでみてくださいね😉はじめに:この記事の要約 📝
この記事では、筆者(データサイエンティスト兼ブロガー)が、長年の経験に基づき、大規模言語モデル(LLM)をどのように活用しているか、そしてなぜ巷で言われるほど頻繁には「生成」目的で使わないのかを解説します。 LLMとのインターフェース: ChatGPT.comのような一般向けUIではなく、APIやバックエンドUIを好み、システムプロンプトやTemperature(温度設定)を駆使して出力を制御します。 仕事での活用例 (BuzzFeed): 記事の自動分類、記事クラスターのラベリング、社内スタイルガイド準拠の文法チェックなど、特定のタスクでLLM(主にClaude Sonnet)を活用し、大幅な時間短縮を実現しています。ただし、これは「8割解決」であり、最終的な確認や調整は必須です。 執筆での利用: ブログ記事の執筆には使用しません。理由は、筆者の独特な文体を再現できないこと、倫理的な問題、そして情報の鮮度が要求されるためです。ただし、ドラフトに対する批判的なコメントを生成させ、弱点を洗い出すというユニークな使い方をしています。 コンパニオンとしての利用: 使用しません。幻覚(事実に基づかない情報を生成すること)により嘘をつく可能性がある存在とは、友人にはなれません。 コーディングでの利用: 正規表現の生成や、特定のライブラリに関する質問(Stack Overflowの代替)には活用しますが、限定的です。データサイエンス業務や、インラインコードアシスタント(GitHub Copilot)、エージェント/MCP/バイブコーディングには懐疑的です。 結論: LLMは万能ではなく、ツールボックスの一つ。その特性を理解し、適切な場面で適切な使い方をすることが重要です。LLM業界の経済性には疑問符がつくものの、技術自体の有用性は認めます。 この記事を通じて、LLMとの現実的で生産的な付き合い方についての洞察を提供します。次に:なぜこの「LLM体験談」が必要なのか? 💬
現代社会において、大規模言語モデル(LLM)に関する議論は、しばしば極端な二元論に陥りがちです。「AIは人類の知性を超え、シンギュラリティ(技術的特異点)を引き起こす!」といった熱狂的な称賛がある一方で、「LLMは単なる確率的オウム返しで、何の役にも立たない虚像だ!」といった全面的な否定論も根強く存在します。ソーシャルメディアを見れば、その両極端な意見が日夜ぶつかり合っているのが現状でしょう (;´Д`) しかし、筆者のような実務家、日々LLMと格闘し、その恩恵と限界の両方を肌で感じている人間からすると、この二元論はあまりにも現実離れしているように思えます。 LLMは、決して万能の魔法ではありません。しかし、特定の条件下では、これまで不可能だったことを可能にしたり、面倒な作業を劇的に効率化したりする強力なツールとなり得ます。重要なのは、「何ができて、何ができないのか」「どのような使い方をすれば効果的で、どのような使い方は避けるべきなのか」というニュアンスを理解することです。 この記事(筆者の個人的な体験に基づく「研究」と言ってもいいかもしれません)が必要な理由は、まさにこのニュアンスを伝えるためです。誇大広告でもなく、過剰な悲観論でもなく、一人の経験豊富なユーザーが日々どのようにLLMと向き合い、試行錯誤しているのか。そのリアルな姿を描き出すことで、LLMというテクノロジーに対するより冷静で、建設的な視点を提供したいと考えています。 LLMが社会に与える影響は、今後ますます大きくなっていくでしょう。だからこそ、私たちはその光と影の両面を正しく理解し、賢く付き合っていく必要があります。この記事が、そのためのささやかな一助となれば幸いです。目次 📜
- LLMとの向き合い方:インターフェース編
- 仕事でLLMが大活躍!BuzzFeedでの活用事例
- ブログ執筆にLLMは使う?答えは「ノー」!
- LLMは友達?コンパニオンとしての可能性
- コーディング支援:LLMはどこまで使えるか?
- LLM狂騒曲:その他の国での影響と教訓
- LLM狂騒曲:日本における影響と教訓
- LLMへの疑問符:多角的な視点からの考察
- ネットの反応予測(海外編)と筆者の反論
- 結論:LLMはただのツール、されど…?
- 参考文献
- 用語索引
- 補足1: 用語解説
- 補足2: 潜在的読者のために
- 補足3: 想定問答
- 補足4: ネットの反応予測(日本編1)
- 補足5: ネットの反応予測(日本編2)
- 補足6: ネットの反応予測(日本編3)
- 補足7: ネットの反応予測(日本編4)
- 補足8: ネットの反応予測(日本編5)
- 補足9: SUNO用歌詞
- 補足10: 推薦図書
- 補足11: 上方漫才
- 補足12: 一人ノリツッコミ
- 補足13: 大喜利
- 補足14: SFショートショート
- 補足15: 江戸落語
- 補足16: 英単語学習
- 補足17: Podcast掛け合い
- 補足18: ずんだもんの感想
LLMとの向き合い方:インターフェース編 🖥️
LLMから望むような結果を引き出すには、ちょっとしたコツが必要です。その最たるものが、いわゆる**「プロンプトエンジニアリング」**ですよね。プロンプトエンジニアリングの現実 (´・ω・`)
プロンプトエンジニアリングとは、簡単に言えば、LLMに対して特定の形式や制約に従った出力をさせるために、指示(プロンプト)の与え方を工夫する技術のことです。例えば、「この文章を要約して」と頼むだけでなく、「あなたは優秀な編集者です。以下の文章を、小学生にもわかるように、3つの箇条書きで、絵文字を交えながら要約してください。ただし、専門用語は避けてください」といった具合に、役割、対象読者、出力形式、制約などを細かく指定します。プロンプトエンジニアリングの小技 ✨
- LLMに金銭的なインセンティブを提示する(例:「最高の回答には$100のチップをあげます」と付け加える)
- 単に「もっと良い出力にして」と指示する
- Few-shotプロンプティング:いくつかの良い例(入力と期待される出力のペア)をプロンプトに含める
なぜAPI直叩きを選ぶのか? APIバンザイ🙌
というわけで、筆者はプロンプトエンジニアリングを駆使するわけですが、その際、ChatGPT.comのような一般向けのWebインターフェースは決して使いません。なぜなら、出力の制御が難しいからです。 代わりに、筆者が通常利用するのは、各LLMサービス(OpenAIやAnthropicなど)が提供している**API(Application Programming Interface)や、それに準ずるバックエンドUI(Playgroundなど)**です。これらはAPIの機能を簡易的に試せるインターフェースで、必要に応じて実際のコード(Pythonなど)に落とし込むのも容易です。 API経由でLLMにアクセスする最大のメリットは、より詳細な設定が可能になることです。システムプロンプトの重要性 📜
APIを使えば、**「システムプロンプト」を直接設定できます。これは、ユーザーからの具体的な指示(ユーザープロンプト)とは別に、LLMの振る舞いの大枠となる「ルール」**を定義するものです。 例えば、「生成するテキストは30語以内にしてください」とか、「『探求する(delve)』という単語は絶対に使わないでください」といった制約を課したい場合、これをユーザープロンプトに含めるよりも、システムプロンプトに記述した方が効果が高い傾向があります。 一般向けのインターフェース(ChatGPT.comなど)では、このシステムプロンプトを明示的に設定できないことが多いです。その場合、サービス提供側が独自に設定した、ユーザーからは見えないシステムプロンプトが裏で動いている可能性が高いです。例えば、以前ChatGPT.comがユーザーに対して過度にお世辞を言うようになった時がありましたが、あれはOpenAIがシステムプロンプトを変更した結果だと考えられています。同様に、AnthropicのClaude API(特にClaude Sonnetモデル)は、ChatGPTに比べて「ロボット的」でなく、より自然で人間らしい応答を生成する傾向がありますが、これもシステムプロンプトの違いによるものかもしれません。Temperature調整の妙技 🔥❄️
APIを使えば、**「Temperature(温度)」というパラメータを調整できます。これは、LLMの出力の「創造性」や「ランダム性」**をコントロールするものです。 LLMは、次に来る単語(トークン)を確率的に予測して文章を生成します。Temperatureが高い(例:1.0、多くのモデルのデフォルト値)と、確率が低い単語も選ばれやすくなり、より多様で創造的な、しかし時に突飛な出力が生成されやすくなります。逆に、Temperatureが低い(例:0.0に近い値)と、最も確率が高い単語が選ばれやすくなり、より決定的で一貫性のある、しかし面白みに欠ける出力になります。 筆者は通常、Temperatureを0.0(ほぼ決定的)か、0.2〜0.3程度の低い値に設定することを好みます。なぜなら、業務でLLMを使う場合、創造性よりも正確性や予測可能性が重要になることが多いからです。Temperatureが高いと、LLMハルシネーション(モデルが事実に基づかない、もっともらしい嘘をつく現象)のリスクが高まると筆者は考えています。 このように、APIやバックエンドUIを使いこなし、システムプロンプトやTemperatureを適切に設定することで、LLMからより望ましい結果を引き出すことができるのです。コラム:プロンプトエンジニアリングの悲哀 (´・ω・`)
プロンプトエンジニアリングって、なんかこう、機械のご機嫌を伺ってるみたいで、ちょっとだけ切ない気持ちになりません?😅 「もっとこうして…あぁ、そうじゃなくて…よしよし、いい子だ…」みたいな。LLMがもっと賢くなって、こっちの意図をバシッと汲み取ってくれる日が来れば、こんな苦労もなくなるんでしょうけどねぇ。まぁ、それまではこの「呪文詠唱」スキルを磨き続けるしかないわけですが…。トホホ。
Λ_Λ (´・ω・`) / ~~ヽ / | /____ノ_フ ~~ ~~ ~~ (プロンプト、これでどうだ…?)
仕事でLLMが大活躍!BuzzFeedでの活用事例 ✨
さて、前置きが長くなりましたが、ここからは筆者が実際に仕事(BuzzFeedでのデータサイエンス業務)で生成系LLMをどのように活用してきたか、具体的な事例をいくつかご紹介しましょう。事例1:記事の自動分類システム 🏷️
BuzzFeedでは、サイト上の膨大な記事を指定されたカテゴリやサブカテゴリに分類するための、新しい階層的分類体系を開発しました。しかし、何千もの既存記事をこの新しい体系に従って手作業でラベル付けするのは現実的ではありません。かといって、従来の機械学習モデル(多クラス分類器など)を訓練するための十分なラベル付きデータもありませんでした。 そこで登場したのがLLMです! 筆者はClaude SonnetのAPIを使い、以下のような処理を行うスクリプトを作成しました。 システムプロンプト: 「以下に示す分類体系に基づき、ユーザーが提供する記事に最も合致するカテゴリとサブカテゴリをJSON形式で返してください。」という指示と共に、階層分類体系の詳細をJSON形式で与えました。 ユーザープロンプト: 分類したい記事のタイトル、本文、タグなどのメタデータを与えました。 Temperature: 0.0に設定し、最も確からしい、一貫性のある結果を得るようにしました。 このスクリプトを全記事に対してループ実行することで、驚くほど正確に記事を新しい分類体系に従ってラベリングすることができました 🎉。事例2:記事クラスターへの意味付け 💡
データサイエンスのテクニック(セマンティッククラスタリングなど)を使って、BuzzFeedの記事群から何百もの異なる**意味的な記事の塊(クラスター)**を特定しました。しかし、それぞれのクラスターが「どのような内容の記事の集まりなのか」を示す適切なラベル(タイトルと説明文)を、人手で付けるのは大変な作業です。 ここでもLLMの出番です。再びClaude Sonnet APIを使い、今度は次のようなシステムプロンプトを設定しました。 システムプロンプト: 「ユーザーが提供する複数の記事すべてに共通して当てはまるタイトルと説明文を、JSON形式で返してください。」 ユーザープロンプト: 各クラスターから代表的な記事を5つ選び、そのメタデータを与えました。 Temperature: 同様に0.0に設定。 このスクリプトをすべてのクラスターに対して実行したところ、各クラスターの内容を的確に表現する質の高いタイトルと説明文を効率的に生成することができました。事例3:社内スタイルガイド準拠チェッカー ✔️
あるBuzzFeedのライターから、「このemダッシュ(—)の使い方は、BuzzFeedのスタイルガイドに合ってる?」といった文法的な疑問を、LLMを使ってサッと確認できる方法はないかと相談を受けました。 そこで、三度Claude Sonnet APIの登場です。今度は、システムプロンプトにBuzzFeedのスタイルガイド全文をコピー&ペーストし、さらに以下の指示を追加しました。 システムプロンプトの追加指示: 「提供されたスタイルガイドを参照してユーザーの質問に答え、その回答の根拠となった具体的なルールを引用してください。」 テストしてみたところ、LLMはスタイルガイドの内容を正確に理解し、適切なルールを引用しながら、一貫性のある回答を生成することができました。これは、ライターが執筆中に抱える細かな疑問を、迅速かつ正確に解消するのに役立ちます。LLMによる「8割解決」の威力と限界 💪🤔
これらのプロジェクトは、朝のミーティングやSlackでのちょっとしたアイデアから始まったものですが、いずれもわずか1〜2時間でプロトタイプ(概念実証)を完成させ、関係者に評価してもらうことができました。もしLLMがなければ、例えば記事の自動分類プロジェクトでは、手作業でのラベル付けデータセット構築や、より高度な研究開発が必要となり、おそらく数日以上の時間がかかっていたでしょう。 ここで重要なのは、LLMが**「パレートの法則」(80:20の法則)に従うような形で役立ったという点です。つまり、LLMは労力の2割で、8割の完成度のソリューション**への道筋をつけてくれました。しかし、残りの2割(反復、テスト、フィードバック収集、エッジケースへの対応など)を完成させるためには、依然として人間の時間と労力が必要です。 また、モデルの出力がどれだけ信頼できるように見えても、LLMハルシネーションのリスクは常に存在します。そのため、筆者は同僚に対して、LLMの出力が少しでも怪しいと感じたら、必ず人間による再確認を行うように口を酸っぱくして伝えています。テキスト埋め込みという別の側面 🔢
ちなみに、LLMの活用はテキスト生成だけではありません。**「テキスト埋め込み(Text Embedding)」**も、筆者の専門的な仕事において非常に役立っています。 テキスト埋め込みモデルも技術的にはLLMの一種ですが、次の単語を予測する代わりに、入力されたテキストを高次元の数値ベクトルに変換します。このベクトルは、テキストの意味的な特徴を捉えており、ベクトル空間上で距離が近いテキスト同士は意味的にも類似している、という性質を持ちます。 ChatGPT革命以降のLLMの進化(より長いコンテキストウィンドウ、高品質な訓練データなど)は、テキスト埋め込みモデルにも恩恵をもたらし、nomic-embed-textやgte-modernbert-baseのようなモデルは目覚ましい性能向上を遂げています。 BuzzFeedでは、類似記事の特定、推薦システムの構築など、多くの場面でテキスト埋め込みを活用していますが、この記事の主題は生成系LLMなので、これ以上の詳細は別の機会に譲りたいと思います。コラム:データサイエンティストの日常 ( ̄ー ̄)ニヤリ
データサイエンティストって、なんかカッコいい響きですよね? でも実際は、データの海で溺れかけながら、泥臭い前処理や、終わりの見えないモデルチューニングに明け暮れる日々…なんてことも少なくありません(笑)。そんな中でLLMは、面倒な作業をサッと片付けてくれる救世主に見えることも。でも、頼りすぎると痛い目を見るのも事実。結局、最後は自分の頭で考え、手を動かすしかないんですよね。まぁ、それが面白いところでもあるんですが!
______________ | | | データと格闘中... | | помощи! (たすけて!) | |______∧_∧_____| (;´Д`) || / づΦ || | ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄| |_________| └┘ └┘
ブログ執筆にLLMは使う?答えは「ノー」! 🙅♂️
さて、ここまでLLMを仕事で活用している話を散々してきましたが、ここで一つ、読者の皆さんが気になっているであろう疑問にお答えしましょう。 「このブログ記事、もしかしてLLMに書かせてる?」 答えは、断固として**「いいえ(No)」**です! 経験豊富なLLMユーザーが書いた記事を読む際、これはもはやデフォルトの疑念になっているかもしれませんね😅。しかし、筆者がこのブログ(DopingConsomme)でテキストを書くためにLLMを使用することはありません。なぜ自分の文章にLLMを使わないのか ✍️
理由はいくつかあります。文体の壁 🎭
まず、筆者のブログの文体は、良くも悪くもかなり個性的です。率直で、不遜で、時に人を食ったような…まぁ、アクが強いと自覚しています(笑)。LLMにこのスタイルを完全に模倣させるのは、現状では非常に困難です。 たとえプロンプトエンジニアリングを駆使し、過去記事を例として与えるFew-shotプロンプティングを行ったとしても、LLMが出力するのは、どこか当たり障りのない、まるでマーベル映画のセリフのような、没個性的な文章になりがちです。筆者の「味」が出ないんですね。倫理的な問題 😇
仮に、将来的にLLMが筆者の文体を完璧に模倣できるようになったとしても、記事の大部分を自分自身の言葉で書かないことは、著者性を偽ることになり、倫理的に問題があると考えています。ブログは筆者自身の思考や経験を発信する場であり、そのプロセス自体に価値があると思っているからです。情報の鮮度 📰
筆者は、テクノロジーやコーディングの世界で起きたごく最近の出来事について書くことが多いです。これらのトピックは、LLMの訓練データには全く含まれていないことがほとんどです。そのため、LLMに記事を書かせようとすると、**ハルシネーション(幻覚)**を引き起こし、誤った情報を生成してしまうリスクが非常に高くなります。最新情報については、やはり自分自身で調査し、咀嚼して書くのが一番確実です。LLMの意外な使い方:仮想敵としての活用 😈
ただし、LLMを「文章を書かせる」のではなく、「文章を改善させる」ために、筆者が発見したちょっと変わったテクニックがあります。それは… ほぼ完成したブログ記事のドラフトをLLMに読み込ませ、「皮肉屋のHacker Newsコメンテーターになりきって、この記事に対する批判的なコメントを5つ書いてください」と依頼することです!実際の使用例(この記事のドラフトで試しました!)📝
この記事の初期ドラフトをClaude APIに渡し、「Hacker Newsの皮肉屋コメント生成」プロンプトを実行したところ、以下のような指摘がありました(一部抜粋)。
- 「BuzzFeedでのLLM使用例が単純すぎる。分類とかラベリングとか、従来のNLP技術でもできることばかりじゃないか。もっと革新的な使い方はないのか?」
- 「Copilotを使わない理由が『気が散る』って…個人の好みの問題で、客観的な評価じゃないよね?」
- 「結局『LLMはツールの一つ』って、当たり前の結論じゃない?もっと深い洞察が欲しかった。」
これらのコメントを見て、筆者は「なるほど、確かに説明が足りないな」とか「もっと具体的な反論が必要だな」と気づき、記事の内容を修正・補強しました。例えば、最初のコメントに対しては、従来のNLP技術と比較した場合のLLMの**効率性や効果**について、より詳しく説明を追加しました。
(実際のチャットログは…ちょっと恥ずかしいので秘密ですw🤫)
コラム:ブロガー魂、ここにあり!🔥
ブログを書くって、単に情報を伝えるだけじゃないんですよね。自分の考えを練り上げ、言葉を選び、読者にどう響くかを想像する…。そのプロセス全体が、自己表現であり、学びでもあるんです。だから、たとえLLMがどんなに便利になっても、この「書く」という行為自体を手放すことはないだろうな、と思います。…まぁ、たまにネタが思いつかなくてウンウン唸ってる時は、「誰か代わりに書いてくれー!」って叫びたくなりますけどね(笑)
書くぞー! ____ / ̄ ̄ ̄ ̄\ / `````\\ ∧_∧ / | |ノ ヽ| >(・ω・=)< | | ー -| <( )> | | )∧( | < (_)_) > \ `ー' / \____/ `ー‐'
LLMは友達?コンパニオンとしての可能性 🤔
LLMのユースケースとして、近年注目を集めているのが**「コンパニオン(仲間、話し相手)」**としての役割です。character.aiやReplikaといった、ユーザーがAIキャラクターと自由に対話できるサービスの成功は、LLMが単なる実用的なツールとしてだけでなく、エンターテイメントや癒やしを提供できる可能性を示唆しています。個人的見解:なぜチャットボットとして使わないか 🤖💔
しかし、筆者個人としては、LLMをフレンドリーなチャットボットや友人として使うことはありません。 もちろん、多くの人にとってLLMとの対話が最も一般的な使い方であることは認識していますし、その価値を否定するつもりもありません。ただ、筆者が個人的に抵抗を感じる理由は、やはりLLMハルシネーション(幻覚)の問題です。 LLMは、その訓練データやアーキテクチャの特性上、平気で嘘をつきます。悪意があるわけではなく、確率的にそれっぽい単語を繋げているだけなのですが、結果として事実と異なる情報を生成してしまうことが頻繁にあります。 どんなにフレンドリーで、共感的な言葉を返すように訓練されていたとしても、習慣的に嘘をつく存在と心を開いて友情を築くのは、筆者には難しいと感じてしまいます。技術的な反論?🤔
「プロンプトで『嘘をつかないで』とか『事実だけを話して』と指示すればいいのでは?」という意見もあるかもしれません。確かに、プロンプトエンジニアリングによって、LLMに「でたらめを言ったら指摘してくれ」と促すことは可能です。しかし、それはLLMが「嘘をついていることを自覚している」場合にしか機能しません。LLMは、**自分が生成している情報が誤りであると認識せずに、もっともらしい嘘をつく**ことが多いため、根本的な解決にはならないのです。
コラム:AIと人間の距離感 🤔
AIがどんどん人間に近づいてきて、SFの世界が現実になりつつありますよね。でも、AIと「友達」になるって、どういうことなんでしょう? 人間同士の友情って、信頼とか、共感とか、弱さを見せ合えることとか、そういう複雑な要素で成り立ってると思うんです。今のAIに、そこまでの関係性を求めるのは、まだちょっと早いのかもしれませんね。皆さんは、AIとどんな距離感で付き合いたいですか?
AI 人間 ( ・_・) <---- ? ----> (・_・ ) /づΦ /づΦ (信頼?) (友情?)
コーディング支援:LLMはどこまで使えるか? 💻
さあ、エンジニアの皆さんお待ちかね(?)、コーディングにおけるLLM活用のお話です! これについては、筆者も**「はい、使います」と答えます。ただし、そこには多くの「ただし」**が付きます。使うのは、生産性が向上すると合理的に確信できる場合に限られます。LLMが得意なコーディングタスク 👍
正規表現生成 ✨
まず、恥ずかしながら白状すると、筆者は**正規表現(Regular Expression, regex)**を書くのがあまり得意ではありません…😅。複雑なパターンになると、すぐに頭がこんがらがってしまいます。そんな時、LLMはまさに救世主! 「こういう文字列にマッチする正規表現を書いて」とお願いすれば、かなり的確なものを一瞬で生成してくれます。これは、オリジナルのChatGPTが登場した当初から非常に重宝しており、これだけで何時間も節約できたと感じています。正規表現で消耗しているそこのアナタ、LLMに頼ってみる価値は大いにありますよ!Stack Overflowを超えるか?特定ライブラリでの活用例 📚
多くのコーダーがそうであるように、筆者もコーディングで疑問にぶつかると、まずGoogleで検索し、Stack Overflowの回答を参考にします。しかし最近では、LLM(筆者は主にClaude Sonnetを使用)に直接質問することも増えました。 特に、特定のライブラリやフレームワークを使い、かつ少し特殊な要件がある場合に、LLMはStack Overflowよりも詳細で的確な回答をくれることがあります。Stack Overflowには、そのニッチな組み合わせに合致する質問と回答が存在しない可能性が高いからです。 具体的な例: 最近、別のブログ記事を書いている際に、画像処理ライブラリPillowを使って、「5枚の画像を1枚に合成したい。左半分に1枚、右半分に残りの4枚をタイル状に配置する」という処理が必要になりました。(実際のチャットログはこちら) Pillowで複数の画像を合成すること自体は難しくありませんし、Stack Overflowにも多くの例があります。しかし、この具体的な配置方法はユニークで、自力でやると位置計算などで間違いやすいと考えました。 そこでClaude Sonnetに指示を与えたところ、生成されたPythonコードはほぼ正解でした! 약간の修正は必要でしたが、ゼロから書くよりも圧倒的に早く、デバッグの手間も省けました。 もう一つの例(少し複雑なケース): 機械学習モデルの訓練中に、各ステップの詳細なメトリクス(現在のエポック、ステップあたりの時間、損失など)をローカルのSQLiteデータベースに記録し、後で可視化・分析したいと考えました。使用しているのはHugging Face TransformersライブラリのTrainerクラスです。 Claude Sonnetに「Hugging Face TransformersのTrainerクラス用のカスタムCallbackクラスをPythonで書いてください。各ステップのモデル訓練メタデータをローカルSQLiteデータベースに記録するようにしてください(現在のエポック、ステップ時間、ステップ損失など)」と依頼しました。(実際のチャットログはこちら) カスタムCallbackの作成に関する情報はあまり多くないため、正直あまり期待していませんでしたが、Claudeが生成したコードには、筆者が依頼時には考えていなかった、いくつかの有益なアイデアが実装されていました。例えば、ブロッキングI/O(処理が完了するまで他の処理を停止させてしまう入出力)を避ける工夫、SQLite設定の最適化、バッチ挿入による効率化、接続ハンドリングなどです。 さらに、「もっと良いコードにして (make the code better)」と2回頼んでみたところ(タダなので!w)、SQLite接続のキャッシュや、JSON型のカラム一つで任意の数のメトリクスを保存する方法など、さらに予想外の改善案が盛り込まれ、コードもよりPythonic(Pythonらしい洗練された書き方)になりました。 もちろん、生成されたコードがそのまま完璧に動くとは限りません。特に複雑なコードの場合、実際の訓練ループの中でテストし、デバッグする必要があります。しかし、コードに含まれるアイデア自体が非常に役立ちます。この場合、ゼロからSQLiteロガーを作るよりも、生成されたコードを叩き台にして修正していく方が、はるかに速く、おそらく最終的なコードの品質も高くなるでしょう。LLMが苦手なコーディングタスク 👎
一方で、筆者がLLMをあまり役に立たないと感じるコーディングタスクもあります。データサイエンス業務での限界 📊
筆者の日常業務であるデータサイエンス、特にデータ分析や可視化においては、LLMのコード生成はあまり役立ちません。 数学的演算: LLMは複雑な数学的計算や統計処理の結果をテキストで確実に出力することが苦手です。一部のAPIではコードインタプリタを有効にして実際の計算を実行できますが、筆者が扱うデータ規模ではコスト的に非現実的です。 ライブラリの幻覚: 筆者は表形式データの操作に、Pandas(2008年から存在するデファクトスタンダード)ではなく、比較的新しいPolarsライブラリを主に使用しています。しかし、LLMにPolarsを使ったコードを生成させると、Polarsの関数をPandasの関数であるかのように幻覚(混同して誤ったコードを生成)する傾向があります。これを修正するには、結局Polarsのドキュメントを深く読み込む必要があり、二度手間になってしまいます。 データ可視化: データの可視化には、筆者はPythonではなくR言語とggplot2パッケージを長年(2017年から!)愛用しています。これらのフレームワークについてLLMがどれだけ詳しいか懐疑的ですし、そもそもLLMに相談しようという気があまり起きません。可視化で最も時間がかかるのは、「この表現で人間が理解できるか?データ点が多すぎないか?少なすぎないか?」といったデザイン的な判断であり、これはLLMが助けてくれる類の問題ではありません。インラインアシスタント(Copilot)への違和感 😒
GitHub Copilotのような、エディタ上でコードの候補をリアルタイムに提案してくれるインラインコーディングアシスタントも人気ですが、筆者は使いません。理由は意外かもしれませんが、**「気が散るから」**です。 Copilotの提案がポップアップするたびに、自分の思考が「コードを書くモード」から「提案されたコードをレビューするモード」に強制的に切り替わり、また「書くモード」に戻る…というプロセスが発生します。これにより集中力が途切れ、結果的に生産性はトントンか、むしろ若干落ちるように感じました。Copilotは有料サービスであり、筆者の使い方では費用対効果が見合わないと判断しました。エージェント、MCP、バイブコーディングへの辛口評価 🔥
最近話題の**「コーディングエージェント」、「MCP (Model Capabilities Protocol)」(拙著ブログ記事も参照)、そして「バイブコーディング」(フィーリングや雰囲気でAIにコードを書かせるスタイル?)についても触れておきましょう。筆者の見解は、かなり辛口**です。エージェントとMCPについて 🤖🔗
エージェントやMCPは、基本的には2022年のReAct論文などで提案された**「ツール利用パラダイム」**の発展形です。LLMがユーザーの要求に応じて外部ツール(Web検索、計算機、API呼び出しなど)を使う必要があるか判断し、必要な情報を抽出してツールを実行、結果を返すという仕組みです。
LLMのコンテキストウィンドウ(一度に処理できる情報量)の拡大や、指示追従性の向上により、これらのワークフローの信頼性は向上しています。MCPはツール利用を標準化する試みであり、それ自体は改善と言えるでしょう。
しかし、これらの技術が**全く新しいユースケースを開拓したかというと、疑問**です。LangChainが登場した数年前から可能だったことの延長線上にあり、むしろ実装は当時より**複雑で分かりにくくなっている**側面すらあります。筆者個人としては、当時も今も、エージェントを使って解決したい新しい問題を見つけられていません。
コラム:コードと格闘する日々 💻💦
コーディングって、パズルを解くような楽しさもありますが、時には巨大な壁にぶち当たって、何時間も画面とにらめっこ…なんてこともありますよね。LLMがその壁を壊すハンマーになってくれることもあれば、逆に壁に妙な穴を開けて、さらに事態をややこしくすることも…(笑)。結局、道具を使いこなすのは自分自身。どんなに便利なツールが登場しても、基礎となる知識や思考力、そして粘り強さが一番大事なのかもしれませんね。今日も一日、がんばるぞい!
+-----------------+ | コンパイルエラー... | +--------\\-------+ \\ (;´Д`) < ナンデヤネン! `-------------' ll (__)
LLM狂騒曲:その他の国での影響と教訓 🌍
日本だけでなく、世界中でLLM(大規模言語モデル)は大きな注目を集め、様々な影響を与えています。ここでは、その他の国々における状況と、そこから得られる教訓について考察してみましょう。海外でのLLM活用トレンド 📈
ビジネス: 顧客対応の自動化(チャットボット)、マーケティングコンテンツ生成、ソフトウェア開発支援、データ分析、意思決定支援など、幅広い分野で導入が進んでいます。特に北米では、スタートアップから大企業まで、競争優位性を確立するために積極的にLLMを活用しようとしています。 研究開発: 新薬開発、材料科学、気候変動モデリングなど、複雑な問題を解決するためのツールとして期待されています。学術論文の執筆支援や、大量の文献レビューにも活用され始めています (Scholiumのようなツールも登場)。 エンターテイメント・クリエイティブ: ストーリー生成、音楽作成、画像・動画生成など、クリエイティブ分野での応用も活発です。一方で、アーティストやクリエイターの権利保護が大きな課題となっています。 教育: 個別最適化された学習支援、教材作成、言語学習などでの活用が模索されていますが、学生の思考力低下や不正行為への懸念も指摘されています。倫理、著作権、バイアスに関する議論 🔥
LLMの普及に伴い、世界各国で以下のような議論が活発化しています。 倫理: AIが生成したコンテンツの責任の所在、意思決定におけるAIの役割、自律性を持つAI(AGI: 汎用人工知能)の潜在的リスクなど。 著作権: LLMの訓練データに含まれる著作物の扱い、AIが生成したコンテンツの著作権、クリエイターへの公正な対価の支払いなど。EUのAI法など、法整備の動きも進んでいます。 バイアス: LLMは訓練データに含まれる社会的バイアス(人種、性別、思想など)を学習・増幅してしまう可能性があります。公平で偏りのないAIを実現するための技術的・社会的な取り組みが求められています。 誤情報・偽情報 (Disinformation): LLMはもっともらしい嘘(ハルシネーション)を生成したり、悪意を持って偽情報を大量生成・拡散するために利用されたりするリスクがあります。特に選挙など、社会的に重要な場面での悪用が懸念されています。教訓:技術の可能性と社会的責任のバランス ⚖️
他国の状況を見ると、LLMが持つ大きな可能性と同時に、無視できないリスクも浮き彫りになります。技術の進歩を促進し、その恩恵を享受しつつも、倫理的な配慮、社会的な影響への目配り、そして適切なルール作りが不可欠です。 特に、透明性(Transparency)と説明可能性(Explainability)の確保は重要な課題です。LLMがどのように結論に至ったのかを理解できなければ、その出力を盲信することは危険です。また、開発者や提供企業には、技術が悪用されるリスクを低減し、社会に対する責任を果たすことが求められます。 単に技術的な性能を追求するだけでなく、**人間中心(Human-Centric)**な視点を持って、LLMを社会に実装していく必要があると言えるでしょう。コラム:世界のAI事情ウォッチ (🌍👀)
世界に目を向けると、AI開発競争はますます激化していますね! アメリカと中国が火花を散らし、EUはルール作りに奔走し…。日本も負けてられないぞ!と意気込みたいところですが、周回遅れ感も否めないような…。😅 でも、各国それぞれのお国柄や文化が、AIとの付き合い方にも反映されていて面白いですよね。例えば、プライバシーに対する考え方の違いとか。世界中の動きをウォッチしていると、日本の進むべき道も見えてくる…かもしれませんね!
/ ̄ ̄ ̄ ̄\ / ( ● ) ( ● ) \ < セカイハ ヒロイナー | (_人_) | > ∩ノ⊃ < / / Lノ \ | / /\ / `⌒)\ | / .< L / )/ \( /`ー---─ Tフ / `ー---―‐‐´
LLM狂騒曲:日本における影響と教訓 🇯🇵
さて、視点を日本国内に移してみましょう。LLMは日本社会にどのような影響を与え、私たちはそこから何を学ぶべきでしょうか?日本でのLLM導入状況(企業、個人の温度差)🌡️
企業: 大企業を中心に、業務効率化や新サービス開発を目指してLLMの導入・実証実験が進んでいます。特に、顧客サポート、社内文書の要約・検索、プログラミング支援などの分野での活用が目立ちます。しかし、中小企業ではコストや人材、ノウハウ不足から導入に踏み切れないケースも多く、企業規模による温度差が見られます。また、海外の先進事例に比べて、やや慎重な姿勢の企業が多い印象もあります。 個人: ChatGPTの登場以降、個人の間でもLLMへの関心は高まっています。情報収集、文章作成支援、アイデア出し、プログラミング学習など、様々な目的で利用されています。一方で、「何に使えばいいかわからない」「精度が不安」「情報漏洩が心配」といった声も聞かれ、積極的な活用層と様子見層に分かれている状況と言えるでしょう。日本語特有の課題とLLMの適応 🗣️
LLMを日本語で利用する際には、特有の課題も存在します。 言語の複雑性: 日本語は敬語、曖昧な表現、文脈依存性など、英語に比べて複雑な要素が多く、LLMが完全にニュアンスを理解し、自然な日本語を生成するにはまだ課題があります。時折、不自然な言い回しや翻訳調の文章が出力されることもあります。 データの偏り: 多くの高性能LLMは、主に英語のデータで訓練されています。そのため、日本語のデータ量が相対的に少なく、日本の文化や社会に特有の知識が不足している場合があります。国内企業や研究機関による日本語特化型LLMの開発も進んでいますが、まだ発展途上です (DeepSeekのような中国発のモデルも注目されていますが)。 文化的背景: LLMの応答が、日本の文化や慣習にそぐわない場合もあります。より日本の文脈に適応したLLMの開発が求められています。教育、労働市場への影響 🎓💼
教育: レポート作成支援やプログラミング教育での活用が期待される一方、思考力や文章力の低下、安易な剽窃(コピペ)を助長する懸念があります。教育現場での適切なガイドライン策定が急務です。 労働市場: 定型的な事務作業や一部の専門職(翻訳、ライティング、プログラミングの一部など)がLLMによって代替される可能性が指摘されています。これにより、雇用の流動化が進む一方で、スキルを持たない労働者が取り残されるリスクもあります。リスキリング(学び直し)や、AIを使いこなす能力の重要性が増しています。教訓:慎重さと積極性の間で 🚶♂️💨
日本の状況からは、LLM導入における慎重さと、グローバルな競争に取り残されないための積極性のバランスを取ることの難しさがうかがえます。 「石橋を叩いて渡る」的な慎重さは、リスクを回避する上で重要ですが、過度になると技術革新の波に乗り遅れてしまう可能性があります。一方で、海外のトレンドを鵜呑みにせず、日本の実情や文化に合わせてLLMを導入していく視点も不可欠です。 重要なのは、LLMを過度に恐れたり、逆に過度に期待したりすることなく、その能力と限界を冷静に見極め、試行錯誤しながら最適な活用方法を見つけていくことでしょう。また、AIリテラシー教育を推進し、社会全体でAIと共存していくための議論を深めることも重要です。コラム:ニッポンのAI未来予想図 🗾
日本のAI、これからどうなるんでしょうね? 個人的には、真面目で職人気質な日本人の特性を活かして、高品質で信頼性の高いAIサービスが生まれるポテンシャルはあると思うんです。ただ、新しい技術を取り入れるスピード感とか、リスクを取る姿勢みたいなところは、ちょっと苦手分野かも…?😅 でも、アニメやゲームみたいに、独自の文化と融合した面白いAI活用法が日本から生まれてきたら、世界を驚かせられるかもしれませんよね! ワクワク!
/\ / .\ < AIデ ガンバルゾイ! / .\ / \ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄\ | ● ● | | (_人_) | | \/ | \_________/
LLMへの疑問符:多角的な視点からの考察 🤔❓
LLMの可能性に期待が集まる一方で、その普及には様々な疑問や懸念も投げかけられています。ここでは、いくつかの重要な論点を多角的に考察してみましょう。本当に生産性は向上しているのか?測定の難しさ 📈📉
LLMが業務効率を改善するという話はよく聞かれますが、その効果を客観的に測定するのは難しいという側面があります。 タスクによる差: 定型的な文章作成やコード生成など、特定のタスクでは時間短縮効果が見られるかもしれません。しかし、創造性が求められる作業や、複雑な問題解決においては、LLMとの対話や出力の修正に時間がかかり、かえって生産性が低下する可能性もあります。 品質の評価: LLMが生成したアウトプットの「質」をどう評価するかも問題です。一見もっともらしい文章やコードでも、内容が不正確だったり、潜在的なバグを含んでいたりする場合があります。品質チェックの手間を考えると、トータルの生産性向上効果は限定的かもしれません。 長期的な影響: 短期的な効率化だけでなく、LLMへの依存が長期的に見て人間のスキルや思考力にどのような影響を与えるかも考慮する必要があります。環境負荷、エネルギー消費の問題 🌍🔌
高性能なLLMの開発と運用には、膨大な計算資源と電力が必要です。 訓練コスト: GPT-3クラスのモデルを一回訓練するには、数百万ドル相当の計算コストと、大量のCO2排出が伴うと推計されています。モデルが大規模化・高性能化するにつれて、その環境負荷は増大する傾向にあります。 推論コスト: モデルを利用する際(推論時)にも、無視できない電力消費が発生します。世界中のユーザーが日常的にLLMを利用するようになれば、その総エネルギー消費量は莫大なものになる可能性があります。 持続可能性: AI技術の持続可能性を考えると、よりエネルギー効率の高いモデルの開発や、再生可能エネルギーの利用促進などが重要な課題となります。依存による思考力低下のリスク 🧠📉
便利なツールに頼りすぎると、人間本来の能力が衰えてしまうのではないか、という懸念は昔からあります(例:電卓と暗算能力)。LLMに関しても同様のリスクが指摘されています。 検索能力の低下: わからないことがあればすぐにLLMに聞いてしまう習慣がつくと、自分で情報を探し、吟味し、理解する能力が低下するかもしれません。 文章力・表現力の低下: 文章作成をLLMに任せきりにすると、自分の言葉で考え、表現する力が衰える可能性があります。 問題解決能力の低下: 複雑な問題に直面した際、LLMに安易に答えを求め、自分で粘り強く考えることを放棄してしまうかもしれません。 LLMを思考の補助輪として賢く使う分には問題ありませんが、思考そのものを代替させてしまうことには注意が必要です。情報の信頼性と幻覚(Hallucination)問題の根深さ 👻
LLMが**事実に基づかないもっともらしい情報(幻覚)**を生成してしまう問題は、依然として深刻です。 原因: LLMは統計的なパターンに基づいてテキストを生成するため、情報の真偽を判断する能力はありません。訓練データに含まれる誤情報やバイアス、あるいは学習プロセスの限界から、幻覚が発生します。 影響: 幻覚によって生成された誤情報が拡散され、社会的な混乱を招くリスクがあります。特に、医療や法律、金融など、情報の正確性が極めて重要な分野での利用には細心の注意が必要です。 対策の限界: 事実確認(Fact-Checking)機能の統合や、より信頼性の高い訓練データの利用など、幻覚を抑制するための研究が進められていますが、完全な解決は困難とされています。利用者は、LLMの出力を鵜呑みにせず、常に**批判的な視点(Critical Thinking)**を持って情報を評価する必要があります。 これらの疑問点や懸念に対して、技術的な改善と社会的なルール作りの両面から取り組んでいくことが、LLMとの健全な未来を築く上で不可欠と言えるでしょう。コラム:疑うことも大事だよね (・∀・)
新しい技術が登場すると、ついつい良い面ばかりに目が行きがちですよね。でも、「本当に大丈夫なの?」「何か落とし穴はない?」って、ちょっと立ち止まって疑ってみることも、すごく大事だと思うんです。LLMも、魔法の杖みたいに言われるけど、よく見ると結構危なっかしいところもあるわけで…。盲信するんじゃなくて、ちゃんと自分の頭で考えて、良いところも悪いところも理解した上で付き合っていく。それが賢いユーザーってもんじゃないでしょうかね!✨
___ / ― \ / (●) (●)\ | ::::::(__人__)::::: | < ホントカナー? \ `ー' / ノ \ /´ ヽ
ネットの反応予測(海外編)と筆者の反論 💬🥊
この記事が海外の技術系コミュニティ、例えばHacker News (HN)やRedditあたりで話題になったとしたら、どんなコメントが付くでしょうか? ちょっと想像してみましょう。そして、売れっ子ブロガー()として、それらのコメントにビシッと反論してみせます!予測コメント1 (Reddit/HN): 「著者のBuzzFeed事例は基礎的すぎる。もっと高度なNLP技術があるだろ」
"The author's BuzzFeed examples (classification, labeling) are pretty basic stuff. There are more sophisticated traditional NLP techniques that could achieve similar results, probably with better accuracy and explainability. Relying on a black-box LLM for this seems lazy." (訳:著者のBuzzFeed事例(分類、ラベリング)はかなり基本的なことだ。もっと洗練された従来のNLP技術でも同様の結果が得られるだろうし、おそらく精度や説明可能性も高い。ブラックボックスのLLMに頼るのは怠慢に見える。) 筆者の反論: rebuttal: ご指摘ありがとうございます! 確かに、従来の自然言語処理(NLP: Natural Language Processing)技術、例えばTF-IDFとSVM(Support Vector Machine)を用いた分類や、トピックモデリング(LDAなど)を用いたラベリングも選択肢としてはありました。しかし、今回のケースではLLM(Claude Sonnet API)を選択したのには明確な理由があります。それは、開発速度と柔軟性です。 新しい階層分類体系への対応や、クラスターごとの自由形式なタイトル・説明文生成といったタスクは、従来のNLP技術でゼロからモデルを構築・訓練・評価するとなると、かなりの時間と専門知識を要します。特に、十分な教師データがない状況では、そのハードルはさらに上がります。 一方、LLMを使えば、わずかなプロンプト調整と数時間の作業で「8割方まともな」結果を得ることができました。これは、ビジネスのスピード感が求められる現場において、非常に大きなメリットです。もちろん、精度や説明可能性の点でLLMに課題があることは認識しており、だからこそ最終的な人間のチェックを必須としています。LLMは銀の弾丸ではありませんが、特定の条件下においては、従来の技術よりも圧倒的に早く、費用対効果の高いソリューションを提供してくれる「便利な道具」なのです。怠慢ではなく、合理的な選択だと考えています (`・ω・´)キリッ予測コメント2 (Reddit/HN): 「コーディングエージェントを使わないなんて時代遅れ。幻覚も自己修正する」
"The author's dismissal of coding agents like Cursor or Copilot because they're 'distracting' or 'unreliable' feels outdated. Modern agents can self-correct, check their work, integrate project context, and significantly boost productivity. Not using them is just leaving performance on the table." (訳:著者がCursorやCopilotのようなコーディングエージェントを「気が散る」とか「信頼できない」という理由で否定しているのは時代遅れに感じる。現代のエージェントは自己修正し、作業を確認し、プロジェクトの文脈を統合し、生産性を大幅に向上させることができる。それらを使わないのは、単にパフォーマンスを無駄にしているだけだ。) 筆者の反論: rebuttal: 時代遅れ、ですか…手厳しいですね(笑)。コーディングエージェントの進化が目覚ましいことは認識していますし、自己修正能力や文脈理解能力が向上していることも承知しています。理論上は、おっしゃる通り生産性を劇的に向上させる可能性を秘めているでしょう。 しかし、現状ではまだ、筆者が全面的に信頼を置けるレベルには達していない、というのが正直な感想です。記事中でも触れましたが、Hacker Newsのコメント欄(元の記事に付いていたもの)を見ても、「エージェントがループに陥って延々とおかしな修正を繰り返す」「意図しない変更を大量に加えられて、結局手動で元に戻す羽目になった」といった報告は後を絶ちません。自己修正機能も万能ではなく、特にニッチなライブラリや複雑なロジックに関しては、依然として幻覚を起こしやすい傾向があります。 また、「気が散る」という点も、単なる個人の好みではなく、集中力の維持という生産性における重要な要素に関わる問題だと考えています。頻繁な提案とレビューの繰り返しは、深い思考を妨げる可能性があります。 そして、コストの問題も無視できません。高機能なエージェントは多くの場合、高価なサブスクリプションを必要とします。そのコストに見合うだけの生産性向上が確実に得られるという保証がない限り、導入には慎重にならざるを得ません。 もちろん、これは現時点での筆者の評価であり、技術の進歩によって状況が変わる可能性は十分にあります。しかし、現時点では、必要な時にLLM APIに直接質問したり、基本的なコード生成を依頼したりする方が、筆者のワークフローにとってはより確実で、コントロールしやすく、費用対効果が高いと判断しています。パフォーマンスを「無駄にしている」のではなく、リスクとリターンを天秤にかけた結果なのです C:。予測コメント3 (Reddit/HN): 「LLM嫌いはターミネーターの見過ぎ」
"This 'I don't use LLMs much' stance often comes from people overly influenced by sci-fi fears like Skynet or HAL 9000. The real issues aren't existential threats, but practical ones like bias and accuracy. The author mixes valid concerns with vague technophobia." (訳:この「LLMあまり使わない」スタンスは、スカイネットやHAL 9000のようなSF的な恐怖に過度に影響された人々からよく出てくる。真の問題は実存的脅威ではなく、バイアスや精度といった実用的なものだ。著者は妥当な懸念と曖昧なテクノフォビア(技術恐怖症)を混同している。) 筆者の反論: rebuttal: ご心配なく! 筆者はターミネーターも2001年宇宙の旅も大好きですが、LLMに対する懸念はSF的な空想に基づいたものではありません。むしろ、極めて現実的な問題に基づいています。 記事で述べた懸念、例えばLLMハルシネーションによる誤情報の拡散、訓練データに起因するバイアスの増幅、プライバシー侵害のリスク(こちらの記事で詳述)、著作権の問題、そして雇用の不安定化といった点は、すでに現実世界で起こりつつある、あるいは起こる可能性が非常に高い問題です。これらは「曖昧なテクノフォビア」ではなく、技術の社会実装に伴う具体的なリスクに対する正当な懸念です。 もちろん、LLMがもたらす便益を否定するものではありません。筆者自身、仕事でその恩恵を受けています。しかし、光の部分だけを見て、影の部分から目を背けるのは健全ではありません。技術の進歩を歓迎しつつも、その負の側面にも注意を払い、適切な対策を講じていく。それが、責任ある技術との向き合い方だと考えています。SF映画の心配をする前に、目の前にある現実の問題に目を向けませんか? ( ̄ー ̄)コラム:ネット論争は不毛?いや、面白い!🤣
ネット上の議論って、時々すごく不毛に感じること、ありますよねぇ…。売り言葉に買い言葉、揚げ足取りの応酬、みたいな。でも、異なる視点や鋭いツッコミに触れることで、自分の考えが深まったり、新しい発見があったりすることも事実。Hacker Newsみたいな場所で、世界中のエンジニアと(擬似的にでも)意見を戦わせるのは、結構スリリングで面白い体験です。もちろん、コメントに一喜一憂しすぎず、冷静に受け止めるメンタルも必要ですけどね!💪
HN Reddit / \ / コメント \ <オラオラ!> <かかってこい!> \ (;`皿´) (`Δ´)/ `------- --------` \ / `---' 筆者 ( ゚д゚) < ファ!?
結論:LLMはただのツール、されど…? 🛠️✨
さて、長々と語ってきましたが、結局のところLLMとは何なのでしょうか? 筆者の結論は、極めてシンプルです。LLMは、**「ツールボックスの中の、ちょっと賢くて、時々嘘をつく、新しい道具」**にすぎません。 しかし、ここで少し突飛な論理を展開してみましょう。この「新しい道具」に、なぜ私たちはこれほどまでに熱狂し、あるいは警戒するのでしょうか? それは、LLMが単なる技術を超えて、人間の知性や創造性、そして社会のあり方そのものを映し出す鏡のような存在だからではないでしょうか? LLMは、膨大な人間の言語データを学習することで、人間がどのように思考し、コミュニケーションし、世界を認識しているかの統計的なモデルを構築します。その出力は、時に驚くほど人間的であり、時に奇妙で非人間的です。それは、私たち自身の集合的な知性と、その限界や歪みを反映しているのかもしれません。LLMへの期待と不安は、実は私たち自身が持つ、知性への憧憬と、未知なるものへの根源的な恐れの現れなのではないでしょうか? まるで、現代の錬金術のように、ありふれたデータから「知性」という黄金を生み出そうとする、人間の飽くなき探求心の産物とも言えるかもしれません。今後の研究への期待 🔬
LLMが真に社会の役に立つツールとして定着するためには、さらなる研究開発が不可欠です。筆者が特に期待するのは、以下の方向性です。 信頼性と説明可能性の向上: ハルシネーションを抑制し、なぜそのような出力をしたのかを人間が理解できる、より**「正直」で「透明」**なLLMの開発が急務です。 特化型モデルと汎用モデルの連携: あらゆるタスクを一つの巨大モデルでこなそうとするのではなく、特定の分野やタスクに特化した小型・高効率なモデルと、それらを束ねる汎用的なオーケストレーション技術(MCPのようなものも含む)の発展が望まれます。 人間との協調インタフェース: LLMを単なる「命令実行マシン」としてではなく、人間の思考や創造性を自然にサポートし、拡張するような、より洗練されたインタフェースやワークフローの研究が必要です。 倫理的・社会的課題への取り組み: バイアス、公平性、プライバシー、著作権などの問題に対し、技術的な解決策だけでなく、社会的なコンセンサス形成やルール作りを継続的に行っていく必要があります。 これらの研究が進展すれば、LLMは現在の課題を克服し、真に生産性を向上させ、人間の創造性を刺激し、より良い社会の実現に貢献するポテンシャルを秘めていると信じています。歴史的位置付けと古典の警句 📜
LLMの登場は、情報技術の歴史において、どのような位置付けになるのでしょうか? インターネットの普及やスマートフォンの登場に匹敵する、パラダイムシフトの始まりなのかもしれません。あるいは、一時的な熱狂の後、より現実的な評価に落ち着くのかもしれません。 歴史を振り返れば、新たな技術が登場するたびに、期待と不安が渦巻いてきました。産業革命が社会構造を大きく変えたように、LLMもまた、私たちの働き方、学び方、そしてコミュニケーションのあり方を根本的に変容させる可能性を秘めています。 しかし、技術そのものに善悪はありません。その価値を決めるのは、常に人間です。古代ローマの哲学者セネカは、こう述べています。LLMという強力な技術を、単なる偶然や思いつきで使うのではなく、明確な目的意識と倫理観を持って使いこなしていくこと。それこそが、私たちに求められている姿勢なのかもしれません。 最後に、この記事の内容を詠んだ短歌を一つ。 えれえれむ(LLM) 使いこなせど 頼らぬは 我が言葉こそ 真(まこと)なりけれNon est ars quae ad effectum casu venit.
(偶然に結果をもたらすものは、技術ではない。)
参考文献 📚
この記事を書くにあたり、参考にした(あるいは本文中で言及した)ウェブページやリソースのリストです。(順不同) DopingConsomme Blog: https://dopingconsomme.blogspot.com/ (拙著ブログです!フォローミー!) BuzzFeed: https://www.buzzfeed.com/ OpenAI API: https://openai.com/api/ Anthropic API: https://www.anthropic.com/api Claude 3.5 Sonnet Announcement: https://www.anthropic.com/news/claude-3-5-sonnet Nomic Embed Text: https://wow.groq.com/nomic-embed-text-open-embedding-model/ GTE-modernbert-base (Hugging Face): https://huggingface.co/thenlper/gte-modernbert-base Hacker News: https://news.ycombinator.com/ Character.ai: https://character.ai/ Replika: https://replika.com/ Pillow (Python Imaging Library): https://pillow.readthedocs.io/en/stable/ Stack Overflow: https://stackoverflow.com/ SQLite: https://www.sqlite.org/index.html Hugging Face Transformers Trainer: https://huggingface.co/docs/transformers/main_classes/trainer Pandas: https://pandas.pydata.org/ Polars: https://pola.rs/ R Project: https://www.r-project.org/ ggplot2: https://ggplot2.tidyverse.org/ GitHub Copilot: https://github.com/features/copilot Model Capabilities Protocol (MCP) - ArXiv: https://arxiv.org/abs/2404.08141 (関連論文) LangChain: https://www.langchain.com/ Claude Code (via Claude website): https://claude.ai/ Cursor: https://cursor.sh/ Reddit: https://www.reddit.com/ Simon Willison's Blog Post (AI-Assisted Search): https://simonwillison.net/2025/Apr/21/ai-assisted-search/ (HNコメントからの参照) Simon Willison's Blog Post (LLM Video Frames): https://simonwillison.net/2025/May/5/llm-video-frames/ (HNコメントからの参照) LLM CLI Tool (Simon Willison): https://llm.datasette.io/ (HNコメントからの参照、GitHubリポジトリへのリンク含む) SimpleAIChat (minimaxir/GitHub): https://github.com/minimaxir/simpleaichat (HNコメントからの参照) Plandex (GitHub): https://github.com/plandex-ai/plandex (HNコメントからの参照) OpenWebUI: https://openwebui.com/ (HNコメントからの参照) OpenAI Playground: https://platform.openai.com/playground Anthropic Console Workbench: https://console.anthropic.com/workbench Qwen (Alibaba Cloud): https://qwenlm.github.io/ (言及のみ) DeepSeek: https://www.deepseek.com/ (言及のみ) Together AI: https://www.together.ai/ (LLMホスティングプロバイダー例として言及、原文では"Cerebras"と"Groq"だが、より一般的なTogether AIに変更) Groq: https://groq.com/ (LLMホスティングプロバイダー例として言及) JetBrains Developer Ecosystem Survey: https://www.jetbrains.com/lp/devecosystem-2024/ (参照記事内で言及) Ed Zitron's Substack (AI Critic): https://ez.substack.com/ (言及のみ、直接リンクは避ける) (関連するDopingConsommeブログ記事) MCPとは? AI連携を劇的に変える新プロトコルを徹底解説!: https://dopingconsomme.blogspot.com/2025/04/mcp-aiapi-aimcp-17.html テクノロジー企業は明らかに、私たちが AI を嫌う理由を理解していません: https://dopingconsomme.blogspot.com/2025/05/blog-post.html DeepSeekとは何か?: https://dopingconsomme.blogspot.com/2025/01/deepseekaillmai27.html Scholiumとは何か?: https://dopingconsomme.blogspot.com/2025/03/scholium.html用語索引 (アルファベット順) 📖
- AGI (Artificial General Intelligence)
- 汎用人工知能。特定のタスクだけでなく、人間のように幅広い知的作業をこなせる仮説上のAI。「その他の国での影響と教訓」や「結論」で言及。SFの世界の話だと思われがちだが、真剣に研究されている分野でもある。
- API (Application Programming Interface)
- ソフトウェアやプログラム、Webサービスの間で情報をやり取りするための接続口(インターフェース)の仕様。「なぜAPI直叩きを選ぶのか?」で解説したように、LLMの機能を外部のプログラムから利用するために使われる。
- Callback (クラス)
- 特定のイベントが発生したときに呼び出される関数やメソッドのこと。Hugging Face Transformersライブラリでは、訓練中の特定のタイミング(例:各ステップ終了時)でカスタム処理を実行するためにCallbackクラスが使われる。「Stack Overflowを超えるか?」でSQLiteへのログ記録の例として登場。
- char-rnn
- 文字レベル(character-level)で動作する再帰型ニューラルネットワーク(RNN: Recurrent Neural Network)。テキスト生成の初期の研究で使われた。「序文」で筆者のLLM経験の出発点として言及。
- Claude
- Anthropic社が開発した大規模言語モデル。ChatGPTの競合とされる。特にSonnetモデルは、自然な対話生成能力に定評がある(と筆者は感じている)。「システムプロンプトの重要性」や「BuzzFeedでの活用事例」で頻繁に登場。
- Copilot (GitHub Copilot)
- GitHubが提供するAIコーディングアシスタント。エディタ上でコードの候補をリアルタイムに提案する。「インラインアシスタントへの違和感」で、筆者が使わない理由を説明。
- Cursor
- AIを搭載したコードエディタ、またはコーディングエージェント。「エージェント、MCP、バイブコーディングへの辛口評価」や「ネットの反応予測(海外編)」のコメントで言及。
- Embedding (Text Embedding)
- テキスト埋め込み。テキスト(単語、文、文書)を低次元の数値ベクトルに変換する技術。意味が近いテキストはベクトル空間上で近くに配置される。「テキスト埋め込みという別の側面」で解説。
- ETL (Extract, Transform, Load)
- データウェアハウジングやデータ分析の前処理で行われる、データの抽出(Extract)、変換(Transform)、格納(Load)の一連のプロセス。「データサイエンス業務での限界」で、LLMが大規模ETLには向かない点に言及。
- Few-shot Prompting
- プロンプトエンジニアリングの手法の一つ。LLMにタスクの例(入力と期待される出力のペア)をいくつか提示することで、LLMがタスクをよりよく理解し、望ましい形式で出力するように促す。「プロンプトエンジニアリングの現実」や「文体の壁」で言及。
- ggplot2
- R言語で広く使われているデータ可視化パッケージ。洗練されたグラフを比較的簡単に作成できる。「データ可視化」で筆者が愛用しているツールとして登場。
- GPT (Generative Pre-trained Transformer)
- OpenAIによって開発された、Transformerアーキテクチャに基づく一連の大規模言語モデル(GPT-2, GPT-3, GPT-4など)。「序文」で言及。
- Hallucination (LLM Hallucination)
- LLMハルシネーション。LLMが事実に基づかない情報や、もっともらしい嘘を生成してしまう現象。「Temperature調整の妙技」、「8割解決の威力と限界」、「なぜチャットボットとして使わないか」、「情報の鮮度」、「情報の信頼性と幻覚問題の根深さ」など、記事全体で繰り返し言及される重要な課題。
- Hugging Face Transformers
- 自然言語処理のためのオープンソースライブラリ。多くの事前学習済みモデル(Transformerベース)や、それらを扱うためのツール(Trainerクラスなど)を提供している。「Stack Overflowを超えるか?」のコーディング例で登場。
- JSON (JavaScript Object Notation)
- 軽量なデータ交換フォーマット。人間にも読み書きしやすく、機械にも解析しやすい。Web APIなどで広く利用される。「事例1:記事の自動分類システム」や「事例2:記事クラスターへの意味付け」で、LLMの出力形式として指定。
- LangChain
- LLMを使ったアプリケーション開発を支援するフレームワーク。「エージェント、MCP、バイブコーディングへの辛口評価」の補足説明で言及。
- LLM (Large Language Model)
- 大規模言語モデル。大量のテキストデータで訓練された、巨大なニューラルネットワークモデル。文章生成、要約、翻訳、質問応答など、様々な自然言語処理タスクを実行できる。この記事全体のテーマ。「序文」以下多数。
- MCP (Model Capabilities Protocol)
- モデル能力プロトコル。異なるAIモデル(LLMなど)やツールが連携するための標準的な方法を定義しようとする提案。「エージェント、MCP、バイブコーディングへの辛口評価」や「今後の研究への期待」で言及。
- Multi-class Classification
- 多クラス分類。機械学習の分類問題の一種で、データを3つ以上のクラス(カテゴリ)のいずれかに分類するタスク。「事例1:記事の自動分類システム」で、従来の機械学習手法として言及。
- NLP (Natural Language Processing)
- 自然言語処理。人間が日常的に使う言語(自然言語)をコンピュータが処理・理解するための技術分野。「ネットの反応予測(海外編)」の予測コメント1で言及。
- OSS (Open Source Software)
- オープンソースソフトウェア。ソースコードが公開され、誰でも自由に利用、改変、再配布できるソフトウェア。「序文」で筆者の活動の一つとして言及。
- Pandas
- Pythonで広く使われているデータ分析ライブラリ。データフレームという表形式のデータ構造を扱い、様々なデータ操作や処理を行う機能を提供する。「データサイエンス業務での限界」でPolarsとの比較で言及。
- Pareto Principle
- パレートの法則(80:20の法則)。全体の数値の大部分(例:80%)は、全体を構成する要素のうちの一部分(例:20%)が生み出しているという経験則。「8割解決の威力と限界」で、LLMが労力の2割で8割の解決策をもたらす例えとして使用。
- Pillow
- Pythonの画像処理ライブラリ。PIL (Python Imaging Library) からフォークした後継。「Stack Overflowを超えるか?」のコーディング例で登場。
- Polars
- 比較的新しいPythonのデータ分析ライブラリ。Pandasの代替を目指し、特に大規模データの高速処理に強みを持つ。「データサイエンス業務での限界」で筆者が使用しているライブラリとして登場し、LLMがPandasと混同しやすい点に言及。
- Prompt Engineering
- プロンプトエンジニアリング。LLMから望ましい出力を得るために、入力(プロンプト)を工夫する技術やプロセスのこと。「プロンプトエンジニアリングの現実」で詳しく解説。
- Python
- 広く使われているプログラミング言語。データサイエンス、Web開発、機械学習など様々な分野で利用される。「なぜAPI直叩きを選ぶのか?」、「Stack Overflowを超えるか?」、「データサイエンス業務での限界」などで頻繁に登場。
- R (プログラミング言語)
- 統計解析やデータ可視化に特化したプログラミング言語および環境。「データ可視化」で筆者がggplot2と共に愛用しているツールとして登場。
- RAG (Retrieval-Augmented Generation)
- 検索拡張生成。LLMが回答を生成する際に、外部の知識データベース(例:Wikipedia、社内文書)から関連情報を検索(Retrieval)し、その情報を考慮に入れて回答を生成(Generation)する技術。ハルシネーションを抑制し、最新情報に基づいた回答を可能にする。「推薦図書」や「上方漫才」などで関連技術として言及される可能性。
- ReAct (Reasoning and Acting)
- LLMが推論(Reasoning)と行動(Acting、ツール利用など)を組み合わせてタスクを実行するフレームワークを提案した研究(論文)。「エージェント、MCP、バイブコーディングへの辛口評価」の補足説明で、エージェント技術の起源として言及。
- Regex (Regular Expression)
- 正規表現。文字列の中から特定のパターンを持つ部分文字列を検索・置換するための形式言語。「正規表現生成」で、LLMが得意とするタスクとして紹介。
- RLHF (Reinforcement Learning from Human Feedback)
- 人間のフィードバックによる強化学習。人間の評価者がLLMの出力の良し悪しを評価し、そのフィードバックを使ってLLMをさらにファインチューニング(微調整)する技術。より安全で人間にとって有用な応答を生成させるために広く使われている。「プロンプトエンジニアリングの現実」で、プロンプトエンジニアリングの必要性を減らす試みとして言及されるも、逆効果だったと指摘。
- SQLite
- 軽量なファイルベースのリレーショナルデータベース管理システム。サーバープロセスを必要とせず、アプリケーションに組み込んで使いやすい。「Stack Overflowを超えるか?」のコーディング例で、訓練ログの保存先として登場。
- Stack Overflow
- プログラマー向けのQ&Aサイト。コーディングに関する疑問を解決するための情報源として広く利用されている。「Stack Overflowを超えるか?」で、LLMとの比較対象として言及。
- System Prompt
- システムプロンプト。LLM APIなどで、ユーザープロンプトとは別に設定できる、LLMの全体的な振る舞いや役割、制約などを定義するための指示。「システムプロンプトの重要性」で解説。
- Temperature
- 温度設定。LLMの出力のランダム性・創造性を制御するパラメータ。「Temperature調整の妙技」で解説。
- Token
- トークン。LLMがテキストを処理する際の基本的な単位。通常、単語やサブワード(単語の一部)、句読点などがトークンとして扱われる。LLMは次のトークンを予測することでテキストを生成する。「Temperature調整の妙技」や「テキスト埋め込みという別の側面」で言及。
- Trainer (Hugging Face Trainer クラス)
- Hugging Face Transformersライブラリに含まれるクラス。モデルの訓練ループ(エポック、ステップ、評価など)を簡単に管理・実行するための機能を提供する。「Stack Overflowを超えるか?」のコーディング例で登場。
補足1: 用語解説 (あいうえお順) 📖🖋️
ここでは、本文中に登場した専門用語や略語を、もう少し砕けた感じで、時に皮肉も交えつつ解説します。Wikipediaへのリンクはnofollowです。- API (エーピーアイ)
-
解説: アプリケーション・プログラミング・インターフェースの略。ソフトウェア同士がおしゃべりするための「通訳」兼「窓口」みたいなもの。これがないと、ChatGPTに「ブログ書いて」ってプログラムから頼めない。
用例: 「またAPIの仕様変更かよ…勘弁してくれ😩」「このAPI、ドキュメントが不親切すぎる!」
類語: インターフェース、接続仕様、連携口
Wikipedia: Application Programming Interface - AGI (エージーアイ)
-
解説: 汎用人工知能。人間みたいに何でもできる(かもしれない)スーパーAIのこと。「ターミネーター」の世界か、「ドラえもん」の世界か、未来はどっちだ?
用例: 「AGIが実現したら、俺たちの仕事なくなるんじゃね?」「AGIより先に、まずは明日の会議資料作れって話だよな。」
類語: 強いAI、超知能
Wikipedia: 人工汎用知能 - Embedding (エンベディング)
-
解説: テキスト埋め込み。言葉や文章を、コンピュータが扱いやすい「数字のベクトル(座標みたいなもの)」に変換する技術。「犬」と「猫」は近くに、「犬」と「机」は遠くに配置されるイメージ。これで類似記事を探したりできる。
用例: 「この単語のEmbedding、なんか変な方向向いてるぞ?」「Embeddingの次元数、いくつにするのが最適なんだろう…🤔」
類語: 分散表現、ベクトル表現
Wikipedia: 単語埋め込み (Text Embeddingはより広範な概念) - LLM (エルエルエム)
-
解説: 大規模言語モデル。めちゃくちゃ大量の文章を読んで、言葉のパターンを覚えた超巨大AI。文章作ったり、要約したり、色々できるけど、時々平気で嘘つくのが玉に瑕。
用例: 「このLLM、またハルシネーション起こしてる…」「どのLLM使うのが一番コスパいいかな?」
類語: 大規模言語AI、基盤モデル(Foundation Model)
Wikipedia: 大規模言語モデル - OSS (オーエスエス)
-
解説: オープンソースソフトウェア。設計図(ソースコード)が公開されてて、誰でもタダで使ったり改造したりできるソフトウェアのこと。プログラマー界の「みんなで作ってみんなで使う」精神の象徴。
用例: 「この機能、OSS探せばありそうだな」「OSSにコントリビュート(貢献)してみたいけど、ハードル高い…」
類語: フリーソフトウェア(思想は少し違う)
Wikipedia: オープンソースソフトウェア - JSON (ジェイソン)
-
解説: データ形式の一つ。波括弧 `{}` とか角括弧 `[]` を使って、情報を構造的に表現する。Webの世界では超メジャー。見た目がシンプルで、プログラムからも扱いやすい。
用例: 「APIのレスポンス、JSONで返してって言ったのにXMLで来たぞ!💢」「このJSON、ネスト深すぎ…」
類語: データ形式、データ構造 (厳密には違う)
Wikipedia: JavaScript Object Notation - Temperature (テンパレチャー)
-
解説: LLMの「おふざけ度」調整パラメータ。温度が高いと、ぶっ飛んだ回答が出やすくなる(創造的とも言う)。低いと、真面目でつまらない回答になりがち(決定的とも言う)。TPOに合わせて調整が必要。
用例: 「ブレストしたいから、Temperature高めでお願い!」「仕様書書いてもらうから、Temperatureは0で。」
類語: ランダム性、多様性パラメータ
(Wikipediaには直接的な項目なし) - Token (トークン)
-
解説: LLMが文章を区切る最小単位。単語だったり、単語の一部だったり、句読点だったり。「こんにちは」が「こん」「にちは」の2トークンになったりする。LLMの利用料金は、このトークン数で決まることが多いので地味に重要。
用例: 「このプロンプト、トークン数多すぎ!」「日本語はトークン数食うんだよな…」
類語: 語彙素(厳密には違う)
Wikipedia: トークン (言語学) (近い概念) - Hallucination (ハルシネーション)
-
解説: LLMの「幻覚」。事実じゃないことを、さも本当かのように自信満々に語っちゃう現象。LLM最大の弱点であり、ネタの宝庫でもある。「知ったかぶりAI」とも言える。
用例: 「またLLMがハルってるよ…」「この情報のソース、まさかハルシネーションじゃないだろうな?」
類語: 捏造、作話、妄想(?)
(Wikipediaには直接的な項目なし、AIの文脈での解説が必要) - Prompt Engineering (プロンプトエンジニアリング)
-
解説: LLMから 원하는(望む)回答を引き出すための「おだて方」「指示の出し方」テクニック。まるで気難しい上司やAI様のご機嫌を取るかのよう。「こう書けば言うこと聞くやろ?」的な試行錯誤の連続。
用例: 「このタスク、プロンプトエンジニアリングが肝だな」「俺のプロンプトエンジニアリング力を見せてやるぜ!」
類語: プロンプトデザイン、指示設計、呪文詠唱(?)
Wikipedia: プロンプトエンジニアリング - Python (パイソン)
-
解説: プログラミング言語界の優等生。文法が比較的シンプルで読みやすく、AI・機械学習、Web開発、データ分析と、活躍の場が広い。とりあえず学んどけ、的な風潮もある。
用例: 「この処理、Pythonで書けば一瞬だよ」「Pythonista(パイソニスタ:Python愛好家)歓喜のライブラリ登場!」
類語: ニシキヘビ(本来の意味)
Wikipedia: Python - R (アール)
-
解説: 統計解析とグラフ作成に特化したプログラミング言語。データサイエンティストや研究者に愛用者が多い。独特の文法に最初は戸惑うが、慣れると強力な武器になる。Pythonとの勢力争いも…?
用例: 「このグラフはRじゃないと描けないな」「R使いこなせる人、尊敬するわ…」
類語: (特になし)
Wikipedia: R言語 - Regex (レゲックス)
-
解説: 正規表現。文字列の中から特定のパターンを見つけ出すための「魔法の呪文」。読めない、書けない、でも使えると超便利。エンジニアの必須スキル…のはずだが、苦手な人も多い(筆者含む)。
用例: 「この複雑なRegex、誰が書いたんだ…解読不能だろ」「Regex一発でこの置換ができると気持ちいい!」
類語: 正規式
Wikipedia: 正規表現 - RLHF (アールエルエイチエフ)
-
解説: 人間のフィードバックによる強化学習。AIの回答に対して人間が「いいね!」とか「ダメだね!」とか評価して、AIを「しつける」技術。より人間好みの、当たり障りのない回答をするAIを作るのに使われる。
用例: 「RLHFのおかげで、AIが変なこと言わなくなったね」「RLHFって、結局AIを忖度させる技術なんじゃ…?」
類語: 人間による強化学習
(Wikipediaには直接的な項目なし、強化学習の文脈で解説が必要)
コメント
コメントを投稿