A14. 運用の Agent 化 | Agentifying Operations

トラック: Path A: 運用担当 · モジュール: A14 最終更新: 2026-07-31 難易度: 中級 所要時間: 1 日 1 時間、1〜2 週間 前提モジュール: F2 プロンプトエンジニアリング(特に §5 Prompt から Skill へ)

章ナビゲーション

Agent 化が実際に何を削るのか · 2. データソースの棚卸し · 3. タスクの仕分け · 4. 既存プロンプトをスキルに変える · 5. そのまま使える運用 Agent 3 つ · 6. よくある罠 · 7. 完了チェック

このモジュールで学べること

Path A のこれまでの 13 章は「AI に仕事をさせるプロンプトの書き方」だった。この章はその次だ。その仕事を、毎回自分で起動しなくて済むようにする。

このモジュールを終えると、次ができるようになる:

自分の運用工程のうち、どれを Agent 化する価値があり、どれは今やっても無駄かを判断する
各工程のデータがどこから来るかを棚卸しする — Agent 化が成立するかどうかの前提条件
人的確認の境界を引き、Agent に単独でやらせてはいけない動作を把握する
Path A の既存プロンプトを再利用可能なスキルファイルに作り変える
具体的な運用 Agent を 3 つ立ち上げる: 日報、在庫警告、低評価レビュー対応

一言で: Agent 化とは「プロンプトの置き場所を変えること」ではなく、間に挟まっているデータ運搬の工程をなくすことだ。データが動かせないなら、Agent 化は偽の前提になる。

1. Agent 化が実際に何を削るのか

本書で最も典型的なワークフローを例に取る。「週次の広告最適化」に今かかっているのはこれだ:

1. Seller Central にログイン                  ← 人、2 分
2. 検索語レポートをダウンロード                 ← 人、3 分
3. ChatGPT を開き、データとプロンプトを貼る      ← 人、2 分
4. 分析を待つ                                 ← AI、1 分
5. 結果を読み、どの提案を採用するか判断           ← 人、10 分
6. 管理画面に戻り、1 件ずつ適用                 ← 人、15 分

AI がやったのはステップ 4 だけ。 残り 32 分は人の作業で、しかも 1・2・3・6 は純粋な運搬だ。判断は一切なく、データをある場所から別の場所へ移しているだけ。

Agent 化の価値はここにある。ステップ 5(何を採用するか)は自動化すべきではない。それがあなたの仕事だ。

ステップ	性質	Agent 化後
1-2 取得	純粋な運搬	Agent が API/MCP で直接読む
3 プロンプト組立	純粋な運搬	スキルファイルに書いてある
4 分析	AI の判断	変わらず
5 採用可否の判断	あなたの判断	人のまま — ここがゲート
6 変更の適用	純粋な運搬	あなたの確認後に Agent が実行

したがって正しい目標は「Agent に広告を全自動で回させる」ではなく、「32 分の運搬を 10 分の判断に圧縮する」だ。 ステップ 5 まで自動化した人は、たいてい最初の 1 か月で人手の後始末が要る事故に当たる。

2. データソースの棚卸し: Agent 化の前提条件

前節のステップ 1-2 を自動化できるかは、データに手が届くかどうかで決まる。この章で最も実務的な節だ。他より先にこの表を埋めること。

2.1 データソースを 3 種類に分ける

分類	特徴	Agent 化できるか	典型例
A 類: API あり	公式の安定したインタフェース	できる。最優先	Amazon SP-API、Amazon Ads API、Shopify Admin API
B 類: 書き出しはあるが API なし	ファイルは落とせるが手動クリックが要る	半自動: 人が書き出し、Agent が処理	一部プラットフォームの管理画面レポート
C 類: 画面のみ	API も書き出しもない	保留、または computer use(遅く高い)	地域プラットフォームの管理画面、一部のサプライヤーポータル

結論は率直だ。まず A 類の工程を Agent 化し、B 類は半自動で妥協し、C 類は現段階では触らない。 C 類のトレードオフは B6 §9 Computer Use を参照。

2.2 棚卸し表のテンプレート

運用工程ごとに 1 行埋める。埋め終われば、何をどの順でやるかは自ずと出る。

運用工程	必要なデータ	ソース分類	取得方法	週あたり運搬にかかる分
広告最適化	検索語レポート	A(Ads API)	API	20
在庫補充	在庫 + 販売数	A(SP-API)	API	15
レビュー対応	新着レビュー	A/B(プラットフォーム次第)	API か書き出し	30
競合モニタリング	競合の価格/BSR	C(多くは API なし)	保留	40

優先度は最後の列を取得難易度で割った値。 運搬時間が長く、かつ A 類のものから着手する。

2.3 正直な判断

棚卸しの結果、大半が C 類だったなら、現段階でやるべきは Agent 化ではなくデータ可用性の解決だ。書き出せるツールに替える、API 権限を申請する、あるいは一部の工程は手動のままだと受け入れる。

