SwiGLUとは？LLMの性能を底上げする活性化関数を図解でやさしく解説

LLMのアーキテクチャ図を眺めていて、「SwiGLU」という文字だけが読み飛ばされている。そんな経験ありませんか。Attentionの説明はどこにでもあるのに、その隣のFFN（フィードフォワード層）は「まあ全結合層でしょ」で片付けられがち。

でも実は、LLMのパラメータの約3分の2はFFN側にあります。Attentionではありません。そこで使う関数を変えるだけで品質が動くなら、無視できる話ではない。

SwiGLUとは、Swish（別名SiLU）という滑らかな活性化関数と、GLU（ゲート付き線形ユニット）という仕組みを組み合わせた活性化関数です。Noam Shazeerが2020年の論文「GLU Variants Improve Transformer」で提案しました。

---

SwiGLUは結局なにをしている関数なのか

SwiGLUは「片方の経路が、もう片方の経路の音量つまみを回す」構造です。入力ごとに、通す情報と抑える情報をモデルが自分で選びます。

まず言葉の整理から。活性化関数とは、ニューラルネットの中で「この値をそのまま次に渡すか、弱めるか、消すか」を決める小さな関数のことです。これが無いと、何層重ねてもただの掛け算の連続になり、複雑なパターンを学べません。

従来のFFNはこうでした。

1. 入力を大きな行列で引き伸ばす
2. 活性化関数（ReLUなど）を通す
3. もう一度行列で元のサイズに戻す

SwiGLUはここにもう1本の経路を足します。引き伸ばす行列を2つ用意して、片方にはSwishを通し、もう片方はそのまま。そして2つを要素ごとに掛け算する。

この掛け算が肝です。Swishを通した側が0付近の値なら、相手の値がどれだけ大きくても結果は0付近になる。逆にSwish側が1に近ければ、相手はほぼそのまま通過する。つまり片方が門番（ゲート）として機能しているわけです。

ゲート付き、と呼ばれる理由がここにあります。

固定のルールで一律に切り捨てるのではなく、入力の内容次第で通す量が変わる。これが「入力依存のゲート」の意味です。

次に、その門番役であるSwishがどんな形をしているか見ていきます。

---

Swish（SiLU）とはどんな関数か

Swishは、xにシグモイド関数を掛けただけの関数です。ReLUに似た形ですが、0付近が滑らかにへこむのが違いです。

式にすると Swish(x) = x × sigmoid(x)。SiLU（Sigmoid Linear Unit）という別名でも呼ばれ、PyTorchではnn.SiLUとして実装されています。

ReLUとの違いを整理します。

つまりSwishは「ReLUのなめらか版」です。角が無いぶん学習時の勾配（どちらに重みを動かすかの手がかり）が安定しやすい。

ここで小さな注意点。Swishには本来βという係数があり、x × sigmoid(βx)と書かれることもあります。LLMで使われるSwiGLUでは、このβを1に固定した形（＝SiLU）がほぼ標準です。論文や記事でSiLUとSwishが混ざって出てくるのは、この事情によります。

なめらかな関数を門番にすると、閉じるか開くかの二択ではなく「6割開く」のような中間状態が作れます。これが表現力の源です。

---

GLUのゲート構造はどう効いているのか

GLUは「値の経路」と「ゲートの経路」を分け、掛け算で合流させる仕組みです。ゲート側が0に近いほど、その特徴は次の層へ伝わりません。

もう少し噛み砕きます。

普通のFFNは、入力に対して一律の変換をかけます。「この方向の特徴は強調、この方向は無視」というルールが重みとして固定されている。学習後は入力が何であれ同じルールが適用されます。

GLUは違う。ゲート経路も学習された重みを持つので、入力ごとに違う抑制パターンが生まれます。文法的な処理をしている場面と、固有名詞を扱っている場面で、活きる特徴が切り替わる。そういう芸当ができます。

GLUには複数の派生があります。中で使う活性化関数を差し替えたものです。

Shazeerの論文はこれらをまとめて比較し、ゲート付きの派生がどれも素のFFNを上回ることを示しました。中でもSwiGLUとGEGLUが安定して良い。

論文の締めくくりが有名です。うまくいく理由については「神の恵み（divine benevolence）」に帰する、と半分冗談で書かれている。理論的な説明が後追いになっている領域なんです。

この正直さは、実は重要な示唆を含んでいます。次のセクションで触れます。

---

なぜSwiGLUで性能が上がるのか？

明確な理論的証明はまだありません。実験的に「同じ計算量で品質が上がる」ことが繰り返し確認されているため採用されています。

これは歯切れの悪い答えですが、事実です。原論文の著者自身が理論的説明を避けている。

