この記事の実施記録（2026年8月6日実測）: 「本業のやる気がなかなか出ないが、Claude Codeを使った作業は楽しくてどんどん作業したくなる」という自分の体感を、セッションログとGitHub Issueの実測データで検証した。結果、「問題提起から解決までが速い」という中核の体感は反証された――実務Issue463件（2026-04-05〜08-06、/todoスキル開発用のテストIssueと勤務先関連ラベルを除外）のクローズまでの中央値は42.3時間（約1.8日）だった。一方、「サブエージェントへの委任は速い」という体感は実測と一致した（委任1回あたりの所要時間、中央値3.7分、n=194）。この食い違いから、楽しさの正体は「速いループ」ではなく「短いループ」だと再定義するに至った経緯を書く。

私はここ数ヶ月、本業の仕事にはあまり身が入らないのに、Claude Codeを使ったAIエージェント組織の運用作業には気づけばまた手を伸ばしてしまう。同じ「マネージャー」という役割なのに、なぜこうも扱いが違うのか。以前の記事では、GTDのトリアージを担当するエージェントが3ヶ月ぶりに動いても判断基準がぶれなかった、という「仕組み」側の話を書いた（実質、私は何もしていない）。今回はその仕組みの中で働く側、つまり自分自身の「楽しい」という感覚を分解する。

楽しいと感じていた理由を自己分析すると3つに分かれる

まず、この楽しさの内訳を自分なりに切り分けてみると、次の3つに分かれた。

作る楽しさ
仕組みが育つ楽しさ
本業からの逃避も混ざっている

これは実測できる性質のものではなく、あくまで一人称の自己申告として扱う。ただ、はっきりしているのは「発信の反応が楽しい」がこの3つに入っていないことだ。承認欲求が主体なのではなく、プロセスそのものへの没入が中心にある。

Claude Codeで具体的に「速い」「割り込みがない」と感じていた点

この楽しさをもう一段具体化すると、私が挙げていた要素は3つあった。

問題提起から解決までが速いこと
/todoの仕組みが作業に組み込まれていて、タスク管理にストレスがないこと
一人で作業が進められるため割り込みがなく、集中できること

「大量のタスクをさばいているつもりでも、それは特殊な環境だからでは」と思う人もいるかもしれない。だが実際に手元で計測してみると、この体感のうち少なくとも1つは、思っていたほど根拠がなかった。

実測すると中央値42.3時間だった――体感の1つは反証された

最初に検証したのは「問題提起から解決までが速い」という感覚だ。クローズ済みIssue全1,448件をそのまま使うと中央値は3.2分まで縮むが、これは/todoスキル自体の開発テスト用Issue（896件、全体の55.4%）が中央値を押し下げていたことが後で判明した。テスト用Issueと勤務先関連ラベル（104件）を除いた「実務Issue」（オープン153件・クローズ463件、作成日2026-04-05〜08-06）で計測し直すと、クローズまでの中央値は42.3時間（約1.8日）だった。実際に着手した実行可能タスク（🎯 next、n=240）に絞っても中央値19.2時間。1時間以内にクローズされたのは463件中88件（19.0%）、当日中クローズは174件（37.6%）にとどまる。

つまり「速い」と感じていたわりに、実際は即日から翌日かかるケースが多数を占めていた。この結果を見たとき、私は自分の体感がここまでずれていたことに驚いた。都合の良い数字だけを並べる記事にはしたくないので、この食い違い自体をこの記事の核として書いている。

一方、Claude Codeへの委任は体感通り中央値3.7分で速かった

