プレイブックの読み方 ― 「そもそもエージェントが要るか」から
各ユースケースを見る前に、判断の順序を揃えておきます。エージェント設計の第一の問いは、常に「ワークフローで足りるならそちらへ」です。手順があらかじめ決まっている定型処理なら、確率的に振る舞うエージェントより、決定的に動くワークフロー自動化のほうが安全で保守もしやすい。適用判断で「エージェント不要」に落ちることは失敗ではなく、正しい判断です。エージェントが真価を発揮するのは、何をどこまでやるかが進めながら決まる、手順が動的なタスクに限られます。
この関門を通ったタスクは、次の3項目で設計します。本コラムの各ユースケースもこの順で読んでください。
- 構成。どんなツールを、どういう処理の流れで組むか。どこにゲート（人の承認や機械検証の関門）を置くか。
- 自律性設計。どこまで任せ、どの操作で人が承認するか。後述の自律性レベルで表現します。
- リスク。そのタスクで事故が起きる場所と、それを受け止める仕組み。
自律性は「エージェント全体」ではなく操作ごとに設定するのが要点です。目安として、人が実行前に毎回承認する段階を低自律、定義済みの低リスク操作だけ自動化して例外は承認する段階を中自律、範囲内は自動実行して事後にサンプル監査する段階を高自律と呼びます。同じ業務の中で「検索は高自律・提出は低自律」のようにツールごとにレベルが割れるのが正常であり、その解像度の高さがそのまま安全性になります。
代表5ユースケース ― 一覧で見る
実務で相談の多い5つを、適用判断の要点と自律性の目安で並べます。注目すべきは、5つのうち2つ（UC2・UC5）の第一候補がワークフローである点です。エージェント化の誘惑が強い領域ほど、実は定型処理だったというのはよくあることです。
| ユースケース | 内容 | 適用判断の要点 | 自律性の目安 |
|---|---|---|---|
| UC1 調査・レポート作成 | 社内外の情報収集 → 整理・分析 → レポート化 | 手順が動的で適性が最も高い定番。最初の1本に最適 | 読み取り中心のため中〜高自律から可 |
| UC2 社内手続き代行 | 出張申請・修理依頼などを社内システムで代行 | 定型ならワークフローで足りる。複数手続きを跨ぐ場合のみ | 作成は中自律／提出は低自律必須 |
| UC3 開発支援（コーディング） | issue → 修正・テスト → プルリクエスト提出 | 探索が本質。戻せる・検証できる仕組みが既にある | 砂場は高自律・マージは人 |
| UC4 データ処理パイプライン | 非定型データの整形・変換・突合 | 固定形式はETLで。入力の多様性が高い場合のみ | 本流反映は検証ゲートの先 |
| UC5 複数SaaS横断 | 受注→CRM更新→請求→調整→通知の一連処理 | 原則ワークフローで作る。例外処理だけ委譲を検討 | 幹は従来・枝は低〜中自律 |
UC1 調査・レポート作成 ― 最初の1本に最適
読み取り系ツールで情報を集め、構成案を人に示してから調査ループを回し、出典を付けたドラフトを生成、確定は人が行う流れです。何をどこまで調べるかが進めながら決まる典型で、エージェント適性が最も高い。書き込みが下書きフォルダに限られ、誤りの影響は読む人が検証できるため、例外的に中〜高自律から始められます。主なリスクは、読んだWebや文書経由の間接的なプロンプトインジェクションと、もっともらしい誤要約。対策はシンプルで、出典のない記述を出させない設計にすることです。
UC2 社内手続き代行 ― 大半はワークフローで足りる
「出張申請しておいて」を社内システムを操作して代行するもの。手順が定型ならワークフローで足り、複数手続きを跨いで要件を対話で確定する場合にのみエージェントの出番です。設計の肝は、本人名義の行為は本人の承認を技術的なゲートにすること。作成までは中自律でも、提出は低自律（本人承認必須）で恒久固定します。主なリスクはなりすましと誤った申請の量産で、認証との紐付けをLLMの外で行い、冪等性（同じ内容の重複起票を遮断）と取消可能性を担保します。
UC3 開発支援（コーディング）― 最も成熟したUC
issueを受けて隔離環境（サンドボックス）で実装し、プルリクエスト経由で反映、CIとセキュリティスキャンを自動ゲートにし、マージは人が行います。Gitとレビューという「戻せる・検証できる」仕組みが既にある稀有な領域で、2026年7月時点で最も成熟しています。サンドボックス内は高自律で自由に試行錯誤させてよい一方、本番環境や秘密情報にはアクセスさせません。主なリスクは依存パッケージの捏造や脆弱なコードの混入、そしてレビューの形骸化。PRの差分行数に上限を設け、人が読み切れる量に保つことが支えになります。
UC4 データ処理パイプライン ― 本流反映は検証ゲートの先
形式がばらばらの取引先データの取り込みなど、非定型な整形・変換・突合を状況判断しながら処理します。固定形式なら通常のETLで足り、入力の多様性が高い場合にのみエージェント。ステージング（一時領域）まで出力し、件数・合計値・形式を機械で独立に突合してから本流へ反映します。数値計算はAIに任せずコードで決定的に行うのが鉄則。主なリスクは入力データ経由の間接インジェクションと、静かなデータ破損です。検証不一致は黙って補正せず例外キューへ送ります。
UC5 複数SaaS横断 ― 原則ワークフローで作る
「受注→CRM更新→請求書発行→日程調整→関係者通知」のように複数サービスを跨ぐ一連処理です。手順が事前に決まるため適用判断で落ちやすく、エージェント化の誘惑が最も強いのに最も不要なユースケース。設計方針は「幹＝ワークフローで決定的に、枝＝非定型な判断だけAIに委譲」。委譲部分の自律性は低〜中に留め、承認ポイントは従来どおり幹のワークフロー側で持ちます。全体をエージェント化すると毎回経路が変わり監査が通らなくなるのが最大のリスクです。
5つのユースケースは業務こそ違え、失敗の型は似ています。自己申告を信じる／承認の形骸化／権限の過剰付与／最初から高い自律性／手段の目的化の5つです。対策はいずれも賢さではなく構造の側 ― 出典必須・独立検証、人が読める量への制限、最小権限の専用ツール、実績に基づく段階昇格、そして適用判断の徹底 ― にあります。エージェントの出力は、エージェント以外の何か（出典・検証コード・人）で確かめるのが共通の背骨です。
「最初の1本」の選び方 ― 土台と受け皿で決める
どのユースケースから始めるかは、やりたい順ではなく「事前に要る土台」と「誤りの受け皿」の有無で判定します。次の5つのチェックにすべて「はい」と言えたときに着手してください。
- 適用判断を通過している。「ワークフローで足りる」に落ちていない。
- 影響を限定できる。読み取り専用にできる、または書き込み先を隔離・下書きに絞れる。
- 完了条件が明確。何をもって「できた」とするかを機械や人が判定できる。
- 件数がある。繰り返し発生し、評価データが貯まる業務である。
- 受け皿と担い手がいる。戻せる・検証できる仕組みがあり、業務オーナーと昇格を決裁する人が決まっている。
一般則はシンプルです。開発組織があればUC3、なければUC1から。どちらも誤りを「戻せる・検証できる」受け皿が最初から強く、立ち上げ期間の目安も数週間と短い。UC2・UC4は土台（規程RAGや検証ルール）の整備に一〜二ヶ月、UC5の委譲は運用実績が貯まってからが原則です。土台の不足が2〜4週間で埋まる見込みかどうかも、着手可否の重要な物差しになります。
成熟度モデルと3原則 ― 自律性は最後に足す
個別の1本を超えて、組織としてのエージェント活用度は5段階で捉えられます。ガードレールなしで試すだけのLv0（実験）、適用判断を通した1タスクがハードリミットとトレース付きで動くLv1（統制された最初の一歩）、繰り返し評価で信頼性を測りデータを根拠に自律性を段階昇格するLv2（実績に基づく拡大）、許可済みツールカタログや共通ガードレール・停止訓練が基盤化されるLv3（組織能力化）、そして限定領域で高自律運用が定着するLv4（高度自律）です。本シリーズの最初の到達点はLv1。Lv1→Lv2の橋は「評価データ」、Lv2→Lv3の橋は「共通基盤」であり、2026年7月時点でLv4が現実的なのは一部領域に限られます。
① 自律性は最後に足す。まず提案のみ・読み取り専用から始め、実績データを根拠に一段ずつ上げる。最初から高自律で設計しない。
② 間違えても被害が限定される構造を先に作る。リスク管理はAIを賢くすることではなく、権限・上限・承認・隔離・即時停止の構造を先に用意すること。
③ 多くの業務は、エージェントでなくワークフローで足りる。適用判断で落ちるのは失敗ではなく正しい判断。UC2・UC5がその実例です。
始め方は「1本ずつ・構造で・実績から」に尽きます。読み取り専用や提案のみといった影響の小さいところから着手し、評価データで信頼性を確かめ、そのうえで承認の関門を一段ずつ緩める。この順序を守れる組織だけが、エージェントの便益を事故なく手にできます。自社に近いユースケースを1本選び、適用判断から自社のタスクで回し始めることが、最も確実な第一歩です。