ノートPCを閉じても会社が止まらない。Grok BotにClaude CodeとCodexを入れて、このコラムを書かせるまで

• Codex
• Claude
• AI
• 地方中小企業

こんにちは、株式会社カンマンの貝出です。

いきなりですが、今読んでいただいているこのコラム、私が書いていません。

正確に言うと、私が「書いて」と頼んだだけで、文章そのものはAIが書いています。しかも私のMacの中ではなく、クラウドのどこかで動いているコンピュータの上で。もっと言うと、そのコンピュータは、ついさっきまでClaude CodeもCodexも入っていなかった、まっさらな環境でした。

導入からだいたい20分後に、その同じ仕組みで、この原稿が生まれています。

……と書くと、なんだか近未来の話みたいに聞こえるかもしれません。でも実際にやってみると、びっくりするほど地味で、途中でけっこう失敗もしていて、「あ、こういうのは普通の会社でも全然できるな」という感触だったんですよね。

今日はその一部始終を、うまくいかなかったところも隠さずに書いていきます。中小企業の経営者さんや、Web担当の方に向けて、「AIに仕事を任せるって、具体的にはこういうことですよ」という一例として読んでもらえたら嬉しいです。

そもそもの悩み：Macがオフラインだと、会社がちょっと止まる

私はふだん、AIにけっこう仕事を任せています。カンマンのコラムを書いたり、定型の投稿を直したり、ちょっとした調べものをしたり。そういう作業を、OpenAIの「Codex」というツールや、AIの秘書ボットにやってもらっているんですね。

ただ、ここに一つ弱点がありました。

それらの多くが、私のMacの上で動いていたんです。

つまり、Macがスリープしたり、電源が落ちたり、ネットから切れたりすると、そこで作業がピタッと止まる。実際この日も、昼ごろにMacがオフラインになっていて、「あ、また止まってるな」と思っていました。

会社の仕事って、私がMacを開いている時間だけで回っているわけじゃないんですよね。夜でも、移動中でも、本当は少しずつ進んでいてほしい。でも道具がMacに紐づいていると、どうしても私の行動に引きずられてしまう。

ここをなんとかしたいな、とずっと思っていたわけです。

Grok Botって何なのか

そこで出てくるのが「Grok Bot」です。

ざっくり言うと、Grok Botは「名前と役割と文脈を持ち続けるAIの同僚」みたいなものです。公式の説明（cursor.com のドキュメントや x.ai の発表）によると、それぞれのBotは、ブラウザ・ファイル・ターミナルを備えた常時稼働のクラウドのコンピュータの上で作業します。

ここが大事なところで、ノートPCを閉じていても作業が続くんですね。こちらはメッセージで仕事を頼み、承認が必要なタイミングになったらBotのほうから戻ってくる。デモで手順を覚えさせてスキルとして保存したり、スケジュールで定期実行させたりもできる。ベータ公開は8月11日からでした。

私はこのGrok Botで、「秘書」をはじめ複数のAIボットを運用しています。この秘書ボットは、この日も裏でいろいろな連絡の転送や確認、申込の記録といった細かい作業を自動で回してくれていました。具体的に言うと、サーバーからの通知をしかるべき場所へ転送したり、新着のメッセージをチェックしたり、セミナー申込をスプレッドシートに記入したり。私が別のことをしている間にも、こういう細々した仕事が、黙々と片づいていくわけです。

もう一つ、Grok Botのいいところを挙げておくと、複数のボットが同じクラウドのコンピュータを共有できることです。ファイルも、ブラウザのログインも共有される。だから、秘書ボットがログインして整えた環境を、別のボットがそのまま使える。会社でいえば、同じオフィスの同じ机まわりを、複数のスタッフが共有しているようなイメージですね。今回Claude CodeとCodexを入れたのも、この「みんなで使える共有の机」の上でした。

で、ふと思ったわけです。

「このGrok Botのコンピュータって、常に起きてるんだよな。だったら、Macでやってた作業を、そっちに引っ越せばいいんじゃないか?」と。

「入れられない?」から10分後には動いていた

というわけで、16時33分に秘書ボットに聞いてみました。

「Grok botのコンピュータで、Claude CodeやCodexを動かせない?」

