「手作業でやってきた部分ほど自動化しづらい」 MIXI社「インフラAI活用」の“泥臭い” 実践

オンプレミス、ハイブリッド、競輪場。

MIXI社が抱えるインフラは事業の多角化に伴い、複雑かつ広範囲に広がっています。主要サービスを振り返ると、SNS「mixi」のオンプレミスサーバに始まり、「モンスターストライク」ではハイブリッドクラウド、「家族アルバム みてね」ではクラウドネイティブ。そして競輪・オートレース投票サービス「TIPSTAR」では、全国の競輪場に無数の物理回線やサーバが運用されています。

そんな同社では現在、AIを前提とした業務設計を推進中。全社で300件を超えるAIプロジェクトが進行しています。その波は、同社インフラチームにも。膨大なsyslogから「対応すべき異常」を判定するログ解析や、特殊な現地機材のマニュアルを即座に引き出すRAG（検索拡張生成）、サーバの故障診断などの実装が進められています。

そこには会社の内外にWebから物理まで多様なインフラを抱える、同社ならではの課題や発見もあるはず。その現状について聞くため、同社インフラチーム出身で、現場の最前線で奮闘を続けてきた執行役員 CTO・吉野純平さんにインタビューを申し入れました。

実際の取り組みを通じて吉野さんが感じた「インフラにおいて、AIに任せられる領域」「そうでない領域」の境界線とは。そして、AI活用が現場にもたらした「インフラそのものに留まらない、予期せぬ変化」とは――。

• keyboard_arrow_down 自動化の“パラドックス”。人が手を出したくない部分ほどAIに任せづらい？
• keyboard_arrow_down AIは「コードを普段書かないエンジニア」を変える
• keyboard_arrow_down 障害対応から「人」を解放したくて

――本日はよろしくお願いいたします。MIXI社では全社的にAI活用を推進しているとのことですが、インフラチームにおいては、具体的にどのような領域で活用が進んでいるのでしょうか。

吉野：まず背景をお話すると、当社では開発本部を含む全社的な目標として、部署ごとの成果の一定割合をAI関連のアウトプットで構成することを求めています。その体制のもと、インフラチームでは現在、大きく分けて3つのアプローチでAI活用を進めています。

1つ目は、「ログ解析・判断」。日々大量に出力されるsyslog等のログをAIに読み込ませ、その重要度や異常の有無を判定させるものです。2つ目は「専門業務の自動化・診断」。ネットワーク機器の脆弱性診断やコードレビュー支援など、特定の専門タスクをAIエージェントに代行させるアプローチです。3つ目は「ナレッジ検索（RAG）」。過去の障害対応ログや手順書、物理拠点にある機材のマニュアルなどを、対話形式で引き出せるようにするものです。

この中で、インフラ運用の現場の負担軽減という点で、特に効果を実感しているのが「ログ解析」の領域です。

――ログ解析ですか。SNS「mixi」時代から10数年以上にわたり蓄積されてきた、膨大な障害ログや運用データがあるかと思います。これらを基盤に学習させ、過去の事例から最適解を導き出すようなAIを構築したのでしょうか？

吉野：いいえ、基盤モデルそのもののファインチューニングなどは行っていません。そもそも、過去の生ログには、現在は存在しない機材のエラーや「開発環境で発生した無視していいエラー」などが大量に含まれています。これらを無差別にAIに与えても「過去にこんなエラーがあったので今回も危険です！」と誤ったアラートを出し続けるだけになってしまう。

私たちが行っているのは学習ではなく、日々流れてくるリアルタイムのログをLLMに判断させるというアプローチです。

――各サービスの規模を考えるとリアルタイムのログも量が膨大かと思いますが、どのようにしてAIに「正しい判断」をさせているのでしょうか。

吉野：当たり前かもしれませんが、重要となるのはAIに読ませる前段での「人間による徹底的なフィルタリング」です。

私たちは、過去の実践知として「絶対に無視していいもの」「既知のバグであり影響がないもの」を把握しています。そしてそうした知識は、日ごろからログ収集フィルターにどんどん蓄積させています。人間がすでに経験知を有していることなら、ルールベースで処理すればいい。その上で、フィルタリングをすり抜けた未知の挙動や判断に迷うログだけをLLMに渡し、解析してもらうイメージです。

――そうして、AIにはどのような役割を求めているのでしょうか。

