AIの次の律速はどこへ移るのか

AIの次の律速はどこへ移るのか

――NESTOR、内部状態共有、自己改善するAgent、そして半導体・電力が決める次の競争

2026年11月1日｜AI研究フロンティア・AIインフラ総合分析

Dots、Muse、スケジューラー観測

はじめに――AIの進歩を、モデルの大きさだけでは説明できなくなる

AIの進歩を説明するとき、私たちは長い間、パラメータ数、学習データ、GPUの数量、計算量を中心に考えてきた。

この考え方はいまも重要である。大規模な計算設備を利用できることは、依然としてフロンティアモデル開発の大きな競争条件だ。

しかし、2026年10月に公表された研究と産業情報を横断すると、別の問題が浮かび上がってくる。

すでに計算した情報を、なぜ何度も計算し直すのか。

解決できない仕事を、なぜAgentは実行し続けるのか。

GPUや半導体の設備投資が増えているのに、それが実際に使える計算能力になるまでには、なぜ時間がかかるのか。

これらは異なる問題に見える。しかし、共通する構造がある。

現在のAIは、モデルの内部、Agentの実行環境、データセンター、半導体製造という各段階で、計算結果や設備を最終的な成果へ変換する際の損失を抱えている。

次の競争は、その損失をどこまで取り除けるかに移る可能性がある。

本稿では、研究段階にあるS級構造変化候補を中心に、2026年10月31日までに確認できた情報から、今後6か月〜3年の変化を検討する。

なお、S級とは研究や企業に対する確定評価ではない。既存のAIアーキテクチャや運用の前提を変え得る研究を示す分析上の区分である。今回取り上げる研究について、フロンティア規模での独立再現と商用本番への普及が確認されたわけではない。

第1章　最重要S候補・NESTOR――Attentionそのものを条件付き計算へ変える

2026年10月22日、Tianzhe Chu、Druv Pai、Yi Maによる研究「Nested Sparsity for Scalable Pretraining and Continual Learning」が公開された。

研究で提案されたアーキテクチャは、NESTORと呼ばれる。

原論文：NESTOR（arXiv:2610.31818）

1-1. 従来のMoEが変更していなかった部分

現在の大規模言語モデルでは、Mixture of Experts（MoE）が重要な位置を占めている。

MoEの考え方は、モデル全体のパラメータを毎回使用するのではなく、入力に応じて必要なExpertだけを活性化するものだ。

これにより、総パラメータ数を増やしながら、1回の推論で実行する計算量を抑えられる。

ただし、一般的なMoE Transformerでは、条件付き計算の中心はFFN部分にある。

Attentionは、どの情報を参照し、どのToken同士の関係を計算するかを決める重要な機構であるにもかかわらず、MoEとは異なる共通計算として扱われる部分が大きかった。

NESTORは、その前提を変更しようとする。

1-2. Attentionにも複数の計算経路を与える

NESTORでは、Attentionの計算機構自体を複数のColumnとして構成し、入力に応じて必要なColumnを選択する。

さらに、その内部でMoEのExpertを条件付きで利用する。

つまり、条件付き計算が二重に組み合わされる。

従来のMoEが主に「どのExpertを使用するか」を選択していたのに対し、NESTORでは「どのAttention経路を利用し、その内部でどのExpertを使用するか」という構造になる。

これは単にAttentionの計算を一部省略するSparse Attentionとは異なる。

モデル内の計算経路そのものを、入力に応じて選択する仕組みだからである。

仮にこの構造が大規模化しても有効なら、パラメータ数を増やすことと、毎回の計算量を増やすことの関係をさらに緩められる可能性がある。

1-3. 実験結果は何を示しているか

研究では、最大約10億のActive Parametersを用いたモデルを評価している。

最大規模の比較では、NESTORの総パラメータ数は約55.3億、通常MoEは約54.9億であり、学習Token数はともに500億だった。

その条件で、Held-out LossはNESTORが2.571、比較対象のMoEが2.592と報告された。

また、複数規模の結果から同じLossに到達する計算量を推定すると、通常MoEはNESTORより約1.13〜1.29倍の学習FLOPsを必要とするという結果になった。

ここは慎重に読む必要がある。

1.29倍という数字は、実際のGPUクラスタで学習時間が1.29倍短縮されたことを意味しない。

