今でこそAI活用のトップランナーとして業界をリードするDeNAだが、その創業期は、多くのベンチャーがそうであるように、収益化に向けた泥臭い試行錯誤と「制約」の連続だった。

そんな苦難の時代を「1人目のエンジニア」として支え、同社のエンジニアリングの基盤を築き上げた人物がいる。現在は、freeeのCISO（最高情報セキュリティ責任者）を務める茂岩祐樹さんだ。

茂岩さんは、一時は1日で50億アクセスを誇った巨大サービスであり、今年20周年を迎える「Mobage（モバゲー）」の立ち上げに従事。 長年にわたり、DeNAのインフラとセキュリティーを死守し続けてきた。

2026年、Mobage誕生から20年という節目に。当時直面した困難とチャレンジを振り返りながら、AI時代を生き抜くエンジニアにとって欠かせない資質について話を聞いた。

サーバー1台に数百万円
クラウドなき時代の「絶望的な制約」

——DeNAに「1人目のエンジニア」として参画し、「Mobageを守った男」と評された茂岩さんですが、そもそも創業期のインフラ担当って、どんな毎日だったんですか？

今のエンジニアが聞いたら「嘘でしょう？」と思うことの連続ですよ（笑）。まず、とにかくお金がなかった。今はボタン一つでサーバーを増やせるクラウドの時代ですが、当時は1台追加するのに数百万円。赤字続きのベンチャーには、そんな解決策はおいそれと選べませんでした。

——まさに、持たざる者の戦いですね。

そうです。だから、いかに「今ある資源」を使い倒すか。泊まりがけでMySQLやIAサーバーのチューニングをやり尽くしました。外部のOracleコンサルタントから「もうこれ以上、やれることはない」と言われるまでやり込んだこともあります。それくらい、常に「物理の限界」との戦いでした。

——物理の壁を、技術の力技でどうにかするしかなかったと。

ネットワークもそうでした。当時はデータセンターに自分たちで10Gbpsの通信ケーブルを引いて、それらを何本も束ねて運用していたんです。

業者に頼むと、希望通りのスペックが実現するまで半年待ちなんてザラ。待っていたらサービスが終わってしまうので、自らフィジカルに動くしかありませんでした。

実は回線工事って、世の中の情勢に左右されるんですよ。当時は選挙期間になるとインフラ関連の公的な工事に制限がかかったり、電話局のリソースがそちらに取られたりして、回線が開通しなくなることがあったんです。選挙があるたびに「電話局の工事が止まるぞ」とハラハラしていたのを覚えています。

——選挙がインフラエンジニアの天敵だったとは……（笑）

そうやって何とか課題を一つクリアしても、また次が来る。性能管理は、常に事業の成長との「いたちごっこ」でした。

事業が伸びると、まずストレージの入出力（I/O）が限界を迎え、そこを解消すれば次はCPUが頭打ちになり、それを突破すればメモリが足りなくなる……。ボトルネックは解消されるたびに次のレイヤーへと移動して、システム内を循環していくんです。

——解消した瞬間に、次の火種が別の場所で燃え上がる。

はい。でも、この泥臭いループを何度も何度も繰り返していくうちに、OSの内部挙動やデータ処理のフローが、理屈じゃなく「手触り」を持って理解できるようになっていきました。

システムの裏側にある「動作原理」そのものを構造的に把握する力が、自然と身体に染み付いていったんだと思います。

当時からいたメンバーは、ドキュメントがなくても「今、システムの中で何が起きているか」を頭の中で精緻に描くことができていました。そうやって「構造の解像度」を極限まで高めないと、あの規模の負荷を捌き切ることは不可能でしたから。

受話器越しに聞こえた赤ちゃんの泣き声

——物理の限界をチューニングで突破する……。まさに職人技ですが、そんな果てしない「いたちごっこ」を、なぜそこまで必死に続けられたのでしょうか。普通なら「もう限界です」と投げ出したくなりそうです。

単なる技術的好奇心だけだったら、どこかで折れていたかもしれません。踏みとどまれたのは、ある原体験のおかげかもしれません。

電話の主は、僕がMobage誕生以前に携わっていたオークションサイト『ビッダーズ』（現：au PAY マーケット）の熱心なユーザーさんでした。

「出品がうまくできない」という問い合わせだったのですが、受話器の向こうから、赤ちゃんの泣き声が聞こえてきたんです。

