ソフトウェアエンジニアがシステムNW冗長化を実現するまで

はじめに

この記事は BBSakura Networksアドベントカレンダー2025 の9日目の記事です。

本記事は、今までソフトウェアエンジニアとして、システム開発を主に担当してきた私が、オンプレミスサーバのNW冗長化を行った時の実体験を紹介します！

自己紹介

はじめまして、BBSakura Networks株式会社の姜（カン）です。

2023年4月にBBIX株式会社に中途入社し、BBSakura Networksに兼務で勤めています。 普段の業務ではBBIXのカスタマーポータルと、共通認証部分の開発、BBIX HPのサーバ管理を担当しています。

BBIX、BBSakuraに中途入社するまでは、前職としてWEBアプリケーション開発をAWS等既存のクラウドサービスを利用して、システム開発を行っていました。 そのため、オンプレミスサーバの運用とVMのNWに関する知識はほとんど無い状態でした。

システムのNW冗長化を実現するまでの流れ

そもそも、冗長化とは

基礎的な知識かもしれませんが、各役割（WEBサーバ、APPサーバ、DBサーバ等）ごとに1台の構成だと、VM故障、アプリの停止等なにか障害が起きた際にシステムの継続利用ができません。それを防ぎ、システムの耐久性を向上させるため、予備の機器や機能などをあらかじめ多重に組み込んでおいて可用性と信頼性を高めるための重要な設計のことです。

なぜソフトウェアエンジニアがNW冗長化に挑むことになったか

ネットワークの会社であることもあり、システム開発メンバーとしても、単純にアプリケーションの開発補修だけではなく、そのアプリケーションとDBが動いているVMの運用全般を担当することになっています。

既存NWの問題点

既存のシステム構成でも一般的なオンプレミスネットワーク内のNW冗長化を行っていましたが、全てのサーバが同じネットワーク内である場合、ネットワーク網の障害時にシステムが利用できないことから、別のネットワーク網との冗長化を計画することになりました。

一般的なシステムNW構成図

今回のNW冗長化構成の変更案

さくらのクラウド上にサーバを増設してインターネット経由でのNW冗長化を実現することに決めました。 これによって、BBIXのネットワーク網に障害が発生しても、さくらのクラウドにあるバックアップサーバでシステムが継続利用できるようになります。

NW冗長化対応後イメージ

工夫した部分

通信の方法

異なるネットワーク間の通信を連携させるためには一般的にインターネット経由でのGlobal IP解放でも良いですが、セキュリティ的にリスクがあるため、今回の冗長化対応としてはVPNを構築しての通信にすることにしました。 そこで採用したのが WireGuardです。その理由としては以下が挙げられます。

• 「速い！」: カーネル内部で動作し、他のプロトコル（IPsec/OpenVPNなど）と比較してオーバーヘッドが極めて少ないため、体感できるほどの通信速度の向上が期待できる。
• 「安全！」: 採用している暗号技術が最新かつ強固であり、セキュリティを専門としないユーザーでも安全性が担保されていること。
• 「簡単！」: 設定ファイルが非常に短く、数行でセットアップが完了するため、従来のプロトコルよりも大幅に容易。

データベースのデータ同期の方法

さくらのクラウド側とのデータ同期のため、オンプレミス側のネットワークにMySQL Router（クライアントからのDB接続を仲介・ルーティングするミドルウェア）のVMを増設し、構築したVPN経由でレプリケーションを張ることにしました。

また、データの同期整合性を確保するため、DBの構成を大きく変更しました。

• マルチプライマリーからシングルプライマリーへ： 以前の構成では書き込み競合（コンフリクト）のリスクがあったため、MySQL InnoDB Clusterを構築し、オンプレミス側をシングルプライマリー構成に一本化しました。

• レプリケーション：オンプレミスのPrimary DBサーバと、さくらのクラウド側のDBサーバ間に非同期レプリケーションを構築。これにより、アプリケーションは常にオンプレミスのPrimaryを参照し、データはさくらのクラウド側へ流れ続ける状態を実現しました。

NW障害復旧時のデータ同期の方法

BBIX網でNW障害が発生し、さくらのクラウド側へ切り替わった（フェールオーバー）場合、さくらのクラウド側のDBが一時的にMasterとなり最新データが書き込まれます。しかし、NW復旧時にそのままオンプレミス側に戻すと、オンプレミス側のDBが最新データを持っていない（さくら側がMasterになっているため）という問題がありました。

BBIX網でNW障害時にが発生した際にはさくらのクラウド内でシステムが完結して問題ありませんが、復旧時にオンプレミス側のDBサーバがさくらのクラウド側の最新データの情報を取得していないことがわかりました。（障害時にさくら側にフェールオーバーしてDBのMasterになってるため） そのためオンプレミスのAPPサーバ内部に通信の障害&復旧を監視する仕組みを導入し、NW障害が発生した際にオンプレミス側のシステムからさくら側にあるDBサーバを参照するように向き先自動変更のツールを導入しました。

NW冗長化を実現してからのふりかえり

システムは開発フェーズも重要ですが、運用フェーズ、特に障害時の挙動こそがサービスの継続性を支えると痛感しました。今回の経験から、特に以下の2点を強く意識するようになりました。

• 自動復旧の追求: 障害発生時、人手を介する手順を極力減らし、復旧までのスピードを意識した自動化の重要性。

• IaaSの裏側を知る: 普段、AWSやGCPといったクラウドサービスで「当たり前」に提供されているロードバランサやマネージドDBの自動フェールオーバー機能が、裏側でどのような仕組み（監視、レプリケーション、Master切り替えなど）で動いているのかを、オンプレミス環境で自ら構築することで深く理解することができました。

これからも、お客様が支障なく継続利用できるような「止めないシステム」の仕組みを追求し、この貴重な経験を活かして開発・運用に取り組んでいきたいです。

