オウンドメディアを 1 人 × AI で運用する — 編集部を再現する制作パイプライン

本記事のポイント

• 1 人でメディアが回らない原因は人手ではありません。企画・執筆・校閲・SEO・入稿という編集部の 5 役割を、1 人が頭のなかで同時に走らせて詰まっているだけです
• humbulls Knowledge のパイプラインは企画から入稿までの 9 工程。執筆は記事タイプ T1〜T7 の 7 骨格、品質ゲートはレビュー担当 AI と SEO チェック 25 項目 (必須 16 + 推奨 9) で機械判定しています
• この記事自体が同じパイプラインで作られています。レビュー観点・タイプ判定・工程の棚卸しをそのまま再現できる AI 実行キットを公開します

「編集部のような体制を作りたいけれど、うちは 1 人。ライターも編集者も校閲も雇えない」。私たち humbulls が AI 活用の相談を受けるなかで、オウンドメディアを始めたい 1 人マーケターから最もよく聞く声です。ただ、1 人でメディアが回らない原因は、人手が足りないことではありません。企画・執筆・校閲・SEO・入稿という編集部の 5 役割を、1 人が同時に走らせようとして詰まっているだけです。本記事では、humbulls Knowledge 自体をどう 1 人 × AI で運用しているか、企画から入稿までの全工程と品質ゲートの設計を裏側ごと公開します。特別なライティング体制は要りません。役割の分解と、巻末の実行キットがあれば再現できます。

1. なぜ 1 人では編集部が回らないのか — 同時に走る 5 役割という壁

「書き始めると SEO が気になって手が止まる。タイトルを直すと今度は構成が気になる」。オウンドメディアを 1 人で立ち上げた担当者から、よく聞く詰まり方です。

原因は文章力でも時間でもありません。編集部では企画・執筆・校閲・SEO・入稿を別々の担当者が持ち、モードの切り替えコストを組織構造で吸収しています。1 人でやると、この 5 つを 1 本のなかで脳内スイッチし続けることになります。書きながら SEO を気にし、SEO を直しながら誤字を探し、誤字を探しながら公開手順を思い出す。1 本あたり最低 5 回のモードチェンジが起き、そのたびに集中が切れます。量産できないのは筆が遅いからではなく、この切り替えで消耗しているからです。

解くための型はひとつです。役割を「時間」で分けるのではなく「仕組み」で分けます。今日は執筆の日、明日は校閲の日、と時間で分割しても、1 人である限り担当者は増えません。そうではなく、5 役割それぞれに判断基準を固定した AI の持ち場を用意し、人間は 1 役割だけを担う設計にします。

よくある失敗は、AI に「いい感じの記事を書いて」と丸投げして、5 役割を 1 プロンプトに全部詰め込むことです。企画も執筆も校閲も一度にやらせると、返ってくるのは平均点のどこかで見た文章です。役割を分けるほど、逆に品質は上がります。

2. 編集部の 5 役割を AI に分担する — 編集長・ライター・校閲・SEO・入稿の再設計

「AI に書かせると、うちの記事っぽくならない」。仕組み化を始めた人が最初にぶつかる壁です。

らしさが出ないのは AI の能力不足ではなく、役割ごとの判断基準を渡していないからです。編集部にたとえれば、スタイルガイドも校正ルールも見せずに新人へ丸投げしている状態です。逆に言えば、各役割の基準を文章にして渡せば、AI は編集部の一員として動きます。humbulls では 5 役割を次のように割り当てています。

• 編集長 (企画): 6 クラスタ・50 記事のコンテンツプランから、次に書く 1 本を選ぶ。何を書くかの意思決定だけは人間が持ちます
• ライター (執筆): 記事タイプ別の骨格を持つドラフト生成の仕組み (詳細は第 5 章)
• 校閲 (品質): 読み取り専用のレビュー担当 AI。構造とトーンを指摘する (詳細は第 4 章)
• SEO: title / 見出し階層 / タグ / 内部リンクを機械判定するチェック (詳細は第 4 章)
• 入稿 (publish): プレビュー用の静的サイトに変換し、CMS へ取り込む工程 (詳細は第 3 章)