C 類に computer use を無理に当てるのは、多くの場合人手より遅く高くつき、プラットフォームが 1 度改修すれば全部壊れる。

3. タスクの仕分け: 何を渡し、何を手元に残すか

判断基準はただ 1 つ。間違えたときに取り返せるか。

3.1 3 つの区分

グリーン — Agent が自律的にやってよい

共通する性質: 読み取り専用、または成果物が社内で完結し、間違えても直せる。

データ取得、集計、日報の生成
レビューのラベリング、分類
Listing・コピーの下書き生成
異常検知とアラート(通知のみ、手は出さない)

イエロー — Agent がやるが、あなたが頷いて初めて有効になる

成果物が外に出る、またはプラットフォーム上の状態を変える。

広告の入札・予算の調整
Listing 内容の変更
顧客への返信
補充提案の提出

やり方は、Agent が用意はするが提出はしない。チェックリストとして出し、あなたが選んでから実行させる。

レッド — 絶対に Agent に渡さない

商品の出品取り下げ、Listing の削除
あらゆる返金・補償・資金の移動
プラットフォーム規約の承諾、アカウント設定の変更
高額の発注

この区分は「今はまだ、いずれは」ではなく、構造的に自動化すべきでない。得るものが数分で、失うものが 1 ロットやアカウント 1 つ、と非対称だからだ。

3.2 見落とされやすいイエロー項目

「顧客への返信」をグリーン扱いする人は多いが、これは誤りだ。 CS の返信は送ってしまえば取り消せず、しかもモデルは返金額・再送の期日・規約の例外をあなたの代わりに気前よく約束する。どれもあなたが授権していない。

本書の CS 系プロンプトはすべて <コピー規律> にこの条項を持っている。Agent 化する際はそのまま持ち込み、さらに人的ゲートを重ねること。

4. 既存プロンプトをスキルに変える

3 形態の違いと移行チェックリストは F2 §5 にある。この節は Path A の具体論だ。

4.1 1 つのプロンプトを移行する 5 ステップ

A3 の除外キーワードのプロンプトを例に:

ステップ 1: データソースを確認する。 必要なのは検索語レポート → Amazon Ads API で取得可 → A 類 → 進めてよい。

ステップ 2: 「データを貼る」を「どこから読むか」に置き換える。 元の [貼り付け: 検索語、マッチタイプ…] を、ソースとフィールドの宣言に変える。

ステップ 3: 出力を機械可読にする。 「除外リスト + 理由」の散文は人が読む前提だった。今は API 呼び出しに流れる。

ステップ 4: 事前チェックと失敗時の挙動を足す。 行数が少なすぎる、フィールドが欠けている場合に走らせない。

ステップ 5: イエローの動作に人的確認を紐づける。 除外語の追加は流入に影響するのでイエローだ。

4.2 移行後の姿

---
name: negative-keyword-harvester
description: Amazon の検索語レポートを週次で分析し、確認待ちの除外キーワード
  リストを産出する。過去 30 日の検索語レポート(費用・クリック・注文・売上の
  フィールドを含む)が必要。
---

<データソース>
Amazon Ads API: 検索語レポート、過去 30 日、必須フィールドは
searchTerm / matchType / impressions / clicks / cost / orders / sales
</データソース>

<事前チェック>
- レポートの行数が 200 未満なら停止し「サンプル不足のため今週はスキップ」と報告
- 必須フィールドが欠けていれば停止し、欠落フィールドを列挙
</事前チェック>

<役割>Amazon PPC 除外キーワードの専門家</役割>

<タスク>
四象限に分類し、完全一致除外 / フレーズ除外 / 監視 の 3 リストを産出する
</タスク>

<データ規律>
- レポートに存在する数値のみを使う。推定しない。記憶にある業界平均を引用しない
- 除外の提案はすべて、具体的な検索語の行まで追跡できること
</データ規律>

<失敗時の挙動>
データ不足または検証不通過のときは停止して報告する。推定値で続行しない
</失敗時の挙動>

<出力形式>
JSON: [{term, matchType, action: "negative_exact"|"negative_phrase"|"watch",
        reason, cost_30d, orders_30d}]
</出力形式>

<人的確認>
本スキルは確認待ちリストを産出するのみで、API を呼んで除外語を書き込まない。
ユーザーが選択した後、呼び出し側が書き込みを実行する。
</人的確認>

<セルフチェック>
① 依頼された成果物（四象限に分類し、完全一致除外 / フレーズ除外 / 監視 の 3 リスト…）が実際に出力されている。 <!-- ref: amazon.negative_keyword.exact.behavior --> <!-- ref: amazon.search_term.classification.observe_word -->
② 数値は貼り付けたデータのみを使用。無いものは「欠測」と書き、記憶からの推定なし。
③ 各結論にソースを明記：[入力データ] または [モデル推論]。
</セルフチェック>

