mcpField
T
translation-reframing-audience-shift

translation-reframing-audience-shift

github.com/lyndonkl生産性187112 回インストール9 週間前に更新
リポジトリ

translation-reframing-audience-shift について

異なる読者に合わせて内容を翻訳・再構成するスキルです。技術からビジネスへの変換、要約、異文化向けの調整を扱い、読者分析と忠実性・適切性の確認を支援します。

主な機能

  1. 01原文と対象読者の分析
  2. 02翻訳タイプの選定
  3. 03読者に合わせた再構成
  4. 04忠実性と適切性の確認
  5. 05構造化された納品形式

活用シーン

  1. 01技術報告をビジネス要約に変換
  2. 02戦略を戦術計画に落とし込む
  3. 03専門的な内容を初心者向けに説明
  4. 04多忙な読者向けに長文書を短縮

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/lyndonkl/claude --skill translation-reframing-audience-shift

インストール後、Claude Code で/translation-reframing-audience-shiftを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

resources/
methodology.md
template.md
resources/evaluators/
rubric_translation_reframing_audience_shift.json

詳細

翻訳、リフレーミング、対象読者の変更

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Translation & Reframing Progress:
- [ ] Step 1: Analyze source and target audiences
- [ ] Step 2: Identify translation type and constraints
- [ ] Step 3: Apply translation strategy
- [ ] Step 4: Validate fidelity and appropriateness
- [ ] Step 5: Refine and deliver

ステップ 1:原文と対象読者を分析する

対象読者分析のフレームワークを使って、両方の読者層の特徴を整理します(専門知識、目標、状況、制約)。原文の読者と対象読者の違いを特定します。

ステップ 2:翻訳の種類と制約を特定する

技術↔ビジネス、戦略↔戦術、専門家↔初心者、フォーマル↔インフォーマル、長文↔短文、社内↔社外、異文化間のいずれかに分類します。パターンについては、一般的な翻訳の種類を参照してください。

ステップ 3:翻訳戦略を適用する

単純なケース → 構成に沿って翻訳するにはresources/template.mdを使います。複雑なケース(複数の読者層、重大な影響、繊細なリフレーミング)→ 高度な手法についてresources/methodology.mdを確認します。

ステップ 4:忠実性と適切さを検証する

resources/evaluators/rubric_translation_reframing_audience_shift.jsonを使って自己評価します。意味の正確さが保たれているか、トーンが適切か、強調点が読者の優先事項に沿っているかを確認します。検証セクションも参照してください。

ステップ 5:仕上げて提出する

原文、対象読者、翻訳文、翻訳の根拠を含むtranslation-reframing-audience-shift.mdを作成します。提出形式を参照してください。


対象読者分析

翻訳の前に、原文の読者と対象読者の特徴を整理します。

1. 専門知識のレベル

  • 専門家:その分野に精通し、専門用語を問題なく理解でき、深さやニュアンスを求めます
  • 中級者:基礎知識があり、ある程度の背景説明を必要とし、バランスの取れた説明を好みます
  • 初心者:前提知識がないため、たとえや平易な言葉を必要とし、実践的な要点を求めます

2. 主な目標

  • 意思決定者:選択肢、トレードオフ、推奨事項、リスク、スケジュールを求めます
  • 実装担当者:具体的な情報、手順、制約、成功基準を求めます
  • 学習者:理解、背景、メンタルモデル、例を求めます
  • ステークホルダー:影響、状況、次のステップ、自分への影響を知りたがります

3. 状況と制約

  • 時間:多忙な経営幹部向け(1ページ)、詳細な解説(包括的)、簡単な進捗報告(箇条書き)
  • 媒体:メール(流し読みしやすい)、プレゼンテーション(視覚情報+口頭説明)、ドキュメント(参照用)
  • 既知の情報:社内(共通の背景知識がある)と社外(前提を置かない)
  • 機密性:公開(慎重な表現)と非公開(率直な表現)

