見出し画像

AIへの依頼が長い・ちゃんとしているのに、なぜうまく進まない？複雑な仕事を7要素へ分解する基本設計

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中

AIに複雑な仕事を任せようとして、できるだけ詳しい指示を書いた。

背景も説明した。条件も並べた。参考資料も大量に渡した。作業手順も細かく指定した。

それでも、出てきた成果物はどこかずれている。一部の条件が抜け、重要ではない説明ばかりが膨らみ、最後まで読んでも「結局、何に使えるのか」が分からない。

こうしたとき、「もっと詳しく指示しなければ」と考えがちです。

ただ、複雑な仕事では、情報量を増やすだけでは解決しません。

必要なのは、長いプロンプトではなく、仕事の設計図です。

フェーズ1では、単発タスクに必要な情報を渡し、確認できる初稿を作りました。フェーズ2では、その初稿を批評し、対話によって改善しました。

フェーズ3では、成果物の修正だけではなく、複雑な仕事そのものを、目的・背景・材料・制約・工程・出力・完了条件へ分解します。

複雑な仕事でAIの成果を安定させる鍵は、指示を長くすることではありません。目的・背景・材料・制約・工程・出力・完了条件を分け、重要な判断だけを明示することです。

このシリーズでは、AI活用が単発利用から業務・組織の再設計へ進む過程を、12のフェーズに分けて解説します。


フェーズ3では、プロンプトを書く前に仕事の設計図を作る

フェーズ3の「構造化された依頼設計」とは、複雑な仕事を、AIと人間の双方が理解・確認できる単位へ整理することです。

ここでいう複雑な仕事とは、単に文章量が多い仕事ではありません。

次のような特徴を持つ仕事です。

  • 複数の目的や関係者がいる

  • 複数の資料や情報源を使う

  • 作業工程が複数ある

  • 途中で人間の判断や承認が必要

  • 守るべき条件や禁止事項がある

  • 成果物を別の業務で利用する

  • 完成したかどうかを判断しにくい

たとえば、「営業資料を作る」という依頼でも、実際には次の仕事が含まれるかもしれません。

  • 顧客の課題を理解する

  • 自社サービスとの適合性を整理する

  • 必要なデータを確認する

  • 資料の構成を決める

  • 本文を書く

  • 図表を作る

  • 表現を確認する

  • 社内承認を得る

これらを一つの文章に詰め込んで「良い営業資料を作って」と頼んでも、AIが何を優先すべきか判断できないことがあります。

そこで、フェーズ3では仕事を次の7要素へ分けます。

  1. Goal：最終的に達成したいこと

  2. Context：背景、対象者、利用場面

  3. Inputs：参照すべき材料

  4. Constraints：守る条件、禁止事項、優先順位

  5. Process：必要な工程と判断ポイント

  6. Output：成果物の形式

  7. Done when：完了条件

この7要素は、長いプロンプトを作るためのテンプレートではありません。

仕事の複雑さに応じて、必要な要素だけ使います。

単純なメール修正なら、目的、元情報、出力形式だけで十分かもしれません。一方、調査、企画、資料作成、承認を含む仕事なら、7要素を分けた方が失敗を見つけやすくなります。

目的・背景・材料・作業を一つの文章へ混ぜると、優先順位が消える

複雑な依頼で起きやすい失敗の一つが、異なる種類の情報を一つの文章へ混ぜることです。

新規顧客向けの営業資料を作ってください。
当社は2018年創業で、これまで多くの企業を支援しています。
競合との差も示し、分かりやすく、説得力のある内容にしてください。
10枚程度で、料金は最後に入れてください。
過去の提案書も参考にしてください。

この依頼には、目的、会社紹介、作業、形式、制約が混在しています。

AIには次の点が分かりません。

  • 誰に向けた資料なのか

  • 読者に何を判断してほしいのか

  • 過去資料のどこを事実として使うのか

  • 競合比較をどの軸で行うのか

  • 「説得力」を何で判断するのか

  • 料金掲載が必須なのか、推奨なのか

