作業ログからブログネタを掘り出す5基準――AI作業者のコンテンツ採掘術

「今日も作業したのに、ブログに書くことが見つからない」と感じる日はないだろうか。

セッションを重ねるほど試行錯誤や発見は増えるはずなのに、「これは記事にならない」と判断して流してしまう。その積み重ねが「書けない人」を作る。

問題は素材の不足ではなく、何がネタになるかの判断基準がないことだ。

今回紹介するのは、作業ログからブログネタを体系的に掘り出す「5基準テーブル」と、それを日常的に回す仕組みの設計だ。AIツールを使っているかどうかにかかわらず、「作業した日の記録」が手元にある人なら転用できる。

きっかけ：「今日やったこと整理して」から始まった

ある日、組織のメンテナンス作業が一段落した後、ユーザーから一言が来た。

「今日の組織改善についてやったことを整理。私の指示と、問題点、対策、CEOから見た反省点など記載し、Blog元ネタに」

「作業記録をまとめるだけ」のつもりで整理し始めたら、取り出せた素材は予想外に多かった。

CEOエージェントが自分で実装してしまうという「矛盾した失敗」
「コミットは秘書エージェントにやらせたら？」というユーザー発の意外な解決策
権限不整合8件の発見、指示書が160行から32行へのスリム化という数字

振り返ってみると、記事として成立する素材が一日の作業のなかにすでにあった。「書くことがない」ではなく「まだ掘っていなかった」だけだった。

なお、この記事で紹介する仕組みはマルチエージェント構成（秘書エージェント・CEOエージェント等）を前提としている。1エージェント構成でも5基準テーブルやフロー設計は転用できる。

5つの判断基準：「何がネタになるか」を言語化する

素材が出てきたのはよかったが、次の問題が出た。「毎回これを手動でやるのか？」という話だ。

ユーザーから問いが来た。

「一日のセッションの内容からネタになりそうなことを探してネタ帳を作る。手順書うまくつくれるかな？」

「何がネタになるか」は感覚的な判断だ。手順書に落とせるのか。

落とせた。今日の実績から帰納的に抽出すると、以下の5基準になった。

基準	内容	例
失敗・矛盾・やり直し	ルールを作った本人がルールを破った	CEOが自分で実装してしまった
意外な解・ユーザーの発想	エージェントが思いつかなかった解	「コミットは秘書にやらせたら？」
数字で語れる発見	Before/Afterが明確に示せる	160行→32行のスリム化
構造・設計の変化	新しいフォルダ・ルール・ワークフロー	playbooks/ の新設
再利用可能なパターン	他のプロジェクトでも使える処方箋	「指示書の賞味期限管理」

1つでも該当すればネタ候補。逆に「単純な作業記録」「プロジェクト固有すぎる話」「既出ネタとの重複」は除外する。

この基準があれば、「何となく面白かった気がする」という感覚を「どの基準に当てはまるか」に変換できる。完全に自動化できるわけではないが、「何も拾えない」は防げる。

実際にこの仕組みで日常のブログ更新素材が電子書籍の材料になった実例は「9体のAIエージェントと電子書籍を2日で作った話」で紹介しています。

パイプラインの設計：秘書が素材を集め、CEOが評価する

基準が決まれば、あとは手順に落とすだけだ。フローはシンプルに3ステップにした。

ステップ1: 素材収集（secretary エージェント）
  - git log --since="midnight" --oneline（当日のコミット）
  - logs/ 配下の当日ログ・引き継ぎ
  - ops/ 配下の当日作成された指示書
  - content/reports/ 配下の当日調査レポート

ステップ2: 5基準での評価（CEO）
  - 各素材を5基準に照らし合わせ
  - 「どの基準に該当するか」を付記

ステップ3: ネタ帳作成または既存ネタ帳への追記
  - 新テーマ → 新規ネタ帳作成
  - 既存テーマへの追加事例 → 既存ネタ帳に追記

素材収集を秘書エージェントに委ねることで、CEOは「評価だけ」に集中できる。ログを掘り起こす作業がボトルネックになっていたが、これで機械的に処理できるようになった。

この手順書は ops/playbooks/mining/session-idea-mining.md に保存してある（実測: 107行）。

