このページの内容
提案された同期には20個の箱があります。7番目はステータスをスプレッドシートへコピーし、8番目はメール基盤向けに形式を変え、9番目は取り込み承認を求めて管理者にメールします。計画では、7番から9番をどのエージェントが行うかを問います。
最初に問うべきは、なぜそれらの箱があるかです。これは説明用の例であり、実在チームの監査ではありません。
ワークフロー設計に関する対談は作業を4つに分けます。手順を削る、通常のコードを使う、エージェントを使う、人の決定を残す、です。役立つ判断はモデル選びの前にあります。1手順を削れば、周囲の仕組みも不要になるかもしれません。
顧客に見える成果から始める
ワークフローが生むべき結果を名付けます。店舗とメールの接続なら「購入した顧客にカートのリマインダーが届かない」かもしれません。この結果には状態、時間、送信抑制の規則が必要です。スプレッドシート、毎晩の全件エクスポート、管理者の受信箱までは必要としません。
以下のTajoの図は、提案された対応付けと有効化前の境界に焦点を当てています。カート通知の停止機能を実装した図ではありません。その結果を得るには、購入を示す信号と停止ルールを先に定める必要があります。項目を増やしても代わりにはなりません。
実行前に同期を確認
顧客の更新をメール配信サービスに同期してください。
顧客同期
| 元のフィールド | 送り先のフィールド | ルール |
|---|---|---|
email | EMAIL | そのまま |
first_name | FIRSTNAME | そのまま |
last_name | LASTNAME | そのまま |
合成データでのプレビュー成功
3項目を対応付け · 送り先への書き込みなし
Tajoの対応付けツールを基にした概念図です。合成データでのプレビューや保存した下書きだけでは同期は有効になりません。
結果から既存の経路を逆にたどります。各手順が消えたら何が失敗するかを問います。実際の統制なら、同意が失われる、支払いに関する争いを無視する、許可されない送信が起きるなど、答えがあります。慣習的な引き継ぎの答えは「古いシステムでファイルが必要だった」だけかもしれません。
削除する分類は、安全策を消す許可ではありません。分類する前に各手順の目的を調べます。
- 必要な成果顧客への結果逆にたどる
- 手順を点検目的と統制不要な手順を削る
- 残す作業担当と検証方法あり
点検では、成果物と本当にそれを守る依存関係を見つけます。スプレッドシートに他の場所にない業務判断が記録されているなら、ファイルをなくしても判断は残す必要があります。
| 手順の種類 | 問い | カート処理の例 |
|---|---|---|
| 削除 | 必要な成果を守るか、生みますか？ | 誰も読まない重複エクスポート |
| 通常のコード | 規則は厳密で安定していますか？ | 購入が確認できたらリマインダーを抑制 |
| モデルの判断 | 範囲を限った解釈が必要ですか？ | 自由記述の依頼を適切なチームに分類 |
| 人または承認済み方針 | 権限を与えるか、重大な結果を伴いますか？ | 顧客データへのアクセスを承認 |
この表は設計の道具です。実際の企業の手順分類結果ではありません。
厳密な規則はコードに置く
API 呼び出し、項目の検証、時刻の比較、権限確認は、モデルに即興で行わせてもよくなりません。コードなら不変条件を表せて、再実行しても同じ結果になり、失敗も調べられます。規則を明文化できるところに使いましょう。
カートの例では購入イベントが遅れて、または2回届くかもしれません。プログラムは注文を識別し、現在の状態を比較して、購入が分かっている場合にリマインダーを拒否すべきです。購入の有無を確定できないなら、不確実という状態が必要です。モデルが「購入していない」と推測する権限を自ら与えることはできません。
厳密な規則では扱いにくい作業もあります。「昨日買ったのに領収書には古い住所が載っている」というサポート依頼の振り分けには、範囲を限った意味判断が使えるかもしれません。出力は既知の担当チームか「不確実」とし、注文を変更する自由な指示にはしません。モデルの判断を、アクセス制御と状態の書き込みの制約を確実に適用するコードから分離します。
1つのエージェントが手順を隠す理由
「1つのエージェントが手順を読んで全部やればよい」という案は実演では簡単に見えます。しかし本番では、なぜ記録を閲覧できるか、どんな行動が許されるか、誤った行動をどう戻すかを説明する必要があります。広範なエージェントは同じ手順をプロンプト内に隠し、監査に役立つ名前を消しがちです。
4分類の点検自体にも時間がかかるという反論もあります。その通りです。短く保ちましょう。顧客への結果を1つ選び、達成に必要な手順を並べ、それぞれの貢献を問います。作業を減らすか責任を明確にするときだけ価値があります。周辺システムすべての詳細な監査は、新たな箱になるだけです。
通常事例と失敗事例で分類を試します。削った手順が密かに統制を担っていたなら、試験で分かるはずです。モデルの判断を例で評価できないなら、範囲を狭めるか人に戻します。顧客ごとの例外で毎回コード変更が必要なら、安定した仕組みと各業務固有のルールを分けます。
点検には終了条件も必要です。すべての仕事を分解し続けると、分類の費用が削減分を上回ります。残した各手順に担当者、開始条件、検証できる存在理由が付いたら止めます。設計を変え得る不確実な点を1つ記録し、最小の実運用範囲で試します。同期なら、購入イベントが送信待ちリマインダーの抑制に間に合うかもしれません。連携ガイドは広い計画手順を示し、4分類は不要な手順を残さないために使えます。ワークフローや権限が変われば分類を見直します。
最も安い手順は、成果に初めから必要なかった手順です。
よくある質問
自動化する前に何を削るべきですか？
取り除ける引き継ぎ、重複記録、使われないレポートを補うためだけの手順は候補です。削る前に、後続の利用者と統制を確認します。
どんな手順にモデルが必要ですか？
安定した厳密な規則では表せない、範囲を限った意味判断に使います。観測できる入力、型の決まった出力、不確実な場合の経路を用意します。
どの決定を人に残すべきですか？
同意を必要とする、権限を与える、またはシステムに許された範囲を超える結果を伴う選択は、責任者か明示的に承認された方針に任せます。