- QodoはGPT-3時代からAIコーディング支援ツールを開発してきたチームで、最近ではより柔軟で動的なコーディングエージェントを作るためにLangGraphフレームワークを選択
- この文書は、LangGraphがどのように開発フローの柔軟性とコード品質基準を同時に満たせたのかを説明している
初期の構造的アプローチからLangGraphへの移行
- GPT-3ベースの初期には、テスト生成、コードレビュー、改善作業など、明確なフローを持つ構造的な作業が中心だった
- Claude Sonnet 3.5以降、LLMの性能が大きく向上し、より動的なエージェント設計が可能になった
- 従来は定型化されたワークフローしか実現できなかったが、新しいモデルを活用してユーザーのリクエストに柔軟に対応できるシステムを開発しようとした
- 迅速な実験と検証が可能なフレームワークを探す過程でLangGraphを選ぶことになり、初期の概念実証を超えて実際の製品まで拡張できた
柔軟性と明確なルールの共存
- LangGraphは状態機械（state machine）を基盤としたグラフ構造を提供する
- 各ノードはワークフローの個別ステップ（コンテキスト収集、計画、実行、検証など）を担当し、エッジはステップ間の遷移ルールを定義する
- エッジの密度に応じて、ワークフローの柔軟性または構造化の度合いが変わる
- 疎グラフ → 固定的で予測可能なフロー
- 密グラフ → 動的なフローと多様な経路選択が可能
- LangGraphの利点は、モデルの進化に合わせてワークフローの構造化の度合いを簡単に再調整できる点にある
- 主なフローは次のような構造になっている:
- コンテキスト収集 → 作業計画 → コード実行 → 結果検証 → 失敗時は反復
簡潔で直感的なインターフェース
- LangGraphは宣言的にワークフローを定義できるため、コードがほとんど文書のように読める
- 状態グラフを宣言し、ノードとエッジを追加する方式で動作する
- 条件付きフローも簡単に実装可能（例: 検証失敗時に実行ノードへループ）
- LangChainの複雑な抽象化とは異なり、LangGraphはロジックが見える構造になっており、開発者体験が良い
多様なワークフロー間での再利用性
- ノードベースの構造のおかげで、コンポーネントの再利用が容易
- 例: コンテキスト収集ノードと検証ノードはほとんどのフローで繰り返し使われる
- 新しい特化フロー（TDDなど）を作る際も、既存ノードを再接続することで素早く拡張できる
標準で提供される状態管理機能
- LangGraphは状態保存機能を標準で提供しており、永続性の実装が非常に簡単
- 例: Postgresによるチェックポイント機能は数行のコードで設定可能
- 収集したコンテキスト、計画、実行結果などの全体状態を保存でき、ブランチとロールバック機能もサポートする
- SQLite、インメモリなど他の方式にも簡単に置き換えられる
改善が必要な点
- 急速に発展しているフレームワークであるため、ドキュメントが不完全だったり更新が遅れたりすることがある
- 幸い、Slackを通じたメンテナーとのコミュニケーションは迅速かつ積極的だった
- 非決定的なLLMシステムのテストは依然として課題
- IDEと相互作用するエージェントの場合、自動化されたテスト環境の実装が難しい
- 一部のIDE機能はモック化が非常に難しく、手動テストに依存せざるを得なかったため、反復速度が遅くなった
- 成熟したフレームワークではテストおよびモック用インフラを提供していることが多く、LangGraphもその方向に発展していくことが期待される
まだコメントはありません。