Smart Data Platform (SDPF) クラウド/サーバーのネットワークオーケストレータ「ESI」の開発において、生成 AI を活用するために行ったログ基盤の整備や開発環境の工夫についてご紹介します。ログサーバーの新設や コーディング支援 AI（本事例では GitHub Copilot を使用）の導入により、エラー調査・開発の自動化を実現した事例です。
はじめに
はじめまして。NTTドコモビジネスの SDPF クラウド/サーバーの内製開発に従事している堀岡勇杜と申します。
私が主に担当しているのは、「ESI（Elastic Service Infrastructure）」という名称の、クラウドのネットワークオーケストレータの開発です。ESI チームの業務内容については、こちらの記事でも紹介しています。
今回は、私が昨年度に取り組んだ ESI 開発における生成 AI 活用事例について、ご紹介したいと思います。
ESI について
具体的な活用事例について述べる前に、ESI の役割や構成について軽く触れたいと思います。
ESI は、SDPF クラウド/サーバーの SDN（Software Defined Networking）サービスや VM（Virtual Machine）サービスといった各種サービスと連携して、仮想ネットワークやゲートウェイ、VNF（Virtual Network Function）の提供・リソース監視を実施しているシステムです。SDPF クラウド/サーバーのネットワーク機能の中核を担っており、高信頼性と高可用性が要求されています。
下図は、ESI が Web ポータル や API 経由でのリクエストを受け付け、各種クラウドサービスと連携し、ネットワーク機能を提供する様子を示しています。
この ESI ですが、次のようなサービス群によって構成されています。
- OpenStack Neutron と互換性のある API サービス
- オーケストレーションサービス
- リソース監視サービス
これらのサービスは全て冗長化されており、高可用性を担保しています。
しかし、既存のオーケストレーションサービスには拡張性や管理面での課題が発生しつつあります。また ESI は10年を超える長寿システムであり、抜本的なアーキテクチャ改善が必要となってきています。
そこで私は昨年度からこのリアーキテクティングに、生成 AI を活用しつつ取り組んでいます。
リアーキテクティングにおける課題と施策
ESI のリアーキテクティングを進めていく中で、次のような課題が浮上しました。
- 生成 AI が各種サーバーからログを取得する構成にする場合のセキュリティ・権限・トークン消費量の問題
- 実装した内容がエラーを発生させた際のログ調査において、冗長化された複数サービスから出力されるログを横断的に調査することの難解さ
- 複数サービス結合によりシステムが成立していることによる、生成 AI 側のコンテキストやノウハウ不足
これらの課題を解決するために、以下の施策を実施しました。
ログ内容の精査 ― セキュリティ確保と安全なログ提供
生成 AI に渡されることがセキュリティ的に望ましくないログ出力の存在を入念に調査し、これらを全てログ出力から除去しました。地味な作業ですが、生成 AI にログを安全に提供するための前提として非常に重要です。
ログサーバーの新設 ― サービス横断的なログ調査の実現
冗長化された複数サービスから出力されるログを一元的に収集する、ログサーバーを新設しました。各サービスサーバーには Filebeat を配置してログを転送し、ログサーバー上の Elasticsearch に集約する構成としています。収集時にパイプラインを通すことで、サービス横断的に時系列順でのログが取得でき、かつ簡単にフィルタリングも可能です。
ログサーバーでは、API や MCP（Model Context Protocol）ツール経由でログを取得できるようにしました。 MCP ツールとしては以下のようなものを提供しています。
| ツール | 用途 |
|---|---|
| get_error_summary | エラーの全体像を把握する（パターン別集計） |
| get_recent_errors | 直近のエラーログを取得（日時範囲を指定可） |
| get_error_trends | エラーの時系列傾向を分析 |
| search_logs | キーワード・ID でログを横断検索 |
| trace_request | request_id からサービス横断でログチェーンを追跡 |
| investigate_proxy_error | リバースプロキシのエラーからバックエンドまで自動追跡 |
| get_proxy_errors | リバースプロキシの 4xx/5xx エラーを取得 |
| count_logs | サービス別のログ件数を確認 |
これらのツールを組み合わせることで、生成 AI が少ないトークン消費で段階的にログを調査できるようになっています。
この仕組みにより、ESI のリソース間リレーションも考慮したエラー調査が可能となりました。ESI のリソースは複数の関連リソースと密接に結びついており、あるリソースのエラー原因がその他のリソースにあることも多々あります。ログサーバーを通じてサービス横断的にログを参照できるようになったことで、エラーの真の要因に容易にたどり着くことができるようになりました。
また、コーディング支援 AI にはあくまでログサーバーへのアクセス権のみを与え、ログサーバーから各種 ESI システムへのリクエストは禁止しました。これにより、コーディング支援 AI が ESI システムに与える影響を最小限に抑えつつ、安全にログを参照できる環境を実現しました。
リポジトリ一元管理 ― コンテキスト不足の解消
開発サーバー上で ESI を構成するリポジトリ群を集約して配置することで、開発で使用しているコーディング支援 AI がこれらのコードを網羅的に調査・修正できるようにしました。下図は最終的に完成した構成です。
複数リポジトリを横断して参照できるようになったことで、ESI のコンテキスト不足問題についてはかなり解消されました。さらに、前述のログサーバーと組み合わせることで、例えばエラーが発生したリソースの ID を指定するだけで「ログからエラーの原因を特定 → ソースコードからエラー発生要因となるバグを特定 → バグを修正」といったことが自律的に可能になり、直近のバグ修正において調査・開発の時間が平均して従来比 約2割（つまり約80%減）に短縮できました。
実際の運用では、コーディング支援 AI が作成した差分を開発者がレビューしたうえでそのまま採用できるケースが多く、人手による追加修正が最小限で済む傾向にあります。ESI には既存開発で蓄積された大小さまざまなテスト群が存在しており、レビューとこれらのテストを前提に生成 AI を活用しつつ品質を確認しています。
展望
今回の取り組みで生成 AI による開発の基盤は整いましたが、まだまだ発展の余地があると考えています。
試験計画・品質検証の自動化
現在は「バグの特定→コード修正」までを生成 AI が担っていますが、試験は人間が計画しています。試験の計画、および生成される試験レポートのチェックも生成 AI が実施することで、コードの品質向上を自動的に進められていく環境を整えたいと考えています。
監視・障害対応への拡張
現在はあくまで開発時のエラー調査・修正に活用していますが、この仕組みは監視・障害対応にも応用できると考えています。例えばユーザーから不具合への対応を依頼された際に、生成 AI が自動的にログを分析して障害の影響範囲を特定し、既知のパターンであれば復旧手順を提案する、といった運用支援への発展が見込めます。この運用を見越し、既知の不具合パターンおよび対応方法を生成 AI が理解しやすい形で蓄積する営みを、現在進めています。
コンテキストの拡大
現状では、トークン上限の制約からログの出力内容を厳選し、必要最小限の情報のみを生成 AI に提供しています。将来的に AI がより長大なコンテキストを処理できるようになったり、ローカルで十分な性能を発揮できるようになったりした暁には、設定ファイルやデプロイ履歴など、より多くの情報を含んだログを提供することも検討できます。これにより、エラーの根本原因分析の精度がさらに向上することを期待できます。
今後の開発では、「どの程度の量のログ」を「どの程度の粒度」で「どのログレベルで出力するか」をより入念に設計していく必要があると考えています。
まとめ
今回は SDPF クラウド/サーバーのネットワークオーケストレータ開発における、生成 AI 活用の取り組みについて紹介させていただきました。今後も「品質の維持」と「生成 AI 活用による速度向上」の両輪で最適な開発を追求し、より便利で使いやすいクラウドの実現に向けて取り組んでいこうと思っています。
最後にインターンの宣伝です。本記事を通じて SDPF クラウド/サーバー開発や ESI 開発に興味を持っていただけた学生の方は、ぜひインターンのポスト「【B19】エンタープライズ向け大規模クラウド/ネットワークサービスを支えるコントローラ開発」にご応募ください。
