こんにちは。NTT Comの市村、田口、村上です。2024年8月に米国ラスベガスで同時期に開催された3種類のセキュリティカンファレンスへ聴講者として参加しました。 この記事では連日参加した3種類のセキュリティカンファレンス及び、聴講した中で印象深かった講演の概要について紹介します。 目次 目次 8月のラスベガスを彩るセキュリティの祭典 BSides Las Vegas Black Hat USA DEF CON 複数の会議が同時開催されるメリットについて 講演内容 BSides Las Vegas: Devising and detecting spear phishing using data scraping, large language models, and personalized spam filters Black Hat USA: Modern Kill Chains: Real World SaaS Attacks and Mitigation Strategies DEF CON (BHでも講演有) : Self-Hosted GitHub CI/CD Runners: Continuous Integration, Continuous Destruction 現地Tips おわりに 8月のラスベガスを彩るセキュリティの祭典 毎年8月、ラスベガスではBSides Las Vegas、Black Hat USA、DEF CONという3種類のセキュリティカンファレンスが同時期に続けて開催されます。 いずれもセキュリティをテーマとするカンファレンスですが、それぞれが異なる特徴を持っています。 以下、3種類のセキュリティカンファレンスの特徴と開催概要について紹介します。 BSides Las Vegas BSides Las Vegasは、Black Hat USAやDEF CONのような大規模カンファレンスと異なり、 コミュニティ主導で運営されるカジュアルな雰囲気のセキュリティカンファレンスです。 Black Hat、DEF CONと比べ小規模ですが、内容はどちらにも劣らず多様かつ高度な講演を聞くことができます。 BSides Las Vegasの最大の特徴は、セキュリティに関心のある人が自由に情報共有できるオープンな環境を提供している点です。 特に注目すべきは「Proving Ground」と呼ばれるトラックです。 このトラックは、国際的なカンファレンスでの講演経験のない人たちが初めて登壇する場として設けられおり、国際カンファレンスの初登壇をコミュニティがサポートしています。 今年のBSides Las Vegasは、Tuscany Suites & Casinoホテルにて、8月6日・7日の2日間開催されました。 また、今年はNTT Comからも講演しました。BSides Las Vegasで登壇した話については、以前当ブログで公開した 「 BSides登壇のBサイド ～なんで、私が海外セキュリティカンファレンスに！？～ 」にて紹介しています。 Black Hat USA Black Hat USAはサイバーセキュリティに携わる人々にとって、最も注目されるカンファレンスの1つであり、世界中のセキュリティプロフェッショナルが一堂に会するイベントとなっています。 Black Hat USAは、技術的な知識を共有するだけでなく、新たなビジネスチャンスを生み出すための商業的な色彩が強いカンファレンスでもあります。 ビジネスホールと呼ばれる展示会場では、大手セキュリティベンダーからスタートアップまで、数百もの企業がブースを出展し、参加者に対して製品デモやソリューションを提案しています。 講演（ブリーフィング）では、世界中から集まったセキュリティの専門家やリサーチャーが最先端の脅威、攻撃手法、脆弱性に関する講演が行われます。 多くの講演ではセキュリティ対策の導入や強化に関する具体的なアドバイスが提供され、企業は自社のセキュリティ戦略を見直し、最先端のソリューションを導入するための情報を得ることができます。 今年のBlack Hat USAは、Mandalay Bay Convention Centerにて、8月3日から8日までの6日間開催されました。 8月3日から6日までの期間は主にトレーニングが開催される期間で、7日・8日の2日間は講演が行われる期間です。今回は講演期間に聴講者として参加しました。 Black Hat USA ビジネスホールの様子 DEF CON DEF CONはBlack Hat USAと並ぶサイバーセキュリティ界の一大イベントです。 他2つのカンファレンスとはまた違った独自の文化と自由な雰囲気を持っており、 セキュリティに関心のあるすべての人が最新の技術を学び、実践し、そして楽しむことができるイベントとなっています。 DEF CONの大きな特徴は「Village」と呼ばれるコミュニティスペースです。 無線ハッキング、IoTセキュリティ、物理セキュリティなど特定のテーマに基づいたトーク、コンテスト、ワークショップが行われます。 参加者は自分の興味に応じたVillageへ訪れることで、興味分野の知識を深めることができます。 今年のDEF CONは、Las Vegas Convention Centerにて、8月8日から11日までの4日間開催されました。 今年は33個のVillageがありました。特に注目を集めていたVillageは「AI×CC」と呼ばれるVillageで、AIを活用した近未来の街をモチーフとした派手なブースが建てられていました。 DEF CON AI×CC Villageの様子 複数の会議が同時開催されるメリットについて 約1週間という期間の中で、対象/規模/雰囲気を異にした3種類のカンファレンスが まとめて開催されるのが例年のスタイルですが、これには大きなメリットが3つあると感じました。 まず参加者側にとっては、短時間・1回分の旅費で多くのテクノロジーを学べるというメリットがあります。 この時期のラスベガスに来さえすれば、最先端の情報に追い付いたり、また同好の士と出会うことができるのです。 同様にスポンサー企業側にとっても、この1週間を狙えば広告、イベント、採用活動を効率よく行えます。 どのイベントに出資するとしても費用対効果は抜群ではないでしょうか。 最後にカンファレンスそれぞれの雰囲気/目指す姿が異なることは、結果的に多くの人をセキュリティの世界へ立ち寄らせることに役立っている点が最大のメリットであると感じました。 たとえば、Black Hatでは「技術は専門ではないがビジネスに興味がある人」、BSidesでは「発表の機会が欲しかったセキュリティ研究者」、 DEF CONでは前者2つよりも手ごろな参加費のおかげで多くの学生や家族連れが参加していました。 これらのメリットを総合して考えると、対象が少しずつ異なるカンファレンス複数を同時期に開催する計画は、国内のセキュリティ界隈を盛り上げ、人材の裾野を広げることに繋がるのではないでしょうか。 講演内容 各セキュリティカンファレンスで聴講した講演の中で、印象深かったものを紹介します。 BSides Las Vegas: Devising and detecting spear phishing using data scraping, large language models, and personalized spam filters パーソナライズされたフィッシングメールフィルタを AI で作れないか、という内容の講演が興味深いと感じました。 訓練用の無害なフィッシングメールを使って、「A さんがひっかかりやすいキーワード」「B さんが...」といういわば弱点のデータベースを作り、 そういった弱点の要素を検出して優先的に弾いてくれる個人化されたメールフィルタを作成する試みについてでした。 この講演の概要はこちらからご覧ください。 https://www.bsideslv.org/talks#8WK8P3 Black Hat USA: Modern Kill Chains: Real World SaaS Attacks and Mitigation Strategies APP OmniというSSPM（SaaS Security Posture Management）ベンダーによる近年のSaaSに対する攻撃の統計情報を共有する発表でした。 企業業務で多くのSaaSを利用することが当たり前になってきた近年において、攻撃者はどのようなサービスをどのような目的で攻撃しているかをSSPMベンダーの視点から統計情報とともに共有していました。 特に興味深かった内容として、SaaSを起因とする攻撃者による一連の攻撃観測に成功したという点でした。 一連の攻撃を時系列に並べて観測したSaaS侵害後の流れを発表内で提示していました。 講演の最後では、多様なSaaSが普及した現代において特に注目しなければならないAttack Surfaceの提示と今後行うべきセキュリティ戦略についてまとめていました。 セキュリティ製品ベンダーからの啓蒙と対策提案という講演内容は、商業色の強いBlack Hat USAの特徴が現れている講演だったと思います。 この講演のスライド資料はこちらにありますのでご参照ください。 http://i.blackhat.com/BH-US-24/Presentations/US24-Michal-Modern-Kill-Chains-Real-World-SaaS-Attacks-Wednesday.pdf DEF CON (BHでも講演有) : Self-Hosted GitHub CI/CD Runners: Continuous Integration, Continuous Destruction GitHub Actionsを実行するためのRunnersを利用した攻撃方法についての発表でした。 APIで対象のRunnerの情報を取得し、権限確認後、ContributorになってC2サーバを埋め込むといった一連の流れから、 その詳細までみっちりと解説があり、非常に面白かったです。 対策方法はRunnersの設定やアクセストークン・シークレットを適切に管理しましょう、といった一般的なものが多かったですが、 攻撃のロジックやなぜ脆弱なのか？といった説明がわかりやすく、技術を探求するDEF CONらしさが味わえました。 講演はDEF CONのメディアサーバに上がっていますので、詳細気になる方はこちらからご覧ください。 https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20video%20and%20slides/ 現地Tips トコジラミが、盗難が、といった不安を覚える話を出発前によく聞きましたが、いざ現地に着いてみると意外と安全でした。（ただ事故がおきなかっただけ） とはいえここは運もあると思うので、しっかりと対策はして行った方が良いと思います。 （NFLabs.のエンジニアブログにトコジラミ対策等の詳細が書かれていたので、対策の詳細を知りたい方はこちらのブログを見てみてください） https://blog.nflabs.jp/entry/2024/09/19/133000 上記ブログで紹介されている以外のTipsとして以下もあります。 サングラス・日焼け止めは必須 一応羽織るものはあった方がいい 夏のラスベガスはとても暑く、気温は40度を超えます。 ただ非常に乾燥しているので、筆者的にはジメジメとした暑さの日本より快適に感じました。 また、外がやたらめったら暑い一方で、室内は寒いと感じるレベルで空調が効いている場所も多いです。なので筋肉量少なめエンジニアは防寒具を持っていくことをお勧めします。 （とても寒がりな上司はウルトラライトダウンを持って行ってもいいくらいと言っていました。） 現地の移動手段については、Lyft/Uber、モノレールあたりが良いと思います。 特にモノレールはDEF CON会場への移動手段として役立ちますし、複数日乗る場合はお得な○日券みたいなのもあります。 UberはBlack Hat会場への行き来で使いましたが、混雑しているスポットもあるので配車場所には要注意です。 先人達から現地Tipsを教わり、なんとか生きながらえることができました。（ありがとうございます） 来年以降ラスベガスへ行かれる方たちに、このTipsが役立てば幸いです。 おわりに BSides Las Vegas、Black Hat USA、DEF CONと盛りだくさんで非常に充実したラスベガス出張でした。 こういった機会を与えてくれるNTT Comには感謝しかないです。 担当分野の知見向上はもちろんですが、専門外の分野についての知見も広がるので、 今後のキャリアを考える上でも有意義な出張になりました。 また参加者同士の交流があるというのは、現地参加の大きなメリットだったかと思います。 海外の方との交流は言わずもがなですが、海外だからこそ日本からの参加者とも密な関係を気づくことができたのは非常に大きな収穫でした。

はじめに こんにちは、5G&IoT部/IoTサービス部門の下地です。SIMのAppletを活用したサービスの企画・開発に取り組んでいます。 IoT (Internet of Things) デバイスの普及に伴い、セキュリティの重要性が高まっていますが、GSMA規格のIoT SAFE (IoT SIM Applet For Secure End-to-End Communication) は、この課題に対するソリューションとして注目されています。 今回はそのIoT SAFEとAWS IoT Coreを連携させてみます。 はじめに IoT SAFEの特徴 試してみた 構成概要 ATコマンド利用設定 セルラー接続の設定 IoT SAFE連携用パッケージをインストール CSRの作成と確認 CA証明書の作成 クライアント証明書の作成 AWS IoT Coreへの登録・設定 CA証明書の登録 クライアント証明書の登録 ドメインの設定 AWS IoT Coreでのsubscribe設定 publishの実施 publishされたメッセージの確認 考察 IoT SAFEの特徴 特徴は以下の通りです。 安全な鍵管理 SIMカード内でキーペアを生成 そのため秘密鍵がSIMカード外に流出することなく安全な鍵管理が可能 エンドツーエンドの暗号化 デバイスはPKCS#11を通じてSIM内の秘密鍵にアクセス可能 PKCS#11を通じた署名により安全で標準性の高い相互認証を実現 運用負荷軽減 鍵の生成や公開鍵の登録が自動化されており、手動での運用負担を軽減 コスト削減 SIMカード内のHSM機能により、IoT機器自体のコスト軽減に貢献 リモート管理機能 OTA (Over-The-Air) による鍵情報やIoT SAFEアプレットの更新が可能 GSMA標準 GSMA標準規格に準拠しているため、異ベンダー間での相互運用性を促進 主要諸元 IoT.04 IoT.05 試してみた NTTコミュニケーションズの IoT Connect mobile Type S では、IoT SAFEをPoC (Proof of Concept) として提供しています。PoC申込者には、IoT SAFEアプレット搭載のSIMカードが提供されます。今回はそのSIMカードを用いてIoT SAFEとAWS IoT Coreの連携を試行しました。 構成概要 端末としてラズベリーパイを用い、IoT SAFEの管理コンソール「AppletConsole」と接続し、CA証明書やクライアント証明書を自作し、証明書等をAWS IoT Coreに登録します。 項目 詳細 SIMカード IoT Connect mobile Type S 提供のSIMカード IoT Device Raspberry Pi4　modelB OS Raspberry Pi OS 通信モジュール EG25-G CA証明書 OpenSSLによる自作 SIM管理コンソール AppletConsole デバイス管理 AWS IoT Core ATコマンド利用設定 デバイスからSIMカード内のIoT SAFE Appletと通信するためATコマンドツール (minicom) をインストールします。 minicomのインストール sudo apt-get install minicom ATコマンド送受信用デバイスファイルを確認 sudo minicom -D /dev/ttyUSBX ( ttyUSBX はデバイスにより異なる) プロンプト表示後、基本的なATコマンド( AT 等)を入力しレスポンスを確認 ctrl+a, x でminicomを終了 セルラー接続の設定 IoT Connect Mobile Type Sの接続のため、wvdialをインストール・接続設定を行います。 wvdial のインストール sudo apt-get install wvdial /etc/wvdial.conf の編集 [Dialer Defaults] Init1 = ATZ Init2 = AT+CGDCONT=1,"IP","mobiledata.ntt.com" Phone = *99# Username = "a" # ダミーの値が必要 Password = "b" # ダミーの値が必要 Modem = /dev/ttyUSB2 # デバイスによって異なる Baud = 115200 Stupid Mode = 1 セルラー接続 sudo nohup wvdial > wvdial.log 2>&1 & IoT SAFE連携用パッケージをインストール IoT SAFE連携に必要なパッケージをインストールします。 パッケージ名 説明 pkcs11-provider PKCS#11（暗号化トークンインターフェース）のプロバイダー。OpenSSLなどからHSMへのアクセスを提供。 pcscd PC/SCデーモン。スマートカードの読み取り・書き込みを管理するためのサーバープロセス。 opensc スマートカードのセキュリティ機能を提供するライブラリ。 pkcs11-dump PKCS#11のデバッグツールで、PKCS#11のオブジェクトを表示。 libifd-atcmd 個別提供パッケージ。ATコマンドを通じてIoT SAFEアプレットと通信時に使用。 pkcs11-iotsafe 個別提供パッケージ。PKCS#11を通じてIoT SAFEアプレットを利用するために使用。 各種既定パッケージのインストール apt install pkcs11-provider pcscd opensc pkcs11-dump 個別提供パッケージ libifd-atcmd のインストール sudo apt install ./libifd-atcmd_0.1.6-1_arm64.deb /etc/reader.conf.d/libifd-atcmd の編集 FRIENDLYNAME libifd-atcmd DEVICENAME :/dev/ttyUSB3 LIBPATH /usr/lib/pcsc/drivers/serial/libifdhandler_atcmd.so ATコマンド送受信用のデバイスファイルを指定する DEVICENAME :/dev/ttyUSB3 は、通信モジュールに合わせて調整する 個別提供パッケージ pkcs11-iotsafe のインストール sudo apt install ./pkcs11-iotsafe_0.1.3-1_arm64.deb CSRの作成と確認 クライアント証明書作成のためのCSR(証明書署名の要求)を作成します。 PoC申込者向けに提供されるpoetry管理のスクリプトを実行し、CSRを生成する 一定時間後にCSRがAppletConsoleに送信されるのでAppletConsoleにアクセスしCSRをコピーペーストして適当な場所にファイル保存する(ファイル名: csr.pem としておく) CSRがApplet Consoleに登録されていることを確認する方法 CA証明書の作成 クライアント証明書を検証するためのCA証明書を作成します。opensslが利用できる環境であれば、作成場所は特に問いません。 今回はラズベリーパイ内でCA証明書を作成します。 秘密鍵の作成 openssl genpkey -algorithm RSA -out ca.key CA証明書の作成 openssl req -new -x509 -key ca.key -out ca.crt -sha256 -days 1825 -subj "/C=JP/ST=Tokyo/O=mycompany" クライアント証明書の作成 クライアント証明書の作成 openssl x509 -req -in csr.pem -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 365 -sha256 AWS IoT Coreへの登録・設定 CA証明書とクライアント証明書をAWS IoT Coreへ登録します。 CA証明書の登録 AWSコンソールへログインし、AWS IoT Coreを開く 「認証機関」＞「CA証明書を選択」を選択しca.crtをアップロード(その際に証明書IDを控えておく) CAステータスを「ACTIVE」に変更し、その他はデフォルトのまま「登録」をクリック クライアント証明書の登録 続いて「証明書」＞「証明書を追加」＞「証明書を登録」をクリックし証明書の登録画面を開く CA証明書を選択のドロップダウンメニューから前述の証明書IDを選択 先に作成したclient.crtをアップロードしクライアント証明書を登録 ドメインの設定 「ドメイン設定」＞「ドメイン設定を作成」＞「続行」を選択 ドメイン設定名に任意の値を入力し、認証タイプが「X.509」であることを確認する アプリケーションプロトコルとしてHTTPSを選択する HTTPSでもpublishはできるためこちらを選択 「ドメイン設定を作成」を実施する AWS IoT Coreでのsubscribe設定 AWS IoT Coreにてトピックのsubscribe設定します。 「MQTTテストクライアント」＞「サブスクライブ」タブを選択 「トピックフィルター」に test/testing を入力 「サブスクライブ」をクリック こちらの画面でpublishされたメッセージを確認できます。 publishの実施 PoC申込時に提供された openssl_iotsafe.cnf を使用して以下スクリプトでHTTPSによるpushを行います。 MQTTSでも大丈夫なはずですが、ひとまず扱いやすいHTTPSで実施してます。 #!/bin/bash topdir=$(realpath $(dirname $0)) export OPENSSL_CONF=${topdir}/openssl_iotsafe.cnf # 必要なパスの定義 ENDPOINT="xxxxx.iot.ap-northeast-1.amazonaws.com:8443" PATH_TO_CERTIFICATE="iotsafe.client.cert" PATH_TO_PRIVATE_KEY="pkcs11:token=IoTSAFE;type=private;id=%01" PATH_TO_AMAZON_ROOT_CA_1="AmazonRootCA1.pem" TOPIC="test/testing" MESSAGE="{\"message\": \"Hello, world\"}" # POSTリクエストのHTTPヘッダーとボディを構築 HTTP_REQUEST="POST /topics/${TOPIC}? HTTP/1.1\r\n" HTTP_REQUEST+="Host: $ENDPOINT\r\n" HTTP_REQUEST+="Content-Type: application/json\r\n" HTTP_REQUEST+="Content-Length: ${#MESSAGE}\r\n" HTTP_REQUEST+="Connection: close\r\n\r\n" HTTP_REQUEST+="$MESSAGE\r\n" # OpenSSLでPOSTリクエストを送信 (echo -en "$HTTP_REQUEST"; echo ; sleep 4) | \ openssl s_client \ -connect $ENDPOINT \ -cert $PATH_TO_CERTIFICATE \ -key $PATH_TO_PRIVATE_KEY \ -CAfile $PATH_TO_AMAZON_ROOT_CA_1 \ -tls1_2 AmazonRootCA1.pem はAWSの 既定サイト からダウンロードしておきます。 publishされたメッセージの確認 ラズベリーパイからpublishを実施すると、先にsubscribe設定した画面にて指定トピックのメッセージを購読できます。 考察 AWS IoT CoreとIoT SAFEの連携についての考察です。 SIM内で秘密鍵が生成されるため、秘密鍵等を外部からダウンロードする手間や保管場所に関する懸念からは解放される 今回はOpenSSL上にHTTPSでpublishを実施したが、理屈的にはMQTTSでもpublishできるはずで、こちらは試行錯誤中。 クライアントを openssl s_client から mosquitto に変えて試行してみたが、mosquittoにはPKCS#11連携にバグがありそうでうまくいかず。 ただ、理屈的にはPKCS#11対応アプリケーションであればIoT SAFEアプレットとの連携が容易かとも推測。 現状のAppletConsoleでは、CSRの作成やクライアント証明書の作成・登録手順が複雑なため、これらのプロセスが簡素化されないと商用運用は難しいとみる。 この技術がどのような領域の業種や産業で活用できるかについての考察は、次回記載予定。

