人間が操作するシステムから、業務を遂行するシステムへ
これまでのシステムは、人間が操作するものだった
例えば、人事評価の進捗を調べるために、複数の画面を開き、未完了者を探して連絡する。システムに情報があっても、業務を前へ進める操作は人が担います。従来も自動化はありましたが、SaaSを使いこなす学習や入力は残っていました。
第1記事では改善する余力の不足、第2記事では可視化のために増える入力を考えました。AIエージェントは、その作業を引き受けられるのでしょうか。それとも、AIの仕事を確認する作業に置き換わるだけでしょうか。
私は本業でITシステムの運用・監視・統制を効率化するシステムを開発し、副業でHR業務を支援するAIプロダクトを開発しています。今回はSRE領域の経験も踏まえ、この問いを考えます。
SaaSと従来の自動化は、すでに仕事を減らしてきた
SaaSの価値は、情報を共有するだけではありません。申請や承認の流れを標準化すれば、部署ごとの独自手順や保守する個別カスタマイズを減らせます。SAPのFit-to-Standardも、標準プロセスを業務担当者が確認する進め方です。 [1]
ただし、従来の仕事を変えるには、教育、データ移行、例外の整理が必要です。標準に合わせることが改善になる場合もあれば、必要な業務が画面の設計に収まらない場合もあります。
RPAは画面操作などの反復作業を自動化してきました。Microsoftのデスクトップフローも、Webやデスクトップアプリなどを操作できます。 [2] APIでシステムをつなぎ、期限や状態で分岐するワークフローも有効です。定型通知のためだけに、AIを持ち込む必要はありません。
AIエージェントは、返答から実行へ踏み込む
この記事では、AIエージェントを、目的に応じて次の処理を選び、ツールの実行結果を見ながら仕事を進める仕組みと捉えます。返答だけを行うチャットボットと違い、権限の範囲で外部システムを検索・更新できます。チャット画面でも、裏側がこの仕組みならエージェントです。
「未完了の評価を確認して」と自然言語で依頼し、メールや文書から事情を読み取り、複数システムを調べる。情報が足りなければ人に確認し、必要な処理をAPIなどで実行する、という可能性があります。ただし、情報の理解も処理の選択も誤ることがあります。
Anthropicは、事前に決めた経路を通るワークフローと、モデルが処理やツール利用を動的に選ぶエージェントを区別し、必要以上に複雑にしないことを勧めています。 [3]
IT運用とHRでは、どの工程を任せるか
以下は導入実績ではなく、想定ユースケースです。AIが情報を解釈する部分と、確定した条件で動く部分、人が判断する部分を分けて考えます。
| IT運用 | HR業務 |
|---|---|
| AI ログと過去の類似障害を照合し、対応候補を提示 | AI 自由記述から未完了の事情を整理し、担当者向け報告を作成 |
| 従来の自動化 監視データ収集、条件を満たす定型手順の実行 | 従来の自動化 複数システムの進捗取得、未完了判定、定型リマインド |
| 人間 重大な変更の承認、影響と復旧方針の判断 | 人間 例外対応の判断、人事評価の最終判断 |
障害対応なら、AIは収集ツールで得た情報から調査先を選び、対応候補を提示します。ただし、安全性を事前に確かめた定型対応でも、対象・実行回数・適用条件をAIの外側で検証してから動かします。重大な変更は担当者が承認します。
評価進捗なら、未完了者への定型リマインドはワークフローで足ります。AIを使うなら、部署ごとに異なる説明の整理などに絞る。連絡先や送信条件は確定データで確認し、重複送信を防ぎます。人事評価の最終判断までAIへ渡す設計にはしません。
AI自身の運用が、新しい仕事になる
AIが誤った対象を更新したり、過剰な権限で機密情報へアクセスしたりすれば、手戻りは大きくなります。メール内の指示を業務上の命令と取り違えることも考える必要があります。読んだ内容に従って、勝手に操作範囲が広がる設計は避けたいです。
NIST AI RMF 1.0は、統治、状況の把握、測定、管理の4機能から、AIのライフサイクルを通じてリスクを扱います。人とAIの役割や監督責任も明確にする考え方です。 [4] 先ほどの設計方針は、これを業務システムに当てはめた私の整理です。
Google SREの自動化の章でも、権限を絞った操作と監査記録、自動化を維持するチームの責任が扱われています。 [5] 私は、AIにも成功率や失敗率を観測し、変更を小さく試し、止められる状態を作る必要があると考えます。
Anthropicの評価資料は、AIの「完了した」という返答と、外部システムで本当に完了した状態を分けています。 [6] 送信履歴や更新結果まで確かめる必要があります。私はその検証時間も含め、従来より仕事が減ったかを測りたいです。
自働化と、人が介入する条件
トヨタの「自働化」は、異常を機械が検知して停止したり、作業者がラインを止めたりする仕組みです。異常の再発防止とともに、設備を見張り続ける負担の削減につなげます。 [7]
「品質を工程でつくり込む」
トヨタ自動車「トヨタ生産方式」 [7]
AIの処理に人が確認・承認で関与するHuman-in-the-loopにも、任せる範囲と介入条件を決める接点があります。ただし、生産設備の異常検知とAIの意味理解は同じではありません。AIは誤りに気づかず進むため、「自信がないときだけ聞く」では不十分です。
例えば、送信対象数の上限や重大変更の承認をプログラム側で強制します。すべてを人が常時確認するなら、見張る仕事が残ります。人を入れた事実だけで安心せず、確認の量と異常の見逃しを評価したいです。
標準化する裏側と、柔軟にする入口を分ける
ここからは私の考察です。「業務をシステムに合わせるか、その逆か」を、ひとまとめに決めなくてもよいのではないでしょうか。状態の定義、権限、承認、更新手順は標準化し、ユーザーとのやり取りにはAIの柔軟性を使います。
利用者は画面の場所を覚える負担を減らせるかもしれません。ただし、曖昧な依頼を確認する会話が長ければ逆効果です。定型業務には従来の画面も残し、AIとの会話を必須にしないことが大切だと思います。
業務を遂行するシステムを、成果で評価する
人間がすべての操作を担わなくても、仕事が進む可能性は広がっています。一方、確認や復旧が増えれば、改善の余力は戻りません。
次回はこの考え方を統合し、AI時代の業務支援プロダクトの設計原則を考えます。
連載：第1記事：改善する余力の不足 ／ 第2記事：管理者と現場のすれ違い
参考文献
[1] SAP（年記載なし）Understanding the Standard Business Processes。
[2] Microsoft（2026年更新）Introduction to desktop flows。
[3] Anthropic（2024）Building effective agents。
[4] NIST（2023）AI Risk Management Framework 1.0／AI RMF Core。
[5] Niall Murphy・John Looney・Michael Kacirek／Google（2016）The Evolution of Automation at Google。
[6] Anthropic（2026）Demystifying evals for AI agents。
[7] トヨタ自動車（年記載なし）トヨタ生産方式。
資料の説明は要約し、直接引用には引用符を付けています。工程の分担、設計案、業務負荷の評価は私の考察です。年記載のないWeb資料は2026年11月2日参照。
コメント