【編集中】HubSpot にブログを一括インポート — Starter のまま 17 本を手作業ゼロで移行
最終更新日: / 公開日:
最終更新日: / 公開日:
本記事のポイント
- HubSpot のブログ取り込みは 4 方式あり、そのすべてが全プラン対応です。上位プランへ上げなくても、Starter のまま一括で載せられます
- 静的プレビューサイトを公開 → Smart Copy で一括取り込み → 下書きで受けて補完、の 3 STEP で再現できます。ビルドは AI に組ませて 1 コマンド化するので、記事が増えても同じ手順で回せます
- この手順で humbulls Knowledge の 17 本を、コピペ作業ゼロ・追加コスト $0/月・本文セレクター 1 個で一括移行しました
「AI で記事は何本も書けるようになったのに、HubSpot に載せる工程で詰まっている」。humbulls が AI 活用を支援するなかで、いま最もよく聞く悩みです。原因は書き込み方式でも予算でもありません。「AI で書いたのだから Claude にそのまま投稿させればいい」と考えて、そこで最初に躓くからです。本記事では、humbulls 自身が Starter のまま 17 本を一括移行した実運用を、静的サイトの用意から HubSpot への取り込み、取り込み後の補完まで、そのまま再現できる STEP に落として公開します。ビルドのコードは巻末の一括実行プロンプトで生成できるので、必要なのは「どの原稿を載せるか」を決める力だけです。仕様はすべて 2026 年 7 月時点の公式ドキュメントで確認しています。
できあがるもの — 17 本が下書きで一括生成される
完成形から見せます。下図の流れで、AI で書いた原稿 (humbulls の場合は draft.md 形式の Markdown) が、静的プレビューサイトを経由して HubSpot のブログに下書きとして一括生成されます。1 本ずつエディタに貼り付ける作業はゼロです。

| 項目 | 内容 |
|---|---|
| 所要時間 | 17 本で半日 (ビルド 30 分 + 取り込み・下書き確認) |
| 前提条件 | HubSpot Starter 以上 / Markdown 原稿 + meta.json / Claude Code またはブラウザ版 Claude / Cloudflare アカウント |
| 追加ランニングコスト | $0/月 (Cloudflare Pages 無料枠 + HubSpot 標準機能) |
| 取り込み規模の実測 | 17 本を 1 スキャンで一括生成、本文セレクター 1 個で全件抽出 |
なぜこの経路なのかを、先に整理しておきます。CMS を乗り換えるときの定石は、記事を 1 本ずつ手で作り直すのではなく、プラットフォーム標準の「ブログ移行 (インポート) 機能」でまとめて取り込むことです。HubSpot が受け付ける方式は 4 つに絞られています。WordPress connect (WordPress の API 経由)、Smart Copy (公開済みのページ URL を読み取る)、XML アップロード (WordPress・Squarespace のエクスポート)、CSV アップロードの 4 つです。重要なのは、この 4 方式がいずれも「全プラン対応 (All products and plans)」で、Starter でもそのまま使える点です。ブログの一括取り込みのために Pro へ移行する必要はありません。

