Shun Bibo Roku

起きていること

Claude Code を使い始めてから、明らかに集中力が散漫になった。

具体的には、

• ブラウザのタブを行き来しながら「あれ、何やってんだっけ」となる
• スイッチばかりして、気が付いたら 1 日終わってる
• 仕事が全然進んでないみたいな落ちを感じる

同じ症状の人、いないだろうか。

自分もまだ使い始めて長くないが、使い始めて 1 年以内くらいの人は同じ感覚を持っているのではないかと思う。

この記事は、その症状に対して現時点で自分が試している答えを、後日答え合わせができるようにレコードとして残すことを目的とする。

何が起きているのか - コンテキストスイッチが脳のキャパを超えている

なぜ集中力が散漫になっているのか。自分の仮説はこうだ。

Claude Code を使う前は、コードを書くのは自分の手だった。手を動かさないとタスクが進捗しないので、自然と一つのことに集中せざるを得ない状況だった。

Claude Code を使ってからは、自分は「指示を出す側」に回った。指示を出すと、AI が処理している間は自分の手が空く。

この「手が空く時間」が問題だ。

暇になった瞬間に、別の文脈の新しい指示を投げたくなる。新しい指示を投げると、また AI 処理中に手が空く。空いた時間にまた別の文脈に手を出す...という連鎖が起きる。

結果、頭の中で複数の文脈が同時並行で走ることになり、コンテキストスイッチコストが脳のキャパを超える。

これは Claude Code というツール特有の話ではなく、AI エージェントに指示を渡して、自分が指示者になったことで発生する構造的な現象だと考える。バイブコーディングという言葉が出てきた背景には、この働き方の構造変化があると思う。

対処の本質: 待ち時間の質を制御する

ここまで整理すると、対処の本質が見えてくる。

問題は「AI 待ちの暇な時間に、別文脈の新指示を投げてしまうこと」だ。

つまり対処は、待ち時間に「別文脈の新指示」ではなく「メイン文脈に居続ける行動」を当てることになる。

次節で書くプラクティスは、すべてこの本質を実装するための運用ルールだ。プラクティスを並べる前に、まずこの一文を握っておくのがポイントだと思う。

やっているプラクティス

メインタスクの明示と 2 並行ルール

第一優先のメインタスクをマニュアル操作で明示する。今やるべきことを 1 つに決め、それ以外は意識から外す。

並行できるサブタスクは 2 つ目まで。サブタスクは「メインの待ち時間に成立するもの」であることが条件。

ただし重要なルールがある。

• メインタスクが完了したら、サブタスク途中でも必ずメインの次のタスクに戻る
• メインを進めることが常に最優先

サブタスクはあくまで「メインが詰まっている間に進めるおまけ」であって、サブが楽しくなってきても、メインが動き出したらメインに戻るというルールだ。

3 つ目はやらない

3 つ目のタスクをやりたくなった時は、できるだけやらない選択肢を取る。

具体的には、

• 早めに休憩に入る
• メインタスクのソースコードの差分を読み返す
• 関連 PR や Issue を眺める

要は、メイン文脈に居続けるための代替行動を当てる。

「2 つは OK で 3 つはダメ」の根拠はぶっちゃけ経験則だ。本当は認知科学の研究を引用したい気持ちもあるが、今のところ「自分は 3 並行になると破綻する」という n=1 の体感。所詮ブログなので主観で書いているが、自分でも 2 か 3 か試してみると差を感じられると思う。

pomofocus.io でセッション化

最近 pomofocus.io を使い始めた。

シンプルなツールで、

1. タスクを作る
2. そのタスクに必要なポモドーロセッション数を見積もる
3. 自動でタイマーが回る

自分はポモドーロ本来の 25 分という時間にはあまりこだわっていない(本来のやり方をちゃんと調べていないというのもある)。重要なのは以下の 3 点だと思う。

• 今が何を集中する時間なのかを明示する
• どれぐらいで終わらせるべきかの見積もりを置く
• 終わらなかった場合に強制的に休憩に入り、頭を切り替える

要は「締切効果」を作るのが目的で、25 分という長さ自体は本質ではないと考えている。

