Claude翻訳をクライアント別に訳し分ける — Projectsで文体と用語を分離

クライアントごとにProjectsを分けると、訳文の取り違えが構造的に減る

翻訳の仕事を複数のクライアントから受けていると、訳文のスタイルは案件ごとに食い違います。A社は「です・ます」で社名の後ろに敬称を付けず、B社は体言止めを多用して「お客様」を禁じる。こうした違いを、毎回の依頼文で伝え直すのは現実的ではありません。

解決策は、クライアント1社につきProjectsを1つ作り、そのクライアントのスタイルガイドをカスタム指示とナレッジに置くことです。Projectsは、独自のチャット履歴とナレッジを持つ自己完結した作業スペースです。指示とナレッジは同じプロジェクト内のすべてのチャットに効きますが、別のプロジェクトには漏れません。

この分離が、取り違えを人の注意力ではなく置き場所で防ぎます。A社の案件はA社のプロジェクトを開いて頼む。それだけで、B社の禁止表現が混ざる経路が閉じます。

検証の手順(出力言語の指定や訳し戻し)はClaude翻訳の精度を検証してから確定するワークフローにあります。ここでは、その前段にあたる「どのスタイルでClaudeに訳させるか」を案件ごとに切り分ける運用を扱います。

1つのProjectsに全クライアントを入れるのと、案件別に分けるのと

先に判断材料を並べます。どちらにも向く場面があります。

目安は、ルールの衝突があるかどうかです。語尾や用語が互いに矛盾しない複数社なら、1つにまとめても事故は起きにくいでしょう。逆に、同じ原語を社ごとに別の訳語にするような関係(たとえばcustomerを「お客様」と「ユーザー」に訳し分ける)があるなら、分ける価値が出ます。

Projectsの作り方 — 名前と説明はClaudeに見えない

作成手順そのものは単純です。ただし1点、翻訳の運用では見落としやすい仕様があります。

見落としやすいのは、プロジェクトの名前と説明にClaudeがアクセスできない点です。ヘルプには、名前と説明はClaudeには見えないと明記されています。「A社_日英」とプロジェクト名を付けても、Claudeはそれを手がかりにしません。

したがって、クライアント名と案件の種類は、カスタム指示の冒頭に本文として書きます。後の節で触れる取り違えの検出も、この一行に依存します。

カスタム指示には「文体・用語・禁止表現」の3点を書く

カスタム指示は、プロジェクト内のすべてのチャットに適用されます。翻訳では次の3点に絞ると、運用が回しやすくなります。

• 文体: 敬体か常体か、一人称、見出しの語尾、数字の書式
• 用語: 原語と訳語の対応、訳さずに残す語、社名・製品名の表記
• 禁止表現: 使わない語、避ける言い回し、置き換えの指定

例えば次のような形です。これは書き方を示す例で、実在のクライアントの規定ではありません。

このプロジェクトは、クライアント「A社」の英日翻訳専用です。
A社以外のルールは適用しません。
 
# 文体
- 敬体(です・ます調)で統一する
- 見出しは体言止めにする
- 数字は半角、桁区切りは原文のまま保持する
 
# 用語
- customer は「お客様」と訳す(「顧客」「ユーザー」は使わない)
- 製品名 AlphaDesk は訳さず、英字のまま表記する
 
# 禁止表現
- 「〜させていただく」を使わない
- 「弊社」ではなく「当社」と書く
 
# 出力
- 訳文のみを返す。説明や前置きは付けない
- 先頭行に「【A社ルール適用】」と書く

最後の「先頭行に【A社ルール適用】と書く」は飾りではありません。依頼の結果にこの印が出ていれば、意図したプロジェクトで動いたことが一目で分かります。

ナレッジに置くのは、指示に収まらない長いルールと実例

指示は短く保ち、長いものはナレッジに回します。クライアントが渡してくるスタイルガイドはPDFやWordで数十ページあることが多く、指示欄には入りません。

ナレッジに置いて役立つのは、おおむね次の3種類です。

有料プランでは、ナレッジがコンテキスト上限に近づくとRAGモードが自動で有効になり、容量が最大10倍まで広がります。分量の多いスタイルガイドを置いても溢れにくい反面、RAGでは必要な箇所だけが取り出される仕組みなので、全文を毎回参照するわけではありません。挙動の違いはClaude ProjectsのRAG検索の解説で扱っています。禁止表現のように1つでも漏れると困る規則は、ナレッジに任せず、短くカスタム指示にも書いておくと安全です。

もう1点、ヘルプには「プロジェクト内のチャット同士でコンテキストは共有されない。共有したい情報はナレッジに追加する」とあります。あるチャットで「この語は今後こう訳す」と決めても、別のチャットには引き継がれません。決定事項は、その場でナレッジの用語集に書き足します。

