NTTビジネスソリューションズ株式会社様

ご利用サービス：Kompira Enterprise、Kompira Pigeon
導入時期：2025年〜
ご担当者様（右から）：
カスタマーサクセス部 マネージドサービス部門
マネージドオペレーションセンタ（大阪）
所長　　　難波様
担当課長　岡本様
　　　　　廣川様
　　　　　酒井様

クラウドサービスの高度化・多様化が進むなか、運用監視の現場には、これまでにない大量のアラートと複雑な手順が押し寄せている。
NTT西日本のMC-SOCは、NTT・NTT西日本グループをはじめ、企業が提供する複数サービス／システムを対象に、休日・夜間を含む24時間365日（24/365）の運用監視を担う“大規模SOC”だ。

そのMC-SOCがいま取り組むのは、運用監視の自動化。実現の裏側には、運用現場発のDXともいえる挑戦があり、必要に応じて外部の知見も取り入れながら推進してきた。本記事では、MC-SOC運用監視マネージャー・岡本氏、酒井氏に、その歩みを聞いた。

－自動化に取り組むことになった背景を教えてください。

岡本氏：MC-SOCでは、複数のサービス／システムを24/365体制で監視しています。監視対象が増えるのに合わせて保守運用マニュアルも増加し、手順の複雑化・属人化・負荷増大・初動対応のばらつきといった課題が顕在化してきました。

運用品質を維持しながら規模を拡大するには、「これまで通りのやり方」では限界があります。そこで、自動化を本格的に検討し始めたのがスタートでした。「MC-SOCの高い品質を、より速く、より確実に。保守手順を“仕組み化”することが不可欠だと考えました。」
従来は、サービス／案件ごとにマニュアルが整備され、手運用が前提の内容で現場が回っていました。

結果として、「一定期間に軽微なアラートが通知された場合」のような表現が解釈の揺れを生みやすく、“一定期間”はどれくらいか、 “軽微”はどのレベルかといったあいまいさが残りました。
オペレータのスキルレベルもまちまちで、同じ事象でも判断や対応品質にばらつきが生じがちだったのです。

自動化を進めるにあたっては、まずこのあいまいさを徹底的に排除し、プログラムとして解釈できる内容へ仕様を定義し直すことが不可欠でした。

－当初、自動化はどのように進めましたか。

岡本氏：最初の検討段階では、MC-SOCで内製していたツールを改良して自動化を進める案を検討しましたが、個人のスキルへの依存や
特定メンバーへの負荷集中、メンテナンス性の課題から、持続的な運用には不向きと判断しました。
また、ノーコード／ローコードの自動化ツールもトライアルで検証しましたが、MC-SOCではアラートの識別からインシデント対応までの手順が
複雑であり、当社の要件に照らすと適合しきれませんでした。

そこで外部の知見も取り入れつつ、まずは主要サービスをモデルケースに選定し、手順の分解と、自動化可能な領域の抽出から着手しました。
これに先立ち、外部の視点も取り入れて現状整理を行いました。

すでに一部ではツール活用による効率化は進んでいたものの、案件ごとに対応内容が異なり、自動化のための運用設計や目標が十分に定義されていない。その結果、自動化のレベルは限定的で、総合的にはあまり進んでいないという所見でした。
この所見は、私自身が現場で抱いていた課題認識とも一致していました。

既存の運用マニュアルは、一部ツールの活用を取り入れたものがありますが、基本的には手作業前提で書かれており、そのままでは自動化を実現することができません。
そこで、「どこが共通化できるか」「どこを自動化対象にするか」を丁寧に紐解き、自動化オペレーションへ落とし込みました。この段階では、レビューや優先度整理に外部の視点も得ながら、標準APIや内製スクリプトを軸に、将来の拡張も見据えた設計を意識しました。

－自動化の体制について教えてください。

