経験豊富なLLMユーザーなのに、実際にはあまり使わない理由

 (minimaxir.com)
29 ポイント 投稿者 GN⁺ 2025-05-06 | 2件のコメント | WhatsAppで共有
  • 著者は10年以上にわたりLLMとテキスト生成技術を研究してきたが、意外にも日常生活ではLLMをあまり頻繁には使わないと明かしている
  • LLMを使う際には、プロンプトエンジニアリング、システムプロンプトの設定、温度調整などの細かな制御を重視し、一般的なフロントエンドではなくAPIベースのアプローチを好む
  • データラベリング、記事クラスタ要約、スタイルガイドのレビューなど、BuzzFeedの業務で具体的な問題解決にLLMを活用し、大きな時間短縮効果を実証した
  • 文章執筆にはLLMを使わないが、架空のHacker Newsコメントを通じて批判的な観点をテストする形で、文章の論理検証に活用している
  • LLMはコーディング支援に有用だが、複雑だったり信頼性が必要だったりする作業では自分で実装することを好み、エージェントやバイブコーディングについては懐疑的な立場を保っている

私とLLMの距離

  • 著者は、RNNベースのテキスト生成、GPT-2のチューニング、GPT-3/ChatGPTの実験など、生成AIツールの活用経験が豊富なデータサイエンティストである
  • しかし、直接的に頻繁に使うケースはまれで、使うかどうかは作業の性質と必要性に応じて決める道具的なアプローチを取っている

LLMを制御する方法

  • プロンプトエンジニアリングによって望む出力を引き出すことが、LLM活用の中核である
  • 一般的なフロントエンド(ChatGPT.com)ではなく、自分でAPIを呼び出すかバックエンドUI経由で利用しており、特にClaude Sonnet APIを好む
  • システムプロンプトと温度（temperature）調整によって創造性と決定性のバランスを取る。通常は0.0 ~ 0.3に設定し、出力の予測可能性を確保する
  • **ハルシネーション問題（事実ではない内容の生成）**は温度が高いほど悪化しやすい傾向があるため、注意している

業務での活用事例

  • BuzzFeed記事分類の自動化: Claude APIとJSONベースの分類体系、temperature 0.0設定により、正確なカテゴリ割り当てを実施
  • 記事クラスタの要約: 類似記事5本を与え、共通タイトルと説明を返させることで、効率的なクラスタ要約の自動化を実現
  • 句読点とスタイルガイドのレビュー: スタイルガイド全体をシステムプロンプトに入れ、ポリシーに基づく文法判断を実行
  • それぞれの作業は数時間以内にPOCを完成可能で、従来の方法と比べて数日以上の時間削減を実証した

執筆は自分で、批判はLLMで

  • ブログ記事は自分で書いており、文体的にLLMでは再現しにくい独自性がある
  • ただし、LLMにHacker Newsユーザーのような批判的コメントの作成を依頼し、論理的な穴を探すツールとして利用している
  • この方法は文章の質の向上に寄与するが、LLMが文章そのものを代替するわけではない

コーディングにおけるLLM活用

  • 正規表現の作成、Pillowでの画像合成など、複雑だが反復的な作業では、LLMは生産性向上に大きく貢献する
  • 一方で、Polarsのような新しいライブラリを使う際には、LLMがpandas関数と取り違えるなどの問題が発生する
  • Copilotのようなリアルタイムのコード推薦は、精神的なコンテキスト切り替えが増えてかえって集中を妨げるという理由で好まない
  • LLMが提案したアイデアについては、「アイデアを借りて自分で修正する」ほうがよいという立場を維持している

Agents、MCP、Vibe Codingに対する見解

  • MCPとAgentsは概念的には改善されているが、実質的に新しいユースケースは提供できていない
  • Vibe Codingは趣味のプロジェクトには有用かもしれないが、正式な製品には不適切であり、責任逃れの手段として使うべきではない
  • 信頼できるコードだけがプロフェッショナルだという立場を強調している