4. 文化・人口統計

  • 言語:母語話者と非母語話者(慣用的な表現と字義どおりの表現)
  • 世代:コミュニケーションの慣習(絵文字の使用、フォーマルさへの期待)
  • 業界:テクノロジー業界と伝統的な業界(進行速度、言及内容、前提)
  • 地域:米国と海外(日付形式、測定単位、文化的な言及)

対応付けの演習: 原文の読者は[専門知識/目標/状況] → 対象読者は[専門知識/目標/状況] → 差を埋めるために[翻訳戦略]が必要です。


一般的な翻訳の種類

技術 ↔ ビジネス

技術 → ビジネス:

  • 取り除くもの:実装の詳細、専門用語、コード、アルゴリズム
  • 加えるもの:ビジネス価値、顧客への影響、費用対効果、競争上の優位性
  • 強調点の変更:仕組み → 重要な理由、指標 → 成果
  • 例:「クエリの最適化によりp95レイテンシを450msから120msに短縮」→「ページの読み込みが3倍速くなり、顧客満足度とコンバージョンが向上」

ビジネス → 技術:

  • 取り除くもの:マーケティング表現、曖昧な目標、流行語
  • 加えるもの:要件、制約、受け入れ基準、技術的な影響
  • 強調点の変更:ビジョン → 実装の詳細、成果 → 指標
  • 例:「シームレスな体験で顧客に喜んでもらう」→「チェックアウトの手順を2ステップに減らし、完了率95%を目指し、PCI準拠を維持する」
戦略的 ↔ 戦術的

戦略的 → 戦術的:

  • 削除:ハイレベルなビジョン、市場動向、抽象的な目標
  • 追加:具体的なアクション、スケジュール、担当者、依存関係、成功指標
  • 重点の移行:理由 → 何をどのように行うか、3年のビジョン → 今四半期の計画
  • 例:「データドリブンな組織になる」→「第1四半期:主要なユーザーフロー10件に計測機能を導入する。第2四半期:PM に分析のトレーニングを行う。第3四半期:週次の指標レビューを定着させる。」

戦術的 → 戦略的:

  • 削除:細かなタスク、個別のチケット、日々の活動
  • 追加:テーマ、根拠、事業との整合性、累積的な影響
  • 重点の移行:個々の業務 → ポートフォリオの全体像、タスク → 成果
  • 例:「バグを47件修正し、機能を12件追加し、認証をリファクタリングした」→「製品の安定性とセキュリティの基盤を強化し、エンタープライズ顧客を支援できるようにした」
エキスパート ↔ 初心者

エキスパート → 初心者:

  • 削除:専門用語、予備知識があるという前提、複雑な用語
  • 追加:たとえ、定義、例、「これが重要な理由」
  • 重点の移行:細かなニュアンス → 基本概念、エッジケース → 通常のケース
  • 例(医療):「特発性高血圧。ACE 阻害薬を処方し、腎機能をモニタリングする」→「原因がはっきりしない高血圧です。薬で血管を広げます。定期的に腎臓の検査が必要です。」

初心者 → エキスパート:

  • 削除:過剰な説明、たとえ、手取り足取りの案内
  • 追加:正確さ、専門用語、注意事項、エッジケース
  • 重点の移行:単純化したモデル → 正確で複雑な内容
  • 例:「ボタンをクリックしやすくする」→「iOS HIG に従ってタッチ領域を44×44ptに広げ、8ptのパディングを追加し、コントラスト比3:1を確保する」
フォーマル ↔ インフォーマル

フォーマル → インフォーマル:

  • トーン:三人称 → 一人称、受動態 → 能動態、複雑 → シンプル
  • 構成:厳格なセクション分け → 会話のような流れ、引用 → 気軽な言及
  • 表現:「さらに、それは明らかです」→「また、これを見ればわかります」
  • 例:「当組織は、リモートワークを認めることを決定しました」→「リモートワークを認めることにしました」

