なぜ今どきのLLMはdecoder-only構造なのか

0. はじめに

この記事は F2. Transformerって結局何なのか を読まれた方を想定しています。

「Transformerは文を一度に広げて、attentionで単語どうしの関係を計算する構造」という感覚があれば、この記事はすっと読めます。

---

1. まずは白状から

Transformerを少し深掘りすると、こういう図を必ず1回は見ることになります。

左側に「Encoder」と書かれた四角いかたまり
右側に「Decoder」と書かれた四角いかたまり
その間を矢印がつないでいる

そしてみんなこう説明します。「これがTransformerの元々の構造だよ。」

ところが同じ説明のすぐあとに、こんな話が出てきます。

「ChatGPT、Claude、GPT-4はdecoder-only構造だよ。」

この地点で多くの方が止まります。

• じゃあ左側のencoderはどこに行った?
• なぜ捨てられた?
• BERTはencoder-onlyって聞いたけど、それはまた何?
• T5はencoder-decoderだって?

この記事は、その混乱を一度にほどくために書いています。

まず一文で押さえるなら:

Encoderは「読む部分」で、Decoderは「書く部分」。もともと翻訳機では両方必要だったけれど、文章生成中心のLLMではdecoderひとつだけを大きく育てるほうがうまくいく、というのが明らかになった。

これを解きほぐしていきます。

---

2. もともとの論文は翻訳機を作っていた

「Attention Is All You Need」(2017) は 英語 → ドイツ語の翻訳モデル を提案した論文です。

なのでもともとのTransformerはこういう作業をします。

入力: “The cat sat on the mat.”
出力: “Die Katze saß auf der Matte.”

こうした作業には2つの仕事が必要です。

1. 入力の文を理解する(英語が何を言っているのかつかむ)
2. 理解した内容を別の言語で書き起こす(ドイツ語として自然に出力する)

この2つの仕事を1つのかたまりに詰め込まず、2つの専門部署 に分けました。

• Encoder(エンコーダー): 入力文を読んで 意味ベクトル に圧縮する部署
• Decoder(デコーダー): その意味ベクトルを受け取って別の言語として 1単語ずつ生成する 部署

たとえるなら:

読解担当(Encoder)が英語の文を丁寧に読んで要約メモを作り、
作文担当(Decoder)がそのメモを見ながらドイツ語の文を書き下ろしていく。

この2人の間でやりとりされるのが 意味ベクトル です。

翻訳のように入力と出力の形式が違う作業には、この構造がぴったりです。

---

3. Encoderがやること — 「読んで理解するだけ」

Encoderはシンプルなルールを1つだけ守ります。

すべての単語が、文のすべての単語を見ていい。

「The cat sat on the mat」が入ってくると:

• 「cat」は「The, sat, on, the, mat」すべてを参照して自分の意味を更新
• 「sat」も他のすべての単語を参照して更新
• …

すべての単語が双方向にお互いを見ます。

これを bidirectional attention(双方向アテンション) と呼びます。

なぜこれが許されるかというと、文全体がすでに与えられているから です。「cat」が「sat」を先に見てもカンニングではありません。どうせ文全体が見える状態で圧縮しているわけですから。

Encoderの役割は、文全体を読んで、各単語が文脈に合わせて表現し直されたベクトルの束 を作ることです。

この束を受け取ると、Decoderが翻訳を始められます。

ちなみにこの「全体を一度に読める」という性質は、Encoderがなぜ理解タスクでそこまで強いのかという答えにも直結しています。ある単語の意味は、前の単語と後ろの単語の両方を見たほうが当然しっかり決まるからです。「bank」という単語が銀行のことなのか川岸のことなのかは、前後を両方見ないと判定できませんよね。Encoderはそれを構造としてそのまま持っている、という話です。

---

4. Decoderがやること — 「1単語ずつ書いていく」

DecoderはEncoderと違って、ルールがもう1つ 追加されます。

今書いている単語は、まだ書いていない単語(後ろ)を見てはいけない。

「Die Katze saß auf der Matte」を書くとき:

• 最初の単語「Die」を書くときには、その後に何が来るか知りません(当然です、まだ書いていないので)
• 「Katze」を書くときは前の「Die」だけを参考にする
• 「saß」を書くときは「Die Katze」までだけを参考にする
• …

つまり 左方向にだけ 見られます。これを masked attention または causal attention と呼びます。

なぜこう塞ぐのか?

