DeepSeekプロンプトの書き方｜基本構造と業務別例文10選

DeepSeekで業務に使える回答を得るには、長い指示を書くことよりも、「何をするか」「何を前提にするか」「何を守るか」「どの形式で返すか」「何を確認するか」を分けて記載することが重要です。

現行のDeepSeek APIでは、DeepSeek-V4-ProとDeepSeek-V4-Flashが提供され、モデル名とは別にThinkingとNon-thinkingを切り替えられます。そのため、DeepSeek-R1向けに広まったプロンプト設計を、現在の環境へそのまま適用するのは適切ではありません。

本記事では、DeepSeekプロンプトの基本構造、ChatGPT・Claude・旧R1向けプロンプトとの違い、業務別例文10選、改善方法、失敗対策、チーム運用、導入判断の順に整理します。プロンプトを工夫しても、事実の正確性や情報管理を完全には保証できません。一次情報との照合や、利用環境の審査と組み合わせて運用することが前提です。

DeepSeekプロンプトの基本とV4で変わった設計前提

DeepSeekプロンプトを業務で設計する際は、文章表現の工夫だけでなく、利用モデル、Thinking設定、実行環境を分けて考える必要があります。まず、プロンプトの役割と現行V4の前提を整理します。

DeepSeekプロンプトは回答の目的・条件・形式を伝える指示文

DeepSeekプロンプトとは、DeepSeekに実行させる作業、判断に使う情報、守る条件、返してほしい形式を伝える入力文です。単なる質問ではなく、業務で利用できる成果物を作るための仕様書と捉えると設計しやすくなります。

たとえば「この資料を要約して」だけでは、対象読者、利用目的、残すべき情報、文字数、出力形式が不明です。同じ資料を入力しても、担当者が期待する結果とDeepSeekが生成する結果にずれが生じやすくなります。

業務用のプロンプトでは、次のように成果物の利用可能な状態まで定義します。

• タスク：資料を要約する
• 対象読者：経営会議の参加者
• 用途：投資判断前の論点整理
• 必須項目：結論、根拠、リスク、未確認事項
• 出力形式：800字以内、見出し付き
• 検証条件：資料にない数値は補完しない

プロンプトはAIへの入力文、コンテキストは回答判断に使う背景情報、トークンはモデルが文章を処理する単位です。専門用語を増やすことより、これらの役割を区別することが重要です。

現行DeepSeek V4におけるモデル名とThinkingモードの分離

2026年4月に公開されたDeepSeek V4のAPIでは、`deepseek-v4-flash`と`deepseek-v4-pro`が案内されています。両モデルはThinkingとNon-thinkingの双方に対応し、Thinkingは初期状態で有効です。

旧来の`deepseek-chat`と`deepseek-reasoner`は、V4-FlashのNon-thinking／Thinkingへ接続する互換名として扱われた後、2026年7月24日15時59分（UTC）に廃止予定と案内されていました。新規のプロンプト設計では、V4のモデル名と設定を基準にする必要があります。

モデル選択とThinking設定は別の判断軸です。V4-Flashを選んでもThinkingは利用でき、V4-Proを選んでもNon-thinkingへ切り替えられます。

モデル	Thinking	初期候補となるタスク	確認項目
V4-Flash	Non-thinking	文体修正、分類、形式変換、定型メール	形式準拠、速度、修正時間
V4-Flash	Thinking	中程度の比較、要因整理、一般的な計画	品質改善幅、出力トークン
V4-Pro	Non-thinking	高品質な文章生成、複雑でない専門文書	Flashとの差、費用対効果
V4-Pro	Thinking	複数条件の分析、複雑な計画、エージェント処理	正確性、時間、総コスト

単純な文章整形や定型分類でThinkingを常時利用すると、必要以上に処理時間や出力トークンが増える可能性があります。一方、複数条件の比較や原因分析では、Thinkingによって回答品質が改善する場合があります。タスクごとに同じ評価データを使い、品質・時間・トークン数を比較することが必要です。

Webチャット・API・自社管理環境による管理方法の違い

DeepSeekのプロンプトは、利用環境によって管理方法が変わります。Webチャットでは、目的・背景・条件・出力形式を入力欄へまとめて記載するのが基本です。

APIでは、恒常的な役割や共通ルールをSystem message、個別の依頼や入力データをUser messageへ分けられます。さらにThinking、出力トークン、JSON形式などのパラメータを自然言語のプロンプトと組み合わせて制御します。

自社管理のローカル環境では、使用モデル、量子化方式、推論設定、チャットテンプレートなどによって挙動が変わります。公式Web版と同じ名称のモデルを利用しても、同じ回答になるとは限りません。