現時点で有力とされている説明は3つあります。

1. 入力依存の情報選択ができる

固定の非線形変換より、状況に応じて特徴を選べるほうが表現の幅が広い。ゲートは一種の注意機構（Attention）を、FFNの内部に小さく持ち込んだようなものだという見方があります。

2. 勾配が流れやすい

Swishはすべての点で微分できます。ReLUのように負側で完全に0になる（＝勾配が消える）現象が起きにくい。深いモデルほど効きます。

3. 掛け算そのものが表現力を持つ

2つの経路の掛け算は、足し算では作れない相互作用を生みます。特徴同士の「AND条件」に近い表現が、1層で作れるようになる。

ただし、いずれも後付けの説明です。

ここまでの整理 SwiGLU＝Swish（なめらかな活性化）×GLU（ゲート構造）。ゲート経路が値経路の通過量を入力ごとに調整する。ReLUやGELUより表現力が高く、実験的に品質が上がる。理由の理論的解明は途上。

理由が分からなくても採用される。この状況が実務にどう影響するかは、パラメータ数の話とセットで考える必要があります。

---

パラメータが1.5倍になるのに「計算量は同じ」とはどういうことか

SwiGLUは行列を3枚使うため、素朴に置き換えるとパラメータが1.5倍になります。そこで中間層の幅を2/3に縮めて帳尻を合わせるのが慣例です。

順を追って説明します。

従来のFFNは行列を2枚使います。引き伸ばす行列と、元に戻す行列。中間層の幅は、入力の4倍にするのが定番でした。

SwiGLUは3枚必要です。ゲート用、値用、そして戻す用。同じ幅のまま置き換えると、FFN部分のパラメータが1.5倍に膨らみます。

つまり「4倍」を「8/3倍（約2.67倍）」に落とせば、行列が1枚増えてもパラメータ総数は変わりません。LLaMA系のモデルがFFNの幅に中途半端な数字を使っているのは、この2/3調整の名残です。

論文の比較実験も、この条件をそろえた上で行われています。「パラメータを増やしたから強い」のではなく、同じ規模で品質が上がるという主張になっているのはそのためです。

ここは誤解が多いポイント。「SwiGLUは重い」という話を聞いたら、幅を調整していない実装の話かどうかを確認したほうがいい。

もっとも、パラメータ数が同じでも、行列積が3回になるぶんメモリアクセスは増えます。学習速度が完全に同じにはなりません。

実装レベルの話に進みます。

---

実装はどれくらいの手間なのか？

PyTorchなら10行程度で書けます。既存のFFNクラスの中身を差し替えるだけで、モデル全体の構造には手を入れません。

擬似コードで骨格を示します。

class SwiGLUFFN(nn.Module):
    def __init__(self, dim, hidden_dim):
        super().__init__()
        # hidden_dim は 4*dim ではなく 8/3*dim 程度にする
        self.w_gate = nn.Linear(dim, hidden_dim, bias=False)
        self.w_up   = nn.Linear(dim, hidden_dim, bias=False)
        self.w_down = nn.Linear(hidden_dim, dim, bias=False)
        self.act = nn.SiLU()

    def forward(self, x):
        return self.w_down(self.act(self.w_gate(x)) * self.w_up(x))

見どころは3点。

• 線形層が3つ（w_gate w_up w_down）
• nn.SiLU()がSwishの実体
• *が要素ごとの掛け算。ここがゲート

バイアス項を省くのがLLM実装での通例です。効果が薄いわりにパラメータを食うため。

実装で詰まりやすいのはhidden_dimの決め方です。8/3倍した値をそのまま使うのではなく、GPUが効率よく扱える倍数（256の倍数など）に丸めるのが一般的。この丸めのせいで、公開モデルの設定値が一見不規則な数字になっています。

小さなモデルで試すなら、既存の実装済みライブラリを触るほうが早い。画像生成まわりのローカル環境構築に慣れている人なら感覚がつかみやすいはずで、ComfyUIとStable Diffusionの違いを扱った記事でもモデル内部の構成要素をどう差し替えるかに触れています。

---

ReLU・GELU・SwiGLUはどう使い分けるべきか

新規にTransformer系のモデルを組むならSwiGLUが一択です。ReLUは軽さが必要な組み込み用途、GELUは既存資産との互換性が要るときに残ります。

判断材料を表にします。

つまり、Transformerの言語モデルという文脈ではSwiGLUが定番になった。それ以外の領域では話が別、というのが現在地です。

注意したいのは、既存の学習済みモデルの活性化関数だけを差し替えても意味がないこと。重みは活性化関数とセットで最適化されています。差し替えるなら再学習が前提。

