プロンプト・待機・評価のループ：AIがいつの間にかフローを殺す仕組み

数ヶ月前、著者はAI時代におけるプログラミングの喜びについて記事を書いた。その前後に行った同僚開発者との個人的な対話で、一つのことが著者を驚かせ続けている。ほとんどの人は反論しない。ただ「そう、まさにその感覚だ」と言うだけだ。しかし、それらの会話の中で繰り返し浮上した疑問がある：なぜこのように感じるのか？哲学的な意味ではなく、機械的な意味で——AIコーディングアシスタントを使うとき、私たちの注意に実際何が起きているのか？

このメカニズムを理解することが重要だと著者は考える。それは「何かがおかしい」と漠然と感じることと、それに対して具体的に対処できることの違いだからだ。

まず、フローとは何かを理解する必要がある。1990年、心理学者ミハイ・チクセントミハイは『フロー：最適体験の心理学』を出版し、私たちがすでに経験したことのある状態に名前を付けた。フローとは、行動と意識が融合する完全な没入状態であり、時間を忘れ、自己意識が消え、仕事が自然に進む。チクセントミハイは三つの前提条件を特定した。

明確な目標：各瞬間に何を達成しようとしているのか、高レベルだけでなく、次の数回のキーストロークの解像度で理解していること。

即時フィードバック：自分が行ったことがすぐにわかる。コンパイラ、テスト、出力——何かが自分の位置を教えてくれる。

スキルに合った挑戦：タスクは完全な関与を必要とするほど難しいが、固まってしまうほど難しくはない。自分は伸ばされているのであって、行き詰まっているのではない。

プログラミングは、その最高の状態において、最も純粋なフロー状態の一つである。良いデバッグセッションを考えてみよう。明確な目標がある（バグを見つける）、即時フィードバックがある（テストが通るか通らないか）、挑戦は自分に合わせてスケールする。仮説を排除するにつれて、検索範囲は狭まる。完全に没入している。新しいコンポーネントをゼロから書く場合も同じだ。アーキテクチャを頭の中で保持し、スケルトンを置き、イテレートする。コンパイルのたびに軌道に乗っているかどうかがわかる。難易度は現実的だが管理可能で、時間は瞬時に過ぎ去る。

しかし、AIアシスタントは「プロンプト→待機→評価」という新しいループを導入し、これら三本の柱を体系的に破壊する。プロンプトを書くとき、目標は曖昧になる。自分でコードをタイプするときは次の行が何をすべきか分かっているが、プロンプトでは高レベルの記述をしているだけで、機械が何を生成するかの瞬間的な明確さはない。フィードバックは遅延する。チャット型のアシスタントでは数秒から30秒、エージェント型のツールでは数分から十数分に及ぶことがある。待っている間に、Slackをチェックし、メールをちらりと見て、別のブラウザタブを開き、さらに別のAIセッションを始めるかもしれない——つまり、二つの問題の間でコンテキストスイッチを起こし、どちらにも完全には没入していない。

カリフォルニア大学アーバイン校のGloria Mark教授は、知識労働者が実際にどのように時間を過ごしているかを20年以上研究し、一回の中断後、同じレベルの集中に戻るのに平均23分15秒かかることを発見した。彼女の2023年の著書『Attention Span』によると、切り替え前に単一の画面に費やす平均時間は2004年の2.5分からわずか47秒に減少している。Chris ParninとSpencer Rugaberによるプログラマーの中断研究では、86人のプログラマーの10,000記録セッションと414人の調査に基づき、中断のうち1分以内にコーディングを再開できるのはわずか10%であることが示された。93%のセッションでは、プログラマーが再編集を始める前に重要なナビゲーション（ファイルを開く、スクロール、検索）が発生した。彼らは中断した場所を探しているのではなく、中断した場所を再構築しているのだ。

これがまさにプロンプトと応答の各サイクルの間に起こることだ。プロンプトを書き、応答を得て、それを評価するために、生成されたコードを頭にロードし、自分の望んだもののメンタルモデルと比較し、一致するかどうかを判断する。これは再開ではなく、毎回ゼロからの再構築である。

AIループが特に厄介なのは、それが仕事そのものに偽装される点だ。会議やSlackメッセージのような従来の中断とは異なり、プロンプトを入力して応答を待つことは仕事を止めたように感じさせない。むしろ、まだタスクの中にいるように感じる。しかし実際は、あなたは保留パターンに陥り、他人の出力を待っている。そしてその出力が到着したとき、あなたは続きをするのではなく、異なる高度から再スタートしている。

解決策として著者は、AIツールを完全に放棄するのではなく、タスクの種類によって使い分けることを提案する。ボイラープレート、設定、探索的プロトタイピング、よく理解された動作のテストなど、そもそもフローに到達しないようなタスクにはAIを使う。しかし、アーキテクチャ設計、微妙なバグのデバッグ、複雑なモデルを頭の中で保持する必要がある実装など、フローが可能で価値のあるタスクには、AIアシスタントをオフにする。なぜなら、インタラクションパターンそのものが最良の思考を妨げるからだ。

もう一つの方法は、AIインタラクションをバッチ処理することだ。チャットウィンドウを一日中開いたままにするのではなく、AI支援に適したタスクを集めて専用のブロックで処理する。そうすることで、残りの時間をフローと成長を生み出す深い中断のない作業に充てることができる。

結局のところ、これは生産性の問題ではない。指標は良好かもしれない。ベロシティチャートは以前よりも良く見えるかもしれない。しかし、仕事日の質感——機械を監督する日と仕事に完全に存在する日の違い——が問題なのだ。両方とも成果を生み出すが、満足感を生み出すのは後者だけである。メカニズムを理解し、それがAIに対する漠然とした不安ではなく、ループそのものが状態を壊しているのだと知ることで、行動に移しやすくなる。あなたは感情と戦っているのではなく、中断パターンを管理しているのだ。そして、それを中断として認識すれば、それに応じて対処できるようになる。