secretary/CEOエージェントの役割分担の全体像は「SE歴26年、初めての部下はAIだった」で詳しく解説しています。

初回実行の結果：手順書を作った日に手順書を回した

手順書が完成した日の夕方、即日実行してみた。結果として、漏れていたネタ候補が3件見つかった。

棚卸し手順書・ネタ発掘手順書を作ったこと自体（構造変化 + 再利用パターン）
秘書の権限不足で作業が止まった→即修正のサイクル（失敗 + 再利用パターン）
「手順書にできるか？」→判断基準の言語化という発想（意外な解 + 再利用パターン）

そして3件目は、このネタ帳そのものになった。

「手順書を作る→手順書を実行する→手順書の実行自体がネタになる→そのネタを記事にする」という再帰的な構造だ。手順書を作った日の素材で手順書の有効性を検証できた。

maturity：「このネタ帳はまだ寝かせる」を明示する

初回実行後にユーザーから方針が出た。

「同様の事例がたまったら追記」

そこで次の問いが来た。

「ネタ帳のステータスとして、内容が薄いとか十分たまったとか持っておけるかな」

1回の事例だけではネタ帳として薄い。事例が積み上がることで記事の説得力が増す。しかし「薄い」「十分」の判断が感覚的では、いつ記事化に動くか分からない。

そこでネタ帳に maturity フィールドを追加した。

thin — 事例が足りない。追記待ち
ready — 事例が十分。記事化着手可能

フロントマターの state（draft / ready）とは別軸だ。記事の制作進捗ではなく、素材の充実度を管理する。これにより「このネタ帳はまだ寝かせておく」「これはもう書ける」の判断が明示的になった。

棚卸しとの両輪：溜まったネタ帳を管理する仕組み

ネタを掘る仕組みができると、次の問題が見えてくる。「溜まったネタ帳をどう管理するか」だ。

同じセッションで、棚卸しの手順書も作った。現時点で content/writing/netacho/ には69件のネタ帳がある（実測）。放置すると「あのネタ、どこまで進んでたっけ」が増える。

棚卸しの手順は ops/playbooks/mining/netacho-inventory.md にある。フローは:

content/writing/netacho/ 全件の maturity と state を確認
記事化状況を「公開済み」「記事あり（未公開）」「未着手」「ネタリスト」の4分類で整理
未着手リストから優先度付けしてInboxにタスク追加

掘る仕組みと管理する仕組みが両輪で回る。ネタが溜まるだけで記事にならなければ意味がない。逆に記事が足りない状態でも困る。この2つのサイクルが噛み合うことで、コンテンツ制作が「考えてから書く」ではなく「書けるものから書く」スタイルに変わる。

ネタを採掘した後の記事状態管理システムは「Claude Code でブログ記事を frontmatter で状態管理する仕組みを作った」で紹介しています。採掘と管理の両輪が揃います。

実際のところ、この仕組みを入れる前は「何を書こう」という問いから記事制作が始まっていた。今は「今日の素材で何が書けるか」という問いから始まる。

作業ログが残る状態さえ作れば、コンテンツの原料が溜まっていく。

作業ログからネタを掘り出せるようになると、次の問いが出てくる——では、そのマルチエージェントチーム自体はどうやって組み立てるのか。

私はこの仕組みを動かすまでの試行錯誤を一冊にまとめた。Vol.1ではClaude Codeのエージェント設計と役割分担を、Vol.3ではブログ執筆・記事公開の自動化までを体系化している。序章・第1部は無料で読める。

コードを書けない私がClaude Codeで「AIチーム」を作るまで（Vol.1）（序章・第1部無料）
コードを書けない私がClaude Codeで「書き続けるまで」（Vol.3）（序章無料）

参考リンク

この記事で紹介したマルチエージェント構成の背景は以下を参照してほしい。

Claude Code を書籍で体系的に学ぶなら、以下が参考になる。

Claude CodeによるAI駆動開発入門（平川知秀著）

実践Claude Code入門——現場で活用するためのAIコーディングの思考法（西見公宏・吉田真吾・大嶋勇樹著）

2026-04-24 執筆

コードを書かないSE日誌

SE歴26年。コードを書かずにClaude Codeで8体のAIエージェントチームを動かしています。AIエージェント・自動化・GTDの実験日誌。