並行稼働には一覧性が要る
AIを使う場面で、複数のセッションを並行に動かす運用、いわゆる一人社長的な使い方の比重が増えている。別々のタスクを同時に進めさせ、進捗を見ながら指示を切り替えていく。これが成立すると、一人で複数のプロジェクトを同時に進められる。
この運用を支えているのは、並行する全セッションを 一度に見渡せること だ。どのセッションが何をしていて、どれが止まっていて、どれに次の指示を入れるべきか、一画面で把握できる状態。切り替えのクリックを挟まずに済む状態。一覧性が成立している間は、全セッションが常に視界に入っているので、待機中のAIに次の指示を出すのも自然な動作の延長になる。
一覧から外れた瞬間、意志の力が必要になる
一覧性が失われた瞬間に、運用コストは跳ね上がる。画面に表示されていないセッションを見るには、タブやリストを開く1クリックが要る。この1クリックの問題は時間ではなく意志の力だ。「今あのセッションはどうなっているか確認しよう」と能動的に思い出し、意図的に手を動かさないと、見に行けない。
意志の力は有限で、1日の中で使える量に上限がある。並行稼働は本来、意志の力を消費せずに複数のことを進めるための仕組みのはずだ。それが、見に行くたびに意志を消費する状態になると、仕組みそのものが崩れる。気づくと手前の見えているセッションにしか手が伸びなくなり、他のセッションは放置される。名目は並行でも、実質は逐次処理に戻る。
Claude Code Desktopの構造的限界
Claude Code Desktopは、一画面に並べて表示できるセッションが最大4つまでだ。5つ目以降は左側のセッションリストに押し込まれ、見に行くには1クリックかかる。
このクリック1回が並行稼働の致命傷になる。4セッションまでは一覧に入るので意志の力なしで運用できるが、5つ目からは意志の力が要る。つまり並行稼働の実質的な上限は、一画面に並べられる数で決まっている。
背景にあるのは機能不足ではなく思想だ。デスクトップアプリは1セッションを中心に据えて他をサブに見せる設計になっている。1人の書き手が1つの対話に深く入っていく想定で、複数セッションを同時に育てる想定がない。
並行稼働の上限は一覧性で決まる
AIを並行に動かす運用の上限は、モデルの同時実行数や契約プランではない。意志の力なしに視界に入れ続けられるセッションの数 で決まる。視界に入っているセッションには自然に手が伸び、視界から外れたセッションは放置される。
だから並行稼働のためのAI環境を選ぶとき、機能の豊富さよりも一覧性の上限を先に見たほうがいい。一画面に何セッション並べられるか。並べたセッションの状態が常時見えるか。ここが細いなら、本体のモデルがどれだけ強くても、並行運用は成立しない。
AIの理想はツールではなくアイアンマンスーツであるという話をしたが、スーツが一度に使える機能が1つだけなら、複数の戦いを同時にはさばけない。並行稼働の時代のAIツールに求められる条件の筆頭は、一覧性の上限を高く保つ設計だ。