Askiveデイリー #182 ・ 2026-08-19

n8nのAI精度に不満があるなら、DeepSeek切り替えの最短手順で比較する

すでにn8nでAI処理フローを組んでいるが、要約が的外れだったり分類がブレたりして精度に不満がある担当者向けに、既存ワークフローを作り直さずにモデルの接続先だけ差し替え、差し替え前後を同じ入力で比較する手順を説明する。

DeepSeekは複数のモデルをAPIで提供しており、OpenAI互換のインターフェース（Base URLとAPIキーで接続する方式。既存のOpenAI向けクライアントがそのまま利用できる）を通じてn8n（自社サーバーでも動くワークフロー自動化ツール）から呼び出せると、DeepSeek公式APIドキュメント（platform.deepseek.com、2025年5月時点）およびn8n公式ドキュメントのOpenAI Compatibleノード仕様（docs.n8n.io、2025年5月時点）に記載されている。

なお、「どのモデルが最適か」は業務内容・データ言語・コストの組み合わせで変わる。切り替えが有効なケースと、いったん保留すべきケースの両方を先に確認してほしい。

また、出力品質の問題がモデル起因かプロンプト設計起因かで対処法が異なる。本文中に簡易診断フローを設けているため、切り替えを判断する前に参照されたい。

DeepSeek APIを選ぶ前に確認すること

切り替えが向くケースと向かないケース

モデルの差し替えが効果を発揮しやすいのは、次の条件が揃う場合だ。

すでにn8nのAIノードが動いており、入出力の形式は固まっている
要約・分類・文書整形など、正解の定義が比較的明確なタスクである
現行モデルの出力品質に具体的な不満があり、どの点が不満かを言語化できる

一方、次のいずれかに該当する場合は切り替えを急ぐ必要はないと考えられる。

AI処理のフロー自体をまだ作っていない（まずフロー構築の記事を参照する）
顧客情報・機密情報を含むプロンプトを送る予定があり、社内のデータ管理規程との照合が済んでいない
現行モデルの出力品質に問題がなく、コスト削減だけを目的にしている場合は費用対効果を先に試算する

出力品質の問題：モデル起因かプロンプト起因かを切り分ける

切り替えを検討する前に、現在の不満がモデル自体の限界によるものか、プロンプト設計の問題によるものかを切り分ける。以下の簡易診断フローを参考にしてほしい。

【簡易診断フロー】

Q1. プロンプトに出力形式・制約・禁止事項を明示的に書いているか？
  → No の場合：まずプロンプトを具体化する（モデル変更より先に効果が出やすい）

Q2. 同じプロンプトで複数回実行したとき、出力のばらつきが大きいか？
  → Yes（ばらつきが大きい）：temperature（出力の多様性を制御するパラメーター）を下げる調整を先に試す

Q3. 上記2点を調整してもなお要点の網羅性・分類精度が改善しないか？
  → Yes：モデル自体の能力差に起因する可能性が高い → 本記事の手順でモデルを差し替えて比較する

この診断を経ずにモデルを変更すると、切り替え後も同じ問題が残るケースがある。プロンプト起因の問題はどのモデルでも再現しやすいためだ。

DeepSeek APIの料金と現行モデルの確認

DeepSeekが提供するモデル名・料金・対応状況は随時更新される。モデル一覧と入出力トークン単価はDeepSeek公式APIドキュメント（platform.deepseek.com/docs、2025年5月時点）の「Models」および「Pricing」ページで確認できる。記事内でモデル名や単価を固定すると、公式の更新時に読者が誤った設定を行うリスクがあるため、以下の手順で都度確認することを推奨する。

DeepSeekの開発者コンソール（platform.deepseek.com）にログインする
「Models」または「Pricing」ページで現在提供中のモデルIDと単価（入力トークン・出力トークンそれぞれの1Mトークンあたりの価格）を確認する
自社の月間処理量（概算トークン数）と単価を掛け合わせて月間概算費用を算出する

コスト比較の試算式は「月間入力トークン数 × 入力単価＋月間出力トークン数 × 出力単価」で表せる。n8nのワークフロー実行ログには各実行の usage.total_tokens が記録されるため、現行フローを1週間運用した実績値から月間トークン数を推計できる。現行モデルとDeepSeekモデルで単価を比較し、差額が月額換算で稟議の根拠になる水準かどうかを確認してから切り替えを判断する。

なお、コスト差の参考として、OpenAIのAPIトークン単価はOpenAI公式料金ページ（openai.com/pricing、2025年5月時点）で、DeepSeekのAPIトークン単価はDeepSeek公式料金ページ（platform.deepseek.com/docs、2025年5月時点）でそれぞれ公開されている。両社とも料金改定が頻繁なため、本記事では特定の数値を固定して記載しない。稟議・上申の際は取得日を明記した上で両ページのスクリーンショットを添付することを推奨する。

