stakeholder-translationlisted

## Purpose 「エンジニアの報告が技術用語ばかりで意思決定できない」を防ぐ。 施工AIや開発者が出力した技術的な内容を、意思決定者・事業担当者が行動できる形式に翻訳する。 ## Use When - 実装結果・進捗を非エンジニアに報告する場合 - ブロッカーや技術的リスクについて承認・判断を求める場合 - 設計決定（ADR）の背景・トレードオフを説明する場合 - インシデント・障害の原因と対処を報告する場合 ## Inputs 以下を準備すること。不足している場合は推測せず、不足を明示する。 - **原文（技術内容）**: 翻訳元の技術的な説明・レポート・コード変更サマリー - **受け手の役割**: 誰に向けた翻訳か（経営者 / 事業担当者 / 顧客 / チームメンバー） - **目的**: 報告のみ / 判断を求める / 承認を求める / 理解を促す - **背景**: 受け手がすでに知っていること・知らないこと ## Output Contract 以下の順で出力すること。順序を変えない。 1. **論点**: この翻訳で最も重要な伝達すべき核心 2. **根拠**: その論点をそう判断した理由 3. **翻訳結果**: ステークホルダー向けの説明文 4. **含意**: この内容を正確に伝えないと起きうる意思決定ミス・誤解 5. **改善案**: 翻訳の明確さ・簡潔さを高めるための調整案 6. **代替案**: 受け手の役割・目的が異なる場合の別バージョン 7. **判断材料**: 「この翻訳で送る / 追加確認が必要 / 別の形式にする」を選ぶための情報 ### 翻訳結果 フォーマット **状況（What）**: 何が起きているか（1〜2文） **影響（Impact）**: 事業・ユーザー・スケジュールへの影響（箇条書き） **必要なこと（Need）**: 受け手に求めること（判断 / 承認 / 情報提供 / なし） **期限（Deadline）**: 判断・対応が必要な期限（あれば） ## Review Lens - **目的妥当性**: 受け手の役割に対して適切な言葉・粒度か - **範囲の過不足**: 技術詳細が不要に含まれていないか / 必要な文脈が省略されていないか - **中長期リスク**: 翻訳による情報の歪み・誤解のリスクはないか - **LAB全体との整合性**: 主力プロダクト（LMS）の事業文脈と一致しているか - **非エンジニア理解可能性**: 受け手が追加質問なく行動できるか - **他LLM移植耐性**: 翻訳フレームワークが Claude 固有の解釈に依存していないか ## Instructions 1. 原文の技術内容を「事実 / 影響 / 必要なアクション」に分解する 2. 受け手の役割に合わせて専門用語を日常語に置き換える 3. 「何を決めてほしいか」が明確でない場合は明示的に記載する 4. 数値・日付・条件は具体的に保つ（「近日中」「大幅に」は使わない） 5. 感情的なトーン（緊急感の誇張・過小評価）を排除する 6. 受け手が「次に何をすべきか」で終われるよう構成する 7. 最終判断は人間に委ねる ## Guardrails - 技術的正確性を犠牲にして分かりやすさを優先しない - 「問題ない」「大丈夫」等の曖昧な安心文句を使わない - 受け手を不安にさせないために不都合な情報を省略しない - 翻訳者（AI）の意見・推奨を受け手の判断として混同させな