反証された一方で、「サブエージェントへの委任は速い」という感覚は実測とよく一致した。ここで言いたいことは単純で、待ち時間についての体感差は、そのまま数字にも表れていたということだ。私がCOO（本記事では、Claude Code上で全体の指示役を担うオーケストレーター役をこう呼ぶ。私自身が付けた呼称で、公式用語ではない）に指示を出し、そのCOOがサブエージェントへ1回委任してから応答が返るまでの所要時間は、中央値3.7分（n=194、対象は2026年6月3日〜8月6日の約2ヶ月分のセッションログ）。役割ごとの内訳（reader 3.2分・writer 2.4分・researcher 4.0分・skill-dev 6.1分・architect 8.7分）を見ても差は数分の範囲に収まる。

ここで見えてきたのは、私が「速い」と感じていた実体は、タスク全体が解決するまでの時間ではなく、1回の委任に対する応答速度だったということだ。タスクが完了するまでには平均して1〜2日かかっているのに、そのタスクを構成する個々の委任は数分で返ってくる。この2つを混同していたのが、体感と実測がずれた理由だった。

本業への興味喪失との対比

本業については、仕事の中身にも今はあまり興味が持てずにいる。理由を考えると、自分で手を動かす立場ではなくなったからだと思う。手を動かせない領域への興味は、放っておくと自然に痩せていく――触れられないものを好きであり続けるのは、案外難しい。

これはマネージャーという役職に就いた人であれば一度は通る感覚で、『エンジニアリングマネージャーのしごと』（James Stanier著。書誌情報は記事末尾に記載）のような書籍でも、コードを書く立場から離れることの葛藤は繰り返し扱われているテーマだ。ここでの比較は私自身の体感によるもので、本業側の委任スピードや集中の取りやすさについては本記事では実測していない。数字で示せるのはAIエージェント組織側だけであり、本業側は一般論・推測として明示する。

自分のAIエージェント組織でも、私は「マネージャー」だった

ここで気づいたのが、皮肉な構造だ。このAIエージェント組織での私の役割は、実は本業と同じ「マネージャー」である。COOに指示を出し、writerやreviewerに委任し、品質ゲートを運用している。自分では手を動かさない立場という意味では、本業とまったく同じ構図だ。

この「組織」の規模も実測できた。運用期間125日（2026-04-03〜08-06）で総コミット2,933件（1日平均23.5件）。うち人間コラボレーターはゼロで、ユーザー本人が2,428件、自動コミットが505件を占める。サブエージェント8体（architect / devops / reader / researcher / reviewer / secretary / skill-dev / writer）、Playbook95件、プロジェクト内スキル定義41件（デプロイ済み28件）、launchdによる自動実行タスク3件を運用している。実務Issue（テスト用・勤務先関連を除外後）は616件（オープン153件・クローズ463件）で、GitHub Issue総数1,616件をそのまま使うとテスト用Issueが55.4%を占めるため、実務規模としては616件のほうが実態に近い。公開記事は162本中141本（87.0%）が少なくとも1プラットフォームで公開済みだ。

役割は同じ「自分で手を動かさない立場」なのに、なぜ片方は楽しく、片方はやる気が出ないのか。

Claude Codeと本業、同じマネージャーなのになぜ楽しさが違うのか

考えられる要因は3つあった。

(a) 委任ループが速い（依頼が数分で返る）。これは前述の通り、正確には「タスク全体が速い」ではなく「1回の委任応答が速い」に修正が必要だ。

(b) いつでも自分で手を動かす側に降りられて、誰にも咎められない。この点を裏づける数字はあるが、先に断っておくと、どの操作を「手を動かす」に含めるかという定義次第で印象が大きく変わる数字だ。COOセッションのツール呼び出しのうち、直接ファイル編集（Edit+Write）と委任（Agent）だけで比べると約2:1（470回:235回）で直接編集が上回るが、Bashやファイル読み取りまで含めると約12.5:1にまで開く。ここでは狭義の比率（約2:1）を、「いつでも自分で降りられる」という体感の参考値として扱う。

(c) 割り込みも社内政治もない。この点は本記事のデータからは直接測定できていない。測定不能なものは測定不能と明記する。

楽しさの正体は「速いループ」ではなく「短いループ」