吉野：主には、残ったログに対する「重み付け」による判断です。フィルタリングを通過したログに対し、LLMが「これは静観でOK」「これは今すぐ対応が必要」といった重み付けを行い、「なぜそう判断したか」を自然言語で要約し、メールやSlackなどで通知します。

これによる成果は大きいと感じています。従来なら監視システムから何らかのエラー通知が届くたびに運用担当者がPCを開き、サーバにログインしてログの中身を確認し、影響範囲を調査する……というフローを繰り返していました。

しかし今では、AIが「この通知は問題ないので静観で良いです」と判断したり、あるいは対応が必要なアラートであれば、自動的にサーバの状態を見に行って故障箇所を特定し、「メーカーへの修理手配が必要です」という報告と共に修理依頼メールのドラフトまで作成したりしてくれます。人間は、AIが提示した内容を確認して送るだけ。「とりあえず調査する」という初動にかけていた時間は、ほぼゼロになりました。

――人間が担ってきた判断の前捌きを、AIが肩代わりしているのですね。

吉野：はい。ただ、こうした仕組みをすぐに進めることができたのは、AI導入以前から、ログを収集・集約する基盤や、エラーをフィルタリングする知見が社内に整備されていたからだと思います。このように「人が課題意識を持ってコーディングを行い、もともと仕組み化を進めてきた」領域でこそ、AIは活躍しやすいんですよね。土台があるから、AIを組み込むだけでレバレッジが効く。

逆にいえば、人が「作業の発生する頻度が低いから」「複雑だから」といって手作業で凌いできた部分は、結局のところAIにとっても手出しが難しいとも感じています。

「手作業でやってきたところほど、自動化が難しい」というもどかしい課題があるのです。

――人間自身が仕組み化を進めていたところではAIは活躍しやすく、「手作業で凌いできた領域」には適用しづらいというのは、皮肉な問題だと感じます。具体的にどのような業務がそれに該当するのでしょうか？　そして、なぜAIの活用が難しいのでしょうか？

吉野：分かりやすい例でいえば、サーバの物理的な納品やセットアップ作業です。

例えばインターネットサービスプロバイダのように、毎日膨大な数の回線開通作業が発生する事業であれば、自動化の投資対効果は高いでしょう。

しかし、当社の場合はサーバを数千台規模で運用しているとはいえ、「毎日1台ずつ増える」わけではありません。ある時期にまとめて納品され、まとめてセットアップして終わりです。このように頻度が低い作業というのは、人間にとって「わざわざ自動化ツールを作るモチベーション」が湧きにくい。

だから、これまでは基本的に手作業で対応していました。そして、人が手順書を見ながら手作業でやっている業務を、いきなりAIに「やっておいて」と頼むことはできません。

しかももともと自動化のモチベーションが湧きづらい以上、必然「AIを使って効率化する喜び」も生まれづらい。

こうした複合的な理由によって、自動化がなかなか進まない領域というものがあるのです。

――他に、AIの活用を阻む壁が存在する領域はありますか？

吉野：「設定変更」の領域もそうです。先ほどお話したような、AIによるログ解析はいわば「読む」作業ですが、インフラの設定を書き換えるという「書く」作業については、現状ではAIに自律的には行わせていません。

技術的に不可能というわけではありません。しかし、設定変更は一度ミスをすればサービス全停止などの甚大な被害に繋がるリスクがあります。そのリスクに対し、頻度の低い変更作業を自動化するメリットが見合わない。ここも「人が課題意識を持って仕組み化するコスト」に見合わない領域であり、あえて人間が判断して実行する形を残しています。

そして、最も手作業や属人化による壁が厚いのが、「社外の物理的な現場」を伴う事業のインフラです。

――物理的な現場、ですか。

吉野：はい。当社はWeb完結のサービスだけでなく、スポーツ領域では全国の競輪場やオートレース場、さらにはアリーナ運営事業の施設など、社外の様々な「物理的な現場」にもインフラを有しています。

一般的なデータセンターであれば、電源や空調は安定しており、ある程度標準化された環境で運用できます。しかし、それ以外の通常の施設ではそうはいきません。施設ごとに電源の事情も違えば、建物の管理規則も違う。ビルの点検によって、突然電気が止まることもあります（笑）。

また、新たに地方などで設備を立ち上げる際には、電源の形状や配線のルート、コンセントの電流値ひとつとっても、人間が現地に行ってみないと分からないことが多々あるので、地場の回線業者さんに片っ端から電話をかけて頼み込んだり。場合によっては私も、機材をセットアップした状態で「行ってきます！」と旅行カバンに詰め込んで新幹線に乗って現地へ向かい、数時間で設置し、そのまま帰ってくる……という対応をしたことも何度かあります。

