集中時間を新規執筆に使わない — 個人ブログ運営 1 年で気付いた時間配分の逆

集中時間を新規執筆に使わない、という結論

朝の一番集中できる時間を、私は新規記事の執筆に使っていません。AetherEchoes を 1 年運用してみてはっきり見えてきたのは、執筆そのものは深夜でも進むタスクで、本当に朝の集中力を投入すべきは編集 / 没判断 / 構造リファクタといった「自走しないタスク」だった、ということです。

きっかけは Zenn の ryugotoo 氏の記事「集中できる時間に開発する、というのは正しいのか？」でした。テーゼは単純で、「開発は内的報酬ループが強いから疲れていても進む。集中力はむしろ自走しないタスクに使うべきだ」というもの。これを個人ブログ運営という文脈に当てはめてみたら、私の時間配分が完全に逆だったことが見えました。

元ネタ — 開発に朝を使うな、というテーゼ

ryugotoo 氏の主張をひとことで言えば、「ゴールデンタイムは最も難しい仕事に使うべき」というセオリーは、タスクの報酬構造を無視している、という指摘です。設計や実装には内的フィードバックループ（書いたコードが動く / テストが通る / エラーが消える）があるため、疲労時でも着手できます。

逆に勤怠処理や経費申請のような管理業務は、思考難易度自体は低いものの、起動コストが高く、終わっても誰も褒めない構造です。これは疲労時にまず実行できません。だからこそ朝の集中時間を投入すべきだ、というのが氏の結論でした。

「タスクの難易度」ではなく「タスクが自走するかどうか」で時間配分を決める、という補助線が、私には新鮮でした。

個人ブログ運営の「自走するタスク」と「自走しないタスク」

私のブログ運営に同じ目で線を引き直すと、タスクが綺麗に 2 種類に分かれました。結論を先に書くと、執筆系はだいたい「自走する側」、編集・構造系はだいたい「自走しない側」です。

自走するタスク（書き始めれば進む / 報酬感が強い）:

• 新規記事の本文執筆
• リサーチ（公式 doc を読む / 他の人の記事を漁る）
• コード例の準備
• 公開直後のアクセス確認（これは報酬というより、ほぼ中毒）

自走しないタスク（着手のたびに踏ん張りが要る）:

• 半年前に書いた記事のリライト
• カテゴリ / タグ体系の見直し
• 「これは没にする」の判断
• 法務ページ（プライバシーポリシー / 利用規約）の更新
• リンク切れチェック
• アクセスゼロ記事の原因分析

下のリストが、朝の集中時間を回す価値があるタスク群です。書くこと自体は深夜のドトールでも、新幹線の中でも進みます。けれど「半年前の記事 3 本を読み直して没を 1 本決める」は、夜の私には絶対に無理でした。何度か試して、毎回スプレッドシートだけ開いて閉じる、を繰り返しました。

朝の集中時間を回したタスク — 3 つの具体例

実際に運用を変えてみて、朝の 60〜90 分に回した作業を 3 つ挙げます。いずれも「夜だとどうしても進まなかった」と私が観測したタスクです。

1. 没判断の朝会: 火曜の朝に「直近 30 日の記事 3 本を読み直す」というカレンダー枠を入れました。スプレッドシートで（タイトル / 公開日 / アクセス数 / 自分の評価 5 段階）を埋め、評価 2 以下は archive または書き直し候補に移します。これは夜にはできない作業でした。自分の書いた文章を冷たい目で見るのに体力が要る、というのは運用してみないと分からない発見でした。

2. カテゴリ構造のリファクタ: 月 1 で「カテゴリ別に記事一覧を眺めて、所属を変える / タグを統一する」を朝に置きました。AetherEchoes は engineering / ai / design / process / essay の 5 カテゴリですが、運用してみると design と process の境界が曖昧で、最初 design に置いた記事を process に移し直すケースが 3 ヶ月で 4 本ありました。これは夜だと「面倒だな」で半年放置されます。

3. 法務 / 規約ページの点検: 四半期に 1 度、プライバシーポリシーと AdSense ポリシーを読み直して、本文の表現と矛盾していないか確認します。私はこれが本当に苦手で、朝の集中時間以外には絶対やりません。1 度、夜にやろうとして 15 分でブラウザを閉じた記憶があります。

副作用と修正 — 「書く時間がなくなる」問題

集中時間を編集に振り替えたら、当然「では新規執筆はいつやるのか」が問題になりました。最初の 1 ヶ月、書く時間が露骨に減って週 1 本のペースが崩れました。

修正したのは 2 点です。1 つは、執筆は土曜の朝に大ブロックで取る、と曜日固定にしたこと（私が 月 4 本を回すための執筆スケジュール術 で書いた「週 1 / 土曜の朝」ルーチンと同じ枠です）。もう 1 つは、平日の 22 時以降の「眠いけど作業はできる」時間に書き始めることです。

最初は文章のクオリティが落ちると心配したのですが、ほぼ変わりませんでした。これは正直、私もちょっと驚きました。文章を書く脳と、編集や構造判断をする脳は、別物だったということなのかもしれません。

副次的な効果として、auto-publish（Claude Code + launchd で自動投稿する仕組み）を導入した動機の半分は、この「書く時間問題」の最終解答でもありました。書く工程の一部を機械に移譲することで、私の集中時間を完全に編集と意思決定に振れるようになりました。

時間配分は「難易度」ではなく「自走するか」で決める

ここまでの観察をまとめると、個人ブログ運営における時間配分の判断軸は、タスクの 難易度 ではなく 自走するかどうか で決めるのが効きました。難しさは関係ありません。「放っておいたら来月もまだ着手していない」タスクに、朝の集中時間を投入する。これだけで運営の安定度が一段上がります。

「自走しないタスク」が放置されると、サイトは表面的には毎週新記事が出ているのに、3 ヶ月後に振り返ると「カテゴリの整合性が崩れている / リライトすべき古い記事が大量に残っている」という状態になります。これは累積するほど修正コストが上がる、いわゆる技術的負債と同じ構造です。コードと違うのは、ブログの場合は誰も Pull Request を出してくれないので、運営者本人が朝の集中時間を割くしかない、ということだけでした。

時間配分の話を「タスクの種類で分ける」という発想は、古くは Paul Graham 氏の Maker's Schedule, Manager's Schedule があります。氏のフレームは「会議が頻繁に挟まる Manager の時間と、長い集中ブロックが必要な Maker の時間は構造が違う」という他人との関係軸でしたが、ryugotoo 氏のフレームは「自分のタスク内部の報酬構造」軸という違いがあります。個人ブログ運営者の私には、後者のほうが効きました。

私の中で時間配分の話は、もう「どの仕事が一番難しいか」ではなく「どの仕事が私を放っておいたら絶対に進まないか」という質問に変わりました。ryugotoo 氏のテーゼを個人ブログに翻訳すると、こうなる、というのが 1 年運用後の結論です。