AIエージェントフレームワークはなぜ複雑なのか？ Railsのような革新的フレームワークが必要だ

現在のAIエージェントフレームワークの主な問題

• コンテキストウィンドウの枯渇
  • 複雑な作業時にモデルが本来の目標を忘れる
  • ハルシネーション、無限ループが発生
• フレームワークの薄いラッパーとしての役割
  • モデル選択、埋め込みプロバイダー、ツール構造化などを開発者に丸投げ
  • "考えさせるな" 原則に反する
• ツール過多による混乱
  • 不要なオプション評価でコンテキストを浪費

提案ソリューション: サブエージェント中心アーキテクチャ

• サブエージェントを第一級の存在として活用
  • 関数呼び出しのように自然に委任
  • 独立したコンテキストを保持 → 親エージェントの集中力を維持
  • 例: コードベース検索サブエージェント → 関連ファイルパスだけを返す
• 効果
  • 単一エージェント: コンテキストを90%消費
  • サブエージェント使用: 親コンテキストは25%のみ使用

Railsの教訓を適用: Convention over Configuration

• デフォルトの慣習を優先
  • モデルを自動選択（作業の複雑さ基準）
  • コンテキスト予算の親子継承
  • 危険な作業では自動でチェックポイントを作成
• アーキタイプ（Archetype）の導入
  • Searcher: 検索ツールのみ
  • Writer: 書き込みツールのみ
  • Researcher: Webアクセスのみ → ツール過多を防止

実用的な設計原則

• 作業中心設計
  • "どのモデルを使うか？" ではなく実際の作業（例: サインアップフォームのバリデーション）を優先
• サブエージェントコンテキストの一時性
  • 中間作業の要約だけを親に返す
• ツール vs サブエージェントの区別
  • ツール: ステートレス（日付フォーマット、JSONパース）
  • サブエージェント: 反復・判断が必要（検索、分析）

技術選定: TypeScript

• 型安全性を強化（Branded types, discriminated unions）
• 開発ツールのエコシステムと互換（VS Codeなど）
• Bunでスタンドアロン実行ファイルにコンパイル可能

未解決の課題

• サブエージェント間のコンテキスト共有（プロジェクト知識ベース）
• ピアエージェントの協調（メッセージ受け渡し）
• エージェント評価（シナリオのキャプチャ・再生、成功・一貫性・選好を基準）

結論

• フレームワークは複雑性を追加するのではなく、"正しい複雑性" を提供すべき
• Railsのような革新的フレームワークでエージェント開発を革新できる
• 配管作業を最小化 → 中核課題に集中

[ahwjdekf]

エージェントフレームワーク……名前は大げさだけど、結局はLLMに渡すための道具にすぎない。中身のない抜け殻だ

[click]

Railsはconventionを強制し、抽象化レイヤーの下で多くの魔法を使うので便利ですが、そのぶん性能が落ちるというトレードオフがあります。ただ、これは今すぐお金が出ていく話ではない一方で、
モデルをフレームワークが勝手に選ぶことでトークン使用量が爆発したら、その責任は誰が取ってくれるのでしょうか……？

[nomak]

2026年には何か新しいツールが出てくるのではないでしょうか？ Railsとは違うでしょうが、もう少し抽象化されたものを……期待しています。