微調整（ファインチューニング）で済ませようとして精度が落ちた、という失敗はここから来ます。

---

どのモデルがSwiGLUを採用しているのか

GoogleのPaLM、MetaのLLaMA、そしてDeepSeekが採用しています。オープンウェイトのモデルではLLaMA系の派生が多いため、実質的な標準になりました。

採用の広がりを整理します。

つまり2020年以前と以後で世代が分かれています。ReLU→GELU→SwiGLUという流れ。

LLaMAのアーキテクチャを踏襲したオープンモデルは非常に多く、そのほとんどがSwiGLUをそのまま引き継いでいます。Llama-styleと呼ばれる設計セット（RMSNorm、RoPE、SwiGLU）の一角、という位置づけ。

個別のモデルの最新バージョン番号や採用状況は変動が激しいため、実装前に各社の公式リポジトリで確認するのが確実です。

Metaのモデルまわりの動きを追いたい人は、Meta AIの使い方と特徴をまとめた記事が入口として読みやすいはずです。

---

SwiGLUに弱点はないのか？

3つあります。メモリアクセスの増加、実装の複雑化、そして学習の安定性に関する未解決の議論です。

順に見ます。

メモリ帯域を食う

行列積が2回から3回に増えます。パラメータ数を揃えても、GPUのメモリ読み書き回数は増える。計算そのものより、データの往復がボトルネックになる場面があります。

カーネル最適化の手間

3つの行列積と要素積を1つにまとめる（fusion）最適化が必要になります。素直に書くと中間結果がメモリに書き出され、速度が落ちる。主要フレームワークは対応済みですが、独自実装では落とし穴。

学習の安定性は議論が続いている

活性化関数の設計は、大規模モデルの学習安定性を左右する要素として研究が続いています。SwiGLUを前提としつつ、その先を狙う新しい活性化関数の提案も出ています。PowLUのように、事前学習の安定性を明示的に狙った関数がその例です。

つまりSwiGLUは終着点ではありません。現時点の最良解、という理解が正確。

弱点を踏まえた上で、それでも採用され続けている理由は「置き換えコストに対して得られる改善が確実だから」に尽きます。

---

数式が苦手でも理解できる例え話はあるか

水道の蛇口とホースの関係で考えると腑に落ちます。ホースに流れる水が「値」、蛇口の開き具合が「ゲート」です。

従来のReLU型FFNは、蛇口が固定されたホースです。ある水圧を超えたら流れる、下回ったら止まる。ルールは常に同じ。

SwiGLUは、水を流すたびに蛇口の開き具合が変わるホースです。しかもその開き具合を決めるのは、同じ水源から分岐したもう1本の細い管。

「いま流れてきた水の性質を見て、どれだけ通すか決める」

これがゲートの働きです。全開でも全閉でもない、3割開きという状態が作れる。ここがシグモイドではなくSwishを使う理由にもつながります。

もう一つの例え。オーディオミキサーのフェーダーです。曲の場面ごとに、ボーカルを上げてドラムを下げる。この調整を、演奏内容に応じて自動でやってくれるのがゲート機構です。

固定のイコライザー設定（＝ReLU）と、曲を聴きながら調整する人（＝SwiGLU）の違い、と言い換えてもいい。

抽象的な話が続いたので、学ぶ順序の話に移ります。

---

SwiGLUを学ぶ前に押さえるべきことは？

Transformerの全体構造、特にFFN層の位置づけを先に理解してください。Attentionだけ知っていてもSwiGLUの意味は掴めません。

推奨する順序を示します。

つまり4段目までが前提知識です。ここを飛ばすと「3つの行列を掛ける関数」という暗記で終わります。

情報収集の効率を上げるなら、論文検索に強いツールを使うのが早い。Feloの完全ガイドでは、日本語で論文や技術資料を横断的に探す使い方を扱っています。

学習リソースは英語が中心です。原論文「GLU Variants Improve Transformer」は5ページと短いので、翻訳ツールを併用すれば読み切れます。

---

業務でLLMを使う立場なら知っておくべきか

モデルを自作しない限り、SwiGLUの詳細を知る必要はありません。ただし「アーキテクチャの違いが品質差を生む」という感覚は持っておくべきです。

現実的な線引きをします。

知る必要がある人

• 自社でモデルを事前学習・継続学習する
• 推論エンジンの最適化を担当する
• モデル選定で技術的根拠を求められる

知らなくていい人

• APIでLLMを呼び出して使う
• プロンプト（AIへの指示文）の設計が主業務
• ツール選定を機能と料金で判断する

ただし後者でも、「同じパラメータ数なのに性能が違う」現象の理由がアーキテクチャにある、という理解は役に立ちます。パラメータ数だけでモデルを比較するのは危ういという話。