プロンプト例を再利用するときは、次の前提を確認します。

• 対象モデル
• モデルのバージョン
• Webチャット、API、ローカルの別
• Thinkingの有無
• System messageの利用有無
• JSON Outputなどの実行パラメータ

「どの環境・モデル・設定を前提とした例か」を記録することが、再現性の出発点です。

DeepSeekプロンプトを業務で整備するメリットと限界

プロンプトの構造化は、担当者の文章力を高める施策ではありません。業務品質を再現し、評価しやすくするための運用設計です。一方、正確性や情報管理には別の対策が必要です。

再現性・再利用性・検証性を高める3つのメリット

1つ目のメリットは再現性です。目的、条件、出力形式を固定すると、担当者ごとの指示の差を小さくできます。同じ入力に対して同じ観点の回答を得やすくなり、レビュー時の比較も容易です。

2つ目は再利用性です。入力箇所を`[対象読者]`、`[元資料]`、`[期限]`などの変数にすれば、議事録整理、メール作成、問い合わせ分類などの反復業務へ転用できます。

3つ目は検証性です。期待結果や確認条件を明文化すれば、出力を合格、修正、不採用に分けられます。「良い文章が出た」という主観ではなく、文字数、必須項目、禁止事項、事実一致、修正時間などの基準で比較できます。

正確性・データ品質・利用環境に対する限界

プロンプトを詳細にしても、モデルが保持していない情報や、入力資料に含まれない事実を正しく補完できるとは限りません。誤ったデータを入力すれば、整った形式のまま誤った結論が返る可能性もあります。

必要情報が資料に存在しない場合は、一次情報、社内データ、検索、RAGなどの情報供給が必要です。RAGとは、外部資料を検索して回答時に参照させる仕組みです。

また、機密情報の保護、アクセス制御、ログ管理は、プロンプト内に「漏えいしないこと」と書いても実現できません。契約条件、利用環境、認証、権限、監査ログなどのシステム側の管理が必要です。

業務利用では、プロンプト改善、データ整備、システム制御、人による確認の4層を組み合わせます。

DeepSeekプロンプトとChatGPT・Claude・旧R1向けプロンプトの違い

主要な生成AIでは、プロンプトの基本構造を共通化できます。ただし、推論設定、構造化出力、モデル固有のAPI仕様は分離して管理する必要があります。

ChatGPT・Claudeから再利用できるプロンプトの5要素

DeepSeek、ChatGPT、Claudeでは、次の5要素を共通の基本構造として利用できます。

• Task：実行する作業
• Context：判断に使う背景・参照情報
• Constraints：制約・禁止事項・優先順位
• Output：出力形式
• Verification：確認項目・合格条件

「誰に向けた成果物か」「何のために使うか」「どの資料だけを根拠にするか」などの業務情報は、モデルを変更しても原則として再利用できます。箇条書き、Markdown、表、JSONなどの出力指定も転用できます。

ただし、厳密なJSON出力やツール呼び出しでは各APIの仕様確認が必要です。プロンプト本文と、モデル名、Thinking、出力形式パラメータを分離すると、他モデルへ移行しやすくなります。

比較軸	DeepSeek	ChatGPT／OpenAI API	Claude／Anthropic API
共通要素	Task、Context、Constraints、Output、Verification	同左	同左
推論設定	Thinkingの切り替えと強度設定	モデル・API仕様に応じた推論設定	Extended Thinking等の仕様確認
System指示	APIで利用可能	APIで利用可能	System Promptで利用可能
構造化出力	JSON Outputとプロンプト指定を併用	Structured Outputs等の仕様確認	Tool useやJSON設計の仕様確認
移行時の要点	モデル名、Thinking、response_formatを分離	モデル固有設定を分離	モデル固有設定を分離

DeepSeek V4で個別確認が必要なThinking設定とAPI仕様

DeepSeek V4では、Thinkingの有効・無効と推論強度を設定できます。初期検証では、文体修正、単純分類、定型メール、形式変換をNon-thinking、複数条件の比較、原因分析、計画策定をThinkingの候補にします。

JSON Outputでは、自然言語で「JSON形式」と指示するだけでは不十分です。公式ドキュメントでは、`response_format`を`json_object`へ設定し、プロンプト内にJSONという語と出力例を含め、途中切断を避けるために十分な`max_tokens`を設定するよう案内しています。

同じプロンプトを複数モデルへ送る場合は、回答品質だけでなく、処理時間、出力トークン、形式違反率、修正時間を比較します。

旧R1向け推奨とV4での判断の切り分け