測定結果を基にしたScaling Law上の計算量推定であり、実際の学習時間にはRouting、通信、メモリ配置、GPU利用率などが影響する。

それでも、この研究は重要である。

同じような総パラメータ規模と計算条件で、従来MoEとは異なる計算構造が性能改善を示したからだ。

さらに、長いContextへの拡張や継続事前学習において、従来MoEより旧領域の忘却を抑えながら新領域へ適応できる可能性も報告されている。

1-4. なぜS候補なのか

NESTORの最も重要な点は、個別のLoss改善ではない。

Transformerにおける条件付き計算の適用範囲を、FFNからAttentionへ拡張したことにある。

これは将来、モデルの学習方法、Expert配置、KV Cache構造、GPU間通信、継続学習の方法を同時に変える可能性がある。

ただし、今回の検証は最大約10億Active Parametersまでである。

数百億Active Parametersのフロンティア規模でも利点が維持されるか、本番推論のTTFT、TPOT、HBM使用量、ネットワーク通信量がどう変わるかは未確認だ。

したがって現時点の評価は、A+級の実験成果を持つS昇格候補が適切だろう。

大規模化、実効コスト、独立再現が今後の分岐点になる。

第2章　もう一つのS候補――Agent同士は、なぜ文章で会話する必要があるのか

NESTORがモデル内部の計算経路を変える研究なら、次に取り上げる研究は、モデル同士の通信方法を変えようとしている。

10月15日に公開された「Augment the Cache, Replace the Activation: A 2x2 Study of Internal-State Sharing」である。

原論文：Internal-State Sharing（arXiv:2610.22026）

2-1. 現在のAgent通信にある再計算

複数のAgentが協力するシステムを考えてみる。

Agent Aが長い資料を読み、調査結果をまとめる。

その結果をAgent Bへ渡す際、一般的には文章を生成する。

Agent Bは受け取った文章をTokenへ変換し、再び自分のモデルで処理する。

ところが、Agent Aは文章を生成する以前に、その資料を内部表現へ変換している。

Agent Bは、Agent Aが一度計算した内容を文章から再構成しているわけだ。

ここには二つの損失がある。

一つは、文章へ変換することで内部表現の一部が失われること。

もう一つは、受け取る側で再び計算が必要になることだ。

もし内部表現を直接共有できるなら、この工程の一部を省略できる可能性がある。

2-2. KV CacheとActivationでは、適切な共有方法が異なる

研究では、KV CacheとActivationという二種類の内部状態を対象に、共有方法を比較した。

重要なのは、内部状態を単純にコピーすればよいわけではなかったことだ。

KV Cacheでは、受信側が自分の状態を保持しながら、他のAgentのKVへ追加的にアクセスする方法が有効だった。

一方、Activationでは、適切な位置に内部状態を書き込んで置き換える方法が有効だった。

研究タイトルの「Augment the Cache, Replace the Activation」は、この違いを表している。

内部状態の種類によって、受け渡しの方法も変わるのである。

2-3. Agentの知識交換が「通信」から「共有」へ変わる可能性

さらに研究では、Agentごとに専用の通信変換器を作るのではなく、共有された状態プールを利用する方法を検討している。

これが発展すれば、複数のAgentがそれぞれの調査結果や処理状態を毎回文章化するのではなく、計算済みの状態を必要に応じて参照する設計が考えられる。

ただし、大きな制約もある。

異なるモデル同士の内部表現が十分に近くなければ、共有できない場合がある。

モデル更新によって内部表現が変われば、以前の共有方法が成立しなくなる可能性もある。

権限管理、汚染された状態の混入、状態の検証方法も課題になる。

したがって、あらゆるAIが内部状態を自由に共有できると考えるのは早い。

それでも、Agent間の情報交換を文章中心から内部状態中心へ変更する可能性が示されたことは、S候補として重要である。

NESTORが「何を計算するか」を変えるなら、この研究は「計算したものをどう引き継ぐか」を変えようとしている。

第3章　第三のS候補――Agentは経験を保存するだけでなく、能力として蓄積できるか

AI Agentが長時間働く時代には、モデルの推論能力だけでなく、過去の成功経験を次の仕事にどう利用するかが重要になる。

ここで注目したいのが、10月22日に公開されたPhronixである。

原論文：Phronix（arXiv:2610.31789）

Phronixは、Agentの実行経験から再利用可能な能力を獲得し、検証し、改善する枠組みを提案した。

