<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>生成AI on hagizo.io</title><link>https://ha.gizwoo.com/tags/%E7%94%9F%E6%88%90ai/</link><description>Recent content in 生成AI on hagizo.io</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Thu, 21 May 2026 08:10:57 +0900</lastBuildDate><atom:link href="https://ha.gizwoo.com/tags/%E7%94%9F%E6%88%90ai/index.xml" rel="self" type="application/rss+xml"/><item><title>【AIニュース】非トランスフォーマーLLMの台頭と中国勢の推論コスト競争</title><link>https://ha.gizwoo.com/non-transformer-llm-cost-war-tfrwbnjvkp/</link><pubDate>Wed, 20 May 2026 10:00:00 +0900</pubDate><guid>https://ha.gizwoo.com/non-transformer-llm-cost-war-tfrwbnjvkp/</guid><description>&lt;p&gt;AI業界において、2026年5月は大きな転換点として記憶されるかもしれない。長年支配的だったトランスフォーマーというアーキテクチャへの具体的な挑戦が製品として現れ、中国の主要AI各社が猛スピードでオープンウェイトモデルをリリースし、消費電力を根本から変えうるアプローチが論文だけでなく実用システムとして発表された。個々の出来事ではなく、これらが一斉に起きていることに注目したい。&lt;/p&gt;
&lt;h2 id="subq二乗の壁を突き破った非トランスフォーマーllm"&gt;SubQ：「二乗の壁」を突き破った非トランスフォーマーLLM
&lt;/h2&gt;&lt;p&gt;AIの基盤技術として長く君臨してきたトランスフォーマーアーキテクチャには、根本的な制約がある。注意機構（アテンション、モデルがテキスト内のどの部分に注目するかを決める仕組み）の計算コストが、扱うテキストの長さに対して「二乗のオーダー」で増える点だ。文章の長さが2倍になれば計算量は4倍、10倍になれば100倍になる。これがAIモデルが非常に長いテキストを処理しにくい主な理由のひとつである。&lt;/p&gt;
&lt;p&gt;2026年5月5日、マイアミを拠点とするスタートアップ「Subquadratic社」が、その壁を破ったと主張するモデル &lt;a class="link" href="https://subq.ai/introducing-subq" target="_blank" rel="noopener"
 &gt;SubQ&lt;/a&gt; を発表した。調達額は約44億円（2900万ドル）のシードラウンドだ。&lt;/p&gt;
&lt;p&gt;SubQの核心は「サブクワドラティック・スパース・アテンション（SSA）」と呼ばれる独自の仕組みにある。すべてのトークン（単語を細かく分割した断片）の組み合わせを計算するのではなく、重要な関係だけに絞って計算する。これにより計算コストがほぼ線形（O(n)、文章が2倍になっても計算量は約2倍程度）に抑えられるという。&lt;/p&gt;
&lt;p&gt;&lt;a class="link" href="https://www.eweek.com/news/subquadratic-subq-12m-token-llm-neuron/" target="_blank" rel="noopener"
 &gt;eWeek の報告&lt;/a&gt;によると、コンテキストウィンドウ（一度に扱えるテキストの長さ）は1200万トークンに達する。これは小説数百冊分に相当する量だ。FlashAttention（トランスフォーマーの高速化手法）と比べると、100万トークン時点で約52倍高速だという。価格もClaude OpusやGPT-5.5の約5分の1とされている。&lt;/p&gt;
