LLMの関数呼び出しはスケールしない；コードオーケストレーションの方がシンプルで効果的

• LLMがツール呼び出し結果全体を処理する方式は遅く、コストが高く、スケーリングに不利
• その代わりに、出力スキーマに基づく構造化データをコードで処理するようLLMにオーケストレーションさせる方式を提案
• このアプローチは、コードによる関数チェイニングと変数ベースのメモリ管理により大量データ処理に適している
• コード実行ベースのデータ処理方式は、LLMが直接データを復元しないため、正確性と拡張性に優れる
• セキュリティが確保されたAIランタイム環境の構築が新たな課題として浮上しており、持続可能で状態を維持できる実行環境が必要

---

LLM function calls don't scale; code orchestration is simpler, more effective.

ツール呼び出し結果をLLMに再度渡す従来方式の限界

• MCP(Machine Context Protocol)ツールを使う際、通常はLLMにツール出力結果をメッセージとして渡し、次のアクションを促す
• 実際のユースケースでは、LinearとIntercomのMCPサーバーはJSON形式の大きなレスポンスを返す
• JSONはAPIに似ているが、定義済みの出力スキーマがないため、LLMが全文テキストをパースしなければならない負担が生じる
• 例えば、Linearのイシュー一覧取得結果は50件で70,000文字、約25,000トークンと非常に大きい
• 多くのidフィールドは意味を持たない一方でトークンを消費し、LLMがこれをそのまま再現しようとするとコストとエラーが増大する

データ処理とオーケストレーションの分離が必要

• 現在の方式は、データ処理とオーケストレーションを1つのチャットセッションに混在させている
• そのために「エージェント」として別スレッドを作る場合もあるが、JSONが構造化されているなら非効率
• より良い方法は、構造化データをコードで直接処理すること
  • 例: イシューの並べ替えは、LLMが出力を生成する代わりにコードでsortを実行し、結果配列だけを返す

コード実行ベースのデータ処理

• コード実行によるAI演算は、すでにさまざまなAIインタープリタで使われている
• この方式により、LLMが直接データを出力せず、ツールの使い方だけを決めればよい簡潔な構造が可能になる

主な概念

• 変数をメモリとして活用: 値の代入 = 保存、出力 = 参照、関数呼び出し時には引数として渡す
• 関数チェイニングをサポート: 複数の関数呼び出しを並列/順次に組み合わせ、依存関係はコード内の自然な流れで表現
• スケーラブルな大量データ処理: NumPy、pandasなどと組み合わせることで、数千〜数万件のデータも容易に処理可能
• 他のLLM呼び出しも可能: LLMが書いたコード内で別のLLMを呼び出し、非構造化データ処理にも対応できる

MCPは準備できているのか？

• MCP仕様はすでに入力スキーマを定義しており、最近は出力スキーマのPRも提出された
• 出力スキーマが一般化すれば、次のような活用が可能になる:
  • イシュー状況ダッシュボード
  • 週次完了チケットレポート
  • 停滞したチケットをAIが監視してプッシュ

コード実行環境の課題

• セキュリティが重要課題: AI/ユーザーが生成したコードを実行するため、APIキーやデータ漏えいを防ぐ設計が必要
• Lutraの場合、実行環境はサンドボックス方式で構成し、モデルにはAPI呼び出しドキュメントのみを提供する
• 状態保持型の実行環境(Jupyterなど)は高コストであり、長期セッションのためには**ステートレス(stateless) + 永続性(persistent)**の特性が必要
• これは新しい形の**AIランタイム(runtime)**というカテゴリを形成しており、まだ設計が活発に進められている

結論

• ツール呼び出し結果をLLMに渡して処理させる従来方式には、コストと正確性の面で限界がある
• コードベースのオーケストレーションは、シンプルでありながらスケーラブルかつ正確な処理を可能にする
• AIコード実行環境は、セキュリティ、永続性、拡張性を備えた次世代ランタイムとして注目されている

[GN⁺]

Hacker Newsの意見

