Cline で作った Devin 風ワークフローを Microsoft Agent Framework で再構築する① - 準備編

前シリーズでは、VS Code + Cline を中心に、LangGraph、LiteLLM、Ollama などを組み合わせて “Devin 風” の開発エージェントループを自作しました。

実際に動かしてみることで、AI がコードを書き、テストし、再試行し、必要に応じてクラウド LLM へ切り替えるところまで構築できました。

ただし、その仕組みを安定して動かすためには、状態管理、Tool Calling、Retry、履歴保存、エスカレーションなど、多くの制御を自前で実装する必要がありました。

そこで今回からは、「Microsoft Agent Framework」を使用して、これまで自作してきたハーネスをどこまで簡潔かつ堅牢に再設計できるのかを検証していきます。

Microsoft Agent Framework は、Microsoft が提供する AI エージェント開発用のオープンソースフレームワークです。LLM を利用するエージェントの作成に加えて、ツールの呼び出し、会話状態やメモリの管理、複数のエージェントや処理を連携させるワークフローなどを構築できます。

また、Azure OpenAI や OpenAI だけでなく Ollama などのローカル LLM にも対応しており、クラウドサービスに依存しないエージェントシステムを構築することも可能です。

開発用の言語として、C#、Python、Go などが利用できますが、今回は C# を使用します。

今シリーズでは、これまで作成してきた

• Workflow
• Worker / Reviewer
• Retry
• Interrupt / Resume
• 監視ループ
• Tool Calling
• Healing
• 履歴保存
• ローカル / クラウドエスカレーション

といった機能を、Microsoft Agent Framework の機能へ一つずつ対応付けながら置き換えていく予定です。

また、前シリーズで使用していた PowerShell や独自 Dispatcher についても、可能な部分は C# 側へ移し、より型安全で保守しやすい構成を目指します。

最終的には、前シリーズの自作ハーネスと比較して、

「どこまでコード量を減らせるのか」
「どこまで信頼性を上げられるのか」
「独自実装として残すべき部分はどこなのか」

を確認していきます。

今回はその第 1 回として、まず Cline 版ハーネスの構成を整理し、Microsoft Agent Framework ではどの機能に置き換えられそうかを確認していきます。

※以降本記事内では、Microsoft Agent Framework を MAF と表記しています。

構成の確認と対応機能

Kanban (Cline) と MAF 機能の対応は以下のようになっています。

Workflow

前シリーズでは、LangGraph を使用して WORKER、REVIEWER、FIX_WORKER などの処理をノードとして定義し、それぞれの処理結果に応じて次に実行するノードを切り替えていました。

MAF でも同様に、複数の処理を順番に実行したり、条件によって処理を分岐させたりする場合には「Workflow」を使用できます。

C# では WorkflowBuilder を使用して Executor 同士を接続し、処理の流れをグラフとして定義します。MAF の Workflow は、Agent だけではなく通常の C# コードを実行する Executor も同じグラフ上に配置できるため、AI に判断させる処理と、決められたルールで実行する処理を分離できます。

前シリーズの

WORKER
  ↓
REVIEWER
  ├─ OK → DONE
  └─ NG → FIX_WORKER
             ↓
          REVIEWER

のような構成についても、MAF の Workflow 上で同様の流れを構築できそうです。

今シリーズでは LangGraph が担当していたワークフロー制御を、MAF Workflow へ置き換えていく予定です。

Worker / Reviewer

前シリーズでは、コードを作成・修正する WORKER と、その実装内容を確認する REVIEWER を、それぞれ別の LangGraph ノードとして実装していました。

MAF では、それぞれを役割の異なる AIAgent として定義できます。

例えば WORKER には

• 対象コードの調査
• コードの修正
• テストの実行
• 実行結果の報告

といった役割を持たせ、REVIEWER には

• 変更内容の確認
• 完了条件の確認
• テスト結果の確認
• 修正が必要かどうかの判定

といった役割を持たせます。