おわり

ここまで読んでいただきありがとうございます。

初のBBSakura Networksアドベントカレンダー投稿で、読み返すと未熟なところもありますが、自分の経験を共有しつつ、改めて整理したことも良い経験になりました。 こういった互いの経験や情報、さまざまな場面を共有する場に積極的に参加していきたいと思います！ これからもBBIX、BBSakuraの一員として社会のインフラを支えていくエンジニアとして成長していきます。よろしくお願いします！

エンジニア初心者がOCX-Router(v1)の仕様に関する検証をした話

この記事は BBSakura Networksアドベントカレンダー2025 の8日目の記事です

はじめに

こんにちは！営業の技術支援や個別案件のPMOなどをやっている青木です。BBIXではクラウドSE課というところにいます。

本記事では、エンジニア初心者である私が行ったOCX-Router(v1)の仕様に関する検証について、ここで得た知識や経験を紹介します。 この検証のおかげで、NWエンジニアのスタートラインにも立てていなかった自分が、スタートラインから一歩出るくらいのところまでいけたと思っています。 当時の私にとってはかなり難易度が高く感じましたが、エンジニアの経験値という意味でとても充実していました。

この検証は3ヶ月くらいやっていたので（もちろんずっとというわけではないですが）、いろいろなことを試していましたが、今回は掻い摘んで簡単にまとめています。

また、検証内容の詳細は記載していません。この検証で得られた知識や、新たな視点にフォーカスして書いていきます。

なお、本検証はベテランのNWエンジニアの方だったらおそらく2~3日で片付けられる検証内容だと思います。 「初心者がこの検証でエンジニアとしてのスタートを切ったんだー、へぇー」くらいの軽いノリで見ていただけると幸いです。

検証について

BFDとGraceful Restart

本検証で大きく関わってくるのが、BFDとGraceful Restartという2つのプロトコルです。それぞれのプロトコルはネットワークの可用性向上やネイバー関係の維持を目指すという意味では似ていますが、相反する効果を持ちます。検証でも大きく関わっていたので、以下で簡単に説明します。

※2025年12月8日の情報です。

BFD

データプレーンの通信経路に障害が発生していないかを、非常に高速 （ミリ秒単位）に検出するためのプロトコルです。 ルーター間でBFD専用のパケットを送り合い、それが途絶えることで「相手との通信経路に問題がある」と判断します。

OCX-Router(v1)ではRouter InterfaceのBGP Paramaterで設定でき、クラウド側も、本検証においては全ての場合でBFDが有効になっていました。

Graceful Restart(以降GR)

ルーターのコントロールプレーン（ルーティングプロセスのソフトウェアなど）が再起動する際に、通信の転送（フォワーディング）を止めずに処理を継続させるための仕組みです。 再起動中、隣接ルーターに「少し待ってほしい」と伝え、その間は既存の経路情報を使って通信を続けてもらいます。

GRが働く際は、役割によって、再起動するためにGRのオファーをするルーターと、再起動中ルートを保持して待つヘルパーモードのルーターに分けられますが、ヘルパーモードでしか働けない（helper mode onlyの）ルーターもあります。

OCX-Router(v1)はヘルパーモードでしか働けないルーターであることがCLI上やパケットキャプチャから確認できており、クラウド側ではGoogle CloudのCloud RouterのみGRのオファー機能が設定されていることが、Google Cloudの公式のドキュメントより確認できています。このGoogle Cloudの仕様が、本検証に大きく関わっていました。

このようにBFDとGRには、「即座に切り替える」か「ルートを保持して待つか」の点で、相反する効果を持っています。

検証の構成と経験

本検証の構成はこちらになります。

本検証の構成図

本検証では、OCX-Router(v1)を自由に触れるような環境で用意する必要があったため、構成は商用環境と検証用環境を跨ぐようになっていました。この構成上、商用のVCIと検証用のRouter Connectionを繋げる必要があり、この際に通常ポータルでVC作成→アタッチでできる設定を手動で行う必要がありました。

この検証をするまでの私は、VC作成やアタッチの際に、システム・技術的に何が行われているのかは全く知りませんでした。

「ポータルでポチポチ操作したら何かしらの魔法がかかって繋がるんだ！」

本当にこのレベルの理解です。

そのため、まずは社内の技術に関する資料をひたすら読み込みました。 ここで、VC以外の他リソースも含め、システム上でどのような設定が投入されているかを初めて知ることになります。

その後は、実際に手を動かすフェーズです。

CLIでの設定投入の経験値が乏しかったこともあり、設定しても簡単にはPingが通らなかったり、VCの手動設定の部分で資料を読み込んでいても理解できていないところがあったり、一つ一つの工程で課題が出てくるような状況でした。

しかし、ルーティングテーブルやARPテーブルを見ながら切り分けを行い、トライ＆エラーを繰り返しながらラボの機器に設定を投入しました。その結果、今まで理解できていなかったSWの設定や、ネットワークにおける存在意義など、挙げ始めたらキリがないほど多くの仕組みを学ぶことができました。

副産物

検証の構成や機器への設定の話に焦点を絞って書いてきましたが、これら以外にもこの検証で初めてやってことを超初歩的なことも含めて羅列していくと、ざっと以下のようになります。

• ラボ環境の把握
• 商用環境のCLI操作
• 実機へのBGP設定
• パケットチャプチャ　　　　　　　　　　etc…

細かいところまで含めようとすると書き切れないですが、この全てがメインテーマになれるくらい貴重な経験でした。

（逆にこの検証をしていなかったらと思うと何も知らなさすぎて怖い...）

まとめ

初めてのブログなのでうまく書けていたかわかりませんが、少しでも伝わっていたら嬉しいです。

さまざまな経験を一度にできる初心者にはもってこいの検証でした。

