榎本、BBSakura 副社長になったってよ

このたび、BBSakura Networks株式会社の代表取締役副社長 兼 COOに就任いたしました榎本です。

前任の代表・佐々木、CMO・山口が築き上げてきた意志と挑戦のマインドを受け継ぎながら、これからのBBSakura Networksは、次の時代に必要とされる価値を自らの手で創り出していきます。

「技術の会社」であるというアイデンティティを大切にしながら、最先端技術とエンジニアの力を最大限に引き出し、確かなビジネスへとつなげていく。会社をさらにスケールさせ、継続的な成長とインパクトを生み出すフェーズに入っていきます。

私自身、これまでに「OCX」というコアサービスの立ち上げを担ってきました。今後はこのOCXをさらに成長させつつ、BizDev(ビジネス開発)の面でも新たな挑戦を仕掛けていきます。従来の枠組みにとらわれず、スピード感と柔軟性を持って新しい価値を創出し、パートナーやお客様から選ばれ続ける存在を目指します。

クラウド、IoT、AIなどの技術が急速に進化し、市場環境が大きく動く今こそ、私たち自身がその変化を先取りし、挑戦的かつ常識を覆すような事業を展開していくべきタイミングです。BBSakura Networksを、マーケットの中心で、最先端を走り続ける存在へと進化させていきたいと考えています。

お客様、パートナーの皆さま、そして社員の皆さんと力を合わせ、面白く、価値のあるサービスを社会に届け、挑戦と進化を止めずに歩んでまいります。

今後とも、BBSakura Networksをよろしくお願いいたします。

代表取締役副社長 兼 COO 榎本

Findy Team+ 導入してからの フロントエンドチームの開発改善について

Findy Team+ 導入してからの フロントエンドチームの開発改善について

1. はじめに

はじめに こんにちは、BBSakura Networks 株式会社(以降 BBSakura) で OCXのフロントエンドを開発しているソンと申します。 BBSakuraのフロントエンド開発では、チームで協力しながら開発を進めています。

その中で以下のような課題を感じており、改善に取り組みました。

  • 開発状況が感覚ベースで語られ、定量的に把握できていない
  • GitHubの運用ルールが統一されてない
  • PR(Pull Request)レビュアーの偏りがあり、レビューが遅れることがある

本記事では、これらの課題を解消するために、 Findy Team+ を導入してチームで開発生産性を向上できた取り組みを共有いたします。


2. Findy Team+ とは?

Findy Team+ は、開発生産性を向上させるためのツールとなります。

  • GitHubでの開発状況(PRの作成、レビュー、マージなど)を可視化
  • チームの改善サイクルを回すためのデータを提供
  • 振り返りやボトルネックの特定に役立つ

これにより、チームの開発体験そのものを見直すきっかけになりました。


3. チーム課題

GitHubの使い方がチーム内でルールが統一されてない状況

メンバーそれぞれ、PRの作成時に「Draft」機能を活用するかどうかが人によって異なっており、使用するメンバーと使用しないメンバーが混在していました。 また、レビュー依頼の方法も統一されておらず、PRのコメント内でメンションを使う人もいれば、Slackで別途依頼する人もいるなど、対応がバラバラな状態でした。

特定メンバーにレビュー依頼が集中し、レビューが遅れる

レビュー依頼が特定のメンバーに偏る傾向があり、その結果としてレビュー対応が遅れるケースも発生していました。 レビューの負担が一部のメンバーに集中することで、対応までに時間がかかってしまったり、チーム全体の開発スピードにも影響が出る場面がありました。

実際に、Findy Team+のメトリクスを確認してみたところ、 レビューまでの平均時間が長かったり、PRの滞留数が多かったりと、数値的にも開発の生産性があまり良くない状態であることを確認できました。

感覚として抱えていた課題が、数値やグラフを通じて明確に確認できたことで、具体的な改善へ取り組むきっかけとなりました。


4. 課題への取り組み

Findy Team+の導入と共に、フロントエンドチームでは以下のような取り組みを行いました。

  • 開発開始からの時間を計測するため、ブランチ作成の初期段階に空コミットが入る仕組みを運用
  • PRのOpenタイミングを明文化(レビュー依頼する段階にルール化)
  • レビュアーは全員が対応できる体制を意識
  • PR作成・レビューのSlack通知で反応速度を向上
  • チーム定例MTGでの定期的な振り返りの時間を確保

5. 導入後、チームの変化

導入から4ヶ月で、以下のような成果が見え始めました。