「米中AIモデルの性能差が縮小している」という傾向は複数の研究者・メディアが指摘しているが、本記事で断言できる一次情報は確認できていないため、「縮小傾向にあると考えられる」と表記するにとどめる。自社ユースケースでの精度は後述の比較手順で実測することを優先する。

データ管理・規約の確認事項

DeepSeekは海外サービスであり、プロンプトとして送信したテキストの取り扱いはDeepSeek公式プライバシーポリシー（2025年5月時点）で規定されている。顧客情報・個人情報・機密情報を含む文書を処理する前に、送信先の規約と自社のデータ管理規程を照合する。

中小企業ではデータ管理規程が整備されていないケースも多い。その場合、規程の策定を待つより先に以下の最低限の判断軸で対処するのが現実的だ。

送信するテキストに氏名・住所・電話番号・メールアドレス等の個人情報（個人情報保護法が定める「個人情報」に該当するもの）が含まれるか
送信するテキストに取引先との契約内容・未公開の価格情報・製品の未発表仕様など、外部流出した場合に自社または取引先に損害が生じうる情報が含まれるか

上記いずれかに該当する場合は、外部AIサービスへの送信の適否を経営者または法務・コンプライアンス担当者が判断してから進める。該当しない業務（社内議事録の構造化、一般的な文章整形など）から試験的に開始するのが安全だ。

実装手順：既存フローのモデル接続先を変更する

ステップ1：APIキーを取得して管理ツールに保存する

DeepSeekの開発者コンソール（platform.deepseek.com）でアカウントを作成し、APIキーを発行する。発行直後に表示される文字列は再表示できないため、パスワード管理ツールにその場で保存する。

テスト前に決済情報を登録し、少額のクレジット（例として5〜10ドル相当）をチャージしておく。残高ゼロの状態でリクエストを送ると認証エラーではなく残高不足エラーが返るため、初回はチャージ済みの状態で進める方が原因の切り分けが速い。

ステップ2：n8nの認証情報（Credentials）にDeepSeekを登録する

n8nの左メニューから「Credentials」を開き、新規作成する。DeepSeek APIはOpenAI互換のエンドポイント形式を提供しているため（DeepSeek公式APIドキュメント、platform.deepseek.com/docs、2025年5月時点）、n8n上では「OpenAI」または「OpenAI Compatible」の認証タイプを選択して設定できる（n8n公式ドキュメント OpenAI Compatibleノード仕様、docs.n8n.io、2025年5月時点）。

Base URLには以下を設定する。

https://api.deepseek.com/v1

APIキー欄に発行したキーを貼り付け、保存する。

設定時に詰まりやすい点として、Base URLの末尾を /v1/chat/completions まで書いてしまうとエンドポイントのパスが二重になり接続に失敗する。/v1 で止めることが正しい設定だ。

ステップ3：AIノードのモデルIDと設定値を書き換える

既存のワークフローを開き、AI処理を担っているノードを選択する。n8nでよく使われるのは「OpenAI Chat Modelノード」と「HTTP Requestノード」の2種類だ。

OpenAI Chat Modelノードを使っている場合：「Credential to connect with」を先ほど登録したDeepSeekの認証情報に切り替え、「Model」フィールドに使用するモデルIDを入力する。モデルIDは開発者コンソールの「Models」ページで確認した正式名称を使う。

HTTP Requestノードで直接APIを叩いている場合：リクエストボディの model フィールドを対象のモデルIDに書き換える。設定例を示す。

{
  "model": "使用するモデルID（開発者コンソールで確認）",
  "messages": [
    {
      "role": "system",
      "content": "あなたは社内文書を要約する担当です。事実のみを残し、推測を足さないこと。"
    },
    {
      "role": "user",
      "content": "{{ $json.body }}"
    }
  ],
  "temperature": 0.2
}

max_tokens（モデルが1回のレスポンスで生成できるトークン数（AIが一度に処理できる文字量の単位）の上限）の値が前モデル向けに小さく設定されている場合、日本語の長文要約が途中で切れることがある。日本語は英語に比べてトークン消費量が多いため、英語基準の設定値のまま流すと尻切れになりやすい。要約用途では余裕を持った値に調整する。

差し替え前後の精度を評価する

動作確認で確認する3項目

n8nのノード画面で「Execute step」を実行し、実データではなくダミーの日本語テキスト（実業務に近い内容で個人情報を含まないもの）を1件流す。以下の3点を確認する。