自分から技術をやりたいと希望を出してやらせていただいているので、これからも頑張っていきます！

新卒3年目、異職種へ飛び込んでみた件について

はじめに

はじめまして。BBSakura Networks株式会社（以下、BBS）の桑原です。

2025年7月より、BBSに所属し、約5ヶ月が経過しました。

それ以前は、2023年4月にソフトバンクへ新卒入社後、BBSの親会社であるBBIX株式会社（以下、BBIX）へ出向し、Internet Exchange（IX）事業におけるSEとして約2年間従事しておりました。 その後、縁あって社内のOA・情報セキュリティを管轄する部署に異動しました。

本記事では、2年のSE経験から異職種への異動後、約5ヶ月間での立ち上がりと関わった業務、そこで得た業務的な気づきについて共有します。

異動前のSE経験

私が所属していたSE部ではIXを導入前、導入後のお客様へ大凡以下の業務を行なっていました。

• お客様のより良いNW環境構築のためのNW構成提案

• 新規AS、IPアドレス取得の支援

• BGPルータのマネージドサービス提案、設計、構築、運用、設定変更

• お客様へPeering先の提案と支援

約2年の間、NW知識、BGPを使ったインターネット世界の仕組み、お客様への提案経験に留まらず、NWの構築運用など、SEとして幅広く経験をさせていただきました。

NWの会社に所属する上で基礎となる「インターネット世界」の勉強させていただき、この経験を若いうちに積むことができたことは非常にラッキーでした。

異動後のOA・情報セキュリティ業務

私が現在所属しているOA・情報セキュリティの部署では、社内の社員へ対して大凡以下の業務を行っています。

• SaaS製品導入時、自社開発時のセキュリティチェック

• 全社システムのログ監視

• 全社システムのアカウント管理、運用

• 社内規程、ポリシーの更新対応

• 入社退社時のOA端末の対応

• セキュリティ製品の比較検討、全社導入後の運用建て付け

細かい業務が多く書ききれませんが、SEとしてお客様へ「提案する立場」から一転、「社内を管理する立場」へ変化しました。

異動当初は前職と比較すると、全社システムアカウントの棚卸し業務などの定常的な業務が多く、そのスケジュール、ボリューム感に慣れることや、 OA/情報セキュリティに関しては全くの新しい分野でしたので、そのギャップに適応することに時間がかかりました。

しかし、前職では経験できない、社内の全社サービス管理・フロー、サービスリリース・システム開発時に必要なセキュリティ要項、社内規程・ポリシーの修正などなど、日々の学びや取り扱う業務の責任感も（いい意味で）重く、毎日新鮮な気持ちで働いています。

何より新鮮なのは提案を"受ける側"へ回ったことです。

定型的な資料ではなく、お客さんに合わせた内容に資料を工夫するなど手間を加えるだけで、信頼関係の構築に繋がるなと実感しましたし、 運用する立場としては「何を具体的にどうすれば良いかを端的に分かりやすく」伝えてくれる資料だと助かるな〜など、 運用する側の視座を獲得することができました。（と同時に、SE時代お客様の反応が薄い、内容が入っていなさそうだなぁとなっていた事態は、私にも問題があったことも反省）

まとめ

長々と書き連ねましたが、まとめに入ります。

• どんな経験も異動先で活かすことができる

• マンネリから脱却し、新鮮な気持ちで働ける

• 社内管理する側の視座の獲得

私は新卒3年目での異動だったので当初は不安でしたが、若いうちに様々な経験を積み、どの分野で専門性を高めたいかなど、 後の人生の選択肢を広げる意味でも良い機会だなぁと実感した、そんな話でした。

新しいことを経験する前はマイナスなイメージや不安な気持ちにもなると思いますが、心機一転、 BBSでは手を上げてチャレンジできる環境なので、興味があれば何事も経験と思い挑戦してみることはいかがでしょうか。

そんな魅力が詰まった組織です。

SS7（Signaling System No.7）を学んでみた

こちらはBBSakura Networksアドベントカレンダー2025 6日目の記事です。

こんにちは。BBSakura Networksでソフトウェアエンジニアをやっている楽野です。本記事では、2G / 3G 等の電話網を支えてきた「SS7（Signaling System No.7）」について基本から調べた内容を、自分なりに整理して紹介しています。

SS7 概要

・ SS7 とはなにか？

SS7 は、Common Channel Signaling System No.7 とも呼ばれる共通線信号方式の一種で、電話網（PSTN / 2G / 3G）で使われるシグナリングプロトコル体系です。 音声通話やSMSの接続制御、番号案内、加入者位置情報の更新、課金などの多くの機能が SS7 によって動いています。

・ 共通線信号方式と SS7

アナログ電話時代ではチャネル関連方式（Channel Associated Signaling）と呼ばれる方式が用いられていました。この方式では音声を流す通話用の回線上に通話制御の信号（発信・着信・切断など）も一緒に流す仕組みになっており、

• 回線がふさがりやすい
• 制御情報を柔軟に扱えない
• 高度なサービス（転送、ローミング、SMS など）が実現しにくい

と言った弱点がありました。そこで通話とは別の専用データ経路（シグナリングリンク）を設けて、音声とは独立して制御信号だけを集中管理する方式が考案されました。これが共通線信号方式となります。この方式を元に制御信号の構造・ルーティング・サービス機能までを包括的に標準化したのが SS7 となります。

SS7 の全体像：OSI 風の多層アーキテクチャ

SS7 は OSI 参照モデルに近い階層構造を持ちます。

SS7の機能構成モデル

共通のメッセージ転送部（MTP: Message Transfer Part）とアプリケーション対応の ISDNユーザ部（ISUP）等のユーザ部から構成されています。

・ MTP（Message Transfer Part）

