日鉄ソリューションズ株式会社

巨大統合基盤のEOSLを乗り越え、サービス事業を加速させる新エンジンへ
~事業継続性と「国産の安心感」が採用の決め手~

日鉄ソリューションズ株式会社

日鉄ソリューションズ株式会社
ITS&E事業本部 ITソーシング事業部 emerald推進部
豊田 洋輔 様(部長)
松尾 尚文 様(プロジェクトリーダー)
中山 泰秀 様(アーキテクト)
西中 隆志郎 様(チームリーダー)

日鉄ソリューションズ株式会社
  1. 日鉄ソリューションズ株式会社
  2. 情報通信業
  3. 日鉄ソリューションズは日本製鉄の情報通信部門を母体に1980年発足。パーパス「ともに未来を考え 社会の新たな可能性を テクノロジーと情熱で切り拓く」のもと、デジタルの力で社会の未来を描き、実現するべく、深い業務知見と確かな技術力の総合力によって、お客様へ最適なITソリューションをご提供しています。システムインテグレーションをはじめ、クラウドやAIなどの先進技術を活用しながら、製造、金融、流通、公共など多様な業界のお客様のビジネス成長をITでご支援します。

導入背景更なる運用の高度化を見据え、一度は見送った製品を再検討

まずはじめに、貴社サービス「emerald(エメラルド)」の自動化基盤として、新たにロボシュタインをご採用いただいた理由と経緯を教えて下さい。

中山:私たちのアウトソーシングサービス「emerald(エメラルド)」では、もともと海外製の統合運用基盤を利用していました。しかし、その製品がEOSL(メーカーのサポート終了)を迎えることになり、システムの移行検討を始めたのが、今回のプロジェクトのきっかけです。

当時、私たちはemeraldのサービス基盤が持っていた「受け取ったデータを加工して処理を実行する」フロー型の機能を代替できる外部製品を探していました。その過程でロボシュタインを見つけ、「面白そうだ」と社内で話題になったのが最初の出会いです。しかし、2020年当時のロボシュタインはサービスとして発展途上で、当社が求めた技術要件に対していくつかの課題があったことから一度は採用を見送り、他製品の検証を優先しました。

豊田:少し背景を補足しますと、私たちは2015年に「emerald」を立ち上げて以来、「運用の高度化」を追求してきました。その中核を担っていたのが、emeraldのサービス基盤としてアラート集約からチケット管理までを一台でこなしていた当時の統合運用基盤です。それがEOSLを迎えることになったのは、私たちのサービスにとって大きな転換点でした。

私たちが日々向き合う「システム運用」はお客様の事業継続に直結する非常に重要な業務であり、市場の変化に合わせて、お客様のニーズも当然多様化していきます。当時、サービス提供開始から5年が経過するemeraldもそうした変化に柔軟に対応し、より細やかにお客様のニーズを汲み取れるよう進化させていかなくてはならないと思っていました。そうした想いもあり、この節目のタイミングでサービス企画・開発のメンバーが一丸となって検討を進めました。既存の課題解決に向けて徹底的に議論を重ねるなかで、機能ごとに最適なツールを組み合わせ、自ら新しい基盤を構築する方向でまとまっていきました。

中山:その結果、1年以上の議論と検証を繰り返し辿り着いたのは、「ITSM」や「自動化」といった運用の高度化に必要不可欠な機能群ごとに統合基盤を分離し、それぞれを最適なツールで繋ぎ合わせた構成をとるという方針でした。そして改めて候補になりそうな製品を調査したところ、かつて検討したロボシュタインも俎上にあがった際に、さまざまなバージョンアップが加えられ大きく進化していることを知りました。再度のPoCを通じて「これなら技術要件を満たせる」と判断し、最終的に採用に至りました。

日鉄ソリューションズ株式会社

課題「巨大なオールインワンツール」が故の不自由さ

旧サービス基盤の課題はどういった点にあったのでしょうか?

松尾:統合運用プラットフォームという点を評価して採用した旧サービス基盤ですが、長年使い込んでいくにつれて、大きく2つの点が徐々に気になるようになってきました。
1つ目は、システムの構造です。以前の基盤は、マルチテナントでお客様にイベント連携機能などを提供していましたが、その機能全体が単一のシステムに集約されていました。そのため、お客様ごとにリソースを分割したり、インターフェースを分離したりすることが難しく、柔軟性に欠けていました。

