AIで実現する“攻めのインフラ” Red Frascoはいかに監視運用を事業成長につなげたか

大東建託グループの不動産ポータルサイト「いい部屋ネット」をはじめ、不動産業界に特化したメディアのグロースを支えるRed Frasco。2025年11月公開の記事では、4年にわたるAWS移行と、その難所となったデータベース移行の舞台裏を紹介しました。

その後、同社は「いい部屋ネット」に加え、複数の顧客へとサービス提供の範囲を拡大。担当する基盤が増えるなか、監視運用にAIを導入しました。以前は原因の特定に早くても半日ほどかかっていた調査が、現在はDatadog Bits AI（以下、Bits AI）を使えば数分で回答を得られ、対応策の整理まで含めても1時間以内で完了します。月1回が限界だったログ分析も日次の自動レポートへと変わり、広告配信に関する課題を見つけ、インフラチームからマーケティングチームへ情報連携する動きも生まれています。

一方、AI活用に伴うコストが想定以上に膨らんだことから、インシデント対応の自動化を見直す場面もありました。AIにすべてを任せるのではなく、分かりやすいログやアラートを整備したうえで、AIが得意な事実の抽出と、人が担う解釈・判断をどう分けるのか。 今回はRed Frascoのシニアインフラエンジニアである猪熊さんに、試行錯誤から見えてきたAI活用の現実と、監視運用を事業成長につなげる“攻めのインフラ”の考え方について伺いました。

高度化するサイバー攻撃と大量アクセスに、AIで先手を打つ。“アラートが鳴ってから動く”監視運用からの脱却

──前回の記事では、4年にわたるAWS移行と、その難所となったデータベース移行について伺いました。その後、猪熊さんの担当領域・役割にはどのような変化がありましたか

猪熊： 前回からの大きな変化は、お客様やプロジェクトが増え、複数の基盤を担当するようになったことです。私は引き続きインフラエンジニアとして、複数の不動産メディアを支える基盤の設計・構築・運用を担っています。

以前は「いい部屋ネット」のインフラに深く入り込み、その改善に集中していました。現在はそれに加えて、あるプロジェクトで有効な仕組みや知見を、ほかの基盤にも横展開することの重要性が高まっています。SREの文脈でいえば、プラクティスを組織全体へ浸透させるような動きですね。

とりわけ、昨今サイバー攻撃が高度化・多様化し、日本中のさまざまなサイト・サービスが不安定になったり、情報漏洩事故に繋がったりするケースが増えていて、最近は国内でも情報漏洩につながったりするケースが相次いでいます。

不動産メディアは、問い合わせを通じてユーザーの大切な情報をお預かりするサービスです。だからこそ、被害が起きてから対処するのではなく、攻撃の兆候をできるだけ早く捉えて先回りしたい。担当基盤が増えるなかでも、その水準を保つため、監視運用にいち早くAIを取り入れています。

──監視運用にAIを取り入れるにあたり、従来の業務や対応のどこを変えたいと考えていましたか

猪熊： 一番変えたかったのは、アラートが鳴ってから動く、受動的な対応です。予兆を事前に捉えようにも、メトリクスやログなど確認すべき範囲が広く、ログの量も膨大です。サイトが成長するにつれて、人の目で一通り確認するだけでも、負荷の大きな作業になっていました。

ログ量の推移や怪しいアクセスの有無を確認するモニタリングも、月1回の定例会議で行うのが限界でした。本当は日々の細かな変化まで追いたかったのですが、体制やリソースを考えると難しかった。そこでAIを活用し、何かが起きてから調査する運用から、日常的に変化の兆候を捉えられる運用へ変えられないかと考えたんです。

──確認する範囲が広いなか、限られた体制で日々の変化を追うのは難しいですよね。実際にアラートが発生した際は、チームでどのように対応していたのでしょうか

猪熊： 特定のメンバーがすべてのアラートを一次受けするのではなく、開発チーム全員で対応しています。そこにアプリとインフラ間の壁は一切ありません。