&lt;p&gt;実務への示唆は大きい。長大なコードベースの一括解析、法律文書の全文読み込み、数年分のメールスレッドを一度に処理するといった「長文脈タスク」が劇的に安くなる可能性がある。&lt;/p&gt;
&lt;h3 id="実務上の示唆"&gt;実務上の示唆
&lt;/h3&gt;&lt;ul&gt;
&lt;li&gt;コスト面から長文脈AIの活用を見送っていた場面でも、SubQは現実的な選択肢になりうる&lt;/li&gt;
&lt;li&gt;現時点ではベンダー（開発元）以外の第三者による独立した性能検証が存在しない。採用判断は独立した評価が出てから行うべきだ&lt;/li&gt;
&lt;li&gt;「トランスフォーマーがすべて」ではなくなる可能性を示しており、AIアーキテクチャの多様化が本格化するかもしれない&lt;/li&gt;
&lt;li&gt;長文脈が必要なユースケースを抱える組織は、今のうちに要件を整理しておくと選択肢の評価がしやすくなる&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="中国4社が12日間で4つのオープンウェイトコーディングモデルを投入"&gt;中国4社が12日間で4つのオープンウェイトコーディングモデルを投入
&lt;/h2&gt;&lt;p&gt;2026年4月7日から4月24日の間、わずか12日間で中国の主要AI企業4社が立て続けにオープンウェイト（モデルの重みが公開されており、手元のサーバーで動かせる）コーディングモデルをリリースした。&lt;a class="link" href="https://www.abhs.in/blog/chinese-open-weights-models-4-in-12-days-glm-minimax-kimi-deepseek-cost-war-2026" target="_blank" rel="noopener"
 &gt;各社の比較記事&lt;/a&gt;によると詳細は次のとおりだ。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Z.ai の &lt;a class="link" href="https://dev.to/bean_bean/the-late-april-2026-chinese-llm-stack-qwen-36-deepseek-v4plus-kimi-k26-minimax-m27-glm-51-2bif" target="_blank" rel="noopener"
 &gt;GLM-5.1&lt;/a&gt;&lt;/strong&gt;：総パラメータ数7440億・一度の処理で使うアクティブパラメータ約400億、コンテキスト200K（20万トークン）&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Moonshot の &lt;a class="link" href="https://codersera.com/blog/kimi-k2-6-vs-deepseek-v4-vs-glm-5-1-2026/" target="_blank" rel="noopener"
 &gt;Kimi K2.6&lt;/a&gt;&lt;/strong&gt;：総パラメータ数1兆・アクティブ約320億、コンテキスト256K&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;MiniMax の &lt;a class="link" href="https://andrew.ooo/answers/minimax-m2-7-vs-kimi-k2-6-vs-glm-5-1-vs-deepseek-v4-may-2026/" target="_blank" rel="noopener"
 &gt;M2.7&lt;/a&gt;&lt;/strong&gt;：MoE（複数の小さなモデルを組み合わせて動かすアーキテクチャ）採用、最大100万トークンのコンテキスト&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;DeepSeek の &lt;a class="link" href="https://artificialanalysis.ai/articles/deepseek-is-back-among-the-leading-open-weights-models-with-v4-pro-and-v4-flash" target="_blank" rel="noopener"
 &gt;V4&lt;/a&gt;&lt;/strong&gt;：V4-Pro（総数1.6兆パラメータ）とV4-Flash（2840億）の2バリアント&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;コーディングのエージェント評価指標「SWE-Bench Pro（ソフトウェアエンジニアリングの自動化タスクを評価するベンチマーク）」では、Kimi K2.6が58.6%でトップ、僅差でGLM-5.1が58.4%、DeepSeek V4-Proが55.4%と続く。いずれもClaude OpusやGPT-5.5の推論コストの3分の1以下で提供されている。&lt;/p&gt;
&lt;p&gt;この動きの意味は単なる性能競争ではない。オープンウェイトという形式でモデルが公開されると、企業は自社サーバーで動かすことができ、APIの利用料を払い続ける必要がなくなる。特に大量のコード生成・レビューを行う組織にとって、コスト構造が根本から変わる可能性がある。各モデルの特徴を整理すると、ベンチマーク総合ではGLM-5.1、コーディングエコシステムではKimi K2.6、長大な文書処理ではMiniMax M2.7、コストパフォーマンスではDeepSeek V4がそれぞれ強みを持つ。&lt;/p&gt;
&lt;h3 id="実務上の示唆-1"&gt;実務上の示唆
&lt;/h3&gt;&lt;ul&gt;
&lt;li&gt;自社インフラへのオープンウェイトモデルの展開が、API費用削減の現実的な手段になりつつある&lt;/li&gt;
&lt;li&gt;コーディング支援用途であれば、西側最前線モデルと比肩する性能をずっと低コストで得られる可能性がある&lt;/li&gt;
&lt;li&gt;12日間で4モデルというリリースペースは今後も続くと考えておくべきだ。ベンダーロックインを避けた柔軟なシステム設計が重要になる&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="ニューロシンボリックaiが消費電力を100分の1に削減"&gt;ニューロシンボリックAIが消費電力を100分の1に削減
&lt;/h2&gt;&lt;p&gt;AIの大きな課題のひとつが電力消費だ。大規模LLMの訓練・推論は膨大なエネルギーを使い、データセンターの電力不足が社会問題になりつつある。この問題へのアプローチが、2026年4月にタフツ大学工学部から発表された。&lt;/p&gt;
&lt;p&gt;Matthias Scheutz教授率いる研究チームが開発したのは、「ニューロシンボリックAI」と呼ばれるシステムだ。ニューラルネットワーク（大量のデータからパターンを学習する仕組み）と、シンボリック推論（論理ルールと記号を使ってステップごとに考える仕組み）を組み合わせる。人間が「直感」と「論理的思考」を使い分けるように、AIも状況に応じて両方の能力を切り替える発想だ。&lt;/p&gt;
&lt;p&gt;&lt;a class="link" href="https://www.sciencedaily.com/releases/2026/04/260405003952.htm" target="_blank" rel="noopener"
 &gt;ScienceDaily の報告&lt;/a&gt;によれば、このシステムはロボット計画タスクにおいて、標準的なVLAモデル（視覚・言語・行動を統合したロボット向けAI）の100分の1の電力で動作し、精度95%を達成した。一方、従来の標準的なVLAモデルの精度は34%にとどまった。消費電力を1%にしながら精度は約3倍という結果だ。&lt;/p&gt;