Workflow に AIAgent を追加すると、MAF 内部では Agent Executor として扱われ、メッセージの受け渡しや Agent のセッション管理、出力結果の引き渡しなどを Workflow エンジンが行います。

そのため

WORKER → REVIEWER

という前シリーズの構成は

WorkerAgent → ReviewerAgent

という形で比較的そのまま移行できそうです。

Retry

前シリーズでは、LLM が正常な Tool Call を返さなかった場合や、タスクが正常に完了しなかった場合に、同じモデルで再試行する Retry 処理を独自に実装していました。

MAF でも、Conditional Edge と Workflow State を組み合わせることで、Retry の分岐を Workflow の一部として構成できます。

例えば Reviewer が

FIX_REQUIRED

と判定した場合には、再度 Worker または FixWorker に処理を戻すような条件分岐を Workflow に定義できます。

また、API の一時的な失敗や例外などについては Middleware 側で Retry を行う構成も考えられます。MAF の Middleware は Agent の実行前後に処理を挿入でき、例外処理や一時的な失敗に対する再試行などにも利用できます。

今回の構成では

実装内容に問題がある
    → Workflow で Retry

通信エラーなど一時的な問題
    → Middleware で Retry

のように、Retry の理由によって処理場所を分けるのが良さそうです。

Interrupt / Resume

前シリーズでは、LangGraph の interrupt() を使用して Workflow の実行を一時停止し、Kanban 側でタスクが完了するまで待機していました。

タスク完了後は Command(resume=...) を使用して LangGraph の処理を再開していました。MAF では、Workflow の Request / Response 機能を使用することで、これに近い処理を実現できそうです。

Workflow 内の Executor から外部システムへ Request を発行すると、Workflow はその Response が返されるまで待機します。これは Human-in-the-loop 用途だけでなく、外部システムや非同期処理との連携にも使用できます。

そのため、Kanban を外部システムとして扱えば

MAF Workflow
    ↓
Kanban にタスク登録
    ↓
Request を発行して待機
    ↓
Kanban タスク完了
    ↓
Response
    ↓
Workflow 再開

という流れを構築できます。

さらに MAF の Checkpoint には Pending Request や Workflow の状態も保存できるため、長時間の待機処理や途中再開にも利用できます。

監視ループ

前シリーズでは、Kanban に登録したタスクの状態を PowerShell や Python の監視処理から定期的に確認していました。

例えば

BACKLOG
↓
IN_PROGRESS
↓
REVIEW
↓
DONE

といった状態変化を監視し、一定時間 IN_PROGRESS のまま変化しない場合には、処理が停止した可能性があると判断する仕組みも追加しました。

MAF 自体に Kanban のファイルを監視する機能が用意されているわけではないため、この部分については C# のサービスとして実装する予定です。

構成としては

FileSystemWatcher
    +
定期ポーリング
    ↓
Kanban の状態を確認
    ↓
完了条件を判定
    ↓
MAF Workflow に Response

という形式を想定しています。

FileSystemWatcher を使用すればファイル変更を即座に検知できますが、イベントの取りこぼしや連続発生も考慮する必要があります。そのため FileSystemWatcher のみには依存せず、定期的なポーリングも併用する予定です。

つまり、前シリーズの監視ループそのものは残りますが、PowerShell で行っていた処理を C# の非同期サービスへ置き換える形になります。

Tool Calling

前シリーズでは、LLM から PowerShell や Python の処理を直接呼び出すのではなく、独自の Dispatcher を経由して各種コマンドを実行していました。

例えば

LLM
↓
Tool Call
↓
Dispatcher
↓
PowerShell
↓
Kanban / Test / OS操作

という構成です。MAF では、C# のメソッドを Function Tool として Agent に公開できます。

そのため

• run-tests
• new-kanban-task
• get-task-list
• archive-task

といった操作を、それぞれ C# の型付き Tool として実装できます。

最終的には

LLM
↓
MAF Tool Calling
↓
C# Tool
↓
Kanban / Test / OS操作

という形に変更する予定です。

