AIの仕事を毎日きちんと動かす担当者の役割

1. 概要: エージェントにはプロンプトだけでなく運用者が必要

AI導入でよくある失敗は、エージェントを少し賢いchat windowのように扱うことです。目標を与え、toolをいくつか接続し、残りはモデルが何とかしてくれると期待します。demoでは魅力的です。しかし、それが毎日繰り返され、顧客に届き、recordを変更し、お金を使い、最新の会社ルールに依存すると壊れます。

エージェントが強くなるほど、仕事は運用に近づきます。approval queueがあり、failed runがあり、tool error、古いsource document、cost spike、曖昧なhandoff、顧客に出るdraft、もっと早く止まるべきだったcaseが出ます。これらは一度のきれいなpromptでは解決できません。

だから役割が重要です。Agent Ops Managerは必ずしもmachine learning engineerである必要はありません。小さな会社では、代表、運用責任者、カスタマーサポート責任者、外部AI運用パートナーが担当できます。重要な仕事はagent loopを健康に保ち、繰り返しの修正をより良いsystemに変えることです。

2. 小さな用語集: 言葉は難しくても概念は単純

Agent Ops Managerとは、AIエージェントの日々の運用状態を責任を持って見る人です。簡単に言えば、digital workerのシフトリーダーです。すべての仕事を手で行うわけではありませんが、何を自動実行し、何を承認に回し、何が失敗し、次に何を学ばせるかを決めます。

Queueは待ち行列です。Approval queueは、人がapprove、edit、rejectする必要がある行動が並ぶ場所です。Traceはエージェントが通った経路です。どのinstructionを読み、どのtoolを呼び、どんな結果が返り、どこで次の判断をしたかを示します。Spanはtrace内の小さな作業単位です。tool call一つ、retrieval step一つがspanです。

Evalはエージェントが正しく働いているかを繰り返し確認するtestです。Regression testは、修正した失敗が戻らないようにするtestです。Healthcheckはworkflowが生きていて正常かを素早く見る点検です。Rollbackは悪い行動を戻したり被害を抑えたりする手順です。SLAはservice promise、KPIはworkflowがうまく動いているかを見る数字です。

SOPはStandard Operating Procedure、つまり標準業務手順です。チームが望む仕事の進め方を書いた文書です。AGENTS.mdやCLAUDE.mdのようなfileはproject memory fileです。エージェントにこのprojectのルール、文脈、境界を教える案内書です。MCPはagentがtool、file、database、appへ接続する標準connectorです。便利ですが、tool callが安全かどうかをMCPが代わりに判断するわけではありません。

• Queue: 仕事、承認、失敗、escalationが待つ行列です。
• Trace: agentが何をして、なぜそうしたかを見せる経路記録です。
• Eval: agentがまだ正しく働くかを繰り返し確認するtestです。
• Regression: 修正した失敗が再び戻ってくることです。
• Healthcheck: workflowが生きていて正常かを見る素早い点検です。
• Rollback: 悪い行動を戻したり被害を抑えたりする準備済みの方法です。
• MCP: 接続レイヤーであり、permissionとreview ruleの代わりではありません。

3. 毎日見るloop: 運用者が確認するもの

最初の仕事はapproval queueです。どの顧客メッセージ、CRM update、refund、public post、file change、tool callがreviewを待っているでしょうか。運用者は単にapproveを押すだけではいけません。なぜ承認が必要だったのか、agentは十分な根拠を示したのか、次回このcaseをもっと簡単にできるのかを見ます。

二つ目はfailure queueです。どのrunがtimeoutし、間違ったsourceを使い、間違ったtoolを呼び、budgetを超え、弱い回答を作り、情報不足のescalationをしたでしょうか。失敗したrunは、四つのartifactのどれかになるべきです。より良いSOP、より鋭いsource rule、新しいeval case、より厳しいpermission boundaryです。

三つ目はfreshnessです。会社知識に接続されたagentは、古い真実によって間違えることがあります。運用者はsource of truthが変わったか、policyが期限切れか、顧客向けruleが古いmemoと衝突していないか、sourceがstaleなときにagentが止まって聞くかを確認します。

