著者注：「データの削除、お金の支出、方向転換のときだけ人に確認する」という考えを出発点に、Agent自動化システムにおける人間の意思決定の境界を定める3つの判断基準、承認フローの設計、CIによる検証との役割分担を解説します。
Agentが「会話相手」から「仕事を代行する存在」へと変わるとき、最も難しいのは、動かすことよりも、いつ立ち止まるべきかを決めることです。承認ポイントを増やしすぎれば、自動化は「人が確認ボタンを押すだけ」になってしまいます。逆に少なすぎると、一度の誤削除や制御不能な支出が、数か月分の効率化の成果を帳消しにしかねません。この記事では、Agentはいつ立ち止まって人に確認すべきかという問いを軸に、応用可能な人間の意思決定の境界の設計方法を紹介します。
これは「AIは危険だから注意しよう」という漠然とした議論ではありません。出発点となるのは、すでに公開されている実際のシステムです。個人メディアの運営者カズク氏は、約1年かけてAgent自動化システムを構築し、データの削除、お金の支出、方向転換という3種類の重要な判断に限って、Feishuのカードを通じて自分に判断を求めるようにしています。この記事では、この原則を判断基準として整理し、承認フローの設計方法も補足します。
この記事で得られること：どの操作をAgentに任せ、どの操作を人が確認すべきかを判断できるようになります。また、自動化を妨げずにリスクを抑える承認フローの設計方法もわかります。
Agent はいつ立ち止まって人に聞くべきか：3種類の判断ポイント
カジックのシステムが示す答えは、いたってシンプルです。人が登場するのは、3つの場面だけです。以下の表では、それぞれの判断ポイントと、その背後にあるリスクを整理しています。
| 判断ポイント | 典型的な操作 | リスクの本質 | 人の判断が必要な理由 |
|---|---|---|---|
| データを削除する | データベースのレコード削除、ファイルの削除、過去のバージョンの上書き | 不可逆性 | 一度実行すると、元に戻すコストが非常に高いか、復旧できない |
| お金を使う | 有料サービスの呼び出し、リソースの購入、モデル利用枠の大量消費 | 資金の流出 | 実際に費用が発生し、処理の繰り返しによって膨らむ可能性がある |
| 方向性を変える | コンテンツのテーマ調整、製品戦略の変更、既存ルールの書き換え | 目標への影響 | Agent にはビジネスの背景全体を把握し、価値判断を行う能力が不足している |
4層アーキテクチャにおける Agent と人の判断の境界
公開された概要によると、カジックのシステムの基本的な考え方は「タスクの起点を人から切り離す」ことです。人が一つひとつのタスクを開始するのではなく、イベントをきっかけに Agent が動きます。システム全体は4層に分かれており、人による判断は最後の層に置かれています。つまり、一連の流れを進める「アクセル」ではなく、「ブレーキ」として機能します。
| 層 | 役割 | 公開情報における実装方法 |
|---|---|---|
| 自動化プラットフォーム | イベントによる起動と Agent のスケジューリングを一元管理 | rules.json でルールを一元設定 |
| Agent 実行層 | Agent のタスクを実行 | ローカルの Mac Mini で実行 |
| CI プラットフォーム | レビュー、チェック、マージ、リリース、検証の5段階を担当 | 自社構築 |
| 飛書の判断層 | 重要な判断が必要なときに人の承認を求める | 飛書のカード |
この階層構造からは、重要な設計方針が見えてきます。「正しいかどうか」という問題の大部分は CI プラットフォームによる機械的な検証に任せ、「実行すべきかどうか」という問題だけを人に委ねる、という方針です。前者は客観的な基準でチェックできますが、後者には選択と責任が伴います。ここが、人の判断に委ねるかどうかを分ける核心です。
なお、元の資料は概要のみで、飛書のカードの具体的な項目、人による判断の頻度や応答時間、「方向性を変える」の正確な定義は明らかにされていません。以降のカード設計や判断基準に関する内容は、この原則に基づく筆者側の提案であり、元のシステムをそのまま紹介するものではありません。
Agent がいつ作業を止めて人に確認すべきか：3つの判断軸
「データを削除する、お金を使う、方向性を変える」は、判断の出発点として有効です。ただし、実際のシステムで行われる操作は、この3つに限りません。これらを再利用可能な3つの軸、可逆性、コストへの影響、方向性に抽象化すれば、新しい操作もすばやく分類できます。
判断軸1：可逆性で結果を取り消せるか判断する
可逆性とは、「間違えたときに取り消せるか」ということです。ドラフトの作成、ブランチの作成、テスト環境でのスクリプト実行は、いずれも可逆的な操作です。間違えても破棄してやり直せます。一方、本番データの削除、社外へのメール送信、コンテンツの正式公開は、取り消せない、または取り消しが難しい操作です。元に戻すためのコストは、実行時のコストを大きく上回ります。
判断に迷ったら、具体的にこう問いかけてみましょう。「Agent が実行直後に間違いに気づいた場合、復旧にはどれくらいの時間と人手が必要か」。その答えが許容範囲を超えるなら、その操作には承認を必要とすべきです。
次元2：コストへの影響で予算の承認ラインを決める
コストへの影響とは、単に「今回いくらかかるか」だけでなく、「コストが膨らむ可能性があるか」も含みます。Agent にとって最大の金銭的リスクは、多くの場合ループから生じます。リトライ処理のミスや広すぎるトリガー条件によって、モデル呼び出しが何時間も繰り返されることがあります。1回あたりのコストが低くても、制御不能な回数に達すれば許容できない金額になりかねません。
そこで、予算のしきい値を設定するのが実用的です。1回あたりと累計の費用がしきい値内なら自律的に実行し、超える場合は停止して人に確認します。Agent が複数の大規模言語モデルを呼び出す必要がある場合は、APIYI apiyi.com のような統一インターフェースプラットフォームを使って呼び出しを一元化できます。使用量が同じ窓口に集約されるため、複数のベンダーの管理画面を行き来せずに、累計消費量をしきい値と照らし合わせられます。
次元3：方向性によって、誰が目標に責任を持つかを決める
方向性は、3つの次元の中で最も曖昧です。その操作が「どこを目指すか」を変えるかどうかを指します。例えば、記事のテーマ選定方針の変更、ルール設定の調整、製品の優先順位の変更などです。Agent は与えられた目標のもとで最適な道筋を見つけるのは得意ですが、目標そのものを変えるべきかどうかの判断は得意ではありません。そこにはビジネスの背景やブランドに関する判断、そして責任を負うことが必要だからです。
実務上の判断基準としては、Agent 自身のルールや目標を変更する操作（例えば rules.json のトリガー条件を書き換える）や、その結果が後続の多数のタスクの前提となる操作を「方向を変える」と見なします。
| 次元 | 低リスクの特徴 | 高リスクの特徴 | 推奨される対応 |
|---|---|---|---|
| 可逆性 | 下書き、ブランチ、テスト環境、ワンクリックでロールバック可能 | 削除、上書き、外部公開、メッセージの送信 | 高リスクの場合は必ず承認を得る |
| コストへの影響 | 1回あたりのコストが低く、累計も予算内 | しきい値超過、ループによってコストが膨らむ可能性がある | しきい値内は自律実行、超過時は承認を得る |
| 方向性 | 既定の目標のもとで実行 | ルール、目標、長期戦略の変更 | 必ず人が判断する |
| 組み合わせによる判断 | 3項目すべてが低リスク | いずれか1項目が高リスク | いずれかの次元が高リスクなら停止して人に確認する |
承認が多すぎる場合と少なすぎる場合の代償
境界線を引くとは、2つの失敗の間でバランスを取ることです。承認が多すぎても少なすぎても、Agentの自動化プロジェクトは失敗します。ただし、その失敗の仕方は異なります。
| 状況 | 典型的な状態 | 直接的な結果 | 長期的な影響 |
|---|---|---|---|
| 承認が多すぎる | 各ステップで確認が表示され、カードがたまる | 自動化が「人によるボタン押し」になる | 承認疲れが起き、内容を見ずに同意するようになる |
| 承認が少なすぎる | 重要な操作も自律的に実行される | 誤削除、予算超過、目的からの逸脱 | 一度の事故でシステムへの信頼が失われる |
| 境界が適切 | 3種類の高リスクな場面でのみ停止する | 人は本当に判断が必要なことだけを処理する | 信頼が徐々に蓄積され、少しずつ権限を委ねられる |
承認が多すぎることの最も気づきにくい弊害は、「承認疲れ」です。毎日何十枚もの確認カードを受け取ると、内容を見ずに同意する習慣がすぐに身についてしまいます。承認は形だけのものとなり、むしろ承認がない場合よりも危険です。誰かがチェックしていると、皆が思い込んでしまうからです。カズクシステムが「3種類の場面でのみ人に判断を求める」と抑えているのは、確認を求める一つひとつの場面で、きちんと判断してもらうためです。
Agentの人間による意思決定の境界を学ぶ：5ステップで承認フローを構築
ここでは、承認フローをゼロから設計する手順を紹介します。特定のフレームワークには依存しないため、任意のイベントスケジューリングツールとチャットプラットフォームを使って実装できます。
ステップ1：Agentのすべてのアクションを洗い出す
ファイルの読み取り・書き込み、レコードの削除、外部APIの呼び出し、メッセージの送信、設定の変更など、Agentが使用できるすべてのツールと実行できるアクションを列挙します。それぞれに3つの観点からタグを付け、「アクションリスク一覧」を作成しましょう。この一覧は、以降のすべてのルールの土台となり、チームで境界を話し合う際の共通認識にもなります。
ステップ2：ルールを一元管理する
卡兹克が rules.json でトリガーとスケジューリングを一元管理している方法を参考に、「どのアクションに承認が必要か」も各 Agent のプロンプトに分散させず、設定ファイルにまとめます。一元管理には、次の2つのメリットがあります。
- 監査しやすい：現在どの操作に人間の確認が必要か、誰でも把握できる
- 調整しやすい：承認が必要な範囲を広げたり狭めたりするときも、1か所を変更するだけで済む
なお、この設定自体の変更は「方向性の変更」にあたるため、人間だけが行うようにしましょう。
ステップ3：CI で先に自動検証する
人間に確認を求める前に、自動チェックで確認できることはすべて済ませておきます。卡兹克の CI 基盤には、レビュー、チェック、マージ、リリース、検証の5つのステップがあります。つまり、人間に判断が委ねられる時点では、フォーマットエラーやテストの失敗といった基本的な問題はすでに取り除かれています。人間が機械の代わりにチェックを行うべきではありませんし、機械が人間の代わりに判断を下すべきでもありません。
ステップ4：判断カードを設計する
以下は、判断カードの設計に関する提案です（元のシステムの詳細ではありません）。人が数十秒で判断できるようにすることを基本原則とします。
- 何をするかを一文で説明：例えば「3月より前の下書きレコードを削除します」；
- 該当するリスクの種類：取り消せない操作なのか、予算超過なのか、方針変更なのかを明示する；
- 影響範囲と金額：対象となるデータの件数や予想費用を示す；
- Agent の理由と根拠：なぜ実行するのか、CI による検証結果はどうだったかを示す；
- わかりやすい操作ボタン：「承認」「拒否」を用意し、必要に応じて「修正して実行」も提供する。
ステップ5：タイムアウトとデフォルト動作を定義する
人が常にオンラインとは限りません。カードが処理されないままどれくらい経過したらタイムアウトとするか、タイムアウト後はデフォルトで「実行しない」のか「機能を制限して実行する」のかを、あらかじめ決めておく必要があります。データの削除や費用が発生する操作では、デフォルトを「実行しない」にしましょう。タスクを待機させてでも、無応答を承認とみなさないことが大切です。
🚀 クイックスタート：プロトタイプの段階では、まず統一されたモデルの窓口を使い、「Agent の実行 → CI による検証 → カードでの承認」という一連の流れを動かしてみるのがおすすめです。APIYI apiyi.com を通じて複数の主要なモデルを呼び出せば、承認ロジックを変更せずにモデルを切り替え、承認が必要になる頻度や理由の質を比較できます。
CIによる検証と人間の意思決定の役割分担
「CIでチェックできるのに、なぜ人間が必要なのか」と疑問に思うチームは少なくありません。答えは、両者が判断する対象が異なるからです。役割分担の境界を以下の表にまとめました。
| 工程 | 判断すること | 判断基準 | 担当 |
|---|---|---|---|
| レビュー / チェック | 成果物が規範に沿っているか | ルール、テスト、形式 | CI基盤 |
| マージ / リリース | 次の段階に進めるか | すべてのチェックに合格したか | CI基盤 |
| 検証 | 結果が実際に反映されたか | 事後検証 | CI基盤 |
| データの削除 / 支出 / 方向転換 | そうすべきか | ビジネス上の判断と責任 | 人間による意思決定 |
| モデル呼び出し先 | どのモデルを使い、いくら費やすか | 予算の閾値 | 設定ルール＋人間による最終対応。APIYI apiyi.com で利用量を集計することも可能 |
よくある質問 FAQ
Q1：Agent の人間による判断の境界とは何ですか？
Agent が自律的に実行できる操作と、人間の確認が必要な操作を分けるルールです。境界の内側では Agent が全速力で動き、境界に達すると処理を一時停止して判断を人間に委ねます。通常は、可逆性、コストへの影響、方向性の3つの観点から境界を定めます。
Q2：人間による承認と CI の自動チェックはどう違いますか？
CI はルールやテストに基づいて「正しいか」を判断するもので、機械による処理に適しています。一方、人間による承認は、ビジネス上の判断と責任に基づいて「実行すべきか」を判断します。前者はできる限り自動化し、後者は件数を絞って重要な判断に集中することで、速さと安定性を両立できます。
Q3：「方向を変える」という曖昧な分類はどう定義すればよいですか？
原資料では、著者が具体的にどう定義しているかは明かされていません。私たちの提案は、Agent 自身のルールや目標を変更する操作と、その結果が後続の大量のタスクの前提となる操作を、いずれも「方向を変える」操作として扱うことです。判断に迷う場合は、まず承認対象に含め、実情に合わせて徐々に権限を広げるとよいでしょう。
Q4：人間による判断が特に必要な場面はどこですか？
主に次のような場面です。
– **データクリーンアップ**：期限切れのレコードやファイルを定期的に削除する場合；
– **コンテンツの自動公開**：外部に公開する前の最終確認；
– **モデルの一括呼び出し**：ループによって課金額が膨らむ可能性のある呼び出し；
– **方針に関わる調整**：企画テーマの方向性やスケジューリングルールなどの変更。
Q5：Agent による大規模言語モデルの呼び出し費用をどう管理すればよいですか？
1回あたりと累計の2段階で予算のしきい値を設定し、しきい値内は自律的に実行、超える場合は承認を求める方法がおすすめです。モデル呼び出しを APIYI apiyi.com のような統合インターフェースプラットフォームに集約すると、利用量を一元的に把握でき、しきい値と照らし合わせた監視や振り返りがしやすくなります。
Q6：承認の境界が妥当かどうかを素早く検証するには？
まずは小規模な実際のタスクで試運用し、毎日の承認件数、却下率、平均応答時間を記録します。承認件数が多いのに却下率が極端に低ければ、境界が厳しすぎる可能性があります。問題が事後に発覚する場合は、境界が緩すぎる可能性があります。初期段階では、APIYI apiyi.com を使って同じタスク群を複数のモデルで実行し、モデルごとに承認が発生する頻度の違いを観察することもできます。
Q7：この方法にはどのような限界がありますか？
人間による承認は担当者が対応可能であることに依存するため、深夜や休日にはタスクが滞る可能性があります。また、カードの情報が不十分な場合、人間も判断を誤ることがあります。さらに、本記事の根拠となる原資料は要約であり、承認を経ずに誤実行された事例や具体的な防御メカニズムの詳細は公開されていません。導入時には、自社のシステムに合わせてタイムアウト、ログ、ロールバックの仕組みを補う必要があります。
Agentはいつ立ち止まって人に確認すべきか：要点 Key Takeaways
- 基本原則：人に確認するのは、データ削除、費用の発生、方針転換の3つの場面に絞り、一つひとつの承認の重要性を保ちます。
- 3つの判断軸：可逆性、コストへの影響、方向性を使って、新しい操作をすばやく分類します。
- 明確な役割分担：CIは「正しいか」を、人は「実行すべきか」を判断し、互いの役割を代替しません。
- 承認疲れに注意：承認が多すぎると、人は習慣的に同意を押すようになり、承認がない場合よりも危険です。
- 保守的なデフォルト：タイムアウトまでに対応されなかった場合、リスクの高い操作は実行しません。
- 窓口の一元化：APIYI apiyi.comを通じて複数のモデルをまとめて呼び出すことで、コストのしきい値管理やモデルの比較がしやすくなります。
まとめ
Agentがいつ立ち止まって人に確認すべきかは、突き詰めると、効率とリスクの間に明確な線を引くことです。
- 3種類の判断ポイントから始める：データ削除、費用の発生、方針転換で、リスクの高い場面の大半をカバーできます。
- 3つの判断軸で対象を広げる：可逆性、コストへの影響、方向性を使えば、どんな新しい操作にも判断の境界を適用できます。
- 機械による検証で負担を減らす：CIに初歩的な問題を除外してもらい、人は本当に判断が必要なことだけを扱います。
境界は一度決めたら終わりではなく、信頼を積み重ねながら徐々に緩めていくものです。まずは厳しめの境界で試験運用を始め、どこまで権限を委ねられるかをデータに基づいて決めることをおすすめします。構築・調整の段階では、APIYI apiyi.comを通じて複数のモデルに一元的にアクセスし、承認フローにおける各モデルの性能をすばやく検証できます。
📚 参考資料
- 数字生命卡兹克による、1年かけて試行錯誤した Agent 自動化システムのアーキテクチャ紹介：本記事の原則とアーキテクチャに関する情報源
- リンク：
aihot.news/items/dzwfvd9xp6v4qaj6olxezpier - 説明：自動化基盤、Agent 実行、CI 基盤、飞书での意思決定からなる4層アーキテクチャと、「データの削除、費用の発生、方針の変更が必要なときだけ人に確認する」という原則を紹介しています（資料は要約のため、詳細は原文でご確認ください）
著者: APIYI 技術チーム
技術交流: Agent 自動化や人間と AI の協働に関する実践経験を共有したい方は、APIYI の apiyi.com トップページからお気軽にお問い合わせください。詳しい資料は docs.apiyi.com のドキュメントセンターでもご覧いただけます。