情報が少ないのではなく、情報の役割が分かれていないことが問題です。

情報を増やす前に、何を達成する仕事かを一文で固定する

複雑な依頼では、最初にGoalを一文で決めます。

成果物名ではなく、成果物によって誰の何を変えるのかを示します。

新規顧客が、自社の課題と当社サービスの適合性を判断し、
次回の個別相談へ進める営業資料を作る。

この一文があるだけで、資料へ入れるべき情報の優先順位が変わります。

創業年や実績も、読者の判断に必要なら残します。会社紹介として載せたいだけなら、削るか後ろへ回します。

重要な曖昧さだけを解消し、細部まで決めすぎない

依頼を構造化する目的は、すべてを固定することではありません。

現在の高性能モデルでは、直接的で簡潔な指示が推奨される一方、目的、利用する文脈、制約、出力条件を明示することは引き続き重要です。GoogleはGemini 3系について、旧来の冗長で複雑なプロンプトは過剰分析を招く場合があると説明しています。

一方で、すべての工程を細かく指定しすぎると、次の問題が起きます。

  • 条件同士が衝突する

  • より良い構成を選べなくなる

  • 指示を守ることが目的になる

  • 小さな変更で依頼全体を書き直す必要がある

  • 実際の材料に合わない工程を強制する

厳密に決めるべきなのは、違反すると利用できない条件です。

それ以外は、AIが判断できる余地を残します。

Goalでは、成果物名ではなく「誰の何を変えるか」を定義する

Goalは、依頼全体の最上位にある目的です。

ここが曖昧だと、後ろの要素をいくら詳しくしても、成果物は安定しません。

成果物名だけでは、仕事の目的にならない

次の依頼は、作るものしか示していません。

社員向けのAI研修を企画してください。

これだけでは、AIは次を判断できません。

  • なぜ研修を行うのか

  • 研修後に何ができればよいのか

  • 知識を教えるのか、実務利用を増やすのか

  • 全社員向けか、特定職種向けか

  • 安全教育が中心か、成果創出が中心か

Goalは次のように書きます。

AI初心者の営業担当者が、研修翌日から
メール作成・要約・商談準備の3業務で、
安全にAIを使える状態にする。

このGoalなら、研修で扱う内容、演習、完了条件を逆算できます。

読者・判断・行動を含めると、目的が具体化する

Goalを作るときは、次の三つを確認します。

  • 誰が対象か

  • 何を理解・判断できるようにするか

  • その後、どの行動へ進んでほしいか

営業資料なら次のようになります。

中小企業の経営者が、自社の課題とサービスの適合性を理解し、
個別相談を申し込むかどうか判断できる状態にする。

記事なら、次のように書けます。

AI活用がうまくいかない読者が、
失敗原因をモデル性能だけでなく設計要素から診断し、
次に見直す項目を選べる状態にする。

目的が複数ある場合は、最優先を一つ決める

一つの成果物へ複数の目的を持たせることはあります。

たとえば、営業資料には次の目的があるかもしれません。

  • サービスを理解してもらう

  • 信頼を得る

  • 競合との違いを示す

  • 料金を説明する

  • 相談へ進んでもらう

すべてを同じ優先度で扱うと、資料が長くなり、何を伝えたいのか分からなくなります。

そこで、次のように優先順位を付けます。

最優先：
自社の課題とサービスの適合性を判断できること

次点：
導入方法と相談までの流れを理解できること

補助：
会社の信頼性を確認できること

目的と手段が逆転していないか確認する

AIを使うこと、資料を作ること、記事を書くことは手段です。

次のような依頼は、手段が目的になっています。

AIを使って新しい研修資料を作る。

本来の問いは次です。

現在の研修で、受講者が実務へ移れない原因は何か。
資料の改訂で解決するのか。
演習、レビュー、実案件適用を変える必要はないか。

作れることと、作るべきことは同じではありません。