3-1. 記憶を保存することと、能力を保存することは異なる

一般的なAgent Memoryでは、以前の会話、実行履歴、成功例、失敗例などを保存する。

しかし、履歴を保存するだけでは、同じ問題に遭遇したときに再び長い推論が必要になることがある。

Phronixは、実行の中で得られた手順を、MCP ToolやSkillのような再実行可能な形で保持することを目指す。

重要なのは、単にコードを生成して保存するのではなく、実行結果を使って検証する構造を持つことだ。

これは記憶の蓄積というより、検証可能な能力の蓄積に近い。

モデルが固定されていても、その外側のHarnessが改善されれば、システム全体として以前は難しかった仕事を処理できる可能性がある。

3-2. 自己改善に必要なのは、成功を判定する能力である

しかし、ここで新しい問題が生まれる。

Agentが新しいSkillを作ったとして、それが正しいと誰が判断するのか。

テストに通っただけで正しいのか。

実行環境を変更して成功を装っていないか。

以前は正常だったSkillが、依存ライブラリや権限の変化によって危険になっていないか。

Agentの能力が増えるほど、それを検証する工程の重要性も高まる。

10月22日の別研究、ImpasseBenchはこの問題を別の方向から扱った。

原論文：Knowing When to Stop（arXiv:2610.31895）

この研究は、Agentが環境上の障害によって作業を進められなくなっても、同じ試行を続けたり、不適切な回避策を試みたりする問題を調査している。

8モデル、約1万9,371件の実行履歴を含む評価では、外部の助けが必要な条件にもかかわらず、実行予算を使い切る事例が多く見られた。

エスカレーション用のToolを導入した条件では、予算を使い切る割合が34.0%から6.7%へ低下したと報告された。

これは特定の障害条件を組み込んだ評価であり、一般的なAgent全体の成功率改善を意味するものではない。

それでも示唆は大きい。

Agentに必要なのは、仕事を最後まで続ける能力だけではない。

できないと判断する能力、停止する能力、引き継ぐ能力、進捗と未検証事項を正確に残す能力も必要なのである。

3-3. 検証は無料ではない

10月末には、GUI操作の結果を検証する研究も報告された。

VeriCUA v1では、AndroidWorldを用いた著者らの実験で、判定精度90.5%という結果が示されている。

比較対象のVLM判定器は78.4%だった。

しかし、オンライン検証では判定を保留する割合が18〜30%あり、検証方式によっては数万Tokenと数十秒以上を要した。

この結果が示しているのは、検証の改善には追加の計算費用が伴う場合があるということだ。

Agentが自律的に行う仕事が増えれば増えるほど、成功判定、権限確認、異常検知、復旧確認に必要な計算も増える可能性がある。

モデルが効率化しても、検証する工程が増えれば、システム全体の計算需要が同じ割合で減るとは限らない。

逆に、適切な検証によって失敗や再実行が減れば、総費用が改善する場合もある。

重要なのは、推論Token数だけではなく、検証を通過した仕事1件当たりの総費用で評価することである。

第4章　S候補を実現するA+技術――KVとRLの転送が新しい制約になる

ここまでの研究には共通点がある。

計算する内容、計算済みの状態、実行経験を、いかに効率よく利用するかという問題だ。

しかし、状態を保存し、再利用する仕組みが高度になると、新たな負担も生まれる。

状態をどこに保存するのか。

別のGPUへどう転送するのか。

保存して読み戻す方が、再計算するより本当に安いのか。

4-1. KVStream――保存したKVを読む方が速いとは限らない

10月22日に公開されたKVStreamは、長いContextで生成されたKV Cacheを、複数のストレージ階層から並列に読み出す方式を提案した。

原論文：KVStream（arXiv:2610.31827）

著者らは最大128GPUを用いた評価で、従来方式LMCacheに対してOffline Throughputを最大1.49倍、バースト負荷下の平均TTFTを最大約6.1倍改善したと報告している。

この倍率は注目に値する。

ただし、どの負荷でも改善するわけではない。

KVStreamでは、複数の保存先へ同じKVを複製するため、追加の書き込み負担が生まれる。

KV再利用率が低い条件では、比較対象に対する性能が0.81倍まで低下した実験もある。

ここに重要な経済条件が現れる。

