生成AIを「文章をそれっぽく作る」だけでなく、複雑な判断・計画・検証まで任せるケースが増えてきました。
前回（第1回）では、OpenAI公式のプロンプトエンジニアリングガイドをもとに、プロンプトを「お願い」ではなく作業依頼書（＝指示書＋材料）として設計する基本を整理しました。
今回はその続きとして、同じOpenAI公式ドキュメントの中でも Reasoning best practices をベースに、推論（reasoning）モデルをうまく使うポイントをまとめます。
結論から言うと、推論モデルはテクニックを駆使するより、目的・制約・成功条件を正しく渡す設計のほうが効果的です。
なお、2026年現在の GPT-5シリーズ は、いわゆる「純粋な推論モデル」ではなく、
推論能力を内包したハイブリッド型モデルという立ち位置にあります。
GPT-5は、従来のoシリーズのように「思考・判断・検証」に特化した設計ではありませんが、
thinking（推論）モードを使うことで、
- 条件整理
- 軽〜中程度の計画立案
- 複数案の比較・妥当性チェック
といったoシリーズの特徴を明示的に設定できます。
本記事で扱う Reasoning best practices は、
最も相性が良いのは oシリーズですが、
GPT-5シリーズを使う場合でも「考えさせ方の設計指針」としてそのまま有効です。
目次
推論モデルとGPTモデルは“得意技”が違う
第1回で扱ったのは、いわゆる「文章生成が得意なモデル」を安定運用するための基本でした。
一方で推論モデルは、文章を整えるより先に、状況整理・判断・計画・検証といった「考える」工程で強みが出ます。
公式ドキュメントの整理をざっくり言うと、モデルにはそれぞれ「役割」があります。
- 推論モデル：状況整理、複数条件の両立、計画立案、検証など“考える”用途に向く
- （一般的な）生成モデル：文章化、要約、整形、アイデア出しなど“作業する”用途に向く
つまり、第1回の「指示書＋材料」という考え方を土台にしつつ、
- 推論モデルで「方針・手順・注意点・評価基準」を固める
- 生成モデルで「文章化・体裁整形・言い回し調整」を回す
という分業が効果的です。
推論モデルが有効な7つのパターン
推論モデルが強いのは、答えを出す前に、整理や判断が必要なタスクです。
- 曖昧な依頼の整理：論点整理、前提確認、抜け漏れ洗い出し
- 大量テキストから要点抽出：必要な箇所だけ拾ってまとめる
- 複数資料の関係性・ニュアンス推定：資料横断で整合性を取る
- 多段の計画：タスク分解→手順化→リスク想定
- 視覚推論：図表や読み取りづらい画像を含む理解
- コードのレビュー／品質改善：意図を汲んで改善点を提案
- 評価・検証：条件を満たしているかの点検、矛盾検出
“推論モデル向け”プロンプトの鉄則
第1回では、精度が欲しいときに「思考の型を渡す（手順を指定する）」話も出しました。
ただし推論モデルでは、そこを詳しく書くよりも、目的と制約を正しく渡すほうが安定する、というのが公式の趣旨です。
（＝考え方を誘導するより、設計条件を渡して任せる）
1) プロンプトは短く、率直に
長い指示で縛るより、簡潔・明確に目的を伝えたほうがブレにくいです。
特に推論モデルは、過剰な手順や装飾があると「何を達成すべきか」がぼやけやすいです。
2) 「ステップバイステップで考えて」は基本いらない
推論モデルは内部で考える前提なので、毎回「順に考えて」と促すより、
何を達成したいかと制約を明確にするほうが効きます。
※ここは第1回とのつながりで補足すると、
- 一般的な生成モデル：手順指定が効く場面が多い（ブレを抑える）
- 推論モデル：手順の押し付けよりも目的・制約・成功条件が重要
という住み分けのイメージです。
3) 区切り（デリミタ）で入力の構造を渡す
ここは第1回の学びがそのまま効きます。
材料・条件・出力形式を、見出しやタグで分けて書くと解釈が安定します。
例：
## 目的## 前提## 制約## 出力形式
4) まずはゼロショット、ダメなら少数例
最初から例を盛りすぎず、まずはゼロショットで試し、必要になったら最小限の例を追加するのがやりやすいです。
（第1回のFew-shotと同じ考え方ですが、推論モデルでは例の盛りすぎが逆効果になることもあるので、少なめスタート推奨されています。）
5) 制約条件と成功条件を具体化する
推論モデルに任せれば任せるほど条件は増えがちです。だからこそ、
- 制約：期限、予算、対象範囲、禁止事項、トーン
- 成功条件：何が満たされれば合格か（チェック項目）
を明確に書くのが効果的です。
「何をやるか」より「何ができていれば成功か」を先に固定すると、推論のブレが減ります。
コピペで使える：推論モデル用プロンプトテンプレ
テンプレ1：曖昧タスクを要件化→実行計画まで
以下をそのまま貼り付けて項目を埋めるだけで、依頼の解像度が上がります。
- 目的：
- 背景：
- 前提（分かっていること）：
- 不明点（分からないこと）：
- 制約（期限／予算／対象／禁止事項）：
- 成功条件（満たすべきチェック）：
- 出力形式（例：箇条書き、章立て、表）：
- 補足：不足情報があれば確認質問してよい
テンプレ2：大量テキストから“必要な根拠だけ”抜く
調査や仕様読み込みで強い型です。
- 資料：＜本文を貼る＞
- 知りたいこと：＜質問を書く＞
-
抽出ルール：
- 該当箇所のみ抽出
- 推測はしない
- 不明は不明と明記
- 可能なら引用（短め）＋要約
実際に指示してみる
テンプレート1のプロンプト例を用いて指示を出してみました。
テーマ：新規システム導入の進め方
モデル：ChatGPT5.2 Thinking
Before
インプット
社内に新しい業務システムを導入するにあたり、進め方の全体像を整理したいと考えています。現在はExcelやメールを中心とした業務フローで運用しており、手作業が多く業務が属人化している状況です。また、ITに詳しくない関係者も多くいます。利用部門は営業部と管理部で、利用人数は約30名、クラウドサービスの利用は可能です。制約としては、3か月以内に本稼働を開始したいこと、可能な限りSaaSを活用したいこと、大規模なスクラッチ開発は避けたいことが挙げられます。成功条件は、導入までのステップが明確になっていること、各ステップで実施すべき内容と注意点が整理されていること、不明点や事前に確認すべき事項が洗い出されていることです。
アウトプット
以下、「3か月で本稼働」「SaaS優先」「スクラッチ回避」「ITに詳しくない人が多い」「営業＋管理で約30名」を前提にした、導入の進め方“全体像（ロードマップ）”です。
そのまま社内説明資料の骨子としても使える粒度にしています。
---
## 0. まず決める全体方針（最初の3日で固める）
**目的**：後戻りを防ぎ、3か月を成立させる前提を揃える
* **導入方式**：SaaS（標準機能＋設定）＋必要最小限の連携（iPaaS/CSV）
* **スコープの考え方**：
* **Must（初回リリース必須）**＝“現行Excel/メールで回ってる最小セットを置き換える”
* **Nice（2段階目）**＝分析/高度な自動化/例外処理の拡充
* **体制**：
* 業務責任者（営業/管理から各1名）
* 業務代表（現場のキーマン2〜4名）
* IT（あなた）＝推進/設計/ベンダ窓口
* 決裁者＝スコープ・費用・運用方針の最終判断
* **成功基準（KPI）**例：
* 手作業削減（入力二重化ゼロ、メール依頼ゼロ化など）
* 属人化解消（担当交代しても回る、手順書、権限設計）
* 定着（稼働2週間後の利用率、問い合わせ件数など）
**注意点**：3か月では「業務改革全部」は無理。**“稼働させる範囲”を早く決める**のが最重要。
---
## 1. 現状把握（As-Is）と課題の見える化（1〜2週）
**成果物**：業務一覧、フロー、課題、要件のたたき台
### 実施内容
* 対象業務を棚卸し（営業・管理で各5〜10業務程度に分解）
* Excel/メールのやり取りを含めて、以下を記録
* 入力元（誰が、何を、いつ、どこに）
* 承認・確認の流れ（誰がOKを出すか）
* 例外（イレギュラーの種類と頻度）
* 月次・締め、監査・証跡の必要性
* “困っていること”を定量化（時間、回数、差し戻し件数）
### 注意点
* ITに詳しくない人が多い場合、**「画面」ではなく「作業」ベースで聞く**
* 「このメールが来たら次に何をしますか？」で掘る
* Excelファイルは、**実物を回収して版数・マクロ有無・入力規則**を確認
---
## 2. To-Be（あるべき姿）と最小スコープ確定（2週目）
**成果物**：To-Beフロー、業務要件、優先順位、初回リリース範囲
### 実施内容
* To-Beフローを作る（できるだけシンプルに）
* 要件をカテゴリ分け
* **入力**：フォーム/取込/必須項目/添付
* **処理**：自動採番、通知、承認、ステータス管理
* **出力**：台帳、一覧、検索、CSV、帳票
* **権限**：部門別、役職別、閲覧制限
* **監査/証跡**：更新履歴、承認ログ
* “Must/Nice”で仕分けし、初回リリースを確定
### 注意点
* 「現行Excelの全項目をそのまま」はやらない
→ **使われていない列**が必ずあるので削る（短期導入の鍵）
---
## 3. 製品選定（SaaS比較）と意思決定（2〜3週目）
**成果物**：比較表、候補絞り込み、採用サービス決定
### 実施内容（SaaS優先・スクラッチ回避）
* 候補タイプ（例）
* **業務アプリ/ワークフロー系**（申請・承認・台帳）
* **CRM/SFA系**（営業案件中心なら）
* **経費/請求/購買などの専用SaaS**（管理部中心なら）
* 連携はiPaaS（必要なら）で最小化
* 比較軸（30名規模で失敗しにくい軸）
* 必須要件充足（Must）
* 画面の分かりやすさ（非IT向け）
* 権限/監査ログ
* データ移行しやすさ（CSV、API）
* 通知（メール/Teams等）
* 管理運用のしやすさ（設定変更の容易さ）
* 料金（初期/月額/オプション）
* **短期導入の推奨手順**
* 2〜3候補に絞る → ベンダに要件を渡してデモ → トライアルで検証 → 決定
### 注意点
* 「カスタマイズ前提」の提案は、3か月案件ではリスクが高い
→ **標準機能でMustが満たせるか**に寄せる
---
## 4. 導入設計（設定・権限・マスタ・運用）（4〜6週目）
**成果物**：設定仕様、権限設計、マスタ定義、運用ルール
### 実施内容
* 画面/項目/ステータス/承認経路の設計
* マスタ設計（取引先、商品、部門、担当者など）
* 権限（閲覧/編集/承認/管理）をロールで定義
* 通知設計（誰に、どのタイミングで、何を送るか）
* 例外処理の設計（戻し、取消、差し戻し）
* 運用設計
* マスタ更新は誰がいつやる？
* 問い合わせ窓口と一次対応の切り分け
* 障害時の代替（紙/Excelに戻す手順）
### 注意点
* “現場が勝手に運用を変えられる”状態は属人化が再発
→ **変更権限と変更手順**を決める
---
## 5. データ移行・連携（必要最小限）（5〜7週目）
**成果物**：移行計画、移行データ、移行手順、連携仕様（必要時）
### 実施内容
* 移行対象の決定（全部は移さない）
* 例：案件は直近1年、マスタは現行のみ、など
* クレンジング（表記揺れ、重複、必須欠損）
* リハーサル移行（本番前に最低1回は通す）
* 連携は最小化（最初はCSV手動でもOK、後で自動化）
### 注意点
* 移行で詰まると間に合わない
→ **移行範囲を絞る＋早めに着手**が鉄則
---
## 6. テスト（業務受入/UAT）と教育（7〜9週目）
**成果物**：テストシナリオ、結果、手順書、教育資料
### 実施内容
* テスト観点（最低限）
* 権限通りに見える/触れるか
* 承認フローが詰まらないか
* 通知が過不足ないか（うるさすぎ問題）
* 例外（差し戻し、取消、代理対応）
* 教育（非IT多め向けのコツ）
* 60分×2回くらいで「やることだけ」
* 画面操作は動画 or 1枚チートシート（最重要）
* “よくあるミス”を先に共有
### 注意点
* 教育は機能説明ではなく**業務のやり方**として教える
---
## 7. 本番切替（10〜12週目）
**成果物**：切替計画、ロールバック手順、初期サポート体制
### 実施内容
* 切替方式
* 30名規模なら、**一斉切替＋初期2週間の厚めサポート**が現実的
* リスクが高い業務だけ先行稼働も可
* 初期サポート（問い合わせ窓口、即時対応の範囲）
* ロールバック基準（どの条件で戻すか）
### 注意点
* 切替初週に“締め”や繁忙があると事故りやすい
→ スケジュールは業務カレンダー優先
---
## 8. 定着化・改善（本番後2〜4週）
**成果物**：改善バックログ、運用改善、追加自動化計画
* 問い合わせ分析（どこで迷うか）
* Must未達・例外の吸収
* Niceを第2フェーズとして実装（自動連携など）
---
# 3か月で成立させる標準スケジュール（例）
* **1〜2週**：現状把握（As-Is）＋To-Be/スコープ確定
* **3週**：製品選定（デモ/トライアル）＋決定
* **4〜6週**：設定・権限・マスタ・運用設計
* **5〜7週**：移行準備＆移行リハ
* **7〜9週**：UAT＋教育
* **10〜12週**：切替＋本稼働＋ハイパーケア
---
# 各ステップ共通の注意点（失敗パターン回避）
* **要件が増える**：Must/Niceを固定、追加は第2フェーズ送り
* **キーマン不在**：業務代表が週1で意思決定できる場を固定
* **教育不足で使われない**：チートシート＋短時間トレーニング＋初期サポート
* **移行で詰まる**：移行範囲を早期決定、クレンジングを先に着手
* **属人化が残る**：権限、運用ルール、手順書、変更管理を明文化
---
# 事前に洗い出しておくべき確認事項（チェックリスト）
* **対象業務**
* 置き換える業務は何か（営業/管理それぞれ）
* 現行Excelの一覧、マクロ有無、担当者
* **承認・権限**
* 承認者/代理承認の必要性、履歴保存要件
* 部門間で見せてはいけない情報の有無
* **データ**
* 移行する期間・範囲（全部/一部）
* マスタの正本はどれか（Excelが乱立していないか）
* **運用**
* マスタ更新担当、問い合わせ窓口、障害時手順
* 退職/異動時の権限・引継ぎ
* **環境**
* SSO要否、社内のID管理、利用端末（PC/スマホ）
* 既存ツール（メール、Teams/Slack、Box/SharePoint等）
* **法務/セキュリティ**
* 個人情報/機密情報の扱い、監査ログ要件
* データ保管場所（国内要件などがあるか）
After
インプット
## 目的
社内向けに新規業務システムを導入するにあたり、
進め方の全体像を整理したい。
## 背景
・現在はExcelとメール中心の業務フロー
・手作業が多く、属人化している
・ITに詳しくない関係者も多い
## 前提（分かっていること）
・利用部門：営業・管理部
・利用人数：約30名
・クラウド利用は可能
## 不明点（分からないこと）
・詳細な業務フロー
・既存システムとの連携要否
・予算上限
## 制約
・3か月以内に本稼働したい
・可能な限りSaaSを利用したい
・大規模なスクラッチ開発は避けたい
## 成功条件
・導入までのステップが明確になっている
・各ステップでやるべきことと注意点が整理されている
・不明点や事前に確認すべき事項が洗い出されている
## 出力形式
・マークダウン形式
・フェーズごとに箇条書き
・最後に「要確認事項リスト」をまとめる
アウトプット
# 新規業務システム導入の進め方（3か月本稼働・SaaS前提）
## フェーズ0：立ち上げ（1週目）
- やること
- 目的・成功条件の言語化（何ができたら「成功」かを具体化）
- 体制決め（業務オーナー：営業/管理、IT窓口、意思決定者、現場キーユーザー2〜4名）
- 対象範囲の確定（今回やる/やらない：業務範囲、部門、拠点、帳票）
- 3か月の大枠スケジュール作成（マイルストーン：選定→設定→移行→教育→本番）
- 注意点
- 「全部一気に」ではなく、初回リリースで必須（Must）に絞る
- 意思決定者の合意が遅れると3か月が崩れるため、決裁ポイントを先に置く
---
## フェーズ1：現状把握と要件整理（1〜3週目）
- やること
- 現行業務の棚卸し（Excel・メール・台帳・承認の流れを“見える化”）
- 業務フロー簡易ヒアリング（営業・管理それぞれ：入力→確認→承認→出力の流れ）
- 例外パターン収集（イレギュラー、差戻し、緊急対応、月末処理など）
- 要件定義（SaaS向けに「業務をシステムに寄せる」前提で整理）
- 画面/項目、権限、承認、通知、検索、帳票、データ出力、監査ログ
- 既存Excelの必須列・計算式・マクロ有無
- 優先度付け（Must / Should / Could）
- 成果物（最低限）
- 現状業務フロー（簡易図でOK）
- 要件一覧（Must中心）
- データ項目一覧（マスタ/トランザクション）
- 注意点
- ITに詳しくない関係者が多い場合、「画面イメージ」「実データ例」で会話する
- “要望”をそのまま要件にせず、目的（何を防ぎたい/早くしたい）に分解する
---
## フェーズ2：製品（SaaS）選定（3〜4週目）
- やること
- 候補タイプを決める（例）
- 業務ワークフローSaaS（申請・承認中心）
- CRM/SFA系（営業プロセス中心）
- 業務アプリ基盤（ノーコード/ローコードで台帳＋承認）
- 評価観点の作成（短期間導入向けに重要度高）
- 要件適合（Must充足）
- 設定の柔軟性（項目追加、承認ルート、権限）
- UI/操作性（非ITユーザーでも迷わない）
- データ入出力（Excel移行/CSV、レポート）
- 連携（メール/SSO/既存システム/API）
- 標準機能でどこまで行けるか（開発不要度）
- サポート体制（導入支援、QA速度）
- セキュリティ/監査（権限、ログ、IP制限等）
- 料金（初期/運用、ユーザー課金、ストレージ）
- デモ/トライアルで「実業務シナリオ」を流す（3本程度）
- PoC（小さく）：Must要件の山場だけ実機で検証
- 選定決裁（最終候補1つ＋保険の2nd候補）
- 注意点
- 3か月制約の場合、「カスタム開発が必要」な時点で失速しやすい
- “連携の要否”が不明なら、まずは「CSV運用で暫定」できるかも判断軸にする
---
## フェーズ3：導入設計（Fit to Standard）と運用設計（4〜6週目）
- やること
- ToBe業務フロー確定（SaaS標準に寄せた運用）
- ルール策定
- 入力責任者、承認権限、差戻し時の扱い、締め処理
- マスタ管理（誰がいつ更新するか）
- 画面/フォーム設計（項目、必須、入力制御、ステータス）
- 承認・通知設計（メール/チャット通知、リマインド、期限）
- 権限設計（営業/管理/管理者、閲覧範囲、操作範囲）
- レポート/出力設計（最低限：現場が必要な一覧と管理用集計）
- 注意点
- “現行のExcel計算式”をそのまま再現しようとしない（運用簡素化の機会）
- 権限を細かくしすぎると運用が破綻するため、まずは粗く始める
---
## フェーズ4：設定・データ移行・連携（6〜8週目）
- やること
- 環境構築（本番/検証、ユーザー、権限、基本設定）
- マスタ整備（顧客/商品/担当者など必要なもの）
- データ移行計画
- どのExcelを移すか（移す/捨てる/アーカイブ）
- クレンジング（重複、表記揺れ、欠損、コード体系）
- 移行リハーサル（少なくとも1回）
- 連携方針の確定
- 当面はCSV手動で回すか、API/ETLでつなぐか
- 連携先がある場合は責任分界（どこまで誰が面倒を見るか）
- 注意点
- 最大のリスクは「データ品質」と「移行作業の遅延」になりやすい
- 既存システム連携が必要な場合、3か月では“簡易連携（CSV）”を第一候補に
---
## フェーズ5：テスト（8〜10週目）
- やること
- シナリオテスト（業務シナリオで端から端まで）
- 権限テスト（見えちゃいけないものが見えないか）
- 例外テスト（差戻し、取消、修正、締め後の扱い）
- 受入テスト（現場キーユーザーでOK判定）
- 運用テスト（問い合わせ対応、マスタ変更、障害時の手順）
- 注意点
- テストは「画面」より「運用事故（権限/締め/例外）」を重視
- “承認が回らない/止まる”を想定したバックアップ手順を用意
---
## フェーズ6：教育・展開・切替（10〜12週目）
- やること
- 教育資料（1枚チートシート＋短い操作動画 or 画面キャプチャ）
- 役割別トレーニング（営業/管理/承認者/管理者）
- 問い合わせ窓口と運用（初月は即レス体制：FAQ整備）
- 切替計画
- 旧運用停止タイミング（Excel更新禁止日）
- 並行運用の有無（原則短く）
- 初回の締め/集計の実施手順
- 本番リリース（段階リリースが可能なら、まず小さく開始）
- 注意点
- 非ITユーザー向けは「全部教える」より「迷わない導線」と「よくあるミス集」
- 並行運用が長いと定着しないので、切替日を強く固定する
---
## フェーズ7：安定化・改善（本稼働後 2〜4週）
- やること
- 利用状況の可視化（未入力、滞留、承認遅延）
- 問い合わせ分析→改善バックログ化（小改善を毎週反映）
- 次フェーズ検討（連携自動化、帳票強化、権限最適化）
- 注意点
- 初回リリースで削ったShould/Couldを、運用実績ベースで再優先付けする
---
# 要確認事項リスト（不明点の洗い出し）
- 業務フロー
- 営業・管理それぞれの「開始〜完了」までの具体フロー（例外含む）
- 承認者/決裁者の範囲、承認段数、差戻しルール
- 月次/週次の締め処理・集計処理の有無
- データ
- 現行Excelの種類一覧（台帳/申請/集計/マスタ）と重要度
- 必須データ項目、計算式/マクロの有無、データ量（行数・ファイル数）
- データの機密区分（閲覧制限が必要な項目）
- 既存システム連携
- 連携候補（会計、人事、基幹、CRM、グループウェア等）
- 連携の目的（二重入力削減/マスタ同期/帳票出力など）
- リアルタイム必須か、日次バッチで良いか（CSVで足りるか）
- 運用・体制
- システム管理者は誰か（権限/マスタ/ユーザー管理）
- 問い合わせ一次窓口は誰か（IT/業務）
- 教育の実施方法（集合/動画/オンボーディング）
- 制約条件
- 予算上限（初期・月額・ユーザー課金許容）
- セキュリティ要件（SSO、MFA、IP制限、ログ、監査、データ保持）
- 社内のクラウド利用ルール（契約、稟議、セキュリティ審査の所要日数）
- スケジュール前提
- 決裁に必要な会議体と開催頻度（いつ承認が取れるか）
- 本稼働希望日（固定日か、幅を持てるか）
Before,Afterの違い
指示した内容自体は大きく変わりませんが、以下のような違いがみられました。
・beforeは方針や全体像を重視した説明・合意形成向けの構成である
・afterはフェーズ単位で明確に構造化された実行・運用向けの構成になっている
・afterそのままタスク分解や進行管理に転用できるレベルまで具体化されている
Beforeでもよさげな回答が出力されていますが、Afterの方が余計な情報がなく、簡潔にまとめられている印象です。
まとめ
推論モデルは「技巧」より「設計」が重要です。
推論モデルを活かすコツは、派手な言い回しではなく、
- 目的を短く明確に書く
- 入力を構造化する（区切る）
- 制約・成功条件を具体化する
- まずゼロショットで試す
この4点を徹底することでした。
第1回の「プロンプト＝指示書＋材料」という土台はそのままに、推論モデルでは特に成功条件の設計が効果的、というのが今回の学びです。
さいごに
テンダでは、「こんなプロジェクトに挑戦したい」「こんなチームで働きたい」「理想のチームを創りたい」と願う仲間を求めています。
カジュアル面談も随時受付中です。ぜひ一度お話ししましょう。