Qiitaのトレンド記事でおもしろいのがあったので日曜深夜なのに言及したところ結構反応がありました。
この記事は日本語のAI臭さを消すスキルの比較記事なんですが、個人的にいま日本語を最終アウトプットにするサービスを作っていて、このあたりの部分は苦労したので「やはりモデル性能がすべて」と思うようになりました。
やっぱりどんだけSkillで武装しても、新しいフロンティアモデルのほうがいいコード出力を出すように、日本語性能もモデルの素行が一番効いてくると思っています。
よく知人やコンサル先にもいってますがタスクの精度をあげたいときに、「モデル性能が10の位、プロンプトやスキルで1の位」みたいな話をしています。これは正確ではありませんが、例えとしてはいいんじゃないかなと思っています。
誤解してほしくないのは、元記事は日本語のスキルを比較した記事であり、それ自体は大変示唆のある結果になっているということです。
ですが、私が実務でぶつかっている壁としては「Qiitaらしい文章」「noteらしい文章」「Linkedinらしい文章」「GitHubのREADMEにふさわしい文章」など、TPOに合わせた正しさをAIに出し分けてほしいと考えているということです。
個人が書いた技術ブログなんて、なんだったらです・ますが統一しきれてないほうが正しい場面もあると思うんよね。←
実際に各モデルのアウトプットをみてみる
では実際にどういうことなのか、具体例をあげていきましょう。元記事の文章をそのまま使います。余談ですがめちゃくちゃ「臭う」いい例文ですよね。評価は各パーツがどうとかではなく、みなさんの嗅覚で「臭う」か判断してみてください。
使用するプロンプト：
以下のQiita記事がAI臭いのでリライトして
----
## 同じ指示を何度も書く毎日は、もう終わりにしませんか?
記事を書くたびに「です・ます調で」「初心者向けに」「見出しはこの形式で」とAIに頼み直していませんか。この手間こそ、文章作成で最も地味に時間を奪う正体です。
そこで使いたいのが、Claude Codeの**Agent Skills**です。Skillsは、あなた専用の「**文章作成マニュアル**」をAIに持たせる仕組みです。新人に毎回口頭で説明する代わりに、分厚い業務マニュアルを一度だけ渡しておくイメージです。
### メリット1:書き方が毎回ブレない
文体、構成、用語のルールをSkillに書いておけば、誰がいつ頼んでも**同じ品質**で仕上がります。チームの記事に統一感が生まれ、「担当者によってトーンが違う」という悩みも消えます。
### メリット2:指示が劇的に短くなる
「Qiita記事にして」の一言で、長い前提条件がすべて伝わります。毎回のプロンプトが**呪文のような長文**から、**ひと言の合図**に変わります。
### メリット3:使い回して育てられる
Skillはただのファイルなので、改良も共有も簡単です。うまくいった書き方を足していくほど、AIは**あなたの分身**のように成長します。
### さあ、最初の一歩を
プログラミングの知識がなくても、Skillsは「ルールを文章で書くだけ」で作れます。**文章作成を、繰り返す作業から育てる資産へ。**今日から、あなた専用の執筆パートナーを育て始めましょう。
Gemini 3.8 Flash medium
毎回同じプロンプトを書くのをやめたい。Claude CodeのAgent Skillsで執筆ルールを固定する
Claudeで記事を書くとき、毎回似たような前提条件を書いていませんか？
- 「です・ます調で」
- 「エンジニア初心者向けに」
- 「見出し構成はMarkdownで」
毎回コピペするのも地味に面倒ですし、指定を忘れて出力のトーンがブレてしまうこともよくあります。
このあたりの共通ルールをあらかじめ固定しておきたい場合は、Claude Codeの Agent Skills を使うと便利です。
Agent Skillsを使うメリット
トーンや構成がブレない
文体やフォーマットのルールをSkill側に持たせておけるため、いつでも一定のトーンで出力されます。チームで記事を書くときのレギュレーション共有にも使えます。毎回のプロンプトが短くて済む
前提条件を毎回入力する必要がなくなるので、「このメモをQiita記事にして」と投げるだけで期待通りのフォーマットに落とし込んでくれます。Markdownファイルで手軽に管理・改善できる
Skillの実体はテキストファイルなので、Git管理やチーム共有が簡単です。「この表現は避ける」「この構成が良かった」といった気付きを追記していくだけで、少しずつルールをブラッシュアップできます。特別なコードを書く必要はなく、ルールをテキストで記述するだけで導入できます。毎回プロンプトの調整に時間を取られている方は、ぜひ試してみてください。
Opus 5.5 high
毎回同じ指示を書くのが面倒になってきた
Claude Codeに記事の下書きを頼むとき、毎回「です・ます調で」「初心者向けに」「見出しは
##から」と前置きを書いていました。1回ならたいした手間ではありません。ただ、何本も書いていると面倒ですし、書き忘れると記事ごとに文体がバラバラになります。これをまとめて解決できたのがAgent Skillsです。書き方のルールをファイルに書いておき、Claudeが必要なときに読む仕組みです。
Skillの中身
.claude/skills/qiita-writer/SKILL.md のようなファイルを置くだけで使えます。
(筆者による中略・ここにSkillの例が張られる)
Claudeは
descriptionを見て、このSkillを使うかどうかを判断します。なので、どんなときに使うSkillなのかをここに具体的に書いておくのがポイントです。使ってみて良かったこと
文体のブレが減った
ルールをSkillに書いておけば、頼み方が多少雑でも同じルールに沿って書いてくれます。チームで同じSkillを使えば、人によってトーンが違うという問題もある程度は抑えられそうです。
プロンプトが短くなった
前置きを毎回書かなくてよくなりました。「この内容でQiita記事にして」くらいで済みます。
あとから直せる
Skillはただのテキストファイルです。気になる点が出てきたら、その都度ルールを書き足せます。Gitで管理すればチームへの共有も簡単です。使うほど自分好みの書き方に近づいていきます。
おわりに
Skillといっても、中身はMarkdownでルールを書くだけです。同じ指示を何度も書いていると感じたら、まずはその指示をそのまま
SKILL.mdに貼り付けてみてください。
Fable 5.1 high
Claude CodeのAgent Skillsで、記事執筆の前置きをなくす
AIに記事を書かせるとき、毎回「です・ます調で」「初心者向けに」「見出しはこの形式で」と前置きしていました。一回あたりは数行ですが、記事を書くたびに繰り返すと地味に面倒ですし、書き忘れると文体が前回とずれます。
この前置きをまとめて置いておけるのが、Claude CodeのAgent Skillsです。
Skillsとは
ざっくり言うと、「こういう依頼が来たらこう書いてほしい」という手順書をMarkdownで用意しておき、Claude Codeに読ませる仕組みです。.claude/skills/<スキル名>/SKILL.md にルールを書いておくと、関係する依頼のときにClaudeがそれを参照してくれます。
中身は普通の文章です。たとえばQiita記事用なら、
- 文体はです・ます調
- 想定読者は該当技術を触り始めた人
- 冒頭に「この記事でわかること」を箇条書きで入れる
- コードブロックには言語指定をつける
といった内容を書いておくだけで動きます。プロンプトのテンプレートをファイルに切り出した、くらいの感覚で始められます。
使ってみて良かった点
出来上がりが安定する。 文体や構成のルールがファイルにあるので、日をまたいでも、別の人が頼んでも、同じ形で出てきます。チームで記事を書いていると、担当者ごとにトーンが変わる問題が起きがちですが、Skillを共有すればそこが揃います。
依頼文が短くなる。 「この内容でQiita記事にして」で済むようになりました。以前は毎回コピペしていた前提条件が不要になるので、本題の内容を書くことに集中できます。
手直しがそのまま次に活きる。 出力を見て「ここは毎回直しているな」と気づいたら、その修正内容をSKILL.mdに一行足すだけです。ただのテキストファイルなので、Gitで管理して差分を追うこともできますし、他のリポジトリにコピーして使い回すこともできます。
まとめ
Skillsを作るのにコードは要りません。普段AIに口頭で伝えているルールを、文章にしてファイルに置くだけです。「毎回同じことを頼んでいるな」と思う作業がひとつでもあれば、まずそれをSkillにしてみるのがおすすめです。
Opus 4.6 high
Claude CodeのAgent Skillsで、記事執筆の「毎回あの指示」を省く
Qiitaに記事を投稿するとき、AIに毎回こんな前置きを書いていた。
です・ます調で書いて。対象読者は初心者。見出しはH2から始めて、冒頭にリード文を入れて……
内容を考える前にプロンプトの整備で疲れる。正直、ここが一番だるい。
Claude CodeのAgent Skillsを使うと、この定型指示をファイルに切り出しておける。次からは「Qiita記事にして」だけで、文体も構成も指定どおりに出てくる。要はプロンプトの共通部分を外部ファイル化する仕組みだ。
出力がブレなくなる
「です・ます調」「見出しの粒度」「用語の表記ゆれ」あたりのルールをSkillファイルに書いておくと、実行するたびに同じフォーマットで出力される。チームで使う場合、書く人が変わっても記事のトーンが揃うのが地味にありがたい。
プロンプトが短くなる
自分の場合、以前は毎回200字くらいの前提指示を貼り付けていた。Skillに移してからは、本題だけ書けばいい。「このテーマで記事書いて」で済むので、試行錯誤のサイクルが早く回る。
ファイルなので普通に管理できる
Skillの実体はただのテキストファイル（Markdown）なので、Gitで管理できるし、チームメンバーに渡すのもコピーするだけ。「前回うまくいった言い回しのルール」を書き足していけば、使うほど精度が上がっていく。
まとめ
プログラミングの知識は要らない。ルールを日本語で書いてファイルに置くだけなので、技術記事を書く人なら誰でもすぐ試せる。毎回同じ指示を書く手間が気になっていたら、まずSkillファイルを1つ作ってみるといい。
いかがでしたか？()
何をもって性能が高いか、という点は評価が分かれると思いますが、個人的な「お気持ち」としては、Gemini > Opus4.6 > Fable 5.1 > Opus 5.5というかんじです。
もちろん、スキルなしの素の状態なので、まだ改善や統一の余地はそれぞれありますが、スタート位置がここまで違うとスキルによる調整幅にも限界があることがわかると思います。
大切なのは、コードで言うときのlintのようなものにとらわれず、自分の感覚で「好き・嫌い」を判断していくことです。AI臭さの対局であるわれわれ人間は、ですます調を守らなかったり、その時はやっている表現を取り入れたり、出身地の方言がほんのり混ざったりして、ふわふわしているのです。
ぜひ皆さんもお手元のAIに上のプロンプトを突っ込んでみて遊んでみましょう！
※この記事の本文は100%人間が構成・執筆しました。
おまけ：Geminiを使う方法
とはいえ、Claudeしか契約してないんだよな～みたいな人もいると思います。Geminiの2026年10月の使い方についてですが、以下の選択肢があります。
- AI Studioでつかう（無料枠あり）
- Antigravityでつかう（無料枠あり）
- https://antigravity.google/
- Google AI Proを契約すれば月額サブスクでいけます。個人だと2900円くらいです
- Cursor契約していればそっちでも行けます