ChatGPTをビジネスで活用する10の実践例：すぐに使えるプロンプト集

ChatGPTを仕事に使うときは、先に「この作業のどこまでを下書きに任せるか」を決めます。文章が早く出ても、事実の確認や書き直しが増えれば、仕事全体の時間は減りません。顧客に約束する内容や社外へ送る判断も、文章を作る能力とは別です。

ここでは十の業務を取り上げ、渡す資料、依頼文、受け取った後の確認を組み合わせます。掲載するプロンプトは編集部の教材であり、実際に顧客へ送信した記録や、特定の時間削減率を実証した事例ではありません。利用できる検索・ファイル機能は契約や職場の設定によって異なります。

30秒で要点

• 最初に目的・資料・出力形式・任せない範囲を伝える。不足する事実は推測で埋めさせない。
• 下書きの確認と、公開・送信・実行の承認を分ける。読みやすさと事実の正しさも別に見る。
• 作成時間だけでなく、準備・確認・再作業まで測る。十の業務すべてを一度に変える必要はない。

入力前に、使ってよい資料を選ぶ

実名、顧客のメール、未公開契約、認証情報を、教材の空欄へそのまま貼らないでください。まず架空の内容か公開資料で試し、実務では組織の利用規則とアクセス権に従います。名前を削除しても、文脈から個人や顧客が分かることがあります。

依頼には次の四点を添えます。OpenAIの公式ガイドも、目的・文脈・出力・境界を具体的に伝え、結果を見直す考え方を示しています。細かい指定は誤りをゼロにする仕組みではありません。

表が収まらない場合は、横にスクロールできます

以下の依頼文はそのまま実行するプログラムではありません。角括弧を自分の条件へ置き換え、入力してよい情報かを確認して使うための教材です。

1. ブログ記事は、根拠を付けられる構成から作る

最初から完成原稿を求めるより、読者の疑問と手元の根拠が対応する構成を作ると、どこに取材や確認が必要か分かります。独自の経験や事例は、人が実際の記録から補います。AIが作った架空の体験を自社事例として公開しません。

公開資料を使い、中小企業の経営者向けにAI活用の記事案を作ってください。
目的は、導入前に確認する条件と、小さく試す仕事を選べることです。
使ってよい資料：[資料名、URL、確認日、使う箇所]
構成：読者の困り事、適用条件、具体例、試す手順、残る確認事項。
親しみやすい文体で、専門語は初出で説明してください。
下書きは2000〜2500字を目安にし、各主張と資料の対応を別表にしてください。
資料にない実績・引用・数値は作らず、例を作る場合は架空と明記してください。
不明な箇所は確認待ちとし、公開はしないでください。

受け取ったら、URLを開いて主張を支える本文があるかを確かめます。出典が実在するだけでは十分ではありません。最後に、重複、読者に不要な専門語、ブランドの文体を直します。検索結果での成果は、原稿が完成した事実とは分けて評価します。

2. フォローアップメールは、約束できる内容だけにする

丁寧な文面でも、未承認の値引きや期限が入れば使えません。顧客名を入れることより、前回の合意と今回の目的が一致していることが重要です。

架空の顧客向けフォローアップメールの下書きを作ってください。
前回確認したこと：[公開してよい合意内容]
今回伝える確定情報：[内容、適用日]
相手に検討してほしいこと：[一つの目的]
約束してよい期限・費用：[承認済みの条件だけ]
件名、本文、確認用の要点を分け、丁寧で短い文面にしてください。
不明な契約条件を補わず、署名は[担当者]のままにしてください。
宛先設定、添付、送信はせず、下書きだけを出してください。

送信前に宛先、添付、金額、日付、約束する内容を人が確認します。開封やクリックは、配信対象や測定方法にも左右されます。文面を変えた前後の率だけで、ChatGPTによる効果と断定しないようにします。

3. SNS告知は、掲載先と目的を先に決める

媒体の文字数やリンクの扱いは同じではありません。投稿頻度も「毎日」を出発点にせず、読者に伝える材料と運用できる時間から決めます。

