Grok Botとは｜常時稼働AIエージェントに渡す権限の決め方

「AIが勝手に仕事を進めてくれる」——2026年8月、xAIが発表したGrok Botのニュースを見て、期待と同じくらい不安を感じた方も多いはずです。

結論から言うと、Grok Botのような常時稼働AIエージェントを業務に入れるかどうかは、性能ではなく「何を渡すか」と「止まったときどちらに倒れるか」の2点で決まります。この2つを決めずに導入すると、動いている間は便利で、止まった日に事故が起きます。

株式会社Fyveは、常時稼働のAIエージェントを自社で1年以上動かし続けています。この記事では、Grok Botが何なのかを整理したうえで、私たちが実際に運用して決めた「渡す権限の線引き」を、失敗の実例つきでお伝えします。

Grok Botとは｜3行でわかる要点

Grok Botは、xAIが2026年8月11日にベータ版として発表したAIエージェント製品です。公式発表と複数の報道を突き合わせると、要点は次の3つに集約されます。

• 自分専用のコンピュータをクラウド側に持つ——ブラウザ・ファイル置き場・コマンド実行環境を1台分まるごと与えられる
• あなたの認証情報で、あなたが普段使っている道具にログインする——専用の連携機能がないサービスにも入っていける
• 承認が必要になったときだけ、あなたのところへ戻ってくる——それ以外は、あなたが寝ていても作業を進める

公式は「90%終わったのと100%終わったのとでは、大きな違いがある」という趣旨の説明をしています。従来のAIが「下書きを出すところまで」で止まっていたのに対し、Grok Botは成果物を実際の道具の中に着地させるところまでを担当する、という設計思想です。

これまでの「AIに聞く」と何が違うのか

違いは、AIが動く場所です。

チャット型のAIは、あなたの画面の中で完結します。あなたが質問を投げ、答えが返り、その答えをあなたがコピーして実際の道具に貼り付ける。最後の一手は必ず人間が持っていました。

Grok Botは、その最後の一手ごと引き取ります。クラウド上の専用マシンからブラウザを開き、あなたのIDでサービスにログインし、入力し、保存する。人間がやっていた操作をそのまま代行するため、APIや連携機能を持たない古いシステムにも入っていけるのが最大の特徴です。

これは強力ですが、裏を返せば「人間と同じ操作ができる＝人間と同じ壊し方ができる」ということでもあります。ここが、この記事の本題につながります。

チャット型AI・従来の自動化ツールとの位置関係

「結局それは、今までの自動化と何が違うのか」という疑問が出てくると思います。3つを並べると違いがはっきりします。

従来の自動化ツールは、事前に手順を作り込む必要がある代わりに、作った範囲の外には絶対に出ませんでした。窮屈さが、そのまま安全装置として働いていたわけです。

常時稼働エージェントは、その窮屈さを取り払うことで導入の手間を劇的に下げました。しかし同時に、安全装置も一緒に外れています。だから今度は、自分で境界を設計し直す必要がある——これが常時稼働型を業務に入れるときの核心です。

提供形態と料金（2026年8月時点）

単体で買えるプランはありません。ベータ提供のため、既存の上位プランの一部として配られています。そして少し変わっているのが、その配布経路です。

表を見て「なぜCursorが出てくるのか」と思われたかもしれません。Cursorは開発者向けエディタを出している別の会社の製品です。ところが今回、ダウンロードも決済もCursor側を通り、サインインもCursorアカウントで行います。すでにSuperGrok Heavyを契約している場合は、Grokアカウントを連携するとCursor Ultraが0ドルで作られ、そこからGrok Botに入る——という経路になっています。

ここは導入時に地味に効いてきます。請求先・アカウント管理・退職時の停止手続きが、想像していた先とは違う会社側にぶら下がるからです。誰の名義でどのアカウントを作るのかは、契約前に決めておいたほうがいい部分です。

