Author Archives: DeveloperTiatra

重要なのは、ここでやっていることが“理解”というよりも、“情報の集め方と混ぜ方のルールを学習する”という点だ。文章中の各トークン（入力の単位）は、自分に必要な情報を、同じ文章の別のトークンから集めてくる。そして集めた情報で自分の表現を更新する。これを層として何十回も繰り返すことで、局所的な語のつながりから長距離の依存関係まで、段階的に扱えるようになる。本稿では、数式を前提にせず、自己注意が「何をして」「なぜ効いて」「どこで詰まりやすいか」を、実装の匂いがするレベルまで文章だけで説明する。

LLMの中身は「積み重ねる機械」：デコーダ型Transformerという前提

生成系LLMの多くは、同じ形のブロックを縦に何層も積み上げた構造をしている。入力は文字列ではなくトークン列で、各トークンはまず埋め込みという変換でベクトルになる。ここから先は基本的に、同じ形のTransformerブロックを順番に通り、最後に「次に来そうなトークン」を選ぶための出力に変換される。

生成モデルとしての重要な制約は、ある位置のトークンが「未来のトークン」を参照できないことだ。文章を左から右へ生成する以上、まだ出力していない未来を見てしまうとズルになる。そこでTransformerは、自己注意の計算で「見てよい範囲」を制限する。これが因果マスクと呼ばれる仕組みで、後ろの単語を“見えないもの”として扱うことで、モデルは常に「過去だけを頼りに次を予測する」状態に置かれる。

自己注意とは何か：各トークンが「どこを見るか」を自分で決める

自己注意を直観的に説明すると、次のようになる。文章の各トークンは、処理のたびに「今の自分の状況だと、文中のどの部分が役に立つか」を判断し、その部分から情報を引き出して自分の表現を更新する。つまり、各トークンは“問い合わせ役”になり、同時に他のトークンは“情報源”にもなる。

このとき、トークンは内部的に三つの役割の表現を持つと考えると理解しやすい。一つ目は「何を探しているか」という問い合わせの方向性、二つ目は「自分はどんな特徴を持っているか」という名札、三つ目は「提供できる中身（情報）」である。問い合わせが名札と照合され、「この情報源は自分に関係が深い」と判断されるほど、その情報源の中身が強く取り込まれる。結果として、各トークンは文中の複数箇所から情報を集め、それを混ぜ合わせた新しい表現へ更新される。

ここで重要なのは、参照先を決めるルールが固定ではない点だ。単に「近い単語を見る」ではなく、入力内容に応じて、遠く離れた場所も見にいける。たとえば主語と述語が離れていても、必要なら主語を参照して整合する表現へ更新できる。これが、自己注意が長距離依存に強いと言われる理由である。

因果マスク：未来を見ないことで「生成できる」モデルになる

生成においては、各位置が参照してよいのは自分より前までのトークンだけである。自己注意は本来、文中のどこでも見にいけるが、それを許すと学習時に“答えを見ながら解く”状態になってしまう。そこで因果マスクで「後ろ側は参照できない」と強制し、常に“過去だけ”を材料に次を予測する。

この制約は学習時にも推論時にも同じように働く。学習時は全文が手元にあっても、各位置の計算では未来が見えないようにして、推論時の状況に合わせる。こうすると、学習で身につけた振る舞いがそのまま生成に使える。逆に言えば、因果マスクは「Transformerを生成器として成立させるための安全装置」だ。

Multi-Head Attention：一つの見方では足りないので、複数の“視点”を並列に持つ

自己注意を一種類だけ持つと、各トークンが参照先を決める「判断基準」が一通りになってしまう。しかし自然言語には、同時に複数の関係が重なっている。語の意味の類似、係り受け、共参照、話題の継続、否定や条件のスコープなど、同じ文を読むにも複数の観点が必要だ。

Multi-Head Attentionは、この問題への実用的な解である。内部の表現を複数のグループに分け、それぞれが独立に「どこを見るか」を決める。あるヘッドは局所的なつながりを見るのが得意になり、別のヘッドは文頭の主語を追跡するのが得意になる、といった分業が起こり得る。もちろん、ヘッドごとに意味が必ず決まるわけではないが、「複数の視点で同時に参照できる自由度」を設けること自体が、表現力を押し上げる。

最後に各ヘッドが集めてきた情報は結合され、元の次元に戻される。したがってMulti-Headは、単に並列化しているのではなく、「異なる参照パターンを足し合わせた総合的な文脈表現」を作っていると考えるとよい。

残差接続とLayerNorm：深く積んでも壊れないための骨格

