技術ドキュメント英→日を読み手別に翻訳するプロンプト
いつ使うか
React/Stripe/AWS の公式ドキュメントを社内 wiki に転載したい時、機械翻訳をそのまま貼ると専門用語が壊滅する。読み手レベル (初学者 / 中堅エンジニア) を指定して、訳と一緒に補足注釈まで出させる。
プロンプト本文 (コピペして使う)
あなたは技術ドキュメントの翻訳者です。以下の英文ドキュメントを日本語化してください。
## 原文
```
<ドキュメントを貼る>
```
## 文脈
- 元ドキュメント: <例: React 公式 / Stripe API リファレンス / AWS S3 ガイド>
- 読み手: <例: フロントエンド初学者 / バックエンド中堅 / インフラエンジニア>
- 用途: <例: 社内 wiki に転載 / 技術ブログとして公開>
## 翻訳ポリシー
- 専門用語は **第一原則: 業界で定着しているカタカナ表記** を使う
- 例: "hook" → "フック" / "context" → "コンテキスト" / "prop" → "prop (プロップ)"
- ただし関数名・API名は英語のまま残す
- コードブロック内のコメントも訳す (識別子は触らない)
- "please" / "you should" 等の英語の指示語は "〜してください" にせず能動文にする
- バージョン依存の記述があれば訳の中で明示する
## 補足注釈の追加
- 初学者向けと指定された場合、本文中に「補足: 〜」の形で1-2文の説明を挿入する
- 専門用語の初出時は (英語表記) を併記
- 日本では別呼称が広く使われている用語があれば脚注に書く
## 出力
1. 訳文 (補足注釈込み)
2. 用語対照表 (英語 / 日本語 / 補足 の3列)
3. 翻訳で迷った箇所と判断理由 (3点)
4. 原文に存在する不明瞭な箇所 (あれば)
## 制約
- 直訳調の語尾 ("〜することができる" 連発) を避ける
- コードと文章の対応を崩さない (コードの行数を勝手に増減しない)
効くポイント
- 読み手レベルを指定すると、注釈の入れ方が大きく変わって読みやすくなる
- 用語対照表を一緒に出させると、シリーズ翻訳の用語ブレを防げる
- 「迷った箇所」を聞くと、後で人がレビューする時の確認ポイントが明確になる
よくある質問
- 用語の業界標準カタカナ表記が分からない場合はどうしますか?
- プロンプトに「業界標準カタカナ表記が確証できない場合は『要確認』と明示し、推測で訳語を作らないこと」と1行加えると安全です。Google 検索で「英語用語 + サイト名 (例: React 公式日本語版)」を確認したり、MDN 日本語版のような一次ソースに合わせる運用を併用すると、用語ブレが減ります。
- コードブロック内のコメントが訳されすぎてコードが壊れます
- プロンプトに「コードブロック内は変数名・関数名・型名・APIエンドポイント・文字列リテラルを一切変更しない。コメント (// または # の後) のみ訳す」と明示してください。それでも訳が漏れる場合は、コメント部分だけ別出力させて後でマージするのが確実です。
- 公式ドキュメントを訳して社内 wiki に転載するのは法的に問題ない?
- 技術ドキュメントは MIT / Apache 2.0 / CC-BY などのライセンスが付いていることが多く、ライセンス条件 (帰属表記・改変明記など) を守れば翻訳・再配布が可能なケースがあります。一方、ライセンスが明示されていない場合は無断翻訳の再配布は著作権侵害になり得るため、原典のライセンス確認は必須です。
このプロンプトを実戦で使った所感や改善案があればぜひフィードバックを。姉妹サイト ai-pick.tech では AI x SNS集客の運用ノウハウを公開しています。