可視化されたメトリクス

  • サイクルタイム(PRの最初のコミットからマージまでの平均時間):370時間減少
    サイクルタイムのグラフ。2024/12/1 から 2025/4/1 にかけて、時間が約半分に減っている。
  • オープンからアプルーブまでの時間:60%改善
    オープンからアプルーブまでのグラフ。2024/12/1 から 2025/4/1 にかけて、60%改善されている。

チーム内の変化

  • レビューの担当が特定のメンバーに偏ることが減り、チーム全体でバランスよくレビュー対応できるようになりました。
  • 自分のPRへの反応が早まり、フィードバックの質も向上
  • 振り返りを通じて、継続的な改善サイクルが生まれた

6. まとめ

Findy Team+ の導入によって、フロントエンドチームでは「見える化」と「ルールの明確化」を通じて、チーム開発全体のスピードと体験が大きく改善されました。

チーム全体が前向きに開発に取り組めるよう、これからも継続的に働きやすい環境づくりに取り組んでいきます。💪

取締役退任にあたって

BBSakura Networks元取締役の山口です!

すべてのものがつながる社会を技術で支える—— そんな理想を掲げながら、BBSakura Networksという会社がちゃんと「会社」として立ち上がっていくまで、あれこれ手探りでやってきましたがこの6月末をもって取締役を退任させていただくことになりました!

振り返ると、最初は本当に何もなくて。オフィスをどうするか?制度は?もちろん会社の文化も何もない状態から、メンバーと会話を重ねてシェアードバリューや行動指針を作っていったのをよく覚えています。 BBSのロゴはLANケーブルとさくらの意匠が入っているものなのですが、産み出しまではなかなか大変でしたが今思えばすごくいい思い出ですね。

技術的なチャレンジも山のようにありました。私自身が手を動かすということは無かったのですが、メンバーが増えてチームが立ち上がり次第に形になっていくインフラやプロダクトを見るたびに、「ああ、自分たちで作ってるんだな」って実感できて、すごく嬉しかったです。 小さなチームだからこそ、全員がいろんなことに首を突っ込んで、いろんな議論をしてきたと思いますし、改めて「会社って人」だと思わされました。

あらゆる意味でカオスな状態から、ちょっとずつ形になっていく感じ。 それに参加し続ける熱量はきっと、これからのBBSakuraの大きな強みになっていくのではないかと思っています。

今後はBBSの新しい理想を体現している新しい経営チームにバトンタッチさせていただいて、私の取締役としての役目は一区切りとなりますが、BBSakuraへの思いはこれからも変わりません。 これからもっと面白いことを仕掛けてくれるメンバーたちに、僕自身もワクワクしていますし、ちょっと離れたところから応援していけたらと思っています。

私自身はさくらインターネットに戻らせていただいて、海外市場を目指す役割を担わさせていただこうと思っています! おそらく会社設立以上にいろんなことがあるかと思いますので、海外に知見のあるかた、想いのある方ぜひご一緒させていただければと思いますのでよろしくお願いします!

ここまで支えてくださったすべてのみなさん、本当にありがとうございました! 引き続き、BBSakura Networksをよろしくお願いします!

※写真は設立翌年のBBSakura Netoworks本社のビルです。

住友不動産西新宿ビルの前からの写真、さくらの花が満開
BBSakura Networks本社(西新宿)

BBSakura Networks社長交代と、今後の体制について

はじめに

こんにちは。BBSakura Networks元代表取締役社長の佐々木です。 本日6/24付でBBSakura Networksの社長を退任し、後任として川畑が就任し、役員体制を刷新いたしました。2019年の創業以来6年に渡り、皆様と共に歩んでこられたことに深く感謝申し上げます。

今後の役員体制

役職 氏名
代表取締役社長 兼 CEO 川畑 裕行
代表取締役副社長 兼 COO 榎本 恵太
取締役 兼 CTO 日下部 雄也
取締役 兼 CCO 池田 雅弘
取締役 田中 邦裕
取締役 江草 陽太
取締役 佐々木 秀幸
取締役 田邉 重樹
監査役 永山 雄大
監査役 塚田 麻美子

www.bbsakura.net

BBSakura Networksでの思い出