比べてみてほしい。タスクの記述とデータ規律は一字も変わっていない。 増えたのはすべて「どこから読むか、いつ走らせないか、誰が出力を使うか、誰が頷くか」だ。

5. そのまま使える運用 Agent 3 つ

実装難易度順。3 つとも同じ型に従う。Agent がデータを取り、分析し、確認待ちリストを出す。あなたが頷いてから実行される。

5.1 日次運用レポート(グリーン、最も始めやすい)

なぜこれから始めるか: 全工程が読み取り専用で書き込みがなく、誤りのコストがほぼゼロ。Agent の判断の質を観察するのに向く。

トリガー: 毎朝 8:00
ソース: SP-API(販売数、在庫)+ Ads API(広告費)
動作:
  1. 前日データを取得
  2. 直近 7 日平均と比較し、閾値を超える乖離に印を付ける
  3. 日報を生成し、Slack/メールに送る
人的確認: 不要(読み取り専用)

設計上の要点: 日報の各数値には取得時刻とソースを付し、Agent には一切「推定」をさせない。仕事は提示と異常の明示であって、原因の説明ではない。原因は異常を見たあなたが判断する。

5.2 在庫補充の警告(イエロー)

トリガー: 毎週月曜
ソース: SP-API(在庫、販売履歴、輸送中)
動作:
  1. SKU ごとの在庫日数を計算
  2. 安全線を下回るものについて、リードタイムを加味した提案数量を算出
  3. 補充提案リストを産出
人的確認: 必須 — 補充は資金の約束だ

設計上の要点: 補充数量の計算はコード側に書き、モデルに任せない。モデルの担当は「どの SKU に注意が要るか」と「異常なパターンがないか」であって、具体的な数字は式で出す。補充数量をモデルに計算させるのは、この章で最も踏みやすい罠だ。もっともらしいが根拠のない数字が返ってくる。

5.3 低評価レビュー対応(イエロー、価値は最大だがゲートも最も厳格に)

トリガー: 新規の 1〜3 星レビューを検知
ソース: Review API またはプラットフォーム通知
動作:
  1. 分類: 物流 / 品質 / 期待とのずれ / 悪意
  2. 返信の下書きを生成
  3. 人へのエスカレーションが必要か判断
人的確認: 必須 — 送信した返信は取り消せない

設計上の要点: 下書きには具体的な返金額・補償の約束・期日の保証を絶対に含めない。それらはあなたが埋める。Agent の価値は 30 分の仕分けと起草を 3 分のレビューに圧縮することであって、あなたの代わりに約束することではない。

3 つの技術的な実装は B4 Agent ワークフロー、MCP の配線は B6 MCP 統合を参照。本章は運用側の境界の引き方のみを扱う。

データソースが C 類のとき。 本章冒頭のデータソース等級分けは形式ではない。API も安定した書き出しもないデータソースの上に Agent を載せれば、運用ではなくスクレイパーの保守に大半の時間を使うことになる。C 類での順序は、まずデータ取得を解決し、それから自動化を語ることである。
タスクが赤ゾーンのとき。 不可逆な動作 — 送金、価格変更、顧客への約束、データ削除 — は、Agent の精度がどれだけ高くても無人で走らせるべきではない。赤ゾーンの正しい形は、Agent が提案し人が確認することである。これは保守的なのではなく、誤りのコストが誤りの確率と無関係だからだ。
浮く時間が保守コストを下回るとき。 Agent にはデータ接続、ツール、例外処理、そしてプラットフォーム API の変更に追随する定期作業が要る。置き換える動作が週 20 分しか使っていないなら、この計算は合わない。本章のタスク分流表で各動作の実所要時間を測ってから、どれに手を付けるか決めること。
チームがまだ Agent の実行ログを読めないとき。 Agent の失敗は静かである — 誤ったデータを自信を持って最後まで運ぶ。軌跡を読む人がおらず異常検知もない状態では、Agent 化は人的ミスを見えない自動化ミスに置き換えるだけになる。稼働前に「どうすれば誤りに気づけるか」の仕組みを作ること。

7. 完了チェック

§2 のデータソース棚卸し表を完成させ、各工程を A/B/C に分類した
§3 に沿って運用動作をグリーン/イエロー/レッドに仕分け、リストとして書き出した
既存プロンプトを少なくとも 1 つ、§4 の 5 ステップでスキルファイルに移行した
日報 Agent(グリーン)を立ち上げ、1 週間安定稼働させた
すべてのイエロー動作に人的確認を設定した
すべての書き込み動作が監査ログを残している
説明できる: 自分の Agent 化がどの運搬工程を削ったか、そしてどの判断工程を意図的に残したか

越境EC AI 実践ナレッジベース