フェーズ3では、依頼を作る前に「その成果物が本当に必要か」も確認します。

Contextでは、成果物の方向を変える背景だけを渡す

Contextは、AIが仕事を理解するための背景です。

ただし、背景は多ければよいわけではありません。

重要なのは、その情報によって結論や成果物が変わるかです。

背景は長さではなく、結論への影響で選ぶ

AI研修を企画する場合、次の情報は成果へ影響します。

  • 対象者の職種

  • AI経験

  • 研修時間

  • 参加人数

  • オンラインか対面か

  • 利用可能なAIサービス

  • 会社の利用ルール

  • 研修後に使う業務

一方、次のような情報は、今回の設計に不要かもしれません。

  • 会社の沿革全体

  • 研修に関係しない事業説明

  • 過去の会議経緯のすべて

  • 廃止された案の詳細

  • 関係のない担当者情報

情報を渡す基準は、「知っていた方がよさそう」ではなく、「知らないと結果が変わるか」です。

普遍的な条件と今回だけの条件を分ける

Contextには、長期間変わらない情報と、案件固有の情報があります。

普遍的な情報：

  • 会社の基本方針

  • ブランドの文体

  • 情報管理ルール

  • 対象顧客の基本像

案件固有の情報：

  • 今回の対象者

  • 納期

  • 予算

  • 利用場面

  • 成果物

  • 未確定事項

両方を一つの長い依頼へ混ぜると、再利用しにくくなります。

フェーズ7では、これらを継続的なコンテキスト環境として管理します。フェーズ3では、まず今回の依頼で必要な情報を分類できれば十分です。

古い経緯や関係ない情報を大量に混ぜない

過去資料や会話履歴を大量に渡すと、古い条件や無関係な内容が出力へ混ざる可能性があります。

長いコンテキストを扱えるモデルであっても、情報の優先順位付けや不要情報の除外は重要です。Googleも長いコンテキストの利用時に、情報のフィルタリングや要約などの管理方法を示しています。

Contextを渡す際は、次を明示します。

  • 現在も有効

  • 参考用

  • 廃止済み

  • 未確定

  • 今回は使用しない

現在有効：
・研修時間は90分
・対象は営業担当20名
・ChatGPTのみ利用可能

参考用：
・昨年度の研修アンケート

廃止済み：
・3時間の対面研修案

未確定：
・研修後のフォローアップ日程

AIが知るはずのない組織事情を明示する

AIは一般的な営業、研修、採用、会議について説明できます。

しかし、自社で何が問題になっているかは、材料がなければ分かりません。

  • 上司承認が必要

  • 顧客情報を入力できない

  • 特定の用語を避ける

  • 現場ではスマートフォンしか使えない

  • 既存システムへ登録する必要がある

  • 研修後の実務課題が必須

こうした組織固有の事情は、明示する必要があります。

Inputsでは、成果物の根拠として使う材料を選別する

Inputsは、AIが仕事に使う材料です。

Contextが「仕事の背景」であるのに対し、Inputsは「成果物を作るために実際に参照する情報」です。

材料が多いほど精度が上がるとは限らない

大量の資料を渡すと、必要な情報が増える一方で、ノイズも増えます。

AI研修の企画なら、次の材料が考えられます。

  • 会社のAI利用ルール

  • 対象職種の業務一覧

  • 過去研修のアンケート

  • 実際の業務例

  • 利用可能なAIサービスの仕様

  • 演習用の匿名化サンプル

一方、過去研修の全スライド、全会議録、会社案内などは、今回の企画に不要かもしれません。

事実の原本と、参考表現を区別する

材料には、使い方の異なるものがあります。

  • 事実の原本

  • 表現の参考

  • 構成の参考

  • 仮説

  • 未確認情報

過去の提案書を参考にする場合、数字まで再利用してよいとは限りません。

事実の根拠：
・最新の料金表
・サービス仕様書
・顧客ヒアリング記録

構成の参考：
・過去の提案書A

文体の参考：
・既存記事B

