はじめに

初投稿です！

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

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

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

AI は非常に優秀でした。

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

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

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

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

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

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

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

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

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

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

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

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

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

Quota Limit reached

の通知。

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

「なぜこうなった……」

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

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

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

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

問題だったのは、

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

でした。

そこで考えました。

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

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

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

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

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

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

自分はAIに、

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

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

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

例えばエラー調査では、

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

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

つまり問題は、

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