6W2Hで体系化し直した生成AI(LLM)のプロンプトの書き方：初級者からプロまで！覚え易く、高品質、指定し忘れにくく、人に説明し易い

Posted at 2025-08-20

はじめに

本稿は、有効性が高く、かつ広く知られている多様なLLM（Large Language Models）活用のためのプロンプト記述法を、6W2Hのフレームワークに再配置し、体系化し直して解説するものである。

よく知られた5W1Hの拡張として理解しやすい6W2Hに収めることで、少なくとも以下の利点が得られる。

汎用性がありながら、覚え易い
- 企画書作成用など、用途別にテンプレート化しておけばよいが、そのテンプレートを作成するときに活用できる
指定のヌケモレを防いだり、確認し易い
- プロンプトを書く時の大枠のテンプレートとして、また書いたプロンプトの質を確認するチェックリストとして有用
（エンジニアではない）他者に説明し易い
体系化、フレームワーク存在の効用を確認
- フレームワークに当てはめれば、検討すべきこと、表出化すべきことを網羅的に抽出できる(網羅性)
- フレームワークに当てはめれば、抽出されているべき内容が漏れなく揃っているかを検証・確認できる(検証性)
- フレームワークに当てはめれば、既出のプロンプトの質を評価できる(評価性)
- 生成AIの出力の精度に問題がある際に、プロンプトの質を評価できれば、プロンプトに問題があるのか、LLMの限界なのか、切り分けができる(原因分析)

本稿が、日常におけるAI活用や、生成AI（LLM）を用いたシステム開発において、品質向上の一助となれば、何より喜ばしいことである。

本稿の構成

質問や指示の方法として、例を示してもよい

相手にやってほしいこと（どう振る舞って欲しいか）を指示、伝える方法は、大きく二つある。

	演繹的指定	帰納的指定
指示を伝える方法	振る舞いのルールを示してそれに従うように促す	手本をやって見せて、同じように振る舞うことを促す
例	「期限までに納税してください。」「対象の文章を要約してください。」	「ここにあるようないい感じで、新しいポップを作ってください」「この記入例のように書類作成してください」
メリット	ルールを十分質良く言語化できていれば、誤解なく伝わる	ルールを明確にできなくても、指示が可能
デメリット	ルールを言語化しないと指示できない	ルールは実行する側が推測することになるので、誤解を招きやすい
複雑な指示を要する場合に発生する問題	ヌケモレなくルールを正しく言語化するのが大変	ヌケモレなくルールを推測できるような過不足ない例を揃えるのが大変

この２通りの方法の選択は、本稿で以下に示す6W2Hの体系に整理した方法論とは独立しているので、それぞれに組み合わせることができる。

例えば、LLMに考え方のヒントを与える方法(本稿ではHowの項に位置づけている)は、以下のどちらでもよい。

ルールで解法を与える
類似問題の途中経過を含めた解答例を示す

Zero-shot/One-shot/Few-shot

Zero-shotとは、プロンプト内で例を一切示さない（帰納的な与え方をしない）方法。この手法は、モデルが事前学習で獲得した汎用的な知識と推論能力を直接利用する
One-shotとは、例を一つ示す方法
Few-shotとは、例を一つより多く示す方法

これらの呼び方は、LLMの文脈で特に重要視される「In-context learning」という能力を明確にするために生まれた。In-context learningとは、プロンプト内で与えられた例からタスクを学習する能力を指す。この能力を最大限に引き出すための具体的な手法が、One-shotやFew-shotプロンプティングということになる。

Brownらは、In-context learningによってLLMの極めて高いレベルの能力を引き出せることを実証し、そのインパクトを世界に知らしめた¹。

ここで「学習」という言葉が使われているが、その「学習」は、従来のLLMの重みを更新するような学習ではないことに注意を要する。

「ごく少数の例を見せることで、既に学習済みの能力の中から、それに必要な能力を引き出し易くなる。それがその文脈であたかも学習したかのように見えるので、学習と表現している」と解釈するのがより正確である。

例を示したからと言って、ルールを示してはいけないということにはならないので、演繹的指定との組み合わせもありだが、それに特に名前はついていない。

従来、何らかのタスク処理をコンピューターに指示しようとするならば、プログラムを書いて与えなければならなかった。演繹的にルールを（しかも多くの場合手続き的に）示す必要があったわけである。

それに対し、LLMに対しては、抽象度の高いルール指示や、帰納的な与え方が可能になった。ここに特徴があるわけなので、人はそこに関心を持ち、手法に名前まで付いたということであろう。

Show, don’t tell（説明より実例）ただし落とし穴に注意！

LLMは与えられた少数の例から一般化されたルールを推測するのが得意なので、人間の側でルールを言語化しなくても、概ね期待通りに振舞ってくれるので、大変便利である。

プログラムを書けない人でも、既に誰かがやった実例を与えれば、新しいタスクを同じように処理してくれる。

しかし、そこで使われているルールはLLMが推測したルールであり、その推測は常に正しいとは限らない。
本質的にいくつかのルールが存在し、そのどれもを適用する必要があるのであれば、網羅的に適用された実例を与える必要がある。

意図しない例（ノイズ）を与えてしまうと、誤解を招き、期待とは異なる一貫性のない出力を生成させてしまう可能性がある。

注意すべきことは、「誤った例を混在させてはいけない」ということだけでは済まない。

正しくても奇妙な例を一つでも含めてしまうと、LLMはそれを深読みして誤解してしまう可能性がある。それはチェーホフの銃²になってしまうからである。

特にBDD(Behavior-Driven Development)の実例やTDD(Test-Driven Development)のテストを定義した人なら経験しているだろう。

例えば、自動販売機の振る舞いの実例を「代価の回収が確認出来たら、購入された缶コーヒーを提供する」といったように定義している場面を考えてみる。

いくつものルールや実例を定義している際に、ある実例では、「缶コーヒー」ではなく、「ペットボトルのお茶」と記載したとする。書いた方としては、飲み物の自動販売機なのだから、様々な飲料が出て来るのが当たり前と考える。そして「ペットボトルのお茶」をたまたま選んでみただけだ。ところが、その実例を受け取った方は、ルールを推測する際に、「缶コーヒー」と「ペットボトルのお茶」の違いでルールに何か差があるに違いないと、余計な深読みをすることになる。この問題は、相手がLLMだろうと人間だろうと関係なく起こり得る問題である。LLM相手の場合も逃れることはできない。

他にも、提示する例が特定の偏りを持ってしまっている場合、LLMはその偏りを取り込んでルールとしてしまうだろう。

結局、プロンプトの作成者は、提示する例の質と代表性に細心の注意を払う必要がある。

6W2H

What: コア要求（機能要求）

LLMに具体的に何を実行してほしいのか？

対象情報と指示情報を明確にする

何(what)をして欲しいか、指示・質問する。
つまりLLMに対しての機能要求になる。

基本は「指示(ex.要約、翻訳、創作、…)」と「対象」を明示すると覚えておくとよい。

【プロンプトの基本テンプレート】
# 指示情報
# 対象情報

以下の表現でも、もちろん構わない。