インフォーマル → フォーマル:

  • トーン:短縮形 → 完全な形("we're" → "we are")、くだけた表現 → プロフェッショナルな表現
  • 構成:緩やか → 明確な見出しを持つ構造化されたセクション
  • 表現:「いろいろ壊れてる」→「システムの性能が低下しています」
  • 例:「クールな機能をリリースしました!」→「ユーザーエクスペリエンスを向上させる機能をリリースしました」
長文 ↔ 要約

長文 → 要約:

  • 構成:逆ピラミッド型(最重要事項を先に)、箇条書き、重要な決定事項やアクションを強調
  • 削除:補足的な詳細、全体的な背景、網羅的な例
  • 維持:主要な調査結果、提言、次のステップ、重要な注意事項
  • 比率:50ページ → 1ページ(50:1)、1時間 → 5分(12:1)、包括的な内容 → 要点

要約 → 長文:

  • 追加:背景、方法論、裏付けとなる証拠、別の視点
  • 構成:序論 → 本論 → 結論、小見出しを含む複数のセクション
  • 維持:元の重要なポイントをアウトラインとして残し、それぞれを詳しく展開

検証

最終版を確定する前に、以下を確認してください。

意味の忠実性(最優先):

  • 中核となる事実は正確ですか?(意味を変える歪曲や省略がない)
  • 関係性は保たれていますか?(因果関係、依存関係、制約が維持されている)
  • 注意事項は含まれていますか?(関連する制限、不確実性、例外的なケースが記載されている)
  • 含意は正確ですか?(対象読者にとっての意味が正しく伝わる)
  • 検証可能ですか?(対象分野の専門家が、翻訳の正確さを認める)

対象読者への適合性:

  • 専門性のレベルは適切ですか?(専門的すぎず、簡略化しすぎていない)
  • 専門用語のレベルは適切ですか?(必要に応じて説明し、理解される用語を使用している)
  • 目標に応えていますか?(意思決定者には選択肢、実装者には手順、学習者には理由が示されている)
  • トーンは適切ですか?(形式、感情、文体が対象読者の期待に合っている)
  • 分量は適切ですか?(対象読者の時間的制約を尊重している)

強調点の整合性:

  • 優先事項は対象読者に合っていますか?(対象読者が重視する点を強調している)
  • 詳細度は適切ですか?(理解に十分で、過剰ではない)
  • 実行可能性はありますか?(対象読者が行動する必要がある場合、次の手順が明確になっている)
  • 枠組みは効果的ですか?(文脈や目的に合った肯定的・否定的・中立的な表現になっている)

媒体と形式:

  • 構成は媒体に合っていますか?(メールは要点を把握しやすく、プレゼンテーションは視覚的で、文書は参照しやすい)
  • 書式は理解に役立っていますか?(見出し、箇条書き、重要箇所の太字など)
  • アクセシビリティは確保されていますか?(必要に応じて、非ネイティブスピーカーにも明確で、リンクや参考資料が示されている)

文化・人口統計上の配慮:

  • 慣用表現や言及は適切ですか?(国際的な読者に向け、米国中心の慣用表現を避けている)
  • 例は親しみやすいですか?(対象読者が状況を想像できる)
  • 前提は明示されていますか?(対象読者に共有されているとは限らない文脈に依存していない)

最低基準: 評価基準(resources/evaluators/rubric_translation_reframing_audience_shift.json)を使用してください。提出前に平均スコアが 5 点満点中 3.5 点以上であることを確認してください。


納品形式

translation-reframing-audience-shift.md を作成し、以下を記載してください。

1. 原文の分析

  • 元の対象読者:[専門性、目標、背景]
  • 原文の内容:[短い抜粋または要約]
  • 原文のトーンと強調点:[何を強調し、どのように表現しているか]