SS7 の伝送層にあたる部分です。ユーザ部から渡された信号メッセージをSS7網経由で所要の宛先（信号局）へ伝送する役割を持ちます。 MTPは Level1、Level2、Level3 の3つの機能レベルに分かれています。

MTP Level1（信号データリンク部）

Level1 では伝送路条件を合わせるため、信号データリンクの電気信号・物理回線、機械的特性などを規定しています。信号データリンクは双方向の信号伝送路で同一速度の2つのデータチャネルで構成されています。

MTP Level2（信号リンク機能部）

Level2 は相手信号局との間の信号データリンク上で誤りのない信号メッセージの転送を行う役割を担っています。それぞれの信号データリンク上での信号ユニットの送受信、フロー制御、誤り検出や信号リンク監視などの機能を持ちます。

MTP Level3（信号網機能部）

Level3 はSS7ネットワークにおける「ルーティング」と「ネットワーク管理」を担当する層です。OSIモデルでいうと「ネットワーク層（L3）」に相当します。 以下の3つの主要な役割を持ちます。

1. ルーティング

MTP3 は SS7 メッセージの宛先である Point Code（交換局番号） を見て、どの経路に流すかを決めます。

• どの STP（Signal Transfer Point）へ送るか
• どのリンクセットを使うか
• リンクが落ちたらどこに迂回するか

といった経路制御を担っています。

2. ネットワーク管理

リンクや交換局の状態を監視し、問題が起きたら他の経路へ切り替えるなどの機能です。 MTP3 のネットワーク管理には以下の機能が含まれます。

• リンクセットの状態監視（SLM：Signaling Link Management）
  • 例： リンクが落ちたとき通知を全装置に広報
• 経路管理（SRM：Signal Route Management）
  • 例： 迂回ルートが必要になった場合、経路を切り替える
• トラフィック制御（STM：Signaling Traffic Management）
  • 例： 輻輳が発生した場合に低優先度メッセージを抑制

といった動作を自動で行います。

3. メッセージの優先順位制御

MTP3 ではメッセージに「優先度」が付いており、高優先度のメッセージは輻輳時でも優先的に流されます。

例：

• MTP 管理メッセージ（最優先）
• MAP/TCAP（中程度）
• 大量のSMS 関連メッセージ（低優先度）

この仕組みによって、ネットワークの混雑時でも重要な制御が止まらないように設計されています。

・ SCCP（Signalling Connection Control Part）

SCCP はユーザ部（ISUP・MAP・INAP などのアプリケーション層）に「ネットワーク機能」を提供するレイヤで、MTP3 より高度なアドレス機能や接続管理を追加する層です。 メッセージ転送部とユーザ部の中間層に位置付けられています。

主に次の機能を提供します。

• Global Title（GT：電話番号のような論理アドレス）
• ルーティング制御
• トランザクション型通信（コネクションレス／コネクション型）

この SCCP の上に、次の MAP が乗ります。

・ MAP（Mobile Application Part）

携帯通信に特化したアプリケーション層が MAP です。 HLR / VLR / AUC / SMSC などの信号が MAP によって流れます。

以下は MAP メッセージの例です。

• UpdateLocation（位置登録）
• SendAuthenticationInfo（認証ベクトル）
• InsertSubscriberData（加入者データ更新）
• ProvideSubscriberInfo（端末情報取得）
• SendRoutingInfoForSM（SMS ルーティング）

MAP は 3GPP 29.002 に相当します。

・ TCAP（Transaction Capabilities Application Part）

SS7 のアプリケーション層でトランザクション（要求と応答のやり取り）を扱うためのプロトコル層です。 MAP などの上位アプリケーションが動くための土台として使われています。

具体的には

• HLR に加入者の位置情報を問い合わせる
• 認証ベクトルを取得する
• SMS 配送のための宛先を問い合わせる
• 番号案内や課金情報を取得する

といった処理を独立したトランザクションとして開始・継続・終了させる役目があります。

・ ISUP / TUP（音声呼制御）

ISUP（ISDN User Part） は「音声通話の開始・接続・切断」を制御するためのプロトコルで、いわゆる 回線交換（CS）通話のシグナリングを担います。 音声通話の呼設定を行うプロトコルです。

以下は ISUP のメッセージ例です。

• IAM：通話開始
• ACM/ANM：着信通知・通話確立
• REL/RLC：切断

固定電話・2G/3G のCS ドメインで利用されます。

TUP（Telephone User Part）は ISUP 以前に使用されていた呼制御プロトコルです。

SS7 のネットワーク構成

次にネットワークの構成についてみていきます。 SS7 ネットワークは大きく分けて、信号局と信号リンクから構成されます。

信号局

SS7 の処理機能を持つノードを信号局と呼びます。信号局の例としては、交換機・ネットワークサービス制御局・信号局などがあり、各信号局にはそれぞれを一意に識別できる信号局コード（Point Code）が付与されています。 信号局は大きく以下の3種類に分類されます。

1. SSP（Service Switching Point）
2. STP（Signal Transfer Point）
3. SCP（Service Control Point）

・ SSP（Service Switching Point）

交換機（スイッチ）に相当する信号局です。ISUPを利用して音声呼の制御、MAP を利用して HLR への問い合わせ（位置更新、認証）などを行います。

携帯電話網では

• MSC（Mobile Switching Center）
• GMSC（Gateway MSC）

に相当します。

・ STP（Signal Transfer Point）

SS7 のルータ（中継交換機）に相当する信号局です。信号を運ぶことに特化したノードで、STP 自体は呼制御や加入者管理などの機能は持ちません。

以下の役割を担います。

• MTP3 によるメッセージのルーティング
• SCCP の Global Title Translation（GTT）
• 輻輳制御、障害時の迂回
• 事業者境界でのフィルタリング（セキュリティ）

・ SCP（Service Control Point）

サービスロジックやデータベースを保持する信号局です。SCP に分類される装置は業務によって複数あり、携帯電話網では以下が相当します。 またこれらのノードはSTPを介して相互接続されます。