2つ目は、運用の自由度の低さです。利用していたのがPaaS(Platform as a Service)だったため、内部の仕組みがブラックボックス化しており、トラブルが発生した際に原因の特定や対処が困難でした。また、当然ながら提供されている機能しか使えないため、「もう少しこうしたい」といった独自の要件に応えるためのカスタマイズができないという制約もありました。今回の刷新では、こうした課題を解決できる点を重視しました。

中山:松尾が申し上げた通り、旧サービス基盤はまさに「巨大なオールインワンツール」でした。お客様ごとにサーバーを分けるといった細かなリソース分割ができず、システム全体が単一の大きなリソースで動いている状態だったため、性能面での負荷分散が非常に難しいという課題がありました。

また、海外製のツールだった点も運用上の課題でした。技術的な問い合わせはすべて英語になり、通常のコミュニケーション以上に、繊細なニュアンスを伝えなければならない場面では非常に苦労しました。サポートの品質も国内の基準とは異なる部分があり、運用していく上での難しさを感じていました。

日鉄ソリューションズ株式会社

導入検証技術・操作性の両面を検証、
新サービス基盤移行に確かな手応え

導入前には、どのような内容を検証しましたか?

中山: PoCでは、3~4ヶ月ほどかけて、複数のSaaSを組み合わせたプラットフォームとして特に重要となるインターフェース設計やデータモデルをテストしました。 具体的には、実際の運用を想定してシステムからアラートを受け取ってITSMツールへ連携する一連のフローをテストしました。アラートの受信方法としてHTTPとメールの両方を試し、メールが受信順に正しく処理されるか等です。また、利用者視点で日々の運用変更をどのように反映できると実用的かといった点も確認しました。

また、短時間に大量のアラートが発生する「アラートバースト」を想定し、それらを一件に集約する処理も試しました。その他、受信したデータがロボシュタイン上でどのように変数として格納されるか、サーバー側で利用する「Robostein Agent」の導入方法なども初期段階で確認しています。

ロボシュタインはオープンソースのNode-REDをベースとしていると伺っていたので、基本的な機能は問題なく使えるだろうという前提でした。そのため、個々のノードを細かくテストするよりも、メール受信のような特に重要な機能に絞って検証を進めました。

実際にツールを触ってみて、以前の基盤との使用感の違いや感想はいかがでしたか?

中山:私自身は旧ツールの自動化部分に深く関わっていなかったため厳密な比較は難しいのですが、ロボシュタインの操作に違和感を覚えることはありませんでした。直感的に使えるローコードツールだと感じましたし、一方でJavaScript等を使えるFunctionノードがあるため、作り込めばかなり高度な処理も実現できるという自由度の高さも魅力でした。

豊田:旧基盤で実現できていたことは、ロボシュタインでもほぼ再現できるという手応えを得られましたね。 加えて、操作性も大きな違いでした。旧基盤のUIは少し専門的で分かりにくい部分がありましたが、ロボシュタインは直感的で、メンバーからも「これなら使いやすい」という声が上がっていました。これなら、より多くのメンバーが自動化の構築に取り組みやすくなるのではないか、という期待も持てました。

選定理由事業モデルにマッチした技術要件、
事業継続性、国産の安心感が採用を後押し

ロボシュタイン採用の決め手は何だったのでしょうか?

豊田:複数の要因を検討しましたが、主に2つの点が採用を後押ししました。

一つ目は、国産ならではの安心感とコミュニケーションの円滑さです。
以前利用していた海外製ツールでは、サービスレベルの違いや、こちらの意図の細かなニュアンスが伝わりにくい場面がありました。日本の商習慣や運用方法について、背景から説明しないと要件を理解してもらうのが難しいこともありましたが、国内企業であるコムスクエア様とは「共通言語」で話せる安心感が大きく、特に運用における円滑な連携が期待できました。

二つ目は、Node-REDベースであることの将来性と事業継続性です。
Node-REDは汎用性が高く、充実したマニュアルを参考に自社で開発を進めやすい利点があります。それに加え、今回の基盤選定では「利用中のサービスが終了する」という事業リスクへの対策が重要なテーマでした。その点、オープンソースベースのロボシュタインであれば、万が一サービスが終了する事態になっても、Node-REDとして開発資産を活かし、事業を継続できる可能性があると考えました。このリスクヘッジができる点は非常に重要でした。