• Approval queueをreviewし、approve、edit、rejectの理由をlabelとして残します。
• Failed runをreviewします。tool error、弱い根拠、timeout、誤ったretrieval、危険な推測を見ます。
• 顧客に影響するoutputが約束になる前に確認します。
• 総額だけでなくworkflow別のtokenとcost spikeを見ます。
• 古いsource、衝突する文書、unresolved handoffを探します。
• 繰り返しの失敗をSOP update、eval、permission rule、dashboard alertへ変えます。

4. Dashboard: 何が見えるべきか

良いagent dashboardは、見栄えのよいanalytics pageではありません。control surfaceです。今日の実行数、成功率、失敗run、待機中approval、rejectされたapproval、unresolved escalation、tool error、平均latency、workflow別cost、stale source count、繰り返し失敗categoryが見えるべきです。

AWS AgentCore observability、OpenTelemetry trace、Google SRE monitoringの方向は実務上同じです。production systemは、何が壊れているか、なぜ壊れているかを答えられるだけ見えている必要があります。エージェントではinfra signalとproduct signalの両方が必要です。latencyも重要ですが、agentが正しいsourceを使ったか、危険行動の前に止まったかも重要です。

Dashboardはsymptomとcauseも分けるべきです。Symptomはユーザーが経験したことです。wrong answer、late reply、failed workflow、unsafe draftです。Causeはそれを作った原因です。stale knowledge、missing permission、bad tool result、weak instruction、budget exhaustion、model routing mistakeです。運用者には両方が必要です。

• Operations: run数、成功率、failure、latency、duration、retry、timeout。
• Safety: approval、rejection、escalation、forbidden action attempt、rollback event。
• Knowledge: source freshness、conflict count、missing owner、stale answer risk。
• Cost: token usage、model routing、expensive task、repeated retry、wasted context。
• Quality: eval pass rate、regression failure、human edit、customer complaint、recurring defect。

5. Traceとevalが感覚より重要な理由

多くのチームは最終outputだけを見ます。顧客が見るのはoutputなので自然です。しかし最終output reviewだけでは、本当の問題が隠れます。回答が間違った理由が、古いsourceを取ったからなのか、toolを飛ばしたからなのか、policyを読み違えたからなのか、contextを超えたからなのか、三つ前のstepで危険な仮定をしたからなのかが分かりにくくなります。

これがobservability gapです。2026年のoutput-level feedback論文は、人が結果だけを見ると隠れたexecution stateの問題を見つけにくいと指摘します。2026年のAI coding agent logging研究も有用な警告です。agentはloggingを人間より扱わない傾向があり、明示的なlogging instructionだけでは十分ではなく、人間が後からobservabilityを修理する役になりがちでした。実務の教訓は単純です。運用証拠をpromptの願いに任せてはいけません。

良い運用者はtraceをevalへ変えます。agentが古いpolicyを使って失敗したなら、policy freshnessを確認するtestを作ります。間違ったtoolを呼んだならpermissionまたはrouting testを追加します。承認なしで顧客への約束を作ったなら、次のrelease前にそのpatternを止めるregression caseを作ります。

6. Permission、approval、MCP: 境界ができてからtoolを接続する

MCPとtool callingが強力なのは、agentが行動できるからです。だから運用者が必要です。接続されたCRM、email tool、payment system、file system、browser、deployment commandは、もはや単なるtextではありません。現実の面を変えます。

OpenAI Codex approvalとpermission guidance、OpenAI Agents approval pattern、MCP tool specificationは同じ運用アイデアを示しています。敏感なtool callは見え、確認でき、logに残り、制限され、reviewできるべきです。モデルがtoolを使いたいと言っただけで安全になるわけではありません。

運用者はpermission tableを維持します。Read-only internal lookupは多くの場合自動実行できます。顧客メッセージ、CRM update、refund、publishing、outboundは通常draft-firstまたはapproval-firstです。Money movement、credential change、account deletion、irreversible production write、regulated decisionは、原則禁止または毎回明示承認です。

• 自動レーン: 内部向け、read-only、戻しやすい、低費用、検証しやすい。
• 承認レーン: 外部公開、費用発生、敏感情報、顧客影響、policy依存。
• 禁止レーン: 戻しにくい、破壊的行動、credential、規制、大きなblast radius。
• すべてのtoolにはowner、allowed action、blocked action、log位置、rollback ruleが必要です。

7. 週間loop: incidentをsystem upgradeへ変える