アラートが飛んできたら、気づいた人が当事者意識を持って対応する。一人に負担を集中させず、開発チーム全員で見る体制は、当時も現在も変わっていません。

──役割の境界を設けず、チーム全体でサービスを支えるのは、Red Frascoの開発チームらしさでもありますね

猪熊： はい。ただ、全員で見ていても、長く担当している人ほど勘所をつかんでいるため、状況の把握や対応が速い。一方、経験の浅い人や参画したばかりの人は、アラートが飛んできても何が起きているのか判断しづらい。どうしてもノウハウの差が生まれるため、一次切り分けには結局は主要メンバーが入ることが多いのも事実です。

toC向けのポータルサイトは、24時間365日動き続けています。不特定多数のユーザーに加え、さまざまなボットからも大量のアクセスがあります。その傾向を捉え、根拠を持って状況を判断するには、やはり一定の経験やスキルが必要なんです。

こうした経験による差を補いたいと考えたことも、AIの導入を決めた理由の一つです。ログやメトリクスの収集・整理をAIに任せることで、誰でも一定の水準で状況を把握できる状態を目指しました。

Bits AIを1カ月足らずで仕組み化。“まず試す”を支える裁量と意思決定

──監視運用へのAI活用を進めるうえで、最初に着目したのはどのような技術だったのでしょうか

猪熊： 具体的な活用の起点となったのは、監視基盤として利用しているDatadogの「Bits AI」です。当社ではログやメトリクスをDatadogに集約しているため、Bits AIを使えば、蓄積された情報をチャット形式で確認できます。

実際に試してみると非常に便利で、使わない手はないと感じました。対応が後手に回りやすいという課題や、担当者によって初動判断の速さや質に差が生じる状況を、Bits AIによって改善できるのではないかと考えたんです。

──Bits AIはいつ頃から使い始め、どのように監視運用へ組み込んでいったのでしょうか

猪熊： Bits AIのChat機能がDatadogの画面に登場して間もない、2026年6月ごろから使い始めました。

月次のモニタリングでは、複数のアカウントにまたがるインフラコストやGoogle Cloudの利用料、アクセス元IPの傾向、クローリングへの対策状況などを確認しています。まずはDatadogに蓄積されたこれらの情報をBits AIで分析できるようにし、1カ月足らずで一連の作業を仕組み化しました。

──検証から意思決定、導入まで、非常にスピーディに進められたのですね

猪熊： 当社では、新しいツールはまず試してみて、効果が見込めれば導入し、合わなければすぐにやめるというスタンスです。予算の範囲内であれば、CTOと直接話しながらスピーディに判断しています。

──実際に試したものの、導入や継続利用を見送ったAIツールもありますか

猪熊： Claude Tagなどを使ったインシデント対応の自動化も試しましたが、コストに見合うほどの効果は得られず、こちらは本格的な導入には至りませんでした。

※注：当時利用したβ版での検証結果です。モデル自体の解析能力は非常に高かったものの、履歴全域を巻き込んだトークン消費によって1ストロークで数ドル以上かかるケースがあり、費用対効果の観点から継続を見送りました。

──見送ったツールもある中で、Bits AIがわずか1カ月足らずで実用化できたのはなぜでしょうか。AIがうまく機能するかどうかの分かれ目はどこにあると感じますか

猪熊： AIを導入する以前に、適切なログ設計やデータ整備といった「当たり前の土台作り」ができていたかどうかの差だと思います。

過去にロードバランサーとWebサーバー間のタイムアウト不整合によるトラブルを調査した際も、全員でDatadog上でアクセスログを泥臭く追って「なぜデフォルトの60秒ではなく65秒でなければならないのか」という根拠まで突き止めました。そうした挙動のメカニズムを人間が理解し、人間がデータとして追える状態になっていなければ、AIを投入したところで魔法のように原因を特定してくれるわけではありません。