——赤ちゃんの泣き声、ですか。

ええ。その瞬間、ハッとしたんです。

「ああ、この人は家で商売をして、生活しているんだな」と。僕たちがインフラを止めることは、この人の商売を、ひいては生活を止めてしまうことなんだ。その重みを肌身で感じた瞬間でした。

——画面の向こう側にいる「生身の人間」の存在を突きつけられた。

おっしゃる通りです。もともと「システムを落とすのは悪」と思っていましたが、その先にいる「具体的な誰か」の生活が、自分の手の中に乗っている感覚に変わったんです。

インフラを死守することも、セキュリティーを固めることも 、全ては誰かの日常を止めないため。そう自分の中で理屈が通ってからは、どんなトラブルが起きても「やるべきことは一つだ」と、迷いがなくなりました。

“人力”で帯域を稼ぐ。今ではありえない戦い方

——その「日常を守る」という言葉の重みを、身を持って知ることになったのが、2006年に始まったMobageの爆発的な成長だったのですね。

はい。リリース後、トラフィックが半年で4倍、最終的には1日50億アクセスという、桁違いの規模まで膨れ上がりました。実はこの時、エンジニアとして猛省した出来事があるんです。

——猛省、ですか？

当時、僕は経営陣と「キャパシティには常に1.5倍の余裕を持つ」という約束をしていました。

でも、コスト削減の責任感もあったし、何より「これまでのチューニング経験があれば、まだいけるだろう」という過信がどこかにあって、バッファーの確保を後回しにしてしまったんです。

そこへ爆発的なヒットが重なり、物理的なネットワーク帯域がパンクして、文字通り「詰まって」しまった。

——回線不足は、インフラエンジニアにとって最も胃が痛い、言い訳のできない状況ですよね。

本当に（苦笑）。でも先ほどお話しした通り、当時は回線を増やすのに数ヶ月待ちです。「回線が来るまでサービスを止めます」なんて、生活を支えているユーザーに対して絶対に言えない。そこで僕たちが選んだのは、驚くほどアナログな「力技」でした。

——打てる手がない中で、一体何を？

「回線が増やせないなら、流れるデータ量を削り出すしかない」と。全エンジニアに招集をかけ、各ページのHTMLから不要なコメント行を一つずつ消したり、画像の数画素を削ったりしていきました。

——……1ページ数百バイトの世界ですよね？ 微々たるものに聞こえてしまいますが。

いえ、たかが数百バイトでも、何十億ものトラフィックがあれば、それだけで100Mbps単位の帯域が削減できます。毎日、必死にデータを削り、回線が届くまでの時間を稼ぎ続けました。

——まさに「人力」で帯域を捻り出した。現代のクラウド環境では考えられない解決策です。

本当に泥臭い話です。このような自分たちでなんとかするという考え方は、内製主義がもたらしたもの。実は内製主義はDeNA創業直後にアウトソースしていた開発が全く進んでおらず、リリースが2ヶ月遅れたという体験により作られました。自分たちでコントロールできないもの（ブラックボックス）に依存しないことの重要性を、この時創業メンバー全員が身に沁みて実感したわけです。

——ここでの「コントロールできないもの」とは、既製品のツールやインフラそのものを指すのでしょうか。

クラウドもAPIも便利ですが、結局は誰かが作った「中身の分からない箱」です。でも、サービスの根幹をそこに委ねてはいけない。代表の南場（智子）さんも、前述の創業時の体験を通じて事業におけるエンジニアリングの内製の重要性を認識し、優秀なエンジニアを自社で抱えることに力を注ぎ始めました。

重要なことを人に任せきりにせず、自ら手を動かして「構造」を理解する。このスタンスは、今のfreeeでの仕事にも深く根付いています。

15年前から、サイバー攻撃のリスク増大を確信していた

——インフラの内製化に踏み切り、ようやくシステムが安定してきた。そんな時期に、茂岩さんは次なる領域「セキュリティー組織」の立ち上げへと舵を切ります。まだ世の中に「セキュリティー担当」という職種すら一般的ではなかった当時、なぜあえてその道を選んだのでしょうか。

2010年頃、米ngmoco社の買収を機にグローバル展開が本格化したのがきっかけでした。同時に、世の中がガラケーからスマートフォンへと一気にシフトした時期でもあります。

