コールセンター向けクラウド通信サービスを提供するRingCentralが、ChatGPT Work（企業向けChatGPT）とCodex（OpenAIのコーディングエージェント）を、エンジニアリングと運用オペレーションの両輪に組み込んでいます。単なる開発支援ツール導入の話ではなく、開発チームと運用チームの情報を横断的につなぐ「運用インテリジェンス」の中央集約が焦点です。SREやインフラ担当者にとっては、AIツールをどこに接続すれば障害対応やオブザーバビリティ（システム内部の状態を外部から観測できる仕組み）の改善につながるかを考える材料になります。
通信インフラを24時間365日で提供する事業者にとって、可用性の担保は開発速度と同じくらい重んじられます。RingCentralの取り組みは、AIコーディングエージェントを使って機能開発を早めつつ、運用側の知見（インシデント履歴やログの傾向など）をAIが横断的に参照できる状態を作る発想に基づいています。この「開発と運用の情報を同じ基盤で扱う」という考え方は、DevOpsが目指してきた文化的統合を、AIエージェントという形で技術的に実装し直す動きとも言えます。
Codexが担う役割を分解する
Codexは自然言語の指示からコードを生成・修正するエージェントです。GitHub Copilotのような補完型ツールと異なり、複数ファイルにまたがるタスクをまとめて処理できる点が特徴です。
RingCentralのようにマイクロサービス（機能ごとに独立したサービス群でシステムを構成するアーキテクチャ）を運用する組織では、1つの機能変更が複数のサービス・複数のリポジトリに影響します。Codexにこうした横断的な修正を任せる場合、SREの視点では次の点を事前に確認しておく必要があります。
- 変更対象のサービスにCI/CD（継続的インテグレーション・継続的デリバリー）パイプラインでの自動テストが組まれているか
- Terraformなどのインフラ定義（IaC、Infrastructure as Code）に対する変更をAIエージェントに許可する範囲をどこまでにするか
- 生成されたコードがデプロイされる前に、ステージング環境での検証フローを通す仕組みがあるか
AIが生成したコードは人間が書いたコードと同様に、レビューとテストの対象です。むしろ生成速度が上がる分、レビュー体制とテストカバレッジの確認が追いつかないと、障害の火種を増やすリスクがあります。
運用オペレーション側でのChatGPT Work活用を考える
ChatGPT Workは企業のドキュメントやツールと接続できる企業向けChatGPTです。RingCentralはこれをエンジニアリングだけでなく、運用オペレーションの「情報の中央集約」に使っています。
SREの現場に置き換えると、インシデント対応の振り返り（ポストモーテム）、ランブック（障害対応手順書）、監視ダッシュボードの解釈といった、これまで人が個別に探していた情報を、自然言語で横断検索できる状態に近づけます。たとえば「先月発生したAPIレイテンシ増加の原因と対応手順は」という問いに対し、過去のインシデントレポートとランブックを横断して回答を返すような使い方が考えられます。
ここで重要なのは、AIが参照する情報源の鮮度と正確性です。オブザーバビリティツール（DatadogやGrafana、New Relicなど）から出力されるメトリクスやログを、ChatGPT Workのような対話型AIに接続する場合、次の点を確認しておくと安全です。
- 接続するデータソースが最新の状態に同期されているか（古いランブックを参照して誤った対応を提案しないか）
- 機密情報（顧客データ、認証情報）が含まれるログをAIに渡す前にマスキングされているか
- AIの回答をそのまま実行するのではなく、人間の承認ステップを挟むフローになっているか
SLO設計とAI活用の接点
SLO（サービスレベル目標）は「このサービスは99.9%の可用性を維持する」といった数値目標を定め、エラーバジェット（許容される障害時間の予算）を管理する仕組みです。AIエージェントを本番環境の変更に関与させる場合、SLOの文脈で押さえておきたい点があります。
変更頻度が上がるほど、エラーバジェットの消費速度も変わる可能性があります。CodexのようなAIエージェントによってコード変更のリードタイムが短縮されると、デプロイ頻度が増加し、結果としてインシデント発生の母数も変化します。SLOのアラート閾値やエラーバジェットの消費レートを、AI導入前後で比較検証しておくと、可用性目標とのズレを早期に発見できます。
コスト最適化の観点も忘れずに
ChatGPT WorkやCodexのようなAIツールはAPI呼び出しやシート課金でコストが発生します。運用インテリジェンス基盤として全社展開する場合、利用状況をモニタリングし、部門ごとの利用量とコストの相関を可視化しておくと、後々の予算見直しがしやすくなります。クラウドコストの最適化（FinOps）と同じ発想で、AIツールの利用量もオブザーバビリティの対象に含めておくと良い判断材料になります。
今日から確認できること
RingCentralと同じ規模でなくても、以下は今日から着手できる確認作業です。
- 自社のCI/CDパイプラインに、AIエージェントが生成したコードを検証する自動テストゲートがあるか
- ランブックやポストモーテムのドキュメントが、AIツールから参照可能な形式（社内Wiki、Confluence、Notionなど）で整理されているか
- Terraform/PulumiなどIaCのリポジトリで、AIエージェントによる変更提案をPull Request経由でレビューする運用になっているか
- SLOダッシュボードで、直近のデプロイ頻度とエラーバジェット消費の相関を確認できるか
これらはAIツールの有無にかかわらず、SREのベストプラクティスとして本来整備しておきたい項目でもあります。AI活用はこうした基盤の未整備を浮き彫りにするきっかけにもなります。
まとめ
AIコーディングエージェントと企業向けAIチャットの組み合わせは、開発速度の向上だけでなく、運用側の情報集約にも波及します。導入を検討する際は、CI/CDのテストゲート、IaCの変更管理、SLOのエラーバジェット監視という3点を軸に、既存の運用体制がAIエージェントの変更頻度増加に耐えられるかを点検してみてください。まずは自社のランブックがAIから参照できる状態にあるか、そこから見直してみるのが現実的な一歩です。