ハクソク

世界を動かす技術を、日本語で。

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

2025年5月22日原文(jngiam.bearblog.dev)

概要

  • LLMにツールコールの全出力を渡すのはコスト高・低速という課題を指摘
  • 出力スキーマが普及すれば構造化データ処理が容易になると提案
  • コードによるツールコール処理は効率的かつスケーラブルであることを強調
  • MCPサーバの現実的な課題と、コード実行環境の設計上の困難に言及
  • 今後の展望として「AIランタイム」新カテゴリへの期待を述べる

LLMによるツールコール出力処理の限界とコード実行アプローチ

現在のツールコール出力処理の課題

  • LLMに ツールコールの全出力 （例：巨大JSON）をそのまま渡すと コスト高・処理遅延 が発生することを確認
  • MCPサーバ（例：Linear, Intercom）は API類似の大きなJSON を返すが、 事前定義スキーマがない ため、LLMによる解釈に頼らざるを得ない状況を確認
  • 例としてLinearのMCPで 50件のIssue出力 を取得した場合、 約70,000文字・25,000トークン と大規模データとなり非効率
  • JSONには 意味的価値の少ないidフィールド等 が多く含まれ、LLMへの入力・出力トークン数が膨大になることを確認
  • LLMが 全データを出力で再現 しようとすると コスト増・速度低下・データ欠落リスク が発生することを指摘
  • 出力データに ノイズ情報 （再現手順、エラー、ユーザプロンプト等）が多く、LLMが 正確に再現できない・指示から逸脱する 危険性も指摘

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

  • オーケストレーション （処理手順管理）と データ処理 を同一チャットスレッドで混在させることが 根本的な問題 と分析
  • マルチエージェント方式（別スレッドでデータ処理専任エージェントを立てる）は 調整次第で効果的 だが、 構造化データ前提なら冗長 と指摘
  • MCPサーバが 既にJSON構造で返している場合、LLMに再現させるより 直接データ操作（例：ソート処理） を行う方が 効率的・スケーラブル と提案

コード実行によるデータ処理の優位性

  • コード実行（例：Code Act, Smol Agents）を AIによるデータ処理の基本手法 とすることで スケーラブルなAI活用 が可能と主張
  • 変数をメモリとして活用 し、外部メモリ不要で 値の保存・参照・引数渡し が可能となることを強調
  • 型情報が明確な言語を使えば スキーマ活用 も容易であることを確認
  • ツールチェイニング （複数関数の連携呼び出し）により、 並列処理・出力の再利用 が実現できることを説明
  • LLMは データの再現出力を担当せず、 処理の完全性保証 が得られることを評価
  • コードでの大規模データ処理は ループ・NumPy/pandas等のライブラリ活用 で自然にスケール可能であることを強調
  • コード内から 他のLLM呼び出し （LLM-inception）も可能で、 非構造データ処理 にも対応できる点を指摘

MCP仕様の進化と今後の可能性

  • MCP仕様は既に 入力スキーマ を定義しており、 出力スキーマも導入 されたことを紹介
  • 出力スキーマの普及により、 大規模データセット活用 （例：カスタムダッシュボード、週次レポート、自律エージェントによる監視・介入）が期待できると提案

コード実行環境の課題とAIランタイムの展望

  • コード実行環境は セキュリティ重視のサンドボックス での運用が必須となることを説明
  • MCPやツール・ユーザデータへのアクセスには、 APIキー管理・ツール公開設計 が重要であると指摘
  • 設計例として、 限定APIアクセス環境 と APIドキュメント提供 でモデルに秘密情報を渡さずに操作可能としたことを紹介
  • 多くの実行環境は ステートフル （例：Jupyterカーネル常駐）だが、 管理困難・コスト高 となるため、 ステートレスかつ永続的な実行環境 が求められると提案
  • こうした要件から「 AIランタイム」という新しい実行環境カテゴリが生まれつつあると展望
  • コード実行アプローチの詳細はまだ初期段階であり、 同様の課題に取り組む方からのフィードバック を歓迎すると表明
  • 実際の取り組み例として Lutra の利用を案内

提案・確認

  • MCPツールコールの出力処理は 構造化データ＋コード実行 へ移行することが 効率化・スケーラビリティ向上 の鍵
  • AIランタイム 設計では セキュリティ・永続性・API管理 を重視すること
  • 出力スキーマの普及 を待ちつつ、 コード中心のAIオーケストレーション を検討すること

Hackerたちの意見

最適な解決策は極端なものではなく、ハイブリッドだと思う。つまり、できるだけ決定論的なアプローチを使いつつ、残りの複雑な部分を扱うためにLLMを活用するってこと。

└

そうだね、特に面白い視点は、LLMを使って決定論的なアプローチ（コード）を生成することだと思う。それで、もしそのコードがうまくいけば、将来のために保存しておいて、今後は決定論的に使えるようになる。

└

同意するよ。ワークフローではできるだけLLMを使わない方がいいよね。

Shopifyの私のチームが最近Roastをオープンソースにしたよ。[1] これを使うと、非決定論的なLLMのジョブをオーケストレーションされたワークフローに組み込むことができる。何百万行ものコードを持つコードベースで作業を自動化する際には欠かせないね。[1] https://github.com/shopify/roast

└

Rubyが存在し続けて、ちゃんと機能しているのを見るのは嬉しいね…「AI」の時代でも。

└

わあ、Roastは素晴らしいね。ずっと悩んでたことに名前や制約をつけて設計したんだね。決定論と非決定論をうまく融合させてるのがすごく好きだよ。（READMEを何回か（さっと）読んでも、LLMが必要に応じて複数のツール呼び出しを調整したり、どのツールをどの順番で呼ぶか決めたりできるかどうかが明確じゃなかったんだ。リファクタリングを指示するときにはできるみたいだけど、「改善してからテストを実行。完了するまで繰り返す」ってタスクに適してるかは分からなかった。）

└

いいね！俺、Claude Code Research Previewを壊しちゃったし、ChatGPT 4.5 Pro Deep Researchもクラッシュさせたよ。証拠もあるからね :)、だから使えるツールを探してるんだ。

└

これ、めっちゃクールだね！Shopifyの内部でこういうワークフローがどう使われてるのか気になるな。何か例を共有してもらえる？

そもそも、構造化データをソートするのにLLMを使う理由がちょっとわからないな？

└

目標はもっと複雑なデータ処理をすることで、ダッシュボードを作ったり、どのチケットが停滞しているかをエージェント的に把握したり、やったことの四半期レビューをしたりすることなんだ。ソートは大きなタスクの中の小さな作業だけど、問題をよりわかりやすく示すことができるといいな。

問題は関数呼び出しではなく、ここでMCPがどのように設計されているか、そしてあなたが使っているかだね。ほとんどのMCPはAPIを複製していて、データの塊を返している。1. これはJSON形式でのフォーマットに多くの入力コンテキストを使っていて、すでにJSONの中にあるJSONをエスケープしている。2. これには関係のない情報がたくさん含まれていて、それに対して同じことが言える。だから、問題はMCPツールにある。データをできるだけフラットにすべきで、JSONエンコーディングを通って戻るときに必要なフィールドを削除するべきだ。だから、ここでのMCP SAASは主にAPIゲートウェイなんだ。それがこのノイズを生んでいる！ そして、何よりもMCPを最適化していないんだ。

└
  1. これ、JSONの形式で大量の入力コンテキストを使っていて、すでにJSONの中にJSONをエスケープしてるよね。複雑なJSONスキーマを尊重しないのはモデルの問題じゃない？
Hacker Newsで議論の続きを見る