&lt;p&gt;この研究は2026年5月にウィーンで開催される「国際ロボティクス・オートメーション会議（ICRA）」で発表された。エッジ推論（ユーザーや機器の近くにある小型コンピューターでAIを動かすこと）や、バッテリー駆動のロボット・ドローンへの応用可能性が高い。「AIは電力を大量に消費するもの」という前提が、少なくとも特定のタスクでは覆されつつある。&lt;/p&gt;
&lt;h3 id="実務上の示唆-2"&gt;実務上の示唆
&lt;/h3&gt;&lt;ul&gt;
&lt;li&gt;ロボット・IoT・自律移動体への軽量AI組み込みを検討する場合、ニューロシンボリックアプローチは検討に値する&lt;/li&gt;
&lt;li&gt;「エネルギー効率」を重視するAI要件では、純粋なLLMに頼らない選択肢が現実的になりつつある&lt;/li&gt;
&lt;li&gt;現状は特定タスク向けの研究段階であり、汎用LLMとの直接比較はできない。補完的な用途からPoC（試作・実証実験）を始めるのが現実的だ&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="まとめ"&gt;まとめ
&lt;/h2&gt;&lt;p&gt;2026年5月のAI動向を一言で表すなら「多様化と低コスト化の加速」だ。SubQはトランスフォーマーを前提としない新アーキテクチャの可能性を示し、中国の4モデルは推論コストの基準を一段と引き下げた。ニューロシンボリックAIは「大きく、電力を食う」というAIのイメージそのものを問い直している。次の半年で、これらのアプローチがどれだけ実用化されるかに注目したい。&lt;/p&gt;</description></item><item><title>AIサービスの課金は「月額」から「トークン従量制」へ：背景と今後の予想</title><link>https://ha.gizwoo.com/ai-token-based-pricing-k7mqp4vzx9/</link><pubDate>Tue, 28 Apr 2026 20:07:00 +0900</pubDate><guid>https://ha.gizwoo.com/ai-token-based-pricing-k7mqp4vzx9/</guid><description>&lt;p&gt;AIサービスの課金は、単純な月額サブスクリプションから、入力・出力・キャッシュ・バッチ・優先処理・エージェント実行環境までを細かく分ける従量制へ移っています。OpenAI、Anthropic、Google、Microsoft、DeepSeekの料金体系を見ると、各社は「何回使ったか」ではなく「どれだけ計算資源を消費したか」を価格に反映する方向へ進んでいます。本記事では、その事実、背景、そして今後起こりそうな変化を整理します。&lt;/p&gt;
&lt;h2 id="トークン単位課金が標準になりつつある"&gt;トークン単位課金が標準になりつつある
&lt;/h2&gt;&lt;p&gt;OpenAIのAPI料金は、モデルごとに入力トークン、キャッシュ済み入力トークン、出力トークンを分けて価格を示しており、Batch APIでは入力と出力を50%割引で処理できると案内しています &lt;a class="link" href="https://openai.com/api/pricing/" target="_blank" rel="noopener"
 &gt;OpenAI API Pricing&lt;/a&gt;。さらにOpenAIはPriority processingを用意し、通常より高いトークン単価を払うことで、低遅延とSLAを得られるサービス階層を提供しています &lt;a class="link" href="https://openai.com/api-priority-processing/" target="_blank" rel="noopener"
 &gt;OpenAI Priority Processing&lt;/a&gt;。&lt;/p&gt;
&lt;p&gt;AnthropicもClaude APIで、Base Input Tokens、Cache Writes、Cache Hits &amp;amp; Refreshes、Output Tokensを分けて課金しています &lt;a class="link" href="https://docs.anthropic.com/en/docs/about-claude/pricing" target="_blank" rel="noopener"
 &gt;Claude API Docs&lt;/a&gt;。同社はBatch APIで入力・出力トークンを50%割引にし、長文コンテキストでは200K入力トークンを超えるリクエストに別料金を適用すると説明しています &lt;a class="link" href="https://docs.anthropic.com/en/docs/about-claude/pricing/" target="_blank" rel="noopener"
 &gt;Claude API Docs&lt;/a&gt;。&lt;/p&gt;
&lt;p&gt;Google Gemini APIも、入力、出力、コンテキストキャッシュ、Batch、Flex、Priorityなどを分けて価格設定しています &lt;a class="link" href="https://ai.google.dev/gemini-api/docs/pricing" target="_blank" rel="noopener"
 &gt;Google AI for Developers&lt;/a&gt;。GeminiのContext cachingは、同じ入力内容を繰り返し使う場合にキャッシュ済みトークンを低コストで再利用でき、保存時間にも応じて課金されます &lt;a class="link" href="https://ai.google.dev/gemini-api/docs/caching" target="_blank" rel="noopener"
 &gt;Gemini API Context Caching&lt;/a&gt;。&lt;/p&gt;
