Claudeで開発するときの集中力を、設計し直す
待ち時間にスマホを開くと、23分が消える
Claudeにコードの生成を頼むと、数秒から数分の待ち時間が発生します。
短い待ち時間でも、僕はつい手元のスマホを開いてしまいがちでした。
LINEの通知をチェックしたり、Xを少し眺めたり、何ということもない情報を見つめたりします。
Claudeの応答が返ってきた頃には、自分が何を頼んだのかすら少し曖昧になっていました。
ここで何が起きているのか、脳科学の世界では「注意残余(Attention Residue)」と呼ばれる現象で説明されてきました。
提唱したのはワシントン大学のソフィー・ルロワ教授で、あるタスクから別のタスクへ切り替えるとき、前のタスクへの思考や記憶が脳のワーキングメモリに残り続け、新しいタスクのパフォーマンスを下げる、という研究です。
タスク切り替えがたとえ数十秒であっても、注意残余は確実に発生します。
驚いたのは、ここからでした。カリフォルニア大学のグロリア・マーク教授らの研究によれば、中断されたタスクに戻るまでに、平均23分15秒かかるという報告があります。
1日に5回か6回、Claudeの待ち時間にスマホを開くだけで、その日の作業時間のかなりの部分が「集中を取り戻すための時間」に消えていく計算になります。
さらに、現代の人々の注意持続時間そのものが、過去20年で大きく縮んでいます。
2004年の研究では、スクリーン上の1つの対象に集中できる時間は平均2分30秒でした。
これでも本来の集中時間に比べれば、すでに短い数字です。脳は深いところで5〜15分は集中を維持できる設計なのに、当時すでに2分30秒しか持たなくなっていました。
そして現在、その2分30秒が47秒まで縮んでいます。デジタル環境が、脳の集中構造を根本から変えてきました。
待ち時間にスマホを触る行動は、一見すると小さく見えます。けれども、その代償は思っていたよりずっと大きいものでした。
わからないコードに「OK」を返してしまうのは、脳の防衛反応
Claudeに複雑な機能の実装を頼むと、長くて専門用語の多いコードと説明が返ってくることがあります。
Sanity CMSのスキーマ設計、Next.jsのルーティング、Vercelのデプロイ設定。
読んでいるうちに、僕は途中で「これ、もう読まなくていいか」と感じてしまうことがありました。
意味がわからないまま「OK」と返し、次のタスクへ進みます。
気がつくと自分が今どこにいるのかすら、見失っています。
これも意志の弱さではなく、認知負荷理論(Cognitive Load Theory)で説明できる現象です。
人間のワーキングメモリ(短期的に情報を保持する脳の領域)は、一度に扱える情報のチャンク(まとまり)が7±2個しかありません。
理解できない専門用語、複雑な構造、長く続く説明、これらが重なるとワーキングメモリの処理能力を超えてしまいます。
そして処理能力を超えたとき、脳は防衛的に「読むのをやめる」という選択をします。
これは怠けではなく、むしろ生存本能に近い反応です。
脳は身体全体のエネルギーの約20%を消費する高コストな器官です。
無理な負荷をかけ続けると消耗を加速させてしまうので、自動的に「シャットダウン」する仕組みが備わっています。
「OK」を連打してしまうのは、まさにこのシャットダウンが起きている瞬間でした。
しかも、この行動の代償は思っていたよりずっと深刻でした。
AI支援開発に関する脳波(EEG)を使った研究では、AIに頼って作業した被験者は、自力で作業した被験者と比べて脳内の神経接続が有意に低下し、約8割が数分前にAIと共同生成した内容を正確に記憶できなかったという報告が出ています。
理解しないままOKを連発することは、その場の作業が進むだけでなく、長期的なスキルの成長そのものを止めてしまうおそれがあります。
僕がOKを連発してしまう瞬間は、たいてい「コードが難しすぎる」ときに起きていました。
それは僕の理解力の問題というより、Claudeから返ってきたコードが、僕のワーキングメモリの容量を超えていただけでした。
集中力は鍛えるものではなく、環境を設計するものだった
ここまで、僕が集中を失う典型的なパターンを2つ見てきました。
待ち時間にスマホを開いてしまう、わからないコードにOKを返してしまう、どちらも意志の弱さではなく脳の自然な反応でした。
そうなると、ひとつの問いが残ります。脳の自然な反応であるなら、いくら「気合いを入れろ」と自分に言い聞かせても無駄なのではないか、という問いです。
脳科学者の中野信子さんが、著書やメディアで語っていることがあります。
脳というものは、集中できる環境を作ってやると勝手にそのことに集中してしまうようにできている、という趣旨です。
集中力を「鍛える」のではなく、集中できる環境を「設計する」という発想です。
この一言で、僕の取り組み方は変わりました。
意志でなんとかしようとするのをやめて、Claudeと開発しているときの環境とタスクの粒度を、意図的に設計し直す方向へ切り替えました。
フロー状態という、考えすぎなくなる科学
設計し直すと決めたとき、次に出てくる問いは「では、何を目指して設計するのか」でした。
集中の理想状態とはどんなものか、それがわかっていないと、設計の方向が決まりません。
ここで参考になるのが、心理学者ミハイ・チクセントミハイが提唱した「フロー(flow)」という概念です。
フローは「ほとんど自動的で、努力感がなく、しかし極度に集中した意識状態」を指します。
時間感覚が消え、自意識も消え、作業そのものが報酬になります。
スポーツ選手が「ゾーンに入った」と語る感覚に近いです。
興味深いのは、フローに入ると前頭前皮質の活動が一時的に低下するという仮説です。
一過性前頭葉機能低下仮説(transient hypofrontality)と呼ばれ、神経科学者のアーン・ディートリッヒさんが提唱しています。
前頭前皮質は「判断」「自己評価」「内省」を司る領域です。
ここの活動が下がるからこそ、「考えすぎなくなる」深い没入が可能になっていると考えられています。
フローが発生しやすい条件は7つ挙げられていますが、なかでも最も重要視されているのが「挑戦と能力のバランス」です。
簡単すぎる作業は退屈を生み、難しすぎる作業は不安を生みます。フローは、その中間の「少し背伸びすれば届く」ゾーンでしか発生しません。
Claudeとの開発に置き換えると、ひとつわかります。OKを連発してしまう瞬間は「難しすぎて不安になっている」状態で、待ち時間にスマホを触ってしまう瞬間は「待っているだけで退屈になっている」状態でした。
どちらも、フローの逆方向に脳が引っ張られていた瞬間です。
待ち時間別使い分け — 何秒待つかで、やることが変わる
ここから実践のセクションに入ります。最初に取り組んだのは、Claudeの待ち時間の使い方を見直すことでした。
待ち時間が15秒なのか、3分なのか、10分なのかで、脳に与えるべき対応は変わります。
短い待ち時間に長い休憩を取ればコンテキストが失われ、長い待ち時間に身体を固定したままだと疲労が抜けません。
秒数別に4つの帯に分けて、それぞれの対応を決めておきます。
15〜30秒:身体的リセットで衝動を断つ
もっともスマホを触りたくなる時間帯です。
短すぎて何かをするには中途半端なのに、ただ待っているだけだと退屈で、脳が「何かしたい」と訴え始めます。
ここでの正解は「コンテキストはそのままに、身体だけを動かす」です。
姿勢を整える、深呼吸を3回する、6メートル先のものを20秒間見つめる(20-20-20ルール)、水を一口飲む。
どれもコードのコンテキストを脳から追い出さず、身体だけがリセットされる行動です。
1〜3分:コンテキスト内で判断の精度を上げる
もっとも価値の高い時間帯です。
Claudeに送ったプロンプトを読み返したり、周辺のコードをスキャンしたり、次に書きたいテストケースを書き出したりできます。
ポイントは、絶対に同じプロジェクトの作業の中にとどまることです。
LINEを見たり別のタブを開いたりした瞬間に、注意残余が発生して23分の回復コストが始まります。
3〜5分:次の指示を下書きする
もう少し踏み込んだ作業ができる時間帯です。
次にClaudeへ出す指示を紙に下書きする、機能の設計図を簡単に描く、自分が何を作ろうとしているかをメモする、といった準備に使えます。
Claudeの応答が届いた瞬間にすぐ次の指示を投げられるので、テンポを失わずに作業が進みます。
5分以上:脳に本物の回復を与える
5分を超える待ち時間は、むしろチャンスです。
窓の外を眺める、台所へ歩いて飲み物を取ってくる、目を閉じて少し姿勢を崩す。
このとき脳は「拡散的思考(Diffuse Thinking)」と呼ばれるモードに切り替わります。
集中状態とは違い、複数の領域を緩く繋ぎながら、バックグラウンドで問題を処理し続ける状態です。
シャワーや散歩中に良いアイデアが浮かぶ現象は、このモードで起きていることが多いと言われています。
補足:別プロジェクトの並行は逆効果
ひとつだけ追加したいことがあります。
AI開発の待ち時間が長いと「この時間で別のプロジェクトも進めよう」と考えがちですが、これは注意残余を最大化する典型的な行動です。
作業の切り替えコストが累積し、結果として複数のプロジェクトを並行するほうが、1つずつ完了させるよりも総時間が長くなります。
待ち時間にやってよいのは「同じプロジェクトに関すること」か「コンテキストゼロの身体的リセット」のどちらかだけです。
僕がClaudeとの開発で実践している2つのこと
ここから先は、僕自身が試行錯誤しながらたどり着いた2つの実践を紹介します。
どちらも特別な道具やアプリは要らず、いま手元にあるものですぐに始められます。
ノートとペンを、マウスのすぐ横に開いて置く
最初の実践はとてもシンプルです。
マウスのすぐ横に、ノートを開いた状態で置きます。ペンも一緒に。
Claudeが応答を生成している待ち時間、頭に浮かんだことをそこに吐き出していきます。
吐き出す内容は何でも構いません。
次にやろうとしている作業の手順、いま気になっているコードの構造、Claudeに次に頼みたいこと、あるいは「ここでなぜこの実装にしたのか」という自分への問いかけなど。
文章になっていなくても、箇条書きでも、矢印で繋いだ単語の羅列でも、なんでもいいです。
書いていて気づいたのは、頭の中で考え続けるよりも、紙に出したほうが自分の考えがはっきりしてくることでした。
書いている最中に「あ、そういえばこれもあった」と思い出すことも多く、書いた結果を眺めながらClaudeの応答を待っていると、コードのコンテキストが頭の中で温まり続けていく感覚があります。
スマホを触っていたときは、コードから頭が離れていきました。
ノートに書いているときは、その逆です。
同じ「待ち時間に手を動かす」行為でも、結果がまったく違いました。
ユーザーへの影響、そのための行動、コードの意味、の順で聞く
もうひとつの実践として、Claudeに質問をする順番を固定しました。
難しいコードが返ってきてOKを連発しそうになったとき、次の3つを順番に聞くようにしています。
このコードは、ユーザーにとってどんな影響があるのか
その影響を生むために、何をしているのか
このコードのこの行は、どんな意味なのか
最初は「ユーザーへの影響」から始めます。実装の詳細ではなく、「これが完成したら、サイトを訪れた人に何が起きるのか」という、いちばん大きな視点の問いです。
次に「そのために何をしているのか」を聞きます。
機能としての役割、データの流れ、処理の大きな流れを順に確認していきます。
最後に「この行はどんな意味か」と、コードそのものに降りていきます。
この順番に行き着いたきっかけは、いきなり細かいコードの意味を聞いても、その答え自体がよくわからなかったことでした。
逆に「これは結局、ユーザーにとって何になるのか」を最初に聞くと、頭の中に大枠ができて、その下の細かい話が「この大枠の中の一部だ」と位置づけられるようになります。
そしてこの順番で3つの答えを並べていくと、自然にひとつのストーリーとして読める文章になります。
ユーザーへの影響という大きな目的から、それを実現する仕組み、最後に個々のコードの行へと降りていく流れは、何度読み返しても先が繋がっている読み物のような形を持っています。
この文章を、その後の待ち時間に何度も読み返すようになりました。
次のコードが生成されている間、先ほど読んだストーリーをもう一度なぞって、頭の中でコンテキストを温め直します。
スマホを開く代わりに、自分が一度理解した内容を再確認する時間に変わりました。
理解してから次に進む、を貫く
ここまでで、Claudeとの開発で集中が途切れる仕組みと、僕が集中力を取り戻すためにやっていることを、ひと通り書いてきました。
脳の防衛反応や注意残余といった仕組みの話から、待ち時間別のプロトコル、ノートに思考を吐き出す習慣、Claudeへの3つの質問まで、いくつもの要素を並べてきましたが、結局のところひとつの原則に行き着きます。
それは「理解してから次に進む」という原則です。
Claudeは速く動きます。
指示を出せば、数秒から数分でコードが返ってきます。
そのスピードに合わせて自分の作業も速くしようとすると、たいてい「わからないまま進める」状態に陥ります。
OKを連発する瞬間も、待ち時間にスマホを触ってしまう瞬間も、根は同じで「Claudeのスピードに僕の理解が追いついていない」状態でした。
集中力の設計とは、結局、自分の理解の速度を守ることでした。
Claudeが速いからといって、僕まで速くなる必要はありません。
むしろ、Claudeが速いからこそ、僕は自分のペースで「ここまでわかった、ここから先がわからない」を区別する作業を、ていねいに続けなければなりません。
そのために、待ち時間にコンテキストを温める方法を変えました。
難しいコードに出会ったら、3つの順番で聞くようにしました。
これらはすべて、自分の理解の速度を守るための、設計の一部です。
集中力は意志ではなく、設計の問題でした。
記事の冒頭で書いたこの言葉に、もう一度戻ります。気合いや精神論ではなく、机の上のノートの位置を変えたり、Claudeへの質問の順番を決めたり、待ち時間の身体の動かし方を意識したりする、そういった小さな設計の積み重ねが、僕にとってClaudeとの開発で集中を取り戻す方法でした。
本記事で触れなかった集中法について
最後にひとつだけ補足します。集中力に関する研究や手法は、本記事で扱った以外にもたくさんあります。
25分集中5分休憩を繰り返すポモドーロテクニック、脳の自然なリズムに沿った90分単位の作業設計、深い集中状態に入るためのルーティン(Cal Newportが提唱する「ディープワーク」)、マインドフルネス瞑想による前頭前皮質の強化など、どれも効果が確認されている方法です。
本記事ではClaudeとの開発という具体的な場面に絞ったので、これらの一般的な集中法はあえて扱いませんでした。
それぞれが独立した深いテーマなので、別の機会に取り上げる価値があると感じています。
参考文献
注意残余(Attention Residue)に関する研究: Leroy, S. (2009). "Why is it so hard to do my work? The challenge of attention residue when switching between work tasks." Organizational Behavior and Human Decision Processes, 109(2), 168-181.
中断後の回復時間に関する研究: Mark, G., Gudith, D., & Klocke, U. (2008). "The cost of interrupted work: more speed and stress." Proceedings of the SIGCHI Conference on Human Factors in Computing Systems.
注意持続時間の経年変化に関する研究: Mark, G. (2023). Attention Span: A Groundbreaking Way to Restore Balance, Happiness and Productivity. Hanover Square Press.
認知負荷理論: Sweller, J. (1988). "Cognitive load during problem solving: Effects on learning." Cognitive Science, 12(2), 257-285.
ワーキングメモリの容量(7±2): Miller, G. A. (1956). "The magical number seven, plus or minus two: Some limits on our capacity for processing information." Psychological Review, 63(2), 81-97.
AI支援開発における脳活動の研究: MIT Media Lab (2025) "Your Brain on ChatGPT" 等のEEG研究(LLM使用群における神経接続の低下、および記憶定着率の低下に関する報告)
フロー理論: Csikszentmihalyi, M. (1990). Flow: The Psychology of Optimal Experience. Harper & Row.
一過性前頭葉機能低下仮説: Dietrich, A. (2003). "Functional neuroanatomy of altered states of consciousness: The transient hypofrontality hypothesis." Consciousness and Cognition, 12(2), 231-256.
拡散的思考: Oakley, B. (2014). A Mind for Numbers: How to Excel at Math and Science. Tarcher.
中野信子さんの著書(集中力に関する記述全般)