2026年9月1日 11:06 AM

第5回：夜勤室の引き出しに、白紙のノートを置く――運用・監視の座席表と、“育つ”エージェント

Cloud Endpoints と呼んでいる、Windows 365 や Azure Virtual Desktop のソリューションエンジニアを務める曳野（ヒキノ）と申します。「SE曳野の仮想デスクトップとAI」と題して、私たちの仮想デスクトップサービスとAIやエージェントの関係性を中心にブログをお届けしています。第5回目のテーマは「夜勤室の引き出しに、白紙のノートを置く」です。

第1回では、エージェントを「どこで動かすか」という問いから、管理された実行環境である Windows 365 for Agents をご紹介しました。第2回では、“社員証”にあたる Microsoft Entra エージェント ID と、“上司”にあたるスポンサーの必要性を。第3回では、人とエージェントの仕事の持ち方を決める “動く座席表” の描き方を。そして第4回では、その座席表をコンタクトセンターという現場に持ち込みました。

第4回の現場は、人が話している現場でした。今回は、人が寝ている時間も止まらない現場へ持っていきます。IT運用、監視、サービスデスク。24時間365日、誰かが画面を見ていなければならないとされてきた場所です。

執筆者：日本マイクロソフト株式会社　クラウド＆AIソリューション事業本部　ソリューションエンジニア曳野洋幸 | 2026年9月1日

はじめに：なぜ、次の現場が「運用・監視」なのか

コンタクトセンターと運用・監視は、一見よく似ています。どちらも交代制で、どちらも「席」があり、どちらも件数で語られます。しかし、決定的に違う点が2つあります。

1つ目は、波の形です。コンタクトセンターの一日はなだらかな山でした。朝に増え、昼に落ち、夕方にまた上がる。ところが運用・監視の一日は、山ではなく階段です。何も起きない時間が大半を占め、起きるときは、関連する事象が一斉に鳴ります。1件の障害が、20件のアラートを生むこともあります。

2つ目は、同じことが何度も起こるという点です。コンタクトセンターの入電は、お客様が違えば話も違います。しかし運用の現場では、先月と同じアラートが、今月もまた鳴ります。 同じ機器の、同じ症状に、同じ手順で対処する。この繰り返しが、運用という仕事の大きな部分を占めています。

そしてこの2つ目こそが、今回の本題につながります。同じ仕事を何度も繰り返す現場では、エージェントの判断そのものを、少しずつ定型化していけるからです。

夜勤室の、引き出しの中のノート

比喩から入らせてください。運用の現場を訪ねると、夜勤の席の引き出しに、たいてい一冊のノートがあります。正式な手順書とは別の、誰が書き始めたのか分からない、書き足され続けてきたノートです。

「このアラートが鳴ったら、まず◯◯を見る。だいたい△△が原因」

「このエラーは3分待つと自然に消える。慌てて再起動しないこと」

「××の画面は反応が遅い。二度押ししないこと」

このノートは、最初は白紙でした。 誰かが夜中に困り、考え、対処し、翌朝「これは次の人も引っかかるな」と思って1行書いた。それが積み重なって、今の厚さになっています。

新人が配属された最初の月は、このノートを持っていても、一つひとつ考えながら手を動かします。しかし3か月も経つと、典型的なアラートには考えるより先に手が動くようになる。半年経つと、自分でノートに書き足す側になります。

熟達とは、知識が増えることであると同時に、いちいち考えなくて済む範囲が増えることでもあります。

今回お話ししたいのは、エージェントにも同じことが起きる、という話です。そして、そのノートをどこに置き、誰が書き足し、誰が承認するのか、という話です。まずは第3回・第4回と同じ手順で、席から決めていきましょう。

1本のアラートを、作業に分ける

第4回では1本の電話を分解しました。今回は1本のアラートを分解します。

検知 → 重複・関連の集約 → 一次切り分け（トリアージ）→ 関連情報の収集 → 定型手順の実行 → 影響範囲の確認 → エスカレーション判断 → 関係先への連絡 → 復旧確認 → 記録・再発防止の検討

「監視業務」とひとまとめにすると、24時間人が張り付く仕事に見えます。しかし分けてみると、性質のまったく違う作業が並んでいます。第3回の3つの問い（①正解を客観的に確認できるか、②間違えても戻せるか、③人であることに価値があるか）で席を割り当てると、こうなります。

ここで注目していただきたいのは、上から3行です。

