エージェント型ワークフロー設計：デモ自動化から本番信頼性へ

2026年4月2日Lin Ivan

重要なポイント

デモが本当のワークフローになるのは、不完全な入力や部分障害、policy の境界を越えても危険な即興に頼らず動けるときです。
本質的な設計課題はモデルの賢さではありません。実行前に state、context、tool scope、approval、recovery をどう定義するかです。
人間のレビューは弱いシステムの補助輪ではありません。むしろ、安全に価値ある自動化を早く出すための重要な制御です。
信頼できるエージェント型ワークフローは、計画、承認、実行を分離します。同じ step が「判断」と「実行」を同時に持つべきではありません。
puppyone は、毎回ばらばらのシステムから証拠を寄せ集めるのではなく、統制された context bundle に依存したいときに役立ちます。

多くのエージェントデモに潜む「見えないオペレーター」問題

初期のエージェントデモが実態以上によく見えるのは、人間のオペレーターが静かに一部の仕事を引き取っているからです。

エージェントに渡す前に入力を整える
context が古いことに気づく
どの tool が安全かを判断する
出力が十分かどうかを見極める
実行が被害を出す前に止める

そのため、最初の本番運用で「急に壊れた」ように感じることがあります。実際には、信頼性を支えていた見えない人間の層が消えただけです。

だからこそ、よいワークフロー設計は次の問いから始まります。

オペレーターが忙しく、入力も雑だったら何が起こるか。

この問いに対する答えが「prompt が何とかしてくれる」であれば、それはまだデモです。

Anthropic の effective context engineering for AI agents は、問題の焦点を prompt wording から、モデルに渡される context state 全体へ移しています。本番ワークフローが壊れるのもまさにそこです。モデルが文を「忘れた」からではなく、ワークフローが間違った state や tool、あるいは境界のない実行環境を渡したからです。

本番で見るべき六つの制御面

tool を増やしたり agent persona を増やしたりする前に、まず次の六つを明確にしてください。

制御面	設計上の問い	曖昧だと何が壊れるか
Goal contract	この run は何を正確に達成すべきか	エージェントが脱線し、余計なことまでやる
State model	何が完了済みで、何がまだ暫定か	リトライで作業が重複し、人間も安全に再開できない
Context contract	この step を形作ってよい証拠は何か	古い情報、ノイズ、矛盾が混ざる
Tool boundary	この step で許される action は何か	何でもできそうに見えて、必要以上に手を伸ばす
Approval policy	どの action が実行時の review や policy check を要するか	リスク制御が prompt の文言だけに依存する
Recovery path	step が失敗したり confidence が低いとき、どう止まるか	timeout や弱い回答で全体が止まる

この表は意図的に地味です。信頼できるワークフローは、派手さよりも地味な明確さから生まれます。

NIST の AI Risk Management Framework も、traceability、control、lifecycle management を重視しています。エージェントワークフローでも同じです。どの evidence を使い、どの tool が開いていて、どの policy gate が働き、なぜ継続または停止したのかを説明できるべきです。

最も重要な分離線は「計画」と「行動」の分離

一つの step に判断と実行を同時に持たせることは、ワークフローを危険にする最短ルートの一つです。

たとえば次のような指示です。

「チケットを読んで顧客に最終返信を送る」
「取引を確認して返金を承認する」
「問題を要約して本番設定を変更する」

一見効率的ですが、実際には judgment と action を一つの prompt 形状の塊に押し込んでいます。

より強い本番パターンは次の形です。

evidence を集める
plan を提案する
policy を確認する、または approval を求める
狭い一つの action を実行する
audit record を残す

これは一見遅く見えても、デバッグしやすく、展開しやすく、スケールしやすい形です。各 step の役割が違うため、ワークフローが検査可能になります。

「考える」と「動く」の間に review 可能な artifact が作れないなら、それは設計上の匂いです。artifact は小さくて構いません。

計画の要約
構造化された diff
リスクラベル
confidence と evidence ID を持つ action proposal

大事なのは官僚化ではなく、side effect が起きる前に decision seam を見えるようにすることです。

heroics ではなく resumability のために state を設計する

本番ワークフローは、最初から再開可能であるべきです。つまり、何が終わり、何を待ち、何なら安全に再試行できるかをシステムが知っている必要があります。

例として、次のような state shape が考えられます。

{
  "run_id": "wf_2026_04_02_1842",
  "status": "awaiting_approval",
  "current_step": "execute_change",
  "evidence_bundle_id": "ctx_8842",
  "proposal": {
    "action": "update_policy_exception",
    "reason": "ticket matches approved template",
    "confidence": 0.78
  },
  "approval": {
    "required": true,
    "requested_from": "ops-reviewers",
    "requested_at": "2026-04-02T14:20:00Z"
  },
  "side_effects": [
    {"step": "collect_context", "status": "complete"},
    {"step": "propose_plan", "status": "complete"}
  ]
}

重要なのは完璧な schema ではなく、明示性です。

こうした state を持つと、次のことが起きます。

失敗した一 step だけをリトライできる
なぜ pause したかを operator がすぐに理解できる
人間は chat history 全体ではなく、コンパクトな object を見ればよい
audit log が action と evidence、decision state を結びつけられる

これは「エージェントが覚えていてくれることを祈る」から、「設計として再開可能である」への転換です。

human-in-the-loop は decision seam に置くのが最も効く

人間の承認を入れる場所が遅すぎたり、間違っていたりするケースは多いです。エージェントが読んだものを人間にも全部読み直させると、自動化は手作業に戻ってしまいます。

よりよいパターンは、ビジネスリスクが集中する seam に人間を置くことです。

destructive write の前
外部へのコミュニケーションの前
policy exception の前
弱い evidence に基づく action の前

そして reviewer には短時間で判断できる対象を渡すべきです。

よくない approval object	よい approval object
chat transcript 全体	evidence link つきの一つの action proposal
生の document dump	source ID つきの compact な evidence bundle
「全部見てください」	一つの decision への approve / deny / request changes

人間の review は、元のワークフローを手で再実行するためではなく、リスクを除くためにあります。

提案された action を一分以内で理解できないなら、問題は upstream にあることが多いです。context が多すぎる、state が弱い、または action contract が曖昧なのです。

見た目以上に本番で持つワークフローの形

信頼できるものを出すために巨大な orchestration platform は必須ではありません。小さくても明示的なワークフローでかなりの距離を進めます。

trigger:
  source: inbound_request

steps:
  - collect_context
  - compact_evidence
  - propose_plan
  - check_policy
  - request_approval_if_needed
  - execute_one_narrow_action
  - write_audit_log
  - return_summary

fallbacks:
  on_missing_context: ask_for_more_input
  on_low_confidence: route_to_human
  on_tool_failure: retry_once_then_pause
  on_policy_violation: block_and_log