はじめに
AIが考えてる間、何してますか？ 🤔
Claude CodeやGitHub Copilotを使って開発していると、AIの応答を待つ時間が結構あります。数秒で返ってくることもあれば、複雑なタスクだと数分かかることも。
……ぼーっと待ってたりしませんか？
私はこの「待ち時間」がもったいなくて仕方ありませんでした。だって、AIが頑張ってる間に人間がボケっとしてるの、なんかもったいなくないですか？ 🙄
で、試行錯誤の末にたどり着いたのが「AIエージェント3体同時稼働 + モニタ4枚」という、ちょっとヤバめの構成です。
人間が手を動かしている間にAIが考え、AIが考えている間に人間が別の作業をする。この二重の並列化で、体感的な待ち時間をほぼゼロにできました 🎉
この記事では、私がどうやって並列度を最大化しているか、デスク写真付きで全部お見せします。
🏗️ 全体像：人間×AIの二重並列化
まず全体像から。私の日常業務は大きく5つのストリームで構成されています。
考え方はシンプルで、自分の仕事をシステム設計する ⚙️ ということです。
マイクロサービスアーキテクチャと同じ発想で、各ストリームを独立したサービスとして設計します。依存関係を最小化して、非同期で回す。ブロッキングI/Oを排除して、ノンブロッキングで全部回します。
……と書くと大げさですが、要は「手が空いたら別の作業をするを徹底しているだけ」だったりします 😂
🪟 VSCode 3窓戦略：AIを3体同時に走らせる
中核になるのはVSCodeでの開発作業です。ここで3つのウィンドウを使い分けています。
🔬 1-1. リサーチ（技術調査）
- 新しい技術やツールの検証・実験
- PoC（概念実証）の作成
- 専用のディープリサーチスキルを作成して情報収集 🔍
- 調査結果はNotionやQiitaの記事に展開します（後述のアウトプット循環に接続）
🏃 1-2. 短期的開発（スプリント作業）
- 現在のスプリントのSBI（Sprint Backlog Item）に対応
- チームとして最も優先度が高い作業
- 割り込みが入りやすいので、こまめにコミットして中断に備えます
🚀 1-3. 中長期的開発
- チームの生産性向上や開発プロセス改善に関わる取り組み
- 直近の納期には紐づきませんが、中長期的にチーム全体の速度を底上げするものです
- スプリント作業の合間や待ち時間に進めます
なぜ3つに分けるのか？ 🤷
ポイントは常にAIが何かしら動いている状態を作ることです。
たとえばこんな流れです：
- 🏃 短期開発のAIに「このSBIの実装をお願い」と指示を出します
- ⏳ AIが考えている間に、中長期開発のウィンドウに切り替えて前回のAI出力をレビュー
- 🚀 レビューが終わったら次の指示を出します
- ⏳ 2つのAIが動いている間に、リサーチのウィンドウで技術調査のAIを起動
- 🤖🤖🤖 3つのAIが並行稼働！ 人間は各ウィンドウを巡回しながらレビューと判断に集中します
人間の役割は「考えること」と「判断すること」に特化します。 手作業はAIに任せて、人間はオーケストラの指揮者になります 🎵
……ただし、3体同時に指揮するので死ぬほど疲れます 😇 脳のCPU使用率が常に90%超えてる感じです。慣れるまでは1体から始めることをおすすめします。
🖥️×4 モニタ4枚の物理レイヤー
私は4枚のモニタを使って、画面切り替えなしで全ストリームを同時に視認できる環境を構築しています。
| # | モニタ | サイズ | 解像度 | 用途 |
|---|---|---|---|---|
| 1 | 🖥️ メインモニタ | 28インチ | 2560x1440 | VSCode開発 |
| 2 | 💻 MacBookモニタ | 14インチ | 1800x1169 | VSCode開発 |
| 3 | 🖥️ サブモニタ | 26インチ | 1920x1080 | Teams / メール |
| 4 | 📱 iPad SideCar | 11インチ | 1194x834 | 情報収集 / 情報展開 |
ここで大事なのは Alt+Tabを押す回数を減らすこと ⌨️
ウィンドウを切り替えるたびに「あれ、さっき何やってたっけ……」が発生します。これがコンテキストスイッチのコストです。モニタを物理的に分ければ、視線を動かすだけで別のストリームに移れます 👀
メインとMacBookの2画面でVSCodeを開きっぱなし、Teamsの通知は左のサブモニタに常時表示、iPadでは技術ニュースをチラ見。全部が視界に入っている状態です。
エンジニアならピンとくると思いますが、これってメモリとCPUのトレードオフに近いんです。物理的なスペース（メモリ）を使って、切り替えコスト（CPU時間）を削減しているわけです。
デスクは多少カオスになりますが、それは仕方ありません 😇
⏳ AIの応答待ち = ゴールデンタイム
AIに指示を出した後の数十秒〜数分。この時間をどう使うかで1日の生産性が変わります。
| 待ち時間 | 活用先 |
|---|---|
| 🤖 AIの応答待ち | 別のVSCodeウィンドウで他の開発を進める |
| 👀 レビュー待ち | リサーチまたは記事執筆 |
| ☕ 打ち合わせの合間 | Teams返信・メール処理 |
| 🤖💤 AIの長時間タスク実行中 | Notion/Qiita記事の作成 |
📺 情報収集もながらで回す
開発中のBGMとして技術系YouTubeをながら聴きしています。
「ながら聴きなんて意味あるんですか？ 🤨」と思うかもしれません。でも目的は深い理解ではなくトレンドの把握です。
「あ、Gemma 4出たんだ」「Cloudflareがこんなサービス始めたのか」くらいのレベルで十分です。気になったものだけ後でちゃんと調べます。アンテナを張り続けることが大事なんです。
ただし、設計や文章を書くときはやりません 🙅 認知負荷が高いタスクと聴覚のインプットは相性が悪いです。手を動かすだけの作業中に限定しています。
💬 コミュニケーションは非同期で
| チャネル | 確認頻度 | 対応方針 |
|---|---|---|
| 💬 Teams | 常時（通知ベース） | 即レスが必要なものはすぐ対応、それ以外は区切りの良いタイミングで |
| 📧 メール | 1日2〜3回 | まとめて処理。緊急のものはTeamsで来るはずです |
| 🗣️ 打ち合わせ | スケジュール通り | 事前にアジェンダを確認、準備してから臨みます |
Teamsの通知はサブモニタに常時表示しているので、メンションが来たら視界に入ります。ただし即座に反応するのは本当に急ぎのものだけです。それ以外はAIの応答待ちのタイミングでまとめて返します 📨
「返信遅い」って言われたことは……今のところありません。たぶん。
🔄 インプット⇄アウトプット循環
知識は溜め込むだけだとチームのボトルネックになります。これ、エンジニアなら「あるある」だと思います。
だから私はインプットとアウトプットを意図的に循環させています。
具体的にはこうです：
- 📺 YouTube/ブログで気になった技術を見つける（インプット）
- 🔬 VSCodeのリサーチウィンドウでPoCを作って検証する（検証）
- ✍️ Notionでチーム内に共有 or Qiitaで外部発信する（アウトプット）
- 💡 記事を書く過程で新しい疑問が出てくる（次のインプットへ）
このサイクルが回ると、情報収集と記事執筆が「やらなきゃいけない作業」から「自然に回る習慣」になります ✨
なぜ情報展開に時間を使うのか
「忙しいのに記事なんて書いてる場合ですか？ 😤」って言われそうですが、逆だと思っています。
自分の頭の中にしかない知識は、自分がいないと使えません。それってチームにとっての SPOF(Single Point of Failure) ですよね？ 文書化してNotionに置けば、自分がいなくても他のメンバーが参照できます。
知識は共有して初めて価値になります。 これはガチです 🔥
📅 ある1日のタイムライン
実際の1日はこんな感じです。
見てほしいのはリサーチが1日に4回散らばっているところです 👆
これは「リサーチの時間を取る」のではなく、「AIの応答待ちや気分転換のタイミングで15分だけ技術調査する」というスタイルです。短時間で区切ることで、メインの開発作業を中断せずにインプットを確保できます。
あと、短期開発とコミュニケーションが交互に入っているのも意図的です。Teamsの返信はAIの応答待ちに合わせて処理するので、開発のフロー状態を崩さずに済みます 🧘
🎯 まとめ：並行作業の3原則
結局やっていることは、エンジニアとしては当たり前の考え方を自分自身の仕事のやり方に適用しているだけです。
| エンジニアリングの常識 | 仕事への適用 |
|---|---|
| ⚡ 非同期処理で待ち時間を有効活用 | → AIの応答待ちに別の作業をする |
| 🖥️ ハードウェアでボトルネック解消 | → モニタ4枚でコンテキストスイッチを減らす |
| 🛡️ SPOFを排除 | → 知識を文書化して共有する |
「もっと速く仕事がしたい」と思ったら、まずは自分の仕事のアーキテクチャを見直してみてください 🏗️