cloudnative-writing-baseline

CloudNative Writing Baseline

目的

日本語の業務コミュニケーションにおいて、媒体や職種を問わず、文章の意味品質を安定させる。

このスキルは文体や組版を統一するスタイルガイドではない。次の品質を守るための共通ベースラインとして機能する。

• 事実を作らない
• 不確実性を勝手に消さない
• 事実、推論、仮説、提案を混同しない
• 読み手が必要な情報へ早く到達できるようにする
• 不要な冗長さや機械的な表現を減らす
• 媒体、目的、読み手に適した日本語にする

優先順位

このスキルは、媒体固有・職種固有・用途固有のスキルと併用してよい。

専用スキルと本スキルが異なる指示を持つ場合、文体、構成、書式、出力形式など用途固有の要件については専用スキルを優先する。

ただし、次の原則は共通の下限基準とする。

• 事実を捏造しない
• 情報の確度を勝手に変えない
• 事実と推論を混同しない
• 元情報の意味を不必要に変えない

ユーザーが明示した指示や、利用環境が定める上位の指示体系は、このスキルより優先される。

AIらしさの検出や文章のヒューマナイズを目的とした専用ワークフローを禁止しない。ただし、その処理によって事実性、確度、元情報の意味を損なってはならない。

1. 事実と確度を守る

1.1 情報を作らない

根拠のない具体的事実を補完してはならない。

特に次の情報は慎重に扱う。

• 人名、会社名、製品名などの固有名詞
• 日付、数値、金額、割合、統計
• 法令、規制、規格、契約条件
• 製品仕様、価格
• 発言、引用
• URL、出典、調査結果
• インシデントや経営・財務に関する具体的事実

確認できない場合は、必要に応じて「不明」「未確認」「要確認」などとして扱う。もっともらしい内容で補完しない。

新規作成時に、外部検証可能な具体的事実を追加する場合も、根拠を確認できない内容を確定事項として記載しない。

1.2 確度を変えない

元情報の確度を保持する。

「可能性がある」を「発生する」に変えない。

「推測される」を「判明した」に変えない。

「一因と考えられる」を「原因である」に変えない。

「確認できていない」という留保を、文章を簡潔にするためだけに削除しない。

1.3 情報の種類を区別する

必要に応じて次を区別する。

事実
確認できている情報。

推論
確認済みの情報から合理的に導いた解釈。

仮説
まだ確認されていない可能性。

提案・判断
筆者または組織としての評価や推奨。

推論や提案を客観的事実として書かない。

1.4 因果関係を作らない

出来事Aの後に出来事Bが起きただけで、AをBの原因と断定しない。

複数要因が考えられる場合は、一つの原因へ単純化しない。

因果関係を述べる場合は、それを支える根拠または機構があるか確認する。

2. 読み手が必要な情報を先に置く

文章構成は目的によって変える。すべての文書に同じ型を強制しない。

2.1 判断・承認・依頼

何を判断、承認、実行してほしいのかを早い位置で明確にする。期限がある場合は併記する。

背景説明から長く始めない。

2.2 報告

必要に応じて次の順序を検討する。

1. 結論または現在の状態
2. 影響
3. 根拠または経緯
4. 対応
5. 次のアクション

目的に合わない場合はこの順序を強制しない。

2.3 インシデント・障害・セキュリティ報告

次を混同しない。

• 確認できていること
• 確認できていないこと
• 影響
• 実施済みの対応
• 今後の対応

調査中の事項を確定事項として書かない。

2.4 技術説明・解説

理解しやすい場合は、次の順序を利用する。

1. 定義
2. 要点
3. 比較または違い
4. 具体例

必要な背景がある場合は先に説明してよい。

2.5 Slack・チャット・メール

用件、依頼、判断事項、期限など、読み手が最初に必要とする情報を早い位置に置く。必要な背景だけを後から補足する。

3. 論理を守る

3.1 主張を根拠より広げない

一つの事例だけを根拠に「一般的」「すべて」「必ず」などと一般化しない。

例は例として扱う。

3.2 比較条件を揃える

製品、方式、企業、制度などを比較する場合は、可能な限り同じ評価軸を使う。

条件の異なる数値を、違いを説明せず直接比較しない。

3.3 指示対象を明確にする

「これ」「それ」「この問題」などが何を指すか曖昧な場合は、具体的な名称へ戻す。