もし「saß」を作るときに、その後に来る「auf der Matte」を先に見られるとしたら、学習時にはカンニングになります。答えを見ながら答えを当てているわけです。

でも実際の推論時にはその先を知らないですよね。だから学習と推論の環境を合わせるため、後ろを隠した状態で 学習させます。

そしてDecoderはもうひとつ、別のことをやります。

Encoderが渡してくれた意味ベクトルも参照する。

つまりDecoderの各単語の席ではattentionが 2回 起きます。

1. ここまで書いた自分の出力(左側)を見る → self-attention
2. Encoderから渡された意味ベクトルを見る → cross-attention

この cross-attention が翻訳の核です。ドイツ語を書くときにも、元の英語の文のどこを見ながら書いているのかを、ずっと確認しているわけです。

こうしてDecoderは1単語ずつ:
– 自分の前の単語を参照し
– Encoderの英語の意味を参照し
– 次の単語の確率分布を計算 → 1単語を引く
– 繰り返し

これを EOS(end of sequence) トークンが出るまで続けます。

---

5. ところが対話型AIはちょっと違う

ここまで見るとencoder + decoderの組み合わせはけっこう自然に見えます。

でもChatGPTのような対話型AIを思い浮かべてください。

あなたが「PythonでCSVを読む方法を教えて」と入力すると、ChatGPTが「import pandas as pd…」と答えます。

ここで入力と出力は 根本的に違う言語 でしょうか?

いいえ。どちらも日本語 + コードが混ざった普通のテキストです。

そしてもっと大事なのは、会話はずっと続いていく という点です。

あなたが答えをもらって「pandasじゃなくて標準ライブラリで」と追加質問をすると、今度は入力は [あなたの最初の質問] + [ChatGPTの最初の答え] + [あなたの追加質問] になります。

これは入力なのか出力なのかが、だんだん曖昧になってきます。

この時点で 「いっそdecoderだけを大きく1つ作って、全部をdecoder式で処理すればいいんじゃない?」 という発想が出てきます。

• 文全体(あなたの質問 + AIの回答)を ひとつの連続した文章 として見る
• Decoderが この文章の次の単語をずっと予測 する
• どこまでが「入力」でどこからが「出力」かをモデル側で区別する必要はない

この発想から出てきたのが decoder-only モデルです。

GPT、Claude、Gemini、Llama、ぜんぶこの構造です。

---

6. Decoder-onlyがなぜ勝ったのか

「翻訳用にはencoder+decoderが自然、対話用にはdecoder-onlyが便利」くらいの話だったら、今みたいにdecoder-onlyが圧勝することはなかったはずです。

本当の理由は別にあります。

(1) 構造がシンプル

• encoder+decoder: attentionの種類が3つ(encoder self、decoder self、cross)
• decoder-only: attentionの種類が1つ(masked self)

構造がシンプルだと学習・推論のコードもシンプルになります。規模を大きくしやすく、最適化も効きやすい。

(2) 「次の単語予測」ひとつでほぼすべての作業をやらせられる

decoder-onlyモデルは 「次の単語予測」 というただ1つの作業でしか学習しません。

ところがその1つでぜんぶ済んでしまうんです。

• 翻訳: "英語: The cat sat. ドイツ語:" の次に来る単語を予測 → 翻訳される
• 要約: "長い文章。要約:" の次に来る単語を予測 → 要約される
• 質問応答: "質問: …。回答:" の次に来る単語を予測 → 回答される
• コード: "Write Python to read CSV. Code:" の次に来る単語を予測 → コードになる

1つの学習目標(next token prediction)で ほぼすべてのNLP作業 を表現できるとわかりました。

これがGPT-3の論文(「Language Models are Few-Shot Learners」)が世に衝撃を与えた核心です。わざわざencoderを別に用意する必要がなくなったわけです。

(3) Scalingしやすい

Decoder-onlyは1種類のブロックをずっと積むだけの構造です。だから ものすごく大きくしても構造が崩れません。

encoder+decoderは2つの部分を分けて育てないといけないうえ、cross-attentionの接続も管理する必要があるので複雑です。

OpenAI、Anthropic、Meta、Googleがすべてdecoder-onlyに賭けた理由がこれです。

もうひとつ付け加えるなら、decoder-onlyは 学習データが集めやすい という大きな利点もあります。インターネット上のどんな文章も、そのまま「次の単語予測」の教材として使えます。encoder+decoder方式では「入力と出力のペア」が必要になり、たとえば翻訳なら英語とドイツ語のパラレルコーパスを用意しないといけません。ところがdecoder-onlyには対訳ペアが要らないので、「とにかく大量の文章をかき集めて流し込めば学習が進む」という、あまりに強力な性質を持っていました。この学習データの差が、規模の差をさらに広げていったんです。