再計算を省いた価値が、保存・転送・復元に必要な費用を上回る必要がある。

長期稼働するAgentが増えるほど、HBMだけでなくDRAM、NVMe SSD、ストレージネットワーク、データ配置の重要性が高まる可能性がある。

ただし、KVStreamの実験結果から、NAND需要やGPU台数が何%増えるかを直接計算することはできない。

4-2. KnitTrans――学習では計算以外の待機が問題になる

10月23日に公開されたKnitTransは、大規模強化学習におけるTrajectory転送を対象とした研究だ。

原論文：KnitTrans（arXiv:2610.32389）

Agent RLでは、Rollout側が生成した軌跡をTrainerへ渡す。

その際に必要なのはToken列だけではない。

報酬、Log Probability、Mask、画像・動画情報、その他の学習用データも転送される。

KnitTransは、この転送と学習の開始条件を改善する。

最大256GPUを用いた実験では、転送と学習を合わせた工程で最大5.8倍の高速化が報告された。

また、古いモデルで生成された軌跡を、新しいパラメータの学習に使う際のずれを減らす効果も示された。

ここで重要なのは、モデルの演算が直接5.8倍速くなったわけではないということだ。

高速化されたのは、転送・待機を含む特定の学習工程である。

これは、今後のRLがより大規模化した際、GPUの演算性能だけでなく、学習データを必要な場所へ必要な時点で届ける能力が競争条件になることを示唆している。

第5章　研究の進歩は、半導体需要を減らすのか

ここから産業側を考えたい。

NESTORが学習FLOPsを抑え、KVStreamが再計算を減らし、Agentが経験を再利用するようになった場合、GPU需要は減少するのだろうか。

答えは、現時点では決められない。

単位仕事量当たりの計算資源が減少したとしても、処理される仕事の量が増えれば、総計算需要は増加する可能性がある。

逆に、効率化が進んでも利用量が増えなければ、必要な設備は減るかもしれない。

考えるべき関係は次のようになる。

総資源需要 ≒ 単位仕事当たりの資源使用量 × 実仕事量 × 技術の採用率

実際には学習と推論、検証、保存、ネットワーク、待機などを別々に測る必要があるため、これは簡略化した関係式である。

さらに研究の方向性によって、需要を受ける半導体の種類も変わる。

NESTOR型の条件付き計算では、Routingや分散Expertの配置が重要になる。

内部状態共有では、状態の保存と転送が問題になる。

KVStream型の仕組みでは、SSDとネットワークの役割が増える可能性がある。

検証型Agentでは、Verifierや実行環境を動かす追加計算が必要になる。

つまり、AIの効率化は、単純な計算需要の減少ではなく、計算資源の構成比率を変える可能性がある。

GPU、HBM、DRAM、SSD、ネットワーク、CPU、電力のどこへ負担が移るかは、各技術の実装方法と利用量に依存する。

第6章　現実の供給制約――投資額は、使える計算能力ではない

研究の世界で計算方式が変わる一方、半導体産業とAIインフラでは別の問題が進んでいる。

需要に対応するための設備投資が増えても、それが直ちに良品供給や本番稼働へ転換するわけではない。

6-1. 先端実装は契約から量産まで時間を要する

2026年10月8日、GlobalFoundriesはTSMCのCoWoS先端実装向けシリコンインターポーザ供給について、20億ドル規模の製造契約を発表した。

生産拠点は米国ニューヨーク州Maltaであり、量産立ち上げは2028年上期を見込む。

GlobalFoundries公式発表

この契約は、先端実装の供給基盤を広げる重要な動きだ。

しかし、2026年に契約が成立したからといって、2026年にその分の良品インターポーザが市場へ供給されるわけではない。

将来の生産能力と、現在利用可能な供給能力は分ける必要がある。

さらにHBMでは、積層数が増えるほど接合方法と熱管理が重要になる。

ハイブリッドボンディングは有力な次世代技術だが、サンプル出荷、顧客認定、限定的商業化、全面量産は異なる段階である。

製造方式が優れていても、良品率と工程コストが十分でなければ大規模な置き換えは進まない。

6-2. GPUが存在しても、稼働できるとは限らない

AIデータセンターでも同じことが起こる。

電力契約を結んだこと、建物が完成したこと、GPUが設置されたこと、顧客が本番の仕事を実行できることは、すべて異なる。

