【ITニュース解説】Stop Letting Five Coding Agents Ping You. Answer Them in Batches From One Inbox

最近のソフトウェア開発では、AIコーディングエージェントがコードの生成、リファクタリング、テストの実行など、様々な開発タスクを支援するようになってきた。これらのエージェントは生産性向上に貢献する一方で、開発者に新たな課題も提示している。特に問題となるのは、複数のエージェントが同時に動作し、その都度、開発者に承認や選択を求める「割り込み通知」である。例えば、テスト実行の許可、パッケージのインストール提案、複数のアプローチからの選択など、頻繁に画面にバナーとして表示されたり、ターミナルに表示されたりするこれらの通知は、開発者の集中を妨げ、思考の流れを寸断してしまう。開発者が特定の機能実装に集中している最中に、複数のエージェントから個別のタスク進行状況がリアルタイムで報告されると、開発者は同時に異なる複数の作業領域に引きずり込まれる感覚に陥り、本来の作業から意識が引き離されてしまうのだ。

このような割り込みが人間の生産性や精神状態に与える影響は、長年の研究テーマである。2005年の研究では、情報労働者（ソフトウェア開発者を含む）が平均11分で作業を切り替えるか、割り込みを受けることが判明した。そして、割り込みを受けた作業に再開するまでには、平均25分以上もの時間がかかっていた。この中断中に、人々は平均2つ以上の別の作業を行っていた。特に、集中を要する作業中、作業の自然な区切りではないタイミング、そして全く異なる作業領域へ引きずり込まれる割り込みが、特に有害であると報告されている。さらに、2014年の研究では、わずか2.8秒程度の短い割り込みでも、作業におけるエラー率が2倍に増加し、4.4秒の割り込みでは3倍に増加するという結果が出ている。別の2008年の研究では、割り込みを受けた作業は完了が早まる傾向があるものの、その代償として「より多くのストレス、高いフラストレーション、時間的プレッシャー」が伴うことも示されている。これらの研究はAIコーディングエージェントに特化したものではないが、開発者がタスクから引き離されることによって生じるコストの形を明確に示しており、複数のエージェントからの絶え間ない通知が、まさにこの「タスクからの引き離し」を引き起こすと言える。

ここで重要なのは、エージェントが待つコストと、開発者が思考を中断されるコストを比較することだ。エージェントは開発者からの応答を待っていても、その作業の状態（プロンプトや作業ツリー）を正確に保持できる。たとえ10分後に開発者が戻ってきても、エージェントは中断した場所から作業を再開できるのだ。エージェントが待つことによるコストは、そのタスクに費やされる「ウォールクロックタイム」（実経過時間）のロスに過ぎない。一方で、開発者の思考は全く異なる性質を持つ。開発者が特定の機能を実装する際に頭の中で構築している、半ば完了した一連の意思決定や文脈（コンテキスト）のスタックは、通知によって集中が途切れるとその大部分が失われてしまう。一度失われた思考の流れを再構築するには、手作業で最初からやり直す必要があり、これが大きな時間のロスと精神的負担につながる。以前のテスト内容を忘れてしまい、同じテストを繰り返すといった具体的な問題も発生する。実際、通知を即座にではなく、開発者の作業における「ブレークポイント」（区切りが良いタイミング）まで保持してから一度にまとめて配信するシステムの研究（2008年）では、フラストレーションの軽減と反応時間の短縮という効果が確認されている。このシステムによる通知の平均遅延はわずか1.5分であり、エージェントを数分待たせることと、開発者の貴重な集中力を維持することのトレードオフは明らかだ。ほとんどの作業において、エージェントが待つことの方が、開発者のコンテキストが失われるよりもはるかにコストが低いと言える。

この課題に対処するための具体的なアプローチは、エージェントからの「プッシュ型」の割り込み通知をオフにし、代わりにそれらの通知を「プル型」で、つまり開発者が自分のタイミングで確認できるようにすることである。多くのAIコーディングエージェントには、このような通知設定を無効にする機能が備わっている。例えば、Claude Codeというエージェントでは、設定ファイル（/.claude/settings.json）内でpreferredNotifChannelを"notifications_disabled"に設定することで、デスクトップ通知を無効にできる。同様に、Codexというエージェントでも、設定ファイル（/.codex/config.toml）内でtui.notificationsをfalseに設定することで、ターミナル通知をオフにすることが可能だ。通知をオフにしても、エージェントの進捗を見失うわけではない。Claude Codeのフック機能を利用すれば、許可プロンプトなどのイベントが発生した際に、その情報をJSON形式で取得し、それをログファイルに追記するように設定できる。例えば、jqコマンドと組み合わせることで、各エージェントからの待機メッセージをタイムスタンプ、現在の作業ディレクトリ、メッセージ内容と共に一行のログとしてファイルに記録できるのだ。これにより、複数のエージェントからの要求がログファイルという「一つの受信トレイ」に蓄積され、開発者は自分の好きなタイミングでそのログを確認し、まとめて処理できるようになる。

