Grok Botのスキルとルーチンを使い分ける — 朝ダイジェストを例に

チャットで一度きりの作業を頼むのと、毎朝決まった時間に動いてほしいのとでは、ボットに求めるものが根本的に違います。Grok Bot にはその違いに対応する仕組みとして スキル（Skill） と ルーチン（Routine） があります。この記事では二つの概念の違いを整理し、朝ダイジェストの例を使いながら実際の設計ポイントを書いていきます。

1. 永続ボットには「一発チャット」以上のものが必要

Claude や Grok を試したことがある人なら、「毎朝メールを要約して」「週に一度トピックを提案して」といった繰り返しタスクをチャット欄で設定しようとして困った経験があるかもしれません。チャットは会話のたびにコンテキストがリセットされるため、スケジュール実行や条件トリガーには向いていません。

Grok Bot はデスクトップ／モバイルのアプリから操作し、実際の作業はクラウド側で進むボットです。スキルとルーチンという二つの仕組みで「どう動くか」と「いつ動くか」を分離して管理できます。

2. スキル = 再利用レシピ（How）、ルーチン = 実行タイミング（When）

スキル（Skill）

スキルは 「こういう手順でやる」 を保存したレシピです。

  • 入力・出力の形式、使うツール、応答のスタイルを定義する
  • 一度作ればルーチンや手動呼び出しから何度でも参照できる
  • 「承認済みチャンネルとカレンダーを読んで、優先度に紐づく項目だけ返す」という手順をスキルにすれば、ルーチンから呼んでも、チャットから / でスキルを参照しても同じ品質で動く

ルーチン（Routine）

ルーチンは 「いつ・何をきっかけに動かすか」 の設定です。

  • スケジュール（例: 平日 8:00）や、対応しているイベント（Slack / GitHub など）で動く
  • カレンダーは トリガーではなくデータ源 として使う（予定を読む・要約する）
  • 「平日の 8:00 に朝ダイジェストスキルを実行して、この会話に結果を出す」という指示がルーチン
  • スキルを持たずに直接プロンプトを書くこともできるが、使い回したい処理はスキルに切り出すと管理しやすい
概念問いに答える変更頻度
スキルどうやるか処理の改善時
ルーチンいつ・何をきっかけにやるかスケジュール変更時

公式の言い回しに寄せると、「やり方は Skill、いつ動かすかは Routine。一度うまくいった手順を Skill にしてから、Routine で自動化する」です。

3. 推奨順序：まず一度手動で試す → スキル化 → ルーチン化

いきなりルーチンを組むと、処理が期待どおりでも設定ミスなのかスキルのミスなのか切り分けが難しくなります。次の順番が現実的です。

  1. チャットで一度手動実行する — 出力が納得できる品質か確認する
  2. スキルとして保存する — 手順・フォーマット・ツールを固定する
  3. ルーチンに組み込む — スケジュールとトリガーだけを設定する

スキルが安定してからルーチンに繋ぐ、この順序を守るだけで「なぜ毎朝変な出力が届くのか分からない」という状況をかなり減らせます。

4. 実例①：平日朝のダイジェスト（Chief of Staff 骨格）

概要

平日 8:00 に、承認済みチャンネル・受信箱・カレンダー・会議メモなどを横断してレビューし、優先度に紐づく項目だけをダイジェストとして返します。カレンダーは予定の データ源 です。

スキル／プロンプト（公式骨格に沿った例）

Every weekday at 8:00 AM, review activity since yesterday across my approved Slack channels, inbox, calendar, and meeting notes. Return only items that map to the priorities in [priority doc]. For each item include the source, why it matters, the proposed next step, and whether I owe a decision. Post the digest in this conversation. Do not send messages or change meetings. If a source is unavailable, report the failure instead of using old data.

出力に含める要素は次のとおりです。

  1. 優先度に紐づく項目だけ
  2. 各項目: source / why it matters / proposed next step / decision owed?
  3. 送信・会議変更はしない（境界）

ルーチン設定（イメージ）

トリガー: 平日（月〜金）08:00（タイムゾーンは Settings のスケジュール用設定）
実行: 上記の朝ダイジェスト手順（スキル化したもの）を呼び出す
出力先: この会話（ダイジェスト投稿）
境界: メッセージ送信・会議変更はしない。ソース欠落時は失敗を報告

出力イメージ

## 朝ダイジェスト（優先度に紐づくもののみ）