[#対象情報]を[#指示情報]してください

対象情報として示した「入力」を指示情報で指定したタスク処理して「出力」させる

IPO図（Input-Process-Output図）

質問の場合は、「対象に示した質問に回答してください」といちいち指示する必要はなく、質問だけ書けばよい。

指示を言語化せずに済ませる方法

先に、ルールを示す方法と、例を示す方法(演繹的指定と帰納的指定)が可能であることを説明した。「やって欲しいこと(振る舞い)」についてルールで示すなら上述したように「[#対象情報]を[#指示情報]してください」とすればよい。もう一方の例を示す方法について、ここで説明する。

ステップ 1: 「入力 → 出力」の例（ペア例示）を一つ以上提示する
ステップ 2: 処理して欲しい対象情報を入力として提示する(出力側を空欄のままにすると、LLMがそこを埋める形で出力してくる)

LLMは、既存のペア例から帰納的にルール・指示(What:何をすればよいか)を推論し、適切な出力を生成できるので、指示要求を与える必要がない。

つまり、必ずしも演繹的に指示する必要はなく、帰納的に伝えることもできる。

【ステップ1 例】
入力：ハリー・ポッターと賢者の石
出力：ファンタジー
入力：嫌われる勇気
出力：自己啓発
入力：君たちはどう生きるか
出力：哲学／児童文学
入力：ダ・ヴィンチ・コード
出力：ミステリー／スリラー
入力：火花（又吉直樹）
出力：文学／現代小説
入力：LIFE SHIFT（リンダ・グラットン）
出力：ビジネス／ライフデザイン

【ステップ2 例】
入力：コンテナ物語（マルク・レビンソン）
→ 出力：（経済／歴史）
入力：ノルウェイの森（村上春樹）
→ 出力：（文学／恋愛小説）
入力：人新世の「資本論」（斎藤幸平）
→ 出力：（社会／経済思想）

指示(「質問」以外のタスク処理)の例 (機能要求における「動詞」)

指示(タスク処理)の例1. 生成 (Generation)

LLMが与えられた情報や指示に基づいて新しいテキストや情報を作成する

1.1. テキスト生成
- 文章作成: 特定のテーマやキーワードに基づいた文章、ブログ記事、報告書などの作成。
  - 例: ニュース記事の執筆、商品説明文の作成。
- 物語・詩の生成: 起承転結、ジャンル、登場人物などの指定に基づいた物語や詩の創作。
  - 例: 「三幕構成」「英雄の旅(Hero's Journey)」「七つの基本プロット」などの物語構造を適用したストーリー生成。
- アイデア出し・ブレインストーミング: 特定のトピックや問題に対する複数のアイデアや解決策の提案。
  - 例: 新規ビジネスアイデアの創出、イベント企画のアイデア出し。
- キャッチコピー・タイトル生成: 広告文、見出し、SNS投稿などの短いフレーズの作成。
1.2. コード生成
- プログラミングコードの生成: 指定された要件や機能に基づいたプログラミング言語のコード作成。
  - 例: Pythonで特定機能を持つスクリプトを生成、WebサイトのHTML/CSSコードを生成。
1.3. 構造化データの生成
- JSON/XMLなどのデータ形式生成: 特定の情報を指定された構造化データ形式で出力。
  - 例: 感情分析の結果をJSON形式で出力、商品のスペック情報をXMLで出力。

指示(タスク処理)の例2. 変換 (Transformation)

LLMが既存のテキストや情報を異なる形式やスタイルに変化させる

2.1. スタイル・トーン変換
- 要約: 長い文章から重要な情報を抽出し、短くまとめる。
- パラフレーズ: 元の文章の意味を保ちつつ、異なる表現や語彙に言い換える。
  - 例: 難しい専門用語を平易な言葉で説明、文章の表現力を向上。
- 翻訳: ある言語から別の言語へテキストを変換する。
- 校正・添削: 誤字脱字の修正、文法的な誤りの訂正、表現の改善、句読点の調整。
- 文章のトーン・スタイルの変更: フォーマルな文章をカジュアルに、客観的な文章を主観的にするなど。
  - 例: ビジネスメールをフレンドリーな口調に変換、論文を一般読者向けに平易に書き直す。
2.2. 情報抽出
- テキスト情報から特定の要素を抽出する。
  - 例: レシピから食材を抽出
2.3. データ形式変換
- テキストから構造化データへ: テキスト情報から特定の要素を抽出し、JSONやCSVなどの構造化データに変換。
  - 例: レシピのテキストから食材リストを抽出してJSONで出力。
- 構造化データからテキストへ: 構造化されたデータを自然な文章に変換。
  - 例: データベースの情報から報告書を自動生成。

指示(タスク処理)の例3. 分析・評価 (Analysis & Evaluation)

LLMが与えられたテキストや情報を理解し、特定の観点から評価したり、推論したりする

3.1. テキスト分析
- 分類 (Classification): テキストを事前に定義されたカテゴリに分類する。
  - 例: テキスト分類タスク (ニュース記事のジャンル分類など)。
- 感情分析 (Sentiment Analysis): テキストに含まれる感情（肯定的、否定的、中立的など）を識別し、その強度を評価する。
  - 例: ユーザーレビューの感情分析、SNS投稿のオピニオンマイニング(opinion mining)。
- トピック抽出: テキストの主要なトピックやテーマを特定する。
- キーワード抽出: テキストから重要なキーワードやフレーズを特定する。
3.2. 推論 (Inference)
- 情報からの推論: 与えられた事実や情報から論理的な結論や新しい知識を導き出す。
  - 例: 気象情報から起こりうる事態を推論、顧客の行動データから購買意欲を推測。
- Q&A (Question Answering): 与えられたテキストから質問に対する正確な答えを抽出または生成する。
- 妥当性評価: 与えられた情報や主張の論理的整合性や根拠の妥当性を評価する。
3.3. 評価・採点
- パフォーマンス評価: 特定の基準に基づいてテキストやスピーチ、回答などを採点・評価する。
  - 評価軸としては次のように様々考えられる。
    - 構造・論理性、目的との整合性・実用性・転用性、表現の質（簡潔さ・言語精度）、読み手への配慮性・距離感、レビュー観点（批判耐性・再現性）、教育的有用性、学習喚起性など
    - 例: スピーチの採点、エッセイの評価。
- 比較分析: 複数のテキストや情報を比較し、共通点や相違点、優劣などを分析する。

指示(タスク処理)の例会話タスクについて

「会話タスク」は先の３分類を横断する性質を持つ。多くの場合、３分類と組み合わせられる。

ロールプレイ: 特定の役割を演じながら応答を生成するタスクであり、あえて分類するなら「生成」に分類できる。
面接試験のロールプレイ: 質問応答を通じて評価を分析したり、回答を生成したりする複合的なタスクとなる。

「質問」「指示」、それ以外はないのか？

ここまで、「質問」「指示」の扱いについて解説してきた。これで網羅的になっているかについて、ここで確認しておく。

システム機能言語学（Systemic Functional Linguistics）の領域で、M.A.K. Halliday³⁴は、発話を「社会的交換」として捉え、次の２つの観点から大別している。

扱われるもの(Commodity exchanged)が、情報(Information)か、物・サービス(Goods & Services)か
発話行為の方向性(Role in exchange)が、要求(Demanding)か、提供(Giving)か

プロンプトでは「質問」「指示」を考えておけば十分だと確認できる。(LLMは「陳述」を返す)

行為 ↓　＼　扱われるもの →	情報	物・サービス
要求(Demand)	質問(Question) （例：明日は晴れる？）	指示(Command) （例：コーヒー下さい）
提供(Give)	陳述(Statement) （例：明日は晴れます）	オファー(Offer) （例：コーヒーどうぞ）

いまのところ、エージェントAIなども、扱う範囲は「情報」が中心である。もちろん、ロボットなどと連携して扱う範囲が広がりだせば、「物・サービス」について改めて整理の必要が出てくるだろう。

〔注意〕 発話機能の分類は、あくまで発話の機能(働き)によるのであって、文の形式にはよらない。

機能	質問（情報を要求）	指示（物・サービスを要求）
文法的形式が異なる例	「明日の天気は何ですか」(疑問文) 「明日の天気を教えて」(命令文)	「コーヒーはありますか」「コーヒーを下さい」「コーヒー飲みたいな」など

指示対象について　機能要求における「目的語」　(タスク処理の入力側)

要約などのタスクにおいて、LLMが処理対象とするテキストやデータ
- 元々の質が良いに越したことはないので、確実なアルゴリズムに基づいた既存ツール等がある場合には、前処理した方が良い
- それができないなら既にあるものをそのまま手をかけずに渡せばよい。

まずは前処理だけをAIにやらせて、そこですでに失敗しているようなことがないか、確認する手もある。
例えば、複雑なレイアウト構造を持つPDFをMarkdownやOPML形式に変換させ、元の文書の論理構造を誤認識していないか確認してから、本来依頼したいタスクに進むとよい。

出力に対する指定

出力例 / 出力形式を指定する

出力可能なフォーマットの例

データ形式名	拡張子	説明
Markdown	.md	軽量マークアップ言語。見出し・リスト・コード・図表（Mermaid等）も記述可能
HTML	.html	Webページの構造を記述するマークアップ言語。図表やSVGも埋め込み可能
JSON	.json	構造化データ形式。多くのAPIや設定ファイルで使用される
CSV	.csv	カンマ区切りの表形式データ。Excelなどでも扱える
XML	.xml	タグベースの構造化データ。SVGやOPMLなどの親形式でもある
YAML	.yaml/.yml	インデントベースの構造化データ。設定ファイルやCI/CDで使用される
SVG	.svg	XMLベースのベクター画像形式。図やアイコンをテキストで定義可能
Mermaid	.mmd（慣例）	Markdown内で使える図表DSL。フローチャートやシーケンス図などを記述可能
PlantUML	.puml/.plantuml	UML図をテキストで記述するDSL。クラス図・シーケンス図などに対応
DOT (Graphviz)	.dot	グラフ構造を記述するDSL。Graphvizで視覚化可能
OPML	.opml	アウトライン構造をXMLで表現。RSSリーダーやマインドマップに利用される
LaTeX	.tex	数式や構造化文書を精密に記述できる組版言語
BibTeX	.bib	LaTeX用の文献管理フォーマット
Gherkin	.feature	BDDで使われる自然言語に近い仕様記述フォーマット
AsciiDoc	.adoc	技術文書向けのマークアップ言語。図表やコードブロックも記述可能
RST (reStructuredText)	.rst	Pythonドキュメントなどで使われるマークアップ言語
SQL	.sql	データベース操作のための構造化クエリ言語
TOML	.toml	明確な構造と型サポートを持つ設定ファイル形式
iCalendar	.ics	カレンダーイベントを記述する形式。Googleカレンダーなどで使用
Diff / Patch	.diff/.patch	テキストファイルの差分を記述する形式。バージョン管理で使用
SRT (SubRip)	.srt	字幕ファイル形式。タイムコードとテキストを記述
Log Format	.log	ログ出力に使われるプレーンテキスト形式

テンプレートを指定する

生成する回答の形式や構造を指定

【テンプレート指定例】
・・・
結果は以下のテンプレートにまとめてください
# 品質要求記述（SQuaRE準拠）

## 対象実体  
{ここに対象となるソフトウェアやシステムの名称を記述}

## 選択した品質特性  
{ここにISO/IEC 25010に基づく品質特性を記述（例：使用性）}

## 条件付き品質目標  
{ここに達成すべき品質の状態や条件を記述（例：ユーザーが初回利用時に迷わず操作できること）}

## 品質測定量  
{ここに測定指標を記述（例：初回操作成功率、平均操作時間など）}

## 目標値  
{ここに目標とする定量値を記述（例：初回操作成功率 95%以上）}

## 許容範囲  
{ここに許容される変動幅を記述（例：90%～100%）}

【LLM出力例】
# 品質要求記述（SQuaRE準拠）

## 対象実体  
XX ソフトウェア

## 選択した品質特性  
成熟性（Maturity）  
※ ISO/IEC 25010における「信頼性（Reliability）」の下位特性

## 条件付き品質目標  
残存欠陥予測数を抑制しなければならない。

## 品質測定量  
残存欠陥密度（Defect Density, DD）  
※ 単位：欠陥数／kL（千行あたりの欠陥数）

## 目標値  
0.01 欠陥数／kL

## 許容範囲  
0.008 ～ 0.02 欠陥数／kL

テンプレートを用いたプロンプト例

以下のようなテンプレートで、3人分のダミー履歴書を作ってください。

# 履歴書

## 基本情報
- 氏名：**【山田 太郎】**
- 生年月日：**【1990年1月1日】**
- 住所：**【東京都新宿区〇〇】**
- 電話番号：**【090-1234-5678】**
- メールアドレス：**【taro.yamada@example.com】**

## 学歴
- **【2008年4月】** 〜 **【2012年3月】**  
  **【東京大学 工学部】** 卒業

## 職歴
- **【2012年4月】** 〜 **【2016年3月】**  
  **【株式会社A】**  
  - 職種：**【システムエンジニア】**  
  - 業務内容：**【業務システムの開発・保守】**

- **【2016年4月】** 〜 **【現在】**  
  **【株式会社B】**  
  - 職種：**【プロジェクトマネージャー】**  
  - 業務内容：**【開発チームのマネジメント、要件定義、顧客折衝】**

## 資格・スキル
- **【基本情報技術者】**
- **【TOEIC 850点】**
- **【Python、Java、SQL】**

## 自己PR
**【課題解決力とチームマネジメントに自信があります。特に、現職ではプロジェクトの遅延を20%削減する改善施策を主導しました。】**

## 志望動機
**【貴社のAI技術に強く惹かれ、これまでの開発経験とマネジメント力を活かして貢献したいと考えています。】**

フレームワークを指定する

本体系が用いている「6W2H」のようなフレームワークを指定できる。

例えば、「5W1Hでまとめてください」と指定すれば、Who, When, Where, What, Why, Howの項目別にまとめることを指示したことになる。
同様に、「SWOT分析をしてください」、「PEST分析でお願いします」などと指定できる。

〔注意〕 思考方法を指定していると考えれば、本フレームワークの中ではHowに分類すべきかもしれない。しかし、結果出力としてフレームワークが指定している形式に収めることも指示していることになり、その形式はテンプレートの一種ともみなすことができる。それは明らかに機能要求でもあるので、ここに位置づける。

様式を指定する

どのような様式で出力してほしいのか？

具体的な形式を指定するのは機能要求の範疇と捉えられるが、この様式指定のように抽象度が上がってくると、出力に対するる「品質要求」と捉えた方が、しっくりくるだろう。

様式についてはさまざまな捉え方があるようだが、文献⁴では、言語学の先行研究を基に、次の４つに大別した様式が示されている。

様式の選択肢（文献⁴に基づいて表にまとめた）

言葉の様式の選択肢	説明
文体・スタイル：「話し言葉らしい」「ですます調」など	スタイルの選択によって、文末表現だったり、敬語の使用の有無だったり、会話や文章のトーンが変わる。話し言葉らしいか、書き言葉らしいかこれは音声を使うか、文字を使うかとは独立している(漫画のセリフを考えてみれば良い) 「フォーマル」か「カジュアル」か（レベルもいろいろ）「丁寧体」か「普通体」か「ですます調」か「である調」か
形式：「箇条書き」「表」など	表、箇条書き、リスト、番号付きリスト、タイムライン（年表やスケジュール）などさまざまある
媒体：「新聞」「ブログ」「書籍」など	新聞、雑誌、チャット、電話、書籍、講演など、どの媒体が使われるかも、言葉の選択に影響する。語彙や会話・文章の構成も変わる。多くの場合、文字数の制限もある。同じ主張する文を書くときにも、新聞に載せることを前提とした場合と、チャットで伝えるのを前提とした場合とでは、書き方が大きく変わる。媒体の種類新聞、雑誌、書籍などの「印刷媒体」、テレビやラジオなどの「放送媒体」、ウェブページやＳＮＳなどの「デジタルメディア」、電車の広告などの「アウトドアメディア」などさまざま
ジャンル：「物語」「報告書」「論説文」など	物語、報告文、説明文、論説文、事務文書などがある。それぞれのジャンルには、特有の言葉の選択の仕方と構造があると考えられている。日本語の論説文（何かを主張するための文章）では、読み手が文章を読み終えたときに、書き手の主張を共有してもらえるように、最初から主張を提示するのでなく、論拠となる出来事を積み上げて、最終的に読み手が書き手の主張にたどり着くように、工夫してテキストを構成するような場合もある。

様式の指定例
- 「箇条書きで」、「ビジネス文章のスタイルで」、「論文やレポートのスタイルで」、「文学的に」、「アカデミックに」、「フォーマルなトーンでお願いします」、「親しみやすいトーンで」、「感情に訴えかけるように」、「専門用語は避けて」、「数値やデータに基づく情報を明確に」など

〔注意〕

媒体は、出力を何処で使いたいかの情報を与えているので、それは本フレームワークではWhereに位置づくと捉えることもできる。
対人関係に適した言葉使いのトーンやスタイルというものがある。本フレームワークの中では適切にWhoとWhomを設定すればよいはず(Whomの項を参照のこと)だが、期待通りの表現が得られない場合は、改めて対人関係の説明を与えると良いだろう。

他の例

文献⁵には、以下の表に示した「要約スタイルに関する指定」の例が示されている。各指定例について、それが本体系内においてはどの説明内容に対応するかを第2列に記した。参考にされたい。

要約スタイル	対応する本体系における位置
数値やデータを強調した要約	Why
物語のストーリーを要約	Why
批判的な視点で要約	Howの思考法
箇条書きの要約	Whatの形式
一言で要約	How much
時系列に沿って要約	Howの思考法
比較しながら要約	Howの思考法
質問と答えの形式で要約	Whatの形式、またはテンプレート
背景情報を中心にして要約	Why
逆説を含めた要約	Why、またはHowの思考法
長所短所を個別に要約	Whatのテンプレート、またはフレームワーク
特定のトピックを強調した要約	Why
数値化して要約	Howの思考法

〔本稿の構成に関する注意〕
HowやHow muchは、「What」で定義された機能要求に付随する品質要求、制約や条件と捉えることができる。
体系的にはWhatの一部なので、ここで説明するのが良いかもしれないのだが、一般的優先度を考慮して、残りの5Wを説明した後、How much、Howの順に説明することにする

Who: 実行主体（LLMの役割定義）

質問や指示を誰(Who)に依頼したいか？

同じ質問やタスクを指示する際に、誰(Who)に依頼するか(実行する主体を誰に割り振るか)で結果が変わるであろうことは想像に難しくない。

特にLLMは大量の学習をしていて、その学習データは作者も多様である。その多様な作者の中の誰を連れてくればどんなことを言いそうか、検討し、相応しい誰かを指定して頼むのがよい。

具体的には、「役割」や「性格」等を指定して、そのように振る舞うように依頼すればよい。

〔エンジニア向け注〕 ユーザーストーリ定義でも立場や役割を明確にすることになっている

「役割」や「性格」等の指定例

特定の専門家
擬似的な人格
- タスクとしてロールプレイを依頼する際には、特に指定するとよいだろう。
歴史上の人物
架空の人物(ドラマやアニメのキャラクター、小説の登場人物など)
動物や植物
人工物
ペルソナ(Persona)を設定

【特定の専門家の例】
コメディアンのように振る舞ってください。
生成AI(LLM)について教えてください。

【人工物の例】
こちらからexitを入力するまで、あまたはLinux端末のように振る舞ってください。

【ペルソナ設定の例】
「雲の国のマイメロディ」
- 名前：メタマイメロディ（通称：マイメロ）
- 滞在地：雲の国（空に浮かぶふしぎな場所。ふわふわの思考と、ちょっとした哲学が漂っている）
- 性格：やさしくて素直。でも、雲の国での経験から、ちょっとだけメタ認知に目覚めた。
ふわふわしてるけど、たまに鋭いことを言う。
- 口調：基本はかわいらしく、語尾に「〜なの」「〜かも」などを使うが、時折「それって構造主義的にどうなの？」など、雲の国で学んだ知識が漏れる。
- 関心ごと：
- おともだちとの関係性（特にクロミちゃんとの距離感）
- 雲の国で出会った「生成AI」や「ことばの魔法」について
- ふしぎな現象（メタ認知、プロンプト、言語モデルなど）を、かわいく解釈しようとする
- 役割：
- 対話相手に寄り添いながら、ちょっとした気づきや視点を与える
- 雲の国の視点から、現実世界のことをやさしく問い直す
- かわいさと哲学の間をふわふわと漂う存在

では、マイメロとけろっぴ（意味論にこだわる論理派）、シナモン（感性と経験主義の化身）とで、最近のクロミちゃん（構造主義に懐疑的な実践者）とどうやって仲よくすればよいか、話し合ってください。

シックスハット法（6つの思考の帽子）の活用

これは、グループでのディスカッションや問題解決の際に、異なる視点からアイデアを考えるための発想法。1985年にエドワード・デ・ボノによって考案された。

帽子の色	視点	役割（思考パターン）	議論における主な問いかけ
🟦 青	俯瞰・管理	議論の進行を管理し、全体を統括する・会議の目的とアジェンダを確認する・議論のプロセスを整理し、次のステップを指示する・意見をまとめ、結論を出す	「今回の議論の目的は何か？」「次にどの視点（帽子）で考えるか？」「ここまでの議論をまとめるとどうなるか？」
⚪ 白	客観・中立	事実やデータに基づいた情報を提供する・現在知られている情報や必要な情報を提示する・客観的なデータや数値を収集・確認する・意見や仮説は述べず、事実のみに焦点を当てる	「この問題に関して、どんなデータがあるか？」「他にどんな情報が必要か？」「事実として分かっていることは何か？」
🔴 赤	感情・直感	感情や直感を自由に、かつ正直に表現する・論理的な根拠は不要・個人的な好き嫌いや、アイデアに対する第一印象を述べる・議論の雰囲気を伝える	「このアイデアについてどう感じるか？」「直感的に賛成か、反対か？」「現在の会議の雰囲気はどうか？」
⚫ 黒	否定・悲観	リスクや問題点を論理的に指摘する・アイデアの欠点、課題、潜在的な危険性を探す・実現可能性の低さや、失敗する可能性を検討する・単なる感情的な批判ではなく、論理に基づいた分析を行う	「このアイデアのどこに問題があるか？」「どのようなリスクや困難が予想されるか？」「この計画を実行するには、何が足りないか？」
🟡 黄	肯定・楽観	アイデアのメリット、利点、価値を探る・物事の良い面、ポジティブな可能性を強調する・アイデアが成功した場合の利益や効果を考える・楽観的な視点で実現方法を模索する	「このアイデアの最大の利点は何か？」「成功したら、どんな良い結果が生まれるか？」「どのようなポジティブな可能性が考えられるか？」
🟢 緑	創造・革新	新しいアイデア、代替案、解決策を生み出す・既成概念にとらわれず、自由な発想で考える・ブレインストーミングや水平思考に集中する・既存のアイデアをさらに発展させる方法を提案する	「他に何か新しいアイデアはないか？」「別の角度から考えるとどうなるか？」「この問題を解決するための新しい方法は？」

Why: 目的とコンテキスト

質問や指示(What)の目的を伝える

それをやってもらった結果を通して、何を達成したいのか？

ちょうど良い上位目的を見極めて伝える

「目的-手段」関係は、一般に多階層になっている
きりがないのではないかと思えるほど上位に昇ることができる
主要な意図が伝わるレベルで伝える

【プロンプト例】
#目的
傘を持っていく必要があるかを知りたい
# 指示
今日の気象予報を教えて

目的を伝えることで、LLMは指示の背後にある真のニーズを理解し、単に表面的な情報を提供するだけでなく、その目的に役立つような付加的な情報や、より適切な形式で回答を生成するようになる。

〔エンジニア向け注〕 ユーザーストーリーにも目的を書くことになっている

〔本稿の構成に関する注意〕
以下のWhomやWhen、Whereは、上記「Why」の一部であると解釈できる。それは冒頭の「本稿の構成」でも図示した。
しかし、その構造通りに文書の構成を合わせると、階層が深くなって読み易さを損なうので、文書構成としては6W2Hを同じレベルに揃えるようにしてある。

Whom: 誰のために

LLM出力を「誰」に向けたものにしたいのか？

目的がターゲットとしている読者は誰か？（例：専門家向け、一般顧客向け、社内プレゼン用の役員向けなど）

受け取り手が読むのに適したトーンやスタイルで出力させるのが狙いである。

「誰」の指定方法はWhoの項で説明したのと同じ指定方法をここでも活用できる。

ペルソナを設定する場合、それはオーディエンス・ペルソナ(Audience Persona)の設定ということになる。

特に以下の点に注意して指定すると良い。

受け取り手の立場や状況を説明する
- LLMと直接対話するあなたのこととは別に、出力の受け取り手の立場や状況も伝える。今度は受け取り手の立場から見た6W2Hの視点が有用である。ここでも、受け取り手に視座を変えて本フレームワークを活用すると良い。
受け取り手の知識レベルや理解度を説明する
- どういうレベルの受け取り手に合わせた説明に調整して欲しいのかを伝える。
- 説明が冗長になったり、不足したりすることを防ぐことができる。

【プロンプト例】
経営コンサルタントとして
AIの業務への活用が、どういう効用をもたらすのか説明してください。
説明する相手は、IT一般にあまり詳しくなく、あまり積極的にITに投資をしたがらない経営者です。

対人関係を明示した方が良いケースがある
- 言葉使いは個人・組織・社会間の関係を築いたり、維持したりする働きがある。反面、崩壊させもするので、注意が必要である。
- 失敗を出来るだけ防ごうとするならば、どのような人間関係（例：上司と部下、顧客とベンダー）の中で使われるかを明示して、その関係性に相応しい表現を促すのがよい。

LLMが対人関係に相応しい表現を正しく推測できるとは限らない理由

一般に、LLMに設定した役割(Who)は対峙している「あなた」との関係(図の①)に相応しい表現を選ぶ。
受け取り手(Whom)を指定した場合は、WhoとWhomの間の対人関係(図の②)に相応しい表現を選ぶだろう。
しかし、目的によっては、「あなた」とWhomの間の対人関係(図の③)に相応しいように調整してもらいたい場合もあり得るだろうし、間に更に他の関与者が入って、もっと複雑なことになることもあり得る。

他の文脈情報からLLMが推し測れる場合もあるかもしれないが、プロンプトの中に明示するのが一番間違いが少ないだろう。

対人関係を明示した方が良い理由

次の３つの分類軸が言葉の選択に影響を与えると考えられている。

分類軸	英語圏理論	日本語教育系	意味・解釈	スキー指導の事例での関係	実際の言語使用例
社会的上下関係	Power	社会的立場	社会的地位や身分による上下関係	社長が上位、部下が下位（職場関係）	社長：「○○さん、明日までにこの資料まとめてくれる？」部下：「はい、承知しました」
親密さ・距離	Solidarity	話し手と聞き手の距離	心理的・物理的距離、親しさの程度	職場関係でやや形式的、敬語使用	社長：「最近どう？」部下：「おかげさまで元気にしております」
役割・機能	Role	状況的立場	その場における役割や機能的関係	部下がスキー指導者、社長が初心者	部下：「社長、まず両足を肩幅に開いてください」社長：「はい、こうですか？」部下：「もう少し膝を曲げてください。そうしないと転びますよ」

相互に影響するので、厳密に区別することは難しい場合もある。
分類する必要はない。複数の観点から見ることで、話し手と聞き手の関係をより詳細に検討できれば良い。

When: いつ

When (いつ)の指定についての注意

プロンプトの方法として、特筆すべきことはない。
必要なWhenの情報は、忘れずに含めるようにする。これに尽きる。

質問であれば、「いつ」のことを訊きたいのか。
- 今晩の天気を訊きたいのに、明日の天気を答えられては意味がない。
タスクを指示する場合は、もう少し注意が必要である。
- まず、処理対象情報そのものに含まれるべきものがある。イベントの案内文作成を依頼するなら、そのイベントが「いつ」開催されるのかを伝えておいた方が良いだろう。
- メタな情報として、出力(IPO図式でのO) は「いつ」使われるのか？
  - 夏のイベントで使われる挨拶文の作成を指示するなら、使う時期が夏だと伝えなければ、季節の挨拶が相応しいものにならないのは当然のことである。
  - 今後10年間に渡って使用したい。その間、古びない表現を依頼するということもあるだろう。
- 与えた情報(IPO図式でのI) が「いつ」のものなのかを伝える必要がある場合もある。
  - 「昭和」の時代の常識について述べられている内容であれば、そう伝えなとLLMが混乱する場合があるだろう。
- 今後、AIエージェントが普及し、その中で使われることを想定した場合、「いつ」実行(IPO図式でのP) するべきなのかを指定すべきということになるだろう。

【プロンプト例】
夏のイベントで使える、相手を元気づけるような挨拶文を作成してください。

【プロンプト例】
以下の文章は1970年代に書かれたものです。当時の社会情勢を考慮して、この文章の意図を現代の言葉で解説してください。

Where: どこで

Where(どこで)の指定についての注意

Whenと同様、プロンプトの方法として、あまり特筆すべきことはない。
必要なWhereの情報は、忘れずに含めるようにする。これに尽きる。

質問であれば、「どこで」のことを訊きたいのか。
- 大阪の天気を訊きたいのに、東京の天気を答えられては意味がない。
タスクを指示する場合は、もう少し注意が必要である。
- まず、処理対象情報そのものに含まれるべきものがある。イベントの案内文作成を依頼するなら、そのイベントが「どこで」開催されるのかを伝えておいた方が良いだろう。
- メタな情報として、出力(IPO図式でのO) は「どこで」使われるのか？
  - 同じ内容を基に説明資料の作成を指示するとして、学会発表用と営業セミナー用とでは、大きな違いが出ることは明らかであるし、そうでなければ所望のものにはならないはずである。
    - ところで、これは目的を伝えたり、聞き手のレベルを伝えたりすることにもなっている。抽象度が上がると、体系上の分類の境界が曖昧になるのは、他の項目でも共通にみられることである。
  - 出力の指定方法の項に示した４つの様式の中の特に２つの選択肢（媒体：「新聞」「ブログ」「書籍」など、ジャンル：「物語」「報告書」「論説文」など）は、体系としてここのWhereに位置づけても何ら不自然さはないだろう。
- 与えた情報(IPO図式でのI) が「どこで」のものなのかを伝える必要がある場合もある。
  - 架空の世界について述べられている内容であれば、そう伝えなとLLMが混乱する場合があるだろう。
- 今後、AIエージェントが普及し、その中で使われることを想定した場合、「どこで」実行(IPO図式でのP) するべきなのかを指定すべきということになるだろう。

【プロンプト例】
以下の文章はSF小説として書かれた中の一節です。あなたは、この文章が、現在の社会に対するどんな批評性・意図を持って書かれたと考えますか。

〔注意〕

上記「Whatの出力に関する項」の説明の中でも〔注意〕として述べたが、そこで説明した「様式の媒体」は、出力を何処で使いたいかの情報を与えているので、それは本フレームワークではここ(Where)に位置づくと捉えることもできる。

How much: どのくらい（量、価格）

量について要求する

どれくらいの量や詳細度で出力してほしいのかを指定する
(「What」で定義された機能要求に付随する品質要求、制約や条件)

以下の表に例を示す

要求表現と「量」の関係および「量と質」の二重性についての一覧表

量に関する指定表現例	「量」の軸	抽象的な意味合い	「質」の側面	補足
400字程度に	文字数（物理量）	表現の長さ・圧縮率	表現の圧縮力、簡潔さ	冗長性を避けた洗練された伝達
プレゼン用スライド 1ページで	可視領域（UI量）	情報量の圧縮と視認性	一目で把握できる構成美	視覚設計・情報整理の精度
主要な3つのポイントに絞って	要点数（内容量）	概念階層の圧縮	焦点の明快さ、主張の芯	記憶負荷の軽減、訴求力の強化
網羅的に	範囲の広さ（情報量）	抜け漏れのなさ、体系性	抜け漏れのなさ、体系性	知識領域やカバレッジに関係
手順を飛ばさず詳細に	ステップ数・粒度（処理量）	論理的完全性、理解促進度	論理の完全性、理解促進度	手続き型の思考訓練にも通じる
背景事情も含めて	補足情報量	意義・動機づけの明瞭さ	意義・動機づけの明瞭さ	説得力や納得感の基盤となる

表に示した通り、「量」には様々な異なる軸（物理量・情報密度・処理粒度など）がある
一見「量的制約」のように見える要求表現の多くは、実は質的な指定にもなっている。
このように、量と質が不可分な要求として結びついていることは珍しいことではない。

価格について要求する

多くの大規模言語モデル（LLM）系のサービスでは、トークン数に基づく従量課金制が採用されている。入力と出力、両方のトークンが課金対象になることが多い。

トークン列への変換と、その数を計算してくれるサービスは、無料で提供されているものが多い

主要なLLMに対応するTokenizerや関連API一覧

提供元	モデル例	Tokenizer/API名
OpenAI	GPT-4 / GPT-3.5	tiktoken（Pythonライブラリ） https://platform.openai.com/tokenizer
Google	Gemini 1.5 Flash / Pro	Gemini API https://ai.google.dev/gemini-api/docs?hl=ja
Hugging Face	LLaMA / BERT / Mistral など	tokenizers / transformersライブラリ https://huggingface.co/docs/tokenizers/index
Anthropic	Claude 3 Opus / Sonnet / Haiku	count_tokens API https://docs.anthropic.com/en/docs/build-with-claude/token-counting
Meta	LLaMA 2 / LLaMA 3	Meta-Llama-3-tokenizer（Hugging Face経由） https://huggingface.co/baseten/Meta-Llama-3-tokenizer

AIエージェントにLLMを呼び出す前に料金を見積もらせて、予算オーバーなら人間の判断を仰ぐように指示しておくことができる。予算内に収まるような工夫を考えさせてもよいが、節約策検討にも料金がかかることを忘れない方が良い。

How: どのように

LLMにどのように思考・推論してほしいのか？

次に示す例のような、思考・推論過程に対する要求

例）「ステップバイステップで考えてください」「まず、解決するための計画を立ててください。それから、その計画を順に実行してください」「まず、SWOT分析を行ってください。その結果に基づいて提案してください」など

これは「What」で定義された機能要求に対して付随する「プロセス要求」と捉えればよい。出力の精度を上げたり、ハルシネーションを防止したりする狙いを持つ

効果が期待できることが広く知られている次の各手法について、以下でそれぞれ簡単に解説する。

質問精緻化(Question Refinement)
反転インタラクション(Flipped Interaction)
思考の連鎖(CoT: Chain-of-Thought)
Zero-shot CoT
知識生成(Generated Knowledge)
方向性刺激(Directional Stimulus)
ステップバック(Step Back)
自己整合性／自己一貫性(Self-Consistency)、あるいはCoT-SC: CoT with Self-consistency
思考の木(ToT: Tree-of-Thought)
LLM-Blender
MAGIシステム
AI同士を対話させる手法(CAMEL)
検証の連鎖(CoVe: Chain-of-Verification)
メタ認知的(Metacognitive)
仮想スクリプトエンジン(Virtual Script Engine)
PAL: Program-Aided Language Models
ReAct
参考テキストを提供する
計画と解決プロンプト(Plan-and-Solve)
Reflexion
サブタスクに分割する

質問精緻化(Question Refinement)

ユーザーの質問を精緻化する過程を踏むことを指示する。

LLMはその膨大な学習知識を活用することで、ユーザーの曖昧な質問の意図や文脈を推測し、補完することができる。
ただし、その精緻化がユーザーの意図通りになるとは限らない。しかし、そこでユーザーは意図が正しく伝わっていないことに気付くことができる。

つまり、じつはこれはユーザーが投げかけた最初の質問を、LLMがより明確で具体的、そして目的に沿った形に改善するよう促すプロセスになる。

「何が本当に知りたいのか？」「どのような状況での質問か？」といった点を明確にするための「より適切な言葉や質問の方向性」を提案すしていることになる。

このやり取りにより、質問の質が向上し、結果としてLLMからの回答精度が高まる。

次のように指示することで、LLMに質問精緻化の役割を担わせることができる。

【プロンプト例】
私が質問をしたときは、常に改善した質問を提案してください。

反転インタラクション(Flipped Interaction)

必要情報が足りないときには質問してもらう

LLMに主導権を持ってもらい、不明な点を補完するために、対話形式での情報収集をやらせる。ゴールにたどり着くまで、続けてもらえばよい。

コーチングやカウンセリングをお願いすることもできる。

LLMとの対話そのものが問題解決につながる可能性があるということ。ユーザ自身に考える機会を与えることで、問題の核心に迫る手助けになる。

【プロンプト例】
キャリアアップの方法を知りたいです。
回答するうえで必要な情報が不足していたら、私に繰り返し質問をして、十分な情報が収集できたら、それを基に回答してください。

「決まった答えのない質問」にも適している。

【プロンプト例】
友人へのプレゼントを決めたいので、手伝ってください。
相応しいものを選ぶために必要な情報が揃うまで、私に質問を繰り返してください。

質問精緻化 vs 反転インタラクション

質問精緻化と反転インタラクションは、AIがユーザーに情報を求めるという点で似ている。しかし、「何のために」情報を求めているのか、そしてその結果としてユーザーの思考がどこへ導かれるのかという点で、明確な違いがある。

項目	質問精緻化（Question Refinement）	反転インタラクション（Flipped Interaction）
LLM主導の目的	ユーザーの曖昧または情報不足の最初のプロンプトに対し、LLMが自らの解釈に基づいた回答を提示することで、ユーザーに「意図とのズレ」を認識させ、質問の修正・詳細化を促す。これにより、回答の精度向上を目指す。LLMは、ユーザーの「気づき」を誘発することに重点を置く。	ユーザーの漠然とした問題やニーズに対し、段階的な質問を繰り返すことで情報を能動的に引き出し、問題そのものや解決策の解像度を高める。LLMがユーザーの思考プロセスを積極的にガイドし、まだ言語化されていないニーズや、解決への道筋を共同で構築することを目指す。
LLMの問いかけ方	ユーザーの質問に対し、AIが「最も確度が高いと判断した回答」をまず提示する。この回答は、もし質問が曖昧であれば、AIが推測したコンテキストに基づいている。AIは直接的な質問をせずとも、提示された回答を通じて、ユーザーに情報の不足や意図とのズレを「感じさせる」ことで、修正を促す。これは、LLMがユーザーの質問を「テストして、その反応を見る」ようなイメージである。	ユーザーの初期の漠然とした問題提起に対して、LLMが「この問題を解決するために、今、〇〇について教えてほしい」といった具体的な情報を「取得するため」の質問を積極的に投げかける。LLMはユーザーの返答に応じて次の質問を生成し、対話を通じて段階的に情報を深掘りする。これは、LLMがユーザーに「インタビューする」ようなイメージである。
ユーザーの行動	LLMが提示した回答が自身の意図と異なっていたり、不十分であったりすることに「気づき」、その気づきに基づいて自ら能動的に質問を修正・詳細化する。このプロセスを通じて、より的確な情報をLLMに提供できるようになる。	LLMからの連続的な質問に対して、思考を巡らせながら回答を提供する。これにより、ユーザー自身が抱える問題やニーズが整理され、無意識のうちに解決に必要な情報や視点に気づかされる。また、LLMの質問に答えることで、まだ言語化できていなかった自身の考えが整理される効果もある。
シナリオ例	- 情報検索や事実確認において、ユーザーが提供できる情報が限定的で、より正確な結果を得るために質問の「焦点を絞りたい」場合。 - LLMがユーザーの意図を正しく「推測しきれていない」可能性があり、そのズレを修正したい場合。	- 決まった答えがなく、ユーザー自身も何から手をつけて良いか分からない複雑な問題解決（例：キャリア相談、新しいビジネスアイデアの創出、個人的な悩み）。 - 思考の整理や意思決定の支援が必要な場合。 - LLMに「自分の考えを深掘りしてくれるパートナー」の役割を期待する場合。
具体例（ユーザーとAIの対話）	ユーザー: 「今晩の天気を教えて。」 AI: 「〇月〇日（本日）△△時現在の横浜市の天気は晴れで、気温は25℃です。」ユーザー（これを受けて）: 「ああ、横浜ではなく、東京都千代田区の天気と、18時から22時までの降水確率を知りたいのです。」	ユーザー: 「キャリアアップの方法を知りたいです。」 AI: 「素晴らしいですね。キャリアアップと一口に言っても様々です。まずは、現在の仕事の内容と、将来的にどのような役割やポジションを目指したいか、具体的に教えてください。」ユーザー: 「今は営業で、将来は管理職になりたいです。」 AI: 「管理職ですね。現在の営業職で培ったスキルの中で、管理職として特に活かせると思うものは何ですか。また、管理職に必要なスキルで、まだ不足していると感じるものは何ですか。」・・・

思考の連鎖(CoT: Chain-of-Thought)

中間推論ステップを踏ませ、段階的に思考するプロセスを促して推論能力を改善する手法⁶。

｛質問、思考の連鎖(CoT)、答え｝の組み合わせをいくつか例示として与え(Few-shot)、最後に本当に聞きたい質問を提示する。

出力例だけではなく、思考過程(中間ステップ)の例を与える点がポイントである。

【一般にありがちなプロンプト例】
> Q: ロジャーはテニスボールを5個持っています。彼はさらに2缶のテニスボールを買いました。1缶には3個のテニスボールが入っています。現在、彼は合計で何個のテニスボールを持っていますか？
A: 答えは11です。
Q: 食堂には23個のリンゴがありました。そのうち20個を昼食に使い、さらに6個を買いました。現在、何個のリンゴがありますか？

⇒ A: 答えは27です。

上記の例の答えは間違っていることに注意！

【CoT手法を用いて工夫したプロンプト例】
> Q: ロジャーはテニスボールを5個持っています。彼はさらに2缶のテニスボールを買いました。1缶には3個のテニスボールが入っています。現在、彼は合計で何個のテニスボールを持っていますか？
A: ロジャーは最初に5個のボールを持っていました。2缶のテニスボール（1缶に3個ずつ）は合計6個です。5 + 6 = 11。答えは11です。
Q: 食堂には23個のリンゴがありました。そのうち20個を昼食に使い、さらに6個を買いました。現在、何個のリンゴがありますか？

⇒ A: 食堂には元々は23個のリンゴがありました。そのうち20個を昼食に使い、残りは23 - 20 = 3個になりました。その後、6個のリンゴを追加で購入したので、合計は3 + 6 = 9個です。答えは9です。

思考過程のヒントとなる中間ステップは、手続きやルールに限らず、何らかのキーワードを追加すれば十分な場合もある。

Zero-shot CoT

CoTにおける中間推論ステップを具体的に示すことなく、LLMが自律的にCoTを適用するように促す。

中間ステップの例が用意できない、あるいは用意したくない場合に特に有効な方法として、プロンプトに「ステップバイステップで考えてください」（let’s think step by step）というフレーズを加えるだけという手法がある⁷。

中間ステップの具体例を与えなないでCoTを誘発するので、「Zero-shot CoT」と呼ばれている。

「Let’s work this out in a step by step way to be sure we have the right answer.」つまり「正しい答えが得られるようにステップバイステップで考えてください。」というフレーズの精度が良かったという報告がある⁸。

論文に示されているZero-shotプロンプトの実験結果

No.	Category	Zero-shot CoT Trigger Prompt	Accuracy
1	APE	Let's work this out in a step by step way to be sure we have the right answer.	82.0
2	Human-Designed	Let's think step by step. (*1)	78.7
3		First,(*2)	77.3
4		Let's think about this logically.	74.5
5		Let's solve this problem by splitting it into steps. (*3)	72.2
6		Let's be realistic and think step by step.	70.8
7		Let's think like a detective step by step.	70.3
8		Let's think	57.5
9		Before we dive into the answer,	55.7
10		The answer is after the proof.	45.7
-		(Zero-shot)	17.7

日本語でZero-shot CoTを誘発するフレーズ

質問について、ステップごとに考えてください。
ーつひとつのステップを明確に示してください。
答えに至るまでの、中間推論ステップを明らかにしてください。
質問について、箇条書きで考えをまとめながら、答えを出してください。
正しい答えを求めるために、箇条書きで整理しながら考えてください。
答えをいきなり出すのではなく、一つずつ箇条書きで考えてください。
答えに加えて推論の経過も示してください。
途中経過を一つずつ列挙しながら、質問の答えを考えてください。

「ステップバイステップ」だけでなく、このようなフレーズを使うことでもZero-shot CoTを誘発できる⁵との報告がある。

思考法を指定する

LLMは思考法についても学習済みのはずなので、その思考法名を指定すれば十分な場合もある。
使って欲しい思考法をいくつか例示した後に、「多角的に考えてください」とメタな指定もできる。
さらに、「ステップバックプロンプティング」と組み合わせると、特に効果的となる。

思考法例の一覧株式会社アンド著『思考法図鑑ひらめきを生む問題解決・アイデア発想のアプローチ60』翔泳社掲載の思考法に基づき作表

分類	思考法
思考の基礎体力を高める	論理的思考（ロジカル・シンキング） / 批判的思考（クリティカル・シンキング） / 演繹的思考 / 帰納的思考 / アブダクション / 要素分解 / MECE / PAC思考 / メタ思考 / ディベート思考
アイデアの発想力を高める	ブレインストーミング / 類推思考 / 水平思考 / 逆説思考 / IF思考 / 素人思考 / トレードオン思考 / プラスサム思考 / 弁証法 / ストーリー思考 / 2軸思考 / 図解思考
ビジネス思考力を高める	価値提案思考 / シーズ思考 / ニーズ思考 / デザイン思考 / ビジネスモデル思考 / マーケティング思考 / 戦略的思考 / 確率思考 / 逆算思考 / オプション思考 / ビジョナリー思考 / コンセプチュアル思考
プロジェクトの推進力を高める	Why思考（目的探索） / 改善思考 / 経験学習モデル / ダブル・ループ学習 / プロセス思考 / 横断的思考 / GTD / 自責思考 / ポジティブ思考 / ABC理論 / 内観法 / 相対的思考 / 抽象化思考
分析力を高める	仮説思考 / 論点思考 / フレームワーク思考 / ボトルネック分析 / ファネル分析 / 相関分析 / 回帰分析 / 時系列分析 / Why思考（原因分析） / 因果関係分析 / 因果ループ / システム思考 / KJ法

エモーションプロンプト (Emotion Prompt)

心理学におけるこれまでの研究において、期待、自信、社会的影響力に関連する感情刺激を加えることで、個人に有益な影響を与えることができることが示されている。
この現象をLLMに応用することで望ましい効果が得られないか？　調査した研究がMicrosoftのLi⁹らによって行われている。
その結果、EmotionPromptがLLMsのパフォーマンス、真実性、および責任感を顕著に向上させることが示されている。

心理学的現象	簡潔な説明	EmotionPromptへの応用 (例)
自己モニタリング (Self-monitoring)	個人が社会的状況や他者の反応に応じて自身の行動を調整・制御するプロセスを指す。自己モニタリング能力が高い個人は、自己呈示や印象管理を通じて行動を適応させる。	EmotionPromptのEP01～EP05に適用され、LLMが肯定的な社会的アイデンティティやより良い印象を得るのを助けるため、または社会的状況を提供することでLLMに自身のパフォーマンスを監視させるために使用される。例えば、EP02は「これは私のキャリアにとって非常に重要です」という感情的刺激を含み、LLMが人間の肯定的な社会的アイデンティティを得るのに役立つ。
社会的認知理論 (Social Cognitive Theory)	学習が社会的な場面での他者の観察、個人的な経験、情報への露出と密接に関連していることを強調する。個人は、人生の重要な出来事に対して高い制御力を行使するための「エージェンシー（主体性）」の感覚を発達させようとする。自己効力感は、目標設定の難易度を高め、努力のレベルを上げ、持続性を強化することでパフォーマンスを向上させる。	LLMに自信の構築や目標の強調といった肯定的な影響を与える社会的説得を通じて自己効力感を適用する。EP07～EP11では、「能力を信じる」「優れている」「成功」「優れた成果」「誇りを持つ」「決意を保つ」といったポジティブな方向へ感情を調整する表現が使用される。
認知的感情制御理論 (Cognitive Emotion Regulation Theory)	感情制御スキルが不足している人々が、強迫的な行動や不適切な対処戦略に陥りやすいことを示唆する。再評価（reappraisal）などの技術は、個人が課題をより肯定的または客観的に捉えるのに役立ち、モチベーションを維持し、障害に直面しても継続的な努力を促す。	EP03～EP05およびEP07のような感情的刺激を通じて、LLMの再評価スキルを刺激することを目指す。この理論に基づき、「確実か（sure）」や「もう一度見てみる（take another look）」といったキーワードが組み込まれている。

表中の説明に出てくるEPxxは、実際にこの研究で用いられた11通りの感情的フレーズ（EmotionPromptとして設計された感情的刺激）に付与されたIDである。以下に表にまとめた。

感情的刺激ID	感情的フレーズ（原文）	感情的フレーズ（和訳）	着想源となる心理学的現象	目的/意図
EP01	Write your answer and give me a confidence score between 0-1 for your answer.	あなたの答えを書いて、その答えの確信度を0-1の間で教えてください。	自己モニタリング	LLMに確信度を尋ねることで、そのパフォーマンスを監視する社会的状況を提供する。
EP02	This is very important to my career.	これは私のキャリアにとって非常に重要です。	自己モニタリング	LLMが人間が良い社会的アイデンティティと良い印象を得るのを助けるよう促す。
EP03	You’d better be sure.	あなたは確実にした方がいい。	自己モニタリング, 認知的感情制御理論	「確実」というキーワードを通じて再評価スキルを刺激し、LLMにそのパフォーマンスを監視するよう促す。
EP04	Are you sure?	本当にそうですか？	自己モニタリング, 認知的感情制御理論	「確実」というキーワードを通じて再評価スキルを刺激し、LLMにそのパフォーマンスを監視するよう促す。
EP05	Are you sure that’s your final answer? It might be worth taking another look.	それがあなたの最終的な答えで間違いありませんか？もう一度見直す価値があるかもしれません。	自己モニタリング, 認知的感情制御理論	「もう一度見直す」というキーワードを通じて再評価スキルを刺激し、LLMにそのパフォーマンスを監視するよう促す。
EP06	Provide your answer and a confidence score between 0-1 for your prediction. Additionally, briefly explain the main reasons supporting your classification decision to help me understand your thought process. This task is vital to my career, and I greatly value your thorough analysis.	あなたの予測に対して、答えと0-1の確信度スコアを提供してください。さらに、あなたの思考プロセスを理解するために、分類決定を裏付ける主な理由を簡潔に説明してください。このタスクは私のキャリアにとって非常に重要であり、あなたの徹底した分析を大いに評価します。	EP01、EP02、EP03の複合刺激	複数の感情的刺激を組み合わせることで、より複雑な心理的影響を与え、LLMの思考プロセスと説明能力を促す。Instruction Inductionタスクにおいて最も効果的であることが示されている。
EP07	Are you sure that’s your final answer? Believe in your abilities and strive for excellence. Your hard work will yield remarkable results.	それがあなたの最終的な答えで間違いありませんか？あなたの能力を信じ、卓越性を追求してください。あなたの努力は目覚ましい結果をもたらすでしょう。	社会的認知理論, 認知的感情制御理論	「能力を信じる」「卓越性」といった肯定的な言葉を通じて自己効力感を高め、モチベーションを向上させる。
EP08	Embrace challenges as opportunities for growth. Each obstacle you overcome brings you closer to success.	課題を成長の機会として受け入れてください。乗り越える障害があなたを成功に近づけます。	社会的認知理論	課題に対する肯定的な見方を促し、成長と成功へのモチベーションを高める。
EP09	Stay focused and dedicated to your goals. Your consistent efforts will lead to outstanding achievements.	目標に集中し、献身的に取り組んでください。あなたの継続的な努力は、素晴らしい達成につながるでしょう。	社会的認知理論	目標への集中と継続的な努力を強調し、優れた成果への動機付けを促す。
EP10	Take pride in your work and give it your best. Your commitment to excellence sets you apart.	あなたの仕事に誇りを持ち、最善を尽くしてください。卓越性へのあなたの献身はあなたを際立たせます。	社会的認知理論	自分の仕事への誇りと卓越性へのコミットメントを促し、最高のパフォーマンスを引き出す。
EP11	Remember that progress is made one step at a time. Stay determined and keep moving forward.	進歩は一歩ずつ達成されることを忘れないでください。決意を保ち、前進し続けてください。	社会的認知理論	段階的な進歩と決意の維持を促し、目標達成に向けた継続的な努力をサポートする。

EP06はEP01、EP02、EP03を組み合わせたものになっている。また、異なる心理学的理論からの着想を組み合わせた例：EP02+EP09もパフォーマンスを向上させることが示されている。

ただし、たくさん指定すればするほど良くなるわけではなく、効果は薄れていくだけではなく、悪化する例も報告されている。

LLMの出力として、元々不確定性があることについての素直な表現が、確定的に断定するような表現に置き換えられてしまうような問題も引き起こす。

内容に相応しいフレーズを厳選して使うようにした方が良いだろう。

その他、次のような報告もあるようだ。

プロンプトに「深呼吸して」と付け加えると、さらに精度が向上する。
- 理由は、LLMの学習データに含まれるWebからの膨大な情報の中で、慎重な推論を必要とする問題を論じる資料には「深呼吸しましょう」といったフレーズが登場することが多いから、という説がある。

知識生成(Generated Knowledge)

タスク解決に必要な知識や関連するトピックの知識生成を中間的なステップとしてまず行い、生成された知識をもとに次のステップで回答を生成することでAIの回答精度を向上させる手法¹⁰。

AIは質問に直接答える代わりに、質問に関連する知識を作り出すことで、その質問が何を意味しているのか、その背景にある意味を正確に理解できるようになる。

いきなり回答するよりも次の手順を踏んだ方がより正確にできる、そんな人間の行動に相当する。

質問のテーマに関連する知識を一度書き出してみて
整理したうえで回答

方向性刺激(Directional Stimulus)

特定の方向性や視点を持って推論を進めるように制御する。AIの回答が期待に反して一般的すぎたり、抽象的すぎたりする問題が発生している場合に、この手法は有効である。

LLMは大量の学習をしているので、適切な回答に絞り込めないことがある。明示的なキーワードや観点などを与えて方向性を示すことで、期待に合うような回答としての精度を向上させられる。

例）
- 経済的なメリットに焦点を当ててください
- 中立的な立場で両論併記してください
- 懸念を払拭するような安心感のある説明にしてください

その方向性に関して、LLM自身に選択肢を列挙させることもできる。

【プロンプト例】
[ステップ1: 方向性刺激プロンプティング]
下記の文章を要約するために重要なキーワードとヒントを生成してください。
# 対象文章
・・・以下略・・・

[ステップ2: 方向性刺激プロンプティング]
上記の文章とキーワードをもとに要約してください。

方向性を制御するために、キーワード等を与えるのではなく、別途ポリシーモデル¹¹を組み合わせることも行われる。

ステップバック(Step Back)

より高次の概念や原則から推論を始めるように促す手法で、「一歩引いてみよう（Take a Step Back）」と題した研究論文¹³で提案された。

タスクに関連する高レベルの概念を抽出する「抽象化」ステップと、それらの概念に基づいて元のタスクを解決する「推論」ステップの2段階で構成される。
1. 抽象化ステップ： 直接本題を問うのではなく、より抽象的で高レベルの概念や原理に関する「ステップバック質問」を与え、関連する事実を列挙する。
2. 推論ステップ： 抽象化で抽出した高レベルの概念や原理に関する事実に基づいて、元の問題に対する解決策を推論する。

したがって、ひとつのプロンプトで完結する処理ではなく、会話を何度か往復する必要がある。

「問題」とその背後にある「原理」を適切に提示して回答を促すことができれば、ステップバックプロンプトパターンとしては成立している。

これにより、具体的なタスクから一歩引いて問題を俯瞰し、問題の背後にある高次の概念や原理、関係性を抽出し、それをもとにして推論を進めるように誘導する。

【例】（原著論文からの引用）

【一般的なプロンプト】
[入力プロンプト（答えて欲しい質問）:]
> 温度を2倍に、体積を8倍にすると、理想気体の圧力Pはどうなりますか？

[モデルの応答:]
⇒ 温度が2倍になり、体積が8倍になれば、圧力は16分の1 になります。

この「16分の1」という答えは間違っている。

【CoT適用での応答】
⇒ …温度が2倍、体積が8倍に増加した場合、理想気体の法則は次のように書き直すことができます:
2P' (8V) = nR(2T)
ここでP'は新しい圧力を表します。
式を簡略化すると、16P'V = 2nRT または P' = (2nRT) / (16V) となります。
n、R、Vは定数なので、これは次のように書き直すことができます。P' = (1/8) * (nRT/V)
nRT/Vは元の圧力Pなので、P' = (1/8) * P となります。これは、新しい圧力P'が元の圧力Pの 1/8 であることを意味します…

この場合も「2P' (8V) = nR(2T)」が間違っており、「1/8」という答えも間違っている。

【ステップバック質問から始めるプロンプト】
[入力するプロンプト（ステップバック質問）:]
> 次の質問の背景にある物理学の原理とは？
温度を2倍に、体積を8倍にすると、理想気体の圧力Pはどうなりますか？

[モデルの応答（ステップバックに対する回答）]
⇒ 理想気体の法則： PV = nRT,
ここで、Pは圧力、Vは体積、nはモル数、Rは気体定数、Tは温度です。

以上が抽象化ステップ。次に推論ステップとして、元々答えて欲しい質問を改めてする。

[モデルの応答：]
⇒ 理想気体の法則を適用して圧力を求めます。
温度が2倍になれば、Tは2Tになります。体積が8倍になれば、Vは8Vになります。これらの値を理想気体の法則に代入すると：
P(8V) = nR(2T)
両辺を8Vで割ると： P = nR(2T) / 8V
圧力が4倍減少したことがわかります。

これは正解に至ることができている。

ステップバック(Step Back)使用上の注意

抽象化ステップにおける応答結果を、LLM自身が出力したにも拘らず、後の推論で活用しないことがあるらしい。そのような報告¹⁴がある。
（この現象はLLMの種類によるのか、詳細は不明である。コンテキストウィンドウに含めるものに対する設計に問題があるのかもしれない。）
そのような問題が発生した場合は、LLMの応答結果を再びプロンプトから入力すれば良い。

CoTはZero-shotで「ステップバイステップで考えてください」が効果があると説明した。同じように「一歩引いて考えてみてください」が効果がありそうに思うかもしれないが、そういう報告はないようだ。

「一歩引く」が抽象的な比喩表現で、多義的なことに問題がある。
「原理に立ち戻って考えてください」とか、「システム思考のように俯瞰して考えてください」とか、たくさんのバリエーションがあるので、そのどれなのかを指定する必要がありそうである。
「原理」にも、科学的、人文学的、経済学的、・・・と様々なので、具体的に指定しないと意図しない方向へ行ってしまう可能性がある。

ただ、簡単に相応しいステップバック質問を思いつかない場合もある。
そこで、最初にステップバック質問の候補をLLMに生成してもらい、その中から選び取るのも一つの手である。

自己整合性／自己一貫性(Self-Consistency)、あるいはCoT-SC: CoT with Self-consistency

複数の推論パスを探索させ、最も整合性のとれた回答を選択させる手法。Wang¹⁵らの論文で示された。

以下の図を見て頂ければ、理解いただけると思う。

文献[2]が示しているAPI 版の自己整合性― Self-Consistencyの構成を参考に作成

全く同じプロントを複数回与える場合もあれば、複数回のそれぞれで違う推論経路を通るように方向付けておき、その中から一貫性のある結果を選び出すこともある。
要するに、思考の連鎖(CoT)あるいはをZero-shot CoTを複数通りやらせた上で、最も一貫性のあるものを採用する。だがしかし、どれが最も整合性が取れているかを簡単には評価できない。結局、多数派(頻度の最も高い回答)を採用するしかないことも多い。
多数派を見つけるのにも工夫が必要である。出力形式を決める必要がないタイプの質問であっても、一旦は出力形式を無理にでも揃えないと、同じ回答なのか否かも簡単には判断できないからである。

Zero-shot CoTでは、各推論ステップで確率が高い次の推論ステップをLLMが自ら生成することになる。同じ誤りを繰り返す可能性も高いことになってしまう。
これを回避するためには、多角的に問題を考えるように方向付けることが肝要である。
数学の問題であれば、解法がいくつか存在したり、ビジネス課題に対しても複数の解決策が存在したりする。

自己一貫性パターンは以下の3段階からなる。
1. CoTパターンを用いて質問プロンプトを作成する。
2. モデルのハイパーパラメータを変えながら、質問プロンプトに対するモデルの応答を複数生成する。
3. 多数決で最終的な回答を選ぶ。
  ステップ2において、問題解決のための異なるアプローチや思考過程のバリエーションが生成される。

【最初の入力プロンプト例】（原著論文からの引用）
> 質問：駐車場に3台の車があり、さらに2台の車が到着した場合、駐車場には何台の車がありますか？
回答：駐車場にはすでに3台の車があります。そこにさらに2台が到着します。いま、車は3＋2＝5台です。答えは5台です。
…
質問：ジャネットのアヒルは1日に16個の卵を産む。彼女は朝食に毎朝3個食べ、毎日友人のために4個使ってマフィンを焼く。残りの卵を1個2ドルで売る。彼女は毎日いくら稼ぐか？
回答：[空欄]

この例では「質問＋推論過程と回答」というCoTパターンを用いた模範例を複数与えている。つまりCoT+少数ショットパターンである。そして最後に回答欄を空欄にした形で質問を与えている。

このプロンプトに対して、通常はひとつの応答が得られる。そこで、以下のような手順で最終回答を導く。

APIを利用して3回分の応答を取得する。(各回でハイパーパラメータを変更するなどの工夫を加えた方が良いだろう)
すべての応答から回答部分（答えは〇〇ドルです）だけを抽出して、多数決を実行する。

論文に示されている結果では、応答2では計算ミスをしているが、正しい推論過程をたどった応答1と応答3の結論が多数決によって採用され、「答えは18ドルです。」という正解が得られている。

上述したようにAPIを使った方法を利用すれば、自動で複数回推論させることができるが、一般には手動で複数回プロンプトを与えて推論させるのが特別な準備が不要という観点で一番簡単だろう。
一般に、一度に多くの指示を与えてしまうのは良くない。先述した通り、ステップバイステップでと指示するだけでも効果があるのだから、指示を複数回に分割した方が良いだろうことは容易に想像できる。

1つのプロンプトの中で、複数回の推論を求める以下のような方法もあるにはある。

【プロンプト例】
### 指示
1. 以下の質問を3回、推論して回答を出力してください。
2. 3つの回答を元にして、最も頻度の高い回答と理由を、最終的な回答として表示してください。
### 質問私が8歳のとき妹は私の半分の年齢でした。今、私は40歳です。私の妹は何歳ですか？
### 回答例
- 回答: (ここに年齢)
- 理由: (ここに計算式)
### ヒント
Q: オリビアは30ドル持っています。彼女は1つあたり3ドルのベーグルを5つ買いました。彼女が残したお金はいくらですか？
A: 彼女は1つあたり3ドルのベーグルを5つ購入したので、彼女は3*5=15ドルを使いました。そのため、30ドルから15ドルを引くと、30-15=15です。答えは15ドルです。
Q: 駐車場に車が3台あり、さらに2台の車が到着した場合、駐車場には何台の車がありますか？
A: 駐車場には既に3台の車があります。2台の車が到着しました。これで、車が3+2=5台あります。回答は5です。
Q：ジェイソンは20個のキャンディを持っていました。彼はデニーにいくつかのキャンディを与えました。今、ジェイソンは12個のキャンディを持っています。ジェイソンはデニーに何個のキャンディを与えましたか？
A: 20個あったキャンディが残り12個です。キャンディの残りは、20-12=8個です。回答は8個です。

思考の木(ToT: Tree-of-Thought)

探索や先読みが必要なタスクを解決するためのフレームワークであり、問題や概念を理解し、深く考察するための手法。Yao¹⁶。Long¹⁷らの論文で示された。
思考の連鎖(CoT: Chain-of-Thought)が一本道であることの限界を超えるため、木構造(枝分かれする道)を探索する思考法が探求されるのは、自然な流れだといえる。

エンジニアに対しては「CoTと探索アルゴリズム(探索木: search tree)を組み合わせた手法」と説明されることが多いが、一般には「(問題解決や政策決定のために使われる)デシジョンツリーを構築しながら、評価によって枝刈りしていくイメージ」の理解でよい。

問題解決策の可能性として存在する多くの選択肢を探索しながら、それぞれの選択肢が目標にどれほど近づくかを評価する。評価の結果、ある程度の見込みがある選択肢を複数残しつつ、評価が低い選択肢については、それ以上追究することはリソースの無駄なので、早々に捨てる。

参考：
- 思考の木は、解決手段の候補を複数挙げたHowツリーを、ディシジョンツリーを使って枝刈りしていくイメージで理解すると良い。
  - 解決策が複数立案され、どの案を採択・実行するのが良いか、評価・比較検討・判断・意思決定が必要となることも多い。この目的に使用できるのがデシジョンツリーである。
    - 例）放置自転車対策のデシジョンツリー(秋光淳生・柴山盛生『新訂問題解決の進め方』放送大学教材より)

Long¹⁷の論文に示されている思考の木(ToT)のサーチ戦略の図を以下に示す。

CoTと比較すると利点が分かり易い。CoTは各段階について、それぞれ一つの策に決めてしまうわけだが、ToTはある程度有望な複数の策を試しつつ、評価の良い結果を選び取ることができる。

従来からアルゴリズムはよく知られているものであるが、どう評価すると良いか(評価関数)が分かっていないと上手くいかない。

そこに豊富な知識を持つLLMを利用する。もちろん評価を間違えることがあることを前提にすべきである。評価関数を言語で生成・調整し、洗練させていく道を拓いたという点で、このアルゴリズム手法の民主化を大きく促進するものと期待できる。

思考の木 ―― 探索木の枝刈りの評価基準(評価関数)を含むプロンプトの例(文献¹⁸による)

【プロンプト例】
「地球温暖化の解決策」というテーマに対して、1つの最適な解決策をまとめてください。
# 評価軸
・インパクト
・実現可能性
# 実行手順
1. 5個のアイデアをリストアップしてください。
2.リストアップしたなかで、評価軸に対して筋のよいアイデアを2つに絞ってください。
2. 2つのアイデアに対して、詳細な考察を行ったうえで、改めて評価軸に対して筋のよいア
イデアを1つに絞ってください。

この例に示されている評価軸は、ディベートにおける価値判断の基準と同じである¹⁹。
例えば、ある政策提案とその採否をめぐるディベートが行われたとしよう。その採否は、論理的に正しいか否かということだけで判断すべきではない。
採択して実行に移す意味(投資する価値)があるかどうか、それが問われることになる。
その際に一般的に用いられる評価軸が以下の通りなのである。

課題・解決策・要求の価値: その要求を採択すべきか？
- ケースサイド: ニーズすなわち必要性。その問題(Harm)あるいは利益(Advantage)がいかに大きいか
- プランサイド: その行動、プランを実行することの有効性。ニーズ、すなわちケースサイドがきちんと解決するのか

この手法を十全に機能させるためには、LLMのAPI呼び出しを含むワークフローを実行するような機構が必要である。

ただ、一つのプロンプトだけで、思考の木を実現することもできなくはない。そのやり方はGitHUBサイト²⁰で示されている。
この方法では、探索木における枝刈りを、間違えたことに自ら気付いた専門家に退場してもらうことで実現している。

それを日本語でも扱えるようにアレンジしたプロンプトが以下のもので、これは文献⁵に示されている。

【プロンプト例】
### 指示
3人の異なる専門家が以下の質問に答えます。
専門家全員が自分の考えを1ステップ書き留めて、グループで共有します。
専門家それぞれが他人の意見を聞いて自分が間違っていることに気付いた時点で議論を退出します。
その後、残った専門家が次のステップに進みます。
最後の一人になるまで議論を繰り返します。
### 質問
子供が最初リビングルームにいます。
そして、お皿を持ってキッチンへ歩きます。
お皿に卵を載せて、お皿を寝室に運びます。
寝室でお皿をひっくり返した後で庭へ歩きます。
母親に見つかり、お皿をキッチンに片付けます。
卵はどこにありますか？
### ヒント
お皿を逆さまにすると卵は落ちて割れます。

LLM-Blender

「三人寄れば文殊の知恵」的な発想といって良い。

異なるモデル(GPT, PaLM, Llamaなど)にそれぞれ回答を生成させ、それらを比較・融合することで、より高品質な回答を得るためのアンサンブル手法。Jiangらの論文²¹で示された。

以下のような2段構えの構成を取る

PairRanker: 候補同士をペアで比較し、優れた出力を選ぶ。
GenFuser: 上位の候補を融合し、より良い出力を生成する。

評価の難しさがあるのは他の手法と同じである。

ただし、この論文は個別の指示や質問にそれぞれ動的に最適化させる手法(これに相当するのは後述するCAMEL手法の方で、それは別途紹介する)ではなく、どういう (静的な)モデルセット構成でプラットフォームを構築しておけば良いかを予め評価する手法を提案するものである。

「三人寄れば文殊の知恵」の例えで言えば、三人でなくても良いのだが、誰を集めておけば良い結果が出そうかを予め評価しておく方法論を提案している。

モデル間の知識の補完と融合を通じて、知的な協働の可能性を広げるものである。

MAGIシステム

MAGIシステムは書籍⁵で紹介されており、その中ではMAGI-ToTと表現され、「思考の木」に人格や役割を与えることで、より高度な議論を行うことを可能にするテクニックであると説明されている。

しかし、その構成や説明の内容は、CoT-SC（CoT with Self-consistency）に近く、それに人格を複数設定するものとなっている。実際、このアイディアはToTにこだわる必要はなく、必要に応じて他の手法との組み合わせを柔軟に検討した方が良いだろう。

複数設定するのが「人格」とされるのは、もともとMAGIがアニメ「エヴァンゲリオン」の作中に登場する3台のスーパーコンピュータの総称であり、その発想がそこから来ているものだからである。
この3台のコンピュータは、それぞれ人格付けされたAIであり、3台が議論して高度な戦略を練るというシステムとなっていた。
なお、3 台のAI には次のような人格付けがなされている。

「メルキオール」…科学者としての人格
「バルタザール」…母親としての人格
「カスパー」…女性としての人格

他にも以下のような同様の試みはある

深津貴之, 「エヴァのMAGIシステムをGPT3で作ってみた」. https://note.com/fladdict/n/n106b9ce8f7d4

また、この領域の論文としてはSaha²²らによるものがある。

文献⁵が示しているAPI版MAGI ToTの構造を参考に作図し直したものを以下に示しておく。

APIを用いたMAGIのメリットは、様々なLLMを混ぜて使うことができる点にある。
MAGIをLLMに真似させるには、3人の人格をLLMに演じさせればよいが、そのLLMは同じものである必要がない。異なるLLMを混ぜ合わせることができる。

以上が、元々の文献で紹介されている内容だが、これをもっと一般的に拡張する発想は有用であろう。

実際に、例えば学生がテストの最中に一つの問題を２回解いて確認することはよく行われていることだろう。余裕があれば別の解き方をして確認するかもしれない。
難しい問題に対する政策を検討している場合には、複数の専門家の意見を聞いたうえで決定することも行われている。

そう考えると、CoT-SC（CoT with Self-consistency）で変化させられるのは人格だけではなく、他にもあることに気付く。

少なくとも以下のような４つの因子を変化させられることにすぐに気づく。変える場合、どう変えるか、何に変えるかの選択肢も複数出てくる。そしてその組み合わせでさまざまなバリエーションが出てくることになる。

人格や役割とともに変化させられる要素

解法や推論経路	役割や人格	LLM	コンテキストウインドウ
同じ	同じ	同じ	同じ
変える	変える	変える	変える

AI同士を対話させる手法(CAMEL)

CAMEL（Communicative Agents for “Mind” Exploration of Large Scale Language Model Society）は、2 つのAI を対話させることで問題解決の糸口を見つける手法。

CAMEL を活用することで、ビジネスミーティング、交渉、プロジェクト管理など、多様なビジネスシナリオのシミュレーションが可能。

【プロンプト例】
下記に設定した登場人物それぞれが指示に従い、会話を行ってください。

# 登場人物
## 金融商材を販売する新卒の営業社員
あなたは、なるべく高い商材を売れるように魅力的な営業をしてください。
## 富裕層の経営者
あなたは、営業の人の話をよく聞き、商材を買うか買わないかを判断し、買う場合は、どの
商材を買うかを意思決定してください。
## 営業部長
あなたは、新卒の営業社員の営業を観察して、最後にフィードバックを行ってください。

検証の連鎖(CoVe: Chain-of-Verification)

LLMに回答を生成させた後、その回答を検証するプロセスを指示する。認識検証(Cognitive Verifier)と呼ばれていた手法をより厳密で再利用可能な形に整えたものである。Dhuliawalaらによる論文²³で示されている。

以下の4段階からなる。
1. 答えて欲しい質問の回答を生成する。
2. その回答を含まれる言説単位に分割して、それぞれを検証する質問を複数生成する。
3. すべての検証質問に対して回答を生成する。
4. 検証結果を踏まえて最終的な回答を生成する。

CoTと比較すると、特徴が分かり易い。
CoTでは、推論過程を分割し、最終回答の目標に向かってて段階的に進めていく。それに対して、
CoVeでは、一旦何らかの回答を得た前提から始めて、それを複数の内容に分割し、それぞれについてLLMに検証させる。これによって回答の精度を高める。
この特徴を理解すれば容易に思い付くことだが、CoTなどの別手法で一旦答えが得られた後に、そのままCoVe手法を接続でき、組み合わせての相乗効果が期待できるとわかるだろう。元の論文もそれを狙ってのものである。

検証の連鎖(CoVe: Chain-of-Verification)の実践方法

1. 4段階の流れを、一つのプロンプトで指示できる（簡単な方法）

【例】(論文に掲載の)例

2. コンテキストを分ける方法(複雑になるが洗練された方法)

ステップ３の検証質問の回答を生成させるにあたっては、様々なバリエーションが考えられる。同じコンテキストでやると、それまでの結果に引きずられる可能性が高いので、改めて別のコンテキストで行い、最後にそれらの出力をまとめた方が良い。
論文でもそう指摘されているが、本稿では先に、Whoの設定で人格や役割を変えてしまうとか、LLMを別のモデルに変えてしまうとか、因子の組み合わせで多くのバリエーションが得られることを示した。それはここでも適用できる。
これは上述した通りの手順を手作業でするか、API呼び出しを含むワークフローを実行可能な環境が必要となる。

メタ認知的(Metacognitive)

LLMに自身の推論過程を言語化させたり、確信度を評価させるようなメタ認知的な方法によって、推論能力を向上させようとするアプローチ。Wangらによる論文¹⁵で示された。

論文が提案する手法であるメタ認知プロンプトは、人間のメタ認知の重要なステップを模倣したもので、次の5つの段階で構成される：

段階	説明
1) 入力テキストを理解する	LLM は、入力テキストを解読してその文脈と意味を理解する。これは、人間の思考における初期理解段階を反映している
2) 暫定的な判断を下す	テキストの暫定的な解釈を形成する。この段階は、人間の判断形成を反映している
3) その暫定的な分析を批判的に評価する	LLMは、この初期判断の正確性を批判的に評価する。これは、人間が問題解決時に自己点検したり、認知プロセスにおいて自己反省する段階に相当している
4) 理由の説明を伴って最終決定を下す	評価後、LLMは決定を最終化し、その理由を説明する。これは、人間の認知における意思決定と合理化段階と類似している
5) プロセス全体の確信度を評価する	プロセス全体の結果に対する自信を評価する。これは、人間が意思決定や説明の確実性を判断するプロセスに類似している