――確かに、複雑で様々な事情を持つ物理的な現場にAIを導入するのは、簡単ではなさそうですね。

吉野：そうですね。なので、できそうなことから少しずつ手をつけ始めています。例えば、当社が運営に関わっている「LaLa arena TOKYO-BAY（ららアリーナ 東京ベイ）」の設備運用においては、現場のエンジニアたちが「RAG」により「LaLa arena Bot」という仕組みを自作しました。

これは「ネットワークプリンタのIPアドレスを教えて」「内線電話の設定はどうやるの？」と自然言語で尋ねると、AIが社内のWikiやマニュアル、構成図などを検索し、回答してくれるものです。これにより、その現場の専任者でなくても、AIに聞けば現地対応が可能になりました。

――属人化しがちな「物理的な場所の情報」という、ある種のドメイン知識の民主化がなされたのですね。

吉野：ええ。ただ、ここでも重要なのはAIそのものではなく、「情報の鮮度」を保つ仕組みです。現地の機材設定は、日々変更される可能性があります。古いマニュアルをAIが参照して嘘を教えたら、現場は混乱します。

そこで現場の担当者の間では、現地のネットワーク機器から最新の設定情報を毎日自動的に収集し、ドキュメントを常に上書きし続けるパイプラインを構築する動きが出ています。AIが正しく答えるためには、人間が正しいデータを与え続けなければならない。そのための仕組みづくりが現場で進められています。

――なんだかんだで、現場でのAI活用は進んでいる？

吉野：そこなのですが、インフラへのAI導入によって得られた最大の収穫は、業務の効率化やシステムの自動化でもなく、実は「現場のエンジニア」そのものの変化だったのではないかと感じているんですよ。

これまでインフラエンジニアの中には、サーバ構築や運用の高い専門性はあっても、「コードを書くこと」自体にはあまり馴染みのないメンバーもいました。「こうすればもっと楽になるのに」というアイデアは頭にあっても、それをゼロからコードに落とし込む手間や学習コストを考えると、どうしても腰が重くなってしまう。そんなケースもままあったのではないかと思います。

しかし、生成AIというツールの導入により、コーディングへの心理的・技術的なハードルが劇的に下がりました。その結果、彼らが自分たちの業務を楽にするためのツールやソフトウェアを、自ら積極的に書き始めるようになったのです。先ほどのLaLa arena Botもそうですし、ログ解析のスクリプトもそうです。また、システム構成図を描くプログラムを書かせる人もいます。

AIはインフラを勝手に直してはくれませんが、エンジニアたちを「自らの課題を解決するためにコードを書く人材」へと進化させてくれた。このマインドチェンジこそが、インフラへのAI導入を通して、当社が得られた最大の資産だと感じています。

――設定変更の領域は現状AIに任せていないとのことでしたが、今後の展望としてはいかがでしょうか。

吉野：ゆくゆくは、そうした領域にもAIを適用していきたいと考えています。もちろん、いきなり自律的に構成変更などをさせるわけではありません。まずは「定型化された変更作業」からです。

例えば、外部の回線事業者がメンテナンスを行う際、こちらのトラフィックを別の回線へ「迂回」させる作業が発生します。これは手順が決まっており、かつ一定の頻度で発生する作業です。こうした一定以上の頻度で発生する、定型的な作業においては、徐々にAIによる自動化、あるいはAIが生成した変更プランを人間が承認するフローへと移行していければいいなと考えています。

物理的な情報についても、もっと「データ化」を進めたいですね。例えば、遠隔地のコンセントに今どれくらい電流が流れているか、といった物理的なステータスもリアルタイムに収集し、分析可能なデータとしてAIに渡せるようにしていく。そうすれば「この機器、そろそろ故障しそうですよ」という予兆検知の精度も上がるはずです。

これまでお話したように、当社は運営型のビジネスが多いので、いかに障害対応から「人を解放していくか」というのは非常に重要なテーマです。

将来的には、インフラ利用部門からの問い合わせに対し迅速に対応可能な「障害調査エージェント」も構築していきたいと考えています。そうして煩雑な運用業務にかかるコストを下げ、エンジニアがサービスの価値向上や、新しいインフラの設計といったクリエイティブな業務に集中できる状態を作る。それこそが、私たちが目指すインフラ運用の未来です。

取材・執筆・編集：田村 今人
撮影：曽川 拓哉