このレッスンでできるようになること
Botが毎朝動いていても、使わない報告が増えただけなら改善が必要です。最終回では、完成した仕事、手戻り、人の確認時間、利用量から運用を見直します。目標はBotを増やすことではなく、必要な成果を少ない負担で受け取ることです。評価表と判断基準は本コースの設計例です。公式の管理方法は2026年10月19日に確認していますが、時間削減や売上の効果を実測した記事ではありません。
1．開始前と運用後を、同じ仕事で比べる
比較する単位を決めます。競合調査なら一回分の対象企業数と期間をそろえ、完了件数、事実の誤り、修正回数、人が使った準備・確認・修正時間を記録します。対象が一社から十社に増えていたら、総時間だけでは前後を比べられません。
たとえば手作業四十分の仕事が、依頼五分、確認十分、修正五分になれば、人の作業は二十分です。これは計算方法を示す仮の数字で、Grok Botの効果を示す実績ではありません。Botが待機した時間と、人が手を動かした時間を分け、実測していない値は未計測とします。
2．品質の問題を、起きた場所へ戻す
不具合を「AIの精度」で一括りにすると、改善の場所が分かりません。対象が違ったなら依頼書、古い価格を使ったなら情報源の確認、担当が二重に動いたなら受け渡し、表が切れていたなら成果物の検査、と分けます。毎回同じ修正が出るなら、その場の会話だけでなく役割説明やスキルへ反映します。
どこへ保存するかの目安は、全案件で守る好みは役割説明、繰り返す作業手順はスキル、日時と起動条件はルーチン、その回の条件は依頼書です。変更箇所を一つに絞ると、次の結果が改善した理由を追いやすくなります。ルーチンだけを直しても、手動で使うスキルの誤りは残る場合があります。
3．利用量を、仕事の価値と一緒に見る
SettingsのUsage & Billingや利用可能なアカウント画面で、週の利用状況と追加利用の設定を確認します。表示される項目はアカウントによって異なります。Bot別の正確な費用が画面で得られない場合に、依頼回数から金額を推測して確定値として書かないでください。
利用量が増えたら、まず読んでいない日報、広すぎるイベント条件、同じ出典の再調査、解決しない再試行を探します。単に品質確認を外して使用量を減らすと、後で人が直す負担が増える可能性があります。価値の低い実行を減らし、確認が必要な仕事へ余力を残す順で見直します。
Team Botでは利用者自身のやり取りはその人の利用枠、個人ルーチンは作成者の利用枠として扱われます。共有のBotだから所有者だけを見ればよいとは限りません。公式資料にはSlackのワークフローなど例外もあるため、利用経路と負担先を一緒に確認します。
4．増やす、統合する、休止するを決める
専門担当を増やすのは、安定して繰り返す仕事があり、別の判断基準を持つ方がよい場合です。逆に二体が同じ情報を集めているなら、収集を一体へまとめられます。月に一回しか使わない担当は、常時ルーチンを動かさず、必要時だけ呼ぶ形も選べます。
実際に休止すると決めたら、対象のルーチンを一時停止し、次回実行が無効になったことを確認します。サイドバーでBotを隠す操作は停止ではありません。Team Botを一時的にチームから外す場合は、所有者がUnpublishを使う選択肢があります。削除より先に、影響する利用者と再開方法を確かめます。
5．改善後も、同じ基準で一度確かめる
変更したら、新しい入力で一回動かします。前と同じ種類の仕事で、誤りが減ったか、人の確認時間が減ったかを記録します。結果が悪化したら元の手順へ戻せるように、変更前の内容と変更理由を残します。改善案を採用しただけで「改善済み」にしないことが大切です。
記録は「問題、根拠、変更箇所、結果、次の見直し日」の五項目で十分です。次の見直し日を決め、使われない報告が残っていないかを確認します。頻繁な改善より、効果があった変更を定着させることを優先します。
実践課題と完了チェック
一週間分の運用、または一件の試験記録から振り返り表を作り、改善を一つ選んでください。実測と未計測が分かれ、変更箇所と再テストの結果が残り、次の確認日が決まれば本コースの課題は完了です。仕事を一つ選ぶ、役割と資料を整える、連携を試す、スキル化する、自動化を確かめる、結果から見直す。この順番を、新しい仕事にも適用してください。
