こんにちは、CARTA ZERO CTOの河村（@r_kawaiimura）です。
書きたいテーマはある。伝えたいこともある。でも、白紙の画面を前にすると手が止まる。 そんな経験はありませんか。
わたし自身がずっとそうでした。テックブログに限らず、社内ドキュメントや社内ブログも、技術広報の ShuzoN（@shuzon__）に伴走してもらいながら書くことが多かったです。壁打ちしながら構成を固め、推敲を重ねて仕上げていました。それだけ頼りになる存在でした。でも一人で書くとなれば、途端に腰が重くなります。
これは書く能力の問題ではありません。頭の中にあるものを文章として外に出すまでの摩擦が大きいのです。
そこで、個人的な自由研究として Claude Code Skills を使った執筆の仕組みを作りました。結果、文章を書くハードルが明らかに下がりました。社内向けにこの仕組みについて書いたところ反響があったので、対外向けに再構成してお届けします。
「文章を書き始められない」「AIを使って執筆プロセスを改善したい」と考えている方に届けばうれしいです。エンジニアに限った話ではありませんが、Claude Code というツールの性質上、Git やターミナル操作に慣れている方のほうが読みやすいかもしれません。
なぜ仕組みが必要だったのか
「伴走者がいれば工程ごとのハードルが下がる。その伴走者を仕組みとして持てないか？」 これが出発点でした。
文章を書くという行為を分解すると、いくつかの工程があります。
- テーマを決める
- 構成を考える
- 本文を書く
- 推敲する
- 公開する
一人で全工程を担うと重いです。特に「構成を考える」と「推敲する」がボトルネックになりやすいです。
構成を考える段階では、頭の中にぼんやりとあるものを論理的な流れに組み立てる必要があります。伝えたいことはあるし、考えもある。でもそれを「どの順番で」「どのトーンで」「どこまで書くか」決めるのが難しい。 壁打ち相手がいれば違うのはわかっています。ただ、誰かに「ちょっとこの記事の構成一緒に考えて」と頼むのも気が引けます。
推敲の段階では、自分が書いた文章を客観的に見る必要があります。これも一人では限界があります。時間を置いて読み返す手はありますが、それだけ完成が遅れます。
作ったもの
GitHub リポジトリに記事の原稿を管理し、Claude Code Skills で執筆プロセスを支援する仕組みを作りました。
Claude Code は Anthropic が提供するターミナルベースの AI コーディングツールです。Skills はその拡張機能で、Markdown ファイルにロールや振る舞いを定義すると、スラッシュコマンドで呼び出せる専門エージェントになります。今回はこの仕組みを「コードを書く」ではなく「文章を書く」に転用しました。
構成はシンプルです。
articles/ # 記事の原稿
.textlintrc.json # 文章の自動チェック
prh-rules.yml # 表記ゆれルール
.claude/
skills/ # Claude Code スキル
co-writer/ # 執筆の伴走者
review-article/ # 記事レビュー
eyecatch-prompt-designer/ # アイキャッチ画像
references/
rules/ # 文体ルール
past-articles/ # 過去記事（トーンの参照用）
3つのスキルがそれぞれ異なる役割を持っています。
/co-writer — テーマの種からアウトラインと下書きまでを一緒に練る伴走者です。代筆者（ghostwriter）ではなく、共筆者（co-writer）。筆者の声を代弁するのではなく引き出します。
/review-article — 書き上がった記事のレビューです。構造 → トーン → 表現品質の順にチェックします。修正案は複数提示して筆者が選ぶ設計にしています。
/eyecatch-prompt-designer — アイキャッチ画像のプロンプト設計です。記事を読み込んでビジュアルコンセプトを提案し、画像生成AIに渡すプロンプトを作ります。
ワークフローの全体像はこの図のとおりです。
最も工夫したのは「擦り合わせ」の設計
最も時間をかけたのは /co-writer の設計です。
核にあるのは「擦り合わせ」という概念です。コアコンセプトとアウトラインが噛み合うまで、使う言葉と伝えたい内容が一致するまで、繰り返します。一度で正解にたどり着く必要はなく、往復の中で輪郭が見えてきます。
具体的には、こういう設計にしています。
- アウトラインの合意なしに執筆に入らない: 各セクションの方向性が擦り合っていることを確認してから本文に進みます
- 筆者の声を引き出す: 「こう書くべき」ではなく「こういう構造が見える」「こういう言葉はどうか」と提案します
- チャネルごとのトーン制御: テックブログ、個人note、社内noteで立場・一人称・トーンが変わります。その違いを文体ルールとして言語化し、スキルが参照します
品質のガードレール
もう一つ重要なのは、文体ルールが「ガードレール」として機能していることです。AIに執筆を伴走してもらう上で、品質の下限を保証する仕組みは欠かせません。文体ルールとは、筆者の書き方の癖や方針をMarkdownで言語化したもので、トーン、一人称、文末表現、助詞の使い方などです。これらをルールとして明文化しておくことで、AIの出力が最初から筆者の思想に近づきます。ガードレールがあるからこそ、安心してAIに委ねられる領域が広がります。
さらに、過去記事を参照データとして持たせています。わたしの過去の文章を読み込むことで、トーンや言葉の選び方の手癖を掴んでもらいます。文体ルールという明文化されたガードレールと、過去記事という実例の参照。この両輪が co-writer の出力品質を支えています。
実際のやり取り
この記事の元になった社内版記事は /co-writer で書きました。そして、このテックブログ版自体も /co-writer で再構成しています。
社内版を書いたときの実際のやり取りをいくつか抜粋します。
まず、テーマを伝えるところから始まります。今回は GitHub issue に書いた箇条書きをそのまま渡しました。
- なぜやろうと思ったか
- 文章を書くハードルが明らかに下がった
- 工夫したポイント
- 各種skillsの説明、特にco-writerかな
- 今後の展望
- slideもやりたいよね
これだけの入力で、co-writer はチャネルの確認と想定読者の確認を経て、7セクションのアウトラインを出してきます。
出てきたアウトラインに対して、わたしはこうフィードバックしました。
2. 考えを持っているけどなかなか始められない、みたいなのも入れたそうです 7. 結びはちょっとかたいですね。 それ以外は大丈夫そうです
すると co-writer が修正案を返してくる。そこでさらにわたしが「結びが硬いのは『結び』という言葉の方です」と返す。co-writer は「なるほど、セクションタイトルを『最後に』に変更」と即座に修正します。
この「セクション単位でフィードバックして、修正して、また返す」というサイクルが、一人で構成を練るよりも圧倒的に速いです。
頭の中にぼんやりあるものを「違う、そうじゃない」「そう、それに近い」と反応するだけで輪郭が見えてきます。ゼロから考えるのと、叩き台に反応するのでは、認知的な負荷がまるで違います。後者のほうがはるかに楽です。
そしてもう一つ重要なのは、AIに書かせているわけではないということです。構成もフィードバックも判断もわたしがしています。co-writer はあくまで伴走者で、わたしの代わりに考えてくれるわけではありません。擦り合わせを重ねる中で「自分の言葉」が見つかる感覚があります。
Agentic-Writing という考え方
AIが文章を「代わりに書く」のではなく、執筆プロセスの各工程でAIが伴走者として機能します。この仕組みを社内に公開したとき、CARTA HOLDINGS CTO の suzuken（@suzu_v）は「Agentic-Writing」と呼んでいました。
Agentic AI、すなわちAIが自律的にタスクを遂行するという概念はすでに広く知られています。Agentic-Writing はその考え方を執筆に適用したものですが、AIに丸投げする自動生成とは異なります。各工程で人間が判断し、AIが伴走する。その関係性がポイントです。
- 構成を考える: 叩き台を出し、フィードバックを受けて修正する
- 本文を書く: 文体ルールというガードレールの中で下書きを生成する
- 推敲する: 構造 → トーン → 表現品質の順にレビューする
人間はディレクションに集中します。「何を伝えたいか」「どういうトーンで書くか」「この表現は自分の声か」。こうした判断は筆者にしかできません。AIはその判断を引き出し、形にする伴走者です。
そして興味深いのは、書いた文章がAIにとっての「外部参照先」になることです。過去記事を参照データとして蓄積すればするほど、co-writer の出力が筆者の声に近づきます。書くことで仕組みが育ち、仕組みが育つことで書くハードルがさらに下がる。この好循環こそが Agentic-Writing の本質だと考えています。
今後の展望
スライド資料にも同じアプローチを適用したいと考えています。記事からプレゼンの構成を練り上げ、ストーリーラインを組み立てるという工程は、記事執筆と本質的に似ています。
また、この仕組み自体をもっと育てたいです。スキルの定義も、文体ルールも、使いながらアップデートし続けています。実際にこの記事を書く過程でも、co-writer の振る舞いについて「こうしたほうがいいな」と気づくことがありました。使いながら改善を重ねていく、そういうループを回していきたいです。
最後に
文章を書くことは、思考を外に出すことです。頭の中にある曖昧な考えを、他者に伝わる形に構造化する行為です。そしてその文章は、AIにとっての外部参照先にもなります。書けば書くほど、AIがあなたの声を理解し、あなたの思考を引き出す精度が上がっていきます。
書くのが得意じゃなくても大丈夫です。仕組みを持つことが、文章を書くハードルを下げてくれます。