検知・集約・一次切り分け・情報収集。この4つは、読むだけで、何も壊しません。 件数が最も多く、正解を後から確認でき、間違えてもやり直せる。第3回の基準に照らせば、これ以上ないほど典型的なエージェント席の仕事です。

そして同時に、人が最も消耗している仕事でもあります。深夜に起こされて、結局「対応不要」だったという経験は、運用に携わった方なら覚えがあるはずです。

この現場のエフェメラルは、意味が少し違う

第3回で、エージェントの席は固定しない――必要なときだけ現れ、終われば消えるとお話ししました。第4回では、それを「朝のピークは20席、深夜は0席」という繁閑差の話として説明しました。運用・監視では、この意味が少し変わります。

この現場で長年コストになってきたのは、忙しさではなく、待機です。何も起きない8時間でも、当直者は席に座っていなければなりません。「何も起きないこと」を確認するために、人がそこにいる。これが24時間運用の構造的な負担でした。

エージェントの席なら、その待機が要りません。アラートが鳴った瞬間に席が現れ、片付いたら消える。何も起きない深夜の席数は、ゼロで構いません。

ただし、ここに1つだけ例外があります。一次切り分けの最初の数十秒です。障害の初動では、環境が立ち上がるのを待つ時間が惜しい場面があります。

第4回でご紹介したとおり、Windows 365 for Agents には、実行時間に応じた従量課金のオンデマンド型に加えて、低遅延の応答が必要な用途向けに、すぐ使える状態を保つ「常時利用可能」オプションが用意されています（米国地域で、オンデマンドは1時間あたり0.40 USD・1時間単位に切り上げ、常時利用可能はCloud PCあたり月額5 USD。いずれも執筆時点の米国地域の価格で、地域によって異なります）。

運用の現場では、この2つを組み合わせるのが現実的です。

「常に0席」ではなく、「最前列だけ温めて、後ろは呼んだときに出す」。運用・監視におけるエフェメラルは、この形になります。

エージェントの席をつくる ― Windows 365 for Agents

席が決まったら、実際に用意します。Windows 365 for Agents は、エージェント用途のために用意された新しい種類のCloud PCで、Microsoft Entra参加・Microsoft Intune管理という企業の管理境界の中で動きます。

管理者が扱うのは個々のデバイスではなく、プールです。エージェントは「あのPCを使わせてほしい」ではなく、「実行できる環境を1つください」と要求します。そして1回のタスクは、次の5つのフェーズをたどります。

Prepare（用意する）→ Acquire（借りる）→ Connect（つなぐ）→ Act（働く）→ Release（返す）

運用の現場で押さえておきたい性質も、第4回と同じです。最大実行時間の上限はなく（数秒のタスクも、数日にまたがる作業も扱えます）、30分間まったく動きがないセッションは自動的に回収され、セッション内の状態は持ち越されません。作業の途中経過は、外部に保存する前提で設計します。

そして、この現場にはAPIがない

第1回で、こうお伝えしました。理想は「エージェント ⇄ API ⇄ 業務システム」。しかし現実には、APIのない基幹システムや独自アプリが残っている、と。

運用の現場は、その壁が最も分厚い場所です。

ネットワーク機器、ストレージ、UPS、空調、入退室管理のベンダー製管理コンソール
構成管理台帳や作業申請といった、長く使われてきた社内システム
参照はAPIで取れるが、設定変更は管理画面からしか通らない機器
外部ベンダーの状態を確認するための、SaaSの管理ポータル

ただし、順序を間違えないでください。APIがあるなら、APIを使うのが先です。 APIで届く操作をわざわざ画面操作に置き換える理由はありません。速く、安く、壊れにくいのはAPIのほうです。

Windows 365 for Agents が要るのは、APIでは届かない場所にだけです。画面を見て、クリックして、入力して、結果を読む。人間がやっていたことを、そのまま企業の管理境界の中で実行する。「APIの整備を待つ」か「そこだけ人が残る」かの二択だった場所に、三つ目の選択肢を置く――それが、この現場でのWindows 365 for Agents の役割です。

なお、Microsoft Copilot Studio の computer use から、このCloud PCプールを実行先として指定できます（プレビュー）。

人の席についても触れておきます。当直者やオンコール担当者は、自宅からでも拠点からでも、同じ管理された環境に入れる必要があります。データを持たない専用デバイスの Windows 365 Link、時間で分け合える Windows 365 Flex は、シフトとオンコールが混在するこの現場でも、そのまま人の席として使えます。