ログファイルに蓄積されたエージェントからの要求は、開発者が「消費者」として扱うべき「キュー」となる。このキューから要求を取り出して処理するタイミングを、開発者自身がコントロールすることが重要だ。最も効果的なのは、自分の作業における明確なブレークポイント、つまり区切りの良いタイミングでキューをチェックすることである。具体的なブレークポイントとしては、コードをコミットした後、テストスイートを実行した後、あるいは次の新しい関数の記述を始める前などが考えられる。キューを確認する際には、最も古い要求から順に処理することが推奨される。これは、特定の簡単な質問ばかりに答えてしまい、緊急度の高い、あるいは時間のかかる質問を待たせ続けることを防ぐためだ。また、キュー内の要求に対しては、「回答すること」に集中し、「レビューすること」は別の作業として扱うべきだ。許可プロンプトや単純な質問は数秒で解決できるが、エージェントが完了したコードの差分を確認する作業は、それ自体が集中を要する別の作業領域であるため、個別にスケジュールを組むのが望ましい。ただし、エージェントを長時間ブロックしないように、例えば25分に一度はキューをチェックするなど、定期的な確認の目安を設けることも有効である。

このような複数のAIエージェントからの通知管理と、開発者の集中維持を支援するために設計されたツールの一つに「Hermes IDE」がある。これは、各エージェントをそれぞれ独自のターミナルと作業ツリーで実行することで、エージェント間の干渉を防ぎつつ、その状態を一元的に管理する統合開発環境だ。Hermes IDEの主要な機能は、各セッションのステータス（作業中、承認待ち、質問あり、完了など）を明確に表示することにある。特に、開発者からの対応を必要としているエージェントの数を「アテンションインボックス」に表示し、ショートカットキー（macOSでは⌘I、Windows/LinuxではCtrl+Shift+I）一発で、最も長く待っているエージェントのターミナルにジャンプできる機能が提供される。Hermes IDEは、開発者の承認プロンプトに自動で応答したり、勝手にターミナルに何かを入力したりすることはなく、あくまで開発者が自分で判断し、操作するための環境を提供する。システム通知は、エージェントが開発者からの対応を待っているか、または作業が完了したときにのみ発生するが、現在開発者が actively に見ているセッションについては通知しないようになっている。これは、通知が依然として割り込みになりうるため、アテンションインボックスのカウントを、ブレークポイントで定期的にチェックすべきものとして扱う、という考え方に則っている。Claude Code単体での利用であれば、その組み込みのステータス表示機能で十分な場合もあるが、Claude Code、Codex、そしてその他の複数のエージェントを一つの画面で同時に扱う場合には、Hermes IDEのような統合環境が開発者の生産性を高める助けとなる。

もちろん、常にエージェントを待たせるべきではない例外も存在する。例えば、ホットフィックス対応のような緊急性の高い作業や、チームメイトがその結果を待っているデプロイ作業など、エージェントの応答が他の誰かの作業パスをブロックするような「クリティカルパス」上にエージェントがいる場合は、すぐに回答すべきである。また、現在開発者が作業しているコードに関する質問である場合も、すぐに回答することが有益であると、過去の研究では示されている。彼らは、現在の作業領域内での割り込みは、むしろ助けになると感じていたからだ。しかし、割り込みの内容が現在の作業に関連しているか否かが、割り込みによるコストに有意な違いをもたらさないという研究結果もあるため、この例外は慎重に適用すべきだ。これら限られた例外を除けば、基本的には他の全てのエージェントからの要求は、開発者のブレークポイントまで待たせるべきだと言える。AIコーディングエージェントからの通知を、開発者が能動的に制御する考え方は、イベント駆動システムにおけるキューの処理と非常に似ている。エージェントからの通知をキュー内のメッセージとして扱い、開発者という「コンシューマー」が、いつそのメッセージを取り出して処理するかを決定することで、AIコーディングエージェントの恩恵を最大限に享受しつつ、集中力を維持し、ストレスを軽減しながら生産性を向上させることが可能になる。