秘書が環境を確認したところ、Grok Botのコンピュータ（中身はLinuxでした）にはNode.jsのv20が入っていて、Claude CodeもCodexも、入れようと思えば入れられる状態でした。どちらもまだ未導入だっただけで。

「入れたいです」と返したら、npmでサッと導入してくれました。入ったのはCodex CLIの0.166.0と、Claude Codeの2.1.197。このインストール自体は、本当に数秒で終わっています。拍子抜けするくらいでした。

ここで一つ、経営者の方に伝えておきたいことがあります。

両方とも、サブスクリプションの範囲で動かしました。APIの従量課金（使った分だけお金がかかるやつ）はかかっていません。この「青天井にならない」という安心感、地味だけどすごく大事なんですよね。AIを会社に入れるときに、「気づいたら請求がとんでもないことに」というのが一番こわいので。

最後に、両方に「『OK』とだけ答えて」と指示して、ちゃんと反応するか動作確認をしました。16時41分ごろに完了。質問してから、だいたい10分です。

「サブスクで動かす」を、公式情報でも確かめておく

ここで、「サブスクの範囲で動かせる」という話を、もう少しだけ踏み込んで書いておきます。経営者の方が一番気にするのは、だいたいここだと思うので。

まずCodexのほうです。OpenAIの公式ドキュメント（learn.chatgpt.com）によると、Codex CLIはターミナルで動くコーディングエージェントで、サインインのやり方が二つあります。一つはChatGPTでサインインする方法。こちらは、契約しているサブスクリプションの範囲で使えます。もう一つはAPIキーを使う方法で、こちらは使った分だけ払う従量課金です。つまり、どちらの入り口から入るかで、料金の性格がまるっきり変わるんですね。今回私がやったのは前者、ChatGPTアカウントでのサインインのほうでした。

ちなみに、今回のように画面のない（手元でブラウザを開けない）環境では、公式はデバイスコード認証を推奨しています。表示されたURLを自分のブラウザで開いてサインインし、ワンタイムのコードを入力する、あの方式です。さっき出てきた「デバイスコード方式」というのは、まさにこれのこと。リモートのコンピュータに道具を入れるときの、定番のやり方だと思っておけばいいです。

次にClaude Codeのほう。こちらも公式ドキュメント（code.claude.com）を読むと、Claudeのサブスクリプションでログインして使えます。ただ、一つだけ気をつけたい落とし穴があって。ANTHROPIC_API_KEY という環境変数が設定されていると、Claude Codeはそのキー（＝APIの従量課金）のほうで動いてしまうんです。だから「サブスクの範囲で使いたい」なら、このキーは外しておく。ここを知らずに設定したままにしておくと、サブスクのつもりがいつの間にか従量課金、という事故が起きかねません。地味ですが、覚えておいて損のないポイントです。

もう一つ、Claude Codeは「スキル」「MCP」「フック」といった仕組みで、できることを足していけます。このあと出てくるスキルの引っ越しも、この拡張性があるからこそ効いてくる話なんですね。

正直に書く：ログインは一発ではうまくいかなかった

ここまで読むと「え、10分で全部スムーズにいったの?」と思われそうですが、そんなことはなくて。むしろログインのところで、けっこうつまずきました。

まずCodexのほう。こちらはChatGPTのアカウントで「デバイスコード方式」というログインをしました。画面のない環境向けの方法で、表示された短いコードを、私が自分のブラウザで入力する、という手順です。9文字のコードを入れる途中で、見慣れない画面が出てきて、「こんなのが出ましたけど……」とスクショを秘書に送ったら、ちゃんと説明してくれて、無事に完了しました。

問題はClaude Codeのほうです。

こちらはClaudeのTeamプランでログインするんですが、最初、うまくいきませんでした。

私は「普通にログインしました」と言ったんですね。でもそれ、ただClaudeのサービスにログインしただけで、Claude Codeを承認する手順ではなかったんです。だから認証コードを入れても、無効になってしまう。しばらく「あれ、なんで通らないんだろう」とお互い首をかしげていました。

最終的に秘書が「私の手順の案内が悪かったです」と謝ってくれて、ログインを一からやり直したら、今度は成功しました。