要は、5 役割のうち人間が握るのは編集長 (何を書くか) の 1 つだけで、残り 4 役割は判断基準ごと AI に委譲する、という配分です。1 人マーケターが AI をどこまで持ち場にできるかは claude-code-for-marketers でも整理しています。

よくある失敗は、校閲まで書き手の AI に兼任させることです。書いた本人にレビューさせると、人間と同じで判定が甘くなります。校閲は別の持ち場 (別のレビュー担当 AI) に分けるほど効きます。

→ 5 役割のうち校閲の基準づくりは、巻末の 実行キット① (所要 20 分) でそのまま作れます。

3. 制作パイプラインの全工程 — 企画から入稿までの 9 工程を公開

「ツールは揃えたけれど、どの順番で回せばいいのか分からない」。AI を導入した直後に、いちばん多い相談です。

工程が言語化されていないと、1 本ごとにゼロから段取りし直すことになります。編集部の強さは個人の才能よりも、工程が固定されていて誰がやっても同じ順番で流れることにあります。humbulls Knowledge の制作は、0 から 8 までの 9 工程で固定しています。

この設計の要は、記事ごとのフォルダに outline.md / sources.md / draft.md / meta.json / assets/ が揃うことです。どのファイルまで埋まっているかを見れば、その記事が 9 工程のどこにいるかがフォルダを開くだけで分かります。進行管理表を別に持たなくても、フォルダ構造が進行状況そのものになります。入稿 (工程 7) では、本番ブログに直接触らず、いったんプレビュー用の静的サイト (Cloudflare Pages・検索エンジンには noindex) に HTML を置き、CMS 側のインポート機能にクロールさせて記事・画像・タグをまとめて取り込みます。本番を編集する前に必ずプレビューを一段挟む構造です。

よくある失敗は、いきなり執筆 (工程 3) から始めることです。出典収集 (工程 2) を飛ばすと、書いた後で数字の裏取りに戻り、本文を書き直す羽目になります。順番は企画 → 出典 → 執筆。この 3 工程の順序だけは崩さないでください。【要確認: 9 工程を 1 本通す平均所要時間の実測】

→ 自社の制作作業をこの 9 工程に棚卸しする手順は、巻末の 実行キット③ (所要 30 分) で実行できます。

4. 品質ゲートの設計 — レビューを主観から機械判定に落とす

「自分で書いて自分で OK を出すと、公開後に誤字を見つける」。1 人運用でいちばん怖い瞬間です。

1 人の校閲が甘くなるのは、気合の問題ではなく、判定基準が頭のなかにしかないからです。基準を外に出して機械判定にすれば、その日の体調や締め切りの焦りに左右されません。humbulls の品質ゲートは二段構えです。

一段目はレビュー担当 AI です。ここには 3 つの設計上の縛りがあります。第一に、原稿を書き換える権限を与えず、指摘だけをさせます (読み取り専用)。勝手に直させないことで、何を根拠に判断したかが人間の側に残ります。第二に、判定は「ルールに準拠しているか」の YES / NO に限定し、文章の好みは言わせません。第三に、軽量なモデルで回します。構造 (見出し階層・本文と実行キットの分離)、トーン (です・ます調・煽りの有無)、タグの規約整合を機械的にチェックする用途なので、重いモデルは要りません。

二段目は SEO チェックで、必須 16 項目 + 推奨 9 項目の計 25 項目を自動判定します。title の文字数、H1 がページに 1 つだけか、slug が kebab-case か、見出しが h4 以降に散らばっていないか、タグが規約どおりか、内部リンクが 3〜5 本あるか、出典が 3〜5 件あるか。人間が毎回目視で数えると抜ける項目を、機械が漏れなく数えます。