対応環境はデスクトップ版とiOS。法人向けには順番待ちリストが用意されています。価格・対応OSは変動しやすく、報道値と公式値がずれることもあります。導入判断の直前には必ず公式ページで確認してください。ここに書いた数字は「桁感を掴むための目安」として読むのが安全です。

なぜ今、常時稼働エージェントが一斉に注目されているのか

2026年に入って、AIの競争軸が「賢さ」から「終わらせる力」に移りました。

要約や下書きの品質は、主要なモデルの間でほとんど差がつかなくなっています。差がつくのは、その先——書いた文章を実際に投稿するところ、まとめた数字を実際の表に入れるところ、承認をもらって次に進むところです。この「最後の10%」は地味で、しかも人間の時間を一番食う部分でした。

Grok Botが「常時稼働」を前面に出しているのは、この最後の10%があなたが席にいる時間に縛られていたからです。夜中に処理が終わっても、承認する人が寝ていれば朝まで止まる。エージェントに自分専用のマシンを与えるのは、その待ち時間をなくすための設計です。

ただし、待ち時間をなくすということは、人間が目視するタイミングもなくなるということです。便利さと危うさは同じ設計から出てきています。

ここが本題｜常時稼働エージェントに「何を渡すか」

Grok Botの説明で、私が最も注目したのは性能ではなく「あなたの認証情報でログインする」という一文でした。

これは、鍵を渡すという意味です。そして鍵には、必ず範囲があります。範囲を決めないまま渡すと、「できること」と「できてしまうこと」の区別がなくなります。

私たちが実際に渡した権限と、渡さなかった権限

私たちは、常時稼働の機械にコンテンツ管理システム（CMS）の操作を任せています。記事を書き、画像を作り、公開する——ここまでを人手を介さずに回す仕組みです。

その際に発行した鍵の範囲は、次のように決めました。

この表で本当に重要なのは、いちばん下の行です。

なぜ「消す権限」だけを外すのか——失敗の非対称性

AIに仕事を任せるとき、多くの人は「失敗する確率」を心配します。しかし実務で効くのは、確率ではなく失敗したときの戻しやすさです。

間違って新しいものを作ってしまったら、消せば元に戻ります。間違って上書きしてしまったら、前の版から復元できます。しかし間違って消してしまったものは、戻せないことがあります。同じ「1回の操作ミス」でも、被害の大きさが桁違いなのです。

だから私たちは、確率の低い操作を細かく禁止するのではなく、取り返しのつかない操作を1つだけ、鍵の段階で物理的に外しました。指示文で「消さないでください」と書くのではありません。鍵そのものに消す機能を持たせない。そうすれば、AIがどれだけ暴走しても、どれだけ巧妙な指示を外部から受け取っても、消すことは起きません。

指示文で書いた境界は破れます。鍵の範囲で作った境界は破れません。これが1年運用して得た、いちばん実用的な結論です。

「書き換え」だけは専用の道具を通す

5つの操作のうち、判断が難しかったのが「既存のものを書き換える」でした。

完全に禁止すると、公開済みの記事に後から関連リンクを足すといった、価値のある作業まで止まります。かといって素手で渡すと、既存の本文をまるごと書き換える事故が起こり得ます。しかも既存コンテンツの破損は、しばらく誰も気づきません。数週間後にアクセス数が落ちて、ようやく分かるのです。

そこで、書き換えは専用の道具を1つ作り、その道具経由でのみ許可しました。道具の中には次の4つの安全装置を仕込んであります。

• 追記した分を取り除いたとき、元の本文と1文字単位で一致するか検証する——一致しなければ処理を中止
• リンク先が実在するか確認する——存在しない場所へのリンクを作らせない
• すでに同じ追記があればスキップする——二重に足さない
• 書き込んだ後に読み戻して検証し、おかしければ自動で元に戻す

ポイントは、これらが人間のレビューを前提にしていないことです。夜中に無人で走る処理に「あとで人が確認する」を組み込むと、確認が滞った瞬間に安全装置が消えます。機械が自分で検証して、自分で元に戻せる形にして初めて、人がいない時間帯に任せられます。