使用禁止：
・旧料金が記載された提案書C

この区別がないと、古い数値や別案件の条件が混ざる可能性があります。

最新版・旧版・廃止版を明示する

同じ名前の資料が複数ある場合は、何を使うか指定します。

最新版：
2026-07-15_研修要件_v3.md

参考用：
2026-07-01_研修要件_v2.md

使用禁止：
2026-06-20_研修要件_旧案.md

ファイル名だけで判断できない場合は、本文中にも状態を書きます。

不足材料は推測させず、質問または未確認にする

必要な材料がないとき、AIへ無理に補わせてはいけません。

不足情報が結論を大きく左右する場合は質問してください。
確認できない事項は推測せず、「未確認」と記載してください。

とくに、次の情報は推測させない方が安全です。

  • 金額

  • 日付

  • 契約条件

  • 法令

  • 顧客の発言

  • 社内決定

  • 実績

  • 個人情報

  • 利用可能な権限

Constraintsでは、厳格な条件と好みを分ける

Constraintsは、守る条件や禁止事項です。

ここでよく起きるのは、条件を並べすぎて相互に矛盾することです。

たとえば、

  • 詳細に説明する

  • 500字以内

  • すべての論点を含める

  • 初心者にも分かりやすくする

  • 専門性を落とさない

これらは同時に満たせない場合があります。

そこで、条件を三段階へ分けます。

  • 必須：違反すると利用できない

  • 推奨：できる限り守る

  • 好み：状況に応じて変更できる

必須条件を増やしすぎると、条件同士が衝突する

AI研修企画なら、次のように分けられます。

必須：
・90分以内
・顧客情報を使わない
・参加者が一つ以上の成果物を作る
・利用可能ツールはChatGPTのみ

推奨：
・講義時間を30分以内にする
・少人数で共有する時間を設ける
・専門用語を減らす

好み：
・演習を3種類用意する
・明るい雰囲気にする

必須と好みを分けることで、条件が衝突した際の優先順位が分かります。

禁止事項だけでなく、優先順位も伝える

禁止事項を並べるだけでは、条件が競合したときに判断できません。

優先順位：
1. 安全性
2. 実務で使えること
3. 90分以内
4. 見た目の魅力

この順序があれば、時間内に収まらない場合、デザイン要素を減らし、安全説明と演習を残す判断ができます。

変更してよい部分と、維持する部分を分ける

既存資料を改善するときは、次を明示します。

変更してよい：
・見出し
・説明順序
・例
・表現

維持する：
・確認済みの数値
・商品名
・料金
・契約条件
・承認済みの中心結論

フェーズ2の差分修正と同じ考え方ですが、フェーズ3では依頼の最初から境界を設計します。

AIに与える権限や承認境界も制約に含める

AIが外部サービスを操作する場合は、さらに明確な制約が必要です。

フェーズ3では実行基盤までは扱いませんが、依頼設計の段階でも次を区別できます。

  • 読み取りだけ

  • 下書き作成まで

  • 人間承認後に送信

  • 公開はしない

  • 削除・課金・契約変更は禁止

作ることと、外部へ反映することは分けます。

Processでは、外から確認できる工程と人間判断を分ける

Processは、AIの内部思考を逐一指定するものではありません。

外から確認できる作業工程、停止地点、承認地点を定義するものです。

OpenAIのGPT-5.6向けガイドは、結果と重要な制約を明示しつつ、不要な重複や過剰な工程指定を避ける方向を示しています。

AI研修企画なら次のように書けます。

1. 提供資料から研修目標と制約を整理する
2. 結論を左右する不足情報を最大3問質問する
3. 90分の構成案を作る
4. 演習候補を3案比較する
5. 推奨案を提示する
6. 人間の承認を待つ
7. 承認後に教材詳細を作る
8. 完了条件を自己確認する

順序を誤ると手戻りが大きい工程だけ指定する

構成を承認する前に教材本文をすべて作ると、方向修正の工数が大きくなります。