このとき良かったなと思ったのが、認証コードをチャットにそのまま貼らなかったことです。秘密の入力欄から渡す形にしてくれました。コードやトークンの類いって、うっかり会話に残すと危ないので、こういう「秘密は秘密の場所で扱う」という作法が自然にできているのは、安心材料でした。会社でAIを使うとなると、どうしても「情報の扱いは大丈夫なのか」が気になります。だからこそ、こういう小さな作法が、ちゃんと身についているかどうかは、見ておく価値があります。

ついでに、Grok Botを会社で使うなら知っておいたほうがいい注意も、公式ドキュメント（docs.x.ai の「Use the computer and apps」や「Approvals, security, and privacy」）から拾っておきます。

一つは、さっき「便利だ」と書いた「複数のBotが同じクラウドのコンピュータを共有する」という性質の、裏側の話です。ファイルもブラウザのログインも共有されるということは、裏を返すと、Botを分けても、それはセキュリティの境界にはならない、ということなんですね。「このBotにだけは見せたくない」ものがあったとして、Botを別に立てるだけでは守れない。ここは勘違いしやすいところなので、はっきり書いておきます。見せたくないものは、そもそもその共有の机に持ち込まない。これが基本です。

もう一つは、手元のMac（やWindows）と、クラウドのコンピュータは、あくまで別物だということ。そして、手元での実行は、既定で毎回承認を求める設計になっています。つまり、クラウド側でいろいろ自動で進むからといって、手元のパソコンまで無断で動かされるわけではない。この「手元は毎回ことわりを入れる」という前提は、安心材料でもあり、同時に「何もかもが全自動になるわけではない」という現実でもあります。私はむしろ、この一手間があるほうが、安心して任せられると思っています。

失敗の話をわざわざ書いているのは、「AI導入=全部スルッといく魔法」みたいに思ってほしくないからです。人間同士の引き継ぎだって、手順を間違えることはあるじゃないですか。それと同じで、AIとのやりとりも、ちょっとした行き違いはあります。大事なのは、つまずいたときに「どこでズレたか」をちゃんと言葉にして、やり直せることだと思っています。

Macに残すもの、Grokに移すもの。この線引きが肝

道具が入ったので、次に考えたのは「じゃあ、何をこっちに引っ越すの?」という話です。

私は秘書にこう聞きました。「Macのローカルフォルダと繋いでいるセッションは、移動できますか?」

答えは「そのままでは無理」でした。理由はシンプルで、Grok BotのコンピュータからはMacのフォルダが直接見えないし、これまでの会話の履歴はMac側に残っているからです。クラウドのコンピュータと、手元のMacは、あくまで別物なんですね。

その代わりに、秘書は現実的な方法を出してくれました。フォルダをコピーする、GitHubで共有する、これまでの経緯をまとめて渡す、といったやり方です。

そこで私が聞いたのが、この質問でした。

「私の使い方からして、何をGrokに移せばいいですか?」

ここの答えが、すごく腑に落ちたんです。整理するとこうでした。

Grokに移すものは、「Macがオフラインだと止まってしまう自動作業」。たとえばコラムの作成、定型投稿の修正、ちょっとした調べものなど。これらは、私がいなくても進んでいてほしい仕事です。

Macに残すものは、「Macの中のファイルや、MacのChromeのログインが必要なもの」。たとえばメルマガ配信ツールの操作や、PowerPointの資料づくりなど。これらはMacの環境とくっついているので、無理に引き剥がさないほうがいい。

この線引き、めちゃくちゃ大事だと思っていて。

AIに任せるかどうかを、「できる／できない」だけで考えると、つい全部移したくなります。でもそうじゃなくて、「止まると困るから常時動くほうに置くもの」と、「この環境じゃないと動かないからここに残すもの」で分ける。この視点を持つと、むやみに散らからないんですよね。

私は「それでいきましょう、許可します」と返しました。

スキル240個を引っ越す。ここでも失敗しています

次に気になったのが、スキルです。

私のMacには、AIに特定の作業をやらせるための「スキル」が、約240個もありました。コラムを書くもの、資料を作るもの、動画を扱うもの……気づいたらずいぶん溜まっていたんですね。

「このスキルも、Grokで使えますか?」と聞いたら、「使えます」と。じゃあ移しましょう、ということになりました。

ここでも、スパッとはいきませんでした。

