業務フロー Skill ─ 複数の API を束ねて「業務の手順」を実行可能にする話
はじめに
第1回・第2回の記事で、既存の .NET 資産から Skill を生成しました。
この段階でできあがるのは、1 つの関数 = 1 つの Skill という粒度のものです。
select_order_list ← 発注一覧を取得する
get_inventory ← 在庫を取得する
update_order_status ← 発注ステータスを更新する
send_notification ← 通知を送る
これらを AI が組み合わせて動かすことはできます。しかし実際の業務を処理させると、こんな問題が起きます。
「この処理、毎回 AI に手順を説明しないといけない」
「発注残があったら担当者に通知して」という依頼に対して、AI は毎回「まず一覧を取得して、次に…」と考え直します。手順が決まっているにもかかわらず、依頼のたびに推論が走ります。
その「決まった手順」を Skill として固めたものが、業務フロー Skill です。
API レベル Skill と業務フロー Skill の違い
2 種類の Skill を対比すると次のようになります。
| API レベル Skill | 業務フロー Skill | |
|---|---|---|
| 粒度 | 1 関数 = 1 Skill | 1 業務プロセス = 1 Skill |
| 生成元 | ソースコード / DLL | 業務マニュアル |
| 内部構造 | 関数呼び出し 1 つ | 複数の API Skill を順に呼ぶ |
| 判断ロジック | なし | 業務ルール（閾値・分岐・必須チェック）を含む |
| 呼び出し方 | AI が組み合わせて使う | 1 つの依頼で完結する |
API レベル Skill は「部品」、業務フロー Skill は「手順書が実行可能になったもの」というイメージです。
業務マニュアルが仕様書になる
第1回では「既存ソースコードが AI の仕様書になる」と書きました。業務フロー Skill では、業務マニュアルが仕様書になります。
業務マニュアル（手引き・規程・手順書）
↓ 読み取る
処理の順序・判断条件・必須チェック・例外処理
↓ 実装する
業務フロー Skill（run.py）
たとえば「発注残の点検と通知」という業務マニュアルに次のような記載があるとします。
1. 当月の発注残一覧を取得する
2. 納期超過（14日以上）のものを抽出する
3. 担当者別に集計する
4. 担当者ごとにメールで通知する
※ 金額が 50 万円以上の場合は上長も CC に入れる
この手順と判断条件をそのまま Skill として実装します。
# 業務フロー Skill の内部（概略）
def run(target_month):
# ① 一覧取得
orders = select_order_list(month=target_month)
# ② 納期超過を抽出
overdue = [o for o in orders if o.days_overdue >= 14]
# ③ 担当者別に集計
by_staff = group_by_staff(overdue)
# ④ 担当者ごとに通知（金額で CC 分岐）
for staff, items in by_staff.items():
cc = [manager] if total_amount(items) >= 500_000 else []
send_notification(to=staff, cc=cc, items=items)
AI が毎回手順を推論するのではなく、マニュアルに基づく判断ロジックが Skill の中に固まっています。
業務フロー Skill の構造
業務フロー Skill は、複数の API Skill を束ねたラッパーです。
業務フロー Skill
├── SKILL.md ← 業務の目的・トリガー・準拠マニュアルを記載
└── run.py ← 複数の API Skill を呼び出す処理フロー
内部で呼ぶ API Skill（第1回・第2回で生成したもの）
├── select_order_list
├── get_staff_info
└── send_notification
SKILL.md には、どの業務マニュアルに基づいているかを明記します。
## 準拠マニュアル
- 発注管理規程 第3章（納期超過対応）
## トリガー
「発注残を確認して」「納期超過の担当者に通知して」と依頼されたとき
これにより、なぜこの判断ロジックになっているかの根拠が Skill に残ります。マニュアルが改訂された場合に、どの Skill を更新すべきかも明確になります。
よくある構造パターン
業務フロー Skill を作っていると、処理の構造が数パターンに収束することが分かりました。
パターン 1：点検フロー（READ のみ）
データ取得 → 条件でフィルタ → 集計・一覧化 → 報告
最も安全なパターン。DB を書き換えないため、どの環境でも安心して実行できます。
「〜の状況を確認して」「〜に問題がないか点検して」という依頼に対応します。
パターン 2：処理フロー（READ → WRITE）
現状確認 → 処理実行 → 結果確認 → 通知
更新系を含むパターン。実行前に現状を確認し、実行後に結果を再取得して整合性を確かめます。
パターン 3：照会 → 人ゲート → 確定
データ取得 → 提示（ここで止まる）→ 人が確認 → 確定実行
不可逆な処理や金額が大きい処理は、途中で人の確認を挟みます。
エージェントが「ここまで準備しました、内容を確認して承認してください」と止まり、人が承認してから次のステップへ進む設計です。
人ゲートの設計
自律的に動くエージェントでも、すべてを自動化しないという設計判断が重要です。
特に次のようなケースは、人の確認を必須にしています。
| ケース | 理由 |
|---|---|
| 本番 DB への更新 | 取り消しが困難 |
| 金額が一定以上の処理 | ビジネスインパクトが大きい |
| 外部への送信（請求書・契約書など） | 誤送信のリスク |
| 例外的な状況の判断 | マニュアルが想定していないケース |
人ゲートのある Skill は、「準備まで」と「確定実行」を明確に分けて実装します。
準備フェーズ
─ データ取得・検証・下書き生成
─ 担当者に「内容を確認してください」と通知
確定フェーズ（担当者の承認後）
─ 実際の更新・送信を実行
─ 完了を記録
エージェントが「準備して待つ」、人が「確認して承認する」という分業が自然に成立します。
API Skill と業務フロー Skill の分担
2種類の Skill は、発見・呼び出しの経路も分けて管理しています。
業務フロー Skill（少数・業務担当者が使う）
─ AI が「発注残の確認」と聞いて直接マッチ
─ SKILL.md にトリガーフレーズを明記
API レベル Skill（大量・AI が内部で組み合わせる）
─ 業務フロー Skill の内部から呼ばれる
─ 直接マッチさせない（業務担当者は意識しない）
業務担当者が「〜して」と頼んだとき、AI は業務フロー Skill を選びます。その内部で API レベル Skill が動く、という2層構造です。
メリット
- ✅ 手順が固まる ─ 毎回 AI が推論しなくてよい、結果が安定する
- ✅ マニュアルとの対応が明確 ─ どの規程・手順書に基づくかが Skill に残る
- ✅ 人ゲートを設計に組み込める ─ 自動化と人の判断の境界を明示できる
- ✅ 第1回・第2回の Skill 資産をそのまま活用できる ─ 既存の API Skill を束ねるだけ
まとめ
- API レベル Skill（第1回・第2回）：関数単位の部品
- 業務フロー Skill（今回）：マニュアルに基づく手順の実装
この2層を組み合わせることで、「自然言語で依頼する → 業務マニュアル通りに処理される」という流れが完成します。
業務フロー Skill が増えるほど、エージェントが対応できる業務の幅が広がります。そして Skill の数が増えたときに新たな課題が生まれます ─ 次回はその話（Skill が増えすぎたときのコンテキスト管理）を書きます。