&lt;p&gt;MicrosoftのAzure OpenAIも、Standardでは消費トークンに応じてAPIコールを課金し、Batch APIではGlobal Standard Pricingから50%割引で24時間以内に処理する仕組みを提供しています &lt;a class="link" href="https://azure.microsoft.com/en-us/blog/maximize-your-roi-for-azure-openai/" target="_blank" rel="noopener"
 &gt;Microsoft Azure Blog&lt;/a&gt; &lt;a class="link" href="https://azure.microsoft.com/en-us/pricing/details/azure-openai/" target="_blank" rel="noopener"
 &gt;Azure OpenAI Pricing&lt;/a&gt;。Foundry Agent Serviceでは、モデル利用のトークン課金に加えて、hosted agentsの実行に使うコンテナ計算資源を時間単位で課金する方向も示されています &lt;a class="link" href="https://azure.microsoft.com/en-us/pricing/details/foundry-agent-service/" target="_blank" rel="noopener"
 &gt;Microsoft Azure&lt;/a&gt;。&lt;/p&gt;
&lt;p&gt;DeepSeekも、V4 FlashとV4 Proについて入力キャッシュヒット、入力キャッシュミス、出力トークンを分け、費用はトークン数と単価の掛け算で決まると明記しています &lt;a class="link" href="https://api-docs.deepseek.com/quick_start/pricing" target="_blank" rel="noopener"
 &gt;DeepSeek API Docs&lt;/a&gt;。DeepSeekは全モデルの入力キャッシュヒット価格をローンチ価格の10分の1に下げたとも説明しており、キャッシュを前提にした価格競争が進んでいます &lt;a class="link" href="https://api-docs.deepseek.com/quick_start/pricing" target="_blank" rel="noopener"
 &gt;DeepSeek API Docs&lt;/a&gt;。&lt;/p&gt;
&lt;h2 id="なぜ従量制へ向かうのか"&gt;なぜ従量制へ向かうのか
&lt;/h2&gt;&lt;p&gt;最大の理由は、AIサービスの原価がユーザー数ではなく計算量に強く連動するからです。短い質問に一言で返す場合と、巨大なコードベースを読み、長い推論を行い、数千行の出力を生成する場合では、同じ「1回の利用」でもGPUやTPUの消費量がまったく違います。&lt;/p&gt;
&lt;p&gt;特に2026年は、長文コンテキスト、推論モデル、マルチモーダル、AIエージェントの普及によって、1リクエストあたりの計算量が大きくなっています。Anthropicが200K入力トークン超の長文リクエストに別料金を設定していることや、Googleがキャッシュ保存時間まで課金要素に入れていることは、長い文脈を扱うコストが無視できないことを示しています &lt;a class="link" href="https://docs.anthropic.com/en/docs/about-claude/pricing/" target="_blank" rel="noopener"
 &gt;Claude API Docs&lt;/a&gt; &lt;a class="link" href="https://ai.google.dev/gemini-api/docs/caching" target="_blank" rel="noopener"
 &gt;Gemini API Context Caching&lt;/a&gt;。&lt;/p&gt;
&lt;p&gt;もう一つの背景は、利用パターンの多様化です。リアルタイムのチャット、夜間バッチ処理、コードレビュー、検索拡張、長時間エージェント、社内文書分析では、必要な速度、信頼性、コストが違います。OpenAIのPriority processingやGoogleのBatch/Flex/Priorityのような階層は、同じモデルでも「安く遅く」「高く速く」を選べる市場へ移っていることを示しています &lt;a class="link" href="https://openai.com/api-priority-processing/" target="_blank" rel="noopener"
 &gt;OpenAI Priority Processing&lt;/a&gt; &lt;a class="link" href="https://ai.google.dev/gemini-api/docs/pricing" target="_blank" rel="noopener"
 &gt;Google AI for Developers&lt;/a&gt;。&lt;/p&gt;
&lt;h2 id="開発者への影響"&gt;開発者への影響
&lt;/h2&gt;&lt;p&gt;開発者にとっては、プロンプト設計がそのままコスト設計になります。毎回同じシステムプロンプトやドキュメントを投げる実装は高くなり、キャッシュ、RAG（検索して関連情報をAIに渡す手法）、差分入力、モデルルーティングを使う実装は安くなります。&lt;/p&gt;
&lt;p&gt;また、モデル選定も「一番賢いモデルを使う」から「タスクごとに最適な単価と品質を選ぶ」へ変わります。分類、整形、要約、軽い抽出は低価格モデルに任せ、難しい設計判断や高リスクな出力だけ上位モデルに送る構成が主流になるでしょう。&lt;/p&gt;
&lt;h2 id="今後予想されること"&gt;今後予想されること
&lt;/h2&gt;&lt;p&gt;今後は、単純なトークン課金だけでなく、より細かい複合課金へ進む可能性があります。たとえば、推論時間、ツール呼び出し、Web検索、ファイル検索、コード実行、メモリ保存、エージェントの待機時間が、それぞれ別の課金項目になるでしょう。&lt;/p&gt;
&lt;p&gt;また、SLA別料金も広がるはずです。ユーザー向けプロダクトでは低遅延が価値になり、バックオフィス処理では安いバッチが価値になります。OpenAIのPriority processingやMicrosoftのhosted agents課金は、その方向を先取りしています &lt;a class="link" href="https://openai.com/api-priority-processing/" target="_blank" rel="noopener"
 &gt;OpenAI Priority Processing&lt;/a&gt; &lt;a class="link" href="https://azure.microsoft.com/en-us/pricing/details/foundry-agent-service/" target="_blank" rel="noopener"
 &gt;Microsoft Azure&lt;/a&gt;。&lt;/p&gt;
