数週間かけて丹念に作り上げたSSE（Server-Sent Events）を取り除きました。最初にSSEを提案し、実装を始めたのは私でした。そして議論の末に取り除くことを最終的に決めたのも、ほかならぬ私自身でした。
SSEを導入してからpollingに切り替えるまでの技術的な判断については、一緒に作業したチームメンバーが前回の記事にまとめています。
この記事では、その判断に至るまでの過程をたどりながら、AIとともに素早く答えを完成させる間に、ループの外側で何がさらに必要だったのかを扱います。
AIは与えられた問題を素早く解決する
QraはVizendでアプリケーションのデプロイを実行し、その状態を表示するサービスです。デプロイには数十秒、長い場合は数分かかります。当時私に与えられた課題は、ユーザーが段階ごとのデプロイの進行状況を確認できる機能を提供することでした。私は以前、別のプロジェクトで時間のかかる非同期処理の進行状況をSSEで可視化した経験を思い出し、今回も自然にSSEで問題を解決できるだろうと考え、その方向で進めました。
当時、私たちのチームはAIエージェントとともにワークフローを洗練させながら、SSEを実装し、検証し、修正していきました。リソースの問題からフロントエンドライブラリの選定まで、解決すべきことが次々と出てきましたが、SSEの実装は大きな困難もなくステージング環境まで進みました。こうしてSSEは順調に定着したように見えました。
実装と検証を繰り返すうちに、SSEは徐々に安定していきました。
問題を解決できたことは、最初の判断まで証明するわけではない
そんな中、Vizendプラットフォームの定期レビューを前に、本番環境の基準を改めて確認したところ、以前から念頭に置いていたステートレスな構成と水平スケーリングという条件を、再び重視するようになりました。Qraでデプロイ状態の変化を検知したインスタンスと、ユーザーとのSSE接続が確立されているインスタンスが異なる可能性があるため、即時に伝達するには別の中継経路が必要でした。しかしQraは特定のインフラが固定されたプロジェクトではなく、複数の環境をサポートするプラットフォームサービスでした。
そもそもQraの要件は 「ユーザーが デプロイの 進行 状況を 確認 できる ように する」であって、「SSEで リアルタイムに 伝達する」ことではありませんでした。しかしSSEを採用する方向に進んでからは、その方法をどうすればより安定して実装できるかに集中し、その選択自体を再検討しようとは考えられませんでした。
その要件に改めて照らしてみると、pollingには画面の更新遅延とリクエスト数の増加という代償があります。しかしこの画面の核心は、ユーザーがデプロイがどこまで進んだのか、失敗した場合はいつ、なぜ失敗したのかを確認できることにありました。画面の更新が数秒遅れても、デプロイそのものやユーザーの次の行動に大きな影響はなかったため、その代償はQraで許容できる水準だと判断しました。
また、1つの画面の即時性のために、中継経路や接続管理、バックエンドとフロントエンドの共通ルールまで新たに定義するのは過剰だと考えました。その後、チームメンバーやインフラチーム、Vizendプラットフォームチームと議論した結果、プラットフォームレベルのSSE基準はバックログに残し、QraからSSEを取り除きました。
この決定に至るまでには、異なる層にまたがる2つの問いがありました。「SSEは正常に動作するのか？」という問いは、AIの実行ループを通じて十分に確認できました。しかし、「Qraがこの運用上の責任を担うほど、即時性は重要なのか？」という問いには、実装結果がどれほど優れていても、そのループの中では答えられませんでした。
振り返りの中で組織学習理論におけるSingle LoopとDouble Loopという概念に触れたとき、その違いがより明確になりました。Single Loopが定められた目標の中で誤りを修正するものだとすれば、Double Loopはその目標と前提から改めて点検します。私が数週間取り組んでいたのは、SSEの完成度を高めるループでした。しかし一歩外側から眺めてみると、SSEそのものがQraに必要なのかを問う、2つ目の問いが残っていました。
何に重きを置くかを判断する感覚
新しい問題に直面すると、過去の経験や知識を抽象化し、現在の問題と似ている部分を探すようになります。ただしその次には、再び解像度を上げて、過去と現在の状況の違いを見なければなりません。
以前のプロジェクトでは、私はリードとして、決められた環境に適した基準を定めて推進することができました。しかし、複数の環境やチームを考慮しなければならないプラットフォームの一部であるQraでは、その基準を自分の判断だけで決めることはできませんでした。私はこの違いを基準として十分に優先できていませんでした。
一度うまく機能した方法なら、今回も正しいはずだという確信を持つことがあります。その確信が強いほど、現在の状況の違いを高解像度で改めて見直すことを忘れやすくなります。
抽象化によって似ている点を見つけ、高解像度で違いを見極めた後は、何を優先するかを決めなければなりません。私はこのとき、複数の要素の間の重みを見極める感覚を、ある種のTasteだと考えています。ここでいうTasteは、単なる好みや審美眼だけでは説明しきれません。
この感覚について、Andrew Ngは、人々がTasteと呼ぶ人間の貢献を、文脈上の優位性（context advantage）と表現しました。製品やユーザーの近くで蓄積された情報と経験が、新たな判断の材料になるという意味です。
判断に必要な材料を、あらかじめ文書とフィードバックだけですべて盛り込んでおくのは困難です。仕事が進む中で新たに明らかになる文脈もあり得ますし、同じ事実であっても、その状況における目的や役割、責任によって、何をより重視するかは変わり得ます。
Qraで変わったのは、判断の材料ではなく、その材料に置いた重みでした。
判断を選択へと移す力
AIが私の選んだ答えを素早く完成させるほど、最初の問いは検討対象から遠ざかっていきました。SSEがうまく動作するかどうかは、実行ループを通じてすぐに確認できましたが、その方法を使い続けるべきかどうかは、ループの外で問うべきこととして残されていました。
基準を満たしているかどうかはループ内で確認できますが、その基準を適用し続けるかどうかは、ループの外で改めて検討する必要があります。
仕事が進んでいる間も、人は最初の判断が現在の目的と役割に合っているかを考え続けなければなりません。それに応じて、現在の方法を続けるのか、手を加えるのか、変えるのかを決める必要があります。
Human Agencyは、実行の速度を高めることではなく、すでに選択した答えを再び検討し、その結果に責任を持つことに表れます。
参考資料
- HKK、リアルタイム性の確保：SSEの導入からPollingへの回帰まで （Nextree、2026-05-07）
- Andrew Ng、The Batch Issue 359 （2026-06-26）
- Chris Argyris、Double Loop Learning in Organizations （Harvard Business Review、1977-09）
TaeZ