---

7. じゃあencoderは死んだのか? — いいえ

ここで誤解が多い部分です。

「decoder-onlyが主流だからencoderは終わった技術」とまとめてしまうと、少し違います。

encoderが いまも主役 の領域があります。

(1) BERT系 — 分類・検索・類似度判定

BERT (2018) は encoder-only モデルです。

BERTがやること:
– 文を読んで 各単語のベクトル を作る
– このベクトルを使って分類、類似度計算、検索を行う

たとえば:
– スパムメール分類: メール本文 → BERT → ベクトル → スパム/通常の分類器
– セマンティック検索: クエリと文書をそれぞれBERTに通してベクトルにしたあと、ベクトルの距離で「意味的に似ているか」を判定

BERTは 生成 はしません。理解 の専門です。

今も 検索エンジン、レコメンドシステム、RAGのembeddingモデル 周りでBERT系がものすごく使われています。

ⓘ RAGの基本retrievalで使われるembeddingモデルはほぼすべてencoder-only系(BERT類)です。シリーズ本編 👉 M1. Retrieval Layer 理解 で詳しく扱います。

(2) T5系 — encoder+decoderハイブリッド

T5 (Google, 2019) はもともとの論文構造をそのまま大規模に押し進めたモデルです。

T5はすべてのNLP作業を 「テキスト → テキスト」 の形に置き換えて解きます。

• 翻訳: “translate English to German: …” → “…”
• 要約: “summarize: …” → “…”
• 分類: “sentiment: …” → “positive/negative”

入力と出力が分かれているこの構造には encoder+decoder が自然です。

今も 翻訳、要約、コード生成の専門モデル、特に 一部のmultimodalモデル(画像→テキスト) でこの構造が生きています。

(3) Vision とMultimodal

画像 → テキスト生成のような作業では encoder が再び戻ってきます。

• 画像encoderが画像をベクトルに圧縮
• テキストdecoderがそのベクトルを見ながら説明文を生成

GPT-4V、Claude 3.5 Sonnet vision、Geminiが内部的にだいたいこういう構造を混ぜて使っています。(完全 decoder-only の中に画像embeddingをpromptとして差し込む変種もあります。実装によって違います。)

---

8. 3つのタイプを整理

1度に比較テーブルでまとめます。

構造	代表モデル	得意なこと	限界
Encoder-only	BERT, RoBERTa, sentence-BERT	文章理解、分類、検索	新しい文を生成できない
Decoder-only	GPT, Claude, Llama, Gemini	文章生成、対話、コード、要約、翻訳まで	(初期には)純粋な理解作業はBERTより弱かった
Encoder-Decoder	元のTransformer、T5、BART	入出力が違う作業(翻訳、要約)	構造が複雑でscaleが難しい

面白いのは、もともと分かれていた役割がdecoder-onlyにだんだん統合されていく流れ だという点です。

GPT-4クラスになると分類・理解の作業もBERT級にこなせます。だから実務では「作業ごとに違うモデルを使う」よりも「decoder-onlyの大きいモデルひとつでほぼすべてカバー」の方向に進んでいます。

それでも 低コスト・低レイテンシが重要な作業(例: リアルタイム検索、スパム分類) では、いまだにBERT級の小さなencoderの方がはるかに実用的です。

---

9. 実務者の目線で、これがなぜ重要なのか

「私はモデル構造まで知らなくていい」と思われるかもしれません。

でもこの区別を知っていると、実務での判断が変わります。

(1) モデルを選ぶとき

• 「何千もの文書からクエリに一番近いものを探す」 → encoder-only(BERT系) + ベクトル検索。GPT-4に全部入れる必要はない。
• 「長い文書をそのまま要約」 → decoder-only(Claude、GPT)
• 「入力形式が固定で出力も固定の反復作業(例: フォーム解析)」 → fine-tunedされたT5系のほうが安く済むことがある

(2) プロンプトを設計するとき

decoder-onlyモデルの弱点は 前しか見ない という点です。「下の文章をすべて読んでから、前の部分をもう一度考慮して答えて」のようなリクエストは1回では処理できません。必要なら「全体を一度読んだうえで、もう一度頭から見ながら答えて」のような 再入プロンプト を設計する必要があります。

