こんにちは。ACS事業部の越川です。
2026年2月にキャリア採用で APC に入社してから、約2ヶ月。APC技術ブログでは 2026年3月10日から4月17日までに 19本 の記事を公開してきました。約39日間で19本、2日に1本のペースです。
書くペース自体はある程度作れるようになりました。ですが、投稿プロセスのあちこちに残る手作業が、本質ではない手間を毎回生んでいました。誤字チェック、ヘッダー画像の配置、記事のメタ情報（タイトル・公開日などの設定欄）の整形、はてなブログへの同期。
そこで Hatena-Blog-Workflows-Boilerplate（はてな公式の企業ブログ向けワークフロー）を取り込んで、自分たちのワークフローを GitHub 中心に作り替えました。この記事は、その記録と、その過程で改めて言語化できた 手作りも道、仕組み化も道 という並立の考え方についてです。
手作り感を大切にしたい方にはそのやり方があり、エンジニアの矜持を仕組みで貫きたい方には別の道があります。どちらかが正しいのではなく、どちらも道です。
- きっかけ — Meet 中に教えてもらった 1 つの Boilerplate
- 何を課題に感じていたか
- 二つの道がある
- 選んだ道 — はてな準拠 + 独自拡張
- アーキテクチャ — 3 層構造
- 執筆から公開までのフローを整理する
- ディレクトリ構造
- 既存記事の一括移行
- 企業ブログだからこそ、仕組み化の価値が違う
- エンジニアの矜持とは何か
- 迷いが消えた日
- 最後に
- 参考
- ACS 事業部のご紹介
きっかけ — Meet 中に教えてもらった 1 つの Boilerplate
2026年4月21日、事業部内の Meet 中に、別の室の同僚から はてな社公式の GitHub Organization が公開している企業ブログ運営向けの Boilerplate（Hatena-Blog-Workflows-Boilerplate）の存在を教えていただきました。ライセンスは MIT、ステータスはベータ版です。
所属の違いを超えて、いいものはいいと共有してくれるカルチャーがあることに、改めて感謝しています。
ひととおり中身を確認して、すぐに思いました。これ、私たちのブログワークフローの基盤にすべきだ、と。
何を課題に感じていたか
書くペースは作れていました。でも、書いた後の「投稿」というフェーズに、毎回手間がありました。
| 手作業 | 本質か |
|---|---|
| 記事の誤字脱字チェック | 仕組みで減らせる |
| ヘッダー画像を所定のフォルダに配置 | 仕組みで減らせる |
| 記事のメタ情報（タイトル・公開日などの設定欄）を整形して貼る | 仕組みで減らせる |
| はてなブログ側の編集画面に内容を転記 | 仕組みで減らせる |
| 公開 URL をリポジトリ側にも記録 | 仕組みで減らせる |
どれも「この瞬間に書き手の判断が要る」作業ではありません。仕組みに落とせるものばかりです。
2日に1本のペースを維持しながら、月6〜10本のオーダーで書き続けると、この「本質ではない手間」の積み重ねは無視できない大きさになっていました。月間で数時間、年間で数十時間の単位です。
二つの道がある
ここで、大事な認識を先に書いておきます。
ブログの書き方には、少なくとも二つの道があります。
手作り感を大切にする道
一本一本を手作業で丁寧に組み立てる。画像も毎回自分で配置し、記事のメタ情報も手で整える。その手触り感が記事の個性を作る、という考え方です。これは一つの道として尊重されるべきです。
仕組みで矜持を貫く道
繰り返し作業は仕組みに落とし、書き手は「書く」という本質に集中する。誤字チェックは自動化し、画像配置はルール化し、投稿は GitHub Actions に任せる。そのぶん、書く内容の検証や構成に時間を使う。こちらも一つの道です。
どちらが正しいのではありません。どちらも道です。
私が選ぶのは後者ですが、前者を選ぶ方のやり方を否定するつもりは一切ありません。企業で複数人が書く場合、仕組み化の価値は大きいと考えているだけです。
選んだ道 — はてな準拠 + 独自拡張
取り込みにあたって、設計思想を一つ決めました。
基盤は、はてな公式の企業ブログ向けワークフローに準拠する。拡張は、自分たちの独自機能として基盤の上に乗せる。
これは Platform Engineering の王道アプローチでもあります。標準に寄せることで、次の4つが同時に手に入ります。
- 他の人・他の組織が「はてな公式準拠」として理解できる（継承性）
- 上流が更新された時、Renovate で自動追従できる（保守コストの低減）
- 自分で保守する範囲が減る（同期ロジックは上流任せ）
- 業界標準に則っているという発信の説得力が上がる
具体的には、Hatena-Blog-Workflows-Boilerplate を基盤として採用し、その上に以下の独自機能を重ねました。
- ヘッダー画像ジェネレーター（1200×630 の OGP 画像を生成するローカル Web GUI / CLI / MCP）
- Claude Code 用の品質ゲート hooks（誤字検出、メタ情報の不整合検知、Qiita 記法の
$未エスケープ警告など） - GitHub Copilot による PR レビュー（レビュー基準を instructions ファイルで定義）
- 記事ネタを GitHub Issue として管理し、Projects V2 でカンバン可視化
アーキテクチャ — 3 層構造
全体像を表で整理します。
| レイヤー | 役割 | 出所 |
|---|---|---|
| 上流 OSS | AtomPub 通信・記事の pull/push | はてな社公式（hatena/hatenablog-workflows + x-motemen/blogsync、いずれも MIT） |
| 自分たちのリポジトリ | workflow ファイルと設定 | 上流を薄く呼び出すだけ |
| 独自拡張 | 品質ゲート・AI Review・ヘッダー画像・Issue 管理 | 自分たちで育てた v2 機能群 |
図にすると、こうなります。
自分たちのリポジトリは 薄い皮 で、実際の同期ロジックは上流が担う。独自拡張は上流とは独立に並走するので、上流の更新と衝突しません。この構造は、仮に自分が抜けても、誰かが引き継げる作りになっています。
執筆から公開までのフローを整理する
新しいワークフローでは、執筆から公開までの流れが 5 つのフェーズに整理されました。
フェーズ 1 — 下書きを作成する
2 通りの作り方があります。
オーナー投稿（自分のアカウントで書く場合）
GitHub Actions の画面で create draft workflow を手動実行すると、はてなブログ側に下書きが作られ、同時にリポジトリに Pull Request が自動で立ちます。PR には draft_entries/{slug}.md というファイルが含まれていて、これを編集していく形になります。
メンバー投稿（個人のアカウントで投稿したい場合）
はてなブログの Web 編集画面で先に下書きを作り、Actions の pull draft from hatenablog を手動実行すると、その下書きがリポジトリに取り込まれて PR が立ちます。
フェーズ 2 — PR 上で記事を育てる
ここが今回の変化で一番大きいところです。
draft_entries/{slug}.md を PR 上で編集していきます。push するたびに はてなブログ側の下書きも自動で同期 されます。つまり、GitHub で編集した内容が即座にはてなブログのプレビューにも反映されます。
PR 上では Slack でレビューを依頼したり、GitHub Copilot の Agent Review による AI チェックを受けたりします。記事の品質を 仕組みで担保 する工程を、通常のエンジニアリングと同じ感覚で組み立てられるようになりました。
フェーズ 3 — 公開する
PR 上の記事ファイル冒頭のメタ情報にある Draft: true の行を削除して、PR を main ブランチにマージします。それだけです。
マージをトリガーに push-when-publishing-from-draft workflow が自動で走り、はてなブログ側で記事が公開され、ファイルはリポジトリ内で draft_entries/ から entries/ へ自動で移動します。
フェーズ 4 — 公開済み記事を編集する
既に公開した記事を修正したくなったら、entries/{YYYY-MM-DD}-{slug}.md を直接編集して PR を立て、マージするだけです。はてなブログ側にも自動で反映されます。
フェーズ 5 — 差分が発生した時の同期
はてなブログの Web 編集画面で直接修正してしまったなど、リポジトリと本体で差分が発生した場合は、Actions の pull from hatenablog を手動実行します。自動で PR が作成されるので、マージすればリポジトリ側が最新になります。
ディレクトリ構造
実際のディレクトリ構造は、次のようになりました。
あなたのリポジトリ/ ├── entries/ (公開済み記事) │ ├── 2026-04-18-claude-design-mcp-header.md │ └── assets/ │ └── 2026-04-18-claude-design-mcp-header/ │ ├── header.png │ ├── references.md │ └── diagram1.png ├── draft_entries/ (下書き記事) ├── .github/ │ ├── workflows/ (7 本の reusable workflow) │ ├── PULL_REQUEST_TEMPLATE/ (下書き PR 用テンプレ) │ ├── ISSUE_TEMPLATE/ (ネタ管理用) │ └── instructions/ (Copilot Agent Review ルール) ├── .claude/ │ ├── settings.json │ └── hooks/ (品質ゲート 8 本) ├── .vscode/ │ └── hatenablog.code-snippets (はてな記法スニペット) ├── tools/ │ └── header-generator/ (ヘッダー画像ジェネレーター) ├── blogsync.yaml (blogsync 設定) └── CLAUDE.md
1 記事 1 ファイル。素材は entries/assets/{slug}/ に紐付け。非常にシンプルです。
既存記事の一括移行
ここが一番大掛かりな作業でした。
入社から書き溜めてきた記事は、私独自のディレクトリ構造 articles/{YYYY-MM}/{YYYYMMDD}_{slug}/article.md に保存されていました。これを新しい entries/{YYYY-MM-DD}-{slug}.md 形式に一括で変換する必要があります。
Python で変換スクリプトを書き、以下の処理を自動化しました。
- 本文冒頭の
#見出し、または冒頭の画像の alt 属性からタイトルを抽出 - 記事のメタ情報（タイトル・公開日・下書きフラグ）を自動で付与
- 本文内の相対画像パスを
assets/{slug}/基準に書き換え - header.png や references.md、図表画像などを
assets/配下に整理
リポジトリ内に蓄積されていた 40 件超の記事フォルダを、--dry-run で事前確認してから一括変換しました。本文 (article.md) が揃っていた記事の変換が一気に完了し、これだけの数を手作業でやっていたら1日では終わらない作業が、10 分で終わりました。
企業ブログだからこそ、仕組み化の価値が違う
ここまで読んで、「個人ブログでここまでやる必要あるの?」と感じる方もいるかもしれません。その通りです。個人ブログなら、好きに書けばいい。
しかし企業ブログは違います。理由は次の3つです。
1. 組織ガバナンスに自然に準拠できる
APC では、社長室 広報グループが発行している「AIを活用した社外向け発信ガイドライン」があります。これに加えて、情報システム部・品質保証部が発行する生成AIハンドブック、AIサービスガイドライン、データ蓄積指針があります。
PR 上で AI レビューと品質ゲートを通す仕組みがあると、これらのガイドラインに 自然に準拠 できます。「ガイドラインを読んで守る」から「ガイドラインが仕組みに組み込まれている」への移行です。誰が、いつ、何を書き、誰がレビューしたかが PR と GitHub のログに残るので、透明性も同時に確保されます。
2. 継承性が保証される
誰がこのワークフローを使っても同じやり方で動けます。READMEに書かれた手順を読めば、次の書き手が運用を引き継げます。人に依存しない設計が、組織として発信し続けるために必須です。
3. 炎上リスクが仕組みで下がる
レビューが人間の善意ではなく仕組みに組み込まれている以上、「確認が抜けた」事故が起きにくい構造になります。これは単なる効率化ではなく、リスク管理 の話です。
エンジニアの矜持とは何か
この実装を終えたとき、自分の中で一つの答えが固まりました。
エンジニアの矜持とは、自分のやり方を仕組みで示すこと だと思っています。
手作業で一本一本の記事の品質を保てる書き手がいれば、私はその腕に敬意を払います。ただし自分自身は、誤字チェックや画像配置、はてなとの同期といった繰り返し発生する機械的な作業を、毎回手作業のまま消耗し続ける道を取りませんでした。こうした作業は GitHub Actions や hooks で自動化する。そのぶん、主張の整理や一次情報の検証といった人間の判断が必要な部分に時間を使う。これが私の選ぶ矜持の形です。
AI を活用することも、この考え方の一部です。AI の出力には必ずハルシネーション (事実と異なる生成) のリスクがあり、最終的な正確性の責任を負うのは読者に向けて発信する書き手自身です。だから AI は書く速度を上げるための加速ツールとして使い、何を主張するか、どの情報を信頼するかといった判断は人間側に残す。記事の構成や表現の整理は AI に任せつつ、主張の筋と責任は書き手が持つ。このバランスが崩れた瞬間に、ブログは読者にとって価値のないものになってしまいます。
迷いが消えた日
実装を終えて、README に Mermaid 図付きの設計書を書き上げた瞬間、自分の中で迷いが消えました。
迷いというのは、「手作り派と仕組み化派のどちらが正しいのか、自分の進む道は合っているのか」という揺らぎのことです。この揺らぎが消えた理由は、私が二つの道はどちらも読者に価値を届けるという同じゴールに向かっていると整理できたからです。
ゴールが同じである以上、手段としての手作り・仕組み化のどちらが上か下かという比較そのものが意味を持ちません。手作業で記事の手触りを作る書き手の道も、GitHub Actions や hooks で本質ではない作業を削る書き手の道も、読者に価値を届けるための別々の経路です。つまり、どちらも道なのです。
そうであれば、自分は自分に合う道を選んで着実に進めばよく、他の道を歩む人にそれをやめろと言う必要はありません。ただし、組織として発信する以上は、自分の進んだ道を 外から見えるようにする ことが書き手の責任だと考えています。なぜなら、後続の書き手が同じ道を再現できる形を残さない限り、個人の実践は組織の資産にならないからです。だからこの記事を書きました。
最後に
今回ベースとして取り込んだのは、はてな社公式の Hatena-Blog-Workflows-Boilerplate です。MIT ライセンスで誰でも利用でき、企業ブログの基本的な投稿フローを reusable workflow として整理してくれています。これをそのまま使うだけでも、Web 編集画面に手作業で貼り付ける運用からは大きく前進できます。
そのうえで自分たちは、独自実装として次のような層を上に重ねました。
- ヘッダー画像ジェネレーター（1200×630 の OGP 画像をテーマ・アイコン・バリエーション指定で生成。Web GUI / CLI / MCP 経由で呼び出せる）
- 品質ゲートの hooks 群（誤字検出、太字とカギ括弧の併用検知、Qiita 記法の
$未エスケープ警告、フッターテンプレートの配置確認など） - GitHub Copilot の Agent Review 用 instructions（記事パターンの分類、文末整形、組織ガバナンス遵守の観点をルール化）
- ネタ管理用の GitHub Issue テンプレートと Projects V2 の連動（タネ → 下準備中 → 執筆中 → レビュー中 → 公開済み のステータス管理）
これらは「はてな公式準拠の薄い皮」と独立して存在するので、上流の Boilerplate が更新されても衝突せず、Renovate でそのまま追従できます。標準に乗りつつ、自分たちの矜持を仕組みとして外側に置く。これが選んだ道の具体的な形です。
興味を持っていただいた方は、まずは公式 Boilerplate を Use this template で試してみてください。そして、もし「手作りの方が自分には合う」と感じたら、それも一つの道です。どちらを選んでも、続けられる仕組みを自分で設計できる人が強いと思っています。
参考
ACS 事業部のご紹介
私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering ＋ AI の推進・内製化を支援しています。
www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。
一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。
※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です
