DeepL ProとAPIはどちらが必要？社内翻訳とシステム組込みを分ける

DeepLを会社で使うなら、社員が画面で翻訳する使い方と、プログラムから文章を送る使い方を別々に考えます。

メールや文書をWeb・デスクトップアプリで翻訳するならTranslator系、自社システムや翻訳支援ツールから自動送信するならAPI向けの契約を調べます。一方の契約で、もう一方の機能までそろうわけではありません。

画面を使うか、システムへ組み込むかで選ぶ

用途	Translator系	API向け
人がWeb画面で翻訳	向く	API契約だけではPro機能を使えない
デスクトップアプリ	向く	API契約だけではPro機能を使えない
自社システムへ組み込む	翻訳APIは含まれない	向く
一括自動処理	手操作が中心	向く
課金の主な基準	利用者・契約内容	契約枠・文字数・音声時間など

公式ヘルプでも、Translator契約から翻訳APIへアクセスすることはできず、APIには専用の契約が必要と案内されています。逆にAPI契約だけでは、Web翻訳ツールやデスクトップアプリのPro機能は付きません。

海外メールや文書を、その場で読みたいならTranslator

営業担当が海外メールを翻訳したり、法務担当が画面で文書を確認したりするなら、まずTranslator系を検討しましょう。社員がWordやPDFを個別に翻訳し、訳文を見ながら直す使い方もこちらです。

この用途のためにAPI連携を作り込む必要はありません。必要な利用者数を数え、文書翻訳、用語集、管理機能、データ保護条件が足りるかを比べる方が、選ぶ理由をはっきりさせられます。

問い合わせや商品説明を自動で翻訳したいならAPI

問い合わせ文を受信後に翻訳する、ECの商品説明を一括処理する、CMSの登録文を翻訳する。こうした使い方は、プログラムからDeepLへ文章を送るAPI向けです。社内システムの翻訳ボタンや、翻訳支援ツールのAPIキー接続も含みます。

接続に使うAPIキーは秘密情報です。ブラウザ側のコードへ直接埋め込まず、どのシステムがどれだけ使ったかを追える構成にします。

APIの新しいプラン名を確認しておく

API向けには、Developer、Growth、Enterprise APIの契約が案内されています。以下の利用枠は2026年9月18日の公式ヘルプに基づき、Developerの上限は10月23日の同ヘルプでも照合しています。申込み時は対象プランの条件を確認してください。

契約	利用量の考え方
Developer	合計100万文字までの開発・小規模利用
Growth	月額または年額の利用枠 + 超過分
Enterprise API	大規模・長期利用向けの個別契約

Developerの100万文字は、月ごとに戻る枠ではなく合計の上限です。公式ヘルプでは、上限到達後はリセットされず、Growthへの変更が必要と案内されています。DeepL APIプランの公式説明

Growthの案内では、月払いに100万文字と音声認識10時間、年払いに1,200万文字と120時間が含まれ、超過分は従量請求でした。支払い周期が違うので、年の枠を月の枠と取り違えないようにしましょう。

従来のAPI FreeとAPI Proは新規購入できないという案内もあります。既存契約者向けの説明が残っているため、古い比較記事を見つけたら、自分が申し込める契約の話かを確認してください。

文字数は、実際の送り方から見積もる

テキストを送る場合は、平均の長さと月間件数から計算できます。同じ文章をやり直す分も含めておきましょう。

テキスト翻訳の月間文字数
= 1件当たりの平均文字数
× 月間件数
× 再処理を含む係数

文書APIは、実際に書かれた文字数だけで計算すると見積もりがずれることがあります。Word（.docx / .doc）、PowerPoint（.pptx）、Excel（.xlsx）、PDF（.pdf）は、1ファイルにつき最低50,000文字が計上されます。50,000文字を超える文書は実文字数で数えます。

たとえば、1,000文字のWordファイルを10件翻訳する計算例なら、合計10,000文字ではなく500,000文字の計上です。短いファイルだから安い、とは限らないんですね。

HTML（.html）、SRT（.srt）、Text（.txt）、XLIFF（.xlf / .xliff）には、このファイル単位の最低文字数はなく、実文字数が計上されます。文書翻訳は、ファイルごとの計上文字数を再処理分も含めて合計しましょう。

見積もり用の一覧は、ファイル形式、件数、1件の文字数、翻訳先の言語数、送り直す回数に分けます。レイアウトを残して返す必要がある文書なら、文字数を減らす目的だけでテキストへ変えず、訳文を元の文書へ戻す作業も比べてください。料金が下がっても、人が表や書式を作り直す時間が増えるなら、仕事全体では楽にならないからです。

文章改善や音声も使う場合は、文字数と音声時間などの単位を分けます。API利用状況の画面で翻訳・文書・言い換えなどの処理別利用量を見て、対応契約ならAPIキー単位の記録も使うと、見積もりとの差を追いやすくなります。

手動翻訳と自動処理が両方ある会社の予算

社員50人のうち10人が手動翻訳を使い、ECの商品説明も毎日自動翻訳する会社を例にします。この場合は、二つの予算を作ります。

手動翻訳
= Translatorの必要利用者数 × 契約単価

自動翻訳
= APIの固定費
+ 含有量を超えた利用分

人が使う席は10人分を起点に、APIは商品説明の処理量から見積もります。「社員が50人いるからAPIも50人分」と数える必要はありません。また、APIを用意しても、10人のWeb版の契約が自動で付くわけではありません。

自動処理は、増え過ぎたときに止められるようにする

同じ文章を何度も送る不具合があると、翻訳が終わっていても利用量だけが増えてしまいます。対応するAPI契約には、月間料金の上限管理、APIキーごとの利用上限、利用状況やキー単位の利用記録があります。

本番へ入れる前に使える上限設定を確認し、部門やシステムごとにキーを分けておきましょう。費用が急に増えたとき、どの処理を見ればよいか分かりやすくなります。

上限で翻訳できなくなったときは、原文を残して担当者へ知らせるか、処理を待たせるかも決めます。空の訳文をそのまま公開する、失敗した依頼を際限なく送り直す、といった運用を避けるためです。評価用の短い文章で、翻訳結果を受け取るところと、失敗を担当者が把握するところまで確認してから、本番の量へ広げましょう。

機密文書を送る前に、契約のデータ条件を見る

翻訳精度が十分でも、機密文書や個人情報を送ってよいかは別に確認します。DeepLは有料契約のデータをサービス提供のために処理し、他ユーザーと共有せず、アカウント外のモデル学習には使わないと説明しています。Growthには、翻訳・改善後にテキストを直ちに削除する条件の案内もあります。

それに加えて、自社の法的根拠、顧客との契約、社内規程、必要なデータ処理契約を確かめてください。2026年にはデータ基盤も更新されているため、以前の記事にある「欧州だけ」という前提をそのまま使わず、契約時点の所在地と処理条件を照合しましょう。

まず、翻訳する仕事を二つに分けてみる

人が画面で読み直す翻訳ならTranslator、システムが文章を送る翻訳ならAPIを先に調べます。両方あるなら、人の席数と自動処理量を別々に数えます。

APIを選ぶ場合は、月間文字数に加えてファイル形式ごとの最低計上や音声時間も確認してください。使いたい仕事をこの順に並べれば、不要な連携を作らず、必要な契約を見積もれます。