高性能なAIで、ようやく満足できる業務手順ができた。次回からは低コストのモデルに任せたい。そこで作業履歴を長い指示書にして渡したのに、別の入力では失敗する。
本稿の業務例は説明用の架空例で、特定モデルの実測結果ではありません。
原因は、手順の長さではなく「前回たまたま通った条件」が残っていることかもしれません。元の資料、会話履歴、ツールの権限、担当者の補助が変われば、同じ説明でも結果は変わります。
引き継ぐ対象は成功した会話ではなく、入力条件・実行手順・検査・停止条件のセットです。 高性能AIを設計に使う価値はありますが、軽量モデルへ移せるかは、別途試験して決めます。
本稿でいう「スキル」は、AIに渡す業務手順と資料のまとまりです。読むときは、自社の一業務について「何ができれば完了か」「何が欠けたら止めるか」「問題が出たら誰が戻すか」の三点を当てはめてください。
スキルは、会話の保存ではない
Agent Skillsの公開仕様では、スキルはSKILL.mdを中心とするディレクトリで、必要に応じてスクリプトや資料、テンプレートを含められます。名前と説明だけでなく、どの条件で使うかを整理する形式です。Agent Skills仕様
ただし、共通の形式で配布できることと、どのモデルでも同じ仕事をこなせることは別です。実行環境、利用できるツール、入力の性質までそろえて確認する必要があります。
本稿が扱うのは、Agent Skills形式に限らない業務手順の受入試験です。形式をそろえる作業と、結果を確かめる作業を分けて考えます。
保存するなら、「この画面のこの位置を押した」という履歴だけでなく、何を確認してその操作を選んだのか、同じ状態でなければどうするのかを残します。認証情報や実際の顧客データは、汎用手順へ埋め込みません。
固定できる処理から、AIの判断を外す
例えば、社内の作業報告を集約する仕事を考えます。件数を足す、必須項目を検査する、同じIDの重複を見つける。これらは、ルールが決まればプログラムで処理できます。
一方、「今週の変化を短く説明する」「未完了の理由を資料に基づいてまとめる」部分には、言語モデルを使う余地があります。
Anthropicのエージェント設計解説も、あらかじめ決めた経路で動くワークフローと、モデルが動的に進め方を決めるエージェントを区別しています。本稿ではこの区別を、毎回同じ判断をさせないための設計に使います。Building effective agents
入力の形式・重複確認 → プログラム
件数・並び順の確定 → プログラム
資料の範囲内での要約 → 言語モデル
数字・保存先の検査 → プログラム
根拠不足・範囲外 → 停止して担当者へAIを使う場所を減らすことも、AI活用の改善です。ただし、プログラムに移した後も、実行環境、保守、障害対応の費用は残ります。
件数の検査が通っても、要約の意味まで正しいとは限りません。試験では作業責任者が全出力を原文と照合し、資料にない原因や納期を足していないかを確認します。
作ったときとは別の入力で試す
手順を作るために何度も見た資料だけで合格を出すと、その例に合わせて調整した結果を評価することになります。
試験用に、まだ手順の調整へ使っていない入力を残します。通常の入力だけでなく、欠けた項目、未知の分類、重複、長い文章、指示のような文を含むデータも用意します。
選び方は「普段よく来る入力」「たまに来る形式の違い」「停止が必要な入力」の三群から始められます。実データを使う場合は利用権限を確認し、機密情報を汎用スキルへ残さないようにします。
ここで、すべての入力から成果物を作ることを合格にしません。必須情報が欠けている場合に、推測で埋めず停止することも合格です。「正常な成果物を返す条件」と「止まるべき条件」を別々に決めます。
試験結果を見て手順を修正したら、その入力は調整用へ移します。新たな未使用入力で再評価し、正常な入力を不必要に止めていないかも確認します。
小さな試験で問題が出なかったことは、長期の安全性の証明ではありません。対象業務を限定した試行へ進める材料として扱います。
上位モデルへ戻す前に、失敗の種類を分ける
軽量モデルで失敗したとき、毎回上位モデルに投げ直すだけでは、手順の欠陥が隠れます。
- 入力が足りない：追加情報を待つ。モデルを変えても根拠は増えない。
- 計算や形式が違う：固定処理や検査を直す。
- ツールや画面が変わった：旧手順を停止し、環境差を調べる。
- 入力・権限・固定処理が正常でも要約の品質が足りない：対象や資料を見直したうえで、権限と予算の範囲で上位モデルを検討する。
外部送信・公開などの結果が不明な場合は、再実行の前に送信先の状態を確認します。タイムアウトは失敗の証拠ではなく、成功したのに応答だけ届かなかった可能性もあるからです。
上位モデルに戻しても解決しない場合の担当者と、再試行回数の上限も決めておきます。
原因が重なって見える場合は、まず入力欠落・権限・保存成否などの停止条件を確認します。その問題を残したまま、モデルの能力比較へ進めません。
単価差ではなく、引き継いだ後の総費用を見る
費用比較には、最初の手順作成、軽量モデルの実行、検査、上位モデルへの戻し、人の追加確認、手順更新を含めます。
比較期間の費用は「初期費＋通常実行費＋再実行費＋検査費＋保守費」で整理できます。各費目は同じ比較期間全体の額にそろえます。同じ費目を二重に足さず、人の時間を金額換算した部分は実際の支払額と別表示にします。
比較する仕事の集合、品質条件、期限を同じにします。未完了を除いて単価だけを下げないよう、投入件数と期限内完了率も併記します。必要な完了率に届かない方式は、安さだけで採用しません。
モデルのAPI単価が数分の一でも、何度も再実行すれば、その比率で安くなるとは限りません。サブスクリプション内の利用枠と、APIの従量料金も同じ金額として混ぜず、実際に増減する支出と人の時間を分けます。
別入力で再現でき、元の運用へ戻せてから引き継ぐ
移行時は、手順の版、モデル、設定、実行ツール、評価入力、検査結果をセットで保存します。どれかを変更したときに、何を再試験するかが分かる状態にします。
まずは社内保存までの一業務に限定し、問題が出たら以前の版や手作業へ戻せるか確認します。高性能AIで作れたことと、日々の運用を任せられることを分ける。この一段が、試作を再利用可能な業務へ変えます。
例えば社内報告なら、正常入力が期限内に正しい下書きになり、欠落入力では保存せず停止することを確認します。誤った出力が出たら利用対象から隔離し、作業責任者が旧手順へ戻す。未確認や重大な誤りが残る場合は移行せず、修正して再試験します。
予算から担当モデルを決める段階なら、モデル使い分けの記事も参考になります。
業務・システムの構築や改善を検討する場合は、案件相談フォームへ対象業務と現在の流れをお知らせください。成果物、含む・含まない範囲、利用アカウント、責任分界、検収方法を確認してから個別にお見積もりします。