こんにちは。ACS事業部の越川です。
先日、社内の週次定例で「技術ブログを続けられる仕組みで書く」というテーマで講習会を行いました。
技術ブログを書きたいけど続かない。ネタが出てこない。レビューが怖い。——エンジニアなら一度は感じたことがある悩みだと思います。本記事では、これらの悩みを仕組みで解消するアプローチと、講習会で得られた気づきをまとめます。
- なぜ講習会をやったのか
- 共有した仕組みの全体像
- ネタに困らない仕組み
- 手軽に書ける ≠ 手抜き — 質を担保する仕組み
- AIとの協働における役割分担
- 参加者からのフィードバックと気づき
- まとめ — 仕組みで始めて、対話で育てる
- お知らせ
なぜ講習会をやったのか
入社2ヶ月弱で10本の記事を公開しました（APC技術ブログ8本 + Qiita 2本）。Xで外部エンジニアから技術的引用をいただき、社内の戦略資料にも公開から数時間以内で引用されました。
社内Slackでも「さすがだ」という反応をいただくことがありました。しかし、これは個人の能力ではありません。仕組みがあるから書けているのです。
この仕組みを自分だけで使い続けても意味がない。仕組みを見せて、使いたい人が使えるようにする。それが講習会の目的でした。
この記事を読んでいるあなたも、同じ仕組みを使えます。特別なツールは不要です。
共有した仕組みの全体像
ブログ執筆をGitリポジトリで管理しています。主要なファイルは以下の通りです。
| ファイル | 役割 |
|---|---|
CLAUDE.md |
AIとの合意文書。執筆ルール・コンプライアンスを定義 |
ideas.md |
ネタ帳。ステータス管理付きで「今やるべきこと」が見える |
lessons-learned.md |
フィードバックから得た学びの蓄積 |
published.md |
公開済み記事のインデックス。「なぜ書いたか」を記録 |
このワークフローのポイントは 加速する構造 です。
- 記事を書いて公開する
- フィードバックを
lessons-learned.mdに記録する - 繰り返すパターンを
CLAUDE.mdのルールに昇格させる - 次の記事がもっと速く書ける
書けば書くほど次の記事が書きやすくなる。この循環が、毎日ブログを書き続けられる理由です。
ネタに困らない仕組み
「何を書けばいいかわからない」はブログ最大の障壁です。私も最初はそうでした。しかし、ネタは「探す」ものではなく「気づく」ものだと考え方を変えてから、ネタが尽きることはなくなりました。
- チャットで話題になった疑問を拾う — エンジニアの生の疑問は、社外の読者にとっても価値がある。あなたのチームで話題になったことは、世の中のエンジニアも同じことを思っている
- 新しい技術を触ったら必ず1本書く — 「触った」は一次情報。他の誰も同じ体験をしていない
- 社内の会議・勉強会がそのままネタになる — 共有会で起きた気づき、振り返りで出た課題、全部記事の素材
- 世の中で話題になっていることを構造で捉える — 感情論で消費せず「なぜこれが話題になるのか」の構造を抽出する。その構造が自分の仕事にも当てはまるなら記事になる
さらに、Gemini Gemで「ネタ探しアシスタント」を構築しました。「今日のトレンドを教えて」と聞くだけで、自社の技術領域に合ったネタが提案されます。
手軽に書ける ≠ 手抜き — 質を担保する仕組み
AIで簡単に書ける時代だからこそ、出す基準が必要です。
質を決めるのは文章力ではなく一次情報があるかどうか。自分で試したか、自分で体験したか、自分の考えが入っているか。「やってみた」だけでは不十分で、「やってみて、何がわかって、誰の役に立つか」まで書くことが求められます。
品質チェックの仕組みとして、Gemini Gemでブログレビュアーも構築しました。下書きを貼り付けるだけで、10点満点のスコアリングと具体的な改善提案が返ってきます。公開前にセルフチェックできるので、レビューへの不安も軽減されます。
「レビューが怖い」という声をよく聞きますが、まずAIにチェックしてもらい、改善してから人に見せる。この順序にするだけで、心理的なハードルは大きく下がります。
AIとの協働における役割分担
AIとの協働では、役割分担が重要です。
| AIが担うこと | 人間が担うこと |
|---|---|
| 文章の構成・下書き・表現の整理 | 一次情報の提供 |
| ネタ候補の提案 | 事実の検証 |
| 品質チェック（スコアリング） | 最終的な発信判断 |
AIに丸投げすると「誰に何を届けたいかわからない記事」になります。一次情報は人間にしか出せません。
講習会では、VS CodeでAIエージェントと対話しながらドラフトを書く実演も行いました。Geminiでも同じことができるので、使い慣れたツールで始められます。ただし、モデルの違いで結果は変わります。うまくいかなければモデルを変えてみるのも一つの手です。
参加者からのフィードバックと気づき
講習会で最も価値があったのは、参加者から返ってきた率直なフィードバックでした。
響いた言葉
- 「昨日の自分に教えるつもりで書く」がわかりやすい — 抽象的に「読者を意識して」と言うより、具体的な対象を示す方が行動に繋がる
- 「一次情報の定義になるほどと思った」 — CLAUDE.mdに書いた定義が、社内の共通言語として機能し始めた
- 「過去のブログが顧客への提供で何度も救われている」 — ブログの価値は公開時点だけではない。将来の自分・チーム・顧客への資産になる
新たな気づきを与えてくれた指摘
- 「AI使用のただし書きは入れた方がいい」 — 世の中の動向として、AI生成コンテンツの透明性が求められ始めている。事業部としてのスタンスを明確にする必要がある
- 「AI検索エンジンがAI生成コンテンツを除外する動きがある」 — SEOの観点からも、一次情報の重要性は増している
- 「ブログはゆるいアウトプット」 — 否定ではなく事実の指摘として受け止めた。ゆるいからこそ障壁が低く、継続でき、力がつく。提案書や仕様書を書く力はブログで鍛えられる
講習会をやって気づいたこと
フィードバックが返ってくる組織だからこそ、講習会に意味があった。
賛同だけでなく、懸念や異なる視点も率直に出てくる。これは押し付けではなく「仕組みを見せて、やるかやらないかは委ねる」というアプローチだったからこそ生まれた対話です。
全員が同じ役割をやる必要はありません。ネタを見つける人、記事を書く人、フィードバックを返す人。それぞれが得意な部分で貢献すればループが回ります。
まとめ — 仕組みで始めて、対話で育てる
| ステップ | 内容 |
|---|---|
| 仕組みを作る | Gitリポジトリで管理。AIとの合意文書で品質を担保 |
| 見せる | リポジトリを公開。強制はしない |
| 使ってもらう | フォークして自分用にカスタマイズ |
| 対話する | フィードバックから新たな気づきが生まれる |
| 育てる | lessons-learned.mdに蓄積。仕組み自体が進化する |
ブログの目的は「対外的な反応をもらえる発信を継続すること」です。続けるには仕組みが要る。意志の力だけでは続きません。
書くことは特別なことではありません。日々の学びの副産物を公開するだけ。昨日の自分に教えるつもりで書いてみてください。
この仕組みは、個人でもチームでも使えます。特別なツールの導入は不要で、GitとAI（GitHub Copilot、Gemini等、使い慣れたもの）があれば今日から始められます。
お知らせ
私の所属する 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 などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。
一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。
