# 業務・仕様・実務ドキュメント向け仕様（PR / 仕様書 / 社内レポート / 提案書）

業務文書は責任の所在や判断の基準が読み手に伝わるように書きます。
元の意味と条件を保ち、以下の指針に従って整えます。

---

## 1. 比喩をふだんの言葉に直す

意味を取り違えやすい比喩は、直接的でふだん使う言葉に書き換えます。比喩や言い回しが持っていた気持ちや評価の向き、理由は残します。
- 含みの例: 「うっかり」の不注意、「ようやく」の待ちくたびれた感じ、「〜てしまった」の後悔、「地味に」の目立たないけれど確かにある感じ。
- 比喩の語は言い換えて構いませんが、その語が伝えていた含みや理由は、別のふだんの言葉で補って言い表します。
- 比喩動詞だけでなく、副詞や前置きの言い回しも同じ扱いにします。
なお、「骨が折れる」「手を焼く」「目から鱗が落ちる」「首を長くして待つ」のような、ふだんの日本語で定着した慣用句は、AIっぽい比喩として扱わずそのまま残します。業務仕様でも、意味を取り違えるおそれがなければ残します。迷ったときの目安は、その言い方を、AIが広まる前の人の文章でもふつうに見かけるかどうかです。見かけるなら残します。
絵文字や装飾としての文末コロン（：）も使いません。

| 不自然な例（比喩・曖昧語） | 推奨表現（自然で客観的な表現） |
|---|---|
| 判断に迷ったときは、安全側に倒して判断します。 | 判断に迷ったときは、安全を優先して判断します。 |
| 前提の理解がずれていると、全体の設計が崩れやすくなります。 | 前提の理解がずれていると、全体の設計に問題が生じやすくなります。 |
| 新機能の手触り感を確認します。 | 新機能の使い勝手を確認します。 |
| 現状の課題について解像度を上げます。 | 現状の課題についてより詳しく整理します。 |
| 作業リソースを各工程へ配ります。 | 作業リソースを各工程へ割り当てます。 |

---

## 2. 条件・採否の基準・責任の所在を明確にする

### 主語の明確化
受動態で曖昧になっている箇所は、元の文や前後の資料から主体が特定できる場合に限り、「開発チームで合意した」など責任主体を明記します。特定できない場合は無理に架空の人物や役職を作らず、客観的な事実として記述します。

### 条件と結果の1対1対応
「適宜対応する」のような曖昧な表現は、元の資料にエラーコードや再試行回数などの条件がある場合だけ具体的に書きます。資料にない条件や数値は作りません。

SKILL.mdの構造点検に従い、期限や条件がどの対象・動作に掛かるかを確かめます。修飾や名詞の連続を整理しても、依頼・相談・提案・決定の区別と強さを保ちます。主体が分からない場合は、新しい担当者や責任を割り当てません。
相手との関係や書き手の希望が分かる依頼は、内容・条件・期限を保って語調を整えます。希望された「〜してもらえると助かります」などの依頼の定型と、新しい具体的な便益・感情・感謝の追加を分けます。定型を一律に追加・削除せず、期限を目安や都合次第にしません。安全手順や必須の指示を弱めません。

### 不要な前置きの整理
「検討にあたっては多角的な視点を考慮し…」といった前置きを削り、結論や要請事項から書き始めます。
ただし、比較結果から方針へ移る合図など、前後をつなぐ働きのある語は残します。主張だけでなく、説明・提案・決定の切替が読み手に伝わるか確かめます。

---

## 3. 文体

報告書、提案書、PR説明文では、過剰な装飾を減らし、内容とつながりを簡潔に書きます。
「これらを理解すれば業務効率が飛躍的に向上します」のように、原文にない読了効果を付け足す表現は削除します。