朝、小舟商事の業務フロアで、七海は壁面モニターの赤いランプを見つめていた。AIエージェント「ソラ」は「稼働中」と表示されているのに、注文変更の返事は届かず、経費精算は承認待ちのまま、営業メールは送信前で止まっている。
「動いているのに、どうして仕事が終わらないのかしら」
七海の机には、「まだ返事が来ません」という問い合わせが次々に届いた。平均の待ち時間や稼働率だけでは、顧客対応、日程調整、外部APIの確認、人の承認に隠れた遅れは見えない。SLA、SLO、SLIを業務ごとに分け、受付から業務完了までの時計を測る必要がある。見えない価値を可視化するための、長い一日が始まった。
この記事の答え
- 結論AIエージェントの価値は、稼働率ではなく業務完了までの時間で可視化できる。
- 根拠SLA・SLO・SLIを業務別に設け、外部待ちや承認待ちを工程ごとに測るためである。
- 最初の一歩まず一つの業務を受付から完了まで分解し、工程別の待ち時間を記録する。
第1章 赤いランプが消えない朝、業務別SLAのない会社

第1章 赤いランプが消えない朝、業務別SLAのない会社 - 本文
午前八時。小舟商事の業務フロアには、給湯室のポットがふつふつ鳴る音と、キーボードをたたく音が重なっていた。出社した七海は、コートを椅子に掛ける前に、壁面モニターの赤いランプへ目を向けた。
画面の中央には、AIエージェント「ソラ」の名前と「稼働中」という表示がある。いつもなら、七海はその文字を見てからメールを開くのだが、今朝はランプが赤いまま消えず、受信箱には「まだ返事が来ません」という件名が並んでいた。
「おはようございます。ソラさん、今日も動いているはずですよね?」
隣の机で、カスタマーサポートの真紀が小さく首をかしげた。七海が画面をのぞくと、注文番号の照会は終わっているのに、返品の受付だけが「処理待ち」と表示されている。お客さまには、確認中という短い返事さえまだ届いていなかった。
「注文の内容は、もう分かっているのにね」 「はい。お客さまは、返品できるかどうかを知りたいんです。でも、ソラは次の箱を開けてくれません」
七海は真紀の画面に、青い丸がくるくる回っているのを見つめた。ソラは注文番号を探し、商品名を読み取り、購入日まで表示している。それなのに、返品処理へ進むための外部ツールの呼び出しで止まっていた。
向かい側では、営業の亮が送信ボタンの前で腕を組んでいた。取引先へのメール文案はできている。「納期変更のお知らせ」という件名も入っている。だが、送信前の確認欄に赤い印が残り、承認を頼む通知も届かないままだった。
「文章はきれいなんです。でも、このまま送っていいかの確認が終わらなくて」 「確認をする人が、まだ決まっていないの?」 「決まっています。ソラが通知を出すところまで、来ていないんです」
そのすぐ横では、総務の日程調整も止まっていた。ソラは参加者のカレンダーを読み、全員が空いている候補日を見つけている。けれども会議URLは発行されず、事前資料の準備を知らせるリマインドも、送信箱の中で眠っていた。
「候補日は出ているのに、会議が始まる場所がないね」 「はい。予定表には入れられます。でも、仕事としては終わっていません」
七海は自分の机へ戻った。朝一番に確認するはずだった顧客対応の一覧を開くと、処理中の行がいくつも並んでいる。画面の上には「稼働中」と表示されているのに、現場の行には「返信待ち」「承認待ち」「URL発行待ち」と、違う種類の待ち時間が積み重なっていた。
そこへ部長の黒田が、紙コップのコーヒーを片手にやって来た。黒田は赤いランプと、七海の机に並んだ問い合わせを交互に見た。
「サービスが動いているなら、なぜ仕事は終わらないのか」
七海はすぐに答えられなかった。これまで会議では、ソラの稼働率や平均の返事の速さを見てきた。数字が悪くなければ、業務も順調だと思っていたからだ。
「平均の待ち時間だけでは、見えないものがあります」 「見えないもの?」 「はい。返事を作るまでではなくて、受付から始まって、処理が始まり、外部ツールを呼び、最後の回答を作り、人が確認して、業務が完了するまでです」
七海はホワイトボードに、細い線を一本引いた。その線の上に、受付、処理開始、外部ツール、最終回答、有人確認、業務完了と書いていく。ひとつの時計だと思っていた待ち時間は、実は、いくつもの時計が順番に動く時間だった。
真紀が返品処理の画面を指さした。照会が終わった時刻と、返品を受け付けた時刻は別の場所に記録されている。亮のメールにも、文案ができた時刻と、確認が終わった時刻を示す欄はなかった。
「ソラが止まった時間だけを測っても、お客さまが待った時間は分かりませんね」 「その通りだね」と黒田が言った。「動いているかではなく、業務が終わったかを見ないといけない」
黒田はホワイトボードの端に、SLA、SLO、SLIと書いた。七海が少し困った顔をすると、黒田はペン先で三つの言葉を順番に示した。
「SLAは、お客さまに約束すること。SLOは、社内で目指す目標。SLIは、その約束や目標を実際に測るものだよ」
「では、返品なら、ソラが稼働していることではなく、受付から返品完了までを測る。メールなら、文案の作成ではなく、確認を終えて送信できたかを測るんですね」 「そう。日程調整も、空き時間を見つけただけでは足りない。URLと資料の準備まで終わって、初めて仕事が終わる」
七海は画面を見た。赤いランプはまだ消えない。「ソラは稼働中」という表示も、変わらずそこにある。その下で、顧客の返品、営業メール、会議の準備が、それぞれ別の場所で静かに待っていた。
七海は新しい表を開き、業務名の横に六つの時刻欄を作った。受付、処理開始、外部ツール、最終回答、有人確認、業務完了。空白だらけの表だったが、今朝まで一つに見えていた待ち時間の形が、少しずつ見え始めていた。
「七海さん、午後の会議までに、この表を埋められそう?」 「はい。まず、終わったことにする場所を、業務ごとに決めます」
七海が保存ボタンを押すと、フロアのどこかで新しい問い合わせの着信音が鳴った。赤いランプはまだ消えない。それでも七海の机では、見えなかった時間を測るための、最初の時計が動き始めていた。
第2章 「すぐ返します」が夜まで残った日