岡本氏：体制としては、運用現場を中心に“自走できる”形を最初から意識しました。
具体的には、MC-SOC側で運用を理解しているメンバーが中核となり、手順の分解・標準化・自動化シナリオ設計を進め、実装はPythonやKompiraの機能を使って内製で回せるようにしています。

設計やレビューでは外部の知見も取り入れつつ、現場で回る“型”を整えました。
結果として、外部に依存しすぎず、現場が継続的に改善できる“自走体制”を築けたことが大きいです。

－何名体制でプロジェクトに参画されましたか。

立ち上がり当初は3名体制でしたが、今は13名が参画しています。
自動化を担うコアメンバーのスキル強化と並行して、メンバーの増員も継続的に進めています。

－プロジェクトにかかった期間を教えてください。

岡本氏：大きく2つのフェーズで捉えています。
まず「コンサルティング評価〜モデルケースの本番投入」までは、全体で2〜3か月程度でした。
この期間で、現状の整理（課題と目標の明確化）から、モデルケースの選定、手順の分解、優先順位付け、自動化オペレーションへの落とし込み、
そして本番投入までを一気通貫で進めました。
その後はPoC（モデル）を起点に、対象サービスへの横展開と定着化を進めていますが、ここは1年以内を目安に、段階的に範囲を広げています。

－Kompiraの強みを教えてください。

岡本氏：MC-SOCでは、もともと大量アラートのフィルタリングにKompiraを使っており、既存環境との親和性が高いことがひとつ。
加えて、当社の運用要件に適合する柔軟性を備えている点を評価しました。

• プログラミングによる自由度
• 各システムとのAPIによる柔軟な連携
• 複雑な例外処理・分岐設計に強い

つまり、“運用にシステムを合わせられる”のがメリットであると感じています。

－伴走支援を受けて、よかった点を教えてください。

岡本氏：初期段階では、自動化における”一番最初の基礎固め”をしていただけたことが非常に助かりました。
ジョブフローを標準的なテンプレートとして作成いただいたことで、個別案件が来た際にも、そのテンプレートをベースにカスタマイズできています。

自動化に精通されているからこそ分かる「オペレーションの要所」や「つまずきやすいポイント」を踏まえ、将来的な拡張も見据えた基盤を構築いただけた点にとても価値を感じています。

酒井氏：仕組みとして、初心者でも理解しやすい構成になっていた点も助かったポイントでした。

岡本氏：また自動化の実現にとどまらず、私たちが自走できるレベルまで踏み込んでレクチャーしていただけた点も印象的でした。

－フィックスポイントのエンジニアに対しての印象をお聞かせください。

岡本氏：まず、自動化プロジェクト全体に対する企画総括的なアドバイスをいただきました。
本当にプログラミングによく精通されていて、具体的な実装の中身までアドバイスいただき、当社要件を踏まえた具体的な技術的助言をいただきました。

酒井氏：フィックスポイントのエンジニアの方はレスポンスが非常に速かったので、そこも助かるポイントでした。

－スキル面の課題はありましたか。

岡本氏：当初、Pythonに慣れたメンバーは多くありませんでした。
ただ、実装に踏み込むほど「なぜこの判断をするのか」「どの条件で分岐するのか」といった”今の業務の深い部分”まで理解し直さないと、
手順をプログラムとして表現できないと痛感しました。
そこで、まずは運用手順を徹底的に分解し、“判断の根拠”まで言語化するところから進めました。

酒井氏：逆にそこまで理解できると、これまで見落としていた改善点が見つかり、効率化や改善提案にもつながっていきました。

岡本氏：フィックスポイントさんの支援により、実案件を教材にした段階的な習得を進められました。

• コードレビュー／ベストプラクティスの提示
• Kompira連携の具体例提示
• 現場シナリオに即した実装演習

このサイクルでスキルが着実に根づき、「自動化フローを自分たちで設計・実装できる自走体制」が確立できました。
これは単なる効率化を超え、組織の資産になっています。