二段とも共通するのは「直さない・指摘だけ」という原則です。判定するゲートと、修正する担当 (人間かライター役の AI) を分けることで、基準がぶれません。

よくある失敗は、レビュー AI に修正までやらせることです。指摘と修正を同じ AI が兼ねると、どの指摘を根拠にどこを直したのかが追えなくなり、次の改善につながりません。レビューは読み取り専用に固定するのが安全です。

→ このレビュー観点を自社ルールに合わせて機械判定プロンプトに落とす作業は、巻末の 実行キット① (所要 20 分) で実行できます。

5. 量産を支える型 — 記事タイプ 7 種と判断基準の転写

「毎回フォーマットを考え直していたら、月に 1 本が限界」。量産の相談で必ず出てくる本音です。

量産できないのは書く速度ではなく、毎回構成をゼロから決めているからです。型が決まっていれば、執筆は「考える作業」から「埋める作業」に変わります。humbulls Knowledge では記事を 7 タイプに分類し、それぞれ骨格を固定しています。

書き始める前にタイプを 1 つ宣言するので、構成の意思決定が 1 回で済みます。ちなみにこの記事は T1 メソッド型です。コンテンツプランは 6 クラスタ・50 記事で、どのテーマをどのタイプで書くかがあらかじめ決まっているため、企画段階の迷いも小さくなります。

もうひとつの型が、判断基準の転写です。各記事末尾の AI 実行キットには、本文で示した判断基準を「必ずこの基準に従うこと」というルールとしてプロンプトに書き写します。こうすると読者は、記事を読むだけでなく、同じ意思決定を自分の AI で再現できます。記事が読み物であると同時に、そのまま使える道具になる。これが humbulls Knowledge が記事を営業資産として設計している理由です。1 人マーケターの AI 活用ワークフロー全体像は one-person-marketer-ai にまとめています。

よくある失敗は、タイプを決めずに書き始めることです。途中で「これは実は検証レポートだった」と気づくと、構成が崩れて書き直しになります。最初にタイプを宣言してから書く。順番はこれが先です。【要確認: タイプ確定後に 1 本を書き上げる実測時間】

→ 書きたいテーマを 7 タイプのどれかに判定して骨格を出す作業は、巻末の 実行キット② (所要 15 分) で実行できます。

6. 失敗と学び — AI 編集部でつまずいた 3 つ

「AI で回し始めたら、逆に AI っぽい記事が量産された」。仕組み化の初期に、私たち自身がぶつかった現実です。

つまずきは 3 つありました。ひとつ目は AI 臭です。役割を分けても、各章で「定石 → 従来 → AI 流 → 失敗」の 4 区分を機械的に見出しで区切って回すと、読み物のトーンが死にます。見出しで区切るのをやめ、段落の接続で 4 区分を自然に流す運用に変えてから、ようやく人が読める文章になりました。

ふたつ目は数字の捏造リスクです。「制作 5 日 → 1 日」のような圧縮率は強い訴求ですが、実測していない数字を書いた瞬間に、一次情報としての信頼が崩れます。そこで、未実測の箇所は原稿の段階で 【要確認】 マーカーを置いて空欄のままにし、実測が取れるまで数字を書かないルールにしました。正直に言うと、この記事にもそのマーカーがいくつか残っています。埋まっていないほうが誠実だと考えています。

みっつ目はレビューの主観化です。良し悪しを AI に感想で語らせると、日によって基準が動きます。第 4 章で触れたとおり、レビューは「ルールに準拠しているか」の YES / NO に限定し、好みは判定から排除しました。

まとめて言えば、いちばんの落とし穴は、仕組みを入れた初月に「AI に任せれば速い」と品質チェックを飛ばすことでした。このパイプラインは速さのためではなく、再現性のための設計です。速さは結果としてついてくるもので、目的にすると品質から先に崩れます。

まとめ — まず自分の 1 本を工程に分解する