文字列ベースのコマンドを Dispatcher で解析するのではなく、Tool ごとに引数の型を明確にできるため、エラーの削減や保守性の向上も期待できます。

Healing

前シリーズでは、ローカル LLM が生成した Tool Call の形式が一部崩れるケースがありました。

例えば

{
  "commands": [
    {
      "command": "python ./kanban/python/dispatch/dispatcher.py --help"
    }
  ]
}

のような出力を

{
  "commands": [
    {
      "command": "python",
      "args": [
        "./kanban/python/dispatch/dispatcher.py",
        "--help"
      ]
    }
  ]
}

のように補正する Healing 処理を LiteLLM 側へ追加していました。

MAF では、このような横断的な補正処理を Middleware として実装する構成が取れます。

Middleware では Agent の入力・出力だけでなく、Function Calling や Chat Client の呼び出し部分にも処理を挿入できるため

Tool Call の検証
↓
形式異常の検出
↓
安全に修正可能なら Healing
↓
修正できない場合は Retry

といった処理を独立した機能として実装できます。

前シリーズでは LiteLLM の内部処理に修正を加えていましたが、MAF 版では自分のアプリケーション側に Middleware として保持できるため、より保守しやすい構成にできそうです。

履歴保存

前シリーズでは、実行したタスクごとに入力内容や出力結果、レビュー結果などを独自の履歴として保存していました。

この履歴は単なるログではなく

• 何を依頼したのか
• どのモデルを使用したのか
• どのような修正を行ったのか
• 何回 Retry したのか
• どのような Review 結果だったのか

といった情報を後から確認するためにも使用しています。

MAF には Agent の Session や Workflow Checkpoint があり、Agent の会話状態や Workflow の実行状態を保存・復元できます。

特に Checkpoint には Executor の状態、Pending Message、Pending Request / Response、Shared State なども保存されます。

ただし、Checkpoint はあくまで Workflow の再開に必要な状態を保存する仕組みであり、前シリーズのような「人間が後から確認しやすい実行履歴」とは目的が少し異なります。

そのため今回も

MAF Session / Checkpoint
    → Workflow 再開用

独自履歴
    → 調査・分析・再利用用

という二段構成にする予定です。

ローカル / クラウドエスカレーション

前シリーズでは、通常はローカル LLM を使用し、処理が一定回数失敗した場合にクラウド LLM へ切り替える仕組みを実装しました。

例えば

ローカル LLM
↓
失敗
↓
Retry
↓
一定回数失敗
↓
クラウド LLM

という流れです。

MAF には Runtime Model Routing の仕組みがあり、会話履歴をアプリケーション側で管理する構成では履歴を維持しながら、実行時に使用するモデルや推論プロバイダーを切り替える構成を作ることができます。

ただし

• 何回失敗したら切り替えるのか
• どの失敗を能力不足と判断するのか
• クラウドでも失敗した場合にどうするのか

といった判断ルールまで MAF が自動的に決めてくれるわけではありません。この部分は前シリーズと同様に、独自の Policy として残す必要があります。

今回も

形式エラー
    → Healing

一時的な失敗
    → Retry

能力不足・繰り返し失敗
    → Cloud Escalation

クラウドでも失敗
    → 停止または人間へ戻す

という考え方を基本にして、MAF の Workflow や Model Routing と組み合わせる予定です。

このように確認してみると、前シリーズで自前実装していた機能の多くは、Microsoft Agent Framework が提供する Workflow、Agent、Middleware、Checkpoint などへ置き換えられそうです。

一方で、Kanban の監視方法や Retry・Escalation の判定条件、Tool Call の Healing ルールなど、実際の運用方針に関わる部分については、MAF を使用した場合でも独自実装として残す必要があります。

つまり今回の再構築では、すべてを MAF に任せるのではなく、フレームワークが提供する共通機能は MAF に任せ、前シリーズで得られた運用上の知見だけを独自ロジックとして残していく形になりそうです。

次回からは実際に C# + Microsoft Agent Framework の開発環境を構築し、まずは簡単な Agent と Workflow を動かすところから進めていきます。