第2章 「すぐ返します」が夜まで残った日 - 本文
朝九時すぎ、配送変更の依頼が、顧客の窓口からソラに届いた。ソラは注文管理システムへ更新を送り、壁のランプを緑にしたが、返事が戻る前に通信マークが灰色へ変わった。
「お届け先を変えたい、という依頼ですね。すぐ返します」
七海は画面をのぞき込んだ。依頼は受け付け済みだったが、注文管理システムからは結果が返っていない。ソラは送信に失敗したと判断し、同じ更新をもう一度送った。
「待って。今の依頼は、もう届いているかもしれないわ」
しかし、ソラの判断は止まらなかった。最初の更新は外部サービスの中で処理されていたが、その返事だけが途中で消えていたらしい。二度目の更新も受け付けられ、同じ配送変更が二つの記録として並んだ。
顧客の画面には、返事が出なかった。窓口の担当者は、受付番号を見ながら七海へ声をかけた。
「まだ返事が来ません。お客様は、今日中に届くのか心配されています」
七海の指は、キーボードの上で止まった。処理は動いている。けれど、仕事は終わっていない。彼女は受付番号「配送変更-48」を手がかりに、ソラのログを開いた。
ログには、リクエスト番号と、何のための処理かを束ねる意図番号が並んでいた。ところが、二つの番号が別々の欄に散っている。番号の形も似ていたため、七海には、どの処理が同じ依頼なのかすぐには分からなかった。
「この二つは、同じお客様の依頼ですか」
「たぶん……でも、ログだけでは断言できません」
担当者の返事は小さかった。七海は受付番号、送信時刻、外部サービスへの呼び出しを一行ずつ見比べた。すると、最初の送信の直後に通信が切れ、その少し後に、同じ内容の再実行が残っていた。
さらにログを広げると、ほとんどの処理は短く終わっていた。一方で、少数の処理だけが、画面を開いたまま長く待っていた。待ち時間の山が、平均という一つの数字の後ろに隠れていた。
たとえば、説明用の例として、100件のうち95件が100msで終わり、5件が5,000msかかったとする。平均は345msになるが、短い順に並べたときの95番目を示すp95は100msで、99番目を示すp99は5,000msになる。平均と分布を分けて見る考え方は、AIエージェントのための負荷テスト戦略でも扱われている。
画面の小さなグラフでは、ほとんどの点が左側に集まっていた。その端に、遠く離れた点がいくつも残っている。平均では問題がないように見えても、待たされた人の記憶には、5,000msだけが残る。
「早く終わった処理が多いから、大丈夫だと思っていました」
七海はそう言ってから、顧客の画面を見た。そこには、配送変更の返事ではなく、「確認中」という言葉だけが残っている。裏側には二つの変更記録があり、表側には一つの返事もない。
午後になっても、窓口には同じ問い合わせが続いた。ソラは稼働中のままだったが、担当者は手作業で注文管理システムを確認し、重複した変更を一つずつ整理した。夕方、七海が最初の依頼を受けた担当者へ電話をかけると、相手は静かに答えた。
「朝の『すぐ返します』を、まだ待っています」
その言葉が、七海の胸に残った。ソラが動いていた時間と、顧客の業務が完了した時間は、同じではなかった。七海はノートに、稼働率、業務完了時間、処理の重複、と三つの欄を分けて書いた。
「一つの時計だけでは、今日の遅れを見つけられない。明日からは、動いているか、終わったか、同じ仕事を何度もしていないかを、別々に測りましょう」
壁のランプは、夜になっても緑のままだった。けれど七海は、その色だけを見て安心しないと決めた。
第3章 古い時計の前で、SLAとSLOを分ける

