🤖 AI

5分の手作業を自動化しようとして、クレジットを溶かした！

著者

📅 —

5分の手作業を自動化しようとして、クレジットを溶かした！

Antigravity（Roo Code）＋OpenRouter＋Claude/Geminiで、ブラウザ自動化タスクを作りました。

もともとは「手作業なら5分で終わる処理」を練習がてら自動化しただけなのに、デグレと「401 User not found」に振り回されてクレジットをかなり消費しました。

同じ構成でハマりそうな人向けに、一連のトラブルと対処をまとめておきます。

Roo Code と OpenRouter とは何か

Roo Code

Roo Code は、VS Code 上で動くオープンソースのAIコーディングアシスタントです。 regolo

単なる補完ツールではなく、

ファイルの生成・編集・リファクタ
ターミナルコマンドの実行
ブラウザを使った自動テストやE2E実行
Code / Ask / Architect など複数モードでのエージェント実行

といった「半自動ペアプロ」的なことができます。 regolo

内部のプロンプトやモード構成をJSONで書き換えられるので、ワークフローに合わせて細かくカスタマイズできるのも特徴です。 spin.atomicobject

OpenRouter

OpenRouter は、複数ベンダーのLLMを 1つのAPI でまとめて叩ける「統合ゲートウェイ兼マーケットプレイス」です。 playbooks

OpenAI / Anthropic / Google / Mistral など多数のモデルに単一のAPIキーでアクセスでき、モデル切り替えは model: "anthropic/claude-4.6-sonnet" のように名前を変えるだけです。 playbooks

課金とUsageトラッキングも1つのダッシュボードで管理でき、プロバイダをまたいだルーティングやフォールバック指定も可能です。 openrouter

Roo CodeはOpenRouterを公式対応プロバイダとしてサポートしており、OpenRouterのAPIキーを設定するだけで複数モデルを切り替えて利用できます。 openrouter

なぜ Roo Code＋OpenRouter を選んだか

最初から「Roo Code＋OpenRouterで課金する」つもりだったわけではありません。

環境制約と各モデルの挙動の結果、ここに行き着きました。

Google Play の国設定が香港で、香港では Gemini の有料版（AI Premium / AI Plus）が提供されておらず、公式ルートでの有料版利用ができない。これはGoogle側の提供地域リストからも読み取れます。 deepmind
無料アカウントのまま Claude を使うと利用上限が低く、実務で長時間回すには有料接続が前提になる設計です。 snowflake
代替として Gemini 3 Pro をAntigravityで回してみたものの、ブラウザ自動化タスクで安定させるのが難しい場面がありました（ここは自分の体験談）。
OpenRouterはRoo Codeと公式に統合されており、Roo側でOpenRouterをプロバイダとして選ぶことで、Claudeなど外部モデルを一括で叩けます。 docs.roocode

その結果として、

IDEは Antigravity（Roo Code）
モデル接続は OpenRouter 経由でClaudeほかに課金

という構成に落ち着き、その組み合わせ特有の挙動（401など）もまとめて踏むことになりました。

環境と前提

IDE: Antigravity（Roo Code）
モデル: Claude 4.6（途中から Gemini 3 Pro も併用）
経由: OpenRouter（プリペイド課金）
タスク内容:
ブラウザ起動 → ログイン
処理A/B/Cを順番に自動実行
人間なら5分で終わるレベルの定型作業

タイムラインで振り返り

1. 朝までは普通に動いていた

昨日：処理Aを完成。
今朝：処理Bを追加し、A＋Bが正常完走。
さらに処理Cを追加 → Cも正常動作。

ここまでは順調でした。

2. 処理C追加後にデグレ発生

Cは正常だが、Aでエラー発生。
修正して通したあと、今度はBでエラー。
デバッグ中にファイルが破損し、バックアップから復元。
復元後はBがエラーを吐くようになり、挙動が「元通りにならない」状態に。

この時点では「自分のリファクタで壊した」と考えて、コード側だけを追いかけていました。

3. OpenRouter課金後に「401 User not found」祭り

朝にOpenRouterへ課金した時点ではタスクが普通に回っていた。
残高が減ってきたので追加チャージ。
ここから突然、「OpenRouter completion error: 401 User not found」が連発し始めた。
Roo Codeの設定でAPIキーを「空 → 保存 → 再起動 → 再入力」しても状況は変わらず。

このあたりで「コードではなく、ツールか認証周りが壊れているのでは？」という疑いが濃くなりました。

OpenRouterの公式ドキュメントでも、401は認証情報やアカウント状態起因のエラーとして説明されています。 openrouter

4. Askモードで一度動かしたら401が解消

Roo Codeのモードを「Code」ではなく「Ask」に変更。
READMEや .md ファイルを読ませるなど、軽いプロンプトを投げたところ、ここでは正常に動作。
その後に Codeモード（Antigravityのタスク）を再実行すると、なぜか401が消えました。

ここから推測したのは：

一部の状態では、Roo CodeのOpenRouter設定が内部的に壊れていて、Askモードでリクエストを投げたタイミングで認証情報が再初期化されることがあるのではないか。

ということです（ここはあくまで推測）。

少なくとも、自分のケースでは課金やクレジット残高とは直接関係なさそうでした。

5. リファクタ後のデグレと格闘