次のような工程は、順序を明示する価値があります。

  • 調査してから執筆する

  • 構成承認後に詳細を作る

  • 計算前に前提を確認する

  • 本文確定後に画像を作る

  • 下書き確認後に送信する

  • テスト合格後に本番反映する

作業工程と人間判断を分ける

AIができる作業と、人間が保持する判断を分けます。

AIが行う：
・資料整理
・構成案
・演習候補
・比較表
・初稿

人間が判断する：
・研修目的
・採用する演習
・会社ルールとの適合
・最終公開

AIへ判断材料を作らせることと、最終判断を任せることは別です。

大きな成果物は中間承認を置く

成果物が大きいほど、一度で完成させるリスクが高くなります。

  • Brief

  • 構成

  • サンプル

  • 初稿

  • 改善版

  • 最終版

のように、中間成果物を置きます。

構成案を提示した時点で停止し、承認を待ってください。
承認前に本文を作らないでください。

こうした停止条件は、手戻りを減らします。

AIへ方法を任せる範囲も明示する

すべての工程を決める必要はありません。

必須の工程と制約を守る範囲で、
構成や説明方法は最適なものを選んでください。

AIへ裁量を渡すことで、材料に応じたより良い方法を選べる場合があります。

工程を細かくしすぎて、AIの判断力を潰さない

過剰指定の例です。

最初に3つの見出しを考え、
それぞれ40字で説明し、
その後に具体例を2つずつ作り、
最後に100字のまとめを……

この手順が本当に必要なら問題ありません。

しかし、「詳しく指示した方がよさそう」という理由だけなら、逆効果になることがあります。

細かい手順を固定する代わりに、次を明確にします。

達成したい結果：
必ず守る条件：
利用できる材料：
途中で人間確認する箇所：
完成と判断する条件：

進め方は、この境界を守る範囲で最適な方法を選んでください。

Outputでは、形式だけでなく「次工程で使える状態」を定義する

Outputは、最終的に何を残すかです。

単に「Markdownで」「表で」と指定するだけでは不十分な場合があります。

出力形式は、次工程から逆算して決める

成果物が次にどこで使われるかを考えます。

  • noteへ貼るなら、note向けMarkdown

  • 会議で使うなら、意思決定項目が分かる1ページ

  • 開発へ渡すなら、要件・受入条件・未確定事項

  • メールへ使うなら、件名と本文

  • システム連携なら、決められたJSON

  • 研修で使うなら、講師手順と参加者演習

成果物単体の見栄えではなく、次工程で使えることが重要です。

文字数より、必要項目と利用場面を優先する

「800字で」と指定しても、何を含めるか分からなければ、重要な情報が抜けます。

必須項目：
・背景
・課題
・提案
・実行手順
・リスク
・次の行動

目安：
800〜1,000字

のように、項目を先に定義します。

本文と補足・根拠・変更点を分ける

AIの出力に、検討メモや説明が混ざると使いにくくなります。

最終成果物：
記事本文だけをMarkdownで出す

本文外：
・未確認事項
・使用した仮定
・人間が確認する箇所
・変更点

と分けます。

ファイル名、配置先、版も必要なら定義する

実務では、内容だけでなく管理方法も重要です。

ファイル名：
2026-07-17_AI研修企画_v1.md

保存先：
/output/training/

状態：
レビュー前

次版：
修正後はv2として保存し、v1を上書きしない

フェーズ10以降では、これを実行基盤やバージョン管理へ発展させます。

Done whenでは、第三者が完成を判断できる条件を作る

Done whenは、何を満たせば仕事が終わったと判断できるかです。

Goalが「何を達成したいか」なのに対し、Done whenは「達成したとどう確認するか」です。

ここがないと、AIは追加案や改善提案を続けます。

人間側も、いつ完成したのか判断できません。

Anthropicはプロンプト改善の前提として、具体的な成功条件と、それを検証する方法を定義することを推奨しています。