第3章 古い時計の前で、SLAとSLOを分ける - 本文
朝、七海は社内の資料室で、止まったままの古い時計を見上げていた。壁には、丸い時計や四角い時計が十個ほど並んでいる。時計の針は、それぞれ違う時刻を指していた。
その前に、篠原が立っていた。以前はSREの仕事をしていた人で、システムを安定して動かす仕組みを考えてきた。
「篠原さん、ソラの待ち時間をどう測ればいいのか、分からなくなりました」
「まず、時計を一つにしないことです」
篠原は、古い時計の一つを指でそっとたたいた。金属の音が、静かな部屋に小さく響いた。
「SLAは、サービスを提供する側と使う側のあいだの品質の約束です。たとえば、この時計を毎朝、正しい時刻に合わせておく約束ですね。SLOは、その約束を守るための社内目標です。SLIは、実際に測る指標です。時計なら、ずれた秒数を測る温度計のようなものです」
「約束と目標と、測るものを分けるんですね」
「そうです。名前が似ていても、役目は違います」
七海は、注文変更の画面を思い出した。ソラは受付を受け付けていた。けれど、外部サービスの返事を待ち、同じ変更をもう一度送っていた。
「ソラが使える状態なら、仕事も完了したことになるのではありませんか」
篠原は、止まった時計と動いている時計を並べた。
「受付できることと、業務が終わることは別の時計です。画面が開く時計と、お客さまの注文が変わる時計は、同じ時刻を刻みません」
七海は、白い紙に二本の線を引いた。上には「受付から返事まで」、下には「受付から業務完了まで」と書いた。
篠原はその紙に、順番に小さな印を足した。受付、処理開始、検索、ツール操作、最終回答、有人承認、業務完了。経費精算なら、領収書の確認と承認を終えた時点までが仕事であり、営業メールなら、送信前で止まらず相手に届くところまでが仕事になる。
「測る場所が増えました。でも、そのほうが遅れの場所が分かります」
「その通りです。平均だけを見ると、短い処理が長い処理を隠します。どの時計が遅れたかを残せば、ソラの中で待ったのか、検索で待ったのか、人を待ったのかが見えます」
篠原は、契約書と業務フロー図を机の上に広げた。契約書の端には稼働率の約束があり、フロー図には注文変更や経費精算の工程が細く続いていた。
「稼働率のSLAを、そのまま待ち時間のSLOに置き換えてはいけません。稼働率は使える時間の約束です。待ち時間のSLOは、業務が決めた時間内に進むかという社内の目標です」
「動いているのに、遅いことがあるからですね」
「はい。LLMの推論、つまりAIが答えを考える時間。検索の時間。外部ツールを呼ぶ時間。そして人の承認を待つ時間。それぞれが重なると、稼働率が高くても、お客さまの仕事は終わりません」
七海は、調査「【リサーチ】AIエージェントの業務別SLAと待ち時間の設計」の「稼働率SLAを待ち時間に換算する基準」という資料をめくった。そこには、99.999%は年5分15秒、月26秒、99.99%は年52分34秒、月4分19秒と記されていた。さらに99.95%は年4時間22分48秒、月21分36秒、99.9%は年8時間45分36秒、月43分12秒、99.5%は年1日19時間48分、月3時間36分、99%は年3日15時間36分、月7時間12分と整理されていた。
数字を見ながら、七海は気づいた。稼働率の換算値は、契約条件を確認するための時計だ。業務完了時間を測る時計とは、別に置かなければならない。
「それなら、外部サービスの約束も見直さないといけませんね」
「そうです。依存先のSLAより厳しい自社のSLAを掲げても、依存先が止まれば守れません。どのサービスを対象にするか、何を障害と呼ぶか、例外は何か、違反時のクレジット条件はどうなっているか。契約書の細かい文字まで確認します」
篠原は、瓶に入った砂を七海の前へ置いた。砂は、朝の光を受けて淡くきらめいた。
「これはエラーバジェットです。遅れを一秒も許さない、という意味ではありません。現実に起こる遅延を見込んで、使える余白を砂で持っておく考え方です」
「砂が減ったら、ソラの自律実行を少し止めるんですね」
「ええ。砂がなくなりそうなら、新しい機能を急いで出さず、原因を直します。余白が戻れば、また安全に進められます」
資料室の時計が、一つだけ小さく鳴った。七海は、赤いランプのソラを思い浮かべた。今まで見ていたのは、動いているかどうかだけだった。これからは、誰が、どの工程で、どれほど待ったのかを記録できる。
「やってみます。まず注文変更で、受付から業務完了までの時計を作ります。そのあと、経費精算と営業メールにも広げます」
七海は紙の二本の線を三本に増やした。稼働率、待ち時間、業務完了。別々の時計が並ぶと、止まっていた仕事の輪郭が、少しずつ見えてきた。
第4章 待ち時間の地図を描く