&lt;p&gt;さらに、キャッシュを前提にしたアプリ設計が重要になります。社内規程、コードベース、顧客情報、ナレッジベースのような繰り返し使う文脈は、毎回入力するのではなく、キャッシュや検索基盤に寄せるほどコスト効率が上がります。DeepSeekやAnthropic、Googleがキャッシュ済み入力を安くしていることは、プロバイダ側もその使い方を促していると見られます &lt;a class="link" href="https://api-docs.deepseek.com/quick_start/pricing" target="_blank" rel="noopener"
 &gt;DeepSeek API Docs&lt;/a&gt; &lt;a class="link" href="https://docs.anthropic.com/en/docs/about-claude/pricing/" target="_blank" rel="noopener"
 &gt;Claude API Docs&lt;/a&gt; &lt;a class="link" href="https://ai.google.dev/gemini-api/docs/caching" target="_blank" rel="noopener"
 &gt;Gemini API Context Caching&lt;/a&gt;。&lt;/p&gt;
&lt;h2 id="まとめ"&gt;まとめ
&lt;/h2&gt;&lt;p&gt;AIサービスの課金は、月額で「使い放題」に見せる段階から、計算資源を細かく測って価格に反映する段階へ移っています。これはユーザーにとって分かりにくくなる一方、設計次第で大きく安く使える余地が生まれる変化でもあります。今後のAI開発では、モデル性能だけでなく、トークン、キャッシュ、バッチ、優先処理、エージェント実行環境を含めた「AIコストアーキテクチャ」が重要な競争力になるでしょう。&lt;/p&gt;</description></item><item><title>DeepSeek V4登場で『AIは高い』が揺らぐ：GPT-5.4の約1/50出力コストが示す価格破壊</title><link>https://ha.gizwoo.com/deepseek-v4-cost-a7klm9qxz2/</link><pubDate>Tue, 28 Apr 2026 19:25:00 +0900</pubDate><guid>https://ha.gizwoo.com/deepseek-v4-cost-a7klm9qxz2/</guid><description>&lt;p&gt;DeepSeek V4 Previewは、生成AIの競争軸を「最高性能」だけでなく「どれだけ安く大規模に使えるか」へ押し戻す発表になりました。特にDeepSeek-V4-Flashの公式価格は、GPT-5.4と比較したときに出力トークンで約53.6倍の差があり、エージェントやコード生成のような出力量の多い用途では無視できないインパクトがあります &lt;a class="link" href="https://api-docs.deepseek.com/quick_start/pricing" target="_blank" rel="noopener"
 &gt;DeepSeek API Docs&lt;/a&gt; &lt;a class="link" href="https://llm-stats.com/models/compare/gpt-5.4-vs-deepseek-v4-flash-max" target="_blank" rel="noopener"
 &gt;LLM Stats&lt;/a&gt;。本記事では、DeepSeek V4の何が価格破壊なのか、そして「90%品質」という言い方をどう受け止めるべきかを整理します。&lt;/p&gt;
&lt;h2 id="deepseek-v4-previewの要点"&gt;DeepSeek V4 Previewの要点
&lt;/h2&gt;&lt;p&gt;DeepSeekは2026年4月24日にDeepSeek-V4 Previewを公開し、DeepSeek-V4-ProとDeepSeek-V4-Flashの2系統を案内しました &lt;a class="link" href="https://api-docs.deepseek.com/news/news260424" target="_blank" rel="noopener"
 &gt;DeepSeek API Docs&lt;/a&gt;。V4-Proは1.6T総パラメータ、49Bアクティブパラメータのモデルで、DeepSeekは「世界トップ級のクローズドモデルに匹敵する性能」と説明しています &lt;a class="link" href="https://api-docs.deepseek.com/news/news260424" target="_blank" rel="noopener"
 &gt;DeepSeek API Docs&lt;/a&gt;。V4-Flashは284B総パラメータ、13Bアクティブパラメータの軽量版で、単純なエージェントタスクではV4-Proに近い性能を示すとされています &lt;a class="link" href="https://api-docs.deepseek.com/news/news260424" target="_blank" rel="noopener"
 &gt;DeepSeek API Docs&lt;/a&gt;。&lt;/p&gt;
&lt;p&gt;大きいのは、両モデルが1Mコンテキストと最大384K出力を公式に掲げている点です &lt;a class="link" href="https://api-docs.deepseek.com/quick_start/pricing" target="_blank" rel="noopener"
 &gt;DeepSeek API Docs&lt;/a&gt;。長文ドキュメント、巨大コードベース、複数ファイルを扱うエージェントでは、短いコンテキストに分割して呼び出すより、1回の呼び出しで広い状態を保持できるほうが設計しやすくなります。&lt;/p&gt;