BBSakuraは私が就任して以来、まずは親会社であるさくらインターネットやBBIXで行っていた様々な事業との棲み分け、整理を行い、 さくらのクラウド ショートメッセージサービスOCX など、通信サービスに関わるサービスを生み出してきました。 新規事業としてゼロからはじめたOCXにおいては、現在、全国に約50拠点のアクセスポイントを展開をされており、様々な企業様や自治体・政府機関に利用されるプラットフォームへ成長させることができました。また今月、Interopにおいて OCX Mobile AccessがInterop Tokyo 2025において、Best of Show Award をいただくこともできました。 これもひとえに、お客様、パートナー企業の皆様、そして何よりも情熱を持って日々業務に取り組んでくれた社員の皆さんの多大なるご支援とご尽力のおかげです。心より感謝申し上げます。

また、テックカンパニーとしては、「革新的情報通信技術(Beyond 5G(6G))基金事業」として公募された「令和5年度社会実装・海外展開志向型戦略的プログラム」にて技術力などをもとに認定いただいたことは大きな自信につながりました。

www.nict.go.jp

BBSakuraでは全ての「モノ」がつながる社会を支えるテクノロジーカンパニーを目指して創業し、社会に貢献することを目指してきました。この道のりの中で、多くの困難もありましたが、その度にチーム一丸となって乗り越え、今日に至る会社の基盤を築き上げることができたと自負しております。

後任への期待と会社の未来

後任の川畑は、まだ30代の若手でありながら、OCXの開発責任者を務め、「開発者の顔が見えるクラウドサービス」を目指し、ゼロからプロジェクトを引っ張ってきました。 彼のリーダーシップのもと、BBSakuraを新たなステージへ進めて欲しいと思います。彼の持つ若さと情熱、そして革新的な視点は、今後のBBSakuraの成長に不可欠であると確信しています。

これからのBBSakuraは、AI時代のConnectivityを支える会社として、OCXをベースとしてネットワークやモバイルに関する技術力を駆使し、デジタルツインの到来を牽引し、より一層社会に貢献できる企業へと進化していくことと期待しています。私も親会社の社長として、取締役として、そして一人のファンとして、今後のBBSakuraの発展を温かく見守ってまいります。

最後に

長きにわたり、皆様には大変お世話になりました。この場をお借りして、改めて深く御礼申し上げます。今後とも、変わらぬご支援とご指導を賜りますようお願い申し上げます。

佐々木 秀幸 元BBSakura Networks株式会社 代表取締役社長 兼 CEO

30代の運用エンジニアが開発エンジニアにキャリアチェンジした話

ネットワーク関連のキャリアパスを示すイラスト。詳細は以下

はじめに

こんにちは、BBSakura Networks 株式会社(以降 BBSakura) で OCX 開発グループに所属している松本です。

「30 代で未経験から開発エンジニアになるなんて無理だよね...」

そんな風に思っている方はいませんか?実は私も、つい最近まで同じことを考えていました。

4 月に BBSakura へ入社し、念願だった開発エンジニアとしてバックエンド開発を担当しています。振り返ると、営業→SIer→通信キャリアの運用エンジニアという、一見開発とは無縁のキャリアを歩んできました。

しかし今考えるのは、一見バラバラに見える経験こそが、キャリアチェンジの最大の武器になるということです。

この記事では、ネットワーク運用から開発へのキャリアチェンジという、あまりネット上で見かけない体験談をお話しします。同じような悩みを抱える方、特に運用系から開発への転身を考えている方の参考になれば幸いです。

予想外から始まったキャリアパス

営業時代:技術への憧れが生まれた瞬間

新卒では技術職志望で入社したものの、配属されたのは営業部門でした。正直、最初は「こんなはずじゃなかった」という気持ちでした。

しかし、ネットワーク製品の営業兼プリセールスとして働く中で、運命的な出会いがありました。それが SDN(Software-Defined Networking)という技術です。

「ネットワークをソフトウェアで制御する」

この概念に触れた時の衝撃は今でも忘れられません。営業の私でも簡単にネットワーク構築ができる様子を見て、「技術ってこんなに面白いものなのか」と感動したのです。

この時の経験が、後の「SDN 関連の技術に携わりたい」という想いの原点となりました。

SE時代:理想と現実のギャップ

ネットワーク製品の営業経験を活かして SIer に転職。念願のネットワーク SE になれて技術で仕事ができると思ったのもつかの間、実際の業務はプロジェクトマネジメントが中心でした。

通信キャリアのネットワーク関連プロジェクトに携わりながらも、「もっと技術的なことがしたい」というもどかしさが日に日に強くなっていました。

運用エンジニア時代:現場のリアルに触れる

SIer での通信キャリアプロジェクト経験を活かして、「もっと技術力を上げたい」という理由でソフトバンクに運用エンジニア(テクニカルサポートエンジニア)として転職しました。