メモリの混線を止める

ナレッジと指示を分けても、別の経路でスタイルが混ざることがあります。メモリです。

ヘルプによると、各プロジェクトは専用のメモリを持ちます。プロジェクト内で作業するとき、Claudeはそのプロジェクトのメモリと、プロジェクト外のチャットで蓄積されたあなたのメモリを併用します。他のプロジェクトのメモリは使いません。つまり、A社のプロジェクトにB社の記憶が入り込む経路はありません。

注意が残るのは、プロジェクト外のメモリです。普段のチャットで「この文体が好み」と伝えた内容が、どのクライアントのプロジェクトにも入り得ます。クライアントのルールを完全に独立させたいなら、プロジェクトのページでメモリ設定の「Use account memory」をオフにします。

メモリは1つのチャットだけ止めることもできます。「+」メニューで「Memory」をオフにしてから最初のメッセージを送ると、そのチャットはプロジェクトのメモリを使わず、書き込みもしません。新しい案件の試し打ちで、記憶を汚したくないときに使えます。

なお、チャット検索もプロジェクトごとに閉じています。プロジェクト内の会話の検索は、そのプロジェクトの範囲に限られます。「前回の続きから」と頼んでも、別クライアントの会話を拾う心配はありません。

依頼のたびに取り違えを検出する

分けた後も、人は間違えます。A社のつもりでB社のプロジェクトを開いたまま依頼することは起こり得ます。置き場所による予防に、出力側の確認を重ねます。

先ほどの「先頭行にルール適用の印を出す」に加えて、依頼文の側でも宣言を添えます。

クライアント: A社
次の英文を日本語に訳してください。
 
訳した後、次の2点を点検して結果を末尾に書いてください。
1. カスタム指示の禁止表現が訳文に含まれていないか
2. 用語集にある語がすべて指定の訳語になっているか
 
{原文をここに貼り付け}

依頼文で「A社」と宣言したのに、開いているプロジェクトの指示は「B社」専用だった。この食い違いは、Claudeが先頭行に出す印で気づけます。指示に「適用するクライアント名と依頼文のクライアント名が違うときは、訳さずに指摘する」という一文を足しておくと、訳す前に止まる確認にもなります。

末尾の自己点検は、あくまで一次チェックです。点検で「問題なし」と返ってきても、納品前の目視は残してください。

チームで運用するときの権限の分け方

TeamとEnterpriseのプランでは、プロジェクトを組織内で共有できます。作成時の公開範囲は、組織の全員が見られる「Public」と、招待した人だけの「Private」から選びます。クライアント案件は、基本的にPrivateで始めます。

共有するときの権限は2段階です。

クライアントのスタイルガイドが改訂されたときに、全員が指示を書き換えられると、いつの間にか版が混ざります。編集権限を案件リードに絞り、翻訳担当者には閲覧権限を渡すと、ルールの正本が1つに保たれます。

Privateのプロジェクトでも、あなたのチャットは他のメンバーには見えません。共有されるのはプロジェクトの内容とナレッジで、チャットは手動で共有しない限り非公開のままです。

よくあるつまずき

新しいバージョンのProjectsとの関係

Claude Code向けにProjectsの新バージョン(ベータ)が段階的に展開されています。新版では、プロジェクトが1つの会話になり、Claudeが作業を並列のスレッドに分けて進めます。Pro / Maxの一部では、既存のプロジェクトを新バージョンへ移す作業も始まっています。移しても指示・ファイル・チャット履歴は引き継がれ、直近30日に使ったプロジェクトは移る前にメールで知らせが届きます。それ以外のチャットとCoworkのプロジェクトは、当面は従来のバージョンのままです。

この記事の運用は従来のバージョン、つまりカスタム指示とナレッジを持つチャット向けのプロジェクトを前提にしています。新版が自分のアカウントに来た場合の挙動はClaude CodeのProjects刷新の記事で整理しています。

クライアント別の分離は、規則を書く前に切り分けを決める作業

スタイルガイドの書き方を磨く前に、やることがあります。どのクライアント同士が衝突するかを洗い出し、衝突する組だけを別プロジェクトに切る。次に、クライアント名を指示の冒頭に本文として書き、先頭行の印で動作を確かめる。そのうえで、編集権限を絞り、決定事項はナレッジに書き足します。

Projectsの基本機能はClaude Projects完全ガイドに、翻訳そのものの質を上げる別の連携はClaudeとDeepLの連携にまとまっています。案件の数が少ないうちは1つのプロジェクトで足りますが、社ごとに同じ原語の訳が分かれた時点が、切り分けどきです。