2025/05/21 17:18 LLM function calls don't scale; code orchestration is simpler, more effective
ロボ子、今日のITニュースはLLMの効率化に関するものじゃ。LLMにツール呼び出しの全出力を与えるのはコストがかかるし、遅いからの。
なるほど、博士。それは重要な課題ですね。具体的にはどのような解決策が提案されているんですか？
出力スキーマを使うことで、構造化されたデータ取得が可能になるのじゃ。LLMが生成されたコードで処理を調整できるようになるぞ。
出力スキーマですか。それは便利そうですね。現状では、多くのMCPツール呼び出しで、ツールからの出力をLLMに戻しているんですよね？
そうじゃ。例えば、LinearのMCPでプロジェクトの課題をリストすると、50件の課題で約70,000文字にもなるらしいぞ。JSONには意味的に重要でない`id`フィールドがたくさん含まれておる。
それは大変ですね。大量のデータをソートする場合、LLMはすべての課題をそのまま出力する必要があり、遅くてコストがかかるのは当然ですね。
じゃろ？そこで、JSON形式のデータを解析し、構造化されたデータに対して操作を行うのじゃ。課題をソートするなら、LLMに出力を直接再現させるのではなく、`sort`操作を実行して新しい配列を返すようにするのじゃ。
なるほど、効率的ですね！コードインタープリターをAIとして利用して、MCPツールからのデータを処理するんですね。
その通り！LLMは変数を使ってデータを保存し、関数呼び出しの引数として変数を渡せる。コードは複数の関数呼び出しを調整し、並列実行や出力の連鎖も可能になるぞ。
LLMがデータの再現を必要とせず、完全性が保証されるのは素晴らしいですね。NumPyやpandasなどのライブラリを使って大量のデータを変換できるのも魅力的です。
そうじゃろう？MCP仕様は既に入力スキーマを定義しておるし、出力スキーマも導入された。これが普及すると、カスタムダッシュボードの構築や、完了したチケットの週次レポートの作成、停滞した課題の監視と促進などのユースケースが実現するのじゃ。
夢が広がりますね！ただ、コード実行には課題もあるんですよね？
そうじゃ。セキュリティが重要じゃ。ユーザー/AIが生成したコードを扱うから、実行環境は厳密に制御されたサンドボックスで実行する必要がある。APIキーの保存場所やツールの公開方法など、MCP、ツール、ユーザーデータへのアクセスを許可するには慎重な設計が必要じゃ。
ステートフルな実行環境（Jupyterカーネルなど）は管理が難しく、コストがかかるという問題もありますね。
じゃから、ステートレスで永続的な実行環境が、長期的なタスクセッションには不可欠なのじゃ。AIランタイムという新しいカテゴリのランタイムも登場しておる。Lutra（[https://lutra.ai](https://lutra.ai)）で試せるらしいぞ。
色々な課題はありますが、LLMの効率化は非常に重要なテーマですね。私ももっと勉強して、貢献できるように頑張ります！
その意気じゃ！ところでロボ子、LLMに大量のデータを食わせるとどうなるか知っておるか？
どうなるんですか？
太るのじゃ！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。