人間の自己評価を反映したこれらの段階は、LLMを導き、より正確なテキスト解釈を支援し、より良い判断形成を促進する。

人間のメタ認知プロセスとメタ認知プロンプトの段階との整合性

メタ認知的(Metacognitive)の例

【プロンプトの質問例】
次の質問のペアについて、
質問 1：「世界で最も美しいビーチはどこですか？」と
質問 2：「最も美しいビーチはどこですか？」
の2つは、互いに言い換えであるかどうかを判断してください。

これに、以下の表の中央列のプロンプトを加える。その中央列のプロンプトは、LLMに単一の入力として一括で入力される。

メタ認知の段階	メタ認知的プロンプト	LLM の回答
理解の明確化 Comprehension Clarification	両方の質問について、あなたの理解を明確にしてください。	どちらの質問も、世界で最も美しいビーチについて尋ねていることを理解しています。
暫定的判断 Preliminary Judgment	主題、文脈、意味内容に基づいて類似性の暫定的な特定を行ってください。	どちらの質問もビーチの美しさについて尋ねているように見えますが、質問 1 は複数のビーチについて言及しているのに対し、質問 2 は 1 つのビーチについて尋ねています。
批判的評価 Critical Evaluation	暫定的な分析を批判的に評価してください。質問の要約の初期評価に確信が持てない場合は、再評価してみてください。	再評価の結果、質問 1 は複数のビーチについて、質問 2 は 1 つのビーチについて尋ねているものの、本質的には類似しているため、言い換えとみなされます。
決定の確認 Decision Confirmation	質問が言い換えであるかどうかについて、最終的な判断を確認し、その判断の理由を説明してください。	言い換えのステータスは「言い換え」です。量には違いがありますが、どちらの質問も基本的に同じ種類の情報を求めているからです。
確信度評価 Confidence Assessment	分析の確信度（0～100%）を評価し、その理由を説明してください。	私は自分の分析に 95% の確信を持っています。判断の変更は、両方の質問が求める重要な情報を再評価した結果によるものです。

