AIエージェント開発の「脱フレームワーク化」：LangChain依存からの脱却と実装の本質

はじめに

近年、AIエージェントの開発現場では「フレームワーク依存」が大きな議論の的となっています。LangChainやCrewAIのような大規模なオーケストレーションフレームワークは、複雑なマルチエージェント連携やツール呼び出しを容易にする一方で、ブラックボックス化された内部ロジックにより、本番環境でのデバッグやパフォーマンスチューニングにおいて深刻な障壁となるケースが増えています。

この記事では、なぜ「フレームワークなし」でAIエージェントを実装することが、中級以上のエンジニアにとって重要なのかを解説します。特に、数百行のコードで実装可能な最小限のエージェントアーキテクチャに着目し、依存関係の排除による透明性の確保と、フレームワーク使用時のトレードオフについて深く掘り下げていきます。

フレームワークが隠蔽する「魔法」の正体

多くの開発者は、AIエージェントを構築する際、会話履歴の管理、ツール実行の再試行ロジック、フォールバック処理などを一から実装することを避け、既存のフレームワークに頼りがちです。しかし、これらの機能は実は複雑な魔法ではなく、極めて単純なループと条件分岐の集合体です。

フレームワークを使わない場合、まず直面するのは「何を実装すべきか」という設計判断です。エージェントの本質は、以下のサイクルを繰り返す制御ロジックに過ぎません。

1. 推論（Reasoning）: LLMに対して現在の状態とタスクを提示し、次のアクション（テキスト出力またはツール呼び出し）を決定させる。
2. 実行（Execution）: 決定されたアクションを実行し、その結果を取得する。
3. 記憶（Memory）: 対話履歴に新しい状態と結果を追加し、次の推論のコンテキストとする。

この基本構造を理解すれば、フレームワークが提供している「抽象化レイヤー」が何をしているのかを明確に把握できます。例えば、CrewAIやLangGraphは、エージェント間の役割分担や状態遷移図を宣言的に記述させることで、上記のループを暗黙的に管理しています。しかし、その代償として、エラー発生時にどこで制御フローが分岐しているのかを追跡するのが困難になる場合があります。

数百行での実装：最小限のエージェント構造

では、実際にフレームワークに依存しないエージェントをどのように構築すべきでしょうか。ここでは、Node.jsを用いたコードレビューエージェントの実装例を通じて、その核心部分を見ていきます。重要なのは、複雑なクラス階層を作らず、単一の「メインループ」を持つことです。

// 簡易的なAIエージェントの核心ロジック（擬似コード）
async function runAgentLoop(userInput, context) {
  let currentContext = [...context];

  // 最大反復回数（無限ループ防止）
  for (let i = 0; i < MAX_ITERATIONS; i++) {
    // 1. LLMへのプロンプト構築
    const prompt = buildPrompt(currentContext, userInput);

    // 2. LLMからのレスポンス取得
    const response = await llm.generate(prompt);

    // 3. アクションの解析（テキスト出力か、ツール呼び出しか）
    const action = parseAction(response);

    if (action.type === 'FINISH') {
      return action.result;
    }

    if (action.type === 'TOOL_CALL') {
      // 4. ツールの実行
      const toolResult = await executeTool(action.name, action.args);
      
      // 5. 結果をコンテキストに追加（重要なステップ）
      currentContext.push({
        role: 'assistant',
        content: `Called ${action.name} with result: ${toolResult}`
      });
    } else {
      // 6. 通常テキスト出力の場合も履歴に加える
      currentContext.push({
        role: 'assistant',
        content: response.text
      });
    }
  }
  
  throw new Error('Max iterations reached');
}

この実装のポイントは、「状態」を明示的に変数（配列）として管理している点です。フレームワークを使わない場合、このコンテキストリストの状態遷移を自分で監視・デバッグできます。例えば、「なぜLLMが特定のツールを呼ばないのか？」という問題が発生した際、プロンプトの内容や履歴の長さを直接確認しやすくなります。

設計判断：なぜ「単純さ」を選ぶのか

フレームワークを使わない選択には、明確な技術的根拠があります。それは「デバッグ可能性（Debuggability）」と「依存関係の最小化」**です。