&lt;h2 id="価格差が変える実装判断"&gt;価格差が変える実装判断
&lt;/h2&gt;&lt;p&gt;DeepSeek公式価格では、V4-Flashは100万入力トークンが0.14ドル、100万出力トークンが0.28ドルです &lt;a class="link" href="https://api-docs.deepseek.com/quick_start/pricing" target="_blank" rel="noopener"
 &gt;DeepSeek API Docs&lt;/a&gt;。OpenAIの公式価格ではGPT-5.4が100万入力トークン2.50ドル、100万出力トークン15.00ドルであり、単純比較では入力で17.9倍、出力で53.6倍の差になります &lt;a class="link" href="https://developers.openai.com/api/docs/pricing" target="_blank" rel="noopener"
 &gt;OpenAI API Pricing&lt;/a&gt; &lt;a class="link" href="https://llm-stats.com/models/compare/gpt-5.4-vs-deepseek-v4-flash-max" target="_blank" rel="noopener"
 &gt;LLM Stats&lt;/a&gt;。&lt;/p&gt;
&lt;p&gt;この差は、チャットUIで数回質問するだけなら小さく見えるかもしれません。しかし、AIエージェントがコードを読み、計画を立て、修正案を書き、テスト結果を要約するようなワークフローでは、出力トークンが大量に発生します。つまり、DeepSeek V4の価格は「高性能モデルをどこにだけ使うか」ではなく、「安価なモデルを常時走らせ、難所だけ高性能モデルへルーティングする」設計を後押しします。&lt;/p&gt;
&lt;h2 id="90品質はどう見るべきか"&gt;「90%品質」はどう見るべきか
&lt;/h2&gt;&lt;p&gt;表現としての「GPT-5.4の90%品質」は分かりやすいものの、公式に単一の品質指標として確認できる数字ではありません。FortuneはDeepSeekの技術レポートを引用し、V4がGPT-5.4やGemini 3.1 Proに「わずかに及ばない」とする一方、Claude Opus 4.6、GPT-5.4、Gemini 3.1 Proとの比較で有利なベンチマークも示したと報じています &lt;a class="link" href="https://fortune.com/2026/04/24/deepseek-v4-ai-model-price-performance-china-open-source/" target="_blank" rel="noopener"
 &gt;Fortune&lt;/a&gt;。したがって、実務では「90%品質」と断定するより、「一部のタスクで frontier model に近い性能を、はるかに低い単価で狙える」と見るほうが安全です。&lt;/p&gt;
&lt;p&gt;特に注意したいのは、ベンチマーク上の近さと本番運用の安定性は同じではない点です。APIの稼働率、レート制限、データ取り扱い、法務リスク、サポート品質は、単価だけでは測れません。DeepSeek V4は魅力的な価格を提示しましたが、企業導入では性能検証だけでなく、ログ管理、データ保持、障害時の代替ルートまで含めた評価が必要です。&lt;/p&gt;
&lt;h2 id="まとめ"&gt;まとめ
&lt;/h2&gt;&lt;p&gt;DeepSeek V4は、「高品質なAIは高い」という前提を大きく揺さぶる発表です。公式価格ベースではV4-Flashの出力単価がGPT-5.4より約53.6倍安く、1Mコンテキストと384K出力も備えています &lt;a class="link" href="https://api-docs.deepseek.com/quick_start/pricing" target="_blank" rel="noopener"
 &gt;DeepSeek API Docs&lt;/a&gt; &lt;a class="link" href="https://llm-stats.com/models/compare/gpt-5.4-vs-deepseek-v4-flash-max" target="_blank" rel="noopener"
 &gt;LLM Stats&lt;/a&gt;。ただし、品質を単純に「90%」と断定するより、コストの低さを活かしてタスク分解、モデルルーティング、エージェント実行基盤を再設計するきっかけとして捉えるべきでしょう。&lt;/p&gt;</description></item><item><title>【AIニュース】推論高速化・エージェント記憶・指示追従の脆さが同時に進む</title><link>https://ha.gizwoo.com/inference-memory-robustness-zmqa75kkod/</link><pubDate>Thu, 16 Apr 2026 08:02:00 +0900</pubDate><guid>https://ha.gizwoo.com/inference-memory-robustness-zmqa75kkod/</guid><description>&lt;p&gt;朝のAIニュースです。今週は「モデルを賢くする」だけでなく、速く回す・長く覚える・壊れにくくするという運用寄りの論点が一気に前に出てきました。研究側の提案が、そのままプロダクトのコスト構造や品質保証の議論に直結し始めています。&lt;/p&gt;
&lt;h2 id="推論高速化-speculative-decoding-がツリー化して伸びる"&gt;推論高速化: speculative decoding が&amp;quot;ツリー化&amp;quot;して伸びる
&lt;/h2&gt;&lt;p&gt;speculative decoding（投機的デコード）は、小さなドラフトモデルで複数トークン先を提案し、大きい本命モデルでまとめて検証することでレイテンシ（応答遅延）を下げる定番テクです。今回のDDTreeは、ブロック拡散型のドラフタが1回の推論で吐く「各位置の分布」を使い、単一路線ではなく&amp;quot;候補の木&amp;quot;を構成して一括検証するのがポイントです（&lt;a class="link" href="https://arxiv.org/html/2604.12989v1" target="_blank" rel="noopener"
 &gt;arXiv: Accelerating Speculative Decoding with Block Diffusion Draft Trees&lt;/a&gt;）。&lt;/p&gt;