完了条件は、観察・照合できる形にする

悪い完了条件です。

  • 高品質である

  • 魅力的である

  • 分かりやすい

  • 完璧である

  • 実践的である

これらは、判断基準がありません。

改善すると次のようになります。

  • 必須5項目がすべて存在する

  • 重要数値が元資料と一致する

  • 全体が90分以内

  • 演習が最低1つある

  • 読者が次に行う行動が一つ明示されている

  • 未確認事項が別欄に整理されている

  • 人間確認が必要な箇所が示されている

品質条件と形式条件を分ける

形式条件：

  • 10枚以内

  • Markdown形式

  • 指定見出しを含む

  • 90分以内

  • ファイル名が正しい

品質条件：

  • 目的に合っている

  • 重要な根拠がある

  • 誤解を生む断定がない

  • 実行手順が再現可能

  • 対象者に適した難易度

両方を分けると、修正すべき箇所が分かります。

完成と「追加改善可能」を区別する

成果物は、常に改善できます。

しかし、追加改善が可能であることと、利用可能な完成状態でないことは別です。

必須条件をすべて満たした場合は「完成」と判定してください。
任意の改善案は、完成判定とは別に最大2件だけ示してください。

とすると、改善が終わらなくなることを防げます。

AIの自己判定だけで完了にしない

AIに完了条件を確認させることは有効です。

ただし、AIが「完成」と言ったから完成なのではありません。

最終的には、人間が次を確認します。

  • 事実

  • 数値

  • 固有名詞

  • 権利

  • 宛先

  • 公開範囲

  • 実行可能性

  • 重要判断

曖昧な研修企画を、7要素の依頼へ変えてみる

ここまでの7要素を、具体的な仕事へ当てはめます。

今回の題材は、社員向けAI研修の企画です。

曖昧な依頼では、AIが重要な条件を推測する

社員向けのAI研修を企画してください。
実践的で魅力的な内容にしてください。

この依頼だけでも、AIは研修案を作れます。

ただし、次の情報がありません。

  • 対象職種

  • AI経験

  • 研修の目的

  • 人数

  • 時間

  • 実施形式

  • 利用可能なツール

  • 情報管理ルール

  • 完成させる成果物

  • 成功条件

AIは一般的な研修案を作るでしょう。

しかし、一般的に良い研修と、今回の現場で使える研修は同じではありません。

7要素へ分けると、何を確認すべきかが見える

Goal：
AI初心者の営業担当者が、研修翌日から
メール作成・要約・商談準備の3業務で、
安全にAIを使える状態にする。

Context：
対象は営業担当20名。
AI経験はほぼない。
研修はオンラインで90分。
利用可能ツールはChatGPTのみ。
顧客情報は演習へ使わない。

Inputs：
・会社のAI利用ルール
・営業業務一覧
・既存研修のアンケート
・演習に使える匿名化済みサンプル

Constraints：
必須：
・機密情報を使わない
・講義だけで終わらせない
・90分以内
・参加者が一つ以上の成果物を完成させる

推奨：
・専門用語を減らす
・少人数で共有する時間を設ける

Process：
1. 研修目標と制約を確認する
2. 結論を左右する不足情報を最大3問質問する
3. 90分の構成案を作る
4. 演習候補を3案比較する
5. 推奨構成を提示する
6. 人間の承認を待つ
7. 承認後に教材詳細を作る

Output：
・研修目的
・90分のタイムテーブル
・演習内容
・講師の進行手順
・必要な事前準備
・終了後の実務課題

Done when：
・全体が90分以内
・参加者が最低1つの実務成果物を作る
・3業務すべてに具体例がある
・安全上の注意が含まれる
・講師がそのまま進行できる粒度である

この依頼の利点は、長いことではありません。

  • 何を達成するか

  • どの背景が重要か

  • 何を材料にするか

  • 何を守るか

  • どこで人間が判断するか

  • 最終的に何を作るか

  • 何を満たせば完成か

が分かれていることです。

