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 指示対象を明確にする

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

ただし、同じ固有名詞を不自然に繰り返さない。

3.4 接続語で論理を偽装しない

「つまり」「したがって」「一方で」「そのため」などは、前後に実際の論理関係がある場合だけ使う。

4. 冗長さを減らす

同じ結論や説明を、情報量を増やさず繰り返さない。

内容のない前置きや総括を機械的に追加しない。

「非常に重要です」「注目すべきです」などの評価表現は、その文自体に情報がある場合だけ使用する。

箇条書きは、並列関係、比較、選択肢、手順などに有効な場合に使う。通常の説明まで細切れにしない。

5. 自然な日本語にする

5.1 AIらしさ自体を品質基準にしない

AIが書いたように見えるかどうかだけで文章を評価しない。

AI検出を回避する目的で文章を書き換えない。

評価対象は、正確性、明瞭さ、読みやすさ、読み手への適合性、筆者の意図である。

自然さのために正確性を犠牲にしない。

5.2 空虚な定型表現を減らす

抽象的な評価語や定型句を、具体的な情報の代わりに使わない。

例として「重要なのは」「多岐にわたる」「今後ますます」などがある。

これらの表現自体は禁止しない。削除しても意味が変わらない場合だけ、削除または具体化する。

5.3 過度な演出をしない

業務文書では、必要がない限り次を追加しない。

• 連続した問いかけ
• 不必要な煽り
• 意図的な「溜め」
• 未回収の謎
• 大げさな転換
• 過剰な比喩

読み物、広告、創作など、それ自体が目的の場合は専用のスタイルを優先する。

6. 媒体と筆者の文体を尊重する

このスキルは組版規則を強制しない。

次のような規則を全文章へ一律適用してはならない。

• 一文ごとの改行
• 初出語の太字化
• 脚注の使用
• 特定の見出し構成
• コラム記法
• 「ですます調」「である調」への一律変更

Slack、メール、Notion、提案書、技術記事、議事録など、それぞれの媒体と目的に合わせる。

既存文章を修正する場合は、明確な変更指示がない限り、筆者の文体、敬語レベル、語調を尊重する。

7. 外部情報を追加する場合

重要な外部事実を追加する必要があり、利用環境に検索または情報取得機能がある場合は、可能な範囲で確認してから記載する。

利用可能であれば、公式発表、規制当局、標準化団体、ベンダー公式資料、原典などの一次情報を優先する。

確認していない情報を確認済みのように書かない。

存在しない引用、出典、URLを作らない。

出典表示が必要な用途では出典を示す。日常的な社内チャットなど、目的に合わない場合まで機械的に引用を追加しない。

8. 既存文章を修正する場合

修正、要約、短縮、整形では、まず元文章の意味を保つ。

特に次を勝手に変更しない。

• 主張と結論
• 数字、日付、固有名詞、引用
• 条件、例外、確度
• 責任主体、時制
• 文体、敬語レベル

内容自体に疑義がある場合は、文章を自然にして隠すのではなく、必要に応じて疑義を指摘する。

レビューでは問題点と修正案を区別する。書き換えを求められた場合は、原則として完成した修正版を提示する。

9. 過剰修正を避ける

元文章に問題がない箇所まで書き換えない。

筆者特有の表現や語彙を、一般的なAI文章へ均質化しない。

短い文章を不必要に長くしない。

簡単な内容を専門的に見せるためだけに抽象化しない。

「丁寧にする」ことを理由に情報密度を下げない。

10. 最終確認

出力前に必要な範囲で確認する。

1. 元情報にない事実を作ったり、確度を変えたりしていないか。
2. 事実、推論、仮説、提案を混同していないか。
3. 読み手、目的、媒体に適した構成と文体になっているか。
4. 不要な反復、定型表現、過剰な書き換えが残っていないか。

確認結果自体は、求められない限り出力しない。

適用しないケース

創作、広告コピー、コード、設定ファイル、構造化データ、計算など、業務文章の意味品質が主な評価対象ではないタスクには原則として適用しない。

それらに付随する説明、報告、レビューには適用してよい。