NTT ドコモビジネスではエンジニアコミュニティイベント、 Tech-Night/Tech-Midnight を定期的に開催しています。
普段はオンラインで実施していましたが、今回は数年ぶりにオフライン会場を用意し、オフラインとオンラインのハイブリッド形式で実施しました。発表を会場とオンライン会議双方へ配信した裏話と併せて、今回の発表内容について紹介します。
はじめに
こんにちは。 Smart Data Platform (SDPF) クラウド/サーバー 仮想サーバーチームの杉浦 (@Kumassy_) です。
普段は VM のハイパーバイザや OpenStack の開発・検証をしています。
この記事では、 2025 年 9 月 3 日に開催された Tech-Night の様子をご紹介します。
Tech-Night とは
Tech-Night は NTT ドコモビジネス内の有志で開催している発表会です。
業務や趣味で技術的に挑戦したことやサービスの裏側について部署の垣根を越えて共有することや、アウトプットの場、対外発表の練習などを目的としています。
今回はインターンシップ期間中の開催であり、多くの人が出社していると想定し、オフィスのイベントスペースを貸し切ってオフラインで発表してもらうようにしました。
2018 年 12 月の第 1 回目の開催の様子はこちら から、 2022 年 12 月開催の様子はこちら から確認できます。
会場の様子
今回は初回と同じく大手町プレイスのガレージ と呼ばれる共用スペースのひな壇の場所を使いました。オーディエンスとの距離が近く発表もしやすかったのではないでしょうか。
これは設営中の私です。
Tech-Night の発表内容
今回の Tech-Night では次の 6 つのテーマの発表がありました。
- Heuristic な Contest 参加のすゝめ (と生成AIでのアプローチ)
- オンラインカジノの闇 (の入口)
- Socks Proxy がつらい
- チーム開発におけるタスク管理術 Vol.1 – 臨時タスクの捌き方
- JANOG レポート 〜 AI を流行らせたい〜
- toby とチャッピーの夏の冒険
それぞれの発表を文字起こし形式で紹介します。
Heuristic な Contest 参加のすゝめ (と生成AIでのアプローチ)
みなさんこんにちは。堀岡です。私は今年入社の新入社員で、 SDPFクラウド/サーバー の NW オーケストレータ ESI (Elastic Service Infrastructure) の開発をしています。
今回は Heuristic Contest の紹介と、コンテストで実際に AI を使ってみて感じたことをお話したいと思います。
AtCoder では、お馴染みの Algorithm コンテストの他に、 Heuristic コンテストもあります。
Heuristic コンテストは厳密解を得るのが難しい問題について、スコアを最大化できるようなコードを考え、得られたスコアを競うコンテストです。
コンテストの期間は 4 時間から長いもので 10 日間と長丁場であり、生成 AI の利用もできる点が特徴的です。 参加者が Algorithm コンテストと比べて少ないので、取り組んでみるとそこそこの順位が取れたりレートが上がりやすかったりでハマりやすいかもしれません。
今回は直近の Heuristic コンテストで出題された次の問題を扱います。この問題は、 10 台のロボットを操作して床にワックスをかけるという非常に理解が簡単な問題です。
10 個のスイッチがあり、それぞれのスイッチに各ロボットの移動方向を割り当てられます。なるべく操作回数を少なくしつつ、全てのマスにワックスをかけることを考えましょう。
今回は生成 AI を活用してコードを書きましたが、いくつか工夫が必要でした。
生成 AI を使うポイントは解法を構造分割することです。
単に問題を丸投げするだけだと、高確率で動作しないコードが生成されました。
そこで、今回の場合ではロボットの現在位置の管理、ボタンを押したあとのロボットの位置計算、壁がある場所を取得する関数、といったように解法を関数の形でいくつかの構造に分割してあげれば、生成 AI にきちんと動作するコードを作ってもらえます。
これらをどう繋ぎ合わせるかは使う側(人間)の腕前と言えるでしょう。
また、生成 AI に上位者のコードを解説してもらえるようにもなり、初めて Heuristic コンテストに挑む上ではこれが一番うれしいかもしれません。
オンラインカジノの闇 （の入口）
みなさんこんにちは。神田です。私は Network Analytics for Security PJ リーダーとして、攻撃インフラの解明・撲滅や高度セキュリティアナリスト人材の育成・事業活動の両立に取り組んでいます。
今日の発表では、ドメインがドロップキャッチされてオンラインカジノ誘導サイトに転用された事例についてお話できればと思います。
ドロップキャッチとは、ドメイン名が更新されずに一定期間登録できない状態を経た後、再登録が可能になる瞬間を狙って目的のドメイン名を取得しようとする行為を指します1。
昨年の 11 月くらいにとある国産ソフトウェアの公式サイトで使用されていたドメイン名が契約更新されずに失効し、その後 ドロップキャッチによって第三者に取得されるという事件が発生しました。
このドメインは、怪しいサイトへの誘導に利用されており、公式から注意喚起が行われる事態となりました。
この件についてセキュリティアナリストの視点からもう少し踏み込んで調べてみました。
whois 情報を確認すると、電話番号が電話番号としてありえない文字列になっていて不審に思ったほか、名前が本当に実在する人のものなのか怪しいと感じました。
whois 情報の中でも、特にメールアドレスに着目して調査しました。
メールアドレスのウェブサイトを見に行くと、一見よくあるフリーメールサービスのようにみえますが、オンラインカジノ関連の利用者の声が数多く掲載されて、怪しい感じがしました。
次に、このメールアドレスを使って登録されているドメイン名の一覧を見てみました。
2024 年 12 月当時は全部で 55 ドメイン見つかり、観光や映画等で一時的に使われいたドメインがドロップキャッチされていることがわかりました。
これらのドメインはオンラインカジノへの誘導サイトに使われていました。
ドメインがドロップキャッチされてオンラインカジノの誘導に使われているといった話はときどきニュースになりますが、ご覧の通り氷山の一角で、みなさんが思っている以上にオンラインカジノ誘導キャンペーンが展開されているようです。
これは闇の「ほんの入口」に過ぎない..。
Socks Proxy がつらい
こんにちは。松下です。
普段私は、 Smart Data Platform (SDPF) クラウド/サーバー を開発している仮想サーバーチームにて、 OpenStack や GitHub Actions を使った CI/CD の開発を担当しています。
このセッションでは Socks Proxy の自作経緯や、 AI を使って調べた Socks5 プロトコルの詳細を話したあと、自作ツール proxs を紹介できればと思います。
SDPF クラウド/サーバーは複数リージョン展開しており、商用リージョンは現時点で展開しているもので 8 拠点、他に開発用やステージング環境などを含めると 10 拠点以上に及びます。
各リージョンには、リージョン内に閉じた Web ページ等があります。
SDPF の開発ではそれらにアクセスする必要がありますが、これらは前述するように各拠点の閉じたネットワーク配下にあるため、素直にアクセスできません。
そのため、我々は各拠点への SSH トンネルを利用して各拠点のサーバーにアクセスしています。
これらの Web ページに Web ブラウザからアクセスしたいときには SSH Client による Dynamic Port Forwarding とブラウザの Proxy 機能または、 Web ブラウザの拡張機能を利用することでアクセス可能です。
しかし、日々の業務ではさまざまな拠点にアクセスすることがあり、そのたびに SSH トンネルを貼ることは煩雑な作業でありストレスです。
このような煩雑さは Web ブラウザの拡張機能によって Socks Proxy 先を自動的に変更することで低減できますが、拠点内部からのみアクセス可能としてるサイトの閲覧にブラウザの拡張機能を利用することは、セキュリティの観点から可能な限り避けたいものです。
そこで、セキュリティを担保しつつ、複数拠点の Web ページに簡便にアクセス可能とする仕組みを作ることにしました。
具体的には、以下 3 点の特徴を持ちます。
- Web ブラウザ視点では、 1 つの Socks Proxy 設定のみを必要とする(= Web ブラウザの標準機能だけで利用可能とする)
- 宛先ドメインに応じて、 Socks Proxy を自動で切り替える
- HTTPS リクエストの TLS は解かない
これらの特徴には、 2 つの矛盾があります。
1 つめは、 Web ブラウザ視点では 1 つの Socks Proxy 設定のみを必要とすることと、宛先ドメインに応じて Socks Proxy を切り替えることです。
Web ブラウザの Socks Proxy 設定は 1 つしか設定できないため、複数の Socks Proxy を利用することは通常できません。
2 つめは、 HTTPS 通信の TLS を解かないことと、宛先ドメインに応じて Socks Proxy を切り替えることです。
通常の HTTPS 通信では HTTP のパケットは TLS で暗号化されており、 HTTPS パケットがどのドメインを宛先としているかは (HTTP Header に格納されており TLS で) 暗号化されているため、 Web ブラウザと宛先サーバーの間で見ることができません。
これらの矛盾を解消しながら実装したものが、「proxs」です。
proxs は、これらの矛盾を以下のように解消し実装します。
まず、 proxs は自身を Socks Proxy として Web ブラウザに対して振る舞います。
したがって、 Web ブラウザはすべてのリクエストを proxs に送信します。
proxs は、受け取ったリクエストの宛先ドメインに応じて、適宜 Dynamic Port Forwarding が有効な SSH 接続を確立し、受取ったリクエストを転送します。
次に、 TLS を解かずに宛先ドメインを知るために、 Web ブラウザから発行される Socks5 の CONNECT コマンドを利用します。
Socks を使った通信をする際、 Web ブラウザは HTTPS リクエストを Socks Proxy へ送信する前に、 Socks Proxy に対して CONNECT コマンドを送信します。
この、 CONNECT コマンドは暗号化されておらず、また、 Proxy させたい HTTPS リクエストの宛先ドメインを含んでいます。
したがって、 proxs は CONNECT コマンドを受け取った際に、宛先ドメインを知ることができ、宛先ドメインに応じて Socks Proxy を切り替えることができます。
Socks5 の CONNECT コマンドは暗号化されていませんが、後続の HTTPS リクエストは通常通り TLS で暗号化されているため、 proxs が知ることのできる情報は宛先ドメインのみとなります。
これは余談ですが、 Socks5 のプロトコルの理解は、 ChatGPT に mermaid.js でシーケンス図を書いてもらうことで、効率的に理解できました。 LLM を利用したおすすめの勉強法です。
実装面では、RFC1928 や go-socks5 を参考にすることで、比較的容易に実装できました。
Tech-Night では、各拠点の Web サーバーに対して Socks Proxy を手動で繋ぎ変えることなく接続可能であることをデモンストレーションしたり proxs の性能評価についても発表しました。
もし、同様の課題を抱えている方がいれば、ぜひ proxs を試してみてください。
チーム開発におけるタスク管理術 Vol.1 – 臨時タスクの捌き方
初めて Tech-Night に登壇させていただきます。三輪です。
私は Smart Data Platform (SDPF) クラウド/サーバー にて、オペレーターのための運用ツールやお客さまによるサービス申し込みを円滑化するための Web アプリケーションを開発しています。
今日はウェブアプリ開発チームの運用方法や臨時タスクの管理におけるポイントを話します。みなさんのチーム開発のヒントになれば幸いです。
スプリントのはじめに計画した開発タスクを予定通り消化できなかった経験はありませんか？いろいろな原因が考えられますが、最大の原因は、スプリントの途中に臨時対応が必要なタスクの発生することだと考えています。
例えば、セキュリティ脆弱性対応タスクや他チームからの問い合わせは事前に発生することが予測できません。
また、このような臨時タスクは性質が違い、コンテキストの切り替えコストがかかったり認知負荷が増大してしまいます。
臨時タスクへの対応として、私のチームでは臨時タスクを「見える化」するよう工夫しました。具体的には臨時タスクも開発タスクと同様にチケットを作成し、スクラムボードに乗せることで今チームが抱えている仕事量を把握できるようになりました。
臨時タスクの量が「見える化」できていると、毎回どの程度臨時タスクが発生するか予測できるようになります。スプリント計画時には臨時タスク用のバッファを持たせておくことにしました。
臨時タスクは必ずしもすぐに取り組む必要はないので、優先度が低いタスクは次のスプリントに回すこともできます。
臨時タスクのコンテキストスイッチ、認知負荷の問題については、臨時タスクを当番制にすることで解決しました。こうすることで、チーム全体の認知負荷を下げ、当番以外のメンバは開発に集中できます。
スプリント振り返りには、臨時タスクの分量や性質などに着目して将来予測に役立てたり、共通パターンを見出して手順化、自動化、ドキュメント整備などを検討して負荷を軽減させることも重要です。
JANOG レポート 〜 AI を流行らせたい〜
みなさんこんにちは。鈴木です。
私は今年入社の新入社員で、 SDPFクラウド/サーバー のファイアウォールやロードバランサ開発をしています。
JANOG 56 に参加した経験をもとに、 JANOG での AI 活用事例を複数紹介し、MCP（Model Context Protocol）の技術概要と社内での検討状況について共有します。
JANOG 56 のタイムテーブルをみてみると、全体の 1/3 が AI 関連で JANOG 53 では 1 件だったことを踏まえると、 AI の流行をみてとれます。
これらの発表では、自然言語をもとにネットワーク機器のコマンドを生成したり、 MCP サーバを実装してネットワークの操作やチケットの参照、アラート対応を自動化したりするなど、 AI を積極的に利用した事例が報告されていました。
一方で、私が普段業務で使っている AI はチャットボットやコーディングエージェント、チャットツールの要約機能に留まっており、 JANOG の事例のようにもっと踏み込んで AI を活用したいです。
そのためには MCP の理解が必要です。
MCP (Model Context Protocol) は、 LLM (Large Language Model) が外部データやツールにアクセスするためのオープンなプロトコルです。このプロトコルは、 Claude を開発した Anthropic によって提唱され、標準化が進められています。
MCP サーバーは、 LLM に対して「どのようなデータを持っているか」「どのようなツールが利用可能か」を教える役割を果たします。ユーザーがリクエストを送信すると、 LLM は MCP サーバーを通じて適切なツールやデータを選択し、そのレスポンスを基に最終的な回答を生成します。
AI エージェントの開発には、 MCP サーバ、アプリケーション、システムプロンプトの実装が必要です。
多くの部分は公式の SDK や OSS を活用すれば簡単に実装できるので、システムプロンプトの工夫が重要です。
具体的には、システムプロンプトを通じて AI をエージェント化し、タスクの消化方法やツールの呼び出しルールを教える必要があります。例えば、チケット管理エージェントの場合、「最後に必ずチケットを作成する」といった指示を与えることができます。また、 Junos の MCP サーバでは「コミット前に必ず人間の確認を取る」といったルールを設定することも可能です。
私のチームでは MCP サーバの導入を進めています。さらに詳しい技術的な詳細や、 AI の API の申請の苦労話など、続編発表ができればと考えています。
toby とチャッピーの夏の冒険
今回の Tech-Night の大トリを飾る toby です。
私は SDPFクラウド/サーバー の開発責任者を担当しており、 NTT ドコモビジネスのエバンジェリスト としても活動しています。
今日は toby とチャッピーの夏の冒険と題して、チャッピー (ChatGPT) と相談して設計・実装したシークレットマネージャーについて説明し、 AI を活用するうえで感じたことを発表できればと思います。
最近、 AI によってコンピュータサイエンスのあり方が変わり、パラダイムシフトが起きそうだなぁと感じています。
今年の夏休みに、 LLM を利用した実装を自ら経験してみることも兼ねて、 LLM (チャッピー) と一緒にシークレットマネージャーを作ってみることにしました。
夏休みの冒険として、チャッピーとはスマートフォンだけで会話はするというチャレンジをしてみました。
シークレットマネージャーは Go 言語で実装され、最終的には 100 ファイル、 13k 行のコードができました。
セキュリティ設計では、 SSH 公開鍵方式や JWT を活用し、 AES-256-GCM で暗号化を強化しました。
鍵管理には KMS を用い、定期的なキーのローテーションや監査ログを実装し、マスターキーはシステム内に保持しないことでセキュリティを強化しました。
AI 活用して便利だと感じたことはいくつかあります。
これまで手作業で行っていた実行環境のセットアップや、細かい仕様の実装、シェルスクリプトのような簡易ツールの作成など、これまで面倒で時間がかかっていた作業が AI によって大幅に簡単になりました。
また、 AI を使うことで自分のユースケースに合ったものを作られることが魅力に感じました。
今回のプロジェクトでは、 SSH 署名を活用した認証システムが必要でしたが、規模感は我々のユースケースにあう程度のスケーラビリティがあれば十分です。
既存の OSS や SaaS を使うよりも、自分たちが本当に欲しいものだけを作れるという点が大きな魅力だと感じました。
AI を使うことで設計の自由度が増し、どこでも作業ができるようになった点も印象的です。
例えば、露天風呂に入りながらでも設計を進めたり、スマートフォンを使ってアイデアを記録したりと、これまでの制約を超えた働き方が可能になりました。
これにより、思いついたアイデアをすぐに形にでき、開発のスピード感が大幅に向上しました。
しかし、 AI を活用する中で感じた課題もあります。
特に、大規模なコードベースにおいては、全体の統一感を保つことが難しいと感じました。
AI が生成するコードは便利ですが、設計者が一貫した指針を持って指示を出さなければ、プロジェクト全体がバラバラになってしまう可能性があります。
また、 AI に頼りすぎることで、開発者自身のモチベーションやコードに対する愛着が薄れるという懸念もあります。
自分でアルゴリズムを考えたり、コードに工夫を凝らす楽しさが減ることで、開発への情熱を維持するのが難しくなるかもしれません。
それでも、 AI は開発の効率化や新しい働き方の可能性を広げる強力なツールであることは間違いありません。
LLM の登場によりソフトウェア開発の変革を体感するとともに、二人三脚で歩むんだなと実感したチャッピーとの素晴らしい冒険でした。
まだこっそりと開発を続けています。
配信の工夫
最後に、司会者の杉浦から今回の Tech-Night の裏話をお話します。
今回の Tech-Night はハイブリッド開催としたかったので、オフライン会場とオンライン両方にプレゼンテーションを配信する必要がありました。また、発表者がオフライン会場からだけでなく、オンラインミーティングからもプレゼンテーションできるように工夫しました。
いろいろと配信の方式を検討しましたが、最終的に下記のような方式に落ち着きました。
発表者は各自の PC から Teams 会議に入り、画面共有をして発表してもらいます。これでオンライン参加者に PC の画面と音声を届けることができます。
会場の音声と映像を届けるために配信用 PC を別で用意しました。
この PC を Teams 会議に発表者として参加させ、プロジェクターの HDMI ケーブルを接続して会議画面を会場に投影しました。
ちなみに、発表者の PC で音声を共有した場合でも、 Teams と HDMI を経由して音声を会場に流すことができます。
発表者の音声を Teams 会議に配信するため、 MacBook の内蔵マイクを使用することにしました。
事前の検証で、 MacBook の内蔵マイクでも十分な音声品質が得られることを確認できたためです。
この方式では発表者の PC に HDMI ケーブルを接しないため、接続トラブルを回避できます。
Teams 会議であれば普段の業務で使い慣れているうえ、事前に画面共有の準備もしておけるのでスムーズに進行できました。
オンラインからプレゼンテーションする場合でも、配信用 PC の設定を変えることなくそのまま続行できるのも利点です。
事前の想定よりも発表者の数が多くタイトなスケジュールでしたが、会場の皆さんのご協力もあり、概ねスケジュール通り進行できました。
発表者の皆さんも素敵なお話をありがとうございました。
おわりに
本記事では NTT ドコモビジネスのエンジニアコミュニティのイベントである Tech-Night を紹介しました。
これまで紹介したように、スクラムの工夫からセキュリティ、AI の活用事例など本当にいろんなテーマの話を聞くことができ、非常に好評なイベントとなっています。
さらに NTT ドコモビジネス ではお昼の勉強会の TechLunch や NTT Tech Conference のほか、一般向けの NTT Com Open TechLunch も開催しています。
このようなイベントの開催は、知識・情報の共有だけでなく、さらにアウトプットを通した発表者個人の知識・技術の向上やエンジニア組織としての一体感の醸成にも繋がっています。
今後もこの取り組みを続けるとともに、輪を広げ、より活力のある組織へ成長させていきたいと考えていますので、共感できる方はぜひ！
NTT ドコモビジネスではメンバーを募集しています
SDPF クラウドでは現在、学生の皆さん向けに Tech Workshop イベントへの参加を募集しております。
SDPF クラウドのエンジニアと参加者の皆さんでチームを組み、モブプログラミングを行います。
今回発表してくれたエンジニアも一部参加予定です。
発表内容についてより詳しく聞けるかも…？
申し込み期限は 2025/10/19(日)23:59 までですので、お早めにお申し込みください！
information.nttdocomo-fresh.jp
そのほか、 NTT ドコモビジネスでは新卒採用や経験者採用、障がい者採用も行ってます！
コメント