通信キャリアネットワークのテクニカルサポートを担当し、お客さま不具合に対するネットワーク調査を行ない、現場のリアルな声に向き合う貴重な経験を積みました。

転機:30代で見つけた「技術の楽しさ」

開発との出会い

転機は、運用業務の効率化へ取り組んだ時に訪れました。

毎日同じような作業の繰り返しに疑問を感じ、「これ、開発で自動化できるんじゃないか?」と思い立ったのです。最初は簡単なスクリプトから始めましたが、自分のコードが動いて業務が効率化され、生産性が向上されることに達成感を得ました。 30 代になって、新たに挑戦したいことが見つかりました。

不安との向き合い方

ただし、30 代での開発エンジニアへの転身には大きな不安もありました。

  • 年齢の壁:「30 代未経験では厳しいのでは?」
  • スキルの差:「新卒から開発をやっている人には追いつけない」
  • 経済的な不安:「転職したら年収が大幅に下がりそう」

これらの不安を乗り越えるために、まずは「今いる場所で力をつける」戦略を選択しました。

開発エンジニアになるための具体的な取り組み

1. 現職での開発経験を積む

  • 業務の自動化を積極的に提案・実装

  • 社内副業制度を活用し、開発部門で実際のサービス開発の経験を積む

2. 体系的な学習

  • 技術書の読書とオンライン講座
  • 個人プロジェクトと社外コミュニティ参加

3. ネットワーク×開発の専門性を構築

既存のネットワーク知識と新しい開発スキルを組み合わせることで、「ネットワーク開発エンジニア」という独自のポジションを目指しました。

BBSakuraでの新たな挑戦

理想的な環境との出会い

取り組みの結果、縁もあり、ソフトバンクから BBIX、そして BBSakura への出向という形で、念願の開発部門に異動できました。

一貫して関わってきた「ネットワーク」の経験を活かしながら開発ができる、まさに理想的なキャリアチェンジとなりました。

そして現在、SDN に該当する OCX の開発に携わることで、新卒時に抱いた「SDN 関連の技術に携わりたい」という想いを実現できています。

入社1か月での成果

BBSakura の「世界を変える Geeks' Playground」というシェアードバリューのもと、スキルアップをサポートしてくれる環境で、入社1か月で次の成果を上げることができました。

  • Cisco Devnet認定資格取得:ネットワークと開発両方のスキルを証明
  • 作業効率化マクロの作成:運用経験を活かした作業の自動化
  • 開発環境の改善:効率化を目的に、ホットリロード機能の追加により、ビルド時間を数分→数秒に短縮

これらは、今までの「一見バラバラな経験」があったからこそ実現できた成果でした。

技術と事業の両輪で考える

BBSakura で特に印象的だったのは、「事業開発集団の一員として技術『だけ』や事業『だけ』を考えない」という価値観です。

私の場合:

  • 営業時代:顧客価値への感覚
  • SE時代:実現性の判断
  • 運用エンジニア時代:持続性の視点

これらの多様な経験が、技術と事業の両面から考える基盤になっています。

OCX というサービスは、私のようなバックグラウンドを持つ者にとって理想的な挑戦の場です。

キャリアチェンジを成功させる3つの方法

私の経験から導き出した、キャリアチェンジを成功させるための方法をお伝えします。

1. 一貫性を見つける

一見バラバラに見える経験でも、共通するテーマを見つけることが重要です。

私の場合、営業・SE・運用という異なる職種でしたが、すべて「ネットワーク」というテーマで一貫していました。

2. 経験を掛け算する

単体では弱い経験でも、組み合わせることで独自の価値を生み出せます。

私の掛け算:

専門知識(ネットワーク) × 営業でのビジネス視点 × SEとしての顧客視点 × 開発スキル = 独自の価値

3. 学び続ける姿勢

年齢に関係なく、新しい技術への好奇心と学習意欲が道を開きます。

最後に

もし「未経験だから」「年齢が」「今さら」という理由でチャレンジを諦めかけている方がいれば、ぜひ再検討をお勧めします。

この記事が、キャリアの気づきに、少しでもお役に立てれば幸いです。

また、BBSakura では現在メンバーを募集しています。私のように、ネットワークと開発の両方に興味がある方、技術と事業の両面から価値創造に挑戦したい方にはぴったりの環境です。

現在はさくらインターネットからの出向のみ募集しています。ご興味のある方は下記リンク先の「さくらインターネットを通した中途採用」ページからご応募ください!

▶︎ 採用情報はこちら