中山: 私からも補足しますと、顧客ごとに実行環境を分離できるアーキテクチャが採用の大きなポイントでした。
私たちのサービスは、お客様から受け取ったデータを加工して次のシステムへ連携する、いわばETLツールのような動きをします。そのため、お客様ごとにインスタンスを完全に分けて、リソースや処理を独立させられることが重要でした。他のツールも検討しましたが、論理的な分割はできても、実行環境レベルで完全に分離できる製品はほとんどありませんでした。この要件を満たしていたのがロボシュタインでした。

日鉄ソリューションズ株式会社

今後の展望更なる自動化推進と
AI活用による次世代の運用サービスを目指す

今後のサービスにおける既存顧客の移行計画や、自動化の取り組みについて教えてください。

豊田:移行計画については、2027年3月末までには、全体の8割のお客様の移行を完了させるスケジュールで進行中です。

現在、そして移行後も当面、自動化の主な適用範囲はアラートの一次処理になります。 当社の運用サービス「emerald」では月間約10万件のアラートを受信しており、その膨大なアラートを「本当に対応が必要なもの」だけに絞り込むためのフィルタリングと集約が、ロボシュタインが担う最も重要な役割です。既存のお客様にご提供している、アラートに応じた自動通知や、既知の事象に対する一次対応(ワークアラウンド)の実行といった自動化は、すべてロボシュタイン環境へ移行していきます。

今後は、アラート対応以外の自動化も検討されているのでしょうか?

豊田:これまではサーバー自体に直接何かを行う「サーバーサイドの自動化」には限定的にしか取り組んでいませんでしたが、今後はこの領域を強化していく方針です。現在、Robostein Agentを活用する構成や、中継サーバーを経由してスクリプトを実行する構成など、私たちのサービスに最適な提供形態をチームで検討し始めたところです。

松尾:具体的な方針としては、ロボシュタインを司令塔である「ハブ」と位置づけ、お客様環境に配備したスクリプトの実行や、ジョブ管理サーバーへのコマンド発行などを指示する形を想定しています。

例えば、アラート受信をトリガーに、対象サーバーのステータス確認やリソース情報、関連ログの収集を自動化します。これにより、運用担当者はサーバーに都度ログインする手間が省け、手元に集約された情報をもとに迅速な状況判断と対応が可能になります。

さらに、そのスクリプトの実行結果(リターンコード)に応じてロボシュタインが次のアクションを判断し、正常ならインシデントを自動クローズ、異常が確認されれば担当者へ電話通知を行う、といった一次切り分けのプロセスも自動化する計画です。将来的には、特定のサービスを再起動させるといった、より踏み込んだ復旧処理まで自動化の範囲を広げていきたいと考えています

今後のサービスの展望についてお聞かせください。

豊田:当社の中核事業であるアウトソーシングサービス「emerald」は、今後も大きく成長させていく計画です。今回導入したロボシュタインは、まさにその「emerald」のコアエンジンに位置づけられています。

現在実現できている自動化は、いわば従来の延長線上にあるものです。しかし、これからの「運用の高度化」を実現するには、AIの活用が不可欠だと考えています。このAI技術をいかに我々の運用サービスに最適化し、お客様に価値を提供していくかが、今後の重要なテーマであり、お客様からも強く期待されている部分です。

そのため、ロボシュタインにもAI関連の機能がさらに強化・統合されていくことに大きく期待しています。
この期待は、2025年8月28日より新たに提供を開始した「emerald SaaS(エメラルド・サース)」でも同様です。emerald SaaSは、従来から当社がお客様のIT運用業務を担う上で利用してきたemeraldでも利用されている運用システムをSaaS版としてお客様に提供します。このサービスを通じて、お客様自身に運用の高度化を実感していただくためにも、AIの活用は鍵となります。当社の成長とロボシュタインの進化は直結していますので、今後の開発にも大いに期待しています。

ありがとうございます。AIを活用した運用高度化というお客様のビジョンと、当社の製品開発の方向性が一致していることを改めて確信いたしました。
弊社で開発を進めているAIフロー生成機能もブラッシュアップを重ねております。 今後も良きパートナーとして、お客様のビジネスの成長に貢献できるプラットフォームへと共に磨きをかけていきたいと考えておりますので、ぜひご期待ください。本日は誠にありがとうございました。

日鉄ソリューションズ株式会社
株式会社CaSy

障害対応の迅速化と費用対効果のバランス。運用自動化の最適解

株式会社つうけんアドバンスシステムズNew!!

年間480時間の工数を「ゼロ」に。アラートメールの複雑な条件分岐対応を完全自動化