常時稼働のLinuxが付くAI Botの使いどころ:Claude Codeとの線引きで解説記事を書き直した

開発mdx-playground

常時稼働のLinuxが付くAI Botの使いどころ:Claude Codeとの線引きで解説記事を書き直した

月30ドルから始められる Super Grok のプランに、常時稼働の Linux マシンが丸ごと付いてくる。 Bot に Tailscale を入れさせれば SSH が通り、中は普通の Linux だから Claude Code も Codex も入る。 X で見かけたポストが言っているのはそこまでで、残りは読んだ側が想像するしかない。

スペックの話としては筋が通っている。 腑に落ちないのは、その1台を毎日何に使うのかのほうだった。 手元の PC でも Claude Code は動くし、Codex も動く。 それでも常時稼働のマシンをもう1台持つ理由があるとすれば、どこにあるのか。

まず Grok Bot がどのプランに含まれるかを Web と X の投稿から調べさせ、あわせて自分がいま契約しているプランを実測して突き合わせさせた。 追加課金なしで使えることが分かった。 20ドルの「Get Pro」を買い足す必要はない。 入口の疑問は消えたが、肝心の「何に使うのか」はそのまま残った。

サブエージェントを3本出した

用途を知るには、ポスト1本では足りない。 調査の口を3つに割って、サブエージェントを並列で派遣した。

  • 英語記事の調査
  • コミュニティの実践報告の調査
  • 公式ドキュメントの調査

結果は scratchpad に research-A-english.mdresearch-B-community.mdresearch-C-official.md として書き出させた。 3本が揃うまでのあいだに記事の骨子を組ませ、完了を待つための再開タイマーも仕込ませておいた。

余談だが、このタイマーは全部終わったあとに残りが発火して、同じ指示をもう一度投げてきた。 記事も図解も書き直しも済んだあとだったので、その場で止めた。

3本が揃ったところで、公開記事として grok-bot-usage-guide.md に本文を書かせ、svg-diagram で図解を3枚作らせた。 SVG の lint、Markdown の lint、禁止表現の grep を通し、Chrome で実際の描画も確認した。 ここまでは順調だと思っていた。

初稿の使用例に引っかかった

出来上がった第3章には、こんな報告が並んでいた。 10年分のカレンダー予定から、会った人物の Notion データベースを作らせた。

これは別に Claude Code でもできる。

数字が派手だから上位に来たのだろうが、やっていることは1回きりのバッチ処理だ。 API か MCP さえあれば、Claude Code でも Codex でも同じ結果にたどり着く。 その場で書き直しを指示した。

数え直させたら、第3章に並べた実践報告7件のうち5件が同じ性質だった。 半分以上は、常時稼働のマシンが要る理由になっていない。 このまま公開すれば、手元の道具でできる話を読者に長々と読ませることになる。

書き直しの軸をどこに置くか

軸として自分から2つ渡した。

1つは、その Bot ならではのやり方に絞ること。 もう1つは、クラウドで実行されるという性質を前に出すことだ。 PC の前にいなくても回ることが、多分いちばん大きい違いだと思った。

この2つで切ると、Claude Code で足りる仕事とそうでない仕事が分かれた。

観点Claude Code や Codex で足りるこのマシンでしか回らない
回数1回きり。人が起動する毎日か毎週、またはメール着信などで勝手に動く
入口API、MCP、リポジトリログイン済みの Web 画面。API が無いサービスも含む
場所手元の PC が起きている時間だけクラウド機。PC を閉じていても外出中でも動く
判断ターミナルの前で返すスマホで承認だけ返す
文脈セッションごとに作り直す名前付きの Bot が前回までを持ち越す

左に収まる仕事は、この製品を買う理由にならない。 記事に残す価値があるのは右側だけだった。

テストの題材を決めた

軸が決まったところで、自分で試す題材も決めた。 会計ソフトAのアカウントにログインさせて、明細が1件増えたら通知する。

右側の条件をそのままなぞっている。 決まった頻度で動き、ログイン済みの画面を見に行き、PC を閉じていても回り、変化があったときだけ知らせる。 同じことを Claude Code でやろうとすると、まず自分の PC が起きていなければ始まらない。

ただし、その場で1点確認が入った。 会計ソフトAはプロダクトが複数あるので、どれを見に行くかで可否が変わるという指摘だった。 言われてみれば画面も入口も違う。 そこは対応を作ってもらうことにして、記事の書き直しを先に進めた。

書き直しと描画確認まで終えて、http://localhost:3000/grok-bot-usage-guide で読める状態になった。

Codex を入れるプロンプトを用意した

もう1つ頼んだのは、そのマシンに Codex を入れる手順だ。 Tailscale で SSH が通るなら、中に入れて動かせるはずだった。 設定そのものを Bot にやらせたかったので、貼り付けるプロンプトを用意させた。

気にしたのは枠の消費だった。 無料枠の残りがもう多くないはずなので、Bot に探索させると本題に入る前に尽きる。 そこで Web 検索も試行錯誤も禁じ、実行するコマンドを全部プロンプトに埋め込み、失敗したらその場で止まって報告させる形にした。 Codex のログインだけは Bot にやらせない。 SSH が通ったあとに自分でやったほうが、枠を減らさずに済む。

プロンプトは手元にある。 まだ貼っていない。

学びメモ

  • 調査の初稿は、材料の派手さで並び替えられる。数字の大きい事例から選ぶと、その製品でなくてもできる話が上位に来る
  • 「これ、手元の道具でもできるのでは」は読者が最初に思うところだった。書き手が先に思っておけば、書き直しは1回で済む
  • 使い分けの軸は、機能で引いても切れなかった。マシンが置かれている場所で引いたら切れた
  • 無料枠のあるサービスを試すときは、探索の余地を残さない形で指示を書く。試行錯誤の分がそのまま枠から引かれる
  • サブエージェントを並列で出すときは、結果の置き場をファイル名まで決めておくと、待ち時間に骨子を組める

明日やること

  • 用意したプロンプトを Bot に貼り、SSH が通るところまで確認する
  • SSH が通ったら、Codex には自分でログインする
  • 明細の見張りは、会計ソフトAのどの製品のどの画面を見るかを1つに決める