毎朝「何からやる？」をAIに聞く前に決めておきたいこと
朝いちばんに「今日は何から手を付けよう」と、AIとのチャットに相談する。
Tomoya心当たりのある方も多いのではないでしょうか。
便利ではあるのですが、同じような質問を毎回一から説明し直すのは、地味に手間がかかります。
Grok Botには、この「やり方」と「いつやるか」を分けて仕組み化できる機能があります。
今回は、公式ドキュメントをもとに、朝の優先タスクを自動で整理してもらうための考え方を整理しました。
🔍先に用語だけサクッと
- Skill（スキル）：「これをこうやって」という作業の手順書。一度うまくいったやり方を、繰り返し使える形にしたものです
- Routine（ルーティン）：「いつ動かすか」の予定表。特定のSkillを「平日の朝8時に実行して」のように割り当てます
- 承認（Approval）：送信・削除・公開など、重要な操作の前に必ず人（自分）の確認をはさむ仕組みです
- Test run（テスト実行）：作った・直したRoutineを、本番同様に一度試してみること。プレビューではなく、実際に動きます
- コネクタ（Connector）：GmailやカレンダーなどのAPI連携（外部サービスと情報をやり取りする窓口）を指す言葉です
先に結論から
細かい話に入る前に、要点を3つだけ先にお伝えします。
- Skillは「やり方」、Routineは「いつ走らせるか」。 この2つを分けて考えるのが基本です。
- 朝の自動化は、何を見るか・どんな結果を期待するか・どこで人の確認を挟むか・情報が取れなかったらどうするかを先に決めてから、Routineとして組み立てます。
- 準備（下書き・提案・並べ替え）までは自動、送信や公開、本番環境への変更は必ず承認を挟むのが基本方針です。危険な操作の前で必ず人に確認を求める設定（Require Approval）を、狭い範囲にピンポイントで置くのがコツです。
参照したのは、Grok Bot公式ドキュメントの「Skills and routines」「FAQ」「Approvals, security, and privacy」の3ページです。この記事では、実装のハンズオンや、複数Botを使った大掛かりな仕組みづくりには踏み込みません。
毎回チャットに聞くのと、何が違うのか
その場その場でAIに相談するチャットは、状況判断には強い方法です。
ただ、同じような「朝の確認作業」を毎回口頭で説明していると、聞き方によって答えの質にムラが出やすくなります。
公式ドキュメントでも、まずは一回きりのタスクとして試し、やり方が安定したらSkillとして保存し、そのうえで自動化する、という順番が勧められています。パソコンを閉じていても、背景で動くRoutineはクラウド上で作業を続けてくれます。
朝起きた時にGmailをチェックするのですが、その日によって量も内容も緊急度も違ってくるので大変です。これを必要なメールのみに仕分けして報告してもらうのが今回の目的になります。
SkillとRoutine。それぞれの役割
まずは、この2つの部品がそれぞれ何を担当するのかを整理します。
| 部品 | 公式の説明 | 朝の優先タスクでの役割 |
|---|---|---|
| Skill | 作業の「やり方」をまとめた、再利用できる指示書 | 何を見て、どう並べて、何を返すかを決める |
| Routine | 「いつ動かすか」を1つのBotに割り当てる予定表 | 平日の朝◯時に、そのSkillを走らせる |
Tomoya例えるなら、Skillはレシピ、Routineはタイマーです！
レシピ（やり方）がないままタイマー（いつ）だけ設定しても、決まった時間に何も起きない、ということになってしまいます。
良いSkillに書いておきたいこと
公式ドキュメントでは、しっかり機能するSkillには次の要素が含まれる、とされています。
- いつ使うか
- 必要な情報源と、そこへのアクセス
- 作業の順番
- 結果が合っているかの確認方法
- 何を返すか
- どこで承認が必要か
Routineを作るときに決めておくこと
- どのBotが担当するか
- スケジュールとタイムゾーン
- 何を情報源にするか
- どんな結果を期待するか
- どこで承認を挟むか
- 情報源が見つからない時にどうするか
公式の例文には「情報が取れない時は、古いデータを使い回さずに失敗として報告する」という一文が含まれています。
これは地味に重要なポイントで、「情報が古いまま、それらしい結果だけ返ってくる」状態を防ぐための工夫です。
朝の優先タスク、指示文の具体例
ここまでは少し抽象的な話だったので、実際にコピーして使える形の例を置いておきます。並べ替えの点数配分などは公式仕様ではなく、あくまで一つの型としての例です。
Skillの指示文例（やり方を教える）
- スキル名：平日朝の優先案 いつ使うか：平日の朝、今日何から手を付けるか決めるとき
- 必要な情報源：カレンダー（今日の予定）、Gmail（未読で対応が必要なものだけ）、GitHub（自分宛てで期限が近いIssueやPR）。コネクタがつながっていない情報源は使わない
- 作業順：①今日の予定を確認 ②返信が必要な未読メールを拾う ③自分宛てで期限が近いタスクを拾う ④並べ方のルールに沿って最大3件に絞る ⑤それぞれ1行＋根拠へのリンクで返す
- 並べ方のルール：期限が今日、または過ぎているものを最優先 → 自分がすぐ動けるものを次に → 承認待ちや情報不足のものは「保留」として別枠に
- 確認方法：それぞれの項目に根拠リンクがあるか。送信や本番変更の提案が紛れ込んでいないか
- 返すもの：今日の優先3件／保留中のもの／情報が取れなかった項目
- 承認が必要なもの：メール送信、Slack投稿、公開、削除、購入、本番環境の変更。ここは提案止まりにする
Routineの指示文例（いつ動かすか＋どこで止まるか）
- 平日8:00（日本時間）に、「平日朝の優先案」のSkillを実行してください。
- 結果はこの会話に投稿してください。顧客や第三者への連絡はしないでください。
- メール送信・公開・削除・購入・本番環境の変更はしないでください。
- 情報源が取得できない、または明らかに古い場合は、前日のリストを使い回さず、失敗として報告してください。
何を見て、どう並べるか
Tomoya自動化の中身をもう少し具体的に見ていきます。
ポイントは「何を情報源にするか」と「どう並べ替えるか」の2つです。
なお、「カレンダー・メール・GitHubから自動で優先度を採点するアルゴリズム」のようなものは、公式には用意されていません。並べ方のルールは、Skillの中に自分で書いておく必要があります。
情報源の選び方
| こんな時 | こうする |
|---|---|
| 今日の予定を優先の起点にしたい | カレンダーを情報源に含める（コネクタが必要） |
| 誰かへの返信が起点になりやすい | メールなどを含める。ただし送信は必ず承認を挟む |
| リポジトリの更新やレビューが起点 | GitHubなどを含める。本番への反映は承認を挟む |
| 情報源が取得できない・古い | それで埋め合わせず、失敗として報告する |
並べ方の考え方
先ほども触れた通り、これは公式のアルゴリズムではなく、Skillに書き込む「自分ルール」です。
朝の優先タスク向けの型としては、次のような順番がひとつの目安になります。
- 今日が期限、もしくは過ぎているものを先に見る
- 他人の返信待ちより、自分ですぐ動けるものを優先する
- 承認待ちや情報不足のものは、別枠として分けて報告する
私は主に「アクションが必要なメール」を優先度をつけて選別してもらい報告するようにしています。
結果はどんな形で返してもらうか
Routineを作る時に「期待する結果」を決めておく、というのは先ほど触れた通りです。朝の優先タスク向けなら、次のような形が扱いやすいでしょう。
- 今日の優先3件（それぞれ1行＋根拠リンク）
- 保留しているもの（承認待ちの候補）
- 情報が取れなかった項目の明示
重要な判断ほど、根拠リンクと作業の記録を残しておくと安心です。
どこまで自動にしてよいか
Tomoyaここが、今回いちばんお伝えしたいポイントです。
準備までは自動、実行は人の承認を挟む、というのが基本方針です。
信頼して自動化を進めるための工夫
公式ドキュメントで繰り返し出てくる考え方をまとめると、次のようになります。
- 実行そのものより先に、準備の部分から自動化する
- いきなり実行せず、下書きや提案を先に出す
- 送信・購入・削除・公開・本番環境の変更は、必ず承認を挟む
- 「情報が無い時」「古い時」にどうするかを、あらかじめ決めておく
- 途中までしか終わらなかった時、どこに報告するかを決めておく
加えて、依頼文の中で「どこまでやってよいか／どこで止まるべきか」をはっきり書いておくことも大切です。
承認は、これから行おうとしている操作を止める仕組みであって、すでに終わった作業を取り消すものではない、という点も覚えておくとよいでしょう。
使うツールは必要最小限にし、可能であれば「まずは読み取りと下書きだけ」から始めるのが安全です。
朝の優先タスクでの判断早見表
| 状況 | 対応 |
|---|---|
| 予定・メール・タスクを読んで並べ替え案を作る | 自動でよい（準備の範囲） |
| 「今日の優先3件」の下書きを会話に投稿する | 自動でよい（下書きの範囲） |
| メール送信、Slack投稿、公開、削除、本番変更 | 必ず承認を挟む。Routineにも「しない」と明記する |
| 情報源が空・古い | 埋め合わせず、失敗として報告する |
| 情報源や運用の前提が変わった | 一旦Routineを止めて見直す |
Test run（テスト実行）は、プレビューではなく実際に動く点に注意が必要です。
サイトの操作やファイルの変更、外部ツールの呼び出しが実際に起こり得るため、書き込み系の操作は必ず承認の後ろに置いておきましょう。
なお、SlackやGitHubの通知をきっかけに自動で動き出す仕組みも用意されていますが、これはCursorアカウントとの連携によるもので、プラグインとは別の仕組みです。
使う場合は「どんなメッセージに反応するか」を狭く絞り込み、「すべてのメッセージに反応する」といった広すぎる設定は避けるのがおすすめです。
私も重要な要件を自動ですべて完結してしまうものは避けています。とても楽ではありますが一度承認を得るプロセスを踏んでからGoサインを出すようにしています。
迷いやすいポイント
最後に、つまずきやすい点を5つにまとめておきます。
- SkillなしでRoutineだけ作らない。 レシピのないタイマーは、決まった時間に何も起きません。
- 「全部自動」にしない。 送信や本番変更は、必ず承認の後ろに置きます。
- 情報源が取れない時、前日の結果を使い回さない。 公式の例でも「失敗として報告する」形が推奨されています。
- Test runを「ただの確認」だと思わない。 実際に操作が動く可能性があります。
- 優先度の点数付けを、公式仕様のように扱わない。 それはあくまで自分で決めるルールです。
CursorプランにもGrokBot利用権があるのでセットで試せます
以下のリンクから月額プランを契約すると、初月は半額で利用できます。コストが心配な方でも、最初の1か月は最低10ドルから試せるので、気軽に始めやすいと思います（解約も簡単にできます）。
まとめと、次にやること
- Skillは「やり方」、Routineは「いつ」。まずはこの役割分担だけ覚えておけば十分です
- 情報源・並べ方・返す形・情報が無い時の扱いは、Skillの中に自分の言葉で書いておく
- 準備までは自動、送信・公開・削除・購入・本番変更は必ず承認を挟む
- パソコンを閉じていても、Routineは背景で動き続けます
Tomoya次にやることは2つです。
①：上のSkill指示文例を、自分が実際に使っている情報源の名前に書き換えること。
②：そして、Routine指示文例の時刻と承認の範囲を自分用に調整してから、一度Test runで試してみることです。
Grok Botにチャットで依頼する事で作成してくれるので試してみてください。
自分の毎日やっている単純な作業を自動化していきましょう！
※本記事は、docs.x.aiの「Skills and routines」「FAQ」「Approvals, security, and privacy」の内容をもとに作成しています。製品の仕様は変更される可能性があるため、最新情報は公式ドキュメントをご確認ください。料金や利用枠の具体的な数値には触れていません。
この記事のQ&A
コメント