1 人でメディアが回らないのは、人手が足りないからではなく、編集部の 5 役割を同時に走らせているからです。企画・執筆・校閲・SEO・入稿を 5 つの持ち場に分け、9 工程のパイプラインと 25 項目の品質ゲートで機械判定に落とせば、1 人 × AI でも編集部の再現性は出せます。まずは自分がいま 1 本を作るときの作業を紙に書き出し、どこを AI の持ち場にできるかを分けるところから始めてみてください。

humbulls では、こうした AI 前提の制作体制づくりを実地で学べる AI 活用レッスン や、メディア運用そのものを伴走する Growth Partner サービス を提供しています。「仕組みは分かったが、自社に落とすのは重い」と感じたらご相談ください。制作テンプレを含む詳細ガイドは BtoB マーケ AI 活用ガイド で配布しています。

🤖 AI 実行キット

本文の判断と作業を、そのまま AI で実行するためのキット集です。プロンプトは Claude (ブラウザ版で可) にコピペすれば動きます。

キット① レビュー観点を機械判定プロンプトに落として、記事を読み取り専用でレビューする — 20 分

種別: 判断キット 使うもの: Claude (ブラウザ版で可) 事前に用意するもの: レビューしたい記事本文 (下書きのコピペで可) と、自社のスタイルルール。ルールがまだなければ「です・ます統一」「煽り表現 NG」「見出しは h3 まで」程度の箇条書きメモでも動きます。

プロンプト:

これから渡す記事を、指摘だけするレビュー担当としてチェックしてください。
本文は書き換えず、判定と指摘のみを返してください (修正版は出力しない)。

【チェック基準(必ずこの基準で YES / NO 判定すること)】
1. 文体: 「です・ます」調で統一されているか(「だ。」「である。」が混ざっていないか)
2. 煽り: 「絶対」「100%」「必ず」「最強」「魔法のように」が使われていないか
3. 見出し: h1 は 1 つだけか / h4 以降を使っていないか
4. 数字: 各章に具体的な数字(期間・件数・割合など)が 1 つ以上あるか
5. 出典: 記事末尾に外部 URL が 3〜5 件あるか
6. 自社ルール:(ここに自社のスタイルルールを貼り付け。例 —
   専門用語は初出で一言定義する / 一人称は「弊社では」に統一 など)

【出力】
- 上記 1〜6 の YES / NO 判定表(NO には該当箇所を 1 行で引用)
- 判定が NO の項目ごとに「どこを・なぜ・どの方向に直すか」だけを提示
  (具体的な修正文は書かない。直すのは人間が行う)

出力の確認ポイント:

• 修正版の本文が返ってきていないか確認してください。返ってきたら「指摘だけ」を強調して再実行します
• NO 判定の引用箇所が実際に本文にあるか照合してください。存在しない箇所を指摘していたら、基準の書き方を具体化して再実行します

うまくいかないとき:

• 判定が甘い (全部 YES で返る) → 「厳しめに、疑わしいものは NO 側に倒して判定してください」を末尾に足す
• 別の AI で書いた記事を同じ AI にレビューさせている → 書き手と校閲は別セッション (できれば別モデル) に分けると精度が上がります

キット② 書きたいテーマを記事タイプに判定して骨格を決める — 15 分

種別: 判断キット 使うもの: Claude (ブラウザ版で可) 事前に用意するもの: 書きたいテーマを 1 行 (例「HubSpot Starter のワークフロー設定手順」) と、想定読者の一言メモ。

プロンプト:

これから渡すテーマを、下の 7 タイプのどれか 1 つに分類し、骨格を出してください。

