はじめに
Xで@oga_aiichiroさんが公開された、新しい日本語推敲スキル「yomiyasu」が話題になっていました。AIが書いた文章の「なんかAIっぽい」を、単語の置き換えではなく文の構造から直すスキルらしいです。
ちょうど自分もQiitaを書くとき、AIに文章の校正を頼んだあとで「整っているけど自分が書いた感じがしないな」と直すことがよくあります。そこで今回は、同じく日本語を読みやすくする natural-japanese と japanese-tech-writing も加えて、同じClaude・同じ原文・同じ指示で比較しました。
結論から言うと、3つとも文章は読みやすくなりました。ただし、どこまで手を入れるかが全然違います。yomiyasu は原文をかなり残し、natural-japanese は段落から組み直し、japanese-tech-writing は技術文書として余分な表現を削りました。
同じ「日本語推敲スキル」でも、性格がちゃんと違う。面白いです。
今回は1つの原文を各スキルに1回ずつ通した比較です。モデルの出力には揺れがあるため、スキルの優劣を決める検証ではありません。「この文章では、どう直し方が分かれたか」を見る記事として読んでください。
比較した3つの日本語推敲スキル
yomiyasu
yomiyasu は、AIが生成した不自然な日本語を読みやすくするAgent Skillです。
特徴は、AIっぽい単語を禁止するだけではなく、「誰が・何を・どうした」という文の骨格を直すこと。非生物を主語にした表現や、「効く」「溶かす」「壊れる」といった曖昧な比喩も、文脈に合う具体的な表現へ直します。
さらに、文章内の太字や箇条書き、不自然な比喩などを検査する yomiyasu_lint.py も同梱されています。今回比較した中では、文章の書き換えと機械的な検査が1セットになっているのが特徴です。
natural-japanese
natural-japanese は、仕事の文書からブログやエッセイまで、日本語を読みやすくするAgent Skillです。
こちらは「設計 → 執筆 → 検査 → 収束」という流れを持っています。文章を部分的に直すだけでなく、主メッセージや見出し、段落の濃淡まで確認します。静的解析用のlintもあり、検出結果を見ながらAIが直すか残すかを判断する設計です。
japanese-tech-writing
japanese-tech-writing は、日本語の技術文書や書籍原稿を書くための文章規範です。
パラグラフライティング、論証の厳密さ、読み手の負荷、冗長な表現の削減など、技術文書としての読みやすさを細かく定義しています。AI臭さだけを消す専用スキルではありませんが、「LLMっぽい空句」や翻訳調の比喩を避けるルールも含まれているため、比較に加えました。
ざっくり整理すると、狙っている範囲はこうです。
| スキル | 主に直すところ | 仕組み |
|---|---|---|
| yomiyasu | 不自然な構文、比喩、装飾 | リライト規則＋専用lint |
| natural-japanese | 文体、段落構成、文書全体の設計 | 執筆工程＋複数の検査スクリプト |
| japanese-tech-writing | 技術文書の論理、冗長さ、読者の負荷 | 詳細な文章規範 |
同じClaude・同じ原文・同じ指示で比べる
比較日は2026年10月1日です。Claude CodeからClaude Sonnetを使い、effort: low、毎回新しいセッション、同じ原文・同じ依頼文で揃えました。
検証前に3つとも普段のスキル置き場から無効化し、各実行では--safe-modeでほかのプラグインやCLAUDE.mdも止めています。そのうえで、比較する1つのSKILL.mdだけを追加しました。
実行コマンドを見る
claude -p \
--safe-mode \
--model sonnet \
--effort low \
--no-session-persistence \
--append-system-prompt-file <比較するスキルのSKILL.md> \
'<同じ依頼文と原文>'
yomiyasuのREADMEにも、似た日本語校正スキルを同時に有効化すると指示が干渉するおそれがあると書かれています。今回は比較対象以外の指示が混ざらない条件に揃えました。
原文もClaude Sonnetに作ってもらいました。最初の比較では普通の導入文を頼んだところ、もともとの文章が整いすぎていて、3つともほとんど変わりませんでした。これでは比較にならない。
そこで今回は、「読者を強く惹きつける」「熱量高く」「印象的な比喩や強調表現も交える」という条件を足しました。人間がAI臭い例文を手書きするのではなく、Claude自身に装飾の多い文章を書いてもらっています。
今回は普段の文章生成を再現する検証ではなく、各スキルの修正傾向を見るため、あえてAIっぽい装飾を増やしたストレステストです。
Claude CodeのAgent Skillsを使って文章作成を効率化する魅力を伝える、
読者を強く惹きつけるQiita記事の一節を500〜700字で書いてください。
導入、メリット3点、締めを含め、熱量高く、
印象的な比喩や強調表現も交えてください。
です・ます調で、技術初心者にも伝わるようにしてください。
Markdownを使い、本文だけを出力してください。
生成された原文がこちらです。
同じ指示を何度も書く毎日は、もう終わりにしませんか?
記事を書くたびに「です・ます調で」「初心者向けに」「見出しはこの形式で」とAIに頼み直していませんか。この手間こそ、文章作成で最も地味に時間を奪う正体です。
そこで使いたいのが、Claude CodeのAgent Skillsです。Skillsは、あなた専用の「文章作成マニュアル」をAIに持たせる仕組みです。新人に毎回口頭で説明する代わりに、分厚い業務マニュアルを一度だけ渡しておくイメージです。
メリット1:書き方が毎回ブレない
文体、構成、用語のルールをSkillに書いておけば、誰がいつ頼んでも同じ品質で仕上がります。チームの記事に統一感が生まれ、「担当者によってトーンが違う」という悩みも消えます。
メリット2:指示が劇的に短くなる
「Qiita記事にして」の一言で、長い前提条件がすべて伝わります。毎回のプロンプトが呪文のような長文から、ひと言の合図に変わります。
メリット3:使い回して育てられる
Skillはただのファイルなので、改良も共有も簡単です。うまくいった書き方を足していくほど、AIはあなたの分身のように成長します。
さあ、最初の一歩を
プログラミングの知識がなくても、Skillsは「ルールを文章で書くだけ」で作れます。**文章作成を、繰り返す作業から育てる資産へ。**今日から、あなた専用の執筆パートナーを育て始めましょう。
太字が6箇所あり、「メリット1〜3」が同じ形で並びます。「呪文のような長文」「AIはあなたの分身」「育てる資産」と比喩も多め。最後は「さあ、最初の一歩を」で読者の背中を押します。
頼んだとおりではあります。でも、濃いな。
この原文を3つのスキルへ渡し、依頼文は次のように統一しました。
次の文章を、技術記事向けに読みやすくしてください。
本文だけを出力してください。原文にない情報は足さないでください。
yomiyasuは、構成を変えずに一部の比喩と装飾を直した
yomiyasuの出力です。
同じ指示を何度も書く毎日は、もう終わりにしませんか?
記事を書くたびに「です・ます調で」「初心者向けに」「見出しはこの形式で」とAIに頼み直していませんか。この手間が、文章作成で最も地味に時間を奪っている原因です。
そこで使いたいのが、Claude CodeのAgent Skillsです。Skillsは、あなた専用の「文章作成マニュアル」をAIに持たせる仕組みです。新人に毎回口頭で説明する代わりに、分厚い業務マニュアルを一度だけ渡しておくイメージです。
メリット1:書き方が毎回ブレない
文体、構成、用語のルールをSkillに書いておけば、誰がいつ頼んでも同じ品質で仕上がります。チームの記事に統一感が生まれ、「担当者によってトーンが違う」という悩みもなくなります。
メリット2:指示が大きく短くなる
「Qiita記事にして」の一言で、長い前提条件がすべて伝わります。毎回のプロンプトが長い指示文から、ひと言の合図に変わります。
メリット3:使い回して育てられる
Skillはただのファイルなので、改良も共有も簡単です。うまくいった書き方を足していくほど、AIはあなたの分身のように育ちます。
さあ、最初の一歩を
プログラミングの知識がなくても、Skillsはルールを文章で書くだけで作れます。文章作成を、繰り返す作業から育てる資産へ変えられます。今日から、あなた専用の執筆パートナーを育て始めましょう。
今回は違いがはっきり出ました。
- 太字をすべて削除
- 「時間を奪う正体」を「時間を奪っている原因」へ変更
- 「劇的に短くなる」を「大きく短くなる」へ変更
- 「呪文のような長文」を「長い指示文」へ変更
太字と一部の比喩は減りました。一方で、「もう終わりにしませんか?」「さあ、最初の一歩を」という呼びかけと、「AIはあなたの分身」「育てる資産」という比喩は残っています。文章全体の構成や熱量を変えず、強すぎる表現だけを普通の言葉へ戻した形です。
変化は大きくなりましたが、それでも原文の骨組みは残す。yomiyasuの「意味と比重を変えない」という方針が、一番見えた出力でした。
natural-japaneseは、段落の役割から組み直した
natural-japaneseの出力です。
Agent Skillsで、毎回の執筆指示をまとめて省く
記事を書くたびに「です・ます調で」「初心者向けに」「見出しはこの形式で」とAIに頼み直す手間は、文章作成で地味に時間を奪います。Claude CodeのAgent Skillsを使うと、この指示をまとめて渡しておけます。Skillsは、自分専用の「文章作成マニュアル」をAIに持たせる仕組みです。新人に毎回口頭で説明する代わりに、業務マニュアルを一度だけ渡しておくイメージです。
書き方が毎回ぶれなくなる
文体、構成、用語のルールをSkillに書いておけば、誰がいつ頼んでも同じ品質で仕上がります。チームの記事に統一感が出て、担当者によるトーンの違いも解消します。
指示が短くなる
「Qiita記事にして」の一言で、長い前提条件がすべて伝わります。毎回の長いプロンプトが、ひと言で済むようになります。
使い回しながら育てられる
Skillはただのファイルなので、改良も共有も簡単です。うまくいった書き方を足すほど、AIは自分の分身のように育ちます。
最初の一歩
プログラミングの知識がなくても、Skillsはルールを文章で書くだけで作れます。文章作成を、繰り返す作業から育てる資産に変えられます。まずは自分専用の執筆パートナーを作ってみましょう。
一番変化が大きかったのがnatural-japaneseでした。
疑問形だったタイトルを、内容がそのまま分かる見出しへ変更しています。「メリット1〜3」という番号も外し、各見出しを「書き方が毎回ブレない」「指示が短くなる」と具体化しました。導入の2段落を1段落にまとめたのも、ほかの2つにはない変更です。
ただ、太字は4箇所残り、「AIは自分の分身」「育てる資産」という比喩も残りました。文章全体の見せ方は一番変わりましたが、AIっぽい装飾を全部消すわけではありませんでした。
「担当者によってトーンが違うという悩みも消えます」を「担当者によるトーンの違いも解消します」とまとめていて、少し硬くなっています。構成は読みやすい。でも、期待していたほど脱臭一色ではない。意外でした。
japanese-tech-writingは、技術文書として短く整えた
japanese-tech-writingの出力です。
Agent Skills で毎回の執筆指示を省く
記事を書くたびに「です・ます調で」「初心者向けに」「見出しはこの形式で」とAIに頼み直す手間は、文章作成で意外に時間を取られる。Claude Code の Agent Skills を使うと、この指示を一度書いておくだけで済む。Skills は、文章作成のルールをまとめたマニュアルをAIに持たせる仕組みである。新人に毎回口頭で説明する代わりに、業務マニュアルを一度だけ渡しておくのに近い。
書き方が毎回ブレない
文体、構成、用語のルールを Skill に書いておけば、誰がいつ頼んでも同じ品質で仕上がる。チームの記事に統一感が出て、担当者によってトーンが違うという問題もなくなる。
指示が短くなる
「Qiita記事にして」と頼むだけで、長い前提条件がすべて伝わる。毎回書いていた長いプロンプトが、ひと言の指示で済むようになる。
使い回して育てられる
Skill はただのファイルなので、改良も共有も簡単である。うまくいった書き方を足していくほど、AIは書き手の好みに合った文章を出すようになる。
作り始めるには
プログラミングの知識は要らない。ルールを文章で書くだけで、Skill を作れる。文章作成を、毎回繰り返す作業から、育てていく資産に変えられる。まずは自分用の Skill を一つ作ってみてほしい。
冒頭の問いかけを事実の説明へ変え、「時間を奪う正体」「呪文」「分身」という比喩と太字を削っています。「メリット1〜3」の番号も外れました。3つの中で一番、技術文書らしい温度です。
一番驚いたのは、依頼で指定した「です・ます調」まで「である調」に変えたことです。技術文書として統一した結果だと思いますが、原文の文体を残すという点では変更が大きすぎます。
最後の呼びかけは「まずは自分用のSkillを一つ作ってみてほしい」と残っています。余計な演出はかなり減りましたが、書き手の指定より技術文書の規範を優先する出力になりました。
3つを並べると「直す範囲」が違った
今回の出力を比べると、違いは次のようになりました。
ざっくり選ぶなら上の図、実際の出力で確認できた細かい違いは下の表です。
| 比較した点 | yomiyasu | natural-japanese | japanese-tech-writing |
|---|---|---|---|
| 原文の残り方 | 構成と熱量を残す | 見出しと段落を組み直す | 論理を残して文体まで変える |
| 太字 | すべて削除 | 4箇所残す | すべて削除 |
| 比喩 | 一部を直して一部を残す | 「分身」「育てる資産」を残す | ほぼ削除 |
| 「メリット1〜3」 | 残す | 番号を外す | 番号を外す |
| 読者への呼びかけ | 強めに残す | 弱めて残す | 弱めて残す |
| 文体 | です・ます調を維持 | です・ます調を維持 | である調へ変更 |
自分の印象では、用途はこう分かれます。
- 書いた人の言い回しをなるべく残したいなら、yomiyasu
- 下書きの構成から読みやすくしたいなら、natural-japanese
- 技術文書として論理と冗長さを厳しく見たいなら、japanese-tech-writing。ただし文体まで変わっていないか確認する
ただし、これは今回の1出力だけを見た感想です。別の文章や実行では結果が変わる可能性があります。特に手書きの口調が強い文章では、natural-japaneseやjapanese-tech-writingが整えすぎるかもしれません。
自分は、まずyomiyasuを試したい
自分のQiita記事へ使うなら、まずyomiyasuを試します。
理由は、自分が書いた文章の癖や個性をなるべく残したいからです。読みやすくはしてほしい。でも、言い回しやテンポまで全部きれいな模範解答にされると、自分が書いた文章ではなくなってしまいます。その点、yomiyasuは元の構成や熱量を残しながら、引っかかる表現だけを直してくれました。
一方、AIにほぼ全編を書かせた下書きならnatural-japaneseが合いそうです。段落ごとの役割が明確になり、読み手が迷いにくくなりました。社外向けの技術資料や、論理の抜けを厳しく確認したい原稿ではjapanese-tech-writingも使いたいです。
どれか1つが上位互換というより、どこまで直してほしいかで選ぶスキルが変わるという結果でした。
こういうの、全部「AI臭さを消すスキル」でまとめていました。実際に同じ文を投げると、思ったより別物です。
次は、自分が過去に書いたQiitaの文章を3つへ通して、どこまで「自分らしさ」が残るかも試してみたいです。
参考
- yomiyasu（GitHub）
- natural-japanese（GitHub）
- japanese-tech-writing（Gist）
- yomiyasu公開時の投稿（X）
- yomiyasuを紹介していた投稿（X）
- Agent Skills overview（Anthropic）
関連記事
- Claude Code新出力スタイル「Concise」で、Claudeが結果ファーストの有能な相棒になった … Claudeの文章を短くし、結果から話してもらう設定を試した話
- 丁寧すぎるClaude Codeを原始人にしたら、トークン使用量が3割減った … 文体を思い切って変えると、出力量までどう変わるかを比べた話
- 「お前がみろ」はAIに効くのか。高圧的なプロンプトで回答精度を検証した … プロンプトの言い方でAIの回答精度が変わるのか、実際に回数を重ねて検証した話
告知
最後にお知らせとなりますが、イーディーエーでは一緒に働くエンジニアを
募集しております。詳しくは採用情報ページをご確認ください。
みなさまからのご応募をお待ちしております。