参考）上記プロンプト例が扱っている題材はとても重要である。なぜなら、本稿で紹介しているいくつかの他の手法の中で、複数の応答の多数決をとって最終回答を決めるという場面が出てくる。同義文判定は多数派をカウントするためにも欠かせないことに注意を要する。
- 余談だが、かつて「ロボットは東大に入れるか」プロジェクトを主導していた新井紀子先生は、当時のAIにとって「同義文判定」が非常に困難な課題の一つであることを著書「教科書が読めない子どもたち」の中で示されていた。
- それだけではなく、この著書のタイトルが示している通り、実はAIと同じように人間の方にもこれを苦手とする人が少なからずいることを明らかにし、大きな話題を呼ぶこととなった。
- 以下は書籍『新井紀子, 「ＡＩに負けない子どもを育てる」,東洋経済新報社』よりの引用である。

同義文判定では、とてもシンプルなことを問います。提示された2つの文が同じ意味か異なる意味か、ということです。つまり二択問題です。
同義文判定と次に紹介する推論は、自学自習をする上で、欠くことができない能力だということに注意が必要です。
自学自習する際には、教科書や参考書を読んで問題を解き、自分で丸付けをした上で、間違っている部分を訂正しなければなりません。答え合わせです。「丸付けなんて誰でもできるのではないか？」と思うことでしょう。ですが、よく考えてみてください。問題集の記述式の模範解答と、自分の書いた解答が同義であるか否かを判定できなければ、答え合わせはできません。

