この記事の要約: 一部の作業だけが何ヶ月も終わらないのは、意志力の問題ではなく作業の設計の問題ではないか、という仮説を、実際に86日(約2.8ヶ月)止まっていたブログ運営の停滞を題材に検証した記録。条件（短いループ・低摩擦・割り込みなし）を満たす作業は速く流れ、満たさない作業は手つかずのまま積み上がる。対処したのは「頑張って書いた」ことではなく、公開先の意思決定と、書いてから公開するまでの手間を減らす仕組み側の改修だった。ただし9日経った執筆時点でも2本目の記事はまだ書けていない、という正直な現状も併記する。
やりたいと思っている作業のうち、1つだけがずっと終わらない、という経験はないだろうか。私にはあった。ウイスキーのレビューを書くもう一つのブログを立ち上げ、独自ドメインもアクセス解析も整えたのに、記事が1本も公開されないまま86日(約2.8ヶ月)が過ぎていた。
「時間がなかった」わけではない。この技術ブログの最初の記事を公開したのは2026年4月6日で、そこから今日までの間に、私は本業のかたわらAIエージェントに指示を出しながら記事を147本書き、公開してきた。同じ「書く」という行為なのに、片方は止まらず流れ続け、片方は完全に止まっていた。この差はどこから来るのか、というのが今回の主題だ。
「在庫」という見方——作業はなぜ停滞するのか
製造業には「仕掛品（WIP）」という言葉がある。工程のどこかがボトルネックになると、そこより前の作業は完成しないまま積み上がっていく。私はこれと同じことが個人の作業にも起きていると考えている。以下、この記事では条件を満たさず手つかずのまま積み上がっていく作業を「在庫」と呼ぶことにする。業務用語として定着しているわけではなく、私が個人的に使っている言い方だ。
在庫になるかどうかを分けているのは、作業の重要度でも好き嫌いでもなく、次の3条件を満たしているかどうかだと私は見ている。
- 短いループ — 手を付けてから結果が返ってくるまでが短い
- 低摩擦 — 着手するまでの準備・判断・待ち時間が少ない
- 割り込みなし — 他人の予定やペースに合わせずに進められる
この3条件は、AIエージェントを使った作業が楽しく感じられる理由を分解した際に見えてきたものだ（詳しい検証は別記事Claude Codeで動かすAIエージェント組織はなぜ楽しいのかに書いた）。3条件が揃う作業は高速で回る。逆に、どれか1つでも欠けると、着手そのものが先延ばしにされ、在庫として積み上がっていく。これは根性が足りないからではなく、条件が揃っていないから止まっている、という構造の話だ。
実例: 86日動かなかったブログ
このもう一つのブログは、ドメイン取得・アクセス解析の設定・アフィリエイトの登録といったインフラ整備は完了していた。それでも記事は1本も公開されないまま86日(約2.8ヶ月)が経過していた。
このタイミングで、この停滞を解消するタスクとして登録し、状況を洗い出した。すると、止まっていた理由は「書けなかったから」ではなかった。実は、記事のドラフト自体は公開直前の品質チェックをすでに通過しており、いつでも公開できる状態になっていた。その「いつでも公開できる状態になった日」を起点に数えると、実際に公開されるまで86日かかったことになる。書く作業は短いループで完了していたのに、その先の「どこに公開するか決める」「公開までの手順を整える」という工程が重く、割り込みも判断待ちも多かったために、完成品が公開されないまま放置されていたのだ。
つまり在庫化していたのは「執筆」ではなく「公開までのラストワンマイル」——最後の仕上げの一手間だった。物流業界で、配送センターから顧客の玄関先までの最後の区間が一番コストがかかると言われるのと同じ構図だと思う。
先延ばしをやめた方法: 判断と手順を仕組みに置き換えた
この診断のあと、最初にやったのは「公開先を決める」という、先送りにしていた判断そのものを下すことだった。この判断は本来なら数秒で終わるはずのものだが、決めていなかったこと自体が、後続のすべてを止めていた。判断を下したあと、ドラフトをそのまま公開して86日の停滞を断ち切った。
同じタイミングで、次に同じ摩擦が再発しないよう、公開までの手順そのものを仕組み化する作業を進めた。人の承認を都度待たずに一晩で走らせた改修で、やったことは大きく3つある。
-
銘柄登録の入口を1つのスキルに集約した — それまで銘柄データの登録経路は、外出先で使うモバイルのクイック投稿画面、PCのWeb編集画面、コマンドラインツールの3系統に分かれていた。しかもコマンドラインツールには新規登録（insert）のコマンドがなく、PCで作業中に「今この銘柄を登録したい」と思っても、その場で完結する手段がなかった。これを、カスタムスキル
/whiskyに add（新規登録）・enrich（情報補完）・list（一覧表示）・get（詳細確認）・article（記事下書きの生成をライター役に依頼する）という5つのサブコマンドを揃え、コマンドラインからその場で完結できる形に集約した。 -
公開前チェックを軽量な仕組みに置き換えた — 数値の実測漏れや出典の欠落がないかを毎回自分の目で見返していたのを、機械的に検出できる簡易チェックに置き換えた。frontmatterに
fact_checkという新しいフィールドを設け、事実確認が通ったかどうかを記事ファイル自体に記録する形にした。この記事のように複数人の目でレビューする本格的な仕組みは、こういう小さな記事を出すたびに回すには重すぎるため、事実確認だけに絞った軽量版として別に用意した。 -
手順書を1本にまとめ、設定ミスも直した — 「執筆から公開まで、次に何をすればいいか」を毎回考え直さなくて済むよう、手順を
ops/playbooks/article/whisky-article.mdという1つの手順書に固定した。あわせて、投稿先のブログ設定を誤って上書きしてしまうscripts/hatena/credentials.shの不具合も見つかったので直した。
3つとも、3条件のうち「低摩擦」を作業側に足す対処だ。加えて、この改修自体が承認待ちなしの一晩で完了したことは、「割り込みなし」の条件を満たした状態で進んだことも意味する。着手までの準備・判断・待ち時間を先に削っておけば、次に同じ種類の記事を書くときは、この一連の作業自体がボトルネックにならずに流れる。
結果として、記事は0本から1本になり、86日(約2.8ヶ月)の停滞は解消した。タスクとして登録してから、実際に記事が公開されるまでは半日ほどしかかかっていない。
ここで一つ断っておきたいのは、この解消をタスク登録それ自体の手柄だと言い切るつもりはないということだ。停滞の本当の原因（公開先が決まっていなかったこと）は、タスクとして書き出すよりずっと前から存在していた。登録したタイミングと動き出したタイミングがたまたま近かっただけの可能性は残っている。私が言えるのは、「公開先を決める」「手順を仕組み化する」という、低摩擦化の作業を先に済ませたことが、結果的に停滞を解いたという事実だけだ。
正直な現状: 9日経っても2本目はまだ書けていない
ここまでを読むと「仕組みを整えれば全部解決する」ように聞こえるかもしれないが、そう単純ではない。この記事を書いている時点で、あのブログはまだ1本のままだ。公開の摩擦を下げる改修は完了したが、次の記事を書いて公開するところまでの一連の流れは、まだ実地で試されていない。
これは理論への反証というより、理論の射程を正しく示していると思う。今回条件を整えたのは「公開する」という工程であって、「書く」という工程ではない。書く作業には依然として人間の判断と時間が要る。低摩擦化した工程は速く流れるようになったが、そもそも人が着手しなければ流れようがない工程が別に残っている、ということだ。条件を整えることは在庫を解消する必要条件であって、十分条件ではない。
先延ばしになりやすいもう一つの仕事: 「決めたこと」を記録に残す
同じ棚卸しの過程で、もう一つ別の停滞が見つかった。以前脱稿していた別の原稿について、出版するかどうかがすでに決まっていたにもかかわらず、その決定がどこにも記録として残っておらず、調査の際に「まだ止まっている」と誤って拾われてしまったのだ。実際には出版を見送るという判断はすでに下りていて、原稿の内容は別の形で公開済みだった。
これも構造は同じだと思う。「決めたことを1行書き残す」という作業は、本来なら数十秒で終わる、条件を満たしやすい作業のはずだ。それでも後回しにされ続けると、今度は「決定そのものが在庫になる」という形で表面化する。記録を残す作業も例外ではなく、同じ3条件の対象になる。
作業が終わらないのはなぜか——3つの条件で診断する
止まっている作業を意志力の問題として扱うと、対処は「もっと頑張る」の一択になり、たいてい長続きしない。条件の問題として捉え直すと、点検すべき質問が具体的になる。
- 着手してから結果が出るまでのループは短いか。長いなら、途中に区切りを作れないか
- 着手するまでの準備・判断・待ち時間は少ないか。多いなら、その判断を先に済ませておけないか
- 他人の予定やペースに合わせず進められるか。合わせる必要があるなら、非同期にできないか
止まっている作業をこの3つに当てはめてみると、たいてい理由はどれか1つか2つに絞られる。そこから先の対処は「その条件を作業側に足す」ことに尽きる。今回の場合は「公開先を決める」という判断を前倒しし、「公開までの手順」を仕組み化することで、低摩擦の条件を後付けした。
まとめ: 意志力ではなく条件を疑う
在庫が動き出したのは、意志力を振り絞ったからではなく、条件が揃っていない工程を先に手当てしたからだった。ただし、これで終わりではない。次に書く記事が実際にどれくらいスムーズに流れるかは、まだこれから確かめることになる。もしあなたの手元にも何ヶ月も動かない作業があれば、一度「意志力の問題」を疑うのをやめて、「どの条件が欠けているか」を点検してみることをおすすめしたい。
条件を作業側に足すという発想を突き詰めると、次に出てくる問いは「その仕組み化自体を、誰がどう回すか」になる。AIエージェントに実行を任せる運用をどう組み立てているかは、Zenn Bookシリーズ「コードを書けない私がClaude Codeで「AIチーム」を回すまで」（序章無料）にまとめてある。
関連記事
- Claude Codeで動かすAIエージェント組織はなぜ楽しいのか——速いのは問題解決ではなく「1往復」だった — 今回使った3条件（短いループ・低摩擦・割り込みなし）を最初に分解した記事
- 「これを仕事にできないかなぁ」——Claude Codeに1セッション相談したら、妄想ではなく「検証可能な設計問題」になっていた — 今回の停滞解消のきっかけになった、雑談から実行可能な形になるまでのプロセスを書いた記事
- タスク管理をClaude Codeの内部に置くと、タスクの主語がAIになる — 同じタスク管理の実践から見えた、別の切り口の記事
この記事は はてなブログ からのクロスポストです。