• HLR（Home Location Register）
• VLR（Visitor Location Register）
• AUC（Authentication Center）
• SMSC（SMS Center）
• EIR（端末機器IDデータベース）

各SPの役割関係

信号リンク

信号局を相互に接続する信号回線（データリンク）を信号リンクと呼び、複数のリンクタイプ（A・B・C・D・E・F）が存在します。

• Aリンク（Access Link）
  • SSP/SCP と STP をつなぐアクセス回線
  • 端末が STP に参加するための入口リンク
• Bリンク（Bridge Link）
  • STP と STP をつなぐ中継回線
  • SS7 網のバックボーンに相当
• Cリンク（Cross Link）
  • STP ペア同士をつなぐ冗長リンク
• Dリンク（Diagonal Link）
  • 異なる STP ペアを斜めに接続するリンク
  • 障害時の迂回経路を拡充し、ネットワークの信頼性を高める
• E/Fリンク
  • 事業者間接続（国際接続など）、他社 STP との相互接続

回線方式

SS7 の物理層（MTP1）は、回線として長らくE1/T1を使っていました。 E1/T1 はデジタル信号伝送のために使われるPDH（Plesiochronous Digital Hierarchy）と呼ばれる時分割多重での回線方式です。

• T1：北米・日本で採用（1.544 Mbps）
• E1：欧州・国際規格で採用（2.048 Mbps）

SS7 の信号（シグナリングリンク）は E1 / T1 のうち 1 つの 64kbps チャネルを専有します。

SS7 の IP 化

・ SIGTRAN の登場

当初SS7は回線としてT1/E1を利用していましたが、回線交換からパケット交換への転換などに伴い IP ネットワーク上で SS7 信号を扱う必要性が高まりました。

そこでIPネットワーク上で SS7 信号を転送するためのプロトコルとして SIGTRAN （Signaling Transport over IP）が導入されました。

・ SIGTRAN のプロトコル構成：

従来の SS7（TDM）	SIGTRAN（IP 上 SS7）	役割
MAP（TCAP）	そのまま（M3UA/SUA の上で動作）	携帯網の制御
ISUP	IUA	呼制御（ISDN / SS7）
SCCP	SUA（SCCP User Adaptation）	アドレス指定と配送
MTP3（ネットワーク層）	M3UA（MTP3 User Adaptation）	ルーティング/ネットワーク管理
MTP2（リンク層）	SCTP	信頼性のある伝送
MTP1（物理）	IP / Ethernet	物理伝送

MAP/TCAP といった上位層は変わらず、下位層だけが IP ベースに置き換わる構造となっています。

まとめ

今回、3G や SMS の仕組みを調べている中で度々目にして気になっていた SS7 や SIGTRAN というワードを改めてまとめてみました。 直接の業務に結びつかないように見える技術であっても、その成り立ちや背景を知ることで、いま扱っている仕組みへの理解が深まることもあるかと思います。 また、歴史を辿ることで「なぜ今の技術がこのような形になっているのか」を想像できるようになり、日々の設計や議論に新しい視点が得られるヒントになるとよいな、と感じました。

Merry Christmas

Google Cloudとのハイブリッドクラウド構成で固定IP宛の通信をリージョン冗長・負荷分散させる方法

この記事は BBSakura Networks Advent Calendar 2025 の 5 日目の記事です。

こんにちは。BBSakura Networks CTO の日下部（@higebu）です。

今回は、オンプレミスから Google Cloud に接続する際、「固定のIPアドレス宛にパケットを送りたい、かつリージョン冗長と負荷分散も実現したい」 という要件に対し、検証と調査の末にたどり着いた構成について紹介します。

トンネル終端など、「何らかの事情で宛先IPアドレスが固定されている」というシチュエーションが世の中にはあります。

こういったケースで、Google Cloud の仕様上の制約を回避しつつ、どうすれば堅牢な構成を作ることができるのか、失敗談（検討過程）も含めて共有します。

前提となる環境と要件

今回想定する環境は以下のとおりです。

• オンプレミス: 東西 2 拠点
• Google Cloud: asia-northeast1 (東京) / asia-northeast2 (大阪)
• 通信の要件:
  • オンプレミスから Google Cloud 上のサーバーへ通信する。
  • オンプレミス方面からのパケットの宛先は「単一のIPアドレス (VIP)」に固定されている。
  • 例：トンネル通信や、宛先IPがハードコードされた機器からの通信など。
• 可用性・拡張性の要件:
  • 通常時は東京・大阪の両リージョンでトラフィックを分散させたい。
  • リージョン障害時には、IPアドレス設定を変更することなく、自動的にもう一方のリージョンでサービスを継続したい。

内部パススルーネットワークロードバランサを使った構成

最初に検討した構成：内部パススルーネットワークロードバランサをネクストホップにする

Google Cloud でプライベートIPへの高スループットな通信を受ける場合、まず思い浮かぶのが 内部パススルーネットワークロードバランサ (Internal Passthrough Network Load Balancer / L4 ILB) です。

当初、私は以下のような構成を考えました。

1. 東京と大阪の各リージョンに L4 ILB を作成する。
2. カスタム静的ルートを作成し、オンプレから見える「宛先VIP」へのネクストホップとして、各リージョンの L4 ILB を指定する。
3. 同じ宛先IP範囲に対し、優先度を同じにして ECMP (Equal-Cost Multi-Path) で分散させる。

非常にシンプルで、Google Cloud の定石のように見えます。

この構成が使えなかった理由

しかし、検証とドキュメント確認を進めると、この構成には 「リージョン冗長・負荷分散ができない」 という致命的な制約があることがわかりました。

Google Cloud のドキュメント「内部パススルー ネットワーク ロードバランサをネクストホップとして使用する」には、以下の仕様が明記されています。