2. 対象読者の分析

  • 対象読者:[専門性、目標、背景]
  • 翻訳の種類:[技術的内容からビジネス向け、戦略的内容から実務向けなど]
  • 主な制約:[長さ、媒体、配慮事項]

3. 翻訳した内容

  • [翻訳の全文]
  • [対象媒体に合わせた書式—メールでは箇条書き、文書ではセクション分けなど]

4. 翻訳の根拠

  • 変更した点:[専門用語の削減、X への強調点の移行、詳細の削減、比喩の追加]
  • 維持した点:[中核となる事実、重要な含意、重大な注意事項]
  • 理由:[対象読者との専門性の差、時間的制約、媒体の要件、文化的な調整]

5. 検証メモ

  • 意味の忠実性:✓ 中核となる事実は正確
  • 対象読者への適合性:✓ [対象読者]に適したトーンと詳しさ
  • 強調点:✓ [対象読者の優先事項]を強調
  • 制限事項:[簡潔さを優先したため一部のニュアンスが失われるなど、避けられない妥協点]

よくある翻訳パターン

「それで何が言いたいの?」テスト(技術的な内容 → ビジネス上の価値): 技術的な詳細にはすべて「それで何が言いたいの?」への答えが必要です。—「Kubernetes に移行」→「トラフィック急増時に自動スケールし、コストを 30%削減」|「OAuth 2.0」→「エンタープライズ向け SSO に対応し、導入の障壁を解消」

「どうやって?」テスト(戦略 → 戦術): 目標にはすべて「どうやって?」への答えが必要です。—「満足度を向上」→「2 時間以内に回答、ヘルプセンターを追加、NPS 調査を実施」|「AI ファーストの企業」→「PM をトレーニング(第 1 四半期)、ML エンジニアを 3 人採用(第 2 四半期)、機能を試験導入(第 3 四半期)」

たとえによる橋渡し(専門家 → 初心者): なじみのあるものから、なじみのないものへ — 「Git のブランチ」=エッセイの下書きのバージョン|「マイクロサービス」=1 軒のレストランではなく、フードトラック|「API のレート制限」=ナイトクラブの入場人数制限

逆ピラミッド(長文 → 要約): 最も重要なことを最初に示します — リード(1~2 文)→ 重要な詳細(2~3 個の箇条書き)→ 補足情報(必要に応じた詳細)

コードスイッチング(異文化間): 文化的な表現を置き換えます — 「ホームラン」(米国)→「大成功」(中立的な表現)|「fire hose」の慣用句 →「圧倒的な情報量」(文字どおりの表現)|MM/DD/YYYY → YYYY-MM-DD(ISO)


クイックリファレンス

リソース:

主な原則:

  • 意味の正確さを保つ - 事実、関係性、含意を正しく保ちます
  • 伝え方を調整する - 対象読者に応じて、トーン、詳細度、強調点を変えます
  • 対象読者のニーズに合わせる - 専門知識のレベル、目標、背景、制約を考慮します
  • 「専門家が確認して正しいと言えるか?」で検証する - 翻訳の正確さを原文分野の専門家に確認してもらいます
  • 「対象読者が行動に移せるか?」で検証する - 対象読者が内容を理解し、活用できることを確認します

注意すべき兆候:

  • 意味のずれ(簡略化によって事実が不正確になる)
  • 見下した言い方(初心者に対して恩着せがましいトーンになる)
  • 専門用語の不一致(対象読者にとって専門的すぎる、または曖昧すぎる)
  • 「それで何が言いたいの?」への答えがない(ビジネスへの影響を示さずに技術的な詳細だけを述べる)
  • 「どうやって?」への答えがない(戦術的な説明を伴わない戦略的なビジョン)
  • ニュアンスの喪失(簡潔さを優先して重要な注意事項を省く)
  • 文化的な前提(対象読者を疎外する慣用句や言及を使う)
  • 強調点の誤り(対象読者のニーズではなく、書き手が興味深いと思うことを強調する)

コメント