深夜1時、アラートが鳴る

では、実際に1本流してみましょう。深夜1時、あるバッチ処理の遅延を示すアラートが上がったとします。

① 検知と集約（エージェント席）
関連するアラートが計12件、数分のあいだに上がりました。エージェントはこれを1件の事象としてまとめます。人が最初に見るのは、12件の断片ではなく、1件のまとまりです。

② 一次切り分け（エージェント席）
過去の記録、直近の変更履歴、依存関係を突き合わせ、「夕方に適用された設定変更が起点である可能性が高い」という見立てを立てます。

③ 情報の収集（エージェント席・ここで画面操作）
必要な情報の一部は、APIを持たないベンダー製の管理コンソールにしかありません。エージェントはCloud PCを1台借り、その画面を操作して該当の状態を確認します。読むだけです。何も変更しません。

④ 定型手順の実行（エージェント席）
ノートに書かれた手順どおり、影響のない範囲で再実行を1回だけ試みます。上限は1回。これは後ほど重要になります。

⑤ 影響範囲の確認（共同席）
復旧しませんでした。エージェントは影響範囲を整理し、「翌朝の業務開始までに間に合わない可能性がある」という判断材料をそろえます。

⑥ 境界に触れたら、止まる（統制）
ここから先は構成変更を伴います。あらかじめ決めたしきい値に触れたため、エージェントは自分で突破せず、人に判断を求めます。 第1回でお話しした、ガバナンスループ＝ブレーキとハンドルです。

⑦ エスカレーション（人の席）
オンコール担当者が起こされます。ただし、起こされ方が違います。手元には、まとめられた1件の事象と、見立てと、確認済みの状態と、試した手順の結果が、すでにそろっています。「何が起きているか調べる」ところから始めなくてよいのです。

⑧ 復旧と記録（人の席 → エージェント席）
人が判断して復旧させ、記録の作成と関連システムへの反映はエージェントが実行し、人が確認して承認します。

⑨ 席を返す（Release）
Cloud PCはリセットされ、実行能力がプールに戻ります。第4回でお伝えしたとおり、消えるのはセッション。残るのは、記録と監査ログと、責任の所在です。

なお、⑥の場面では、人が同じセッションをリアルタイムに観測し、必要に応じて操作を引き取れます。エージェントの接続を切らずに、人がその画面に入れる設計です。第1回でご説明したヒューマン・オン・ザ・ループ――「見ながら、代われる」――が、深夜の現場では特に効きます。

ここからが本題：二度目のアラートを、どう扱うか

さて、ここまでは第4回の応用でした。ここからが第5回の本題です。

翌月、まったく同じアラートが鳴りました。

このとき、エージェントは①から⑨をもう一度、最初から同じようにたどるでしょうか。もしそうなら、それは自動化ではありますが、学習ではありません。 三度目も、四度目も、同じだけ考え、同じだけ時間とコストをかけることになります。

冒頭のノートを思い出してください。人間の運用者は、二度目には同じだけ考えません。「ああ、あれか」で手が動きます。

エージェントにも、同じことをさせたい。そのためには、エージェント席の中身をもう一段開けて見る必要があります。

エージェント席の中を、もう一段開けてみる

第3回で、座席を「エージェント席／共同席／人の席」の3つに分けました。あれは「その仕事を誰が持つか」という軸でした。

ここで開けるのは、別の軸です。エージェント席に来た仕事を、どうやって判断するか。 判断のしかたは、3つあります。

呼ぶ順番は、上からです。 まず手順の席を見る。そこに書いてあれば、考えずに実行して終わり。書いていなければ考える席へ。考える席でも決められない、あるいは決めてはいけない境界に触れたら、人の席へ渡す。

番号が小さいほど、先に呼ばれ、速く、安い。番号が大きいほど、対応できる幅が広く、遅く、高い。これは優劣ではなく、呼び出しの順序です。そして、ここが一番大事なところです。

導入した直後、手順の席は空っぽです。

ノートが白紙なのと同じです。書いていないのだから、参照しようがありません。だから最初は、ほとんどすべての判断が考える席に流れます。毎回LLMが考える。毎回、時間とコストがかかる。

その状態から、どう厚くしていくか。 それが「育つ」ということの中身です。

ノートは、最初は白紙である ― 3つの段階

同じ判断を何度も繰り返したら、それを手順として書き出し、次からは考えずに実行する。これを続けていくと、3つの席の比率が、時間とともに移り変わっていきます。

