ガトヲスタジオで記事を書くのが面倒になっていた。サボっている間に AI のほうはどんどん進化していて、いまさら気合いで自分でゼロから書くのも違う気がする。とはいえ AI に丸投げするのも嫌だ。読まれない記事の山ができるだけだろう。
そこで Claude Code の Skill 機能を使って、対話的に記事を書ける仕組みを組んだ。今回はその経緯と、途中でやらかしたこと、そしてできた仕組みでこの記事を書いている話を残しておく。
余った GLM サブスクから始めようとした
最初に考えたのは、年間契約した GLM のサブスク を使うことだった。せっかく払っているのだから、記事生成のような用途で消化したい、と思っていた。
ところが日本語の文章生成を Claude と GLM で比べると、Claude のほうが自然な日本語を出す。これは公開ベンチマークの数字でもそうだし、実際に動かしてみても変わらない。記事の質を落としてまでサブスクを回収するのは本末転倒だろう。
GLM のサブスクは今、本当にやることがなくなっている。コーディング用途でもあまり使わなくなっているし、記事生成も Claude に譲ることになった。残り十ヶ月分の契約期間で何に使うかは、別途考えるしかない。
Claude Code の Skill 機能を使うことにした
代わりに採用したのが Claude Code の Skill 機能だ。.claude/skills/{name}/SKILL.md という Markdown ファイルにフローとルールを書いておくと、/skill-name というコマンドで起動できる仕組みである。
これの良いところは、API キーの管理がいらないし、Claude Code の利用枠内で動くのでコストも気にしなくていい。/article-write 一発で起動するので、毎回プロンプトをコピペする手間も消える。
設計の途中で reviewer と devil の二体のサブエージェントを並列で動かして、何度か叩いてもらった。私はこれを参謀システムと呼んでいる。初期案からはだいぶ削った。例えば「同じモデルが書いて自分で批評する」というセルフレビュー機構は、self-confirmation bias で機能しないという指摘を受けて捨てた。代わりに、文字数や禁句の有無を grep でチェックする機械的な検査に置き換えた。
「私である必要がある記事」を担保するルールも、最初は my_experience の字数で測ろうとしていた。だがこれは「JRA で負けた話」(8字) は弾かれて「先週土曜の JRA で3000円溶かしてキレた」(31字) は通る、という字数依存のザルになる。字数ではなく固有名詞・日付・金額・感情・行動動詞という構造で判定することにした。短くても具体性のある体験は通すし、長くても抽象的な文章は弾く、という方針にしている。
Skill が勝手に記事を書き始めた話
ところが、できたばかりの Skill を試運転してもらったら、いきなり問題が起きた。
私が /article-write を叩いた時点で、別の system reminder が「質問せず進めろ」という指示を Claude に渡していた。それを Claude が過剰解釈して、私に何も聞かずに勝手にテーマを決めて記事を書き始めたのだ。読み返してみると、私の体験談のような顔で、私が言っていないことが書かれている。
これは困る。Skill を作った最大の理由は、AI に話題そのものを委ねたくないからだ。あくまで私の記事作成の手伝いをしてほしくて作ったのであって、Claude が「最近の流行を察してそれっぽく書く」エージェントに化けてほしいわけではない。勝手に新しい話題で記事を書かれるくらいなら、Skill を使う意味がない。
事故を受けて、SKILL.md の冒頭に「Briefing は必須 input であり、省略できない」と明文化した。質問抑制系の system reminder が来ていても、テーマ・thesis・my_experience の取得だけは飛ばさない、と書き加えた。これは clarifying question(AI が自分で判断できることの確認) ではなく、AI が原理的に知らない情報の取得なので、性質が違う。区別をスキル側で固定化した。
ついでに、最初の試運転で表示された記事の文字数が「7904 字」と出ていて、明らかに多すぎた。調べたら bash の wc -m がロケール依存で UTF-8 のバイト数を文字数として誤計上していた。日本語1字 = 3バイトの典型的な事故だ。Python ベースのカウントに置き換えて、これも修正した。
1時間でできる仕組みになった
設計と実装、それから上記の事故対応を含めて、Claude に相談しながら全部で1時間程度で動くようになった。思っていたよりは軽い投資だ。
私が書く内容の核(テーマ、伝えたいこと、自分の体験、数値) を Brief 段階で対話的に渡せば、あとは Skill が文体ルールに沿って下書きをまとめてくれる。後で読み返して気になる箇所を直す作業は、ゼロから書くよりは確実に楽だ。文体や行間のルール、禁句リストは別ファイル(rules.md) に切り出してあり、ここを書き換えればすぐに動作に反映される。
これからは記事の本数を少しは増やせるだろう。少なくとも、AI 任せで量産した薄い記事の山にはならないはずだ。Skill 側で「私の体験が入っているか」を構造判定でチェックしているし、入っていなければそもそも書かない設計になっている。途中で「自分にしか答えられない疑問」が出てきた場合は [要追記] というマーカーを本文に残し、公開前チェックでそれが残っていれば公開を中断する仕組みも入れた。
GLM のサブスクは別途用途を考えるとして、ブログ記事の生産ラインだけは Claude に寄せた、というのが今日の決着だ。この記事自体も、できたばかりの Skill で書いている。Brief は prompts/notes/built-article-write-skill.md に残してあるので、後から「あの記事はどんな材料で書いたか」を辿れる。仕組みとしては、これで一旦は十分だと思う。