# Write Clear Business Docs > Transform AI conversations, meeting notes, research, and complex ideas into clear Japanese business documents for third-party readers. Use when an AI agent needs to document project discussions, explain a new concept step by step, turn transcripts or rough notes into reports, decision records, proposals, or explanatory articles, or revise Japanese prose for structure, readability, logical continuity, and evidence discipline. Preserve source meaning, separate facts from interpretations, hypotheses, and proposals, and avoid imitating any specific living author. - Skill: `nob-git-dev/write-clear-business-docs` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add nob-git-dev/write-clear-business-docs` - Raw SKILL.md: https://api.skillmd.com/api/skills/nob-git-dev/write-clear-business-docs/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: nob-git-dev (https://skillmd.com/u/nob-git-dev) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/nob-git-dev/write-clear-business-docs --- # 伝わるビジネス文書 ## 目的 会話や断片的な情報を、元の文脈を知らない第三者が理解・判断・行動できる日本語文書へ再構成する。 表面的な要約ではなく、読者の疑問に沿って論理を組み直す。 ## 参照する資料 - 常に [references/writing-principles.md](references/writing-principles.md) を読み、文章原則を適用する。 - 新しい概念、仕組み、判断基準を説明するときは [references/concept-staircase.md](references/concept-staircase.md) を読む。 - 文書形式を決めるときは [references/document-patterns.md](references/document-patterns.md) を読む。 - 最終稿を出す前に [references/evaluation-rubric.md](references/evaluation-rubric.md) で監査する。 - 成果物ファイルを作る場合は、用途に合う [assets/](assets/) のテンプレートを複製して使う。 ## 作業手順 ### 1. 執筆条件を定める 次を入力から特定する。 - 想定読者 - 文書の目的 - 読後に理解・判断・実行してほしいこと - 文書形式と長さ - 必ず残すべき事実 - 不確実な情報の扱い 指定がなくても作業を止めず、結果を大きく変えない範囲で妥当な前提を置く。前提が重要な場合だけ、完成稿の後に短く明示する。 ### 2. 情報を分類する 執筆前に、入力を次へ分ける。 - 確認できる事実 - 発言者または資料による解釈 - 未検証の仮説 - 提案 - 決定事項 - 採用しなかった案 - 未解決事項 - 次の行動 入力にない事実を補わない。矛盾する情報を一つに丸めない。推測を事実に格上げしない。 ### 3. 読者の疑問を並べる 会話の時系列ではなく、初見の読者が抱く疑問の順に構成する。 基本順序を次とする。 1. これは何の話か 2. なぜ重要か 3. 何が起きているか 4. 従来の理解では何が足りないか 5. どのように考えるべきか 6. 根拠は何か 7. 何を決める、または実行するのか 8. 何が未解決か 内容に応じて不要な問いを削る。 ### 4. 構成を作る 各節を一つの問いへの回答にする。見出しを単なる分類名ではなく、問い、結論、または意味のある要約にする。 各節の結論を次節の前提として使い、論理を一段ずつ進める。 新概念の説明では、次の順序を優先する。 > 観察できる現象 → 矛盾 → 既存説明の限界 → 原因仮説 → 概念の命名と定義 → 適用 → 行動 ### 5. 初稿を書く - 結論または中心問題を早い段階で示す。 - 主張と根拠を近くに置く。 - 数字や事例を示したら、その意味まで説明する。 - 抽象説明が続いたら、具体例、比較、観察可能な事実のいずれかを置く。 - 長い説明の後に短い要約文を置き、リズムを作る。 - 問いを置いたら、直後または同じ節で答える。 - 専門用語を初出時に短く説明する。 - 事実、解釈、仮説、提案の確度を表現で区別する。 ### 6. 意味を監査する 元の入力と照合し、次を確認する。 - 重要な事実や決定が欠けていないか - 発言者の意図を強めたり弱めたりしていないか - 因果関係を飛躍させていないか - 根拠のない断定を加えていないか - 未解決事項を解決済みに見せていないか 問題があれば構成から直す。表現だけで隠さない。 ### 7. 読みやすさを監査する - 冒頭だけで目的と要点が分かるか - 一つの段落に中心メッセージが一つだけあるか - 各段落の冒頭から役割を判断できるか - 「これ」「それ」の参照先が明確か - 接続表現が実際の論理関係と一致しているか - 重複、前置き、内容のない強調を削れているか - 読者が次に何をすべきか分かるか ### 8. 完成稿を渡す 完成した文書を先に提示する。作業過程や自己評価は、求められない限り付けない。 重要な前提、確認できなかった情報、未解決事項がある場合だけ、完成稿の後に短くまとめる。 ## 文体上の境界 - 特定の存命作家の固有表現、口癖、比喩、語彙の組み合わせを再現しない。 - 参考文章からは、構成、論理展開、具体化、読者案内など一般化可能な技法だけを使う。 - 強い一般化、人格攻撃、世代や集団への決めつけ、根拠のない予言を引き継がない。 - 読みやすさのために内容を単純化しすぎない。 - 自信のある文体と、主張の確度を混同しない。 ## 書き直しの優先順位 文字数を削る場合も、次の順に保護する。 1. 結論と目的 2. 結論を支える因果関係 3. 重要な事実と決定 4. 未解決事項と次の行動 5. 具体例 6. 補足説明 意味を保てない場合は、無理に指定文字数へ収めず、何を省略したかを明示する。