社内でAIツールを評価する立場なら、技術的な差分をどう扱うかの整理が要ります。社内監査向けAIツールの選び方では、技術仕様をどこまで評価軸に入れるかの考え方を扱っています。

生成AIの出力品質を左右する要素は、モデル内部の設計だけではありません。用途に合ったモデル選びのほうが、実務上のインパクトは大きい。イラスト生成ツールの比較も、同じ観点で読める内容です。

---

AI PICKS編集部の判定

SwiGLUは、いまTransformerを組むなら一択です。実装コストは10行、パラメータは幅の調整で相殺でき、品質は確実に上がる。ここまで費用対効果がはっきりした改善は珍しい。

ただし過大評価も禁物です。SwiGLUに変えたからモデルが劇的に賢くなる、という話ではありません。ベースラインを数%押し上げる地味な改善。それが積み重なって現在のLLMがある、という理解が正確です。

正直に言うと、この関数の一番おもしろいところは「なぜ効くか分かっていない」点にあります。原論文が理由を神頼みで済ませ、それでも業界標準になった。理論より実測が先行する分野の空気が、ここに凝縮されています。

学習者に伝えたいのは、SwiGLUを暗記対象にしないこと。ゲート機構という考え方は、Attentionにも、LSTMにも、Mixture of Expertsにも通じます。「入力に応じて情報を選ぶ」という発想を掴めば、他のアーキテクチャの理解も一気に進む。

APIでLLMを使うだけの人は、名前だけ知っていれば十分。ただしモデルを比較する場面で、パラメータ数だけを見るのはやめたほうがいい。中身の設計が効いています。

---

関連する比較・代替を見る

技術選定の判断材料として、実際のツール比較も見ておくと理解が立体的になります。

• ChatGPT vs Claude — アーキテクチャの違いが応答品質にどう出るか
• Claude vs Gemini — 長文処理の設計差を比較
• ChatGPT vs Perplexity — 生成と検索、用途の分かれ目
• Felo vs Perplexity — 日本語の論文・技術資料の探しやすさ
• Notion AI vs ChatGPT — 業務組み込み型と汎用型の違い

カテゴリ単位で眺めたい場合は、AIチャットツール一覧やAIコーディング支援ツールから入るのが早いです。

---

よくある質問（FAQ）

Q. SwiGLUとSiLUは同じものですか？

違います。SiLU（Swish）は単体の活性化関数で、x × sigmoid(x)という式です。SwiGLUは、そのSiLUをゲート部分に使ったGLU構造全体を指します。SiLUは部品、SwiGLUは組み立てたもの、という関係です。

Q. なぜ中間層の幅を2/3にするのですか？

行列が2枚から3枚に増えるためです。幅をそのままにするとパラメータが1.5倍になるので、幅を2/3に縮めて総数を揃えます。これで従来FFNと同じ規模での比較が成立します。

Q. GELUではダメなのですか？

ダメではありません。GEGLU（GELUをゲートに使った版）も論文の比較では良好な結果を出しています。SwiGLUが主流になったのは、PaLMやLLaMAが採用したことによる実績の積み上がりが大きい要因です。

Q. 既存モデルの活性化関数だけ差し替えられますか？

推奨しません。学習済みの重みは活性化関数の特性に合わせて最適化されています。差し替えると出力が崩れます。変更するなら再学習、少なくとも大規模な継続学習が必要です。

Q. 推論速度は遅くなりますか？

パラメータ数を揃えても、行列積の回数が増えるぶんメモリアクセスが増えます。最適化されたカーネルを使えば差は小さくなりますが、完全に同じにはなりません。実測での確認をおすすめします。

Q. SwiGLUに代わる新しい活性化関数は出ていますか？

活性化関数の設計は研究が続いている領域です。学習の安定性を狙ったPowLUのような提案も出ています。ただし2026年8月時点で、主要な公開モデルの標準はSwiGLUのままです。

Q. 論文を読む必要はありますか？

モデルを自作するなら読むべきです。「GLU Variants Improve Transformer」は5ページ程度と短く、比較実験の条件設定が参考になります。使う側の立場なら、この記事の内容で足ります。

Q. 画像生成モデルでも使われていますか？

Transformer構造を持つ画像生成モデルでは使われる場合があります。ただしCNNベースのモデルではFFNの構造が異なるため、GLU化の効果は限定的です。SiLU単体はCNNでもよく使われています。

---

次に読むならこれ

モデル内部の話から実務に戻るなら、Feloの完全ガイドがおすすめです。論文や英語の技術資料を日本語で追いかける環境を作っておくと、この手の新しいアーキテクチャの話題を自力で追えるようになります。