それ、AIのせいにしてませんか？ ― 読書会で変わったプロンプトとの向き合い方

こんにちは、ADWAYS DEEEでアプリケーションエンジニアをしているにっしーです。

私たちの組織では2025年2月ごろからAIツールの業務活用を進めており、現在はClaude Codeを中心に日々の開発に取り入れています。
その取り組みについてはこちらの記事でも紹介しています。

今回は、24卒の同期4人で『LLMのプロンプトエンジニアリング』という本を読書会で読み、学んだことを業務に活かしている話をお伝えします。

24卒同期の過去の記事はこちらです。

この本を選んだ理由

私たち24卒の同期4人は、隔週で情報交換の場を設けています。
メンバーの業務領域はアプリケーション開発、クラウド移行、業務フロー改善、データ分析とそれぞれ異なっており、お互いの業務理解と近況報告に役立てています。
この場でいろいろ話している中で、「AIをもっと上手く使いこなしたい」という共通の課題感が出てきました。

そこで、この情報交換の場を活用して読書会を始めることにしました。
選んだのは『LLMのプロンプトエンジニアリング ―GitHub Copilotを生んだ開発者が教える生成AIアプリケーション開発』（John Berryman、Albert Ziegler 著、服部佑樹、佐藤直生訳、オライリー・ジャパン）です。
プロンプトエンジニアリングの仕組みが解説されていて、業務内容が異なる4人でも共通して役立つ知識が得られると考え、この本に決めました。

本の中で得た気づき

LLMは文字列を補完しているだけにすぎない

この本を読む前は、LLMの仕組みを深く考えることなく、なんとなく便利だから使っている、という状態でした。
とりあえずプロンプトを投げればそれっぽい答えが返ってきますし、なぜうまくいくのかはよくわからないけれど、実際に業務で役立っているからいいか、と。

本書の第1章に、こんな一節があります。

その核心部分では単にテキストの次の単語を予測するモデルに過ぎないのです。それ以上でも以下でもありません。つまり、LLMはユーザーが何らかのタスクを達成するための道具であり、この道具と対話する方法は、完成させるべきテキストの塊である「プロンプト」を作り上げることなのです。
――『LLMのプロンプトエンジニアリング』第1章（p.3-4）

LLMがテキストの次の単語を予測しているという仕組み自体は、知識としては知っていました。
ただ、そのシンプルな仕組みが、どうやって高度なAIエージェントのような振る舞いに繋がるのかがわかっていませんでした。
本書では「テキスト補完に過ぎない」という前提に立ったうえで、その補完をどう応用すれば高度なことができるのかが丁寧に説明されていて、そこで初めて腑に落ちました。

これを理解してから、LLMに対する期待感が大きく変わりました。
以前は出力が期待と違うと「AIが間違えた」と感じていましたが、今は「プロンプトの書き方が悪かったのではないか」とまず自分の入力を見直すようになりました。
LLMは与えられたテキストの続きを予測しているだけなので、望む出力が得られないのはプロンプト側の問題だという考え方に変わりました。

赤ずきんの原則

LLMは単にテキストを補完しているだけなので、AIを上手く使うためには精度良く補完してもらう必要があります。
では、どんなプロンプトを与えれば精度の高い補完が得られるでしょうか。
本書ではその指針として「赤ずきんの原則」が紹介されています。

プロンプトはトレーニングセット中のドキュメントに近い形式であるべきです。これを「赤ずきんの原則」と呼びます。
――『LLMのプロンプトエンジニアリング』第4章（p.66）

つまり、LLMが学習時にたくさん見てきたドキュメントに近い形式でプロンプトを書けば、それだけ良い補完が得られるということです。

名前の由来は童話の赤ずきんです。
母親に「道を外れないように」と言われたのに、道を逸れてしまうことでひどい目に遭ってしまうという教訓です。
LLMに対しても同じで、トレーニングデータに頻出するパターンという「よく踏まれた道」に沿ってプロンプトを書こう、という原則です。

