部署横断で取り組んだLLM輪読会 #PERSOL CAREER Advent Calendar2025

Developer&Designer Advent Calendar 2025 24日目の記事です。

はじめに

こんにちは、HR forecasterでエンジニアをしている星野です。

みなさんの会社では、他部署との交流や技術的なディスカッションは活発ですか?

私のチームでは今年、マネジャーの「この書籍、気になっている」という一言をきっかけに、輪読会が発足しました。

今回はその輪読会を振り返ります。

輪読会に参加しようと思ったきっかけ

今回、私がこの輪読会に参加しようと決めた理由は、大きく2つありました。

1つ目は、「独学の限界を感じていたから」です。 業務で生成AIに触れる機会はありましたが、日々のアップデートが激しいこの分野で、断片的なネット記事ではなく「体系的な知識」を身につけたいという想いがありました。しかし、難解な技術書を1人で読み切る自信がなく、強制的に読み進める環境が欲しいと感じていました。

2つ目は、「他チームの知見を知りたかったから」です。 普段は担当プロダクトの深掘りに集中しがちですが、他のチームがLLMをどう捉え、どう活用しようとしているのか、その「生の声」を聞ける絶好のチャンスだと思いました。

「1人では挫折しそうだが、みんなとなら読めるかもしれない」という期待を持って、参加を決意しました。

今回輪読会で読んだ本

今回は『LLMのプロンプトエンジニアリング―GitHub Copilotを生んだ開発者が教える生成AIアプリケーション開発』を読みました。

LLMのプロンプトエンジニアリング ―GitHub Copilotを生んだ開発者が教える生成AIアプリケーション開発

この本の原著であるThe Art and Science of Building Large Language Model–Based Applicationsが2024年に発売されたので、2025年12月時点での最新情報は触れられていません。

しかし、「プロンプトを組み立てて使用する」「サービスの一部として生成AIを組み込む」際、本書は教科書的バイブルだと感じました。

公式の概要にもある通り、LLMのポテンシャルを最大限に引き出すためには、単なる思いつきの命令ではなく、「綿密な設計に基づいたプロンプト」の組み立てが必要です。

そのための小さなテクニックではなく、プロンプトエンジニアリングを根本から学べる本です。

輪読会の概要

  • 参加メンバー: 部署横断で9名
  • 書籍:LLMのプロンプトエンジニアリング ―GitHub Copilotを生んだ開発者が教える生成AIアプリケーション開発
  • 期間:約4か月(フルリモート開催)
  • 頻度:週1回1時間

輪読会の事前準備と本編

今回は「ただ読むだけ」にならないよう、下記の流れで進めました。

  1. 事前学習:全参加メンバーは事前に対象の範囲を読んでくる
  2. 事前準備:輪読会の開始前までに各章のドキュメントに「面白い・なるほどと思った点」「わからなかった点・疑問点」「議論したい点」を書いてくる
  3. 輪読会:書いてきた内容を全員で深掘りする

またファシリテーションは輪番制で、全員が1回は担当する形で回しました。

これら2点によって「読むのを忘れてしまう」「発言者が偏る」ことを防げました。

下記のフォーマットを、実際に使用しました。

2025-07-22_4章

### Aさん
💡 面白い・なるほどと思った点
- LLMアプリケーション開発の出発点は評価であることは意外だった
❓ わからなかった点・疑問点
- 「敵対的プロンプト」の防ぎ方がいまいち腹落ちせず。実務でどこまでケアすべき?
💬 議論したい点
- 安価な(セルフホスト)LLMと高価なLLMの使い分けを定量的に設定するにはどうしたら良いか?

### Bさん
~~ 以下同

このテンプレートのおかげで、当日の議論がスムーズに行えました。

本を読んで得られた気づき

今回の輪読会を通じて、チーム全体で「LLMの正体」について解像度を上げられました。私が特に印象に残ったのは、「LLMは魔法の道具ではなく、徹底したテキスト補完マシンである」という再確認です。

具体的には、以下の3点の気づきがありました。

「考え」ではなく「確率」で動いている

本書では一貫して「LLMはどれほど人間らしく見えても、核心部分は『次の単語』を予測するモデルにすぎない」と述べられていました。これまでどこか「魔法の道具」のような感覚で接していましたが、結局は確率に基づいたテキスト補完であることを再認識しました。この視点を持つことで、なぜLLMが学習していないドメイン知識(社内独自の事業ルールなど)を推測させるのがこれほど難しいのか、その理由が腹落ちしました。

Copilotがループする理由(自己回帰モデル)

開発中にVisual Studio CodeでGitHub Copilotを使っていると、同じ処理のループ提案にハマってしまうことがあります。「なぜそこで詰まる?」と疑問だったのですが、これはLLMが「自己回帰モデル(前の予測結果に依存して次を予測する)」であることに起因しています。仕組みを知ることで、「前の出力に引っ張られているんだな」と冷静に対処できるようになりました。

「立ち止まる」ことができない

人間は答えを出す前に立ち止まって考えたり、振り返ったりすることができます。しかし、今のLLMのモデルには「独り言」や「考える猶予」は与えられず、一気に予測を出力し続けます。この「思考時間の欠如」が、複雑な推論における弱点であることを学びました。

輪読会をやって良かったこと

1人で読んだ時以上の理解を得られた

1人で読んでいる時にはイマイチ理解できなかった概念も、輪読会に持ち込んで議論することで腹落ちさせることができました。

また、自分は理解したつもりの箇所でも、他の参加者の「私はこう感じた」「この参考記事がわかりやすかった」というアウトプットに触れることで、さらに理解の解像度を高められました。一人で読むのが「点」の学習だとすれば、輪読会はそれを「面」で広げていく感覚がありました。

組織を横断した「視点の共有」

普段の業務では接点がない他プロジェクトのエンジニアと交流できたのも大きな収穫です。

それぞれのプロジェクトがどんな取り組みをしていて、どんなことに困っているのか。話し合ってみると「プロンプトの悩みはどのプロジェクトでも同じなんだ」と分かり、組織としての共通課題が見えたのは意外な発見でした。

大変だったこと・解決策

輪読会における一番の課題は、メンバーのスケジュール調整でした。あらかじめ時間を確保していても、プロジェクトの繁忙や突発的な業務対応により、全員が毎週リアルタイムで揃うことは現実的に困難でした。

そこで今回は、Microsoft Teamsの録画とチャット・議事録を徹底して残すことで、非同期でもキャッチアップできる運用を行いました。「リアルタイムで参加できなくても、後から動画を見れば大丈夫」という環境を作ったことで、置いていかれるメンバーを出すことなく、全員で最後まで完走できました。

まとめ

1人で難解な技術書を読んでいると心が折れそうになることがありますが、輪読会という「一緒に読む仲間」がいるおかげで、最後まで読み切れました。

特にLLMのような進化が早く、正解が日々変わっていく分野だからこそ、「本にはこう書いてあるけど、今はこうなっているよね」「以前はこうだったよね」といった議論をしながら読み進めるスタイルは非常に有効でした。

誰か1人でも輪読会をやってみよう・面白そうだなと思ってもらえたら嬉しいです。

※2025年12月現在の情報です。

*

星野 裕太 Yuta Hoshino

クライアントプロダクト本部 テクノロジー統括 プロダクト開発1部

2023年4月新卒でパーソルキャリアに入社。現在はHR forecasterのバックエンド・インフラ開発に従事。