——技術の大きな不連続点が訪れた。

はい。それまでのガラケーは、キャリアの「閉域網」という、いわば城壁の中に守られた世界でした。

しかし、スマートフォンはオープンなインターネットという戦場に直接さらされます。この変化によって、サイバー攻撃のリスクが激増するのは目に見えていました。

ただ当時、国内の同業他社で専門のセキュリティー組織を持つ企業はほとんどありませんでした。誰もやらないなら、自分がやるしかない。そう思って、まずは1人で「CSIRT（シーサート：事故発生時の対応チーム）」を立ち上げました。

——社内に正解がない中で、どのように組織の形を作っていったのですか？

もう、外部のコミュニティーに飛び込んで先人の知恵を必死に手繰り寄せるしかありませんでした。

さらに、それまで外注任せだった「脆弱性診断」の内製化にも踏み切りました。ゲームのリリース速度を落とさずに安全を担保するには、外注の形式的な診断では到底追いつかないと判断したからです。

——インフラからセキュリティーへ。一見すると異なる分野への転身に見えますが、茂岩さんの中ではつながっていたのでしょうか。

実は、僕の中では全く別物ではありませんでした。性能管理でシステムの限界を見極めてきた経験が、そのまま「守りの勘所」に直結したんです。

パケットの流れやOSの内部構造が頭に入っていれば、攻撃者がどこを突き、どこから崩しにくるかという「急所」が、手触りを持って分かります。

自分にとって、インフラもセキュリティーも、「システムの動作原理を知り、事業を守る」という目的において、完全に地続きの課題でした。

「構造を理解」は、一生モノの武器

——「地続き」という感覚は、具体的に今のCISOとしての意思決定にどう活きているのでしょうか。

例えば、システムのセキュリティー対策を考える時やパフォーマンスチューニングを進める時に僕はまず頭の中でパケットがユーザーからどう飛んできて、どういうコンポーネントを通って処理・保存されるか、性能面ではどの部分に上限があり、またそれはどのくらい拡張が大変でどのくらいコストがかかるのかといったことを総合的にシミュレーションします。

——教科書通りの設計ではなく、リアルな挙動を想像するわけですね。

当時Mobageはおそらく携帯トラフィックを処理するコンテンツプロバイダーとして世界で最も巨大なシステムの一つだったと思いますが、度々ネットワーク機器の性能問題に悩まされました。

ネットワーク機器の多くは処理性能を表すスペックを〇〇Mbpsという指標で示していますが、その数値よりも相当低いレベルで処理が詰まってしまう。結論から言うとガラケーのトラフィックはパケットサイズが小さくpps（packet per second）の上限に引っかかっていたんですね。

Mbpsでのスペック表示は直感的にわかりやすいが、ラージパケットでの計測結果がカタログに載っていることが多く、Mobageの環境と前提条件が違いすぎたのです。

その後はネットワーク機器を選定する際は必ず性能試験を行うようにして上限を把握することに努めました。余談ですが、Mobageと同じ膨大なトラフィックを再現できる機器をなかなか入手できず苦労しました。

——なるほど。製品のカタログスペックを鵜呑みにせず、自社環境での限界値を泥臭く見極めていったと。特定の側面から見える部分だけではなく、システムの「設計思想や前提条件」を踏まえて多角的に物事を見るわけですね。

まさに。CISOとして「このリスクは許容できるか」を判断する際も、ブラックボックスのまま「ベンダーが大丈夫と言っているから」と信じるのと、自分の中に「ここを突かれたら物理的にこう崩れる」という解像度があるのとでは、判断の精度もスピードも天と地ほどの差が出ます。

それ以外に、僕がfreeeに入社して最初に取り組んだ大きな課題は、セキュリティーではなく会計システムの「性能管理」と「障害削減」でした。昨年末まではCSIRTだけでなく、SREやQA部門も管轄していたんです。

性能管理では多数あるシステムコンポーネントを丁寧に一覧化して、それらの上限値を把握。日々の性能状態とPVの予測を組み合わせて増強計画を立てて乗り切りました。

過去の障害でCPU使用率の高さが原因だとするとどうしてもそこに注目しすぎてしまいますが、ボトルネックになりうるリソースは他にもあります。

今問題になっていなかったとしても可能性のある指標は漏れなく可視化して後手に回らないようにすることで乗り切ります。