1. [Slack #eng] PR #42 レビュー依頼
   - why: 本日マージ目標のブロッカー
   - next: レビューして Approve / Request changes
   - decision: 要（自分がレビュアー）

2. [Calendar] 13:00 デザインレビュー
   - why: 優先ドキュメントの「顧客向けUI」に該当
   - next: 事前資料を開いて論点を1つ決める
   - decision: 不要

読み取りと要約が中心で、送信・会議変更は境界の外に置くので、最初に試すルーチンとして適しています。

5. 実例②：週次ブログトピック候補リスト

概要

毎週土曜 9:00 に、過去記事の一覧をコンテキストとして渡し、新しく書けそうなトピックを 5 件提案させます。

スキル定義（イメージ）

スキル名: ブログトピック提案

入力: 既存の記事タイトル一覧（テキスト）
出力: 書いていない・書ける可能性が高いトピック候補 5 件
  - 各候補に「なぜ読者に刺さるか」を 1 行で付ける
言語: 日本語
トーン: 実用的・技術寄り

ルーチン設定（イメージ）

トリガー: 毎週土曜 09:00（タイムゾーンは Settings）
入力: src/content/blog/ の記事タイトルを自動収集
実行: ブログトピック提案スキルを呼び出す
出力先: この会話、または承認済みの通知先
境界: 投稿・公開はしない（提案のみ）

読み取りと生成だけなので副作用がなく、出力をそのまま採用しなくてよいため気軽に回せます。「提案が来たら一つ選んで書く」という習慣づくりに使えます。

6. 信頼設計：承認ゲートと冪等リトライ

自動実行が便利になるほど、「気づいたら変なメッセージが大量送信されていた」「カレンダーのイベントが勝手に削除されていた」というリスクが増えます。次の4点を意識するだけで安全性が大幅に上がります。

送信・購入・削除・公開には承認ゲートを設ける

読み取りと生成だけのスキルはそのまま自動化できます。一方で、外部に影響する操作（メール送信、予約、削除、SNS 投稿）には人間の承認ステップを挟むのが原則です。

承認が必要なとき、会話には提案された操作とその入力が表示されます。デスクトップでは Allow once / Deny（必要なら Always allow でルール保存）、モバイルでは Approve once / Deny です。承認はその提案アクションを制御するもので、すでに完了した作業を取り消すものではありません。

# 悪い例（無条件に送信）
毎朝 8:00 に顧客へのフォローアップメールを送る

# 良い例（承認付き）
毎朝 8:00 にフォローアップメールの草稿を作成する。
送信は承認（Allow once）が出た場合のみ実行する。

ルーチンやイベントトリガーの変更も、Auto-review の対象になり得ます（proceed / require approval / deny）。承認ルールは Settings → General → Auto-review で確認できます。

テスト実行でも本番の副作用が発生する

「とりあえずテスト」で実行しても、カレンダーへの書き込みやメール送信は本物の環境で動きます。テスト用の設定を用意するか、出力を確認してから本番に繋ぐ手順を踏みましょう。

冪等な設計にする

ルーチンが二重実行された場合でも結果が変わらない設計（冪等性）を意識します。「今日の予定を投稿する」は何度実行しても同じ内容なので問題ありません。「カウンターを +1 する」や「イベントを新規作成する」は二重実行すると意図しない状態になります。

部分失敗を報告する

ステップが複数あるスキルでは、途中でエラーが起きたとき「何が成功して何が失敗したか」を報告させるようにしておくと、原因特定が速くなります。

# スキルの末尾に追加する指示の例
ステップが完了したら結果を箇条書きで報告してください。
失敗したステップがあれば、理由とともに記録し、残りのステップは続行してください。
ソースが取れない場合は古いデータで埋めず、失敗を報告してください。

7. 実用Tip まとめ

  • 最初の 1 ルーチンは読み取り専用から始める — カレンダーやファイルを読んで要約するだけなら副作用がなく安全
  • スキルとルーチンを 1 対 1 にしない — 同じスキルを「平日版」「週末版」で別ルーチンから呼ぶのは有効
  • 出力フォーマットをスキルに固定する — 受け取り側に合わせてフォーマットをスキル内に書いておくと、ルーチンを変えても出力が安定する
  • スケジュールは少なめに始める — 毎分実行や毎時実行は API コストと通知疲れを招く。日次・週次から試して必要なら増やす
  • ルーチンのログを定期的に確認する — Bot を開く → View conversation details → Routines で履歴を見られる。「毎日来ているはずが来ていない」に気づくために、月に一度は実行履歴を見る習慣をつける

8. まとめ：まず朝の 1 ダイジェストから

スキルとルーチンの役割分担を一言で言うと、「手順はスキルに、タイミングはルーチンに」です。

両方を最初から完璧に設計しようとせず、まず手動でスキルを試して品質を確認し、それからルーチンに組み込む——この順番を守るだけでトラブルの大半は防げます。

最初の一歩としては、送信・会議変更を境界の外に置いた朝ダイジェストが適しています。副作用が小さく、失敗しても困らず、成功したときの価値が分かりやすい。そこから「週次トピック提案」や、承認付きの送信へと少しずつ広げていくのがお勧めです。

参考