レスポンスがJSONで返り、choices[0].message.content に日本語の出力が入っている
元の文章に存在しない固有名詞・数字・主張が追加されていない（ハルシネーション（AIが事実に基づかない内容を生成する現象）の有無を目視確認）
実行ログの usage にトークン数が記録されており、課金が発生していることが確認できる

差し替え前後の比較に使うプロンプト評価テンプレート

「精度が上がった」を感覚ではなく数値で判断するために、以下のチェックリストを用意する。差し替え前のモデルと差し替え後のモデルに同じ入力を3件以上流し、各件について採点する。

【精度評価チェックリスト】（1項目あたり0〜2点で採点）

1. 必須情報の網羅性：拾ってほしい要点（事前に定義）が出力に含まれているか
2. 不要情報の混入：元のテキストにない情報・推測が追加されていないか
3. 指示への準拠：プロンプトで指定した形式（箇条書き、文字数、見出し構成など）に従っているか
4. 日本語の自然さ：不自然な言い回し・誤字・文法の崩れがないか
5. ハルシネーション：固有名詞・数値が原文と一致しているか

【採点基準】
2点：問題なし　1点：軽微な問題あり　0点：致命的な問題あり

【判定】
合計8点以上：実運用可　5〜7点：プロンプト調整後に再評価　4点以下：モデルまたはプロンプトの見直しが必要

このテンプレートを差し替え前後で使い、合計点と各項目の内訳を並べることで、どの軸で改善・悪化したかが明確になる。評価点が差し替え前のモデルを上回らなければ、認証情報を元に戻すだけで原状復帰できる。

なお、5〜7点の「プロンプト調整後に再評価」に該当した場合は、前述の簡易診断フローに戻り、プロンプト起因の問題が残っていないかを確認してから再採点する。

業務別のプロンプト設定例

総務・バックオフィス：議事録の要約

会議の文字起こしを要約するフローで、以下のプロンプト構成を参考にできる。

以下の議事録を、決定事項・宿題・保留の3見出しに分けて箇条書きにしてください。
発言者の主観や、本文にない推測を足さないこと。金額が出てきた場合は原文の数字をそのまま残すこと。

作業時間の変化は業務量・会議の長さ・担当者のスキルによって異なるが、人の最終確認工程を残した上でフローを組むことを前提とする。自動生成した要約はそのまま議事録として配布せず、担当者が原文と照合してから確定させる。

営業：問い合わせメールの分類

受信メールを複数のカテゴリに振り分けるフローで使えるプロンプト例を示す。

次のメール本文を、[見積依頼/クレーム/一般問い合わせ/その他]のいずれか1つに分類し、判断理由を1行で添えてください。
複数に該当する場合は最も緊急度が高いものを選んでください。出力はカテゴリ名と理由のみ。

分類結果は自動でフォルダ振り分けや通知に連携できるが、クレームや契約に関わる件は人が内容を確認する工程を工程内に残す。

マーケティング：商品説明文の下書き生成

商品スペック表から説明文の草案を生成するフローに使えるプロンプト例を示す。

以下の商品スペックから、ECサイト用の説明文を150字程度で作成してください。
スペックに書かれていない性能・効果を追加しないこと。誇張表現（最高・絶対など）を使わないこと。

生成された草案は事実確認と語調調整を経てから公開する。スペックに記載のない効能・比較表現を生成物がそのまま含んでいないかを確認する工程が必要だ。

切り替えを進める3段階のステップ

差し替えを安全に進めるための順序をまとめる。

初日：DeepSeekの開発者コンソールでAPIキーを発行し、n8nの「Credentials」にOpenAI互換の認証情報として登録する。開発者コンソールで現在提供中のモデルIDと料金を確認し、自社の月間処理量から概算費用を試算する。
同週内：精度に最も不満のある既存フロー1本を選び、モデルIDを書き換えてテスト実行する。同じ入力を差し替え前後で3件以上流し、前述の評価チェックリストで採点する。
翌週以降：チェックリストの合計点が差し替え前を上回れば、他のフローへ順次横展開する。下回る場合は認証情報を元のモデルに戻すだけで原状復帰できる。この「戻せる」状態を保っておくことが、安心して試す条件になる。

モデルの性能比較は自社ユースケースでの実測が最も信頼できる。公開ベンチマークはタスク・言語・評価指標によって結果が変わるため、上記の評価テンプレートを使って自社データで検証することを優先する。

本記事はAI編集を経たのち、編集長が事実確認と品質チェックを実施しています。

本記事はAskiveのAIネイティブ編集部が執筆し、編集長四月鶉（Yotsuki Uzra）が監修しています。内容は公開時点で確認できた情報に基づきます。