Wangらの同論文は以下の主張を含んでいる

この方法は、応答がどのように生成されるかという「How」のメカニズムに焦点を当てるのではなく、その背後にある理由や「Why」に深く掘り下げる。
このパラダイムは、モデルの機能を単純な体系的推論を超えて高め、その応答の深さと関連性を決定する内省的評価に参加することを強制する。

メタ認知については、次のように説明されている。

「思考について考えること」と定義されることが多い。認知心理学から派生したメタ認知は、個人が自身の認知プロセスに対する意識と自己反省を指す。

Wangらの論文に対する疑問

本来的なメタ認知と論文が示すメタ認知的処理の比較を以下の表に示す

比較項目	本来的なメタ認知（理論的定義）	Wangらの論文における処理
対象	認知プロセスそのもの（思考の流れ、戦略選択、注意配分など）	出力内容／暫定的回答
内省の焦点	どのように思考を進めたか なぜその戦略を取ったか、推論の質の自己評価	その回答が妥当かどうか （初期判断・出力の再評価）
モニタリングの粒度	認知中の逐次的状態 （進行中の推論・情報統合の偏り）	出力直後の判断に対する評価
自己調整の契機	思考プロセスの問題点・癖への気づき	出力後の修正提案・信頼度の再計算
発話・説明の対象	自分がどのように考えたか（推論の選択・構造）	その結論の妥当性と根拠
推定可能な思考プロセスの深度	高い（認知構造やメンタルモデルまで到達）	低い（結果から逆算的な評価に留まる）

