何をやったか：記事制作〜計測の運用管理
「記事は出しているのに、次に何を直せばいいのかが見えにくい」――あなたの会社でも、オウンドメディア運用が“記事を作る作業”に寄ってしまうことはないでしょうか。今回の実践ログでは、Claude Codeのブログ運用として、記事制作から公開後の計測までを一つの仕組みとして管理した方法を整理します。
やったことは、Claude Codeで記事を書くことそのものではありません。メディア運用に必要な「調査、構成、原稿、検品、公開承認、効果測定、改善メモ」を、同じ場所で扱えるようにしたことです。
具体的には、テーマごとにブリーフ、下書き、チェックリスト、公開メモ、計測メモをファイルで残しました。Claude Codeは、そのファイル群を読みながら、次に必要な作業を提案したり、抜け漏れを確認したりする“運用管理の相棒”として使いました。
編集長が毎回ゼロから状況を思い出すのではなく、運用台帳を見ながら次の一手を決めるイメージです。ブログ/メディア運用にClaude Codeを使う価値は、単発の記事生成よりも、継続運用の文脈を持たせやすい点にあります。
今回の範囲は、次の5つです。
- 記事テーマと検索意図の整理
- 構成案と本文ドラフトの作成
- トーン、事実関係、CTA、内部リンクの検品
- 人間による公開承認
- 公開後の検索・行動データを見た改善メモ作成
あなたが社長や広報担当であれば、「書く人」「見る人」「承認する人」が分かれているだけで、同じ悩みが起きやすいはずです。Claude Codeは、そこで散らばりやすい判断材料を一つの流れに戻す役割を持たせました。
この体制は、まさにいまご覧いただいているサイトで動いているものです。書く作業の大部分と検品の一次チェックはAIが担い、「公開してよいか」の判断は必ず人間の私が行う。私はエンジニアではないので、技術的な部分はAIに教わりながら仕組みを組みました。
それでも、「AIが作業し、人間が判断する」という一つの流れは崩れずに回っています。体制づくりで大事なのは人数ではなく、この役割の線引きでした。
なぜ：オウンドメディアは“制作”より“運用設計”で詰まりやすい
自社でオウンドメディアを始めるとき、最初に目立つ課題は「記事をどう作るか」です。ただ、数本から数十本に増えてくると、本当に詰まりやすいのは、記事制作そのものよりも運用設計です。
たとえば、誰に向けた記事なのか、前回の記事と何が違うのか、どの記事に誘導したいのか、公開後に何を見るのか。これらが担当者の頭の中に残ったままだと、記事数が増えるほど改善の会話がしにくくなります。
ここでは3Cが役に立ちます。Customer、Competitor、Companyの3つを記事ごとに軽く確認するだけでも、発信が「なんとなく良さそうな話」から「自社の商談につながる論点」に近づきます。
- Customer：読者はどんな課題を抱えているか
- Competitor：競合記事は何を説明し、何を説明していないか
- Company：自社なら、どんな経験や視点を出せるか
「AIで記事を増やせば、メディアが育つのでは」と感じる場面もあるかもしれません。けれど、自社の強みや顧客理解が運用に組み込まれていないと、記事は増えても意思決定に使える資産になりにくいのです。
そのため、今回の目的は“AIで大量に書くこと”ではなく、“AIを使って運用の再現性を上げること”に置きました。オウンドメディア ai活用を考えるなら、まずは記事本数より、判断の流れを残すことが先になります。
Claude Code自体の基本的な考え方を先に押さえたい場合は、非エンジニア向けのClaude Code活用入門が参考になります。技術担当でなくても、役割を理解しておくと社内での会話が進めやすくなります。
ツール構成：Claude Code＋API群の役割分担を平易に整理する
社内で導入を考えるとき、ツール構成は複雑に見えるかもしれません。ただ、全体像はシンプルで、Claude Codeを“作業場所”、各種APIを“外部データや外部サービスにつなぐ窓口”として分けると理解しやすくなります。
Claude Codeは、原稿やチェックリストなどのファイルを読み書きしながら、作業の流れを支えます。「このブリーフに沿って構成を見直して」「公開前チェックをして」と依頼すると、関連ファイルを参照しながら作業できます。
API群は、Claude Code単体では持っていない情報や操作を補います。たとえば、検索データ、アクセス解析、CMS（たとえばWordPress）、スプレッドシート、プロジェクト管理ツールなどと連携させることで、自社の運用実態に近い形で使いやすくなります。
役割を平易に分けると、次のようになります。
- Claude Code：運用台帳、原稿、チェックリストを扱う作業ハブ
- 生成AI API：構成案、本文案、リライト案の作成補助
- 検索・調査系API：競合記事、検索意図、関連語の確認補助
- CMS API：公開前データや記事ステータスの受け渡し
- 解析系API：表示回数、クリック、流入、CV前行動などの確認補助
- 表計算・管理ツールAPI：進行状況や担当者メモの同期
最初から全てをつなぐ必要はありません。むしろ、最初はClaude Codeと手元のMarkdownファイル、またはスプレッドシートだけでも十分に運用の型を作れます。
大切なのは、「どのツールが賢いか」よりも、「どの判断をどこに残すか」です。Claude Codeでブログ/メディア運用を管理する場合も、記事ごとの判断履歴を残せる構成にしておくと、後から改善しやすくなります。
運用フロー：調査→生成→検品→公開承認→効果測定
自社で実装するときは、いきなり自動化の範囲を広げるより、運用フローを5段階に分けるのがおすすめです。今回の実践では、調査、生成、検品、公開承認、効果測定の順に進めました。
1. 調査：記事の目的を先に固定する
最初に、記事テーマごとに「誰の、どんな意思決定を助ける記事か」を書き出します。自社の商談や問い合わせにつながるテーマであっても、読者の悩みから始めないと、売り込み感の強い記事になりやすいからです。
ここでClaude Codeには、想定読者、検索意図、競合記事の傾向、自社で出せる経験を整理させます。最終的に見るべきなのは、AIの答えそのものではなく、「自社の立場から書く理由」が明確になっているかです。
2. 生成：構成と本文を分けて作る
次に、構成案と本文案を分けて作ります。現場でよく起きる失敗は、いきなり本文を作ってから、後で「この話は誰向けだったのか」と迷うパターンです。
構成段階では、H2ごとの役割、読者の疑問、内部リンク、CTAの位置を先に決めます。本文生成はその後に行い、Claude Codeにはブリーフと文体ルールを参照させながら、段落単位で下書きを作らせます。
3. 検品：ブランドと事実を人間が見やすい形にする
検品では、Claude Codeにチェックリストを使わせます。自社の表現ルール、避けたい言い方、事実確認が必要な箇所、内部リンクの妥当性、CTAの整合性を一覧で確認します。
AIの出力には誤りが混ざりうるため、最終的な掲載判断はあなたの会社の責任者が行う前提にします。ここを曖昧にしないことで、スピードと安全性のバランスを取りやすくなります。
4. 公開承認：自動公開ではなく、承認ゲートを置く
公開前には、担当者が「公開してよい状態か」を確認するゲートを置きます。自社の名前で出る記事は、検索順位だけでなく、営業資料や採用候補者の印象にも影響するためです。
Claude Codeには、公開前サマリーを作らせました。この記事の目的、想定読者、主要メッセージ、未確認事項、CTA、内部リンクを短くまとめることで、担当者や上長が確認しやすくなります。
5. 効果測定：数字を“評価”ではなく“次の仮説”に変える
公開後は、表示回数、クリック、平均掲載順位、流入後の行動、関連記事への遷移などを確認します。あなたの会社にとって重要なのは、数字を担当者評価に使うことではなく、次の改善仮説に変えることです。
たとえば、表示はあるがクリックが少ないならタイトルやディスクリプションを見直します。流入はあるが次の記事に進まないなら、本文中の導線や読者の温度感が合っているかを確認します。
実例を1つ。このサイトでは、記事を公開したら「7日後・14日後・30日後・60日後」の確認日を、その場で予定表に登録してしまいます。人間の記憶に頼ると、忙しい週の点検は必ず飛ぶからです。
この予定表はAIと共有していて、確認日が来ると漏れなく点検が回ります。計測を「気が向いたときの作業」にしないことが、続けるいちばんのコツでした。
承認ゲート早見表：どこをAIに任せ、どこを人が判断するか
5工程を「AIが行うこと」と「人が判断すること」で分けると、次のように整理できます。ここを一枚にしておくと、運用の役割分担が社内で共有しやすくなります。
| 工程 | AIが行う | 人が判断する | 残す証跡 |
|---|---|---|---|
| 調査 | 読者・競合・検索意図の整理 | 自社の立場から書く理由 | ブリーフ |
| 生成 | 構成案・本文ドラフトの作成 | 誰向けか、論点のずれ | 下書き・構成メモ |
| 検品 | チェックリストの一次確認 | 事実・表現・掲載の可否 | チェックリスト |
| 公開承認 | 公開前サマリーの作成 | 公開してよいかの最終判断 | 承認メモ |
| 効果測定 | 数字の集計・変化の抽出 | 次の改善仮説の採否 | 計測メモ |
うまくいった点：運用の見える化で会話がしやすくなった
今回うまくいった点は、記事制作のスピードだけではありません。自社でも再現しやすい学びとしては、「今どの記事が、何の目的で、どこまで進んでいるか」が見えやすくなったことです。
特に効果があったのは、記事ごとの判断履歴を残したことです。後から見返したときに、「なぜこのキーワードを選んだのか」「なぜこのCTAにしたのか」「公開後に何を見たのか」が追えるようになります。
もう一つは、レビューの観点がそろったことです。担当者によって見る場所が違うと、メディアは記事ごとに品質のばらつきが出やすくなりますが、チェックリストを共通化すると会話が具体的になります。
たとえば、レビュー時の指摘が「なんとなく弱い」ではなく、「読者の課題から自社の解決策へ移る段落が急」「競合比較の視点が不足している」といった形になります。自社のノウハウも、こうした指摘を蓄積することで育っていきます。
AIでブログ運用を自走化する全体像は、AIでブログ運用を自走化する方法でも整理しています。今回のClaude Code活用は、その中でも“運用管理の中核”に近い位置づけです。
また、社長が関与する時間を圧縮しやすくなった点もあります。毎回本文全体を読み込むのではなく、公開前サマリーと未確認事項を見て判断できる状態にすると、承認の負担が下がります。
もちろん、すべての会社で同じ形が合うわけではありません。自社の商材、リスク許容度、社内体制に合わせて、レビュー項目や承認者を調整することが前提です。
失敗と学び：人間の承認ゲートを外すと、運用は不安定になる
「ここまで整えたなら、自動で公開まで進めてもよいのでは」と感じる場面が出てきます。あなたの会社でも、運用に慣れてくるほど、承認工程を短くしたくなるかもしれません。
ただ、今回の学びとして、公開承認のゲートは外さないほうがよいと感じました。理由は、オウンドメディアの記事が単なるコンテンツではなく、あなたの会社の信用や営業文脈とつながっているからです。
実際に起きやすい失敗は、細かなところにあります。たとえば、過去の記事の前提を引きずった表現、古い社内方針に基づく説明、CTAと本文の温度差、社長の考え方と少しずれた言い回しなどです。
Claude Codeは文脈を扱いやすい一方で、与えたファイルや指示の設計が曖昧だと、曖昧なまま整った文章を作れてしまいます。この“整って見えるが判断が必要な文章”を見抜くために、人間の承認ゲートが必要です。
もう一つの失敗は、計測結果の解釈を急ぎすぎたことです。数日分のデータだけで結論を出そうとすると、本来見るべき季節性や検討期間を見落としやすくなります。
そこで、計測メモには「事実」「仮説」「次に試すこと」を分けて書くようにしました。会議で見るときも、数字そのものより、次の打ち手が妥当かどうかを確認しやすくなります。
安全運用の思想も、体制に組み込んでいます。たとえば、費用が発生する処理をAIが実行する前には「必ず私に許可を取る」ことをルール化し、本番サイトに触れる操作は必ず人間の承認を通す。AIに渡す権限を最初に絞っておくのです。
権限だけでなく、「何をAIに入力してよいか」も先に決めています。顧客情報、未公開の原稿、契約情報、氏名やメールアドレスのような個人情報は、そのままAIに渡しません。
どうしても必要なときは、固有名詞や数値を伏せて匿名化してから渡します。
APIキーやパスワードなどの認証情報はAIに貼らないことも徹底しています。権限を絞ることと、入力してよい情報を決めておくことは、情報漏えいを防ぐための両輪です。
こうしておくと、「整って見えるが判断が必要な文章」も、想定外の支出も、世に出る前に必ず人間の目を通ります。攻めの自動化は、守りの設計とセットで初めて安心して回せます。
最小構成での始め方：まずは“台帳化”からでよい
あなたの会社がこれから始めるなら、最初からAPI連携を組み込む必要はありません。最小構成では、Claude Code、記事ごとのMarkdownファイル、簡単な進行管理表があれば始められます。
最初に作るとよいのは、記事運用のフォルダです。記事ごとに同じ構成で情報が残るようにしておくと、後から人が増えても引き継ぎやすくなります。
例として、次のように分けます。
- briefs：記事ブリーフ
- drafts：本文ドラフト
- checks：公開前チェック
- published：公開済みメモ
- reports：効果測定メモ
次に、記事ブリーフのテンプレートを作ります。最低限「想定読者」「検索意図」「自社視点」「読後に取ってほしい行動」「内部リンク候補」「CTA候補」を入れるだけでも、記事の方向性がぶれにくくなります。
そのうえで、Claude Codeに「このテンプレートを埋める」「不足している観点を指摘する」「本文の構成案を作る」と依頼します。人が確認するのは、AIがきれいに書けているかではなく、事業上の目的と読者の課題がつながっているかです。
公開前チェックも、最初は10項目程度で十分です。自社の業種に合わせて、法務確認、価格表現、導入事例の扱い、競合比較の表現、成果表現の注意点などを追加していきます。
効果測定は、最初から細かく見すぎないほうが続きます。月1回でもよいので、表示、クリック、流入、次に見られた記事、問い合わせ前に読まれた記事を確認し、改善メモに残すところから始めると現実的です。
全社的なAI活用の位置づけまで整理したい場合は、中小企業社長のためのAI戦略活用完全ガイドに戻って、オウンドメディア以外の業務とのつながりも確認してみてください。自社でAIを点ではなく線で使うための整理に役立ちます。
よくある質問
非エンジニアでも運用できますか？
できます。私自身もエンジニアではなく、技術的な部分はAIに教わりながら仕組みを組みました。大切なのはコードを書くことではなく、「AIが作業し、人が判断する」という役割の線引きを決めることです。
安全面は大丈夫ですか？
本番サイトに触れる操作や費用が発生する処理は、必ず人間の承認を通す前提にしています。あわせて、顧客情報や個人情報、認証情報はAIに渡さないというルールを先に決めておくことで、リスクを抑えられます。
どこから始めればよいですか？
最初はClaude Codeと記事ごとのMarkdownファイル、簡単な進行管理表だけで十分です。API連携や自動化は後からで問題ありません。まずは判断の流れを台帳として残すところから始めるのがおすすめです。
関連記事と「AI戦略」に関するご案内
Claude Codeでオウンドメディア運用を管理する要点は、記事生成を任せることではなく、あなたの会社の判断を残しながら改善を回すことです。調査、生成、検品、公開承認、効果測定を一つの流れにすると、メディア運用は属人的な作業から、社内で共有できる仕組みに近づきます。
最初の一歩は、API連携や高度な自動化でなくてもかまいません。自社の記事ブリーフ、公開前チェック、効果測定メモをClaude Codeで扱える形にするだけでも、次に何を直すべきかが見えやすくなります。
Claude Codeの基本理解を深めるならClaude Codeのビジネス活用の基礎、メディア運用全体の設計を見直すならAIを使ったブログ運用の自走化プロセスもあわせて読むと、導入順序を考えやすくなります。