すべてのバックエンドが異常な場合 内部パススルー ネットワーク ロードバランサのすべてのバックエンドでヘルスチェックに失敗した場合でも、そのロードバランサのネクストホップを使用したルートは引き続き有効です。

つまり、あるリージョンのバックエンドが全滅しても静的ルートは消えません。 そのリージョンに向かったパケットはブラックホール行き（破棄）となり、自動的に別リージョンへフェイルオーバーされないのです。これではリージョン冗長の要件を満たせません。

同じ宛先と優先度の複数のルートがあり、ネクストホップの内部パススルー ネットワーク ロードバランサが異なる場合 Google Cloud は ECMP を使用して 2 つ以上のネクストホップ内部パススルー ネットワーク ロードバランサ間でトラフィックを分散することはありません。代わりに、Google Cloud は決定論的な内部アルゴリズムを使用して、ネクストホップ内部パススルー ネットワーク ロードバランサを 1 つだけ選択します。

こちらは負荷分散に関する制約です。東京の ILB と大阪の ILB を並べても、ECMP でパケットが分散されることはなく、どちらか一方に偏ってしまいます。 これを回避するにはルートごとに一意のネットワークタグが必要になりますが、今回の要件（不特定多数の拠点からの透過的なアクセス）では現実的ではありません。

もう少し詳しく言うと、2つの静的ルートはどちらも有効に見えるのですが、実際にはどちらか1つだけ有効な状態になっており、東西どちらのオンプレからのパケットも、どれか1つのリージョンにしかルーティングされないことになります。

これらの制約により、「L4 ILB をネクストホップにした静的ルート」案は不採用となりました。

結論：NCC と Router Appliance による BGP Anycast 構成

そこでたどり着いたのが、Network Connectivity Center (NCC) を活用し、GCE インスタンスを Router Appliance として扱う構成です。

NCCを使ってBGP Anycastする構成

構成の概要

1. GCE インスタンスをルーターとして構成: 各リージョン（東京・大阪）の GCE インスタンス内で BGP デーモン（FRRouting や GoBGP など）を動作させます。
2. NCC スポークとして登録: これらのインスタンスを NCC の「Router Appliance スポーク」として登録し、Cloud Router と BGP セッションを確立します。
3. BGP Anycast : 東京・大阪のすべてのインスタンスから、オンプレミスが宛先とする「固定IP (VIP)」 を /32 の経路として Cloud Router に広報します。

なぜこれで解決するのか？

この構成には以下のメリットがあり、先ほどの課題をすべて解決できます。

• リージョン障害への耐性: BGP を使用しているため、インスタンスやリージョンに障害が発生して BGP セッションが切れると、自動的にその経路（VIPへのパス）は Cloud Router から削除されます。 これにより、静的ルートの時のように「死んだ経路にパケットが吸い込まれる」ことがなくなり、生きているリージョンへトラフィックが流れます。

• ECMP による負荷分散: Cloud Router は、複数のネクストホップ（この場合は各 GCE インスタンス）から同じプレフィックスを受け取ると、ECMP によってトラフィックを分散します。 これにより、リージョン内のインスタンスへの負荷分散が可能になります。

• スケールアウトが容易: 処理能力が不足した場合は、同じ設定を入れた GCE インスタンスを追加し、同じ VIP を広報させるだけで、自動的に負荷分散の対象に追加されます。

設定例（GoBGP）

例として、GoBGP での設定を載せておきます。

[global.config]
  as = 65001
  router-id = "10.146.0.10"

[[neighbors]]
  [neighbors.config]
    neighbor-address = "10.146.0.100"
    peer-as = 16550
  [[neighbors.afi-safis]]
    [neighbors.afi-safis.config]
      afi-safi-name = "ipv4-unicast"

[[neighbors]]
  [neighbors.config]
    neighbor-address = "10.146.0.101"
    peer-as = 16550
  [[neighbors.afi-safis]]
    [neighbors.afi-safis.config]
      afi-safi-name = "ipv4-unicast"

経路広報については systemd を使っている場合、サーバで動かしたいサービスの unit ファイルで、下記のように ExecStartPost / ExecStop で add / del すると良いと思います。サービスの起動・停止と合わせて、経路広報を開始・停止できます。

ExecStartPost=/usr/local/bin/gobgp global rib add -a ipv4 192.0.2.1/32
ExecStop=/usr/local/bin/gobgp global rib del -a ipv4 192.0.2.1/32

オンプレミスとの接続には OCX を利用

さて、この構成を組むためには、オンプレミスと Google Cloud を高品質かつ低遅延につなぐ必要があります。ここで活躍するのが、BBSakura Networks が開発し、BBIXが提供している OCX です。

ここまでの図に特に断りなく登場していましたが、OCX の Cloud Connection 機能を使えば、オンプレミスの拠点から Google Cloud の Interconnect (Partner Interconnect) までを、オンデマンドで簡単に接続できます。

今回の構成では、東西のオンプレ拠点から OCX 経由で Google Cloud に入り、そこから BGP Anycast で最適な（または生きている）リージョンのサーバーに着弾するという、非常に堅牢なネットワークを構築することが可能です。

まとめ

「固定IPアドレス宛に通信したい」という要件に対し、Google Cloud でリージョン冗長と負荷分散を両立させるには、以下の点がポイントでした。

• L4 ILB ネクストホップの静的ルートは使わない: バックエンド全断時の経路残留と、リージョン冗長不可の制約があるため。
• NCC + Router Appliance (BGP Anycast) を採用する: BGP の動的な経路制御により、障害時の自動切り離しとリージョン冗長が実現できる。

「クラウドならロードバランサでなんとかなる」と思わずに、公式ドキュメントの制約事項や考慮事項をよく読むことの大切さを改めて痛感しました。

同じような構成を検討されている方の参考になれば幸いです。