サブタスクは git worktree で分離

メインタスクと並行するサブタスクが同じリポジトリへの作業の場合、git worktree を切って別ディレクトリで作業する。

実例として、

• メイン: 仕事のコード書き
• サブ: NeoVim の設定で違和感があったところを直す

メインと NeoVim の設定改善を 2 セッションに分けて、サブの方をワークツリーに隔離する。

ポイントは「サブはワークツリーで作っておき、メインに切り替えたタイミングで動作確認をすればいい」こと。なので、複数の環境を同時に立ち上げる必要はあまりないと感じている。

(一応、ポートを分けて両方同時に動かせる環境も作ってみたが、結局そこまでやる必要があった場面は今のところ少ない)

「並行できるのが Claude Code の良さじゃないの?」への答え

ここまで読んで、「Claude Code の最大の良さは並行できることなのに、それを 2 並行までに抑える運用は AI のメリットを殺してないか?」という反論があると思う。

正直、明確に答えられている自信はないが、現時点で考えていることを書く。

「使いこなしている」の指標を「並行できる数」から「1 タスクが価値に昇華するまでのリードタイム」に取り直すと、答えが少し見えてくる。

• 並行 5 で 1 タスク 5 日 vs 並行 2 で 1 タスク 2 日 → 後者の方が「使いこなしている」
• アウトプットの量を増やしても、価値に昇華するまでのリードタイムが長ければ意味が薄い

自分の立場はこうだ。

• 並行数を増やしてもリードタイムを短くできる人はそれでいい
• ただし自分は脳のキャパ的に並行 2 が限界
• その制約下でリードタイムの最大化を狙う

「並行できる = 使いこなしてる」は短絡で、本来見るべきはリードタイム × 価値の質だと考える。並行数で測るからメリットを殺しているように見えるだけで、リードタイムで測ればむしろ最適化しに行っているとも言える。

ただし、ここの線引きが難しいのも事実。「どこまでが使いこなせていて、どこからが使いこなせていないのか」の境界は曖昧で、自分でもまだ整理しきれていない。なのでここは、もし反論がある人がいたら教えてもらえると嬉しい。

計測できてないが、透明化のスタートラインに立った

このルールを採用してリードタイムが本当に短くなったかと聞かれると、計測できていない。

ただ、pomofocus.io を使い始めてから「進んでる / 進んでないが目に見えるようになった」のは大きな変化だと感じる。

• 今のタスクがどのセッションで終わるはずだったか
• 実際にどこで終わったか
• 残りどれくらいかかりそうか

これは数値での厳密な計測ではないが、ある種の透明化だと思う。スクラムでいう透明性に近い感覚だ。

数値での計測ができていないので「本当にリードタイムが短くなったか」はわからないが、改善のためのスタートラインには立てたという感覚がある。

今後の展望

次にやりたいことは以下。

• 見積もりと実績の統計データを取る — pomofocus.io でも一部できるが、自分の使い方に完全にフィットしているとは限らないため
• 自作のサービスとして組む — データを自由に使える状態が一番幸せ
• 同じ症状を持つ人のプラクティスを集める — みんながどう集中力を保ってるのか、何が効いて何が効かなかったのかをトラッキングしたい

3 つ目は特に気になる。バイブコーディングで遠回りしながら働いている人は多いと思うが、各人の対処はまだあまり共有されていない印象だ。

まとめ

現時点で自分が試している答えを、レコードとして残した。

• 散漫化の本質は「AI 待ちの暇な時間に新指示を投げてコンテキストスイッチが爆増する」こと
• 対処の本質は「待ち時間に別文脈の新指示ではなく、メイン文脈に居続ける行動を当てる」こと
• 具体には「メインタスク明示 + 2 並行ルール + ポモドーロでセッション化 + ワークツリーで分離」
• 効果はまだ計測できていないが、透明化のスタートラインには立てた

このルールが半年後、1 年後にどうなっているか、リードタイムは本当に短くなったのかは、後日この記事を読み返して答え合わせをしようと思う。

同じ症状で悩んでいる人の参考や、別アプローチを共有してもらうきっかけになれば嬉しい。