DeepSeek-R1の公式リポジトリでは、温度を0.5～0.7にする、System Promptを避けて指示をUser Promptへまとめる、数学問題では段階的な推論を促すといった推奨が示されていました。

これらはR1シリーズと当時の評価条件を前提とした推奨です。V4の全利用環境へ適用する恒久的な規則ではありません。現行Chat Completion APIはSystem messageを受け付け、公式のJSON Output例でもSystem Promptが使用されています。

例示についても一律には判断できません。論理問題ではゼロショットから試し、文体、分類、JSON形式など期待形を説明しにくいタスクでは短い例を付けて比較します。

「DeepSeekでは常に短い方がよい」「例を入れてはいけない」と固定せず、同じ評価データによる結果を基準に判断します。

DeepSeekプロンプトの書き方6ステップ

業務用プロンプトは、Task、Context、Constraints、Output、Thinking、Verificationの順に組み立てると、抜け漏れを抑えられます。

ステップ1｜タスクと完成条件の限定

プロンプトの先頭では、「要約する」「比較する」「分類する」「修正する」など、実行する作業を明記します。ただし、「分かりやすくする」のように完成形が不明な表現は避けます。

悪い例：
「この議事録を分かりやすく整理してください。」

改善例：
「経営会議向けに、議事録から決定事項、未決事項、担当者、期限を抽出してください。資料に記載がない項目は『記載なし』としてください。」

1回のプロンプトでは、主要タスクを1つに絞ります。調査、分析、執筆、校正が混在する場合は工程を分けます。

テンプレート：

• タスク：[実行する作業]
• 対象読者：[成果物を読む人]
• 用途：[利用場面]
• 完成条件：[必須項目・合格基準]

ステップ2｜背景と参照情報の提供

対象企業、商品、顧客、業務目的、既に決まっている事項をコンテキストとして渡します。要約や分析では、使用してよい資料を明確に区切り、資料外の知識を使ってよいか指定します。

長い資料を入力する場合は、指示と資料を混在させず、タグや区切り線を使います。

例：
「以下の資料だけを根拠に分析してください。資料外の知識は使用せず、不足情報は『確認できない』と記載してください。
<reference>
[元資料]
</reference>」

最新情報が必要な場合は、対象期間、確認日、使用可能なURLを明記します。関係のない背景を大量に追加すると重要条件が埋もれるため、判断に必要な情報へ絞ります。

ステップ3｜制約・禁止事項・優先順位の明示

文字数、文体、対象読者、使用言語、必須項目、除外項目を箇条書きで指定します。抽象的な禁止ではなく、実行可能な行動へ変換することが重要です。

悪い例：
「専門用語を使わないでください。」

改善例：
「専門用語は必要な場合のみ使用し、初出時に20字以内の補足を付けてください。」

条件が競合する場合は、「正確性を簡潔さより優先する」のように優先順位を明記します。不明な情報を推測しない、根拠のない数値を作らないなどの安全条件も加えます。

禁止事項を増やしすぎると、条件同士の競合が起こります。重要な禁止事項に絞り、可能であれば代替行動も指定します。

ステップ4｜完成形に近い出力形式の指定

「表で出力」ではなく、列名まで指定します。

例：
「評価項目、現状、課題、推奨対応、担当部門の5列でMarkdown表を作成してください。」

文章では見出し構成、箇条書き数、文字数を指定します。JSONではキー名、値の型、必須項目、分類不能時の値を定義します。

APIで機械処理する場合は、自然言語の指定だけでなくJSON Outputを併用します。出力例を付ける場合は、内容を模倣させる長い例ではなく、形式を伝える短い例にします。

ステップ5｜タスクに応じたThinkingモードの選択

文体修正、単純分類、フォーマット変換、定型要約は、まずNon-thinkingで品質と速度を確認します。複数制約を満たす計画、比較評価、数値分析、原因仮説の検討ではThinkingを試します。

Thinkingを有効にしても、正確性が保証されるわけではありません。入力情報と検証条件が不足していれば、推論を増やしても正しい根拠は得られません。

API利用では、Thinkingの有無、推論強度、出力トークン、処理時間を記録します。「順を追って考えて」とプロンプトに書くことと、APIのThinking設定は別の仕組みです。

ステップ6｜回答前チェックと再実行条件の設定

回答前に、必須項目、文字数、事実と推測の区別、出力形式を確認するよう指示します。不足情報がある場合は、推測して完成させず、不足項目を列挙させます。

「正しいか確認する」ではなく、照合項目を具体化します。

例：
「回答前に次を確認してください。

1. 必須項目がすべて含まれている
2. 数値は参照資料と一致している
3. 推測には『推測』と表示している
4. 指定した表の5列を満たしている

