リード
事例記事を1本書こうとしたとき、最初にやったのは「書くこと」ではなかった。
「書ける状態を作ること」だった。型を作るほうが記事より難しかった。でも型ができたら、書くことよりも書き続けることが、格段に楽になった。
ネタがあるのに出ない
書けない、というわけではない。
AI顧問として実装に関わってきた案件が、そのままコンテンツになる。「こういう判断をした」「こう失敗した」「こう設計し直した」という話は、読んでもらえる自信がある。ネタには困っていない。
詰まるのは、いつも書き始める手前だ。
社名はどこまで出せる？数値を書いたら特定されないか？社内の仕組みを公開して問題ないか？CTAはどこに置く？文体は？導線は？
ネタを持っているのに、判断の数だけ消耗する。先延ばしになる。そのうち鮮度が落ちる。
これは「書き方」の問題ではなかった。書き始めるまでの「起動コスト」の問題だった。
最初の試み：ルールをメモにした
判断のほとんどは、一度決めれば次から迷わないことだと気づいた。
社名ぼかしの方針、リスクの確認項目、文体のルール、CTAの配置——それをマークダウンにまとめた。「これで起動コストが下がる」と思った。
1週間後、次の記事を書こうとしたとき、そのメモを開かなかった。
書こうとすると、まず書くことを考えてしまう。メモを参照するのは、すでに詰まってから。ルールが手元にあっても、使うタイミングに使えない。
ドキュメントを作ることと、その通りに動くことは別の話だ。
転換点：「呼び出せる型」
Claude Code には SKILL という仕組みがある。
~/.claude/commands/ にマークダウンファイルを置くと、チャット欄で /ファイル名 と打つだけで、その内容ごとClaude が起動する。書こうと思ったタイミングで /jirei-kiji と打てば、記事執筆の全工程が立ち上がる。
メモとの違いは「能動的に読む」か「呼び出すと動く」かだ。
起動コストが、メモを探す手間から、コマンドを打つ0.5秒に変わった。始められる確率が、構造レベルで上がる。
仕組みを作る前の段階で詰まっている方。設計の相談はこちら → ai.tosakafunk.com
7フェーズの設計
SKILL の中身は7フェーズで構成している。
フェーズ1：ぼかし方針の確認
社名・業種・数値・人員変化の4軸を、書き始める前に確定する。
「社名は出さないが業種は書く」で進めた記事を「やっぱり業種も出さない」に変えると、ほぼ書き直しになる。方針は最初に決める。それだけで後の修正コストが大幅に変わる。
フェーズ2：リスク監査
6項目のチェックリストを、骨子の段階で通す。
- 関係者のプライバシーに配慮されているか
- 公開して困る機密情報が含まれていないか
- 誰かへの不利益につながる表現がないか
- 競合他社名・個人名・訴訟リスクのある表現がないか
- 記事全体がポジティブな文脈で完結しているか
骨子の段階でやるのが正解だ。本文を全部書いてからだと修正コストが高い。何も書いていない前では判断できない。骨子レベルが一番ダメージが小さい。
フェーズ3：骨子構築
テンプレートに沿ってセクションを埋める。
【0】リード（100字）
【1】課題
【2】最初の実装・試み
【3】限界・転換点 ＋ CTA①
【4】再設計
【5】結果
【6】業種・用途への転用
【7】クロージング ＋ CTA②骨子を先に固める理由は単純で、書き始めてから構造を変えるのが一番消耗するからだ。骨子が決まれば、本文は「埋める作業」になる。
フェーズ4：本文執筆
文体ルールと CTA 配置ルールがここに入る。
文体ルール（抜粋）：
- 1文は40字以内。長くなるなら「。」で切る
- 「〜と思います」「〜かもしれません」は使わない。断言する
- 「AIを活用して」ではなく「AIに◯◯をさせて」と具体化する
- 段落は3〜4行まで。白地を惜しまない
CTA 配置ルール：
- CTA①（共感型）：転換点の直後。「この段階で詰まっている方へ」の形で置く
- CTA②（本命誘導型）：記事末尾。LP への橋渡し
文体ルールを「書いた後に直す」のではなく「書きながら守る」ために SKILL に入れてある。呼び出している間は、ルールがコンテキストに常駐している。
フェーズ5：バズチェック
自社のバズ設計プレイブックにある5問を通す。
1. 誰の、どの痛みに刺さるか（1行で書けるか）
2. タイトルと中身は一致しているか
3. 主役は「議論・共感・驚き」のどれか
4. 引用したくなる一句があるか
5. 炎上・誤解・権利のリスクはないか
この5問に答えられてから初稿として出す。答えられない状態で出しても戻ってくる。先に自分でフィルターをかける。
フェーズ6：公開前チェック
最終確認。リスク監査通過済みか、CTA①②が両方入っているか、リンク先は正しいか、業種転用リストは入っているか。チェックボックスを埋めてから出す。
フェーズ7：アイキャッチ生成
最初、このフェーズは存在しなかった。
記事を書き終えてから「アイキャッチはどうする」という問題が発生した。それをきっかけに、Gemini Imagenで記事のコンセプトから画像を生成し、microCMSのメディアAPIに自動アップロードして eyecatch フィールドに PATCH する——というフローをSKILLの最終フェーズとして設計した。
記事を書き終えたら、コマンド一つでアイキャッチまで出る。
型は「完成させてから使う」ものではない。「使いながら育てる」ものだ。
実際に動かした結果
このSKILLで書いた最初の記事が、「AIに判断を任せる前にやるべきこと：失敗から辿り着いた二層設計」だ。
本業の社内AI実装プロジェクトの記録を、社名をぼかした上で公開した。フェーズ1でぼかし方針を確定し、フェーズ2でリスク監査を通し、フェーズ3〜4で骨子と本文を作り、フェーズ5でチェックした。
SKILL を呼び出してから初稿が出るまで、1セッションで完結した。
「起動コスト」が消えると、書き始めるまでの時間がほぼゼロになる。ネタがあるのに出ない、という状態が構造ごと変わった。
型は使うたびに賢くなる
SKILL を作ってから、2回の更新をした。
1回目は noreferrer の問題だ。microCMS の「外部リンク」設定がデフォルトで noreferrer を付加するという挙動を、記事を公開してから発見した。最初はフロント側のコードのせいだと疑って修正パッチまで書いたが、実際の原因は CMS 管理画面の設定だった。「次回は同じ調査をしない」という意図でSKILLに追記した。
2回目はアイキャッチ生成フロー（フェーズ7）の追加だ。
ドキュメントは書いたら放置されがちだ。SKILL は違う。次に記事を書くとき、必ず呼び出す。使うたびに「ここを更新すれば次が楽になる」という気づきが生まれる。更新のサイクルが自然に回る。
これが、メモとSKILLの本当の違いだと思っている。
同じパターンを使える業務
「型を SKILL にする」というアプローチは、記事執筆以外にも使える。
業務 | SKILL に入れる内容 |
|---|---|
提案書・企画書 | 構成テンプレート・禁止表現・提出前チェック |
見積もり | 積算ルール・リスク項目・文言パターン |
SNS 投稿 | フック・文字数・NG表現・ハッシュタグルール |
顧客フォローメール | 件名パターン・本文構成・送信タイミング |
月次報告書 | 数値の見せ方・説明の順序・改善提案の型 |
条件は「繰り返す」「毎回似た判断をする」「判断基準を言語化できる」の3点だ。
Claude Code を使わなくても、同じ発想は使える。システムプロンプトに入れる、ショートカットに登録する——手段は問わない。「呼び出せる型」がある状態と、ない状態では、起動コストが変わる。
型を持つということ
「型を持つ」というのは、業務を画一化することではない。
毎回やり直さなくていい判断を固定し、本当に考えるべきことだけに集中する設計だ。
記事執筆でいえば「何を書くか」は毎回考える。「どう書くか」「リスクはないか」「CTAをどこに置くか」は、もう考えなくていい。それがSKILLに入っている。
少しの仕組みが、継続性を変える。