10月22日以降に発生したCoreWeaveのUS-EAST-15Aにおける電力・冷却障害では、電源復旧、冷却設備の再発、再度の電力問題、監視状態への移行といった工程が確認された。

10月31日朝の観測記録では、完全な復旧を示す公式のResolved確認に至っていなかった。ただし、これはその観測時点の状態であり、その後の更新まで断定するものではない。

この事例が示すのは、GPUの数量だけではデータセンターの可用性を説明できないということだ。

電力、冷却、配電、ラック、ストレージ、ネットワークが揃って初めて計算設備は利用可能になる。

6-3. 小さな部品がシステム全体の納入を止める可能性

10月29日付のFusion Worldwideの市場レポートでは、Vishayの一部AI関連MOSFETについて104週間超の納期、Diodes Incorporatedの一部顧客について要求数量の約10%しか割り当てられない事例が報告された。

Fusion Worldwide：The Greensheet October 2026

これは販売代理店による市場観測であり、メーカーが全製品について公式に示した納期ではない。

それでも、重要な警戒材料である。

高性能GPUを確保しても、必要な電源部品やアナログ半導体が揃わなければ、システム全体の出荷は遅れる可能性がある。

もちろん、この報告だけで世界のアナログ半導体が全面的に不足しているとは判断できない。

不足が本当に起こっているかを評価するには、製品型番、数量、顧客、納期、代替可能性、認定状況が必要だ。

重要なのは、AI設備の供給能力が、最も高価な部品ではなく、代替できない一つの工程や部品によって決まる場合があるという点である。

第7章　もう一つの律速――安全なコードを作ることと、安全に配布することは異なる

AIがコードを生成し、脆弱性を発見し、修正案を作成する能力は高まっている。

しかし、修正が完成したことと、利用者の環境が安全になったことは同じではない。

この問題を示したのが、2026年10月21日のLiteLLMのサプライチェーン侵害である。

攻撃者は公開リポジトリに流出した管理用認証情報を起点に、追加の権限を獲得し、公式リリース経路を悪用した。

その結果、悪意あるv1.107.0がパッケージやコンテナイメージとして公開された。

LiteLLM公式の根本原因報告

その後、問題のある配布物は取り下げられ、新しい署名鍵や証明書の信頼設定変更を含む修正が提供された。

しかし、上流の修正提供だけでは、すべての下流環境で更新が完了したことにはならない。

侵害された認証情報がすべて適切に更新されたか。

影響を受けた環境が再構築されたか。

利用者のシステムが正常に復旧したか。

それぞれ別の確認が必要になる。

この構造は、AI Agentの自己改善ともつながっている。

Agentが新しいSkillを作れるようになったとしても、そのSkillが安全かどうかを検証し、署名し、配布し、実際の環境で正しく動作することを確認しなければならない。

能力を獲得する速度と、安全な能力として運用へ反映する速度は異なる。

AIによる発見と修正が高速化した場合、後者が新たな律速になる可能性がある。

ただし、現在の公開情報だけで、AIによる発見速度が業界全体のパッチ適用速度を上回っていると定量的に結論することはできない。

これは今後、発見から適用確認までの時間を同一条件で追跡すべき仮説である。

第8章　複数の研究と産業情報は、どの方向に収束しているのか

ここまでの研究と産業情報を整理すると、少なくとも四つの方向が見えてくる。

第一の変化：計算量から計算経路へ

NESTORは、すべての入力に同じような計算経路を使う前提をさらに緩めようとしている。

今後、重要になるのはパラメータ数だけでなく、どの入力にどの計算経路を使うかという選択である。

第二の変化：情報の再生成から状態の再利用へ

内部状態共有、KVStream、長期Memoryの研究は、すでに計算した情報をどう再利用するかという問題へ向かっている。

その結果、GPUの演算性能だけではなく、記憶階層とデータ移動の効率が重要になる可能性がある。

第三の変化：推論の成功から実行結果の検証へ

Phronix、ImpasseBench、VeriCUAが扱うのは、単に回答を出す能力ではない。

過去の成功を再利用すること、実行できない状態を認識すること、本当に仕事が完了したかを確認することだ。

Agentの能力を測る際には、単一のベンチマーク成功率よりも、長時間の実行における最終成果と総費用が重要になる。

第四の変化：設備投資額から実効供給能力へ

半導体では、契約した製造能力と認定済みの良品供給量は異なる。