不足がある場合は回答を完成させず、不足項目を列挙してください。」

最初の回答を別プロンプトでレビューさせる方法もあります。ただし、重要業務では人が原典と照合します。同じ条件で複数回生成して結果が大きく変わる場合は、プロンプトまたは評価基準を見直します。

汎用テンプレート：
「Task [実行する作業]
Context [対象・目的・参照資料]
Constraints [文字数・文体・必須項目・禁止事項・優先順位]
Output [見出し・列・JSONキー・出力順]
Verification [照合項目・不足時の処理・合格条件]」

DeepSeekプロンプトの業務別例文10選

以下では、BtoB業務で利用頻度の高い10種類のプロンプトを紹介します。角括弧の部分を自社の条件へ置き換えて使用します。

文書要約・議事録整理のプロンプト例2選

例文1｜社内資料の要約
「Task
以下の資料を[対象読者]向けに要約してください。

Context
利用目的は[利用目的]です。
<reference>
[元資料]
</reference>

Constraints

• 資料内の情報だけを使用する
• [文字数]字以内
• 数値、固有名詞、期限を省略しない
• 資料にない情報を補完しない

Output

1. 結論
2. 重要な根拠
3. リスク
4. 次の確認事項

Verification
資料内の数値と回答内の数値を照合し、不一致があれば出力前に修正してください。」

例文2｜会議議事録の整理
「以下の議事録を業務フォロー用に整理してください。

抽出項目：

• 決定事項
• 未決事項
• 担当者
• 期限
• 次回確認事項

条件：

• 発言者、担当者、期限が記載されていない場合は『記載なし』とする
• 推測で担当者や日付を補完しない
• 同じ内容の発言は統合する
• 各項目をMarkdown表で出力する

議事録：
[議事録本文]」

単純な整形ではNon-thinkingを初期選択とし、複数の論点や矛盾を整理する場合はThinkingも比較します。

メール・提案書作成のプロンプト例2選

例文3｜取引先メールの作成
「[取引先名]へ送るメールを作成してください。

関係性：[初回連絡／既存顧客／協力会社]
伝える事実：[事実]
依頼内容：[依頼]
期限：[期限]
避けたい表現：[表現]

出力：

1. 件名
2. 本文
3. 送信前の確認事項

条件：

• 存在しない日付や条件を補完しない
• 敬語は過度に重ねない
• 依頼内容と期限を明確にする
• 300～500字とする

」

例文4｜社内提案書の構成作成
「以下の情報から、社内提案書の構成案を作成してください。

目的：[目的]
現状：[現状]
制約：[予算・期限・人員]
根拠資料：[資料]
意思決定者：[役職]

出力項目：

• 現状
• 課題
• 原因仮説
• 施策
• 効果指標
• リスク
• 必要な意思決定
• 想定反論
• 反論への回答案

前提と事実を分け、根拠がない効果は数値化しないでください。」

調査・比較・企画立案のプロンプト例2選

例文5｜提供資料に基づく市場調査
「以下の資料だけを根拠に、[市場]を調査してください。

対象期間：[期間]
調査項目：[項目]

参照資料：
<reference>
[資料]
</reference>

出力は『事実』『推測』『不足情報』を分けてください。
資料内にない市場規模、企業名、数値は作らず、『資料内で確認できない』と記載してください。
各事実に参照資料名と該当箇所を付けてください。」

例文6｜複数施策の比較
「[施策A]、[施策B]、[施策C]を比較してください。

評価基準と重み：

• 期待効果：[重み]
• 実行難易度：[重み]
• 費用：[重み]
• 導入期間：[重み]
• リスク：[重み]

制約：
[予算・期限・人員・禁止条件]

出力：

1. 評価表
2. 推奨案
3. 採用条件
4. 選ばなかった案の不採用理由
5. 追加で必要な情報

不明な数値は推測せず、定性的に評価してください。」

複雑な比較ではThinkingを試し、最終回答には判断根拠を簡潔に残します。

データ整理・構造化出力のプロンプト例2選

例文7｜CSVデータの確認
「以下のCSVデータを確認してください。

列の定義：
[列名と意味]

確認条件：

• 欠損値：[扱い]
• 除外条件：[条件]
• 異常値：[基準]
• 計算式：[式]

出力：

1. 集計結果
2. 異常値一覧
3. データ上の注意点
4. 追加確認項目

計算に使用した列と式を明記し、定義が不明な列は推測しないでください。

CSV：
[データ]」

例文8｜問い合わせ内容のJSON分類
「問い合わせ文を次の分類ラベルへ分類し、JSONで出力してください。