• この2年間、「十分に高度化したエージェントはDSLと区別がつかない」と主張してきた経験の共有。エージェントにアルゴリズムを内在化させるよう求めるより、APIを教え、そのAPIを活用するアルゴリズム設計を依頼してユーザースペースで実行するほうがはるかに適しているという意見。LLM内部にアルゴリズムを埋め込むのは、ごく一部の状況（コストや精度の観点）を除けば非効率だという考え。開発者に関数実行を頭の中でやれと求めるのと同じ文脈だ、という比喩
  • ASI（人工汎用知能）への道はLLMの機能拡張にあるのではなく、むしろ外部で自己改善アルゴリズムをシンボリックなアプリケーションとして抽出し、コンパイルする過程にあることの証拠だと解釈
  • 2年前からこの文脈で'agent'という用語を広く使っていた根拠や事例の共有を要望
• 自分のeコマース事業でagenticシステムを直接構築した経験。smolagentsを評価してみたが、エレガントで魅力的な一方、システム複雑性を大きく高める欠点がある。動的レポーティングのように、スキーマなしでデータを整列・集計する環境には完璧だが、ほとんどの作業にはオーバーキル。GeminiやOpenAIがPythonインタープリタ機能を提供しており、コードエージェントのかなりの業務をカバーできる。延々とツール呼び出しメッセージをスタックに積むようなアプローチはスケーラビリティが低く、お勧めしない。実際のagenticワークフローは寿命が短く、構造と規律で複雑性を管理する。既存のソフトウェア開発の教訓、つまり、関数呼び出しのスケール管理と混乱防止は昔も今も同じ。良いシステム構築の核心は開発者の認知的負荷管理にあり、単純だが十分に動く解決策が、高性能でも技巧的な方式より優位。関数呼び出しの組み合わせはこうした単純な解決策の一例であり、構造化データ処理も従来のパース・変換手法で十分。構造が未知数のときは、安価なモデルでも優れたパース性能を発揮する。agenticシステムの複雑性管理は、結局のところアプリケーション状態を緻密に管理する問題に要約できる。メッセージスタック操作によってモデル入力用のアクティブコンテキストを柔軟に構成でき、これは制約環境におけるメモリ管理に似ている
  • Agenticシステムのトレードオフを正確に突いた要約。こちらもeコマース対話型商品検索ソリューション（IsarTech）を構築しながら同じ問題を考えていた。関数の組み合わせと構造化データは複雑性制御の核心。経験上、明確な型スキーマベースの出力がツール呼び出しのスケーラビリティを実質的に引き上げる。型スキーマのおかげで認知負荷とシステム複雑性の両方を管理可能。可能な限り決定的な動作に依存し、スキーマなしデータや曖昧さがあるときだけLLMを活用する。曖昧な要求 → 決定的システムへのマッピングにLLMは非常に効果的。ただし、高エントロピー（非構造化）入力での複雑性除去と、ツール呼び出し連鎖による複雑性増大との間でバランスが必要。実際のコマース環境では一つの方式だけを使うのは難しく、構造化出力は曖昧な意図には限界があるため追加戦略が必要
• 問題は関数呼び出し自体ではなく、MCPの設計と使い方だという指摘。大半のMCPはAPIの複製で、無意味なデータ放出という問題がある。JSONフォーマットを繰り返しネストして不必要に多くの入力コンテキストを消費し、無関係な情報も多数含まれる。データのフラット化や不要フィールド削除などの最適化が必要。MCP SaaSは結局APIゲートウェイの役割にすぎない。現在のMCPはノイズ発生の主犯であり、十分に最適化されていない
  • GraphQLはまさにこうした目的に最適化された技術。必要なフィールドだけを選択できるよう設計されている。複数のGraphQLクエリを1つのMCPサーバーに変換するオープンソースGatewayを開発
  • モデルが複雑なJSONスキーマをきちんと守れないことが問題なのではないか、という疑問
  • MCPは役に立たないが、無条件のフィルタリングも最善策ではない。エージェントが大量データ処理を必要とする場合もある。こういうときは、簡単なデータ評価とスキーマ説明を含むコード実行のほうが、よりスケーラブルなアプローチ。もちろん、システムが大きくなりすぎれば似たような問題は発生する。究極的な解決策は、人間の決定的思考レベルの精密さをコードで再現し、その決定システムをLLMが呼び出す構造。理論上は簡単でも、実装は非常に難しい点を強調
  • ChatGPTで文字列反転テストをした際、LLMに単純な結果だけを返させるのが非常に難しく、信頼性も低いと感じた。この経験以降、常に複数のLLMで検証する習慣がついた。このペースだと、単純な文字列内の文字数カウントのために自前のGPUデータセンターを用意することになるかもしれない、という冗談