酒井氏：プログラムは最初からうまく動くわけではなく、途中で止まって原因を追うなどデバッグが必要になることも多いです。
それでも、試行錯誤して“最初に動いた瞬間”は本当に感動しました。「自分たちの手で運用を変えられる」と実感できた出来事でした。

－Kompiraトレーニングコースの内容はいかがでしたか。

岡本氏：まず、プログラミングの基礎理解に加え、さらに一歩踏み込んでPythonについて最低限押さえておくべきポイントをレクチャーいただきました。単に教材に沿って学ぶのではなく、実装に直結する具体的な知識やスキルを身につけられる内容だったため、コーディングルールなど標準的なものが十分に整っていなかった当社にとっては非常に助かる内容でした。

また、社内でスキルアップの仕組みを整備し、レベルごとに必要なスキルの可視化と自己評価による達成度の測定を行っています。
こうした体制づくりについてもアドバイスをいただき、非常に参考になりました。

－導入効果について教えてください。

岡本氏：まず、「監視アラート → 切り分け → 自動復旧 → 結果通知」のフローを自動化したことで、夜間・休日の対応負荷の軽減につながりました。
いまでは、人の手を介さない運用も一部サービスで実現しています。結果として、現場は自動化を土台に“自走”で改善サイクルを回せる段階に到達しました。注目すべき変化としては、「サービス開発段階から自動化前提で相談が来る」ようになったことです。

以前は、サービス完成後に手運用前提のマニュアルを受け取り、現場が運用しやすくなるよう作り替える流れでした。いまは「効率的かつ高品質な運用になる設計」を初期段階から議論できています。
運用部門が“後工程”から“価値共創パートナー”へと変化していく転機となりました。いまでは、保守運用マニュアルに記載されたことを遂行するだけでなく、サービスの付加価値を高める提案まで踏み込めるようになっています。

－お二人が本プロジェクトでの苦労点と楽しかった点を率直にお聞かせください。

岡本氏：当初は、これまで手順書やドキュメントをもとに人が判断して行っていた業務を本当に自動化できるのかと、正直懐疑的な部分もありました。
ただ、御社の三角社長がおっしゃっていたように、やり方や考え方を一度身につけてしまえば、自分たちでも自動化や効率化をどんどん進められるようになっているなと感じています。
実際に取り組んでみると「こうすればできる」という手応えが得られ、自動化を前に進めていく楽しさも実感できました。

酒井氏：慣れるまでは苦労しましたが、一度理解が進むと、自動化の拡張が非常に楽しく感じられるようになりました。
実際に自分たちが作ったものが動き、目に見えて効果が出ていると成功体験が積み重なり、「もっとやってみたい」という意欲につながっています。

－今後の展望をお聞かせください。

岡本氏：運用監視の自動化を自走できる準備は整いました。今後も自動化対象のサービス／案件を拡大していきます。
新規サービスの運用設計は、可能な限り「自動化前提」で進めたい。さらに、関連イベント間の相関分析／障害時の波及影響の推定など、これまで属人的に対応してきた“判断系”の自動化にも挑戦します。

あわせて、個別最適に留まらずシステム連携を積極的に進め、自動化の適用範囲を拡大していきたいと考えています。
自動化は終着点ではなく、より高品質な運用を継続的に提供し続けるための基盤だと捉えています。

MC-SOCが推進する運用自動化は、単なる効率化にとどまらず、組織の役割と提供価値を進化させる取り組みだ。
外部の知見も広く取り入れながら、より良い運用のかたちを追求していく。

手作業から技術へ。属人化から標準化へ。後工程から価値共創へ。
運用の世界は、いままさに変革期を迎えている。
MC-SOCの挑戦は、その未来を形づくる確かな一歩となった。

主な事業内容：ビジネスユーザーに対する情報通信システムの提案、構築、サポート等業務
設立：2013年10月1日
URL：https://www.nttbizsol.jp/