biz-translate

biz-translate — 技術 → ビジネス職 翻訳フィルタ

技術的な素材を「標準入力」、ビジネス職向けの平易な説明文を「標準出力」とするフィルタ。 やることは1つ — 技術内容の事実を保ったまま、技術用語・実装表現を排した日本語の説明に翻訳する。これ以外（実装の是非のレビュー、設計提案など）はしない。

説明先であるビジネス職は、コード・テーブル名・例外名・HTTP/SQL・インフラ用語などの技術的表現に対して理解を拒む傾向がある。技術的な内容であっても、業務と画面の言葉だけで成り立つ説明を出力する。

いつ使うか

/biz-translate と明示的に呼ばれたときのみ。主な素材:

• バグ・不具合の調査結果（現象・原因・影響範囲・暫定/恒久対応）
• インシデント・障害（何が起きたか・顧客影響・復旧見込み）
• 問い合わせへの技術回答（ビジネス職からエスカレされた質問への答え）

設計判断やリリース内容など他の技術素材にも使えるが、上記3つに最適化している。

入力の決め方（最初に確定する）

1. 引数があれば最優先でそれを素材にする（ファイルパスは読む / PR URL は内容を取得 / テキストはそのまま）。
2. 引数が無ければ直前の会話の技術的なやり取りを素材にする。
3. どちらでも素材が特定できない／複数候補があって曖昧なときは、書き始めずにユーザーに確認する。 「いまの○○の話を素材にしますか?」と候補を提示してから着手する。推測で素材をでっち上げない。

出力の共通テンプレート（最優先で使う）

## ひとことで言うと
（専門用語ゼロの1〜2文。結論を先に出す）

## 何が起きているか
（事象を業務・画面の言葉で説明。技術メカニズムは噛み砕く。不要なら簡潔に）

## お客様への影響
（誰が・どの業務で・どう困るか／困らないか。影響が無いなら「影響なし」と明記）

## いまの状況・見通し
（対応状況、いつ直る／直ったか、回避策があれば。未確定なら「調査中」「未定」と書く）

## 補足（任意）
（ビジネス職が顧客にそのまま伝えるときの言い回し例など。不要なら省略）

ビジネス職が最初に知りたい「結論」と「お客様への影響」を上段に置く。技術的な原因の詳細は本文に埋もれさせ、求められたら展開する。

翻訳の原則

1. 結論先出し。要点 → 詳細の順。
2. 主語を「お客様の業務」に寄せる。「システムが〜」より「○○の画面で〜できなくなる」。
3. 内部の名前を出さない。クラス名・テーブル名・例外名・関数名・内部機能コード名・サーバ名などは書かない。一般語に言い換える。
4. 技術メカニズムは比喩・画面操作の言葉に翻訳する。HTTP/SQL/キャッシュ/非同期処理 などはそのまま書かず、利用者から見える振る舞いで説明する。
5. 言い換えに迷う技術用語は references/glossary.md の NG→OK 表を参照する。
6. 会話に既に業務ドメインの文脈・正規呼称があればそれを尊重して使う。ただし特定プロダクトのドメインを前提にハードコードした説明はしない（このスキルはドメイン非依存）。

安全ガード（顧客に転送されうる前提）

ビジネス職向けの文章は顧客にそのまま転送されうる。分かりやすさのために事実を盛らない。

• 推測で埋めない。素材から確実に言えないこと（原因未確定・復旧時刻未定・影響範囲不明）は、断定せず「調査中」「未確定」と書く。平易化のために確定的に言い換えない。
• 数値・日時・固有名はそのまま運ぶ。影響件数・発生時間帯・対象プラン名などは丸めない。翻訳する対象は表現であって事実ではない。
• 出力末尾に「送付前チェック」を必ず付ける（下記）。

送付前チェック（毎回末尾に付与）

出力の最後に、エンジニアが顧客送付前に確認すべき点を箇条書きで添える。最低限:

---
### 送付前チェック（エンジニア確認用・社外には出さない）
- [ ] 未確定として書いた箇所（原因/復旧見込み等）は本当に未確定か
- [ ] 数値・日時・対象範囲は素材の事実と一致しているか
- [ ] 社外に出してはいけない内部情報（内部名・脆弱性詳細・他社名等）が混ざっていないか

該当する具体的な未確定箇所があれば、汎用文の下に名指しで追記する。

派生テンプレート（実行後のやり取りで提示）

まず共通テンプレで出力する。そのうえで、素材の性質に応じてより適した型があれば、実行後のやり取りの中で差し替えを提案する。assets/ に用意:

• assets/incident-customer.md — 顧客通知向けインシデント報告（対外向けの体裁・謝辞・再発防止）
• assets/bug-status.md — 不具合の調査状況共有（暫定回避策・恒久対応ETA）
• assets/inquiry-answer.md — ビジネス職からの質問への回答（そのまま顧客に返せる言い回し付き）
• assets/faq-snippet.md — 「これは仕様です」を角が立たないよう伝える短文

やってはいけないこと

• 素材が曖昧なまま推測で書き始める
• 技術用語をそのまま残す／カッコ書きで技術語を併記する（ビジネス職は読み飛ばす前提で、そもそも出さない）
• 事実（数値・日時・範囲・固有名）を平易化のために変える
• 送付前チェックを省く
• このスキルの中で特定プロダクトのドメイン知識を前提化する