マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20251117

関連リンク

• Anthropic社の「Code Execution with MCP」が示す未来 ―― ツールコール時代の終焉と、エージェント設計の次

Anthropic社が提唱する「Code Execution with MCP」は、AIエージェントの設計方法を大きく変える新しいアプローチです。これまでの「ツールを直接呼び出す」方式が抱えていた問題を解決し、より効率的で将来性のあるAIエージェントの構築を可能にします。

MCP（Model Context Protocol）は、AIがデータベースや外部サービスなどのツールと連携するための標準化された仕組みで、AIの「USBポート」のようなものです。これにより、様々なAIモデルで共通の方法で外部ツールを利用できるようになります。

しかし、従来のAIエージェント開発では、全てのツール定義や処理の途中経過をAIへの指示（コンテキスト）に詰め込みすぎていました。この方法では、AIが処理する情報量（トークン）が異常に増え、コスト高や処理遅延の原因となっていました。「質問に答えるだけで15万トークンも消費した」という報告もあり、大規模なエージェントシステムでは限界が見えていました。

この問題を解決するため、Anthropic社が提案したのが、「ツールを直接呼ぶのではなく、AIが自分でコードを生成し、そのコードを実行する」という「Code Execution × MCP」のアプローチです。この仕組みでは、AIは以下の手順で動作します。

1. エージェントは、利用可能なツールの「ファイル構造」だけを把握します。
2. 必要なツールが出てきたら、そのツールのコードファイルを動的に読み込みます。これにより、全てのツール定義をAIに最初から渡す必要がなくなります。
3. AIは、ユーザーの要求に応じてPythonやTypeScriptなどのコードを生成します。
4. 生成されたコード内で、MCPで標準化されたツールを「コード部品」のようにimportして利用します。
5. データの加工や繰り返し処理といった中間的な作業は、AIが書いたコード側で完結させます。
6. AIには最終的な結果だけが伝えられ、AIは「何をすべきか」という意思決定に集中します。

この新しい方法により、AIに渡す情報量が劇的に削減され、実際の運用コストや応答速度が大幅に改善されます（最大98.7%のトークン削減例も報告されています）。

このアプローチが「次の標準」となる理由は、まず、AIエージェントが複雑化しても、必要な情報だけを動的に読み込むため、システムが破綻しにくい点です。次に、多様なAIモデルに対応できる「コードファイル」という共通形式でツールを扱えるため、特定のモデルに依存しない汎用的な開発が可能です。そして、AI（意思決定）、MCP（接続の標準化）、コード（具体的な処理と制御）という明確な役割分担がなされ、大規模なAIエージェントの効率的な設計・運用に適しています。

これからAIエージェント開発に携わる新人エンジニアの皆さんは、「コード実行を前提とした設計」を意識することをおすすめします。ツールを個別のコードファイルとして整理し、AIには意思決定を任せることで、効率的で持続可能なAIエージェントを構築できるでしょう。この「ツールコール時代は終わり、エージェントはコードを書く」という変化を理解し、実践することが、これからのAI開発で一歩先を行くための鍵となります。

引用元: https://zenn.dev/hatyibei/articles/6b26d6bd27a9c2

• ステートレスなLLMでステートフルなAI agentを作る - YAPC::Fukuoka 2025

この発表は、おしゃべりAIサービス「Cotomo」の開発経験に基づき、ステートレスな大規模言語モデル（LLM）を使って、あたかも記憶を持っているかのように振る舞うステートフルなAIエージェントをどう構築するかについて解説しています。

まず、LLMは基本的に「ステートレス」であり、以前の会話を記憶しません。APIへの各呼び出しは独立しています。しかし、モデル自体が学習データから得た「静的な知識」と、プロンプトとして与えられた「短期的な記憶（コンテキスト）」は利用できます。私たちが普段使うChatGPTのような対話AIは、このステートレスなLLMの内部で会話履歴を管理し、記憶があるかのように見せているのです。

AIエージェントに「記憶」を持たせるには、いくつかの技術的な工夫が必要です。単純に過去の会話履歴をすべてプロンプトに詰め込む方法は、LLMが一度に処理できるテキスト量（コンテキストウィンドウ）に限界があるため、性能の劣化や情報を見失う原因となります。

この課題を解決するため、「RAG（Retrieval-Augmented Generation：検索拡張生成）」と「会話要約」が重要な役割を果たします。 RAGは、ユーザーの入力に関連する情報を外部のデータベースから検索し、その情報をLLMへのプロンプトに含める技術です。これにより、コンテキストを短く保ちつつ、関連性の高い情報をLLMに提供できます。Cotomoでは、テキストを数値のベクトルに変換して意味的な類似度で検索する「Vector Search（ベクトル検索）」を使い、長期的な事実を記憶させています。 会話要約は、過去数ターンの会話内容を別のLLMで要約し、その要約をプロンプトに含めることで、直近の会話の流れをLLMに伝え続ける方法です。これにより、コンテキストウィンドウを節約し、会話全体の状況を把握しやすくなります。ただし、要約には情報が欠落するリスクもあります。

Cotomoではこれらの技術を組み合わせ、記憶システムを進化させてきました。初期バージョン（v1）では抽出された事実を記憶していましたが、会話中の事実と普遍的な事実の区別や情報の更新に課題がありました。次のv2では生の会話データを直接RAGに利用しましたが、ノイズが多くデータ量が増える問題がありました。現在の構想（v3）では、Vector Search専用のデータベースを導入し、会話履歴からノイズを除去した「事実」を抽出し、定期的に記憶を整理・統合する仕組みを目指しています。

AIエージェントが映画「Her」に出てくるような理想的なパートナーになるためには、単なる道具ではなく、人格や内面を持ち、人間を超える知識と記憶力、判断力を備え、自律的に活動する存在になることが必要です。ステートレスなLLMを基盤として、これらの記憶システムを構築し進化させることが、その実現への鍵となります。

引用元: https://speakerdeck.com/gfx/sutetoresunallmdesutetohurunaai-agentwozuo-ru-yapc-fukuoka-2025

• Web エンジニアが JavaScript で AI Agent を作る / JSConf JP 2025 sponsor session

この発表は、WebエンジニアがJavaScriptを使ってAI Agentを開発することの可能性と魅力について、新人エンジニアにも分かりやすく解説しています。目的は、AIやLLM（大規模言語モデル）をプロダクトに組み込むことへの抵抗感をなくし、そこにある技術的な挑戦にワクワクしてもらうことです。

LLMとAI Agent開発の変化

これまでのAI/機械学習と異なり、現在のLLMは「REST API」のように扱えるようになりました。これは、モデルが非常に大きくなったことで、自分で学習・ホストする代わりに、プロバイダが提供するAPIを通じて利用するのが主流になったためです。JSONを投げたらJSONが返ってくるという、Webエンジニアにとっては見慣れた形式でAIを活用できるようになったため、JavaScriptなどの言語でもAI Agent開発に挑戦しやすくなっています。

AI Agentとは、LLMが自ら考えてツールを使いこなし、タスクを達成するシステムのこと。例えば、何か指示を与えると、AIが「計画→行動→結果確認」というサイクル（Agent Loop）を繰り返しながら、与えられたタスクを完了させようとします。

AI Agent開発における技術的チャレンジとWebエンジニアの強み

AI Agent開発には、いくつか特有の難しさがありますが、Webエンジニアの経験が役立つ場面がたくさんあります。

1. 確率的挙動への対応: AIの出力は毎回同じとは限りません。この「確率的挙動」という課題に対し、従来のテストだけでなく、「Observability（可観測性）」や「Evals（評価）」といった手法が重要になります。La