Python と私

2026/06/09, 2026/06/10 - ~

Python との出会い

Python と出会ったのは、セキュリティのベンチャー企業に参画したときのことだ。そのベンチャーは今はもう解散してしまったが（私にも一端の責任はあるが）、創業者がバッファオーバーフローを検知するアルゴリズムを開発していた。TCP/IP(とTCP/IPv6) のペイロードを再構成してそのアルゴリズムを適用し、検知したらブロックする(RST送出する)、というシステムを作ろうとしていた。

そのテストデータを作る必要があり、当時は TCP/IP ヘッダの生成も C 言語で書いていた。フレームを一つ作るだけでも、相当な量のコードが必要だった。

scapy との衝撃的な出会い

そんなとき見つけたのが、Python の scapy だった。今もあるライブラリだが、これがなんとも直感的でわかりやすかった。

scapy.net にあるような例を見れば一目瞭然で、たとえばこれだけで github.com 宛の ICMP フレームが生成できる。

Ether() / IP(dst="github.com") / ICMP()

チェックサムを自動で計算してくれる、というのと、レイヤーが / 演算子を上書きされて表現されている、というのが、自分としては感動的だった。

生成したフレームを pcap ファイルに出力したり、そのままネットワークに送出したりすることもできた。pcap にしてしまえば、tcpreplay などで送出できたが、scapy からも直接ネットワークインタフェースに送出できた。信じられなかった。

今思えば、その頃からあった metasploit を使いこなせていれば、ペネトレーションテストの第一人者になれていたかもしれない。記憶では Python で作られていたので、拡張することもできたはず。ファジングなんかもできたはず。先見性が無さすぎる。。。

C 言語を捨てた瞬間

scapy の衝撃もさることながら、そもそも Python のリスト処理が簡単すぎるというのが大きかった。

C 言語で連結リストを扱おうとすると、malloc でデータ領域を確保して、そのポインタを next フィールドにセットして……と、相当面倒なことをしなければならない。Python ならそれが数行で済む。

scapy とリスト処理の組み合わせで、「もう C 言語は捨てよう」と思った瞬間だった。いや、「もう C 言語捨てますわ」と言ったかもしれない。

当時は ASIC の開発をしていたが、HDL のテストベンチに投入するテストデータは scapy で作った。これが私が本格的に Python を使うようになったきっかけだ。

ハードウェアのテストデータ生成という、一見ローレベルな用途から Python に入ったのは少し変わった経歴かもしれないが、そのおかげで「Python は高級言語の中でも特にネットワークやバイナリを扱いやすい言語だ」という感覚を最初から持てたのは良かったと思っている。

Django との出会い

その開発も一段落したころ、セキュリティベンチャーとして次に注目したのが WEB セキュリティだった。WEB アプリケーションが一般にどのように作られているのか知りたくなり、Python を軸に調べてみると、Django というフレームワークの存在を知った。

これもまた、私には強烈なインパクトがあった。

まず ORM（Object-Relational Mapper） の仕組みだ。データベースを意識することなく、Python オブジェクトだけでデータの生成・読み出し・更新・削除が完結する。SQL を書かずにデータを操作できるというのは、当時の私には驚きだった。

そしてテンプレートエンジンは、変数を出力する際に クロスサイトスクリプティング（XSS）攻撃を自動的にエスケープしてくれる。セキュリティを意識して作られている設計が随所に感じられた。CSRF 対策もフォームにトークンを埋め込む形で標準搭載されている。認証システムも内蔵されており、ログイン・ログアウト・パスワード管理といった仕組みをゼロから書く必要がない。

そして極めつけは、管理サイトの自動生成だ。モデルを定義するだけで、データの閲覧・編集ができる管理画面が自動的に出来上がる。つまり、マスター画面が自動生成されるということだ。これを初めて見たときは、(いい意味で)「なんやこれ」と思った。

業務システムを作ったことがある人ならわかると思うが、マスターメンテナンス画面というのは地味に工数がかかる。それが定義だけで出てくるのだから、衝撃を受けるなというほうが無理だ。今でもここまでやってくれるフレームワークは他にないんじゃないかと思っている。

こういう経緯があるので、私は Python で WEB システム開発に携わる機会がなかったにもかかわらず、Django への思い入れは人一倍強い。だから正直に言うと、「なんで FastAPI やねん」 と思う。FastAPI は確かに軽量で高速だし、非同期処理や API 開発には向いている。でも、Django が標準で提供しているものを一から自分で組み立てなければならない。セキュリティ、認証、管理画面——Django はそれらをすでに持っている。車輪の再発明をしてどうするのか、と思わずにはいられない。

scapy でネットワークの世界に引き込まれ、Django で WEB の世界に引き込まれた。Python は私のキャリアを大きく変えた言語だと改めて思う。

そして、RUNSERVER へ

そうこうしているうちに、創業者グループを含むセキュリティベンチャーの株主から会社を解散したいという話が出てしまった。

私はそのとき、「Python を使ってセキュアな WEB サーバを作れないか」という思いを強く持っていた。Django で得た知見と、セキュリティベンチャーで培った経験を活かせるはずだ、と。そこで会社を作ることにした。

社名は、Django の管理コマンドの一つである runserver から（勝手に）いただいた。ローカル開発サーバーを起動するあのコマンドだ。Python と Django がなければ、この会社名は生まれていなかった。

