この画面、ちょっとLINEっぽくないですか。
出典：Grok Bot公式サイトの公開デモ。UIの説明のため画面部分を引用。2026年10月15日取得。筆者の環境や実際の会話ではありません。
左に相手の名前とアイコンが並んでいて、右には会話の吹き出し。
下には、選んだBotへメッセージを送る入力欄があります。
普段のメッセージアプリに近い配置です。
「LINEっぽい」は、この見た目と会話の進め方の話です。LINE連携という意味ではありません。
仕事もこのくらい気軽に頼めたら、かなり楽そうです。
公式紹介でも、チームメイトにメッセージを送るように仕事を頼む使い方が説明されています。
ただ、AIをいくつも使うなら、入口の先も考えたい。
Dotsで調べた内容をClaudeやCodexへ渡すたびに、最初から説明し直すのは面倒です。
せっかく調べた根拠や決めた条件まで、毎回拾い直したくない。
そこで、Grok Botを最初に相談する場所にして、その先の担当分けと仕事の渡し方を考えてみます。
ここからは、人が内容を確認して引き継ぐ運用案です。製品間の自動連携は未検証で、会話や作業の例も説明用に作っています。
最初に話しかける相手を決めておく
たとえば、「一覧画面の絞り込みがおかしい。直したい」という相談。
最初から、どのAIに何を頼むかまで整理して入力するのは少し重い。
まずGrok Botに投げて、対象の画面と起きていることをそろえるところから始めたいです。
原因を知りたいだけなのか、修正まで進めたいのか。
そこが分かったら、必要な担当へ渡します。
| 担当 | 頼みたいこと | 返してほしいもの |
|---|---|---|
| Grok Bot | 最初の相談を受けて、依頼を整理する | 何を、どこまで進めるか |
| Dots | 関連情報を調べて、前提をそろえる | 根拠、分かったこと、未確認のこと |
| Claude / Codex | 許可された環境で実装し、確かめる | 差分、検証結果、残っていること |
| 人 | 方針を決めて、必要な承認をする | 採用する案と反映してよい範囲 |
この分け方は、今回の案です。
ClaudeとCodexのどちらに渡すかは、対象の環境や使えるツール、権限で決めます。
一人の担当で終わる修正なら、そのまま最後まで進めてもらえばよくて、毎回全員を通す必要はありません。
案件ごとに「続きはここ」をつくる
会話で頼めるのはいいけれど、後から「あの修正、今どうなった？」となるのは避けたい。
AIごとに会話を開いて、最後の返事を探すのも手間です。
仕事を整理する画面をつくるなら、案件の中にタスクを置き、そこから会話と成果物へ戻れる形にしたいです。
タスクの一覧には、これくらい見えていれば助かります。
一覧画面の絞り込みを修正
担当：Codex
いま：検証中
次：条件を変えたときの表示を確認する
自分がやること：いまはなし
最終確認：YYYY-MM-DD HH:mm
これは追加したい表示の案で、Grok Botの標準画面ではありません。
最初は別のタスク管理ツールやメモに置いてもよさそうです。
各AIとの会話に同じタスク名やIDを添え、結果を戻す場所を決めておきます。
同じ不具合の続きなら元のタスクへ、別の機能追加なら新しいタスクへ。
状態を確認できていないときは「確認待ち」にしておく。
これなら、しばらく離れてから戻ってきても、どこから再開するか分かります。
別のAIに渡すとき、もう一度全部説明したくない
引き継ぎでは、次の担当が着手するのに必要なことをまとめます。
さっきの絞り込み修正なら、こんなメモです。
やりたいこと：条件を変えると一覧の表示も変わるようにする
対象：画面名と作業環境を記載
分かっていること：再現手順、関連箇所、根拠を添付
まだ分からないこと：該当データが0件の場合の表示
やってよいこと：対象箇所の修正と、作業環境内での検証
終わりの条件：元の不具合、条件解除、0件の場合を確認する
返してほしいもの：差分、試した操作と結果、残る懸念
今回はここまで：公開、外部送信、マージ、本番反映は含めない
特に「まだ分からないこと」を渡しておきたいです。
ここが抜けると、次の担当が調査済みだと思って進めてしまうかもしれません。
前の担当が読めた資料を次の担当も読めるか確認し、渡せない資料があれば、それも書いておきます。
作業が終わったら、差分と結果を元のタスクへ戻す。
次に続きを頼むときは、そこから始められます。
「直しました！」のあとに知りたいこと
返事が「直しました！」だけだと、ファイルを直したのか、画面で動いたのか、本番まで変わったのかが分かりません。
ここは短くても、分けて返してほしいところです。
たとえば、承認前にはこんな報告があると判断しやすい。
修正案を用意しました。差分はこちらです。
検証環境で、絞り込みの変更、条件解除、0件の場合を確認しました。
本番はまだ変更していません。
この差分を、指定した本番環境に反映してよいですか。
差分と検証結果へのリンクに加えて、影響する範囲と戻し方も見られるようにします。
「何か実行していい？」とだけ聞かれるより、判断する材料がそろっています。
反対に、すでに頼んだ範囲の調査や検証で毎回止まられるのも困ります。
承認した範囲はそのまま進めて、対象や操作が増えるところで確認してもらう形です。
結果の報告も、実際に確かめたところまで。
型チェックだけなら、画面操作はまだ未確認です。
接続が切れて反映できたか分からないなら、反映先を確認してから次へ進む。
同じ操作をもう一度実行して、二重に反映してしまうのは避けたいです。
毎日の学びは、聞き直されたことから拾う
一日の終わりには、「今日、何を説明し直したっけ」を振り返りたいです。
立派な日報を増やすより、次の依頼が少し楽になることを残したい。
たとえば、引き継いだあとに「どの環境で直しますか」と聞かれたなら、次から環境名を入れて渡す。
翌日、それで聞き直しが減ったか確かめる。
起きたこと、次に変えること、その結果があれば十分です。
Dotsには、その材料を整理する役を任せたいです。
人が改善案を選び、同じ種類の仕事で試す。
一度つまずくたびにルールを増やすと、依頼文を書くのが面倒になってしまうので、役に立ったものを残していきます。
まず試すなら、一つの案件で一つの修正を頼むくらいから。
短く相談して、担当に渡して、必要なところで確認し、結果を見る。
その途中で説明し直したところを、次の依頼で直していく。
Grok Botの会話UIを見て、仕事を頼む最初の一言も、このくらい気軽にできたらいいなと思いました。
「続きはどこだっけ」と探す手間まで減らせたら、日々の仕事で開きたくなる入口になりそうです。