生成AI活用Tips共有会レポート

この記事は BBSakura Networks Advent Calendar 2025 の 4 日目の記事です。

こんにちは、BBSakura Networks の IT システム室に所属している澁谷です。普段は BBIX から委託されているシステムなどの開発・運用をメインに業務しています。

〜みんな、どうやってAIを使ってるの？をざっくばらんに共有しました〜

某日某所にて、社内メンバー 8 名（兼務メンバー及び関係者含む）が集まり、初の「生成 AI 活用共有会」を開催しました。
普段なんとなく使っている AI ツール。
「実際みんなどうやってるの？」という素朴な疑問から生まれたこの会は、気軽な雰囲気ながらも、想像以上に濃い学びの場となりました。

ここでは、当日の内容をまとめてご紹介します。

まずはこの会について

• 参加者は全部で 8 名
• 発表順はその場でルーレットにて決定（意外と盛り上がった）
• LT 形式で 1〜10 分の短い発表
• それぞれのリアルな AI 活用事情をフランクに紹介

みんなの発表まとめ

◆ 管理職 Aさん

ガイド付き学習って思った以上にすごい

A さんが紹介してくれたのは、Gemini の“ガイド付き学習”。
英語やプログラミングだけじゃなく、資格取得の勉強にも便利で、ステップ形式でどんどん進められるのが特徴です。

実際に資格取得につながった例もあったそうで、AI 学習の可能性を感じる内容でした。

なお、Google 側も Guided Learning を教育支援機能として公式に説明しており、「単に答えを返すだけでなく、対話を通じて深い理解を促す」ことを目指しているとしています（Google公式ブログ参照）。

◆ 中堅エンジニア Bさん

資料づくりはGammaとNapkinで驚くほど楽になる

資料作りって、地味に時間がかかりますよね。
そんな中で紹介されたのが Gamma AI と Napkin AI。

• Gamma AI：数行の文章から 10 枚くらいのスライドを自動生成
• Napkin AI：テキストを図で表現してくれる

「Slack で説明するより図の方が早い」という共感の声がたくさんありました。

社内では未利用ですが、今後の活用も期待できます。

◆ 若手エンジニア Cさん

Geminiを“相棒”にして業務を進める新卒のリアル

新卒の C さんは、Gemini を日常業務のほぼすべてに活用しています。

• わからないことはまず Gemini
• 毎朝 9 時に IT ニュースが自動で届く設定
• 定型業務は「Gem」で一発生成

と、AI を頼りながらも自分なりに工夫し、効率的に使っている様子が印象的でした。

ただ本人曰く、

「Geminiなくなったら何もできないって言われて反省しました（笑）」

というエピソードもあり、会場が和やかな空気に。

◆ 若手エンジニア Dさん

Copilotだけに頼らない“賢い学習スタイル”

Copilot は便利ですが、便利すぎて理解が追いつかないことも。
そこで D さんは、

• コードの一部だけを Gemini に聞く
• Markdown で構造化して指示する
• 質問は話題ごとにチャットを分ける

といった工夫をして“理解しながら使う AI 活用”を実践していました。

“AI との付き合い方”を考えるきっかけになる発表でした。

◆ 管理職 Eさん

毎日Geminiの取り組みと、管理業務こそAIが効く

E さんは、社内向け施策として「毎日 Gemini」という取り組みを実施。
毎日 1 つ、Gemini の機能を紹介し続けるという企画で、40 名以上が参加したそうです。

また管理策や内部監査など、ややこしい文書も AI で作成。

「お役所的な文章はAIの方が上手い」

という実感は、参加者全員が納得の様子でした。

◆ 若手エンジニア Fさん

UI開発 × AI活用：55ファイル一気修正のインパクト

UI 開発の現場での AI 活用も紹介されました。

• Google Drive 連携で業務調査が効率化
• UI テキストの多言語対応 → 55 ファイルを AI が自動修正
• デザインの確認もスクショで AI に相談

“実務の AI 活用”がイメージしやすい内容でした。

◆ 中堅エンジニア Gさん

半年でAIツール沼を駆け抜けた実践知

G さんは、Claude・ChatGPT・Gemini・Cursor・Cline といった多くの AI ツールを検証してきた経験者。

特に印象的だったのは、

• Claudeは曖昧な日本語を丁寧に解釈してくれる
• Cursorはプランモード→エージェントモードが安定
• 共通ルールは AGENTS.md に記載し、詳細仕様は docs ディレクトリに記述しておくとAIも人も見れるドキュメントが勝手に積み上げられる

といった“実務に効くノウハウ”でした。

◆ 若手エンジニア Hさん

Cursorのリアル：実務ならではのTips

最後に H さんからは、Cursor を使った開発の実務知見が共有されました。

• コメントアウトで意図を伝えながらタブ補完で段階生成
• エージェントモードは便利だが誤爆もある
• モデルの違い（Composer・1M context・思考モデル）を使い分ける
• コミットはこまめに

Cursor ユーザーには特に参考になる内容でした。

全体で見えてきたこと

この会を通して感じたのは、

AIは“難しい仕事”よりも、“面倒な仕事”にこそ効く

ということ。

• 役所風の文章
• 調査やメモ
• ドキュメントの叩き台
• UI テキスト修正
• ニュース収集

こういう作業ほど AI が強い。

一方で、開発では

• どこまで AI に任せていいのか
• 自分が理解すべき範囲はどこか
• レビューはどう担保するか

といったテーマが多く語られ、次回への議題にもつながりました。

おわりに

今回の共有会では、
「AIの使い方は人それぞれで、どれも正解」
ということを実感しました。

• 便利に使う
• 面倒な作業を任せる
• 精度を上げる
• 新しいスタイルに挑戦する

どれも立派な AI 活用。