今回は、アクセス元IPの傾向やリクエストを串刺しで追跡できるIDなどをDatadog上に構造化データとして蓄積していたからこそ、「異常値と急増要因を抽出してレポートを出して」というシンプルな指示だけで実用的な結果が得られました。人間が追えないブラックボックスをAIに丸投げするのではなく、まずは人が適切に運用できる基盤をつくる。その上でAIを調査の高速化に活かすという本質は、AIが当たり前になった今でも変わらないと思います。

──クライアントワークでは、利用するツールの選定に制約が生じることもあると聞きます。Red Frascoでは、どの程度の裁量を持って判断できるのでしょうか

猪熊： 私たちは、専門家として不動産メディアの成長と売上への貢献まで責任を持ちます。その責任を果たすために必要なツール費用は一定の予算枠として確保しているため、その範囲内であれば、新しいツールも比較的スピーディに検証できます。

もちろん、自由にツールを導入しているわけではありません。必要な説明責任を果たしたうえで、ツールの選定や導入を進めています。また、ツールは導入して終わりではありません。費用対効果が得られているのか定期的に確認・議論し、コスト最適化やツール利用の廃止など臨機応変に意思決定しています。

半日の調査が数分に。AIの“鳥の目”で事業課題まで捉える

─ Bits AIの導入後、監視運用はどのように変わりましたか

猪熊： 大きく変わったのは、問題発生時の調査スピードと、変化の兆候を捉える頻度です。

以前は、CPUやメモリ、データベース、各種メトリクス、ログを横断して調査する必要があり、原因の特定まで早くても半日ほどかかっていました。現在は、Bits AIに「この時間帯に起きた問題を調べて」と質問すれば、数分で回答が返ってきます。AIが調査している間に別のタスクを進められますし、調査から対応策の整理まで含めても、1時間以内に完了できるようになりました。

もう一つは、予兆を捉えやすくなったことです。ToC向けの集客サイトは、集客施策やクローラーなどの様々な要因でアクセストレンドが絶えず変化します。不連続的に急激に変化するものは捉えやすいですが、時間をかけてゆっくりと変化することもあり、連続性のある動き方をすることも多くあります。その中から、前日や前週と比べたわずかな変化を見つけ、インサイトを得て改善活動に繋げることが重要です。

そこで、Bits AIによる傾向分析を日次の自動レポートとして運用フローに組み込みました。「WAFによるブロックが急増しており、最もブロックが増加しているルールは〇〇である」「問い合わせフォームのネットワークエラーが増えている」「301転送の件数が増えている」といった、しきい値監視や異常検知だけでは気づきづらい変化を、AIが毎日報告してくれます。これまで月1回だった確認を日次で行えるようになり、変化に反応するスピードだけでなく、得られる情報の質と量も格段に向上しました。

─それは大きな変化ですね。こうした監視運用の進化は、プロダクトや事業への貢献にどのようにつながっていますか

猪熊： 特に大きいのは、監視基盤から得られたインフラの情報を元に、開発だけでなく、マーケティングの改善につなげられるようになったことです。

ログやメトリクスが膨大になるため、インフラのモニタリング範囲はどうしても広くなりがちです。AIは膨大なメトリクスやログを俯瞰して捉える「鳥の目」のような役割を果たしてくれます。その結果、これまでインフラだけでは見つけにくかった事業上の課題にも気づけるようになりました。

─インフラのデータから、集客に関する課題まで見えるようになったのですね。具体的な例を教えてください

猪熊： 広告の配信設定を変えると、アクセス数や流入元の変化として真っ先にログに表れます。ただ以前は、月次のモニタリングでも開発観点のエラー対処だけで手一杯で、Bits AIがなければマーケティングの領域まで分析の手を広げる余裕はありませんでした。

Bits AIによって高頻度でログを追えるようになり、その真価を実感したのが、ある広告キャンペーンでの出来事です。