LLM産業と倫理についての考え

  • 「LLMは無用だ」という主張は実利用の側面から見ると現実を反映しておらず、むしろ短期ROIと産業構造の問題が核心だとしている
  • オープンソースモデルや代替インフラ（Cerebras、Groqなど）は、OpenAIが消えたとしてもLLM需要を満たせる
  • 結局のところ、LLMは目的に合わせて適切に使うべき道具であり、無条件の礼賛も否定もどちらも危険だとしている

まとめ

  • LLMは丸い穴に四角い釘を無理やり押し込むような道具であり、非効率にもなり得るし、革新的にもなり得る
  • 重要なのはいつ、どこで、どう使うかを見極める技術者の判断力であり、それこそがLLM時代の本当の能力だ

関連記事

2件のコメント

 
ifmkl 2025-05-07

いちばん最後の行に共感します。また、私が感じていたことも似ていますが、結局のところ、AIやLLMはユーザーの能力の分だけ使いこなし、活用できるものなんですよね。
 
GN⁺ 2025-05-06
Hacker Newsの意見

  • 経験豊富なプログラマーがLLMsと作業するときに感じる混乱についての意見がある

    • pandasはPythonで表形式データを操作する標準ライブラリで、2008年から使われている
    • 最近は新しいpolarsライブラリを使っており、LLMsがpolarsの関数をpandasの関数と取り違えることが多いため、ドキュメント確認が必要になる
    • コーディングエージェントを使わない理由は「気が散る」からで、自動補完が嫌いな人として共感できる立場だ
    • 「純粋な」LLMsはコーディング作業でコードの誤りを生むが、エージェント型のLLM構成にはLLMとのやり取りを構造化するコードも含まれる
    • LLMが関数の誤りを起こすとプログラムはコンパイルできず、エージェントがそれを検知して、LLMが繰り返し修正する

  • UIやWebサイトのモックを作るときにvibe codingを使っている

    • フロントエンドの経験はないが、80%完成したライブデモを作って他人に見せられるのは価値がある
    • 実際の製品にはまだ準備不足だが、社内議論のためのモック作成には有用だ

  • LLMsで最良の結果を得るためにさまざまな方法を使ってきた

    • LLMsを「だます」シナリオを考えるのは非効率で、モデルのバージョンによって効果が大きく変わることがある

  • あまり人気のないライブラリについての複雑なコード質問では、LLMの出力をより慎重に扱っている

    • ここ数か月、ChatGPTインターフェースを使って新しいライブラリに関するコード質問を解決するのに効果があった
    • 新しいJavaScriptライブラリへコードをアップグレードする作業はうまくいった

  • 新しいライブラリのドキュメントやコードベース全体を長いコンテキストのモデルに直接貼り付ける方法を使っている

    • 50,000トークン以下のライブラリには効果的で、Gemini 2.5 Proは数十万トークンでもうまく扱える

  • 著者がチャットログを含めていた点がよかった

    • 情報を公開できず共有できない人は多いが、LLMの成果を主張するなら、それを裏づけることが重要だ

  • ChatGPT.comや一般向けユーザーインターフェースは使わない

    • 各LLMサービスのバックエンドUIを使って、よりよい結果を得ている
    • OpenAIはChatGPT UIでモデルを制限しがちな傾向がある

  • システムプロンプトを明示的に設定できない現代のLLMインターフェースは、独自のシステムプロンプトを使っている

    • ChatGPTにはシステムプロンプトがあるが、Claudeにはない
    • 新しいモデルではシステムプロンプトの有用性が低下している

  • 生成テキストへの特定の制約を設定するのは、ユーザープロンプトよりシステムプロンプトの方が効果的だ

    • LLMsは30単語の概念を理解するが、この種の作業で常にうまく実行できるわけではない

  • 各LLMサービスのバックエンドUIを使っている

    • APIと連携するためにカスタムラッパーを使っているのか、それとも既に確立されたクライアントを使っているのか気になる

  • JSON応答は常に期待どおりに動くわけではない

    • 一貫したJSONを返すには、JSONスキーマを定義して常に同じ構造を返すようにする

  • LLMを使って新しいことを学んだり、短いスクリプトを書いたりしている

    • ブログ記事のテキストをLLMに入力し、LLMに皮肉屋のHacker Newsコメント投稿者のふりをさせて、5つのコメントを書かせる手法が興味深い