この 4 方式のうち、humbulls は Smart Copy を採用しました。公開済みの記事 URL を渡すと、その構造を読み取ってタイトル・本文・画像・タグを吸い上げる機能です。原稿を一度どこかに静的サイトとして公開しておけば、その URL 群を Smart Copy に食わせるだけで、HubSpot 側にブログ記事が一括で生成されます。
その手前で、多くの人が 2 つの近道を試して溶かします。ひとつは「Claude に直接投稿させる」ルートです。コンタクトや取引を MCP (AI と外部ツールをつなぐ規格) で読み書きできているなら、ブログも同じ感覚でいけるはず——正直に言うと、humbulls も最初にそう考えました。ところが HubSpot の MCP が公開しているのは CRM / マーケ系のオブジェクトで、ブログ記事は読み取りはできても書き込みには対応していません。もうひとつは「RSS で取り込めるのでは」という発想ですが、HubSpot の RSS はフィードを表示・配信する出力側の機能で、取り込み元にはできません。ブログ記事 API (POST /cms/v3/blogs/posts) を使えば作成・公開自体は可能ですが、それは対話でその場でやらせるのではなく、スクリプトを 1 本組んで回す話になります (規模が増えたら有力なので、後半で使い分けを整理します)。AI に一言で直接やらせるルートは今のところ無い、と割り切って、AI が確実に噛める現実解として次の 3 STEP を進めます。
STEP 1. 静的プレビューサイトを用意する — draft.md を 1 コマンドで公開用 HTML に
「原稿は Markdown で全部あるのに、これを Web ページにするところでまた手作業に戻ってしまう」。ここが最初の分かれ道です。Smart Copy の入力はライブ URL なので、AI で書いた原稿を、いったん人が読める形の Web ページとして公開しておく必要があります。
やることは 2 つです。記事本文を HTML に変換して静的ホスティングに載せること、そしてその変換をスクリプト 1 本に集約して手作業に戻さないことです。humbulls では、この変換と公開をビルドスクリプト 1 本にまとめ、スクリプト自体も Claude Code に書かせました。やっていることは単純で、各記事の Markdown を HTML に変換し、共通テンプレート (ヘッダー・フッター・スタイル) に流し込み、図版を所定のフォルダにコピーし、記事一覧ページを全記事で作り直す、という流れです。原稿を 1 本足したらスクリプトの記事リストに 1 行加えて再実行するだけで、サイト全体が更新されます。
公開先には Cloudflare Pages を使いました。無料で、コマンド 1 つでデプロイでき、*.pages.dev の URL が即発行されます。ここで 1 つだけ大事な設定があります。プレビューサイトは取り込みのための一時公開なので、検索エンジンには出さない (noindex) ようにします。Smart Copy はこちらが指定した URL を直接読みに行くため、noindex でも取り込みには影響しません。プレビューが検索に載って本番記事と重複するのを防ぐための措置です。
つまずきポイントは図版のファイル名です。1 つのフォルダに全記事の画像をまとめると、別々の記事が同じ figure-01.png のような名前を持っていた場合に上書きで壊れます。humbulls でも、2 本の記事が同名の図版を持っていて衝突しました。対策はシンプルで、画像名に記事の slug を接頭辞として付け ({slug}-figure-01.png)、名前を記事ごとに一意にするだけです。ビルドスクリプトにこの命名を組み込んでおけば、以降は記事を増やしても衝突しません。このビルドスクリプトは巻末の実行キット①でそのまま生成できます。
STEP 2. Smart Copy で一括取り込み — CSS セレクター 1 個で本文だけを抜く
プレビューサイトを公開したら、HubSpot 側で取り込みます。ブログ設定のインポートからスマートコピーを選び、一覧ページの URL を「ブログのホームページ」に、記事 1 本の URL を「最近の投稿」に指定します。すると Smart Copy がサイト構造を学習し、残りの記事を自動で見つけて吸い上げます。1 回のスキャンで最大 400 本まで対応するので、数十本規模なら 1 回で終わります。
ここで多くの人がつまずくのが、本文に余計な要素が混ざる問題です。Smart Copy はページを丸ごと読むため、指定しないとナビゲーション・パンくず・サイドバー・フッター・シェアボタン・著者欄まで本文として取り込んでしまいます。対策は、記事本文が含まれる領域の CSS セレクターを指定して、本文だけを切り出すことです。Smart Copy の設定画面にも、この本文セレクターを入力する欄があります。

