「この作業、もうRoutineにしていい？」
Tomoya先に答えます。
Grok Botを使うゴールはRoutine化です。
ただし、チャット→Skill→Routineと1段ずつ上げ、崩れたら1段戻します。
いきなりRoutineにすると、失敗したときの決まりがないまま毎週動き続けます。この記事では、手持ちの作業を横並びの比較表で仕分け、次の一段と「戻すサイン」までを表にします。
読む時間は約7分です。表はそのままコピーして使えます。
ポイントは次の3つです
- 比べる軸は、向く条件／まだ早いサイン／次の一手の3つです。
- 手持ちの作業を棚卸し表に並べ、1つずつ「いまの段階」と「次の一段」を決めます。
- Routineにしたあと崩れたら、切り戻しサインを見て1段下げます。
Tomoyaよく聞かれる点を、先に表にします。
| よくある質問 | 答え |
|---|---|
| SkillとRoutineの違いは？ | Skillは「どうやるか」の手順。Routineは「いつ走らせるか」の予定です |
| 全部Routineにするべき？ | いいえ。ゴールはRoutineでも、判断が毎回変わる作業はチャットかSkillに残します |
| Routineにしたあと崩れたら？ | 削除せず一時停止し、1段戻して型を直します。直ったらまた上げれば十分です |
チャット・Skill・Routineの比較表。3つの軸で並べる
Skillは、タスクの「やり方」を再利用できる形にした指示です。
Routineは、1つのBotに「いつワークフローを走らせるか」を伝えるものです。
スケジュールのほか、対応していればイベントをきっかけにもできます。
順番は、一回限りの仕事から始める→信頼できる状態にする→やり方をSkillに保存する→そのあとで自動化する、です。
わかりやすく言うと
チャットはその場で頼む、Skillは頼み方をメモに残す、Routineはそのメモで予約するです。
メモがないのに予約だけ入れない、が公式の順番です。
この順番そのものの詳しい説明は、別記事にまとめています。ここでは、手持ちの作業を横に並べて比べることに絞ります。
比較表です（コピーできます）
| 使い方 | 向く条件 | まだ早いサイン | 次の一手 |
|---|---|---|---|
| ① チャット | 一回限り／やり方がまだ揺れる／結果の形が決まっていない | 同じ説明を毎週貼り始めている | 一回やりきって、結果の形を固める |
| ② Skill | 成功した手順を再現できる／別の入力でも通る | 失敗したときの扱いや、承認が要る操作が空のまま | 手順をSkill名で保存し、別の入力で試す |
| ③ Routine | 入力元・期待する結果・失敗時（データ欠けを含む）が決まっている | テスト実行で失敗が曖昧／毎回手順が変わる | 確認項目を埋めてから有効にする |
具体例です。
「GitHubの週次の更新通知を読んで、今週直す候補を3つ出す」という作業で考えます。頼み方が毎週変わるうちはチャット、出力の形が固まったらSkill、毎週月曜の朝に自動で回したくなったらRoutine、の順です。
Tomoya同じ作業でも、段階は時期によって変わります。
表は一度埋めて終わりではなく、月に1回くらい見直すと現在地がずれません。
手持ちの作業を棚卸しする。条件→行動で現在地を決める
Tomoya表を見たら、いま抱えている作業を1行ずつ当てはめます。
当てはまった行の行動だけやってください。
| 条件 | 行動 |
|---|---|
| 初めて／言い方が毎回変わる／出力の形が決まらない | チャットで一回やりきる |
| 一回成功し、別の入力でも同じ形で通る | Skillとして保存し、別の入力でもう一度試す |
| Skillがあり、失敗時・入力が欠けたときの動きまで書ける | Routineを検討する（まだ有効にしない） |
| 読む・下書きまでは自動でよいが、外への送信は毎回確認したい | 準備まではRoutineにしてよい。送信や公開は承認の後ろに置く |
手順は次の3つです
- 作業を一文で書く（「毎週月曜に公開候補を3つ出す」など）
- 上の比較表で、向く条件にいちばん近い行を選ぶ
- 条件→行動表のその行だけやる（SkillとRoutineを同じ日に作らない）
コピー用の棚卸し表です。
| 作業（一文） | いまの段階 | まだ早いサイン | 次の一手 | 戻す条件 |
|---|---|---|---|---|
| チャット／Skill／Routine | ||||
| チャット／Skill／Routine | ||||
| チャット／Skill／Routine |
Tomoya「戻す条件」の欄は、上げる前に書いておくのがコツです。
崩れたときに迷わず1段下げられます。
Use casesのページも同じ流れです。まずは「読んで準備する」仕事から始めて結果を確認し、そのあとで承認つきの操作やRoutineを足す、と書きます。
長く任せる手順も同じです。成功した手順をSkillに保存し、2つ目の入力で試します。リトライと失敗したときの扱いが決まってから、Routineにします。
概要ページでは、設定はワークフローを組む画面ではなくメッセージで行う、とあります。結果を確認して直し、安定した手順をSkillやRoutineにする前提です。
Tomoya試しに、この1か月でチャットに2回以上同じ説明を貼った作業を数えてみてください。
その数が、Skillに上げる候補の数です。
週次振り返りの中身をどう回すか、やる／やらないの仕分けそのものは、ここでは扱いません。
「まだ早い」サインと切り戻し。崩れたら1段戻す
ここでいう切り戻しは、RoutineやSkillを消すことではありません。
1段下の使い方に戻して、型を直すことです。
| サイン | どこが早いか | 切り戻し |
|---|---|---|
| 毎回指示を足さないと通らない | Skillが早すぎる | チャットに戻して型を固める |
| 別の入力で崩れる／結果の確かめ方がない | Skillがまだ未完成 | Skillを直し、試し直してからRoutineを考える |
| 元データが無いのに、古いデータで進もうとする | Routineの信頼設計が足りない | 「データが無ければ古いもので進めず報告する」と書いてから、テストし直す |
| テスト実行で、失敗したのかどうかが曖昧 | Routineを有効にするのが早い | 失敗の状態をはっきり書いてから有効にする |
| 手順が週ごとに変わる | SkillもRoutineも早い | チャットで安定するまで待つ |
切り戻すときは、削除より一時停止を選んでください。
公式には、Routineの削除はすぐに反映され、元に戻せないとあります。
公式の管理画面では、Routineの有効化と一時停止、テスト実行、スケジュールや指示の編集、最近の成功・失敗の履歴の確認ができます。
信頼できる形にする目安も挙がっています。実行より準備を先に自動化する、データが無いときや古いときの決まりを入れる、の2つです。Webサイトやコネクタ、元データの形式が変わったらテストし直す、ともあります。
| 条件 | 行動 |
|---|---|
| Routineを回しているが、毎週手直しが要る | Routineを一時停止し、Skillかチャットで型を直す |
| Skill名だけあって、中身が空に近い | チャットで一回成功させてから、Skillを書き直す |
| 失敗したときの扱いが「不明」のまま | Routineにしない |
| 連携先のサイトや元データの形式が変わった | 一時停止してテスト実行し直す |
TomoyaいまRoutineにしている作業があれば、最近の実行履歴を開いてみてください。
失敗が「何が足りなかったか」まで分かる書き方になっていなければ、1段戻すサインです。
送信や公開の前にどこで止めるか、承認ルールの置き方は別記事にまとめています。
ここで迷いやすい点
- ゴールがRoutineでも、全部の作業を上げなくてよい（判断が毎回違う作業はチャットに残す）
- SkillとRoutineを同じ日に作らない（Skillを別の入力で試してから）
- 崩れたRoutineを削除で片付けない（まず一時停止。削除は元に戻せない）
- 三者を並べた公式の比較表はない。この記事の表は、公式の定義と順番から組んだもの
まとめと次の行動
- ゴールはRoutine化。ただし、チャット→Skill→Routineと1段ずつ上げる
- 比べる軸は、向く条件／まだ早いサイン／次の一手
- 手持ちの作業は棚卸し表で1行ずつ現在地を決める
- 崩れたら切り戻し表で1段下げる。削除より一時停止
次の行動は2つです。
Go1：毎週くり返している作業を3つまで一文で書き、比較表で「いまの段階」を決める。
Go2：いちばん上の1つだけ、その行の次の一手を今日やる。
※本記事は xAI の Grok Bot ドキュメント（Skills and routines、Use cases、概要）に基づきます。三者を並べた公式の単一比較表はないため、表は公式の定義と順番から組み立てています。製品の文言は変わることがあります。
コメント