許可ラベル：

• product
• billing
• technical
• contract
• other

JSON形式：
{
“category”: “許可ラベルのいずれか”,
“confidence”: 0.0,
“reason”: “50字以内”,
“needs_human_review”: true
}

分類不能時はcategoryをother、needs_human_reviewをtrueにしてください。
JSON以外の文章は出力しないでください。

問い合わせ文：
[本文]」

APIでは、`response_format`、JSONという語、出力例、十分な`max_tokens`を組み合わせます。構文が正しいことと、値が業務ルールに合うことは別々に検証します。

コード修正・プロンプト改善のプロンプト例2選

例文9｜コードの不具合修正
「以下のコードの不具合原因を特定し、最小変更で修正してください。

実行環境：[OS・言語・バージョン]

現在のコード：
[コード]

エラー：
[エラーメッセージ]

期待する動作：
[期待結果]

変更禁止範囲：
[範囲]

テスト条件：
[条件]

出力順：

1. 原因候補
2. 最小変更案
3. 修正コード
4. テスト手順
5. 残るリスク

確認できない依存関係は推測せず、追加で必要な情報を列挙してください。」

例文10｜既存プロンプトの改善
「以下のプロンプトを改善してください。

現在のプロンプト：
[プロンプト]

期待結果：
[期待結果]

実際の問題：
[冗長／形式違反／抜け漏れ／事実誤認など]

変更可能範囲：
[範囲]

次を確認してください。

• 曖昧な指示
• 競合する条件
• 不足した背景
• 評価不能な条件

出力：

1. 問題点
2. 改善後のプロンプト
3. 変更点
4. テスト項目

元の目的を変更せず、追加した条件の理由を説明してください。」

DeepSeekプロンプトの精度を高める改善方法

回答が期待と異なる場合、プロンプト全体を書き直すのではなく、症状から原因候補を絞ります。修正対象は、プロンプト、入力情報、実行設定、評価方法の4領域です。

出力症状に応じた修正箇所の特定

回答が一般論になる場合は、対象読者、目的、固有の背景、参照資料を追加します。冗長な場合は、文字数、項目数、優先順位、不要な前置きの禁止を指定します。

形式が崩れる場合は、見出し、列名、JSONキー、短い出力例を追加します。重要事項が抜ける場合は、必須項目と回答前チェックを加えます。

事実誤認が多い場合は、プロンプトを長くするより、根拠資料と照合工程を追加します。症状に対応する箇所だけを変え、同じ評価データで改善前後を比較することが基本です。

ゼロショットと例示のタスク別選択

ゼロショットとは、回答例を与えず、タスクと条件だけを伝える方法です。論理問題や複雑な推論では、まずゼロショットから試します。

ブランド文体、分類基準、翻訳用語、特殊なJSON形式など、期待形を言葉だけで説明しにくいタスクでは短い例が有効です。「この形式は不可」という負例が役立つ場合もあります。

例が多いほど精度が高まるとは限りません。入力トークンとノイズが増え、例文の内容へ回答が引きずられることがあります。追加前後を同じテストセットで比較し、改善しない例は削除します。

複雑な業務における工程分割

調査、分析、作成、確認を1つの長いプロンプトへ詰め込むと、各工程が浅くなりやすくなります。次の4工程へ分ける方法が有効です。

1. 資料から事実を抽出
2. 抽出した事実から論点を分析
3. 分析結果から成果物を作成
4. 成果物を確認

前工程の出力を次工程へ渡す際は、確定事項と仮説を区別します。各工程に完成条件を設定し、途中結果に誤りがある場合は後工程へ進めません。

APIでは、単純抽出をNon-thinking、複雑分析をThinkingで実行するなど、工程ごとに設定を変えられます。中間データを保存すると、誤りが混入した工程を特定しやすくなります。

評価データと採点基準による比較

実際の業務データから、通常例、難しい例、例外例を含むテストセットを作ります。評価項目は、正確性、網羅性、形式準拠、簡潔性、修正時間などです。

プロンプトAとBへ同じ入力を与え、モデル、Thinking設定、実行日を記録して比較します。モデルによる自動採点だけに依存せず、重要業務では担当者が基準回答と照合します。

合格基準を満たしたプロンプトのみ共有テンプレートへ登録します。偶然得られた良い回答ではなく、複数の代表データで安定して合格することが採用条件です。

DeepSeekプロンプトをチームで標準化する運用設計

個人で成功したプロンプトを、そのまま共有フォルダへ保存するだけでは標準化できません。入力変数、使用条件、所有者、評価結果、更新履歴まで管理します。

