「この作業、もうRoutineにしちゃおうかな」
Tomoya先に答えます。
公式の順番は、一回限りの仕事で安定させ、やり方をSkillに保存し、それからRoutineです。
やり方が揺れているうちは、毎回チャットのままが正解なことが多いです。
読む時間は約9分です。
ポイントは次の3つです
- 決定順は、一回限り→Skill→Routineです。すぐRoutineにしない（skills-routines）。
- Skill化するのは、いま使った成功手順が再現できたあとです。
- Routine化するのは、入力・期待結果・失敗時（欠落やリトライ）まで定義してからです（use-cases）。
| よくある質問 | 答え |
|---|---|
| SkillとRoutineの違いは？ | Skill＝やり方、Routine＝いつ走らせるか（詳細は morning へ） |
| すぐRoutineでいい？ | いいえ。一回で安定→Skill→失敗時まで決めてからRoutine |
| 毎回チャットはダメ？ | 初回や状況判断はチャット向き。同じ説明の繰り返しがSkill化のサイン |
| 週次や承認・コネクタは？ | 中身は別記事へ。ここでは切り分けだけ |
決定順の骨格と「まだチャット」が正解な場合
成功したタスクを繰り返せる形にするとき、
一回限りの仕事から始め、信頼性を上げ、方法をskillに保存し、そのあとに自動化せよ、と書きます。
| 段階 | 向くやり方 | まだ足りないサイン |
|---|---|---|
| 一回限り／未安定 | その場のチャット | 毎回指示が変わる、結果の形が決まらない |
| やり方が再現できた | Skill | 同じ説明を何度も貼っている |
| 繰り返し＋失敗時まで決まった | Routine | 入力欠落や失敗時の挙動が未定義 |
具体例
「来週の公開候補を3つ出して」と毎週言い方が変わるうちは、チャットで一回ずつ直します。
言い回しと出力の型が固まったらSkill、毎週同じ時刻に無人で回すならそのあとRoutine、という順です。
わかりやすく言うと
チャットは試作、Skillはレシピカード、Routineはタイマーです。
レシピが無いのにタイマーだけセットしない、が公式順です。
「チャットのままが正解」という専用ラベルは公式にありません。一回限りや未安定の仕事は、まだ自動化しない、と公式順序から読む範囲に留めます。状況判断が毎回違う仕事も、チャット側に残すのが自然です。
| 条件 | 行動 |
|---|---|
| 初めての作業／手順が揺れる | チャットで一回やりきる |
| 同じ説明を毎週貼っている | Skill化を検討（次のH2） |
| 週次で無人起動したい | 失敗時まで揃えてからRoutine（その次のH2） |
用語の長い定義や朝の優先の型そのものは、ここでは再説しません。
Skill化するサイン
公式のskill例は、「いま使った手順」を保存する頼み方です。
Teachで作ったdraftにも、失敗処理と承認境界を足せ、とあります。つまりSkill化のゲートは、「いまの一回が、レビューできる結果まで直った」ことです。
Tomoyause-casesの「Turn an example into a durable Bot」も同じ順です。
実タスクを安全範囲で1回→結果がレビュー可能になるまで直す→成功手順をskill→別入力でテスト、のあとでroutineです。
手順は次の3つです。
- チャットで一回、満足できる結果まで直す。
- 「いま使った手順」をSkill名付きで保存する（いつ使うか／入力／手順／検証／返すもの／承認が要るものを残す）。
- 別の入力でもう一度試し、説明を足さずに通るか見る。
指示の例
- いまのやり方を『週次公開候補の洗い出し』というSkill名で保存して。
- 入力は下書きフォルダ、返すものは候補3つと理由1行ずつ。外部送信はしない。
別週のフォルダでも同じ型で通れば、Skill化のサインです。
| 条件 | 行動 |
|---|---|
| まだ結果の形が毎回違う | Skillにしない。チャットで型を固める |
| 一回成功したが別入力で崩れる | Skill前に直し、再テスト |
| 別入力でも通る | Skill化してよい |
週次振り返りの中身の手順や、コネクタをどれにつなぐかの表は扱いません。
私の場合は、Gmailを毎日チェックするのでGmailから緊急度の高い内容を優先順位付けしてTodo化してもらう作業を自動化しています。
これをすることで毎日一定の時間を精査する必要がなくなり重要な事だけピックアップしてもらう事で何に集中するべきかが明確になり時短になりました。
報告・承認後にBotでできる事は実行して、できない所は自分のタスクになります。粒度の細かい状態でTodoになるのでやることも明確です。
Routine化する前に揃えるもの
Routineは「いつ走らせるか」です。
作成前に公式が確認せよと言うのは、担当Bot・スケジュールとタイムゾーン・入力源・期待結果・承認境界・ソース欠落時、です。
Test runでは、失敗状態が明示か、意図した承認点で止まったかも見ます。無データ／古いデータ方針も信頼設計に入ります。
use-casesは、リトライと失敗ケースを定義してからroutine、重い外部アクションは承認の後ろ、と書きます。ここが最終ゲートです。失敗時が空のままRoutineだけ作ると、空回りや危険な自動実行につながります。
確認の書き方の例
- 入力が空のときは候補を捏造せず『不足』と報告する。
- 古い下書きしか無いときは日付を明示する。
- 公開やメール送信はしない
これが揃ってから、月曜9時のRoutineを検討します。
| 条件 | 行動 |
|---|---|
| Skillはあるが失敗時が未定義 | Routineにしない。欠落時の報告をSkill／依頼文に書く |
| 下書きまでなら自動でよい | Routine可。外部送信は承認の後ろ |
| Test runで失敗が曖昧 | 直してから有効化 |
Ask firstのルール表そのものは再説しません。境界の置き方の詳細は別記事へ。
ここで迷いやすい点
- 便利そうだからすぐRoutineにしない。
- Skill名だけ作って、成功手順の中身が空のままにしない。
- 週次・朝・承認・コネクタの手順記事を、この切り分けの代わりに読まない（リンクで足りる）。
- 「チャット禁止」と誤解しない。未安定ならチャットが正解。
まとめと次の行動
- 順は一回限り→Skill→Routine
- Skillは再現できた成功手順から
- Routineは失敗時まで定義してから
次の行動は2つです。
Go1：毎週チャットで繰り返している作業を1つ書く。
Go2：それが未安定ならもう一回チャットで型を固める。再現できているならSkill化し、失敗時を書いてからRoutineを検討する。
※本記事は xAI Skills and routines と Use cases に基づきます。製品文言は変わり得ます。
コメント