まず、動画素材が入った大きなフォルダが3つあって、これが約950MBありました。さすがにこれを丸ごと運ぶのは重すぎるので、除外。残りをまとめて圧縮すると、最終的には約30MBにおさまりました。ただ、そこに行き着くまでが一苦労で。

最初にまとめたファイルが、なぜか約2GBになってしまって、一度やり直しました。原因はともかく、2GBと30MBって、ぜんぜん違うので、「あ、これはおかしい」と気づいて作り直し。

さらにもう一つ。Macの /tmp（一時ファイルを置く場所）からコピーしようとしたら、拒否されました。それでファイルをいったんホームフォルダに移してから運んだら、今度はうまくいった。

こういう「ちょっとした詰まり」って、実際にやると必ず出てくるんですよ。ブログに書くときはつい「スムーズに移行しました」と一行で済ませたくなるんですが、現場はいつもこんな感じです。2GBになってやり直して、/tmpで断られて、ホームに移して、やっと通る。

無事に運び終わったあと、Claude CodeとCodexの両方から、ちゃんとスキルが見えることを確認しました。

そして、スキルは時々アップデートするので、「定期的に同期してほしい」とお願いしました。毎日お昼の12時ごろに自動で同期する予定を作ってもらっています。Macがオフラインの日は、無理せずスキップする設定です。ここも「止まってもいいように、止まることを前提に組む」という考え方が効いています。

ここまでで、16時48分ごろ。導入からスキルの引っ越しまで、トータルでもそんなに時間はかかっていません。

そして、このコラム自体を書いてもらった

さあ、道具もスキルも揃いました。

私は最後にこう聞きました。「このスキルを使って、カンマンコラムを書けますか?」

すると、「kanman-blog-creator」というスキルが見つかりました。カンマンコラム用に、8000字以上で、けんすうさん風の文体で、スラッグやサムネイル、note版まで作る、というスキルです。

私は前々から、noteの下書きまでは自動でやってもらっていました。だから今回も、こうお願いしたんです。

「カンマンブログへの下書きも、自動でやってほしい。確認と公開は、私がします。」

ここで、この記事のテーマが決まりました。16時55分のことです。

「Grok BotにClaude CodeとCodexをインストールして、Grok Botに指示して、この記事を書いてもらった」

つまり、この記事は、導入から約20分後に、その導入したばかりの仕組みそのもので書かれている、というわけです。

流れを分解すると、こうなります。私が秘書ボット（Grok Bot）に指示を出す。秘書が、Grok Botのコンピュータ上のClaude Codeに執筆を頼む。そしてClaude Codeが、今まさにこの原稿を書いている。

自分で書いておいてなんですが、ちょっと不思議な感覚です。さっき自分の手で入れた道具が、20分後には自分の代わりに文章を書いている。入れたばかりの新人が、その日のうちに自分のことをレポートにまとめてくれた、みたいな感じでしょうか。

そして、この「書いてもらう」という体験が、思ったより自然だったのも発見でした。Claude Codeは、名前に「コード」とついているので、プログラムを書く専用の道具だと思われがちです。実際コーディングには強いんですが、公式の説明（code.claude.com のドキュメント）を読むと、「コマンドラインでできることは何でも手伝える」とあって、ドキュメント作成や調べものも守備範囲なんですね。動き方も、「文脈を集める → 行動する → 結果を確かめる」というループで、これは人が仕事を進めるときの段取りとほとんど同じです。だから、コラムの下書きみたいな文章仕事も、ちゃんとこなせる。今まさに、その実物を読んでいただいているわけです。

「AIが下書き、人が確認と公開」。この役割分担がすべて

ここまで読んで、「じゃあもう人間はいらないの?」と思った方がいるかもしれません。

いや、むしろ逆だと思っています。

私が大事にしているのは、役割をちゃんと分けることです。今回のやり方を整理すると、こうなっています。

この「確認と公開は人がやる」という最後の一線を、私は絶対に手放しません。

なぜかというと、文章って、会社の名前で世に出るものだからです。事実が合っているか、言い回しに失礼がないか、お客さんに誤解を与えないか。ここはやっぱり、人の目で見て、人の責任で出すべきだと思っています。