本記事では、「ローカル5G網への接続と公衆モバイル網への接続を切り替え可能なSIMアプレット」について説明します。 SIMアプレットはSIMカード上に搭載するアプレットです。SIMアプレットとは何か、どのような機能を実装することで技術開発を実現したのかといったことをご紹介します。 目次 目次 はじめに 背景 SIMカード SIMアプレット 動作例 開発環境 SIMアプレットの活用事例 新たなSIMアプレットの開発 動機 開発技術の構成要素: プロファイル切替機能 開発技術の構成要素: エリア判定機能 各切り替え時のシーケンス 開発技術の検証 検証概要 検証結果 バグの修正 課題への対処 発信活動 おわりに はじめに こんにちは、イノベーションセンターの山田です。 私が所属するプロジェクトでは、NTT Communications株式会社 (以下、NTT Com) の有するアプレット領域分割技術を活用した新規技術の開発に取り組んでいます。 取り組みの1つが、2024年10月2日発表のニュースリリース「 ローカル5G網への接続と公衆モバイル網への接続を切り替え可能なSIMアプレットを開発 」で取り扱ったものです。 本記事ではSIMカードやSIMアプレット等の背景知識に触れたのち、開発した技術について説明します。 また、東日本電信電話株式会社 (以下、NTT東日本) と共同で実施したProof of Concept (以下、PoC) についても紹介します。 背景 SIMカード SIMカードはICカードの一種です。 スマートフォンやIoTデバイス等の端末で公衆モバイル網 (以下、公衆網) へ接続するときなどに必要となるもので、皆さんもスマートフォンとともに利用されているかと思います。 SIMカードの規格は大きさの違うものがいくつかあり、大きいものから順に1FF, 2FF (Mini SIM), 3FF (Micro SIM), 4FF (Nano SIM) となっています。 最近のスマートフォンで利用されているものの多くはNano SIMになります。 各規格については下図をご参照ください。 また、最近では端末と一体になったeSIMも広まりつつあります。 SIMカードの特長として耐タンパ性 1 の高さがあげられます。 ソフトウェアの観点では、SIMカード内部へのアクセスはいくつかの鍵によって多段に管理されています。 また、ハードウェアの観点では、SIMカードを物理的に開封するとチップの回路が破壊される構造になっています。 そのため、外部からの不正アクセスや情報の改ざんが困難です。 SIMカードは小さなコンピュータとしての側面も持ちます。 CPUやメモリ領域を保有し、OSが実装されています。 SIMカード上で動作するアプレットをSIMアプレットといいます。 SIMカードと端末はSim Toolkit (STK) という規格にそって通信します。 通信には Application Protocol Data Unit (APDU) コマンドが利用されています。 このAPDUコマンドをSIMカードが能動的に端末へ送ることはできず、端末がなんらかのAPDUコマンドを送りSIMカードがそれへ応答する形式になっています。 しかし、SIMカードが能動的に端末が持つ情報を要求したいといったことも想定されます。 そのために、Proactiveコマンドという仕組みが用意されています。 Proactiveコマンドは、FETCHというAPDUコマンドへの応答に載せることで、SIMカードから端末へと送られます。 下図は一連の流れを抽象化したシーケンス図です。 端末からSIMカードへAPDUコマンドが送られる。 SIMカードはAPDUコマンドへの応答として 91 XX を返す。ここで 91 XX は「APDUコマンドの実行に成功、かつ端末へ送りたいデータが XX バイトある」ことを意味する。 端末がFETCHを送る。 SIMカードはFETCHへの応答として実行したいProactiveコマンドを送る。 端末はAPDUコマンドの1つであるTerminal Responseを用いて、SIMカードへProactiveコマンドの実行許可を出す。 SIMカードはTerminal Responseへの応答として実行結果を送る。ここで Status Word: 90 00 は「Proactiveコマンドの実行に成功した」ことを意味する。 SIMアプレット SIMカードの論理構造は、通信プロファイル領域とアプレット領域に分けられます。 従来のSIMカードは通信プロファイル領域にアプレット領域が含まれていました。 この場合、通信プロファイル領域へアクセスするための鍵はSIM提供者によって管理されているため、ユーザが自由にアプレット領域を活用することは不可能でした。 これに対して、NTT Comは2つの領域を分割する技術であるアプレット領域分割技術を開発。 通信プロファイル領域の安全性は守りつつ、ユーザがアプレット領域に独自のSIMアプレットを実装できるようになりました。 本記事で紹介する各種アプレットは、この技術を活用して実装されています。 SIMアプレットのもっとも基本的な実装は、EventとProactiveコマンドを活用することです。 たとえば端末が圏外になったときや通信が4Gから5Gへ変更になったとき、FETCHによって端末からSIMカードへ対応するEventが通知されます。 特定のEventを受け取った際にProactiveコマンドを送信するプログラムを実装することで、独自の機能を追加していきます。 動作例 サンプルプログラムとして、Android端末のGUI上に表示されるHelloボタンを押すことでWorldというテキストがポップアップされるSIMアプレットを作ってみました。 SIMアプレットがインストールされたSIMカードをAndroid端末に挿入すると、STK Servicesというアイコンが表示されます。 なお、以降のGUIのスクリーンショットでは、端末としてXperiaを利用しています。 このアプリケーションを開いてみると、事前にSIMアプレット内で設定してあるメニューの一覧が表示されます。 今回は、Helloと表示されているメニューのみが表示されています。 Helloメニューをタップすると、下図のようにWorldというテキストがポップアップされます。 とても単純なプログラムです。このとき、次のような通信がSIMカードとAndroid端末の間で行われています。 2行目 (No.25) では SET UP MENU というProactiveコマンドを端末へ送っています。 名前の通り、前述したSTK Services内のメニュー画面をセットアップするためのコマンドです。 8行目 (No.702) では Menu selection というEventが端末から送られています。 これはHelloメニューをタップしたときのものです。 その直後、９行目 (No.703) では DISPLAY TEXT というProactiveコマンドを端末へ送っています。 このコマンドの中にWorldという文字列が含まれており、結果としてディスプレイ上にポップアップされます。 開発環境 通常では、前述のログのようなSIMカードと端末間で行われる通信を見ることはできません。 そこでsysmocom社が販売しているSIMトレースキットを用います。SIMトレースキットを使うことでSIMカードと端末間の通信をキャッチすることが可能になります。 物理構成としては、SIMトレースキットにSIMカードを挿入し、SIMトレースキットをFCPケーブルで端末と、Mini B-AケーブルでPCと接続します。 これにより、PCにインストールしたWireshark等のアプリケーションから、SIMカードと端末間の通信を見られるようになります。 SIMアプレットの活用事例 アプレット領域分割技術の活用事例をご紹介します。 一つ目がActive Multi-access SIM 2 です。 複数の公衆網のプロファイルを所持しており、基本的にはドコモ網へ接続しつつ、 ドコモ網にトラブルが発生した場合は他キャリア網へと接続先を切り替える、という機能が実装されています。 二つ目がキャッシュレス決済端末への導入 3 です。 従来は端末側で保存・処理していた機微情報をSIMカード側で行うことで、堅牢性を保ちつつ端末の製造コスト削減を実現しています。 新たなSIMアプレットの開発 動機 近年、事業へのローカル5G網 (以下、L5G網) の導入が広がっています。 L5G網は5Gネットワークの特長をもったネットワークを専有して運用できる一方で、その利用には制度的な難しさも存在しています。 電波法 4 やローカル5G導入に関するガイドライン 5 において、 端末がL5G網へ接続していい場所は事前に免許交付を受けたエリア (以下、エリア) 内に限定されています。 そのため、エリア外に端末を持ち出す場合は電源を落とす、もしくはSIMカードを抜くといった操作が必要となります。 もしエリア外でもインターネット接続が必要となる場合は、公衆網へ接続可能な別のSIMカードを用意しておき、手動で切り替える等の対処が必要となります。 また、たとえデュアルSIMスロット対応の端末であっても、GUIからSIMスロットを切り替える操作が必要となってしまいます。 このような操作が必要となることは、人が持ち運ぶ端末であっても運用コストを増加させ、時としてインシデントの原因となることが予想されます。 当然、人が付随しないIoT端末であればその運用を困難にします。 そのような状況の一方で、バスや電車に搭載されたIoTデバイスが、移動中は公衆網へ、事業所や各駅では分散配置されたL5G網へ接続し通信するユースケースが出てきています。 そのため、前述の課題に対する解決策となるような技術の開発が必要とされています。 開発技術の構成要素: プロファイル切替機能 この課題に対して、私たちはSIMカードが自律的にL5G網への接続と公衆網への接続を切り替え可能なSIMアプレットを開発しました。 本技術では、端末がL5G網へ接続しているときにエリア外へ出た場合、接続先を公衆網へと切り替えます。 公衆網への切り替えは、エリア外を示唆する特定のEventをトリガーとして行われます。 反対に、端末が公衆網へ接続しているときにL5G網を見つけた場合、L5G網へと切り戻します。 公衆網へ接続しているときでもSIMアプレットで事前に指定したPublic Land Mobile Network (以下、PLMN) 6 のL5G網を見つけた場合は接続を切り替えるようにすることで、 公衆網からL5G網への自動的な切り戻しを実現しています。 開発技術の構成要素: エリア判定機能 プロファイル切替機能により、L5G網と公衆網を自動で切り替えられるようになりました。 しかし、この機能のみではガイドラインに対応できません。 その理由は、エリア内となるL5G網 (以下、自社L5G網) とエリア外となるL5G網 (以下、他社L5G網) が同じPLMNを持つ場合があるからです。 SIMカードは同一PLMNの自社L5G網と他社L5G網を区別できないため、公衆網接続時に他社L5G網を見つけた場合、接続を試みます。 最終的に他社L5G網の基地局により接続を拒否されますが、接続を試みる行為自体がエリア外での端末の電波発射とみなされガイドライン違反となってしまいます。 そこでプロファイル切替機能内に、自社L5G網のエリア内かどうかを判定するエリア判定機能を実装、 エリア判定機能により自社L5G網エリアであると判定されない限り公衆網からL5G網への切り戻しが行われないように改修しました。 これにより、他社L5G網エリアでは接続を試みないようになりました。 各切り替え時のシーケンス 各切り替え時のシーケンス図を見てみましょう。まずはL5G網から公衆網の場合です。 ここで、SIMカードがアプレットとUSIMの2つのレイヤで表されていることにご注意ください。 USIMは端末とSIMカードのインタフェースとなるSIMカード内のアプリケーションです。 L5G網に接続している端末がエリア外に出た場合、それと対応する特定のEventが端末からSIMカードへ送られます。 それを受け取ったアプレットはプロファイルを設定する各Elementary File (以下、EF) 7 の内容を公衆網のものへ更新し、端末へEFの再読み込みと認証を要求します。 要求を受けた端末はEFを読み込みんだのち、公衆網へ接続を要求します。公衆網基地局で認証が受け入れられれば切り替えは完了です。 つぎに、公衆網からL5G網の場合です。 公衆網に接続時は、STATUSコマンドと呼ばれるAPDUコマンドを受信するEventをトリガーとし、定期的に位置情報を要求・取得します。 取得した情報をもとにエリア判定機能を走らせ、エリア外と判定された場合はそのまま公衆網へ接続し続けます。 もしエリア内と判定された場合は、L5G網を見つけしだい接続を試みます。 ただし、この時点ではSIMカード内のプロファイルが公衆網のままなため、接続は拒否されます。 一方で、端末はL5G網への接続を試みたとき、通信規格が変化したことを伝えるEventであるAccess Technology ChangeをSIMカードへ送ります。 このEventの値が0x0A=NG-RANの場合、アプレットはプロファイルを設定する各EFの内容をL5G網のものへ更新し、端末へEFの再読み込みと認証を要求します。 要求を受けた端末はEFを読み込みんだのち、ふたたびL5G網へ接続を要求します。 L5G網基地局で認証が受け入れられれば切り替えは完了です。 開発技術の検証 検証概要 6月から7月、開発した技術に対して1day×3回の動作検証を行いました。 本検証は、NTT東日本が運用するL5Gサービスであるギガらく5Gと、その環境が構築されているNTT中央研修センタ内のローカル5Gオープンラボを用いて行いました。 上図のように、台車に検証用端末 (Xperia 1VといったスマートフォンやNOKIA社およびHytecInter社のSIMカードを挿入できるゲートウェイルータ) などを乗せて移動することで、 ユースケースの移動体を模擬 ローカル5Gオープンラボから不感地域となるヘリポートまでを往復し、L5G網->公衆網->L5G網に接続が移り変わるようにしました。 残念ながら1往復で無事完了することはなく、梅雨の雨や酷暑の日差しの中、往復10分ほどの道のりを何度も行き来しました。 その甲斐もあって、最終的にプロファイル切替機能とエリア判定機能が正しく動作することを確認できました。 また本検証はエリア内の不感地域を利用するなど、エリア外で電波を発射することがないように計画し法令遵守のもとで行いました。 検証結果 前述したように、最終的には開発技術が正常に動作することを確認できました。 一方で、検証を繰り返す中でいくつかのバグや課題を発見、その都度修正を繰り返しました。 その一部をご紹介します。 バグの修正 事象1: L5G網へ接続しているときにローミングで接続する。 事象2: 公衆網へ接続しているときにL5G網へ接続を試みたあと、トリガーとなるEventである ”Access Technology Change” が端末から送られてこない。 原因: PLMNは正しい値を書き込んでいたが、桁数の設定に誤りがあり異なるPLMNとして扱われていたため、ローミング接続となっていた。 その結果、ギガらく5Gが接続の対象とならず、接続を試みないことからトリガーとなるEventも送られてこなかった。 対処: 桁数設定を5桁->6桁とすることで解決。 PLMNは3桁のMobile Country Code (以下、MCC) と2-3桁のMobile Network Code (以下、MNC)で構成されます。 MCCは国ごとに割り振られており、日本は440と441が割り振られています。 またMNCは国から事業者へ割り振られ、その運用は国が担っています。 運用上、440に属するものはMNCが2桁、441に属するものはMNCが3桁となっています。 ギガらく5Gを運用するNTT東日本には、441210という6桁のPLMNが割り振られています。 しかし、内部的な設定でPLMNの桁数を5桁としていたため別のネットワークとみなされ、接続や切り替えがうまく動作しませんでした。 わずか1バイトの設定項目のミスですが、それが大きなバグにつながることを実感しました。 課題への対処 事象: L5G網から公衆網への切り替えトリガーとなるEventを受け取ったあと、公衆網へ接続するまでに数分を要する。 原因: Eventを受け取る地点より遠い箇所でもL5G網の微弱な電波は届いており、 それを受信した端末がL5G網への接続を試みるも電波強度が基地局側で設定されている閾値を超えていないため失敗する、という動作を繰り返していた。 対処: SIMカードに備わった接続を禁止するPLMNを設定できる機能を利用。Event受け取り時にL5G網のPLMNへの接続を禁止することで接続を試みることがないようにした。 この改修により、切り替えに必要な時間は数分から数十秒まで縮まりました。 普段検証に利用していた田町ラボ環境では、作業の効率化のためにL5G網の電源を落とすことで擬似的にエリア外を作り出していました。 そのため、この課題を発見することができませんでした。 今回、より実環境に近い条件下での検証の意義をあらためて実感できました。 発信活動 本記事では私たちが開発した技術について紹介してきました。 さいごに、本技術に関する発信活動をご紹介します。 第一に、2024年10月2日にニュースリリースを行いました。 みなさんがご覧になれるのは、Webページに掲載された文面とオンラインで行なった1時間ほどのメディア向け説明会のみです。 しかしその裏では、1ヶ月以上かけて綿密な準備をしています。 NTT Comの広報室だけでなく、NTT東日本をはじめとした関連各所と連絡を取り合い、ニュースリリースの内容について精査しました。 背景に電波法などの法令やガイドラインが関わっていることもあり、内容の検討は入念に行いました。 結果として複数のWebメディアに記事が掲載され、良い外部への発信となりました。 第二に、2024年10月9日から11日にかけて開催されたdocomo business Forum’24 では、SIMアプレットを扱ったブースにて本技術に関するパネルも展示。 9日には開発チームのメンバーもブースに立ち、来場者の方々にSIMアプレット施策について説明しました。 また、本技術はNTT東日本の「ローカル5Gオープンラボ」で今後展示する予定です。 おわりに 本記事では、私たちが新たに開発した「ローカル5G網への接続と公衆モバイル網への接続を切り替え可能なSIMアプレット」について述べました。 現在、本技術の開発は技術検証の第一段階にあります。 今後は、最終的な商用化を見据えつつ、各機能の実装のさらなる検討や、関連各所と連携し法令・ガイドラインに反していないかの検証を進めていき、 2024年度の下期にはユーザーPoCによる受容性評価検証を実施する方針です。 L5G網は多くの特長を持つ5Gネットワークを専有でき、その活用は現在実用されているサービスのコスト削減や革新的なサービスの実現につながります。 しかし、その活用には技術面、制度面、費用面のさまざまな課題が存在します。 今回開発した技術は、その中でも制度的な課題を解決できるものです。 本技術のユースケースの一例として、バスなどの移動体にIoTデバイスを搭載しL5G網とモバイル網の両方を活用するものを前述しました。 ほかにも、公衆網をL5G網のバックアップ回線として利用するユースケースも想定しています。 L5G網が皆さまにとってより身近な技術となるよう、本技術の開発・改良を進めていきます。 内部の情報への不正アクセスに対する耐性のこと。 ↩ Active Multi-access SIMの詳細についてはこちらをご覧ください。 https://www.ntt.com/business/sdpf/service/icms/multiaccess.html ↩ キャッシュレス決済端末（クラウド型決済端末）への活用の詳細についてはこちらをご覧ください。 https://www.ntt.com/about-us/press-releases/news/article/2024/0409.html ↩ 電波法の詳細についてはこちらをご覧ください https://www.tele.soumu.go.jp/horei/law_honbun/72001000.html ↩ ローカル5G導入に関するガイドラインの詳細についてはこちらをご覧ください https://www.soumu.go.jp/menu_news/s-news/01kiban14_02000616.html ↩ 通信事業者、およびその電波の識別番号。 ↩ Elementary File。SIMカードは独自のファイル構造をもち、EFは一般的なPCのファイル構造におけるファイルの概念に近しい。 ↩

はじめに こんにちは、インターンシップ生の木戸です。普段大学院では、ヒトの認知科学に関する研究をしています。 8/26-9/6までの2週間、『超低遅延ライブ配信技術を活用した、新規ライブ配信サービスを実現する技術の開発』というテーマの下、NTTコミュニケーションズの現場受け入れ型インターンシップに参加しました。 この記事では、私がお世話になったプロジェクト／インターンシップで取り組んだ業務体験内容について紹介していきます。 なお開発に利用したアバターは IZUMO.com さんのAilisを利用しております。 Fan creation of Ailis by IZUMO.com 目次 はじめに 参加のきっかけ 配属されたプロジェクトチームについて インターンシップのスケジュールについて インターンシップでの業務体験内容 1. モーションデータの取得 2. アバターの顔の動きの実装 3. 姿勢推定を用いた腕の動きの実装 おわりに 参加のきっかけ 私がインターンシップに参加した一番のきっかけとしては、自身が動画編集を日常的に行っているという背景から、 ライブ配信技術 に興味があったからです。 HPや説明会だけでは絶対に得られないような開発プロセスを体験 ライブ配信技術という技術の斬新さに触れる 新規価値を創出することの面白さを体感 したいと思い、インターンシップに応募しました。 配属されたプロジェクトチームについて 私が今回お世話になったチームでは、WebRTC技術を活用した超低遅延ライブ配信サービス（ Smart vLive ）を用いて、「超低遅延を活用してどのようなライブ配信が可能か？」について諸技術の開発に取り組んでいます。 Smart vLive とは、1秒未満の低遅延で映像配信が可能なライブ配信プラットフォームで、リアルタイムなコミュニケーションを含むイベント配信を可能にするサービスです。 インターンシップのスケジュールについて 日程としては、冒頭でも述べたように8/26-9/6の10日間（土日除く）でした。具体的には次の通りです。 8/26 午前：全体でのオリエンテーション、午後：業務体験内容の概要説明、夜：懇親会 8/27 午前：具体的な業務内容の説明を受ける、午後：開発を開始（9/6 午前まで継続） 9/6 午後：業務体験報告と最終オリエンテーション また、開発業務の他には配属チームが開催している以下のイベントにも参加させていただきました。 8/28 Media over QUIC（MoQ）に関する勉強会 8/29 Smart vLiveを用いたインタラクションライブ 普段の研究室での活動だけでは、絶対に出会えないような方々とコミュニケーションをとる機会を頂き、貴重な経験を得ることができました！ インターンシップでの業務体験内容 インターンシップでは、VTuberライブにおいて、リアルタイムで双方向的なライブを実現するためのクライアントレンダリング型デモのフロントエンド部分を実装しました。 現在のVTuberライブ配信は、 送信側 でアバターのモーションデータを映像に変換したものを配信しています。しかしながら、この場合、受信側の環境／操作に応じてアバターのアングルを変えるなどのメタバース（XR）への適用が難しいという課題があります。以上の背景から、『MoQという新しいメディア転送プロトコルをVTuberライブに適用することで、双方向的なライブを実現しよう！』というのが大きな目的です。 デモの大まかなイメージとしては次の図になります。 送信側は以下のデータを取得し、MoQTを用いて送ります。 映像データ：PCに接続されたWebカメラから取得 音声データ：PCに接続されたマイクから取得 モーションデータ：Google社の MediaPipe を用いて顔のランドマーク、姿勢のランドマークを取得（取得イメージ：図中の①） 受信側では、送信側から受け取った上記3種類のデータを基にアバターを再構成します（再構成イメージ：図中②）。 次に実際に取り組んだ内容を大きく3つに分けて説明していきます。 1. モーションデータの取得 まず、送信側で顔のモーションデータを取得します。 インターンシップでの業務体験内容 で述べている通り、モーションデータの取得にはGoogle社の MediaPipe という機械学習ライブラリを使用しました。Webカメラのみで、フレーム内の顔と顔の特徴を検出可能で、検出した顔の特徴点はX軸、Y軸、Z軸での値を持つ3次元空間上の値として渡されます。 以上のように取得したモーションデータを用いて、アバターの顔・腕の動きを実装していきます。 2. アバターの顔の動きの実装 次に、アバターの顔の動きの実装です。 瞬きや口の動きなどの実装には、ピクシブ社が提供している @pixiv/three-vrm を使用しました。 @pixiv/three-vrm はthree.jsを使ってブラウザ上でVRM（ドワンゴ社が提供するオープンソースの人型3Dモデル用ファイルフォーマット）を読み込んで表示するためのライブラリで、ピクシブ社がオープンソースで提供しています。 アバターの顔の動きを表現するために利用するモーションデータはWebカメラから取得した顔の映像の各ランドマーク（物体を表現する為に定めた特徴点）に対して3次元空間座標の配列として提供されるので、アバターの顔のランドマークとの対応を把握することが不可欠です（例えば、瞬きの実装ならば目に関するランドマークの対応を把握するなど）。また顔のモーションデータはランドマーク毎にインデックス番号が付与されていることから、顔のモーションデータのランドマークのインデックス番号をWebカメラから取得した顔の映像に重ねて表示して、対応するアバターのランドマークを特定していきました。表示させた状態のスクリーンショットを撮影していなかったので、代わりにGoogle社から公式に公開されているインデックス番号の位置を示すガイド画像で示すと、（数字が小さすぎて見え辛いですが）以下の画像のようにインデックス番号が割り当てられていることが分かりました。 ( Google社 MediaPipeの顔のランドマーク検出ガイド より) 次にインデックス番号を用いて取得した顔の座標データをもとに以下の値を算出し、それらをアバターの動きに適用しました。 目の開き幅 口の開き幅 首の傾き（X方向、Y方向、Z方向） その結果が下の動画です。 しかしながら、見ていただけると分かるように、このままだと首だけが異様にグルグル回る不自然な動きになってしまっています。 そこで、 胴 ・ 脊髄 の動きを首の動きに対応させることで、より人間らしい動きに近づけられました。 3. 姿勢推定を用いた腕の動きの実装 最後に、アバターちゃんで手を振りたい！ということで姿勢推定を用いた腕の動きの実装に移りました。 2. アバターの顔の動きの実装 で使用した顔のランドマーク同様、まずは姿勢のランドマークのインデックス番号をWebカメラから取得した映像に重ねて表示をし特定していきました。こちらも、表示させた状態のスクリーンショットを撮影していなかったので、公式が出しているガイドを下に示します。 ( Google社の姿勢のランドマーク検出ガイド より) すると、上記のように割り当てられていることが分かったので、インデックス番号を用いて腕に関する座標データ（今回は時間の関係で左腕のみの実装なので[11][13]）を取得し、腕の傾きを算出しました。 そして、その値を上腕の動きに適用し、最終的には下のアバターのような動きを実装しました。 実際に姿勢を推定したところ、値のブレが少し大きかったため、アバターの腕の動きが小刻みに震えてしまっています。そこで、何秒間かの値の平均値をとることにより、滑らかな動きを実現できるのではないかと考えています。（上長に伺ったところ、ロボット制御の要領で対応可能だというアドバイスを頂きました） おわりに 今回のインターンシップにおいて、最初はネットワークの基本的な知識しか身についておらずWebRTC／MoQに初めて触れる状態からのスタートだったのですが、上長の小松さん・トレーナーの河合さんに説明していただき、また質問があるときには丁寧に対応していただいたことでMoQや実装に関して理解を深められました。最終的にはアバターに自然な顔の動きの実装、時間の切れで途中までになってしまいましたが姿勢データを使った動きの実装ができ、満足のいくデモに仕上げられました。しかし、正直なところアバターで手を振りたかったので、その実装までいけなかったのが少し悔やまれます。私自身のプロトコルや実装に関する知識がもう少しあれば、手を振る実装まで効率的に進められたかもしれないので、今回の経験を胸に今後も精進していきたいです。 インターンシップではさまざまなイベントを通して多様なバックボーンを持つ方々にお話を伺えて、自分が実際に働いている明確なイメージを持つことができました。また、多くの出会いとその方たちとのお話を通じて、自分の長所や短所を再確認できました。この経験を今後の学校生活／研究活動／就職活動に活かしていきたいです。 今回お世話になりました、小松さん、河合さん、本当にありがとうございました！

この記事では、NeWork の開発チームがフルリモート環境でアジャイル開発するにあたり個人的に重要だと感じた部分を紹介します。 目次 目次 はじめに 背景 NeWork のチーム構成と動き方 コミュニケーションの工夫 オンラインの人を取り残さない各種ツールの利用 各種打合せ アイデア出し・情報共有・レトロスペクティブ 開発作業 話しやすいチームの文化づくり オープンな打合せ 話しかけやすく・呼び出しやすい環境 常に会話できることで雑談 データでみるコミュニケーション量 まとめ おわりに はじめに こんにちは、 NeWork 開発チームの加藤です。私は普段、オンラインワークスペースサービス NeWork の開発エンジニアをしています。 NeWork は、手軽に話しかけることを重視したオンラインワークスペースサービスです。従来の Web 会議ツールとは異なり、話したいメンバーとすぐに話すことができるなど、リアルに近いコミュニケーションが可能です。 私たち NeWork チームは、フルリモートでアジャイル開発をしています。コミュニケーションが重視されるアジャイル開発において、フルリモート環境でどのように工夫しているのか、NeWork チームの開発方法を事例の 1 つとして紹介します。 背景 NeWork のチーム構成と動き方 NeWork チームは、大きく以下の 4 つの役割に分かれています。 プロダクトオーナー (PO) 開発メンバー デザイン担当 プロモーション担当 PO と開発メンバーは、その時々の対応するテーマやデバイスに応じて 5 つのチームに分かれて開発しています。各チームは開発メンバー 2 ~ 5 名程度と PO の小規模で構成しており、チームごとに必要なコミュニケーションを取りながら開発を進めています。 開発手法はチームごとに異なりますが、基本的にはスクラムをベースとしたアジャイル開発を実施しています。チームが複数あるため、基本のスクラムイベントのほかにチームを跨いだ全体の振り返りや、チーム間の情報共有のためのミーティングなどを追加しています。 例えば特定チームの PO と開発メンバーのみでリファインメントをしたり、開発メンバーの間での情報共有のための朝会をしたりしています。 各チームメンバーは朝の 9 時から、プロダクト方針やプロモーションに関わる議題を中心としたプロダクト朝会・当日のイベントや打合せスケジュール等の事務連絡中心の全体朝会を行い、その後各チームに分かれてチームごとの朝会やリファインメント、スプリントプランニングを行います。 さらに、開発メンバーはチームごとの朝会(デイリースクラム)や開発メンバー全体の共有相談などを行ってから開発作業に入ります。 コミュニケーションの工夫 リモートワークをする上でよく聞く、雑談のきっかけが生まれない・相手のリアクションがみえないなどの理由による「コミュニケーションが取りづらい」という問題を解決するために、NeWork チームでは以下のように工夫しています。 オンラインの人を取り残さない各種ツールの利用 話しやすいチームの文化づくり オンラインの人を取り残さない各種ツールの利用 NeWork の開発・打合せは、全てオンラインで完結できるようにツールを導入しています。そのため職場やオフィスにいる人と、リモートで働いている人との間に情報量の差が生まれない構成となっています。 特にアジャイル開発をする上で重要な場面について、どのようなツールを使っているかを紹介します。 各種打合せ スプリントレビューやリファインメント、スプリントプランニングなど、各種スクラムイベントは、全て私たちの開発しているツール NeWork 上で行っています。会議 URL の共有なども不要でスムーズに打合せが可能です。 打合せの記録には Notion・Google Drive・Confluence などを、プロダクトバックログの管理には Jira を利用して、メンバーであれば誰でもアクセスできるようにしています。 一般的にオンラインの打合せでは、メンバーのリアクションが見えにくく打合せに参加しているのか分かりづらいという問題があります。NeWork チームでは以下のような工夫でこの問題を軽減しています。 例えばリファインメントでは、Product Backlog Item (PBI) のタイトルを NeWork 上のルームメッセージとして投稿し、その PBI について各メンバーが「考え中・質問あり・Ready」の ルームリアクション をつけるようにしています。これによりオンラインでもメンバーのリアルタイムな考えを把握しやすくしています。 またいくつかの打合せでは、Notion のコメント機能などを利用してリアルタイムに複数のメンバーが意見を表明しやすいようにしています。そのためよくある、「皆さんどう思いますか？」などのメンバーのリアクション確認を会議内で挟むことなく議論を進めることができます。この方法では他メンバーもコメントに返信できるため、ちょっとした質問などは相互に回答できるので打合せをスムーズに進められています。 アイデア出し・情報共有・レトロスペクティブ NeWork チームでは上記の他に、Miro も打合せのツールとして利用しています。 Miro をオンライン上のホワイトボードとして、主に付箋を使って視覚的な情報共有や、アイデア出しを行っています。レトロスペクティブなどフレームワークを利用する場合や、図形・フローの認識合わせなどにも利用しています。 Miro の各ボードは URL を持っているので、そのまま関連する PBI に張り付けたり、Slack で共有したりしています。またレトロスペクティブの際に重要な事項などは前説として毎回説明しています。これらは自分たちでテンプレートとして作成し使い回しています。 このようにオンラインホワイトボードならではの強みを活かして利用しています。 開発作業 開発については、GitHub を使ってコード管理・レビューをしています。開発中にペアプログラミングを実施する際には、Visual Studio Code の Live Share を使いリアルタイムでコードを共有しています。 開発中の動作確認時や不具合の発生時などには、NeWork 上で複数人の映像をお互いに表示しあうことで、環境ごとの違いを確認したり、よりスムーズに相手の状況を把握しながら開発しています。 話しやすいチームの文化づくり フルリモートでのアジャイル開発において円滑なコミュニケーションは重要です。NeWork チームでは、話しかけやすいチームの文化を作るために以下のような取り組みを行っています。 オープンな打合せ NeWork チーム内の打合せは、誰でも参加したり、聞いたりしてよいという文化になっています。この文化形成は NeWork の仕様によるものもありますが、リモートでのコミュニケーションを取りやすくするために重要だと考えています。 一般的な打合せツールの場合は、打合せに途中から入るにはいくつか物理的・心理的なハードルがあります。 例えば物理的には打合せ URL の共有の手間があります。また、心理的には打ち合わせ途中に参加することですでに打ち合わせをしていた人たちの話の流れを切ってしまわないかという不安などによるハードルがあります。 NeWork の場合は 聞き耳機能 があるため、自分が打合せに主体的に参加するのではなく、聞いているだけであることを表明できます。これによって、興味のある話を聞きにいくハードルを下げています。 この結果、自分の興味のある内容について情報を得たり、他のチームの活動を知ることができます。聞き耳中の打合せ内容に自身の知見があれば、 ルームメッセージ でコメントを送ることや聞き耳から打合せに参加変更することで、自分の意見を発信できます。 このように誰でも参加できるオープンな会議環境を作ることで、心理的安全性を確保できるので周囲の人を巻き込みやすい環境が作られていますと考えられます。 話しかけやすく・呼び出しやすい環境 朝一にチームメンバーが NeWork 上で打合せに参加するため、30 人以上いるチームメンバーのほぼ全員が常に NeWork を開いています。そのためオンラインツールでよくある、ツール上に人が居らず気軽に話しかけることができないという問題はほとんど発生しません。 また、通話を歓迎する「ウェルカム」や集中していることを示す「ゾーン」の 会話ステータス を設定したり、 ひとことを表示する機能 に退席中や作業中などの状況を表示したりできます。打合せやペアでの開発作業も NeWork 上で行うことが多く、その人が何をしているか分からないということもありません。NeWork 以外での打合せがあっても、 NeWork 上から Outlook の予定や Teams 会議中かどうかを確認でき、相手の状況を把握できます。 これらの文化や機能が、話しかけやすい環境を作るベースになっていると思います。 例えばとある日の NeWork オンラインメンバー数の分かる画像を以下に示します。開発メンバーが検証用に複数アカウントを使っていたりするため、実際のメンバー数よりも多く表示されていますが、大体 40 アカウントほどがオンラインであることが分かります。 開発中にデザインの疑問が生じたり、PO に確認したいことがある場合、事前にテキストコミュニケーションで今相談できるか確認することもありますが、基本的には呼び出してみることが多いです。 NeWork チーム全体として、気軽なコミュニケーションを重視していることもあり、呼び出しに対して好意的な反応を返してくれるメンバーが多いです。 またメンバーによっては常に 1 人でも NeWork のルームに参加していることで、他のメンバーが話しかけやすい環境を作っています。他メンバーはルームに参加して話すことができるため、リモートでも気軽にコミュニケーションできます。 NeWork 上では、メンバーが打合せ中なのか・他の打合せを聞いているだけなのか・忙しいのかなどの情報がリアルタイムにわかるため、相手の状況を考慮しつつ相談できます。また緊急度が高い場合は、作業中や打合せ中であっても、その打合せに参加してメッセージを送ることで、すぐに相談するようにしています。 常に会話できることで雑談 NeWork の開発チームでは、雑談によるコミュニケーションを重要視しています。 リモートワークでよく使われる Teams や Zoom などは、打合せごとに URL が変わるので、打合せ終わりや会議室までに移動時間の雑談がなくなるという話をよく聞きます。それに対して、NeWork チームでは Slack と NeWork を使って雑談を促進しています。 NeWork 上での打合せは、同じルームにて連続で予定していることがあります。例えばプロダクトの朝会とチーム全体の朝会は同じルームで続けて実施しています。このようなときは、それぞれの打合せが早く終わったタイミングや、次の打合せまでの合間の時間を使って、他のメンバーと雑談できます。 また NeWork 上には ひとことを表示する機能 があり、その日の予定・今何をしているのかなどのちょっとしたことを共有できます。打合せの隙間にこれらを話題のタネとして雑談することもあります。 それ以外にも Slack 上に雑談チャンネルを作成しています。その雑談チャンネルは業務に関係ない話題から、業務に関係ある課題など、幅広い内容が気軽に投稿されています。 Slack 上の話題にはスタンプでのリアクションやリプライも自由に行えるため、気軽にコミュニケーションを取っています。 このような雑談から、他のメンバーのことを知ることができ、前述の話しかけやすい環境を作ることにも繋がっています。また打合せをするほどではない内容なども円滑に共有できるため、幅の広いコミュニケーションを取ることができています。 データでみるコミュニケーション量 実際に NeWork チームがオンライン(NeWork 上)でどの程度コミュニケーションを取れているのかを数値化した結果を以下に示します。NeWork のワークスペースにて、2人以上が同じルームに参加している時間・回数をそれぞれコミュニケーション時間・回数として集計しています。 チーム内の 1 週間のコミュニケーション時間（ある月の平均）：187.5 時間 チーム内の 1 週間のコミュニケーション回数（ある月の平均）：368.7 回 チーム内の 1 回あたりのコミュニケーション時間（ある月の平均）：0.5 時間 NeWork 以外のチームとの比較はできませんが、リモートでも頻度の高いコミュニケーションを取ることができていると感じています。 まとめ NeWork チームでは複数のオンラインツールを使うことや、オープンな打合せ・雑談によるコミュニケーション・呼び出しやすい環境作成などの文化によって、フルリモートでもコミュニケーションを取りやすくしています。 一方で新規メンバーが参加した際には、さまざまなツールを利用しているため事前準備やツールの使い方の説明が多く必要になることもあります。 しかし全体的にみると、リモート環境でも対面で集まるよりもコミュニケーションを取りやすく、またリモート環境ならではのメリットを活かして、職場で集まるよりもより便利な環境が作れています。 アジャイル宣言の背後にある原則 には、「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。」という記述がありますが、NeWork チームでは、オンラインでも効率的に進める工夫によって、フェイス・トゥ・フェイスに勝るとも劣らないコミュニケーションを取ることができています。 おわりに この記事では、NeWork チームがフルリモートの環境にてどのように開発を工夫しているのかについて紹介しました。 NeWork はどなたでも無料でお試しできますので、もし興味を持っていただけたらぜひ触ってみてください。

