2026年10月8日に、Anthropicのエージェント設計、MicrosoftのRetry pattern、OWASP LLM06:2025、NIST AI 600-1を再読しました。Anthropicは単純で組み合わせ可能な構成から始め、複雑なエージェントは必要性で選ぶよう説明しています。Microsoftは一時障害だけを遅延付きで再試行し、上限・ログ・サーキットブレーカーを設け、非冪等操作の重複実行を考えるよう求めます。OWASPの最小権限とNISTのテスト・事故対応を含め、速度や自動化率だけで改善とは判断しません。
AIで返信文を作れるようになっても、確認や差し戻しが増えれば、業務全体は速くなりません。自動化を設計するときは、どの入力を受け、何をAIに任せ、誰が実行を許可し、結果をどう確かめるかを一つの流れとして考えます。
このガイドでは、メール対応・データ集計・申請処理を題材に、業務の選び方から試験運用までを整理します。数値例は計算方法を説明するための仮例です。特定の削減率や投資回収期間を保証するものではありません。
30秒で要点
- 必須項目の確認や合計計算など、規則で決まる部分は通常のプログラムで処理する。
- AIが作る分類・要約・文章は、検査する対象として扱う。生成できたことと、実行してよいことを分ける。
- 速さだけでなく、修正・例外対応・保守にかかった時間と、誤りの内容を記録して継続を判断する。
どこから読むか — 自分の状況から選ぶ
この記事は自動化する範囲の決め方と境界設計を扱います。個別の工程・ツール・費用はそれぞれ別の記事にあります。 いま決めようとしていることに近いところから入ってください。
指示の書き方から整えたい。 基本の型はプロンプトエンジニアリング入門、エージェント前提で何が変わるかはコンテキストエンジニアリングとの違い、業務で使う際の指針はLLMをビジネスで活用するベストプラクティス。
どの業務から始めるか選びたい。 工程の洗い出しはAIで業務プロセスを最適化する方法、小規模から始めるなら中小企業でも始められるAI活用、具体例から逆算するなら文書作成・データ分析・顧客対応の自動化事例。
費用と効果を見積もりたい。 月額の内訳は生成AI導入費用の内訳、成功・失敗の型から見るならAIとビジネスの統合パターン、事例の読み方そのものは成功事例をどう読むか。
運用で崩れないようにしたい。 先に失敗の型を知るならAI導入で失敗しないための5つのポイント、稼働後の監視はAIシステムのパフォーマンス監視、安全側の設計はAIシステムのセキュリティベストプラクティス。
開発・実装の現場に入れたい。 コード生成ツールの比較はGitHub Copilot・Cursor・Windsurfの選び方、Web開発への組み込みは生成・検証・公開の境界を設計するとWeb開発にAIを統合する方法。
用途が決まっている。 問い合わせ対応ならAIチャットボット導入ガイド、表計算からの移行はExcelからAI分析への移行ガイド、販促ならパーソナライゼーションと広告最適化、自社専用に作るならカスタムAIソリューションの開発。
ワークフローとAIエージェントは何が違うか
ここでいうワークフローは、入力から出力までの手順や分岐をあらかじめ定めた業務の流れです。その一部でAIを使えば、AIを組み込んだワークフローになります。たとえば「問い合わせを分類し、関連する社内資料を探し、返信案を作る」という流れです。
一方、AIエージェントには、状況に応じて次の手順や使うツールをモデルが選ぶ構成があります。Anthropicの設計記事も、この違いを説明し、まず単純な構成で足りるかを確かめるよう勧めています。自由度を増やすほど良いとは限りません。Anthropic：Building effective agents
表が収まらない場合は、横にスクロールできます
| 処理したいこと | 最初に検討する方法 | 確かめる点 |
|---|---|---|
| 日付・必須項目・上限金額を検査する | 固定ルール | 境界値や欠損の扱いが決まっているか |
| 決まった項目の合計を出す | SQLや集計プログラム | 単位・重複・締め日がそろっているか |
| 自由文から候補を抽出する | AIで抽出し、形式と原文を照合する | 推測を事実として埋めていないか |
| 承認済み資料から回答案を作る | 検索とAI生成を組み合わせる | 引用先にその説明があるか |
| 未知の問題を調べ、手順を組み立てる | 範囲を限定したエージェント | 調査範囲・費用・停止条件が明確か |
「請求額を確定する」のような処理では、AIの文章力よりも、元データと計算規則の正確さが中心になります。業務全体にAIを当てはめる前に、通常の自動化で解決できる部分を取り出しましょう。
対象業務を選び、現状の負担を測る
最初の対象は、件数があり、入力を集められ、正誤を確認しやすい業務から選びます。同時に、誤ったときの影響と戻しやすさを見ます。頻度が高くても、基準が未整理の重要判断は試験の難度が上がります。
着手前に、担当者と次の項目を記録します。
表が収まらない場合は、横にスクロールできます
| 項目 | 記録例 | 設計に使う理由 |
|---|---|---|
| 開始と完了 | 受信から、担当者が返信を送るまで | 下書き生成だけを完了と数えないため |
| 処理量 | 週ごとの対象件数と除外件数 | 繁忙期や簡単な案件だけの比較を避けるため |
| 作業時間 | 読む・調べる・書く・確認する時間 | どの工程に負担があるかを見るため |
| 品質 | 誤回答、差し戻し、再問い合わせ | 速くなっても悪化させられない条件を決めるため |
| 例外 | 資料不足、個別契約、判断が割れる案件 | 人に戻す条件を先に用意するため |
| 責任と制約 | 業務責任者、利用可能な資料、保存期間 | データと判断を無制限に渡さないため |
作業時間と、順番を待つ時間は分けて測ります。生成が数秒になっても、確認担当者の待ち行列が長ければ、顧客への回答は遅れたままです。平均だけでなく、時間がかかった案件の理由も残します。
目標は「全体の処理時間を一律70%減らす」と先に決めるより、現状を測ってから業務責任者と合意する方が判断しやすくなります。「重要な誤回答を許容しない」「保留案件を翌営業日までに確認する」など、品質と対応期限も一緒に定義してください。
入力から実行までの境界を作る
次の図は、返信案を作る業務を想定した設計例です。矢印は検査を通ったときの進み方を表します。各段階で不明点があれば保留に戻せるようにします。
入力：受け取ってよい資料を決める
入力元、必須項目、対象期間、利用者が閲覧できる範囲を定めます。資料が欠けている場合は、AIに補完を期待せず、未確認として残します。個人情報や機密情報を扱う場合は、使用するサービスの契約・保存条件と組織の規則に従い、処理に必要な項目に絞ります。
外部から届いたメールや添付資料には、処理手順を変えさせる文章が混ざる可能性があります。業務データとして読み取る文章を、実行権限を変更する指示として扱わせない設計が必要です。検索で資料を追加するRAGも、この問題を完全には防ぎません。OWASP：Prompt Injection
処理：AIの出力を確定値にしない
出力項目を、分類候補、回答案、参照資料ID、未確認事項などに分けます。形式・文字数・必須項目はコードで検査し、事実や業務上の妥当性は原資料と照らします。「JSONとして読める」ことは「内容が正しい」ことを意味しません。
AIが「確信度95%」と書いても、それだけで承認基準にはできません。実際の対象データで誤りを測った評価が必要です。また、別のAIに確認させても同じ誤りを見逃す場合があるため、それだけを最終判断の根拠にしないようにします。
判断：誰が、何を許可したかを残す
下書きを閲覧することと、顧客に送ることでは影響が違います。利用者の権限、送信先、対象内容、業務上の承認条件を、実行側で確認します。AIが出した「承認済み」という文字列で、その検査を省略しない設計にします。OWASP：Excessive Agency
人が承認する画面では、原文・参照資料・変更点・未確認事項を確認できるようにします。承認後に送信先や本文が変わった場合に、古い承認がそのまま使われないことも大切です。低影響で条件の明確な処理を自動実行する場合も、事前に合意した規則と権限の検査を通します。
出力：実行の結果を記録する
記録には、案件ID、処理状態、使った資料や設定の版、承認した対象、実行結果を含めます。機密文書や秘密情報をすべてログへ複製する必要はありません。何を保存し、誰が閲覧し、いつ削除するかを決めてください。
モデルへの依頼回数、費用、処理時間にも上限を設けます。上限に達したら、途中の結果と理由を残して担当者に戻します。終わらない再生成を、成功するまで続ける設計にしないことが重要です。
3つの業務に当てはめる
同じAIを使っても、完了条件と例外の扱いは業務ごとに変わります。次は導入方法を考えるための例です。
表が収まらない場合は、横にスクロールできます
| 業務 | AIに任せる候補 | 固定処理・人の担当 | 保留にする条件 |
|---|---|---|---|
| メール対応 | 用件分類、承認済み資料を使った返信案 | 宛先確認、契約・金額の確認、送信判断 | 根拠資料なし、個別条件、苦情の対応方針が未確定 |
| データ集計 | 自由記述の分類案、集計結果の説明案 | 件数・合計の計算、重複除去、元データ照合 | 単位不一致、欠損増加、未定義の分類 |
| 申請・承認 | 申請内容の要約、不足資料の候補提示 | 金額上限、承認者の権限、規程に基づく判断 | 規程の解釈が割れる、例外契約、資料の不整合 |
メールの例なら、最初は自動送信をせず、担当者が普段どおり送れる下書きを作ります。修正箇所が多いときは、プロンプトだけでなく、参照資料が古くないか、入力が足りないか、分類が細かすぎないかを調べます。
集計では、AIに表を読ませた結果を正解にせず、計算を再現できる形で残します。承認業務では、要約の出来が良くても、決裁の責任や権限が移るわけではありません。役割分担はAI導入の責任境界でも整理しています。
確認と保守を含めて効果を計算する
仮に、週100件の返信に1件6分かかり、合計600分を使っているとします。AI導入後も全100件を確認し、例外案件には追加対応が必要です。次の表は、同じ件数・同じ完了範囲で比べるための架空の3条件です。
表が収まらない場合は、横にスクロールできます
| 条件 | 全件の確認 | 確認後の追加例外対応 | 週の保守 | 合計 | 導入前600分との差 |
|---|---|---|---|---|---|
| 確認が軽い | 100件×1分 | 10件×5分 | 60分 | 210分 | 390分減 |
| 確認が中程度 | 100件×2分 | 10件×5分 | 60分 | 310分 | 290分減 |
| 修正が多い | 100件×4分 | 30件×5分 | 120分 | 670分 | 70分増 |
例外対応は、全件確認に含まれない追加時間です。この例では、AIの生成中に人が待機する時間は含めていません。待機が必要なら追加します。品質が同等であることも別に確かめなければ、この時間差を改善とは呼べません。
費用を比べるときは、初期設計・データ整備・教育の費用に加え、モデル利用料、連携サービス、監視・保守、差し戻し対応を含めます。空いた時間を人件費換算した金額と、実際に減る支出は区別しましょう。一律に「3〜6か月で回収できる業務がよい」とは決められません。担当者が別の仕事に使えた時間や、回答までの待ち時間の変化も判断材料になります。
例外と再試行を先に設計する
失敗をひとまとめにすると、直らない処理を繰り返したり、同じ操作を二重に実行したりします。最低限、次の状態を区別してください。
表が収まらない場合は、横にスクロールできます
| 状態 | 例 | 次の対応 |
|---|---|---|
| 入力が不十分 | 必須資料がない | 不足を記録し、担当者へ戻す |
| 出力を採用できない | 根拠と回答が矛盾する | 理由を残し、限定回数の修正か人の処理へ |
| 一時的に利用できない | 外部サービスが混雑 | 回数と待ち時間を決めて再試行する |
| 実行結果が分からない | 送信要求後に接続が切れた | 状態を照会し、確認できるまで保留する |
| 業務条件が変わった | 承認後に申請内容が更新された | 古い承認を使わず、対象を再確認する |
とくに「応答がない」は「実行されていない」と同じではありません。相手側では成功していることがあります。MicrosoftのRetryパターンも、再試行によって意図しない重複が起きる点を説明しています。Microsoft Learn：Retry pattern
送信先が対応している場合は、同じ業務操作を識別するキーを使い、同じ操作を重複実行しない仕組みを組み合わせます。単にログへIDを付けるだけでは防げません。照会も重複防止もできない操作は、結果不明のまま自動で再送しない運用を用意します。
試験から運用へ進める条件
まず、許可された過去案件や作成した試験データで、正解と照合できる状態を作ります。通常案件だけでなく、資料不足、表記ゆれ、矛盾、古い規程、外部文書内の不適切な指示、タイムアウトも含めます。
評価用の案件は、調整に使った案件と分けます。担当者には、回答の採否と理由を記録してもらいます。NISTの生成AI向け資料は、狭い試験の結果が実利用へそのまま当てはまるとは限らないことを指摘しています。試験件数だけを増やすより、実務で出会う条件を含めることが大切です。NIST AI 600-1：Appendix A.1.4
段階は、たとえば次のように分けられます。
- 試験データで確認する：形式、根拠、例外、権限検査、停止条件を確かめる。
- 実業務の横で試す：許可されたデータを使い、業務結果を変えずに人の処理と比較する。
- 人が確認して採用する：対象を限定し、修正時間と誤りを測る。
- 条件を満たす範囲だけ自動化する：対象・件数・影響を限定し、監視と戻し方を用意する。
第4段階へ進むこと自体が目的ではありません。下書き支援のままで十分な価値があれば、その範囲で運用できます。運用開始後も、モデル・資料・入力傾向が変わったときは再評価し、重大な誤りや保留の増加があれば対象を狭めるか止めます。
最初の設計書には、対象業務、完了条件、利用データ、担当者、採用基準、例外の戻し先、費用上限、停止方法を1ページにまとめてください。実装の選択を詳しく考える場合はAIエージェント開発ガイド、業務全体の見直しにはAIによる業務プロセス最適化が次の読み先になります。