富士通の新AIアーキテクチャ 「PHOTON」 の凄さと“475倍”のカラクリを技術的に考察してみた
話題になっている富士通の新AIアーキテクチャ 「PHOTON」 について、技術的なアプローチやプレスリリースで謳われている数値の裏側を詳しく読み解いてみました。
きっかけは、開発者である富士通の市川佑馬氏が出演されていたYouTubeの解説動画（テレ東BIZ『理系通信』）を拝見したことです。
参考動画：
富士通が開発「PHOTON」ChatGPTやClaude超える？開発トップを直撃【理系通信】（YouTube）※概要欄より一部引用：「現状のPHOTONは、モデルのサイズが12億パラメータと小規模な研究モデルですが、『モデルサイズが大きくなれば、勝ったも同然だ』と自信を見せます。」
しかし、動画内で語られていた「モデルサイズが大きくなれば勝ったも同然」という発言や、「ChatGPTやClaudeを超える」といったメディアの煽り文句に対しては、率直に言って 「流石に誇張しすぎではないか？」 と強い疑問を抱かざるを得ませんでした。
技術的なアイデアとしては面白いものの、 「既存のTransformer（Claude、Gemini、ChatGPTなど）の完全な代替」 になるような期待は構造的にあり得ないと考えています。
その理由を、 「表現力と計算効率のトレードオフ」 や 「多数決（マルチクエリ統合）の限界」 といった観点から解説します。
PHOTONの仕組み：縦の 「2階建て分業」
まず、PHOTONが解決しようとしている課題とそのアイデア自体は非常にわかりやすいものです。
従来のTransformerは、長い文章を読む際にすべての文字と文字の関係性を同時に計算するため、入力が長くなるほど計算量とメモリ消費量が爆発（$O(N^2)$の壁）します。
これに対し、PHOTONは人間が厚い本を読むときの頭の使い方を模して、処理を縦の2階建てに分業させています。
- 「2階（大局把握）」 ：文章全体の流れを「要約データ」として大雑把に保持する。
- 「1階（詳細生成）」 ：2階からの指示を受け取りながら、目の前の文脈を1文字ずつ細かく生成する。
生データをすべてメモリに載せるのではなく、2階が作った「要約データ」を使い回すことで、メモリ消費量を劇的に抑えることに成功しています。
1文字のミスも許されない現場での致命的な弱点
しかし、この 「情報を要約して保持する」 というアプローチには構造的な弱点が存在します。
情報の圧縮＝確実な情報の欠落だからです。
文章の要約や日常会話程度なら問題になりませんが、 「記号1文字、1行のズレが致命傷になる領域」 ではハルシネーション（嘘）や精度の低下が顕著に表れます。
具体例1：Webシステムのプログラム
例えば、Pythonでログイン処理のパスワード比較を行うコードを考えてみます。
# 正常な判定コード
if password == input_password:
allow_login()
要約によって記号の連続性がノイズとして処理されてしまうと、==（比較演算子）が =（代入演算子）に抜け落ちてしまうリスクが生じます。Pythonにおいてこれはセキュリティ崩壊を意味します。
具体例2：ECサイトの決済処理
「購入ボタンが1回押されたか、連打されて2回処理されたか」という繊細な文脈・ログの差分も、要約によって 「似たような処理の重複」として消し去られてしまう懸念 があります。
※低レイヤ開発における影響
C言語（Linuxカーネル等）、CUDA、Tritonといった分野におけるポインタの1文字や、レジスタのビットマスク（例:0x0Fが0x0Eになるなど）のズレを「微小なノイズ」として圧縮してしまった場合、システム全体のクラッシュにつながるため、ミッションクリティカルな開発への適用は極めて厳しいと言えます。
プレスリリースにある 「475倍」 という数字の正体
プレスリリースなどで目を引く 「475倍」 という驚異的な数値。これを聞くと「応答速度が475倍速くなった」あるいは「性能が475倍賢くなった」と錯覚しがちですが、実態は異なります。
この数値の正体は、 「モデルを軽量化・短縮化してメモリを徹底的に削った結果、1枚のGPUに同時に詰め込めるリクエスト（マルチクエリ）の数が最大475倍になった」 という 「スループット（並列処理数）」 の話です。
1トンの荷物を細かく粉砕して475台の軽トラックに詰め込み、「同時に並べて運べる量（容量）が増えた」と言っている状態に近く、1人のユーザーに対する処理能力が爆発的に向上したわけではありません。
単一レスポンスの 「遅延（レイテンシー）」 はむしろ不利？
1人のユーザーが利用する際の体感速度という観点では、PHOTONには以下の構造的ボトルネックがあります。
-
階層間のデータバケツリレー
「上層モデルで要約を作る ➔ 下層モデルへ引き渡す」という直列処理が発生するため、階層を跨ぐデータ転送待ちによる遅延が生じる。 -
多数決（マルチクエリ統合）によるオーバーヘッド
情報圧縮による精度低下を補うため、同じ質問に対して表現を変えたクエリを複数走らせ、多数決で回答を統合する手法をとっている。
多数決（マルチクエリ統合）が抱える限界
「多数決をとって精度が補えるなら良いのでは？」と思えるかもしれませんが、これにも明確な限界とコストが存在します。
1. 完全に消去された記憶は引き出せない
多数決が有効なのは、 「頭の中に知識自体は存在するが、確率のブレによって正しい出力が得られなかった時」のみです。
圧縮プロセスによって最初から消滅・欠落してしまった知識は、何回推論を繰り返して多数決をとっても復元することはできません。消えた記憶はどう足掻いても出せないのです。
2. 「繊細なニュアンス」 や 「知性」 の平均化
ClaudeやGeminiなどの高度なLLMの真価は、文脈の行間、感情、ユニークな視点や論理展開にあります。
多数決（統合処理）は回答の 「最大公約数」 をとる作業であるため、こうした高度で繊細な表現やエッジの効いた考察は 「ノイズ」 として平均化されて消えてしまい、無難でつまらない出力に落ち着いてしまいます。
3. 計算コストと待ち時間の目減り
例えば9回の多数決を行う場合、裏では9つのモデルを同時に走らせる必要があります。
せっかく475倍の効率化を達成しても、1回の回答のために9倍の計算を行うのであれば、実質的な計算コスト・電力の節約効果は9分の1に目減りします。
さらに、9つの出揃いを待つ分、ユーザーへの応答速度は一層遅くなります。
まとめ：PHOTONの正しい立ち位置とは
PHOTONの論文等で示されている 「従来Transformerと同水準の性能」という結果は、あくまで 1.2B（12億パラメータ）程度の極小サイズモデル において、特定ベンチマークで多数決を行って追いついたという限定的な条件下のものです。
現在最前線で動いている巨大モデル（数千億〜兆クラスのパラメータ群）が持つ、「数万行のコード解析」「高度な論理推論」「複雑な文脈理解」 といった領域では、構造的にハルシネーションの壁を突破するのは難しいと考えられます。
- PHOTONが向いている領域： 記憶の完全性が厳しく問われない、エッジデバイスや大量のリクエストを低メモリで捌きたい特定タスク
- PHOTONが苦手な領域： 1文字のミスも許されないプログラミング・インフラ構築、高度な創造性や繊細なニュアンスが求められる文章作成
新しい技術のアプローチとしては非常に革新的で素晴らしいものですが、プレスリリースの数字に惑わされず、 「表現力と計算効率のトレードオフ」 という本質を見極めて使いどころを判断することが重要だと感じました。