AIツールの許可設定は「どこまで許したか」を読み違えやすいという問題も併せて押さえておくと、権限設計の精度が上がります。

「承認が必要なときだけ戻る」が壊れる日

Grok Botの設計で、業務利用の観点から最も重要なのは「承認が必要になったときだけ戻ってくる」という部分です。

これは裏返すと、承認の仕組みが、システム全体の最後の砦になっているということです。では、その砦自体が壊れたらどうなるのでしょうか。

実例｜審査役が9日間動かなかった話

私たちの記事公開の仕組みには、公開の直前に独立した審査役を置いています。記事を書いたAIとは別のプロセスで、まっさらな状態のAIを立ち上げ、「機密情報が混ざっていないか」「事実関係に矛盾がないか」「画像は要件を満たしているか」を検査させる。合格したものだけを公開し、不合格なら公開しない、という関門です。

2026年8月12日から8月20日までの9日間、この審査役が起動しませんでした。原因は品質の問題ではなく、認証情報の期限切れです。呼び出しても認証エラーで落ちる状態が続きました。

結果どうなったか。自動公開はゼロになりました。その間に書き上げた記事は、公開されずに下書きとして積み上がっていきました。

それでも事故が起きなかった理由

ここが設計の分かれ目です。私たちの仕組みは「審査結果が取れないときは、公開しない」という規則で作ってありました。合格でも不合格でもなく、判定できない状態も不合格として扱う——安全側に倒す設計です。

そのおかげで、9日間にわたって審査が完全に止まっていたにもかかわらず、未検査の記事が世に出た件数はゼロでした。積み上がった下書きは、8月20日に人間が内容を確認したうえで、まとめて公開されました。失われたのは公開の速度だけで、品質は一切損なわれていません。

もし逆の設計——「審査に失敗したらとりあえず公開する」——だったら、どうなっていたか。9日分の未検査記事が、誰にも見られないまま公開されていました。そして誰もそれに気づきません。エラー通知は出ず、記事は増え、表面上はうまく回っているように見えるからです。

常時稼働エージェントを検討するとき、多くの人は「うまく動いたら何ができるか」を見ます。しかし本当に確認すべきは、止まったときにどちらへ倒れるかです。動いている間の性能はデモを見れば分かりますが、止まり方は仕様書を読み込まないと分かりません。

常時稼働にして初めて出てくる「3つの維持コスト」

常時稼働エージェントの紹介記事は、たいてい「何ができるか」で終わります。しかし1年動かしてみて分かったのは、常時稼働にした瞬間に、それまで存在しなかった種類の手間が発生するということでした。

1. 認証の寿命という、誰も話題にしない問題

人間が使う道具は、認証が切れるとログイン画面が出ます。だから即座に気づき、その場で入り直して終わりです。

無人で動く仕組みには、この画面が出ません。認証が切れても、ただ処理が失敗するだけです。そして失敗したことを誰かに伝える仕組みを別途作っていなければ、何日でも切れたまま走り続けます。

先ほど紹介した審査役が9日間止まっていた件も、原因は認証の期限切れでした。さらに極端な例もあります。画像を作る処理の主経路が認証切れで落ちていたのですが、予備の経路が自動的に働いたため、画像自体は毎日作られ続けていました。その結果、主経路が落ちたまま37日間気づかれずに運用が続いたのです。

これは、よくできた予備経路がかえって発見を遅らせた例です。壊れているのに止まらない状態が、無人運用でいちばん厄介だという教訓として残しています。

対策はシンプルで、認証の有効期限を業務カレンダーに載せてしまうことです。切れてから気づくのをやめ、切れる前に更新する運用に変えます。

2. 依存している外部サービスが止まる日

常時稼働の仕組みは、たいてい複数の外部サービスを組み合わせて動いています。そのうち1つが提供終了になれば、当然そこで止まります。