当初の仮説は「自分の裁量で、速いループを、邪魔されずに回せる労働条件」だった。だが実測を経て、この表現は不正確だとわかった。タスクが完了するまでは平均して1〜2日かかっている。速いのは「1往復のテンポ」のほうで、投げれば中央値3.7分で返ってくる。これは出典のある調査結果ではなく私自身の実感に基づく推測だが、人間組織のマネジメントでは、1往復（メールの返信待ち・次の定例会議待ち）に数日かかることが多いという印象がある。もしその印象が実態に近いなら、AIエージェント組織では同じ「マネージャー」という役割でも、1日に回せる往復の回数が桁で違う、という説明のほうが実態に即している。ただしこれは私の推測であり、本業側のやり取り速度は本記事では実測していない。

この再定義を裏づけるように、集中ブロック（30分以上の空白で作業単位を分割、n=111、対象は同じく2026年6月3日〜8月6日の約2ヶ月分)の中央値は19.7分、43.9%が15分未満で、4時間を超えるブロックは111件中1件（0.9%）しかなかった。「長時間ぶっ通しで没頭する」というより「短い作業を高頻度で繰り返す」パターンが実態に近い。作業開始時刻を見ると、夜21〜23時が36.9%と突出しており、夜間（18〜23時）だけで50.4%を占める。プロジェクト開始は2026-04-03だが、この集中ブロック・時間帯のデータは直近約2ヶ月分しか取得できていないため、「開始からずっとこうだった」とは言えない点は留保しておく。

夜の20〜30分の隙間時間でも、1往復が短ければ1サイクルが完結し、達成感が積み上がる。この解釈は複数の実測値と矛盾しないというところまでは確認できたが、「夜の隙間時間だから短いサイクルが選ばれている」のか「短いサイクルで回せるから夜の隙間時間でも作業が成立している」のかは、このデータからは因果の向きを特定できない。断定はせず、仮説として書いておく。

「割り込みなく作業している」についても、30分の空白が本当に割り込みによる中断なのか、単に別の作業へ移っただけなのかは、このデータからは判別できない。ここも断定は避ける。

マネジメントが嫌いなのではなかった――結論の反転

「マネジメントが嫌い」なのではなく、「人間組織のマネジメントから、条件と手触りを奪われたのがつらい」というのが、私がたどり着いた反転だった。AIエージェント組織のマネジメントは、その両方――短いループと、手を動かす自由――を返してくれる。

「逃避」という言葉には後ろめたさがつきまとうが、正確には「悪い労働条件からの避難」であり、それ自体を恥じる必要はないと今は思っている。

もし本業でやる気が出ない理由に心当たりがあるなら、それは仕事の中身そのものより、「1往復の長さ」のせいかもしれない。返事を待つ時間、承認を待つ時間、次の定例会議を待つ時間――それをどこまで短くできるかという観点で自分の働き方を見直してみると、案外別の見え方をするかもしれない。

試すとしたら、まず自分の環境でも「委任1回の応答時間」と「タスク全体が完了するまでの時間」をログや履歴から分けて拾ってみることを勧める。この2つを同じものとして混同したまま「速い」と感じていたのが、今回の私自身のズレの正体だったからだ。

委任1回あたり3.7分という短いループを、実務Issue616件へ積み上げていくと、次の問いが出てくる――その先で、人間が判断すべき仕事はどこまで残るのか。私がGTDのタスク管理をまるごとClaude Codeに任せていった記録は、Zenn Booksのコードを書けない私がClaude Codeに「仕事」を任せるまでにまとめている（序章無料）。

参考文献

James Stanier 著『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』（オライリー・ジャパン）

本記事は Claude Code（AIエージェント）との協働で執筆しています。データの実測・分析は本文に記載した手順で行い、文章化に AI の支援を用いています。

関連記事

実質、私は何もしていない — Claude CodeにGTDを組み込んだら、優秀なのはAIエージェントではなく「仕組み」だった

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