AI workers はツール箱ではない：自動化を広げる前に運用ワークベンチを作る

創業者が AI workers に投稿、顧客返信、ダッシュボード更新を任せるとき、本当のリスクはモデルの知能ではありません。仕事の表面が見えないことです。OpenAI News、GitHub Blog AI、Hugging Face Blog、Microsoft WorkLab は、AI が会話からワークフローへ移っていることを示しています。だから今日の経営判断は、会社が「その仕事がどう起きたか」を説明できるかです。

> ALTOS LAB の判断：観測できず、修復できず、作った人以外が説明できない AI workers は、まだ自律性を広げるべきではありません。

自律化の前に観測可能にする。 work diary は技術ログではなく「仕事の日誌」です。AI workers が何を見て、どの道具を使い、何を出し、どこで引き継いだかを残します。scorecard は試験ではなく、同じ種類の仕事が良くなっているかを見るスコアカードです。safe return path は失敗ではなく、問題が起きたときに前の信頼できる手順へ戻る保険です。

タスク市場から始める ツールから始めないでください。毎週繰り返す仕事を並べます。サポート返信、調査メモ、SNS 対応、記事制作、レポート点検。どれも自動化できそうですが、必要な証拠、リスク、引き継ぎは違います。最初に、自動完了、承認必須、提案のみの三つに分類します。

分類できると、権限は小さくなります。AI workers は全システムに触る必要はありません。タスクごとに最小のツールだけを開き、実行ごとに後から監査できる証拠を残します。

証拠がプロダクトになる 投稿 AI workers は「完了しました」だけでは足りません。ソース、下書き、レビュー理由、公開 URL、スクリーンショットまたは system receipt、失敗理由、次の修復を残すべきです。これがなければ、自動化ではなく会話ログへの信頼です。

30 日の導入 一週目は三つの仕事を選びます。完了できる仕事、承認が必要な仕事、提案だけの仕事。二週目は入力、出力、許可ツール、禁止ツール、証拠欄、修復経路を決めます。三週目は毎日動かし、公開行動に証拠を残します。四週目は完了率、証拠率、同じ失敗の減少だけを見ます。

数字が動かないなら、ツールを増やさず運用ループを直します。規模化とはコネクタを増やすことではなく、同じ失敗が翌朝戻ってこないことです。

読者の質問 Q: 遅くなりませんか？ A: 最初は構造が増えますが、同じ失敗の調査が減るので一か月後は速くなります。

Q: 最小版は？ A: タスクリスト、証拠欄、owner、公開 proof receipt、修復メモです。

Q: 人の確認はいつ必要？ A: お金、ブランド、法務、顧客、公開主張に関わるときです。

実例 たとえば SNS 運用 AI workers を考えます。朝に前日の反応を読み、返信すべきコメントを三つ選び、ブランドの声で下書きを作ります。ワークベンチがない場合、owner には「完了」しか見えません。ワークベンチがある場合、元コメント、返信理由、使ったデータ、下書き、公開確認、誤解されたときの修復経路まで見えます。

これは見た目の透明性ではありません。訓練データになります。反応が低い返信があれば、AI workers は「冒頭がテンプレートすぎたのか」「根拠が薄いのか」「サポート口調すぎたのか」「時間が悪いのか」を説明します。その理由が skill に戻り、次の実行ルールになります。

ALTOS LAB はこれを学習する運用単位と呼びます。毎日仕事を終え、毎日の失敗を翌日の改善方法に圧縮する単位です。