日々の運用はworkflowを生かします。週間運用はそれを良くします。週に一度、運用者はtop failure、最も多くeditされたapproval、最も高価なrun、stale source、顧客影響issueを見るべきです。問いは誰が失敗したかではありません。来週同じ失敗を防ぐartifactは何かです。

OpenAI cookbookのagent improvement loopはここで良いモデルです。Trace、human feedback、model observation、eval、codeまたはharness changeがflywheelを作ります。ビジネスの言葉では、correctionがchat historyに残るだけではいけないという意味です。SOP update、source-of-truth change、eval case、dashboard alert、permission updateになるべきです。

このweekly loopがあって初めてautonomyを安全に広げられます。demoが良かったという理由だけでagentに権限を増やしてはいけません。logが繰り返し成功を示し、evalが通り、approval editが少なく、rollbackが準備され、human ownerが残るriskを説明できるときに権限を広げます。

• 繰り返し失敗top 5を見て、それぞれをartifactに変えます。
• Rejectされたapproval、editされたdraft、customer complaintからeval caseを追加します。
• 古いSOPとsource-of-truth documentを更新します。
• Permissionをauditし、現在のworkflowより広すぎるtool権限を外します。
• 何が改善し、何がまだapproval対象で、何がblockedかを報告します。

8. 小さな会社では誰がAgent Opsを担当するべきか

小さな会社が新しい部署を作る必要はありません。名前の付いたowner一人が先です。最初の一か月は代表が担当できます。その後はworkflowに応じて、運用、support、growth、外部service partnerが担当できます。重要なのはownershipが明示されることです。全員がAIは自分で管理されると思うと、失敗queueは誰も見ません。

Ownerが最高のprompt writerである必要はありません。business rule、customer risk、source of truth、approval boundaryを理解する人で十分です。Trace、dashboard、tool integration、eval harnessにはtechnical helpが必要になることがありますが、運用基準はbusiness側から出るべきです。

この役割はGUILDEX service packageにも自然に合います。Fit Checkでworkflowを一つ選びます。最初のworkflowをsource、SOP card、approval lane、verificationと一緒に作ります。その後、Monthly Agent Ops Retainerとしてqueue monitoring、incident review、eval update、stale knowledge cleanup、permission audit、短い運用reportを提供します。

• Founder: priority、risk appetite、first workflow choiceを責任持って決めます。
• Operations lead: SOP、approval、handoff、weekly reviewを担当します。
• Supportまたはsales lead: customer-facing品質とescalation ruleを担当します。
• Technical partner: trace、tool wiring、dashboard、eval harness、release checkを担当します。
• GUILDEX package: Fit Check、First Workflow Setup、Monthly Agent Ops Retainer。

9. AIが発展するほど人も一緒に発展すべき理由

AIが良くなるからといって、人間の成長が不要になるわけではありません。人間の仕事が変わります。これから価値ある人は、すべての答えを書き、すべてのbuttonを押し、すべてのdraftを直す人だけではありません。仕事を定義し、根拠を選び、境界を決め、patternを読み、失敗後にsystemを改善する人です。

だからAgent Opsはanti-automationではありません。より深い自動化への道です。人がsource rule、approval rule、eval、dashboard、rollback、ownershipを表現できるようになると、agentはより多くの仕事を安全に任されます。人はtask doerからsystem operatorでありcoachである立場へ上がります。

最初の行動は小さく始めれば十分です。今週agent workflowを一つ選び、ownerを決めてください。Approval queue一つ、failure log一つ、eval list一つ、stale-source check一つ、weekly review一つを作ってください。それだけで、AIを運の良いpromptではなく運用体系として扱い始められます。

非エンジニアがすぐ確認する質問

すべての専門用語を覚える必要はありません。下の質問に答えられるなら、実務で試す準備ができています。答えが空なら、自動化より先に仕事の基準を整えるべきです。

• このテーマを自社の繰り返し業務に置き換えると何か?
• この仕事が失敗したら、顧客、費用、時間、評判のどれが傷つくか?
• AIに任せる部分と、人が承認する部分はどこか?
• AIが参照すべき信頼できる資料はどこにあるか?
• 結果が良くなったことを、どんな証拠で確認するか?
• 同じ失敗が繰り返されたら、どのSOPやチェックリストを変えるか?