401が落ち着いたあとも、リファクタの影響でA/B/Cに順番にエラーが出続けました。

動作ログなしパターン
Aでエラー → 修正 → Bでエラー → 修正。
動作ログありパターン
Aでエラー → 修正 → Bでエラー → 修正。

実際には、共通化した処理やログ周りのラッパーで条件分岐を壊しており、

「Aで見つかった不具合を直す → 別の分岐で同じ共通コードを踏んだBが落ちる」

というパターンを何度か繰り返していました。

このリファクタとデバッグはほぼ全部AI任せで、動作ログを出す処理を追加したことで、Roo側が自動的にログを読みながらデバッグを始めるようになったのはかなり便利でした。 spin.atomicobject

一方で、「どうデバッグするか」「どこまで踏み込んで原因を特定するか」はモデルによって差があり、上位モデルのほうが原因究明と再発防止まで踏み込んでくれる場面が多いと感じました。 snowflake

6. Ver.1として確定

最終的に、以下を確認・実施して「Ver.1」として確定させました。

すべてのテストケースで A/B/C が正常完走。
デバッグ用コードや臨時ログ出力を削除。
実行計画書（各ステップの処理内容）を最新状態に更新。
プロジェクト一式を「Ver.1」としてフルバックアップ。

OpenRouterの残高はだいぶ削れましたが、ツールのクセをかなり掴めたので、「これは授業料」と割り切ることにしました。

学びと対処パターン

1. 401系エラーにハマったときのチェックリスト

OpenRouterダッシュボードで、クレジット残高とUsageが正常に見えるか確認する（401でも一部ケースで課金が発生し得る旨がドキュメントで言及されています）。 openrouter
APIキーを手動でコピーし直し、「空 → 保存 → 再起動 → 再入力」を一度試す（Roo CodeのOpenRouter連携手順でも再設定が案内されています）。 docs.roocode
それでも直らない場合は、いきなり重いタスクを流さず、Ask/Chatモードで軽いプロンプトを1発投げて疎通確認する。
どうしてもダメなときは、「モデルや自分のコードではなく、ツール側のバグ」を疑って一度手を止める。Roo CodeのGitHub issueには、OpenRouter使用時のエラー報告がいくつか存在します。 docs.roocode

2. リファクタ中にデグレ地獄を避けるコツ

リファクタ前に、必ず「動いている版」を丸ごとバックアップ（今回でいう Ver.1）。
共通化やログ周りを触ったら、まず共通関数／ヘルパーに対して小さなテストを用意し、A/B/C それぞれの代表ケースを短い入力で再現できるテストに落とす。
本体の自動タスクを回す前に、「ログインだけ」「Aだけ」といった最小ルートの検証を必ず挟む。

こうして「共通部分が壊れていないか」を先に潰しておくと、A→B→Cと順番に地雷が出てくるパターンを減らせます。

3. クレジットの無駄撃ちを減らす運用

モデルを切り替えた直後や設定変更直後は、必ず「軽いプロンプト1発」で疎通確認する。
本番レベルの自動タスクは、そのあとにまとめて流す。
「どう考えてもツール側が怪しい挙動」を見たら、深追いせず、一度ログを整理してから休む。

OpenRouterは、エラー時にも条件によっては課金が発生し得るため、意味のない再試行を重ねると残高だけ削れていきます。 openrouter

4. バックアップの重要性

今回は、リファクタや大きめの修正を行うたびに、「ファイル単位のバックアップを作成せよ」とAIに指示する運用でしのぎました。

これでも「最悪ここまでは戻れる」という安全網にはなりますが、手動運用ゆえに抜け漏れや履歴の混乱が起きやすいのも事実です。

本来は、Gitなどのバージョン管理を使って、

自動コミットによる継続的なバックアップ
ブランチ単位での実験（A/B/Cの機能追加ごとにブランチを切る）
差分管理と履歴の可視化（どの変更で壊れたのかを追いやすくする）

を整えるのが理想です。

Roo Codeの活用例でも、Gitとの併用が推奨されています。 spin.atomicobject

5. 設計ドキュメントを常に更新してAIに読ませる

処理を追加するたびに、コーディング前にArchitectモードで実行計画書（フロー）やクラス関連図を更新しておくのはかなり効きました。 spin.atomicobject

Roo Codeは設計支援用モードを備えており、こうした情報をAIに読ませてからコーディングやデバッグを行うワークフローが想定されています。 regolo

デグレが起きたときに、まずその最新の計画書やクラス図をAIに読ませてからデバッグを始めると、

どのクラス／関数がどの処理A/B/Cに関わっているか
変更前後で「どの経路」が変わったのか

をAIが把握した状態で原因を絞り込めるため、無駄な当てずっぽう編集が減ります。

まとめ

手作業なら5分で終わる作業に、丸一日とそこそこのクレジットを使いました。

ただ、その過程で

Antigravity＋Roo Code＋OpenRouter＋各モデルのクセ
401「User not found」系エラーが、必ずしも課金や残高不足とは限らないこと
リファクタ時のデグレと、その抑え込み方
設計ドキュメントとバックアップをAI時代にどう回すか

を一通り体験できたので、本命プロジェクトに入る前の「有料練習」としては悪くなかったと思っています。

同じ組み合わせでハマっている人の参考になれば幸いです。

著者

だよん