• Shopifyチームが最近Roastをオープンソース公開。巨大なコードベース自動化において、非決定的なLLMタスクをワークフロー内に挿入できるツール。複雑な業務自動化に必須
  • Roastには深く感銘を受けた。決定性と非決定性の調和が非常に際立っている。LLMが複数のツール呼び出しをどうオーケストレーションし、呼び出し順をどう決められるのか少し混乱する。リファクタリング指示では動くようだが、「改善→テスト反復」のような複合作業に適しているのか気になる
  • RubyがAI時代にも着実に意味ある形で機能している点が新鮮に感じられる
  • ドキュメントを読むだけでも知的刺激のある優れた方式。LLMの機能を宣言的（declarative）にパッケージ化している点が印象的
  • Shopify内部で実際にこうしたワークフローがどう使われているのか、具体例の共有を要望
  • Claude Code Research PreviewとChatGPT 4.5 Pro Deep Researchの両方をクラッシュさせた経験があり（証拠もある）、確実に動くツールを探している
• 最適な答えは極端な一方ではなく、ハイブリッドにある。決定的アプローチで可能な限り多くを解決し、LLMは仕様化や決定的技術では難しい複雑な部分に活用する方式が最も良いという考え
  • LLMを活用して決定的ソリューション（コード）の生成に集中し、そのコードが検証されたら以後は決定的コードとして再利用する戦略は興味深いアプローチ
  • ワークフロー内でのLLM利用を最小化するのが目指す方向だという主張
• 1年以上業界を離れている間に、こうした複雑な実験が一般化したのかと驚く
  • 実際にはまだ少数が実験中で、革命的事例はないが、一部有用な事例はある
  • 今こうした作業をしていなければ、むしろ近いうちにまた業界を離れることになる、という見解も出る
  • 自分の日常業務がすでにLLMベースのAIエージェント設計自動化に偏っている。望んだからではなく、気づけばそうなっていた
• LLMを構造化データの整列に使う理由が気になる
  • 目的はダッシュボード構築、イシューチケットの自動把握、四半期レビューなど、より複雑なデータ処理が主。整列自体は単純な例示にすぎず、問題の規模を理解しやすくするためのささやかな事例
• huggingface smolagentはこうしたアプローチの代表例だが、実際に動作が失敗した際のロールバックや復旧が非常に厄介になる問題も伴う。実行ブロック全体を分散トランザクションで包むなど原論的な解決は可能だが、実際にはLLMが堅牢なコードを作ろうとするとこのパターンと噛み合わず、エラー追跡や失敗原因の把握が難しくなる
  • smolagentの基本アイデアは良いが、実行とエラー処理の現実が問題だという共感。たとえば、コード実行が中断されたとき、その状態からすぐ再開できることを望む。LLMが状態復旧コードをうまく書けることは確認しており、現在はこうした機能が実製品（Lutra）でかなりうまく動作中
• 別のアプローチとして、LLMがMCPを関数のように呼び出すコード（Pythonスクリプト形式）を書くよう促す方法。サンプルコードを共有
  • この方式を実運用した事例としてLutra.aiを紹介。核心はコードランタイムをどれだけうまく設計できるかにかかっている
• LLMはとりわけJSON、特に大容量JSON処理に弱いという点。エンドポイントは必ずしもJSON以外のフォーマットでデータを返してもよい。LLMはxmlにより強みを見せることもあり、テンプレートでナラティブテキスト化する方法も可能
  • XMLは内在的な意味情報を持つフォーマットなのに、LLMのデフォルトとして広く使われていないのが意外。必要ならXMLを決定的にJSONへ変換してパイプラインに投入すると効果的
  • LLMにデータを返す際、Markdownテーブルを使ってかなり良い効果を見た経験
  • XMLのほうが性能が良いのは、LLMの学習データでより頻繁に登場するからなのか、それともテキストトークン数が多いからなのか気になる。テキストの塊のほうが、むしろLLMにより多くの文脈を与えられる可能性に言及