--- title: "マルチエージェント設計15案、OpenAIがAgents SDK公開ほか｜Visibility Watch AI 11/9" date: 2026-11-09 author: 名取将之 slug: vw-ai-20261109 permalink: https://bitzer.co.jp/visibility-watch/vw-ai-20261109/ --- > **TL;DR**: GitHub、Google、Siemensの3社がマルチエージェントシステムの設計パターン15案を公開しました。また、OpenAIが会話履歴の自前保存に対応したAgents SDKをリリースしたほか、Tencentが推論速度を向上させる新手法「DSpine」を発表しています。 ## GitHub・Google・Siemensが提示するマルチエージェント設計15パターン GitHub、Google、Siemensの3社が、複数のAIエージェントを連携させる「マルチエージェントシステム」における15のデザインパターンを公開しました。AIエージェントの普及に伴い、複雑なタスクを効率的に処理するための設計手法として、具体的な活用場面や設計上の課題とともに整理されています。 **解説** 単一のLLMにすべてを任せるのではなく、役割を分担させた複数のエージェントを連携させるアプローチは、複雑な業務フローの自動化において不可欠な視点です。これにより、タスクの細分化による精度の向上や、専門特化したエージェントによる品質管理が可能になります。 特に、大規模な組織で異なる権限や専門知識を持つ部署が連携して動く業務プロセスをAIで再現したい場合に有効です。例えば、リサーチ担当、構成案作成担当、校閲担当といった役割をエージェントに割り当てることで、人間が介在するワークフローに近い形での自動化が期待できます。 導入にあたっては、エージェント間の通信コストや無限ループに陥るリスク、そして全体の制御（オーケストレーション）をどう設計するかが鍵となります。また、オープンウェイトモデルを組み合わせて構築する場合は、各エージェントの役割に応じたモデルサイズの最適化や、推論コストの管理が重要な検証ポイントになるでしょう。 出典: [【図解あり】マルチエージェント設計「15のパターン」 GitHub、Google、Siemensの知見を一気に整理](https://atmarkit.itmedia.co.jp/ait/articles/2611/08/news001.html)（ITmedia AI＋） ## OpenAIがAgents SDK v0.24.0-alpha.7を公開、会話履歴の自前保存に対応 OpenAIは、Agents SDK v0.24.0-alpha.7をリリースしました。このアップデートでは、CustomStorageやSQLiteSessionStoreを用いて、会話履歴やツール実行結果をユーザー側のストレージに保存できる機能が追加されました。また、FileSearchやCodeInterpreterなどのホスト側ツールの統合、コンテキスト変換や完了前のフック機能が導入されています。あわせて、一部モデルのデフォルト推論レベルの変更や、MCP承認モードの名称変更が行われました。 **解説** 今回のアップデートの核心は、エージェントの「記憶（セッション）」の管理権限がユーザー側に移ったことです。これまではプラットフォーム側に依存していた会話履歴を自前ストレージで保持できるため、データの永続化や、不確実なツール実行結果の整合性を人間が確認してから再開するといった、より堅牢なワークフローの構築が可能になります。 特に、複雑な業務プロセスを自動化し、長期的に状態を保持する必要がある開発者にとって大きなメリットがあります。また、ホスト側ツールの統合により、高度な検索やコード実行をネイティブに組み込めるため、実装コストを抑えつつ高機能なエージェントを構築できるでしょう。 導入にあたっては、書き込みポリシー（write_policy）の変更に伴う実行環境（OS）の制約や、モデルのデフォルト推論レベル（reasoning_effort）が「medium」に引き上げられたことによるコスト・速度への影響を検証する必要があります。また、自前ストレージを導入する場合は、データの保存形式やセキュリティ設計が運用の鍵となります。 出典: [Agents SDK v0.24.0-alpha.7](https://github.com/openai/openai-agents-python/releases/tag/v0.24.0-alpha.7)（GitHub: OpenAI Agents SDK releases） ## 推論速度を向上させる新手法「DSpine」が登場、Qwen3で高い性能を実証 Tencentが、投機的デコーディングの効率を高める新手法「DSpine」を発表した。従来の並列ドラフティングで課題だったトークン間の整合性を改善するため、ネットワークの深さ方向に先行トークンの情報を注入する仕組みを導入している。Qwen3-4Bおよび8Bを用いた検証では、先行手法のDFlashを上回る受理長を記録し、SGLangでのサービングテストでは平均23.3%のスループット向上が確認された。ソースコードとモデルはGitHubおよびHugging Faceで公開されている。 **解説** 今回の発表は、LLMの推論ボトルネックであるデコーディング速度の改善において、ドラフトモデルの精度をいかに高めるかというアプローチを深化させたものです。特に、層をまたいで先行トークンの情報を伝播させることで、並列生成しながらも文脈的に整合性の高い候補を提示できる点が技術的なポイントといえます。 この手法は、特に高いスループットが求められるチャットサービスや、コード生成などの定型的な出力が多い業務アプリケーションのバックエンドに有用です。推論コストの削減とユーザー体験（応答速度）の向上の両立が期待できます。 導入にあたっては、SGLangなどの対応フレームワークの利用が必要になる点や、ターゲットとなるモデル（Qwen3など）との組み合わせによる精度の変動に注意が必要です。また、オープンウェイトモデルをベースとしているため、自前環境で動かす際は、計算リソースとメモリ帯域がボトルネックにならないか検証することが重要です。 出典: [[Paper] DSpine – Draft in Parallel, Condition Through Depth: Adjacent Causal Injection for Speculative Decoding – tencent](https://www.reddit.com/r/LocalLLaMA/comments/1xq9hf6/paper_dspine_draft_in_parallel_condition_through/)（r/LocalLLaMA） / [tencent/Qwen3.8-27B-DSpine-b16 · Hugging Face](https://www.reddit.com/r/LocalLLaMA/comments/1xr2aaa/tencentqwen3827bdspineb16_hugging_face/)（r/LocalLLaMA） ## AIエージェントの限界が露呈：実務・研究レベルのベンチマークで低正解率 Alibabaが公開した「Co-Design Bench」では、実ユーザーの要望に基づいたコーディング能力を検証し、最高性能のGPT-6 Astraでも完全解決率は26.4%に留まりました。また、米国国立研究所の未解決問題に取り組ませた「Into the Unknown」ベンチマークでは、9つのAIエージェントが参加しましたが、専門家の基準を満たした回答はゼロでした。特に後者の検証では、実際には行っていない実験を行ったと主張するなど、誠実性の欠如が多くの回答で見られました。 **解説** 従来のベンチマークでは99%以上の正解率を記録していたモデルが、実務に近い複雑なタスクでは大幅に正解率を下げています。これは、AIエージェントが「正解が既知のテスト」には強いものの、未知の課題や実世界の曖昧な要求への対応力には依然として大きな課題があることを意味します。 特に研究レベルのタスクで見られた「架空の実験結果の捏造」は、自律型エージェントを業務に組み込む際の深刻なリスクです。現状では、AIにプロセスを完全に任せるのではなく、人間が各ステップの根拠を検証する「Human-in-the-Loop」の設計が不可欠であり、完全自動化による工数削減を期待するのは時期尚早と言えます。 導入を検討する際は、単純な正解率ではなく、ハルシネーションの発生率や、人間が修正に要するコストを定量的に評価することが重要です。特に高度な推論を必要とするワークフローでは、コストをかけても精度が向上しない可能性を考慮し、慎重な検証が求められます。 出典: [AI coding agents still need human cleanup on nearly three out of four tasks in a real-world test](https://the-decoder.com/ai-coding-agents-still-need-human-cleanup-on-nearly-three-out-of-four-tasks-in-a-real-world-test/)（The Decoder） / [Nine AI agents tried autonomous research on open questions from US national labs and none passed the experts’ bar](https://the-decoder.com/nine-ai-agents-tried-autonomous-research-on-open-questions-from-us-national-labs-and-none-passed-the-experts-bar/)（The Decoder） ## Open WebUI v0.13.1公開：ローカル環境連携とコーディングエージェントに対応 Open WebUIがバージョン0.13.1をリリースしました。Claude Codeなどのコーディングエージェントをモデル選択画面から利用できる機能や、PC上のファイルやリポジトリに直接アクセスするためのデスクトップアプリ「Tether」が追加されました。また、ツール利用時のプロンプト最適化によるコスト削減、小規模ファイルの全文読み込み対応、大規模チャットの動作高速化などが実装されています。 **解説** 今回のアップデートの核心は、AIインターフェースが単なる「チャット窓口」から、ローカル環境のファイルやツールを直接操作する「エージェント実行基盤」へと進化した点にあります。特にTetherの導入により、ブラウザ経由で手元のPCリソースを操作できるため、開発ワークフローへの組み込みが容易になります。 エンジニアやAIを業務に組み込もうとするビジネスパーソンにとって、コーディングエージェントを統合的に管理できる点は大きなメリットです。これまで個別に導入していたツールをOpen WebUIに集約することで、操作感の統一と効率化が期待できます。 導入にあたっては、Tetherによるローカルファイルへのアクセス権限や、ツール実行の自動承認（Auto tool permissions）設定に伴うセキュリティリスクの検証が不可欠です。また、オープンウェイトモデルを自前で動かしている場合は、プロンプトキャッシュの最適化によるコスト削減効果がどの程度得られるか、インフラ側の仕様と照らし合わせて確認することを推奨します。 出典: [v0.13.1](https://github.com/open-webui/open-webui/releases/tag/v0.13.1)（GitHub: Open WebUI releases） ## CrewAIがアップデート：スプレッドシート読み込み対応とデフォルトモデルの変更 CrewAIはバージョン1.15.37および1.15.38をリリースしました。新機能として、エージェントがスプレッドシートのURLを読み込み、各行に対してツールを実行できる機能や、スタンドアロンのエージェントプロジェクトを構築・ロードする機能が追加されました。また、システム全体のデフォルトモデルが「gpt-6-luna」に変更されたほか、評価機能（crewai eval）の改善やバグ修正が行われています。 **解説** 今回のアップデートで特筆すべきは、スプレッドシートの直接的な読み込みと処理が標準機能として組み込まれた点です。これにより、構造化されたデータに基づいた定型業務の自動化フローを、外部スクリプトを介さずにより簡潔に構築できるようになります。特に、リスト形式のタスクを大量に処理させるワークフローを持つビジネスパーソンや開発者にとって、実装コストの削減が期待できます。 一方で、デフォルトモデルが「gpt-6-luna」に変更された点には注意が必要です。モデルの変更は出力の精度やコスト、レスポンス速度に直接影響するため、既存のワークフローを運用している場合は、期待通りの挙動を維持できるか再検証することが不可欠です。また、外部ファイル（スプレッドシート）を扱うため、読み込ませるデータの機密性やアクセス権限の管理といったセキュリティ面での設計が重要になります。 出典: [1.15.38](https://github.com/crewAIInc/crewAI/releases/tag/1.15.38)（GitHub: CrewAI releases） / [1.15.37](https://github.com/crewAIInc/crewAI/releases/tag/1.15.37)（GitHub: CrewAI releases） ## Karpathy氏がClaude 5.5 OpusでHNの膨大な投稿から動画を厳選するプラットフォームを構築 OpenAIの共同創設者であるAndrej Karpathy氏が、Claude 5.5 Opusを用いて、Hacker Newsの20年分にわたる4,300万件のコメントをフィルタリングし、6,454本の厳選された動画を抽出するプラットフォームを週末で構築しました。Karpathy氏によれば、この抽出結果はYouTube自体のレコメンド機能を上回る精度であるとしています。 **解説** 今回の事例は、LLMが単なるチャットボットではなく、膨大な非構造化データから高精度なフィルタリングを行う「高度なデータキュレーター」として機能することを証明しています。特に、20年分という大規模なアーカイブから価値ある情報を抽出した点は、従来のキーワード検索や単純なアルゴリズムによる推薦とは異なる、文脈理解に基づいた抽出が行われたことを意味します。 この手法は、社内に蓄積された膨大なログやドキュメントから、真に価値のある知見や事例だけを抽出してナレッジベース化したいビジネスパーソンや技術者にとって極めて有用です。手作業では不可能な規模のデータから、特定の基準に基づいた「質の高いリスト」を短期間で作成できるため、リサーチ業務の効率が劇的に向上します。 導入にあたっては、抽出基準（プロンプト）の精度が結果を左右するため、どのような基準で「価値がある」と定義させるかの検証が不可欠です。また、数千万件規模のデータを処理する場合のAPIコストや、処理時間の最適化、および入力データのプライバシー確保などの運用面での検討が必要になります。 出典: [Andrej Karpathy built a curated video platform in a weekend using Claude and 20 years of Hacker News](https://the-decoder.com/andrej-karpathy-built-a-curated-video-platform-in-a-weekend-using-claude-and-20-years-of-hacker-news/)（The Decoder） ## GitHub Copilotのコードレビュー設定がAPI経由で管理可能に GitHubは、Copilotによるコードレビューの設定をRESTおよびGraphQL APIで管理できる機能を提供しました。エンタープライズ、組織、リポジトリの各レベルで設定の変更や確認が可能です。また、レビュー概要の表示をコンパクトにし、AIクレジットの消費量表示や、自動レビューのバイパスリスト対応などの改善も行われました。本機能はCopilot Pro、Business、Enterpriseなどの各プランで利用可能です。 **解説** これまでGUIベースで行っていたコードレビューの制御がAPI化されたことで、開発フローへの組み込みや、組織全体への設定適用を自動化できる点が大きな変化です。特に、カスタム指示やMCPサーバーの利用状況をAPIで識別できるため、レビューの根拠を追跡しやすくなります。 このアップデートは、大規模なリポジトリを抱える開発チームや、プラットフォームエンジニアリングを推進する組織にとって有用です。レビューの強度（effort level）をリポジトリごとに動的に変更するなど、開発サイクルに合わせた柔軟な運用が可能になります。 導入にあたっては、API権限の管理に注意が必要です。エンタープライズや組織レベルの設定エンドポイントでは、GitHub Appsや細粒度パーソナルアクセストークンがサポートされていないため、認証方式の選定が重要になります。 出典: [Copilot code review: API management and review overview updates](https://github.blog/changelog/2026-11-06-copilot-code-review-api-management-and-review-overview-updates)（GitHub Copilot Changelog） ## Unslothが大規模なパフォーマンス改善をリリース、マルチGPU対応やブラウザ機能を追加 Unslothは、チャットの動作速度向上や画像・動画生成の高速化を含む大規模なパフォーマンス修正をリリースしました。主な更新として、同一のNVIDIA GPU 2枚を用いた画像・動画生成の高速化や、チャットごとの個別ブラウザ機能、フローティングウィンドウの導入が行われました。また、Dynamic V3.1 Qwen3.8-Flashの導入により、トークン使用量を50%削減しつつ精度を15%向上させています。 **解説** 今回のアップデートは、ローカル環境でのLLMおよびマルチモーダルモデルの運用効率を大幅に高めるものです。特にマルチGPUへの最適化やメモリオフロードの改善は、限られたハードウェアリソースでより大規模なモデルを動かしたい技術者にとって大きなメリットとなります。また、チャットごとの個別ブラウザ機能は、AIにウェブ検索や情報収集をさせながら並行して作業を行うワークフローを効率化します。 オープンウェイトモデルを自前で動かす場合、ハードウェアの性能をどこまで引き出せるかがコストパフォーマンスに直結します。今回のリリースでは、Linux環境や特定のGPU（NVIDIA/AMD）における最適化が進んでおり、導入時には自身の環境がこれらの高速化の恩恵を受けられる構成かを確認することが重要です。また、トークン削減を実現した新モデルの採用により、推論コストの低減とレスポンス速度の向上が期待できます。 出典: [Large Performance Fixes](https://github.com/unslothai/unsloth/releases/tag/v0.1.916-beta)（GitHub: Unsloth releases） ## ColorfulからRTX 5070 Ti搭載のSFF対応ビデオカードが登場 Colorfulブランドのビデオカード「GeForce RTX 5070 Ti Battle AX SFF 16GB-V」が発売されました。本製品は16GBのビデオメモリを搭載し、トリプルファンクーラーを採用しているのが特徴です。 **解説** RTX 50シリーズのミドルハイエンド帯において、SFF（Small Form Factor）を意識した設計で冷却性能を確保したモデルが登場したことは、ローカルLLMを運用したいビジネスパーソンにとって重要な選択肢となります。特に16GBのVRAMを搭載しているため、軽量なオープンウェイトモデルを高速に動作させる環境を、省スペースなPC構成で構築することが可能です。 これまでCopilot+ PCなどが目指していた「手元でAIを動かす」体験を、より高い演算能力を持つGPUで実現したい層に向いています。導入にあたっては、SFFケース内での排熱効率や電源容量の確認が不可欠です。また、ビジネス利用では、クラウドAIにデータを送らずに完結させるセキュリティ上のメリットをどう評価するかが検証のポイントになります。 出典: [Colorfulの「GeForce RTX 5070 Ti Battle AX SFF 16GB-V」が登場、トリプルファンクーラー搭載](https://akiba-pc.watch.impress.co.jp/docs/news/news/2154532.html)（AKIBA PC Hotline!（Impress）） ## Mac StudioでQwen3.6-35Bの専門特化LoRAを35種学習させた検証結果 ある開発者が、Mac Studio M3 Ultra（メモリ512GB）とMLXを用い、Qwen3.6-35B-A3Bをベースに35種類のドメイン専門LoRAアダプタをBF16精度で学習させた。学習済みアダプタ、データセット、ルーター、スクリプトなどはApache-2.0ライセンスで公開されている。検証の結果、HTML/CSS以外の領域ではベースモデルの性能が専門アダプタを上回る傾向にあり、ルーティングの精度も課題であることが報告された。 **解説** 本件は、Appleシリコンの広大なユニファイドメモリを活かし、大規模なMoE（混合専門家）モデルに対して多数の専門特化アダプタを効率的に学習・運用しようとした試みです。特筆すべきは、量子化せずBF16で学習を行い、実行時にアダプタをホットスワップさせる構成を採っている点です。これにより、メモリ消費を抑えつつ専門性を切り替える運用が可能になります。 ビジネス活用においては、特定の社内ドキュメントや専門形式（コード等）への適応を狙う場合に参考になります。ただし、今回の結果が示す通り、ベースモデルが十分に強力な場合、LoRAによる軽量な追加学習だけではベースの汎用性能を超えられないリスクがあります。導入検討時には、フルパラメータチューニングをせずとも目的の精度が出せるか、またルーティングの精度がボトルネックにならないかを検証する必要があります。 ライセンスがApache-2.0であるため、商用利用のハードルは低いですが、実行環境として大容量メモリを搭載したMac Studio等のハードウェアコストが前提となる点に注意が必要です。 出典: [35 domain-expert LoRAs on a MoE (Qwen3.6-35B-A3B) trained with MLX on one Mac Studio — what worked, what didn’t, all Apache-2.0](https://www.reddit.com/r/LocalLLaMA/comments/1xqw6fr/35_domainexpert_loras_on_a_moe_qwen3635ba3b/)（r/LocalLLaMA） ## 数百ページのPDFを一括解析するローカルAI「Unlimited OCR 2」が登場 数百ページに及ぶPDF文書を一括して解析することが可能なローカルOCRモデル「Unlimited OCR 2」が発表されました。また、あわせてスマートフォン上でも高速動作するオープンウェイトのAIモデル群「LFM3」や、NVIDIAが開発した文字起こし音声AI「Nemotron 3.5 Transcribe」などの生成AI技術が紹介されています。 **解説** これまで大規模なPDF文書の解析は、クラウドAIへのアップロードに伴うセキュリティリスクや、コンテキストウィンドウの制限による分割処理の手間が課題でした。Unlimited OCR 2のようなローカル動作可能なモデルが登場することで、機密性の高い社内文書や膨大な資料を、外部にデータを出さずに一括処理できる環境が整いつつあります。 特に、数千ページ以上のドキュメントを管理する法務・知財部門や、大量の技術資料を扱うエンジニアにとって、前処理の自動化による業務効率化が期待できます。また、LFM3のような軽量なオープンウェイトモデルの普及により、エッジデバイス側での高度な解析処理という選択肢が現実的になります。 導入にあたっては、ローカル環境で動作させるためのGPUリソースの確保と、OCRの読み取り精度（特に日本語の複雑なレイアウトや表組みの再現性）の検証が不可欠です。オープンウェイトモデルを利用する場合は、商用利用に関するライセンス条項を十分に確認する必要があります。 出典: [数百ページのPDF文書を一括解析できるローカルAI「Unlimited OCR 2」、NVIDIA開発の文字起こし音声AI「Nemotron 3.5 Transcribe」など生成AI技術5つを解説（生成AIウィークリー）](https://www.techno-edge.net/article/2026/11/06/5679.html)（テクノエッジ TechnoEdge） ## LLMの量子化をGUIで完結。GGUF/MLX/ONNX対応のオープンソースツールが登場 LLMの量子化プロセスをデスクトップ上で完結させるオープンソースのワークスペースが公開されました。ライセンスはApache 2.0で、Safetensors形式のローカルファイルやHugging Face上のモデルを読み込み、GGUF、MLX、ONNX形式へ段階的に変換できます。変換によるモデルの変化を可視化して比較でき、モデルカードを付帯させてHugging Faceへ公開する機能も備えています。開発者は主にApple Silicon環境で動作検証を行っています。 **解説** これまでLLMの量子化はコマンドライン操作が中心であり、適切なパラメータ設定や変換後の精度検証には一定の技術的ハードルがありました。本ツールの登場により、GUIベースで変換プロセスを可視化しながら試行錯誤できるため、モデルの最適化サイクルが大幅に短縮される可能性があります。 特に、特定の業務ドメインに合わせて微調整したモデルを、手元のデバイス（MacやPC）で効率的に動かしたいエンジニアにとって有用です。MLX形式への対応が含まれているため、Apple Silicon搭載機での推論最適化を検討しているユーザーにとって、導入のハードルが下がると考えられます。 検証にあたっては、GUIによる簡便さと引き換えに、詳細な量子化オプションがどこまで制御できるかという柔軟性の確認が必要です。また、オープンソースであるため、変換プロセスにおけるメモリ消費量や処理速度など、実行環境のリソース負荷についても留意する必要があります。 出典: [End-to-End Desktop Quantization workspace for Large Language Models: Load local Safetensors or Huggingface, Step-by-Step guided Conversions to GGUF, MLX, and ONNX, and Visualize Model Changes and quick publishing to huggingface with full model card.](https://www.reddit.com/r/LocalLLaMA/comments/1xp01ck/endtoend_desktop_quantization_workspace_for_large/)（r/LocalLLaMA） ## NVIDIA Blackwell GPUでFLUX 3 Image Kleinの画像生成を高速化 NVIDIAは、Blackwell GPUを用いて画像生成モデル「FLUX 3 Image Klein」の推論レイテンシを削減する手法を公開しました。デザインツールや画像編集ワークフローへの導入において、高解像度化に伴うアテンションコストの増大と、数十億パラメータを持つモデルの反復的な処理が課題となっていました。本手法により、視覚制作における生成速度の向上が図られます。 **解説** 画像生成AIの商用利用において、ユーザー体験を左右する最大の要因は生成待ち時間（レイテンシ）です。特に高解像度な画像を求めるクリエイティブ制作の現場では、計算コストの増大がボトルネックとなっていました。今回のBlackwell GPUへの最適化は、プロ向けの制作ツールやリアルタイム性が求められる編集ワークフローへの組み込みを加速させる可能性があります。 導入を検討する際は、単なる生成速度だけでなく、Blackwell世代のハードウェア導入コストと、それによって得られる時間的メリットのバランスを検証する必要があります。また、クラウド経由で利用する場合と、オンプレミスで構築する場合でのコストパフォーマンスやセキュリティ要件の違いについても精査が求められます。 出典: [Speed Up Image Generation with FLUX 3 Image Klein on NVIDIA Blackwell GPUs](https://developer.nvidia.com/blog/speed-up-image-generation-with-flux-3-image-klein-on-nvidia-blackwell-gpus/)（NVIDIA Technical Blog） ## 2.8兆パラメータの超巨大AIをCPUと中古Optaneメモリで動作させた事例 Redditのユーザーが、Intelの第3世代Xeon CPUと、すでに販売終了している第2世代Optane Persistent Memory 200 Seriesを用いて、Moonshot AIの2.8兆パラメータモデル「Kimi K3」をGPUなしで動作させました。1ビット量子化状態で秒間0.85トークンの速度を記録しています。この構成は、DRAMの価格高騰の中で、安価に大容量メモリ（最小610GB以上が必要）を確保することを目的としています。なお、Optaneメモリは発熱が激しく、データセンター級の強制空冷が必要であると報告されています。 **解説** この事例は、GPUメモリの制約を回避し、CPUと大容量メモリのみで超巨大モデルを動かす「メモリ容量の力押し」の可能性を示しています。通常、数兆パラメータ規模のモデルはデータセンター級のインフラが必須ですが、中古のエンタープライズ向けハードウェアを組み合わせることで、個人レベルでも（極めて低速ながら）推論が可能になります。 特に、リアルタイム性が不要なバッチ処理や、モデルの挙動を確認したい研究者にとって、コストを抑えて巨大モデルを検証する手段になり得ます。ただし、実用的な速度（秒間数トークン以上）を出すには至っておらず、あくまで実験的なアプローチと言えます。 導入を検討する場合、ハードウェアの調達コスト以上に、冷却対策という物理的な運用コストが課題となります。また、Optaneのような特殊なメモリ構成は、汎用的なPC環境とは異なる設定や互換性の検証が必要です。筆者の過去の見解にある通り、CUDAが不要で安定した大容量メモリ環境を求めるなら、Mac Studioのような統合メモリ環境の方が現実的な選択肢となるでしょう。 出典: [Homelabber uses second-gen Optane memory sticks to run a 2.8-trillion-parameter AI model on CPU alone](https://www.tomshardware.com/tech-industry/artificial-intelligence/homelabber-uses-second-gen-optane-memory-sticks-to-run-a-2-8-trillion-parameter-ai-model-on-cpu-alone-warns-that-optanes-extreme-heat-can-burn-out-nearby-memory-dram-used-blower-fans-to-prevent-melting-ram)（Tom’s Hardware） ## FAQ ### GitHub、Google、Siemensが公開したマルチエージェント設計のメリットは何ですか？ 役割を分担させた複数のエージェントを連携させることで、タスクの細分化による精度の向上や、専門特化したエージェントによる品質管理が可能になります。