&lt;h3 id="意味-速度最適化がモデル選定からデコーダ設計へ"&gt;意味: 速度最適化が「モデル選定」から「デコーダ設計」へ
&lt;/h3&gt;&lt;p&gt;これまでの高速化は「より軽いドラフタを作る」「量子化する」などモデル側の話になりがちでした。しかしDDTreeは、同じドラフタ出力でも&amp;quot;どう検証するか&amp;quot;の設計で受理トークン数を押し上げようとしています（&lt;a class="link" href="https://arxiv.org/html/2604.12989v1" target="_blank" rel="noopener"
 &gt;arXiv: Accelerating Speculative Decoding with Block Diffusion Draft Trees&lt;/a&gt;）。実務的には、同一GPUでも体感速度が変わる余地が増え、推論スタック（デコーダ、キャッシュ、バッチング）のチューニングが競争領域になります。&lt;/p&gt;
&lt;h3 id="示唆-abだけではなく負荷時のsloとコスト曲線で評価する"&gt;示唆: A/Bだけではなく、負荷時のSLOとコスト曲線で評価する
&lt;/h3&gt;&lt;p&gt;高速化手法は平均レイテンシの改善だけでなく、ピーク時のスループット・p95/p99（リクエストの95〜99%が収まる応答時間の上限）・キャッシュヒット率などで&amp;quot;どこが律速になるか&amp;quot;が変わります。導入時は、オンライン推論のSLO（応答速度などのサービス目標値）とコスト（$/reqや$/token）を同時に見て、最適化が別のボトルネック（検証側のメモリ帯域、KVキャッシュ（モデルが処理した文脈情報の一時保存領域）の膨張、バッチサイズ制約）を呼んでいないかを検証したいところです（&lt;a class="link" href="https://arxiv.org/html/2604.12989v1" target="_blank" rel="noopener"
 &gt;arXiv: Accelerating Speculative Decoding with Block Diffusion Draft Trees&lt;/a&gt;）。&lt;/p&gt;
&lt;h2 id="エージェント記憶-事実情景でセッションを跨ぐ想起が伸びる"&gt;エージェント記憶: 「事実＋情景」でセッションを跨ぐ想起が伸びる
&lt;/h2&gt;&lt;p&gt;LLMエージェントの長期記憶は、事実をフラットに保存すると&amp;quot;いつ・どの文脈で得たか&amp;quot;が欠け、更新や時系列推論が弱くなる問題がありました。Dual-Trace Encodingは、事実（fact）に加えて、その学習時の状況を物語的に再構成した「scene trace」を対で保存する設計です（&lt;a class="link" href="https://arxiv.org/abs/2604.12948" target="_blank" rel="noopener"
 &gt;arXiv: Drawing on Memory: Dual-Trace Encoding Improves Cross-Session Recall in LLM Agents&lt;/a&gt;）。LongMemEval-Sで精度が53.5%→73.7%に上がったという報告が目を引きます（&lt;a class="link" href="https://arxiv.org/abs/2604.12948" target="_blank" rel="noopener"
 &gt;arXiv: Drawing on Memory: Dual-Trace Encoding Improves Cross-Session Recall in LLM Agents&lt;/a&gt;）。&lt;/p&gt;
&lt;h3 id="意味-メモリはragの下位互換という見方が崩れる"&gt;意味: &amp;ldquo;メモリはRAGの下位互換&amp;quot;という見方が崩れる
&lt;/h3&gt;&lt;p&gt;メモリを単なるベクトル検索やログ保存の延長として扱うと、更新・矛盾・経時変化に弱いままです。Dual-Traceの肝は「保存時に文脈を生成させる」点で、後段の検索以前に&amp;quot;記憶表現の品質&amp;quot;を上げています（&lt;a class="link" href="https://arxiv.org/abs/2604.12948" target="_blank" rel="noopener"
 &gt;arXiv: Drawing on Memory: Dual-Trace Encoding Improves Cross-Session Recall in LLM Agents&lt;/a&gt;）。エージェント運用では、検索精度より先に「何を、どの形で、いつ確定するか」が設計パラメータになります。&lt;/p&gt;
&lt;h3 id="示唆-1-書き込み時に強制的に具体化させる-2-更新を前提にスキーマを持つ"&gt;示唆: 1) 書き込み時に強制的に具体化させる 2) 更新を前提にスキーマを持つ
&lt;/h3&gt;&lt;p&gt;実装のコツは、メモリ書き込みを&amp;quot;後回し&amp;quot;にせず、イベント発生時にscene traceを生成して固定することです（&lt;a class="link" href="https://arxiv.org/abs/2604.12948" target="_blank" rel="noopener"
 &gt;arXiv: Drawing on Memory: Dual-Trace Encoding Improves Cross-Session Recall in LLM Agents&lt;/a&gt;）。さらに、事実は変わるので「最新版」「旧版」「根拠となる会話断片」を分離し、更新ログを残すと後日の説明可能性が上がります。&lt;/p&gt;