Stage 1 は、ほぼ白紙のノートです。何を見ればいいのかも分からないので、毎回一から考えます。この時期にコストと時間がかかるのは、失敗ではなく仕様です。

Stage 2 で、ノートが厚くなり始めます。よく鳴るアラートから順に手順が書き出され、半分が「考えずに済む」ようになります。同時に、人が呼ばれる回数も減っていきます。人が呼ばれていた理由の多くは、「エージェントが決められなかったから」だったからです。

Stage 3 になると、ほとんどの判断がノートで決まります。考える席が呼ばれるのは、前例のない事象が来たときだけです。これは、熟練の運用チームの姿とよく似ています。

なお、この表は考え方をお伝えするための整理であり、公式の成熟度モデルでも、保証された数値でもありません。進み方は現場によって大きく違います。同じ事象が繰り返し起きる現場ほど速く進み、毎回条件が違う現場ほどゆっくり進みます。 運用・監視が最初の現場として向いているのは、まさに前者だからです。

育つことの値打ちは、安さではない

「LLMを呼ぶ回数が減るなら、安くなりますね」――そのとおりです。ですが、順番を間違えないでください。一番大きな値打ちは、安さではありません。 順に挙げます。

1つ目：説明できるようになる。
書き出された手順は、同じ入力に対して同じ答えを返します。これは監査の場面で決定的な差になります。「なぜこの操作をしたのか」という問いに対し、「この条件に合致したので、この手順を実行しました」と答えられる。条件と手順が文書として存在し、いつ誰が承認したかも残っている。無人の時間帯に自動で動くものほど、この性質が要ります。

2つ目：速くなる。
考える席は秒から分を要しますが、手順の席はミリ秒です。深夜の初動で、この差は体感できる大きさになります。

3つ目：安くなる。
考える席を呼ぶ回数そのものが減ります。ここで起きているのは、少し直感に反することです。ふつう、システムを賢くしようとすれば、より大きなモデルとより多くの計算が要り、コストは上がります。ところがこの構造では、成熟するほど、1件あたりの判断は軽く、速く、安くなります。

第3回で、「考えるコストと、動かすコストは分けて捉える」とお伝えしました。育つ仕組みが効くのは、このうち考えるコストのほうです。動かすコスト（実行環境）は仕事量に比例しますが、考えるコストは、運用を重ねるほど逓減していきます。 この差は導入1年目にはほとんど見えませんが、3年目に効いてきます。

勝手には育たせない ― 影のように並走させてから、昇格させる

ここまで読んで、不安になった方がいるはずです。「エージェントが自分でルールを作って、自分でそれを使い始めるのか」と。

いいえ。そこは、人が止めます。

書き出された手順の候補は、いきなり本番の判断に使いません。まず、判断はさせるが、実行はさせない状態で並走させます。実際の運用ではこれまでどおり考える席が判断し、その隣で、新しい手順の候補が「自分ならこう判断した」を記録し続ける。影のように、ついて回るだけです。

そして一定期間、両者の答えが十分に一致し続けたことを確認してから、人が承認して手順の席へ入れます。この設計には、2つの原則があります。

原則	意味
入口は人だけ	手順の席に何かが入る経路は、人の承認ただ一つ。機械が自分で追加することはない
出口も人が引ける	結果が悪化した手順は、外す・止める判断を人ができる。入れっぱなしにしない

そして、承認するのは書いた本人ではなく、その業務に責任を持つ人です。第2回でお話ししたスポンサーが、ここで再び登場します。エージェントの目的とライフサイクルに責任を持つ人が、「この判断を、今後は考えずに実行してよい」と決める。

第2回でお伝えした「自律性は与えるものではなく、実績によって獲得させるもの」という原則を、覚えていらっしゃるでしょうか。あれは、エージェント全体に対する話でした。同じことが、一つひとつの判断に対しても成り立ちます。並走させ、実績を見て、人が承認して、初めて昇格する。

ノートに書けないことは、人が書く

もう1つ、大事なことをお伝えしておきます。

繰り返しから書き出される手順は、「何をするか」しか写し取りません。

人が書いた正式な手順書には、こう書いてあったとします。

該当プロセスを再起動する

ただし冗長構成が健全であることを確認してから行う

再実施は1回まで

2回失敗したら、下位層の問題を疑い、人へ渡す

全系が同時に落ちているときは、実施せず即エスカレーション