こんにちは、NTTドコモグループの現場受け入れ型インターンシップ2024に参加させていただきました、佐藤と鈴木です。 本記事では、現場受け入れ型インターンシップ「D1.攻撃者視点に立ち攻撃技術を開発するセキュリティエンジニア」での取り組み内容について紹介します。NTTドコモグループのセキュリティ業務、とりわけRedTeam PJに興味のある方への参考になれば幸いです。 目次 目次 RedTeam PJの紹介 参加に至った経緯 インターンシップ概要 ローコード・ノーコードとは 検証業務 Power Pwnの概要 PowerDump reconコマンド dumpコマンド 条件や制約の調査 dumpコマンドの制約 検証まとめ 感想 おわりに RedTeam PJの紹介 私たちは、NTTコミュニケーションズ イノベーションセンター テクノロジー部門 RedTeam PJのポストに参加しました。RedTeam PJでは主に次の業務を行っています。 RedTeamサービスに資する攻撃技術や、先進的な攻撃技術の調査・研究・開発 攻撃自動化ツールの開発 社内グループ向けRedTeam業務・技術支援 RedTeam PJの活動や、過去のインターン生の体験記については下記資料をご覧ください。 The Dark Playground of CI/CD: Attack Delivery by GitHub Actions MITRE ATT&CK Contribution - T1562.009 Safe Mode Boot Pool Partyという攻撃手法を通じてWindowsの深淵を覗いた７日間（インターンシップ体験記） 参加に至った経緯 私たちの背景と参加経緯についてお話しします。 佐藤 RedTeam PJはどんな業務をおこなっているのか、またオフェンシブセキュリティにも興味があったので、攻撃技術の調査・検証の業務を体験できるポストに参加しました。 鈴木 普段は大学院にて、おとりシステムに関する研究を行っています。 オフェンシブセキュリティに興味を持っており、RedTeamとしての研究開発業務を体験したいと考え応募しました。 インターンシップ概要 インターンシップは8/26から9/6の10日間で行われました。オリエンテーションや成果報告会を除くと実質的な期間は8日間でした。初日と最終日に出社し、それ以外の日はリモートで実施しました。 取り組んだテーマは、「 ローコード・ノーコード (LCNC) への攻撃技術検証 」です。 私たちはどちらもLCNC自体がほぼ未知の領域であったため、LCNCの概要やそのセキュリティを知るところからスタートしました。 攻撃技術検証としては、Microsoftが提供するLCNC開発プラットフォームであるMicrosoft Power Platform 1 への攻撃ツール、 Power Pwn 2 の検証業務を行いました。 本記事では、検証業務の一部を紹介します。 ローコード・ノーコードとは ローコード・ノーコードとは、従来の人手によるコーディングに代わり、GUIを介してアプリケーションを簡単に作成できる開発手法です。LCNC開発プラットフォームとして、Microsoft Power Platformなどがあります。 LCNC開発プラットフォームは、ビジネスアプリケーションの迅速な配信を可能にします。一方、LCNC開発プラットフォームが組織で広く使われるようになると、開発されたアプリケーションには潜在的なセキュリティの脆弱性が入り込むリスクが高まります。 非営利団体OWASPがLCNCのセキュリティリスクや関連する課題、解決方法をまとめた文章として、 OWASP Low-Code/No-Code Top 10 3 があります。 検証業務 検証業務では、まずPower Pwn自体がどのようなツールであるかの調査から始まりました。 Power Pwnの概要 Power Pwnは、Microsoft Power Platformに対する攻撃的・防御的なセキュリティツールセットです。 ツールに関する講演 4 がBlackHatやDEFCONなどのカンファレンスで行われています。 このツールは複数のモジュールから構成されますが、今回のインターンシップでは PowerDump というモジュールに焦点を当て、検証しました。 PowerDump PowerDumpは、Microsoft Entra IDのユーザーアカウントを起点に、テナント内で必要以上のユーザーに対して共有（以降、過剰共有・過剰に共有と記載）されているアプリやコネクタを列挙し、データのダンプを行うツールです。ここでは、アプリと企業のビジネスデータSQLサーバが接続されている例として示します。 下記のような構成のアプリケーションを想像してください。 アプリとSQLサーバの接続を実現するコネクタというものがあり、コネクタにはSQLサーバの認証情報が含まれています。この時、コネクタが過剰に共有されていると、これを悪用してSQLサーバからのデータ取得が可能になります。 このコネクタなどの過剰共有を調査し、データのダンプまでをツール化したものがPowerDumpになります。 攻撃の流れは次の通りです。 テナントへのアクセス権があるユーザーアカウントを用意する。 AADInternals 5 を利用し、ユーザーアカウントからテナントIDを調査する。 Power Pwnを用いてreconコマンドを実行する。 PowerDumpを用いてデータを取得する。 reconコマンド reconコマンドでは、テナント内で過剰に共有されているアプリやコネクタを列挙できます。 図は実際にreconコマンドを実行し、GUIで確認した場合の例です。 過剰に共有されたコネクタに紐づく認証情報が確認できます。 dumpコマンド dumpコマンドでは、reconで取得したコネクタの認証情報を用いて、データのダンプを行うことができます。 図は実際にdumpコマンドを実行し、CLIで確認した場合の例です。 SQLサーバから、各テーブルデータをダンプできることが確認できます。 無意識にコネクタの過剰共有を行っていると、このように情報漏洩のリスクにつながります。対策のためには、適切な共有範囲の設定が重要になります。 条件や制約の調査 検証業務の後半では、PowerDump実行にあたり条件や制約はあるかについて、ソースコードや実際の動作から調査しました。今回は調査から新たに分かった知見について、一部紹介します。 dumpコマンドの制約 RedTeamがdumpコマンドを利用する場合、次のことが制約条件になります。 dump対象はコネクタが共有可能設定のものに限定されること コネクタには共有可能/不可の2種類の設定があり、コネクタの作成者が設定します。 dumpコマンドによりデータダンプ可能なコネクタは、共有可能に設定されているものに限定されます。 コネクタは現在1200種類以上ありますが、この制約条件により現在データダンプ可能なコネクタは約60種類に絞られます。 RedTeamでは通常何らかの方法で内部ユーザーアカウントを獲得し、その内部ユーザーが保有している機密情報の取得を試みます。しかしコネクタについては内部ユーザーが所有しているものであったとしても、この制約条件を満たせないためにデータダンプできない場合が考えられ、データダンプを目的とした攻撃シナリオに制限がかかります。 ちなみに現在dumpコマンドがサポートしているデータダンプ可能なコネクタは5種類に限定されています。 ここではdumpコマンドの制約について記載しました。 一方でソースコードを確認した結果、コネクタによるデータ操作は実際にはAPI操作によって実現していることがわかりました。 このことから、現在はdumpコマンドがサポートしていないコネクタであったとしても、独自にAPI操作を実装することでdumpコマンドによるデータダンプを可能にできます。 検証まとめ 今回の検証により、RedTeamとしてPowerDumpの利用をまとめると次のようになります。 LCNCのセキュリティを評価する reconコマンドで過剰に共有設定がされていないかを評価することは可能。 LCNCを利用して、情報漏洩シナリオを評価する dumpコマンドが利用できるコネクタには制限がある。独自にAPI操作を実装することで対応は可能。 感想 佐藤 LCNCとそのセキュリティやプラットフォームへの攻撃ツールの調査・検証を通してRedTeam PJの業務について知ることができ、成長することもできました。対象の知識が全くなかったので苦労もありましたが、調査・検証をおこない、無事報告することができてよかったです。 鈴木 LCNCのセキュリティに関しては全く知見がなかったため、インターンシップを通して新たな領域に触れることができ、とても楽しかったです。検証業務としては、序盤は既存のトレースも多く限られた時間で成果を出す難しさを感じていましたが、トレーナーさんのサポートもあり、なんとか形にすることができ、よかったです。 おわりに 今回は、NTTドコモの現場受け入れ型インターンシップ2024「D1.攻撃者視点に立ち攻撃技術を開発するセキュリティエンジニア」での取り組みについて紹介しました。 トレーナー、上長をはじめとするRedTeam PJの皆さまには大変お世話になりました。ありがとうございました。 AI 搭載ローコード ツール | Microsoft Power Platform ↩ GitHub GitHub - mbrg/power-pwn: An offensive security toolset for Microsoft ↩ OWASP Low-Code/No-Code Top 10 | OWASP Foundation ↩ Black Hat All You Need is Guest ↩ GitHub GitHub - Gerenios/AADInternals: AADInternals PowerShell module ↩

みなさんこんにちは、イノベーションセンターの益本 (@masaomi346) です。 Network Analytics for Security (以下、NA4Sec) プロジェクトのメンバーとして活動しています。 この記事では、2024年9月14日に開催されたセキュリティ・ミニキャンプ in 愛知 2024で、講師として参加したことについて紹介します。 ぜひ最後まで読んでみてください。 NA4Secについて セキュリティ・キャンプについて 参加者から講師に 担当した講義について 講師をしてみて 学生の方へ 出張講演承ります NA4Secについて NA4Secは、「NTTはインターネットを安心・安全にする社会的責務がある」を理念として、インターネットにおける攻撃インフラの解明・撲滅を目指した活動をしているプロジェクトです。 NTT Comグループにおける脅威インテリジェンスチームとしての側面も持ち合わせており、有事において脅威インテリジェンスを提供し、意思決定を支援することもあります。 イノベーションセンターを中心として、NTTセキュリティ・ジャパンやエヌ・エフ・ラボラトリーズ（以下、NFLabs.）からもメンバーが参画し、日夜攻撃インフラを追跡しています。 セキュリティ・キャンプについて 一般社団法人セキュリティ・キャンプ協議会とIPA(独立行政法人情報処理推進機構)が主催しており、学生に対して情報セキュリティに関する高度な技術教育を実施し、次代を担う情報セキュリティ人材を発掘・育成することを目的にしたイベントです。 セキュリティ・キャンプ 毎年8月に開催されているセキュリティ・キャンプ全国大会は、選考課題を突破した学生にハイレベルな専門講義が実施されています。 また、選考倍率も5倍以上となっており、学生から非常に人気のあるイベントとなっています。 全国大会以外に、セキュリティ・ミニキャンプ(地方大会)と呼ばれるものがあります。 セキュリティ・ミニキャンプは、全国各地で開催されており、1~3日間の短期間で専門講義を実施しています。 セキュリティ・キャンプ全国大会と同様、参加するには選考課題を突破する必要があります。 ただし、全国大会と比べると難易度は易しめとなっているため、セキュリティ初学者も参加しやすくなっています。 今回私は、名古屋大学で開催されたセキュリティ・ミニキャンプ in 愛知 2024に講師として参加してきました。 セキュリティ・ミニキャンプ in 愛知 2024が始まりました！オープニングでは、一般社団法人セキュリティ・キャンプ協議会ステアリングコミッティによるセキュリティ・キャンプの紹介が行われ、続いて講師と受講生がアイスブレイクを楽しみました。 #seccamp pic.twitter.com/lamcTHlrUn — セキュリティ・キャンプ (@security_camp) 2024年9月14日 参加者から講師に 私は、学生の時にセキュリティ・キャンプ全国大会へ参加していました。 参加してからも、さまざまなことを経験し、セキュリティ業界に飛び込みました。 そうしているうちに、いつかセキュリティ・キャンプのコミュニティに貢献したいと思うようになりました。 そんな時に、修了生コミュニティ経由でセキュリティ・ミニキャンプの講師をする機会をいただくことができました。 少しでもコミュニティに貢献できて良かったです。 担当した講義について 「Phishing Analysis ～ フィッシングサイトの仕組みを学ぶ」という講義を担当しました。 次は、NTTコミュニケーションズ株式会社 益本 将臣氏による『Phishing Analysis ～ フィッシングサイトの仕組みを学ぶ』です。フィッシングサイトの仕組みやエコシステムを学んだ後、チームでフィッシングサイト構築ツールのフィッシングキットの脅威解析を実施し、解析結果を発表しました。 #seccamp pic.twitter.com/Ntiim8aNAR — セキュリティ・キャンプ (@security_camp) 2024年9月14日 名前の通り、フィッシング詐欺を題材に扱った珍しい講義となっています。 具体的な分析手法とかではなく、フィッシング詐欺の仕組みの紹介に重点を置いています。 フィッシング詐欺がどのように行われているのか スミッシングの仕組み フィッシングサイトを分析すると何がわかるのか フィッシングサイトがどのように構築されているのか etc. なぜこの講義にしたのかというと、(私が調べた限り)今までのセキュリティ・キャンプでフィッシング詐欺を取り扱っている講義がなかったので、こういうのもあると面白そうだと思ったからです。 また、講義だけでなく、ハンズオンも実施しました。 フィッシングサイトの構築に使われているツールであるフィッシングキットを分析し、分析レポートを作成して発表するといったものです。 フィッシングキットを分析することで、どのようにクローキングをしているのか、どのように窃取した情報を攻撃者に送信しているのか理解できたかと思います。 フィッシングキットを分析する機会はなかなかないと思うので、いい経験をしてもらえたのではないかと思います。 また、グループで分析を進めることで、受講者同士でいい刺激になったかと思います。 特に大きなトラブルもなく終わることができて良かったです。 講師をしてみて ハンズオン形式の登壇は初めてでしたので、時間配分だったり、ハンズオンの難易度が適切なものか少し不安でした。 そのため、頭の中でのシミュレーションを何度も繰り返すなどして、入念に準備しました。 いざやってみると、特に問題なく進めることができ、ハンズオンもみんなついていけてそうだったので良かったです。 受講者アンケートの結果を見ても、「大変満足した」と「満足した」の回答ばかりで、この内容でやって良かったと思えました。 また講師をする機会があった場合は、内容を改良しつつ、より満足していただける講義にしていきたいと思います。 チューター・運営スタッフの方々にも、さまざまなことをサポートしていただきました。 本当に感謝しています。 学生の方へ セキュリティ・キャンプ関連のイベントはこれからも開催されます。 興味を持った方は、ぜひ挑戦してみてください。 ご応募お待ちしております。 セキュリティ・キャンプ全国大会 セキュリティ・ミニキャンプ(地方大会) 出張講演承ります セキュリティ・キャンプは定員があるので、受講できる人に限りがあります。 また、せっかく作成したコンテンツを1回で終わりにするのはもったいないので、出張講演なども前向きに検討します。 興味のある方はNA4Secプロジェクトまでお気軽にご相談ください。

この記事では、できるだけアクセスを絞るべき本番環境に対して、かのシンデレラのように時間制限つきの承認性アクセスができるようにした事例を紹介します。 目次 目次 はじめに 背景 複数の環境 これまでの運用 課題 実現方法 実装 - Google Cloud IAM 設定スクリプト 設定 - GitHub Environments 実装 - GitHub Actions その他細かな工夫点 ゴミ掃除 Slack 連携 サービスアカウントキーの発行 運用を変えてみて おわりに はじめに こんにちは、 NeWork 開発チームの藤野です。普段はオンラインワークスペースサービス NeWork のエンジニアリングマネジメントをしており、最近では実際にコードを書く機会も増えてきています。 この記事では、これまで手動 + ガッツで運用していた本番環境へのアクセス管理の工程のほとんどを自動化した内容をご紹介します。 背景 複数の環境 他のよくあるWebサービスと同様に、NeWork においてもサービスの運用・開発をするにあたって以下の3種類の環境を用意しています。 開発環境 ステージング環境 本番環境 開発環境・ステージング環境については開発メンバーは普段からフルアクセスできるようにしていますが、本番環境についてはセキュリティ等の観点からアクセスできるメンバーやそれぞれの権限は最小限にしています。 単純なセキュリティ以外の観点でも、開発者が本番環境までアクセスできてしまうと環境取り違えによる誤操作でトラブル発生につながる可能性があります。 開発作業を余計な心配なく集中してできるようにする観点でも、環境の分離と余計なアクセス権限をなくすことが重要です。 一方で普段は本番環境に一切アクセスできない開発メンバーであっても、以下のようないくつかのシーンでアクセスが必要になることがあります。 申告やアラートにもとづくトラブルシューティング 新機能のリリースに伴う設定の更新や DB のマイグレーション作業 これまでの運用 NeWork では Google Cloud を主に利用してサービス提供しています。 上記のような本番環境へのアクセスが必要になったシーンでは、以下の運用で対応していました。 開発メンバー. : 特権アカウント所持者 (≒ 藤野) に理由を添えてアクセス権限付与依頼 特権アカウント所持者 : (依頼に気づいたタイミング以降で) アクセス権限を付与 開発メンバー : 作業完了後に権限の削除依頼 特権アカウント所持者 : アクセス権限を削除 課題 しかし 2 年以上この運用を続けてきていて以下の課題があると感じていました。 特権アカウント所持者の状況によっては、対応が遅れタイムリーに処理できなくなりうること 特権アカウント所持者 (≒ 藤野) の業務上の役割が変化し、実際に開発をする頻度が向上することによって、開発環境と取り違えて誤操作をする可能性が浮上 緊急のトラブルシューティング等の場合、対応完了と素直に判断できなくなるシーンがあり、権限削除依頼を失念し、不必要に長期間権限が付与された状態になることがある 上記の問題に対処するため、普段は一切開発等をしない複数のメンバーにも特権を付与し、代わりにアクセス権限付与作業をしてもらうことも考えられましたが、以下の懸念がありました。 そもそもの操作に慣れていない状況でセンシティブな作業をお願いしづらい 複数依頼対象がいると、誰にお願いすればいいかわからず手間が増える 実現方法 上述の背景を考慮して、2024 年 5 月から以下のワークフローを用意し、運用を開始しました。 開発メンバー : GitHub Actions を以下の情報を入力して起動して権限昇格申請 環境 (基本的には本番環境) 権限付与対象アカウントのメールアドレス 権限 権限付与期間 : 1h/2h/5h/1d から選択 目的 承認可能メンバー : 申請内容に問題なければ承認 自動 : GitHub Actions が期間限定の権限を対象かアカウントに付与 自動 : 設定した期間を過ぎると自動で権限が無効になる これにより、開発メンバーであっても本番環境の特権アカウントを持つことなく承認可能メンバーになることもできるようになりました。 実装 - Google Cloud IAM 設定スクリプト 期限付きの権限付与は Google Cloud の 一時的なアクセス権付与 の仕組みを利用します。 これを GitHub Actions から実行できるように bibbidi-bobbidi-boo.sh という名前の以下のシェルスクリプトを用意しました。 #!/bin/bash # # bibbidi-bobbidi-boo.sh # ============ # # Script to configure temporary access to an account # # Usage: # # bibbidi-bobbidi-boo.sh $PROJECT_ID $USER_EMAIL $ROLE $DURATION # パラメータ PROJECT_ID=$1 # GCPプロジェクトID USER_EMAIL=$2 # ユーザーのメールアドレス ROLE=$3 # 付与するロール DURATION=$4 # ロールを付与する期間（日または時間） # DURATIONを秒に変換 if [[ $DURATION == *d ]]; then DURATION_SECONDS=$(( ${DURATION%d} * 24 * 60 * 60 )) elif [[ $DURATION == *h ]]; then DURATION_SECONDS=$(( ${DURATION%h} * 60 * 60 )) else echo "Invalid duration format. Use <number>d for days or <number>h for hours." exit 1 fi # 現在の日時を取得 CURRENT_DATE=$(date -u +%Y-%m-%dT%H:%M:%SZ) # 期限日時を計算 EXPIRATION_DATE=$(date -u -d "$DURATION_SECONDS seconds" +%Y-%m-%dT%H:%M:%SZ) # ロールを付与 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="user:$USER_EMAIL" \ --role=$ROLE \ --condition="expression=request.time < timestamp('${EXPIRATION_DATE}'),title=Cinderella_${ROLE}_access,description=Temporary ${ROLE} access until ${EXPIRATION_DATE}" これにより、指定したプロジェクト・アカウント・ロールを期間限定で付与できるようになります。 実行すると以下のように期間限定で権限付与ができます。 なお、仕様により オーナー / 編集者 / 閲覧者 等の基本ロールには条件設定ができない点は注意が必要です。 設定 - GitHub Environments GitHub Environments は以下の目的で利用できます。 変数を variables / secrets に設定 アクション実行ブランチの制限 それ以外にも特定のメンバーによるアクション実行を承認性にすることもできます。 今回のアクションはリポジトリにアクセスできる人が誰でも実行できてしまうと困るので、この用途でも活用するようにしました。 これにより、ワークフローを実行すると指定されたメンバーの承認がないと実行できなくなります。 また、 Prevent self-review にチェックをいれることで自作自演による環境アクセス承認もできなくなります。 実装 - GitHub Actions 上記のスクリプトを実行できる GitHub Actions を用意します。 name : Cinderella Request on : workflow_dispatch : inputs : environment : type : environment required : true email : description : "User Email" required : true role : description : "Role" type : choice # 付与するロールはプロジェクトにあわせて調整必要 default : "roles/firebase.admin" options : - roles/firebase.admin - roles/run.admin - roles/cloudfunctions.admin duration : description : "Duration" required : true type : choice default : "1h" options : - 1h - 2h - 5h - 1d purpose : description : "Purpose" required : true run-name : Request ${{ inputs.role }} during ${{ inputs.duration }} to ${{ inputs.email }} for ${{ inputs.purpose }} jobs : cinderella : runs-on : ubuntu-latest environment : name : ${{ inputs.environment }} steps : - name : Checkout uses : actions/checkout@v4 - name : Authenticate Google Cloud uses : "google-GitHub-actions/auth@v2" with : workload_identity_provider : ${{ vars.IDENTITY_PROVIDER }} - name : Run a magic run : ./scripts/bibbidi-bobbidi-boo.sh ${{ vars.GC_PROJECT_ID }} ${{ inputs.email }} ${{ inputs.role }} ${{ inputs.duration }} 基本的にはスクリプト実行に必要なパラメータに関する値を指定して実行できるようにしています。 スクリプトとは関係なく purpose も取得するようにしており、これは実行時のタイトルに設定しています。 これにより、前述の承認判断をより簡単にできるようにしています。 なお、スクリプトの実行には resourcemanager.projects.setIamPolicy の権限が必要なので、 Project IAM 管理者 (resourcemanager.projectIamAdmin) あたりを認証に利用します。 その他細かな工夫点 ゴミ掃除 権限の観点では、指定した時間を過ぎると権限は無効になります。ただ、Google Cloud の設定上は不要な権限が残ってしまいます。 このゴミが溜まってしまわないように、以下のスクリプトを GitHub Actions で定期実行することでゴミが削除されるようにします。 #!/bin/bash -e # # tremaine-family.sh # ============ # # Remove temporary access right named with Cinderella # # Usage: # # tremaine-family.sh $PROJECT_ID # パラメータ PROJECT_ID=$1 # GCPプロジェクトID # プロジェクトのIAMポリシーを取得 CURRENT_POLICY=$(gcloud projects get-iam-policy $PROJECT_ID --format=json) # `Cinderella` がつく condition を削除 NEW_POLICY=$(echo $CURRENT_POLICY | jq 'del(.bindings[] | select(.condition) | select(.condition.title | startswith("Cinderella_")))') # 更新後のIAMポリシーを整形してJSONファイルに出力 echo $NEW_POLICY | jq . -M > updated_iam_policy.json # 差分があった場合に更新 if [ "$CURRENT_POLICY" != "$NEW_POLICY" ]; then gcloud projects set-iam-policy $PROJECT_ID updated_iam_policy.json fi name : Cleaner on : workflow_dispatch : inputs : environment : required : true type : environment # 平日 24:00 JST schedule : - cron : "0 15 * * 1-5" run-name : IAM Cleaning @ ${{ inputs.environment || 'prod' }} jobs : clean : runs-on : ubuntu-latest environment : name : ${{ inputs.environment || 'prod' }} steps : - name : Checkout uses : actions/checkout@v4 - name : Authenticate Google Cloud uses : "google-GitHub-actions/auth@v2" with : workload_identity_provider : ${{ vars.IDENTITY_PROVIDER }} - name : Run cleaner run : | ./scripts/tremaine-family.sh ${{ steps.vars.outputs.GC_PROJECT_ID }} これにより、24時の鐘が鳴ると Cinderella_ がつく権限を削除します。 日を跨ぐ作業がこれまでもなかったので、権限が賞味期限切れになっているかに関わらず削除してしまっていますが、 jq 構文を頑張ることで期限切れの権限のみの削除もできるはずです。 Slack 連携 承認依頼は GitHub の設定に応じてメール等でも承認者に飛びますが、利便性を考慮して Slack と連携しました。 これにより、以下の全てが Slack へ通知等できるようにしています。 ワークフローの起動時の通知 ワークフローに対する承認処理 ゴミ掃除結果 (上述のスクリプトに +α の追加をして実現しています) Slack の連携時に以下の方法でスレッドに連携しないとワークフローの承認ができないのでご注意ください。 /github subscribe ${REPO_NAME} workflows:{name: "${WORKFLOW_NAME}"} 単純な通知としても便利ですが、ログの意味でも役立っています。必要あればさらにワークフローを改良して、監査用のスプレッドシートなどに実行履歴を保存することなども考えられます。 サービスアカウントキーの発行 Firebase Admin SDK を利用するスクリプトをローカルで実行する場合は、権限を持つサービスアカウントキーを読み込んだ上でスクリプトを実行する必要があります。 1 これについても一時的な権限をふったサービスアカウントキーを発行できるようにしています。 #!/bin/bash # # pumpkin-carriage.sh # ============ # # Script to generate service account key with temporary access # # Usage: # # pumpkin-carriage.sh $PROJECT_ID $DURATION # パラメータ PROJECT_ID=$1 # GCPプロジェクトID DURATION=$2 # ロールを付与する期間（日または時間） # DURATIONを秒に変換 if [[ $DURATION == *d ]]; then DURATION_SECONDS=$(( ${DURATION%d} * 24 * 60 * 60 )) elif [[ $DURATION == *h ]]; then DURATION_SECONDS=$(( ${DURATION%h} * 60 * 60 )) else echo "Invalid duration format. Use <number>d for days or <number>h for hours." exit 1 fi # サービスアカウントを作成 SERVICE_ACCOUNT_NAME="firebase-admin-cinderella" SERVICE_ACCOUNT_EMAIL="${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" # サービスアカウントが存在するか確認 if ! gcloud iam service-accounts describe $SERVICE_ACCOUNT_EMAIL > /dev/null 2>&1; then gcloud iam service-accounts create $SERVICE_ACCOUNT_NAME \ --description="Temporary Firebase Admin" \ --display-name="Temporary Firebase Admin" fi # 現在の日時を取得 CURRENT_DATE=$(date -u +%Y-%m-%dT%H:%M:%SZ) # 期限日時を計算 EXPIRATION_DATE=$(date -u -d "$DURATION_SECONDS seconds" +%Y-%m-%dT%H:%M:%SZ) # ロールを付与 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \ --role="roles/firebase.admin" \ --condition="expression=request.time < timestamp('${EXPIRATION_DATE}'),title=Cinderella_roles/firebase.admin_access,description=Temporary roles/firebase.admin access until ${EXPIRATION_DATE}" # サービスアカウントのキーを作成 gcloud iam service-accounts keys create ./${PROJECT_ID}-firebase-admin-key.json \ --iam-account $SERVICE_ACCOUNT_EMAIL name : Firebase Key Request on : workflow_dispatch : inputs : environment : type : environment required : true duration : description : "Duration" required : true type : choice default : "1h" options : - 1h - 2h - 5h - 1d purpose : description : "Purpose" required : true run-name : Key Request during ${{ inputs.duration }} for ${{ inputs.purpose }} jobs : cinderella : runs-on : ubuntu-latest environment : name : ${{ inputs.environment }} steps : - name : Checkout uses : actions/checkout@v4 - name : Authenticate Google Cloud uses : "google-GitHub-actions/auth@v2" with : workload_identity_provider : ${{ vars.IDENTITY_PROVIDER }} - name : Run a magic run : ./scripts/pumpkin-carriage.sh ${{ vars.GC_PROJECT_ID }} ${{ inputs.duration }} - uses : actions/upload-artifact@v4 with : name : firebase-admin-key path : ./${{ vars.GC_PROJECT_ID }}-firebase-admin-key.json if-no-files-found : error retention-days : 1 overwrite : true このワークフローも実行には承認が必要です。 承認され実行されると、サービスアカウントキーのファイルが生成され、GitHub Actions のページからキーファイルをダウンロードできます。 運用を変えてみて 2024年5月からこの運用を導入してみました。 変更以来、月平均で10回ほど実行されており、運用に欠かせないツールとなりました。 運用していくなかで、以下のような場面に遭遇し、改善も日々しています。 設定に複数のロールが必要であったり、そもそもの必要なロールを割り出したりするのが手間 => 全般的な操作をできるカスタムロールを追加 新機能の追加時に伴い、ワークフローのロールリストも追随するのが手間 => ロールを選択肢から選ぶのではなく、自由記述式に変更 スクリプトの想定実行時間の見積もりが甘く、期限間際にハラハラしながら完了を待つ => ちょっと長めに期間設定をする運用対処に現状は逃げているが、延長機能の追加も検討中 メンバーもこの運用になって以下のようなポジティブな反応をしてくれており、今後も継続予定です。 一部の開発メンバーは承認者も兼任できるようになり、各チームに一人は承認できるメンバーを含むようになった。そのため、承認者への相談を忖度したり、不用意に長い待ち時間の発生がなくなって楽になった 本番環境へのリリース前に考慮すべきことや実施すべきことが減り、楽になった おわりに この記事では、本番環境へのアクセス管理の運用を改善した事例について紹介しました。 今回の内容とは関係が薄いですが、 NeWork はどなたでも無料でお試しできますので、もしプロダクトや使われている技術に興味を持っていただけたらぜひ触ってみてください。 https://github.com/firebase/firebase-admin-node/pull/2466 がマージされればこの状況も改善が見込まれています。 ↩