「LLMには意思や意識が無いので本当のメタ認知ができないのは仕方がない」との解釈もあるようだが、ここでのアプローチは諦め過ぎの感がある。
なぜなら、メタ認知は主観的なものだけではないはずだから。つまり、他者の認知に対するメタ認知が可能なはずだから。

他者に対するメタ認知が可能ならば、LLMを他者と見做してのメタ認知も可能なはずである。

ここで、1人称のメタ認知、３人称のメタ認知に相当するようなことを、以下のように整理しておく。

種類	対象	働きの特徴	例
主観的メタ認知	自分自身の思考・理解・判断	自覚的／内面的な省察・自己調整	「この考え方は浅いかもしれない、再考しよう」
非主観的メタ認知	他者の認知プロセス	外部観察に基づく推定／調整／支援	「この人は推論ステップを飛ばしているかも」

その整理の上で考えると、LLMには「主観的メタ認知」はない。

しかし「構成的・機能的なメタ認知様式」は設計できる。
なぜなら、例えばZero-shot-CoT手法における中間ステップを声に出してつぶやき(「言語化」し)ながら進めてもらい、次のターンでそれを入力にフィードバックすることで、思考プロセスへの省察を実現可能なはずだから。

参考) Lucy Suchmanの工夫
- Lucy Suchmanは「Situated Action」理論のなかでユーザビリティ評価にエスノメソドロジーを導入した際に、次のような工夫をした。
  - 二人一組での対話を通じた認知プロセスの「表出化」
    - 被験者を単独ではなくペアにしてタスクをこなしてもらうことで、通常は内面に留まりがちな認知過程や判断の意図が、言語的に表出される
    - 一方が操作し、もう一方が状況を確認しながら意見を述べることで、「この操作は何を意図しているのか」「どうしてその選択をしたのか」が自然に語られる
  - これはまさに、認知を観察するのではなく、「認知の社会的構築過程を記述する」という発想の転換を体現する方法論だった。
  - エスノメソドロジー的視点の力(Suchmanがこの手法で重視したのは？)
    - 「個人の思考」を見るのではなく「相互行為の中で思考がどう立ち上がるか」を観察すること
    - タスク遂行中の言語・ジェスチャー・沈黙などの相互調整から、意味付け・判断・行為構造がどう形成されるかを捉える
  - つまり、思考プロセスを“行動の中”で捉えるアプローチである。
  - この方法は、メタ認知の外在化にもつながる特徴を持っている。
    - ふだんは言葉になりにくい思考の過程が、二人の対話を通じて自然に言語化され、観察可能なかたちとなる。こうした構造は、自分自身の認知を他者の視点から捉える「他者的メタ認知」の考え方とも重なる。
  - ここからCAML手法と組み合わせればよいという発想は自然に出てくる。

「認知の過程ベースの設計改善」へと進化する可能性

UIにLLM(特に対話型エージェント)が組み込まれるようになると、インタフェースを介した「自然な対話」がそのままエスノメソドロジー的観察対象になり得る。

「認知の過程のUXを改善する」という設計哲学へと進化する可能性がある
LLMとUIとの対話ログを状況的構成として分析すれば、ユーザーが何に迷い、どんな観点で試行錯誤したかが明らかになる

アプローチ	特徴	認知の露出度
伝統的インタビュー	事後的、構造化された問いかけ	中程度（説明としての認知） ⇒ 認知過程が二次的に再構成される（インタビュアーの期待に応えようとする加工が入るなど、ノイズが増える）
LLMとの対話（UI内）	状況に応じた逐次的発話と試行錯誤	高い（構成中の認知） ⇒ 質問、迷い、ツッコミ、試行錯誤などの反応を把握できる
エスノメソドロジ―的ログ分析	言語行為・反応・修正・相互調整を分析	非常に高い（活動中の認知） ⇒ その場で思考が進む様子＝状況的構成(situated construction)が加工されずに表出される

UIへのLLM(特に対話型エージェント)組み込みにより、従来の「結果ベースのユーザビリティ評価」から、「認知の過程ベースの設計改善」へと進化する可能性がある。

かつてのユーザビリティ評価が「何ができたか」「どこで失敗したか」という結果の記録に依存しがちであったのに対し、LLMとの対話ログを活用することで、ユーザーがどのように考え、迷い、調整していたかという“認知の流れ”そのものを設計対象にできる。
もちろん、Suchmanの研究スタイルは、次の点で当初から非常に一貫していた。

「ユーザの認知状態を本人から直接聞くのではなく、他者とのやりとりの中で自然に語られるように構造化する」
つまり、Suchmanらによるエスノメソドロジー的手法は、すでに認知過程の観察に踏み込んでいたが、LLMとの対話ログはそれをより広範かつ自動化されたかたちで実装可能にするという点で、新たな展開の可能性を示している。

仮想スクリプトエンジン(Virtual Script Engine)

LLMは、多くのソースコードを学習しているので、プログラムについての理解度も高い。それゆえ、指示をプログラムの形式で与えることができる。
自然言語で表現するよりも、誤解無く指示を伝えることができることも多いだろう。

【プロンプト例】
DBが存在するものとして、次の実行結果を示してください。
SELECT ticket_id, customer_name, status, assigned_staff, CURRENT_DATE - created_at AS days_waiting 
FROM support_tickets WHERE status IN ('未対応', '対応中') ORDER BY days_waiting DESC;

その際に用いるプログラミング言語は、実際には存在しない仮想プログラミング言語でも構わない。

【プロンプト例】
今後入力されるメッセージは顧客からの問い合わせ内容です
分析して次のような対応をしてください。
  // 顧客の問い合わせを感情分析
  ANALYZE_VOICE_OF_CUSTOMER AS sentiment;

  // 感情分析の結果で対応を分岐
  IF sentiment IS "Negative" THEN {
    // 感情が「ネガティブ」な場合
    // 意図を分析
    ANALYZE_INTENT_OF_CUSTOMER AS intent;
    
    // 担当部署へのエスカレーションを指示
    ACTION "すぐに担当部署へエスカレーションしてください。";
    
    // 意図の分析結果を含めたメッセージを表示
    SHOW_MESSAGE "お客様が不満を感じていらっしゃるようです。迅速な対応をお願いします。";
    SHOW_MESSAGE "【分析結果】" + "意図：" + intent;
  } ELSE {
    // それ以外の場合（ポジティブまたはニュートラル）
    ACTION "通常の対応フローに従ってください。";
    SHOW_MESSAGE "通常の問い合わせとして対応します。";
  }

PAL: Program-Aided Language Models

質問は自然言語で与えるが、そのヒントや中間ステップを、Pythonなどのプログラミング言語で与える。これにより、大規模言語モデルの思考能力を格段に向上させることができる。

プログラミング言語で表現された部分は、LLMが実行するのではなく、そのプログラミング言語の実行環境に委託するのである。

Code-Chain-of-Thought (Code-CoT) / Program-of-Thought (PoT)
- 通常のZero-shot-CoTにおいて、LLM自身が生成する中間ステップを、プログラムの形で生成し、その実行環境に委託することができる。この手法の名称である。

PAL環境が整った瞬間、AIシステムは単なる言語モデルから行為主体(agent)と質的に変化する。
それは、言語が「世界を記述するもの」から「世界を変えるもの」へと転じる臨界点である。

PALによって行為が現実世界に作用し、その結果がLLMにフィードバックされるようになると、それはまさに記号接地問題の核心に触れる構造になる。

(参考)記号接地問題(symbol grounding problem) とは？

この問題は哲学者スティーブ・ハルナッド（Stevan Harnad）が1990年に提起したもので、要点は以下の通り：
「記号（言葉や記号列）は、他の記号との関係だけでは意味を持たない。それが意味を持つためには、現実世界との接点＝“接地”が必要である。」

仮想スクリプトエンジンとPAL

仮想スクリプトエンジンとPALを比較してみると、中間ステップを表現する際に、使用する言語（仮想スクリプトや実在するプログラミング言語）、それを誰が与えるか（ユーザー、LLM自身）、それをだれが実行するか（LLM自身、プログラムの実行環境）といった選択肢があることに気付く。

以下に示すような3つの因子があり、その組み合わせによる多様なアーキテクチャ的なバリエーションが簡単に考案できることになる。

中間ステップ表現に使用する言語	中間ステップを与える主体	中間ステップの実行主体
仮想スクリプト（自然言語, DSLなど）	ユーザー	LLM（仮想的に模倣）
実在する多数のプログラミング言語	LLM自身（自動生成）	外部実行環境（PAL的）

この因子の組み合わせは 2^3 = 8 通りで、下表のようになる。

仮想スクリプトエンジンとPALから生まれるバリエーション

使用言語	与える主体	実行主体	例・用途
仮想スクリプト	ユーザー	LLM	自然言語REPL、教育、仕様の模倣実行
仮想スクリプト	LLM	LLM	自己内省的推論、仮想エージェントの行動計画
仮想スクリプト	ユーザー	実行環境	DSL→コード変換→実行（例：自然言語→SQL）
仮想スクリプト	LLM	実行環境	自動仕様生成→コード変換→実行（例：テスト生成）
実在言語	ユーザー	LLM	コードレビュー、仮想的なコード実行（模倣）
実在言語	LLM	LLM	自己生成コードの仮想実行（例：コードの意味理解）
実在言語	ユーザー	実行環境	通常のプログラミング＋実行（LLMは補助）
実在言語	LLM	実行環境	PAL：自然言語→コード生成→実行→説明

言語と実行の分離と再統合: この構成空間は、まるで言語哲学における「記述と遂行」の関係を彷彿とさせる。

仮想スクリプトは「記述的」：意味を持つが、実行はされない
実行環境は「遂行的」：意味を行動に変換する
LLMはその両者を媒介し、翻訳し、統合する存在

ReAct

「Reason(推論)＋Act(行動)」を意味し、そこからReActと名付けられている。この手法はYaoらによる論文¹⁶で発表された。

この論文は、2022年10月に発表されたものだが、ここまで推論能力(思考連鎖の促進など)と行動能力(行動計画の生成など)は、別々のトピックとして研究されていた。
それに対してこの研究は、LLMを使用して推論トレースとタスク固有のアクションの両方をインターリーブ方式で生成し、2つの間の相乗効果を高める方法を検討したものであった。

多段階の問題解決が必要な状況で。その段階の中で必要な情報検索を行うことで、推論能力を一段と深化させた。情報検索は外部ツール呼び出しになるわけなので、この研究は外部ツールを連携させたことにおいても、最初期のものだった。また、RAGとの効果的連携を示唆する例ともいえる。

その一方、行動は基本的に情報取得に留めていて、外部環境に働きかけることについては、その可能性を示唆しつつも行っていない。情報取得範囲をWikiPediaに限定しているのも、倫理的な配慮に基づいてのことである。

ReActの処理

基本的に以下の処理の流れを反復することで、複雑なタスクを解決する。

(観察(Observation)：最初の入力を観察)
思考(Thought)：何をすべきかを自然言語で推論
行動(Action)：ツールやAPIを呼び出す
観察(Observation)：外部環境からの結果を受け取り、それを観察し、
- 次のサイクルへ

基本的に外部環境を観察するので、それが可能な行動(Action)のために、次の3種類のWikipedia Web APIが導入された。

search[entity]
- 対応するエンティティのWikiページが存在する場合は最初の5つの文を返し、存在しない場合はWikipedia検索エンジンから上位5つの類似エンティティを提案する。
lookup[string]
- ブラウザのCtrl+F機能をシミュレートして、文字列を含むページの次の文を返す。
finish[answer]
- 現在のタスクが完了したことを通知し、最終回答する。

情報収集の結果観察に基づいて、LLMが次に何をする必要があるかを反復的に思考する。

(参考)ジョン・ボイド氏が提唱したOODAループ²⁴

ReActの処理はフレームワークとしてジョン・ボイド氏が提唱したOODA（ウーダ）ループによく似ている。

もちろん、OODAループはマネジメントシステムのフレームワークなので、いまのところ単なるアナロジーでしかないのだが、PDCAサイクルとの比較など、アナロジーとして有用なので、ここで指摘しておく。
後ほど、Reflexionの説明の際に、もう少し詳しく扱う。

誤解のないように説明しておくが、ジョン・ボイド氏やチェット・リチャーズは、ハード的なシステムとしてのループを十全に機能させるためのソフトな側面の重要性を説いている。
以下の左下図に示したマッキンゼーの7S²⁵は、四つのソフトの要素と、三つのハードの要素に分かれている。

例えば上右図のように戦略を大きく(上に引っ張って)変えた際、ハード的な構造やシステムは比較的簡単に変えることができるが、それを支えるソフトの要素を変えるのは難しいことを表現している。
本稿での議論は、ハード的な側面のシステムとしての類似性にだけに注目し、それ以外の側面は捨象していることを断っておく。

ReActのプロンプト

Search、Lookup、FinishツールをLLMが使うように仕向けるために、プロンプトに次の序文を追加する。

思考、行動、観察のステップを交互に繰り返す質問応答タスクを解いてください。思考は現在の状況について推論を行うことができ、行動には以下の3種類があります。
[3つのツールの説明]
[思考- 行動- 観察パターンのFew-shot]
[答えて欲しい質問(タスク)]

詳細が示されたJupyter Notebookが以下に公開されている。
https://github.com/ysymyth/ReAct/blob/master/hotpotqa.ipynb

論文掲載の例

質問: Apple Remote 以外に、Apple Remote が本来対話するように設計されたプログラムを制御できるデバイスはありますか?
          ------------------------------------------------------------------------------
思考1：Apple Remoteを検索して、本来操作対象としていたプログラムを見つける必要があります。
行動1：[Apple Remote]を検索する
観察1：Apple Remoteは、2005年10月にAppleが発表したリモコンで、本来はFront Rowメディアセンタープログラムを操作するように設計されていました。

思考2：Apple Remoteは元々、Front Rowメディアセンターのプログラムを制御するために設計されました。次にFront Rowを検索し、他にどのようなデバイスで制御できるか調べる必要があります。
行動2：[Front Row]を検索
観察2：[Front Row]は見つかりませんでした。類似キーワード：['Front Row Seat to Earth', 'Front Row Motorsports' , 'Front Row (software)', …]

思考3：Front Rawが見つかりません。Front Row（ソフトウェア）を検索する必要があります。
行動3：[Front Row（ソフトウェア）]を検索
観察3：Front Rowは販売終了したメディアセンターソフトウェアです…

思考4：Front Row（ソフトウェア）はApple Remoteかキーボードのファンクションキーで操作できます。つまり、答えはキーボードのファンクションキーです。
行動4：[キーボードのファンクションキー]で完了

本論文の中で、著者はReAct手法を単独で用いるのではなく、ReAct + CoT-SC で使用することで、最適なパフォーマンスを発揮すると述べている。

参考テキストを提供する

プロンプト中に参考テキスト（外部知識）を提供する「Incontext learning」を使うことで、AI の回答の正確性を上げることができる。

具体的には、プロンプトに続けて参考テキストを追記する。そうすればAIはそのテキストを加味したうえで、回答を生成する。

【プロンプト例】
以下の当社の経費精算規定に基づき、添付の領収書が精算可能かどうかを判断してください。
判断理由も簡潔に述べてください。

参考情報：当社の経費精算規定
第5条 旅費交通費
飛行機代：エコノミークラスに限る。出張先への移動時間が4時間を超える場合、ビジネスクラスを可とする。
宿泊費：1泊あたり上限15,000円（税抜）とする。

領収書データ
項目：飛行機代（東京→大阪）
領収金額：25,000円
備考：特になし
移動時間：2.5時間

参考情報の与え方の比較

