日本語の文章を、事実・数字・専門用語・書き手の声を保ちながら作成・編集するAgent Skillです。Codexなどの対応エージェントに、文章の整え方を指示するファイルをまとめています。
自然な日本語への推敲、やさしい日本語への調整、技術文書の作成を、一つの入口から扱います。読者が「その分野をどれくらい知っているか」と「日本語をどれくらい読めるか」を分けて考え、必要な説明と表現を選びます。
文章や資料を渡して、何をしてほしいかを伝えれば使えます。モード名や内部の設定を覚える必要はありません。
- 文章を推敲する：意味の薄い前置きや反復を減らし、文のつながりと語調を整えます。
- やさしい日本語にする：期限、条件、例外、正式な名称を残しながら、語彙と文型を調整します。
- 技術を説明する：提供されたコードや資料を根拠に、概念説明、手順書、障害の切り分け、比較資料を作ります。
- 書き手の声と会話を保つ：作者サンプルや既存の書式を尊重し、共有済みの前提を繰り返さずに会話を続けます。
- なんJ風の掛け合いにする：明示された場合に、猛虎弁やレス番号、アンカーを使って架空のスレッドにします。口調だけの変換も選べます。
- 問題点だけ確認する：全文を書き換える前に、重要な問題を1〜5件に絞って示します。
たとえば、次のように文章を整えます。以下は動作を説明するための架空の例です。
入力
申請につきましては、9月10日までに提出していただく必要があります。なお、期限後の申請は受け付けておりません。
編集例
申請は9月10日までに提出してください。期限を過ぎた申請は受け付けません。
期限と受付条件を保ちながら、依頼内容を直接伝えます。必要な専門語や細かい条件まで削って短くすることは、編集の目標にしていません。
Gitが使える環境で、次のコマンドを実行します。macOS・Linuxのシェルで、個人用のスキルとして配置する例です。
mkdir -p ~/.agents/skills
git clone --depth 1 --branch main https://github.com/Eonshore/humanizer-ja-editor.git ~/.agents/skills/humanizer-ja-editorプロジェクト内だけで使う場合は、そのプロジェクトの .agents/skills/humanizer-ja-editor に配置してください。既に同名のフォルダがある場合は、中の変更を確認してから更新します。同じスキルを複数の場所へ重ねて配置する必要はありません。
Codexのスキル一覧で Humanizer JA Editor を選び、文章を渡します。CLIやIDE拡張では、次のように名前を指定できます。追加後に見つからない場合はCodexを再起動してください。配置先と呼び出し方の詳細は、OpenAIの公式スキルガイドを参照してください。
$humanizer-ja-editor
この文章を、事実と語調を保って自然な日本語に直してください。
（ここに文章を貼る）
Agent Skills形式を読み込めるクライアントの手順に従い、リポジトリのフォルダを配置します。GitHubからZIPをダウンロードした場合は、展開したフォルダ名を humanizer-ja-editor にしてください。
SKILL.mdだけでなく、references/などを含むフォルダ全体が必要です。クライアントごとの呼び出し方法や対応状況は、そのクライアントの仕様に従います。
スキルの中心は文章による指示です。補助スクリプトを実行する場合はPython 3.10以上が必要で、外部のPythonパッケージは不要です。
基本的には、対象・目的・守りたいものを伝えれば十分です。想定読者や作者サンプル、変更してよい範囲に希望がある場合は追加してください。
draft.mdを自然な日本語に直してください。事実、常体の語調、段落の順序は保ってください。
分野の初心者向けの説明と、日本語学習者向けの調整は別々に指定できます。必要なら両方を使います。
読者は日本語を読めますが、この技術は初めてです。専門用語を消さず、必要になる理由と小さな例から説明してください。
読者は技術者で、日本語を学習中です。技術の初歩は説明し直さず、文型と情報の順序を整えてください。
この導入資料から、開始前の条件、操作、確認結果、失敗したときの戻り先が分かる手順書を作ってください。資料にない実行結果は追加しないでください。
障害メモの整理では観察と原因候補を分け、比較資料では各候補を同じ条件で比べます。資料にない原因、重み、点数、成功実績を補いません。
共有済みの前提を繰り返さず、この会話の続きとして応答してください。新しい提案や総括は足さないでください。
この説明を、なんJのスレッド風にしてください。ノリは標準で7レス。数字、条件、誰が確認したか、未確認の点は残してください。
この3行を、なんJ風の口調だけにしてください。行数と一人の文章という形を保ち、レス番号は付けないでください。
ノリは「控えめ」「標準」「濃いめ」を指定できます。架空の話者や掛け合いは演出として加えますが、資料にない実体験、評判、性能を事実として追加しません。通常の編集や、GitHubなどの「スレッド」という語だけでは適用しません。詳しくはなんJスレッド風プロファイルを参照してください。
この文章の重要な問題点だけを示してください。全文の改稿はまだ不要です。
細かく指定したい場合は、出力モードと場面ごとの編集方針を参照してください。完成文への書き直し、問題点の指摘、ファイル編集、資料からの文書作成を選べます。
v0.7.0では、yasashii-nihongo-writerのやさしい日本語と会話の指針、japanese-tech-writingの用語・論証・原稿書式の指針を統合しました。新しく導入する場合は、このスキルだけを配置してください。
- やさしい日本語への調整は、読者と目的を添えて依頼できます。
- 技術文書の用語と論証は、技術文書を扱うときに適用します。
- 一文一行や記号の使い方などの原稿スタイルは、必要な書式として明示された場合に適用します。一般の技術文書へ一律には適用しません。
独立した旧スキルを導入済みの場合は、独自の変更を退避したうえで呼び出し先を humanizer-ja-editor に切り替え、旧スキルの重複適用を解除してください。旧名の互換入口は、このリポジトリには同梱していません。既存の依頼で旧名の原稿書式を使う場合は、humanizer-ja-editorに「旧japanese-tech-writingの原稿スタイルを使う」と伝えられます。
主体と責任、数字と単位、条件と例外、確度、引用、コード、パス、URLを保つことを優先します。作者サンプルがある場合は、その声を一般的な文章規則より優先します。元の文章にない実在の人の体験・感情、出典、因果関係は追加しません。明示的に求められた架空の掛け合いは、対象についての事実と区別して作ります。
これはエージェントへの指示であり、出力の正確さを保証する仕組みではありません。書き換えた文章は、元の資料と照らして確認してください。AI生成の判定や検出回避は目的にしていません。
また、資料にテストや手順が書かれていることと、実際に成功したことを区別します。文書の作成だけで、未確認の動作や性能を実証済みとは扱いません。
v0.8.0では単体テスト12件と、なんJスレ形式・口調だけ・問題点の指摘・通常文の代表例を確認しました。文章評価の仕様は既存となんJを合わせた59件と、日本語統合の14件がありますが、全73件をモデルで実行した結果ではありません。観察した失敗、修正、再確認、未検証の範囲は検証結果に記載しています。
リポジトリのルートで実行します。
# 編集前後の数字、URL、コードなどの追加・脱落を調べる
python3 scripts/protect_audit.py before.txt after.txt --json
# 作者サンプルの文長、語尾、記号などを集計する
python3 scripts/profile_author.py samples/*.md --output author-profile.json前者は意味の同一性を証明するものではなく、後者は作者の説明戦略や専門知識を推定するものではありません。どちらも、文章を読んで確認する際の補助として使います。
検証方法と変更時の注意点はCONTRIBUTING.mdにまとめています。問題を報告する際は、個人情報を除いた入力、依頼文、期待した結果、実際の結果を添えてください。
MIT License。参考にしたプロジェクトと資料の帰属はNOTICE.mdに記載しています。参照先の文章や図などには、それぞれの権利と利用条件が適用されます。