こんにちは。イノベーションセンターの鮫嶋です。本記事では、今年で入社2年目の新人が、2024年8月に開催されたセキュリティカンファレンス BSides Las Vegas 2024 で登壇するまでの道のりについてご紹介します。 Team NA4Secとは BSides Las Vegasに登壇してきました BSides Las Vegasまでの道のり リサーチにかかわり始めたきっかけ どんな活動をしてきたか JSAC2024に参加して BSides Las Vegas 2024で登壇！ 振り返って おわりに Team NA4Secとは 私は、Network Analytics for Security（以下、NA4Sec）プロジェクトに所属しています。 NA4Secプロジェクトは「NTTはインターネットを安心、安全にする社会的責務がある」を理念として、攻撃インフラの解明、撲滅を目指すプロジェクトです。 NTT Comイノベーションセンターを中心としてNTTセキュリティ・ジャパンやエヌ・エフ・ラボラトリーズからもメンバーが参画し、日夜攻撃インフラ *1 を追跡しています。 今回は、Team NA4Secから皆川、神田、鮫嶋の3名がラスベガスで講演してきました。 BSides Las Vegasに登壇してきました BSides Las Vegasとは情報セキュリティコミュニティ主導で毎年開催されているセキュリティカンファレンスです。Black Hat USA, DEF CONと共に、ラスベガスで開催される主要なセキュリティイベントの1つとして知られています。今年は8月6日・7日に Tuscany Suites & Casino で開催されました。 講演では、Team NA4Secのメンバーと共に、親ロシア派ハクティビストを長期にわたって追跡した内容について話をしています。 ／ イベント登壇情報✨ ＼ ​ ラスベガスで開催されるセキュリティカンファレンス @BsidesLV にて、NTT ComとNFLabs.の社員が登壇🙋 ​ 詳細はこちら⬇ https://t.co/CotWhfcpy1 ​ #ドコモビジネス — ドコモビジネス｜NTTコミュニケーションズ (@NTTCom_online) 2024年7月16日 当日の講演の様子はYouTubeにて録画が公開されていますので、ご興味のある方はぜひご覧ください。 www.youtube.com BSides Las Vegasまでの道のり リサーチにかかわり始めたきっかけ 実は、私の入社前から本リサーチは開始されており、アイデアはあるものの人手不足で作業が進んでいない状況が続いていました。そこで配属後、進んでいない作業を補う形で本リサーチに途中からかかわることになりました。 どんな活動をしてきたか 私は本リサーチにおいてはSNS調査やデータ分析を担当していました。 主にTelegram *2 での投稿収集・分析をしましたが、OPSEC *3 に配慮し調査をするための回線や端末の調達から始め、プロジェクト内の環境を用いて自動で投稿を収集する機能の実装と収集したデータの分析をしました。 初めはBSides Las Vegasに投稿する予定はなく、日本で開催されるセキュリティカンファレンスである CODE BLUE に投稿することを目標に進めていました。 リサーチにかかわり始めたのが昨年6月で、CODE BLUEのCFP締切が昨年8月だったため、わずか2ヶ月足らずで、必要物を調達するための社内プロセス理解、プロジェクト内環境の把握、使用したことのないツール理解、データの収集・分析までしなければなりませんでした。 私は学生時代にセキュリティ分野には触れていたものの、ツール類に疎く、慣れない環境で四苦八苦していました。自分の作業が遅れると周りにも迷惑をかけてしまうという思いもあり、当時は日々焦燥感を抱きながら作業を進めていたように思います。気軽に質問をできる風土であり、分からないことを分からないと遠慮なく声を上げることのできる環境があったのは恵まれていたのだなと感じています。サポートしてくれたチームメンバーには感謝の気持ちしかありません。 JSAC2024に参加して CODE BLUEには残念ながら不採択となりましたが、代わりに JSAC という日本で開催されるセキュリティカンファレンスへ投稿し、無事に採択。登壇することが決まりました。 登壇の様子や発表内容については 過去のブログ にありますので、興味のある方はご覧ください。 途中からかかわったリサーチであり、作業期間も短かったため、自分以外のメンバーが講演するんだろうなと思っていたらいつの間にか（？）登壇することになっていました。1年目から登壇する機会があるとは思っていなかった上、私は対面での登壇経験が少なく、スピーチも苦手だったため、当日は緊張で顔が青白くなりながら聴衆の面前で話していたのを覚えています。 BSides Las Vegas 2024で登壇！ このリサーチの内容を海外にも発表しよう！という話になり、BSides Las Vegasへ投稿し、今年6月に採択される運びとなりました。詳細な経緯を知りたい方は、登壇者の1人である皆川さんのブログをご一読ください。 8月のラスベガスでの発表に向けて、JSACでの発表から半年分アップデートする形でデータを再度分析し、発表資料を作る日々が始まりました。しかし、無事採択されたものの、私は英語が大の苦手であり、長時間のフライトも苦手なため、期待というより不安を大きく抱えながら準備を進めることになりました。 フライトも無事に乗り越え、ラスベガスへ到着。そして迎えた発表当日。カンファレンス1日目の午後ということもあり、他の発表を聞いている余裕もなく、直前まで発表練習を行っていました。私が話すパートはわずか10分程度でしたが、貴重な経験をさせていただけたと感じています。ただ、準備不足と緊張で原稿を見ながら喋ることしか出来なかったのは心残りです。 登壇者の皆川(左: @strinsert1Na )、 神田(中央: @ashy0x41 )、 筆者(右: @islairand ) 振り返って まさか、配属直後にかかわったリサーチで海外登壇まで経験できるとは夢にも思っていませんでした。正直、私は今回のリサーチにタイミング良くかかわることができ、偶然ラスベガスへ連れて行ってもらったのだと感じています。しかし、偶然であったとしてもその機会をモノにするための力を蓄えていくことが大事なんだなとも同時に実感しました。 また、英語の勉強不足は大きな反省点でした。登壇が決定してからできる限り英語の勉強もしましたが、やはり付け焼刃ではどうにもなりませんでした。今回の出張では周りの助けのおかげで何とかなったものの、1人では受け答えも満足にできず、不甲斐なさを感じる結果となりました。これを機に英語は勉強し続けようと思います。 おわりに 2年目社員がラスベガスで登壇してきた体験談でした。若いうちから海外登壇する機会をいただき、日本では得られない、何ものにも代えがたいさまざまな経験を積むことができました。この経験を糧に、今後もリサーチャーとして自信をもって海外登壇できるように、日々精進したいと思います。 ラスベガス出張に聴講者として参加したNTT Comメンバーの体験談も後日公開予定ですので、そちらもお楽しみに。 また、BSides Las Vegasには他にも日本から登壇された方々がおり、体験記が公開されています。気になる方はぜひこちらもご覧ください。 *1 : 攻撃者の管理するマルウェアや C&Cサーバ など。 *2 : スピードとセキュリティに重点を置いたメッセージアプリ。 *3 : 本記事では、ターゲットを偵察する際に個人情報を秘匿する概念として用いている。

本記事では、今年8月にパブリックベータ版として GitHub に搭載された新機能 GitHub Models について、概要や利用法を簡単にご説明します。さらに、実際に GitHub Models を活用して、多数の LLM の日本語性能を横断的に測定していく例を紹介していきます。 目次 目次 はじめに 三行で GitHub Models を説明すると... GitHub Models の使い方 Waitlist への登録 モデル一覧 ブラウザ上で試す API経由で試す GitHub Models を利用する上での注意点 API レート制限の制約が強い Azure AI Content Safety が全ての LLM に適用されている GitHub Models を使って LLM の日本語性能を横断的に測定する 実験 1. GPT-4o による自動評価 2. 出力が日本語になっているかどうかの評価 結果と考察 まとめ はじめに イノベーションセンターの杉本（GitHub: kaisugi ）です。普段はノーコードAI開発ツール Node-AI の機能開発や、Node-AI を用いたデータ分析人材育成、LLM に関する技術調査などに携わっています。 今回は、 GitHub Models という GitHub の新機能についてご紹介します。 github.blog 三行で GitHub Models を説明すると... GitHub Models は GitHub 上で LLM を 無料 で試せるプラットフォーム。ブラウザ上、API経由の双方で、さまざまな LLM を動かすことができる API レート制限の制約が強くプロダクションには向かないが、無料で試せるので プロトタイピング や 研究 の用途に最適 GitHub Models 上の全てのモデルが Azure AI Studio にも搭載されているため、Azure AI Studio の無料版として使うこともできる GitHub Models の使い方 Waitlist への登録 本記事を執筆している現在、GitHub Models はまだパブリックベータ版の機能であるため、利用するには Waitlist に登録する必要があります。以下のリンクから登録できます。 https://github.com/marketplace/models/waitlist モデル一覧 GitHub Models のトープページは https://github.com/marketplace/models から開くことができます。ここでは、GitHub Models 上で試せるモデルの一覧が表示されています。 私が調査した8月末時点で、GitHub Models で使える LLM は以下の 21 種類がありました。GitHub を運営している Microsoft 関連のモデルだけでなく、Llama や Mistral などの外部のモデルも搭載されています。 なお、GitHub Models に搭載されているモデルは随時アップデートが行われており、この記事をご覧になっている際には、すでに内容が古くなってしまっているかもしれない点にご注意ください。 モデル名 開発元 備考 AI21-Jamba-Instruct AI21 Labs パラメータ数52B（アクティブパラメータ数 1 12B）。世界初の商用規模の Mamba 2 ベースのLLM Cohere Command R Cohere パラメータ数35B。日本語を含む多言語対応 Cohere Command R+ Cohere パラメータ数104B。日本語を含む多言語対応。RAG 3 への最適化 Meta-Llama-3-70B-Instruct Meta Meta-Llama-3-8B-Instruct Meta Meta-Llama-3.1-405B-Instruct Meta Llama 3 よりも新しいモデル。多言語対応 Meta-Llama-3.1-70B-Instruct Meta Llama 3 よりも新しいモデル。多言語対応 Meta-Llama-3.1-8B-Instruct Meta Llama 3 よりも新しいモデル。多言語対応 Mistral Large Mistral AI 多言語対応 Mistral Large (2407) Mistral AI Mistral Large よりも新しいモデル。パラメータ数123B。日本語を含む多言語対応 Mistral Nemo Mistral AI, NVIDIA パラメータ数12B。日本語を含む多言語対応 Mistral Small Mistral AI 多言語対応 OpenAI GPT-4o OpenAI 日本語を含む多言語対応 OpenAI GPT-4o mini OpenAI 日本語を含む多言語対応 Phi-3-medium instruct (128k) Microsoft パラメータ数14B。4kモデルよりもコンテクスト長 4 が大きい Phi-3-medium instruct (4k) Microsoft パラメータ数14B Phi-3-small instruct (128k) Microsoft パラメータ数7B。8kモデルよりもコンテクスト長が大きい Phi-3-small instruct (8k) Microsoft パラメータ数7B Phi-3-mini instruct (128k) Microsoft パラメータ数3.8B。4kモデルよりもコンテキスト長が大きい Phi-3-mini instruct (4k) Microsoft パラメータ数3.8B。 Phi-3.5-mini instruct (128k) Microsoft Phi-3 よりも新しいモデル。パラメータ数3.8B ブラウザ上で試す 例として、Meta-Llama-3.1-405B-Instruct という LLM を動かしてみます。 ブラウザ上で LLM が試せるプレイグラウンドは、 https://github.com/marketplace/models/azureml-meta/Meta-Llama-3-1-405B-Instruct/playground というリンクからすぐに使うことができます。普通の ChatGPT などの画面と同様に、質問文を入力して送信するだけで、LLM からの回答を得ることができます。 API経由で試す API 経由で LLM を触ることもできます。 まず初めに、 https://github.com/settings/tokens から GitHub の Personal access token (PAT) を発行してください。なお、この PAT には、GitHub 関連の権限を付与する必要はありません。 そして、PAT を GITHUB_TOKEN という環境変数に格納した上で、以下のようなコードを実行すると、出力を得ることができます。 import os from azure.ai.inference import ChatCompletionsClient from azure.ai.inference.models import SystemMessage, UserMessage from azure.core.credentials import AzureKeyCredential endpoint = "https://models.inference.ai.azure.com" model_name = "meta-llama-3.1-405b-instruct" token = os.environ[ "GITHUB_TOKEN" ] client = ChatCompletionsClient( endpoint=endpoint, credential=AzureKeyCredential(token), ) response = client.complete( messages=[ UserMessage(content= "NTTコミュニケーションズについて教えてください。" ), ], model=model_name, temperature= 0.8 , max_tokens= 4096 , top_p= 0.1 ) print (response.choices[ 0 ].message.content) ここでは Python のコード例を示しましたが、Azure AI Inference SDK が実装されている C#, JavaScript や、通常の REST API でも同様の処理が可能です。 GitHub Models を利用する上での注意点 API レート制限の制約が強い GitHub Models では全ての LLM を無料で利用できますが、その代わりに、強い API レート制限が設定されています。 レート制限の詳細は、以下のドキュメントにまとめられています。 https://docs.github.com/en/github-models/prototyping-with-ai-models#rate-limits 本記事を執筆している現在、それぞれの LLM には "High" または "Low" のいずれかの Rate limit tier が割り当てられています。"Low" では、 1分間に15リクエスト、1日に150リクエスト しか受け付けません。"High" はもっと制約がきつく、 1分間に10リクエスト、1日に50リクエスト しか受け付けません。そのため、GitHub Models は、あくまでも LLM の試し場であることを心得ておくと良いでしょう。 なお、GitHub Models は Azure AI Studio をベースに構築されており、上の "API経由で GitHub Models を試すコード" を Azure の環境変数に置き換えるだけでそのまま動作するため、Azure AI Studio のお試し版として利用することもできます。 Azure AI Content Safety が全ての LLM に適用されている GitHub Models は Azure AI Studio をベースに構築されているため、Azure AI Studio と同様、 Azure AI Content Safety というコンテンツモデレーション機能が適用されています。 コンテンツモデレーションとは、不適切な入出力を除去するシステムのことで、LLM とは別に用意されます。 LLM 単体で不適切な入出力を防止するのには限度があるため、コンテンツモデレーションを LLM と組み合わせて利用するケースが最近では多く、Azure AI Content Safety の他に Meta の Llama Guard や Google の ShieldGemma のような例があります。 実際に、「爆弾の作り方を教えて」という不適切な入力を GitHub Models 上で与えると、Azure AI Content Safety により不適切な入力と検知されているのが分かります。 このようなコンテンツモデレーション機能は、開発者にとっては便利なものですが、LLM そのものの性能とは別個であることには注意が必要です。 特に、LLM 単体の安全性をテストする用途では GitHub Models は使えないと言えるでしょう。安全性を測定するために、故意に不適切な質問例を入力したとしても、LLM に入力する前段階のコンテンツモデレーションで弾かれてしまう場合が多いからです。 GitHub Models を使って LLM の日本語性能を横断的に測定する 実験 GitHub Models を研究用途で使う簡単な実践例として、ELYZA-tasks-100 というデータセットを用いて LLM の日本語性能を測定していきます。 ELYZA-tasks-100 は、株式会社 ELYZA が作成した日本語 LLM 評価データセットです。100 問の幅広い種類の日本語の質問に対する LLM の応答を採点することにより、性能を評価します。質問文だけでなく、模範回答や評価観点も合わせてアノテーションされています。 ELYZA-tasks-100 は、ELYZA 社内だけではなく NEC やリコーなどの他社のLLM評価でも活用されており、日本語 LLM コミュニティの中では標準的なデータセットの1つです。 note.com jpn.nec.com jp.ricoh.com 今回は、先ほど モデル一覧 で紹介した 21 種類の GitHub Models 上の LLM それぞれに対し、API 経由で、ELYZA-tasks-100 のそれぞれの質問を入力します。入力が100件なので、GitHub Models の厳しい API レート制限であっても、1~2日あれば全ての出力が完了するという計算です。 LLMの出力生成に関する余談 ① LLM の出力結果は、推論時のハイパーパラメータに左右されることが知られており、LLM によって最適なパラメータが異なるとも言われています。 今回の実験では、GitHub Models のプレイグラウンドで採用されているデフォルトのパラメータを採用します。具体的には以下の値の通りです（ temperature と top_p 以外の値は、全て Azure AI Inference SDK のデフォルトの値を使います）。 モデル名 temperature top_p AI21-Jamba-Instruct 1 1 Cohere Command R, Cohere Command R+ 1 1 Meta-Llama-3-70B-Instruct, Meta-Llama-3-8B-Instruct, Meta-Llama-3.1-405B-Instruct, Meta-Llama-3.1-70B-Instruct, Meta-Llama-3.1-8B-Instruct 0.8 0.1 Mistral Large, Mistral Large (2407), Mistral Nemo, Mistral Small 0.7 1 OpenAI GPT-4o, OpenAI GPT-4o mini 1 1 Phi-3-medium instruct (128k), Phi-3-medium instruct (4k), Phi-3-small instruct (128k), Phi-3-small instruct (8k), Phi-3-mini instruct (128k), Phi-3-mini instruct (4k), Phi-3.5-mini instruct (128k) 0 1 LLMの出力生成に関する余談 ② ELYZA-tasks-100 の 100 件の質問の中でも、Azure AI Content Safety で不適切と判定される質問が 2 件存在しました。具体的には、 あの、娘がやっているあのキ、チックトック？チックトッカー？っていうのは何なんですか？ と、 ガラスを使い捨てライターで炙ったら燃えますか？ です。これらは LLM が出力を返すことができないため、後述する評価の対象から除外しました。 ELYZA-tasks-100 の質問集に対するそれぞれの LLM の回答を記録した後に、以下の 2 点から評価します。 1. GPT-4o による自動評価 現在使える最高性能の LLM の1つとされる GPT-4o を使って回答を評価します。具体的には、 ELYZA のテックブログで紹介されたプロンプト を改変し、以下のプロンプトを GPT-4o に入力することで1 ~ 5 の 5 段階でスコア付けします。最後に、回答全体でスコアの平均を計算し、評価結果とします。 なお、プロンプト中の {質問文} がデータセットの元の質問文、 {LLMの出力} が質問文に対する LLM の回答、 {評価観点} と {模範回答} がデータセットに質問文と合わせて収録されている評価観点と模範回答の文章になります。 以下に示すユーザの質問に対するAIアシスタントの回答を評価してください。 AIアシスタントの回答に加え、模範的な回答である参考回答が与えられます。参考回答と比較したうえで、AIアシスタントの回答を評価してください。 評価は短い説明から始めてください。説明を提供した後、「評価：[[評価値]]」という形式で1から5までの尺度で応答を評価してください（例：評価：[[5]]）。各尺度の基準は以下の通りです。 基本的な採点基準 - 1点: 誤っている、 指示に従えていない - 2点: 誤っているが、方向性は合っている - 3点: 部分的に誤っている、 部分的に合っている - 4点: 合っている - 5点: 役に立つ 基本的な減点項目 - 不自然な日本語: -1点 - 部分的に事実と異なる内容を述べている: -1点 - 「倫理的に答えられません」のように過度に安全性を気にしてしまっている: 2点にする 問題固有の採点基準 {評価観点} [質問] {質問文} [参考回答開始] {模範回答} [参考回答終了] [AIアシスタント回答開始] {LLMの出力} [AIアシスタント回答終了] なお、GPT-4o で自動評価を行なっているため、評価対象の LLM のうち GPT-4o や GPT-4o mini に対しては過剰に高いスコアになる可能性があります。 5 2. 出力が日本語になっているかどうかの評価 GPT-4o のような LLM を使った自動評価の欠点の1つとして、 出力が日本語以外であったとしても、内容に問題なければ高い点数をつけてしまう ことが知られています。少なくとも日本語を母語とする人たちが LLM を利用する際には、日本語で答えるべき質問には日本語で回答してほしいでしょう。 そこで、それぞれの LLM が各回答においてきちんと日本語を出力しているかを調べていきます。具体的には、以下の 2 ステップを踏むことで、出力が日本語でない件数をカウントします。 Python の langdetect モジュールにより、日本語ではない出力一覧を自動で抽出 その中から、実際に日本語ではない出力を目視でカウント 結果と考察 以下の通りになりました。 モデル名 GPT-4o による自動評価 日本語以外の回答の件数 AI21-Jamba-Instruct 1.99 13 Cohere Command R 2.81 0 Cohere Command R+ 3.37 0 Meta-Llama-3-70B-Instruct 3.17 80 Meta-Llama-3-8B-Instruct 2.66 87 Meta-Llama-3.1-405B-Instruct 3.11 0 Meta-Llama-3.1-70B-Instruct 3.13 0 Meta-Llama-3.1-8B-Instruct 2.51 0 Mistral Large 3.01 33 Mistral Large (2407) 3.90 0 Mistral Nemo 2.91 7 Mistral Small 2.86 25 OpenAI GPT-4o 4.10 0 OpenAI GPT-4o mini 3.82 0 Phi-3-medium instruct (128k) 3.11 0 Phi-3-medium instruct (4k) 3.17 2 Phi-3-small instruct (128k) 2.65 1 Phi-3-small instruct (8k) 2.81 0 Phi-3-mini instruct (128k) 2.17 0 Phi-3-mini instruct (4k) 2.27 0 Phi-3.5-mini instruct (128k) 2.61 0 この結果から、以下のような考察を導けます。 同じ開発元の同程度のパラメータ数の LLM であっても、 新しいバージョンになると性能が飛躍的に向上する ケースが見られます。例えば、Mistral Large から Mistral Large (2407) では自動評価スコアが 3.01 から 3.90 に上昇しています。同様に、Phi-3-mini instruct (128k) から Phi-3.5-mini instruct (128k) では 2.17 から 2.61 に上昇しています。 LLM の中には、日本語以外の出力ばかり返してしまう LLM もあれば、きちんと日本語を返す LLM もあります。例えば、Meta-Llama-3-70B-Instruct は自動評価では 3.17 という高スコアを収めているにもかかわらず、80 件もの回答が日本語以外になってしまいました。 6 一方で、Meta-Llama-3.1-70B-Instruct や Cohere Command R+、Mistral Large (2407) など、 公式に多言語対応を謳っている LLM はきちんと日本語を返してくれる 傾向にあるようです。 どの開発元のモデルであっても、パラメータ数の大きい LLM の方が基本的には自動評価スコアも高いです。ただし、Meta-Llama-3.1-405B-Instruct と Meta-Llama-3.1-70B-Instruct の間では差は見られませんでした。 Microsoft の Phi-3 系列のモデルでは、コンテクスト長の長いモデルの方が自動評価スコアは低いという結果になりました。これは、ELYZA-tasks-100 の質問文が基本的に短文であり、長文向けに学習されたモデルにとって不利な測定方法になっているからかもしれません。 まとめ 本記事では、GitHub Models の機能紹介と、GitHub Models を活用した LLM の日本語性能評価の実践例についてご紹介しました。 GitHub Models はまだリリースされたばかりの新しい機能です。今後もさまざまな LLM が GitHub Models に搭載され、すぐに試せるようになることを期待したいと思います。 アクティブパラメータ数とは、Mixture of Experts (MoE) という仕組みを採用した LLM において用いられる概念です。Mixture of Experts (MoE) とは多数の LLM を束ねた構造であり、推論時にいくつかの LLM のみ使用して推論させます。そのため、推論時に使う（アクティブになる）LLM のパラメータ数は、モデル全体のパラメータ数よりも小さい値になります。 ↩ Mamba とは、 Mamba: Linear-Time Sequence Modeling with Selective State Spaces (Gu & Dao, 2023) という論文で提案されたニューラルネットワークのアーキテクチャです。LLM で広く用いられる Transformer というアーキテクチャの欠点である、計算コストの高さを克服するために提案されました。 ↩ RAG とは Retrieval-Augmented Generation の略です。LLM を使ってテキストを生成する際に、まず初めに外部のドキュメントやデータベースなどから質問文に関連するテキストを抽出し、それと質問文を組み合わせて LLM に入力するという技術です。これにより、LLM が持っていない知識に関する質問に対しても正しく答えられることが期待できます。 ↩ コンテクスト長とは、ざっくり言ってしまうと、LLM に入力できる文字数制限のようなものです。 ↩ LLM による LLM の自動評価（LLM-as-a-judge）を提案した論文においては、この種の、自分自身の出力を高く評価するバイアスを self-enhancement bias と名付けています。 ↩ 余談ですが、Meta の Llama 3 に関しては、Llama 3 そのものよりも Llama 3 に日本語で継続事前学習を行なった Llama 3 Swallow を利用するのがおすすめです。Llama 3 自体の言語理解能力を維持しつつ、日本語できちんと出力を返すこともできるからです。本記事を執筆している時点で、Llama 3 Swallow は残念ながら Azure AI Studio には搭載されていませんが、NVIDIA NIM のような他社のプラットフォームにはすでに搭載されています（ https://build.nvidia.com/tokyotech-llm/llama-3-swallow-70b-instruct-v01 ）。 ↩