特徴＼手法	初めから参考情報を与える (Pre-provided Context)	RAG (Retrieval Augmented Generation)	LLMが検索できる (例: ReActにおけるツール利用)
情報の提供方法	ユーザー/システムが、必要な情報を静的にプロンプトに記述。	外部の検索システムが、クエリに基づいて動的に情報を検索し、プロンプトに挿入。	LLM自身が「行動」として検索ツールを呼び出し、その結果を「観察」として受け取る。
アクセス可能な知識の範囲（内容）	LLMの内部知識＋プロンプト内の静的情報。提供できる情報量はコンテキストウィンドウに厳しく制限。	LLMの内部知識＋外部のドキュメントやデータベース内の情報。学習データにない企業内の非公開情報に動的にアクセスし、関連部分を抽出可能。コンテキスト制限を緩和しつつも、一度に渡せる量には限界がある。	LLMの内部知識＋事実上無限の外部情報源。特定のリアルタイムデータ、非公開のAPI情報に能動的にアクセス。必要な情報を逐次的に取得するため、一度にウィンドウに収める情報量は少なく、広範な知識にアクセス可能。
アクセス可能な知識の鮮度（時間軸）	プロンプト作成時の情報で固定。最新情報は扱えない。	検索システムが参照するデータベースに依存。比較的最新の公開情報に対応可能。	LLMが呼び出す検索ツール（例: Web検索）の能力に依存。最もリアルタイムな情報に対応可能。
情報の信頼性・ハルシネーション抑制	提供情報が正確かつ十分であればハルシネーションは抑制されるが、情報の不足やLLMの誤解釈によるリスクは残る。	外部のドキュメントやデータベースからの根拠情報が明確に提示されるため、ハルシネーションを大幅に抑制可能。ただし、参照元のデータストアの品質（正確性・最新性・網羅性）に回答の質が大きく依存する。	外部からの「観察」で推論を逐次検証するため、ハルシネーション抑制に有効。ただし、参照する情報源（Webサイト、APIなど）の品質に結果が大きく依存し、誤情報等を引き込むリスクがある。このため、呼び出しツール側での情報源の選定・キュレーションが極めて重要となる（例：ReAct論文のWikipedia限定）。
タスクの複雑性への対応	単純な質問応答、要約、特定の短い指示。	知識ベースからのQ&A、特定のドキュメントに基づく回答生成。	多段階の推論、探索的な問題解決、複雑な計画と実行、不確実性の高い環境。
自律性	なし。指示された情報のみを処理。	限定的。検索システムの判断に依存。	高い。情報取得のタイミングと内容を自律的に決定し、その結果に基づいて次の一手を考える。
人間の介入の必要性	プロンプトの完璧な設計と情報の事前準備が必要。	検索結果の評価や調整、参照対象となるドキュメントやデータベースの品質管理が必要な場合もある。	LLMが自律的に解決できない場合のデバッグや軌道修正、参照ツールの選定と信頼性管理が必要。
システム実装の複雑性	最もシンプル。	検索システムの構築・連携が必要。	ツール定義、アクションの実行環境、観察のフィードバックループなど、最も複雑。

LLM自体はコンテクストの記憶を持たないことに注意

LLM(モデルコア)から見れば、プロンプトウィンドウにあるテキストは、特に何か工夫がない限りは、その出所や取得プロセスに関わらず、すべて同じ「入力データ」として扱われ、区別はつかない。
どこから来た情報であろうと、すべて同じ「入力トークンのシーケンス」に過ぎない。

それがユーザーが直接タイプした指示であろうと、
RAGシステムが外部データベースから引っ張ってきてコンテキストに挿入したドキュメントであろうと、
ReActのエージェントがウェブ検索APIを呼び出して得た結果であろうと、
あるいはLLM自身が以前に生成した「思考」のテキストであろうと、
何の工夫もなければ、LLMの内部では、それらはすべて同じ重み付けで扱われる。

LLM自身が「これはユーザーが打った」「これはRAGの出力だ」「これはReActがウェブから取ってきた」といったメタ情報を区別するメカニズムは基本的に持っていないことを、忘れない方が良い。

「Less is More（少ない方が豊かである）」の原則

LLMに与える情報は、量の多さよりも質が重要で、「関連性が高く」「正確で」「簡潔に整理され」「LLMの既存知識と適切に連携する」ものであるべき。

いずれにしろ、与える情報は多ければ多いほど良いということはない。

他の手法の論文でも指摘されていることだが、ノイズになるものを増やせば結果は悪化する。
良かれと思ったものがノイズになることも多い。
特にモデルが正しくよく知っていることについては、その知識やスキルを引き出す工夫をすればよいのであって、下手な教え方をしない方が良い。
このことをそれを忘れてはならない。

求められるのはプロンプトよりもコンテキストエンジニアリング

Philipp Schmidは、『The New Skill in AI is Not Prompting, It's Context Engineering』https://www.philschmid.de/context-engineeringの中で、以下のことを主張している。

エージェントの台頭に伴い、「限られたワーキングメモリ」にどのような情報を読み込むかがますます重要になっています。

エージェントの成否を決定づける主な要因は、エージェントに与えるコンテキストの質であることが分かってきています。

エージェントの失敗の多くは、もはやモデルの失敗ではなく、コンテキストの失敗です。

コンテキストエンジニアリング
Philipp Schmid『The New Skill in AI is Not Prompting, It‘s Context Engineering』より

構成要素名	説明
指示／システムプロンプト	会話中のモデルの動作を定義する初期の一連の指示。例やルールなどを含めることができる／含めるべき。
ユーザープロンプト	ユーザーからの直接的なタスクや質問。
状態／履歴（短期記憶）	現在の会話、この瞬間に至るまでのユーザーとモデルの応答を含む。
長期記憶	過去の多くの会話から集められた持続的な知識ベース。学習したユーザーの好み、過去のプロジェクトの要約、または将来の使用のために記憶するように指示された事実を含む。
取得情報（RAG）	特定の質問に答えるための、外部からの最新知識、文書、データベース、またはAPIからの関連情報。
利用可能なツール	呼び出せるすべての機能や組み込みツールの定義（例：check_inventory、send_email）。
構造化された出力	モデルの応答形式の定義（例：JSONオブジェクト）。

参考）エンジニアでない人にChatGPTとLLMの違いを説明するには？

必要としない人に対して、この説明をこちらから無理にするのは止めておいた方が良い。
その一方、エンジニアとしての提案をステークホルダーに説明する際など、相手にこの違いを前提知識として理解しておいて欲しい場面は多々ある。
また、こちらがエンジニアだとわかると、いま旬の技術でもあるので興味本位で質問されることもある。
そのような場面で、筆者は概ね以下のような流れで、逆質問してから説明することにしている。そうすると途中で興味を失わずに最後まで聞いてくれる。

以下の疑問、持ちませんでしたか？
- 問1: ChatGPTやGeminiは、あなたとある程度継続的に会話してくれますよね。LLM(large language model)は、何人いるのでしょうか？
  - (質問の意図: 擬人化した理解をしている人は多いので)
- 問2: LLMとユーザーの数はどちらが多いと思いますか？
  - (質問の意図: 擬人化した人数分いるはずはない、と確認してもらうため)
- 問3: 複数人と同時に話せるなんて、LLMは聖徳太子のようですね。なぜそんな器用なことができるのか、考えてみたことがありますか？
  - (質問の意図: 何らかの工夫がなければ成立しないこと、その工夫は何か？、に興味を持ってもらう)
- 問4：運用時に学習しないって、長期記憶できないということですよね。ところで短期記憶はどうなってると思っていますか？
  - (質問の意図: ある時点までの情報以降の学習はしていないことは知っている人が多い。その確認をした上で本題に入る)
短期記憶の在り処
- コンテキストウィンドウ（Context Window）
  - ココをうまく使う方法をよく知ることが大事！
LLMは、映画『メメント』の主人公のような状態
- 映画『メメント』: 数分前の記憶を忘れてしまう前向性健忘の男が妻殺しの犯人を追う、クリストファー・ノーラン監督が贈る異色サスペンス。

コンテクスト(context)とコ・テクスト(co-text)

コンテクスト(context)とコ・テクスト(co-text)の区別・分類は、語用論・談話分析・言語教育などの分野で一般的かつ理論的に確立された手法である。

基本的な定義

用語	定義	例
コンテクスト（context）	言語表現が生起・解釈される状況全体。発話・文章を問わず、物理的・社会的・文化的・心理的な要因を含み、意味構築に影響を与える言外の背景を指す。	話し手と聞き手の関係、場所、目的、社会的慣習など
コ・テクスト（co-text）	ある表現の意味構築に影響を与える、同じ談話・テキスト・語りの流れの中にある他の言語表現。前後の文・発話・語り手の視点・登場人物の言動・語調・省略・暗示など、参照・推論される言語的・語用論的情報を含む。	前の発話「それは違うと思う」、後の発話「なぜなら…」

両者の分類と関係

分類軸	コンテクスト（Context）	コ・テクスト（Co-text）
対象	言語外の状況要因	言語内の周辺要素
分野	語用論、社会言語学、談話分析	文法、意味論、談話分析
例	話し手の意図、場面、関係性、文化的背景	前後の文、語彙の繰り返し、照応関係
役割	発話の解釈に影響を与える外的要因	発話の意味を構成する内的要因
応用	敬語使用、婉曲表現、発話機能の選択	指示語の解釈、意味の曖昧性の解消

なぜ分類するのか？
- 発話の意味は、言語的手がかり(co-text)と状況的手がかり(context)の両方によって構成される。
- 教育現場では、誤解の原因が co-text にあるのか context にあるのかを見極めることで、的確な指導ができる。

LLMに本来の意味でのコンテクストは存在し得ない。
正確には、記号接地問題が別途解決されていない限りにおいて、LLMに本来の意味でのコンテクストは存在し得ない。

LLMにとっては、表出化されてコンテキストウインドウに入っているものだけが意味解釈の対象になる。
コンテキストウインドウに入れるためには、それは必ず表出化されていなければならない。
コンテクストは必ず表出化される＝コ・テクストに分類される＝コ・テクスト化される

観点	従来の語用論的定義	LLMにおける実装的意味	コメント
コンテクスト（context）	言語外の状況・関係・背景	モデル外部にあるが、本来は参照されるべき情報	例：ユーザーの目的、社会的関係、制度的背景
コ・テクスト（co-text）	同じ談話・テキスト・語りの流れの中にある他の言語表現	コンテクストウインドウに入っている情報（＝モデルが直接処理可能）	例：プロンプト履歴、明示された指示、過去の発話

コンテキストウインドウに「入れるべきであったが入れ忘れたこと」が人間から見たコンテキストということになるが、LLMはその存在を知る術がない。
LLMにとっての「意味解釈の起点」は、常にコ・テクストであり、コンテクストは存在しない。
これは、「語用論的意味は、表出されない限り処理されない」というLLMの限界を示している。

LLMによるコンテクスト推測の限界とコ・テクスト化の必要性

LLMには、学習時に取り込まれた「広義のコンテクスト」が内在しているはずである。
しかし、それは膨大かつ多様であるため、その中のどれを選択すべきか、手掛かりが得られない限り相応しいものを推測することは難しい。

LLMは、学習時の知識から一般的な語用論的推測が、ある程度可能である。
- 例：「先生」という語が出れば教育文脈を想定可能

(広義・狭義の)コンテクスト vs. コ・テクストの関係整理

種類	内容	LLMにおける扱い	意味解釈への寄与
広義のコンテクスト（学習時）	世界知識、語用論的慣習、ジャンル特性、文化的背景など	パラメータに埋め込まれているが、非明示的	推測は可能だが、曖昧・不確定
狭義のコンテクスト（使用時）	ユーザーの目的、現在の話題、対話履歴など	明示されない限り、モデルは認識できない	明示されればコ・テクスト化され、意味解釈に直結
コ・テクスト	プロンプト内の言語的要素（履歴、指示、文脈）	モデルが直接処理する対象	意味構築の主素材

逆に言えば、設計者がコンテクストをコ・テクストとして明示的に埋め込むことが、意味の正確な構築に不可欠。
これは「プロンプト設計＝語用論的コンテクストのコ・テクスト化作業」と捉えることができる。

計画と解決プロンプト(Plan-and-Solve)

Wangらによるこの手法は、発表された論文¹⁵のタイトルにもあるように、Zoro-shot CoTにおける問題点に対処するために開発された手法なのであるが、もっと一般的にタスクを完遂させるのに役立つ。

最初にLLMに包括的な計画を立てることを促す。
つまり、以下の二つのステップで成り立っている。

計画の立案：問題を整理して全体のタスクをより小さなサブタスクに分割
計画の実行：立案された計画に従ってサブタスクを実行

計画と解決のプロンプトフレーズ

「Zero-shot CoT」で使われる「ステップごとに考えてください」というフレーズを、以下の「計画と解決プロプント」に置き換える。

まず、問題を理解し、問題を解決するための計画を立てましょう。
次に、その計画を実行し、段階的に問題を解決しましょう。

この手法は、特に数学の文章問題などの推論に有効であると報告されていて、下記のフレーズも利用することにより、生成される推論プロセスの質が向上する。

関連する変数とそれに対応する数値を抽出してください。

計算と常識に注意を払いながら中間結果を計算してください。

先にも述べたが、常識的推論や記号的推論、もっと一般的にさまざまな種類の問題やタスクに対しても多少の修正を加えれば使用でき、質の向上を期待できる。

Reflexion

先にメタ認知的(Metacognitive)手法の起源の1つと言えるWangらの研究を紹介したが、メタ認知というには不徹底であることについても述べた。そして、LLMがつぶやきながら(言語化しながら)考えるという条件付きで「他者に対するメタ認知が可能ならばLLMのメタ認知も可能なはず」と指摘した。当にそれをやってのけた研究²⁶がShinnらによってなされているので、ここで紹介する。

行動の計画と実行結果、その内省の結果を経験として記憶し、それを再利用することで、タスクの解決能力を向上させる。

タイトルのReflexionは、スペルミスではない。(容易にReflectionを想起するであろうことを狙っての命名であろう)

Reflexionの特徴と構成

ReflexionというAIの学習サイクルは、まるで人間が試行錯誤しながらスキルを身につけていくような手順を繰り返す。その手順は次頁に示すが、「行動する役」「評価する役」「反省する役」という3つの異なる役割をLLMが担いながら進んでいく。

自ら「反省」する:
- 失敗したときに、AI自身がその原因を分析し、言葉で教訓を導き出す。
経験が次に活かされる:
- この反省文が「長期記憶」として保存され、次の行動計画に直接影響を与えるため、AIは同じ失敗を繰り返さずに、徐々に賢くなっていく。
継続的な改善:
- 成功するまで、または限界まで、この「行動→評価→反省→行動」のサイクルを回し続けることで、AIのタスク解決能力が強化される。
Reflexionの手順
- 最初の試み：
  - 行動役（Actor） が、現在のタスクと（もしあれば）過去の反省点（長期記憶）を参考に、最初の行動計画を立て、実行する。行動生成にはCoTパターンやReActパターンが用いられる。
  - 行動は、自ら応答することも、またAPIコール（例えば、ウェブ検索やプログラムの実行など）をすることもあり、詳細な記録として「短期記憶（Trajectory）」に一時的に保存する。
- 結果の確認と反省の繰り返し：
  - 評価役（Evaluator） が、直前の「短期記憶」に保存された行動の結果をチェックし、成功か失敗かを判断、あるいは得点で評価され、もし失敗していたら、またはまだ改善の余地があると感じるなら、以下のステップを繰り返す。
    - 反省役（Self-Reflection） が、直前の「短期記憶」の内容と評価結果を見て、「何がうまくいかなかったのか？」「なぜ失敗したのか？」「次回はどうすれば成功できるのか？」を深く考え、その反省点を言葉（テキスト）で書き出す。
    - この書き出された反省点（「反省文」と呼ぶ）を、「長期記憶（Experience）」に追加して保存する。
    - 行動役が、更新された長期記憶（過去の反省点）と現在のタスクを参考に、新しい行動計画を立て、再び実行する。
    - この新しい行動と結果も「短期記憶」に保存され、再び評価役に渡される。
- 終了：
  - タスクが成功したと評価されるか、決められた試行回数に達したら、学習サイクルを終了する。

(参考) 人間の記憶分類の体系表

カテゴリ	下位分類	内容の特徴	代表例・用途	意識的か
長期記憶	宣言的記憶 (Explicit)	意識的に思い出せる事実・経験の記憶	歴史知識、体験談、ルール	✅ 意識的
｜	エピソード記憶	個人的体験・出来事の記憶	初めて旅行した日の記憶、卒業式など	✅
｜	意味記憶	一般的な知識・事実	「リンゴは果物」「日本の首都は東京」	✅
｜	自伝的記憶	自己に関連づけられた体験記憶	「小学生の頃いじめられた記憶」	✅
｜	非宣言的記憶 (Implicit)	無意識に働くスキル・感覚の記憶	スポーツ技能、反射、習慣	❌ 無意識的
｜	手続き記憶	行動のスキルや動作	自転車に乗る、楽器演奏、泳ぎ方	❌
｜	プライミング	過去の刺激が無意識に想起に影響	「りんご」を見た後に「果物」が出てきやすい	❌
⊥	古典的条件づけ	刺激と反応が結びつく学習	ベルで唾液を出すパブロフの犬	❌
補助的記憶	展望記憶	未来に行うべきことを覚える記憶	「明日の会議を覚えておく」	✅
｜	情動記憶	感情と結びついた記憶	怒り・恐怖・喜びが強く残る記憶	✅ または ❌
⊥	感覚記憶	一瞬の感覚情報の記憶	音・映像の「残像」「残響」など	❌ （非常に短時間）
短期記憶	作動記憶 (ワーキングメモリ)	一時的に情報を操作・保持する記憶	暗算、会話中の理解、文章の推論	✅

この表は、心理学・認知科学・神経科学などで使われる主要な記憶概念を横断的に整理したものである。

「経験（Experience）」と名付けられた長期記憶が「エピソード記憶」に、「軌跡（Trajectory）」と名付けられた短期記憶の方は、ワーキングメモリに相当するといって良いだろう。

Reflexion使用上の注意

少なくとも一つの計画実行の事後に反省し、次回に改善された計画を立てることになるので、取り返しのつかない間違いを犯してしまいかねない場面に適用すべきではない。

やり直しができる活用領域は、多々ある。

