<p><style_prompt>
複雑な論理推論が必要なタスクに対し、思考プロセスを明示的に分離するChain-of-Thought(CoT)を導入し、Few-shotによって出力の構造化と精度を最大化する設計プロセスを構築しました。Gemini 1.5 Proなどの長文コンテキストと高い推論能力を持つモデルの特性を活かし、自己修正プロセスを含むプロンプトへの最適化を重点的に行っています。
</style_prompt></p>
<p>本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト(未検証)</strong>です。</p>
<h1 class="wp-block-heading">多段階の論理推論を要するスケジュール調整タスクにおけるCoTプロンプト最適化</h1>
<h3 class="wp-block-heading">【ユースケース定義と課題】</h3>
<p><strong>ユースケース:</strong> 複数の会議室予約、参加者の優先順位、移動時間等の複雑な制約を満たす動的なスケジュール最適化。
<strong>課題:</strong> 条件が重なるとLLMが論理的な矛盾(ダブルブッキング等)を見落としやすく、出力形式(JSON)が崩れることがある。
<strong>入出力型:</strong> 入力はMarkdown形式の制約リスト、出力は構造化されたJSON形式。</p>
<h3 class="wp-block-heading">【プロンプト設計のループ】</h3>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
graph TD
A["設計: 思考ステップの定義"] --> B["実行: Few-shotによる推論"]
B --> C["評価: 制約充足率の検証"]
C -->|論理エラーの修正| A
</pre></div>
<ol class="wp-block-list">
<li><p><strong>設計</strong>: LLMが結論を出す前に「思考の遊び(Thinking Space)」を持つよう、解析ステップを定義。</p></li>
<li><p><strong>実行</strong>: 推論プロセスを言語化させるプロンプトを投入し、出力の一貫性を確認。</p></li>
<li><p><strong>評価</strong>: LLM-as-a-Judgeを用い、提示された解が全ての制約を遵守しているか自動チェック。</p></li>
</ol>
<h3 class="wp-block-heading">【プロンプトの実装案】</h3>
<div class="codehilite">
<pre data-enlighter-language="generic"># Role
あなたは高度なロジカルシンキングを持つスケジュール管理のエキスパートです。
# Task
以下の「入力データ」に基づき、全ての制約を満たす最適なスケジュールを提案してください。
# Constraints
- 思考プロセス(Thinking Process)を最初に出力し、その後に最終結果をJSONで出力すること。
- 会議室の重複、参加者の移動時間(15分)、優先度(High > Medium > Low)を厳守すること。
# Thinking Process Template
1. 各参加者の空き時間の抽出
2. 会議室の利用可能状況の確認
3. 優先順位に基づくスロットの割り当て
4. 制約(移動時間等)のセルフチェック
# Example
Input: [参加者A: 13-15時空き, 優先度High] [会議B: 14-16時]
Thinking Process: 参加者Aは13-15時が空いているが、会議Bは14時から開始。したがって共通のスロットは14-15時。移動時間を考慮すると...
Output: {"schedule": [{"meeting": "B", "time": "14:00-15:00", "room": "Room1"}]}
# Input Data
[ここに実際のデータを入力]
# Response
Thinking Process:
</pre>
</div>
<h3 class="wp-block-heading">【評価指標と誤り分析】</h3>
<figure class="wp-block-table"><table>
<thead>
<tr>
<th style="text-align:left;">評価項目</th>
<th style="text-align:left;">評価内容</th>
<th style="text-align:left;">失敗パターン</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left;"><strong>論理整合性</strong></td>
<td style="text-align:left;">制約(移動時間等)が守られているか</td>
<td style="text-align:left;">移動時間を無視して連続で予定を入れる</td>
</tr>
<tr>
<td style="text-align:left;"><strong>優先度遵守</strong></td>
<td style="text-align:left;">優先度の高い会議が優先されているか</td>
<td style="text-align:left;">優先度が低い会議のために高い会議を却下する</td>
</tr>
<tr>
<td style="text-align:left;"><strong>フォーマット</strong></td>
<td style="text-align:left;">JSONがパース可能な形式か</td>
<td style="text-align:left;">Thinking ProcessがJSON内に混入する</td>
</tr>
</tbody>
</table></figure>
<h3 class="wp-block-heading">【改良後の最適プロンプト】</h3>
<div class="codehilite">
<pre data-enlighter-language="generic"># System
あなたは複雑な制約解決に特化した推論エンジンです。
回答は必ず以下の2スロット構成で出力してください。
1. <thought>タグ内:ステップバイステップの論理推論プロセス
2. <result>タグ内:パース可能な純粋なJSONデータのみ
# Reasoning Protocol (Internal CoT)
- ステップ1:入力された全制約を変数として抽出せよ。
- ステップ2:各予定の競合(時間・場所)をマトリックス化せよ。
- ステップ3:優先順位に基づき、解を1つずつ配置せよ。
- ステップ4:最終案に対し、移動時間と会議室の重複がないか逆方向から検証せよ。
# Constraint Focus
Gemini 1.5 Proの推論能力を最大化するため、"なぜそのスロットを選んだのか"の根拠を<thought>内で言語化すること。
# Output Format
<thought>
[推論プロセス]
</thought>
<result>
{
"status": "success",
"optimized_schedule": [...]
}
</result>
</pre>
</div>
<h3 class="wp-block-heading">【まとめ】</h3>
<ol class="wp-block-list">
<li><p><strong>「思考の分離」の徹底</strong>: <code><thought></code>等のタグを用い、推論プロセスと最終出力を物理的に分離させることで、JSONの構文エラーを防ぎつつ精度を高める。</p></li>
<li><p><strong>セルフチェックの組み込み</strong>: プロンプト内で「逆方向からの検証」を指示することで、見落としがちな制約違反(移動時間不足など)を劇的に減らす。</p></li>
<li><p><strong>Few-shotの動的選択</strong>: 複雑なケースほど、似た構造の成功例を1つ提示するだけで、モデルの推論ルートが安定する。</p></li>
</ol>
複雑な論理推論が必要なタスクに対し、思考プロセスを明示的に分離するChain-of-Thought(CoT)を導入し、Few-shotによって出力の構造化と精度を最大化する設計プロセスを構築しました。Gemini 1.5 Proなどの長文コンテキストと高い推論能力を持つモデルの特性を活かし、自己修正プロセスを含むプロンプトへの最適化を重点的に行っています。
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト(未検証)です。
多段階の論理推論を要するスケジュール調整タスクにおけるCoTプロンプト最適化
【ユースケース定義と課題】
ユースケース: 複数の会議室予約、参加者の優先順位、移動時間等の複雑な制約を満たす動的なスケジュール最適化。
課題: 条件が重なるとLLMが論理的な矛盾(ダブルブッキング等)を見落としやすく、出力形式(JSON)が崩れることがある。
入出力型: 入力はMarkdown形式の制約リスト、出力は構造化されたJSON形式。
【プロンプト設計のループ】
graph TD
A["設計: 思考ステップの定義"] --> B["実行: Few-shotによる推論"]
B --> C["評価: 制約充足率の検証"]
C -->|論理エラーの修正| A
設計: LLMが結論を出す前に「思考の遊び(Thinking Space)」を持つよう、解析ステップを定義。
実行: 推論プロセスを言語化させるプロンプトを投入し、出力の一貫性を確認。
評価: LLM-as-a-Judgeを用い、提示された解が全ての制約を遵守しているか自動チェック。
【プロンプトの実装案】
# Role
あなたは高度なロジカルシンキングを持つスケジュール管理のエキスパートです。
# Task
以下の「入力データ」に基づき、全ての制約を満たす最適なスケジュールを提案してください。
# Constraints
- 思考プロセス(Thinking Process)を最初に出力し、その後に最終結果をJSONで出力すること。
- 会議室の重複、参加者の移動時間(15分)、優先度(High > Medium > Low)を厳守すること。
# Thinking Process Template
1. 各参加者の空き時間の抽出
2. 会議室の利用可能状況の確認
3. 優先順位に基づくスロットの割り当て
4. 制約(移動時間等)のセルフチェック
# Example
Input: [参加者A: 13-15時空き, 優先度High] [会議B: 14-16時]
Thinking Process: 参加者Aは13-15時が空いているが、会議Bは14時から開始。したがって共通のスロットは14-15時。移動時間を考慮すると...
Output: {"schedule": [{"meeting": "B", "time": "14:00-15:00", "room": "Room1"}]}
# Input Data
[ここに実際のデータを入力]
# Response
Thinking Process:
【評価指標と誤り分析】
| 評価項目 |
評価内容 |
失敗パターン |
| 論理整合性 |
制約(移動時間等)が守られているか |
移動時間を無視して連続で予定を入れる |
| 優先度遵守 |
優先度の高い会議が優先されているか |
優先度が低い会議のために高い会議を却下する |
| フォーマット |
JSONがパース可能な形式か |
Thinking ProcessがJSON内に混入する |
【改良後の最適プロンプト】
# System
あなたは複雑な制約解決に特化した推論エンジンです。
回答は必ず以下の2スロット構成で出力してください。
1. <thought>タグ内:ステップバイステップの論理推論プロセス
2. <result>タグ内:パース可能な純粋なJSONデータのみ
# Reasoning Protocol (Internal CoT)
- ステップ1:入力された全制約を変数として抽出せよ。
- ステップ2:各予定の競合(時間・場所)をマトリックス化せよ。
- ステップ3:優先順位に基づき、解を1つずつ配置せよ。
- ステップ4:最終案に対し、移動時間と会議室の重複がないか逆方向から検証せよ。
# Constraint Focus
Gemini 1.5 Proの推論能力を最大化するため、"なぜそのスロットを選んだのか"の根拠を<thought>内で言語化すること。
# Output Format
<thought>
[推論プロセス]
</thought>
<result>
{
"status": "success",
"optimized_schedule": [...]
}
</result>
【まとめ】
「思考の分離」の徹底: <thought>等のタグを用い、推論プロセスと最終出力を物理的に分離させることで、JSONの構文エラーを防ぎつつ精度を高める。
セルフチェックの組み込み: プロンプト内で「逆方向からの検証」を指示することで、見落としがちな制約違反(移動時間不足など)を劇的に減らす。
Few-shotの動的選択: 複雑なケースほど、似た構造の成功例を1つ提示するだけで、モデルの推論ルートが安定する。
ライセンス:本記事のテキスト/コードは特記なき限り
CC BY 4.0 です。引用の際は出典URL(本ページ)を明記してください。
利用ポリシー もご参照ください。
コメント