逆に言うと、「下書きまで」はどんどんAIに任せていい。白紙から書き始めるのって、人間にとって一番エネルギーがいる工程なんですよね。そこをAIが一気に進めてくれて、私は最後の確認と仕上げに集中する。この分担が、今のところ私にはいちばんしっくりきています。

カンマンは、企業のAI活用の支援をしています。その仕事をしていて私がよく考えるのは、「AIをどこまで信じて、どこで人が握るか」を自分たちで決めておくことが大事なんじゃないか、ということです。全部AIに丸投げでもなく、こわがって何も任せないのでもなく、その間にちょうどいい線を引く。今回の「AIが下書き、人が確認と公開」は、私なりのその一例です。

おもしろいのは、この線の引き方が、人の採用や育成とそっくりだということです。新しく人を迎えたとき、いきなり「何でも好きにやっていいよ」とは言わないですよね。まずは下書きや下準備を任せて、最後は自分が目を通す。慣れてきたら任せる範囲を広げる。AIもまったく同じで、今回私は「下書きまでは任せる、公開は握る」という範囲からスタートしました。この範囲は、信頼が積み上がれば、少しずつ広げていけばいい。最初から100点の運用を目指すより、こうやって「任せる範囲を育てていく」感覚のほうが、私には合っています。

中小企業の経営者さんへ：まず「何を移すか」から

長くなってきたので、今日の話を実務に落とすと、どうなるかを書いておきます。

もしあなたの会社でも「担当者のPCが開いていないと進まない作業」があるなら、一度こう問い直してみてほしいんです。

「この作業は、担当者がいなくても進んでいてほしいものか?」

もしYesなら、それは常時動く環境（今回のGrok Botのような、クラウドで起きっぱなしのコンピュータ）に置く候補です。コラムづくり、定型の投稿、調べもの。このあたりは、だいたい移せます。

逆に、「この端末のこのログインじゃないと動かない」ものは、無理に動かさない。メルマガツールの操作や、特定のソフトで作る資料。これらは手元に残したほうが、かえってトラブルが少ない。

この「移すもの／残すもの」の仕分けさえできれば、あとの導入は、今日見てきたとおり案外あっさりです。npmでツールを入れて、ログインして（ここでちょっとつまずいて）、スキルを運んで（ここでも一回やり直して）、動作確認する。それだけ。

そして忘れてはいけないのが、サブスクの範囲で動かすという前提と、確認と公開は人がやるという一線。この二つを握っておけば、コストも品質も、自分の手の中に残ります。

最後に、自社で試すときのチェックリストを、3つだけ置いておきます。

この3つを押さえておくだけでも、よくある事故はかなり防ぎやすくなると思います。あとは、実際に一つだけ小さな作業を移してみるのが、いちばんの近道です。頭で考えているより、やってみたほうが早いので。

おわりに

今日は、Grok BotにClaude CodeとCodexを入れて、そのままこのコラムを書いてもらうまでの話を、失敗ごと書いてみました。

ログインを一回やり直して、ファイルが2GBにふくらんで作り直して、/tmpから断られてホームに移して。そういう小さなつまずきの先に、「ノートPCを閉じても止まらない会社」が、ちょっとだけ近づきました。

派手な数字で「何時間短縮!」みたいなことは、今日はあえて書きません。実際、始めたばかりですし。でも、「Macがオフラインだと止まる」というずっと気になっていた弱点に、現実的な答えが一つ見つかった。その手応えは、確かにあります。

AIを会社に入れるのは、魔法を買うことじゃなくて、新しい同僚を一人迎えて、どの仕事を任せて、どこは自分が握るかを決めていく作業なんだと思います。

その同僚が、入社20分でこのコラムを書いてくれた、という話でした。最後に確認して公開するのは、もちろん私です。

それでは、また。

参考情報

• Grok Bot｜Cursor Docs
• Introducing Grok Bot（x.ai 公式発表）
• Use the computer and apps（docs.x.ai）
• Approvals, security, and privacy（docs.x.ai）
• Claude Code overview｜Claude Code Docs（Anthropic公式）
• How Claude Code works｜Claude Code Docs（Anthropic公式）
• Authentication｜learn.chatgpt.com（OpenAI公式。Codexのサインイン方法）
• Codex CLI｜learn.chatgpt.com（OpenAI公式）