第4章 待ち時間の地図を描く - 本文
七海たちは、業務ごとの待ち時間を一枚の地図に描き始めた。朝の会議室で、篠原、サポート担当の水野、営業担当の大川が、赤青のペンを持ってホワイトボードを囲んだ。
「受付から完了までを、一本の線にしないことです。どこで止まったかが見えなくなります」
篠原は、線の途中に小さな丸を置いた。丸は、仕事が次の工程へ進んだ時刻を表す。七海はソラのログに、受付番号、工程名、開始時刻、終了時刻、結果、有人対応へ移った理由を記録する項目を足した。
サポートの地図は、受付、注文照会、返品・配送変更、必要な有人確認、顧客への回答という順になった。注文番号を調べるだけなら早く終わるが、配送会社への確認が必要な変更は、外部サービスの返事を待つことがある。
「ここを一つの『回答時間』にすると、ソラが止まったのか、配送会社を待っているのか分かりません」
「だから、各工程にSLIを置きます。SLIは実際に測るもの。SLOは社内の目標です。SLAは、お客様に約束する時間ですよ」
営業メールの地図には、企業情報の調査、文案作成、内容確認、送信が並んだ。大川は、文案ができても確認者が席を外せば送信できないことを示した。七海は、AIの生成時間だけでなく、確認が終わり、実際に送信された時刻までを業務の時計に入れた。
日程調整では、Google Calendarの空き時間を調べ、候補日時を作り、Zoomの会議URLを発行する。その後に資料とアジェンダを送り、Slackでリマインドするところまでを完了とした。
市場調査は、ニュース、SNS、プレスリリースを集め、要約し、競合比較表を作り、レポートを生成する流れになった。経費精算は、領収書の読み取り、内容確認、会計処理、承認待ちに分けた。freeeで会計処理が終わっても、最後の承認は人が行うからだ。
七海は、最初の案にすべての業務を二分以内と書いた。目標は厳しいほど、チームが頑張れると思ったからだ。
「配送変更と市場調査を、同じ二分で測ってよいのでしょうか」
水野の問いに、七海のペンが止まった。配送変更は、顧客が待つほど不安になる。一方で市場調査は、少し長くても、比較表や根拠がそろうことの方が大切だった。
篠原は、社内調査「【リサーチ】AIエージェントの業務別SLAと待ち時間の設計」を開いた。そこには、Webの設計例として99%を2秒、DBの例として99.9%を100ミリ秒、APIの例として可用性99.95%、95%を500ミリ秒以内という値が並んでいた。
「これは技術部品の目安です。WebやDBが速くても、AIが確認し、外部APIを呼び、人が承認する業務全体が速いとは限りません。数字をそのままSLAにしてはいけません」
七海たちは、配送変更には短い完了目標と、遅れたときの有人引き継ぎを置いた。市場調査には、収集、要約、比較表、レポートの各段階に目標を置き、全体は品質を確認してから完了とした。こうして、技術の時計と業務の時計が、別々の線で描かれた。
午後、七海は工程ごとに細かなアラートを設定した。Datadogで遅れを検知し、異常があればSlackへ通知する設定だ。ところが夜になると、高い負荷と外部ツールの一時的な遅れで通知が鳴り続け、担当者の画面が赤い印で埋まった。
「全部を緊急にすると、本当に急ぐ通知が見えません」
チームは、遅い方から5%を見るp95と、遅い方から1%を見るp99を業務別に使い分けた。配送変更はp95を注意、p99を有人担当への通知にした。市場調査はp95で日々の傾向を見て、p99はすぐに呼び出さず、翌日の確認に回した。
小さな失敗は、再送テストでも起きた。外部APIの返事が遅れ、ソラが同じ注文変更をもう一度送ってしまったのだ。七海は第2章で起きた二重処理を思い出し、受付番号をそのまま同じIdempotency-Keyとして再送時にも使う仕様に変えた。
「同じ鍵なら、同じ依頼は一度だけ処理します。返事が遅くても、完了したふりはしません」
外部サービスが止まったとき、画面には「外部確認待ち」と表示することにした。一定時間を超えたら、注文情報と途中までの記録を添えて人へ引き継ぐ。顧客には、止まった場所と次の確認先が伝わるようになった。
最後に、篠原はエラーバジェットを説明した。それは、SLOから少し外れても許される余白だ。再試行を増やせば信頼性は上がるが、外部APIの費用も増える。余白を使い切ったときは、新しい機能より原因調査を優先することにした。
夕方、壁面モニターの赤いランプは、業務ごとに緑、黄、赤へ分かれていた。七海は地図の端に、受付から完了までの時間と、待っている場所を書き足した。ソラが動いているかだけでなく、仕事がどこまで進み、誰が次に受け取るのかが、静かに見えるようになっていた。
第5章 p95とp99が並ぶ朝