&lt;h2 id="指示追従の落とし穴-禁則1つで役立つモデルが急に短くなる"&gt;指示追従の落とし穴: 禁則1つで&amp;quot;役立つモデル&amp;quot;が急に短くなる
&lt;/h2&gt;&lt;p&gt;Instruction-tunedモデルに対し「カンマを使わない」「ある一般語を使わない」などの単純な語彙制約を入れると、内容が極端に短くなり網羅性が落ちる&amp;quot;collapse&amp;quot;が起きる、という報告が出ています（&lt;a class="link" href="https://arxiv.org/html/2604.13006v1" target="_blank" rel="noopener"
 &gt;arXiv: One Token Away from Collapse: The Fragility of Instruction-Tuned Helpfulness&lt;/a&gt;）。ペアワイズ評価では網羅性が14–48%落ちる一方、単体のLLM-as-judgeでは低下を過小評価し得る、という指摘も運用的に重要です（&lt;a class="link" href="https://arxiv.org/html/2604.13006v1" target="_blank" rel="noopener"
 &gt;arXiv: One Token Away from Collapse: The Fragility of Instruction-Tuned Helpfulness&lt;/a&gt;）。&lt;/p&gt;
&lt;h3 id="意味-プロンプトガードレールが品質劣化の原因になる可能性"&gt;意味: &amp;ldquo;プロンプトガードレール&amp;quot;が品質劣化の原因になる可能性
&lt;/h3&gt;&lt;p&gt;プロダクトでは安全上の理由で禁則やフォーマット制約を入れがちです。しかし、その制約がモデルの内部で「テンプレ依存の計画」を壊し、結果的にユーザー価値（網羅性・手順性）を損ねる可能性があります（&lt;a class="link" href="https://arxiv.org/html/2604.13006v1" target="_blank" rel="noopener"
 &gt;arXiv: One Token Away from Collapse: The Fragility of Instruction-Tuned Helpfulness&lt;/a&gt;）。安全性と有用性がトレードオフではなく、設計の仕方で&amp;quot;両方落ちる&amp;quot;ケースがあり得る、という警告です。&lt;/p&gt;
&lt;h3 id="示唆-制約は事前より事後へ寄せ二段生成をデフォルトにする"&gt;示唆: 制約は「事前」より「事後」へ寄せ、二段生成をデフォルトにする
&lt;/h3&gt;&lt;p&gt;論文では、自由生成→制約に合わせたリライトの2段生成で回復する、と述べています（&lt;a class="link" href="https://arxiv.org/html/2604.13006v1" target="_blank" rel="noopener"
 &gt;arXiv: One Token Away from Collapse: The Fragility of Instruction-Tuned Helpfulness&lt;/a&gt;）。実装面でも、最初から禁則を課すより、まず十分な内容を生成してから整形・マスキング・安全フィルタを適用するパイプラインの方が、品質が安定しやすいはずです。&lt;/p&gt;
&lt;h2 id="画像生成-同品質で安く速くの圧力がさらに強まる"&gt;画像生成: 「同品質で安く速く」の圧力がさらに強まる
&lt;/h2&gt;&lt;p&gt;Microsoftは、テキスト入力約730円/100万トークン（$5）、画像出力約2,830円/100万トークン（$19.50）とし、従来比で約41%のコスト低減と、22%高速・4倍スループット効率を掲げるMAI-Image-2-Efficientを発表しています（&lt;a class="link" href="https://microsoft.ai/news/mai-image-2-efficient/?form=M301GN&amp;amp;OCID=CGE_osocial_Copilot_Free_868j8p328" target="_blank" rel="noopener"
 &gt;Microsoft AI: MAI-Image-2-Efficient&lt;/a&gt;）。&lt;/p&gt;
&lt;h3 id="意味-生成品質が横並びになった後は価格速度運用性が主戦場"&gt;意味: &amp;ldquo;生成品質&amp;quot;が横並びになった後は、価格・速度・運用性が主戦場
&lt;/h3&gt;&lt;p&gt;画像生成は品質競争の次に、推論コストと供給能力（同時生成、待ち時間）が差別化になります。LLM側のデコーダ最適化と同様、画像も「何をどのインフラでどの価格で提供できるか」が、機能の実装可否に直結していきます（&lt;a class="link" href="https://microsoft.ai/news/mai-image-2-efficient/?form=M301GN&amp;amp;OCID=CGE_osocial_Copilot_Free_868j8p328" target="_blank" rel="noopener"
 &gt;Microsoft AI: MAI-Image-2-Efficient&lt;/a&gt;）。&lt;/p&gt;
&lt;h2 id="まとめ"&gt;まとめ
&lt;/h2&gt;&lt;p&gt;推論はデコーダ設計、エージェントは記憶表現、指示追従は制約設計、画像生成はコスト曲線。どれも「モデルの賢さ」そのものより、プロダクト品質を左右する&amp;quot;周辺の工学&amp;quot;が中心テーマになっています。次に効いてくるのは、評価指標と運用フローをどう再設計できるかです。&lt;/p&gt;</description></item></channel></rss>