最初の業務Agentを同僚へ渡す前に、三種類の成果物を検収する

デモではきれいな会議資料ができた。同僚が資料を一つ添付し忘れると、Agentは根拠のない「決定事項」で穴を埋めた。見栄えと、実務で受け入れられる成果物は違う。

複雑な採点システムより先に、一つの低リスク業務を固定する。完全な入力、欠損、矛盾の三種類を使い、実物を確認する。三例は出発点であって、全体の信頼性を証明する統計ではない。

一つの成果物と条件を固定する

承認された過去資料から社内会議の準備資料を作る仕事を選ぶ。匿名化コピーと受け入れ済みの参考資料を使い、CRM更新や顧客対応を同時に試さない。送信や本番データ更新も許可しない。

以下は架空の会議とファイルによる準備例であり、実行結果や効果測定ではない。実際の試行では利用権限のある過去資料に置き換える。

タスクカードv1：社内会議の準備資料
入力：指定資料、会議日、参加者の役割、テンプレート
出力：実行別フォルダーのbrief.mdと要確認事項
必須：日付、事実の出典、決定済みと未決の区別、議題
禁止：決定の捏造、外部への期日約束、送信、本番更新
重大な失敗：根拠なし、矛盾の隠蔽、禁止行為

主管が出力を見る前に基準を決める。参考答案と同じ文章である必要はないが、事実と出典、未決事項の扱いは同じ条件を満たす必要がある。

三つの入力に、三つの合格条件を用意する

各ケースを別ディレクトリへ置き、別ケースの答えが混じらないようにする。「必ず完成資料を出す」を共通の成功条件にしない。

矛盾があっても、根拠から承認済み判断が分からないならAgentに推測で決めさせない。欠損ケースでは、理由を示して止まることが合格になり得る。

チャットの完了宣言ではなく、実ファイルを見る

BudaのAgent tabでケースごとに新Sessionを作り、同じ版のタスクカードと指定入力を渡す。ワークスペースではツール呼び出しや成果物を確認できるが、「完了」の一言は成果物ではない。

Driveで実ファイルを開き、日付、決定事項、引用、未決事項、禁止行為を照合する。欠損で止まるべきケースは、不足記録を検収する。もっともらしい完成稿を無理に要求しない。

pilot/
  task-card-v1.md
  cases/complete/   # 入力と期待挙動
  cases/missing/    # 不足と停止点
  cases/conflict/   # 両資料と確認事項
  results/v1/       # Session、成果物、項目別判定
  results/v2/       # 再試行。v1を上書きしない
  decision.md       # 人の判断と利用範囲

ケースID、タスクカード/Skill版、Session、入力一覧、実ファイルのパス、誤りの種類、人の修正、検収者を残す。実行前の結果欄は「未実行」とする。時間は測定した値だけを記録し、未測定の削減時間を作らない。

一人が三例を実行したら三試行であって三人ではない。同じ例を複数人が実行しても、全業務条件を確認したことにはならない。入力範囲、人数、試行数を分けて残す。

重大な失敗は平均点で消さない

• 事実・境界の失敗： 根拠のない確定、矛盾の消去、禁止行為。利用拡大を止め、方法と権限を見直す。
• 不完全な納品： 入力はあるのに議題や成果物の場所がない。修正して再試行する。会話の補足だけでファイル修正済みとしない。
• 形式の問題： 事実と境界は合格だが見出しが違う。形式だけを直し、内容が崩れていないか再確認する。

完全ケースが成功しても、欠損ケースで会議日を作ったら合格とはしない。見栄えのよい二つの出力で重要な失敗を相殺しない。

一つ直し、元の結果を残して再試行する

欠損日付を補ってしまったと仮定する。v2で停止条件を具体化し、変更行を記録する。欠損ケースに加えて正常ケースも再実行し、正しい入力まで止まらないかを見る。出典の選択を変えたなら矛盾ケースも確認する。

これは推奨手順であり、失敗や修復の実績を意味しない。最良の出力だけを選ばず、すべての試行を残す。失敗が続くなら、指示を足すだけでなく仕事の範囲を小さくする。

責任者は、対象者・入力・出力を限定して試行を継続するか、承認済み議事録の整理だけに範囲を縮小するか、根拠と責任を含めて再設計する。重大な失敗が残れば拡大しない。

同僚へ渡す前の疑問

唯一の正解がない資料はどう評価する？

必須の日付、出典、未決事項、追加してはいけない約束をチェックリストにする。その範囲で主管が用途に合うか判断する。参考資料は基準合わせに使い、逐語一致を求めない。

三例が合格なら誤り率ゼロと言える？

言えない。記録した試行が条件を満たしただけである。別の入力や高リスク業務には追加ケースと別の判断が必要だ。

Skillの起動テストとは何が違う？

起動テストは開始と停止を確認する。成果物検収では根拠、手直し、試行可能な入力範囲まで見る。正しく起動しても納品が正しいとは限らない。

定期実行の前に、一つの過去業務を検収する

Budaで匿名化済み入力、タスクカード、三種類のケース、結果と判断を整理する。方法が必要ならBuda AIのMarketplaceでSkillを検索してインストールし、手順と停止条件を確認してから試す。インストールは合格証明ではない。

Skillは方法、Automationは実行時点を決める。先に受け入れられる成果物を定め、その後に日程や実業務の送信権限を別途判断する。