Transformerは非常に深くなる。深いネットワークは表現力が高いが、学習が不安定になりやすい。そこでTransformerブロックは、自己注意やMLPの周りに残差接続を置く。残差接続とは、変換結果だけを次に渡すのではなく、元の入力を足して一緒に流す仕組みだ。これにより、変換がうまく学べていない段階でも情報が消えにくくなり、学習が進みやすい。

LayerNormは、各トークンの内部表現のスケールや偏りを整える役割を持つ。これにより層を重ねても表現が暴れにくくなる。大規模な学習では、LayerNormをどこに置くかが安定性に効く。実務では、変換の前に正規化する配置が採用されることが多く、これは深いスタックでの学習をより安定させる狙いがある。

MLP：注意が集めた情報を「加工」して使える形にする

自己注意は「どこから情報を持ってくるか」を決めるのが得意だが、持ってきた情報をそのまま使えるとは限らない。そこで各ブロックには、MLP（位置ごとの小さなニューラルネット）が入っている。MLPは、各トークン位置で独立に働き、表現を非線形に変形して“使いやすい特徴”へ変換する。

直観的には、自己注意が「材料を集める係」だとすると、MLPは「材料を下ごしらえして料理にする係」だ。注意で混ぜた文脈情報を、分類しやすい形、予測しやすい形に整える。これがブロックを通るたびに繰り返され、表現はより抽象的で、よりタスクに有用なものへと変化していく。

実装で起きるトラブル：動くのに間違っているパターンが多い

自己注意の実装は、数式を知らなくても書ける一方で、間違ってもそれっぽく動いてしまうのが怖い。典型は「正規化の方向を間違える」問題である。本来、各トークンが参照先に対して重みを割り当てるべきなのに、軸を取り違えると、意味の違う正規化になってしまう。それでも出力は出るので、学習は進んでいるように見えるが、性能が伸びない、挙動が変、という形で現れる。

もう一つはマスクの扱いである。未来を見ないための制約が、精度の低い演算形式や実装の都合で弱くなったり、逆に必要な参照まで消したりすることがある。とくに高速化のために混合精度を使うと、非常に大きい負の値で「見えなくする」操作が、丸めの影響で期待通りにならないことがある。こうした問題は、単体テストや可視化で「本当に未来を参照していないか」を確認するのが有効だ。

なぜ長文が苦しいのか：自己注意は“全対全”を見るコストが重い

自己注意の弱点は計算量だ。各トークンが「文中のどのトークンも参照候補にできる」自由度を持つ代わりに、参照の組み合わせが増える。つまり、文が長くなるほど「参照関係の候補」が急激に増え、計算とメモリが重くなる。長文で推論が高価になりやすいのは、単にトークン数が増えるからだけではなく、参照関係を作るコストが増えるからだ。

推論時にはさらに事情がある。生成は1トークンずつ増やすので、新しいトークンが追加されるたびに「過去全部との関係」を計算する必要がある。ここでKVキャッシュという仕組みを使うと、過去の情報を再計算せずに済み、速度は改善する。それでも「過去全体を見る」必要は残るため、長文になるほど遅くなる傾向自体は消えない。長文対応は、位置表現だけでなく計算設計の問題でもある理由がここにある。

まとめ：自己注意は「参照先を学習して決める情報収集装置」

Transformerの自己注意は、文中の各トークンが「どこを見るべきか」を入力から計算して決め、必要な情報を取り込んで自分の表現を更新する仕組みだ。因果マスクが未来参照を禁じることで、モデルは生成器として成立する。Multi-Headにより複数の視点で同時に参照でき、残差接続とLayerNormが深い積層を学習可能にし、MLPが集めた情報を非線形に加工して表現力を増す。一方で自己注意は長文になるとコストが重くなり、実装では正規化の軸やマスクの扱いがバグの温床になる。Transformerを理解することは、モデルを魔法として扱うのではなく、情報がどこからどこへ流れ、何が性能とコストを支配しているのかを言語化できるようになることだ。

異常の定義を決める――点の異常、文脈の異常、集団の異常

異常検知を始める前に最初にやるべきことは、「異常とは何か」を決めることです。これは技術ではなく、業務上の合意です。例えば売上が前日比で大きく落ちたら異常なのか、週次の季節性の範囲なら正常なのか。KPIが下がることだけが異常なのか、急上昇も異常なのか。どれくらいの変化幅から対応が必要なのか。ここを曖昧にすると、精度の議論が空回りします。

異常は大きく三つに分けて考えると整理しやすいです。ひとつ目は点の異常です。単発のスパイクや急落など、単一時点の値が明らかにおかしいケースです。二つ目は文脈の異常です。同じ値でも、時間帯や曜日によって意味が変わるケースです。たとえば深夜のアクセス数が多いのは異常かもしれませんが、昼間に多いのは正常かもしれません。三つ目は集団の異常です。全体のKPIは正常でも、特定地域や特定デバイスだけが急に悪化しているケースです。プロダクトの障害や計測の問題は、全体では薄まって見え、集団の異常として現れることが多いです。