STEP 1 で、本文を囲む要素に固有のクラス名を付けておきました。ここでそれが効きます。humbulls のテンプレートでは本文が blog-post__blog-contents というクラスの要素だけに収まっているので、セレクター欄に .blog-post__blog-contents と入力するだけで、ナビもフッターも著者欄も除外され、見出し・段落・表・コード・図版だけが本文として取り込まれます。全記事が同じテンプレートなら、このセレクター 1 個で 17 本すべてに効きます。カバー画像・タイトル・著者・日付・タグは Smart Copy が別のフィールドで自動取得するので、本文セレクターからは意図的に外すのが正解です (入れると本文内で二重になります)。
つまずきポイントは、セレクターの値をいきなり全件に適用してしまうことです。正しい値は、ブラウザの検証ツールで本文をクリックし、本文全体を過不足なく囲っている一番内側の要素のクラスを読めば分かります。うまく取れないときは、まず 1 本だけ取り込んでプレビューを確認し、本文の範囲が合うまでセレクターを調整してから残りを流すのが安全です。セレクターの特定は巻末の実行キット①に含めています。
STEP 3. 下書きで受けて slug・meta・画像を補完する
取り込みが便利でも、移行の定石として「取り込んで終わり」にはしません。Smart Copy が自動で拾うのはタイトル・著者・公開日・アイキャッチ画像・本文・タグまでで、URL の slug と meta description (検索結果に出る説明文) は拾いません。この 2 つは SEO に直結するため、空欄のまま公開すると自動生成の slug や説明文になってしまいます。
対策は、取り込みを下書き (draft) として実行し、公開前に slug と description だけを各記事に転記することです。humbulls では、原稿の meta.json に slug と description をあらかじめ持たせてあるので、取り込み直後に即公開せず下書きで受けることで、本文の崩れや画像の抜けもまとめて確認できます。
つまずきポイントは画像の参照先です。必ず 1 本目の下書きで、画像が HubSpot 側に取り込まれているかを確認します。Smart Copy がプレビューサイトの画像を HubSpot のファイルに再ホストしてくれれば理想ですが、元 URL を参照したままになる場合、プレビューサイトを閉じた瞬間に本番記事の画像が全部切れます。1 本目で参照先を確認し、もし元 URL のままなら、画像を HubSpot のファイルマネージャーに上げて差し替えるか、後述の Blog API 経路に切り替えます。slug は後から変えると URL が変わり SEO 上不利なので、この下書き段階で確定させます。
動作確認 — 何が見えれば成功か
ここまで進めたら、下書きの 1 本目を開いて次の 4 点を確認します。
- 本文: 見出し (h2 / h3)・段落・表・コードブロック・図版が崩れず、ナビやフッターが本文に混ざっていない
- 画像: 本文中の画像の参照先が HubSpot のファイル (
fs1.hubspotusercontent等) になっている。元のプレビュー URL のままなら再ホストが必要 - メタ: タイトル・著者・公開日・アイキャッチ・タグが正しく入り、slug と meta description が
meta.jsonのとおりに補完されている - 一覧: 取り込んだ本数が下書き一覧に揃っている (17 本なら 17 本)
4 点が揃えば、あとは 1 本ずつ公開ボタンを押すだけです。最初の 1 本で本文セレクターと画像参照が問題なければ、残りは同じ設定でそのまま通ります。
規模が増えたら — Smart Copy・CSV・Blog API の使い分け
Smart Copy が万能というわけではありません。取り込み方式は用途で使い分けるのが定石です。手軽さでは Smart Copy ですが、原稿を HTML でそのまま流し込みたいなら CSV 取り込み、投入から公開まで完全に自動化したいなら Blog API という具合に、規模と体制で最適解が変わります。判断軸は「手作業をどこまで減らしたいか」と「エンジニアがいるか」で、どれも Starter で使える見込みなので Pro 移行は判断軸に入りません。
| 観点 | Smart Copy | CSV 取り込み | Blog API |
|---|---|---|---|
| 事前準備 | 静的サイトを公開 | CSV に本文 HTML を整形 | スクリプト作成 |
| 手作業量 | 小 (UI 完結) | 中 (CSV 整形) | 最小 (自動) |
| 画像 | 要確認 (再ホスト有無) | 元 URL 参照 | API で HubSpot に再ホスト |
| slug / meta | 手で補完 | CSV 列で指定可 | API で指定可 |
| 必要スキル | 設定のみ | 表計算 | 短いコード (AI に書かせれば可) |
| プラン | 全プラン (Starter 可) | 全プラン (Starter 可) | Starter で可の見込み ※ |
CSV 取り込みは、本文 HTML をそのまま列に入れられ、slug や meta description も列で指定できるのが利点です。Smart Copy が拾わない項目を最初から埋められるので、補完の手間が減ります。一方、画像は元 URL 参照のままなので、再ホストは別途必要です。Blog API は投入・画像アップロード・公開までスクリプトで一気通貫にでき、17 本でも数百本でも手作業はほぼゼロになりますが、スクリプトを書く一手間があります。
※ Blog API のプラン制約には補足が要ります。公式スコープ表に残る「上位プラン必須」という content スコープの記述は旧称時代のもので、ブログ記事の作成・公開自体は全プラン対応です。プライベートアプリのスコープ選択画面に content (と画像用の files) が出れば API 経路が確定し、出なければ Smart Copy か CSV に切り替えます。一度きりの移行なら Smart Copy、毎月継続して投入するなら Blog API 寄りが目安です。
まとめ — プレビュー公開 → Smart Copy → 下書き補完の 3 STEP
AI で記事を量産できるようになったら、投入工程を手作業に戻さないことが肝心です。「Claude に直接投稿させる」ルートは現状ありません (MCP はブログ書き込みに非対応、API はスクリプト前提) が、頼るのは HubSpot 標準のブログインポートで、4 方式すべてが Starter で使えます。上位プランへ上げなくても、一括投入は成立します。
手順はシンプルです。まず原稿を静的プレビューサイトとして公開し (ビルドと公開は AI に組ませて 1 コマンド化)、次に Smart Copy で取り込んで本文セレクターを 1 つ指定し本文だけをきれいに抜き、最後に下書きで受けて slug・meta description を補完し画像の参照先を確認してから公開する。この流れなら、書く速度と載せる速度が釣り合い、量産した記事が下書きのまま眠ることがなくなります。特別なスキルは要りません。コードは巻末の実行キットで生成できます。
なお、この記事で使ったプレビューサイトのビルドや記事制作そのものを AI でどう回しているかは、マーケターのための Claude Code 入門 と MCP で HubSpot を AI から操作する で扱っています。プランの見極めから入りたい方は HubSpot Starter と Professional の違い もあわせてどうぞ。
自社の AI 量産コンテンツを HubSpot にどう載せるか、投入経路の設計から相談したい方は、humbulls の 無料相談 をご利用ください。実際に使っているビルドスクリプトと取り込み設定をお見せしながら、体制づくりをお手伝いします。Growth Partner サービス では、こうした HubSpot 運用の内製化まで伴走しています。
🤖 AI 実行キット
本文の STEP 1〜3 のうち、コードで自動化できる「静的プレビューサイトのビルド」を、そのまま Claude Code に丸ごと組ませるためのキットです。記入例を自社の値に置き換えて渡してください。STEP 2・3 は HubSpot の UI 作業なので、末尾のトラブルシュート表を手元に置いて進めます。
キット① 一括インポート用の静的プレビューサイトを生成する — 30 分
種別: 実装キット 使うもの: Claude Code (ブラウザ版 Claude でもコードは生成できますが、実行と Cloudflare へのデプロイは手動になります) 事前に用意するもの: 各記事の draft.md + meta.json + assets/ 一式 / 公開に使う Cloudflare アカウント / 本文を囲むテンプレートのクラス名 (なければ「本文セレクター用に固有クラスを付ける」も依頼に含める)
プロンプト:
Markdown の記事群を、HubSpot Smart Copy で一括取り込みするための
静的 HTML プレビューサイトにビルドするスクリプトを作ってください。
【私の環境】
- 記事の置き場所: 各記事フォルダに draft.md(本文)/ meta.json
(title・description・slug・tags・publishedAt)/ assets/(cover.png と figure-*.png)
- 記事本数: 17 本(記入例。今後も毎月追加する)
- 公開先: Cloudflare Pages(wrangler pages deploy でデプロイ)
- 本文を囲むクラス名: blog-post__blog-contents(記入例。自社テンプレートのクラスに置換。
無ければ本文だけを囲む固有クラスを新設して付けてください)
【必ず守る実装条件(本文の対策を転写)】
1. draft.md の先頭 H1 を除いた本文を HTML に変換する(表・コードブロック・画像を保持)
2. 本文だけを、指定した固有クラス(blog-post__blog-contents)の要素で過不足なく囲う
── Smart Copy の本文セレクターにこの 1 個を使うため
3. 画像は {slug}-figure-01.png のように slug を接頭辞として付けてコピーし、
別記事どうしの figure-01.png 衝突を防ぐ
4. 全記事をリンクした一覧ページ(index)を毎回作り直す
5. 同じ入力なら何度実行しても結果が同一(冪等)にし、記事追加はリストに 1 行足すだけにする
6. どの記事からも参照されない孤立画像は削除する
7. 出力ディレクトリに noindex 用の robots 設定(noindex メタ or _headers)を含める
【出力】
- ビルドスクリプト本体 + 実行手順
- Cloudflare Pages への wrangler デプロイコマンドを最後にコメントで併記
出力の確認ポイント:
- 本文が指定クラス 1 個だけで囲まれ、そのクラスがページ内で 1 回だけ出現するか (Smart Copy のセレクターに直結)
- 画像コピーが
{slug}-接頭辞付きになっていて、同名衝突が起きない実装か - 再実行しても index が重複せず、出力が同一になる (冪等) か
- noindex 設定が出力に含まれているか
うまくいかないとき:
- 再実行のたびに一覧が増える → 冪等になっていません。「出力ディレクトリを毎回クリーンしてから生成」する指示を追記してください
- Smart Copy で本文にナビやフッターが混ざる → 本文クラスの囲みが広すぎます。1 記事分の HTML を貼って「本文だけを囲む一番内側のクラスを提案して」と依頼し、セレクターを絞り込みます
- 取り込み後に画像が切れる → プレビュー URL 参照のままです。STEP 3 で HubSpot ファイルへ再ホストするか、Blog API 経路に切り替えます
よくあるつまずきの早見表:
| 症状 | 原因 | 対処 |
|---|---|---|
| RSS で取り込もうとして経路が無い | RSS は出力側機能で取り込み元にできない | Smart Copy / CSV / XML / WordPress connect の 4 方式から選ぶ |
| Claude に直接投稿させられない | MCP はブログ書き込み非対応 | 静的サイト + Smart Copy、または Blog API スクリプト |
| 本文にナビ・フッターが混ざる | 本文セレクター未指定 | .blog-post__blog-contents 等、本文だけを囲むクラスを指定 |
| 別記事の図版が上書きで消える | 画像名の衝突 (figure-01.png) | slug 接頭辞 {slug}-figure-01.png で一意化 |
| slug・説明文が自動生成になる | Smart Copy は slug / meta を拾わない | 下書きで受けて meta.json から補完 |
| 公開後に画像が全部切れる | プレビュー URL を参照したまま | 1 本目で参照先確認 → HubSpot に再ホスト |
参考文献
- Import your content into HubSpot — HubSpot Knowledge Base (取得日: 2026-07)
- Import a blog from any CMS with smart copy — HubSpot Knowledge Base (取得日: 2026-07)
- Import your blog into HubSpot as a CSV file — HubSpot Knowledge Base (取得日: 2026-07)
- CMS API | Blog Posts — HubSpot Developers (取得日: 2026-07)
- Deploy your directory of static assets — Cloudflare Pages — Cloudflare Docs (取得日: 2026-07)