Zennのmuramasa0228さんが、Claude CodeとGitHub MCPを組み合わせて、技術記事の調査・執筆・公開・実績記録までを一筆書きで回せるパイプラインを組んだ、という事例です。
「自社プロダクトが何かに勝った」みたいな派手な話ではなく、「個人の記事執筆フローを毎月続けるための仕組み化」の記録です。 だからこそ、社内のオウンドメディアや個人ブログを抱えている中小企業に近い話だと思いました。
僕が注目したのは、「Zennのpush=公開というプラットフォーム特性を自動化に振り切った設計」のところです。 裏側のスピード自慢ではなく、「人が毎月続けられる導線にした」というのが効きます。 なお、一次情報には時間短縮や本数増加の定量数値は書かれていないので、本記事でも数字は持ち出しません。
技術記事を出し続けることの課題
個人の発信や、社内のオウンドメディアでよくある課題は、こんな感じです。
- 調査→構成→執筆→公開→実績記録までの工程が、毎回手作業
- 公開後にURLを別ファイルにメモする等、付随作業が地味に多い
- フローが固まらないまま月をまたぐと、結局更新が止まる
- 「書く時間より、書き始めるまでの段取り時間のほうが長い」状態になりがち
このタイプの業務は、1工程ずつは数分でも、合計すると毎月のボトルネックになります。 「スピードより継続」を目的にすると、何を自動化するかの優先順位が変わってきます。
Claude Code + GitHub MCPをどう導入したか
一次情報(Zenn、2026-06-20)の範囲では、以下の構成です。
- 対象業務: Zennでの技術記事執筆〜公開〜実績蓄積
- ツール: Claude Code + GitHub MCP(既存) + Zennプラットフォーム
- フロー: 調査・構成 → Zenn形式で執筆 → 公開前確認ゲート → GitHub push(=Zenn側で自動公開) → 実績JSON更新
ポイントは2つあります。
1つめは「Zennのpush=公開かつURL確定」というプラットフォーム特性を、そのまま自動化のトリガーに使っていることです。 公開ボタンを別途押す導線がないので、GitHubへのpushが完了した時点でURLが決まる。 このシンプルさが、Claude Codeから一気通貫で回すには都合がいい設計になっています。
2つめは「公開前確認ゲート」を明示的に挟んでいる点です。 全自動ではなく、人間の最終チェックを残している。 全自動を志向して破綻するのではなく、「自動化6割+人間チェック4割」くらいで止めている塩梅です。
自動化の中身と実態
一次情報で報告されている主な要素は以下です。
- 既存の GitHub MCP を利用(独自MCP実装は記事の主眼ではない)
articles/とbooks/のディレクトリ使い分けで投稿種別を制御- 公開前確認ゲートで、人間がレビューしてから push する運用
- 実績JSONを公開後に自動更新するところまでを一筆書きに
苦労した点として、一次情報では GitHub MCP の権限まわり(403エラー)や、ディレクトリ構造の使い分けに少し詰まったことが触れられています。
繰り返しますが、時間短縮の数値・本数増加の数値は一次情報では未確認です。 ここでは「定量より、フローを定常化させた」という構造的な価値で読む事例として扱います。
中小企業で再現するなら
ここからが本題です。年商5億規模の会社で、社内オウンドメディアや採用ブログの運用に同じ思想を入れるならどう削るか。
構成
| 項目 | muramasa0228さん(個人) | 中小企業(年商5億・広報/採用兼任1名) |
|---|---|---|
| 対象 | 個人技術ブログ | 社内オウンドメディア or 採用ブログ |
| ツール | Claude Code + GitHub MCP + Zenn | Claude Code Max Plan(月3,000円/人〜、2026年6月時点。要最新価格確認) + 既存のCMS or GitHub Pages/Zenn等 |
| 月額費用 | 数千円規模 | 推定 月3,000〜1万円(担当1〜2名分) |
| 初期費用 | ほぼゼロ(セルフ実装) | 推定 20〜50万円(フロー設計・プロンプトテンプレ整備・GitHub運用ルール策定) |
| 体制 | 本人1名 | 既存広報/採用担当+外部支援月5時間 |
| 期間 | 数日でPoC | 1〜2ヶ月でPoC→定常運用 |
評価軸スコア
| 評価軸 | スコア |
|---|---|
| ROI(投資対効果) | ★★★☆☆ |
| 再現性(中小企業) | ★★★☆☆ |
| 難易度(低いほど簡単) | ★★★☆☆ |
(難易度=数字小さいほど簡単)
スコア根拠は以下です。
- ROIが中程度なのは、一次情報に定量効果が記載されておらず、「継続性の向上」という定性価値が中心のため
- 再現性が中程度なのは、GitHub運用とCLI操作にある程度の慣れが要るため
- 難易度が中程度なのは、Claude Code+GitHub MCPの初期設定と公開前ゲートの設計に学習コストがあるため
前提条件・必要データ
- 記事ソースをGitリポジトリで管理する運用に踏み切れる(WordPress依存だと相性が悪い)
- 公開前ゲートを担当者が運用ルールとして守れる
- 既存の記事構成テンプレ(冒頭・本文・まとめ・タグ)がある程度言語化されている
- 月に1〜数本でも、定常的に出していくコミットメントがある
失敗条件・適用しないケース
- 公開導線がWordPress等のWYSIWYG編集中心で、Git運用にしづらい
- 「Claude Codeに全部書かせる」前提で、公開前チェックを省略しようとする
- 記事の編集権限が複数人にまたがり、Git運用のレビューフローと噛み合わない
- 月の発信頻度がきわめて低く、自動化の初期投資が回収できない
「Claude CodeとMCPを入れれば記事制作が一気に楽になる」とは限りません。
Git運用への移行→記事テンプレの言語化→Claude Codeで下書き→人間が公開前レビュー→pushで公開、という5ステップを踏んで初めて、続けられるパイプラインになります。
「いきなり全自動」を目指さず、まずは「下書き〜公開導線の半自動」を狙うのが現実解です。
出典・参考
市野
愛知県岡崎市でAI活用支援を手がける一人社長。 中小企業の現場でAIを実装してきた経験から、他社事例を「うちで再現するには」の視点で読み解いて発信中。
愛知県岡崎市を拠点に、中小企業向けのAI活用支援を提供。ChatGPT・Claude Code等を活用した業務自動化やSEO・広告運用の内製化を支援。経営者が自らAIを使いこなせる体制づくりをサポートしている。
＞＞詳細なプロフィールはこちら