さらに、異常の目的も分ける必要があります。ビジネスKPIの異常は「売上が落ちた理由を突き止める」ことが目的になりやすい一方で、システム系の異常は「障害を早く検知して復旧する」ことが目的です。同じ“異常検知”でも、許容できる誤検知と見逃しのバランスが違います。売上の監視で誤検知が多いと現場が疲弊しますし、障害監視で見逃しがあると致命的です。異常検知は、精度の前に目的を分けることが成功の第一歩です。

手法の選び方――統計的しきい値、予測残差、機械学習

異常検知の手法は、大きく三系統で考えるとわかりやすいです。まずは統計的なしきい値です。移動平均からの乖離、過去平均との差の標準化、分位点による範囲設定などがこれに当たります。利点は、速くて説明しやすいことです。「過去30日平均との差がこれだけ大きいから異常」と言えると、現場は納得しやすいです。欠点は、トレンドや季節性が強い指標では誤検知が増えることです。曜日で大きく揺れる指標を単純なしきい値で監視すると、週末のたびにアラートが鳴るような状態になります。

次に、予測残差を使う方法があります。時系列予測モデルで「本来の値」を予測し、実測との差が大きいときに異常と見なします。この方法は、季節性やトレンドをモデルが吸収するので、単純なしきい値より誤検知を減らしやすいです。一方で、予測が外れる原因が“異常”なのか“モデルの限界”なのかが混ざることがあります。大型キャンペーンや外部ショックで全体が動くと、残差が大きくなり、異常扱いが増えるかもしれません。ここでは、イベント情報を別途入れる、異常種別を分ける、予測区間で判断するなど、運用を前提にした工夫が必要です。

三つ目は機械学習的な異常検知です。Isolation Forestのように“孤立しやすい点”を異常とする方法や、オートエンコーダのように“再構成できない点”を異常とする方法などがあります。これらは多変量の特徴量を扱いやすく、複雑なパターンの異常に対応できる可能性があります。ただし、説明が難しくなりやすく、導入には注意が必要です。異常検知は、現場が原因探索に動けることが重要なので、「なぜ異常なのか」をある程度説明できる設計が求められます。機械学習モデルを使うなら、どの特徴量が異常スコアに寄与したかを示す、異常の近傍例を出す、異常のタイプごとにルールを分けるといった、説明の補助線が必要になります。

ここで重要なのは、最初から高度なモデルを使うことが正解ではないという点です。異常検知の失敗の多くは、精度ではなく、通知の設計と対応フローの欠如にあります。説明しやすい手法で小さく始め、運用の負荷と見逃しのリスクを見ながら、必要なところだけモデルを強くしていく方が、結果的に成功しやすいです。

アラート疲れを防ぐ――閾値調整、優先度付け、原因探索の導線

異常検知を現場で機能させる最大の敵は、アラート疲れです。アラートが多すぎると、人は見なくなります。すると本当に重要な異常も見逃します。だから異常検知では、検知精度より先に、通知を減らし、重要度を分け、対応を速くする設計が必要です。

まず、異常の優先度を決めます。売上や決済など致命度が高い指標は、多少の誤検知があっても即通知すべきかもしれません。一方、軽微な指標は、即通知ではなく日次のサマリーで十分かもしれません。次に、抑制条件を設けます。例えば「同じ種類のアラートは一定時間内に再通知しない」「全体が正常で特定セグメントだけ悪化した場合は別扱いする」「データが未確定の時間帯は通知しない」など、現場の運用に合わせた抑制は、実用性を大きく上げます。

さらに重要なのが、アラートが鳴った後の導線です。通知だけ送られても、人は次に何を見ればいいかわかりません。異常が起きたら、関連指標を同時に表示し、分解軸を用意することが有効です。例えば売上の異常なら、流入、CVR、客単価、決済成功率など、売上を構成する要素を同時に見られると原因が絞りやすくなります。さらに地域、デバイス、バージョン、流入元など、よくある故障点で切ったビューがあると復旧が速くなります。異常検知は、検知と原因探索が分断されると現場で使われません。検知の仕組みと、原因探索の仕組みを一体で設計することが、成功する異常検知の共通点です。

最後に、異常検知を育てる仕組みも必要です。アラートが真の異常だったか、誤検知だったか、対応は必要だったかを記録できると、しきい値調整やモデル改善が進みます。異常検知は一度作って終わりではなく、運用しながら“現場にとってちょうどいい感度”に合わせ込むことで価値が出ます。通知の量を適正にし、優先度を付け、原因探索を速くする。この三つが揃うと、異常検知は単なるアラート装置ではなく、プロダクトとビジネスを守る意思決定のインフラになります。