このうち、繰り返しの実績から自動的に書き出されるのは、1行目だけです。2行目以降は出てきません。

理由は、考えてみれば当たり前です。実績には、やらなかったことが残らないからです。「2回目はやめておいた」という判断は、記録の上では「1回で直った」と区別がつきません。「全系が落ちていたので実施しなかった」という判断は、そもそも実行の記録として残りません。

つまり、「いつやめるか」「なぜそうするのか」は、誰かが意図して書いた文書の中にしか存在しません。

だから、ノートがどれだけ厚くなっても、こういうものは人が書き、人が渡し続ける必要があります。

再試行の上限
実施してはいけない前提条件
何を「別の障害」として扱うか
どのサービスが業務に直結し、どれが待てるか

参考になる実装があります。Azure Monitor の Azure Copilot Observability Agent には、カスタム指示という仕組みがあります。「どのアラートを関連づけるか」「どのサービスを運用上は別物として扱うか」「どのワークロードが業務上重要か」といった、テレメトリからは読み取れないことを、自然言語で一度書いておくと、以後の自動処理に一貫して適用されるというものです。しかもその指示はAzureリソースの状態として保存され、監査でき、新しく入ったオンコール担当者も同じ前提を引き継げます（プレビュー）。

ここに、人の役割の変化が現れています。手順を書く人から、やめどきを決める人へ。 作業そのものではなく、作業の境界を書く仕事が、人の側に残ります。

残るものが、もう一つ増える

第4回の最後に、こうお伝えしました。「消えるのはセッション、残るのは記録と責任」。第5回で、残るものがもう一つ増えます。

これが、運用・監視という現場に座席表を持ち込む、いちばん大きな意味です。

席は消えます。しかし、ノートは残ります。 そして、そのノートは、担当者の異動でも、委託先の交代でも、消えません。夜勤室の引き出しの中で属人化していたものが、承認と監査を伴った組織の資産になる。

第1回でご説明した学習ループ＝使うほど賢くなるとは、運用の現場ではこういう形をしています。

まとめ：夜間の一次切り分けから、始める

最後に、第1回のエアコンの輪を、もう一度回しておきます。運用・監視の場合、測るべき数字は現場にすでにあります。

測る：アラート件数と集約後の件数、一次切り分けの的中率、人が呼ばれた回数、深夜のエスカレーション件数、復旧までの時間、そして考える席を呼んだ回数。
判断する：エージェントが抱え込みすぎていないか。逆に、決められる判断まで人へ渡していないか。手順の席に入れた判断が、いま正しく効いているか。
動かす：しきい値、席の割り当て、プールの大きさ、手順の追加と削除、人の配置を変える。
また測る：変更後の結果を確かめる。

特に見ておきたいのが、一次切り分けの的中率と、見逃しをセットで見ることです。「人を呼ぶ回数が減った」だけを追うと、呼ぶべきときに呼ばないエージェントが評価されてしまいます。第3回・第4回でお伝えしたとおり、評価の仕組みは、実行能力と同じだけ重要です。

そのうえで。もしあなたがいま、運用の現場でエージェント導入の最初の一歩を探しているなら、夜間の一次切り分けから始めることをおすすめします。

件数が最も多い。つまり、ノートが最も速く厚くなる場所です。
読むだけで、何も壊さない。間違えても戻せます。
正解を後から確認できる。的中したかどうかが、翌朝には分かります。
そして何より、人がいま最も消耗していて、かつ、人でなくてもよい仕事だからです。

第3回で「必要なときに、必要な席だけを」とお伝えしました。第5回で、そこに一言足させてください。

必要なときに、必要な席だけを。そして、席の隣に、白紙のノートを置いておく。

最初は白紙で構いません。というより、最初は必ず白紙です。 厚くするのは、これからの運用そのものです。

次回は、この座席表を1つの現場から、組織全体へ広げます。1部門でうまくいった座席表を全社に展開すると、席は何百に増え、ノートは部門ごとにばらばらに厚くなっていきます。誰が席の棚卸しをするのか、誰がノートを承認するのか、責任者のいない席が生まれないようにするにはどうするか。第2回でお話しした“社員証とスポンサー”の話が、全社規模で戻ってきます。

参考リンク

エージェントの席（Microsoft Learn）

人の席（Microsoft Learn）

運用・監視とアラート（Microsoft Learn）

エージェントの自律実行と統制（Microsoft Learn）