第5章 p95とp99が並ぶ朝 - 本文
朝、新しいダッシュボードが動き始めた。壁面モニターには、稼働率の表示とは別に、受付、処理開始、ツール呼び出し、最終回答、有人確認、業務完了の欄が並んでいる。赤いランプだけを見つめていた前の朝とは、画面の景色が変わっていた。
「ソラは動いているのに、仕事が終わらない。その理由を、今日は見つけられるかもしれないわ」
七海が画面を切り替えると、業務ごとの時計が現れた。欄の上には、SLA、SLO、SLIという小さな表示もある。七海は隣のサポート担当に、SLAは外部への約束、SLOは社内で目指す状態、SLIは実際に測る合図だと、やさしく説明した。
サポート担当が注文変更の画面を開いた。受付と処理開始は進んでいるのに、ツール呼び出しの欄だけが薄い色で止まっている。表示には「処理失敗」ではなく、「外部注文システムの確認待ち」と出ていた。
「お客さまには、止まったと伝えなくていいんですね。外部照会の返事を待っている、と説明できます」
七海はうなずいた。前なら、ソラの再実行を押していたかもしれない。今は、同じ注文を二重に送らないための状態と、次に確認する場所が、担当者の手元に渡っている。
営業の画面では、文案生成の欄が完了になっていた。けれど、最終回答の先にある「送信前の確認」は残っている。文章ができたことと、顧客へ送ってよいことは、同じ時計ではなかった。
「文案はもうあります。残っているのは、営業確認です」
営業担当は画面を見て、送信ボタンから手を離した。以前のように「メールが遅い」と言う代わりに、「承認待ち」と伝えられる。待つ理由がわかると、急かす声も小さくなった。
日程調整の業務では、カレンダーがすぐに応答していた。それでも業務完了には届かない。会議URLの発行と資料の準備が、別の欄で静かに時間を使っていた。
「カレンダーは問題ありません。会議URLと資料準備が、次の待ち時間です」
七海は欄を指でたどった。単一の返事が速くても、予約が終わるまでの流れは長くなる。業務の時計を最後まで置いたことで、速さの見せ方が変わった。
市場調査の画面にも、同じ変化があった。情報収集の欄とレポート生成の欄が分かれ、どちらで時間がかかっているかを見分けられる。検索の返事が遅いのか、集めた情報を整理する処理が遅いのかが、ひとつの「遅い」に隠れなくなった。
七海は平均値の画面を閉じ、p95とp99の表示を開いた。p95は、多くの仕事がどのあたりまでに進んだかを見る線で、p99は、その中でも特に長く待った仕事を追う線だという。平均だけでは平らになっていた長い待ち時間が、業務の段階ごとに浮かび上がった。
「長く待つ仕事を、見落とさなくなりましたね」
「ええ。遅い業務を責めるのではなく、どこで時計が止まったかを見ます」
経費精算の画面では、領収書の読み取りと規定確認は進んでいた。最後の承認だけは、人が確認する欄に残されている。ソラは無理に完了へ進まず、「承認者確認待ち」と「次に見る項目」を担当者へ渡した。
その横では、送信前に止めた営業メールに「再送防止済み」と表示されていた。サポート担当は、注文変更を再実行する前に外部照会の返事を確認した。人が必要な場所には人へ渡し、自動で進めてよい場所だけをソラが進める。その境目が、画面の中で穏やかに見えるようになっていた。
フロアを飛び交う言葉も変わった。「遅い」「止まった」という声は、「外部照会待ち」「承認待ち」「資料準備中」へ変わっていく。誰かが原因を探して画面を何度も開くのではなく、次に何を確認するかを手にして席を立てるようになった。
夕方、七海は朝のモニターを振り返った。ソラの動きが、急にすべて速くなったわけではない。それでも、受付から業務完了までの時間が、見えない霧の中ではなく、担当者と共有できる道として現れていた。赤いランプの前に集まっていた人たちは、今ではそれぞれの仕事へ、落ち着いた足取りで戻っていた。
第6章 時計の音がそろう午後