この原則を知ったことで具体的になにかプロンプトの書き方が変わったわけではありません。
ただ、LLMの得意・不得意を理解する軸ができました。
たとえばMarkdown形式のドキュメントやよくあるシェルスクリプトなど、トレーニングデータに多く含まれているであろう形式のタスクは、LLMが得意とする領域だと自信を持って任せられるようになりました。

CoT（Chain of Thought）

本書を読んで印象的だったのが、LLMには「内的な独り言」がないという話です。
人間なら質問されたときに頭の中で考えてから答えますが、LLMはテキスト補完なので、いきなり次のトークンを生成します。
何も工夫しなければ、直感的な推測をそのまま出力してしまうわけです。

CoT（Chain of Thought）は、いきなり答えを出させるのではなく、まず推論の過程を出力させてから回答に導くテクニックです。
先に推論のテキストを生成させれば、その文脈を踏まえて補完が行われるので、精度が上がります。
テキスト補完という仕組みがわかっていると、CoTがなぜ効くのかスムーズに理解できました。

この「先に考えさせる」という考え方は、実は私たちが普段使っているツールや開発プロセスにも組み込まれているのではないかと気づきました。
たとえば、Claude CodeにはPlanモードという機能があり、実装前にまず計画を立てさせることができます。
また、私たちの組織では今年からOpenSpecというSDD（Spec-Driven Development、仕様駆動開発）ツールを導入しており、AIにコードを書かせる前に仕様書やタスクリストを作成するという開発フローを取り入れています。
どちらも「いきなりコードを出させず、先に考えさせる」というCoTと同じ原則に基づいていることに気がつきました。

本書ではCoTの発展として、推論とアクションを交互に繰り返す「ReAct」や、先に計画を立ててから解く「Plan-and-Solve」といった手法も紹介されています。
これらはエージェント開発において有用な知識ですが、私が普段行っているアプリケーション開発においてはCoTの考え方を押さえておけば十分実用的だと感じました。

実際の業務での活用・変化

読書会前後でメンバーに共通していた変化は、「なんとなくよさそうだから」ではなく「なぜ効くのかを理解したうえで」プロンプトを工夫するようになったことです。

Markdown形式やFew-shotプロンプティング（プロンプトでいくつかの例を提示する手法）など、以前から使っていたテクニックもあります。
読書会を通じて、それぞれの手法のメリット・デメリットを理解したうえで使えるようになったという感想が共通していました。

ここからは、3人の同期メンバーにヒアリングし、この本で学んだことを業務で活用した例を紹介します。

クラウド移行

クラウド移行を担当するメンバーは、CoTを知って「論理の飛躍」を意識するようになったそうです。
以前はAIの出力に疑問があった際に追加で質問する程度でしたが、今ではAIが回答に至る判断過程に実際の情報が含まれるよう心がけることが増えたとのことです。
たとえば、MCPやAWS CLIを使って実際のAWSリソースを確認させたうえで回答してもらい、事実に基づいた出力を得られるようにしているそうです。

業務フロー改善

業務フロー改善を担当するメンバーは、Few-shotの「LLMにパターンを抽出してもらう」という仕組みを応用しているそうです。
業務フロー改善ではSaaSを多数使用しており、MCP経由でテストデータを作成する場面がよくあるとのことです。
以前は自分で複数パターンのデータを指定して作らせていましたが、本書を読んでからはLLMに既存データからパターンを抽出してもらうことで、パターンの調査や検討にかかる手間が減ったと話していました。

データ分析

データ分析を担当するメンバーのチームでは、Gemini APIと組み込みのプロンプトを使って分析文言の生成やRAG（Retrieval-Augmented Generation: 検索拡張生成）の開発を行っているそうです。
本書にはエージェントの実装概要やRAGそのものについての解説もあり、普段の業務と重なる部分が多かったとのことです。
また、分析文言を生成するプロンプトにFew-shotを組み込んで、出力のフォーマットを揃えるようにしたと話していました。