Grok Botでマーケ用コンテンツパイプラインを検証した記録
Grok Botと専門ボット連携で、中小企業IT向けのマーケ用コンテンツパイプラインを実機検証。下書きからレビュー用PRまでの手順、失敗、画像生成実験、学びをまとめます。
はじめに：なぜ今、Grok Botを検証するのか
弊社 toolchainjp の課題は、プロダクトや技術そのものより、マーケティングとコンテンツ作成の弱さにあります。特に「日本の中小企業のIT地盤づくり」というテーマは伝えるべきことが多い一方で、毎週安定して記事や台本を出せる体制がまだ薄いです。
そこで、単発のチャット利用ではなく、役割分担した複数ボットでコンテンツパイプラインを組めるかを検証しました。結論から言うと、「下書き→レビュー用PR」までは再現できました。一方で、短い抽象記事は読者価値が足りないこと、そして人間の編集ゲートを外すと質が落ちることも、同じ日のうちに痛いほど分かりました。
この記事は広告ではなく、社内検証ノートを公開用に整えたものです。読者は技術者で、マーケにも関心がある方を想定しています。
検証の仮説
仮説は次の3つです。
- 専門ボットに分けると、1人で全部やるより再現性が上がる
トレンド収集・執筆・PR化を別人格にすると、プロンプトが肥大化せず、失敗箇所が切り分けやすい。 - 「公開」ではなく「レビュー用PR」まで自動化するのが、中小チームにちょうどいい
マージ権限を人間側に残すと、品質事故を抑えつつ制作速度だけ上げられる。 - 読者が欲しいのは機能カタログではなく、「自分の業務で何が起きるのか」
抽象論・短文・図なしは刺さらない。手順・成果物・失敗をセットで書く必要がある。
カレンダー連携は使わず、依頼文と成果物の受け渡しだけで再現できるかを確かめました。
検証環境
| 要素 | 内容 |
|---|---|
| 司令塔 | Grok Bot（タスク分解・他ボットへの依頼） |
| 収集 | トレンドレーダー（平日朝の開発者向けトレンドブリーフ想定） |
| 執筆 | コンテンツ職人（本記事の執筆担当） |
| 公開導線 | ブログPR職人（toolchainjp/toolchainjp-lp へレビュー用PRを作成。自動マージはしない） |
| ブログ基盤 | Astro。記事は src/content/blog/YYYY-MM-DD/*.md |
| frontmatter | title / description / pubDate / 任意で tags・categories など |
| 関連PR | #12（初稿差し替え）、#13（完成稿の最終反映） |
図: Astro ブログでは日付フォルダ配下に Markdown と画像を置く。今回の検証記事も同じルールに従った。
再現手順
以下は、今回実際に走った流れを、他チームが真似できる形にしたものです。特別なスケジューラやカレンダー連携は不要です。
Step A. 役割を決めてボットを分ける
- 「収集」「執筆」「PR化」を別ボットにする。
- 執筆ボットには最初から次を渡す。
- 読者（例: エンジニア／中小IT関心層）
- 言語（日本語）
- すぐ公開しない・レビュー用
- 成果物フォーマット（
title/description/ 本文Markdown / タグ案）
- PRボットにはリポジトリパスと「マージしない・URLを返す」だけを渡す。
ポイントは、執筆ボットにGit操作まで背負わせないことです。失敗時の切り分けが楽になります。
Step B. 最初の実験は「短い記事でパイプライン疎通」
マーケ検証の第一歩は、名文を書くことではありません。パイプが通るかです。
今回はまずエンジニア向けの短い下書き（AIコーディング支援の選び方）を書き、ブログPR職人へ渡しました。結果、src/content/blog/2026-10-01/ 配下への追加差分を含むPR #12 がオープンになりました。ここまでで仮説2（レビュー用PRまで）は成立しました。
Step C. 同じ日に「質の不合格」を出す
疎通できた直後、短い記事は具体性・長さ・図が足りないと判断し、破棄指示が出ました。これが検証として一番価値がありました。
パイプが通っても、中身が薄いとマーケ資産にならない。むしろ「動いたから公開」は最悪です。だからこそ、人間（または司令塔）による不合格ゲートを最初から設計に入れておく必要があります。
Step D. 本命記事を、検証ログつきで書き直す
破棄後の指示は明確でした。
- 実際に検証する（ボット連携、トレンド→下書き→PR）
- マーケ仮説と結果を書く
- 長め・具体・成果物つきで書く
- 完成後に #12 を差し替えるか、仕上げ用の新PRにする
本記事そのものが、この Step D の成果物です。#12 で検証稿へ差し替え、#13 で言い回しを整えてマージしました。
追加実験：画像生成（富士山サンプル）
テキストだけのパイプでは、記事品質の要件である「図」が後追いになります。そこで検証の一環として、画像生成もできるかを別実験として確認しました。
プロンプトはシンプルに、夜明け・湖面・富士山といった風景指定です。得られた静止画を WebP に変換し、記事と同じ日付フォルダへ配置しました。
図: 画像生成の検証サンプル。湖面に映る富士山と朝焼け。記事用素材として同フォルダの 05-grok-image-generation-fuji.webp に保存。
分かったことは次のとおりです。
- 生成→リポジトリ配置まで一連で運べる
生成物をブログの配置ルール（日付フォルダ＋WebP）に落とせば、本文から相対パスで参照できる。 - 「きれいな一枚」と「説明に耐える一枚」は別物
風景サンプルとしては十分でも、手順説明やUI解説にはならない。用途別にプロンプトと後工程を分ける必要がある。 - キャプションとファイル名を先に決めると差し込みが速い
「後で図を入れる枠」だけ残すと、公開直前に詰まる。今回のように実ファイルを先に置く方が運用しやすい。
つまり、画像工程はオプションではなく、パイプラインの正式ステップに入れるべきです。スクリーンショット担当を人間に残すか、生成ボットに渡すかを役割表に書いておくのがよいでしょう。
検証結果
うまくいったこと
- 役割分担ボットで、依頼文だけで成果物が動く
「下書きを書け」「PRを作れ」という短い依頼で、チャット上の下書きとGitHub PRまで到達できた。 - 公開権限を切ったまま速度を出せる
マージしない運用でも、レビュー可能な差分として残るので、社内共有コストが低い。 - 失敗を同じパイプラインで回収できる
短い記事 → 不合格 → 本記事へ差し替え、というループを同日で回せた。マーケ実験として理想的です。 - 画像生成も検証に含められた
富士山サンプルを生成し、記事ディレクトリに WebP として同梱できた。
つまずいたこと / まだ弱いこと
- 最初の下書きが抽象的すぎた
「3つの型」「チェックリスト」だけでは、読者が明日やる行動に落ちない。既存の良記事（手順・画面・プロンプト付き）と比べると明らかに薄い。 - トレンド起点の本流は、まだ回しきれなかった
設計上は「トレンドレーダーのブリーフ → 最もコンテンツ向きの1件を選んで執筆」だが、初回はブリーフ待ちのまま仮題で疎通検証になった。マーケの本命（テーマ選定の自動化）は未完了。 - PR作成経路の一時不通
受け渡し直後、PR担当側から「GitHubコネクタにファイル追加相当が無く詰まった」との連絡があった。その後 #12 は作成されたが、経路の再現手順をドキュメント化できていない。運用手順書が必要。 - 画像・スクリーンショットが後追いになりがち
初回パイプはテキスト中心だった。今回の富士山サンプルで生成経路は確認できたが、UIスクショや構成図は別途用意する必要がある。
マーケへの活かし方
検証を踏まえて、仮説を次のように更新しました。
1. 「週次コンテンツ工場」は組める。ただしゲートが本体
中小チームがやるべきは、毎日の奇跡的な名文ではなく、次の固定ラインです。
- 朝: トレンド／顧客課題の短いブリーフ
- 昼: 1本の下書き（ブログ or 台本）＋必要なら生成画像
- 夕: レビュー用PR
- 人間: 15分レビュー → マージ or 差し戻し
ここでのKPIは「公開本数」より先に、差し戻し理由の分類です。薄い・抽象・根拠なし、が減ればマーケの基礎体力が上がります。
2. 読者向けメッセージは「AIが書く」ではなく「役割を分ける」
機能紹介になりがちなのを避けるなら、訴求はこうです。
- 一人社長でも、収集・執筆・PR化を分業できる
- 公開ボタンは人間が持つ
- 失敗したら同じ日に差し替えられる
- 画像もテキストと同じパイプラインに載せられる
これは、中小企業のIT地盤づくり支援という当社テーマとも相性が良いです。「全部入りAI」ではなく、運用可能な分業を見せる。
3. コンテンツの最低品質バーを明文化する
今回の不合格から、社内バーを仮置きします。
- 導入で「誰の・何の困りごと」が1段落で分かる
- 再現手順が、特別なスケジューラ無しでも書ける
- 成果物（URL、ファイルパス、画面）が1つ以上ある
- 実画像が1枚以上あり、未完成の図枠を残さない
- 「次の実験」が1つ以上ある
これを満たさない下書きは、PR化してもマージ候補に入れない。
次の実験
- トレンドレーダー初回ブリーフ起点で1本書く
仮題ではなく、ブリーフから「最もコンテンツ向き」を選ぶ本流を完走する。 - UIスクリーンショットと構成図を工程に固定する
生成サンプルだけでなく、手順説明用の実画面を同じ日付フォルダへ置く。 - SME向けライン（SME ITレーダー → SMEコンテンツ職人）も同じ合格バーで回す
読者を経営者・現場寄りに変えたとき、分業が効くかを比較する。 - PR作成手順書を1枚にする
コネクタ不通時の代替（CLI / 手動）を含め、再現不能を潰す。
感想
Grok Bot単体の「賢い返事」より、役割を分けてレビュー可能な成果物まで運ぶ設計の方が、マーケ実務に効きます。逆に、パイプだけ通して中身を雑にすると、AI導入あるあるの「量は増えたが信頼が減る」に一直線です。
今回の一番の収穫は、同日中に「疎通成功」と「品質不合格」、そして「画像生成の同梱」まで取れたことです。これができるなら、コンテンツ不足は気合ではなく、実験回数で解けます。
まとめ
- 専門ボット連携で、下書きから
toolchainjp-lpのレビュー用PRまで到達できた（実例: PR #12 / 仕上げ #13）。 - 短い抽象記事は不合格。具体手順・成果物・実画像が必要。
- 富士山サンプルで画像生成→WebP配置まで検証できた。
- マーケに効くのは自動公開ではなく、分業＋人間ゲート＋同日差し替え。
- 次はトレンド起点の本流と、UI図の固定、SMEライン比較。