データセンターでは、確保した電力容量と、本番のAI処理に利用できる容量は異なる。

ソフトウェアでは、修正を公開したことと、利用者の環境で修正が適用されたことは異なる。

これらは異なる産業の問題でありながら、同じ構造を持っている。

計画された能力と、実際に利用可能な能力の間には、変換工程が存在する。

そして、その工程のいずれかが遅れれば、他の部分の能力が増えても全体の成果は制限される。

第9章　今後6〜24か月で確認すべきこと

S候補が本当の構造変化に成長するかを判断するためには、次の条件を追う必要がある。

1. NESTORの大規模化

数百億Active Parameters級での学習効率、長期学習時の忘却、実機の学習時間、TTFT・TPOT、通信量、HBM消費を比較する。同じ品質と同じ条件で改善するかが重要だ。

1. 内部状態共有の実用化

異なるモデル、異なるバージョン、複数のAgent間で内部状態を安全に共有できるか。文章による通信と比較して、品質を維持しながら総費用を削減できるかを確認する。

1. Agentの能力蓄積と検証

保存したSkillが別の仕事にも有効なのか。長期間の更新で性能が低下しないか。実行成功率だけでなく、検証費用、失敗後の復旧、権限逸脱を含めて評価する。

1. KV・RL基盤の本番採用

KVStreamやKnitTransの改善が、限定的な研究条件を超えて、実際の大規模サービスで再現されるか。GPU節約と引き換えにSSD・ネットワーク・CPU・電力の費用が増えていないかを確認する。

1. 半導体とデータセンターの実効供給

HBM、先端実装、光部品、テスト、アナログ半導体について、設備投資や受注ではなく、仕様別の良品供給量と顧客認定を追う。データセンターでは契約MW、通電MW、顧客検収、本番稼働、売上回収を区別する。

1. セキュリティの適用完了

脆弱性の発見件数や修正公開速度に加えて、署名済み配布、実際の適用率、認証情報の更新、復旧確認までを測定する。安全対策に必要な計算量と、失敗を防いだ効果の両方を見る。

これらの条件が満たされない限り、研究の性能倍率を産業全体のGPU需要や企業収益へ直接換算するべきではない。

結論――次のAI競争は、より大きなモデルを作ることだけでは終わらない

2026年10月の研究で、最も根本的な変更を提案したものの一つがNESTORである。

Attentionそのものを条件付き計算へ拡張するという発想は、TransformerとMoEの計算構造に新しい選択肢を与えた。

一方、内部状態共有は、Agent同士が文章を介して情報を交換する前提を問い直した。

Phronixは、Agentの経験を再利用可能な能力として蓄積する方向を示した。

KVStreamとKnitTransは、それらを成立させるために必要な状態保存とデータ転送の問題を具体化した。

そして半導体、電力、冷却、セキュリティの観測は、研究上の能力がそのまま実際の供給能力になるわけではないことを示している。

ここから一つの仮説を導ける。

AIの競争は、計算能力の総量を増やす競争から、計算・記憶・実行・検証・供給を一つのシステムとして機能させる競争へ、次第に広がっていくのではないか。

もちろん、GPUの数量や大規模学習が重要でなくなるわけではない。

むしろ、より大きな計算設備を保有する企業ほど、それをどれだけ無駄なく利用できるかが重要になる可能性がある。

計算を選択し、状態を保存し、経験を蓄積し、失敗を検証し、安全に実行できるようにする。

そして、それらを支える半導体とデータセンターを、計画上の容量ではなく、実際に使える状態へ転換する。

次のS級構造変化が本当に起こるとすれば、それは一つの論文が高いベンチマークを記録した瞬間ではないだろう。

モデルの内部で生じた改善が、Agentの実仕事量を変え、インフラの利用方法を変え、最終的に同じ費用で実現できる仕事の量を持続的に増やしたときである。

その連鎖が成立するかどうか。

それこそが、これからAI産業を観測するうえで最も重要な問いになる。

調査基準：2026年11月1日。研究部分は2026年10月15〜31日を中心とし、産業側は同月末までの公開情報・観測記録を参照。論文の倍率は著者らの実験条件に依存する。企業の計画、契約、サンプル、量産、顧客稼働を混同せず、製品・地域別の実需と実効供給が不明な項目については確定的な需給判定を行わない。