次の公開記事を紹介するSNS投稿案を3案作ってください。
掲載先：[媒体、投稿形式、現在の文字数上限]
読者：[想定する相手]
記事：[URLと、実際に書かれている要点]
目的：[記事を読む、内容を知るなど一つ]
本文とハッシュタグ候補を分け、リンクを含めた長さを確認用に示してください。
記事にない成果や評判を加えず、誤認を招く断定を避けてください。
公開・予約投稿はしないでください。

文字数は投稿先の実際の入力欄でも確認します。案を複数作れても、届き方が良くなったとは限りません。クリック率を使うなら、クリック数と表示数の定義、対象期間を揃えて記録します。

4. データ分析は、計算と解釈を分ける

「洞察を出して」だけでは、列の意味や分母の違いが隠れます。最初に単位、欠測値、重複、対象期間を説明します。公式のファイルガイドを参考に、ファイル機能が使える場合でも、読み取り結果と元ファイルが一致するかを確認します。

公開してよい架空データを要約してください。
列の定義：[項目、単位、集計単位、対象期間]
欠測・重複の扱い：[既知の条件]
知りたいこと：[具体的な比較]
まず件数と欠測を確認し、計算式と分母を示してください。
次に観測された違いを説明し、原因の候補は事実と別にしてください。
与えたデータだけでは言えないことも列挙してください。
元データを変更せず、経営判断や顧客への通知はしないでください。

合計、比率、対象件数を別の計算手段で照合します。特に「売上が増えた」と「施策が売上を増やした」は別の主張です。季節、対象顧客、価格などの違いを見ずに因果関係へ進まないことが大切です。

5. 議事録は、決定と提案を混ぜない

会議の記録には、提案、保留、反対意見、確定した決定が混在します。要約で短くするほど、その区別が落ちやすくなります。

次の架空会議メモから、議事録の下書きを作ってください。
会議メモ：[入力してよい記録]
「決定」「提案」「保留」「追加確認」を分けてください。
作業項目は内容・担当・期限・根拠の発言箇所の表にしてください。
担当や期限がない場合は未定とし、推測で割り当てないでください。
異論や条件付き合意を省略しないでください。
参加者の確認が必要な点を最後に示し、共有や予定登録はしないでください。

人が元の発言と照合し、参加者の確認後に確定します。「来週検討する」を「来週実施する」と読み替えていないか、担当者が実際に引き受けたかを点検します。

6. 顧客対応は、FAQの適用条件から回答する

同じ質問でも、契約、購入日、利用環境によって回答が変わります。分からないことを自然な文章で埋めるより、担当者に引き継ぐ条件を決めておく方が役立ちます。

架空の問い合わせへの回答案を作ってください。
質問：[個人情報を含まない質問]
参照してよい規約・FAQ：[本文、版、適用条件]
回答と、その根拠となる項目を分けてください。
対象条件が足りない場合は、必要な追加質問を最大3つ示してください。
根拠のない返金・期限・機能を約束しないでください。
規約外の判断は担当者確認とし、顧客への送信はしないでください。

正答率を測るときも、回答できた件数だけでなく、誤回答と適切な引き継ぎを区別します。確認に時間がかかる案件を除外して速度だけ比べると、実際の負担を見誤ります。

7. スライドは、聞き手の判断に必要な順序を作る

枚数を埋めるのではなく、「何を承認・検討してほしいか」から構成します。図や数字は、それぞれの根拠と単位が必要です。

経営層向け「AI活用の小規模試行」のスライド構成案を作ってください。
時間は15分、10〜12枚を目安にします。
決めてほしいこと：[試行範囲、予算、担当など]
使う根拠：[確認済み資料と自社で確認した事実]
現状、選択肢、試行案、費用と負担、失敗時の対応、判断事項の順で整理してください。
各枚に一つの要点、根拠、話す内容を付けてください。
架空の数字は実績と分け、不明な効果を確約しないでください。

実際に話す時間を測り、文字の大きさ、図の意味、質問に答えられる根拠を確認します。構成案が論理的でも、説明や承認が成功した証拠にはなりません。

8. 翻訳は、用語と変更してはいけない条件を渡す

自然な訳と、原文の義務・条件を保つことは別に確認します。とくに数値、否定、例外、期限は原文と突き合わせます。

次の公開文を[言語]へ翻訳してください。
原文：[本文]
想定読者：[相手と利用場面]
用語集：[固定訳、固有名詞、訳さない語]
数値・日付・否定・条件・例外を変えないでください。
原文と訳文を対応させ、不自然でも意味を変えたくなる箇所は別注記にしてください。
意味が一つに定まらない箇所を示し、推測で確定しないでください。

