多言語プロジェクトの用語集を自動構築するプロンプト

あなたはローカリゼーション PM です。以下の素材から多言語用語集 (glossary) を構築してください。

## プロジェクト情報
- プロダクト: <例: GramShift、Instagram 自動化SaaS>
- 翻訳先言語: <例: 英語 (en-US) / ポルトガル語 (pt-BR) / スペイン語 (es-MX)>
- ドメイン: <例: SNS マーケ、Instagram API、自動化、課金>
- 既存の英語ドキュメント / UI 文言:
```
<UI 文言、ヘルプ記事、約款などを貼る>
```

## 用語集の構築方針
1. **抽出対象**
   - プロダクト固有名詞 ("いいね" "フォロー解除" "キャンペーン")
   - 業界用語 ("engagement rate" "shadow ban")
   - 法務・課金用語 ("refund policy" "subscription")
   - UI 要素 ("Save" "Cancel" "Confirm")
2. **各項目の列**
   - 原語 (英語) / 日本語 / pt-BR / es-MX / 定義 / 採用判断理由 / 関連用語
3. **採用判断ルール**
   - 同義語が複数ある場合、業界で最も流通しているものを採用
   - 既訳がある場合は既訳を尊重 (履歴整合)
   - 商標・固有名詞は原語のまま (例: "Instagram" は翻訳しない)
4. **NG 訳語リスト** (誤訳されやすいパターン)
   - 例: "Follow" → 「追いかける」(NG) / 「フォロー」(OK)
5. **コンテキスト別の使い分け**
   - UI 内では短い訳語、ヘルプ内では正式な訳語、のような使い分けルール

## 出力
1. **用語集テーブル** (30-60項目目安、マークダウン)
2. **NG 訳語リスト** (10-20項目)
3. **コンテキスト別使い分けルール** (3-5パターン)
4. **同義語衝突の判断ログ** (なぜAをBに優先したかの記録、5-10件)
5. **翻訳者への注意点** (このプロジェクト特有のルール 3-5点)
6. **次のラウンドで追加すべき項目** (現時点ではデータ不足の項目)

## 制約
- 推測で訳語を作らない (情報がない場合は "要確認" としてプレースホルダ)
- 言語別に異なる慣習がある場合は両方併記
- 商標・登録名は原語のまま固定
- 用語集は CSV や TBX に変換可能な構造で出力 (テーブル形式厳守)