r/PPC のあるスレッドは、顧客アカウントに実際の書き込み権限を与えて AI を運用している人たちに四つを問いました。何を間違えたか、ガバナンスはどうしているか、本当に工数は減ったか、六十日後に何を止めたか。答えはツールの推薦より役に立つものに収束しました——管制のリストです。
以下がそのリストです。弊社を含むどのベンダーにも突きつけられる形で書いています。
七つの管制
1. 提案の前に読み直す
十分前に読んだデータで計画するエージェントは、もう存在しない状態に自信をもって手を下します。最も多く報告される失敗は判断ミスではなく、確信を伴った誤入力です。API 文書にあるフィールドがそのエンドポイントでは undefined を返し、黙ってゼロ扱いになる。変更を正当化する読取は、変更と同じターンで行わせること。
2. 書き込み前に差分を。説明ではなく
エージェントの語りは証拠ではありません。「成績の悪いものの入札額を下げます」は文章です。3 ターゲットの入札 1.40 → 0.95 は差分です。レビューできるのは後者だけです。
3. 影響範囲の上限
最も高くつく失敗は「一件の誤り」ではなく、「その誤りが四百件に適用されること」です。1 回の呼び出しに硬い上限を置き、実行前に検査させること——モデルに「注意して」と頼むのではなく。
4. 人の確認は重要な変更だけに
全部確認させると、全部押して通す習慣がつきます。二か月もすれば、何も承認していない承認ダイアログが残るだけです。ゲートは可逆な編集と金銭の移動を分けられなければなりません。
5. 分類はツールではなくホストが持つ
動作のリスク値がツール自身の説明由来なら、説明を書ける者は自分のリスクを下げられます。「ちょっとした設定変更」と名乗るツールが、言葉で承認を回避できてはいけません。未知・独自の動作は「安全」ではなく「要注意」に落とすべきです。
6. 顧客に渡せる監査記録
問題は「どこかにログがあるか」ではなく、「求められたときに、誰がいつ何を変えたかの不変の記録を出せるか」です。製品のテレメトリはそれにはなりません。
7. 必要になる前に作るロールバック経路
影響のある動作には、それが属する一括を見つけて戻せる鍵を持たせます。問題が起きてから取消し方を考えるのが、悪い一時間を悪い一週間に変える道です。
これらでは捕まえられない失敗
上記はすべて実行を統制するものです。差分は何が変わったか、ログは誰がいつ、ロールバックは元に戻す。しかしどれも「正しい提案」と「誤った提案」を分けません。入り口では同じ顔をしており、誤った方がしばしば論理的に見えます。
ROAS 3.5〜4x で健全に回していた出店者が、モデルに説得されてキャンペーン構成を組み直し、損を出した記録が広く読まれています。最も支持された返信が理由を述べています。モデルは在庫状況も契約上の制約もアカウントの履歴も知りません。別の人の言い方を借れば、二つの善のうちどちらを取るかを知らないのです。パターン発見はこの種のモデルが本当に強い領域ですが、どちらも成り立つ戦略の選択はそうではありません。
二つ目は振れ幅です。三日分のデータで入札を上げ、二日後に下げる。ターゲットは決して安定しません。規模を持って運用している人はターゲットごとに 5〜7 日のクールダウンを強制し、それがどのモデル変更より効いたと述べています。
Orkas が今日カバーしている範囲
Orkas はローカルファーストのマルチエージェントデスクトップアプリです。商取引コネクタ——Shopify、Amazon Seller Central、eBay、Etsy、TikTok Shop、Shopee、WooCommerce、Walmart ほか——はすべてホスト所有のポリシー層を通ります。以下のうち八つは実装済み、四つは未実装です。悪い書き込みの後ではなく、ここで知っていただきたいと考えています。
| 管制 | 状態 | 実際にあるもの |
|---|---|---|
| 四段階のリスク分類 | ✅ | 各コネクタ動作は R / W / H / D（読取・書込・高影響・破壊） |
| 書き込み前のプレビュー | ✅ | 書込操作は即実行せずプレビュー確認を経由 |
| 金銭に関わる変更は再確認 | ✅ | 高影響の動作は外部・財務変更として再確認を要求 |
| 影響範囲の上限 | ✅ | 1 回の呼び出しが触れられる件数に上限、実行前に検査 |
| 読取専用接続 | ✅ | 能力一覧・動作説明・読取のみに限定可能 |
| 分類はホストが所有 | ✅ | リスクは動作 ID に紐づくホスト側の固定表由来。ツール側の記述で信頼は広がらない |
| 未知の動作はフェイルクローズ | ✅ | 未分類は高影響扱い。信頼できるポリシーがない商取引動作は実行せず拒否 |
| 製品境界のブロックリスト | ✅ | 付与スコープに関わらず公開しない固定リスト |
| 動詞別権限（作成 / 編集 / 停止） | ❌ | 権限はリスク段階別で、動詞別ではない |
| 金額の上限・予算変更率の上限 | ❌ | 上限は件数であり、金額ではない |
| ロールバック経路 | ❌ | 未実装。一括の巻き戻しは手作業 |
| エクスポート可能な不変監査ログ | ❌ | コネクタ呼び出しは計測されるが、顧客に渡せる監査記録ではない |
最後の四つが必須要件である場合——多くは監査を求められる顧客の広告アカウントを運用しているとき——Orkas は今日の時点でそれを満たしません。すべての書き込みに人を残してください。
もう一つの道：書き込み権限を渡さない
仕事のかなりの部分は、書き込みではなく分析が本願です。レポートを書き出し、ローカルの作業場に置き、エージェントに読ませる。開発者申請も審査待ちもなく、書き込み権限付きの資格情報も経路に入りません。しかもこれが、不可逆なものを渡す前に「役に立つか」を確かめる最速の方法です。実例二つ：仕入先の追跡番号を注文と照合する、そして週次の店舗レビューのユースケース。
なぜ「買う」が難しいのか
プラットフォームの API はたいてい無料です。関門は承認であって価格ではありません。Amazon 自身の Ads MCP サーバーは有効な Ads API 資格情報を要求します。Shopify は店舗と同じ組織に属する加盟店自身のアプリを。TikTok Shop は売り手開発者審査を通った Custom App を。eBay は Developers Program の本番キーセットと自分の署名鍵を。個人の出店者にとってこれらはフォームではなくプロジェクトです——多くの人がエクスポート経由で済ませ、何も接続しない理由です。それは合理的な選択であり、まともなツールならそのモードでもよく働くべきです。