Claude Codeの枠を逃がすためGrokを試した。ルーチンは移せなかったが、契約はした

Claude Code の使用量を減らすために、決まった時刻に自動で走らせている処理（以下「ルーチン」）の一部を Grok に移せないか試しました。結論から書くと、ルーチンの移行はできませんでした。ただし、移せる処理もあったので契約はしています。

この記事は前回の続きです。 前回：Claude Codeの使用量が足りない。実測したら犯人はCLAUDE.mdだった関連：Claude Fable 5.1が出た。週間制限がリセットされた日に、何が変わったのか調べた

なぜ外に出そうとしたのか

前回の記事で、CLAUDE.md（Claude Codeがプロジェクトごとに自動で読み込む指示書ファイル）を減量して、1日に必ず消費されるぶんを約62%削減しました。それでも余裕があるわけではありません。9月14日から標準の週間上限が25%引き上げになりますが、いま適用されている50%増量と比べると 1.25 ÷ 1.50 ＝約0.83 で、実質はおよそ17%減ります。

そこで考えたのが、全部を Claude Code に背負わせるのをやめることです。ひとつのサービスに全部載せていると、枠が尽きた時点で全部止まります。

外に出す候補にしたのが、調べものと収集の処理でした。

実際に1本、移して動かしてみた

試したのは、回している処理のうちいちばん軽い1本です。外部のAPIを使わず、1日1〜2回しか動かないものを選びました。いきなり重い処理を移して壊すと、復旧のほうが面倒になります。

安全のため、データベースへの書き込みはさせていません。「読み取る → 判定する → 結果を出力する」ところまでに絞りました。

判定の精度は問題なかった

先に良かった点を書きます。判定はきちんとできました。 試した件数はすべて正解で、精度は想定以上でした。

この処理は、以前に「軽いモデルでは誤判定が多すぎて任せられない」と判断して、上位のモデルに回していたものです。それを Grok がこなせていました。能力の問題ではありませんでした。

噛み合わなかったのは、機能の分かれ方

詰まったのは別のところです。必要な2つの機能が、別々の場所に分かれていました。

決まった時刻に動かす「自動化」からは、データベースに問い合わせができない
データベースを操作できる Grok Build は、セッションが7日で切れる

ここで名前の整理をしておきます。Grok 側には似た名前のものが2つあって、別物です。

名前	どういうものか
Grok Build	Claude Code に近い道具。対話しながら作業を進める
Grok Bot	クラウド上の仮想的なパソコンで動くエージェント

そして Grok Build を起動できるのは Grok Bot のほうです。決まった時刻に動かす自動化からは、おそらく起動できません。つまり「自動化 → Grok Build」と直接つなぐ形は取れません。

Grok Bot を挟めば形にはなります。ただ、それでも7日の問題は残ります。噛ませる部品が増えるほど壊れる箇所も増えるので、この案は見送りました。

なお、切れるのは動かし続けるための状態のほうで、作った内容そのものが消えるわけではありません。プロジェクトのフォルダで作業していれば、書いたものはファイルとして残ります。

ひとつ断っておくと、上の2つはどちらも Grok に聞いて言われたことで、自分で動かして確かめたわけではありません。 7日のほうは「毎日回すなら『残す』設定が必要」とも言われたので、詰めれば回避できるのかもしれません。

それでも本番に載せる判断はできませんでした。気づかないうちに止まって、サイトの更新が静かに止まるのが、一番困る壊れ方だからです。切れるかもしれない仕組みの上には置けません。

移せる処理と、移せない処理があった

ルーチンの移行は見送りましたが、契約はしています。同じ自動化でも、移せるものと移せないものがあったからです。

分かれ目は、データベースを触るかどうかでした。

	移せるか
データベースを読み書きする処理	自動化からは問い合わせができないので、移せない
データベースを触らない処理	自動化だけで完結するので、移せる

後者にあたるのが、日々の出来事やニュースを追いかける処理です。あるサイトで毎日回しています。追う対象が多いので、手作業では現実的ではありません。ここは X を直接検索できるかどうかが、そのまま効きます。

X の公式API経由でも取れます。ただし料金は従量制で、投稿の読み取りは1件あたり $0.005 です（X API の料金ページ）。

追っている先は90アカウントほど。リポストも含めると、1アカウントあたり1日20件くらいにはなりそうです。掛けるとこうなります。

90アカウント × 20件 × 30日 = 月 54,000件
54,000件 × $0.005          = 月 $270（1ドル150円で約4万円）

1日あたりの投稿数は実際に数えたわけではなく、見た感じの見積もりです。それでも SuperGrok の ¥5,000/月とは桁が違います。 ここは API を使う話になりません。

もうひとつ分かったのが、同じ「Grok」でも、どこから使うかで機能が違うことです。開発用のエディタである Cursor にも Grok が統合されているので、そちらでも X 検索ができるのではないかと考えました。Cursor のチャットで聞いたところ、X の直接検索が使えるのは SuperGrok のほうだと回答されました。確かめたのは Cursor 経由の場合だけです。

解約しようとしたら、引き止められた

ここまでの検証は、1週間の無料トライアルで試していました。判定はできる、でも常時動かす仕組みには載らない。この状態で月 ¥5,000 を払い続けるのは違うと考えて、トライアルのうちに解約するつもりでした。月 ¥5,000 は、いまの収入では気軽に出せる額ではありません。

それで解約しようとしたところ、こういうオファーが出ました。

3か月で ¥5,000（通常は ¥5,000/月なので、3か月なら ¥15,000）

よくある話です。 解約画面で引き止めのオファーを出すのは、サブスクリプションでは珍しくありません。よくあると分かっていて、それでも契約しました。

言い訳をすると、判断が変わったのは中身ではなく値段のほうです。「微妙」と思ったのは ¥5,000/月に対してで、3か月 ¥5,000（月あたり約 ¥1,667）なら別の話になります。値段が変われば結論が変わるのは、おかしなことではないと考えました。

ただし注意点があります。3か月が終わると、自動で ¥5,000/月に切り替わります。 App Store の表示は「2026年12月7日以降」でした。ここを忘れると割引分は次の2か月で消えるので、カレンダーに解約判断の予定を入れました。

まとめ

判定そのものは問題なくできました。 移せなかったのは能力の問題ではありません
Grok では、分かれ目はデータベースを触るかどうかでした。 触らない処理は自動化だけで完結するので移せます
必要な2つの機能が別々に分かれていました。 決まった時刻に動かす自動化からはデータベースに問い合わせできず、データベースを操作できる Grok Build はセッションが7日で切れます
7日の件は Grok 自身の説明が根拠で、まだ確かめていません。 「残す」設定で回避できる可能性は残っています
同じ Grok でも、どこから使うかで機能が違います。 Cursor 経由では X の直接検索が使えないと回答されました
引き止めオファーは、よくあると分かっていても効きます。 ただし値段が変われば判断が変わるのは当たり前なので、そこは受け入れました
3か月後の自動更新に備えて、カレンダーに解約判断の予定を入れました

ルーチンの移行は見送りです。ただ、どこで噛み合わないかが具体的に分かったのは収穫でした。前回の記事で「他社に全部移しても、単一障害点（そこが止まると全部止まる箇所）が移動するだけ」と書きましたが、少なくとも Grok では、移せない部分があると分かったからです。

ここで書いたのは、あくまで Grok を試した結果です。定期実行の仕組みはサービスごとに違うので、別のサービスなら同じ形で組めるかもしれません。どこで切れるかは、結局そのサービスを触ってみないと分かりません。