【記事タイプの定義(必ずこの中から 1 つだけ選ぶこと)】
T1 メソッド型: 施策の設計・判断・進め方を体系化する(迷ったらこれ)
T2 実装チュートリアル型: セットアップ・構築手順の再現。スクショ多め
T3 ナレッジ整理型: 「〜とは」概念・フレームワーク解説。FAQ を含む
T4 検証レポート型: 同一条件で比較・実測した一次データが主役
T5 プロンプト集型: プロンプト集そのものが本体
T6 速報型: 新機能・新モデルの解説。2,000〜3,000 字の短文
T7 大全・カタログ型: 「全 N 施策」の網羅系。内部リンクハブ

【入力】
- テーマ:(記入例 = HubSpot Starter のワークフロー設定手順)
- 想定読者:(記入例 = HubSpot 導入直後で自動化をこれから組む担当者)

【出力】
1. 判定タイプ(1 つ)とその理由 2 行
2. そのタイプの章立て案(章タイトルを 5〜8 個。各章に入れる数字の観点も 1 語)
3. 章末に置く AI 実行キットの案(何を実行させるキットか、1〜3 個)

出力の確認ポイント:

• 2 タイプで迷った様子なら、テーマを「手順の再現が主目的 (T2)」か「判断の体系化が主目的 (T1)」かで人間が最終決定してください
• 章立て案の各章に数字の観点が入っているか見てください。入っていない章は具体性が弱くなるサインです

うまくいかないとき:

• どのタイプにも決めきれず複数返ってくる → テーマが 2 記事分あるサインです。「知識記事 (T1/T3) と実行記事 (T2) に分けるとしたら?」と聞き直して分割します

キット③ 自社の制作作業を 9 工程パイプラインに棚卸しする — 30 分

種別: 実装キット 使うもの: Claude (ブラウザ版で可) 事前に用意するもの: いま記事を 1 本作るときにやっている作業を、思いつく順に列挙したメモ (順不同・粒度バラバラで可)。

プロンプト:

私がいま記事制作でやっている作業を、下の 9 工程パイプラインに棚卸ししてください。

【9 工程(この枠に現状作業を割り当てること)】
0 受信箱: ネタの一時管理
1 企画: 章立て・想定キーワード
2 出典収集: 参考にする権威メディア 3〜5 件
3 執筆: 初稿を書く
4 アセット: 図表・スクショを用意
5 レビュー: 品質チェック(指摘のみ)
6 SEO チェック: title / 見出し / タグ / 内部リンク / 出典の確認
7 入稿: CMS へ公開
8 実績登録: 制作実績としてストックするか判断

【私の現状作業(順不同で貼り付け)】
- (記入例)ネタを思いついたらメモアプリに書く
- (記入例)いきなり本文から書き始める
- (記入例)公開前に自分で読み返す
- (以下、自社の作業を貼り付け)

【判定ルール(必ずこの基準で振り分けること)】
- 「何を書くか」を決める工程(0・1)は人間が持つ
- 「基準に沿って作業する」工程(3・5・6)は AI に判断基準ごと委譲できる
- 現状で抜けている工程があれば「未整備」と明記する

【出力】
1. 現状作業を 9 工程に割り当てた表(工程 / 現状のやり方 / 未整備か)
2. 人間が持つ工程 / AI に委譲できる工程の振り分け
3. まず着手すべき「未整備の工程」を 1 つだけ提案(理由 1 行)

出力の確認ポイント:

• 工程 2 (出典収集) と工程 5・6 (レビュー / SEO) が「未整備」になりがちです。ここが抜けていると品質が安定しません
• 「AI に委譲できる」と判定された工程に、判断基準がまだ言語化されていないものがないか確認してください。基準がなければ委譲しても品質は上がりません

うまくいかないとき:

• 現状作業が工程に対して多すぎる (1 工程に 5 個以上ぶら下がる) → その工程はさらに分割できるサインです。工程内の手順を分けて再実行します

参考文献

• B2B Content Marketing Benchmarks, Budgets & Trends — Content Marketing Institute (取得日: 2026-07)
• The State of Marketing — HubSpot (取得日: 2026-07)
• Claude Code Documentation — Subagents — Anthropic (取得日: 2026-07)