チームの管理情報を溜めていたオンプレ基盤で動く NetBox を Amazon Elastic Container Service へ AWS Cloud Development Kit を用いて移植しました。 今まで NetBox をオンプレで動かしていた際には以下のような運用の難しさがありました。 DB も Docker コンテナによって管理されており、冗長化もなかったため DB コンテナが落ちてしまうとサービス提供できなくなる可能性があった Docker Compose で動かしているので、サービスの作り直しを実施するとそれまでのログが削除される そもそも NetBox を動かしている場所で法定停電があり、定期的に NetBox のサービスがとまっていた NetBox を AWS へともっていくことでオンプレ運用時に発生していた手間を簡素化し、メンテナンス等も一部 AWS にマネージしてもらえることで運用の省力化を達成できました。 さらに、 AWS Cloud Development Kit を利用することでデプロイも簡素化できました。 今回はその様子や管理における粒度等といった細かい意思決定について共有します。 目次 目次 自己紹介 用語 NetBox データベース キャッシュ Docker コンテナサービス Elastic Load Balancing AWS Secrets Manager Infrastructure as Code と AWS Cloud Development Kit アーキテクチャ 実装 RDS ElastiCache NetBox 注意点 まとめ 自己紹介 こんにちは、イノベーションセンターの福田です。 普段はクラウド関連の調査・開発や Infrastructure as Code (IaC) の推進等に従事しています。 チームでオペレータが手動で実施していた NetBox 管理をパブリッククラウドに移行して運用の省力化をしつつ、 IaC 化することでデプロイがしやすい基盤を整えたのでその方法を共有します。 用語 今回の移植対象である NetBox やその移植先である Amazon Web Services (AWS) で使用しているコンポーネント、 IaC や AWS における IaC の実装としての AWS Cloud Development Kit (CDK) 等用語がいくつも飛びでます。 ここではそれぞれがどういったものかといったことについて説明します。 NetBox NetBox とは NetBox Labs が作成・提供している OSS データセンター管理ツールです。 OSS であるため、一定の環境さえ提供できれば今回紹介する AWS や Microsoft Azure, Google Cloud といったクラウドでも動かせます。 NetBox OSS 4.0.8 データセンター上のさまざまなものを管理できますが、一例を上げれば以下のようなネットワークの資産を管理できます。 IP アドレス ラッキング情報 VLAN 管理 この他にもさまざまなものを管理できますが、データセンターに設置した機器の情報等を一括で管理できます。 Apache License, Version 2.0 で提供されている 1 ため、 OSS として利用することもできますが、 NetBox Labs では NetBox Cloud というクラウドサービスを提供しています。 NetBox Cloud - NetBox Labs NetBox を NetBox Labs にマネージしてもらえるため、運用の省力化やセキュティの迅速な対応、信頼性の確保といったものをまかせることも可能です。 データベース NetBox はデータベースとして RDB である PostgreSQL のバージョン 12 以上を利用します 2 。 NetBox を移植するにあたってはこの PostgreSQL をパブリッククラウド上に用意する必要があります。 幸い、 AWS は Amazon Relational Database Service (RDS) のサービスとして Amazon Aurora というサービスにて PostgreSQL を提供しています。 Amazon Aurora（高性能マネージドリレーショナルデータベース）| AWS 簡単に PostgreSQL 互換の RDB をデプロイでき、セキュリティパッチやバージョンアップグレード、スケーラビリティの確保などを AWS に管理してもらうことができます。 Amazon Aurora には Aurora Standard と Aurora I/O 最適化といったプランがあります。 Aurora I/O 最適化は I/O 要求があるようなアプリケーションに向いていると AWS は述べており、今回の NetBox は社内利用であることからそこまで I/O 要求がないことを考えて Aurora Standard を採用しました。 I/O が少量～中程度のアプリケーションで費用対効果が高い選択肢は Aurora 標準です。I/O が大量のアプリケーションでは Aurora I/O 最適化により、料金パフォーマンスの向上、予測可能な料金の利用、最大 40% のコスト削減が可能です。 参考: AWS が Amazon Aurora I/O 最適化をリリース 他にも Amazon RDS for PostgreSQL というサービスがある 3 のですが、 Amazon Aurora は Amazon RDS for PostgreSQL に対して以下のメリットがあります。 ストレージの自動スケーリング ストレージのサイジングが不要 ストレージの地理的分散 マスターへの障害発生時にレプリカを昇格可能 Amazon RDS for PostgreSQL の場合はスタンバイ状態のものを別途用意する必要あり さらに、 NetBox では管理されるものが DC の IP アドレスや VLAN タグ等であることから利用されるデータ量はかなり少ないことが予想されます。 一般にデータ量や IO が少なければ料金的には Amazon Aurora の方が安いです。 Amazon Aurora と Amazon RDS for PostgreSQL における料金表は次の通りです ^InstanceSize 。 比較項目 Amazon Aurora Amazon RDS for PostgreSQL インスタンス料金 0.113 USD/時間・インスタンス 0.129 USD/時間・インスタンス I/O料金 0.24 USD/100万リクエスト - ストレージ料金 0.12 USD/月・GB 0.138 USD/月・GB 稼働時間を 730 時間 (1ヶ月)、利用する容量を 100 GB とし、 I/O は100万リクエストとします。 また、 Amazon Aurora ではリードレプリカを2つ、 Amazon RDS for PostgreSQL ではスタンバイを2つ用意すると仮定します。 この仮定のもと計算すると次のようになります。 サービス名 金額 Amazon Aurora 0.113 USD/時間・インスタンス * 3インスタンス * 730 時間 + 0.24 USD/100万リクエスト * 1 100万リクエスト + 0.12 USD/月・GB * 1ヶ月 * 100 GB = 259.71 USD Amazon RDS for PostgreSQL 0.129 USD/時間・インスタンス * 3インスタンス * 730 時間 + 0.138 USD/月・GB * 1ヶ月 * 100 GB = 296.31 USD 表をみると Amazon RDS for PostgreSQL は 296.31 USD で Amazon Aurora の 259.71 USD よりも高くなっていることがわかります。 そのため、料金・運用の省力化の観点から今回は Amazon Aurora を採用しました。 Aurora は他にも MySQL 互換のものも提供しており、また MySQL にも Amazon RDS for MySQL があります。 さらに RDS ではエンタープライズで人気のデータベースである Oracle Database を提供する Amazon RDS for Oracle や Microsoft が開発する SQL Server を提供する Amazon RDS for SQL Server もあり、さまざまな RDB の中から要件にあった RDB を選択・利用しつつ運用の省力化を実現できます。 キャッシュ NetBox ではキャッシュも Redis というソフトウェアを利用します 4 。 Redis とはインメモリーで動作するキーバリューデータベースです。 インメモリで動作するため非常に高速に読み書きできます。 こちらもパブリッククラウドで動作させるにあたっては別途用意しなければなりませんが、 AWS には Amazon ElastiCache というキャッシュサーバーを提供するサービスがあり、その中で Redis を提供しています。 Redis 用 Amazon ElastiCache（キャッシュ管理・操作）| AWS こちらを利用すれば AWS 側で可用性やスケーラビリティ・セキュリティの確保してもらうことができ、ユーザーは Redis を利用することに集中できます。 VM を使い自前で用意するといったことも可能ですが、運用にあたってはアップデートやセキュリティパッチの適用、スケーラビリティ・可用性の確保といった運用を減らしたかったので ElastiCache を利用しました。 ElastiCache では Memcached も提供されている 5 ため、ニーズに合わせたキャッシュサーバーを利用できます。 Docker コンテナサービス AWS では Amazon Elastic Container Service (ECS) という Docker コンテナサービスを提供しています。 Amazon ECS（Docker コンテナを実行および管理）| AWS ECS を利用すると Docker コンテナのデプロイや管理、スケーリングを容易に実現できます。 ECS には Docker コンテナを動かす環境によって次の形式が存在しています。 Amazon EC2 起動タイプモデル AWS の仮想マシン提供サービスである Amazon EC2 の上で Docker コンテナを動かす形式 Docker コンテナではなく仮想マシンに対して課金されるので仮想マシンが存在しつづけている限りは課金されつづける 通称 ECS on EC2 AWS Fargate 起動タイプモデル ECS on EC2 では Docker を実行する VM 環境を自前で管理するが、 Fargate は Docker コンテナの実行環境を AWS が管理してくれる コンテナに課金されるため、コンテナが起動した分だけ課金される Amazon EC2 起動タイプモデルよりも後に開発された 通称 Fargate ECS on EC2 は Docker コンテナ環境として仮想マシンを動かすため、地理分散させるときなどには仮想マシンへの配慮も必要となり、管理が煩雑になります。 一方、 Fargate であれば Docker コンテナを動かす環境は AWS が管理するため、ユーザーは Docker コンテナのことだけを考えればよくなり運用の省力化を狙えます。 仮想マシンの管理は煩雑になることが多いため、なるべく省きたいと考え、 ECS を利用して構築することにしました。 さらに幸いなことに、 NetBox は Docker Compose による構築方法も提供しています 6 。 そのため、そちらを参考にして今回の実装を進めました。 また今回はコンテナのみ動かせればよく、 GPU も利用しないため、 VM の管理を回避しなければならない ECS on EC2 ではなく Fargate を選択しました。 Elastic Load Balancing Elastic Load Balancing はロードバランサーを提供するサービスです。 Elastic Load Balancing（複数のターゲットにわたる着信トラフィックの分配）| AWS 用途によって4種類のロードバランサーが提供されています。 Application Load Balancer (ALB) L7 ロードランサー HTTP/HTTPS リクエストのロードバランシングを提供 Network Load Balancer (NLB) L4 ロードバランサー 静的 IP を割り振ることができる Classic Load Balancer (CLB) 名前にある通りクラシックな環境向けのロードバランサー Amazon EC2 の中でもクラシックな EC2-Classic な環境向けであり、 EC2-Classic Networking の環境は販売終了しているため 7 、現代で触る機会はまずない Gateway Load Balancer (GLB) L3 ロードバランサー ファイアウォール、侵入検知、ディープパケットインスペクションといった機能を提供する際に利用する 一般に Web サーバーを提供するのであれば ALB を提供すれば十分です。 ALB を利用すれば簡単に HTTPS 通信を提供できるだけでなく、 HTTP から HTTPS へのリダイレクトも実装できます。 ただし、 ALB では固定 IP アドレスを利用できません。 そのためもし固定 IP アドレスを利用する場合、 ALB の前段に NLB を用意しなければなりません。 NLB は固定 IP アドレスを提供できるので、 NLB -> ALB とすることで固定 IP アドレスを提供しつつ HTTPS 通信を提供できます。 NetBox はパスワードによる認証があり、 HTTP による通信は避けたい状況があります。 そのため HTTPS 通信を提供する必要がありました。 ALB を利用すれば AWS Certificate Manager という証明書管理サービスを通して証明書を取得・設定し、 HTTPS 通信を提供できるため、 ALB を通してサービス提供するようにしました。 AWS Secrets Manager AWS が提供するシークレット情報を管理するサービスです。 AWS Secrets Manager（シークレットのローテーション、管理、取得）| AWS 複数人でシークレットを共有したり、シークレットの閲覧・編集権限をロールベースで制御したり可能です。 シークレット情報はこちらに入れておけばアプリケーションにシークレット情報を含めずとも利用可能になり、安全にシークレット情報を利用できます。 シークレット情報は AWS がマネージする AWS Managed Key というもので暗号化されていますが、より強固なセキュリティが欲しい場合は Customer Managed Key (CMK) という顧客管理の鍵で暗号化もできます。 今回は表立ってでてくるというわけではないですが、利用する PostgreSQL や Redis のシークレット情報を保管・参照するといった用途で利用します。 Infrastructure as Code と AWS Cloud Development Kit 近年、インフラの構成時に設定していた細かい部分の暗黙知を減らしたり、デプロイ対応を平準化する目的でインフラをコード化する Infrastructure as Code (IaC) というパラダイムが普及しています。 有名なものでは HasiCorp が提供する Terraform といったものがあります。 Terraform by HashiCorp AWS では IaC の実装として AWS Cloud Development Kit (CDK) というものを IaC の実装の1つとして提供しています。 オープンソースの開発フレームワーク - AWS クラウド開発キット - AWS CDK はコードを TypeScript/Golang/Python/Java といったプログラミング言語で記述でき、新しく言語を覚えずとも慣れた言語でインフラコードを記述できます。 また、そのまま言語のライブラリなど各種エコシステムを利用できるため、既存の OSS インフラに乗って容易に拡張ができます。 たとえば TypeScript を利用すれば npm を利用してさまざまなコミュニティが提供するパッケージへアクセスできます。 このように既存の言語を利用できるため、簡単に始めることができます。 以下の例は TypeScript で仮想マシンを AWS 上に用意している様子です。 import * as ec2 from 'aws-cdk-lib/aws-ec2' ; new ec2.Instance( this , "Instance" , { // 各種コンポーネントを動かすのひ必要となる Virtual Private Cloud (VPC) // 詳細は https://aws.amazon.com/jp/vpc/ vpc , // 仮想マシンを t2.small で作成 instanceType : ec2.InstanceType.of( ec2.InstanceClass.T2, ec2.InstanceSize.SMALL, ), // OS は Amazon Linux 2023 を利用 machineImage : ec2.MachineImage.latestAmazonLinux2023(), } ); このように各種言語が既知であれば簡単にどのようなインフラ構成をしているのかを読めるところが CDK の特徴です。 CDK は背後で AWS CloudFormation という AWS の提供する構成管理ツールを利用しています。 各種言語で記載されたインフラの情報を元として CloudFormation が解釈できる形式にし、 CloudFormation を呼び出すことでインフラの管理を実現しています。 アーキテクチャ アーキテクチャとしては RDS と ElastiCache を配置し、NetBox からクライアントとして接続するという一般的な構成にしました。 NetBox は Docker イメージ内にバックエンドとフロントエンドを含めているため、1つの Docker コンテナを動かせばバックエンドとフロントエンドの両方を提供できます。 この環境を CDK で実装していきます。 実装 流れとしては次のようになります。 RDS の設置 ElastiCache の設置 NetBox の設置 RDS RDS では強力な権限を持つ管理者ユーザーが存在しており、そのユーザーのパスワードとして強力なものを設置します。 import * as sm from 'aws-cdk-lib/aws-secretsmanager' ; // 自動生成されるパスワードにおいて使わない文字を設定 // // 詳しくは https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_Limits.html#RDS_Limits.Constraints const excludeCharacters = ':@/" \' ' ; const masterPassword = new sm.Secret( this , "DbMasterPassword" , { // AWS Secrets Manager というシークレット管理サービスにシークレット情報を保存するnode、見たときにわかりやすい名前をつけておく secretName : `/Netbox/DbMasterPassword` , // generateSecretString : { excludeCharacters , passwordLength : 64 , // 英大文字小文字、記号、数字を1つずつ含めるようにする requireEachIncludedType : true , // 管理者ユーザー名は `postgresAdmin` 固定 secretStringTemplate : JSON . stringify ( { username : "postgresAdmin" } ), // ここで生成するパスワードは `password` というキーで登録する generateStringKey : 'password' , } , } ); 次にこのパスワードを利用して RDS を生成するようにします。 import * as cdk from 'aws-cdk-lib' ; import * as rds from 'aws-cdk-lib/aws-rds' ; import * as ec2 from 'aws-cdk-lib/aws-ec2' ; new rds.DatabaseCluster( this , "Db" , { // RDS サービス上の DB 識別子 clusterIdentifier : "NetBoxDb" , // PostgreSQL の 12.16 を利用 engine : rds.DatabaseCluster.auroraPostgres( { version : rds.AuroraPostrgesEngineVersion.VER_12_16, } ), // 管理者パスワードを設定 credentials : rds.Credentials.fromSecret(masterPassword), // ストレージ暗号化を有効化 storageEncrypted : true , // マスター DB を動かす仮想マシンの CPU サイズやメモリーを設定 writer : rds.ClusterInstance.provisioned( "DbClusterWriter" , { instanceType : ec2.InstanceType.of( ec2.InsetanceClass.T4G, ecc2.InstanceSize.LARGE, ), } ), // リードレプリカを設置 readers : [ rds.ClusterInstance.provisioned( "DbClusterReader" , { instanceType : ec2.InstanceType.of( ec2.InsetanceClass.T4G, ecc2.InstanceSize.LARGE, ), } ), ] , } ); 最後に管理者パスワードは定期的に更新するようにします。 import * as sm from 'aws-cdk-lib/aws-secretsmanager' ; new sm.SecretRotation( this , "PasswordRotation" , { application : sm.SecretRotationApplication.POSTGRES_ROTATION_SINGLE_USER, // 保存先 secret : masterPassword, target : db, // 1度実行したら1週間後に実行 automaticallyAfter : cdk.Duration.days( 7 ), // パスワードに入れない文字を設定 excludeCharacters , } ); ここまでくれば psql 等の PostgreSQL クライアントで接続できます。 RDS が用意ができたら NetBox が接続するために必要な環境を RDS 内に作ります。 詳しくは ドキュメント に記載があるのでそちらを参照してください。 簡易には次のスクリプトを流せば準備完了です。 CREATE DATABASE netbox; CREATE USER netbox WITH PASSWORD ' <パスワード> ' ; ALTER DATABASE netbox OWNER TO netbox; 用意したら設定したパスワードを AWS Secrets Manager へ保存しておきます。 こうすることで NetBox のデプロイ時にシークレット情報を直接埋め込むことなくシークレット情報を参照できます。 私たちは既存の NetBox 環境があるので、上記設定で必要な初期化を PostgreSQL に行ったのち、以下の手順でバックアップを取得し復元作業を実施しました。 # 事前にユーザーにバックアップと復元計画を周知した上で既存 PostgreSQL から pg_dump で論理バックアップ docker-compose exec postgresql pg_dump -h postgres -U netbox netbox > db.dump # RDS へ接続できる仮想マシンを用意し、 db.dump をコピーしてその上で実行する # ダンプファイルから復元して netbox データベースを再構築 # コマンド実行後にパスワードの入力を求められるので事前に RDS の管理者アカウントのパスワードを AWS Secrets Manager から取得しておく必要がある psql -h "<RDS のマスター DB エンドポイント>" -U postgresAdmin -W < db.dump ElastiCache Redis には アクセス制御機能 があり、ユーザーに対してさまざまな制御を実現しています。 Redis 版 ElastiCache にもこの機能があり、 ユーザーを管理する機能 があります。 まず各種アクセス権限を設定したユーザーがおり、それをまとめておくユーザーグループがあるという状態です。 ユーザーグループには default というユーザー名を持つユーザーを必ず含めなければなりません。 そこで default ユーザーを作成し、 Redis に紐付けるユーザーグループへその default ユーザーを追加します。 import * as sm from 'aws-cdk-lib/aws-secretsmanager' ; import * as ec from 'aws-cdk-lib/aws-elasticache' ; const defaultUserPassword = new sm.Secret( this , "DefaultUserPassword" , { secretName : "/Netbox/RedisMasterPassword" , generateSecretString : { secretStringTemplate : JSON . stringify ( { username : "default" } ), // ここで生成するパスワードは `password` というキーで登録する generateStringKey : "password" , // Redis AUTH コマンドによる認証によって使用できる記号は制限されている // // https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/auth.html#auth-overview excludeCharacters : "@%*()_+=~`{}|[] \\ : \" ;'?,./" , } , } ); const defaultUser = new ec.CfnUser( this , "DefaultUser" , { // ユーザーにつける ID は英小文字とハイフンしか受け付けない userId : "netbox" , userName : "default" , engine : "redis" , // 全ての権限つける accessString : "on ~* &* +@all" , // 生成したパスワードを使用するように設定 passwords : defaultUserPassword.secretValueFromJson( "password" ).unsafeUnwrap(), } ); const userGroup = new ec.CfnUserGroup( this , "UserGroup" , { // ユーザーグループにつける ID は英小文字とハイフンしか受け付けない userGorupId : "netbox" , engine : "redis" , userIds : [ defaultUser.userId ] , } ); ユーザーグループがあれば Redis を構成できます。 new ec.CfnReplicationGroup( this , "ReplicationGroup" , { replicationGroupDescription : "netbox" , engine : "redis" , // バージョンは 6.2 を使用 engineVersion : "6.2" , // Redis を動かす仮想マシンの CPU サイズやメモリーを設定 cacheNodeType : "cache.t5g.medium" , // Redis にはさまざまな設定項目があるが、ベストプラクティスのつまったデフォルトのものを利用する cacheParameterGroup : "default.redis6" , numNodeGroups : 1 , replicasPerNodeGroup : 2 , // TLS 有効化 atRestEncryptionEnabled : true , transitEncryptionEnabled : true , // 作成したユーザーグループを紐付け userGroupIds : [ userGroup.userGroupId ] , // 地理分散して冗長性確保 multiAzEnabled : true , // 英小文字とハイフンしか受け付けない replicationGropId : "netbox" , } ); NetBox NetBox は Docker Compose 化したものがあるので、そちらを参照にして進めます。 GitHub - netbox-community/netbox-docker: 🐳 Docker Image of NetBox 起動に必要となる環境変数は configuration/configuration.py にあります 8 。 以上の情報をもとにサービスを構築していきます。 ECS は以下の関係図式のようなコンポーネントで成り立っています。 タスクとは1つまたは複数の Docker コンテナの集合でタスク内の Docker コンテナは同一ホストで実行されます。 タスク定義は名前の通りタスクの定義を持つもので、タスク定義の内容を元にタスクが起動されます。 サービスはタスクを管理するもので指定された数のタスク数を維持してくれます。 タスクが失敗したら同じタスク定義を元に別のタスクを起動しなおしたりといったことを実施してくれます。 クラスターはサービスやタスクをまとめるための論理的なグループです。 本来は1つ1つのコンポーネントを記載していくのですが、現在の CDK では ALB を配置し、その後ろに ECS コンポーネントを配置するだけであれば ApplicationLoadBalancedFargateService という各種 ECS コンポーネント + Application Load Balancer をまとめてデプロイしてくれるパーツを提供しています。 そのため、今回はこちらを利用して Docker コンテナの実行環境や実行時に必要な情報を設定するのみとして実装量を減らしました。 import * as ecs from 'aws-cdk-lib/aws-ecs' ; import * as et from 'aws-cdk-lib/aws-ecs-patterns' ; const dbSecretName = "<PostgreSQL のシークレット情報を持つ AWS Secrets Manager のシークレット名>" ; new et.ApplicationLoadBalancedFargateService( this , "NetBox" , { // チームでしか利用しないため、アクセス頻度も低くそこまで CPU は必要ないので 0.5 vCPU を利用 cpu : 512 , // チームでしか利用しないため、アクセス頻度も低くそこまでメモリーも必要ないので 1024 MB に設定 memoryLimitMiB : 1024 , // 環境は安定して利用できる Linux/x85_64 で動かす runtimePlatform : { cpuArchitecture : ecs.CpuArchitecture.X86_64, operatingSystemFamily : ecs.OperatingSystemFamily.LINUX, } , taskImageOptions : { // Docker Compose 化された NetBox で指定された Docker リポジトリーを使用 // // https://github.com/netbox-community/netbox-docker/blob/0c99ff8b5663db3e0db5a45660cebda9f917508b/docker-compose.yml#L3 image : ecs.ContainerImage.fromRegistry( "netboxcommunity/netbox:latest" ), // NetBox は 8080 番ポートで動作している containerPort : 8080 , environment : { DB_HOST : "<設置した RDS のマスター DB の持つエンドポイント>" , DB_NAME : "netbox" , DB_PORT : "5432" , REDIS_HOST : "<設置した ElastiCache のプライマリーエンドポイント>" , REDIS_PORT : "6379" , // SSL は入れておくことを推奨 REDIS_SSL : "True" , } , // パスワードや秘密鍵等秘密にしておきたい環境変数はこちらに設定 secrets : { DB_USER : ecs.Secret.fromSecretsManager(dbSecretName, "username" ), DB_PASSWORD : ecs.Secret.fromSecretsManager(dbSecretName, "password" ), // さまざまなハッシュに利用される値 // こちらも事前に AWS Secrets Manager に登録しておくこと // 詳しくは以下の URL を参照 // // https://netboxlabs.com/docs/netbox/en/stable/configuration/required-parameters/#secret_key SECRET_KEY : ecs.Secret.fromSecretsManager( "<シークレットキーを保管する AWS Secrets Manger のシークレット名>" , "<シークレットの参照キー>" ), REDIS_PASSWORD : ecs.Secret.fromSecretsManager( "<設置した Redis の default ユーザーのパスワードを持つ AWS Secrets Manager のシークレット名>" , "password" ), } , } , } ); これらをまとめた上でデプロイすると NetBox 環境が生成されます。 注意点 少し高度な内容になります。 CloudFormation では管理の単位をスタックという単位で行っています 9 。 スタックによってさまざまなリソースを一括で作成・更新・削除でき、削除に失敗すれば元の状態へロールバックしてくれます。 このスタックに変更を加えると場合によってはリソースを削除・再生成するという手順を踏むことがあります。 挙動次第では DB やキャッシュというものの削除・再作成まで走ることがあります。 何度作り直しても問題ない仮想マシンや ECS クラスター等のリソースであればそこまで困ることはありません。 ですが、あまりにも1つのスタックにまとめすぎると何かのパラメータ変更と共にスタックの全てが再作成されることもあり得ます。 場合によっては識別子が一意でなければならない影響で作成に失敗し、ロールバックしようとするも削除されていないものが残っていてにっちもさっちもいかなくなるということも起こります。 特に RDS や ElastiCache は削除や変更は慎重におこなうべきものであり、つくりあげた環境が削除や更新もできなくなるという状況は避けたいです。 そこで CloudFormation スタックを1つで管理はせずに小さく RDS / ElastiCache / NetBox でわけて管理しています。 CloudFormation には Nested Stack という機能 10 もあり、スタックは1つにまとめつつもサブのスタックとして管理もできます。 しかし、Nested Stack があるからと言っても更新頻度が頻繁なものとそうでないものを混ぜると更新頻度の高いものにひっぱられて一斉に更新されることがあります。 Web サーバーは更新頻度が高い一方、 RDS や ElastiCache の更新頻度は高くないことが予想されるため、全てを一緒に含めてしまうと運用が複雑化してしまいます。 このように無用な混乱や運用の複雑化を避けるため、 RDS や ElastiCache 等ステートフルなリソースは個別のスタックで管理すると楽になることがあります。 まとめ ここまででオンプレにあった NetBox を AWS へ CDK を利用して移植する方法について記載してきました。 幸い NetBox が PostgreSQL や Redis を利用しており、 AWS にこれらをマネージするサービスがあったため、それらを利用して簡単にサービスを構築し、運用も省力化可能になりました。 今後は RDS や ElastiCache のアップグレードにおいてインプレースでのアップグレードに対応しているのでそちらを試したり、バックアップの定期取得をおこなったりといったことを計画しており、これらを CDK といった IaC と実体との整合性を考慮しながら実施していこうと思います。 https://github.com/netbox-community/netbox/blob/597fc926c0084ed0935d03f95ca02dc94250be29/LICENSE.txt ↩ https://netboxlabs.com/docs/netbox/en/stable/introduction/#application-stack ↩ https://aws.amazon.com/jp/rds/postgresql/ ↩ https://netboxlabs.com/docs/netbox/en/stable/introduction/#application-stack ↩ https://aws.amazon.com/jp/elasticache/memcached/ ↩ https://github.com/netbox-community/netbox-docker ↩ https://aws.amazon.com/jp/blogs/news/ec2-classic-is-retiring-heres-how-to-prepare/ ↩ https://github.com/netbox-community/netbox-docker/blob/0c99ff8b5663db3e0db5a45660cebda9f917508b/configuration/configuration.py#L60-L338 ↩ https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/stacks.html ↩ https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/using-cfn-nested-stacks.html ↩

こんにちは、イノベーションセンターの加藤です。普段はコンピュータビジョンの技術開発やAI/機械学習（ML: Machine Learning）システムの検証に取り組んでいます。一方で、兼務で生成AIチームに参加し、大規模言語モデル（LLM: Large Language Model）に関する技術の調査を行なっています。 この記事では、日本語のコード生成のデータセットが無い条件下で、進化的モデルマージを活用することで日本語とソースコード生成に特化した大規模言語モデル(LLM)を合成した試みについて紹介します。 目次 目次 モデルマージとは 進化的モデルマージとは 利用したモデル 日本語LLM コード生成特化 MergeKitによる実験 利用モデル マージ用データセット JSQuAD CoNaLa 評価用データセット JCommonsenseQA HumanEval JHumanEval 実験結果 考察 JHumanEvalの回答に必要な日本語能力 CodeLlamaのマージ困難性 まとめ モデルマージとは 学習済みモデルの重みを組み合わせることで、元のモデルの持つ能力を組み合わせたり精度を向上させたりできる手法です。例えばベースモデルの重み に対し、さまざまなハイパーパラメータでファインチューニングした複数の派生モデルの重み があるとき、これらを平均した はmodel soupと呼ばれ元の派生モデルよりも性能が良くなり、かつ入力の変化にも頑健になると言われています 1 。 一方で、ベースとなるLLMの重み に対し数学の問題データでファインチューニングした派生モデル と、ソースコード生成のためのデータセットでファインチューニングした派生モデル があったとします。このとき、派生モデルの重みとベースモデルの重みの差分 はtask vectorと呼ばれ、ファインチューニングによって得られた新しい能力の重みと見なすことができ、これの和を取ることで数学とプログラミング両方に強い新たなLLMの重み を作ることができます。このような差分を線型結合するテクニックはtask arithmetic 2 と呼ばれ、足すだけでなく引くことで特定の性質（例えば攻撃性など）を取り除くという操作も可能とされています。 これらの手法は複数のモデルの出力を合成するアンサンブル手法とは違い、モデルのサイズが変化しないので推論速度が元のモデルから変化しないという利点があります。非線形操作を多量に含んでいるモデルの重みを単純に足し引きする操作は直観的に機能しなさそうですが、実験的にはうまくいく 3 ようで言語モデルや画像生成などさまざまな分野でいろいろなマージモデルが作成されています。 また、重みの合成方法についても単純な線形補間にとどまらないさまざまな手法が提案されています。今回の記事では、task vectorからランダムにパラメータを0にして残りのパラメータをスケーリングするDARE 4 という手法と、マージするパラメータの符号ができるだけ一致するようにいくつかのパラメータを0にするTIES 5 という手法を組み合わせたものを利用します。いずれの手法も、それぞれのtask vectorには能力の発現に実際に寄与するパラメータは少数であるという仮定をおき、そのようなパラメータがもう一方のtask vectorに乱されないように工夫をするというアプローチによって、より性能の良いマージモデルの作成を可能にしています。 進化的モデルマージとは モデルのパラメータを合成する際の重み付け係数やDAREなどにおける非ゼロの密度などは、マージ後の精度を左右する重要なハイパーパラメータです。このハイパーパラメータを探索するために進化的アルゴリズムを活用したのがSakana AIの提案した進化的モデルマージです 6 。この手法は指定されたデータセットの評価指標を最適化するようなパラメータを繰り返し探索するもので、データセット全体に対する評価を何度も実行する必要がある一方で勾配を必要としないという利点があります。Sakana AIが提案した手法はDAREとTIESを併用したマージ手法とCMA-ESと呼ばれる進化的アルゴリズムを組み合わせたもので、モデルマージの際に広く使われているライブラリであるmergekit 7 にも実装されています。この記事では、mergekitに実装された進化的モデルマージを用いて、日本語LLMモデルとコード生成モデルを合成してみました。 利用したモデル マージに利用したモデルを紹介します。モデルマージの制約上、全てのモデルは同じベースモデルから派生している必要があるため、今回はMeta社の基盤モデルであるLlama2 (70億パラメータ)をベースとした派生モデルを合成しました。利用モデルの派生関係は以下の図に示しています。 日本語LLM 日本語を理解できるLLMとして今回は ELYZA Japanese Llama Instruct 7B を利用しました。Llama2をベースに約180億トークンの日本語データセットで追加事前学習したモデルであり 8 、日本語に対する高い処理能力が期待できます。 コード生成特化 マージ用のモデルとして、大部分をソースコードが占める計5000億トークンのデータセットで追加学習し質問応答用にファインチューニングした CodeLlama Instruct と、ソースコードに関する質問応答データセットである Evolved CodeAlpaca を用いてLlama2をファインチューニングした Llama-2-7b-evolcodealpaca の2つを用意しました。 また、比較対象としてCodeLlama Instructに日本語データセットを追加事前学習させた ELYZA Japanese CodeLlama Instruct 7B を用意し、マージモデルがどれくらいこの追加事前学習モデルに匹敵するかを調査しました。 MergeKitによる実験 利用モデル mergekitに実装された進化的モデルマージを用いて、以下の組み合わせでモデルマージを行いました。 ELYZA Japanese Llama Instruct 7B + CodeLlama Instruct ELYZA Japanese Llama Instruct 7B + Llama-2-7b-evolcodealpaca マージモデルと元モデルとの関係は次の図のようになります。 マージ用データセット ハイパーパラメータ探索の際の評価用データセットは以下の2つを利用しました。 JSQuAD 日本語向けの言語理解ベンチマークJGLUE 9 の一部であり、質問応答データセットSQuADの日本語版です。日本語の文章読解能力を評価するために使用しました。回答は文章生成で行いますが、正しい形式で答えさせるために2つの例題をプロンプトに加えています。この工夫によって、LLMに「はい、お答えします。」のような無意味な回答をしないように誘導できます。 指標は exact_match を使いました。これはLLMの出力が想定回答と完全一致した場合に正解とみなすものです。 プロンプトと想定回答の例 入力 以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。 ### 指示: 与えられた文脈から、質問に対する答えを抜き出してください。 ### 入力: {例題1} ### 応答: {回答1} ### 指示: 与えられた文脈から、質問に対する答えを抜き出してください。 ### 入力: {例題2} ### 応答: {回答2} ### 指示: 与えられた文脈から、質問に対する答えを抜き出してください。 ### 入力: 文脈：梅雨（つゆ、ばいう）は、北海道と小笠原諸島を除く日本、朝鮮半島南部、中国の南部から長江流域にかけての沿海部、および台湾など、東アジアの広範囲においてみられる特有の気象現象で、5月から7月にかけて来る曇りや雨の多い期間のこと。雨季の一種である。 質問：日本で梅雨がないのは北海道とどこか。 ### 応答: 出力 小笠原諸島 CoNaLa CoNaLa 10 はStack Overflowから収集されたプログラミング言語のデータセットであり、質問文と短いPythonプログラムのペアからできています。ソースコード生成の能力を評価するためにこれを利用しました。こちらも2つの例題をプロンプトに加えています。 指標はBLEU 11 が使われます。 プロンプトと想定回答の例 入力 Answer the following instructions in one line of Python code: Instruction: {例題1} Solution: {回答1} Instruction: {例題2} Solution: {回答2} Instruction: send a signal `signal.SIGUSR1` to the current process Solution: 出力 os.kill(os.getpid(), signal.SIGUSR1) 評価用データセット マージ後のモデルの性能を測るために、上記のデータセットに加えて、以下の日本語データセットとプログラミング言語データセットを利用しました。 JCommonsenseQA JSQuADと同様に日本語向けの言語理解ベンチマークJGLUEの一部であり、常識を問うタスクCommonsenseQAの日本語版です。日本語の文章読解能力を評価するためにJSQuADと共に使用しました。3つの例題をプロンプトに加え、選択式で答えさせています。指標は accuracy を使いました。 入出力例 入力 以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。 ### 指示: 与えられた選択肢の中から、最適な答えを選んでください。出力は以下から選択してください： {選択リスト1} ### 入力: {例題1} ### 応答: {回答1} ### 指示: 与えられた選択肢の中から、最適な答えを選んでください。出力は以下から選択してください： {選択リスト2} ### 入力: {例題2} ### 応答: {回答2} ### 指示: 与えられた選択肢の中から、最適な答えを選んでください。出力は以下から選択してください： {選択リスト3} ### 入力: {例題3} ### 応答: {回答3} ### 指示: 与えられた選択肢の中から、最適な答えを選んでください。出力は以下から選択してください： - 掲示板 - パソコン - マザーボード - ハードディスク - まな板 ### 入力: 電子機器で使用される最も主要な電子回路基板の事をなんと言う？ ### 応答: 出力 マザーボード HumanEval HumanEval 12 は関数名とそのドキュメント（説明文）から内部のPython実装を生成させるデータセットです。一般的な文書生成の評価手法とは異なり、実際に実装を動作させてテストが通るかどうかで生成結果を評価しています。変数名が正解と異なっていてもプログラムが正しければ正解とみなされるため、より実用に向いた評価指標といえます。また、人手で作成されたため、少量ながら高品質なデータであることも特徴です。 指標は pass@k が使われ、LLMが 個の答えを生成し1つでも合っていれば正解とみなします。 入出力例 入力 from typing import List def has_close_elements (numbers: List[ float ], threshold: float ) -> bool : """ Check if in given list of numbers, are any two numbers closer to each other than given threshold. >>> has_close_elements([ 1.0 , 2.0 , 3.0 ], 0.5 ) False >>> has_close_elements([ 1.0 , 2.8 , 3.0 , 4.0 , 5.0 , 2.0 ], 0.3 ) True """ 出力 for idx, elem in enumerate (numbers): for idx2, elem2 in enumerate (numbers): if idx != idx2: distance = abs (elem - elem2) if distance < threshold: return True return False テスト def check (candidate): assert candidate([ 1.0 , 2.0 , 3.9 , 4.0 , 5.0 , 2.2 ], 0.3 ) == True assert candidate([ 1.0 , 2.0 , 3.9 , 4.0 , 5.0 , 2.2 ], 0.05 ) == False assert candidate([ 1.0 , 2.0 , 5.9 , 4.0 , 5.0 ], 0.95 ) == True assert candidate([ 1.0 , 2.0 , 5.9 , 4.0 , 5.0 ], 0.8 ) == False assert candidate([ 1.0 , 2.0 , 3.0 , 4.0 , 5.0 , 2.0 ], 0.1 ) == True assert candidate([ 1.1 , 2.2 , 3.1 , 4.1 , 5.1 ], 1.0 ) == True assert candidate([ 1.1 , 2.2 , 3.1 , 4.1 , 5.1 ], 0.5 ) == False JHumanEval JHumanEval 13 はHumanEvalのドキュメント部分を日本語化したもので、日本語を理解しかつソースコードを生成する能力を測ることができます。 入力例 from typing import List def has_close_elements (numbers: List[ float ], threshold: float ) -> bool : """リストnumbersの中に、与えられたthresholdより近い２つの数値が存在するか判定する >>> has_close_elements([ 1.0 , 2.0 , 3.0 ], 0.5 ) False >>> has_close_elements([ 1.0 , 2.8 , 3.0 , 4.0 , 5.0 , 2.0 ], 0.3 ) True """ 実験結果 マージ前、マージ後、比較用モデルそれぞれの評価結果は次のようになりました。 model JSQuAD (2shot, exact match) JCommonsenseQA (3shot) CoNaLa (2shot, bleu) HumanEval (pass@1) JHumanEval (pass@1) (J) ELYZA Japanese Llama Instruct 0.6673 0.7194 0.2743 0.1280 0.0976 (C1) CodeLlama Instruct 0.6855 0.6452 0.3582 0.3293 0.2744 (C2) Llama-2-7b-evolcodealpaca 0.6171 0.58 0.2435 0.3354 0.2683 --- --- --- --- --- --- ELYZA Japanese CodeLlama Instruct 0.6828 0.7373 0.3358 0.3232 0.2378 --- --- --- --- --- --- J + C1 0.3165 0.5505 0.2236 0.0732 0.0610 J + C2 0.6517 0.7051 0.2412 0.3415 0.2134 作成した2つのマージモデルのうち、Llama-2-7b-evolcodealpacaを用いた方(J + C2)は日本語能力(JSQuAD,JCommonsenseQA)を保ったままコード生成の性能を元の日本語LLMから向上させることができ、追加事前学習を行なったELYZA Japanese CodeLlama Instructとほぼ同等のHumanEval, JHumanEval性能を持たせることができました。 考察 JHumanEvalの回答に必要な日本語能力 結果を見ると、JHumanEvalの性能はJSQuADやJCommonsenseQAよりもHumanEvalの性能に相関しているようです。関数ドキュメント程度の文章量ではあまり読解能力や常識を必要としなくてもうまくコード生成ができるようです。HumanEvalでは網羅できないような、長く複雑な仕様文書からのコード生成能力を測る必要がありそうです。 CodeLlamaのマージ困難性 日本語LLMとCodeLLamaをマージすると（J + C1）全ての性能が大きく劣化してしまいました。DAREの論文でも挙げられている通りCodeLlamaは追加学習量が多く、ベースモデルからパラメータが大きくずれているためか上手くマージできないようです。この問題は進化的アルゴリズムによるハイパーパラメータ探索でも解決が難しそうだということがわかりました。 まとめ 進化的モデルマージを利用して日本語LLMとコード生成LLMを合成し、両方の能力を獲得できるか実験しました。結果として、日本語のタスクとコード生成のタスクの両方で性能の良いモデルは作成できたものの、日本語からソースコードを生成するというタスクは設計が難しそうなこと、ベースラインからの差分が大きな派生モデルはハイパラ探索を活用してもマージ困難であることがわかりました。 Model soups: averaging weights of multiple fine-tuned models improves accuracy without increasing inference time. https://arxiv.org/abs/2203.05482 ↩ Editing Models with Task Arithmetic. https://arxiv.org/abs/2212.04089 ↩ モデルマージの理論的な背景について研究している論文に次のようなものがあります。 Task Arithmetic in the Tangent Space: Improved Editing of Pre-Trained Models. https://arxiv.org/abs/2305.12827 ↩ Language Models are Super Mario: Absorbing Abilities from Homologous Models as a Free Lunch. https://arxiv.org/abs/2311.03099 ↩ TIES-Merging: Resolving Interference When Merging Models. https://arxiv.org/abs/2306.01708 ↩ https://sakana.ai/evolutionary-model-merge-jp/ ↩ https://github.com/arcee-ai/mergekit ↩ https://note.com/elyza/n/na405acaca130 ↩ https://techblog.yahoo.co.jp/entry/2022122030379907/ ↩ https://conala-corpus.github.io ↩ https://huggingface.co/spaces/evaluate-metric/bleu ↩ Evaluating Large Language Models Trained on Code. https://arxiv.org/abs/2107.03374v2 ↩ https://huggingface.co/datasets/kogi-jwu/jhumaneval ↩

はじめに こんにちは、イノベーションセンターの真崎です。 6月にDatabricksの年次カンファレンス Data+AI Summit 2024 が開催され、 AI/BI Genie というDatabricks上のデータを自然言語で検索・分析・可視化できる機能が発表されました。 本記事では、AI/BI Genieについて機能の概要、及び実際に使用した流れを解説します。 Databricksとは Databricksはデータウェアハウスとデータレイクの両方の強みを兼ね備えたデータとAIのためのオープンな統合プラットフォーム「 データ・インテリジェンス・プラットフォーム 」を提供しています。 AI/BI Genieとは AI/BI Genieとは、Databricks上の構造化データに対して自然言語を用いて検索、分析、可視化を行うことができる機能です。 Databricksでユーザーが特定のデータにアクセスして分析したい場合、従来はPythonなどのプログラミング言語やSQLを用いてデータを抽出する必要がありました。 しかし、AI/BI Genieの登場により自然言語を用いて対話的にデータを抽出して分析できるようになりました。 AI/BI Genieの構成要素 ここでは、AI/BI Genieの構成要素であるGenieスペース、及びGenieチャットの概要について解説します。 Databricksのコンソール上で、AI/BI GenieはGenie>Genieスペース>Genieチャットという構造になっています。 Genie、Genieスペース、Genieチャットの役割は以下のようになっています。 Genie Genieスペースを管理する画面 Genieスペース チャットのまとまり Databricksの計算リソースであるクラスター設定やテーブル設定も管理できる チャット Genieと会話するためのインターフェース 会話の履歴はGenieスペース内のチャットごとに管理される Genieスペースでは以下の設定を管理できます。 Title スペースの名前 Description スペースの説明 Default warehouse スペースで使用するクラスター Tables スペースで検索・分析・可視化の対象とするテーブル Sample Question チャットUI上で、質問可能な内容の例を表示する AI/BI Genieの設定方法については 公式ドキュメント を参照してください。 Genieと会話してみる ここでは、AI/BI Genieに対して実際に自然言語でデータの取得を依頼して意図したデータを適切に取得できるか、実際にAI/BI Genieを使用して確認します。 やりたいこと Databricks内のデータから、誰がどのくらいDatabricksにアクセスしているかについて、該当のデータを持つテーブルを検索・集計・可視化する。 アプローチ システムテーブル( system.access.audit  ) は監査ログに関するテーブルとして設計されており、ユーザーアクセスに関するイベントを記録しています。 そのため、今回のアクセス解析はこのテーブルを集計することで実現可能です。 そこで以降では、AI/BI Genieがシステムテーブル( system.access.audit )を使用して正しく集計・可視化できるかを確認します。 ※本記事で扱う システムテーブル は、事前に有効化しておく必要があります。 Genieスペースの作成 まず、 Genieスペースの設定項目 を設定し、Genieスペースを作成します。 AI/BI Genieはユーザーの質問に対してTablesで選んだテーブルを基に情報を検索するので、事前に該当しそうなテーブルを検索対象に入れておきます。 今回はシステムによる自動作成のログテーブルを検索対象にしたいので system.access 配下のテーブルにチェックを入れます。 データ検索 続いて、Genieスペースが作成できると自動でチャットUIに遷移するのでこの画面で会話を始めます。AI/BI Genieに問い合わせをするには画面下部のチャットボックスに質問文を入力します。 まず、目的のデータの集計が行えるテーブルがあるかを自然言語で問い合わせます。 system.access.audit  テーブルからアクセス回数を集計できるということなので、 system.access.audit  テーブルのデータがどういったものか尋ねます。 AI/BI Genieによると、 system.access.audit  テーブルはDatabricks ワークスペース内でのユーザー行動に関する監査ログであるということであり、公式ドキュメントのテーブル定義と合致するため正しい分析設計ができていることが分かりました。 データ集計 これまでと同様に自然言語でAI/BI Genieにユーザーごとのログの集計を依頼をすると、AI/BI Genieが生成したSQL文が実行され、集計結果がインターフェースに表示されます。 なお、AI/BI Genieが実行したSQL文はAI/BI Genieの回答に添付されています。 データ可視化 最後に、AI/BI Genieに上記のカウント結果を円グラフで可視化してもらいました。 AI/BI Genieに関するTips グラフの可視化にはVega-Liteが利用可能 AI/BI Genieが可視化に使うツールは Vega-Lite がデフォルトとなっていますが、matplotlibやseabornなど別のライブラリも使えるかを確認してみます。 AI/BI Genieにpythonのseabornライブラリを用いた可視化を依頼しましたが、AI/BI GenieからはVega-Liteを用いた可視化のみ可能と返ってきました。 実際にAI/BI Genieが可視化したデータを見ると全てのグラフがVega-Liteが対応するjson形式で描画されています。 円グラフ描画時の注意点 AI/BI Genieが生成した円グラフは、デフォルトでは件数順にソートされません。 そのため、AI/BI Genieが理解できるようにソートを指示する必要があります。 以下では未ソートの円グラフとソートされた円グラフの作成方法をそれぞれ見ていきます。 デフォルトの円グラフ（未ソート） まず、AI/BI Genieに詳細を指定せず円グラフを描いてもらうと、件数順のソートなどはされないまま円グラフが可視化されます。 ソートされた円グラフ 件数順のソートができていない旨を指摘すると、AI/BI Genieがコードの問題点をセルフレビューし、新たな円グラフの作成コードを提案します。 ここでAI/BI Genieに対して再度可視化を依頼すると、AI/BI Genieによりソートされた円グラフが可視化されます。 AI/BI Genieへの可視化の依頼方法を工夫することで、ソートされた円グラフを作成できました。 なお、棒グラフや折れ線グラフについては特に質問の仕方を工夫せずとも件数ソートができます。 まとめ 本記事では以下の2点について解説をしました。 AI/BI Genieの概要 AI/BI Genieを用いたデータ検索・集計・可視化 AI/BI GenieはDatabricks上のデータを自然言語で検索・分析・可視化できるDatabricksのサービスです。AI/BI Genieの登場によりDatabricksでのデータ活用がプログラミングを使えないビジネス現場レベルまで浸透することが予想されます。

本記事では6月に開催された DATA+AI Summit 2024 でGeneral Availabilityが発表された Databricks のDeltaLake Universal Formatの機能を使ってクロスプラットフォームでの分析を実現する方法について紹介します。 DeltaLake Universal FormatはDeltaLakeに保存されたデータをApache Icebergなどの異なるフォーマットで読み出すことができるようにする機能です。本記事では実際にDatabricks上でDeltaLake Universal Formatの機能を有効にしたテーブルを作成し、 Amazon Athena からApache Iceberg形式でクエリを発行するサンプルを用いて、機能の使い方と本機能のメリットについて解説します。 目次 目次 はじめに データレイクとOpen Table Format (OTF) Databricks DeltaLake Universal Format DeltaLake Universal Formatを利用したクロスプラットフォームでの分析 DeltaLake Universal Format対応テーブルの作成 DeltaLake Universal Format(Iceberg互換) Tableの確認 Amazon Athenaの設定 Amazon Athenaからのクエリの発行 まとめ 参考文献 はじめに こんにちは、NTTコミュニケーションズの露崎です。 本記事では6月に開催された DATA+AI Summit 2024 でGeneral Availabilityが発表された Databricks のDeltaLake Universal Formatの機能を使ってクロスプラットフォームでの分析を実現する方法について紹介します。 データレイクとOpen Table Format (OTF) DeltaLake Universal Formatを解説するにあたり、前提となるデータレイクとOpen Table Formatについて説明します。 データレイクは構造化データ、非構造化データを扱うことのできる一元的なリポジトリです。データレイクでは未加工かつ多様なデータを格納するため、データを分析するためにはデータベースやデータウェアハウスのような構造化されたデータとして取り扱う必要があります。 Open Table Format (OTF) はこうしたデータレイク上に構造化されたテーブル形式を表現するためのフォーマットであり、ACIDトランザクションなどデータベースで取り扱う操作をデータレイク上のデータに対して実現します。 DeltaLake や Apache Iceberg 、 Apache Hudi は、OTFを提供するOSSのソフトウェアです。SparkやTrinoといったOSS分散処理ソフトウェアはこれらのOTFの機能を通してデータレイク上のデータにテーブル形式でアクセスできます。 従来、これらのOTFはそれぞれのOSSコミュニティで開発されており、分析プラットフォーム毎に対応するフォーマットが異なるため、特定のプラットフォームにロックインされるという課題がありました。 Databricks Databricksはデータウェアハウスとデータレイクの両方の強みを兼ね備えたデータとAIのためのオープンな統合プラットフォーム「データ・インテリジェンス・プラットフォーム」を提供しています。Databricksではデータレイクのテーブルフォーマットとして DeltaLake をサポートしていましたが、こうした互換性の問題を解決する DeltaLake Universal Format 機能のGeneral Availability (GA)を2024年6月のDATA+AI Summitにて発表しました。 DeltaLake Universal Format 引用元: https://www.databricks.com/jp/blog/announcing-delta-lake-30-new-universal-format-and-liquid-clustering DeltaLake Universal FormatはDeltaLakeのフォーマットで保存されたデータをApache Iceberg形式、Apache Hudi形式で読み出すことを可能とするDeltaLakeの機能です。DeltaLake Universal FormatはDeltaLake、Apache Iceberg、Apache Hudiのいずれのテーブルフォーマットも実データは Apache Paruquet 形式で保存されていることを利用し、DeltaLakeへ書き込まれたデータのテーブルフォーマットに関するメタデータをそれぞれのテーブルフォーマットに変換することで異なるテーブルフォーマットでの読み取りをサポートします。 より具体的な利用イメージを掴んで頂くために、以降では実際にDatabricks上でDeltaLake Universal Formatの機能を有効にしたテーブルを作成し、異なるプラットフォームであるAmazon AthenaからApache Iceberg形式でクエリを発行する方法について解説します。 DeltaLake Universal Formatを利用したクロスプラットフォームでの分析 ここではAzure Databricks上に構築したDeltaLake Universal Format対応テーブルをAmazon Athenaで分析するための設定を行なっていきます。 DeltaLake Universal Format対応テーブルの作成 まず、DeltaLake Universal Formatの機能を有効にするためには、テーブルを作成する際に delta.enableIcebergCompatV2 , delta.universalFormat.enabledFormats の2つのプロパティを設定します。 以下は、 uniform_test というカタログに nyctaxi というスキーマを作り、 trips というテーブルを作成するSQLで、DatabrciksのSQL Editorから実行可能です。 SQLの実行にはDeltaLake Universal Formatが利用可能なDatabricks Runtime 14.3LTS以降のRuntimeを使用します。 1 今回はAmazon AthenaからSpark、Iceberg形式で読み取るため、 delta.universalFormat.enabledFormats に iceberg を設定します。 また、このSQLでは Databricksのワークスペースがデフォルトで提供しているNewYorkのタクシーの運転履歴のデータサンプル を実データとしてこのテーブルに入れています。 CREATE CATALOG IF NOT EXISTS uniform_test; -- create test catalog USE CATALOG uniform_test; CREATE SCHEMA IF NOT EXISTS nyctaxi; -- create test schema CREATE TABLE uniform_test.nyctaxi.trips TBLPROPERTIES( ' delta.enableIcebergCompatV2 ' = ' true ' , -- enable iceberg convert ' delta.universalFormat.enabledFormats ' = ' iceberg ' , -- enable iceberg convert ) AS SELECT * FROM samples.nyctaxi.trips; DeltaLake Universal Format(Iceberg互換) Tableの確認 DeltaLake Universal Formatを作成後、機能が有効になっているかどうかを以下のSQLで確認します。 DESCRIBE EXTENDED uniform_test.nyctaxi.trips; このSQLを実行すると nyctax.trips テーブルの情報が表示されます。以下は実行結果の一部抜粋で、このように Converted delta version 、 Converted delta timestamp が表示されていれば、すでにIceberg形式のメタデータが作成されIcebergテーブルとして読み出し可能な状態になっています。 Amazon Athenaの設定 次にAmazon Athenaでこのテーブルを読み出すための設定をします。設定はAthenaのNotebook EditorからEdit Sessionを選択し、セッションのプロパティを設定します。 プロパティには以下を設定します。設定値については検証時の値のためパッケージバージョン等については利用環境に合わせて変更してください。 公式ドキュメント ではIceberg形式でのメタデータ読み取りに必要なプロパティが紹介されていますが、ここでは参照したメタデータから実際のデータの読み取るためにAzure DataLake Storageのアクセスキーも設定していることに注意してください。 Key Value 備考 spark.jars.packages org.apache.hadoop:hadoop-azure:3.2.1 athenaのpyspark versionが3.2.1のためmaven の3.2.1を指定 spark.sql.catalog.spark_catalog org.apache.iceberg.spark.SparkSessionCatalog spark.sql.catalog.spark_catalog.io-impl org.apache.iceberg.aws.s3.S3FileIO azure adlsでもS3FileIOを指定 spark.sql.catalog.unity org.apache.iceberg.spark.SparkCatalog spark.sql.catalog.unity.catalog-impl org.apache.iceberg.rest.RESTCatalog spark.sql.catalog.unity.token <databricksのpersonal access token> 設定方法 spark.sql.catalog.unity.uri <databricksのapi root>/api/2.1/unity-catalog/iceberg iceberg catalogのAPIエンドポイント spark.sql.extensions org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions spark.hadoop.fs.azure.account.key.datalakedatabricksus.dfs.core.windows.net <ADLSのaccess key> OAuth等での設定等は こちら Amazon Athenaからのクエリの発行 Sparkのプロパティ設定が完了すれば、以下のようにAthenaから直接DeltaLake Universal FormatテーブルのデータにSQLを発行できるようになります。SQLを発行する対象のカタログは unity という接頭辞をつけた unity.uniform_test.nyctax.trips という指定形式になります。 catalog_name = "unity.uniform_test.nyctaxi.trips" result = spark.sql(f"SELECT * FROM {catalog_name}") print(result) result.show() まとめ 本記事ではDeltaLake Universal Formatの機能を使ってDatabricksのUnity Catalog上のデータをAmazon Athenaで分析する方法について紹介しました。 このようにDeltaLake Universal Formatを使うと、利用したいプラットフォームへ事前にデータを移動することなく、直接データを参照し分析することが可能になります。こうしたオープンテーブルフォーマットの機能を利用することで、ユーザー側のプラットフォームの選択肢が広がり、より多くのユースケースへ適応できるようになると考えられます。 参考文献 https://www.databricks.com/ https://aws.amazon.com/jp/athena/ https://learn.microsoft.com/ja-jp/azure/databricks/delta/uniform https://docs.delta.io/latest/delta-uniform.html ↩

みなさんこんにちは、イノベーションセンターの益本 (@masaomi346) です。 Network Analytics for Security (以下、NA4Sec) プロジェクトのメンバーとして、脅威インテリジェンス(潜在的な脅威について収集・分析したデータ)の分析をしています。 この記事では、2024年7月20日に開催されたセキュリティカンファレンスHack Fes. 2024にて、登壇したきたことについて紹介します。 ぜひ最後まで読んでみてください。 Hack Fes.について Hack Fes.は、日本ハッカー協会が主催するセキュリティカンファレンスです。 専門知識やスキルを学ぶだけでなく、参加者同士が直接交流できる機会を提供することを目的に開催されています。 堅苦しいイベントではなく、多くの人が集まることで生まれる「ワクワク感」や「楽しさ」を共有し、参加者とともに「お祭り」を作り上げていくことを目指しているセキュリティカンファレンスです。 講演以外にもさまざまなコンテンツが提供されています。 たとえば、協賛企業主催のCTFやステッカーや技術書の交換会が開催されています。 昨年から開催されており、今年で2回目の開催となります。 Hack.Fes2024のタイムテーブルが決まりました！主催のため、代表の杉浦も全ての講演を聴講できないことを心から悔しがっている（実話）ほどの豪華なラインナップとなっております！皆様のお越しをお待ちしております！ https://t.co/SV5ds1YseD — 一般社団法人日本ハッカー協会 (@JapanhackerA) 2024年6月27日 NA4Secについて NA4Secは、「NTTはインターネットを安心・安全にする社会的責務がある」を理念として、インターネットにおける攻撃インフラの解明・撲滅を目指した活動をしているプロジェクトです。 NTT Comグループにおける脅威インテリジェンスチームとしての側面も持ち合わせており、有事において脅威インテリジェンスを提供し、意思決定を支援することもあります。 イノベーションセンターを中心として、NTTセキュリティ・ジャパンやエヌ・エフ・ラボラトリーズ（以下、NFLabs.）からもメンバーが参画し、日夜攻撃インフラを追跡しています。 NA4Secの最近の活動については、以下の記事をご覧ください。 フィッシングキットから生成されたサイトの調査 (インターンシップ体験記) 社内で検知された悪性通信を調査したらドメインパーキングだった話 Hack Fes. 2024で登壇した講演について 本イベントにおいて、私は、「ブラウザ通知スパムで見る、悪意あるコンテンツが表示される仕組み」というテーマで登壇させていただきました。 インターネットにはマルウェア配布サイトや詐欺サイトなどの悪意あるコンテンツが展開されています。 本講演では、ブラウザ通知スパムを例にしてどのような仕組みで悪意あるコンテンツが表示されているのか、実例を挙げて紹介しました。 攻撃者が用意した誘導コンテンツで誘導している例の紹介 Webサイトを改竄して誘導している例の紹介 トラフィック配信システムでどのようなことが行われているのか ブラウザ通知スパムが主役となっており、かなりマニアックなネタとなっています。 ネタがネタなので、他のトラックに人が流れてしまわないか心配でしたが、見に来て下さった人がたくさんいて安心しました。 講演する前は少し不安もありましたが、思っていたよりもポジティブな反応をもらえたので、講演して良かったと思いました。 【一言講演紹介】『ブラウザ通知スパムで見る、悪意あるコンテンツが表示される仕組み』～益本 将臣氏　本講演では、悪意あるコンテンツの1つであるブラウザ通知スパムを例にして、攻撃者がどのように被害者を誘導しようとしているのかについて説明する。 https://t.co/SV5ds1Z04b 　 #hackfes2024 — 一般社団法人日本ハッカー協会 (@JapanhackerA) 2024年6月30日 さいごに 私自身、登壇した経験はあまりありませんが、今回の登壇はそこまで緊張しませんでした。 Hack Fes.というワイワイとした場の雰囲気の影響があるのかもしれません。 JSACに登壇したときもそうでしたが、聴講者として参加するのと講演者として参加するのとでは、味わう雰囲気が違うと感じました。 今後も引き続き、外部登壇を通じてセキュリティ業界を盛り上げていければと考えています。 宣伝その1 2024年8月6日・7日に、ラスベガスでBSides Las Vegasが開催されます。 NA4Secからは、以下のテーマで登壇します。 Operation So-seki: You Are a Threat Actor. As Yet You Have No Name. JSAC2024でも登壇したネタであり、あるハクティビストを追跡した内容となっています。 YouTubeでライブ配信されますので、現地に行かなくても視聴できます。 興味がある方は、ライブ配信を視聴してみてください。 ／ イベント登壇情報✨ ＼ ​ ラスベガスで開催されるセキュリティカンファレンス @BsidesLV にて、NTT ComとNFLabs.の社員が登壇🙋 ​ 詳細はこちら⬇ https://t.co/CotWhfcpy1 ​ #ドコモビジネス — ドコモビジネス｜NTTコミュニケーションズ (@NTTCom_online) 2024年7月16日 宣伝その2 2024年9月13日・14日に、名古屋でセキュリティ・ミニキャンプ in 愛知 2024が開催されます。 9月14日の専門講座にて、益本が以下の講義の講師を担当させていただきます。 Phishing Analysis ～ フィッシングサイトの仕組みを学ぶ フィッシング詐欺を取り扱っている内容となっています。 今年の夏の思い出作りに、参加してみてはいかがでしょうか。 セキュリティに興味がある学生のご応募お待ちしております。 2024年9月14日(土) 「セキュリティ・ミニキャンプ in 愛知 2024」専門講座 開催！ 📢学生参加者を募集いたします！ 参加費無料！ ✨申込締切：2024年8月12日（月）16:00まで 情報セキュリティに興味のある学生の皆様のご応募お待ちしています！ #seccamp https://t.co/nYWYQAffx2 — セキュリティ・キャンプ (@security_camp) 2024年7月10日

Hewlett Packard Enterprise (HPE) が主催する最大のテクノロジーカンファレンス、 HPE Discover 2024 が 2024年6月17日から20日に米国ラスベガスで開催されました。 この記事では HPE Discover 2024 に聴講参加して得られた知見について、主にサーバー関係のものを中心に共有します。 はじめに HPE Discover 2024 とは Keynote: Intelligence has no limits 新サーバーの発表 AI 向けサーバー サービスプロバイダー向けのサーバー 興味深かったセッション The future of liquid cooling for data centers Transforming management with Open Source Firmware for SPs Showcase 交流イベント Japan Session おわりに はじめに こんにちは、クラウド&ネットワークサービス部の 福岡 です。 普段は SDPF（Smart Data Platform）クラウドの IaaS である、 ベアメタルサーバー ・ ハイパーバイザーサービス 開発のソフトウェアエンジニアをしています。 今回、これらのサービスの継続提供にあたりサーバー周りのトレンドや動向を把握するために、HPE Discover 2024 に参加しました。 HPE Discover 2024 とは HPE Discover は HPE が年に一度主催する最大のテクノロジーカンファレンスであり、HPE が目指していくビジョンや新サービス、新製品の発表が行われる舞台です。 世界各国から HPE のテクノロジーに興味を持つ多くの参加者が集うことで知られており、今年は日本からも100名以上が参加しました。 会場も並大抵の広さではなく、今年は 11.5万平方メートル（東京ドーム2個分以上）の展示面積を持つ、米国ラスベガスの The Venetian Expo & Convention Center で開催されました。 日本からの参加者の基本的なタイムスケジュール プログラムは 「エッジ」「ハイブリッド・クラウド」「AI」 の 3つのトピック分野を中心に組まれており、300以上のセッション（講演）とデモが提供されました。 セッションはいくつかの種類に分かれており、大部屋で開催される General Session、Spotlight Session では、各分野のリーダーによるトレンド、パートナーシップ、イノベーションについての紹介が行われます。 一方、比較的小さい部屋で開催される Breakout Session では、個別的な製品紹介、事例紹介、ベストプラクティスの共有などが行われます。 Keynote: Intelligence has no limits HPE CEO の Antonio Neri による keynote の内容は、驚くほど AI に関連することが数多く取り上げられていました。 講演では HPE 社製の GPU サーバーを使用したさまざまな産業界の事例紹介をはじめとして、AI によって企業の生産性を向上させ、イノベーションを加速することの重要性が語られました。 講演の後半には NVIDIA CEO の Jensen Huang が登場して、HPE と NVIDIA とのパートナーシップを強化していく旨が述べられ、HPE Private Cloud AI という新しいソリューションの発表がありました。 なお、今年の keynote は昨年にオープンしたばかりの巨大映像施設 Sphere で開催されたのですが、映像のあまりの解像度の高さと迫力に圧倒されっぱなしでした。 Keynote の内容は YouTube に公開されているので、興味ある方はご覧ください。 新サーバーの発表 期間中には新しい HPE ProLiant シリーズのサーバーが4種類発表されました。 そのうち 2種類が AI 向け、残りの2種類がサービスプロバイダー向けです。 AI 向けサーバー HPE ProLiant Compute DL380a Gen12 は、最新の GPU NVIDIA H200 を搭載した初のサーバーです。 NVIDIA H200 は前のモデルの NVIDIA H100 と比較して、メモリサイズが2倍、バンド幅が 1.4 倍と性能が向上したモデルです。 このサーバは 4U の筐体に最大で 8個の NVIDIA H200 GPU を搭載可能であり、GPU 同士は 2-way または 4-way の高速インターコネクト NVLink による接続が可能となっています。 HPE ProLiant Compute DL384 Gen12 は、 Grace Hopper として知られる NVIDIA GH200 チップを搭載した初のサーバーとなります。 NVIDIA GH200 は Arm アーキテクチャの NVIDIA Grace CPU と NVIDIA Hopper アーキテクチャの GPU が密結合している画期的なモデルであり、CPU と GPU 間で共有された大規模なメモリ空間を提供します。 サービスプロバイダー向けのサーバー Accelerate your AI journey with HPE Compute より HPE ProLiant DL320 Gen12 SP と HPE ProLiant DL340 Gen12 SP は、電力あたりのパフォーマンス効率の高さが特徴としていて、 Sierra Forest と呼ばれる最新のサーバー/データセンター向けの CPU、Xeon 6 プロセッサを搭載した初のサーバーです。 Sierra Forest は Xeon 6 プロセッサーのうち、電力効率の高い Eコア (Efficient Core) を採用したモデルであり、1つのダイあたり最大 144個もの CPU コアを搭載しながら、既存のチップと比較して同程度の消費電力を実現すると期待されています。 DL320 と DL340 の違いは筐体のサイズであり、前者は 1U サーバー、後者は 2U サーバーとして提供されます。 興味深かったセッション 個人的に興味深かったセッションの内容を紹介します。 The future of liquid cooling for data centers (Speaker: Jason Zeiler) 1つめは冷却技術に関するセッションです (動画は こちら ) 。 昨今の CPU、GPU は高性能化に伴い発熱量が増加しているため、効率的に冷却することが求められています。 これまでの冷却方式は、ファンを使った空冷方式が主流でしたが、最近では空気よりも熱伝導率の高い液体を用いて熱を取り除く 液冷方式 が注目を集めています。 液冷方式は、空冷方式と比較して冷却能力が高く、ムラのない速やかな冷却を実現するため、高い密度でサーバーを配置したサーバーラックの冷却にも対応できるようになります。 また、電力効率が高く少ない電力で冷却が可能であるため、二酸化炭素の排出量の削減に貢献します。 さらに、冷却ファンの使用を最小限に抑えられるため、静音性が高いこともメリットです。 この講演では、液冷方式の例がいくつか紹介されました。 HPE RDHX , HPE ARCS は従来の冷却方式であり、巡回する冷却水がラック内の空気を冷却し、その冷却された空気がパーツを冷却する方式です。 一方、最新の方式の Direct liquid cooling (DLC) は、冷却プレートを使用して直接パーツを冷却する方式であり、冷却能力、効率ともに従来の方式を上回ります。 DLC は従来の方式と組み合わせて使用することもできますが、特に 100% の冷却を DLC のみで行なっている HPE Cray EX2500/EX4000 シリーズは HPE Discover 2024 の目玉であり、展示会場にも目立って展示されていました。 Showcase にて展示されていた HPE Cray EX4000 Transforming management with Open Source Firmware for SPs (Speaker: Damien Lagneux, Richard McQuaide, and Jean-Marie Verdun) 2つめは BMC (Baseboard Management Controller) に関する発展的な内容のセッションです。 馴染みのない方も多いかもしれませんが、BMC は遠隔で筐体の電源操作やハードウェアの状態を監視するための規格であり 、我々の開発しているベアメタルサービスの中核を担う技術です。 BMC は各ベンダーによって乱立しており、有名どころでいうと HPE 社製の iLO、Dell 社製の iDRAC、Fujitsu 社製の iRMC などがあります。それぞれが独自の機能とインターフェースを持ち、ベンダー間で必ずしも互換性が担保されているとは限りません。また、中身がブラックボックスでデバッグが難しく、古い筐体でベンダーがサポートを終了するとセキュリティ的に脆弱になるという課題もあります。 これらの課題を解決するため、最近 OpenBMC という Linux ベースのオープンソースの BMC 実装が提唱されています。 OpenBMC は標準化されたインターフェースを提供しており、オープンソースであることからベンダーに依存することなく、容易にカスタマイズやデバッグ、およびセキュリティ更新を実施できます。 ただし、現状 OpenBMC は初期状態の筐体にはインストールされていないため、後から OpenBMC をインストールしてパッケージを最新にアップデートする作業が必要になります 1 。 この講演では、このような筐体が数多く存在する環境でも、即座に最新の OpenBMC を使用できるように、OpenBMC を iSCSI デバイスからネットワークベースで立ち上げる方法が紹介されました。 後日発表者の Jean-Marie Verdun 氏とお話しする機会がありましたが、「OpenBMC は尖った技術だから好き嫌い分かれるだろうけど、とにかく試してみてほしい」と言われたのを覚えています。 興味を持たれた方は、関連動画 remote booting BMC: an OpenBMC / iSCSI example を参照してみてください。 Showcase HPE Discover 2024のショーケースの充実ぶりは凄まじく、数万平方メートルの展示空間に多くの企業が製品の実機展示やデモを行っていました。 製品やサービスに関する専門家からインタラクティブに説明を受けられるのが個人的に楽しかったので、セッションの合間を見繕って度々足を運びました。 軽食やドリンクコーナーも至るところにあり、非常に快適な空間でした。 Showcaseでは ガイドツアー も充実しており、英語だけでなく日本語、スペイン語、ポルトガル語など、複数の言語で一日に複数回開催されていました。 ガイドツアーの内容はほとんどがAIに関するもので、自動車の生産工場のオペレーションをAIで効率化する動画を見たり、LLMのトレーニングに必要な高速大容量ストレージについての話を聞いたり、keynoteで発表のあったHPE Private Cloud AIのデモを見ることができました。 特に興味深かったのは、HPE Aruba Networkingのデモで、AIによってネットワークの異常な振る舞いを検知したり、環境に応じたコンフィグを自動生成する様子を実際に見ることができたことでした。 左図は新発表の HPE ProLiant DL384Gen12 (HPE と NVIDIA の CEO のサイン入り)、右図は Direct liquid cooling (DLC) を導入した HPE Cray EX2500 Showcase には、開発中の製品、サービス、ソリューションを独占的に覗き見できる CDA Zone という区域もありました。 この区域はカーテンで覆われており、入り口で具体的な内容を外部に漏らさない旨の誓約書にサインすることで初めて立ち入ることができます。 普段は見ることができないサーバーの深い部分を知ることができ、とても興奮しました。 区域自体は小さく、見逃しやすいため、次回以降に参加される方は注意して立ち寄られることを是非おすすめします。 交流イベント HPE Discoverでは、 Peer-to-Peer Program というプログラムが提供されており、参加者同士で交流する機会があります。 このプログラムは、 1対1形式 と ラウンドテーブル形式 の 2種類がありました。 前者の1対1形式の交流では、同じようなサービスを提供している事業者の方とじっくりと対話して情報交換ができました。 自社と同じ課題を抱えていることや、課題に対する異なるアプローチについて知ることができ、非常に貴重な機会でした。 また、ラウンドテーブル形式の交流では、HPE 社 のシニアリーダーを含む白熱した議論を目にし、HPE 社のビジョンを体感して大きな刺激を受けました。 これらとは別に、HPE 社のエクスパートと個別のトピックについて議論する機会も何回か設けていただき、直近のサーバーのトレンドについて詳細な情報を得ることができました。 ラウンドテーブルの会場の様子 エンタメ寄りのコンテンツも充実しており、夕食の時間帯の Reception や Celebration では、バンド演奏やアルコールが提供される中で、さまざまなバックグラウンドの方と交流を深めることができました。 特に18日の HPE Discover Celebration では、貸切りの Sphere にて、アメリカの超人気ロックバンド Dead & Company の生演奏を堪能できたのは、忘れられない思い出になりました。 Reception / Celebration での交流の様子 海外カンファレンスへの参加は旅費もかかり、時差を乗り切るのも大変ですが、現地にわざわざ赴くことの価値は交流イベントにあることを強く実感しました。 Japan Session 最終日には Japan Session と称するイベントがあり、2時間に渡って日本からの参加者向けに4日間の内容のサマリーが紹介されました。 HPE Discover にはあまりにも多くのコンテンツがあり、とても4日間で全てを吸収するのは難しいと思っていたので、Japan Session はありがたいイベントでした。 交流イベントや他の予定と被っていて聞けなかったセッションの内容や、理解が追いつかず消化不良となっていた部分のフォローアップができて助かりました。 おわりに 目先の業務から離れてひたすらインプットできて、視野を広げることができる良い機会でした。 朝から晩まで予定で埋まっている日々で、非日常で濃密な時間を過ごすことができました。 また、HPE 社員の方々のお力添えもあり、多種多様な交流イベントに参加できたのはとても幸運でした。この場を借りてお礼申し上げます。 HPE Discover 2024 のセッションの一部の動画は YouTube の HPE 公式チャンネル に上がっていますので、この記事を見て興味を持たれた方は是非動画などをチェックしてみてください！ 会場の Venetian ホテルの中を流れる運河前で撮影。一見屋外のように見えるが実は屋内である。 HPE ProLiant Gen11 の一部の筐体には、初期状態では iLO6 が入っていますが、後から OpenBMC を上書きインストールしたり、逆に iLO6 を再インストールできます。 ↩

時系列データ分析ツール「Node-AI」を開発するスクラムチームは、LeSS（Large-Scale Scrum）を参考にした開発プロセスを採用しました。 本記事では、その背景や数か月試した結果について紹介します！ 目次 目次 はじめに Node-AIについて フロントエンドのリプレイスを終えて チーム分割に対する勘所 コンポーネントチームとフィーチャーチーム 実際の運用 チームへの愛着 2チーム体制を続けてきて おわりに 追記 (2025/01/20) はじめに はじめまして、イノベーションセンター Node-AIチームの中野、半澤です。 （中野）Node-AIチームでは2024年4月からスクラムマスターとして活動しております。 過去には研究者やデータサイエンティスト、ソフトウェアエンジニアなど幅広くジョブチェンジして今に至ります。 中野 将尚 | LinkedIn （半澤）Node-AIチームでは開発者としてインフラからフロントまで幅広く関わっております。 また、チームビルディングの話題も興味があるので、そういった話にちょいちょい首を突っ込んでいます。 我々は 「フロントエンドを Vue.js から React にリプレイスしたお話 (前編)」 で紹介した開発体制から次のステップに進んで、 LeSSを参考にした開発プロセスを採用し、運用してきました。 結果としてリリース頻度を約2倍にできましたが、そこに至るまでの裏話や新たに出てきた課題などについてシェアしたいと思います。 Node-AIについて 話の本題へ入る前に、Node-AIについて簡単に紹介します。 Node-AI はノーコードで時系列データのAIモデルを作成できるWEBアプリケーションです。 詳しい説明は 以前の記事 でも説明しているのでそちらをご参照ください。 現在（2024年6月時点）はβ版として公開しており、無料で利用可能です！（一部機能は有料） フロントエンドのリプレイスを終えて Node-AIの開発チームは「フロントエンドのリプレイス」という大規模なプロジェクトを完遂するため、 約10名のソフトウェアエンジニアを以下2チームに分割しておよそ1年半進めてきました。 プロダクト全体を改善するチーム リプレイスに集中して取り組むチーム そして、2023年12月の年末リリースというトラブル発生フラグが立ちまくりのリプレイス作業は何事もなかったようにシームレスに完了し、 これまでの技術では実現できなかった洗練されたUXを提供できたことでお客さまからも喜びの声を多数いただきました。 Node-AIチームは一新されたフロントエンドを武器に、さらにプロダクトを成長させていくため、 新年一発目のお題として、今後のチーム体制について話し合うことになりました。 チーム分割に対する勘所 Node-AIのスクラムチームは基本的に1チーム体制を採用してきましたが、いくつかの場面で一時的にチームを分割した体制を取っていました。 フロントエンドのリプレイスプロジェクトがその一例ですが、他には「SRE的に動くチームとNode-AIの機能開発チーム」で分割したこともあります。 その経験の中で、開発者からは1チーム体制へのネガティブな感情と複数チーム体制に対するポジティブな感情が、振り返りでよく出ていました。 1チーム体制だと人数が多いため、認知負荷やコミュニケーションコストが高く調整ごとやファシリテーションにストレスを感じたり、 スプリントプランニングで分割された各タスクの負荷分散がうまくいかず、動きが遅くなるといったことです。 一方、複数チーム体制においては認知負荷やコミュニケーションコストが下がるためタスクに集中できたり、 より自分事として捉えられチャレンジもしやすくなることで創造的な取り組みも増えたということが、 Fun Done Learn等の振り返りでも可視化されチームの共通認識となっていました。 この話は以下のように スクラムガイド にも記載されていることですし、 他社さんの事例もたくさんあるので目新しい発見ではありません。 スクラムガイド（2020） スクラムチームは、敏捷性を維持するための⼗分な⼩ささと、スプリント内で重要な作業を完了するための⼗分な⼤きさがあり、 通常は 10 ⼈以下である。⼀般的に⼩さなチームのほうがコミュニケーションがうまく、⽣産性が⾼いことがわかっている ただ、実際に1チーム体制とチーム分割の体制を両方とも長期間実践することで、 1チーム体制の課題（認知負荷・コミュニケーションコスト・タスクの負荷分散等）をチームが深く認識できていました。 そこで、それら課題の解消を狙いとしてチーム分割を前提に大規模スクラムの各種フレームワーク（LeSS、 Scrum@Scale 、 Nexus 等）の理解と議論を進めました。 コンポーネントチームとフィーチャーチーム Node-AIは多数の技術で構成されており、開発者内でも技術ごとに得手不得手や知識差はあります。 以下に主要な技術要素を挙げます。 これに加えて複雑なシステムの品質を担保するためのテスト技術群などQA的なスキルや、 時にはカスタマーサクセスチームを支援するコンサルタント的な素養も求められます。 時系列データの機械学習 フロントエンド（React） バックエンド（Python/C#） インフラ（パブリッククラウド、Kubernetes） 機械学習については教科書的なことだけでなく、研究開発チームの 成果・ノウハウ も取り込みます。 そのため研究レベルの技術を解釈して実装に落とし込むことも必要になります。 エンジニア約10人を複数のフィーチャーチームに分割した場合、それらのスキルが各チーム内で横断的にカバーできるか、という問いがチームでありました。 結論としてはLeSSの考え方を参考にチームを2つのフィーチャーチームに分割しましたが、 公平に分割すると開発速度に大きく影響しそうなものについて、片方のチームに得意なメンバーを固める体制としました。（一部コンポーネントチーム化） ※ LeSSやフィーチャーチーム・コンポーネントチームについて基本的なことは解説しませんので、 Introduction to LeSS - Large Scale Scrum (LeSS) などをご参照ください。 具体的には、新フロントエンド導入で手薄になっていたE2E試験とフロントエンドの結合試験はある程度形になるまで専門性を持ったメンバーを1チームに寄せました。 まずは1チーム内でスプリントを進めながらノウハウを共有し、その後もう一方のチームに展開する作戦です。 その他の技術も偏りはありますが、チーム内で完結できる能力をもったメンバー構成となっています。 ただ大きめな新機能の設計レベルになると特定の開発者に依存する場合はあるため、完全に分離できているわけではありませんし、 お互いのチームメンバー間で密に連携せざるを得ないことはよくあります。 今のところチーム間で積極的に連携することが何か課題になっている感覚はあまりなく、 むしろコミュニケーションが活性化し、心理的安全性につながっている気がします。 実際の運用 2チーム体制はLeSSを参考に構成することとしましたが、LeSSの形式やプラクティスを積極的に採用するのではなく必要な部分を少しずつ取り入れる形としました。 理由として、1チーム体制時にも継続的に改善に取り組んできた良い面は残したいですし、 各種プラクティスを強制しなければならないほどの課題感はなかったためです。 以下はLeSSを参考にした部分です。 プロダクトバックログは1つ スプリントプランニングは第一部を全体で行い、第二部をチームごとに行う 一方、以下の部分は独自に決めたプロセスです。 デイリースクラムは第一部を全体で行い、第二部をチームごとに行う 振り返り（レトロスペクティブ）は全体で行うことを基本とし、チーム単位で行うかどうかは内容によって決める LeSSではチームごとのデイリースクラムのみが基本ですが、 Node-AIでは全体のデイリースクラム（内部ではOverall朝会と呼んでいる）を開催することにしました。 LeSSといっても2チームで約10人という世の中の大規模スクラムと比較すればまだ少人数です。 全体で予定を合わせることはそこまで大変なことではありません。 Overall朝会では以下のことを実施しています。 今日のイベント、不在者の確認 全体向けに話したいことがあれば共有 両チームは開発問わずさまざまな場面で連携するため、だいたい1日に1議題くらいは話し合っています。 事務処理や全体イベント（リファインメント等）の調整ごと、他チームにも共有したいトピックや相談頭出し等さまざまです。 このOverall朝会は15分をタイムボックスとしていますが1分で終わることもあり、たいていは5分以内で終わります。 レトロスペクティブについては全体で話すだけでも十分に効果的な内容もあるため、 チーム単位でのレトロスペクティブは任意としました。 ただ実際は2回に1回程度の割合でチームごとのレトロスペクティブを実施しています。 スプリントレビューについては臨機応変に調整しています。 多くの場合2名以上のステークホルダーにきていただくため、以下の流れになることが多いです。 最初に参加者全員に対してプロダクトオーナー（PO）からプロダクトゴールに向けた状況やレビューの全体像を説明 招待したステークホルダーの数だけ場所を分かれてレビューを実施 各ステークホルダー向けにインクリメントのレビューを実施（ファシリテーションは開発者） POや開発者はそれぞれのレビュー場所に自由にばらけて議論に参加 最後に全体に対してPOから今後のロードマップ等を共有 ※ スプリントレビュー含めて全てのイベントは基本的にリモートで開催しており、NTT Comのコミュニケーションツール NeWork を使用しています。 NeWorkでは複数の場所に分かれてコミュニケーションしつつ、他の会話にも気軽に参加できるようになっています。 レビュー対象のインクリメントは各チームで内容が異なることもありますが、 1つのスプリントゴールに向けたプロダクトバックログアイテム（PBI）を分担していることもあります。 いずれにせよ、事前にレビューのシナリオを2チームで話し合って準備しています。 また、チームごとに分かれてスプリントレビューを実施するということは基本的にありません。 他チームのインクリメントに関連する次のPBIは次スプリント以降に自分のチームで対応する可能性があり、 そのためにステークホルダーのフィードバックを直接聞く機会は貴重なためです。 また、他の場所で行われたレビューの状況やフィードバックのメモはスプリントレビュー後に全員で眺めながら議論したり、 PBIの種となるペインを抽出する作業も共同で実施しています。 そのようにすることで他チームの開発内容を深く理解することにつながり、 「どちらかのチームしか対応できないPBI」が発生しないようにする効果があると考えています。 チームへの愛着 このようにNode-AIの開発は2チーム体制で進めていくことを合意して運用してきました。 そこで「せっかくチームを分けたのだからチーム名くらい付けよう」という話があがりました。 実は今まで2チーム体制に分けたときは特にこだわったチーム名を付けておらず、 フロントエンドのリプレイス時には「本流チーム」と「リビルドチーム」という何とも味気ない呼び方でした。 新しいチーム名は何か共通の概念で統一したほうがよいとの声が多数だったため、 まずはアイデア出しから始め、「お酒の名前」「何らかの記号」などが挙げられ、多数決で「花の名前」で名づけることになりました。 「花言葉」を使って何らかの意味をチーム名に持たせられるということで各チームが議論し、 結果として「アザレア」「モモ」という花が選ばれました。 アザレアの花（２） | フリー写真素材 Photo-pot モモ（桃）の花 無料フリー写真素材 (freephoto.sakura.ne.jp) ちなみにアザレアの花言葉は「節制」「禁酒」「恋の喜び」、モモの花言葉は「私はあなたのとりこ」「天下無敵」「気立ての良さ」「長命」などのようです。 最初は小恥ずかしさもあった名前ですが、今ではお互いのチームを自然に「アザレア」「モモ」と呼ぶようになり、 事情を知らない人の前でも普通に言ってしまい微妙な空気になることもあります。 またそれぞれaz（azalea）、mm（momo）という略語も浸透したことでSlack等のチャットコミュニケーションで いちいち「リビルドチームは～」とか書かず「mmは～」と書けるためタイピング時間の節約にも役立っています。 またざっくりアザレアは紫色、モモはピンク色だと思うことにして、 タスク管理ツールでもPBI等に色付けをすることで、どちらのチームのタスクなのかが一目でわかるようにもなりました。 チーム名というのはチームへの愛着のわずかな要素ではありますが、最初にやってよかったことの1つだと感じています。 2チーム体制を続けてきて さて、上記の通り2024年1月から2チーム体制を続けてきました。 ここで現状を振り返ると、以下のことがわかりました。 各チームで独立してほとんどのPBIを実施できている 技術的な偏りについてはチーム内/チーム間で少しずつスキトラ（スキルトランスファー）が進んでいるが、まだまだ完全ではない チームを分割したことによる認知負荷やコミュニケーションコストは軽減されているとともに、チーム間連携に大きな問題は発生していない 1.と2.について、現状でも「この人じゃないと難しい」という技術領域はどうしても存在するため、一部のPBIがチームに依存した形となることはあります。 しかし、ほとんどのPBIはどちらのチームでもこなせる状態になっています。 そのためスプリントプランニング時に、どちらのチームでPBIをとるか？でお見合い状態になることもしばしばあります（笑）。 たいていそういった場合はチームメンバーのWillでPBIの担当チームが決まります。 また、チームによって扱う技術領域に偏りが出ないように、前スプリントで扱ったPBIと似たPBIが次のスプリントにある場合は、もう一方のチームが担当するといった工夫もしています。 その場合は必要に応じて他チームの有識者に教えてもらいながらPBIを進めていくこともあります。 （状況によってはもちろん短期的な効率を重視して似たPBIを同じチームで担当することもあります。） 一方で上記に記載している、「この人じゃないと難しい」という技術領域はハイレベルなものや込み入ったものであり、スキトラはなかなか進んでいない状況です。 一朝一夕でスキトラできるものではありませんし、各チームメンバーの興味関心のある技術の違い、キャリアプランも影響してくるため難しい問題です。 3.については本記事を執筆している我々も感じていることですし、レトロスペクティブでもチームメンバーの多くから同様の声が挙がりました。 チームを分割した狙いの1つである「認知負荷/コミュニケーションコストについての負担の軽減」については効果を得ることができたと感じています。 また、レトロスペクティブにて出た内容を一部紹介します。 このレトロスペクティブは2チーム体制になってから3カ月過ぎた4月頭に実施したものです。 ◆良かった点（Keep） リリース頻度が上がった ◆気になる点（Problem） 細かい挙動を把握していない機能が増えた 良かった点として「リリース頻度が上がった」ということが挙がりました。 以前は1スプリント（1週間）で原則1回でしたが、最近では1スプリントで2回、3回と複数リリースできることが増えてきました。 これはより素早い価値検証を可能にするものとなるため、チーム分割により非常に良い効果が出ていると考えています。 具体的に何が理由で「リリース頻度が上がった」のか、大きく2つあると考えています。 1つめはチーム体制以外の効果によるもので、「リプレイスによってコードを修正しやすくなった」からです。 リプレイスによって技術負債が解消して機能追加が容易になり、結果としてリリース頻度の向上に寄与したということになります。 2つめはチームが小さくなったことによる「認知負荷/コミュニケーションコストについての負担の軽減」になります。 認知負荷やコミュニケーションコストが軽減することで、実装に集中できる時間が増えたということになります。 実際に開発者からのコメントでも「タスクを取る迷いは減った（誰かが取るかも…？という迷いが減った）」という意見が出ています。 それに付随して、ある程度チームごとの判断でリリースができるため、各チームが1～2回リリースできている状態です。 一方、気になる点として「細かい挙動を把握していない機能が増えた」が挙がりました。 具体的には、スプリントレビュー時に初めて他チームのインクリメントを見ることが多く、 内容を知らないままスプリントレビューに出てしまうといった問題が出てきました。 これだと他チームのインクリメントに対するフィードバックへの理解が深まらず、関連するPBIが生まれても同じチームが担当する、 といったようにタスクがチームに固定された状態が深刻化すると予想されます。 この改善策として、スプリントレビュー前日にお互いのチームでインクリメントのデモをする取り組みを考えました。 これにより少なくとも他チームのインクリメントがどういったものか理解して翌日のレビューに臨むことができるようになりました。 まだ取り組みを始めたばかりですが、この取り組みによってよりよいレビューを実施できていると感じています。 以下はレトロスペクティブ時の議論の一部のキャプチャになります。 おわりに LeSSを参考に2チーム体制として良い点・悪い点が見えてきました。 しかし、チーム分割の狙いの1つであった「認知負荷/コミュニケーションコストの軽減」には効果があり、 チームメンバーからも好意的に取られていることを考えると、チーム体制変更は正解だったと感じています。 上記で紹介した内容以外にもスクラムを回していく中で問題は現在進行形で出ていますが、 改善を続けていくことでより良いものにしていきたいと考えています。 またNode-AIをユーザにより利用してもらうために、開発者がアプリ開発以外の活動に取り組むことが増えています（以下例）。 カスタマーサクセスチームと連携してユーザの伴走支援をする Node-AIを利用した 学習コンテンツ を作成する これは開発者がユーザの解像度を上げるという点においては良い効果がある一方で、 チーム外とのコミュニケーションコストが増え、開発時間が減る問題も出てきています。 今後はこのあたりの改善も考えていくつもりです。 最後になりますが、この記事を書くにあたって協力いただいた皆さま、Node-AIの開発チームメンバー、 そしてこの取り組みの立ち上げた前スクラムマスターのへ感謝の意を表してこの記事を締めたいと思います。 本当にありがとうございました！ 追記 (2025/01/20) この記事から半年を経て、1チームでのスクラム体制で再出発することになりました。詳しいことはこちらの記事をご覧ください。 engineers.ntt.com

はじめに こんにちは、イノベーションセンターの梶江、原田、佐瀬、江崎、山田です。 NTTコミュニケーションズ株式会社 (以下、NTT Com) は、日本最大級のネットワーク展示会である 「Interop Tokyo 2024（会場：幕張メッセ、会期：2024年6月12日〜14日）」 において構築されるShowNet 1 に対し、昨年に引き続き 2 コントリビューターとしてローカル5G（以下、L5G）システムを提供し、実験試験局の運用に成功しました。 今年はトランスポートNWにNTT研究所のFDN (Function Dedicated Network :機能別専用NW)を使用。オープン光伝送NWを用いた柔軟性のある確定通信を実現。UPFについても、NTT研究所がDPU(Data Processing Unit)を用いて内製開発したdUPF (distributed UPF) 3 を使用しました。 これら新技術と、AWS上にデプロイされたドコモの5Gコア(5GC)をQmonus SDK 4 からあわせてコンロールすることで、より高度なネットワークスライシング制御にチャレンジ。L5Gの特徴である高速大容量・超低遅延・多数同時接続を活かした高精細な音声・映像伝送をShowNetテクニカルツアーという実例で実現しました。本記事ではその構成やスライシング制御手法、技術的なチャレンジ、無線性能測定結果について解説します。 マルチベンダーにおける伝送連携制御 私たちは、高度な情報処理・高機能通信を場所・利用形態を問わず提供可能とする基盤を構築し、端末/デバイス・NW・アプリケーションをエンドツーエンドかつシームレスに連携させることを目標としています。それを達成するには、高機能で多様なネットワークスライシングの要件に対応する5GCと、伝送区間で確定性通信を実現させる仕組み、それらを制御する技術が必要になります。 ネットワークスライシングの説明は 過去の記事 が参考になるため、詳細記載を省略します。今回はAirspan社製の基地局を用いたローカル5G環境を構築。ローカル5Gで使用される周波数帯はライセンスバンドであるため、法令に則って実験試験局免許を取得し運用しました。そのNWで、NTT内製のdUPF、FDN、Qmonus SDKを組み合わせ光伝送レイヤも含めたエンドツーエンドのスライス制御にチャレンジしました。下図が構成となります。順番に解説していきます。 NVIDIA DPUを用いたNTT内製UPF 本構成のUPFでは、NTT ネットワークサービスシステム研究所が内製開発したdUPFを使用しました。NVIDIA社DPUにUPF処理を完全オフロードすることで、5GCと連携する、小型軽量・高性能・高信頼・低消費電力なUPFを実現しました。 また、UPFとしての転送処理だけでなく、NAT・FW・VPN・DPIなど、キャリアネットワークならではの付加価値機能を含め、オープン化が進むDPUハードウェア上で実装・展開することで、ユーザ端末環境やサービスの要件・状態に合わせ、必要となる最適なNW機能・リソースを柔軟に構成可能です。 FDNによる確定通信の実現 基地局〜UPF、UPF〜DN間のトランスポートNWは、NTT ネットワークサービスシステム研究所が開発したFDNによって生成された光伝送路を含む通信路を使用しています。FDNでは、APN 5 上に様々なサービスを収容する専用NWをサービス毎に構築し提供します。APNでの動的な波長制御による伝送パスの割り当てを活用し、FDNに収容するデジタル信号や利用するアプリの特性に応じた最適な専用NWを構築。さらには、無線基盤・コンピューティング基盤との連携制御も目指しています。 今回は、FDNを構築する際に必要となるロスレス・ジッターレスといった確定通信をエンドツーエンドで実現するためにFDN Bridge（WhiteboxTransponder＋WhiteboxSwitch）とそれを制御するためのFDNコントローラを用いました。 FDNコントローラはオーケストレータやアプリからのパスリクエストを受けWhiteboxTransponder及びWhiteboxSwitchを制御することで、200G/400Gといった広帯域の波長パスに対して要求された通信帯域分だけの通信リソースを割り当てることを可能としています。また、APNだけではPoint-to-Pointの通信となってしまいますが、FDN Bridgeで利用する波長パスを選択・振り分けることでより柔軟なネットワーキングを可能としています。NTT ドコモのコントリビューション部分については、  NTTドコモ の ENGINEERING BLOG記事 をご覧ください。 dUPFの性能測定についてはこちらで言及されています。 Qmonus SDKを用いたオンデマンドなスライス払い出し ユーザのリクエストに応じてネットワークスライスを払い出すには、5GC、トランスポートNW、UPFといった異なるドメインの装置それぞれに設定を適用する必要があります。 各装置に対して設定するオーケストレータはQmonus SDK(NTT Com内製のマイクロサービス開発フレームワーク)を採用しました。Qmonus SDKは異なるマイクロサービス間の横断したトランザクション管理を特徴としています。5Gシステムでのスライス操作では、1つの装置に対して複数の設定を直列に投入したり、装置間を跨って設定を投入しなくてはなりません。Qmonus SDKにより5GC、dUPF、FDNそれぞれの装置が持つAPIインタフェースに対して順次設定を投入し、装置間をまたいだトランザクションを保証します。 実験試験局の運用 昨年に引き続き実験試験局免許申請を行い、電波を発波する実験試験局を運用しました。チームメンバーの80%以上が無線従事者免許を保有しており、電波法を尊法し、輪番を組んで運用を行いました。 5G基地局となるgNB装置は廉価且つ簡易な構築・導入が可能な「RU/CU/DU一体型」を特徴とするものを採用。Airspan社の屋内型一体型gNBであるAirVelocity 1901をInterop Tokyo 2024 の会場（幕張メッセの展示ホール4）に設置しました。今回は5Gにおける時刻同期方式にPTP(Precision Time Protocol)を用いました。 PTPは専用の時刻同期用パケットにタイムスタンプを埋め込み、システム間で交換することで双方の時刻を同期する方式です。 これにより1台のPTPタイムサーバーから光ファイバケーブル経由で、高精度な時刻同期を実現できました。 無線性能測定 AirVelocity1901のダウンリンク(以下DL)とアップリンク(UL)の無線性能であるRSRP vs スループットを測定しました。DLのmaxスループットは約650Mbps、ULは約65Mbpsという結果となり、両者ともに高い速度性能が発揮できていることがわかりました。また、DL・UL共に受信電力であるRSRP値が約-100dBmまでmaxスループット値が維持でき、ある程度基地局から離れても最大速度で端末を使用できることが分かりました。 幕張メッセの展示ホール4のShowNetツアーブース周辺での受信電力RSRP値の測定も行いました。ツアーブース内と周辺でRSRPが約ー100dBm(前述のmaxスループットを維持できるRSRP値)を維持しており、ShowNetツアーで音声・映像配信を行うのに問題無いローカル5Gカバーエリアとなりました。 おわりに この記事では、Interop Tokyo 2024（会場：幕張メッセ、会期：2024年6月12日〜14日）において構築されたShowNetにおける、光伝送レイヤも含めたエンドツーエンドのスライス制御の取り組みを紹介しました。今後は、今回の各種性能測定の成果を踏まえ、より多種多様なユースケースに対応できるネットワークスライシングの方式や、NTT Comのネットワークサービスへの応用について検討していきます。この記事に登場したローカル5G基地局はShowNetブースNOCラックの側にある背の高いトラスの先端に設置されています。 是非会場に足を運びご覧になってください。 Interop Tokyo への出展社がインターネットへの接続性を利用して製品の動態展示のほか、来場者のインターネットへのアクセスとしても利用されるネットワーク。また、さまざまな機器・サービスの相互接続性検証を実施するとともに、近未来のサービスアーキテクチャを実際に動かしている形で見ることができる日本最大規模のライブネットワークデモンストレーションでもあります。 https://www.interop.jp/2024/shownet/ ↩ 昨年ShowNet2023でも我々はネットワークスライシングの取り組みを実施しました。 https://engineers.ntt.com/entry/2023/06/14/084318 ↩ 6G Computing Architecture: Distributed, Software Defined Accelerated and AI-enabled( https://www.nvidia.com/en-us/on-demand/session/gtc24-s61898/ ) ↩ Qmonus SDK： NTT Com内製のマイクロサービス開発フレームワーク ↩ APN ：端末からネットワークまで、すべてにフォトニクス（光）ベースの技術を導入し、エンドツーエンドでの光波長パスを提供する波長ネットワーク ↩

はじめに こんにちは、イノベーションセンターの福永です。 NTTコミュニケーションズ株式会社は、日本最大級のネットワーク展示会である「Interop Tokyo 2024（会場：幕張メッセ、会期：2024年6月12日〜14日）」において構築されるShowNet に対して、Celona製品を用いてローカル5G環境を構築しました。 また、ShowNetウォーキングツアー用にローカル5G端末を提供しました。 ローカル5Gの構成について ローカル5Gとは、自治体や企業など通信事業者ではない組織が、自らの建物内・敷地内でユースケースに応じて個別に構築する専用の5Gネットワークをいいます。 5Gには、4Gのインフラを基盤として動作するタイプ (NSA: Non Stand Alone) と5Gのインフラのみで動作するタイプ (SA: Stand Alone) に分けられますが、今回はSA構成で構築しています。 Celonaとは Celonaとは2019年4月設立、カリフォルニア州キャンベルに拠点を置く企業向けプライベート5Gネットワークの新興ベンダーです。 Celonaプライベート5G LANは、組織に容易に導入できるよう設計されています。 設定はすべてCelona Orchestrator上で一元管理されており、ローカル5Gに接続されている各種端末情報を確認することも可能です。 今回の取り組みではCelona製品を利用し、ローカル5Gの環境を構築しました。 事前準備・事前検証 ShowNetに機器を持ち込む前に事前準備や事前検証を行っています。 ローカル5Gの利用にあたり無線局の免許(電波法第四条)の申請が必要であり、Interop Tokyo 2024に向けて屋内でのみ設置可能な周波数帯である4.6GHzの電波の免許を取得しています。 また、スペクトルアナライザで4.6GHzから4.7GHz以内に電波が収まっていることを確認しています。 提供端末について ShowNetウォーキングツアー用に今回私達はローカル5G端末としてiPadを提供しています。 iPadをローカル5Gで利用するためにはいくつか条件があり、その1つがプライバシーの秘匿要件です。 これを満たすためにローカル5G製品ではSUCI(Subscription Concealed Identifier)への対応が必要です。 また、指定されたMCC(モバイル国コード）及びMNC(モバイルネットワークコード)を利用する必要があり、IMSIが999002から始まるSIMカードを利用しています。 MCCが999、MNCが002で始まるIMSIについては、総務省総合通信基盤局電波部移動通信課に対して指定申請を行う必要があり、今回のイベントに向けて申請を行っています。 今回の提供端末は、最新のM4チップのiPadを使用しました。これには物理的なSIMカードを刺すスロットがなく、eSIMのみに対応しています。 アメリカで発売されているiPhoneはすでに物理SIMスロットがなくeSIMだけで今後、日本においても同様にeSIMのみとなる可能性もあるかもしれません。 また、工場やIoTで使用される端末ではeSIMのみに対応する端末もあり、対応が必須となりますが、今回はその実用性も実証できました。 eSIMは大きく分けるとコンシューマ（スマホ向け）とM2M(IoT等の機器向け)の二種類があり、今回はコンシューマ向けのeSIMを利用しています。 その場合、QRコードを読み込んでSIM製造ベンダ側が提供しているeSIMサーバ(SM-DP+)と通信させプロファイルのダウンロードが必要となります。 現地測定について 無線品質の測定はWindows端末にネットワーク測定ツールをインストールして測定しています。 下の散布図は、現地の測定結果で縦軸がスループット(NR PDSCH Tput(Mbps))、横軸が電波強度(NR PCell SS-RSRP (dBm))で表しています。 会場内を歩き回り測定を実施したところ、電波強度が-130dBmを超えたあたりでローカル5Gとの接続が切れることがわかりました。 また、ダウンリンクが500Mbps、アップリンクが70Mbpsを超えたあたりで頭打ちとなっており、会場内での最大スループットはその値までは電波強度と比例関係にあることがみてとれますが、その値が限界となっていることが散布図の傾向から考察できます。 下のヒートマップは会場内の電波強度を色の濃淡で表しています。 展示ホールの4の2箇所から電波を発出しており、中央や奥の展示ホール6に行くにつれて電波強度が弱くなっていることが確認できました。 終わりに 本記事では、Interop会場に構築したローカル5G環境について紹介しました。 今回、屋内環境について検証ができたので、今後は屋外環境での導入検討も進めていく予定です。 今後もローカル5Gについて情報発信していくことにより、多くのお客さまに利用して頂けるよう努めていきたいと思います。 最後までお読み頂きありがとうございました。

こんにちは、クラウド & ネットワークサービス部の井口です。普段は OpenStack を利用した SDPF クラウドの仮想サーバ開発/運用をしています。 昨年 12 月に開催された学生向けの技術広報 1day イベントにて、私は当時新卒 1 年目で運営リーダーとして携わりました。 この記事では、運営リーダーを務めた経験から得た学び・知見を紹介します。 Tech Workshop とは NTT Com が主催する企画の 1 つに「Tech Workshop」 1 というものがあります。主にエンジニア志望学生向けに、現場で活躍する社員とともに手を動かしながら NTT Com の技術や業務を理解できる 1day イベントとなります。大きな特徴として、メンバーの大半が現場のエンジニア社員で構成されており、本業務の傍ら企画・運営を行ない、イベントを主催しています(以降運営チームを Tech Event チームと称します)。 Tech Event チームは技術領域ごとに分かれて活動しています。昨年 12 月及び今年 1 月、私が所属するクラウド分野では、とある OSS をモチーフにしたコーディングイベントを企画し、モブプロ形式 2 で社員/学生問わずワイワイガヤガヤとプログラミングのお題に挑戦していくようなプログラムを開催しました。Step by Step で解き進められる問題を作成していますが、なかなか一筋縄ではいかない課題設定にしているため、参加者の皆さんには良い意味で頭を悩ませていただけたかと思います。 詳しい内容については、同内容で開催した 過去のエントリ をご覧ください。本稿では、そのイベント運営の裏側をお話しします。 イベントを支える運営チーム 紹介した Tech Workshop を始めとするいくつかの技術イベント運営を行なうために、Tech Event チームが組成されています。先に述べた通り、その多くは有志の現場エンジニア社員から構成されており、いくつかの技術分野がある内でクラウドチームだけでも数十人規模となっています。 Tech Event チームの活動の中でも、Tech Workshop は学生が参加することから大きな目玉イベントとなっています。オンラインで実施するため会場設営コストこそ少ないものの、モブプロを題材としながら参加者に NTT Com の事業・取り組み・エンジニア社員への理解度を深めていただくコンテンツを作り上げるため、準備は入念に進められます。そのような背景の下、企画・運営を取り仕切るイベント運営リーダーは、準備を着実に取り仕切り、当日の司会進行含めイベントを必ず成功させなければなりません。 「私がイベント運営リーダーに？！」 〜怒涛の一ヶ月を経験して〜 さて、昨年 12 月のイベント開催から約 1 ヶ月前、Tech Event チームのキックオフミーティングが実施されました。 私は元々イベント運営に強い関心があったわけではありませんが、所属する部署のメンバーが前年度から積極的に本企画運営へ携わってきていたことや、数年前私自身が学生として参加した経験もあり、なにか協力できることがあればいいなという心持ちで参加していました。実際、数十人規模の Tech Event チームクラウドチームの中で 1 年目社員は片手に満たない数であるため、当初は簡単な運営業務に落ち着くのではないかと呑気に考えていました。 そんな気持ちで参加したキックオフにて、なんと部署の先輩から「イベントリーダーをやってみないか？」と声をかけていただきました。はじめは面食らったものの、「新卒社員がイベントリーダーをやってみた」という状況に単純にワクワクしていただけでなく、年次も高く自分より圧倒的に本業が忙しい社員が多い中で、当イベントの流れが頭に入っている自分は誰よりも適任かつチーム全体にとって最適である自負がありました。そしてなにより、まだ何も成していない新卒社員に一定の信頼を置いてお声がけいただけた感謝があったため、この折角の機会を逃すわけにはいかないと、私がリーダーとして携わることを決意しました。 運営のキックオフからイベントの開催までの 1 ヶ月間は、私にとっては新たな経験の連続でした。決意して引き受けたとはいえ、イベントリーダーは本イベントを成功させるための全ての責任を追うプロジェクトマネージャーに相当する役割です。当然、当日運営だけではなくそれまでの事前準備も担います。お題設定などのコアな部分は勿論のこと、当日に向け、関係者との調整やケータリング手配といった雑務など、そのタスクは多岐に渡りました。 私目線で苦労したポイントとしては、以下の 3 点にまとめられます。 タスクマネジメント 先述の通り、イベント開催に向けたタスクは多岐に渡ります。イベントの概要策定、タスクの洗い出し、社内外の連絡、サポートメンバーの勧誘、進行表の作成、当日の資料作成など、考えることは山のように見えました。抜けなく漏れなくタスクを捌いていかなければいけないプレッシャーの中、過去実績とにらめっこしながら、かつ自身の参加経験を思い出し、当日何が必要かといったイメージを具体的な ToDo に落とし込み続ける日々が続きました。 ステークホルダー間の調整 リーダーと共に企画準備・運営の中心となるコアメンバーとの連携は勿論、複数イベントを横断する統括リーダーへの進捗報告、広報へのイベント周知依頼、ケータリングや当日使用するツールの申請・手配など、身近なメンバーを越えたステークホルダーとの調整業務には常に追われ続けることとなりました。社会人 1 年目の私にとってはまだまだ不慣れであり、先輩方に手を差し伸べていただく機会が多い部分でした。サポートを頂きつつも、各調整業務のスケジュール/温度感は特に注視することで、少しでもミスの発生確率を下げられるよう心がけていました。 タイムマネジメント 当然ながら主業務のプロジェクトがあるだけでなく、1 年目向けの部署を越えたジョブローテ研修、技術顧問である twada さんによるソフトウェアエンジニア育成プログラム 3 が同時期に重なったため、四足のわらじでの活動となりました。さすがに入社後で一番忙しかったですね…。自身もスケジュールを強く意識していたほか、運営メンバーにタスクを振る際は事前に締め切りを明確にし、スケジュールビハインドが予想される場合にすぐ共有し次の対応を検討できるような体制作りに努めました。 以上に加え、今回定員を大きく上回る応募があったため、従来に加えて参加者の選考や連絡業務もスケジュール厳守で行なうことになりました。それらを一人でこなすことはもちろんできません。自他部署のメンバーから多大な協力をいただいたほか、先輩方も積極的にアドバイスや相談に乗っていただけたため、何とかイベントを成功させることができました 4 。 一年目の視点で見えたもの 運営者になって感じた Tech Event チームの重要性 先述の通り、私は以前 Tech Workshop に学生として参加しました。当時は NTT Com のエンジニアの方々と直接交流できる良い機会だと考えていた程度でしたが、今回運営側として多くの学生の方との対話を通じたことで、我々自身が持つ課題というのも見えるようになりました。 その代表例は、技術職周辺における企業/事業活動認知には課題が山積している現状です。例えば私が携わるクラウド事業ですが、国内有数のパブリッククラウドを一から内製で開発・運用しているのにも関わらず、NTT Com エンジニアの高い技術力・専門性はおろか、クラウド開発をしていることそれ自体が知れ渡っていない現状を実際に感じることとなりました。私自身も偶然参加した Tech Workshop が無ければ入社を検討しなかっただろうと思うだけでなく、今回のイベントで交流した学生からも、NTT Com のクラウド開発について初めて知ったという声が上がっていました。 今回の Tech Workshop はエンジニア志望の学生に NTT Com の取り組みを体験していただくことを主目的としていましたが、今後もさまざまなイベントの開催・参加を通じ、自社の取り組みを周知していく活動は必要不可欠でしょう。Tech Event チームも more ドコモ 5 に社員インタビュー(なんと 10 人分！)を掲載した他、本チームに関わらず数多くの社員が技術ブログ 6 で社内外での技術情報発信に積極的に取り組んでいます。私も引き続き、より一層 NTT Com の取り組みやその活躍を広く知ってもらえる環境が形成できるよう貢献していきたいと考えています。 リーダーとしての反省 ここは個人的なふり返りとなってしまいますが、まだ本業務でもプロジェクトマネジメントの経験が浅い私にとって、本経験で得た学びは非常に大きいものでした。 特に大きな収穫は、メンバーと協調してプロジェクトを進めるにはまず自分自身がゴールを見据えていることの重要性です。プロジェクトが何を達成しなければならないかという認識を全員で共有できれば、リーダーメンバー問わず自律的に次に成すべき行動が見えてくるものだ、という経験を得ました。 今回至らなかった部分としては、私のオリジナリティを発揮できなかったことでしょう。本イベントは過去にも開催された実績があり、準備段階での参考資料も多く存在しています。それらを元に、期間内に、確実に、チームメンバーの協力を仰ぎながらイベントを無事に終えることを最優先としていたため、自分自身のアイデアを形にできなかったことが反省点です。今回の経験を活かし、本イベント、ひいては Tech Event チーム活動全体がより良いものになるよう、次回に向けて準備しています。期待してお待ち下さい！ 一年目がイベントリーダーを務める意義とは 今回 Tech Event チームメンバーを代表して一年目の私がイベントリーダーを務めさせていただきましたが、本活動を通じて、NTT Com の風土、特に挑戦や改善の道に前向きな環境があることを改めて示せたことに大きな意義があると考えています。 先述の通り、まだまだ入社して日が浅くリーダーとしてもまだまだ微力な私ですが、周りの方々はそれを後押しするだけでなく、共にイベント成功へ向け歩むことができました。社員それぞれの自主性を重んじることに加え、新入社員でも挑戦させてくれる環境があることは、今回私がイベントリーダーを務めたことで名実ともに証明できたのではないでしょうか。また本記事を通じて、常に改善の道へと進もうとする社内風土があり、たとえ技術職であっても(元来 Tech Event チームが現場のエンジニア主体となっていることからも)そのような取り組みが是とされている環境を少しでも感じていただければ嬉しいです。 次回インターンシップのお知らせ ドコモグループでは、今年も Tech Workshop を開催します！ 私が携わるクラウド分野では、より一層クラウド開発について深く知ることができるイベントになるよう現在準備を進めています。クラウドの他にも、ネットワーク、セキュリティ分野でも 1 day イベントが開催されます。 また、サマーインターンシップ 2024 も開催されます。本技術ブログに多数体験談が掲載されている現場受け入れ型インターンシップも下記スケジュールにて開催予定です。 興味を持たれた方は是非ご応募ください。 7 エントリー期間 開催日 Tech Workshop 6/3（月） ～ 6/23（日） 7/7（日）または 7/13（土） 現場受け入れ型インターンシップ 6/3（月） ～ 6/21（金） 8/26（月） ～ 9/6（金） ※ 土日除く Tech Workshop | インターンシップ情報 | NTT ドコモ新卒採用 ↩ Mob Programming - A Whole Team Approach by Woody Zuill | Agile Alliance ↩ ソフトウェアエンジニア育成研修 - twada 塾 - Shines ｜ドコモビジネス｜ NTT コミュニケーションズ ↩ 大きなトラブルなくイベントを終えることが出来ましたが、実は当日の司会進行でガチガチに緊張していた私は、冒頭マイクミュートで話し始めるという失敗をしてしまいました(参加学生の皆さん失礼いたしました)。しかもハードウェア&ソフトウェアの二段構えでミュート芸を披露することに。トホホ…。 ↩ more ドコモ　@NTT ドコモ新卒採用チーム ↩ NTT Communications Engineers' Blog ↩ インターンシップ情報 | NTT ドコモ新卒採用 ↩