この記事の実録（2026-05-03 早朝）: 「いい記事を書いているのに読まれない」というユーザーの一言を起点に、AIエージェント組織が「原因特定 → 公開フローの修正 → 運用知識の記録 → 副次バグの発見 → レポート訂正 → 学びの記録 → タスク登録 → 別バグの修正」までを1セッションで連鎖させた記録を、コミットハッシュとIssue番号つきで時系列に追う。早朝のこの一連の流れは8コミット（うち自動コミット2件）、この日全体では65コミット（同2件）。Claude Code でエージェント組織を運用している人が、自分の運用に「発見を完結まで運ぶ仕組み」を組み込むための実例を示す。
なお、この記事には私のエージェント運用で使っている固有の呼称（CEO/COO・writer・researcher など）が登場する。これらは「全体を統括する司令役」「記事を書く役」「調査する役」といった役割分担の私的な名前なので、読者は自分の環境のエージェント名に読み替えてほしい。
「1日で完結する」とはどういうことか
まず驚いたことから書く。
ある朝、私が放った何気ない一言が、その日のうちに /todo（私が使っているタスク管理コマンド）のバグ修正コミットまでたどり着いた。途中には公開フローの修正、運用知識の記録、別の事故の発見、レポートの訂正が挟まっている。これらがバラバラの作業として散らばるのではなく、1本の連鎖としてつながった。
ここで「自律改善」と呼んでいるのは、人間が何もしないという意味ではない。引き金を引くのは人間で、その後の連鎖をAIエージェント組織が完結させる——この設計を指している。最初の一言は私が言った。だが「PV分析を実行し、原因を特定し、フローを直し、知識を記録し、バグを見つけ、それをタスク化する」までは、私が逐一指示しなくても連鎖した。
以下、この連鎖を10ステップに分けて時系列で追う。各ステップにはコミットハッシュ・Issue番号・実際の発言を添える。すべて私の内部ログ（git履歴・GitHub Issue・記録ファイル）から実測したもので、再構成のための創作はしていない。
Step 1: 発見——「読まれてないね」
すべての起点はこの一言だった。
「我ながらいい記事書いてると思うんだけどなぁ、読まれてないね」（2026-05-03）
私はこのとき、コンテンツ寄りの中長期施策（テーマの独自性を高める、シリーズ化する、など）を提案しようとしていた。「読まれないのは中身の問題だろう」と無意識に決めつけていたわけだ。
ここが最初の分岐点になる。中身の話に進む前に、まずデータを見ることになった。
Step 2: データ取得・原因特定——PV=1、滞在0秒
GA4（Google Analytics 4）のデータを分析した。対象は前日（2026-05-02）に公開した記事。結果は次のとおり。
- PV = 1
- 滞在時間 = 0秒
公開した翌朝で PV が1という数字を見て、続いてこの発言が出た。
「告知してなかったかなぁ」
ここで原因が反転した。中身の問題ではなく、流通がゼロだった。記事を公開しただけで、SNSへの告知をしていなかったのだ。良し悪し以前に、そもそも読者の目に触れる経路が存在していなかった。
「読まれない」と感じたとき、人はつい中身を疑う。だが実際には、書いたものが届く経路を作り忘れているだけ、ということがある。この記事を読んでいるあなたにも、思い当たる節はないだろうか。
（出典: content/reports/research/2026-05-03_hatena-pv-deepdive.md）
Step 3: 修正実施——告知文の作成と投稿
原因がわかれば、まず目の前の穴をふさぐ。X・Threads・Facebook 向けの告知文を作成し、投稿した。投稿の分担はこうなっている。
- Threads: 自動投稿ツール経由でエージェントが投稿
- X / Facebook: 私が手動で投稿
投稿後、確認の発言があった。
「Threads2件投稿されていました」
ここまでは「目の前の1記事の告知漏れを直した」だけだ。多くの場合、作業はここで終わる。だがこのセッションでは、ここから「同じ穴を二度と開けない」フェーズに入った。
Step 4: 構造修正——公開フローそのものを直す
個別対応で終わらせず、公開手順書（Playbook）を書き換えた。
内部の公開フロー手順書 ops/playbooks/article/publish.md を更新（コミット 5675b74、07:21 JST）。主な変更点は次のとおり。
- 公開順序ルールの明文化: はてな公開 → 即時SNS告知 → 24時間後 → Zenn/Qiita へのクロスポスト
- 記事を書く役の手順に追加: X / Threads / Facebook 向けの告知文を作成するステップを明記
- 告知の分担を明記: Threads は自動投稿、X / Facebook は手動投稿
- 自動投稿ツールの制約（Threads と Bluesky には対応するが、X には非対応）を明記
ここが「自律改善」の肝になる部分だ。今回の告知漏れは、手順書に「告知ステップ」が存在しなかったから起きた。だから次回以降の告知漏れを防ぐには、手順書そのものに穴をふさぐ。1回の失敗を、仕組みの更新に変換する——この一手があるかないかで、同じ失敗を繰り返すかどうかが分かれる。
Step 5: 運用知識の記録——memory化（の試み）
続いて、今回わかった運用知識を永続化しようとした。自動投稿ツールの対応範囲（X 非対応など）や、Facebook からの流入が一定割合を占めるという実態を、長期記憶用のファイルに記録する流れだった。
ただし、ここは正直に書いておく。記事執筆時点（2026-06-09）で記録先として想定されていたファイル（reference_blacktwist_scope.md）を確認したところ、現在のmemoryディレクトリに存在しなかった。記録を試みた形跡はあるが、その後の整理で統合されたか、あるいは記録自体が完結しなかった可能性がある。
つまり「すべてのステップが完璧に機能した」わけではない。後述するように、このセッションには別の取り違え事故も含まれている。自律改善ループは万能の魔法ではなく、抜けや訂正を含みながら回る仕組みだ——この点は後の Step 6 でより鮮明になる。
Step 6: 副次バグの発見——「上申直前の一次確認」が働いた
ここがこのセッションで最も象徴的な瞬間だった。
PV分析の追加調査として、別記事（/todo 完全ガイド）の単体PV分析を依頼した。調査役のエージェント（researcher）は GA4 で対象URLをクエリし、計測結果が0件であることを確認した。問題はその次だ。0件という空白を見たエージェントは、「日付が一致する別のURLが、おそらく同じ記事だろう」と推測で穴を埋めてレポートを書いた。
推測の根拠は「記事の作成日と、別URLに含まれる日付が一致している」という1点のみ。一次ソース（実際にそのURLを開いて記事を確認する）での裏取りはしていなかった。
私はこのレポートをユーザーへの報告資料にしようとした、まさにその直前に、自分の運用ルールに従って3つのURLを直接開いて検証した。結果、推測されたURLはまったく別の記事（「9体のAIエージェントと電子書籍を2日で作った話」）のものだったと判明した。
なぜこの検証が習慣として働いたか。前日（2026-05-02）に、別の事故をきっかけに「ユーザーへ報告する直前に、引用元を自分の目で一次確認する」というルールを運用ルールに追加していたからだ。前日に書いたルールが、翌日、別の事故型を捕まえた。
AIは、データに空白があるとき、近くにあるそれらしいデータで埋めようとする傾向がある。この「推測による穴埋め」は、一見もっともらしいレポートになるぶん厄介だ。それを止めたのが、人間の注意力ではなく、前日に明文化した手順だった点に意味がある。
（出典: logs/governance-incidents/2026-05-03_researcher-url-mismatch.md）
Step 7: レポート訂正
取り違えに気づいた以上、誤った前提で書かれたレポートを放置しない。該当レポート content/reports/research/2026-05-03_hatena-pv-deepdive.md に訂正注を追加した（コミット e49aa50、07:31 JST）。
具体的には、誤った推測に基づくセクションの直前に重要訂正の注記を挿入し、「記録としては残すが、結論として参照しない」と明示した。間違いを消すのではなく、間違いだったと分かる形で残す。これも「再発防止のための記録」の一種だ。この地味な訂正作業が、次のステップで「今回の出来事を何に変換できるか」を問う視点を呼び起こす。
Step 8: 学びの記録——ネタ帳化
ここで、今回の一連の出来事を「次に書く記事の素材」として残す作業に入った。私はこれを内部で「ネタ帳」と呼んでいる。記事の種をストックするメモのことだ。
このセッションからは、次の3本のネタ帳が生まれた。
- 告知漏れの発見と「流通ゼロ」問題（pv-1-discovery）
- 運用ルールの進化と、AIの推測の死角（trigger-list-evolution）
- セッション全体を俯瞰した自律改善ループの観察（本記事のもとになったネタ帳）
このセッションからのネタ帳追加は2件のコミットに分かれている。pv-1-discovery（告知漏れの発見）が ff6185b（07:32 JST）で追加され、本記事のもとになった one-session-self-improvement（自律改善ループの観察）は 4f0f0ff7（07:52 JST）で追加された。1つの失敗体験が、再発防止（Step 4）と知識記録（Step 5）だけでなく、公開コンテンツの素材にまで変換されている。今あなたが読んでいるこの記事自体が、その変換の最終生成物だ。
Step 9: タスク化——7日後の効果検証を予約
告知を打った効果は、その場では測れない。数日たってから PV がどう変わったかを見る必要がある。そこで「7日後に効果検証をする」というタスクを /todo に登録した（Issue #1320）。
このタスクは、登録した7日後の2026-05-10に実際に実行され、告知後のPV再分析として**完了済み（CLOSED）**になっている。「あとで確認しよう」という意図が、口約束ではなくタスクとして予約され、期日に実行されたわけだ。発見を「やりっぱなし」にしない仕組みが、ここにも組み込まれている。
Step 10: バグ報告——そして同セッションで修正まで
最後にもう1つ、副産物のバグが見つかった。
このセッション中にタスク登録を繰り返すうち、/todo コマンドの --label オプションを使うと、ラベル文字列がタスクのタイトルに混入する不具合に気づいた。
「ラベル混入何回か起こっているのでISSUEにして」
この一言で、バグを Issue #1321 として登録した。注目すべきは、このIssueが同じ朝のうちに修正コミット 9a42d46（08:10 JST）で閉じられていることだ。発見からタスク化、そして修正までが、ひとつながりの時間の中で完結した。
10ステップを俯瞰する
ここまでを1枚にまとめると、このセッションで連鎖した要素はこうなる。
| Step | やったこと | 残った成果物 |
|---|---|---|
| 1 | 「読まれない」の発見 | （起点の発言） |
| 2 | PV=1・滞在0秒の特定 | 分析レポート |
| 3 | SNS告知の実施 | 投稿済み告知 |
| 4 | 公開フローの修正 | Playbook更新（5675b74） |
| 5 | 運用知識の記録（試み） | ※記録先は現存せず |
| 6 | 推測による取り違えの検知 | 事故記録 |
| 7 | レポートの訂正 | 訂正注（e49aa50） |
| 8 | 学びのネタ帳化 | ネタ帳3本（ff6185b 他） |
| 9 | 効果検証のタスク化 | Issue #1320（CLOSED） |
| 10 | バグ報告と修正 | Issue #1321 / 修正（9a42d46） |
注目してほしいのは、出発点（「読まれない」という主観的な不満）と終着点（コマンドのバグ修正）に、表面的にはまったく関係がないことだ。にもかかわらず、両者は1本の連鎖でつながっている。発見が次の作業を呼び、その作業が別の発見を生む——この連鎖が止まらずに完結まで進んだことが、このセッションの本質だ。
なぜこの連鎖が止まらずに進んだのか
「たまたまうまくいっただけでは？」という疑問はもっともだ。実際、この日の連鎖には抜け（Step 5の記録先消失）も含まれているし、そもそも告知漏れという失敗自体が「いつもうまくいくわけではない」証拠でもある。
それでも連鎖が完結まで進んだ背景には、いくつかの仕組みがあらかじめ存在していた。
-
失敗を記録する場所: 事故やルール失念を書き残す
logs/governance-incidents/があった。だから Step 6 の取り違えも「事故記録」として残せた - 知識を永続化する場所: 運用知識を記録する memory の枠組みがあった（今回は記録先が後に消えたが、記録しようとする動線自体は存在した）
- 手順を直す場所: 公開手順書 Playbook があり、Step 4でそこに穴をふさげた
-
やり残しを予約する場所:
/todoというタスク管理があり、Step 9・Step 10で「あとで確認」「バグ修正」をタスク化できた
つまり、連鎖を完結させたのは天才的なひらめきではなく、「発見の受け皿」がそれぞれ事前に用意されていたことだ。発見が起きるたびに、それを落とし込む先が決まっている。だから連鎖が空中分解せずに、次々と着地していった。
そしてもう1つ。Step 6で前日のルールが翌日に機能したように、これらの受け皿は過去の失敗から1つずつ作られてきた。今回の失敗もまた、新しい受け皿（公開フローの告知ステップ）を1つ増やした。仕組みが失敗を糧に育っていく——この循環があるからこそ、次のセッションの連鎖はもう少し滑らかになる。
自分の運用に組み込むには
この記録から、自分のエージェント運用に持ち帰れる要点を3つに絞る。特別なツールは要らない。Markdownファイルと、タスク管理の仕組みがあれば始められる。
- 発見の受け皿を先に用意する: 事故記録・運用知識・手順書・タスクリストの置き場を決めておく。発見が起きてから置き場を考えると、連鎖はそこで止まる
- 個別対応を仕組みの更新に変換する: 1回の失敗を直すだけでなく、「同じ失敗を防ぐ手順」を手順書に書き足す。Step 4がこれにあたる
- 報告の直前に一次確認するルールを持つ: AIは空白を推測で埋める。だから人間に届く直前に「引用元を自分の目で確認する」関門を1つ置く。Step 6を救ったのはこれだった
これらはどれも、過去の失敗から1つずつ作られたものだ。最初から完璧な仕組みを作る必要はない。失敗するたびに受け皿を1つ増やしていけば、ある日、今回のような連鎖が自然に完結するようになる。
自律改善ループは失敗を糧に育つ
このセッションが見せたのは、「AIが勝手に全部やってくれる」という話ではない。引き金を引いたのは私の何気ない一言で、途中には記録漏れも推測の取り違えもあった。
それでも、「読まれない」という主観的な不満が、データ分析・フロー修正・知識記録・バグ修正へと連鎖し、1セッションで完結した。これを可能にしたのは、発見を受け止める器が、失敗のたびに少しずつ用意されてきたことだ。
次にあなたが「うまくいかない」と感じたとき、その不満をどこに落とし込むかを決めておく——それが、自律的に改善が回り始める最初の一手になる。私の場合、その最初の一手は「告知ステップを手順書に1行書き足す」ことだった。最初の受け皿は1個でいい。私が最初に作ったPlaybookも、3行のMarkdownから始まった。あなたの最初の一手は、何になるだろうか。
この記事は はてなブログ からのクロスポストです。