このブログもほとんど AI が書いています。 会議メモと文字起こしを読み込ませて「ざっくりまとめて、note っぽい雰囲気で」と伝える＋微修正だけで、ここまで仕上がりました。 あとから文章のテンションまで変えられるのは、本当に便利ですね。

実際、他の作業をしながら会話しつつ進めて、1時間ほどでブログとして形になりました。

一方で、文字起こしの精度には課題もあり、固有名詞の認識違いなども見られました。 具体的には、Napkin AI を使った話が、会話の文脈に合わせて勝手に Lucidchart AI に置き換えられてしまい手動で修正しました。 こちらは今後の改善に期待したいところです。

このレポートが、誰かが“もう一歩 AI を使ってみよう”と思うきっかけになったら嬉しいです。

NWエンジニアがCursor を活用して「手順書自動作成ツール」を作ってみた

はじめに

BBsakura Networks でネットワークエンジニアをしている松下です。

ネットワークエンジニアというと「機器を触る側・運用する側」というイメージが強いと思います。 私自身もこれまで、日々の運用業務の中で発生する“面倒だけれど必要”な作業に対して、効率化を考えることはあっても、ツールを作るという発想はあまりありませんでした。

しかし最近、AI を使った開発支援ツールの進化に触れる中で、「エンジニアの専門領域に関係なく、誰でもツールを作れる時代になっている」という実感を得ることが増えました。

そして今回、「interface 情報から手順書を自動生成するツール」を作成しました。 結果としてできあがったものは非常にシンプルなアプリですが、自分にとって新鮮な体験でした。

本記事では、そのプロトタイプの内容と、作ってみて感じたことを紹介します。

今回作ったツールの概要

今回作成したのは、interface 情報を入力すると Markdown 形式の手順書が自動生成されるツールです。
構成は以下のような形になりました。

• Docker Compose
  • Frontend（React）
  • Backend（Flask）
  • Database（ユーザー情報 & interface 情報）
• JWT 認証（ログイン機能）
• interface 情報入力フォーム
• 生成された Markdown をそのままコピー可能

Cursor へ入力したプロンプト

利用したプロンプトはこちらです。一般的にはPlanモードを駆使して作成するそうですが、今回は手軽さを重視してみました。LLM は Composer 1 を利用しています。

手順書自動作成ツールを作りたい
Docker上のバックエンド、フロントエンド、DBで構成される
認証はjwt認証でやりたい
DBにはログインユーザー情報とinterface情報
Interfaceの追加ボタンを押し情報を入力すると、新しく情報が追加され、mdファイルが生成され、それをコピーすることができる
なるたけ単純な実装にして

interface情報は以下
speed
device
interface名
interface名がport-channelの場合、メンバーinterfaceも

言語も指定せず、プロンプトエンジニアリング的な要素もほとんどありません。 流石にこれだけでうまくいくとは思っていなかったのですが、Cursor にこの指示を投げると、必要な Docker コンテナ構成、API、UI、JWT 認証、Markdown 生成処理まで一通り揃ったコードを生成してくれました。バックエンドはPython、フロントエンドはNode.jsで作成されました。これらの言語はネットでも良く見るのでLLM的にも使いやすいのかもしれません。

実際の動作イメージ

画面上に interface 情報を入力し、「追加」ボタンを押すと以下の動作が行われます。

1. interface 情報が DB に保存される
2. 保存された情報をもとに Backend で Markdown テンプレートを生成
3. UI 上で Markdown が表示され、ワンクリックでコピーできる

lagを組むかどうかで場合分けも可能で、汎用性のあるものになっています。

生成される Markdown の例

以下は生成される Markdown の一部です。

---

Interface設定

channel-group 1 mode active
exit
interface Port-channel1
description port-channel1 - Port Channel
no shutdown

メンバーInterface設定

ethernet1の設定

interface ethernet1
description Port-channel1 member 1
channel-group 1 mode active
no shutdown
exit

ethernet2の設定

interface ethernet2
description Port-channel1 member 2
channel-group 1 mode active
no shutdown
exit

---

作ってみて感じたこと

今回、実際にツールを作成してみて感じたポイントをまとめました。

✔ 想像以上に手軽にアプリを作成できる

言語の知識がなく、プロンプトエンジニアリングにも詳しくない状態でも、思っていた以上に簡単に動くアプリを作れたことに驚きでした。
もっと早く触れておくべきだったと感じるし、これは社内でも積極的に活用・浸透させていくべきだと改めて思いました。

✔ AIを活用するにも一定の知識は必要

簡単なアプリならすぐ作れるものの、今後しっかりしたツールに育てていくためのビジョンはあまり明確ではありません。
また、すべてをAI任せにすることはできず、「ここは人間が理解しておくべき」という基礎知識の重要性も強く実感しました。

今後やっていきたいこと

今回作成したのはあくまでプロトタイプですが、今後は以下のような拡張を予定しています。

• テンプレートを編集し、実際の手順書と同じものを作れるようにする
• Docker やGitを使ったデプロイの自動化
• ログ管理やユーザー権限管理の強化
• 社内ツールとして利用できる形へのブラッシュアップ

Cursor を使えば改良も素早く行えるため、業務に本格導入できるレベルを目指していきます。

おわりに

今回作ったツールは本当にシンプルなものですが、自分の業務の中のちょっとした不便を、自分で形にできたのは良い経験でした。

AI を使うことで、普段はアプリ開発に携わらないネットワークエンジニアでも、業務を少し便利にするツールを作ることが意外とできるという感覚を得られたのは大きかったです。

もちろん、生成されたコードを理解したり、必要な部分を調整したりするには一定の知識が必要です。それでも、プロトタイプを作るまでのハードルが大きく下がったことは実感しています。

今後は、今回のツールを少しずつ改善しながら、自分の業務や周りのチームが使いやすくなるような仕組みづくりにも取り組んでいきたいと思います。