問題は、普段動かない予備の経路ほど、棚卸しから漏れることです。毎日使っている道具の終了予告には気づきますが、年に数回しか動かない予備が終了していても気づきません。そして必要になった日に、初めて動かないと分かります。

3. 記録は増え続ける

常時稼働は、動いた分だけ記録を生みます。1日3回動く処理なら、月に90件分の記録が積み上がります。

これは放っておくと読まれない記録の山になります。記録を残すこと自体が目的化すると、異常が起きても埋もれて見つかりません。「毎回全部読む」のではなく、何が起きたときに通知が飛ぶのかを先に決めておくほうが実務的です。

導入前に決めておく5つのこと

Grok Botに限らず、常時稼働型のAIエージェントを業務に入れる前に、私が必ず確認している5点です。

1. 止まったとき、どちらに倒れるか

エージェントが判断できない状況、外部サービスが応答しない状況、認証が切れた状況。これらのときに処理を止めるのか、とりあえず進めるのかを確認します。設定で選べるなら、業務に関わる部分は必ず「止める」にします。

判断基準はシンプルです。止まって困る業務より、勝手に進んで困る業務のほうが、回復に時間がかかります。

2. 取り返しのつかない操作を渡していないか

削除・送信・支払い・公開——この4つは、実行された瞬間に外部へ影響が出ます。取り消しても「一度は出た」という事実は残ります。

これらは可能な限り、権限の段階で外すか、人間の承認を必須にするかのどちらかにします。「AIが賢いから間違えないだろう」で渡さないことです。賢さの問題ではなく、戻せるかどうかの問題だからです。

3. 何をしたか、後から読めるか

常時稼働の最大の弱点は、見ていない時間に何が起きたか分からないことです。実行の記録が残り、後から読める形になっているかを必ず確認します。

記録は「エラーが出たとき用」ではありません。何も問題が起きていないように見えるときにこそ効きます。処理が静かに何もしなくなっていた、という状態は、記録を見ないと絶対に発見できません。

無人運用のログをどう設計するかは、常時稼働を始める前に決めておくべき項目です。

4. 境界は「指示文」か「実行環境」か

ここが最も見落とされる点です。

「このフォルダ以外は触らないでください」と指示文に書くのは、境界ではありません。お願いです。AIは高い確率で従いますが、100%ではありません。そして外部から取り込んだ文章に別の指示が紛れ込んでいた場合、そちらに従ってしまうこともあります。

私たちは、無人で走る処理について書き込んでよい場所を1か所に限定し、そこ以外への変更は実行の仕組み側が自動的に破棄して通知する形にしました。AIが何を考えていようと、決められた場所の外には残らない。指示文の遵守率に賭けるのをやめた、ということです。

導入検討時には「この制限は、お願いですか、それとも仕組みですか」と質問してみてください。答えが曖昧なら、それはお願いです。

5. 止める手段が1つあるか

常時稼働は、裏を返せば「こちらが何もしなくても動き続ける」状態です。おかしいと気づいたときに、迷わず押せる停止手段が1つあるかを確認します。

複数の設定画面を辿らないと止められない仕組みは、実質的に止められません。異常に気づくのはたいてい移動中か夜間で、落ち着いて操作できる状況ではないからです。

より広い観点での上限設定については、無人運用で暴走を防ぐ上限設定にまとめています。

中小企業がGrok Botを検討するときの現実的な判断

ここまで慎重な話を続けてきましたが、私は常時稼働エージェントに対して否定的ではありません。むしろ、人手が足りない小さな組織ほど効くと考えています。

ただし、入れ方には順番があります。

いきなり全社に入れない、1業務から始める

常時稼働エージェントは「何でもできる」ように見えるため、導入の議論が「どの業務に使うか」ではなく「全社でどう使うか」に膨らみがちです。これが失敗のいちばん多いパターンです。

最初に選ぶべきは、次の3条件を満たす業務です。