当時、マーケティングチーム側では「CVRが好調で手応えがある」と見ていたのですが、インフラ側でアクセスログを分析したところ、実は流入の大半がWAFでブロックされていることが分かりました。表面上のCVRは高く見えていたものの、ログの裏側では意図しない属性のアクセスが多く弾かれていたんです。

そこでインフラからマーケティングチームへすぐに状況を共有し、広告媒体の会社様も巻き込んでターゲティング設定の見直しを行いました。インフラ・マーケ・媒体会社様が一体となってチューニングを重ねた結果、意図しないブロックを解消し、より良質なアクセスを届けることでさらなるCV増加に繋げることができました。

ほかにも、「アクセス増に伴うDatadogのログ課金に対して、十分な反響が得られているか」という費用対効果の検証や、「いたずら反響が増えていないか」といった集客の質のチェックなど、マーケティングの管理画面だけでは見えにくい死角をインフラのデータから補えるようになっています。

単なるシステムの障害対応にとどまらず、マーケティングと一緒に事業を伸ばすための議論に参加できるようになったのは、非常に大きな手応えですね。

─サービスを守るだけでなく、インフラ側から事業の改善に踏み込めるようになったのですね

猪熊： もともとインフラは、事業成果とのつながりが見えづらい領域です。そのため、一言で「事業貢献」といっても、具体的に何から優先的に取り組むべきか日々考えながら仕事を進めています。

その一方で、開発チームやマーケティングチームと立場は対等であり、役割が異なるだけに過ぎません。すなわち、事業とのつながりが見えづらくても、他のメンバーと同じ視座で事業について対話・議論する必要があると考えています。これまでは、関わり方について模索することもありましたが、AIによって、インフラ起点で事業目線での課題抽出や問題提起につながる気づきを得やすくなりました。

今では、自分から課題を見つけ、マーケティングチームに働きかけることも増えています。インフラやサービスの振る舞いや傾向の変化は単なる”事象”でしかありません。周囲とよく会話し、そこから得られた情報を事業目線で解釈することで、より事業に踏み込んだ動きができると思います。AI によってそのような働きがしやすくなったと感じています。

AI時代だからこそ、事業成長に向き合い、技術に誠実であり続ける

──AI導入では、業務効率化などの効果が期待できる一方、コスト面の課題も多く聞かれます。Red Frascoでは、AIの費用対効果をどのように考えていますか

猪熊： AIにコストがかかるのは間違いありません。予算は有限ですから、限られた資産は事業成長につながる施策へ最大限配分すべきです。

DatadogのAIクレジットは従量課金のため、分析の頻度や対象ログを広げるほど費用は跳ね上がります。実際、日次レポートを運用に組み込んですぐ、Datadogの月額料金が30万円以上も急増しました。上位の高性能モデルを使い、膨大なログやメトリクスをそのまま解析させていたので当然の結果ではあったのですが、さすがに看過できない金額でした。

費用に見合う価値があれば投資として妥当ですが、この30万円すべてが本当に必要なコストかといえば別問題です。レポートの価値は保ったまま、費用対効果を極限まで高めるための最適化にすぐさま着手しました。

──コストを抑えるために、具体的にどのような見直しを行ったのでしょうか？

猪熊： 鍵になったのは、「AIに集計をさせないこと」と「モデルの適材適所」です。 以前は、生のログやメトリクスをそのままAIエージェントに丸投げしていました。集計、四則演算、前日比の計算、異常値の検知、そしてレポート執筆まで、すべてを単価の高い最上位モデルに処理させていたため、入力トークン数もモデルの利用単価も二重で跳ね上がっていたんです。

そこで設計を見直し、「計算や定型集計はプログラムにやらせ、AIにはデータの解釈と示唆出しだけをやらせる」という役割分担に切り分けました。合計値の計算や前日比の算出、一定のしきい値フィルタリングなどは、AIに渡す前のアプリケーション（スクリプト）側で前処理として集計するようにしたんです。

