AIエージェントのワークフロー設計とは、大きな依頼を「作業」「確認」「承認」の工程に分け、AIに任せる工程と人間が判断する工程を前もって決めることです。チャットへの単発依頼と違い、確認地点と完了条件を明示することで、出力のばらつきと取り返しのつかないミスを減らせます。NISTのAIリスク管理フレームワークも、AIシステムに「説明責任（accountable）」と「人間による監督」を組み込むことを求めています[1]。
AIエージェントのワークフローとは
ここでいう「ワークフロー」は、AIエージェントに一連の作業を任せる際の工程の設計図です。カード1枚が1つの作業（調べる・書く・確認する・公開する）を表し、それらを順に並べます。AGENT WORKBENCHでは、この設計図をブラウザ上で視覚的に組み立てられます。
「エージェント」という語は文脈により幅がありますが、ここでは人間の代わりに複数の工程を自律的に進めるソフトウェアを指します。一連の工程を任せる以上、どこで人間が介入し、どこで止めるかを設計図に残すことが、後からの検証と責任の所在を明確にします。
チャットへの単発依頼との違い
「サイトを改善して」「記事を書いて」と一度に頼むと、AIは多くを推測して進めます。推測が外れても気づきにくく、どこで間違えたかが後から分かりません。ワークフロー設計では、次の点を先に決めます。
- 目的は何か
- どの工程をAIが、どの工程を人間が担うか
- どこで事実確認し、どこで承認するか
- 何をもって完了とするか
単発依頼は「結果」を頼むのに対し、ワークフロー設計は「過程と判断の所属」を決めます。同じ結果でも、誰がどの段階で責任を持つかが異なり、トラブル時の切り分けが変わります。
設計前に決める3層
Task（作業）
「何をするか」を小さな単位に分けます。1工程につき1つの明確な出力があると、AIが得意な作業と人間が見るべき作業が分けやすくなります。
Checkpoint（確認）
AIが作ったものを人間が見る地点です。事実・数値・出典・意図が狙い通りかを確認します。公開や削除といった取り返しのつかない一歩の前には必ず置きます。
Definition of Done（完了条件）
「これでよし」の基準を事前に言葉にします。基準がないと、終わったつもりで肝心の確認が抜けます。
deterministic / probabilistic の見極め
作業を分ける目安の一つが、その工程が決定的（deterministic）か確率的（probabilistic）かです。
- 決定的：同じ入力なら同じ出力（集計、整形、差分抽出、ファイル操作）。人間の承認よりも「実行前の確認」と「ログ」が効く。
- 確率的：出力が毎回変わり得る（文章生成、要約、分類、提案）。AIが得意ですが、事実や意図のズレが起きやすいため、直後の人間確認が効く。
「AIに任せる」をざっくり決めるのではなく、この軸で分けると、どこに確認を置くべきかが自ずと見えてきます。
可逆 / 不可逆操作の分け方
もう一つの軸が、操作が取り消し可能（可逆）か取り消し困難（不可逆）かです。
- 可逆：下書き、ローカル保存、ブランチ作成。失敗しても元に戻せる。
- 不可逆：公開、削除、外部送信、支払い、本番反映。一度実行すると巻き戻しにコストがかかる。
不可逆操作の直前には、原則として人間の承認（approval gate）を置きます。AIコーディングでも「本番反映」は不可逆に近いため、承認を分離します。
failure mode を前もって書く
各工程に「ここが失敗したらどうなるか」を一言書きます。例えば「改善案を列挙する（AI）」なら「実現困難な案が混ざる」。それに対する確認を次の工程に置くと、失敗が本番へ抜けにくくなります。NIST AI RMFは、リスクを「事前に想定し、継続的に見直す」ことを基本としています[1]。
approval gate（承認ゲート）の置き方
approval gate とは、特定の工程の直前に「人間がOKを出さないと先へ進まない」地点を設けることです。置くべきは次の3種です。
- 公開・削除：取り返しのつかない表示・消去。
- 外部送信・支払い：第三者や金銭へ影響が出る。
- 本番反映：ユーザーやシステムへ届く最後の一歩。
承認ゲートを置きすぎると作業が止まり、置かなすぎると事故が本番へ出ます。初期は「不可逆操作の直前」に絞り、運用しながら増やします。
7ステップの設計手順
- 目的を一文で書く
- 対象範囲とやらないことを決める
- 必要な作業をカードに分解する
- 各カードの担当（AI/HUMAN/SHARED）を決める
- AI生成の直後に人間確認を置く
- 公開・削除・支払いの前に承認を置く
- 完了条件を明記する
AI / HUMAN / SHAREDの判断表
AI / HUMAN / SHARED は、AGENT WORKBENCHが提案するサイト独自の実務モデルです。公的基準が定める役割ではなく、作業の「誰が主体か」を3つに分けた運用ルールです。
| 作業の性質 | 推奨 | 理由 |
|---|---|---|
| 調査・下書き・分類・提案 | AI | パターン処理が得意 |
| 事実照合・出典確認・最終承認 | HUMAN | 誤りの影響が大きい |
| 表現調整・保存・ログ | SHARED | AIが下書き、人間が仕上げ |
責任境界を言葉にする
「AIが書いた」「人間が承認した」だけでは、責任の所在が曖昧です。設計図に次の一言を添えます。
「この工程の出力について、事実確認と公開判断の責任は人間（HUMAN）が持つ。」
OECDのAI原則も、AIシステムのライフサイクルを通じて「法の支配・人権・人間中心の価値」を尊重し、人間が説明責任を持つことを求めています[2]。責任境界を設計図に残すのは、この方針と整合します。
Webサイト改善の実例
既存プリセット「Webサイトを改善する」と同じ構成です。
- 対象範囲を決める（HUMAN）
- 現状を確認する（HUMAN）
- 改善案を列挙する（AI）
- 優先順位を決める（HUMAN）
- コードを生成する（AI）
- 差分を見る（HUMAN）
- テストする（HUMAN）
- 危険な変更がないか確認する（HUMAN）
- 保存する（SHARED）
- 公開する（HUMAN）
悪いフロー
「サイトを良くする」→ いきなり「コードを生成する」→「公開する」。目的も範囲も確認もなく、AIの出力をそのまま本番へ流します。
改善後のフロー
範囲決定→現状確認→改善案→優先順位→生成→差分→テスト→リスク確認→保存→公開。各AI工程の直後に人間確認があり、公開前に承認があります。
受け渡しが多すぎる場合
AIと人間の往復が極端に多いと、どこで何を確認したかが曖昧になります。工程をまとめ、確認を「事実」「リスク」「最終承認」の3地点に絞るのが現実的です。
よくある失敗
- 目的を書かずに生成を始める
- AI生成の直後に人間確認を置かない
- 公開をAI任せにする
- 完了条件を口頭だけにする
- 失敗モードを書かず、事故の原因が分からなくなる
FAQ
- AIに全部任せるワークフローではだめですか？
- 取り返しのつかない操作（公開・削除・支払い・外部送信）を含む場合、人間の承認を置かないとミスがそのまま本番へ出ます。
- SHAREDとHUMANの違いは？
- SHAREDはAIが下書きし人間が仕上げる共有作業（表現調整など）。HUMANは人間が主体で判断します。
- ワークフローは保存できますか？
- はい。ブラウザのlocalStorageに保存され、外部へは送信されません。JSONエクスポートや共有URLでも持ち出せます。
- approval gate を多く置くと作業が遅くなりませんか？
- 置きすぎはボトルネックになります。まず「不可逆操作の直前」に絞り、運用しながら調整します。
- AI/HUMAN/SHAREDは公的基準ですか？
- いいえ。AGENT WORKBENCHが提案するサイト独自の実務モデルです。公的資料（NISTやOECD等）は「人間の監督を組み込む」という方向性を示し、具体的な分担は各現場で決めます[1][2]。
- 小さな作業でもワークフローを書くべき？
- 一度きりの小さな作業なら口頭でも足ります。繰り返す作業や、人が代わっても同じ品質を保ちたい作業に向いています。
テンプレートを開く
参考資料
- AI Risk Management Framework (AI RMF 1.0) — NIST 原文を確認 確認日：2026-07-13
- OECD AI Principles — OECD 原文を確認 確認日：2026-07-13
- タスク分解のガイド
- Human-in-the-loopのガイド
- サイト改善の実例
- AGENT WORKBENCH ツール：https://agent-workbench.kawaii-girl.com/
最終確認日：2026-07-13