自律型エージェント開発の現状と「抽象化の罠」
近年、大規模言語モデル（LLM）を活用した自律型エージェントの開発が急速に進展しています。「自律的」であるということは、AIが自ら思考し、行動を選択し、結果を観察して次の行動を決定するということです。このプロセスは業務プロセス改善において非常に魅力的ですが、同時に大きな責任を伴います。
開発現場において、LangChainのAgentExecutorは、その手軽さゆえに多くのプロジェクトで採用されてきました。数行のコードで「ReAct（Reasoning and Acting）」パターンを実装でき、エージェントが動き出す体験は、初期のPoC（概念実証）において強力な武器となります。
しかし、システム導入支援やAI倫理の観点から、この高度に抽象化されたフレームワークがもたらす「透明性の欠如」と「制御の困難さ」、そして見過ごされがちな「セキュリティリスク」には注意が必要です。
AgentExecutorがもたらした開発革命と副作用
AgentExecutorは、複雑なプロンプトエンジニアリングやAPI呼び出しのループ処理を隠蔽（カプセル化）することで、開発の敷居を劇的に下げました。これは「開発の民主化」という観点では素晴らしい貢献です。
一方で、この抽象化は深刻な副作用も生んでいます。実務の現場では、開発者が「中で何が起きているか」を正確に把握できないままシステムを稼働させてしまうケースが散見されます。エージェントが意図しないツールを呼び出したり、無限ループに陥ったりした際、その原因が隠蔽されたプロンプトにあるのか、モデルの推論能力にあるのか、それともパーサー（出力解析機）のエラーなのか、即座に判別することが困難なのです。
さらに重大なのはセキュリティの観点です。最近の報告（CVE-2025-68664等）でも指摘されている通り、抽象化されたロード処理やシリアライズ機構には、インジェクション攻撃のリスクが潜んでいる場合があります。フレームワークの内部実装に依存しすぎることは、こうした脆弱性が発見された際に、迅速な対応を難しくする要因ともなり得ます。
ブラックボックス化する推論プロセスと依存関係のリスク
AI倫理やデータガバナンスの観点から最も懸念すべきは、意思決定プロセスのブラックボックス化です。
企業のコンプライアンスが求められる本番環境において、「なぜAIがその回答をしたのか」「なぜそのツールを使用したのか」を説明できないシステムは、重大なリスク要因となります。
また、AI開発のエコシステムは極めて変化が速いのが特徴です。例えば、LangChainにおけるlangchain-coreとlangchain-communityの分割や、Google GenAI SDKへの移行に伴うVertex AI SDKの非推奨化など、依存ライブラリの構造変更が頻繁に発生します。高度に抽象化されたクラス（AgentExecutorなど）に依存していると、こうした下位レイヤーの変更や廃止の影響を予期せぬ形で受け、昨日まで動いていたシステムが突然機能しなくなる、といった不安定さを招く恐れがあります。
本記事の比較対象：AgentExecutor vs LangGraph vs Raw API
本記事では、制御可能で信頼性の高いAIエージェントを構築し、ビジネス上の成果を出すために、以下の3つのアプローチを比較検討します。
- AgentExecutor: 従来のLangChain標準の高レベルAPI（手軽だがブラックボックス性が高い）。
- LangGraph: LangChain社が新たに提唱する、グラフ理論に基づいたステートフルなオーケストレーションライブラリ（制御性と可観測性を重視）。
- Raw API（素の実装）: フレームワークに依存せず、OpenAI SDKやGoogle GenAI SDKなどを直接利用してループや条件分岐を記述する手法。
これらを「開発速度」「制御性」「可観測性（Observability）」「拡張性」の観点から分析し、プロジェクトにおいてどの技術を選択すべきかの指針を提示します。単なるツールの良し悪しではなく、「責任あるAI」を実装するためのアーキテクチャ選定という視点で論じていきます。
参考リンク
アーキテクチャ比較：3つのアプローチの構造的違い
エージェントの基本動作は、「思考（Thought）→ 行動（Action）→ 観察（Observation）」のループです。このループをどのように管理・実装しているかが、3つのアプローチの決定的な違いとなります。
AgentExecutor：定型的なReActループの自動化
AgentExecutorのアプローチは、「決定論的でないプロセスを、決定論的なコードで無理やり枠にはめる」試みと言えます。
内部的には while ループが回っており、LLMからの出力を特定の正規表現やJSONパーサーで解析し、"Action:" というキーワードが見つかればツールを実行し、その結果をプロンプトに追加して再度LLMに投げます。
この仕組みは、LangChainが用意した「標準的なReActプロンプト」に強く依存しています。もし、標準とは異なる思考プロセス（例えば、ツールを使う前に一度ユーザーに確認する、あるいは複数のツールを並列で使うなど）を実装しようとすると、AgentExecutorのクラスを継承してメソッドをオーバーライドするなど、ハッキング的な実装が必要となり、コードの複雑性が急増します。
LangGraph：グラフ理論に基づくステート管理と循環フロー
LangGraphは、エージェントの挙動を「ノード（処理）」と「エッジ（遷移）」からなるグラフとして定義します。
最大の特徴は、State（状態）の明示的な管理です。AgentExecutorが隠蔽していた「会話履歴」や「ツールの実行結果」といったコンテキスト情報を、開発者が定義したスキーマ（State）として管理します。ノード間のデータの受け渡しが透明化され、どこで何が更新されたかが明確になります。
また、LangGraphは「循環（Cycle）」を許容するグラフ構造を持つため、ループ処理を自然に表現できます。条件付きエッジ（Conditional Edge）を使えば、「ツールの結果がエラーなら修正ノードへ、成功なら回答ノードへ」といった複雑な分岐ロジックも、視覚的に分かりやすいコードで記述可能です。
これは、AI倫理で求められる「説明可能性」の向上に直結します。どのステートでどのような判断が行われたかを追跡できるからです。
Raw API：完全な自由度と実装コストのトレードオフ
Raw API（素の実装）は、openai ライブラリなどのSDKを直接呼び出し、Pythonの標準的な制御構文（for, while, if）でロジックを記述する方法です。
このアプローチの最大の利点は、「何もしないことの自由」です。不要なシステムプロンプトや、ライブラリ特有の抽象化レイヤーが一切存在しません。LLMに送られるプロンプトは、記述した文字列そのものです。
しかし、これには代償が伴います。会話履歴の管理（メモリ）、ツール呼び出しの結果のパース、エラーハンドリング、リトライ処理などをすべて自前で実装する必要があります。特に、LLMの出力形式が崩れた際のリカバリー処理などは、地味ながら工数のかかる部分です。
機能・性能比較：実運用に耐えうるのはどれか
PoCから本番運用へ移行する際、最も重要になるのは「安定性」と「コスト」、そして「安全性」です。これらを比較してみましょう。
【制御性】ループ回数制限とエラーハンドリング
自律型エージェントの最大のリスクは「無限ループ」による暴走です。LLMが同じ行動を繰り返し続け、API利用料が高額になる事故は後を絶ちません。
- AgentExecutor:
max_iterationsパラメータでループ回数を制限できますが、制限に達した際の挙動（エラーで止まるか、そこまでの結果を返すか）の制御は大雑把です。 - LangGraph: グラフのステップ数制限機能（
recursion_limit）があり、より細かく制御可能です。さらに重要なのは、「Human-in-the-loop（人間による承認）」の実装容易性です。ツール実行前に一時停止し、人間の承認を得てから再開する、あるいは人間がステートを修正してから再開するといったワークフローが、アーキテクチャレベルでサポートされています。 - Raw API: 全てをコードで記述するため、どのような制限も実装可能です。しかし、エッジケース（例外的な挙動）への対応漏れが起きやすく、開発者のスキルに依存します。
倫理的な観点からは、人間が介入できる余地を残すHuman-in-the-loopの実装が容易なLangGraphが優位と言えます。
【可観測性】LangSmithでのトレース容易性
システムが「なぜ間違えたか」を追跡する能力（可観測性）は不可欠です。
- AgentExecutor: LangSmithと連携すればトレースは可能ですが、内部処理が1つの大きな「AgentExecutor」ブロックとして記録されがちで、詳細なステップごとの解析が難しい場合があります。
- LangGraph: 各ノードが独立した処理単位としてトレースされるため、どのノードでステートがどう変化したかが非常にクリアに可視化されます。データ分析の観点からも、デバッグの解像度が段違いです。
- Raw API: 独自のロギング機構を実装する必要があります。LangSmith等のSDKを手動で埋め込むことも可能ですが、手間がかかります。
【コスト効率】トークン消費量の比較検証
- AgentExecutor: 汎用性を高めるために、非常に長く複雑なシステムプロンプト（ReAct用の指示書）が自動的に挿入されます。これはAPI呼び出しのたびに送信されるため、トークンコストを圧迫します。
- LangGraph: 必要なプロンプトのみを制御できるため、最適化の余地があります。ただし、ステート管理のために全履歴を持ち回る設計にする場合は注意が必要です。
- Raw API: 最も軽量です。必要なトークンのみを送信できるため、コスト最適化を極限まで追求できます。
実装コード対比：同じタスクを実装して見えた「複雑性」の壁
ここでは、「Web検索を行い、その結果を要約してユーザーに返す」というシンプルなタスクを例に、コードの複雑性と保守性を比較します。
シンプルな検索エージェントの実装行数比較
AgentExecutorの場合、実装は非常にコンパクトです。
# AgentExecutorの疑似コード例
tools = [search_tool]
agent = create_react_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools)
response = agent_executor.invoke({"input": "LangGraphとは？"})
わずか数行で動作します。しかし、ここで「検索結果が0件だった場合は、別のキーワードで再検索する」というロジックを追加しようとすると、プロンプトを調整するか、ツール側でロジックを組む必要があり、途端に難易度が上がります。
LangGraphの場合、セットアップには記述量が必要です。
# LangGraphの疑似コード例
class AgentState(TypedDict):
messages: Annotated[Sequence[BaseMessage], operator.add]
def call_model(state):
# LLM呼び出しロジック
...
def call_tool(state):
# ツール実行ロジック
...
workflow = StateGraph(AgentState)
workflow.add_node("agent", call_model)
workflow.add_node("action", call_tool)
workflow.set_entry_point("agent")
workflow.add_conditional_edges(
"agent",
should_continue,
{
"continue": "action",
"end": END
}
)
workflow.add_edge("action", "agent")
app = workflow.compile()
行数は増えますが、「エージェントが判断し、継続ならアクションへ、終了ならENDへ」というフローがコード上で明示されています。ロジックの追加はノードやエッジを増やすだけで対応でき、構造が破綻しません。
カスタムツール追加時の柔軟性の違い
Raw APIでは、Tool Calling（Function Calling）の定義からレスポンスの処理まで全て書くため、50行〜100行程度のコード量になるでしょう。しかし、依存ライブラリがないため、LangChainの破壊的変更に影響されるリスクを低減できます。
デバッグ時のスタックトレースの可読性
エラーが発生した際、AgentExecutorのスタックトレースはライブラリ内部の深い階層（langchain.agents.agent.pyなど）を指し示すことが多く、原因特定に時間を要します。一方、LangGraphやRaw APIは、記述した関数（ノード定義やループ処理）でエラーが止まるため、直感的にデバッグが可能です。
結論：フェーズ別・技術選定ディシジョンツリー
これまでの分析を踏まえ、技術選定の指針（ディシジョンツリー）を提示します。
PoC・プロトタイプ期ならAgentExecutor
「まずは動くものを見たい」「LLMで何ができるか試したい」というフェーズでは、AgentExecutorのスピード感が有効です。短期間でデモを作成し、ステークホルダーに提示する用途には適しています。ただし、これをそのまま本番コードに流用しないことを強く推奨します。
本番運用・複雑なワークフローならLangGraph
現在、最もバランスが良い選択肢です。特に以下の要件がある場合は必須と言えます。
- 人間による確認ステップ（Human-in-the-loop）が必要
- 複数のエージェントが連携する（マルチエージェント）
- 処理の状態（ステート）を永続化し、中断・再開を行いたい
- 詳細な制御と可観測性を確保したい
LangChainチーム自体も、AgentExecutorからLangGraphへの移行を公式に推奨しており、今後のエコシステムの中心は間違いなくLangGraphになります。
完全な最適化・軽量化ならRaw API
極限までレイテンシー（応答速度）を削りたい、トークンコストを削減したい、あるいは特定のフレームワークへのロックインを避けたい場合は、Raw APIによる独自実装を選択すべきです。初期コストは高いですが、長期的な保守性と資産価値は最も高くなります。
専門家としての提言
AIエージェントは、もはや「実験」の段階を超え、「実務」を担うシステムになりつつあります。だからこそ、その挙動には透明性と説明責任が求められます。
「とりあえず動く」ブラックボックスなエージェントではなく、意図通りに制御され、その思考プロセスを人間が理解できる「ホワイトボックス」なエージェントを構築すること。それが、技術的負債を回避し、社会的に信頼されるAIシステムを作り、企業のブランド価値向上に貢献するための確実なアプローチです。
現在のAgentExecutorベースの実装に限界を感じている、あるいはこれから本格的なエージェント開発を始めるにあたり、アーキテクチャ選定に迷われている場合は、制御可能な環境での検証を推奨します。LangGraphによる可視化された思考プロセスを確認することで、その有用性と可能性を実感できるでしょう。
コメント