特定のエンジニアに頼らない仕組みの作り方
New Relicは、2008年に米国で創業した、オブザーバビリティプラットフォームを提供する企業である。日本国内のオブザーバビリティ市場において、No.1のシェアを誇るベンダーだ。
同社の技術統括を務める伊藤基靖氏は、AI時代の開発における課題について「AIの導入によって開発の生産性が向上する一方、システム構成は今まで以上に複雑になっている」と指摘する。
ブラックボックス化した複雑なシステムでは、問題発生時の原因究明や、影響範囲の特定に多大な時間を要する。さらに、どのチームにエスカレーションするべきか判断がつかないまま対応が遅れ、その間にもユーザー体験が悪化するという悪循環に陥りかねない。
そこで伊藤氏は「AI時代のシステムに求められるのは、誰でもシステムの状態を即座に理解できる環境を整えることではないか」と提起した。特定のスーパーエンジニアに依存しなければ原因を追究できないといった、リスクの高い状態を回避することが重要である。
この理想を実現するのが、New Relicのオブザーバビリティのソリューションだ。同社は、フロントエンドからバックエンド、インフラまでを一気通貫でモニタリングできる「オールインワン」のプラットフォームを提供している。
例えば、アプリケーションでパフォーマンスの劣化が発生した時に、直感的に問題を特定し、LLMなどの依存関係を考慮しながら原因を探索できる。ログの調査が必要な場合も、画面を切り替えることなく、単一のダッシュボードで作業を完結できる点が特徴である。
こうしたプラットフォームを用いることで、開発者の誰もがシステムの状態を把握できる環境を構築できる。その実践事例として、ソフトバンクの開発チームによる取り組みが紹介された。
ソフトバンクの開発チーム直面した「属人化の壁」
New Relicを導入したのは、新しい生成AIチャットサービス「satto workspace」の開発チームである。これは資料作成業務などに特化したサービスで、AIと人間が協調することでスライド作成といった業務を効率化できる。
satto workspaceの開発には、モダンなフレームワークを採用しており、開発者体験を最優先した技術選定が行われている。GitHubを基盤に、さまざまなAIツールを活用して開発生産性の向上や自動化を図っているのが特徴だ。
同開発チームがNew Relicを導入したきっかけは、伊藤氏が指摘した「障害対応の属人化」という課題に直面していたからである。
パイロット検証の段階で障害通知が届くようになったが、その都度、原因の特定と対応に追われることとなった。しかし、ソフトバンクの厳格なセキュリティポリシーにより、AWSコンソールのログを閲覧できるのは、CTOの田口氏に限られていた。
結果として、すべての障害対応が田口氏に集中し、負担が増大した。他の開発メンバーはAWSの本番環境の状況が一切把握できず、システムがブラックボックス化していたのである。satto workspaceの正式リリースに向けてこの課題を解消するべく、オブザーバビリティツールの導入を決定した。
田口氏は、数あるオブザーバビリティツールの中でもNew Relicを採用した決め手を次のように説明した。
「さまざまなAIツールと連携して開発者のEX（Employee Experience）を向上させ、CI/CD全体を観測できる点。そして、ソフトバンクの厳しい社内ポリシーにも適合し、シングルテナントかつスケールに強い料金体系であったことが決め手となりました」（田口氏）
New Relicを導入したことで、開発メンバーがダッシュボードを閲覧できるようになったものの、すぐには全員が障害対応をできる状態にはならなかった。開発メンバーの一人である亀田氏は、3つの課題を挙げた。
1つ目は、度重なる仕様変更によるダッシュボードの陳腐化。2つ目は、パイロット検証の段階のため本番データが不足し、アラートの閾値設定が形骸化していたこと。3つ目が、モダンな技術スタックを使用しているためにNew Relicとの連携に独自の処理が求められることである。
これらの課題に対し、亀田氏は次のように対処した。
1つ目の「ダッシュボード陳腐化」の問題には、「薄く作って育てる」アプローチを採用した。 当初は詳細なダッシュボードを作り込んだが、仕様変更ですぐに使い物にならなくなったためだ。そこで、ALB（Application Load Balancer）などサービスの基本となる指標の監視に絞り、小さく始める方針に転換した。要件が固まるにつれ、必要な機能を順次追加する運用に切り替えた。
2つ目の「本番データ不足」については、閾値を仮説に基づいて設定し、一定の運用期間を設けて誤検知を抑制することで対処した。
また、3つ目の「モダンスタックとNew Relicの連携」には、分散トレーシングを導入して対応した。Honoや独自のロガーを使用していたため、New Relic上でエラーが「その他」に分類され、前後の文脈が途切れてしまうという問題があった。
そこで分散トレーシングを導入し、アプリケーション側に直接手を加え、New Relicに適したログ構造化を実施したのである。これにより、エラーを「点」ではなく「線」として監視することが可能となった。
「全員で」New Relicを見る文化づくりへ
3つの課題を克服し、システム状況を把握する仕組みは完成した。しかし亀田氏は「まだチームは最強になれていない」と述べ、ツール導入後の新たな課題を指摘した。
それは「日常的にNew Relicを確認する習慣が定着していない」という点だ。チーム内には依然として「障害が起きたら田口氏に頼ればよい」という空気が残っており、田口氏自身も多忙のため、十分に確認できていない状況だった。
「構築が終わったので、これからは全員でNew Relicを見るという習慣を作り、“文化を変えていく”フェーズへ進んでいきます。属人的な運用を脱却し、真のBizDevOpsを目指します」（亀田氏）
生成AIの挙動も本番環境の状態も、以前は不可視なブラックボックスであった。しかし、可視化が実現したことで、開発チームとビジネスチームが同じデータを基に議論できる土台が整った。「ツールの導入はあくまでスタート地点」と亀田氏は強調する。
今後の展望として、ダッシュボードの異変から障害を予知する「察知」の自動化を目指している。さらに、トークン使用料などのコストを可視化し、経営判断に直結させるステップも見据えているという。
また田口氏は、satto開発チームを「スタートアップのスピード感と、大手の安定性を兼ね備えた稀有な環境」であると語った。ソフトバンクという大組織の中にありながら、スタートアップ出身の平岡拓氏が率いる部門として、リスクを恐れず生成AIドメインに挑戦している。
「テクノロジーで社会構造を更新し、皆の心に余白をつくる」という理念を掲げ、これからも次世代の開発に取り組んでいく。