第6章 時計の音がそろう午後 - 本文
数日後の午後、七海は、朝と同じ壁面モニターの前に立っていた。赤いランプはまだいくつか灯っている。けれど、フロアには、返事を待ち続ける人ではなく、次に確認する場所へ歩く人の姿があった。
画面には、顧客対応、営業メール、日程調整、市場調査、経費精算が、細い線で分かれて表示されている。顧客対応の線は注文番号の照会へ伸び、営業メールの線は文面確認の箱へ入る。日程調整の線はカレンダーと会議URLへ、市場調査の線は検索と要約へ、経費精算の線は領収書の確認と承認へ続いていた。
ソラは、終わった仕事にはすぐに完了を返していた。外部サービスからの返事を待つ仕事には、ただ止まるのではなく、「外部サービスの確認中」と理由を添えた。人の判断が必要な仕事には、確認する項目と、次に押す場所まで添えて引き継いでいる。
サポート担当の佐伯は、注文照会の画面を見ながら、ヘッドセットの向こうの顧客に声をかけた。
「注文の変更は受け付けています。いま配送会社の確認を待っています。返事が届いたら、すぐにお知らせしますね」
画面の右側には、受付時刻と、外部確認が始まった時刻が並んでいた。佐伯は赤いランプだけを見て慌てることなく、顧客に伝える言葉を選んだ。
隣の机では、営業担当の湊がメールの下書きを開いていた。ソラが取引先名と添付ファイルを確認し、湊の手元には、送信前に見る箇所だけが小さく並んでいる。
「ここを確認したら、送って大丈夫です」
湊は一行を読み、添付された見積書を確かめた。送信ボタンを押す指は、以前より静かだった。
会議室の近くでは、日程調整を担当する美咲が、候補日の一覧を見ていた。ソラは参加者の予定を照らし合わせ、空いている時間を見つけていたが、社外の相手への確定連絡だけは、美咲の確認を待っている。
「候補日はもうできているのね。あとは、この時間でよいか聞けばいい」
市場調査の画面には、集めた記事と要約の欄があった。経費精算の画面には、領収書の金額と社内規定の確認結果が並ぶ。承認が必要なものだけが、人の机の前で小さな印を灯していた。
七海はモニターの端にある二つの時計を見た。ひとつはソラが動ける状態かを示す、稼働率の時計。もうひとつは、受付から業務が終わるまでを測る、業務完了の時計だった。
「同じ仕事の時計なのに、別々に動いているみたいですね」
佐伯が画面から目を上げた。
「ソラが動いていても、外の返事や人の確認を待つことがありますから。止まった場所がわかれば、待つのか、聞くのか、確認するのかを選べます」
七海は小さくうなずいた。以前のように、すべての赤いランプを障害として追いかける人はいない。ランプの先にある時計を見て、必要な場所へ向かっている。
モニターの中央で、ひとつの依頼が青い線を進み始めた。最初に「処理を開始しました」と表示される。次に、外部サービスへ線が伸び、「外部確認を待っています」と変わった。
しばらくして、画面の色がやわらかく明るくなった。「確認が完了しました」。その文字が消えるころ、フロアの壁時計が時を刻み、机の上の小さな時計も重なった。
カチ、カチ。待つ人のためだけではない時計の音が、午後の業務フロアに静かにそろっていた。
関連キーワード
著者について
鈴木信弘(SNAMO)
鈴木信弘(SNAMO)- 静岡県を拠点に活動する総経験19年のフルスタックエンジニア。AI時代の次世代検索最適化技術「レリバンスエンジニアリング」の実装者として、GEO(Generative Engine Optimization)最適化システムを開発。2024年12月からSNAMO Portfolioの開発を開始し、特に2025年6月〜9月にGEO技術を集中実装。12,000文字級AI記事自動生成システム、ベクトル検索、Fragment ID最適化を実現。製造業での7年間の社内SE経験を通じて、受注システム自動化による業務時間の短縮や検品作業のデジタル化など、現場の課題を技術で解決してきた。富山大学工学部卒、基本情報技術者保有。
プロフィールを見るよくある質問
Q1AIエージェントの待ち時間は、なぜ問題になるのですか?
Q2AIエージェントにおけるSLA・SLO・SLIの違いは何ですか?
Q3AIエージェントの稼働率が高いのに、業務が終わらないのはなぜですか?
Q4AIエージェントの待ち時間は、どのように測定すればよいですか?
Q5p95やp99を使ってAIエージェントの遅延を測るメリットは何ですか?
Q6外部サービスの応答遅延による二重処理を防ぐにはどうすればよいですか?
Q7AIエージェントのSLA設計で、稼働率以外に見るべき指標は何ですか?
Q8AIエージェントの待ち時間を可視化すると、現場では何が変わりますか?
関連記事