入力変数付き業務テンプレートへの変換

テンプレートには、目的、対象業務、入力変数、使用モデル、Thinking設定、出力形式、禁止データ、確認担当を記載します。

入力箇所は`[対象読者]`、`[元資料]`、`[文字数]`のように変数化します。必須入力と任意入力を分け、不足時に実行しない項目も決めます。

サンプル入力と合格出力をセットで保管すると、利用者が完成形を理解できます。利用対象外の業務も記録し、テンプレートが誤った用途へ転用されるのを防ぎます。

プロンプトカードの項目例：

• ID
• 名称
• 目的
• 所有者
• 対象業務
• モデル
• モード
• 入力変数
• 出力形式
• 禁止事項
• 評価結果
• 更新日

変更履歴・所有者・再評価条件の管理

各プロンプトへバージョン番号、変更者、変更理由、承認者、適用開始日を付けます。再評価条件には、モデル変更、業務ルール変更、形式違反の増加、重大な誤回答を設定します。

個人が派生版を作り続けると、どれが正式版か分からなくなります。改善提案を所有者へ集約し、検証、承認、公開の手順を通します。

廃止したテンプレートは削除せず、利用停止理由と代替版を記録します。プロンプト所有者と出力内容の業務責任者が異なる場合は、役割を分けて管理します。

固定部分の整理による品質とAPIコストの管理

役割、共通ルール、出力形式などの固定部分を先頭に置き、案件ごとに変わるデータを後ろへ配置します。

DeepSeek APIのContext Cachingは、共通する入力プレフィックスを再利用します。固定部分を統一すると、キャッシュヒットにつながる場合があります。APIレスポンスのキャッシュヒットトークンとミストークンを記録し、プロンプト構造の変更前後を比較します。

ただし、キャッシュは常に命中するとは限りません。キャッシュヒットを前提に予算を固定せず、実測値で管理します。品質を落としてまで短縮せず、再利用されない重複ルールや冗長な説明を削ります。

DeepSeekプロンプトの失敗要因と対策

業務利用で起こる失敗は、プロンプトだけでなく、実行設定、根拠資料、情報管理、後続システムにも関係します。症状、原因、実害、対策を対応付けて確認します。

失敗要因1｜曖昧な依頼による一般論

症状は、内容自体は誤っていないものの、自社の判断や実務に使えない一般論が並ぶ状態です。原因は、「分析して」「改善して」といった成果物が不明な依頼や、対象読者、利用目的、完成条件の欠落です。

対策は、タスク、読者、用途、必須項目、完成条件を追加することです。質問を長くするのではなく、判断に必要な条件を増やします。

改善前：
「新規事業案を分析してください。」

改善後：
「経営会議向けに、新規事業案を市場性、収益性、実行難易度、主要リスクの4軸で評価してください。各軸を5段階で評価し、根拠、不足情報、次の検証項目を表で示してください。」

失敗要因2｜作業と条件の競合による指示違反

文字数違反、必須項目の欠落、前半と後半で異なる結論が出る場合は、複数の作業や条件が競合している可能性があります。

調査、分析、執筆、校正を一度に依頼したり、簡潔さと網羅性の優先順位を示さなかったりすると、モデルがどの条件を優先すべきか判断できません。

工程を分割し、各工程の完成条件を定めます。両立しない条件がある場合は、「正確性を文字数より優先する」などの優先順位を記載します。

失敗要因3｜Thinking固定による時間とコストの増加

単純な整形でも回答が遅い、出力が冗長、トークン消費が増える場合は、Thinkingを初期設定のまま使っている可能性があります。

単純生成と複雑推論を分類し、同じテストデータでThinkingの有無を比較します。正確性、処理時間、出力トークン、修正時間の総合で設定を選びます。

複雑な推論でも、資料不足や誤った前提はThinkingだけでは解決できません。

失敗要因4｜不要な例と長い背景による条件の埋没

例文の内容へ引きずられる、関係のない論点を出力する、重要条件を無視する場合は、コンテキストが過剰な可能性があります。

念のために大量の背景や類似例を入れるのではなく、タスク判断に必要な資料だけを残します。例示は、目的や形式を言葉だけで説明しにくい場合に限定します。

ゼロショット版と例示版を同じ評価セットで比較し、結果が改善しない情報を削除します。

失敗要因5｜根拠未指定による誤情報の採用

存在しない統計、古い制度、誤った企業情報が自然な文章で出力される場合があります。流暢な文章と事実の正確性は別です。

一次情報だけを根拠にする、事実・推測・不足情報を分ける、出典URLと確認日を記載するよう指示します。重要な数値、法令、契約条件は、人が原典と照合します。