7要素すべてを毎回書く必要はない

小さな仕事なら、次の短縮版で十分です。

目的：
材料：
守る条件：
してほしい工程：
成果物：
完成条件：

構造化の目的は、テンプレートを埋めることではありません。

失敗したときに、どの要素が不足していたのかを見つけられる状態を作ることです。

依頼が失敗したときは、7要素のどこが原因か切り分ける

構造化依頼を使うと、失敗を「AIが悪い」「自分のプロンプトが悪い」という曖昧な評価で終わらせずに済みます。

成果物の方向が違うなら、Goalを見直す

作ったものは整っているが、欲しかった結果と違う。

この場合、目的が成果物名だけになっていないか確認します。

資料を作る

ではなく、

誰が、何を判断し、次に何をするための資料か

へ戻ります。

一般論ばかりなら、Contextを見直す

AIの回答が一般的で、自社の現場に合わない場合は、背景不足の可能性があります。

  • 対象者

  • 現場の制約

  • 利用場面

  • 過去の判断

  • 現在の課題

を確認します。

事実誤りや古い情報が多いなら、Inputsを見直す

AIが必要な資料を参照できているか確認します。

  • 最新版を渡したか

  • 使用禁止資料を区別したか

  • 事実の原本を明示したか

  • 足りない情報を推測させていないか

条件違反があるなら、Constraintsを見直す

条件が多すぎないか、矛盾していないか、優先順位があるかを確認します。

詳しく、短く、すべて含める

のような競合がないかを見ます。

途中で迷走するなら、Processを見直す

大きな仕事を一度に頼んでいないか確認します。

  • 構成確認前に全文を作っている

  • 調査と執筆を同時に行っている

  • 人間承認の位置がない

  • 中間成果物がない

場合は、工程を分けます。

形式は整っているが使えないなら、Outputを見直す

「表で出す」「10枚にする」といった形式だけでなく、次工程で使えるか確認します。

  • 誰が使うのか

  • どこへ貼るのか

  • どの情報が必須か

  • ファイルとして必要か

  • 本文と補足を分けるか

を見直します。

終わらない、または完成を判断できないなら、Done whenを見直す

「高品質に」「魅力的に」だけでは、完了を判断できません。

観察可能な条件へ変えます。

7要素を直しても改善しないなら、別の原因を疑う

構造化依頼は万能ではありません。

Anthropicも、すべての品質・速度・費用上の問題がプロンプト改善だけで解決するわけではなく、モデル変更など別の手段が適切な場合があると説明しています。

改善しない場合は、次を確認します。

  • モデルが仕事に適していない

  • Web検索やツールが必要

  • 情報源が不足

  • 業務自体が未整理

  • 人間側の判断が未確定

  • 一つの依頼へまとめるべきではない

  • 専門家確認が必要

すべての問題を、プロンプトの工夫へ還元しないことが重要です。

まず一つの複雑業務を7要素へ分解し、第三者に試してもらう

フェーズ3の練習では、実際に繰り返し発生する仕事を一つ選びます。

候補は次のようなものです。

  • 研修企画

  • 顧客提案書

  • 採用記事

  • 市場調査

  • 会議資料

  • 業務改善案

  • イベント企画

  • 社内マニュアル

現在使っている依頼を、そのまま保存する

まず、今の依頼を変更せず記録します。

これがBeforeになります。

7要素へ分解する

GoalからDone whenへ整理します。

すべて埋める必要はありません。不明な箇所は、不明だと分かる状態にします。

AIに依頼設計だけを監査させる

成果物を作らせる前に、設計を確認させます。

以下の依頼をまだ実行せず、設計だけ監査してください。

確認観点：
・Goalは手段ではなく目的になっているか
・Contextに不要な情報や不足がないか
・Inputsは利用可能か
・Constraints同士が矛盾していないか
・Processは細かすぎないか、粗すぎないか
・Outputは実際の利用場面に合うか
・Done whenは第三者が判定できるか
・AIへ任せる判断と人間が保持する判断が明確か