python manage.py runserver

このコマンドを打つたびに、あのセキュリティベンチャーでの日々と、scapy との出会いを思い出す。

創業して最初のお客様には、Django で作ったシステムを構築した。構築費用もお支払いいただいたにもかかわらず、満足していただけるものを提供できず、結局そのまま立ち消えさせてしまった。本当に申し訳ない思いだ。技術への自信と、お客様が本当に必要としているものを形にする力は、別のものだと痛感した出来事だった。

Python で組み込みへ

その後、タイミング良く、以前仕事をいただいていた方が「Python を使える人を探している」という話を持ってきてくれた。ありがたいことに、その案件を受注することができた。

内容は、スマート電力計への組み込みだ。組み込み Linux 上で、電力系のプロトコルである ECHONET を処理するというものだった。Python がネットワークやバイナリに強いことは scapy で体感していたので、この仕事は自分に向いていると感じた。

プロトコル処理部分とアプリケーション部分が分かれた設計になっていたため、両者の橋渡しには SQLAlchemy を使い、SQLite に一旦データを格納してアプリ層に渡す、という構成にしたと記憶している。ORM を使ってデータをやり取りするという発想は、Django で学んだことが活きていた。

組み込み Linux という、一見 Python らしくない領域でも Python が使えるのだ、という自信につながった案件だった。

Java 案件と Django のセキュリティ知識

それ以降は、しばらく Java の案件が続いた。Python からは少し離れたが、Django で学んだセキュリティの知識は大いに役立った。

Django のドキュメントにはセキュリティに関するトピックがまとまっており、XSS・CSRF・SQL インジェクション・クリックジャッキングといった代表的な脅威とその対策が丁寧に解説されている。Django を通じてこれらを実装レベルで理解していたことが、Java での開発でも基礎知識として機能した。

ただ、今のようにフロントエンドとバックエンドが分離された構成では、Django が前提としていた「サーバーサイドでレンダリングする」モデルとは若干事情が異なる部分もある。たとえば CSRF トークンの扱いや XSS の防御ポイントは、SPA + API という構成では別の考え方が必要になってくる。とはいえ、「何を守るべきか」という本質は変わらない。Django はその基礎を叩き込んでくれた、という意味で今も感謝している。

テストツールとしての Python

プロダクションサーバーに Python を使うことはなかったものの、テストツールとして活用しまくった。

Java で構築したサーバーがデータを取得しに行く先があるのだが、その取得先の動作を模擬してデータを返すモックサーバーを Python で作ったり、テスト用の JSON/XML データの生成、データ解析、データ移行など、縁の下で Python に何度も助けてもらった。P社(日本全国そう呼ばれててそのように表記する意味ない?)の利用実績を取り込むシステムでたいしたトラブルもなくデータが取り込めたのは、Python のおかげだと思っている。

改めて思うのは、Python の以下の強さだ。

DB 操作 — 標準の sqlite3、MySQL も mysql-connector-python や PyMySQL で手軽に扱える
テキスト処理 — 正規表現、文字列操作、CSV・JSON・XML の読み書きが簡潔に書ける
リスト・辞書の操作 — C 言語のリンクリストのような面倒さがなく、配列を扱うように直感的に操作できる
ネットワーク処理 — scapy から始まり、socket・requests・httpx まで、レイヤーを問わず扱える

本番には出ないが、開発・テスト・運用の裏側で Python はずっと動いている。そういう使い方こそ、Python の真骨頂かもしれない。

巡り巡って、また Django

最近になって、音楽教室の予約システムの運用を引き継いだ。何の因果なのか、そのシステムは Django で作られていた。

長い回り道をしてきたようで、結局また Django に戻ってきた。おもしろい話だと思う。

Python と Django は、私のキャリアのあちこちに顔を出す。ネットワークのテストデータ生成から始まり、WEB セキュリティの学習、会社の命名、組み込み開発、Java 案件の裏方、そして音楽教室の予約システム。これだけ多様な場面で使い続けられる言語は、そうそうないと思っている。

Python 嫌いの気持ちもわかる

もっとも、「Python が嫌い」という人がいるのはよくわかる。

動的型付けの言語なので、全然タイプセーフではない。型が合わなくてもそのコードパスを通るまでエラーにならず、実行時に初めて例外が発生する、ということがよくある。テストで網羅しきれていないパスに潜むバグは、本番で踏むまで気づかない。Java や TypeScript のような静的型付け言語に慣れた人から見れば、不安でしかないだろう。

高校生のころ、BASIC で打ち込んだマージャンゲームを思い出す。やっと全部打ち込んで「よっしゃ、上がった！」と思ったら SYNTAX ERROR と言われて、タイポを探して直す——あれと同じだ。実行して初めてわかるエラーというのは、昔も今も人を脱力させる。

ただ、それでも Python を使い続けているのは自分自身なのだが。

以上、とりとめのない昔話を読んでくださり、ありがとうございました。よかったらお仕事ください。ふざけ気味な投稿ですが、本気で困っています。助けてください！工数少な目の開発でも結構ですので moriya@runserver.jp にご相談いただけると嬉しいです。面白いと思ったら、お友達へのシェアだけでも結構です。よろしくお願いします。