最新性が必要な業務では、検索、RAG、社内データ連携を検討します。

失敗要因6｜一般利用環境への機密情報・個人情報の入力

顧客情報、未公開資料、認証情報、営業秘密を外部サービスへ送信すると、情報管理上の問題が生じる可能性があります。

個人情報保護委員会は、DeepSeekサービスで取得された個人情報を含むデータが中国に所在するサーバへ保存され、中国の法令が適用される点について情報提供しています。利用前に、自社の個人情報保護、委託先管理、越境移転、秘密保持の要件と照合する必要があります。

入力データを公開情報、社内情報、機密情報、個人情報に分類し、許可された環境と対応付けます。匿名化、仮名化、不要項目の削除を行い、APIキー、パスワード、秘密鍵は入力しません。

プロンプトに「機密情報を使わない」と書くだけでは統制になりません。契約、利用環境、アクセス権、ログ管理を組み合わせます。

失敗要因7｜JSON出力の欠落・切断・空回答

API連携では、JSONの括弧が閉じない、必須キーが欠ける、途中で切断される、空のcontentが返る場合を想定します。

DeepSeek公式は、JSON Outputで`response_format`を設定し、プロンプト内にJSONという語と出力例を含め、十分な`max_tokens`を設定するよう案内しています。空contentが返る場合がある点も明記されています。

生成後は、構文検証、必須キー検査、業務ルール検証を行います。失敗時の再試行回数、エラーログ、手動確認への切り替えも設計します。

失敗要因	症状・リスク	主な原因	対策	確認担当
曖昧な依頼	一般論で実務に使えない	読者・用途・完成条件の欠落	タスク、読者、用途、必須項目を追加	業務担当
条件の競合	文字数違反、項目欠落、結論不一致	複数工程の詰め込み、優先順位不足	工程分割、優先順位の明示	業務担当
Thinking固定	遅延、冗長化、トークン増加	タスク分類なし	モード比較、総コスト評価	開発・運用担当
過剰な背景・例	重要条件の無視、例への引きずり	不要情報の追加	必須情報へ限定、例示版との比較	プロンプト所有者
根拠未指定	誤った統計・制度・企業情報	資料・対象期間・検証不足	一次情報指定、事実と推測の分離	業務責任者
機密・個人情報入力	情報漏えい、法務・規程違反	情報分類と環境審査の不足	データ分類、匿名化、契約・権限管理	情シス・法務
JSON異常	欠落、切断、空回答、後続処理停止	設定不足、検証・再試行なし	response_format、スキーマ検証、再試行	開発担当

DeepSeekプロンプトが自社業務に向くかを判断する5つの基準

正式導入の判断では、プロンプト例の出来だけでなく、タスク適合性、情報リスク、品質、総コスト、運用体制を確認します。

判断基準1｜明確な入力と出力で定義できる対象業務

入力資料、実行作業、期待成果物、確認者を定義できる業務を優先します。議事録整理、分類、比較表作成、初稿作成など、成果物を評価しやすい業務が候補です。

暗黙知が多く、正解条件を説明できない業務は、プロンプト化の前に業務手順を整理します。判断そのものをAIへ委ねず、判断材料の整理から適用します。

判断基準2｜許可範囲へ限定できる入力情報

使用データを公開情報、社内限定、機密、個人情報に分類します。Webチャット、公式API、自社管理環境と、自社規程、契約条件を照合します。

匿名化しても業務目的を達成できるか確認します。機密情報を除外すると成立しない業務は、利用環境の整備前に一般サービスで試しません。

判断基準3｜誤回答を検出する評価基準と確認者

正解データ、参照資料、業務ルールなど、回答を照合する基準があるか確認します。誤りの影響が大きいほど、専門担当者によるレビューや二重確認が必要です。

「人が確認する」だけでは不十分です。誰が、何を、どの期限で確認するかを定義します。合格基準を満たさない場合は、再生成、手動処理、利用停止の切り替え条件を決めます。

判断基準4｜品質向上に見合う処理時間と総コスト

API料金だけでなく、入力・出力トークン、Thinking利用、再試行回数、人による修正時間を計測します。V4-FlashとV4-Pro、Thinkingの有無を同じテストセットで比較します。

高性能設定による品質改善が、追加コストや待ち時間に見合う業務だけへ適用します。料金とモデル仕様は変更されるため、導入前に公式ページを確認します。

総コストの考え方：
API費用＋レビュー工数＋再処理工数＋運用保守工数

判断基準5｜維持担当者と代替手段を含む運用体制