出力：
1. 重大な不足
2. 過剰な指定
3. 矛盾
4. 未確定事項
5. 修正版

AIの監査結果は補助材料です。人間側でも確認します。

別の人が同じ依頼を使って試す

再利用可能性を確認するには、自分以外が使うのが有効です。

別の担当者が同じ依頼を使ったとき、

  • 同じ目的を理解できたか

  • 必要な資料が分かったか

  • 判断に迷った箇所は何か

  • 成果物のばらつきはどこに出たか

を確認します。

不足条件と過剰条件を修正する

追加するだけでなく、不要な指示も削ります。

  • 毎回使わない背景

  • 結果に影響しない細部

  • 同じ意味の重複指示

  • AIへ任せてもよい手順

  • 現在は無効な条件

を整理します。

記録には次を使えます。

対象業務：
現在の依頼：
失敗しやすい点：

Goal：
Context：
Inputs：
Constraints：
Process：
Output：
Done when：

実行結果：
不足していた条件：
不要だった条件：
AIへ任せすぎた判断：
細かく指定しすぎた箇所：
次回の修正版：

現場で使える、構造化依頼のテンプレート

Goal：
最終的に達成したいこと。
作るものではなく、誰の何を変えるか。

Context：
背景、対象者、利用場面、現在の状況。
結論へ影響する情報だけを書く。

Inputs：
参照すべき資料、データ、原文、見本。
最新版・旧版・参考用を区別する。

Constraints：
必須条件：
推奨条件：
禁止事項：
優先順位：
人間の承認が必要な箇所：

Process：
必要な作業工程：
途中で確認する箇所：
AIへ任せる判断：
人間が保持する判断：

Output：
成果物の形式：
必須項目：
文字数・枚数：
ファイル形式・名前：
利用場所：

Done when：
完成と判断できる条件：
事実確認項目：
未確認事項の扱い：
人間が最終確認する箇所：

日常業務では、次の短縮版も使えます。

目的：
材料：
守る条件：
してほしい工程：
成果物：
完成条件：

長いテンプレートを毎回使う必要はありません。

仕事の複雑さに応じて、必要な構造だけ使います。

フェーズ4へ進む目安は、AIの答えではなく判断材料を設計できること

次の状態になったら、フェーズ4「思考・判断支援」へ進む準備ができています。

  • 最終目的を1文で定義できる

  • 必要な背景だけを選べる

  • 元資料と参考例を区別できる

  • 必須条件と好みを分けられる

  • 作業工程と人間判断を分けられる

  • 利用可能な出力形式を定義できる

  • 完了条件を観察可能にできる

  • 失敗原因を7要素から切り分けられる

  • 同じ依頼を第三者が再利用できる

  • 不要な指示を削れる

  • プロンプトでは解決しない問題を見分けられる

フェーズ3では、AIが迷わず仕事を進めるための設計図を作りました。

次のフェーズでは、成果物制作だけでなく、論点整理、仮説形成、比較、反論、リスク、機会費用など、AIを思考・判断支援へ使います。

「何を作るか」から、「何を考え、どう判断するか」へ進んでいきます。

関連記事

プロンプト単体から、コンテキスト、ツール、権限、評価を含むシステム設計へ対象が広がった流れを整理しています。

AI成果を、モデル、要件、情報、実行方法、評価、権限の6要素から捉えるための基本構造を整理しています。

AIで作れるものが増えるほど、目的と手段を取り違えず、必要なものだけを作る重要性を考察しています。

AI活用成熟度12フェーズ

出典・参考資料

いいなと思ったら応援しよう！

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中 社会問題×マーケティングが好き / ㍿小さな一歩（前澤ファンド出資先）で養育費の未払い問題にビジネスでトライ→㍿SHIRO創業。社会問題の発見→要因分析→ビジネス考案→実行に必要な資本整備→実行・改善のサイクルが最短で回り社会問題が解決されつづけるインフラを創る。