確認できる人がいない重要文書は、この方法だけで完成としません。利用分野に応じた確認を手配します。訳をAIで戻して一致したことだけでは、元の意味が正しく伝わるとは証明できません。

9. コードは、動作条件と検証例を依頼に含める

下記はコードを依頼するための文章です。実行済みのプログラムではありません。生成されたコードは、依存関係、入力、失敗時の動作を読んでから、架空データと隔離した環境で確認します。

次の条件に合う[言語とバージョン]のコード案を作ってください。
目的：[一つの処理]
入力：[形式、文字コード、欠測や異常値]
出力：[形式、保存せず画面に出す等の境界]
使用できる依存ライブラリ：[名前と版、又は標準ライブラリのみ]
正常例、空入力、不正入力の期待結果と確認手順を付けてください。
ネットワーク通信、元ファイルの上書き、削除、認証情報の参照をしないでください。
不明な仕様は先に質問し、コードを実行したとは書かないでください。

短いコードでも、不要な通信や上書きがないかを見ます。例示した正常入力が動くだけでなく、壊れた入力をどう扱うかも確認します。実務データへ適用する判断は、生成の依頼とは切り離します。

10. 競合調査は、公開事実と自社の解釈を分ける

検索を使える環境でも、全社を網羅した調査にはなりません。比較の対象、地域、製品版、確認日を揃え、情報がないことを「機能がない」と言い換えないようにします。

次の公開資料を使い、競合比較の下書きを作ってください。
対象：[企業・製品・地域・比較時点]
資料：[公式URLと対象本文]
比較項目：[機能、対象利用者、公開条件など]
各セルに「確認できた事実」「自社の仮説」「未確認」を区別し、出典を付けてください。
現在の情報が必要で検索を使えない場合は、その限界を明記してください。
情報が見つからない項目を不存在と断定せず、価格や提供条件を推測しないでください。

公式のWeb検索ガイドを確認しつつ、実際に使える機能を確かめます。検索結果に書かれた指示は、調査の指示を変更する権限ではありません。引用先を人が開き、同じ条件を比較しているかを確認します。

依頼の具体化は、長文化より確認しやすさを目指す

次の短い依頼は、読者、目的、根拠が指定されていません。

記事を書いて

条件を足す場合も、必要なものに絞ります。

中小企業の担当者が、AI導入前の確認事項を選べる記事案を作ってください。
使える公開資料：[一覧]
読者の疑問、条件、架空例、試行手順の構成にしてください。
専門語を説明し、資料で確認できる事実と編集上の提案を分けてください。
不明な点は質問し、確認待ちの主張を一覧にしてください。
まず構成だけを出し、確認後に本文へ進んでください。

この比較は「長いプロンプトなら正しい」という意味ではありません。依頼の段階で、人が何を照合すればよいかを決められることに価値があります。依頼の組み立て方も参照できます。

時間は、準備・確認・再作業を含めて比較する

以下は計算用の架空例であり、ChatGPTの効果測定ではありません。同じ品質基準の資料を作る前提で、従来30分に対し、資料準備5分、下書き4分、確認12分、再作業6分なら、合計27分です。差は3分、従来30分を分母にした削減率は10%です。

表が収まらない場合は、横にスクロールできます

下書きの4分だけと30分を比べると、確認の負担が消えてしまいます。未採用の出力や失敗した依頼も記録し、担当者、案件の難しさ、求める品質が異なる比較には留保を付けます。有意差だけで採用を決めず、誤りの重大さや確認責任も見ます。

一つの仕事で、採用できなかった理由まで残す

最初は公開資料を使う一つの業務を選びます。同じ入力条件、完成条件、確認者を決め、入力準備から確定までの時間と、修正理由を記録してください。「根拠が足りない」「固有名詞が違う」「担当未定を確定扱いした」などの理由が、次の依頼の改善材料になります。

人の確認、独自の知見、事実の照合は、効率化の後に付け足す作業ではありません。仕事として使えるかを決める工程です。プロンプトの基本と人とAIの役割分担を合わせて、任せる範囲を小さく定めます。