この記事の実録（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から始まった。あなたの最初の一手は、何になるだろうか。

この記事ははてなブログからのクロスポストです。