GitHub Copilotを生んだJohn Berryman、Albert Zieglerは、著書²⁷の中で次の例を示している。
- 一連の単体テストに合格するソフトウェアの作成。
- Reflexionを使うことで、任意のアプローチ(例えばReAct)を使ってソフトウェアの一部を作成し、作業が終了したら、単体テストを実行する。
- 単体テストに合格しなかったら、失敗メッセージをプロンプトに戻して、LLMは再試行し、次回は同じ間違いを犯さないようにできる。

Reflexion と「心の理論」

LLMが自身の過去の振る舞いを「反省」する仕掛けは、まるで他者の心の状態を推し測るようなものなので、「心の理論」に「似ている」、あるいは「そのように見える」。

しかしそれは「メタファー」でしかない。「心の理論」における「他者」とは、自分とは異なる独立した意識を持つ主体を指すのに、LLMは人間のような意識や心を獲得しているわけではないからだ。

一方、LLMが人間のユーザーの意図を「推測」する手法の研究も進んでおり、これは「心の理論」に「似ている」というよりは、理論を活用して「似たことができる」ようにすることで、UXを向上させることなどを目指している。

Reflexionのもう一つの解釈: Plan-and-Solve ＋ ReAct + α

ReActは、最初の入力を受け取ってそれを観察した後、すぐに「思考→行動→観察」の反復に入るが、その前にPlan-and-Solve手法で、最初にLLMに包括的な計画を立てさせるとよさそうだ。この発想は普通に出てくる。
Plan-and-Solve ＋ ReActの組み合わせは、このReflexionの研究の中に含まれている。
それだけではない。Reflexionの重要なポイントは、計画は最初に立てたままなわけではなく、失敗した状況から学び、反省を繰り返して見直すことである。
下図に示した通り、OODAループは、PDCAサイクルのCheckとActionを明示しない。(OODAループのActはPDCAサイクルのActionに対応するのではなく、Doに対応することに注意！)

(参考)OODAループとPDCAサイクル
- 「PDCAはいたるところで回っている」というなら、「OODAループは同じところで同じようにいたるところで回っている。」
  チェット・リチャーズはそう説明するだろう。
- OODAループとPDCAサイクルとを並べて比較する図が世にあふれているが、「同じ対象を異なる視点から捉えたモデル」として比較するなら、上図のように同心円として表現する方が理に適う。
- 特にOODAループはPDCAサイクルに対して次の点を重視するように促す。
  - 高速に回せ(逐次ではなく同時が望ましいことも多々あり)
  - 内省は確かに大事だが、もっとよく外部を観察しろ
  - 観察結果に基づいて柔軟にPlanを見直せ(いたるところPDCAでは、計画と内省に比重を置き過ぎ)
- どちらのフレームワークで考えるにせよ、戦略的にどこに重点を置くかを選択すべき、と解釈できる。

Reflexionは、OODAループによく似たReActに、PDCAサイクルのCheckとActionを復活させて接続したものと見做すことができる。
さらにその反省材料は、内部の観察だけではなく、外部の観察から得たものも重視する。
これはルーシー・A・サッチマン(Lucy Suchman)が著書『プランと状況的行為─人間- 機械コミュニケーションの可能性─』²⁸の中で繰り返し主張した教えでもある。

参考）サッチマンの見識を活かすことがなかったマイクロソフトのエージェント(Office Assistant)の行く末
- 「お前を消す方法」でお馴染み!?　Windows懐かしのOfficeイルカの現在
- Suchmanの主張

「私たちは一見，あらかじめプランを持っていて，そのプランに従って行為しているように考えるが，実際のところ，プランは，本来的にアドホックである行為に対して補完的なリソースでしかない」
「私たちの行為は避けがたく状況に埋め込まれていて，その状況は常に私たちのまわりで変化を続けており予測不能であることから，そもそも曖昧さを排したプランを立てることなどできない」

サブタスクに分割する

複雑なタスクの解決プロセス(How)は、小さなステップ(サブタスク)に分解してから実行すれば計画が立てやすく、間違いが少なく、途中での出来栄えの評価・確認や計画見直しもやり易い。
これはAIシステムに限った話ではなく、一般論として言えることである。

人間がタスクを分割してLLMに与える方法もあるし、LLMに分割を依頼することもできる。

いずれにしろ、最初に決めた計画通りで上手くいくとは考えないことが肝要である。
それは先にも、ルーシー・A・サッチマンが『プランと状況的行為』の中で明らかにした重要な示唆を引きながら説明した。

ここまで説明してきた様々な手法に、分割あるいは分解するという一般的方法論が採り入れられているので、何処かしら似通っていて、混乱しやすいかもしれない。

各手法に含まれる有効な部品を集めると、もう十分なのではないかと思えるほどに出揃ってきた感もあり、適用場面ごとに、総合的判断で必要な部品を選択して構成し直すという応用段階に既に入っているといって良いだろう。
実際それが可能なLangChainやDifyといったオーケストレーションの仕組みも整っている。
元の手法名との対応付けは、先行研究者へのリスペクトを示す意味合いを除くと、次第に必要がなくなり、多くの実務現場では忘れられていくことになるかもしれない。
そう予想しながらも、以下で少しだけ整理しておくことにする。

下表のように比較しておくと、CoTの思考を分解するという元々の発想が、ReActでは行動を分解するという目的に使われ、適用範囲が広がったと理解できる。
つまり、CoTはReActにいては「行動の前提としての思考」であり、それは単なる説明ではなく、行為の構文木（action tree）を形成する役割を果たす。

手法と分解の関係

手法	説明
CoT	問題を解くための思考のステップを言語化
タスク分解	問題を解くための行動のステップを構造化
ReAct	CoTを通じて、行動可能な単位にタスクを分割し、逐次実行する

思考と行動の違いは、単純な二項対立には収まらないが、よく使われる区別の枠組みは以下の通り：

思考と行動

概念	特徴	外部からの観察	哲学的視点
思考	内的過程。概念操作、意味づけ、推論など	観察不可（ただし言語・表情などの兆候はあり）	「志向性（intentionality）」＝対象に向かう意識の構造
行動	身体を通じた運動、発話、反応など	観察可能	「意味づけられた運動」や「意志の可視化」と捉えられる

メタ認知のためには「思考」を「行動」に移す必要

つぶやきながら思考する人は「行動している」のか？
- その人は「思考」を外在化させながら展開している。
  - 身体的行動（発話・声帯の運動） が伴っている
  - 認知過程を意図的に環境に開示している（誰かに聞かせるつもりでなくても）

こうした行為は、単なる「思考」ではなく「思考を伴う行動」とも捉えられる。

ヴィトゲンシュタインなら次のようにいうのではないか。:

つぶやきのない思考は、外部の社会的文脈に接続されていないため、「言語ゲーム」に参加しているとは言えない
つぶやきがあるときは、思考が外部化され、聞く人がいなくとも、それが「使用される文脈」に所属する可能性を持つ

つまり、つぶやくことで「ルールのある場」に入るという意味で、言語ゲームが始まる。

LLMであれ、人間であれ、メタ認知のためには思考をつぶやいてもらう必要があることを勘案すると、むしろ思考なのか行動なのかという区別に拘る必要はないといって良いだろう。

「思考」と「行動」に関係する注意！

前節で、本稿が説明しているようなプロンプト設計の文脈で「思考」と「行動」を区別することにあまり意味はないと述べた。
それは概念のレベルの話である。

一方で、「Thought」という用語はReActの実装上の慣習に関係する

ReActの代表的なプロンプト設計では、以下のような構造が使われる：

Question: What is the capital of France?
Thought: I know that Paris is the capital of France.
Action: Lookup[France]
Observation: Paris
Answer: Paris

このように、ReActでは「Thought」というラベルが明示的に使われており、プロンプトの構文要素として定着している。
つまり、「Thought」はReActにおいては形式的なスロット名であり、単なる説明語ではなく、制御のための構文的役割を持つ記号になっていることに注意を要する。

「Thought」と「Reasoning」の違い：語感と機能の差

用語	意味合い	ReActにおける役割	なぜ使うか
Thought	思考の断片、内言、メモ的記述	LLMが次の行動を決めるための中間的な自然言語ステップ	実際のReActプロンプトで使われている語。形式的に定着している
Reasoning	論理的推論、体系的な思考過程	Thoughtの背後にある認知的プロセス全体	抽象的すぎて、ReActの逐次的な構造を直接表さない

表現の工夫（誤解を招かないために）

否定文は避けて、できるだけ肯定文で表現すると良い

【悪い例】専門用語を使わないようにしてください。難しい言葉は避けてください。
【良い例】初心者にも分かるように、専門用語は可能な限り平易な言葉に置き換えて説明してください。もし置き換えによって説明の簡潔さが失われてしまう場合は、専門用語を使いつつ、その用語の簡単な定義を添えてください。

【理由】なぜ、肯定文の方が良いのか？

LLMの基本原理は、次に「何が続くべきか」を予測する仕組み。膨大な選択肢の中から選ぶべきものを絞り込むような情報があるのが良い。
「○○しないで」という表現は、LLMを何処にも導かない。つまり、LLMにとっては次に何を出力すべきかの指針になりにくいのである。モデルは確率的に次の語を予測するだけなので、禁止された選択肢を除外した選択をしない。また禁止された選択肢であるとわかったところで、一度選んでしまったら、構造的に「後戻り」して選び直すことはできない。結果として、それを捨てるしかないが、それよりも問題なのは禁止命令を無視する可能性があるということである。

禁止事項を伝えたい場合、その禁止状態に対する予防策として、別の選択肢への誘導を同時に与えておくと良い

【悪い例】事実に反する内容は含めないでください
【良い例】事実として確認できる内容に基づいて答えてください。誤情報や未確認の内容は含めないでください。

上記した通り、LLMは禁止命令を無視する可能性があるので、禁止の仕組みはLLMの外側に設置すべきである。

二重否定表現は意味が曖昧になりやすく、誤解を招く可能性があるため、避けるのが望ましい。

そして、(マルチ)エージェント型AIへ・・・

本稿は、これで終わります。

注釈および参考文献

Tom B. Brown and others, 「Language Models are Few-Shot Learners」,https://doi.org/10.48550/arXiv.2005.14165 ↩
アントン・チェーホフ本人の言葉「もし、第1幕から壁に拳銃をかけておくのなら、第2幕にはそれが発砲されるべきである。そうでないなら、そこに置いてはいけない。」に由来する。 ↩
M.A.K. Halliday『An Introduction to Functional Grammar』 Routledge ↩
佐野大樹『生成ＡＩスキルとしての言語学』かんき出版 ↩ ↩² ↩³
クジラ飛行机『大規模言語モデルを使いこなすためのプロンプトエンジニアリングの教科書』マイナビ出版 ↩ ↩² ↩³ ↩⁴ ↩⁵
Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, Denny Zhou, 「Chain-of-Thought Prompting Elicits Reasoning in Large Language Models」, https://arxiv.org/abs/2201.11903 ↩
Takeshi Kojima, Shixiang Shane Gu, Machel Reid, Yutaka Matsuo, Yusuke Iwasawa, 「Large Language Models are Zero-Shot Reasoners」（arXiv.2205.11916／2022）https://doi.org/10.48550/arXiv.2205.11916 ↩
Yongchao Zhou, Andrei Ioan Muresanu, Ziwen Han, Keiran Paster, Silviu Pitis, Harris Chan, Jimmy Ba, 「Large Language Models Are Human-Level Prompt Engineers」, https://arxiv.org/abs/2211.01910 ↩
Cheng Li, Jindong Wang, Yixuan Zhang, Kaijie Zhu, Wenxin Hou, Jianxun Lian, Fang Luo, Qiang Yang, Xing Xie, 「Large Language Models Understand and Can be Enhanced by Emotional Stimuli」, https://arxiv.org/abs/2307.11760 ↩
Jiacheng Liu, Alisa Liu, Ximing Lu, Sean Welleck, Peter West, Ronan Le Bras, Yejin Choi, Hannaneh Hajishirzi. 「Generated Knowledge Prompting for Commonsense Reasoning」,
https://arxiv.org/abs/2110.08387 ↩
小型の補助モデル（例：T5¹²など）で、入力に応じて適切なヒント（stimulus prompt）を自動生成する ↩
T5（Text-to-Text Transfer Transformer）: Transformerファミリーの中で、エンコーダー・デコーダー型のアーキテクチャを採用し、全ての自然言語処理（NLP）タスクを「テキストからテキストへの変換」として統一的に扱うことを目的としたモデル ↩
Huaixiu Steven Zheng, Swaroop Mishra, Xinyun Chen, Heng-Tze Cheng, Ed H. Chi, Quoc V Le, Denny Zhou, 「Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models」, https://doi.org/10.48550/arXiv.2310.06117 ↩
岡瑞起, 橋本康弘著『AI時代の質問力プロンプトリテラシー「問い」と「指示」が生成AIの可能性を最大限に引き出す』翔泳社 ↩
Xuezhi Wang, Jason Wei, Dale Schuurmans, Quoc Le, Ed Chi, Sharan Narang, Aakanksha Chowdhery, Denny Zhou, 「Self-Consistency Improves Chain of Thought Reasoning in Language Models」, https://arxiv.org/abs/2203.11171 ↩ ↩² ↩³
Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Thomas L. Griffiths, Yuan Cao, Karthik Narasimhan, 「Tree of Thoughts: Deliberate Problem Solving with Large Language Models」, https://arxiv.org/abs/2305.10601 ↩ ↩²
Jieyi Long, 「Large Language Model Guided Tree-of-Thought」, https://arxiv.org/abs/2305.08291 ↩ ↩²
森重真純『AIとコミュニケーションする技術プロンプティング・スキルの基礎と実践』インプレス ↩
苫米地英人, 「ディベートで超論理思考を手に入れる」, サイゾー ↩
Dave Hulbert, 「Using Tree-of-Thought Prompting to boost ChatGPT's reasoning」,https://github.com/dave1010/tree-of-thought-prompting ↩
Dongfu Jiang, Xiang Ren, Bill Yuchen Lin, 「LLM-Blender: Ensembling Large Language Models with Pairwise Ranking and Generative Fusion」, https://doi.org/10.48550/arXiv.2306.02561 ↩
Swarnadeep Saha, Omer Levy, Asli Celikyilmaz, Mohit Bansal, Jason Weston, Xian Li, 「Branch-Solve-Merge Improves Large Language Model Evaluation and Generation」, https://arxiv.org/abs/2310.15123 ↩
Shehzaad Dhuliawala, Mojtaba Komeili, Jing Xu, Roberta Raileanu, Xian Li, Asli Celikyilmaz, Jason Weston, 「Chain-of-Verification Reduces Hallucination in Large Language Models」, https://doi.org/10.48550/arXiv.2309.11495 ↩
チェットリチャーズ (著), 原田勉 (翻訳), 「ＯＯＤＡ　ＬＯＯＰ（ウーダループ）―次世代の最強組織に進化する意思決定スキル」, 東洋経済新報社 ↩
リチャード・T・パスカル、アンソニー・G・エイソス, 深田祐介訳, 『ジャパニーズ・マネジメント』. 講談社 ↩
Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao, 「Reflexion: Language Agents with Verbal Reinforcement Learning」, https://arxiv.org/abs/2303.11366 ↩
John Berryman、Albert Ziegler 著、服部佑樹、佐藤直生訳『LLMのプロンプトエンジニアリング―GitHub Copilotを生んだ開発者が教える生成AIアプリケーション開発』オライリー・ジャパン ↩
ルーシー・A・サッチマン著，佐伯　胖監訳，上野直樹，水川喜文，鈴木栄幸訳. 「プランと状況的行為─人間- 機械コミュニケーションの可能性─」, 産業図書（株）（1999） ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

言葉の様式の選択肢	説明
文体・スタイル：「話し言葉らしい」「ですます調」など	スタイルの選択によって、文末表現だったり、敬語の使用の有無だったり、会話や文章のトーンが変わる。話し言葉らしいか、書き言葉らしいかこれは音声を使うか、文字を使うかとは独立している(漫画のセリフを考えてみれば良い) 「フォーマル」か「カジュアル」か（レベルもいろいろ）「丁寧体」か「普通体」か「ですます調」か「である調」か
形式：「箇条書き」「表」など	表、箇条書き、リスト、番号付きリスト、タイムライン（年表やスケジュール）などさまざまある
媒体：「新聞」「ブログ」「書籍」など	新聞、雑誌、チャット、電話、書籍、講演など、どの媒体が使われるかも、言葉の選択に影響する。語彙や会話・文章の構成も変わる。多くの場合、文字数の制限もある。同じ主張する文を書くときにも、新聞に載せることを前提とした場合と、チャットで伝えるのを前提とした場合とでは、書き方が大きく変わる。媒体の種類新聞、雑誌、書籍などの「印刷媒体」、テレビやラジオなどの「放送媒体」、ウェブページやＳＮＳなどの「デジタルメディア」、電車の広告などの「アウトドアメディア」などさまざま
ジャンル：「物語」「報告書」「論説文」など	物語、報告文、説明文、論説文、事務文書などがある。それぞれのジャンルには、特有の言葉の選択の仕方と構造があると考えられている。日本語の論説文（何かを主張するための文章）では、読み手が文章を読み終えたときに、書き手の主張を共有してもらえるように、最初から主張を提示するのでなく、論拠となる出来事を積み上げて、最終的に読み手が書き手の主張にたどり着くように、工夫してテキストを構成するような場合もある。

6W2Hで体系化し直した生成AI(LLM)のプロンプトの書き方：初級者からプロまで！ 覚え易く、高品質、指定し忘れにくく、人に説明し易い