最後までお読みいただき、ありがとうございました。

CCNA合格体験記

はじめに

正直、何番煎じかわかりませんが…… BBSakura Networks の親会社である BBIX では、今年の新卒メンバーがCCNA(Cisco Certified Network Associate)試験の取得に取り組んでいます。 本記事では、私自身の学習経験をもとに、これから受験を検討している方や、同じような立場の方に向けて、使用した教材・勉強方法・試験当日に気づいたことなどをまとめてご紹介します。 少しでも皆さんの参考になれば幸いです。

使用した教材

インプット教材:Udemy CCNA最短合格講座(動画学習サイト)

  • メリット

初学者にも分かりやすい構成で、体系的に学習できる

動画形式のため、業務の合間や通勤時間など、スキマ時間を活用できる

  • デメリット

音声中心の学習スタイルが苦手な方にはやや不向きかもしれません

アウトプット教材①:黒本(徹底攻略 Cisco CCNA 問題集

  • メリット

試験範囲を広く網羅しており、本番形式に近い問題が多数収録されている

詳細な解説により、理解を深めながら学習を進められる

  • デメリット

ボリュームが多く、継続的に取り組むにはある程度の計画とモチベーション管理が必要です

アウトプット教材②:Ping-t(試験対策サイト)

  • メリット

「コマ問」が優れており、シミュレーション問題への対策に最適

基礎知識から応用問題まで幅広く取り扱っており、繰り返し解くことで実践力が身につく

  • デメリット

UI面にやや改善の余地があり、不正解問題の記録が残らない、コマンドの一字一句に厳密な正解を求められる等、使い勝手に注意点があります

※私はPing-tの無料問題はあまり使用しませんでしたが、有料版含め評判は良好です。

勉強法

  1. Udemyでインプット学習
  2. 黒本を一通り解く(途中で挫折しそうに)
  3. 重要そうな分野を中心に復習
  4. Ping-tのコマ問でシミュレーション対策を実施

実際には、黒本の分量の多さに圧倒され、全体を網羅できたとは言い難い状況でした。 私の場合、ステップ1と2に約半年をかけてしまい、逆にステップ3と4には2週間ほどしか時間を割けませんでした。 もう少し計画的にバランスよく取り組めていれば、より確実に合格できたと感じています。 黒本の代わりにping-tの無料問題に取り組むことでコストを節約することが可能です。

試験を通じて感じたこと

特に重点的に復習すべき分野

  • OSPF

  • STP

これらのトピックでは、以下のような知識が求められました。

  • ネゴシエーションのプロセスの理解

  • 各設定コマンドの動作と意味

  • showコマンド出力の読み解き

この辺りを完璧にしておくとかなり余裕が持てると思います。とはいえCCNAは出題範囲が広いため、特定分野だけでなく全体的にバランスよく復習しておくことが大切だと感じます。

当日の注意点

当日はテストセンターで受験しました。試験は自宅からのオンライン受験も可能ですが、厳格な監視体制があるため、人によっては集中しづらく感じる場合もあるようです。以下気になった点を箇条書きにしてみました。

  • 一度解答した問題には戻れない仕様

    • 解答時は慎重に選択肢を検討する必要があります
  • シミュレーション問題は選択問題の合間に数問出題され、結構難しい

    • コマンドの知識と手順の理解が必要です

    • 時間をかけすぎるぐらいなら飛ばしてしまいましょう

Ping-tのコマ問をしっかり解いておくと、こうした問題への対応力が向上します。

おわりに

BBSakura では、Cisco機器を使った検証環境やラボ環境が整備されており、ネットワーク技術を身につけることが可能です。 資格取得に関しても、実務と並行しながら無理なく学習できるようサポート体制が整っています。

技術を学びたい方、ネットワークインフラに興味がある方にとっては、非常に恵まれた環境だと感じています。

BBSakura では現在、ともに学び・成長していける仲間を募集しています。 興味のある方はぜひご連絡ください!

Azure OpenAI Service使ってみた#3 ~OCXを用いた閉域アクセス編~

はじめに

こんにちは、BBSakura Networks株式会社(以降BBSakura)にてOCXのクラウド直接接続サービスの運用を担当している太田と申します。

「OCXを用いた閉域網でのAzure OpenAI Service活用」3部作もいよいよ最終回となりました。

Azure OpenAI Service | Microsoft Azure

第1部ではAzure OpenAI Serviceの基本的な利用方法を第2部では閉域接続のための基盤となるAzure側ネットワークリソースの準備について解説しました。まだご覧になっていない方は、ぜひそちらもご確認ください。

本記事(第3部)では、これまでの準備を踏まえ、Azure側の最終的な接続設定とOCX側の設定を行い、お客様環境(今回はGoogle Cloud上に構築したUbuntu Desktop環境を想定)からAzure OpenAI Serviceへ実際に閉域接続を確立し、Webアプリケーションにアクセスするまでの手順を詳細にご説明します。

第1部はこちら: Azure OpenAI Service使ってみた#1 ~インターネット接続編~

第2部はこちら: Azure OpenAI Service使ってみた#2 ~閉域接続のためのAzureネットワーク設定編~

構成図

Google Cloud上のUbuntu DesktopからOCXを経由してAzure OpenAI Serviceに閉域接続するシステム構成図
構成図

Google Cloud上の仮想マシンにUbuntu Desktopを立てて、それをPCとして使用します。 そのため本記事ではGoogle CloudとAzure間をOCXを用いて閉域接続しますが、Google Cloud側はお客様環境に合わせて変更することができます。

  • 前提
    • Azureポータルにてリソースの作成ができる状態
    • OCXポータルにてリソースの作成ができる状態
    • PC側環境の整備が終わっている状態

手順目次

<注釈>
・前回の記事(第2部)の続きからの手順となります
・Google Cloud側の作業は省略します

 

  1. ExpressRoute Circuit作成
  2. OCX Cloud Connectionを用いた閉域接続
  3. ExpressRoute Circuit詳細設定
  4. PCにてDNS設定変更&Webアプリに閉域アクセス

1. ExpressRoute Circuit作成

1-1. 作成画面へ

Microsoft Azure ホーム画面の上の検索欄で [ExpressRoute circuits] と検索の上、 「ExpressRoute circuits」 画面を開きます。その後、[作成]を押下します。

1-2. 構成設定

[構成] タブにて以下項目を入力して [確認および作成] を押下します。

Azure ExpressRoute Circuit作成画面の「構成」タブ。サブスクリプション、リソースグループ、回復性、リージョン、回線名、ポートの種類、プロバイダー、ピアリングの場所、帯域幅、SKU、課金モデルの設定項目が表示されている。
1.1 構成タブ

項目 パラメータ
サブスクリプション 該当のサブスクリプションを選択
リソースグループ 作成済みのリソースグループを選択
回復性 標準の回復性
リージョン Japan East
回線名 任意
ポートの種類 プロバイダー
ピアリングの場所 Tokyo2
プロバイダー BBIX
帯域幅 任意
SKU 任意
課金モデル 任意

1-3. サービスキーのメモ

作成したリソースを確認し、サービスキーをメモしておきます

Azure ExpressRoute Circuitの概要画面。作成されたExpressRoute Circuitのサービスキーが表示されている箇所が示されている。
1.2 作成したリソース

2. OCX Cloud Connectionを用いた閉域接続

2-1. Cloud Connectionの作成

2-1-1. 作成画面へ

OCXポータルにログインし、[Cloud Connections]→ [作成]を押下します(以降Cloud ConnectionのことをCCと呼ぶ)。

OCXポータルのCloud Connections一覧画面。「作成」ボタンが強調表示されている。
2.1.1 CC作成画面へ

2-1-2. Azure CC作成

以下項目を入力して [作成] を押下します。

OCXポータルのCloud Connection作成画面(Azure向け)。名前、速度、Cloud NNI PoP名、CPEへの転送方法、サービスキーの入力項目が表示されている。
2.1.2 CC作成

項目 パラメータ
名前 任意
速度(帯域) 50Mbps
Cloud NNI PoP名 BBIX (Tokyo AT-Tokyo CC1 node1) <====> Azure (Primary, AT-Tokyo "Tokyo2", Japan East)
CPEへの転送方法 シングルタグ(dot1q)
サービスキー 1-3でメモしたもの
<注釈>
・Azure CCはAzure仕様により自動でPrimary, Secondaryの2つ作成されます
・本記事ではSecondaryは使用しません

 

2-1-3. VLAN IDをメモ

作成したリソースを確認し、VLAN IDをメモしておきます

OCXポータルのCloud Connection詳細画面。作成されたAzure CCのVLAN IDが表示されている箇所が示されている。
2.1.3 VLAN IDの確認

2-1-4. PC側CC作成

<注釈>
・本記事ではPCをGoogle Cloud上に用意するため、本工程を行います。PCをどこに用意するかによって、本作業の内容は変わります。

 

2-1-2と同様の手順で、Google Cloud用のCCを作成します。詳細は以下をご参照ください。

Cloud Connection(Google Cloud)の作成 | Open Connectivity eXchange

2-2. OCX-Router(v1)の作成

2-2-1. 作成画面へ

OCXポータルにログインし、[OCX-Router(v1)]→ [作成]を押下します。

OCXポータルのOCX-Router(v1)一覧画面。「作成」ボタンが強調表示されている。
2.2.1 OCX-Router(v1)作成画面へ

2-2-2. OCX-Router(v1)作成

以下項目を入力して [作成] を押下します。

OCXポータルのOCX-Router(v1)作成画面。名前、ロケーション、ローカルASNなどの入力項目が表示されている。
2.2.2 OCX-Router(v1)作成

項目 パラメータ
名前 任意
ロケーション Tokyo
ローカルASN 65001
その他 任意
<注釈>
・自動で2インスタンス(Primary, Secondary)作成されます
・本記事ではSecondary Routerは使用しません

 

2-2-3. Primary Interface 作成画面へ

作成したリソースの状態が[activated]になったことを確認し、[+]→ [+Primary Interface作成]を押下します。

OCXポータルのOCX-Router(v1)詳細画面。Primaryルーターの「+Primary Interface作成」ボタンが強調表示されている。
2.2.3 Primary Interface作成へ

2-2-4. Primary Interface 作成

以下項目を入力して [作成] を押下します。

OCXポータルのOCX-Router(v1)のPrimary Interface作成画面。インターフェース名とIPv4アドレスの入力項目が表示されている。
2.2.4 Primary Interface詳細設定

項目 パラメータ
インターフェース名 任意
IPv4アドレス 192.168.1.1/30

2-2-5. BGP Parameter 設定画面へ

作成したリソースの状態が[available]になったことを確認し、[BGP Parameters]→ [BGP Parameters作成]を押下します。

OCXポータルのOCX-Router(v1)のInterface詳細画面。「BGP Parameters作成」ボタンが強調表示されている。
2.2.5 BGP Parameters作成へ

2-2-6. BGP Parameter 設定

以下項目を入力して [作成] を押下します。

OCXポータルのOCX-Router(v1)のBGP Parameter作成画面。ローカルアドレス、リモートアドレス、リモートASNなどの入力項目が表示されている。
2.2.6 BGP Parameter設定

項目 パラメータ
ローカルアドレス 192.168.1.1
リモートアドレス 192.168.1.2
リモートASN 12076
その他 任意

2-2-7. PC側InterfaceとBGP Parameter設定

2-2-3〜2-2-6を繰り返し、PC側(本記事ではGoogle Cloud環境)用のInterfaceとBGP Parameterを設定します。

OCXポータルのOCX-Router(v1)詳細画面。Azure側とPC側(Google Cloud)のインターフェースおよびBGPパラメータが設定完了した状態が示されている。
2.2.7 設定後

2-3. VCの作成、アタッチ

2-3-1. 作成画面へ

OCXポータルで、[Virtual Circuits (VCs)]→ [作成]を押下します。

OCXポータルのVirtual Circuits (VCs)一覧画面。「作成」ボタンが強調表示されている。
2.3.1 VC作成画面へ

2-3-2. VC作成

以下項目を入力して [作成] を押下します。

OCXポータルのVirtual Circuit (VC)作成画面。名前の入力項目が表示されている。
2.3.2 VC作成

項目 パラメータ
名前 任意

2-3-3. VCにAzure CCとRouter Interfaceをアタッチ

作成したVC を選択し、[Cloud Connections]欄で2-1-2で作成したCCの[アタッチ]を押下します。

OCXポータルのVirtual Circuit (VC)詳細画面。「Cloud Connections」セクションでAzure CCをアタッチする「アタッチ」ボタンが強調表示されている。
2.3.3 VCアタッチ

同様に[Router Connections]欄で2-2-4で作成したRouter Interfaceの[アタッチ]を押下します。

2-3-4. PC側用VC作成、アタッチ

2-3-1~2-3-3と同様にしてPC側アタッチ用のVCを作成し、該当リソースをアタッチします(本記事では、手順2-1-4で作成したPC側CCと、手順2-2-7で設定したPC側インターフェースを指します)。

3. ExpressRoute Circuit詳細設定

3-1. プライベートピアリング設定へ

1-2で作成したExpressRoute Circuitリソース画面に戻り、[Azure プライベート]を選択します。

Azure ExpressRoute Circuitの概要画面。「ピアリング」セクションの「Azure プライベート」が選択されている状態。
3.1 プライベートピアリング設定へ

3-2. プライベートピアリング設定

以下項目を入力して [保存] を押下します。

Azure ExpressRoute Circuitのプライベートピアリング設定画面。ピアASN、IPv4プライマリサブネット、VLAN IDなどの入力項目が表示されている。
3.2 プライベートピアリング設定

項目 パラメータ
ピアASN 65001
サブネット IPv4
IPv4 プライマリサブネット 192.168.1.0/30
IPv4 セカンダリサブネット 任意(使用しません)
VLAN ID 2-1-3でメモした値

3-3. ルートテーブル確認

ExpressRoute Circuitリソース画面に戻り[Azure プライベート]の右側にある[•••]を押下し、[ルートテーブルを表示する]を押下します。

Azure ExpressRoute Circuitのプライベートピアリング詳細画面。右側の「•••」メニューから「ルートテーブルを表示する」が選択されている状態。
3.3 ルートテーブルへ

PC側ネットワークへのルートが受信できていることを確認します。本記事ではGoogle Cloud のVPCサブネットのネットワークアドレスを受信しています。

Azure ExpressRoute Circuitのルートテーブル表示画面。プライマリパスのルートテーブルにPC側ネットワークへのルートが学習されている状態が示されている。
3.4 ルートテーブル

<注釈>
・PC側ネットワークへのルートを受信するには、PC側ネットワーク(本記事ではGoogle Cloud)⇔OCX-Router(v1)区間のBGPセッションが確立されている必要があります。

 

3-4. 接続設定へ

ExpressRoute Circuitリソース画面に戻り、[設定]→[接続]→[追加]を押下します。

Azure ExpressRoute Circuitの「接続」設定画面。「+追加」ボタンが強調表示されている。
3.5 接続設定へ

3-5. 基本タブ

以下項目を入力して、 [次へ] を押下します。

Azure ExpressRoute Circuitの接続作成画面の「基本」タブ。サブスクリプション、リソースグループ、接続の種類(ExpressRoute)の入力項目が表示されている。
3.6 基本タブ

項目 パラメータ
サブスクリプション 該当のサブスクリプションを選択
リソースグループ 作成済みのリソースグループを選択
接続の種類 ExpressRoute

3-6. 設定タブ

以下項目を入力して、 [確認および作成] を押下します。

Azure ExpressRoute Circuitの接続作成画面の「設定」タブ。回復性、仮想ネットワークゲートウェイ、接続名、ExpressRoute回線、ルーティングの重みなどの設定項目が表示されている。
3.7 設定タブ

項目 パラメータ
回復性 標準の回復性
仮想ネットワークゲートウェイ 前回記事、5-2で作成したものを選択
名前 任意
ExpressRoute 回線 1-2で作成したものを選択
ルーティングの重み 任意
その他 任意

4. PCにてDNS設定変更&Webアプリに閉域アクセス

4-1. パブリックアクセスができないことを確認

作成したWebアプリのドメインにインターネット経由でアクセスできないことを確認します

WebブラウザでAzure Webアプリのドメインにアクセスしようとし、「このサイトにアクセスできません」というエラーメッセージが表示されている画面。
4.1 インターネット経由アクセス

4-2. DNSクエリの送信先を変更

PCにてDNSクエリの送信先を前回記事、4-4でメモしたIPアドレスに変更します。 下図はUbuntu Desktopでの例です。

Ubuntu Desktopのネットワーク設定画面。DNSサーバーのアドレスをAzure DNS Private Resolverの受信エンドポイントIPアドレスに変更している様子。
4.2 DNSクエリ送信先変更

4-3. 閉域アクセスできることを確認

作成したWebアプリのドメインに閉域アクセスできることを確認します。

WebブラウザでAzure Webアプリのドメインにアクセスし、前回記事(第一部)で作成したChatGPT風UIが正常に表示されている画面。
4.3 閉域アクセス

おわりに

3回にわたり、OCXを用いた閉域網経由でのAzure OpenAI Service利用手順をご紹介しました。設定項目が多く大変だったかもしれませんが、これで安全なAI活用環境を構築する一例がお分かりいただけたかと思います。

Azure OpenAI Serviceは、社内データを活用した専用AIの構築など、様々な応用が可能です。ぜひ本シリーズでご紹介した内容を参考に、お客様の環境やニーズに合わせたセキュアなAIソリューションの実現にOCXをお役立ていただければ幸いです。

最後までお読みいただき、誠にありがとうございました。