AIを仕事で使い始めるなら、まず単発タスクから！「いい感じに作って」を卒業する基本設計
ChatGPTやClaude、Geminiにメール作成や要約を頼んでみたものの、使える回答が出るときと、そうでないときがある。
「日程変更のメールを、いい感じに作って」と頼んだら、伝えていない理由まで追加された。長文を要約させたら、自分が残してほしかった情報が消えていた。同じように頼んだはずなのに、回答の詳しさが毎回違う。
こうした経験から、「AIの性能がまだ低いのか」「自分のプロンプトが悪いのか」と考える人もいると思います。
ただ、この問題は、どちらか一方だけでは説明できません。
AIの出力は、使うモデルだけでなく、任せた仕事、渡した材料、求める形式、確認方法の組み合わせによって変わります。
AI活用成熟度のフェーズ1で目指すのは、AIへ仕事を丸投げすることでも、長大なプロンプトを覚えることでもありません。
まずは、メール、要約、文章修正、情報整理など、範囲が明確で確認しやすい仕事について、人間が確認・修正すれば使える初稿を安定して得ることです。
このシリーズでは、AI活用が単発利用から業務・組織の再設計へ進む過程を、12のフェーズに分けて解説します。
フェーズ1の目標は、AIへの丸投げではなく「確認できる初稿」を得ること
フェーズ1の「単発タスク利用」とは、範囲が明確な一つの仕事をAIへ依頼し、実務で使える初稿を得る段階です。
たとえば、次のような使い方です。
箇条書きのメモからメールの初稿を作る
長い文章から要点を抜き出す
難しい説明を初心者向けに書き換える
会議メモから決定事項や担当者を整理する
一つのテーマについてアイデア候補を出す
翻訳の初稿を作る
ここで大切なのは、AIが出したものを、そのまま完成品だと考えないことです。
フェーズ1の到達点は、AIに最終判断まで任せることではありません。単純な仕事について、確認・修正すれば使える初稿を、以前より速く作れる状態です。
Microsoft Researchが2025年に公表した研究では、6,000人の知識労働者を対象に、生成AIツールへのアクセスが仕事の進め方へ与える影響を6か月間調べています。
結果として、AIを実際に利用した人は、メールに使う時間が週あたり約3時間減り、文書もやや速く完成させる傾向が見られました。一方、他者との調整が必要な会議時間には、有意な変化が確認されませんでした。
これは、AIの価値が小さいという意味ではありません。
個人の単発作業を効率化することと、組織の仕事の流れを変えることは、別の段階だということです。
まずは、自分で完結しやすい仕事でAIの特性を理解する。その後、対話、調査、標準化、自動化へ進む。この順番の方が、失敗の原因を見つけやすく、現場でも無理なく続けられます。
AIに任せる仕事は「簡単そうか」ではなく、失敗を確認できるかで選ぶ
AIは、あらゆる仕事を同じ品質で処理できるわけではありません。
Harvard Business Schoolなどの研究チームは、AIの能力が仕事ごとに不均一である状態を「Jagged Technological Frontier」と呼んでいます。
2026年に査読付き学術誌『Organization Science』へ掲載された研究では、Boston Consulting Groupのコンサルタント758人を対象に、現実的な知識労働の課題を使った実験が行われました。
AIの能力範囲内にある課題では、生産性や成果物の品質が向上しました。一方、能力範囲外の課題では、不正確なAI出力によって人間の成績が下がる場合がありました。
人間には同程度の難しさに見える仕事でも、AI支援が有効なものと、逆効果になるものが混在していたのです。
つまり、AIは「優秀」か「使えない」かのどちらかではありません。
フェーズ1では、次の5つの問いを使って、AIへ任せる仕事を選びます。
AIに渡せる元情報があるか
出力の良し悪しを自分で判断できるか
間違いがあっても修正できるか
出力が外部へ自動反映されないか
重要な専門判断や権利判断を含まないか
取引先へのメールの下書きは、本人が内容を確認してから送信できます。要約も、元資料と見比べれば、重要情報が抜けていないか確認できます。
一方、次のような仕事は、フェーズ1の練習対象には適していません。
法務、医療、税務などの最終判断
顧客への無確認の自動送信
採用や人事評価の自動決定
契約金額や重要条件の確定
最新情報を確認せずに答えさせること
失敗時の影響が大きい業務の完全自動化
これらにAIを使えないという意味ではありません。
ただし、情報源、専門家確認、権限、承認、ログ、停止条件など、単発の文章作成とは別の設計が必要です。それらは後続のフェーズで扱います。
長いプロンプトを作る前に、仕事に必要な5つの情報を揃える
AIへ依頼するとき、「できるだけ長く、詳しく書かなければならない」と考える必要はありません。
OpenAIの一般利用者向け公式ガイドでは、プロンプトに技術的な構文や固定された公式は必要なく、自分の言葉から始めればよいと説明されています。
短い依頼で十分な場合もあり、大きな仕事や重要な仕事では、必要に応じて次の情報を加えるとされています。
何をしてほしいか
役立つ背景や情報源
必要な形式や詳しさ
変更してはいけないことや確認が必要な境界
すべての項目を毎回埋める必要はなく、結果を変える情報だけを使うという考え方です。
GPT-5.6の開発者向け公式ガイドでも、現在のモデルは利用者の意図を以前より推測しやすいため、すべての作業手順を細かく指定する必要はないとされています。
一方、業務固有の背景、厳格な制約、承認範囲、成功条件は、引き続き伝える必要があります。
Googleも、プロンプト設計は一度で完成するものではなく、実際の用途と出力を観察しながら改善する反復的な作業だと説明しています。
Anthropicも、プロンプトを改善する前に、成功条件、評価方法、改善したい初稿を揃えることを推奨しています。また、すべての失敗がプロンプトだけで解決できるわけではないと明記しています。
各社の推奨形式には違いがありますが、共通しているのは、長さではなく、仕事に必要な情報を明確にすることです。
そこで本記事では、単発タスクを依頼するときに確認したい内容を、次の5つに整理します。
この5つは、各AI企業が定めた共通の公式規格ではありません。出力が安定しないときに「何が足りないのか」を確認するための実務用チェックリストです。
目的と利用場面を先に伝えると、残すべき情報が揃いやすい
最初に伝えたいのは、「何を作るか」だけではなく、「何のために使うか」です。
たとえば、単に「文章を短くして」と頼むより、次のように伝えた方が、残すべき情報を判断しやすくなります。
この文章を、会議前に役員が3分で概要を把握するための要約にしてください。同じ資料でも、顧客へ説明する場合、社内会議で使う場合、SNSで紹介する場合では、残すべき情報や言葉の難しさが変わります。
メールなら、相手との関係も重要です。
既存取引先へ、打ち合わせ日程の変更をお願いするメールとして使います。目的や利用場面を伝えることで、AIは文章の長さ、丁寧さ、情報の優先順位を調整しやすくなります。
確認済みの元情報を渡すと、AIによる勝手な補完を減らせる
文章を作らせる前に、AIが使うべき事実を渡します。
たとえば、日程変更のメールなら、最低限必要なのは次のような情報です。
現在の日程
変更後の候補日時
相手の名前
伝えてよい変更理由
必ず残すべき内容
元情報を渡さずに文章だけを作らせると、AIは自然な文章にするために、もっともらしい事情や表現を補う場合があります。
それが単なる言い換えなら問題にならないこともあります。しかし、理由、日付、金額、約束を補われると、業務上の誤りになります。
AIへ文章を作らせる前に、人間が確認した事実を材料として渡す。
これは、フェーズ1で最も重要な習慣の一つです。
してほしい作業を動詞で指定すると、AIの処理がずれにくくなる
AIへ何をしてほしいのかを、動作として伝えます。
たとえば、次の作業は似ていますが、目的が違います。
作成する
要約する
書き換える
抽出する
分類する
比較する
候補を出す
会議メモを「要約して」と頼むと、AIは全体を短くまとめるかもしれません。
しかし、必要なのが業務上の管理情報なら、次のように頼む方が適切です。
会議メモから、決定事項、未決事項、担当者、期限を抽出してください。何をしてほしいのかが曖昧なままでは、文章が自然でも、仕事の目的には合わない出力になり得ます。
一度の依頼へ、異なる作業を詰め込みすぎないことも重要です。
「要約し、問題点を指摘し、改善案を作り、メールにして」と複数の工程を一度に頼むと、どの工程で誤りが生じたのか分かりにくくなります。
フェーズ1では、まず一つの作業へ絞ります。複数工程を構造化する方法は、フェーズ3で扱います。
出力形式を決めると、確認と再利用がしやすくなる
作った文章を、どのような形で返してほしいかを伝えます。
メール形式
社内チャット形式
箇条書き
Markdown
200〜300字
5項目
3案
指定した見出し順
「簡潔に」とだけ頼むより、「200字以内」「重要点を3項目」と伝えた方が、完成条件を確認しやすくなります。
ただし、細かく指定すればするほど良いわけではありません。
実際の利用に必要な形式だけを指定します。使う予定のない表や項目を増やすと、確認作業も増えてしまいます。
制約と確認条件を伝えると、もっともらしい誤りを減らせる
最後に、AIがしてはいけないことや、残すべき条件を伝えます。
変更理由を勝手に追加しないでください。
候補日時を省略しないでください。
不明な情報は推測せず、「要確認」と記載してください。業務によっては、次のような条件も有効です。
元情報にない事実を追加しない
固有名詞や数値を変更しない
必須事項を削除しない
特定の表現を避ける
判断できない箇所を明示する
個人情報を出力へ含めない
過度に断定しない
制約は多ければよいわけではありません。
本当に守る必要があるものへ絞り、同じ内容を何度も繰り返さない方が、依頼全体を理解しやすくなります。
現場では、依頼から利用までを5つの手順に固定すると失敗を見つけやすい
単発タスクを実務へ取り入れるときは、プロンプトだけでなく、依頼前後の流れも決めておくと安定します。
まず、結果を自分で確認できる仕事を一つだけ選ぶ
最初から複数工程をまとめて任せず、メールの初稿、要点抽出、会議メモの整理など、一つの処理へ限定します。
入力前に、機密情報と不要な情報を減らす
目的に必要のない個人情報、顧客情報、社内限定情報は入力しません。
氏名を役職名へ変える、案件名を仮名へ置き換えるなど、必要に応じて情報を最小化します。
5つの情報を使い、完成品ではなく初稿として依頼する
「最終版を作って」ではなく、「確認用の初稿を作って」と明示すると、人間が確認する工程を意識しやすくなります。
元情報へ戻り、影響の大きい項目から確認する
日付、氏名、金額、期限、決定事項など、誤った場合の影響が大きい項目から先に照合します。
使えた条件だけを残し、次回の依頼へ再利用する
毎回使わなかった説明や、結果に影響しなかった条件は削ります。
目標は最も長いプロンプトを作ることではなく、自分の仕事で必要十分な依頼を作ることです。
「いい感じに作って」を、確認できる依頼へ変えてみる
たとえば、次の依頼だけでも、AIはメールを作れるでしょう。
日程変更のメールを、いい感じに作って。しかし、この依頼には、相手、現在の日程、候補日時、理由、文章の長さがありません。
AIは不足情報を質問するかもしれませんが、一般的な日程変更メールを推測して作る可能性もあります。
5つの情報を使うと、次のように書けます。
目的・利用場面：
既存取引先へ、打ち合わせ日程の変更をお願いするメールを送ります。
元情報：
・現在の日程：7月22日 14時
・候補日時：7月23日 10時、7月24日 15時
・変更理由は「社内都合」とだけ伝える
・先方担当者名：〇〇様
してほしい作業：
確認用のメール初稿を作成してください。
出力形式：
件名案を1つと、本文を200〜300字で作成してください。
制約・確認条件：
変更理由を勝手に補足しないでください。
候補日時を省略しないでください。この依頼の利点は、プロンプトが長いことではありません。
AIが何を使い、何を作り、何をしてはいけないかを、人間が確認できることです。
すべての依頼で、5項目を毎回埋める必要はありません。
文章を少し丁寧に書き換えるだけなら、元情報と作業内容だけで十分な場合もあります。
このテンプレートは必須フォームではなく、出力が安定しないときに不足情報を探すための確認表として使います。
仕事の種類に合わせて、依頼の重点を変える
同じ5つの情報を使っても、仕事によって重要度は変わります。
ここでは、現場で使いやすい4つの例を見ていきます。
メールでは、相手・確認済み事実・求める行動を分けて渡す
メールやチャットでは、事実だけでなく、相手、関係性、目的、希望する行動が重要です。
以下の箇条書きをもとに、社内チャット文を作ってください。
目的：
明日の会議資料の提出期限を共有します。
相手：
同じプロジェクトのメンバーです。
元情報：
・提出期限は7月21日17時
・保存先は共有ドライブの「定例会議」フォルダ
・未完成の場合も途中版を保存する
出力形式：
結論を最初に置き、150字以内にしてください。
制約：
期限と保存先を省略しないでください。
初稿ができたら、宛名、日時、金額、固有名詞、相手へ求める行動を確認します。
要約では、誰が何を判断するために読むかを先に決める
要約では、「何文字にするか」だけでなく、「誰が何のために読むか」を伝えます。
経営者向けなら、判断材料やリスクを残す必要があります。担当者向けなら、手順や期限が重要かもしれません。初心者向けなら、専門用語の説明が必要です。
以下の資料を、初めて案件に参加する担当者向けに要約してください。
残す情報：
・案件の背景
・決定済み事項
・未決事項
・担当者が次に行うこと
出力形式：
500字以内。見出しと箇条書きを使ってください。
制約：
原文にない決定事項を追加しないでください。
要約結果は自然に読めるため、重要情報の欠落に気づきにくいことがあります。
要約前に「絶対に残す項目」を決めておくと、確認しやすくなります。
会議メモでは、要約より「誰が何をするか」の抽出が役に立つ
会議メモを単に短くしても、次の行動につながらないことがあります。
現場で使うなら、次のように項目を指定します。
以下の会議メモを、次の項目に分けて整理してください。
・決定事項
・未決事項
・担当者
・期限
・次回確認すること
ルール：
・メモに書かれていない担当者や期限は推測しない
・不明な項目は「未定」とする
・発言と正式な決定を区別する
出力後は、担当者と期限を元メモへ戻って確認します。
人名や日付は、自然な文章よりも業務上の影響が大きい情報だからです。
アイデア出しでは、正解を求めず比較できる候補を増やす
アイデア出しでは、AIに正解を決めさせるのではなく、選択肢を広げるために使います。
新入社員向けのAI研修演習案を5つ出してください。
対象者：
業務でAIを使った経験がほとんどない人
条件：
・機密情報を使わない
・30分以内に完了できる
・メール、要約、情報整理のいずれかを扱う
・各案に目的、手順、完了条件を付ける
避けること：
高度な自動化やプログラミングを前提にしない
出てきた案を採用するかどうかは、人間が目的、実現可能性、リスクを見て判断します。
AIへ「最も良い案を決めて」と丸投げするより、比較可能な候補を出してもらい、人間が選ぶ方がフェーズ1には適しています。
AIが作った文章は、自然さではなく5つの基準で確認する
AIが作る文章は、自然で読みやすいことがあります。
だからこそ、注意が必要です。
文章が自然であることと、内容が正しいことは同じではありません。
AIは、存在しない情報、誤った日付、元資料にない理由を、文章として違和感なく追加する場合があります。
フェーズ1では高度な調査設計までは行いません。まずは、AI出力を使う前に、次の5点を確認します。
元情報へ戻り、日付・氏名・金額・決定事項を照合する
文章全体を何となく読み直すだけでなく、誤った場合の影響が大きい項目を先に確認します。
必須事項が抜けていないか、依頼前の条件と比較する
文章を短くする過程で、期限、条件、注意事項、相手への依頼が消えていないかを確認します。
「何が書かれているか」だけでなく、「書かれるべきだったのに抜けたものはないか」を見ます。
目的・相手・媒体に合っているかを、実際の利用画面で確認する
社外メールとして丁寧か、社内チャットとして長すぎないか、読み手が理解できる言葉になっているかを見ます。
可能なら、メール画面やチャット画面へ貼り付けた状態で確認します。文章だけでは気づかなかった長さや読みにくさが分かります。
AIが追加した事実や理由を見つけたら、削除するか根拠を確認する
もっともらしい説明が、実際に確認された事実とは限りません。
元情報にない内容があれば、そのまま残さず、削除するか別途確認します。
AIが自信ありげに書いているかどうかは、正しさの判定材料にはなりません。
入力・出力してよい情報かを、サービス設定だけでなく社内ルールでも確認する
個人情報、顧客情報、契約情報、未公開情報などを、無判断で入力しないようにします。
データの取り扱いは、サービス、プラン、組織設定によって異なります。
OpenAIの場合、ChatGPT Business、Enterprise、Edu、APIなどのビジネス向けサービスでは、入力と出力を既定でモデル学習へ使わないと説明されています。個人向けChatGPTでも、設定からモデル改善への利用を停止できます。
ただし、モデル学習に使われないことと、どの情報でも入力してよいことは別です。
会社の規程、顧客との契約、アクセス権限、保存場所を確認し、必要に応じて匿名化や情報の最小化を行います。
出力が悪かったときは、AIを諦める前に原因を6つへ切り分ける
期待した初稿が得られなかったとき、すぐに「AIは使えない」と判断すると、改善可能な問題を見落とします。
次の順で確認します。
任せた仕事の範囲が広すぎなかったか
複数の作業や判断が混ざっている場合は、一つのタスクへ分けます。
元情報が不足していなかったか
AIが知るはずのない社内事情、顧客との関係、決定事項を渡していたか確認します。
してほしい作業が曖昧ではなかったか
「整理する」「いい感じにする」ではなく、作成、抽出、分類、比較など、必要な処理を指定します。
出力形式が利用場面に合っていたか
長さ、項目、媒体、案の数など、実際に使う形式を伝えます。
制約を増やしすぎて、依頼同士が矛盾していなかったか
「詳しく」「短く」「すべて含める」など、同時に満たせない条件がないか確認します。
そもそもAIが苦手な仕事ではなかったか
依頼を改善しても安定しない場合は、AIへ任せる範囲を狭めるか、人間中心の作業へ戻します。
すべてをプロンプトで解決しようとしないことも、重要な判断です。
フェーズ1では、まだ無理に高度な機能へ進まなくてよい
AIサービスには、調査、ファイル参照、コード実行、外部サービス操作、エージェント、自動化など、多くの機能があります。
しかし、最初からすべてを使う必要はありません。
フェーズ1では、次の領域へ無理に進まなくて構いません。
AIとの複数回の対話で成果物を改善する
複雑な仕事を工程や完了条件へ分解する
AIを意思決定の相手として使う
Webや一次資料を使って調査する
案件情報を継続的に参照させる
チームの標準手順へ組み込む
AIに外部サービスを操作させる
業務を完全自動化する
高度なAI活用とは、難しい機能を多く使うことではありません。
任せる範囲と、人間が持つ判断を、仕事に合わせて設計できることです。
まず3つの仕事を選び、2週間の小さな実験を行う
AIを仕事に定着させるには、プロンプト集を大量に集めるより、自分の仕事で小さく試す方が有効です。
まず、週に何度か発生する低リスクな仕事を3つ選びます。
社内チャットの文章を整える
会議メモを項目別に整理する
長い資料から要点を抜き出す
メールの初稿を作る
難しい文章を分かりやすく書き換える
選定時は、次の条件を満たすものを優先します。
自分が元情報を持っている
良否を自分で判断できる
週に複数回発生する
間違えても送信前に修正できる
作業時間を測りやすい
1週目は、同じ仕事を複数回試して失敗パターンを集める
最初から完璧なテンプレートを作ろうとせず、3〜5件ほど実際に試します。
出力が悪かった場合は、原因を記録します。
元情報不足
目的不足
作業指定のずれ
形式のずれ
事実の追加
情報の欠落
AIに向かない仕事
2週目は、効果のあった指示だけを残して再利用する
1週目の結果から、品質へ影響した条件だけを残します。
毎回使わなかった条件や、結果に影響しなかった長い説明は削ります。
目標は、最も長いプロンプトを作ることではありません。
自分の仕事で、必要十分な依頼を再利用できるようにすることです。
AI利用の効果は「使った回数」ではなく、時間・品質・修正量で測る
2週間の実験では、次の項目を記録します。
対象業務：
実施日：
AIを使わない場合の所要時間：
AIを使った場合の所要時間：
AI出力の確認・修正時間：
事実誤り：
必要情報の欠落：
AIが追加した内容：
最終成果物へ採用したか：
次回変更する指示：
この仕事でAI利用を続けるか：
AIが初稿を5分で作っても、その後の確認と修正に20分かかり、人間だけなら15分で終わるなら、現時点では効率化できていません。
一方、作業時間が少ししか短縮されなくても、抜け漏れが減ったり、複数案を比較しやすくなったりする場合は、品質面の価値があります。
見るべきなのは、単純な生成速度だけではありません。
合計時間は減ったか
修正量は減ったか
必須事項の欠落は減ったか
成果物の品質は安定したか
確認作業が過剰になっていないか
5回程度試しても、時間、品質、確認負担のいずれも改善しない場合は、依頼をさらに限定するか、その仕事ではAIを使わない判断も必要です。
現場でそのまま使える、単発タスクの依頼テンプレート
次のテンプレートは、すべて埋めるためのフォームではありません。
出力が安定しないときに、不足している情報を確認するために使います。
目的・利用場面：
この成果物を、誰が、何のために、どこで使うか
元情報：
AIが使うべき確認済みの事実、文章、メモ
してほしい作業：
作成、要約、抽出、分類、書き換え、候補提示など
出力形式：
文字数、項目、媒体、形式、案の数
制約・確認条件：
追加してはいけない事実、残すべき情報、避ける表現、不明時の扱い
依頼後は、次の確認テンプレートを使います。
元情報と一致しているか：
必須事項が抜けていないか：
目的・相手・媒体に合っているか：
AIが事実や理由を追加していないか：
入力・出力してよい情報か：
この二つを組み合わせるだけでも、単発タスクの利用はかなり安定します。
フェーズ2へ進む目安は、出力への違和感を具体的に説明できること
次の状態になったら、フェーズ2「対話による改善」へ進む準備ができています。
単純な仕事で、実用可能な初稿を得られる
出力の問題点を具体的に説明できる
AIが追加した事実を見分けられる
用途に合わせて出力形式を指定できる
AI利用前後の時間や修正量を把握している
「もっと良くして」以外の修正指示を出せる
AIに向かない仕事では、無理に使わない判断ができる
フェーズ1では、AIへの一回の依頼で初稿を作りました。
しかし、実際の仕事では、最初の出力だけで十分とは限りません。
次のフェーズでは、AIへ不足情報を質問させる、初稿を批評させる、複数案を比較する、必要な部分だけ差分修正するといった、対話によって成果物の品質を高める方法を扱います。
関連記事
AI成果を、モデルの性能だけでなく、要件、情報、実行方法、評価、権限から捉えるための基本構造を整理しています。
AIへ任せる範囲と、人間が保持すべき採否、停止、回復、責任の境界を詳しく考察しています。
AI活用成熟度12フェーズ
出典・参考資料
OpenAI, “Prompting”
https://learn.chatgpt.com/docs/promptingOpenAI, “Model guidance: Using GPT-5.6”
https://developers.openai.com/api/docs/guides/latest-modelOpenAI, “Enterprise privacy at OpenAI”
https://openai.com/enterprise-privacy/OpenAI, “Data Controls FAQ”
https://help.openai.com/en/articles/7730893-data-controls-faqAnthropic, “Prompt engineering overview”
https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overviewGoogle AI for Developers, “Prompt design strategies”
https://ai.google.dev/gemini-api/docs/prompting-strategiesDell’Acqua et al., “Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of Artificial Intelligence on Knowledge Worker Productivity and Quality,” Organization Science, 2026
https://doi.org/10.1287/orsc.2025.21838Dillon et al., “Shifting Work Patterns with Generative AI,” Microsoft Research, 2025
https://www.microsoft.com/en-us/research/publication/shifting-work-patterns-with-generative-ai/
