ぼくは複数のクライアント・複数のプロジェクトを同時に動かすディレクターです。
AIエージェントを使い始めてから仕事の量は増えましたが、気づいたら別のところで詰まっていました。AIが動いている間、ぼくはただ待っているだけでした。そしてその「待ち」の正体がわかったとき、呆れるくらい単純な原因に気づきました。VSCodeを1つしか立ち上げていなかったのです。
AIに指示を出して、あとは「待つだけ」が生産性を食っていた#
1ウィンドウでAIを動かしていれば、必ず「詰まり」が来ます。その構造を整理しておきます。
1プロジェクト待ちの間、別プロジェクトが止まる構造#
ぼくの場合、Claude Codeはほぼ常にVSCode上で動かしています。ターミナルだけで操作するより、ファイルツリーやエディタが見えた状態の方が判断しやすいからです。
VSCodeは開いているフォルダを作業単位とします。Claude Code的には「ディレクトリ＝コンテキスト1個」になります。コンテキスト汚染を防ぎたいので、ぼくはクライアントごと、あるいは規模が大きければプロジェクトごとに別ディレクトリを使っています。
結果として「VSCode1ウィンドウ＝クライアント1社（またはプロジェクト1つ）」という固定関係が生まれます。1つのプロジェクトに対してAIが走っている間、別のプロジェクトへの指示を入力する場所がありません。単純な話ですが、これが詰まりの本質でした。
待ち時間を会議・チャット対応で埋める悪循環#
AIが動いている間、ぼくは何をしていたか。チャットに返事を書き、メールを処理し、会議で発言していました。
これは「AIの待ち時間を有効活用している」ように見えて、実は違います。次のAIへの指示を設計する時間を圧迫していました。AIに先に全部指示を投入しきる、という発想が最初からなかったのです。1ウィンドウしかないから、物理的に「別プロジェクトの指示入力」ができなかっただけなのに、その問題から目が向いていませんでした。
そういえば、以前未来の自分に先回りして指示を飛ばすという話を書いたことがあります。AIへの指示もまったく同じ構造です。先に指示を投げきった分だけ、未来の自分（とAI）が動いてくれる。1ウィンドウ縛りはその「先投げ」を物理的に封じていました。
原因は「VSCodeを1つしか立ち上げない」という謎のルールだった#
原因を探ってみると、「Electronは重い」という話が頭の中に刷り込まれていました。
VSCodeはElectronベースなのでメモリを食う、複数立ち上げると動作が重くなる——という話を何度も聞いたことがあります。ぼくはいつのまにか「複数起動は非現実的」という前提を自分に課していました。
実際に試してみると、まったく問題がありませんでした。ぼくのマシンは32GBのRAMで、Teams・Outlook・Edge（タブ5個）・Slack・MS Officeと同居させながら3ウィンドウまで試しましたが、動作が重くなる場面は特になかったです。都市伝説にやられていた、としか言いようがありません。
16GBマシンでは状況が変わる可能性はあります。ただ少なくとも32GB環境であれば、よく使うツールをすべて開いた状態で3ウィンドウ並列は現実的な選択肢でした。
Claude Codeを複数起動したら、AIが動いている間に次の指示を出せるようになった#
3ウィンドウに切り替えて最初に変わったのは「AIが動いている間に何ができるか」という問い自体が変わったことです。
A社待ちの間にB社の指示を入力する、並列AIワーク#
A社向けのClaudeが走っている間、B社のVSCodeウィンドウを開いてプロンプトを書きます。B社のClaudeが動き出したら、C社のウィンドウで次の指示を設計します。
これを実際にやって気づいたのは「AIに先に指示を与えきること」の重要性でした。指示を与えた瞬間からAIの時計が動きます。自分が後から指示を入れるほど、その分だけアウトプットは後ろにずれます。AIへの指示投入を最優先にして、その後で自分にしかできない仕事（判断・会議・クライアント折衝）をする、という順序に変えるだけでアウトプット量が変わりました。
以前は「今やっているA社の作業が終わったらB社に着手する」という直列思考でした。今は「A社とB社の指示を先に投入してから、自分は自分の仕事をする」という並列思考になっています。
認知負荷の壁と、フォルダ名で乗り越えた話#
正直に言うと、最初は「どのウィンドウで何を動かしているか」がわからなくなる瞬間がありました。OSのウィンドウ切り替え（Alt+Tab）で増殖するVSCodeアイコンを見て、一瞬止まることが何度かありました。
ただこれは、試してみると思ったより大した問題ではありませんでした。ぼくのディレクトリ構成では、トップフォルダをクライアント名またはプロジェクト名にしています。VSCodeのタイトルバーにはそのフォルダ名が表示されるので、ウィンドウを見れば「このウィンドウはA社、こっちはB社」とすぐ識別できます。
命名規則を徹底していたことが、こういう形で役立ちました。整理癖が布石になっていました。
「AIに先に指示を与えきってから、自分にしかできない仕事をする」順序に変わった#
複数起動によって変わったのは速度だけではありません。仕事の順序が変わりました。
以前のぼくは「自分が手を動かしてから、AIに仕事を振る」という流れでした。自分の判断があって、それをもとにAIに指示する、という直列の発想です。
今は違います。朝の最初の仕事は「今日のAIへの指示を全プロジェクト分書き切ること」になっています。各ウィンドウに指示を投入してClaudeを走らせたら、自分は並行して会議に出て、クライアントと話して、判断が必要なところだけ戻ってきます。
「自分がブロッカーだった」という気づきが一番大きかったです。以前はAIの出力を待っていたのに、実はAIはぼくの指示を待っていました。ボトルネックはAIではなく、1ウィンドウしか開いていなかったぼく自身でした。
VSCode複数起動は、静かに「部下を増やすこと」に近い#
3ウィンドウを並列で動かしていると、ある考えが頭をよぎりました。
ぼくの直下には今、複数のプロジェクトリーダーとチームメンバーがいます。7〜8クライアント、20以上のプロジェクトが動いています。これが今の組織の形です。
ただ、複数のVSCodeウィンドウでClaudeを並列に走らせながら思いました——「これ、プロジェクトリーダーの仕事の多くを、ぼくが自分で回せてしまうのではないか」と。
各プロジェクトの方向性を設計して、課題を特定して、指示を書いて投入します。それをAIが実行する間に次のプロジェクトの指示を書きます。この繰り返しで、以前なら別の人間に委任していたような仕事量を、1人で処理できてしまう場面が出てきました。
以前部下への指示の解像度について書いたことがあります。「何をやるか」だけ渡して「どうやるか」は任せる、というあの話です。AIへの指示も同じ考え方が通じます。ただAIの場合、その「任せる」の範囲がさらに広い。AI時代にこの問いを再考すると、指示の設計こそがディレクターの仕事の核心だと改めて思います。
当然、現実の組織は単純ではありません。クライアントとの関係構築、現場の機微、チームメンバーの育成——それらはまだ人間が担っている部分です。「部下が要らなくなる」は誇張ですし、ぼくもそこまで言い切るつもりはありません。
ただ「ウィンドウを1つ増やす」という単純な行為が、ここまでレバレッジに直結するとは思っていませんでした。
まとめ：ブロッカーはAIではなく、1ウィンドウしか開いていなかった自分だった#
VSCodeを複数起動することで変わったのは、大きく3つです。
- 並列の壁が消えた：複数プロジェクトに対して同時にAIを走らせられる
- 指示投入が最優先になった：AIに先に仕事を与えきってから、自分の仕事をする順序に変わった
- 「自分がブロッカーだった」と気づいた：詰まりの原因はAIではなく、1ウィンドウ縛りの自分自身だった
認知負荷の問題（どのウィンドウかわからなくなる）は、トップフォルダをクライアント名にしておけば現実的に管理できます。Electronが重いという懸念は、32GB環境では都市伝説に近かったです。
今もこの体制を続けています。3ウィンドウ並列は現在のぼくの標準になりました。
「AIのせいで待っている」と思っていましたが、AIはぼくの指示を待っていました。ボトルネックの所在を間違えていたと気づいたとき、答えはあっさり見えました。VSCodeをもう1つ開くだけでした。