入力データを構造化されたサマリーまでギュッと圧縮できたことで、使用するAIモデルのランクを1段階下げることができました。もちろん最初はモデルを下げたことでレポートの表現力や着眼点の甘さが出ましたが、「どの数値を優先して比較すべきか」「どういう文脈で異常と判定するか」をプロンプト側にルールとして落とし込み、品質が元に戻るまでチューニングを繰り返しました。

その結果、レポートの品質を一切落とさずに、月30万円超だったコストを95%以上削減し、月1万円台にまで抑え込むことに成功しました。

最初から完璧なコスト最適化を目指すのではなく、まずはコストをかけてでも最速で価値を証明し、その後に泥臭くアプリケーション側へ処理をオフロードしていく。これが生成AIをオブザーバビリティに組み込む際の現実的なアプローチだと感じています。

──インフラの監視運用にAIを活用するうえで、エンジニアが意識すべきことは何でしょうか

猪熊： 大切なのは、AIに任せる部分と、人が判断する部分を明確に分けることです。

コード生成に限らず、ログから変化を見つけたり、日次レポートを作成したりと、客観的な事実や情報を抽出・整理・再現することはAIの得意分野です。こうした明確に答えのある作業をAIに任せれば、経験の浅いエンジニアでも、一定の水準でインフラやサービスの状況を把握しやすくなります。

一方、その事実をどう解釈するか、事実をもとにどのような意思決定を行うかは、正解のない世界です。正解のない世界においては、人が責任を持って判断・意思決定しなければなりません。正解のない世界では、エンジニア自身の経験や技術力によって判断の質が大きく変わります。特に経験の浅い方は、AIの回答をそのまま受け入れるのではなく、自分自身で吟味・判断をして、判断の経験を数多く積むことでスキルが洗練されていくと考えています。

AIは、エンジニアの仕事を単に代替するものではなく、経験を補い、学びを加速させ、質・量ともに、よりよい成果を出すための手段として活用すべきだと考えています。

──最後に、Red Frascoではどのような志向を持つインフラエンジニアが活躍できるのか、応募を検討している方へのメッセージも含めて教えてください

猪熊： Red Frascoのインフラは、ただサーバーのお守りをするだけの「守りの職種」ではありません。ここで働く面白さは大きく3つあります。

1つ目は、AIを使って最少人数で「攻め」に回る面白さです。よく「AIで効率化しても別の仕事が降ってくるだけで意味がない」と言われますが、それは空いた時間でまた別の作業をやらされているからだと思うんです。私たちが定型監視をAIに任せているのは、空いた時間で別のチケットを消化するためではありません。ログを追ってマーケのボトルネックを見つけたり、基盤そのものの設計を見直したりと、「技術を使ってどんな課題を解決したいか」に向き合う時間を作るためです。

2つ目は、複数の基盤をマルチテナント的に横展開していく難しさと面白さです。個別プロダクトに最適化したインフラ構築だけでなく、複数サービスを見据えて「どこを共通基盤にして、どこを切り離すか」という全体設計に向き合えます。スケールさせるためのアーキテクチャを試行錯誤できるのは、インフラエンジニアとして腕が試される面白いフェーズです。

3つ目は、CTOと直接話して「良さそうだから試してみよう」と即断で新しい検証ができるスピード感です。検証用の予算枠があらかじめ確保されているので、ツールを試すたびに面倒な稟議を何枚も書く必要がありません。先ほどのBits AIのように実戦投入して効果を確かめられますし、マーケティングなど異なる専門性を持つメンバーと対等に議論しながら、チームで売上や事業成長に直接インパクトを出していける環境があります。

そして何より、事業に貢献するためにも「技術に対して誠実であること」は欠かせません。「なぜデフォルトの60秒ではなく65秒にするのか」といった根拠まで徹底して考え、学び続けられること。新しい技術を試すスピード感を持ちつつ、そうした1つひとつの設計に誠実に向き合える方にとっては、すごく手応えのある環境だと思います。