この記事の実施記録（2026年8月3日〜8月6日）: 「これを仕事にできないかなぁ」というキャリアについての漠然とした一言から始まった1時間ほどの壁打ちが、同じセッション内でresearcher（調査担当のAIエージェント）による収益棚卸しを経て、GitHub Issue 3件という「検証可能な設計問題」に変換された。3日後の2026年8月6日にこの3件の実行内訳を追跡した結果、2件は完了（うち1件は別のプロジェクトで2.5ヶ月続いていた停滞の解消につながった）、1件は着手前に「いつかやる(someday)」へ棚上げされたままだった。
「本業のやる気がなかなか出ないけど、claude code使って作業しているのは楽しくて、どんどん作業がしたくなる。これを仕事にできないかなぁ」
2026年8月3日、私はClaude Codeにこう漏らした。誰でも一度は思ったことがある種類の願望だと思う。以前の記事では、この「楽しい」という感覚の正体を実測データで分解し、「速いのは問題解決ではなく、委任1往復のテンポだった」という結論に至った経緯を書いた（Claude Codeで動かすAIエージェント組織はなぜ楽しいのか）。今回書くのは、同じセッションの中で、この一言がどうやって「妄想」のままでは終わらなかったのか、という記録だ。
Claude Codeとの壁打ちは、気づいて満足すると止まってしまう
AIとの壁打ちで悩みが整理された、という話はよく見かける。それ自体は価値がある。ただ私自身、何度も経験してきたのは、気づきを得たところで満足してしまい、翌週には日常に戻っている、というパターンだった。「これを仕事にできないか」も、その場で熱を持って語っても、具体的な次の一歩に落ちなければ、また同じ場所に戻ってくるだけの妄想で終わる。今回のセッションが違ったのは、対話が「気づき」に到達したあと、そこで会話が終わらなかった点にある。
Claude Codeで動かしている、複数のAIが並行して動く組織
私はClaude Code上でAIエージェント組織を運用している。COO（指示役を担うオーケストレーター、私が付けた呼び名で公式用語ではない）が相談を受け、必要に応じてresearcher（調査・数字の裏取り担当）やwriter（執筆担当）、secretary（タスクの仕分け・優先順位づけ担当）といった役割ごとのAIに作業を振り分ける構成だ。この日のキャリア相談中も、対話と並行してresearcherが動いていた。
この組織は今回の1時間で組み上がったものではない。運用開始は2026年4月、前作で実測した稼働日数は125日(同記事執筆時点)。判断ルールを文書化したPlaybookやタスク管理の仕組みを4ヶ月かけて積み上げた基盤があったからこそ、この1時間が成立している。ゼロから同じことをやるなら、その分の助走が要る。
「妄想」が「数字」に変わるまで
まずCOOが、私が既に持っている資産（公開済み記事141本〈下書きを含む記事ファイル162本中、前作で実測した値〉・Zenn Book全6冊）を並べ、「ゼロからの妄想ではなく、すでに足場がある」と前提を組み直した。そこから私は「楽しい理由」を自己分析し、「問題提起から解決までが速い」「タスク管理にストレスがない」「一人で進められて割り込みがない」の3点に言語化した。これは前作でそれぞれ「短いループ」「低摩擦」「割り込みなし」と呼び直したものと同じだ(詳しい検証は前作参照)。「低摩擦」とは、やりたいことに着手するまでの手間や待ち時間が少ない状態を指す。
言語化しただけでは、まだ「気持ちいい実感」の域を出ない。ここでresearcherが同じセッション内で動き、「発信を収益の柱に育てる」という方向性を裏取りした。棚卸し時点の概算では3.5ヶ月累計で3,000円台という推定だったが、この数字は後述するIssue化を経て実測され、累計6部・確定額¥4,339へと精緻化された。
この数字だけを見ると厳しい。月3万円・月10万円を「収益の柱」の水準と置いた場合、既存の単価構造（900円本の著者取り分は約¥781）だけで到達しようとすると、これまでの最良月実績（2026年5月の3部）の約13倍〜44倍の販売ペースが必要という試算になる。誤解のないように書いておくと、この数字は「発信を副業の柱にする」という私個人の仮説を検証した結果であり、AIエージェント組織そのものの費用対効果を示すものではない。
大事なのは、この厳しい数字を見て終わりにしなかったことだ。「じゃあ無理だ」と結論を出す代わりに、次にやったのは月次の収益記録を再開し、現在地を定点観測できる状態に戻すことだった。妄想のままで終わらなかったのは、対話とは別のエージェントが同じセッション内で数字を持ってきたからだ。
Claude Codeとの対話で気づく、から組織が検証するへ
この一連の流れから、私が言いたいことは一つに絞られる。対話だけの壁打ちは気づきで終わりやすい。だが役割分担されたエージェント組織を持っていると、壁打ちで出た仮説の裏取りが会話と並行して走り、セッションが終わる頃には「気づき+証拠+次にやるべきこと」が揃っている。この日、最終的に「次にやるべきこと」はGitHub Issue3件という形に落ちた——こはくのおと(私が運営するもう一つのブログ)の再開、収益記録の月次トラッキング再開、Book経由の効果測定、の3件だ。
3日後に追跡してわかったこと——3件中2件は動き、1件は棚上げされた
Issue化は実行を保証しない。3日後の2026年8月6日、私はこの3件がどこまで進んだかをGitHub Issueの記録を直接確認して追跡した。結果は次の通りだった。
| Issue | 状態 | 結果 |
|---|---|---|
| #1663 こはくのおと再開 | 完了(CLOSED) | 停滞解消。別軸の改修にもつながった |
| #1664 収益記録トラッキング再開 | 完了(CLOSED) | 作成した同じ日に完了 |
| #1665 Book CTA効果測定 | 未着手(OPEN) | 「すぐ着手(next)」から「いつかやる(someday)」へ棚上げ |
#1663は、当初「こはくのおとの執筆ハードルを下げる仕組みを検討する」という設計課題だった。ドラフト記事自体は5月時点で品質ゲートを通過していたのに、公開先が決まらないまま2.5ヶ月間放置されていた。Issue化をきっかけに、翌8月4日深夜、停滞していた記事が公開され(Issue上の記録では「無人実行」、つまり設計担当(architect)から実装担当(skill-dev)へのエージェント連鎖を、私が1ステップずつ承認することなく走らせた、とある)、同時に公開まわりの仕組み(執筆用スキル・品質ゲート・公開手順書)も改修された。翌朝、私自身が操作して動作確認をし、正常動作を確かめている。細かな残タスク(通しフローの検証など)はクローズ後も記録に残っており、「全部完璧に終わった」とは書かない。
#1664は「Zennのダッシュボードを直接見に行く」という地味な単純作業に近いIssueだったが、作成当日に完了し、前述の「累計6部・¥4,339」を確定させた。副次的に、過去のネタ帳に残っていた記録の誤り(販売部数の記憶違い、初売上の帰属先の勘違い)も2件見つかり、訂正された。数字を実測しに行くという地味な作業が、記憶の誤りを正す副産物を生んだ。
#1665は、作成から約7時間後に分類が「すぐ着手する(next)」から「いつかやる(someday)」へ変わり、そのまま着手されていない。降格の理由はIssue上に記録がなかった。ただ、この直後の時間帯にsecretary(GTDのタスク仕分け担当)がタスクリストを大量整理していた記録があり、その時の判断基準(「既存の不具合対処」を優先し「新規の計測・拡張系」は後回しにする)に照らすと、#1665が対象に含まれていても筋は通る。ただし直接の証拠はなく、あくまで状況からの推定にとどまる。
3件中1件が動かなかったことを、私はむしろ肯定的に受け止めている
正直に書くと、#1665が棚上げされたと知ったとき、最初は「なぜ後回しにされたのか」と気になった。だが振り返ると、これは「意図に反して勝手に落とされた」話ではなく、私が普段から明文化してきたタスクの優先順位ルールが、目の届かないところでも一貫して働いた結果だと考えている。「短いループ・低摩擦・割り込みなし」という労働条件は、これまでタスクを実行するスピードの話として語ってきたが、今回わかったのは、その低摩擦が実行のレイヤーだけでなく、何を後回しにするかという優先順位の判断のレイヤーにまで及んでいるということだ。地味だが認知的に負荷の高いその判断まで、安心して任せられている――そう感じている。これは、経営やマネジメントで言う「任せられる相手がいるかどうか」の話にも、どこかで通じているのかもしれない。
あなたの「これを仕事にできないか」は、まだ裏取りされていないか
ここまで読んで、自分にも似たような妄想があると思った人に、一つだけ聞いてみたい。その妄想は、まだ裏取りされていない希望的観測のままではないだろうか。そして裏取りされたあと、実行に移せているだろうか。
エージェント組織を持っていなくても、今日からできることはある。壁打ちで何かに気づいたら、その場で「次にとる具体的な行動」をひとつだけ書き出し、後から見返せる場所に置いておくことだ。GitHubのIssueでも、メモアプリのタスクリストでも構わない。大事なのは棚上げすら記録に残すことで、3日後や1週間後の自分が「進んだか、止まったか」を確認できる状態にしておくことだと思う。今日の気づきを、そういう形にひとつだけ落としてみてほしい。
私の場合、3件中2件は動き、1件は動かなかった。全部うまくいった話として書きたい誘惑もあったが、動かなかった1件を隠さずに書くほうが記事全体の信頼性にとって大事だと思った。妄想を検証可能な設計問題に変えることと、全部を実行しきることは別の話であり、後者ができていなくても、前者ができた時点で十分に前進している。
3ヶ月以上ほぼ動かなかったsecretaryが、一貫した判断基準を守り続けていた話は、このシリーズの1本目に書いた。壁打ちの妄想が数字で裏取りされ、Issue化され、棚上げの判断まで組織に委ねられていく――今回のこの話は、結局その1本目の主張(実質、私は何もしていない)を、私自身の体験として裏付ける形になった。
私は今夜も、Claude Codeを開いてまた新しい妄想を話しかけると思う。それが検証に値するかどうかは、話しかけてみるまでわからない。
参考文献
- デビッド・アレン著『新装版 はじめてのGTD ストレスフリーの整理術』（二見書房）——あいまいな気がかりを「次にとるべき具体的な行動」に変換する、という発想の原点はここにある
本記事は Claude Code（AIエージェント）との協働で執筆しています。データの実測・確認は本文に記載した手順で行い、文章化に AI の支援を用いています。
関連記事
- 実質、私は何もしていない — Claude CodeにGTDを組み込んだら、優秀なのはAIエージェントではなく「仕組み」だった
- Claude Codeで動かすAIエージェント組織はなぜ楽しいのか――速いのは問題解決ではなく「1往復」だった
この記事は はてなブログ からのクロスポストです。