(3) なぜ「コンテキストウィンドウ」がこれほど重要なのかがわかる

decoder-onlyモデルは 入力を二度は読みません。 あなたが渡したコンテキストがそのまま 次トークン予測の条件 になります。

だから長いコンテキストを扱えるかどうかが、decoder-only時代には モデル競争の中核軸 になります。

Claudeが1Mトークンのcontext windowを発表し、GPTが128kまで伸ばし、Geminiが2Mまで押し上げる — これはすべてdecoder-only構造の弱点に正面から挑む動きです。

ⓘ 「でもコンテキストが大きくなればぜんぶ解決しますよね?」それがそう単純ではないんです。👉 M2. Long-context / Memory で lost-in-the-middle のような落とし穴まで解きほぐします。

---

10. なのでもう一度まとめます

• 元のTransformer (2017): encoder + decoder。翻訳のような入出力が違う作業用。
• BERT (2018): encoder-only。理解・分類・検索専門。生成はしない。
• GPT / Claude / Llama / Gemini: decoder-only。次単語予測1つでほぼすべての作業を処理。
• T5 / BART: encoder + decoder。「テキスト → テキスト」形式の専門作業用。

今AIのニュースを読むとき、この4軸が頭にあれば「このモデルは何?」という質問にぼんやりしていた感覚が、すぐに構造として見えてきます。

• 「embeddingモデルです」 → encoder-only系
• 「対話・文章生成のLLMです」 → decoder-only
• 「翻訳・要約の専門です」 → encoder-decoder
• 「マルチモーダルです」 → たいていは decoder-only に image encoder を1つ付けた形

---

締めの一文

encoder-decoder構造は、翻訳機として生まれたTransformerを説明してくれるものの、今私たちが使っているほぼすべての対話型LLMは decoderひとつだけを大きく育てて「次の単語をひたすら予測させる」形にしたもの であり、この単純化こそがscalingを可能にした決定的な分かれ道でした。

---

FAQ

Q1. BERTとGPTではどちらが賢いですか?

「賢さ」の基準によって答えが変わります。文の理解・類似度判定・検索のような作業は以前はBERTの方がうまく、今でも 同じコスト なら小さなBERT系の方がGPT-4より速く、安く、うまくこなします。いっぽう 新しい文を自然に生成 したり 複雑な指示に従う 作業は decoder-only(GPT・Claude系)が圧倒的です。2つは「賢さの軸」が違います。作業に合わせて選ぶのが正解です。

Q2. じゃあEncoderの勉強はしなくていいですか?

生成AIだけを使うのであれば、直接触れる機会はほとんどありません。ただし RAG(検索拡張生成)を実務に組み込むと必須 になります。RAGの「検索」段階は、クエリと文書をベクトルに変換するencoderモデルが担当します。ClaudeやGPTが優秀でも検索がダメなら答えが的外れになります。だから実務者にも「BERT系のembeddingモデルとは何か」という感覚くらいはあると役立ちます。

Q3. ClaudeやGPTの中にもencoderが隠れているんですか?

厳密に言うと decoder-only構造には別のencoderはありません。 その代わり、decoderが入力(プロンプト)を読む過程そのものがBERTのencoderの役割を真似することになります(前だけしか見られないという制約はありますが)。最近のマルチモーダルモデルでは画像処理用の別encoderが付いているケースはあります。テキストだけに限って言えば、ChatGPT・Claudeは「decoderひとつで読み書きを同時にやっている」と捉えていただいて大丈夫です。

---

ニュースレターのご案内

こうして構造の違いを一度につかめるよう解きほぐす技術解説を、毎週月曜日の朝にメールでお届けしています。受け取ってみたい方は ニュースレター会員登録(無料・30秒) からどうぞ。

---

著者: バイブコーディング テイラー(Lovable公式アンバサダー)
運営: テイラーの隠れ家(shuntailor.net)

ソースリスト

• テイラー知識百科事典 — AIのしくみ地図カテゴリ（本シリーズ20編全編）
• AIのしくみ地図 エントリーマップ — 全体構造 + 3つの読み方
• “Attention Is All You Need” (Vaswani et al., 2017)
• Anthropic · OpenAI · Google 公式ドキュメント
• mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown — 易しい解説のリファレンス

---

著者: バイブコーディング テイラー (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ「AIのしくみ地図」20編は、ウィキの蓄積と公式論文・公式ドキュメントを根拠に整理した体系的学習カリキュラムです。