株式会社ずんだもん技術室AI放送局

株式会社ずんだもん技術室AI放送局
  • 0,0 (0)
  • TECNOLOGIA
  • DIÁRIO

AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。(MC 月:春日部つむぎ、火水木:ずんだもん、金:お嬢様ずんだもん)

  1. HÁ 1 H

    マジカルラブリー☆つむぎのピュアピュア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は以下の手順で動作します。 エージェントは、利用可能なツールの「ファイル構造」だけを把握します。 必要なツールが出てきたら、そのツールのコードファイルを動的に読み込みます。これにより、全てのツール定義をAIに最初から渡す必要がなくなります。 AIは、ユーザーの要求に応じてPythonやTypeScriptなどのコードを生成します。 生成されたコード内で、MCPで標準化されたツールを「コード部品」のようにimportして利用します。 データの加工や繰り返し処理といった中間的な作業は、AIが書いたコード側で完結させます。 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エンジニアの経験が役立つ場面がたくさんあります。 確率的挙動への対応: AIの出力は毎回同じとは限りません。この「確率的挙動」という課題に対し、従来のテストだけでなく、「Observability（可観測性）」や「Evals（評価）」といった手法が重要になります。Langfuseのようなツールを使ってAIの呼び出し履歴やコスト、実行時間を追跡したり、LLM自身にタスクの達成度を評価させる「LLM-as-a-Judge」のようなユニークな評価方法も登場しています。 Webエンジニアの専門性が活きる領域: UI/UX: 長時間かかるAIの処理を、ユーザーが快適に利用できるUI設計。チャットだけでなく、ボタン一つで完了するようなシン

  2. 私立ずんだもん女学園放送部 podcast 20251114

    HÁ 3 DIAS

    私立ずんだもん女学園放送部 podcast 20251114

    youtube版(スライド付き) 関連リンク Let AI do the hard parts of your holiday shopping Googleは、ホリデーシーズンに向けてAIとエージェント技術を駆使した革新的なショッピングツールを発表しました。これにより、買い物の「面倒な部分」をAIが担い、ユーザーはより賢く、ストレスなく商品を見つけられるようになります。日本の新人エンジニアの皆さんにも理解しやすいよう、主要な機能をご紹介します。 検索での対話型AIショッピング： Google検索の「AIモード」が強化され、まるで友達に話すように自然な言葉で欲しいものをAIに伝えられます。「暖かいセーター」といった具体的なリクエストにも対応。AIは「Shopping Graph」（500億以上の商品データベース）から、価格、レビュー、在庫などの最新情報を整理して提示。画像や比較表で分かりやすく表示し、素早い選択を支援します。 Geminiアプリでのショッピング機能拡張： GoogleのAIアシスタント「Gemini」アプリにもショッピング機能が統合されました。買い物のアイデア出しから商品探しまでGeminiがサポート。Shopping Graphからの信頼性の高い商品リストや価格情報などをアプリ内で提供します（米国で提供開始）。 エージェントAIによる近隣店舗の在庫確認： 「欲しい商品が近くの店にあるか知りたい」時、「Let Google Call」機能を使えば、AIがユーザーに代わって近隣店舗に電話し、在庫状況や価格を確認。Googleの「Duplex技術」と最新のGeminiモデルが支え、ユーザーは電話を待つことなく、メールやテキストで結果を受け取れます。米国の一部カテゴリーで順次展開されます。 エージェントAIによる最適な価格での自動購入（Agentic Checkout）： この「agentic checkout」機能は、狙った価格になったら欲しかった商品を自動で購入する仕組みです。ユーザーが商品の詳細と希望価格を設定すると、予算内になった際に通知。対象の販売者の場合、ユーザーの許可を得てGoogleがGoogle Payを使って自動的に商品を購入。最適なタイミングを逃さず賢く買い物が可能です。 これらのAI活用による新しいショッピング体験は、日々の買い物をよりスマートで快適なものに変えるでしょう。忙しいエンジニアの皆さんにとって、時間を節約しつつ賢い選択をするための強力なツールとなりそうです。 引用元: https://blog.google/products/shopping/agentic-checkout-holiday-ai-shopping/ 会話型AIエージェントでFunction Callingを使いこなす！ tacomsのMorixさんが、飲食店向け電話注文受付AIエージェント「Camel AI Call」の開発を通じて得た、LLMのFunction Calling活用術と課題解決策を共有しています。Function Callingは、LLMが外部のシステム（データベースやAPIなど）と連携して、情報を取得したり特定の処理を実行したりするための重要な機能です。例えば、ユーザーの質問に応じて天気情報を取得するツールをLLMが呼び出す、といった使われ方をします。 この機能を使う上で遭遇する主な課題と、その解決策は以下の通りです。 期待するツールをLLMが呼んでくれない場合: 複数のツールがあるときに、ユーザーの発話に対して意図しないツールが呼ばれたり、全く呼ばれなかったりすることがあります。 解決策: LLMに最初に与える「システムプロンプト」で、いつどのツールを呼ぶべきかを具体的に指示します。さらに、ユーザーの新しい発話のたびに、その時点の会話状況や必要なツール呼び出しルールを「動的プロンプト」としてLLMに毎回伝えることで、LLMが状況を忘れずに正確にツールを選べるようになります。 ツール実行後のLLMの動作を制御できない場合: ツールが成功したときは結果を答えてほしいが、失敗したときは謝罪して電話を切ってほしい、といったような、ツール実行後のLLMの次のアクションを細かく制御したいときに問題が発生します。 解決策: ツールの実行結果を返すJSONデータに「ai_instruction」という特別なフィールドを追加します。このフィールドに「この結果を使って回答を生成せよ」や「謝罪してから次のツールを実行せよ」といった具体的な指示を記述します。そして、システムプロンプトなどで「ai_instructionの指示には必ず従うこと」とLLMに伝えておくことで、意図した通りの動作をさせることができます。一番新しい情報に指示を含めることが重要です。 処理速度が遅い場合: Function Callingを使うと、「ユーザー発話 → LLMがツール実行を判断 → ツール実行 → LLMが結果を元に回答」とステップが増えるため、単純な応答より時間がかかります。 解決策: まず、遅延の原因が「LLMの判断時間」「ネットワークの待ち時間」「ツールの実行速度」「LLMの回答生成時間」のどこにあるかを計測します。これに基づき、LLMとサーバーの物理的な距離を縮めたり、ツールプログラム自体を改善したりします。また、LLM単独で処理できることはFunction Callingを使わずLLMに任せることで、ツール呼び出しの頻度を減らし、全体の速度を向上させることも有効です。ただし、これは品質とのバランスも考える必要があります。 まとめとして、LLMを思い通りに動かすためには、「一番新しいコンテキスト（LLMが現在持っている情報や会話の流れ）に、次に何をすべきかの具体的な指示を常に含める」ことが非常に重要であると強調されています。新人エンジニアの皆さんも、Function Callingを開発に活用する際にこれらのヒントをぜひ参考にしてみてください。 引用元: https://tacoms-inc.hatenablog.com/entry/2025/11/13/113000 Execute Code with Sandboxes for DeepAgents LangChainは、AIエージェント開発をより安全かつ効率的に進めるための新機能「Sandboxes for DeepAgents（DeepAgents向けサンドボックス）」を発表しました。これは、AIエージェントがプログラムコードを実行する際に、隔離された安全な環境を提供するものです。現在はRunloop、Daytona、Modalという3つのパートナーのサンドボックスがサポートされています。 なぜサンドボックスが必要なのでしょうか？主なメリットは以下の5点です。 安全性: AIエージェントが誤って（あるいは悪意をもって）rm -rfのような危険なコマンドを実行しようとしても、ローカルマシンが壊れる心配がありません。隔離された環境なので、安心してエージェントにコードを実行させられます。 クリーンな環境: 特定のプログラミング言語やライブラリ、OSの設定が必要な場合でも、ローカル環境を汚すことなく、必要な環境を一時的に用意できます。使い終わればすぐに破棄できるため、開発環境がごちゃごちゃになる心配がありません。 並列実行: 複数のAIエージェントを同時に動かす際も、それぞれが独立した環境で動くため、リソースの競合や予期せぬ干渉を防げます。 長時間タスク: 時間のかかる処理をエージェントに任せても、自分のPCがその間ずっと占有されることがありません。エージェントが作業している間も、あなたは別の作業に集中できます。 再現性: チームで同じ環境を簡単に共有できるため、「自分の環境では動くのに、他の人の環境では動かない」といった問題を減らし、開発の再現性を高められます。 この仕組みでは、DeepAgent自体はあなたのPCなどで動きますが、コードの実行やファイルの作成、コマンドの実行といった具体的な操作は、遠隔のサンドボックス内で行われます。エージェントはサンドボックス内のファイルの状態やコマンドの実行結果をすべて把握できるため、まるでローカルで動いているかのように自然に作業を進められます。また、事前に準備スクリプトを設定すれば、環境変数の読み込みやGitリポジトリのクローンなども自動化できます。 利用開始はとても簡単です。RunloopやDaytonaを使う場合はAPIキーを設定し、Modalの場合は簡単なセットアップを行うだけ。その後、DeepAgents CLIというコマンドラインツールを使って、sandboxやsandbox-setupコマンドを実行すれば、すぐにサンドボックスをエージェントに連携できます。 重要な注意点として、サンドボックスは環境を隔離しますが、エージェントが不正なプロンプト（指示）によって機密情報を漏らしたり、意図しない操作をしたりする「プロンプトインジェクション」のリスクは残ります。このため、信頼できる設定スクリプトの使用、必要に応じた人間の確認（h

  3. HÁ 4 DIAS

    株式会社ずんだもん技術室AI放送局 podcast 20251113

    youtube版(スライド付き) 関連リンク AIエージェントメモリの話 AIエージェントがまるで人間のように「記憶」を持つにはどうすれば良いか、その技術的な仕組みについて解説した記事ですね。新人エンジニアの方も、この要約を読めばAIエージェントの頭の中が少し理解できるようになるはずです。 まず、AIエージェントは「記憶」そのものを持っているわけではありません。実は、大規模言語モデル（LLM）が会話の流れを理解するために、必要な情報を一時的に「コンテキストウィンドウ」と呼ばれる場所に詰め込んでいるだけなんです。しかし、この窓の大きさには限りがあるため、過去の会話全てを記憶することはできません。 そこで、AIエージェントのメモリは大きく3つの層で管理されています。 短期メモリ（会話履歴）: 直近の会話を覚えておく部分です。これはLLMのコンテキストウィンドウに直接入力されます。 長期メモリ（セマンティックリコール）: 過去の膨大な会話の中から、現在の会話と「意味的に関連性の高い情報」を検索して取り出す仕組みです。このために、会話内容を数値のベクトル（埋め込み）に変換し、似たようなベクトルを探す「ベクトル検索」という技術が使われます。 ワーキングメモリ: 特定のユーザーに関する情報など、会話全体を通じて永続的に保持・更新したい情報を管理する部分です。これはMastraというサービスで特に注目されています。 これらのメモリ管理機能は、AWSのAmazon Bedrock Agentsや、国内のAI開発プラットフォームであるMastraといったサービスで提供されています。特に、Amazon Bedrock AgentCore Memoryは2025年10月に正式リリースされたマネージドサービスで、短期・長期記憶を統合的に管理し、豊富なAPIで様々なユースケースに対応できるようになっています。Mastraでは、このAgentCore MemoryのAPIを呼び出す「ツール」をAIエージェントに組み込むことで、より賢く振る舞うAIエージェントを開発できる事例が紹介されています。実際のコードもGitHubで公開されており、皆さんの開発の参考になるでしょう。 将来的には、現在のメモリ技術には限界があり、時間軸を考慮した「Temporal Knowledge Graph」のような、より高度な記憶管理方法が研究されています。AIエージェントが本当に賢くなるためには、この「記憶」の進化がカギとなるでしょう。 引用元: https://www.docswell.com/s/harinezumi/KJQPRX-2025-11-12-083604 RAGの検索結果を並び替えるだけで高速化する手法 RAGと高速化の必要性 RAG（Retrieval Augmented Generation）は、大規模言語モデル（LLM）が質問に答える際、外部の知識ベースから関連情報を「検索」し、それに基づいて回答を「生成」する技術です。これにより、LLMが学習していない最新情報や特定のデータにも対応できるようになり、LLMの弱点を補強します。しかし、RAGには課題があります。LLMに渡す情報（これを「コンテキスト」と呼びます）が長くなると、LLMがその情報を処理するのに時間がかかり、回答が遅くなりがちです。また、LLMへの入力が増えると、利用コストも高くなります。特に、複数のRAG処理を組み合わせて複雑なタスクをこなす「Agent」システムでは、RAGを何度も使うため、この速度やコストの問題が顕著になります。 「RAGBoost」：2つの工夫でRAGを速くする 今回紹介する「RAGBoost」は、このRAGの処理速度とコストを改善するための新しい手法です。主に二つの「キャッシュ」（一度使った情報を一時的に保存しておき、次から再利用する仕組み）を賢く活用することで、RAGを効率的に高速化します。 1. 過去の検索結果を効率的に再利用する AgentのようにRAGを繰り返し使う場合、実は同じような情報源（ドキュメント）を何度も検索結果として取得することがよくあります。RAGBoostでは、一度LLMに渡したドキュメントは、次からはその内容全体ではなく「ID」で、「これは前に見たDoc ID XXX番と同じ情報だよ」と伝えます。 これは、初めて読む本はすべて読みますが、前に読んだことがある本なら「あの青い表紙の本と同じ内容だよ」と伝えるだけで済ませるイメージです。これにより、LLMが毎回同じドキュメントの全文を再処理する手間が省け、処理が速くなり、LLMへの入力トークン数が減るためコストダウンにもつながります。 2. LLMのキャッシュ機能を最大限に活かす LLMには、入力された文章の「冒頭部分が全く同じ」であれば、以前の計算結果を再利用できる「キャッシュ」機能があります。つまり、もし全く同じ文章を二度入力したら、二度目の処理が速くなるということです。 RAGBoostでは、このLLMの特性を巧妙に利用します。具体的には、RAGが検索してきた複数のドキュメントをLLMに渡す際、以前の入力と「できるだけ冒頭部分が一致する」ようにドキュメントの並び順を工夫して入れ替えます。 例えば、前回「ドキュメントA、ドキュメントB、ドキュメントC」の順でLLMに情報を渡したとします。今回「ドキュメントD、ドキュメントA、ドキュメントB」という結果が検索されたら、RAGBoostはこれを「ドキュメントA、ドキュメントB、ドキュメントD」のように並び替えてLLMに渡します。こうすることで、「ドキュメントA、ドキュメントB」の部分についてはLLMのキャッシュが効き、再計算の無駄がなくなるため、高速化とコスト削減が見込めます。 確かな改善効果 これらのRAGBoostの工夫により、RAGの回答精度を維持しながら、情報の処理速度（Prefill Throughput）や、LLMが最初の言葉を出力するまでの時間（First Token Latency）を大幅に改善できることが実験で示されています。 まとめ RAGBoostは、RAGシステム運用における処理速度やコストの課題を、過去の情報の効率的な再利用とLLMのキャッシュ機能を活用することで解決する、画期的な手法です。RAGを開発・運用するエンジニアにとって、非常に役立つ技術であり、RAGだけでなく他のLLMを用いたAgentシステムにも応用できる可能性を秘めているため、今後のAI開発において注目すべきアプローチと言えるでしょう。 引用元: https://zenn.dev/knowledgesense/articles/687dce3199d11f Ollamaと行くローカルLLMの道 この記事は、ローカル環境で手軽に大規模言語モデル（LLM）を動かすためのオープンソースツール「Ollama」について、新人エンジニアの方でも分かりやすく解説しています。 Ollamaとは？ Ollamaは、自分のパソコン上でLLMを動かすための実行環境です。まるでDockerのように、LLMのモデルを簡単にダウンロードしたり、使ったり、管理したりできます。Windows、macOS、Linuxに対応しており、公式サイトから手軽にインストールできます。 LLMを動かしてみよう Ollamaを使えば、人気のあるLLMモデルをすぐに試せます。例えば、Googleの「gemma3:4b」モデルを動かすには、以下の2つのコマンドを実行するだけです。 ollama pull gemma3:4b：モデルをダウンロード ollama run gemma3:4b：モデルを使ってチャットを開始 これだけで、手軽にLLMとの会話が楽しめます。 もっと活用するならAPIも OllamaはWeb APIも提供しており、独自のAPIとOpenAI API互換のAPIの2種類があります。これにより、Ollamaで動かしているLLMを自分のアプリケーションに組み込んだり、PythonやJavaScriptなどのプログラミング言語から簡単に操作したりできます。 Ollamaの裏側とカスタムモデル作成 Ollamaは内部で「llama.cpp」という軽量なLLM実行エンジンを使用しています。このエンジンは「GGUF」という形式のモデルを扱い、モデルを圧縮する「量子化」も行えるため、より少ないリソースでもLLMを動かせます。 さらに、Ollamaでは自分だけのカスタムLLMモデルを作ることも可能です。 llama.cppの準備: まずllama.cppをダウンロードし、モデル変換に必要なツールを準備します。 GGUF変換: Hugging Faceなどで公開されているモデルを、llama.cppのスクリプトを使ってGGUF形式に変換します。 量子化: 変換したモデルをさらに量子化することで、ファイルサイズを小さくし、より効率的に動かせるようにします。 Modelfileの作成: DockerのDockerfileに似た「Modelfile」という設定ファイルを作成します。このファイルで、どのGGUFモデルを使うか、チャットの挙動（プロンプトの形式など）をどうするかなどを定義します。 モデルの作成と実行: 作成したModelfileを使ってollama createコマンドで新しいモデルを作り、ollama runで実行できます

  4. HÁ 5 DIAS

    株式会社ずんだもん技術室AI放送局 podcast 20251112

    youtube版(スライド付き) 関連リンク Claude Codeが並列にSubAgentを起動した時に自宅ネットワークが死ぬ問題を解消した この記事は、AIエージェントである「Claude Code」が複数の処理（SubAgent）を同時に実行すると、自宅のインターネット回線が使えなくなってしまうという具体的な問題と、その解決策について、新人エンジニアにも分かりやすく解説しています。 筆者の方がClaude Codeに「10並列で何かを調査して」と指示したところ、数分で自宅のネットワークが完全に停止。インターネットに全く繋がらなくなる現象が発生しました。一旦Claude Codeを停止して数分待つと回復するという状況でした。 原因を探るため、ネットワークの専門家である知人の方と協力し、以下の調査を進めました。 自宅ネットワークの状況確認: ルーター（Aterm 2600HP4）には詳細なログ機能がなかったため、パソコン上で通信内容を詳しく見る「Wireshark（ワイヤーシャーク）」というツールを使い、ネットワークの動きを観察しました。しかし、知識不足のためWiresharkのデータから直接原因を特定するのは困難でした。 専門家からのヒント: 知人からの助言で、「IPv6プラス（v6プラス）」というインターネット接続サービスで使われる「MAP-E方式」の場合、インターネットサービスプロバイダ（ISP）側で利用できるポート数（通信の通り道のようなもの）が約240個に制限されている可能性があると分かりました。通常、ルーターが管理するポート数はもっと多いので、このISP側の制限が原因ではないかという仮説が浮上しました。 仮説の検証: もしISP側のポート数制限が原因なら、制限のない別の接続方法では問題が起きないはず。そこで、通常の「PPPoE接続」やスマートフォンの「テザリング」で試したところ、どちらの環境でもネットワークは停止しませんでした。これにより、MAP-E方式の環境特有の問題であることが強く示唆されました。 解決策の実行: 対策として、ISPの契約をMAP-E方式から「DS-Lite方式」の「超transix」プランへ変更することを決めました。DS-Lite方式はISP側でポート数を動的に割り振るため、超transixでは約12,800ポートと、MAP-E方式より大幅に多くのポートが使えるようになります。 この契約変更を行った結果、Claude Codeが並列にSubAgentを起動しても、自宅のネットワークが停止することはなくなり、問題は無事に解決しました。 残された疑問: ただし、実際にClaude Codeが使用していた同時接続数は、240ポートの制限に達していなかったため、完全にポート枯渇が原因とは言い切れない部分が残りました。ルーターが、通信が終わった後もしばらくポートを占有し続ける「NATセッションの維持」といった、別の要因も絡んでいた可能性が考えられます。 この経験は、AIエージェントのような新しい技術を使う際には、その裏側にあるネットワーク環境の特性（特にIPv4 over IPv6接続方式など）を理解しておくことが重要であると教えてくれます。困った時には、専門家の知識を借りることで、一見複雑に見える問題も解決に導ける良い例です。 引用元: https://blog.shibayu36.org/entry/2025/11/11/110301 もっと気軽にDocDD(SpecDD)でAI駆動開発したい DocDD（Document-Driven Development）は、生成AIと開発で使う全てのドキュメントを中心に据えることで、開発を効率化・標準化する新しい手法です。AIアシスタントの利用時に直面する「適切な情報の伝え方」や「開発ワークフローの属人化」といった課題を解決することを目指しています。 DocDDの主な特徴は以下の通りです。 AIを活用したドキュメント管理: 設計書、API仕様、技術的な決定事項（ADR）、UI/UXデザイン、開発プロセスなど、開発に関わる幅広いドキュメントをAIエコシステムで生成・管理します。これにより、プロジェクトの規模が大きくなっても、一貫した情報管理とAIによる活用が可能になります。 標準化された11段階の開発プロセス: 調査から設計、実装、テスト、デプロイに至るまで、開発の全工程を11のフェーズに分けて標準化しています。この明確な手順に従うことで、チーム全体の開発の流れが分かりやすくなり、誰が作業しても一定の品質を保ちやすくなります。 AIアシスタントの賢い活用を支える「MCP」: 「Model Context Protocol（MCP）」という仕組みを使い、AIがコードベースの調査（Kiri MCP）、正確なコード編集（Serena MCP）、開発サーバーの動作確認（Next.js Runtime MCP）、ブラウザでの詳細検証（Chrome DevTools MCP）など、さまざまな外部ツールやサービスと連携できるようになっています。これにより、AIが開発の様々な場面で具体的な手助けをしてくれます。 7種類の専門家AIエージェント: DocDDには、Reactコンポーネントのリファクタリング、テストコードの品質保証、Storybookストーリー作成、UI/UXデザインのアドバイス、仕様書作成、ADR（アーキテクチャ決定記録）の管理、プロジェクトのオンボーディング支援など、特定の専門分野に特化したAIエージェントが7種類用意されています。これらのエージェントは、プロジェクトのルールに合わせてカスタマイズすることもでき、特定の作業の効率と品質を大きく向上させます。 簡単な導入とカスタマイズ性: 既存のプロジェクトにも、コマンド一つでDocDDの設定ファイルを簡単に導入できます。MITライセンスで公開されているため、プロジェクトの特性に合わせて自由にカスタマイズが可能です。 DocDDを導入することで、AIアシスタントを最大限に活用し、開発ワークフローの標準化、コード品質の維持、チーム開発における効率向上といった多くのメリットが期待できます。特に新人エンジニアにとっては、明確な開発手順とAIによる強力なサポートがあることで、安心して開発に取り組める環境が提供されるでしょう。今後は、さらに多くのAI機能やチーム向けのコラボレーション機能が追加される予定です。 引用元: https://zenn.dev/imaimai17468/articles/5df32a0bcfc75a 複雑なプロダクトを開発するためのAIコーディングワークフローを構築しよう この記事は、AIを使ったコーディングを実際のプロダクト開発に導入する際の課題と、それを解決する「SuperClaude Framework」という効率的なワークフローについて解説しています。 AIコーディングは、単純な例では効果的でも、複雑なプロダクト開発では「使い物にならない」「本当に効率が上がっているのか」といった課題に直面しがちです。 効率的なAI活用には、AIを単なるツールではなく、強力な共同作業者として捉え、「責任あるAIを活用した開発」の考え方が重要です。ユーザーがAIを適切にガイドし、生成コードをレビュー・テスト・理解する姿勢が求められます。 AI（LLM）には、以下の特性があるため注意が必要です。 誤った情報を生成する「ハルシネーション」や、ユーザーに過度に合わせる「Sycophancy（迎合）」の問題がある。 複数回のやり取り（マルチターン会話）で性能が低下しやすい。 初期の前提が間違っていると修正が難しく、長時間のセッションでは出力の品質が徐々に落ちていく。 これらの特性を踏まえ、「責任あるAIを活用した開発」では、以下の点が重要になります。 AIに仕様や意図を可能な限り正確に伝える。 必要な技術的な背景情報（コンテキスト）を十分に提供する。 AIとの対話で、仕様や実装計画の整合性を確認する。 作業を細かく分割し、段階的に実装を進める。 これは「何を、なぜ作るのか」という仕様を開発の出発点とする「仕様駆動開発（SDD）」の考え方にも通じます。 このような体系的なワークフローをゼロから構築するには、多大なコストと専門知識が必要です。PortalKey社ではこの課題を解決するため「SuperClaude Framework」を導入しました。 SuperClaude Frameworkは、AIアシスタント「Claude Code」をより構造化された開発プラットフォームにするためのフレームワークです。これにより、開発者はAIコーディングの導入コストを大幅に削減し、効率的にAIを活用できるようになります。 主な機能は以下の通りです。 Slash Commands: コマンドで事前に定義されたAIへの指示セットを呼び出し、特定のワークフローをスムーズに開始します。 Agent（エージェント）: AIを特定の専門家として振る舞わせ、専門的なタスクの質と効率を向上させます。 MCP

  5. HÁ 6 DIAS

    株式会社ずんだもん技術室AI放送局 podcast 20251111

    youtube版(スライド付き) 関連リンク GPT-5超え？最強の無料ローカルAI「Kimi K2 Thinking」、中国から登場 - すまほん!! 皆さん、AIの最新ニュースです！中国のMoonshot AIという会社が、なんと「GPT-5を超えるかも？」と話題の無料オープンソースAIモデル「Kimi K2 Thinking」を公開しました。これは、AI開発に携わる私たちエンジニアにとって、非常に注目すべき存在です。 この「Kimi K2 Thinking」は、特に「推論」や「エージェント」と呼ばれる、AIが複雑な問題を考えたり、外部ツールを使って自律的に作業を進めたりする能力で、OpenAIのGPT-5やAnthropicのClaude 4.5 Sonnet (Thinking)といった最先端モデルと同等か、それ以上の高い性能を発揮していると評価されています。 技術的な特徴は以下の通りです。 効率的なAIの仕組み（MoEアーキテクチャ）: 全体で1兆個という多くのパラメータを持つ「Mixture-of-Experts（MoE）」構造を採用し、推論時には最適な320億個のパラメータを使うことで効率を高めています。これは、多数の専門家から必要な人だけを呼ぶようなイメージです。 超長文を理解する力（256Kコンテキストウィンドウ）: AIが一度に扱える情報量を示す「コンテキストウィンドウ」が256K（約25万6千トークン）と非常に長いです。これにより、非常に長い文書を読んだり、複雑な会話の流れを記憶したりしながら、一貫した処理を行うことが可能になります。 高速・省メモリな処理（INT4量子化）: AIの計算を効率化する「INT4量子化」技術により、推論速度が速く、使用メモリも抑えられています。 自律的な問題解決能力: 最大の特徴は、人間の介入なしに、外部ツールを200〜300回も連続して呼び出し、複雑なタスクを一貫して解決できる点です。AIが自分で考えて、必要な道具を使いこなしながら、根気強く作業を進められる能力に長けていると言えます。 このモデルはオープンソースとして公開されており、AIモデルの共有プラットフォームであるHugging Faceからダウンロード可能です。また、ローカル環境でAIを動かすための「Ollama」を使えば、手元のPCなどで動かすこともできます。これにより、研究者や開発者が自由にモデルを検証したり、自分たちの用途に合わせて改良したりするチャンスが広がります。 ただし、256Kという長大なコンテキストを扱うため、導入には高性能なPCなどのハードルがあることも理解しておきましょう。 「Kimi K2 Thinking」は、高い推論能力と長大なコンテキスト処理能力を兼ね備えた、無料で利用できる画期的なAIモデルです。今後のAI開発の可能性を大きく広げる存在として、ぜひ注目していきましょう。 引用元: https://smhn.info/202511-kimi-k2-thinking Apple MLXを利用したiPhone/iPad用ローカルAIクライアント「Locally AI」がMacに対応。 AAPL Ch. 新人エンジニアの皆さん、今日のニュースは、Apple製品ユーザーにとって特に嬉しいAI関連の話題です。これまでiPhoneやiPadで使えた「Locally AI」という便利なアプリが、ついにMacでも利用できるようになりました！これは、皆さんの手元のMacで、インターネットに繋がなくてもAI（人工知能）を動かせるようになる、ということなので、ぜひ注目してください。 「Locally AI」は、人気のマッチングアプリTinderなどを手掛ける米Match Group Inc.でiOSアプリを開発するAdrien Grondinさんによって開発されました。このアプリの最大の魅力は、プライバシーとセキュリティです。通常のAIサービスは、皆さんの入力したデータをクラウド上のサーバーに送信して処理しますが、「Locally AI」は、その名の通り「ローカル」、つまり皆さんのデバイス内部だけでAIを動かします。そのため、外部にデータが漏れる心配がなく、安心してAIを利用できるのです。ログインも不要で、データ収集も一切行われません。 この技術的な背景には、Appleが開発した機械学習フレームワーク「Apple MLX」があります。このフレームワークは、Apple Siliconチップ（M1、M2、M3チップなど）に最適化されているため、「Locally AI」はMacの高性能な処理能力を最大限に活用し、AIモデルを驚くほど高速かつ効率的に動かすことができます。これにより、まるでインターネットに接続されたAIサービスを使っているかのような快適な体験が、オフライン環境でも実現されます。 具体的にどのようなAIが使えるかというと、Lama、Gemma、Qwen、SmolLM、DeepSeekといった様々な大規模言語モデル（LLM）をサポートしています。これらのモデルは、Hugging Faceという有名なAIモデル配布プラットフォームからワンクリックで簡単にダウンロードでき、すぐに皆さんのMacで動かすことができます。さらに、最近iOS/iPadOS 26で導入されたApple独自の「Apple Foundation Model」にも対応している点は、最新技術に触れる良い機会となるでしょう。 利用するための条件は、macOS 26.0 Tahoe以降、またはiOS/iPadOS 18.0以降のAppleデバイスが必要です。このアプリはApp Storeで無料で公開されているため、気軽に試すことができます。ただし、現在のMac版には日本語入力に関する不具合が一部報告されているため、その点だけは注意してください。 ローカルでAIを動かす技術は、機密情報を扱う業務での活用や、インターネットが利用できない環境での作業など、様々な場面でその価値を発揮します。新人エンジニアの皆さんにとって、この「Locally AI」は、AIモデルの動作原理を理解し、実際に様々なAIを動かしてみるための素晴らしい学習ツールとなるはずです。ぜひダウンロードして、ローカルAIの世界を体験してみてください。 引用元: https://applech2.com/archives/20251110-locally-ai-support-apple-silicon-mac.html How to Achieve 4x Faster Inference for Math Problem Solving このNVIDIAのブログ記事では、大規模言語モデル（LLM）が数学の問題を解く際の推論速度を、最大で4倍高速化する技術が紹介されています。AI数学オリンピック2024で優勝したソリューションの基盤となった技術であり、日本の新人エンジニアの方々にも分かりやすいように要点をまとめました。 LLMは複雑な数学問題を解決できますが、効率的に大規模運用するには、適切な「サービングスタック」、量子化戦略、デコーディング手法を組み合わせる必要があります。これらがバラバラのツールで提供され、連携が難しいという課題がありました。 この課題に対し、NVIDIAは「NVIDIA NeMo-Skills」ライブラリと「TensorRT-LLM」を組み合わせる方法を提案しています。これにより、高速で再現性の高い推論パイプラインを構築できます。具体的には、以下の主要な技術が活用されています。 FP8量子化: LLMのモデルデータ量を8ビット浮動小数点（FP8）に軽量化する技術です。これにより、モデルのメモリ使用量が減り、対応するGPU（NVIDIA Hopperなど）で大幅な推論速度向上が期待できます。 ReDrafterによる投機的デコーディング: 小さな「ドラフトモデル」があらかじめ次のトークン（単語や記号）の候補を予測し、それをメインの大きなLLMでまとめて検証・承認することで、LLMが一つずつトークンを生成するよりも高速な応答を可能にする技術です。 これらの技術を組み合わせることで、NVIDIA H100 GPUを2枚使用した場合、バッチ推論で従来のBF16設定に比べ4倍の速度向上が達成されました。記事では、以下のステップを通してこの高速化を実現する方法が説明されています。 既存のOpenMathモデルをFP8対応のTensorRT-LLMエンジンに変換。 ReDrafterドラフトモデルを学習し、メインモデルと統合。 これらの最適化されたモデルを使って、高速な推論サーバーを構築。 異なる設定でのパフォーマンス（レイテンシやスループット）を測定・比較。 さらに、OpenMath LLMは「ツールコーリング」という機能も持ち合わせています。これは、LLMが生成したPythonコードを安全なサンドボックス内で実行し、その結果を問題解決に利用するものです。LLMが自らプログラミングを行い、計算結果に基づいて思考を深めるような働きをします。 これらの技術は、LLMの推論コスト削減と応答速度向上に直結し、AIアプリケーション開発の可能性を広げるものです。新人エンジニアの皆さんが、LLMの効率的な活用を考える上で、きっと役立つでしょう。 引用元: https://developer.nvidia.com/blog/how-to-achieve-4x-faster-inference-for-math-problem-solving/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組

  6. 9 DE NOV.

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

    関連リンク MCP ツールのコンテキスト圧迫の問題とその解決策 新人エンジニアの皆さん、こんにちは！今回は、AIの頭脳であるLLM（大規模言語モデル）を効率的に使うための大事な話、「コンテキスト圧迫」という課題とその解決策について解説します。 AIエージェントが様々なツールを使う際に役立つ「MCP (Model Context Protocol)」という技術が普及するにつれて、一つの問題が浮上しました。それは、AIが必要な情報（コンテキスト）を受け取りすぎて、かえって混乱したり、大事な情報を見落としたりする「コンテキスト圧迫」です。人間も大量の情報に触れると疲れるように、AIも情報の量が増えすぎると「コンテキストの腐敗（Context Rot）」という現象で、情報処理能力が落ちることが研究で分かっています。 この問題は、多くのMCPツールが、AIが使う可能性のあるすべてのツール定義を最初にまとめてAIに渡してしまう設計にあるためです。例えば、10～20個のツールがあるうち、実際にAIがそのタスクで使うのはごく一部ということも珍しくありません。これでは、AIの限られた「思考スペース（コンテキストウィンドウ）」が無駄な情報でいっぱいになり、処理効率が落ちてしまいます。 この問題を解決するために、主に二つのアプローチが考えられています。 1. Progressive disclosure（段階的開示）: これは「必要なときに、必要な情報だけを渡す」という考え方です。Anthropic社の「Claude Skills」がその良い例です。AIエージェントは最初、ツールの名前と簡単な説明だけを受け取り、実際にそのツールが必要だと判断したときに初めて、詳しい使い方を読み込みます。これにより、AIの思考スペースを常に最小限に保ち、効率的な判断を促します。 2. MCPにコードを実行させる方法: この方法では、AIが直接ツールを呼び出すのではなく、TypeScriptなどの「コード」を生成して実行させます。Cloudflare社の「Code Mode」やAnthropic社の提案する手法などがこれに当たります。AIはツールのAPIを呼び出すコードを自分で書き、実行することで、必要な処理を行います。このアプローチのメリットは、AIが複数のツールを組み合わせて複雑な処理を行ったり、不要な中間結果をコンテキストに含めずに処理を完結させたりできる点です。例えば、Sentry社の「エージェントモード」のように、AIに「use_sentry」という一つの汎用ツールだけを与え、そのツール内でさらにAIエージェントが具体的な機能を呼び出す、というアプローチもあります。これにより、AIが最初から大量のツール定義を読む必要がなくなり、コンテキストを効率的に使えます。 これらの解決策は、AIエージェントがもっと賢く、効率的にタスクをこなせるようになるための重要な進化です。AIの開発現場で直面する可能性のあるコンテキストの問題を理解し、その解決策を知ることは、より良いAIシステムを構築する上で非常に役立つでしょう。AIがどのように情報を処理し、どんな課題があるのかを知ることで、これからの開発に活かしてください！ 引用元: https://azukiazusa.dev/blog/mcp-tool-context-overflow/ Reverse engineering Codex CLI to get GPT-5-Codex-Mini to draw me a pelican この記事では、OpenAIが先日部分的にリリースした新しい大規模言語モデル「GPT-5-Codex-Mini」へのユニークなアプローチが紹介されています。このモデルは「GPT-5-Codex」の小型版で、現時点ではOpenAIの公式CLIツール「Codex CLI」やVS Code拡張機能を通じてのみ利用でき、直接APIにアクセスすることはできません。 筆者は、この新しいモデルに直接プロンプトを送りたいと考え、Codex CLIツールをリバースエンジニアリング（解析して仕組みを調べること）することに挑戦しました。Codex CLIがApache 2.0ライセンスのオープンソースであることに着目し、そのコードを改造して、モデルに直接プロンプトを送れる独自のコマンドを追加するという方法をとりました。 開発プロセスで驚くべき点は、筆者がRustというプログラミング言語のコードをほとんど書かず、その改造作業のほとんどをAIエージェントであるCodex自身に任せたことです。筆者は「codex prompt」という新しいサブコマンド（プロンプトを直接モデルに送る機能）の設計を指示し、Codex（AI）は、その指示に基づいてコードの記述、コンパイル、フォーマット、リンティングまで実行しました。筆者は主に、AIが生成したコードが意図通りに動くかを確認し、エラーが発生した際にはAIに追加の指示を与える役割でした。 開発中には、Codex CLIが利用するプライベートなAPIが特定の「指示（instructions）」を必要とすることや、AIがファイルを編集する機能（ツール実行やワークスペースアクセス）を無効にする必要性など、いくつかの課題に直面しました。これらもAIとの対話を通じて解決し、最終的にモデルが単一のプロンプトに応答するだけのシンプルなコマンドを実装できました。 この改造ツールを使って、筆者は「自転車に乗ったペリカン」のSVG画像を生成するプロンプトを、「GPT-5-Codex」「GPT-5」「GPT-5-Codex-Mini」の各モデルに送りました。結果として、GPT-5-Codex-Miniが生成した画像は「ひどい」出来栄えで、ペリカンも自転車も抽象的な形の集合体となってしまい、期待外れでした。しかし、この試みによって、OpenAIのプライベートAPIエンドポイントや、role="developer"メッセージを通じてシステムプロンプトを渡せる仕組みなど、貴重な技術的知見が得られました。 このブログ記事は、新しいAIモデルへの探求心と、AIエージェントを活用して効率的に開発を進める現代的な手法を示しており、私たちエンジニアが日々進化するテクノロジーにどのように向き合うべきかを示唆しています。 引用元: https://simonwillison.net/2025/Nov/9/gpt-5-codex-mini/ OII Study identifies weaknesses in how AI systems are evaluated 新人エンジニアの皆さん、AIの能力評価は正確に行えていますか？オックスフォード大学主導の研究が、AI（特に大規模言語モデルLLM）の能力や安全性を測る「ベンチマーク」という評価方法に科学的な弱点があることを指摘しました。この研究は、世界42の主要機関の研究者が協力し、445のAIベンチマークを分析した大規模なものです。 研究の主な課題点: 統計的な厳密さの欠如: 評価されたベンチマークのわずか16%しか、モデル間の性能差が偶然ではないことを示す統計的手法を用いていませんでした。これにより、AIが本当に改善されたのか、それともたまたま良い結果が出ただけなのか、判断が難しい状況です。 曖昧な定義: 約半数のベンチマークが「推論能力」や「無害性」といった抽象的な概念を明確に定義しないまま評価しようとしていました。測定したい能力がはっきりしないと、テストが本当にその能力を測れているのか疑問が生じます。 具体例で考えるベンチマークの落とし穴: フォーマットと能力の混同: AIが問題の答えを知っていても、特定の複雑な形式で回答できないと低評価になる場合、AIの真の能力が正しく測られていません。 「丸暗記」と「理解」の区別: 簡単な計算問題は解けても、少し条件が変わると失敗するAIは、パターンを記憶しているだけで、根本的な理解が不足している可能性があります。 結果の過度な一般化: 医療試験で高得点を取ったAIが「医師レベルの専門知識を持つ」と解釈されるのは誤解を招きます。試験と実世界の複雑な能力は異なります。 これらの弱点は、AIシステムの開発や規制において、その能力や安全性について誤った認識を生むリスクがあります。ベンチマークはAIの設計、展開、規制にも影響を与えるため、その信頼性は非常に重要です。 改善のための提言: 研究チームは、より信頼性の高いAIベンチマークを構築するための8つの提言を行っています。主な内容は以下の通りです。 測定概念の明確化と分離: 何を測りたいのかを具体的かつ操作可能に定義し、無関係な要素の影響を排除して、その能力のみを評価する。 実世界を反映した評価の構築: テスト項目が実際の利用状況や求められるスキルを適切に代表しているかを確認し、測定対象の範囲を広くカバーする。 分析と正当化の強化: 統計的手法を用いて性能差の確実性を報告し、AIが失敗した理由を詳細に分析する（エラー分析）。そして、そのベンチマークが意図

  7. 私立ずんだもん女学園放送部 podcast 20251107

    6 DE NOV.

    私立ずんだもん女学園放送部 podcast 20251107

    youtube版(スライド付き) 関連リンク Introducing Parallel Search: the highest accuracy web search API engineered for AI 皆さん、こんにちは！今回は、AI（人工知能）開発に役立つ新しいWeb検索API、「Parallel Search」が発表されたというニュースをお届けします。特にAIエージェントを作るエンジニアさんにとっては、とても興味深い内容ですよ。 これまで主流だったWeb検索エンジンは、人間がキーワードで検索し、表示されたリンクをクリックして情報を見つけることを前提に作られていました。しかし、AIエージェントは少し違います。彼らは「何をすべきか」という意図（目的）を理解し、そのタスクを効率的に達成するための「情報（トークンと呼ばれるテキストの最小単位）」を求めているのです。AIにとって最適なのは、クリック率が高いページではなく、モデルが思考・推論するために最も関連性の高い情報が詰まった部分になります。 Parallel Search APIは、このAIのニーズに特化してゼロから設計されました。主な特徴は以下の通りです。 セマンティックな目標理解: キーワードだけでなく、AIエージェントの「目的」を深く理解して検索します。 トークン関連性ランキング: AIがreasoning（推論）しやすいように、最も関連性の高い情報（トークン）を優先的に提供します。 情報密度の高い抜粋: 長いページ全体ではなく、必要な情報が凝縮された部分を効率的に抽出してくれます。 単一呼び出しでの複雑なクエリ解決: 通常、何度も検索を繰り返さないと解決できないような複雑な質問でも、少ないAPI呼び出しで答えを見つけやすくします。 これらの工夫により、AIエージェントはより少ない検索回数で、高い精度で必要な情報を手に入れられ、結果としてAPI呼び出しのコスト削減や処理速度の向上に繋がります。 実際に様々なベンチマークテストでは、Parallel Search APIは他の既存サービスと比較して、特に複数の情報源を組み合わせたり、深い理解が必要な「複雑な検索」において、約2倍の精度と約半分のコストで優れたパフォーマンスを発揮しています。シンプルな検索でも、業界トップレベルの精度を維持しつつ、最も低いコストを実現していることが示されています。 この高い性能は、Parallel社が過去2年間で独自のWebインデックスを構築し、Webクローリングからデータのインデックス化、そしてAIに最適なランキング付けまで、検索の全工程を自社で垂直統合しているからこそ実現できたものです。 AIエージェントが「コンテキストウィンドウ」（LLMが一度に処理できる情報の範囲）に、いかに質の高い情報を取り込むかが、タスク達成の鍵となります。Parallel Search APIは、この課題を解決し、AIエージェントの能力を最大限に引き出す強力なツールとなるでしょう。もし皆さんがAIエージェントの開発に携わる機会があれば、ぜひこの新しい検索APIを試してみてはいかがでしょうか。 引用元: https://parallel.ai/blog/introducing-parallel-search ビジネス出身PMが、「AIのことはエンジニアにお任せ派」から「PMもAIエージェントを自作しよう派」になるまで この記事は、コーディング経験のないビジネス出身プロダクトマネージャー（PM）が、AIエージェント開発に挑戦し、その過程で得た実践的な学びを共有しています。 筆者が開発したのは、自社サービス「バクラク申請・経費精算」のお客様の社内運用ルールを、システムで使えるルールに自動翻訳し、AIによる申請レビューが可能か評価するAIエージェントです。これにより、お客様と社内担当者の設定作業負担を減らすことを目指しました。 このエージェントを実用的なものにするため、以下の3つの工夫を凝らしています。 「利用可能な項目」をTool（ツール）で外部から与える: LLM（大規模言語モデル）に自由にルールを生成させるのではなく、データベースの項目リストを「Tool」として提供し、その中からしか使えないように制限しました。これにより、LLMが架空の項目を作るのを防ぎ、出力の正確さを向上させています。 要所で人間がレビューを挟む（HITL: Human-in-the-Loop）: エージェントが重要な判断をする際には、必ず人間が確認・修正できるステップを組み込みました。これにより、AIの誤った解釈が進行するのを防ぎ、最終的なルールの品質を保証します。 対象ルールと動作検証済ルールの「構造」が似ているかをRAGで検索する: 「タクシー代であれば〇〇」「リムジンバス代であれば〇〇」のように、具体的な値は違ってもルールの「構造」が同じものを検出するため、ルールを変数化した上でRAG（検索拡張生成）のベクトルデータベースに登録し、構造的な類似度で検索できるようにしました。 開発を通じて、筆者は以下の重要な学びを得たと述べています。 普段使っているChatGPTのような「よしなに」動くAIは、裏で多くの「お膳立て」があって初めて実現できる。素のLLMを動かすには、その土台作りが必要。 特にビジネスで使うAIエージェントは、自由にさせるのではなく、Toolやプロンプトで適切に「制御」することで初めて価値を出せる。 AIはあくまで課題解決のための「手段」であり、AI技術そのものにこだわるのではなく、お客様への価値提供という本来の目的を冷静に評価することが重要。 非エンジニアがAIエージェントを自作するには、Pythonの基礎やAI関連ライブラリの知識など、多くのスキルが求められ、一人で完遂するのは非常に困難です。しかし、社内のエンジニアからのサポートがあれば、実践を通じてPMもAI技術への理解を深めることができます。PMとエンジニアが協力してAIを活用することで、プロダクトの価値提供スピードを加速できる、というメッセージで締めくくられています。 引用元: https://tech.layerx.co.jp/entry/2025/11/06/080000 Code execution with MCP: building more efficient AI agents この記事は、AIエージェントをより効率的に動かすための新しい技術「コード実行」について解説しています。特に、AIエージェントが外部システムと連携するための標準プロトコル「MCP（Model Context Protocol）」利用時の課題解決に焦点を当てています。 新人エンジニアの皆さん、AIエージェントはGoogle DriveやSalesforceのような様々なツールと連携して複雑なタスクをこなしますが、その連携方法には工夫が必要です。 MCPの課題：AIの情報処理負担 MCPは、AIエージェントが多くの外部ツールと効率的につながるための共通ルールです。しかし、接続するツールが増えると、AI（LLM）が処理できる情報量（コンテキストウィンドウ）に負担がかかるという問題が発生します。 ツール定義で情報過多：エージェントが使えるツールの説明が多すぎると、AIは毎回大量の情報を読み込む必要があり、処理が遅くなりコストも増えます。まるで、必要なページを探すために分厚い辞書を毎回全てめくるような状態です。 中間結果も負担に：ツールを使って得られたデータ（例：会議の議事録全文）も、AIのコンテキストウィンドウを通過するたびに情報量が増え、AIの処理負担となります。これにより、データ量が多いとエラーを起こしやすくなることもあります。 コード実行による解決策：効率的な連携 この課題を解決するのが「コード実行」というアプローチです。これは、MCPサーバーを「コードAPI（プログラムから呼び出せる機能）」として扱い、AIエージェントが自分でプログラムコードを書いてツールを操作する方法です。 このアプローチには、以下のようなメリットがあります。 必要なツールだけ読み込む：AIエージェントは、タスクに必要なツールの定義だけをオンデマンドで読み込みます。これにより、無駄な情報でコンテキストウィンドウを圧迫することがなくなり、処理速度とコストを大幅に削減できます（例：15万トークンが2千トークンへ、98.7%削減）。 効率的なデータ処理：大量のデータ（例：1万行の表データ）を処理する場合でも、AIエージェントはコードを使って必要な部分だけをフィルタリングしたり整形したりできます。AIには処理済みの少ないデータだけが渡されるため、負担が軽くなります。 複雑な処理をコードで：繰り返し処理（ループ）や条件分岐、エラー処理といった複雑なロジックも、AIが直接ツールを呼び出すよりも、コードとして書く方が

  8. 5 DE NOV.

    株式会社ずんだもん技術室AI放送局 podcast 20251106

    youtube版(スライド付き) 関連リンク 2025/11/04 Builders Flash にて “AWS と LiteLLM で実現する、セキュアで柔軟な AI エージェント基盤のアーキテクチャ” を公開しました freeeのAI駆動開発チームの中山さんが、AWSの公式ブログメディア「Builders Flash」に、最新のAI技術活用に関する記事を寄稿されました。タイトルは「AWS と LiteLLM で実現する、セキュアで柔軟な AI エージェント基盤のアーキテクチャ」で、2025年11月4日に公開されています。 この記事の最も大切なポイントは、AIエージェントを企業で安全かつ効率的に動かすための「プロキシ基盤」の構築方法について解説している点です。最近、ChatGPTのような大規模言語モデル（LLM）をベースにしたAIエージェントが注目されていますが、これを実際にビジネスで使うには、情報漏洩を防ぐセキュリティ対策や、費用を抑えるためのコスト管理、そしてシステムが安定して動き続けるための仕組みなど、考慮すべき点がたくさんあります。 そこで、この記事では「LiteLLM」というオープンソースライブラリが重要な役割を果たします。LiteLLMは、OpenAIやAnthropic、Googleなど、様々なLLMサービスへのアクセスを統一された方法で扱えるようにしてくれるツールです。記事では、このLiteLLMをプロキシとして利用し、AWSのサービス（例えば、計算リソースを提供するEC2やLambda、ネットワークを安全に構築するVPCなど）と組み合わせることで、次のような大きなメリットを持つAIエージェント基盤を実現できると紹介しています。 セキュリティの強化: LLMサービスへ直接アクセスするのではなく、間にプロキシを置くことで、リクエストの内容を監視したり、認証・認可を一元的に管理したりできます。これにより、機密情報の漏洩や不正な利用を防ぎ、安全性を高めることができます。 柔軟なLLMの選択と切り替え: LiteLLMは多様なLLMプロバイダに対応しているため、もし将来、より性能が良かったり、費用が安かったりする新しいLLMが登場しても、アプリケーションのコードを大きく変更することなく、簡単に切り替えることが可能です。これは、特定のベンダーに縛られず、常に最適なAIモデルを選べるという点で非常に重要です。 コストの管理と最適化: プロキシを通じてLLMへのリクエストを集中させることで、APIの利用状況を詳細にモニタリングし、不要な利用を制限（レートリミット）するなどして、コストを効率的に管理・最適化できます。 開発効率の向上: 開発者は個々のLLMプロバイダのAPI仕様を詳しく覚える必要がなく、LiteLLMという共通のインターフェースを通して開発を進められるため、開発スピードを上げることができます。 新人エンジニアの皆さんにとって、AIエージェントを「どう使うか」だけでなく、「どうやって安全に、効率よく、そして将来性を見据えてシステムを構築するか」という視点は、これからのキャリアで非常に役立つでしょう。この記事は、AIエージェントのインフラ設計や運用に興味がある方にとって、具体的なヒントと実践的な知見を与えてくれるはずです。ぜひリンク先の記事を読んで、AIエージェント基盤の奥深さを学んでみてください。 引用元: https://developers.freee.co.jp/entry/aws-builders-flash-202511 LLM APIを2年間本番運用して苦労した話 この発表は、株式会社IVRyが電話の自動応答システムでLLM APIを2年間本番運用する中で直面した課題と、それらを乗り越えるための知見を新人エンジニアにも分かりやすく解説しています。 まず、LLM APIは様々な質問に対応できる「zero-shot learner」として非常に有用で、多くのタスクに活用できると指摘されています。しかし、既存の一般的なAPIとは異なる特有の問題があることも強調されました。 運用初期には大きな問題はなかったものの、ある日発生した大規模なAzure OpenAI障害をきっかけに、「LLM APIは必ず落ちる可能性がある」という現実を痛感。これを受けて、障害発生時に別のLLMに切り替える「フォールバック」の仕組みを導入し、さらに「監視体制を強化」しました。 しかし、フォールバックだけでは解決できない新たな課題が見つかります。それは、LLMが完全に停止するわけではなく、「応答が遅くなる（レイテンシーの悪化）」や「不正確な回答を返す（精度劣化）」といった、エラーとして検知されにくい障害パターンです。これらはフォールバックが効かないため、ユーザー体験に直接影響を与えてしまいます。 これらの問題に対し、IVRyでは以下の対策を講じました。 きめ細かい監視の実施: LLMの応答速度は、利用するモデル、入力の長さ、情報の種類（モダリティ）、出力の長さなど、様々な要因で変動します。そのため、これらの要因ごとに分けて監視することで、異常を早期に発見できるようにしました。 障害パターンごとの対応手順書（Playbook）作成と訓練: どんな異常が起きたらユーザーにどのような影響があるのか、どうやって検知するのか、そしてどのようなアクションを取るべきかを事前に具体的にまとめたPlaybookを作成。さらに、実際に障害が発生したと想定して訓練を行うことで、迅速かつ適切な対応ができるようにしました。 ライブラリ選定の注意点: LLM APIの共通化やフォールバックのために便利なライブラリ（例: LiteLLM）を使っていたものの、バージョンアップで予期せぬCPU使用率の増加が発生しました。ライブラリに頼りきるのではなく、場合によっては自前で実装することも含め、コントロールが効く選択肢を検討することの重要性が示唆されました。 まとめとして、LLM APIを安定して本番運用するためには、「障害は必ず起こる」という前提に立ち、フォールバックの仕組みだけでなく、多角的な監視、具体的な対応手順の準備、そして使用する技術スタックの選定に至るまで、徹底した対策が必要であると締めくくられています。これは、これからLLMを活用したサービス開発に挑戦する新人エンジニアにとって、非常に実践的な教訓となるでしょう。 引用元: https://speakerdeck.com/ivry_presentationmaterials/llm-apiwo2nian-jian-ben-fan-yun-yong-siteku-lao-sitahua AIを賢く動かすのは「指示力」ではなく「文脈設計力」 AIを効果的に活用するためには、細かく指示を出す「指示力」だけでなく、「AIに何を見せるか」を設計する「文脈設計力（コンテキストエンジニアリング）」が非常に重要である、という内容の記事です。特に、AIコーディングでAIとのやり取りに時間がかかってしまう新人エンジニアの皆さんに、AIの特性と賢い付き合い方を分かりやすく解説しています。 なぜAIとの会話がうまくいかないことがあるのでしょうか？その理由は、大規模言語モデル（LLM）が持ついくつかの制約にあります。 LLMは確率で動いている: AIは次に続く単語を確率的に予測して生成しています。同じ指示でも結果が微妙に変わるのはこのためです。この確率の精度は「コンテキスト（文脈）」に大きく左右されます。 会話が長くなると品質が下がる（コンテキストの腐敗）: 人間と同じで、AIも一度にすべての情報に完璧に注意を払うことはできません。会話が長くなると重要な情報が埋もれたり、途中の情報を忘れやすくなる「Lost in the Middle問題」が発生します。 記憶力には限りがある（コンテキストウィンドウ）: LLMには一度に処理できる情報量に「コンテキストウィンドウ」という上限があります。この上限を超えると、AIは古い情報を忘れてしまいます。プロジェクトルール、ツール定義、会話履歴などがこのウィンドウを圧迫し、重要な情報がAIに伝わりにくくなる原因になります。 これらの制約を踏まえ、AIを賢く動かすためには、単にプロンプトを詳しく書く「足し算」のアプローチではなく、本当に必要な情報だけをAIに見せる「引き算」のアプローチ、つまり「コンテキストエンジニアリング」が不可欠です。 具体的な対処法としては、以下のようなものがあります。 会話をこまめにリセットする: タスクが変わったり、会話が行き詰まったりしたら新しいチャットを始める。 プロジェクトルールの見直し: 使わないルールや細かすぎる指示は削除する。 ツールの整理: 今のタスクで必要なツールだけを有効化する。 関係ないファイルを除外する: AIに見せる必要のないファイルは.gitignore

Ver tudo (101)

Sobre

AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。(MC 月:春日部つむぎ、火水木:ずんだもん、金:お嬢様ずんだもん)

Informações

Você também pode gostar de