——CISOという立場でありながら、プロダクトの心臓部である性能管理まで。

クラウド環境はリソースを追加すれば一時的に負荷は凌げますが、データベースなどの根幹は、適切な設計がなければスケールしません。そこで、かつて僕がMobageなどで培った性能管理の知見を、組織全体に浸透させていきました。

システムは全てつながっていますから、インフラで解決できなければアプリのロジックにまで踏み込む。そうやって「レイヤーを跨いで問題を解決する経験」を積み重ねてきたことが、今の僕を支えています。

——その「一生モノの武器」の重要性は、今まさに私たちが直面している「AIという巨大な波」においても変わらないということでしょうか。

むしろ、これまで以上に重要になると思っています。

「構造」を握る者だけが、AIの回答を疑える

——「便利になればなるほど、構造を知る価値が上がる」ということでしょうか。AIがコードを書き、システムが極限まで抽象化された現代の状況は、茂岩さんの目にどう映っていますか？

確かに今は、物理サーバーを意識せずとも望む機能が瞬時に形になる時代です。でも、便利になればなるほど「構造を捉える力」の差が如実に出るようになるとも感じています。

——構造を捉える力、ですか。

AIは「動くもの」を簡単に吐き出してくれますが、それが本当に数億のアクセスに耐えうる「動き続けるもの」かどうかを判断できるのは、依然として人間だけです。

例えばAIにコードを書かせれば、一見完璧なロジックが瞬時に出てきますよね。でも、それが1秒間に数万回呼ばれるメソッドだった場合、その内部で行われているメモリ確保の頻度や、コネクションの占有時間にまでAIが配慮しきれているとは限りません。抽象化されたレイヤーの上だけを見ていると、その「重さ」に気付けないわけです。

——パケットの往復やメモリの挙動を、頭の中でシミュレーションできる解像度があるかどうか。

そうです。その解像度を失ってしまうと、AIの回答を鵜呑みにするしかなくなり、本当の意味でシステムをコントロールすることはできません。

——何か問題が起きたときの「最後の一手」は、やはり低レイヤーの知識を持つ人に託されると。

もちろん、全員が職人を目指す必要はありません。でも、AIという新しい道具を使いこなしつつ、自分の中に「語れる領域（構造の理解）」を複数持っておくことが、AI時代の決定的な生存戦略になるのではないでしょうか。

——茂岩さんの場合は、それがインフラとセキュリティー、そして事業だったわけですね。

僕の場合、それらを別々のものとして捉えたことはありませんでした。インフラを突き詰めればセキュリティーの急所が見えてくるし、それらを守ることは、受話器の向こうのユーザーの日常を守ること、つまり事業そのものに直結している。

全てが自分の中で「地続き」だったからこそ、どんなに技術や環境が変わっても、迷わずに役割を果たし続けてこれたのだと感じています。

——その「迷わなさ」の根底には、圧倒的な学習量があるように感じます。驚いたのですが、Mobage全盛期の怒涛の忙しさの中でも、帰宅後に独学でセキュリティーに没頭されていたそうですね。

単純に「未知のものを知る」のが楽しいんですよね。仕事として必要だからやるというより、気になったら自分の手で確かめないと気が済まない。

若いエンジニアの方にも、自分の興味に従って、勝手に新しい領域へ踏み出してほしい。人に強制されたハードワークは毒になりますが、自発的な好奇心に突き動かされた知識の習得は、いつか自分を助ける最強の武器になる。僕はそう信じています。

—— 茂岩さんのお話を聞いていると、技術がどれほど進化しても、その裏にある本質的な苦労は変わらないのだと感じます。まさに、「動くものを作るのは容易だが、それを『動き続けさせる』ことは、いつの時代も困難で、だからこそ価値がある」ということですね。

そうですね。でも、その執念の先にある手応えこそが、エンジニアの醍醐味だと思っています。

僕が一番嬉しいのは、自分の技術が「誰かの日常を守っている」と実感できる瞬間です。赤ちゃんの泣き声が聞こえたあの日の電話から、僕の根底にあるものはずっと同じです。時代が変わっても、エンジニアリングの原理原則はいつだって共通。これからも、その手応えを大切にしながら、新しい技術と向き合っていきたいですね。

取材・文／武田敏則
撮影／桑原美樹　撮影場所／freee本社
編集／玉城智子（編集部）