mcpField
J
japanese-tech-writing

japanese-tech-writing

github.com/hikimayドキュメント1554 回インストール19 週間前に更新
リポジトリ

japanese-tech-writing について

一連の文章規範に沿って、日本語の技術文書を生成・推敲するスキルです。論理的な説明文を必要とする LLM の利用者を対象に、公開前の評価や、AI らしい表現の確認にも対応します。

主な機能

  1. 01日本語の技術文書を生成
  2. 02既存テキストの推敲と校正
  3. 03AI らしい表現の診断と置き換え
  4. 04採点基準による公開前チェック
  5. 058 つの観点から文章規範を適用

活用シーン

  1. 01読者を定めた技術記事の執筆
  2. 02日本語の技術書章の編集
  3. 03公開前の文書評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/hikimay/japanese-tech-writing --skill japanese-tech-writing

インストール後、Claude Code で/japanese-tech-writingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE
.gitignore
README.md
benchmark/
README_with_skill.md
README_no_skill.md
BENCHMARK.md
reference/
checklist.md
ng-vocab.md
rules.md

詳細

プロジェクトの README より

japanese-tech-writing

生成AIに日本語の技術文書(書籍の章、技術記事、解説文など)を書かせる/推敲させるときに、文章の質を制御するためのスキルです。k16shikano 氏の「日本語技術文書の文章規範」に基づき、論理的で誠実な日本語テクニカルライティングを生成し、LLMが陥りがちな「ちゃんと書いている感」だけの文章を避けます。

このスキルが対象とするのは、論理で読ませる説明文です。マーケティングコピーや小説など、演出が主目的の文章には適用しません。

いつ使うか

  • 日本語の技術文書・技術記事・解説文を新規に生成するとき
  • 既存の日本語技術文書を規範に照らして推敲・校正するとき
  • 生成した文章が「AIっぽい」と指摘されたとき、その原因を診断して直すとき
  • 公開前に文章を採点して合否を判定するとき

使い方

ユーザーの依頼から、次のどちらのモードかを判断してください。

モードA:生成(新規に書く)
  1. 何の技術文書を、誰(どの役割の読者)に向けて、どの分量で書くのかを確認する。不明なら最小限だけ質問する。
  2. rules.md の全規範を書きながら適用する。後から直すのではなく、最初から規範に沿って書く。
  3. 書き終えたら checklist.md で自己点検し、違反があれば直してから提示する。
  4. ユーザーには本文だけを示し、適用した規範の解説を本文に混ぜない。
モードB:推敲・校正(既存の文章を直す)
  1. 対象テキストを受け取る(ファイルパスまたは貼り付け)。
  2. checklist.md の各項目と ng-vocab.md の語彙で全文を点検し、違反箇所を特定する。
  3. 次の優先順位で直す。上から潰すほど後段の判断が楽になる。
    1. 主張・厳密さ(観点 3)— 主張がない・因果や定義が不正確なら、まずそこを正す。
    2. 主体性(観点 5)— 無生物主語・受動でぼかした箇所を、行為者の能動態に書き換える。
    3. 構造(観点 2・4)— 段落の崩れ、見出し、冒頭の盛りすぎを直す。
    4. 語彙とフレーズ(観点 6・7・8 と ng-vocab.md)— 予告総括・AI 臭の語を削る/置き換える。
    5. 記号・整形(観点 1)— 和欧文間スペース、ダッシュ・中黒、コードブロックを最後に整える。
  4. 修正版を提示する。あわせて、どの規範のどの違反をどう直したかを箇条書きで簡潔に示す(学習のため)。
  5. 意味が一意に決まらず勝手に直すと内容が変わる箇所は、直さずに指摘し、ユーザーに判断を仰ぐ。
モードC:公開前チェック(採点して合否を出す)

「公開前チェック」「点数をつけて」などと依頼されたとき。checklist.md 末尾の採点ルーブリック(6 軸×10 点)で採点し、合計と各軸の点、減点理由、書き直しの要否を示す。合格ラインは 42/60。0〜2 点の軸が一つでもあれば書き直しとする。

規範の要点(詳細は rules.md)

8つの観点で文章を制御します。

  1. 整形 — 一文一改行、段落は空行区切り、コードはコードブロック、補足は脚注、用語の初出は太字。日本語中の半角英数字は前後に半角スペースを入れる(例:「これは LLM の特徴」)。
  2. 段落と論証の構成 — 一段落一トピック。段落冒頭で内容を明示し、接続表現で前段落との関係を示す。論証は一方向、結論は一度だけ。
  3. 論証の厳密さ — 根拠なき推量表現は削るが必要な不確実性は残す。異なるものを同一視しない。複数要因を単一原因に還元しない。因果は機構まで説明する。「必ず」など絶対化を避ける。
  4. 読み手の負荷の管理 — 不要な固有名詞を避ける。抽象表現は括弧で補う。新しい例は必要性を前置きする。冒頭で詳細を盛りすぎない。
  5. 視点と語り — 能動態で行為者を主語にする。無生物を主語にして主体をぼかさない(false agency)。「あなた」でなく役割名。「AI」「ツール」のような曖昧語を避ける。術語は一度導入したもので通す。分野の慣用訳語を選ぶ。
  6. 演出の抑制 — 説明で足りる箇所に溜め・修辞疑問・決め台詞を使わない。太字は誤読防止と帰結に限定。危険や事故を煽らない。
  7. LLMっぽい表現の禁止 — 「重要なのは〜である」「正面から〜」「不可欠」「核心的」「掘り下げる」など、中身のない予告・総括・姿勢宣言・空虚な形容を使わない。具体的な NG 語彙と置き換えは ng-vocab.md に一覧化。
  8. 冗長の排除 — 同じ主張を言い換えて繰り返さない。場面描写後の要約を重ねない。読者が補える中間説明やメタな枠取り(「〜という発想である」)を書かない。

重要な原則

  • これらの規範は生成時に最初から守る。「あとで推敲する」前提で雑に書かない。
  • 規範どうしが衝突したら、論証の厳密さ(観点3)を最優先する。不確実性を残すことが正確さに必要なら、簡潔さより正確さを取る。
  • 規範を守るために事実を曲げたり、必要な留保を消してはならない。

コメント