止まったAIエージェントが冪等性で仕事を再開するまで
AIエージェントはCheckpointと冪等性を設計すれば、停止後も未完了の仕事から安全に再開できる。処理状態を外部保存し、処理IDとIdempotency-Keyで再実行時の二重処理を防ぐためである。まず処理をステップ分割し、各進捗をCheckpointに保存して外部API呼び出しに冪等性キーを付ける。
読む
更改漏れに悩む保険代理店が生成AIで案件管理を変えるまで
保険代理店は、生成AIを記録整理と確認支援に使い、人が承認する運用で更改漏れを防げる。紙・メール・日誌に分散した情報をRAGで検索・整理し、根拠と次の行動をつなげられるため。まず更改案件の記録場所と次の行動を一つに決め、AIは下書きに限定して担当者が承認する。
読む
AIエージェント導入前、非構造化データの例外を洗い出す旅
AIエージェント導入前に、非構造化データの例外を洗い出すべきです。例外ごとに続行・停止・人への引き渡しを定め、誤登録や権限外処理を防ぎます。まず実データに近い注文で例外テストを行い、停止基準と監査ログを整えます。
読む
AIエージェント導入で、工場の仕事を守るリスク・頻度マトリクス
AIエージェント導入では、低リスク・高頻度の業務から任せ、高リスク業務は人が承認する。リスクと頻度で業務を分類し、閲覧、下書き、実行の三段階で権限を広げる。まず問い合わせ分類や資料検索を閲覧権限で試し、成果と例外、根拠を記録する。
読む
