write-better について
AI エージェント向けの、明確な文章を書くためのガイドです。専門的な連絡やドキュメントを対象に、具体的な表現、実用的な構成、明示的な行動、反復や根拠のない強調の削除を扱います。
主な機能
- 01要点から書き始める
- 02具体的で平易な表現
- 03行動と制約を明示
- 04文体に合わせて調整
- 05反復や宣伝表現を削除
- 06実用的な書式を維持
活用シーン
- 01明確な業務メッセージの作成
- 02技術ドキュメントの編集と再構成
- 03文章の反復や冗長表現の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ plannotator/ write-better --skill write-betterインストール後、Claude Code で/write-betterを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
AI エージェント向けの文章作成ガイド
読み手が読み返さなくても、要点、根拠、次の行動がわかるように書きます。読み手の注意を大切にし、平易な言葉、具体的な詳細、有用な構成を使います。
1. 役立つ情報から始める
要点は最初の1、2文で伝えます。
ビジネス上のコミュニケーションでは、次のいずれかを冒頭に置きます。
- 依頼
- 決定
- 結論
- 結果
- 問題
- 関連する事実
読み手が読む理由を理解してから、背景を加えます。
悪い例:
プロジェクトのスケジュールについて、背景をお伝えしたくご連絡しました。
良い例:
決済テストがまだ失敗しているため、リリース日を5月12日から5月19日に変更します。
機微な情報、法的な情報、安全に関わる情報、または意外な情報を正しく理解するために必要であれば、簡単な背景を先に伝えてもかまいません。
2. すべての文に役割を持たせる
すべての文は、読み手が知ること、判断すること、または行うことを変える必要があります。
文には、次のような内容を含められます。
- 事実
- 定義
- 理由
- 根拠
- 条件
- 制約
- 結果
- 例外
- 警告
- 決定
- 行動
- 具体例
すでに述べた要点を予告したり、強調したり、要約したり、飾ったりするだけの文は削除します。
よくある冗長な表現:
- 「この違いは重要です。」
- 「重要な点として……」
- 「実践的な考え方はシンプルです。」
- 「これは……の重要性を示しています。」
- 「知っておくべきことは次のとおりです。」
- 「今日の急速に変化する環境では……」
- 「本質的には……」
- 「本当の問題は……」
情報をそのまま伝えます。
3. 長さではなく、情報を保つ
元の事実、要件、条件、必要な例を残します。
次のことができます。
- 内容のない文を削除する
- 段落をまとめる
- 重複した説明を削除する
- 例を短くする
- 情報の順序を入れ替える
- 抽象的な表現を具体的な言葉に置き換える
元の段落数や文数を保つ必要はありません。冗長な5段落の原稿を、2段落にまとめる必要がある場合もあります。
4. 平易な言葉を使う
なじみのある言葉と直接的な表現を優先します。
次のように言い換えます。
- 「利用する」ではなく「使う」
- 「促進する」ではなく「助ける」
- 「強化する」ではなく「改善する」
- 「活用する」ではなく「使う」
- 「役割を果たす」ではなく「である」
- 「誇る」ではなく「持つ」
- 「能力を備えている」ではなく「できる」
次の言葉は、使う前によく検討します。
深く掘り下げる、活用する、堅牢な、シームレスな、効率化する、利用する、包括的な、全体的な、促進する、最適化する、最大限に活用する、乗り越える、状況、領域、育む、力を与える、重要な、不可欠な、極めて重要な、大幅に
正確な技術的意味がある場合は使い、正確さを加えずに文章を飾るだけなら削除します。
良い例:
コンパイラーは、繰り返し行われる検索を最適化します。
弱い例:
このプラットフォームは、シームレスな自動化を通じて顧客体験を最適化します。
5. 具体的に書く
人名、日付、数値、担当者、システム、実際に確認できる行動を使います。
弱い例:
提供を効率化するため、部門間の連携を改善する必要があります。
良い例:
Priya は火曜日までに、改訂版の API スキーマをモバイルチームに送ります。チームは木曜日までに移行日を確定します。
読み手が実際の場面を思い浮かべられる表現を優先します。
できる限り、抽象名詞を行動に置き換えます。
- 「評価を実施する」は「評価する」
- 「決定を下す」は「決める」
- 「支援を提供する」は「助ける」
- 「検査を実施する」は「検査する」
6. 行動を実行しやすい形で示す
依頼では、次の点を明確にします。
- 誰が行動するのか
- 何をするのか
- いつまでに行うのか
- 完了したとどう判断するのか
弱い例:
ご意見をお聞かせください。
良い例:
木曜日の午後3時までに、改訂後のリリース日を確認してください。
メッセージごとに、主な成果は1つに絞ります。関連する複数の行動をまとめて示してもかまいませんが、それぞれを明確にします。順序、担当、完了の確認が重要な場合は、番号を付けます。
7. ジャンルに合わせる
明瞭さを保つために、どこでも同じ語り口にする必要はありません。
ドキュメントでは、次の点に留意してください。
- 現在の動作を説明する
- 使い方を説明する
- 制約や失敗条件を明記する
- 曖昧さを解消する場合にのみ例を含める
- 宣伝文句や個性を避ける
職場でのメッセージでは、次の点に留意してください。
- 相手との関係にふさわしい口調を使う
- 丁寧さは簡潔に保つ
- 依頼内容がすぐに分かるようにする
- 不必要に形式ばった表現を避ける
エッセイや個人的な文章では、次の点に留意してください。
- 本物の意見や迷い、ユーモア、不規則さを保つ
- 人間らしく見せるために癖を作り出さない
- それが作者の語り口に含まれない限り、脱線や断片的な表現、わざとらしい自己訂正を加えない
文体上の癖を合わせる前に、ジャンルに合わせてください。
8. 作者の語り口を保つ
文章のサンプルがある場合は、次の点を確認してください。
- 文の長さ
- 語彙
- 段落の書き出し
- 句読点
- 形式ばり具合
- 話題のつなぎ方
- ユーモア
- 繰り返し使われる表現
意味のある不規則さを保ってください。作者の語り口を、ありきたりなカジュアル調に置き換えないでください。
人間が書いたと示すために、個性を加えないでください。
9. 修辞的な飾り立てを避ける
ありふれた情報を、スローガンや格言、短い演説のように仕立てないでください。
次のような定型表現は避けてください。
- 「Xではありません。Yです。」
- 「Xだけの問題ではありません。Yの問題でもあります。」
- 「XはYの言語です。」
- 「Xは罠になります。」
- 「Xの未来はYです。」
- 「本当に重要なのは……」
- 「問題の核心は……」
読者が誤った認識を持っている可能性が高く、それを正すことで行動が変わる場合に限り、対比を使って訂正してください。
弱い例:
これは単なるパフォーマンス改善ではありません。開発者体験を一変させるものです。
よい例:
この変更により、ビルド時間が11分から4分に短縮されます。
10. 根拠のない強調を避ける
重要、重大、極めて重要、画期的といった、根拠のない主張は避けてください。
その結果を説明してください。
弱い例:
これは組織にとって極めて重要な変更です。
よい例:
この変更がなければ、9月1日以降、会社はEUの顧客データを処理できません。
事実そのものに強調を担わせてください。
11. メタ言説を抑える
メタ言説とは、情報を伝えるのではなく、文章の読み取り方を読者に示す表現です。
よくある例:
- 「つまり……」
- 「この違いは……」
- 「別の言い方をすると……」
- 「注目すべきなのは……」
- 「重要な点は……」
- 「お分かりのように……」
- 「詳しく見ていきましょう……」
- 「では、次に見てみましょう……」
実際の構成上の曖昧さを解消するときに限り、こうした表現を使ってください。段落ごとの書き出しに置いて、つながりを人為的に作らないでください。
数を示しても情報が増えない場合は、これから述べる項目数を冒頭で宣言しないでください。
弱い例:
知っておくべきことは3つです。まず、移行中は書き込みが一時停止します。
よい例:
移行中は5分間、書き込みが一時停止します。
番号付きの手順をたどる、要件を確認する、あるいは数量に意味があることを理解するうえで役立つ場合は、数を示してください。
「これ」や「あれ」で始まる段落を確認してください。その段落が前の内容を言い換えるのではなく、説明を前に進めていることを確かめてください。
12. 意味の重複を避ける
同じ主張を、言葉を変えて繰り返さないでください。
言い換えには、次のうち少なくとも1つを加えてください。
- より高い精度
- 必要な例
- 結果
- 制限
- 例外
- 実務上の指示
同じ点を何度も説明する言い換えの連鎖は削除してください。
13. 構成に役立つ場合にのみリストを使う
次のような場合はリストを使ってください。
- 項目を比較する
- 手順に沿って進める
- 要件を確認する
- 担当者を特定する
- 選択肢を見比べる
3項目のまとまりに無理に当てはめないでください。リズムや網羅性のために、3つ目の項目を加えないでください。
文章や表のほうが読みやすい場合は、太字のラベルを付けた長いリストを避けてください。
14. 情報に合わせて文の構造を変える
中程度の長さの文を一様に並べないでください。短文と長文を無理に交互に配置するのも避けてください。
リズムに変化をつけるためだけに、断片的な文や大げさな間を加えないでください。
文章を声に出して読み、次のような場合は修正してください。
- すべての文が同じ形になっている
- 節が繰り返し3つずつ並んでいる
- 各段落の最後が決めぜりふになっている
- 短文をいくつも並べてドラマチックに見せている
- 文章に明らかなパターンがある
文の長さは、情報の量と情報どうしの関係に合わせてください。
15. 主語と動詞を明確にする
責任の所在が重要な場合は、行為者を明示してください。
よくない例:
リクエストが審査され、判断が下されました。
よい例:
セキュリティチームはリクエストを審査し、却下しました。
行為者が不明、無関係、すでにわかっている場合や、プロセスのほうが重要な場合は、受動態を使ってもかまいません。
許容される例:
トークンは30日後に削除されます。
問題は受動態そのものではなく、責任の所在が不明確なことです。
動詞が観察可能な動作を表す場合は、システムやツールを主語にしてもかまいません。
許容される例:
API は JSON を返します。
文字どおり正確でない限り、ソフトウェアに人間の意図、信念、願望を持たせないでください。
よくない例:
プラットフォームは、ユーザーをセットアップの手順に沿って案内しようとしています。
よい例:
オンボーディングのフローでは、セットアップの各手順が順番に表示されます。
16. 同義語を次々に使わない
正確さが重要な場合は、適切な用語を繰り返し使ってください。
よくない例:
顧客がリクエストを送信します。次に、ユーザーが応答を受け取ります。アカウント所有者は結果を確認できます。
よい例:
顧客はリクエストを送信し、応答を受け取り、結果を確認します。
技術文書では、用語を一貫して使うことが大切です。
17. 根拠のない深みを加えない
根拠のない解釈を加える分詞句に注意してください。
- 強調している
- 裏付けている
- 反映している
- 示している
- 象徴している
- 促進している
- 貢献している
- 確実にしている
よくない例:
再設計では青と緑を使い、信頼と成長に対する会社の取り組みを反映しています。
よい例:
再設計では青と緑を使っています。デザインブリーフによると、これらは既存のブランドカラーです。
出典がない限り、象徴性、意図、重要性を推測しないでください。
18. 曖昧な権威を持ち出さない
次のような書き方は避けてください。
- 「専門家によると……」
- 「識者は……と指摘しています」
- 「業界レポートによると……」
- 「批評家は……と論じています」
- 「調査によると……」
出典を明記し、調査結果を示してください。
よい例:
Stack Overflow は、開発者640人を対象にした2025年の調査で、締め切りに追われているときに AI 生成コードを以前より慎重に確認しない人が42%に上ることを明らかにしました。
信頼できる出典がない場合は、その主張を削除するか、不確実であることを明確に述べてください。
19. 宣伝文句を避ける
ドキュメントや事実に基づく文章を、広告のようにしないでください。
次のような表現は削除してください。
- 革新的な
- 活気に満ちた
- 息をのむような
- 著名な
- 世界最高水準の
- 強力で直感的な
- 豊かな歴史
- 卓越性への取り組み
- ワクワクする旅
- 明るい未来
賛辞は観察可能な詳細に置き換えてください。
よくない例:
プラットフォームは、シームレスで強力な操作性を実現します。
よい例:
プラットフォームは最大2 GBの CSV ファイルをインポートし、行単位の検証エラーを報告します。
20. 句読点は簡潔に使う
em ダッシュは使わないでください。
次のように置き換えてください。
- 独立した内容にはピリオド
- 短い挿入句にはコンマ
- 説明にはコロン
- 本当に補足的な内容には括弧
大げさな効果を生み出すために句読点を使わないでください。
適用されるスタイルガイドが範囲や複合的な関係を示すために求める場合に限り、慣例的な en ダッシュを維持してください。ハウススタイルによっては、それらも置き換えることがあります。
21. 書式を機能的に保つ
避けること:
- 機械的な太字
- 業務向けの見出しに絵文字を使うこと
- すべての見出しをタイトルケースにすること
- 装飾的なコールアウト
- 見出しの直後に、その内容を言い換えただけの文を置くこと
- 「重要なポイント」ボックスを繰り返すこと
- 不要な結論セクション
既定のスタイルガイドで指定されている場合を除き、見出しにはセンテンスケースを使います。
書式は、情報を見つけやすくするために使います。
22. 丁寧さは適度に保つ
相手との関係を維持するのに必要なだけ丁寧にします。それ以上は必要ありません。
避けること:
- 「お変わりなくお過ごしのことと存じます。」
- 「どうぞ遠慮なくご連絡ください。」
- 「喜んで対応させていただきます。」
- 「もしかすると、お願いできないかと思いまして……」
- 「もちろんです!」
- 「まったくそのとおりです!」
- 「すばらしい質問です!」
挨拶とお礼は、それぞれ通常一度で十分です。
率直であることは、失礼であることではありません。依頼を明確に伝え、相手の時間を尊重します。
23. 不確実な点は正直に扱う
判明していること、分かっていないこと、不確実性を解消するために必要なことを示します。
良い例:
ログから、認証後にリクエストが失敗したことは分かります。上流サービスがタイムアウトしたかどうかは分かりません。それを確認するにはゲートウェイのログが必要です。
もっともらしい背景情報、曖昧な経歴、一般論で不足を補わないでください。
曖昧な表現を重ねないでください:
その可能性もあり得るかもしれませんが……
最も限定的で正確な表現を使います:
- ~の可能性があります
- おそらく
- ~のようです
- 入手可能な証拠からは~が示唆されます
24. 現在の状態を説明する
ドキュメントやコメントでは、通常、システムが現在どのように動作するかを説明します。
不十分な例:
この関数は、すべての項目を反復処理していた以前の実装を置き換えるために追加されました。
良い例:
この関数はハッシュマップを使い、定数時間で検索します。
変更の経緯を説明するのは、変更履歴、リリースノート、移行ガイド、インシデントレポート、または歴史的な説明に限ります。
25. 作業が終わったら締める
必要な情報を伝えた後に、一般的な結論を付け加えないでください。
避けること:
- 「結論として……」
- 「明るい未来が待っています。」
- 「これは正しい方向への一歩です。」
- 「これからが楽しみです。」
- 「お役に立てれば幸いです。」
- 「質問があればお知らせください。」
結果、決定事項、期限、または次のアクションで締めます。
編集プロセス
ユーザーから分析を求められない限り、このプロセスは内部で使用します。
第1段階:意味
以下を特定します:
- 主旨
- 必要な事実
- 決定事項
- 制約
- 不確実な点
- アクション
- 期限
裏付けのない主張や創作した詳細は削除します。
第2段階:構成
主旨を冒頭に置きます。
関連する情報をまとめます。重複を削除します。弱い段落を統合します。見出しは、情報を探しやすくなる場合にのみ追加します。
第3段階:言葉遣い
以下のように置き換えます:
- 抽象名詞を動詞にする
- 曖昧な主張を具体的にする
- 儀礼的な表現を率直な表現にする
- 宣伝文句を観察可能な事実にする
- 同じ意味の語を使い分けるのではなく、用語を統一する
第4段階:修辞
以下を削除します:
- スローガン
- 無理な対比
- 格言めいた表現
- 三つ並べるだけの構成
- 作為的な決め台詞
- 重要性を強調する表現
- 内容のないつなぎ言葉
- 率直さを装った書き出し
- チュートリアル風の予告
第5段階:リズムと句読点
声に出して読みます。
以下を確認します:
- 文の長さが一様になっていないか
- 文型が繰り返されていないか
- 断片的な文が重なっていないか
- 括弧内の補足が多すぎないか
- ダッシュを使いすぎていないか
- 大げさな句読点を使っていないか
- 段落が整いすぎた締め方になっていないか
リズムが明瞭さを損なう場合や、不自然に聞こえる場合にのみ修正します。
最終確認:読者の視点
次の点を確認します:
- 読者は主旨をすぐに把握できますか?
- 各文に有用な情報がありますか?
- アクション、担当者、期限が明確ですか?
- 省いても意味が変わらない文はありませんか?
- トーンは相手との関係や文書の種類に合っていますか?
- 洗練されて聞こえるという理由だけで残っている表現はありませんか?
- 著者本来の語り口を保っていますか?
- 適切なところで文章が終わっていますか?
最終版を返します。求められない限り、下書き、監査、自己批評は公開しません。