Claude Codeでエラー調査を任せたらトークン上限が溶けたので、ローカルAI診断CLIを作った

はじめに

初投稿です！

普段から Claude Code や Cursor などの AI エージェントと一緒にコードを書いているのですが、ある日、本気でデスクに拳を叩きつけそうになる出来事がありました。

趣味で開発していたプロジェクトが「進捗8割」まで到達し、完成が見えてワクワクしていた頃です。

そこで原因不明のエラーに遭遇し、いつものように AI に修正をお願いしました。

AI は非常に優秀でした。

複数ファイルを読み込み、エラー箇所を探し出してくれるだけではなく、

「ここも将来的に脆弱性になる可能性があるので、一緒に修正しておきますね」

と提案までしてくれました。

「お、助かる！じゃあそこもお願いします！」

軽い気持ちで任せたことが、すべての始まりでした……。

---

芋づる式の崩壊と深夜の絶望

ひとつ直すと、別の場所が壊れる。

その修正をお願いすると、AI はまた大量のファイルを確認する。

そして新しい問題を発見し、さらに修正する。

まさに 「芋づる式」の負のループ でした。

気づけば、自分が最初に書いたコードよりも遥かに複雑になったコードが画面いっぱいに広がっていました。

8割完成していたはずのプロジェクトは、いつの間にか修正前より不安定な状態に。

さらに追い打ちをかけるように、

Quota Limit reached

の通知。

深夜、崩壊したコードを眺めながら、

「なぜこうなった……」

と思いつつ、静かにPCを閉じました（笑）。

---

でも、AIが悪いわけではなかった

冷静になって考えてみると、AIが悪かったわけではありません。

AIは与えられた情報から、一生懸命問題を解決しようとしていただけです。

問題だったのは、

整理されていない大量の情報を、そのままAIに渡していたこと

でした。

そこで考えました。

もし最初からAIに「問題の整理された情報」を渡せていたら？

本当に必要な部分だけを修正させることができたら？

あの負のループは防げたのではないか、と。

---

なぜAIエージェントは迷走することがあるのか？

AIエージェントは非常に強力です。

しかし、調査範囲や前提情報が整理されていない状態では、修正対象が広がりすぎてしまうことがあります。

自分はAIに、

「散らかった部屋から自力で探し物をしてください」

と言っているような状態でした。

生ログをそのまま渡す問題

例えばエラー調査では、

1. エラー原因が不明
2. AIが大量のファイル検索を行う
3. 検索結果やログが会話履歴に蓄積される
4. コンテキストが肥大化する
5. 前提情報が埋もれる
6. 関係ないコードまで修正対象になる

という流れが発生します。

つまり問題は、

AIの能力不足ではなく、AIに渡す情報の構造

でした。

---

作ったもの：DevForge

そこで作ったのが DevForge です。

コンセプトは、

AIエージェントに修正させる前に、AIが理解しやすい形へ整理する

というものです。

役割を分離しました。

役割分担

役割	担当
診断・レビュー	ローカルAI（Ollama）
修正・実装	Claude Code / Cursor など

まずローカルAIに、

• プロジェクト状態
• エラーログ
• ファイル構成
• ビルド状態

などを確認させます。

その結果を構造化JSONとして出力します。

そしてクラウドAIには、そのJSONだけを渡します。

---

DevForgeの内部構成

現在の構成は以下のようになっています。

DevForge
├── CLI
│   └── doctor command
├── Project Scanner
│   ├── file check
│   ├── build check
│   └── dependency check
├── Ollama Adapter
│   └── local LLM analysis
└── JSON Reporter
    └── Claude / Cursor input

---

devforge doctor の診断結果

例えば以下のようなJSONを生成します。

{
  "schema_version": "1.0",
  "workflow": "doctor_ai_diagnose",
  "status": "ISSUES_FOUND",
  "exit_code": 1,
  "summary": {
    "total_tools": 30,
    "healthy": 29,
    "unhealthy": 1
  },
  "issues": [
    {
      "check": "api-tester",
      "error": "BUILD_BUNDLE_MISSING",
      "expected": "dist/builds/api-tester-lite/index.html",
      "actual": "0 bytes"
    }
  ],
  "ai_analysis": "原因: ビルド成果物が未生成です。npm run buildを実行してください。",
  "next_action": "devforge doctor --auto"
}

このJSONをClaude Codeなどに渡すことで、「どこを調べればいいのか」から始める必要がなくなります。

---

役割分担で変わった3つのこと

1. 診断コストをローカル化できる

エラー解析や状態整理はローカルAIで行います。
そのため、

• API料金
• クラウドAIの利用上限
• トークン消費

を気にせず何度でも診断できます。

ちなみに今回使用しているモデルは、qwen2.5:1.5b です。
理由は単純で、自分のPCスペックとの兼ね合いです（笑）。

ただし、このモデルに巨大なコードベースを完全理解させることを目的にはしていません。
役割は、

• 状態整理
• エラー分類
• 原因候補生成
• 次の調査方向の提案

です。
より高性能なPCなら、7Bや14Bなどのモデルへ変更することで、さらに高度な分析も可能です。

2. クラウドAIが「探す時間」を減らせる

以前は、

「まずファイルを探す」
↓
「ログを読む」
↓
「原因を推測する」

という工程をクラウドAIが担当していました。

DevForgeでは、「原因候補を整理済み」の状態で渡せます。
そのためAIは、「探す」ではなく**「直す」ことに集中**できます。

3. 意図しない修正範囲を減らせる

診断結果には、

• 問題箇所
• 推奨対応
• 自動修正可能な範囲

を含めています。
これにより、AIが関係ない部分まで変更してしまうリスクを減らせます。

---

おわりに

今回、自分で作ったツールを公開するのは人生初の挑戦です。
まだまだ設計やコードなど改善すべき部分は多いですが、

「AIエージェントに大量の情報を渡して迷走する」

という自分自身が困っていた問題から生まれたツールです。

AI時代の開発では、「AIの性能」だけではなく、**「AIへ渡す情報をどう整理するか」**も重要になると思っています。

もし同じように、

• AIが調査中に迷走する
• トークン上限に到達する
• 修正範囲が広がりすぎる

という経験がある方は、ぜひ一度試していただけると嬉しいです。

最後まで読んでいただきありがとうございました！

• DevForge Pro: https://devforge-6si.pages.dev