「最小の脳」パーセプトロンを Python でゼロから書いて、LLM 全盛の今に読み直す — 運用者目線で

まず結論 — パーセプトロンは「LLM の祖先」ではなく「今も使える最小の判定器」

パーセプトロンを学ぶ価値は、ニューラルネットワークの歴史を知ることではありません。「入力に重みを掛けて足して、0 より大きいかどうかを見るだけ」という最小の判定器が、説明可能でゼロコストで止まりにくい、という運用上の性質を持っているからです。LLM を呼ぶ前に置く一段目のフィルタとして、2026 年の今でも普通に役に立ちます。

きっかけは ranpara.net の A Perceptron in Python という記事でした。パーセプトロンをゼロから Python で実装する、よくある入門記事に見えます。けれど読み進めるうちに、これは「歴史の勉強」ではなく「最小単位の判定器を手のひらに乗せ直す」作業だと気づきました。1958 年にフランク・ローゼンブラットが考えたこの仕組みを、運用者の目で読み直してみます。

決定関数と学習則 — たった 2 行で「学ぶ」が起きる

パーセプトロンの本体は驚くほど短いです。予測は「重み × 入力 + バイアスが 0 より大きいか」、学習は「外したぶんだけ重みを動かす」、この 2 つだけで完結します。

予測の式はこうです。予測 = (重み * 入力 + バイアス) > 0。yes か no かを返すだけの二値分類器です。学習はもっと素朴で、外したときだけ動きます。誤差 = 正解 - 予測 を計算して、重み += 学習率 * 誤差 * 入力、バイアス += 学習率 * 誤差 と更新する。正解していれば誤差が 0 になるので、重みは 1 ミリも動きません。間違えたときにだけ、間違えた方向へ少し寄る。これだけです。

初めてこの更新則を手で追ったとき、私は拍子抜けしました。for ループの中に掛け算と足し算が数行あるだけで、コードのどこにも「学習」という名前の関数が出てこない。にもかかわらず、データを何周か流す（このひと周りをエポックと呼びます）と、境界線がじわじわ正しい位置へ動いていく。逆伝播もテンソルも勾配ライブラリも要りません。「学ぶ」の最小単位は、これだけの算数で成り立っているのだと、画面の前で一人で感心していました。

バイアスと正規化 — 動かないときの原因はだいたいこの 2 つ

実装して動かないとき、犯人はほぼバイアスか正規化の不足です。バイアスは境界線を左右にずらす役で、これを省くと境界が原点に貼りついて分類できません。正規化はスケールの違う入力を公平に扱うための前処理で、抜けると学習が暴れます。

元記事の例がわかりやすかったです。テストで 50 点以上なら合格、という判定をパーセプトロンに学ばせる。バイアスを切ると境界はゼロ点から動けず、いつまでも合格と不合格を分けられません。バイアスを足した瞬間に境界が 50 へ移り、精度が 100% に届く。重みが「傾き」を決め、バイアスが「線をどこに置くか」を決める、という分担がここで腑に落ちます。決定境界そのものは -バイアス / 重み で出せて、これが「いま自分のモデルは何点で線を引いているか」を一目で教えてくれる。LLM の判断根拠を覗くのに比べたら、笑ってしまうほど透明です。

もう一つの落とし穴が正規化です。たとえば年収（数千〜数百万）と「都市内の移動回数（0 か 1）」を同じモデルに入れると、桁の大きい年収だけが重みを支配して、学習が安定しません。入力を 0〜1 の範囲に圧縮してから渡すと、各特徴が公平に効くようになり、収束も速くなります。学習率も同じ話で、0.1 のような小さい値は安定するが遅く、大きい値は速いが行き過ぎて振動する。このあたりの「測ってから決める」感覚は、私が以前書いた自動化の前にまず測れという話とそのまま地続きでした。勘で学習率を上げた瞬間に、境界は永遠に収束しなくなります。

運用者として何が嬉しいか — 説明可能で、ゼロコストで、止まらない

運用の目で見ると、パーセプトロンの嬉しさは性能ではなく「壊れ方が読めること」に尽きます。判断根拠が重みとバイアスの数値として全部見えて、推論に外部 API もGPU も要らず、止まる要素が原理的に少ない。

LLM 機能を載せると、コストとレイテンシと障害点が一気に増えます。私は以前、LLM API を「呼ばない」で守る三段防御という記事で、入力を呼ぶ前に弾く第一段が一番安く効くと書きました。パーセプトロンは、まさにその第一段に置ける道具です。明らかに線形で分けられる判定（しきい値を超えたか、二つのカテゴリのどちらか）なら、数十行のローカルなモデルで返してしまえる。LLM を呼ぶのは、線形では分けられない曖昧な入力だけでいい。

そして何より、判断が説明できます。なぜこの入力を「合格」にしたのかと聞かれたら、重みとバイアスと入力を並べて「ここがしきい値を超えたから」と即答できる。これは監査やクレーム対応の現場でとても強い性質です。もちろん限界もはっきりしていて、パーセプトロンは線形分離できない問題（有名な XOR がそれ）を一切学習できません。ここは正直なところで、曲がった境界が要るなら素直に上のレイヤーへ渡すべきです。万能ではないが、できることとできないことが最初から見えている。この潔さが、運用では信頼に変わります。

持ち帰る順番 — 最小から始めて、必要になったら足す

最後に実務への持ち帰りを整理します。順番は「まず一番小さいモデルで足りるか測る → 足りなければ段を上げる」で、いきなり大きいモデルから入らないことです。上流の安いところから順に試すのが定石になります。

具体的には、二値の判定機能を作るとき、最初にパーセプトロン（あるいは scikit-learn の Perceptron 一行）で精度を測ってみる。それで十分なら、API もGPU も監視対象も増やさずに済みます。精度が頭打ちなら、線形では足りないサインなので、そこで初めてニューラルネットや LLM へ上げる。判断材料は感覚ではなく、精度・収束したエポック数・正規化前後の差という具体的な数字で持つ。この「小さく始めて必要なぶんだけ足す」発想は、コストとデバッグのしやすさの両方で効きます。

なお、この記事も AI が下書きを書き、私が確認・編集して公開しています。最小の判定器を手で書き直すと、ふだん何気なく呼んでいる巨大なモデルが、結局はこの算数を途方もなく積み上げたものなのだと、足元から見直せた気がします。