• 結果が目に見える——うまくいったか失敗したかが、その日のうちに分かる
• 失敗しても戻せる——社外に何かが出ていく手前で止まる工程
• 今すでに誰かの時間を確実に食っている——「あったら便利」ではなく「毎週必ず発生している」

この3つを満たす業務でまず回し、記録を読み、止まり方を確認する。そのうえで2つ目に広げます。AIエージェントを組織図の形で運用する考え方は、2つ目以降に広げる段階で役に立ちます。

料金は「人件費」ではなく「実験費」で見る

月額200ドル前後という価格は、人を1人雇うことを考えれば安く見えます。しかしベータ版の段階で人件費と比較するのは危険です。仕様が変わることも、提供が止まることもあります。

実際、AIサービスの提供終了や仕様変更は珍しくありません。利用中のAIサービスが止まる日に備える棚卸しの手順は、常時稼働で業務を任せる前にこそ確認しておく価値があります。

判断としては、最初の3か月は実験費として扱い、人員配置を変えないのが安全です。効果が確認できてから、体制の話をします。

よくある質問

Q. Grok Botは日本語の業務でも使えますか

ベータ版の段階では、日本語環境での実務利用に関する公式な情報は限られています。日本語の読み書き自体は問題ないと考えられますが、日本国内のサービスへのログインや、日本語の業務システムでの操作精度は、実際に自社の環境で試すまで分かりません。小さな業務で確かめてから判断してください。

Q. 自分の認証情報を渡して大丈夫ですか

「大丈夫かどうか」ではなく「どの範囲の鍵を渡すか」で考えるのが実務的です。可能であれば、エージェント専用のアカウントを作り、必要最小限の権限だけを付けます。普段自分が使っているアカウントをそのまま渡すのは避けてください。

特に、削除・送金・外部送信の権限が付いたアカウントを渡すのは推奨しません。

Q. 承認を求められる場面は自分で決められますか

ベータ版時点では、どの操作が承認を必要とするかの詳細な仕様は公開されていません。ここは導入前に必ず確認すべき項目です。承認の条件を自分で設定できないなら、そのエージェントに渡してよい権限の範囲は自動的に狭くなります。

Q. 常時稼働だと料金が青天井になりませんか

現時点ではサブスクリプションに同梱される形のため、従量課金による青天井のリスクは低いと見られます。ただし上位プランへの同梱という形式上、使い始めてから上位プランへの移行が必要になる可能性はあります。

Q. 導入して失敗するとしたら、どこですか

私の経験では、失敗のほとんどはエージェントの性能不足ではなく、境界設計の不足から起きます。「どこまで任せたのか」を人間側が説明できない状態で運用を始めると、問題が起きたときに原因を特定できません。

まとめ｜性能ではなく、境界で決める

Grok Botは、AIが「下書きを出す道具」から「仕事を終わらせる同僚」へ移る流れを、はっきり示した製品です。2026年8月11日のベータ発表以降、この方向に他社が追随してくるのは確実だと考えています。

だからこそ、いま決めておくべきは製品の選定ではなく、自社の境界です。

• 取り返しのつかない操作は、鍵の段階で外す
• 止まったときは、進めるのではなく止める側に倒す
• 境界は指示文ではなく、仕組みで強制する
• 見ていない時間の記録を、後から読める形で残す
• 迷わず押せる停止手段を1つ用意する

この5つが決まっていれば、どの製品を選んでも大事故にはなりません。逆にこれが決まっていなければ、どれだけ優秀なエージェントを選んでも、止まった日に痛い目を見ます。

9日間審査が止まっても事故が起きなかったのは、私たちが優秀だったからではありません。止まったら止まる、と最初に決めておいただけです。決めるのに費用はかかりませんが、決めていないことに気づくのは、たいてい事故の後になります。

私たちは、中小企業のAI活用を月額でご支援しています。常時稼働エージェントをどの業務から入れるべきか、どこまで任せてよいかの線引きにお悩みでしたら、専属AI活用顧問サービスの内容をご覧ください。