プロンプト所有者、業務責任者、セキュリティ確認者、システム管理者を明確にします。モデル更新時の再テスト、障害時の手動手順、他モデルへの切り替え方法も定めます。

DeepSeek固有の設定と、他モデルでも使える共通プロンプトを分離します。個人PoC、部門利用、全社利用の段階に応じて管理水準を上げます。

判断基準	確認事項	2点	1点	0点
タスク適合性	入力・作業・成果物・確認者を定義できるか	明確	一部未整理	定義困難
情報リスク	許可データだけで業務が成立するか	成立	条件付き	成立しない
品質管理	正解基準と確認者がいるか	両方あり	片方のみ	なし
総コスト	API・修正・再処理を計測できるか	計測済み	試算のみ	不明
運用体制	所有者、再評価、代替手段があるか	整備済み	一部整備	未整備

判定例：

• 8～10点：導入候補
• 5～7点：限定導入
• 3～4点：条件整備後に再評価
• 0～2点：見送り

DeepSeekの導入支援は「フリーコンサルタント.jp」へご相談ください

フリーコンサルタント.jpでは、事業会社やコンサルティングファーム出身のプロ人材が、生成AI・DX活用の戦略設計から現場のルール整備、社内への知見移転までを伴走支援します。実務経験豊富な人材が、上流の方針づくりから実行段階まで一貫して関わることで、導入後の定着まで見据えた支援が可能です。

フリーコンサルタント.jpによるAI導入支援の事例

フリーコンサルタント.jpでは、AI・DX推進領域全般で企業の支援実績があります。ここでは、社内に専門人材が不足していた企業の支援事例を2件紹介します。

事例①｜大手飲食企業：需要予測・発注レコメンドAIの開発支援

200店舗以上・400品目の発注業務を店舗担当者の経験と勘に頼っており、業務が属人化していた大手飲食企業の事例です。データサイエンティストなどAI活用の経験者が社内に不足し、AIの本格運用に向けたデータ活用の進め方が分からない状態でした。

当時の課題	・データサイエンティスト・データアナリスト人材、AI活用の経験者が社内に不足 ・店舗情報・POSデータをもとにした需要予測を、複数人が同じ精度で行うことが困難 ・発注業務が現場の勘に依存し、担当者の休暇・退職で業務が滞るリスクを抱えていた
実施したこと	・店舗ごとの特徴を踏まえた変数を定義し、データを整理 ・PoC（概念実証）を経て、店舗ごとに高い精度で需要予測ができるAIモデルを構築・運用

需要予測AIの活用により発注業務の多くを自動化し、作業時間を削減。バックオフィス業務の負荷が軽減し、店舗担当者が接客などの対応に時間を割けるようになりました。

事例②｜大手通信キャリア企業：デジタル活用推進に向けたCoE組織の立ち上げ支援

業務効率化を目的に、デジタル活用組織（CoE＝Center of Excellence。複数部門の知見を集約する専門組織）の立ち上げを決定したものの、組織立ち上げの推進とデジタル技術活用の両方を担える人材が社内に不足していた大手通信キャリア企業の事例です。

当時の課題	・デジタル領域の知見と組織立ち上げ経験を併せ持つ人材が社内に不足 ・業務効率化ツールの開発・運用体制をゼロから構築する必要があった
実施したこと	・CoE組織の立ち上げから全体設計・運用構築・実運用までを一気通貫で伴走支援 ・事業部門への課題ヒアリングをもとにしたツール開発の仕組みを構築し、プロパー社員が自走できる体制へ知見を移転

CoE組織の立ち上げと運用の安定化により、組織立ち上げ前と比較して業務工数を約25%削減。プロパー社員が主体的に運用できる体制を構築し、外部人材への依存から段階的に脱却しています。

まとめ

DeepSeekプロンプトは、タスク、背景、制約、出力形式、検証条件を分けて記載することが基本です。現行V4では、Thinkingをモデル名と分けて設定できるため、旧R1向けの推奨を一律に流用せず、利用環境とタスクに合わせて検証します。

まずは業務別例文を使い、通常例、難しい例、例外例を含むテストデータで評価します。個人で成功したプロンプトは、入力変数、禁止データ、所有者、バージョン、合格基準を付けてチーム資産へ変えます。

プロンプトだけでは、事実の正確性や情報管理を保証できません。一次情報、人による確認、許可された利用環境、アクセス制御を組み合わせる必要があります。

正式導入時は、タスク適合性、情報リスク、品質、総コスト、運用体制の5基準で判断します。自社だけで業務選定、PoC、評価、セキュリティ、運用設計を進めることが難しい場合は、外部の専門人材を活用する方法も選択肢です。