本記事では、現在進行中で取り組んでいるテーマ「生成AI×数理最適化」に関する試みとして、生成AIを活用して数理最適化技術の実務適用を支援するアプローチを紹介します。例として、スーパーマーケットにおける在庫管理の効率化を取り上げ、その具体的な応用と効果について述べます。 はじめに 背景 数理最適化モデルの定式化と実装に伴う困難 生成AIの台頭 実現アプローチの検討 生成AI活用の全体像 在庫最適化の課題設定 実現までのステップ 1. 定式化支援エージェントによる定式化支援 2. 入力データ設計支援エージェントによるデータ設計支援 3. Node-AIを活用したデータの準備 4. コード生成エージェントによる実行コード生成 5. 作成されたコードの実行と結果 まとめ おわりに はじめに こんにちは、イノベーションセンター テクノロジー部門 先端AI数理PJの伊藤です。 普段は Node-AI や AI Autopilot System などのプロダクト価値向上に加え、お客さまから寄せられる課題に対してデータ分析を通じた解決策の研究開発に取り組んでいます（例えば 学習速度と変数選択精度を極めたFastGSCADモデル (Ver. 3.22.0)｜Node-AI by NTTドコモビジネス など）。 昨年度は 機械学習×数理最適化で業務プロセス革命！ - NTT docomo Business Engineers' Blog という記事を執筆し、ありがたいことに多くの反響をいただきました。現在も、予測結果を活用した数理最適化技術の研究開発を継続しており、最近では、数理最適化による課題解決を支援する生成AIの活用の研究にも注力しています。 本記事では、スーパーマーケットにおける在庫管理を一例に、生成AIによる支援を活用した数理最適化技術による課題解決のアプローチをご紹介します。 背景 数理最適化モデルの定式化と実装に伴う困難 数理最適化では、現実に存在する課題を以下の形式に抽象化し、数学的モデルとして表現することが求められる場面は多くあります。 具体的には、 個の不等式制約と 個の等式制約を満たしながら、問題の解を決めるための変数 を調整し、目的関数 を最大化する解を求めることを指します。 例えば、 こちらの記事 で取り上げているコールセンターにおけるオペレーター最適配置の課題では、課題の整理から出発し、以下のような数理最適化モデルへと定式化を行っています（詳しくは 該当記事 をご参照ください）。 このような数式で記述された最適化問題は、プログラムとして実装し、最適解を導出することで、業務上の意思決定に応用されます。 しかし、このような定式化やプログラムの実装には、数理的な知識に加えて、プログラミングスキルといった高度な専門性が求められます。そのため、現場で課題を抱える方々が自ら数理最適化モデルを構築・運用するには技術的なハードルが高く、専門家の支援が不可欠となるケースも少なくありません。 生成AIの台頭 近年、読者の皆さまもご存じのとおり、ChatGPT や Gemini に代表されるアプリケーションの登場により、生成AIは大きな注目を集めています。生成AIの活用によって、日々の生活や業務の在り方が大きく変わったと感じている方も多いのではないでしょうか。 NTTドコモビジネスにおいても、生成AIに関する取り組みが積極的に進められており、次のような公開情報からもその一端をご覧いただけます（ 生成AI（Generative AI）｜NTTドコモビジネス 法人のお客さま ）。また、 Node-AI も、ユーザーによって自由度の高い可視化や前処理を支援するために、生成AIを活用したサポート機能が提供されています。詳しくは以下のリソースをご参照ください。 データ可視化 - AI可視化 データ前処理 - AIアシスト付きカスタム前処理 このような流れを受け、私たちは現在、数理最適化問題の定式化やプログラム実装のプロセスを、生成AIによって支援・自動化する研究に取り組んでいます。 具体的には、業務課題を自然言語で入力するだけで、生成AIが最適化問題としての構造を理解し、目的関数や制約条件を抽出・提案する仕組みの構築を目指しています。また、その数理モデルをもとに、ソルバーと連携可能なコードを自動生成することにも取り組んでおり、これにより、これまで専門家の手を要していたプロセスの大幅な効率化が期待されます。 このアプローチにより、数理最適化の専門知識を持たないユーザーでも、業務課題に対して数理最適化技術を活用しやすくなり、より多くの現場で高度な意思決定支援が実現できると考えています。 実現アプローチの検討 本章では、スーパーマーケットの発注量最適化をテーマに、生成AIを支援技術として取り入れた数理最適化の活用について検討していきます。 生成AI活用の全体像 最初に、生成AI活用の全体像を示します。本アプローチでは、以下の3種類のAIエージェントを活用します。 定式化支援エージェント : ユーザーが抱えている課題や要件をプロンプトとして入力するだけで、AIが数理最適化モデルを自動で定式化します。 入力データ設計支援エージェント : 定式化された数理モデルに基づき、数理最適化実行に必要なデータ構造の設計案を具体的な例とともに提案します。 コード生成エージェント : 定式化されたモデルと設計された入力データをもとに、数理最適化を実行するためのプログラムコードを自動生成します。 これら3種類のAIエージェントが連携してユーザーをサポートすることで、これまで専門知識が不可欠であった数理最適化技術の導入プロセスを大幅に簡素化し、現場への迅速な実装を可能にします。 次のフローは、上記のAIエージェントを補助的に活用し、業務課題を解決するための数理最適化モデルの定式化から実行コードの生成、さらに業務への実装に至るまでのプロセスを体系的に整理したものとなっています。 ① 課題の適性診断（担当：定式化支援エージェント） ユーザーが解決したい課題の概要を定式化エージェントに入力。その課題が数理最適化技術での解決に適しているかの判定。 解決可能と判定された場合: ステップ2への移行。 解決困難と判定された場合: 別のアプローチ（機械学習、シミュレーションなど）の検討。 ② 数理モデルの定式化（担当：定式化支援エージェント） ユーザーによる課題詳細（制約条件、目的関数など）のエージェントへ入力。これを数理最適化問題として定式化し、その内容をMarkdownファイルとして出力。 ③ 入力データの設計（担当：入力データ設計支援エージェント） ステップ2で作成された数理モデルのMarkdownファイルを、入力データ設計支援エージェントへインプット。モデルに必要なデータ項目の自動抽出および機械学習による予測の必要性の有無の判断、それらのデータ設計方法の具体例を伴う提示。 ④ 入力データの準備（担当：ユーザー） ステップ3の設計案に基づく、実際の業務データなど必要な入力データの準備。 （分岐）: ステップ3で機械学習による予測が必要と判断されたデータ項目については、Node-AIなどのツールを用いた予測モデルの構築と、それによる予測値の生成。 ⑤ 実行コードの生成（担当：コード生成エージェント） ステップ2の数理モデルのMarkdownファイルと、ステップ4の入力データをコード生成エージェントへインプット。特定の最適化ライブラリを使用した実行可能なPythonコードの生成。 ⑥ 業務への実装と活用（担当：ユーザー ＜＋コード生成エージェント＞） 生成されたPythonコードの、ユーザーによる実際の業務プロセスやシステムへの組み込み。コードの微調整や運用方法の最適化など、コード生成エージェントのサポートを適宜受けながらの業務利活用の推進。 なお、各種AIエージェントの支援を活用し、上記プロセスを通じて業務課題への数理最適化技術の適用を容易にするアプリケーションを開発しています。 本稿では、その開発中の画面の一部とともにご紹介します。 在庫最適化の課題設定 次に、本検討で取り上げる課題設定を示します。なお、課題はシンプルに設定しています。 ○ 目的 スーパーマーケットにおける日配品の在庫管理を対象に、適正在庫を維持しながら、廃棄ロスを最小限に抑えることを目指す。欠品はある程度許容しつつ、過剰在庫によるロスの削減を重視する。 ○ 前提条件 - 対象カテゴリ：日配品 - 対象商品数：50SKU (Stock Keeping Unit: 在庫管理単位) - 発注頻度：毎日 - リードタイム：1日 - オペレーション： - 午前中に発注指示 - 閉店後、消費期限切れ商品を廃棄 - 翌朝、発注商品が納品 - 納品体制：地域の卸業者による一括納品 イメージ図(AI生成) 以降では、こちらの課題を例に、AIエージェントを活用した具体的なフローを説明します。 実現までのステップ 1. 定式化支援エージェントによる定式化支援 まず、数理最適化に不慣れなユーザーにとっては、前述した在庫管理の課題が数理最適化によって解決可能かどうかを判断するのは容易ではありません。そこで、生成AIを活用し、当該課題が数理最適化の適用対象となり得るかを診断するアプローチを試みます。 以下は、当該課題に数理最適化技術を適用できるかどうかを判断するために、定式化支援エージェントに与えるプロンプトの一例です。現在開発中のアプリケーションでは、ユーザーが【課題概要】の欄に自身の課題を簡潔に入力すると、これをもとにエージェントが応答を生成する仕組みになっています。 エージェントによる回答結果はこちらです。 定式化支援エージェントの解析結果として、「 数理最適化によって解決可能である 」との判断が得られました。これを受け、次のステップでは、具体的な数理最適化問題の定式化に進みます。 下記は、定式化支援エージェントに数理最適化問題の定式化を依頼する際のプロンプト例です。開発中のアプリケーションでは、ユーザーが【課題内容】欄に具体的な課題を入力すると、それを踏まえてエージェントが最適な定式化を自動生成します。 定式化支援エージェントからは、次のような回答が得られました。 定式化支援エージェントを用いることで、数理最適化問題の定式化がわずか1分足らずで完了しました。通常であれば、人手による定式化には相応の時間と労力を要しますが、エージェントは非常に短時間で処理を行い、大幅な時間短縮を実現しています。 作成された定式化には、プロンプトで与えた「目的」や「制約」、「補足情報」が的確に反映されており、日本語による説明を通じて、その妥当性が確認できます。 特に注目すべきは、欠品量・廃棄量・在庫の遷移といった要素について、プロンプト内で明示的に指示していないにもかかわらず、適切に定式化へ組み込まれていた点です。 さらに、消費期限順に商品が販売・消費されるという数式で表現するには難易度の高い制約についても、エージェントは短時間で的確に反映しており、その高い汎用性と柔軟性がうかがえます。 本エージェントにより定式化された数理最適化モデルが妥当と判断された場合、生成AIを用いてMarkdown形式で内容の整理・保存を行います。これを次のステップの入力データ設計支援エージェントに引き渡していきます。 2. 入力データ設計支援エージェントによるデータ設計支援 前節では、定式化支援エージェントのサポートを受けながら、数理最適化問題の定式化を完了しました。次に、最適化を実行するために必要な入力データの設計を行います。 不慣れなユーザーにとっては、「どのようなデータを、どのような構成で用意すればよいのか」が分かりにくい場合があります。そこで本アプリケーションでは、入力データ設計支援エージェントを活用して、入力データの設計案を自動的に提示する仕組みを取り入れています。 数理最適化モデルが記述されたMarkdownファイルをアップロードした上で、入力データ設計支援エージェントに次のようなプロンプトを与えます。なお、開発中のアプリケーションにおいては、自動でこのプロンプトが与えられます。 エージェントによる回答結果はこちらです。 まず、Step 1ではデータ項目の整理を行っています。具体的には、「データ項目」「説明」「数式表現」「単位例」「カテゴリ」「機械学習（回帰）を要する可能性」の6項目が一覧化されています。 このステップで特に注目すべきなのは、「機械学習（回帰）を要する可能性」の判定結果です。機械学習に詳しくないユーザーにとって、あるデータを準備するのに機械学習技術が必要かどうかを判断するのは容易ではありません。この判定結果は、その判断をサポートする重要な情報となります。 例えば、「需要量」については機械学習技術の活用が必要と判断されています。実際、将来の需要量を見積もるには予測が伴うため、機械学習手法を用いる必要があります。 Step 2では、CSVファイル形式による入力データの設計案が提示されており、各ファイルの名称や具体的なデータ例も示されています。今回の例では、以下の４つのCSVファイルに分割して設計することが提案されています。 products.csv （商品ごとの基本情報を示すデータ） ※「欠品コスト（円/個）」および「廃棄コスト（円/個）」の値は、ユーザーの業務内容やポリシーに応じて個別に設定する必要があります。例えば、簡易的な想定として、欠品コストは粗利、廃棄コストは仕入れ価格を基準とすることが可能です。 demand.csv （各商品における将来の需要数（予測値）を示すデータ） initial_inventory.csv （各商品の初期在庫量を記録したデータ） scalar_constraints.csv （計画期間といった全体に適用される設定値） この設計案を参考に、次節では実際のデータ準備を進めていきます。 3. Node-AIを活用したデータの準備 前節のエージェントによる出力結果を参考にしながら、必要な入力データを実際に準備していきます。なお、データの取得にあたっては、場合によっては既存の業務プロセスに対する見直しや調整が必要となる可能性もあります。 まず、「機械学習（回帰）を要する可能性」が「あり」と判定された「商品の需要量」に着目します。この項目は機械学習による予測が必要であるため、NTTドコモビジネスのプロダクトである Node-AI を活用します。 Node-AI のキャンバスは以下の画像の通りです。操作手順については、 こちらの記事 で紹介している内容と基本的には同じであるため、本稿では詳細な説明を省略します。 この予測結果に加え、Step 1で提示された「説明」やStep 2の入力データ設計案を踏まえて、実際の入力データの整備を進めます。今回は、以下のような形式でデータを準備しました。 なお、Step 2で提示されている入力データ設計案はあくまで一例であり、その形式に厳密に従う必要はありません。ユーザーの業務環境や保有するデータの構造に応じて、列名やデータ型などを柔軟に調整して問題ありません。 例えば今回の例だと、 initial_inventory.csv における列名「消費期限クラス」を「残消費期限（日）」に変更しており、 demand.csv の日付形式も「yyyy-mm-dd」から「yyyy/mm/dd」へと変更しています。 こうして必要に応じた調整を行いながら、数理最適化の実行に必要なデータを整備しました。 4. コード生成エージェントによる実行コード生成 データの準備が完了したので、最後にコード生成エージェントを活用して数理最適化を実行するための Python コードを作成します。なお、コードの実行は以下の環境で検証しています。 version Python: 3.13.1 PySCIPOpt: 5.2.1 SCIPソルバー: 9.2.0 numpy: 2.2.2 pandas: 2.2.3 準備した入力データのCSVファイルと、数理最適化モデルが記述されたMarkdownファイルをアップロードし、その上でコード生成エージェントに次のプロンプトを与えます。なお、開発中のアプリケーションではこちらのプロンプトに関してもあらかじめ設定されていて、自動で操作が行われます。 エージェントによって出力された結果は以下の通りです。 import pandas as pd from pyscipopt import Model, quicksum class Solver : def __init__ (self, scalar_constraints_path: str , demand_path: str , inventory_path: str , product_path: str ): """ Solverクラスの初期化 :param scalar_constraints_path: スカラーの制約定数が入ったCSVファイルのパス :param demand_path: 需要データCSVファイルのパス :param inventory_path: 初期在庫CSVファイルのパス :param product_path: 商品パラメータCSVファイルのパス """ # CSVファイルのパスを保持 self.scalar_constraints_path = scalar_constraints_path self.demand_path = demand_path self.inventory_path = inventory_path self.product_path = product_path # SCIPモデルを初期化（perishable_inventoryという名前をつける） self.model = Model( "perishable_inventory" ) def load_data (self): """ CSVファイルから各種データを読み込み、 モデルで使うパラメータを準備する """ # スカラーの制約定数が入ったデータを読み込み（shift_jisエンコーディング） self.scalar_constraints_df = pd.read_csv(self.scalar_constraints_path, encoding= "shift_jis" ) # 「パラメータ」列をインデックスに設定 self.scalar_constraints_df.set_index( "パラメータ" , inplace= True ) # 需要データの読み込み self.demand_df = pd.read_csv(self.demand_path, encoding= "shift_jis" ) # 初期在庫データの読み込み self.inventory_df = pd.read_csv(self.inventory_path, encoding= "shift_jis" ) # 商品パラメータの読み込み（消費期限、発注上限、コストなど） self.product_df = pd.read_csv(self.product_path, encoding= "shift_jis" ) # 計画期間 T（日数）を取得 self.T = int (self.scalar_constraints_df.loc[ "計画期間（日）" , "値" ]) # 商品IDの一覧（重複なし）を取得 self.products = list (self.product_df[ "商品ID" ].unique()) # 商品ごとのパラメータ辞書を作成 self.S = self.product_df.set_index( "商品ID" )[ "最大消費期限（日）" ].to_dict() # 最大消費期限 self.U = self.product_df.set_index( "商品ID" )[ "発注上限（個）" ].to_dict() # 発注上限数量 self.c_w = self.product_df.set_index( "商品ID" )[ "廃棄コスト（円/個）" ].to_dict() # 廃棄コスト self.c_s = self.product_df.set_index( "商品ID" )[ "欠品コスト（円/個）" ].to_dict() # 欠品コスト # 需要データの日付を1..Tのインデックスに変換するための辞書を作成 unique_dates = sorted (self.demand_df[ "date" ].unique()) self.date_to_t = {d: idx + 1 for idx, d in enumerate (unique_dates)} # 需要量の辞書を作成（キー：(商品ID, 時間t), 値: 需要量） self.d = {} for _, row in self.demand_df.iterrows(): i = row[ "商品ID" ] t = self.date_to_t[row[ "date" ]] self.d[(i, t)] = int (row[ "需要量(個)" ]) # 初期在庫量の辞書を作成（キー：(商品ID, 残消費期限), 値: 初期在庫量） self.I0 = {} for _, row in self.inventory_df.iterrows(): i = row[ "商品ID" ] s = int (row[ "残消費期限（日）" ]) self.I0[(i, s)] = int (row[ "初期在庫量（個）" ]) def build_model (self): """ 数理モデルの構築 変数定義、目的関数設定、制約条件設定を行う """ # まずはデータを読み込む self.load_data() # 変数を格納する辞書を初期化 self.x = {} # 発注量 x_{i,t} self.I = {} # 在庫量 I_{i,t}^s self.f = {} # 販売量 f_{i,t}^s self.b = {} # 欠品量 b_{i,t} self.w = {} # 廃棄量 w_{i,t} # 変数の定義 for i in self.products: Si = self.S[i] # 商品iの消費期限 Ui = self.U[i] # 商品iの発注上限 for t in range ( 1 , self.T+ 1 ): # 発注量変数（0以上、上限Ui、整数） self.x[(i, t)] = self.model.addVar( vtype= "INTEGER" , lb= 0 , ub=Ui, name=f "x_{i}_{t}" ) # 欠品量変数（0以上、整数） self.b[(i, t)] = self.model.addVar( vtype= "INTEGER" , lb= 0 , name=f "b_{i}_{t}" ) # 廃棄量変数（0以上、整数） self.w[(i, t)] = self.model.addVar( vtype= "INTEGER" , lb= 0 , name=f "w_{i}_{t}" ) # 在庫量と販売量は消費期限ごとに定義 for s in range ( 1 , Si+ 1 ): self.I[(i, t, s)] = self.model.addVar( vtype= "INTEGER" , lb= 0 , name=f "I_{i}_{t}_{s}" ) self.f[(i, t, s)] = self.model.addVar( vtype= "INTEGER" , lb= 0 , name=f "f_{i}_{t}_{s}" ) # 目的関数：廃棄コスト + 欠品コスト の最小化 self.model.setObjective( quicksum( self.c_w[i] * self.w[(i, t)] + self.c_s[i] * self.b[(i, t)] for i in self.products for t in range ( 1 , self.T+ 1 ) ), "minimize" ) # 制約1: 初期在庫条件 I_{i,1}^s = 初期在庫量 for i in self.products: Si = self.S[i] for s in range ( 1 , Si+ 1 ): init_val = self.I0.get((i, s), 0 ) # 初期在庫がなければ0とする self.model.addCons( self.I[(i, 1 , s)] == init_val, name=f "initInv_{i}_{s}" ) # 制約2: 在庫遷移の制約（消費期限の経過を反映） for i in self.products: Si = self.S[i] for t in range ( 2 , self.T+ 1 ): for s in range ( 1 , Si+ 1 ): if s == Si: # 新規発注分は残消費期限Siの在庫になる self.model.addCons( self.I[(i, t, s)] == self.x[(i, t- 1 )], name=f "invTrans_new_{i}_{t}_{s}" ) else : # 古い在庫は1日経つと残消費期限が1減る（販売後） self.model.addCons( self.I[(i, t, s)] == self.I[(i, t- 1 , s+ 1 )] - self.f[(i, t- 1 , s+ 1 )], name=f "invTrans_{i}_{t}_{s}" ) # 制約4-1: 需要充当（販売＋欠品=需要） for i in self.products: for t in range ( 1 , self.T+ 1 ): demand = self.d.get((i, t), 0 ) # 需要がない場合は0 Si = self.S[i] self.model.addCons( quicksum(self.f[(i, t, s)] for s in range ( 1 , Si+ 1 )) + self.b[(i, t)] == demand, name=f "demandFulfill_{i}_{t}" ) # 制約4-2: 販売量は在庫以下であること for i in self.products: for t in range ( 1 , self.T+ 1 ): Si = self.S[i] for s in range ( 1 , Si+ 1 ): self.model.addCons( self.f[(i, t, s)] <= self.I[(i, t, s)], name=f "sellCap_{i}_{t}_{s}" ) # 制約4-3: FIFO販売順序の保証 for i in self.products: for t in range ( 1 , self.T+ 1 ): demand = self.d.get((i, t), 0 ) Si = self.S[i] for s in range ( 1 , Si+ 1 ): if s > 1 : # sより短い消費期限の販売が先に行われている必要がある self.model.addCons( self.f[(i, t, s)] <= demand - quicksum(self.f[(i, t, k)] for k in range ( 1 , s)), name=f "fifo_{i}_{t}_{s}" ) # 制約5: 廃棄量は残消費期限1の在庫から販売量を引いたもの for i in self.products: for t in range ( 1 , self.T+ 1 ): self.model.addCons( self.w[(i, t)] == self.I[(i, t, 1 )] - self.f[(i, t, 1 )], name=f "wasteDef_{i}_{t}" ) def solve (self): """ モデルを解く """ # ログを非表示に設定 self.model.setParam( 'display/verblevel' , 0 ) # 最適化を実行 self.model.optimize() def check_model_status (self): """ 解の状態を確認し、最適解が見つかったかどうかを返す """ status = self.model.getStatus() if status == "optimal" : print ( "✅ 最適解が見つかりました。" ) return True else : print (f "エラー：{status}" ) return False def get_solution (self): """ 最適解がある場合、各変数の値を辞書で取得する """ # 最適解があるかチェック if not self.check_model_status(): return None # 最適解を取得 best_sol = self.model.getBestSol() if best_sol is None : print ( "❌ 実行可能解は取得できませんでした。" ) return None # 変数名と値を辞書に格納 result = {} for var in self.model.getVars(): val = self.model.getSolVal(best_sol, var) result[var.name] = val return result コード生成エージェントを活用することで、このように長大なコードであっても、わずか1分足らずでミスなく作成できました。人手によるコーディングでは多くの手間や時間がかかりますが、エージェントによりそれらを大幅に削減し効率的な開発を可能にしています。 生成されたコードは、先ほど用意した4つのデータを読み込み、それをもとに最適な発注量や在庫の動きを計算する仕組みです。消費期限や在庫の状況、日ごとの需要などを考慮しながら、「どの商品を、いつ・どれだけ発注し、どのくらい販売し、欠品や余剰がどの程度発生するか」を自動的に判断します。 このようにして、在庫の無駄や欠品をできるだけ抑えた、バランスの取れた計画が立てられるようになります。 この Solver クラスを利用して、実務で使うために各商品の当日発注量をCSVファイルとして出力するコードを、エージェントに作成してもらいます。 エージェントに渡すプロンプトは以下の内容です。 エージェントによって作成されたコードはこちらです。 import argparse import pandas as pd from optimizer import Solver def export_first_day_orders ( scalar_constraints_path: str , demand_path: str , inventory_path: str , product_path: str , output_csv_path: str ): """ Solver を使って最適化を実行し、 初日の各商品の発注量を CSV 出力する。 :param scalar_constraints_path: scalar_constraints.csv のパス :param demand_path: demand.csv のパス :param inventory_path: inventory.csv のパス :param product_path: product.csv のパス :param output_csv_path: 出力 CSV ファイルのパス """ # モデル構築・最適化 solver = Solver( scalar_constraints_path=scalar_constraints_path, demand_path=demand_path, inventory_path=inventory_path, product_path=product_path ) solver.build_model() solver.solve() # 最適解取得 sol = solver.get_solution() if sol is None : print ( "最適解が取得できなかったため、CSV を出力しません。" ) return # 初日の発注量をリスト化 records = [] for product_id in solver.products: var_name = f "x_{product_id}_1" qty = sol.get(var_name, 0 ) records.append({ "商品名" : product_id, "発注量" : int (qty) }) # DataFrame 化して CSV 出力（Shift_JIS） df_out = pd.DataFrame(records, columns=[ "商品名" , "発注量" ]) df_out.to_csv(output_csv_path, index= False , encoding= "shift_jis" ) print (f "初日の発注量を '{output_csv_path}' に出力しました。" ) if __name__ == "__main__" : parser = argparse.ArgumentParser( description= "初日の各商品の発注量を最適化し、CSV 出力します。" ) parser.add_argument( "--scalar_constraints" , required= True , help = "scalar_constraints.csv のパス（Shift_JIS）" ) parser.add_argument( "--demand" , required= True , help = "需要データ CSV のパス（Shift_JIS）" ) parser.add_argument( "--inventory" , required= True , help = "初期在庫データ CSV のパス（Shift_JIS）" ) parser.add_argument( "--product" , required= True , help = "商品パラメータ CSV のパス（Shift_JIS）" ) parser.add_argument( "--output" , required= True , help = "出力先 CSV ファイルのパス（Shift_JIS）" ) args = parser.parse_args() export_first_day_orders( scalar_constraints_path=args.scalar_constraints, demand_path=args.demand, inventory_path=args.inventory, product_path=args.product, output_csv_path=args.output ) エージェントを活用することで、こちらのコードも短時間でミスなく作成できました。 5. 作成されたコードの実行と結果 例えば、必要なデータファイルと出力ファイルのパスを指定し、次のようなコマンドを実行することで、 python export_first_day_orders.py \ --scalar_constraints scalar_constraints.csv \ --demand demand.csv \ --inventory initial_inventory.csv \ --product products.csv \ --output initial_orders.csv 以下のような 各商品の当日発注量をまとめたCSVファイルが自動的に出力 されます。こちらの情報をもとに各商品の発注作業を行います。 このように、生成されたコードを活用することで、業務で実際に必要となるファイルの作成までを一貫して自動化できます。現場でもすぐに運用に取り入れやすいため、これまで発注作業にかかっていた時間の大幅な短縮や、ヒューマンエラーの削減が期待されます。 まとめ 本記事では、生成AIを活用した数理最適化技術の自動化に関する検討をご紹介しました。特に、スーパーマーケットにおける在庫管理を一例として取り上げ、エージェント3種のサポートのもとで課題設定から実装に至るまでのプロセスを示しました。 本記事で一部をご紹介したアプリケーションは現在も開発中であり、引き続き改良を重ねてまいります。 今後は、生成AIの回答精度向上やUI/UXの改善に取り組むとともに、実社会での活用に向けた検証を進め、研究開発を一層推進していく予定です。 おわりに 本記事が少しでも皆さまのお役に立てたのであれば、嬉しく思います。 Node-AIを活用した機械学習技術のビジネス活用にご関心のある方は、ぜひ こちら のフォームよりお気軽にお問い合わせください。 また、本記事の内容に関するご質問や、数理最適化技術をはじめとした数理解析技術のPoCにご関心のある方は、メールにてご連絡をお待ちしております。(メール：adam-ic[at]ntt.com)

NTTドコモビジネスが開発しているSBOM管理ソリューション「Threatconnectome」において、Trivyと同じ脆弱性データベースを使用しているにもかかわらず、特定のパッケージで脆弱性検出漏れが発生した事例を紹介します。 はじめに 1. Trivyにおけるパッケージの分類について バイナリパッケージとソースパッケージについて バイナリパッケージ ソースパッケージ バイナリパッケージとソースパッケージの分類の意図 Trivyにおける脆弱性検出の仕組み Threatconnectomeにおける脆弱性の未検知問題の詳細 プロジェクトでの対応策 実施後の効果 まとめ 脚注 参考文献 はじめに こんにちは。イノベーションセンターMetemcyberプロジェクトの千坂知也と申します。 本記事では、私たちMetemcyberプロジェクトが開発しているSBOM（Software Bill of Materials） *1 管理ソリューション「Threatconnectome」（以下Tc） *2 にて発生した大規模な脆弱性の検出漏れについて、その原因と対応、改善結果を取り上げます。 Tcでは、オープンソースの脆弱性スキャナTrivyが脆弱性情報として参照しているTrivy DBを利用しています。そんな中、Ubuntuのパッケージをスキャンした際、Trivyでは該当パッケージ内の脆弱性が検知された一方で、Tcでは該当パッケージ内の脆弱性を検知できていないことが発覚しました。 同じ脆弱性情報を利用しているはずなのになぜこのようなことが起きてしまったのか？私たちは、TrivyとTcの間で脆弱性マッチングの処理に何らかの違いがあると推測いたしました。 以降では、次の4つについて述べていきたいと思います。 Trivyにおけるパッケージの分類について Trivyの脆弱性マッチングとTcの脆弱性マッチングの差異について Threatconnectomeにおける脆弱性の未検知問題の詳細 プロジェクトでの対応策 1. Trivyにおけるパッケージの分類について オープンソースの脆弱性スキャナTrivy *3 では、コンテナイメージやファイルシステム、ソースコードなどに含まれる脆弱性や設定ミスを検出します [1] 。CI/CDパイプラインへの統合が容易であり、SBOM生成・ライセンススキャンなども活用できることからセキュリティ管理の幅広い領域で使われています [2] 。このTrivyでは、脆弱性スキャンの対象を大まかに以下の２種類に分けて扱います [3] 。 OSパッケージ：Linuxディストリビューションのパッケージマネージャで管理されるパッケージ（dpkg,apt, rpm, apk など） Langパッケージ：各プログラミング言語の依存ライブラリ （pip, npm, gem, go, maven など） このうちOSパッケージは、さらに手元でインストールするファイル群及びそれらのファイル群のインストール/アンインストールを制御するパッケージと元のソースが書かれたパッケージの２種類が存在します。Ubuntu（Debian系）のOSパッケージでは前者をBinary Package（バイナリパッケージ）、後者をSource Package（ソースパッケージ）と言います。次の章ではこのバイナリパッケージとソースパッケージを説明していきます [4] 。 バイナリパッケージとソースパッケージについて 公式Ubuntu documentationのPackage modelの項では、ソースパッケージ→バイナリパッケージの順で記載がありますが、ここでは分かりやすさを重視してバイナリパッケージから説明をさせていただきたいと思います [5] 。 バイナリパッケージ バイナリパッケージとは、パッケージマネージャが理解できる標準化された形式のパッケージのことです [6] 。Debian系のバイナリパッケージは、.debというファイル拡張子を持ち、次の2種類のファイル群を含みます。 対象システムにインストールされる実際のファイル群 それらのファイルをどのようにインストールまたはアンインストールするかを制御するファイル群 これにより、ソフトウェアを対象のマシンに簡単に配布・インストール・アンインストールできるようになります。 ソースパッケージ ソースパッケージは、複数のバイナリパッケージをビルドするためのソースコードおよびビルド情報を含んだものです [7] 。その構成は次の通りです。 Debianソースコントロール（.dsc）ファイル 1つ以上の圧縮されたtarファイル（.tar.gz, .tar.xz など） パッケージの形式に応じて、追加のファイル 特に.dscファイルには、以下のようなメタデータが含まれます。 ファイルのリスト パッケージ名とバージョン 作成されるバイナリパッケージの一覧 依存関係 デジタル署名 その他多数のフィールド つまり、普段我々が手元でインストールするファイル群以外に元のソースを含んだパッケージも別に存在しているということです。そもそもなぜこのような分類をしているのでしょうか？ バイナリパッケージとソースパッケージの分類の意図 Ubuntu（および Debian 系）は、基本的にDebianのパッケージモデル（パッケージ方式）を採用しており、上述した通り「ソースパッケージ」→（ビルド）→「バイナリパッケージ」という流れが基本となります。 このような分類をしている理由の1つとして「同じソースから、異なるアーキテクチャやOS向けへとビルドできるようにするため *4 」があります [8] 。Debian系では、まず1つのソースパッケージが用意され、これをもとに複数のバイナリパッケージがビルドされます。実際にソフトウェアを使う環境はさまざまで、CPUの種類（アーキテクチャ）も異なります。UbuntuやDebian系でよく使われるアーキテクチャの具体例としては、amd64、arm64、i386などがあります。個別に各CPUアーキテクチャやOS環境向けのパッケージを用意するのではなく、大本のソースパッケージからそれぞれの環境へ適した最適な実行バイナリを生成するほうが、運用面で効率的です [9] 。 それ以外にもビルドの再現性を担保するため（ソースからバイナリを再ビルドして、元のバイナリと一致するか確認できる。改ざん検出やセキュリティ検証に不可欠）、パッチ管理を容易にするため（Debian系では、オリジナル開発元のソースに対し、独自パッチを追加して管理する）などもソースパッケージとバイナリパッケージを分ける利点として挙げられます。 Trivyにおける脆弱性検出の仕組み Trivyでは、OSパッケージとLangパッケージをそれぞれ独立して識別・スキャンし、対応する脆弱性データベースとマッチングします。この二層構造により、インフラ層（OS）とアプリケーション層（言語ライブラリ）の両面に潜むセキュリティリスクを網羅的に検出できる点が、Trivyの大きな強みです。 このマッチングに利用する脆弱性データベース（Trivy DB）では、Ubuntu（Debian系）のOSパッケージにおいてソースパッケージ名を基準に脆弱性情報を管理しています *5 [10] 。その理由はUbuntuやDebian系ディストリビューションの脆弱性情報が基本的にソースパッケージ単位で配布されているためです [11] 。そのため、マッチングに利用する脆弱性情報（今回の場合Trivy DB内の情報）もソースパッケージ名で格納しておかないと、マッチングすることが出来ないのです。 この仕組みによって、同一のソースパッケージからビルドされた複数のバイナリパッケージに対しても、一貫した脆弱性判定が可能となっています。 Threatconnectomeにおける脆弱性の未検知問題の詳細 冒頭でも申し上げたとおり、私たちが開発しているSBOM管理ソリューションTcにおいて、Ubuntuのパッケージに関する脆弱性検出漏れが発生しました。Tcは脆弱性情報としてTrivy DBを利用していますが、linux-modules-5.15.0-1025-gcpというパッケージを含むソフトウェアをスキャンした際、Trivyではパッケージ内の脆弱性が検知された一方で、Tc側では同一パッケージ内の脆弱性が検知できていなかったのです。 調査の結果、Tcでは入力されたSBOMファイルのバイナリパッケージ名とエコシステムのみを脆弱性マッチングのキーとして使用していたことが原因であると分かりました。 下記は実際に我々が入力したSBOMファイル（フォーマット：CycloneDX）の一部（コンポーネントのひとつ）になります。この例では"name"がバイナリパッケージ名、"aquasecurity:trivy:SrcName"がソースパッケージ名に該当します。この場合、"linux-gcp-5.15"がソースパッケージ名です。 前述したとおりUbuntu（Debian系）の脆弱性情報はソースパッケージ名で配布されているため、Trivy DBではUbuntuのOSパッケージの脆弱性情報をソースパッケージ名（この場合linux-gcp-5.15）で管理しており、Trivy自体も入力されたSBOMの"aquasecurity:trivy:SrcName"部分を抽出しマッチングを行います。 { "name": "linux-modules-5.15.0-1025-gcp", "purl": "pkg:deb/ubuntu/linux-modules-5.15.0-1025-gcp@5.15.0-1025.32~20.04.2?arch=amd64&distro=ubuntu-20.04", "properties": [ { "name": "aquasecurity:trivy:PkgType", "value": "ubuntu" }, { "name": "aquasecurity:trivy:SrcName", "value": "linux-gcp-5.15" }, … ], … } Tcは、Trivy DBの脆弱性情報を利用していたものの、入力されたSBOMから抽出したバイナリパッケージ名（linux-modules-5.15.0-1025-gcp）とpurlフィールドなどから構築されるエコシステムのみを使用していたため、Trivy DB内にあるソースパッケージ名（linux-gcp-5.15）と一致せず、脆弱性を検出できない問題が発生したということです。 適切な脆弱性情報は（Trivyと同じ脆弱性情報を利用していたため）あったものの、入力されたSBOMから抽出するフィールドが異なっていたということです。 SBOM内の"aquasecurity:trivy:PkgType"がubuntuであることから、このパッケージはUbuntuのOSパッケージであると判別できます。しかし、OSパッケージ特有のSrcNameを正確に処理するロジックが不足していたわけです。 プロジェクトでの対応策 前章で述べた通り、Tcでは脆弱性マッチングの際に入力されたSBOMのバイナリパッケージ名を使用していたことが原因で、ソースパッケージ名ベースで管理されているTrivy DBの脆弱性情報と一致せず、一部の脆弱性を検出できていませんでした。この問題を受け、我々のプロジェクトでは以下の対応を実施しました。 OSパッケージとLangパッケージの区別を明確化 入力されたSBOMに含まれる脆弱性を解析する際に、OSパッケージとLangパッケージを明確に区別して扱うようにし、OSパッケージの場合であれば、入力されたSBOMの「ソースパッケージ名」と「バイナリパッケージ名」の両方を保持するよう仕様を変更しました。 パッケージの一意識別ロジックを拡張 パッケージを一意に識別するための条件を、従来の「バイナリ名＋エコシステム」から次のように拡張しました。 一意識別キー:(エコシステム, バイナリパッケージ名, ソースパッケージ名) 脆弱性マッチング条件の改善 脆弱性データベースとのマッチング条件を次のように変更しました。 マッチング条件: 「エコシステムが同一」かつ（「バイナリパッケージ名が一致」または「ソースパッケージ名が一致」） さらに、バイナリパッケージ名、ソースパッケージ名両方の一致候補が存在する場合には、ソースパッケージ名一致を優先するルールを設けることで、判定の一貫性と精度を確保しました。 実施後の効果 これらの対応により、 バイナリパッケージ名、ソースパッケージ名の両方 でマッチング可能になり、脆弱性の検知精度が大幅に向上しました。 linux-gcp-5.15パッケージの脆弱性に限ってみれば3191件もの脆弱性が新しく検知されるようになりました（2025/7/2時点）。逆にいうと、本対応以前までlinux-gcp-5.15パッケージに関するものだけでも3191件もの脆弱性を見落としていたということになります。 まとめ 本稿では、OSパッケージの分類による差分から発生する脆弱性の未検知問題について取り扱いました。SBOMなどを用いたソフトウェア内のパッケージ単位での脆弱性管理は求められつつある一方で、その管理の困難性や一貫したアプローチ法がないなどの課題もあります。我々Metemcyberプロジェクトでは、Trivyを踏襲しつつ、独自のモデル設計によりこれらの問題の解決を図ってきました。ご興味がある方はぜひ Threatconnectome の GitHubページ などもご覧ください。ご連絡お待ちしております。 脚注 ソフトウェアを構成するコンポーネント（オープンソースソフトウェア、ライブラリなど）の一覧表（リスト）。ソフトウェアのBOM。各コンポーネントの名称、バージョン、依存関係、ライセンス情報などが含まれる。代表的なSBOM生成ツールにTrivy、Black Duck、Syftなどがあり、代表的なSBOMフォーマットにCycloneDX、SPDXなどがある。 ↩ nttcom/threatconnectome ↩ Trivy ↩ 全てのアーキテクチャに対応しているわけではない。ビルド依存関係によっては対応していないアーキテクチャもある。 ↩ 全てのOSパッケージの脆弱性情報がソースパッケージ名で格納されているわけではない。 ↩ 参考文献 Vulnerability - Trivy Container Image - Trivy Vulnerability Scanning - Trivy Package model - Ubuntu documentation Package format - Ubuntu project documentation 3. Binary packages — Debian Policy Manual v4.7.2.0 4. Source packages — Debian Policy Manual v4.7.2.0 Debian Policy Manual 5.3. Structure of a Source Package Ubuntu vulnerability source - Trivy DB ubuntu-cve-tracker

こんにちは。NTTドコモビジネスの露崎です。本ブログでは vLLMの本家コミュニティのブログ で紹介されたvLLMのモデルのゼロリロード切り替え機能の概要に加えて本機能をContainerベースで検証した結果について紹介します。 はじめに モデルのゼロリロード切り替え機能が取り組む課題 vLLM Sleep Mode Sleep Level 動作確認 環境構成 利用モデル 実験1. API利用状況の確認 vLLMの起動 Sleepによるモデルの停止 WakeUpによるモデルのリロード 実行結果とパフォーマンス考察 実験2. 複数モデルでの切り替え 準備 実験(各モデルに対して) 実験用スクリプト 実行結果 まとめ はじめに こんにちは。NTTドコモビジネスの露崎です。本ブログでは vLLMの本家コミュニティのブログ で紹介されたvLLMのモデルのゼロリロード切り替え機能について紹介します。 vLLM はカリフォルニア大学バークレー校のSky Computing Labが開発しOSSで公開している推論高速化ソフトウェアです。vLLMでは量子化やバッチ処理を始めとしたさまざまな高速化テクニックを実装しており、Large Language Model(LLM)の推論を高速化できます。また、vLLMはモデルリポジトリである huggingface で公開されているさまざまなモデルに対応しており、Meta社の Llama を始めとするオープンウェイトモデルを高速に実行する基盤ソフトウェアとして世界的に利用されています。 モデルのゼロリロード切り替え機能が取り組む課題 本ブログではvLLMを用いたLLM推論の提供において、同一のGPU上で複数のモデルを利用したい場合のモデル切り替えのオーバヘッドを解決する機能を紹介します。 vLLMはLLMの推論を高速に実行し、ユーザに結果を素早く提供できる有用性の高いソフトウェアです。 vLLMは高速な推論を実現するためにLLMの計算用キャッシュ(a.k.a. KV Cache) を事前にできるだけ確保する(デフォルトでは利用可能なメモリの90%)という仕組みを持っています。 この動作は単一のモデルを提供する際には特に問題となることはありません。しかし、GPUと言う貴重な計算リソースをある1つのモデルのために占有してしまうと言うことでもあります。 この特性のため、以下のように複数モデルを使い分けるユースケースにおいては、利用するモデル毎にGPUリソースを割り当てる必要があり、コストを増大させることにつながります。 質問からテキストベースで回答するLLMと画像の説明や分類を説明するVisual Launguage Model (VLM)を使い分けるシステム 複数の異なるLLMの出力結果を組み合わせて最終的な回答を得るエージェント この対策として、vLLMが提供している公式 Containerイメージ を利用し、需要やタイミングに応じて使うモデルをContainerの起動、終了によって切り替えると言った運用は可能です。 しかし、ファイルシステムからのモデルのロードや、起動時に実行される Cuda Graph 構築による最適化のオーバヘッドのため、例えば gemma-3-4b-it のような比較的小さいモデルであっても1分程度の起動待ちが発生すると言う課題があります。 vLLM Sleep Mode 前述の課題を解決する機能の1つがvLLMのSleep Modeです。Sleep Modeは起動中のvLLMに対して /sleep APIを呼び出すことでロード済みのモデルをCPUのメモリに待避する機能です。待避されたメモリは /wake_up APIを呼び出すことでGPUメモリへリロードできます。 /wake_up ではCPUからGPUへメモリ転送を実施するためファイルシステムからモデルを読み込むより高速にロードが実行でき、CUDA Graphの構築のオーバヘッドを回避できるため、vLLMのプロセスを最初から起動するよりも迅速にAPIが利用できるようになります。 NOTE Sleep Modeを使うためには環境変数 VLLM_SERVER_DEV_MODE=1 を設定する必要があります。 Sleep Level /sleep APIには引数でスリープ時のレベルを設定できます。(例: /sleep?level=1 ) 現在は2段階のスリープレベルがあり、それぞれ以下の通りです。 Level 1: モデルの重みをCPU RAMへオフロードし、KV CacheをGPUメモリから廃棄する Level 2: モデルの重みとKV CacheをGPUメモリから破棄し、スリープ時のCPU RAMの使用量を最小限にする 公式ドキュメント ではLevel 1は同一のモデルを再度利用する際に有効であり、Level 2は異なるモデルを利用する場合に有効である、と解説しています。 動作確認 vLLMの本家コミュニティのブログ や 公式ドキュメント ではPython API、及び、マルチプロセスでの実例が紹介されていますが、実際の運用を考慮するとContainerベースでもこの機能が実行できるかを確認したかったため、現在のStableの最新版である v0.11.0 で動作確認を実施した結果を紹介します。 環境構成 ハードウェア NVIDIA GeForce RTX 4090 24GB ソフトウェア Ubuntu 22.04.5 LTS NVIDIA Driver 580.95.05 docker-ce 5:28.5.1-1 vLLM v0.11.0 利用モデル google/gemma-3-4b-it meta-llama/Llama-3.2-1B-Instruct meta-llama/Llama-3.2-3B-Instruct 実験1. API利用状況の確認 vLLMの起動 まずはSleep Modeが現在のStableであるv0.11.0で利用できるのかを確認します。 以下のコマンドを実行してモデルを起動します。リポジトリへのアクセス権等の設定については必要に応じてHuggingFaceのアカウントで作成したトークンを環境変数 HF_TOKEN へ設定してください。 MODEL="google/gemma-3-4b-it" sudo docker run --runtime nvidia --gpus all \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p 8000:8000 \ --ipc=host \ --env "HUGGING_FACE_HUB_TOKEN=$HF_TOKEN" \ --env "VLLM_SERVER_DEV_MODE=1" \ vllm/vllm-openai:v0.11.0 \ --model ${MODEL} --enable-sleep-mode このコマンドでvLLM v0.11.0を起動できますが、起動時に以下がログ出力されます。 WARNING 10-29 18:58:56 [api_server.py:966] SECURITY WARNING: Development endpoints are enabled! This should NOT be used in production! この後の手順でAPIのサンプルを提示しますが、 /sleep APIは現在、通常のChat API同様のAPIエンドポイントによって受け付けられるため、素のままのAPIを利用すると任意のユーザがモデルの停止ができる状態になります。このため、プロダクションでの利用は現在推奨されていないようです。 Sleepによるモデルの停止 次にSleep ModeのAPIを呼び出します。Sleep ModeのAPIは以下の通りREST API経由で実行します。 curl -X POST 'localhost:8000/sleep?level=1' これを実行すると以下のようなログが出力され、GPUメモリが解放されます。 (EngineCore_DP0 pid=165) INFO 10-29 19:36:16 [cumem.py:228] CuMemAllocator: sleep freed 20.25 GiB memory in total, of which 8.63 GiB is backed up in CPU and the rest 11.62 GiB is discarded directly. (EngineCore_DP0 pid=165) INFO 10-29 19:36:16 [gpu_worker.py:117] Sleep mode freed 20.23 GiB memory, 1.21 GiB memory is still in use. (EngineCore_DP0 pid=165) INFO 10-29 19:36:16 [executor_base.py:189] It took 1.695459 seconds to fall asleep. (APIServer pid=1) INFO: 172.17.0.1:36138 - "POST /sleep?level=1 HTTP/1.1" 200 OK 今回利用した google/gemma-3-4b-it ではvLLM起動時に23GB程度占有していたメモリが、 /sleep 呼び出し後には1GB程度まで減っていることを確認しました。 NOTE Sleep Mode中のモデルに対して推論リクエストを実施するとv0.11.0の時点では400 Errorとなり、vLLMプロセスがクラッシュして停止します。 WakeUpによるモデルのリロード モデルのリロードを実施するには以下のコマンドを実行します。 curl -X POST 'localhost:8000/wake_up' これを実行すると以下のようなログが出力されます。 (APIServer pid=1) INFO 10-29 19:43:03 [api_server.py:1016] wake up the engine with tags: None (EngineCore_DP0 pid=165) INFO 10-29 19:43:03 [executor_base.py:205] It took 0.368304 seconds to wake up tags {'kv_cache', 'weights'}. (APIServer pid=1) INFO: 172.17.0.1:58818 - "POST /wake_up HTTP/1.1" 200 OK WakeUpが完了すると、通常のvLLMとしてOpenAI互換のAPIが利用できます。 NOTE Level 2のSleep Modeでは /wake_up の後に /collective_rpc (methodとして reload_weights を指定) 、 /reset_prefix_cache のAPIを呼び出す必要があります。 実行結果とパフォーマンス考察 モデル実行時の手順とオーバヘッドは以下の通りでした。 level 1 level 2 Sleep後のGPU使用メモリ 1236MiB 1241MiB 復帰時の手順 1 (wake_up) 3 (wake_up, collective_rpc, reset_prefix_cache) 復帰時のコマンド実行時間 (sec) 0.368304 0.737 Level 1、Level 2のいずれにおいても1秒以内にモデルの復帰が完了するため、vLLMのContainerを再起動するより高速にAPIを使えるようになることがわかります。GPUメモリとしてはLevel 1とLevel 2では削減効果は同等でした。復帰の手順の複雑性を考慮するとLevel 1を標準として利用可能だと考えます。公式ブログではLevel 2の際にCPU側のRAMを節約できると記載があるため、GPUだけでなくSleep中のCPUメモリも削減したい場合はLevel 2を使うと良いでしょう。 実験2. 複数モデルでの切り替え 実験1でvLLM v0.11.0のContainerでSleep Modeを利用可能なことが確認できたため、複数のモデルの切り替えを実行してみます。 vLLMの公式ブログでは同じ環境内の別プロセスとして起動する方法を紹介していましたが、ここではより本番環境に近づけるため1枚のGPUに対して2つのvLLM Containerを起動した状態でモデルの切り替えが実行できるかを試しています。 実験の実行手順としては以下の通りです。 準備 1つめのモデルのvLLM Containerを起動(8000ポート) /sleep?level=1 APIで1つめのモデルをSleep 2つめのモデルのvLLM Containerを起動(8001ポート) /slee?level=1 APIで2つめのモデルをSleep 実験(各モデルに対して) /wake_up APIでモデルのリロード sample.py スクリプトを用いてhealthcheck及び、推論APIの呼び出し 実験用スクリプト 今回は以下のようなBashスクリプトで実験をしています。 #!/bin/bash set -e # 切り替えるモデルの定義 MODELS=("meta-llama/Llama-3.2-1B-Instruct 8000" "google/gemma-3-4b-it 8001") RUN_NAME="vllm_sleep" # コンテナの作成と起動用関数を定義 create_vllm(){ c_name=${1#*/} echo "Use name ${c_name}" docker run -d --name ${RUN_NAME}-${c_name} --rm --runtime nvidia --gpus all \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p $2:8000 \ --ipc=host \ --env "VLLM_SERVER_DEV_MODE=1" \ --env "HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}" \ vllm/vllm-openai:v0.11.0 \ --model $1 --enable-sleep-mode } # 各モデルを起動し、APIの疎通が確認できたらSleepする for model in "${MODELS[@]}"; do read model_id port <<< "$model" c_name="${RUN_NAME}-${model_id#*/}" echo "start vllm container" create_vllm ${model_id} ${port} echo "wait and call an inference" uv run sample.py ${port} echo "suspend model with level 1" curl -X POST "http://localhost:${port}/sleep?level=1" done # 各モデルに対してリロードしAPIが実行できれば再度Sleepする echo "--- start benchmark for model switching ---" for model in "${MODELS[@]}"; do read model_id port <<< "$model" c_name=${RUN_NAME}-${model_id#*/} echo "Use name ${c_name}" curl -X POST "http://localhost:${port}/wake_up" echo "wait and call an inference" uv run sample.py ${port} echo "suspend model with level 1" curl -X POST "http://localhost:${port}/sleep?level=1" done # 起動しているContainerをCleanupする docker ps -q | xargs docker kill Containerの起動状態を確認し、推論APIを呼び出すPythonスクリプト( sample.py )は以下の通りです。 #!/usr/bin/env python3 from openai import OpenAI import os import requests import time import sys HOST = "http://localhost" def wait_to_ready(URL): while True: try: requests.get(f"{URL}/health") print("Healthcheck: OK") break except requests.exceptions.ConnectionError: time.sleep(0.1) def main(): port = sys.argv[1] if len(sys.argv) > 1 else 8000 url = f"{HOST}:{port}" wait_to_ready(url) # Localhost上のvLLMでありOpenAIの実際のキーは不要のためdummyを設定 os.environ["OPENAI_API_KEY"] = "dummy" client = OpenAI(base_url=f"{url}/v1") model_id = client.models.list().data[0].id print(f"Model {model_id} found.") response = client.responses.create( model=model_id, input="Write a one-sentence bedtime story about a unicorn." ) print(f"Got response: {response.output_text}") if __name__ == "__main__": main() 実行結果 実験スクリプトを実行すると、 --- start benchmark for model switching --- 以下の出力がおよそ1秒程度で完了することが確認できると思います。このことからvLLMのSleep Modeを利用することで複数のContainer、モデルに対して1つのGPUリソースで効率的なモデルの切り替えを実施できることが確認できました。 NOTE 例示したスクリプトでは meta-llama/Llama-3.2-1B-Instruct 、 google/gemma-3-4b-it の順序で起動し、問題なく /sleep , /wake_up が動作することを確認できました。しかし、別の実験として meta-llama/Llama-3.2-3B-Instruct 、 google/gemma-3-4b-it で試した場合には、Sleep後に meta-llama/Llama-3.2-3B-Instruct を /wake_up させるタイミングでOut of Memory (OOM) Errorが起き、プロセスが停止しました。 meta-llama/Llama-3.2-3B-Instruct は meta-llama/Llama-3.2-1B-Instruct より大きなモデルで、必要なGPUメモリが大きいため、Sleep Modeで切り替える場合であっても最低限必要なメモリの量は事前に調査しておく必要があると考えられます。 まとめ 本ブログではモデル切り替えのオーバーヘッドを削減するvLLMのSleep Modeについて紹介しました。Sleep Modeはまだ開発段階の機能ですが、複数のモデルの処理に対してGPUを効率的に利用できる機能ということが確認できました。今後、LLMの需要拡大に向けてこうしたGPUの処理効率を向上させるソフトウェア、仕組みを活用することはますます重要になると考えられます。

こんにちは。イノベーションセンターの加藤です。 手書きから活字へスタイル変換するモデルをFlow Matchingで学習しようとして色々試したものの上手くいかなかったため、試行錯誤の記録をブログの形で残したいと思います。 背景 上手くいかなかった手法たち 手法１：手書き文字分布から活字分布への変換 手法２：ControlNet学習 手法３：学習済みの活字生成モデルを手法１で転移学習する まとめ 背景 このモデルを学習しようとしたきっかけは手書き文字OCRの性能を向上させようという取り組みでした。OCRの難しい点として、現実のデータにはさまざまな特殊文字が現れるという問題があります。これら全ての手書き文字を学習データとして用意するのは難しく、色々な手法が提案されています。 その手法のひとつに、「活字から手書き文字を生成するモデルを作る」というものがあります。活字はフォントファイルから手に入るため、すでに手元にある手書きデータと共に手書き文字生成モデルを学習し、未知の活字からさまざまな形の手書き文字を学習データ用に生成することで、OCRのデータセットを増強できるというモチベーションです。 この方法を聞いたときに、同じことを「手書きから活字を生成するモデル」でもできるのではないか？と思いました。しかもこちらの方が色々な手書き文字を作って学習を回すという手間を省けるという利点があります。 そこで、Flow Matchingと呼ばれる生成モデル学習手法を使って手書き文字から活字に変換するモデルの学習に挑戦しました。手書き文字データセットはETL9B 1 、活字データセットはGoogle Noto Font 2 を利用し、JIS第１水準漢字を対象にしました。 上手くいかなかった手法たち 手法１：手書き文字分布から活字分布への変換 最初に試したことは、手書き文字から活字へ少しずつ変化させるUNetモデルの学習です。 TorchCFM 3 と呼ばれるライブラリを用いて、手書き文字の分布から活字文字の分布に少しずつ変化させるモデルを学習します。 今回のケースでは以下のような変換過程を学習しています。 データセットの分割はStratified K-Foldを用いて、学習で利用した文字種は評価時に現れないよう工夫しました。 結果は次のような画像になりました。稀にさんずいやしんにょうなどを捉えることはできていますが、基本的によくわからない文字になってしまっています。また、「沖」という文字が「汁」になっているなど、形が似ている別の学習データになってしまっている例も見受けられました。 手法２：ControlNet学習 先ほどの実験では入力に似た学習セット内の文字が出力されるというケースがありました。 そこで次はあらかじめ全ての活字に対して学習を回せるという仮定をおき、まず活字を生成するモデルを作ってから手書き文字で条件付けるという方法を試しました。 フォントデータは手書きよりも簡単に多くの文字種を得られるため、この仮定に無理はないはずです。 この方法でよく使われるのはControlNet 4 です。これはあらかじめ画像生成モデルとして学習されたUNetに、画像で表現できるcontrol情報を注入するためのUNetを新しく学習する手法です。 これによって例えば人体の姿勢情報からそれに沿った人物の画像を出力するなどといったことが可能になります。 データセットの分割は先ほどとは異なり、まず全ての活字画像を使ってランダムノイズから活字を生成するモデルを作り、そしてStratified K-Foldで分割された手書き文字画像を使って条件付けモデルを学習させました。 そのため変換過程は以下のようになり、途中からヒントとして手書き文字の特徴量を加える形になります。 まず活字生成モデルは次のようになりました。学習時には上下左右反転のdata augmentationを行っているので向きが変わっていますが、元の活字のスタイルを正しく生成できているようです。 しかし条件付けモデルの結果は以下のように、残念ながら入力した条件に従わせることができず、相変わらずランダムな活字風の画像が生成されてしまいました。 このように条件に従ってくれない現象はControlNetの元論文でも指摘されており、しばらく学習するとちゃんと従うようになるとされているのですが、残念ながらこの実験ではそのような収束が見られませんでした。おそらく一般的な画像生成とは異なり、文字の生成ではあまりに簡単すぎるため手書き文字画像によるヒントがうまく使われなかったのではないかと思います。 手法３：学習済みの活字生成モデルを手法１で転移学習する 手法1ではあらかじめ全ての活字画像を学習時に活用できず、手法2ではうまく手書き文字画像をヒントとして活用できませんでした。そこで、手法2で作成した活字画像生成モデルの重みを手法1の初期値に利用することで、2つの手法の欠点を補ってみます。 結果は次のような画像になりました。一部うまくいった文字もあり（く、詠、円など）、心なしか似たような文字が出せるようにはなったのですが、結局ほとんどは関係のない活字に変換してしまいました。 まとめ 手書き文字を活字に変換するためFlow Matching周りの手法を色々試してみましたが、異なるスタイルの文字を一対一対応させるのはかなり難しそうでした。 GANなどの方がむしろ安定して学習できる可能性もあるため、こちらも試してみたいです。 ETL文字データベース http://etlcdb.db.aist.go.jp ↩ Noto Sans Japanese https://fonts.google.com/noto/specimen/Noto+Sans+JP ↩ conditional-flow-matching https://github.com/atong01/conditional-flow-matching ↩ https://arxiv.org/abs/2302.05543 ↩

イノベーションセンターの新井です。 普段は全社検証網の技術検証、構築、運用を担当しています。 私の所属するイノベーションセンターではこれまではイーサネット/IPレベルの検証網を運用して全社に提供していましたが、昨今の光伝送とIP系技術の融合の進展などにも対応して、さまざまなユースケースを検証・開発するために、光伝送に関する検証網(All Photonics Network Testbed。以下、APNテストベッド)も同一チームで構築・運用しています。 今回から複数回に分けて現在取り組んでいるAPNテストベッドで用いている技術や運用手法を解説していきます。記事内では我々と同じようにイーサネット/IP技術にはある程度詳しいが光伝送技術の知識はそれほどでもない、という方向けに解説します。 本記事のサマリーです。 光伝送ネットワーク(APN:All Photonics Network)の検証網、APNテストベッドについて連載します。 連載1回目の本記事では、光伝送のオープン化の全体像とトランスポンダーにおけるオープン化の進展について紹介します。 特にIP over DWDM関連やホワイトボックストランスポンダーのアーキテクチャーについて解説し、それらを使った運用手法の一端を紹介します。 光伝送ネットワークの概要 光伝送で用いられる機能 光伝送のオープン化 トランスポンダーのアーキテクチャーとIP over DWDM マックスポンダーとL2スイッチの違いについて ネットワークにおける役割分担 400G-ZR/ZR+とIP over DWDM ホワイトボックストランスポンダー L2/L3レイヤーにおけるホワイトボックススイッチの利用の進展 ホワイトボックストランスポンダーへ 専用トランスポンダーかIP over DWDM構成か 運用における知見 APNテストベッドの構成 複数ベンダーシャーシ/トランシーバーの混在運用 gNMIの活用 まとめ 光伝送ネットワークの概要 光伝送ネットワークではROADMやトランスポンダーといった機器が登場します。これらの役割について馴染みのない方もいるかと思いますのではじめに説明します。 光伝送で用いられる機能 長距離光伝送で用いられる機能は一般的にトランスポンダー、WDM(Wavelength Division Multiplexing)、アンプなどで構成されます。 トランスポンダー(Transponder, TRPN) : 一般的なイーサネット信号などのクライアント信号を波長多重可能かつ長距離延伸が可能な光信号へ変換する機能です。クライアント側(端末などが接続される側)からの光信号を一旦電気信号へ変換後、再度光信号へ変換(Optical-Electric-Optical変換)してライン側(他拠点との接続側)と接続します。 WDM(Wavelength Division Multiplexing) : 波長多重を行う機能です。単純化したわかりやすいイメージとしてはプリズムのようなものです。プリズムを通して1本の光線が色（＝波長）の異なる光線に分離するように、異なる波長に情報を載せた光信号を複数まとめた光を生成したり、逆にまとめた光からそれぞれの波長の光信号を分離したりする機能のことです。WDMはその多重度に応じてさらにDWDM(Dense WDM), CWDM(Coarse WDM)などに分類されます。 WSS(Wavelength Selective Switch) : WDM信号を各波長単位で任意の出力へ制御する波長スイッチ機能です。単純化したわかりやすいイメージとしては波長単位で可変的に動く鏡のようなものです。WSSは波長単位で多重化や出力ポート選択を行えるためスイッチ機能とWDM機能を両方実現できます。 アンプ(Amplifier, AMP) : 光信号の強度を増幅する機能です。 ROADMはReconfigurale Optical Add/Drop Multiplexerの略で、WSSを活用することにより波長単位でスイッチ(Add/Drop)することで、Point-to-Point以外の伝送トポロジーを構成することを可能とする装置です。ROADMにより光伝送ネットワークをSDN(Software-defined-Network)的な制御とすることが可能となります。APNテストベッドでも東京を中心としたハブ&スポーク型のトポロジー、一部拠点間ではリング型のトポロジーとなっていますが、このように光伝送のみである程度自由なネットワークトポロジーが作れるのはROADMならではの利点です。 光伝送のオープン化 従来は相互接続性や管理運用の制限によりこれら一連の機能を実現する装置群を単一のベンダーで構築することが一般的でしたが、WDM可能な信号を送信するデジタルコヒーレント 1 トランシーバー(Digital Coherent Optics, 以降DCO)をスイッチ/ルーターに搭載するいわゆるIP over DWDMの構成(後述します)の台頭などもあり、OOLS(Open Optical Line System)と呼ばれる他社製のトランスポンダーとの連携を重視する構成が注目されています。さらにROADMにおいても標準化に関する取り組みであるOpenROADM MSA(Multi-Source Agreement) 2 に基づき装置の機能単位や筐体内接続を分割するDisaggregation構成をとり、トポロジー変更やネットワーク規模の拡大に対応しやすくする構成も利用されています。また、トランスポンダーやスイッチ/ルーターについてもOSとハードウェアを分割するいわゆるホワイトボックス装置も利用されています。 上記の説明を簡略化したイメージ図が下図になります。 APNテストベッドではこれらの内、最下段に記載した構成を主に用いて構築・運用しています。 トランスポンダー ホワイトボックストランスポンダーを主に利用しています。ベンダー固有の専用筐体/OSで構成されるトランスポンダーも利用していますが、その場合はスイッチ/ルーターにも搭載可能な3rd party製の400G-ZR+/100G-ZR DCOなどQSFP型のトランシーバーを採用しています。後述するIP over DWDM構成もトランスポンダーの一種として活用しています。 ROADM OpenROADM MSAに基づいたDisaggregatedな装置を利用しています。ハブ&スポーク型のトポロジーでは多数の拠点への「方路」を構成する必要がありますが、その方路ごとに筐体を用意するクラスター型の構成となっています。 本記事では上記2つの内トランスポンダーにおけるオープン化の進展としてIP over DWDM構成とホワイトボックス化に焦点をあてて解説し、運用で得られた知見も共有します。 ROADMのDisaggregationやOOLS利用における注意点などについては次回以降に掲載する予定です。 トランスポンダーのアーキテクチャーとIP over DWDM トランスポンダーの役割についてIP over DWDM構成と比較しながら改めて説明します。 マックスポンダーとL2スイッチの違いについて 複数のクライアント信号を集約して1波長にまとめて送出するトランスポンダーは多重化のmultiplexer(Mux)と接続した単語で「マックスポンダー(Muxponder)」と呼ばれます。 マックスポンダーと、スイッチ/ルーターは一見似たように「複数の信号を集約して出力する」動作をしますが、実際には制御対象のレイヤが異なります。 トランスポンダー/マックスポンダー(Layer 1, 物理層) 入力ポートと出力ポートを固定的に対応付け、電気⇔光の変換や光信号変換をします。フレーム/パケットの中身は解釈しません。gearboxと呼ばれる機能部位で電気インターフェースを固定的に接続します。 3 → 「線をつなぐ/信号の形を変える」役割 スイッチ/ルーター(Layer 2/3, データリンク層/ネットワーク層) フレーム/パケットを解釈し、MACアドレスやIPアドレスに基づいて転送先を動的に決定します。 → 「データを理解して行き先を決める」役割 ネットワークにおける役割分担 このように従来は異なるレイヤーの装置として役割分担が行われており、一般的なネットワーク構成としては以下のようになっていました。 拠点内(LAN)：スイッチやルーターでパケットを制御 拠点間接続(WAN)：拠点内機器をマックスポンダーに接続し、ROADMやWDMを組み合わせて大容量・長距離伝送 400G-ZR/ZR+とIP over DWDM 従来は「専用のトランスポンダー筐体」で信号を変換し、その先にスイッチ/ルーターを接続していました。しかし近年、QSFP-DDやOSFPといった小型汎用トランシーバーの形状で長距離光伝送を実現するDCOである400G-ZR/ZR+が登場しました。 これにより、スイッチ/ルーターのポートに直接トランスポンダー機能を内蔵できるようになり、専用のトランスポンダーを使わずとも、スイッチ/ルーターから直接WDM装置(ROADMなど)に接続可能となりました。この構成を「IP over DWDM」と呼びます。 従来： スイッチ/ルーター ⇔ トランスポンダー筐体(マックスポンダー) ⇔ ROADMなど IP over DWDM： スイッチ/ルーター(ZR/ZR+モジュール搭載) ⇔ ROADMなど また、400G-ZR/ZR+では、トランシーバーの制御にCMIS(Common Management Interface Specification)を用いています。これは短距離用トランシーバーの管理仕様を拡張したものであり、既存のNetwork OSを大きく変更せずに対応しやすいというメリットがあります。実際に市販されている多くのメーカーの装置で400G-ZR/ZR+を動作させることが可能になっています。このようにスイッチ/ルーター機能とトランスポンダー機能を一筐体で実現できることからDCOを搭載したスイッチ/ルーターをスイッチポンダーという名前で呼ぶ場合もあります。 特に近年では首都圏や関西圏内において、AI関連のインフラ整備やISP/CSPにおける映像伝送トラフィックの増大に伴い、複数のデータセンター間で大容量回線を必要とする動きがみられます。このような背景からネットワーク帯域の多重化と長距離光信号への変換をマックスポンダーではなくIP over DWDMで直接実現する構成も導入が始まっています。 このような構成のバリエーションとして、800G-ZRや100G-ZR DCOなど、さらなる小型・高効率なDCOも登場しています。これにより、IPレイヤと光レイヤの統合が進み、データセンター間の接続構成は省スペース・省電力でよりシンプルに設計できるようになると予想されます。 ホワイトボックストランスポンダー L2/L3レイヤーにおけるホワイトボックススイッチの利用の進展 トランスポンダーのホワイトボックス化について説明する前にスイッチ/ルーターのホワイトボックス化について説明します。 ホワイトボックスとはネットワーク機器においてハードウェアとソフトウェア(Network OS：NOS)を分離して設計・導入できるオープンなアーキテクチャを指します。2025年現在、このホワイトボックスアーキテクチャで広く普及しているNOSが「SONiC」です。SONiCはMicrosoftによって開発され、OCP(Open Compute Project)に移管された後、現在はLinux Foundation傘下でオープンソースとして継続的に開発が進められているLinuxベースのNOSです。SONiCは複数のホワイトボックススイッチベンダーに対応しており、主に大規模なデータセンターネットワークを実現するために、クラウド事業者やデータセンター運用者を中心に採用が進んでいます。 SONiCが備える特徴のうち、後述するホワイトボックストランスポンダーにも共通する点として、以下の2つが挙げられます。 ハードウェア選定の自由度が高い SONiCは複数のハードウェアベンダーの筐体で動作可能なため、目的や要件に応じて最適な機器を選択できます。 オープンな運用手法が活用可能 SONiCはLinuxをベースに開発され動作しており、基本的には既存のリッチなLinux運用手法を活かした管理・自動化が可能です。また、gNMI(gRPC Network Management Interface)によるStreaming Telemetryなど広く用いられるモダンな運用手法との親和性も高く、効率的なネットワーク運用を実現できます。 1のハードウェア選定の自由度向上を実現している方法について少し詳しく説明します。 ネットワークスイッチは、パケットを高速処理するために スイッチASIC(Application Specific Integrated Circuit)と呼ばれる専用チップを用いています。NOSは、このASICを制御する必要がありますが、従来はASICベンダーごとに異なる専用SDK(Software Development Kit)を用いて実装する必要がありました。また、これらのSDKはライセンス契約が必要になるケースも多く、オープンなNOSの開発や移植性において障壁となっていました。 このような状況を改善するために策定されたのが、SAI(Switch Abstraction Interface)です。 SAIはNOSとASIC SDKの間に位置する抽象化された共通APIであり、ASIC固有の仕様を意識することなくOS開発者が共通のインターフェース経由でハードウェアを制御できるように設計されています。SAIは現在もOCPで開発が進められています。 このSAIにより、NOSは特定ベンダーのSDKに依存せず、同一のSAI APIを介して複数のASICで動作可能となり、開発効率が大きく向上し多数のハードウェアでの動作を行えるようになりました。SONiCもこのSAIを利用してスイッチASICを制御しており、多数のホワイトボックス筐体とともに利用できます。 ホワイトボックストランスポンダーへ ホワイトボックストランスポンダーも基本的にはホワイトボックススイッチの特徴を引き継いでいます。 ホワイトボックストランスポンダーの開発において主たる役割を果たしてきたのはNTTを含めて多数の事業者が参画する Telecom Infra Project (TIP)です。TIPはOCPなどで成功したOpenなコンピューティングの取り組みを通信事業者においても実現できないか目指している団体ともいえます。 ホワイトボックストランスポンダーでオープンなアーキテクチャの実現に貢献している仕組みがTAI(Transponder Abstraction Interface)です。TAIは前述したSAIの光伝送版ともいえるものです。SAIがスイッチASICの制御を抽象化するAPIであるのに対してTAIはその名の通りトランスポンダーに必要な光伝送の部品を抽象化します。 API 主対象 利用領域 開発体制 SAI スイッチASIC スイッチ/ルーター OCP TAI トランスポンダー 光伝送 TIP TIPではこのTAIを活用したNOSであるGoldstone OSの仕様とリファレンス実装を開発し、我々が現在APNテストベッドで活用しているトランスポンダーのOSもこのGoldstone OSを元にした製品です。 さらにSONiCがdockerコンテナとして各機能を実装している構成であるのと類似して、下記のようにkubernetesのpodとして各機能が実装されており、ユーザーからも中身が理解しやすいものとなっています。 $ kubectl get pod NAME READY STATUS RESTARTS AGE north-noscmd-9vxkx 1/1 Running 0 68d tai1-2-54cf969f6b-rhtz2 1/1 Running 0 68d tai2-1-68b48b6c54-jtc42 1/1 Running 0 68d tai2-2-5868f89fdb-zrmmh 1/1 Running 0 68d tai1-1-5774878878-kr59b 1/1 Running 0 68d redis-xcvrd-8lcrf 1/1 Running 0 68d prep-xcvrd-2hx2f 0/1 Completed 0 68d xcvrd-2vgps 1/1 Running 0 68d config-mgmt-ndtmp 1/1 Running 0 68d line-protection-hgvnh 1/1 Running 0 68d redis-cache-k22gt 1/1 Running 0 68d oc-terminal-device-p7bpc 1/1 Running 0 68d oc-interfaces-f9rcs 1/1 Running 0 68d oc-macsec-r8mxd 1/1 Running 0 68d collector-as-qmxqx 1/1 Running 0 68d collector-as-tai-xnmmg 1/1 Running 0 68d collector-pm-qnsns 1/1 Running 0 68d collector-inventory-6vm2t 1/1 Running 0 68d alarm-z96sp 1/1 Running 0 68d oc-platform-vp86h 1/1 Running 0 68d perfmon-4l67b 1/1 Running 0 68d north-netconf-bh6zj 1/1 Running 0 68d redis-ztp 1/1 Running 0 68d xlate-telemetry-5bz22 1/1 Running 0 68d north-gnmi-tnxk9 1/1 Running 0 68d tai-gearbox2-1-779cf9d6d-q2s2j 1/1 Running 1 (68d ago) 68d ztp 1/1 Running 0 68d tai-gearbox1-1-fdfc7d6cd-mtkhk 1/1 Running 1 (64d ago) 68d また、Goldstone OSやその派生OSにおいても、SONiCなどスイッチOSと同じようにONIE(Open Network Install Environment)というインストール環境を利用でき、OSのインストール等が容易になっています。 専用トランスポンダーかIP over DWDM構成か DCOというプラガブルモジュールを用いたIP over DWDM構成と専用トランスポンダーのホワイトボックス化を説明しました。さらに、市場には説明した2種類以外にも400G-ZR/ZR+等を用いつつスイッチ/ルーター機能を排することで専用トランスポンダーでありながら価格を低減したモデルなども存在しており、現在ではトランポンダー機能のあり方が多様になってきています。そのためネットワーク設計者は光伝送分野だけではなくIP/イーサネットレイヤーも含めた最適なアーキテクチャーを再検討する必要があります。 一般論としては下記のような比較ができますが、APNテストベッドでは複数のトランスポンダー構成を用いて、単純なコスト比較のみならず実際に検証・運用し、さまざまな観点から比較をしています。 専用トランスポンダー(ホワイトボックス含む) IP over DWDM(L2/L3機器と400G-ZR/ZR+などの組み合わせ) フォームファクター CFP2などの大型トランシーバーもしくはラインカード(内蔵型)が多い QSFPやOSFPなどの小型トランシーバー 制御API ホワイトボックス装置のTAIは光機能を詳細に抽象化可能 CMISは簡易な制御 伝送距離 長距離にも対応 メトロエリア(数100km以内)程度がメイン 光パラメーターの最適化 細かいチューニングが可能 固定的な部分が多い ライフサイクル スイッチ/ルーターに比べれば長期 上位レイヤーも含めた多機能が求められるためバージョンアップの必要可能性が比較的高い 運用体制 伝送レイヤーとL2/L3レイヤーの運用者の既存のすみ分けが流用可能 イーサネット/IPと伝送の両方の知見が必要なため新たな体制や運用ツールが必要な可能性がある 運用における知見 APNテストベッドの構成 APNテストベッドでは冒頭説明した通り、ROADMを用いてハブ&スポーク型とリング型を組み合わせたトポロジーのネットワークを構築し、そこにこれまで説明した多彩なトランスポンダーを接続しています。 過去には単一ベンダーで光伝送システムを構成するのが一般的だったため、このような異ベンダーのトランスポンダーからの光波長を区別するため「エイリアン波長」と呼んでいる場合もありますが、我々のAPNテストベッドでは一般的な仕様としています。 複数ベンダーシャーシ/トランシーバーの混在運用 我々のホワイトボックストランスポンダーの運用においては、そのオープン性を活かし、複数ベンダー製のシャーシに共通のOSを搭載させています。これまでに3社のハードウェアを導入してきましたが、いずれも大きなトラブルはなく、安定した運用が可能であることを確認しています。 一方で、トランシーバーに関してはベンダー間の相互接続性が課題となる場合もありました。 とくにCFP2形状のDCOについては、光パラメータの細かな調整が可能である一方、異なるベンダー間で接続できないケースが確認されました。実際に、全く通信ができない組み合わせも存在しており、注意が必要です。 これに対してIP over DWDM構成でよく用いられる400G-ZR/ZR+トランシーバーはCMISによる標準インターフェースの普及や仕様の成熟により、初期の一部例外を除いて現在ではほぼ全てのベンダー間で安定した動作が確認できています。 長距離伝送を可能とするDCOは、DSP(Digital Signal Processor)などの信号処理に必要な部品が短距離用トランシーバーよりも一般に高消費電力・高発熱・高体積となり、シャーシ毎に物理的な搭載制約を伴うことがあります。 使用する際は事前に筐体の制限を十分に確認し、実際に搭載して試験するとともに、搭載位置の設計を慎重に検討する必要があります。 以上を踏まえると、オープンな光伝送環境においても適切なトランシーバー選定とパラメータ調整、設計により十分な互換性と運用性を確保できることが示されており、マルチベンダー環境であってもオープンな光伝送の利点を享受することは現実的かつ有効な選択肢といえます。 gNMIの活用 APNテストベッドでは、トランスポンダーの状態監視や可視化にgNMIを活用しています。gNMIは、OpenConfig 4 が策定したオープンなネットワーク管理プロトコルであり、ベンダー依存のSNMPやCLIベースの取得手法に比べ、構造化されたデータを効率的かつリアルタイムに収集できる点が大きな特長です。詳しくは当ブログの以前の記事「 次世代の監視技術 - Telemetry技術のご紹介 - NTT docomo Business Engineers' Blog 」もご確認ください。 監視構成では、gNMIクライアントに gnmic を活用し、複数の機器からストリーム形式でOpenConfigベースのメトリクス(光パワーレベル、エラーレート、SNR:Signal Noise ratioなど)を秒単位で連続取得しています。gnmicはGoogle Cloud上のGKEにデプロイし、オンプレミスのネットワークから自社サービスであるFIC(Flexible InterConnect)を通してメトリクスを取得しています。取得データはPrometheus形式に変換することでGoogle Cloud Monitoringに連携、さらにPrometheus/Grafana連携によりダッシュボードでリアルタイム表示・履歴管理・アラート通知まで対応しています。 gNMIを活用した我々の監視構成では以下のようなメリットが生まれています。 機器追加時にはKubernetesのConfigMapであるYAMLファイルを1つ編集するだけで監視対象に追加可能 YAMLファイルはGitHub上で管理しておりそれを書き換えるだけで機器追加に対応できています。 光学パラメーターの劣化をリアルタイムに検知し、障害予兆に即応可能 ラベル付きの時系列データを標準的なフォーマットで取得できるため、既存のツールが活用しやすく、障害の分析や予測に役立てることができます。 エージェントレスで通信でき、ベンダー固有の監視ソフトが不要 まとめ 本記事では光伝送ネットワークのオープン化について概観し、特にIP over DWDM構成とホワイトボックストランスポンダーにおけるアーキテクチャーと実際の運用上の知見を紹介しました。次回以降は光波長自体を伝送するROADMによるネットワークについて紹介する予定です。 光の強度のみならず波としての性質(位相など)にも情報をのせて伝送する技術。デジタルコヒーレントはその信号情報処理に専用半導体(DSP:Digital Signal Proc­es­sor)を用いています。微細加工技術の進展により小型化・省電力化が進んでいます。 ↩ OpenROADM MSA(Multi-Source Agreement)は光伝送の特にROADM網において複数のベンダーで相互接続が可能とするため、物理的な光インターフェースの仕様やAPI、装置のアーキテクチャーを規定しています。詳しくは次回以降の連載や 公式Webサイト を参照ください。 ↩ OTN(Optical Transport Network)スイッチという光のフレーム情報でスイッチングする方式も存在します。 ↩ ネットワーク機器のAPIをマルチベンダーで共通的に提供できるようにすることを目的とした取り組み。 OpenConfig ↩

こんにちは、イノベーションセンターの二瓶・神田です。 ドコモグループ（NTTドコモ・NTTドコモビジネス）はゴールドスポンサーとして、2025年8月2日に開催された第3回 セキュリティ若手の会に協賛しました。 この記事では、スポンサーの立場から見た当日の様子やスポンサー講演の内容について紹介します。 はじめに：セキュリティ若手の会について 公式イベント開催記 当日の様子 LLMセキュリティの攻防入門 〜ガバナンスと脅威対策〜 オフェンシブセキュリティ入門 ～攻撃者目線でセキュリティ対策を考えよう～ NTTドコモビジネスの業務紹介 おわりに お知らせ 第4回 セキュリティ若手の会（LT&交流会） Tech Workshop はじめに：セキュリティ若手の会について 「 セキュリティ若手の会 」は、将来セキュリティエンジニアを目指す学生や、セキュリティ業務に携わる若手エンジニアのためのコミュニティとして2024年に設立されました。 15歳以上の学生から新卒3年目の社会人までが参加可能となっており、今回の第3回イベントを含めて、これまでに3回のオフラインイベントを企画、主催しています。 公式イベント開催記 このコミュニティの特徴の一つは、創設メンバー自身も若手エンジニアであることです。 当事者として抱える課題感や、課題解消に向けて自ら動く姿、その思いに強く共感し、ドコモグループは第3回のイベントスポンサーに名乗りをあげました。 1 スポンサーをするにあたってはドコモグループ採用担当とも連携し、イベント当日には採用担当も参加して広く事業内容やセキュリティエンジニアの採用についても紹介しました。 当日の様子 第3回イベントはそれまでの2回とは異なり、初めてワークショップ形式で開催されました。 ワークショップの概要や会場の様子などは公式の イベント開催記 にも掲載されているので、ここでは若手“ではない”社員の視点から見たワークショップの印象を紹介します。 LLMセキュリティの攻防入門 〜ガバナンスと脅威対策〜 1つめのコンテンツは、生成AI（LLM: Large Language Model）のセキュリティに関する講義とハンズオンがセットになったワークショップでした。 セキュリティ若手の会幹事のお二人が自ら講師を務め、生成AIの業務利用に潜む脅威について実体験を通じて学びました。 具体的な内容は参加者限りのため詳細は割愛しますが、講義パート、ハンズオンパートはいずれも「若手」の域を超えた内容でした。 事業会社に勤める立場から見ても、生成AIを使う全従業員にぜひ押さえておいてもらいたいポイントが随所に散りばめられていました。 特に利用規約・ガイドラインの読み解き方や生成AIを利用する際の情報漏洩リスクの実例は、事業会社でセキュリティポリシーを策定する立場の方々にとっても有益な情報が多かったです。 オフェンシブセキュリティ入門 ～攻撃者目線でセキュリティ対策を考えよう～ 2つめのコンテンツは、ドコモグループのグループ会社でもあるエヌ・エフ・ラボラトリーズ（以下、NFLabs.）によるハンズオンでした。 NFLabs.が開発した実践型サイバーセキュリティ学習プラットフォーム Purple Flair を用いて、攻撃者の立場でシステム攻略にチャレンジしました。 特に印象的だったのは、攻撃してみて終わりにせずに、そのあとに考察させるパートでした。 「攻撃者としての活動が防御側からはどう見えるのか」、「攻撃者として苦労したポイントがセキュリティ対策の観点でどういった意味を持つのか」。攻撃者の視点から一転して防御する側の視点に転換させる問いかけには考えさせられた参加者も多かったように見えました。 この視点の転換は効果的・効率的な防御の構築につながる重要な思考で、とてもよい気づきにつながっていると感じました。 NTTドコモビジネスの業務紹介 スポンサー講演パートでは、NTTドコモビジネス（旧：NTTコミュニケーションズ）におけるセキュリティエンジニアの働き方を紹介しました。 少し学生時代も振り返りながら、私（二瓶）が所属する「イノベーションセンター テクノロジー部門 Offensive Securityプロジェクト」での業務の概要、部署の説明や実際にどんな業務を担当しているのか、ステークホルダーとの調整に関する苦労話などを紹介しました。 熱心に聞き入る参加者も多く、アンケートでも「話が面白かった」「学生のうちから色々な技術で遊びたいと思った」などの意見をいただけて嬉しかったです。 当日には紹介しきれませんでしたが、NTTドコモビジネス エンジニアブログでは、今回紹介したオフェンシブセキュリティの業務以外にもセキュリティ業務やそこでの成果を情報発信しています。 毎年開催されている現場受け入れ型インターンシップの体験記も多数掲載されていますので、NTTドコモビジネスのセキュリティ業務に興味を持たれた方はそちらもぜひご覧ください。 （今年の体験記もこれから随時公開される予定です。お楽しみに。） おわりに ドコモグループ（NTTドコモ・NTTドコモビジネス）は、セキュリティ若手の会の活動に賛同し、ゴールドスポンサーとして第3回 セキュリティ若手の会の開催を支援しました。 これからも若手の活躍を応援し、ともにセキュリティコミュニティを盛り上げていきたいと考えています。 お知らせ 第4回 セキュリティ若手の会（LT&交流会） すでに募集が始まっており、締め切りは10月31日、開催日は11月16日です。 興味を持たれた方は参加を検討してみてはいかがでしょうか。 参加資格は、15歳以上の学生もしくは新卒1〜3年目の社会人です。 Tech Workshop ドコモグループでは、セキュリティ・ネットワーク・クラウドについてハンズオン形式で学ぶことができる1dayのワークショップ「Tech Workshop」を開催しており、現在11月開催分について参加者を募集しています。 セキュリティについては、今回2種類のワークショップが用意されています。 ドコモグループのセキュリティ業務とフィッシングサイトの仕組みを学ぶ （11月9日開催） Purple Flair で学ぶ実践型サイバーセキュリティ（11月15日開催） いずれも締め切りは10月19日です。 エントリーお待ちしています。 コミュニティ立ち上げにあたっての創設メンバーの思いは 公式ブログ でも紹介されているのでぜひそちらもご覧ください。 ↩

はじめに みなさん、こんにちは。イノベーションセンター IOWN推進室の工藤です。 IOWN推進室では、IOWN APNを体験できる基盤の整備を進めており、その構築や運用などを担当しています。 先日開催されたInterop Tokyo 2025（会場：幕張メッセ、会期：2025年6月11日〜13日）のNTT ドコモビジネスのブースでは、IOWNを利用した「ハイブリッドトラベル」をはじめとする未来の体験を展示し、多くの方にお立ち寄りいただきました。（ブースの展示内容については こちらのニュースリリース をご覧ください） 一方で、ブースでの展示とは別に、イベント全体の通信を支える大規模な実証実験ネットワーク「ShowNet」へIOWN APN技術を提供しておりました。 ShowNetでは、全国の放送局から送られる映像をIOWN APN経由で伝送するといった先進的な取り組みも行われました。この映像伝送のアーキテクチャについては、別チームが こちらの記事 で詳しく解説しています。 本記事では、その映像伝送をはじめとする数々の先進的な試みを根底から支えた「 IOWN APN 」そのものに焦点を当てます。 1.2Tbpsの大容量・低遅延・低ジッタの特徴を活かした多様なユースケースや、設計構築する上でのポイントやトラブル対応をご紹介します。 はじめに ShowNetとは IOWN APNの提供概要 IOWN APNを構成するネットワーク 多様なユースケースでの活用 Media over IP 大手IX・学術ネットワークとの接続 サービスの安定基盤としての活用 ブースでの活用 設計構築のポイントやトラブル対応 設計構築上でのポイント ポイント①：光の特性を考慮した波長設計 ポイント②： ROADMの操作性 ポイント③：ファイバー接続前の光の確認 トラブルシューティング事例 事例①：原因不明のCRCエラー 事例②：Hotstage期間中にOpticsが故障 まとめ ShowNetとは ShowNetとは、Interopの会期中だけ出現する、巨大な実証実験ネットワークです。ボランティアで集ったトップエンジニア達が、各社から提供された最新機器を相互接続し、実際に稼働させることで、この巨大なライブネットワークを構築・運用しています。 IOWN APNの提供概要 NTTドコモビジネスは今年、ShowNetの「External」と呼ばれる外部接続部分に「大容量・低遅延・低ジッタ」という特徴を持つIOWN APNを合計7波長（1.2Tbps）提供しました。 （ShowNet エクスターナル図 (PDF)） IOWN APNを構成するネットワーク 今年のIOWN APNは、都内にハブ拠点を設けて、東は千葉のビルを経由し幕張メッセへ、西は大阪のビルへと接続する広大なネットワークを構築しました。さらに各拠点から、五反田、お台場、QUINTBRIDGEなど、デモやサービス提供に必要な拠点へと延伸しています。 この構成における主要区間の実測遅延値は、東京–大阪間で片道4.2ms、東京–幕張メッセ間で片道0.3msでした。 また、このネットワークでは、NTTドコモビジネスの商用サービス「APN専用線プラン powered by IOWN」を、「東京–大阪間の接続」と「千葉のビルにおけるOCNとの直接接続回線」で実際に活用しています。 APN-T (Open APN Transceiver): 波長パスの終端点で、波長の送受信を行うインターフェイスを表す。 APN-G (Open APN Gateway): APN-Tの光を伝送網へ導入するためのゲートウェイ。APN-Tの制御、APN-Tの信号の多重/分離・折り返し・add/dropなどの機能を有する。 APN-I (Open APN Interchange): 光パスの途中で波長スイッチングのための中継装置。増幅なども行う。 DWDM (Dense Wavelength Division Multiplexing, 高密度波長分割多重) 区間: APN-GやAPN-Iといった装置間を接続し、1本の光ファイバーで複数の異なる波長の光を同時に送受信する伝送路。 なお、APN-T、APN-G、APN-Iに関して詳しくは以下をご参照ください。 参照先：IOWN Global Forumにおけるオープンオールフォトニクス・ネットワークの検討 多様なユースケースでの活用 提供したIOWN APNは、以下のような多様なユースケースで活用されました。 Media over IP 東京と大阪の放送局が映像・音声リソースをIP網で共有し合う「ShowNet Media-X」という、放送業界の未来に向けた試みが実施されました。IOWN APNは、東京と大阪の合計3つの放送局の各スタジオから幕張メッセまでを結ぶ高品質な長距離伝送路を提供し、この壮大なリモートプロダクションの実現に貢献しました。 （ ShowNet Media over IP特別企画 より引用） 大手IX・学術ネットワークとの接続 ShowNetにおいてさまざまな実証実験を行うために、ShowNetを日本のインターネット基盤そのものと接続する必要がありました。IOWN APNは、このShowNetの生命線ともいえる接続路として、複数のIX (Internet eXchange) と接続し、安定した通信を提供しました。 サービスの安定基盤としての活用 ShowNetでは、NTTドコモビジネスが商用提供する主要サービスの通信基盤としてもIOWN APNを活用しました。 例えば、企業のクラウド接続を担う「Flexible InterConnect」、リアルタイム性が求められる音声コミュニケーションを支える「docomo business RINK」、そして社会インフラであるインターネット接続サービス「OCN」など、特性の異なる複数のサービスの通信をIOWN APN上で同時に提供しました。これにより、IOWN APNが、多様な要件を持つサービスを安定して支えられることを実証しました。 ブースでの活用 IOWN APNは、NTTドコモビジネスのブース展示にも活用しました。大阪・お台場・五反田といった遠隔拠点と幕張メッセをAPNにて結ぶことでデモンストレーションを実現しました。 設計構築のポイントやトラブル対応 設計構築上でのポイント ポイント①：光の特性を考慮した波長設計 光ファイバーには種類があり、種類によって特性が異なります。例えば、日本で従来から長距離光伝送で多く使われているDSFという光ファイバーは、1550nm付近の波長で分散がゼロになる特性があります。今回は、四光波混合といった非線形効果の影響を減らすため、この波長帯を避けるといった考慮も行いました。 その他、いくつか設計にあたり検討すべきポイントがあります。OSNR（光信号対雑音比）を事前に測定して通信速度と変調方式を適切な設定にすることや、適切なグリッド幅に設定することなどが挙げられます。 ポイント②： ROADMの操作性 APN-I/GにあたるROADM装置はOpenROADMという標準規格に準拠したAPIへ対応しはじめていますが、現時点では多くの場合ベンダー固有のコントローラからの操作が前提となります。今回もベンダー製のコントローラを用いて、APN装置を操作し、各拠点間の光パスを設定しました。 ポイント③：ファイバー接続前の光の確認 伝送装置の接続においても、通常の光ファイバーを用いるケースと同様に、2芯の光ファイバーの送信と受信を対向拠点の機器同士で確認することが重要となります。今回は事前に片側を接続し、パワーメータなどで光レベルを確認した上で接続しました。 また、光は弱すぎても届きませんが、逆に強すぎても受信側の装置が故障したり、通信が不安定になったりします。実測値が想定より強い場合は、アッテネータ（減衰器）を入れて適切な光量に調整します。 トラブルシューティング事例 InteropへのIOWN APN提供は今年で3年目になり、今回はついに設定関連のトラブル"ゼロ"を達成しました。 しかし、物理的な障害は決してゼロにはなりません。実際に発生した、代表的な2つの事例をご紹介します。 事例①：原因不明のCRCエラー 特定の接続先から「CRCエラーが散発的に発生する」という申告がありました。100G-LR4にて接続していましたが、IOWN APNのクライアントとして低遅延を追求するため、意図的にFEC (Forward Error Correction、前方誤り訂正) をoffの状態で運用していました。設定上は問題が見当たらなかったため、光コネクタの微細な汚れの可能性を疑い、改めて関連する接続箇所を全て専用クリーナーで再清掃しました。汚れによる僅かな信号品質（BER）の劣化が原因と推測され、物理層の丁寧なクリーニングが重要であることを再認識する事例となりました。 事例②：Hotstage期間中にOpticsが故障 本番稼働前の準備期間であるHotstage期間中に、APN-Tに搭載していたCFP2-DCOというOptics（光送受信モジュール）が故障する事態が発生しました。運悪く担当者が現地にいないタイミングだったため、予備物品を持って幕張メッセまで駆けつけて交換対応することで、ShowNetの会期に影響を与えることなく乗り切りました。 まとめ 今年のInterop Tokyo 2025において、IOWN APNはShowNetの外部接続回線として、合計7波長・1.2Tbpsを提供し、多様なユースケースを安定的に支えました。 放送局間の映像伝送（Media over IP）、主要IXや学術ネットワークとの接続、さらにはNTTドコモビジネスの商用サービスやブースの遠隔デモまで、「大容量・低遅延・低ジッタ」という特性を活かした幅広い活用が実現されています。「APN専用線プラン」といった商用サービスが出ていることも含めて、IOWN APNがコンセプトの段階を越え、お客さまへ提供できる実用的な技術であることを証明する重要な機会となりました。

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

はじめに こんにちは、NTTドコモビジネスの 現場受け入れ型インターンシップ で「脅威インテリジェンスを生成・活用するセキュリティエンジニア/アナリスト」として参加させていただきました、大学院1年生の脇本です。 このたびインターンシップを通してさまざまな経験をさせていただきましたので、その中でも特に印象的であった「Telegramチャンネルおよびグループの調査・分析」という内容を本記事で紹介させていただきたいと思います。 はじめに 参加したチーム インターンシップ参加経緯 インターンシップ概要 Telegramを使った犯罪者コミュニティの調査/分析 前提 そもそも、Telegramとは? 調査/分析したTelegramチャンネル、グループの概要 調査/分析結果 調査/分析過程 1. グループ名やグループの投稿で頻繁に目にする単語の調査/分析 2. 販売されているクレジットカード情報入手手口の調査/分析 3. 他の投稿に関する調査 4. グループの概要欄についての分析 5. グループ内でのAの立場に関する調査/分析 6. Aの行っている"ビジネス"に関する調査/分析 インターンシップを通して学んだこと・感じたこと おわりに 参加したチーム 私がインターンシップ中に参加させていただいたのは「 Network Analytics for Security (通称: NA4Sec )」と呼ばれるプロジェクトチームでした。「NTTはインターネットを安心、安全にする社会的責務がある」を理念に攻撃インフラの解明や撲滅に向けて活動しているチームです。 過去には「Botconf 2025」というフランスのセキュリティカンファレンスなどでも登壇されている、すごいチームです。 1 インターンシップ参加経緯 私は大学でセキュリティを専攻するよりも前から世界史、その中でも欧州史に強い興味を持っていました。とはいえ特に興味のある時代は現代とは少し遠い(中世盛紀/後期)のですが、歴史とは連続性を持っておりますので他の時代についても興味があり、その延長として現代の世界情勢にも関心がありました。そのため以前から、世界情勢と直結しているともいえる脅威インテリジェンス分野には非常に強く惹かれていました。 そして去年、インターンシップを経験された方からNTTドコモビジネスのインターンシップをご紹介いただき、過去のインターンシップ体験記なども見て、参加を希望しました。 インターンシップ概要 インターンシップは2週間かけておこなわれ、1週目と2週目では異なる活動に取り組みました。 1週目: Cobalt Strike の調査/分析・ハンズオン 2 フィッシングサイトに関する調査/分析・ハンズオン 3 2週目: Telegram を使った犯罪者コミュニティの調査/分析 本記事では1週目の内容を割愛し、2週目に行った[ Telegram を使った犯罪者コミュニティの調査/分析 ]フェーズのうち特に印象的であったグループに関するものについて紹介させていただきます。 Telegramを使った犯罪者コミュニティの調査/分析 前提 今回のインターンシップでは、 Telegram上で活動している犯罪者とは交流しない との前提の下で調査および分析に取り組みました。 そもそも、Telegramとは? 本記事を見ている方の中には、そもそもTelegramという単語に聞き覚えのない方や、ニュースなどで耳にしてなんとなく怖いツールというイメージを抱いている方もいらっしゃると思います。 TelegramとはLINEやWhatsApp、Messengerなどと同様の機能を提供するメッセンジャーアプリです。そのためTelegram自体に問題があるわけではありません。 ただし以下に挙げるような特徴を有していることから、サイバー攻撃者や詐欺師等の犯罪者による悪用が確認されているのが実情です。 シークレットチャットと呼ばれる機能を使用することで利用者間通信が高い機密性と秘匿性を有する 無料で利用可能 またTelegramには個人間チャットのほかにグループチャットやチャンネルと呼ばれる機能があります。 グループチャットは最大20万人が加入できるチャット機能で、メッセージやメンバーを外部から閲覧可能なパブリックグループと、外部からは秘匿されたプライベートグループの2種類が存在します。 チャンネルは作成者と管理者のみが一方的にコンテンツを投稿できる機能で、他のユーザはフォローまたはフォロー解除ができます。こちらもグループと同様にパブリックチャンネルとプライベートチャンネルが存在します。 今回のインターンシップでは主に、パブリックグループやパブリックチャンネルについて調査/分析しました。 調査/分析したTelegramチャンネル、グループの概要 今回のインターンシップで調査/分析したTelegramチャンネルやグループは以下の3つです。 窃取された認証情報を販売しているチャンネル 犯罪系の雑談グループ 何らかの犯罪に関連するグループ 「 何らかの犯罪に関連するグループ 」について情報が曖昧なのは、私がこのグループの調査/分析を開始した際にメンターの方から渡していただいた情報がこのくらいの粒度であったためです。今後本記事ではこのグループに関する調査/分析の結果や過程について掘り下げていきます。 調査/分析結果 グループの調査/分析過程を紹介するより先に、調査/分析によって判明した結論を示します。 グループでは特定の言語が使用されている グループはクレジットカード情報を窃取している人たちが交流するためのもの 販売されているクレジットカード情報の一部はフィッシングによって窃取されたもの グループ参加者の中には他の犯罪を行っている人もいる グループの作成者、またはそれに準ずるグループの中核を担う人物(以下Aと呼称)が存在する Aはクレジットカード情報に関する独自の犯罪ビジネスを複数展開している 調査/分析過程 調査開始時に「何らかの犯罪に関連するグループチャット」のリンクを渡され、自由に調査/分析しました。 行った分析の多くは、投稿に使用されている隠語との戦いでした。グループ内では主に日本語以外の特定言語でやり取りが行われていたため、隠語の調査には骨が折れました。 調査/分析の過程は以下の通りです。 1. グループ名やグループの投稿で頻繁に目にする単語の調査/分析 初めに目を付けたのは、グループ名の一部で使用されており、さまざまな人の投稿でも頻出していたとある単語です。調査の結果、この語は クレジットカード情報 を指す隠語であることが分かりました。また投稿内容の一部には販売を示唆するものもあり、はじめクレジットカード情報の販売が行われているグループではないかと推測しました。 2. 販売されているクレジットカード情報入手手口の調査/分析 クレジットカード情報の販売を示唆する投稿をより詳しく調査したところ、 フィッシング を意味する隠語がいくつも確認されました。そのため、販売されているクレジットカード情報はフィッシングによって入手されたものだと分析しました。なお投稿について日本のクレジットカード情報販売を示唆するようなものも複数見つかりました。 3. 他の投稿に関する調査 グループに投稿されている他の投稿について調査したところ、クレジットカード情報の販売以外に関する投稿も複数確認されました。中には高収入を謳う謎の仕事の募集や、暗号通貨等の投資への誘導、メールアドレスやパスワードに関するファイル名を冠した謎のツールを配布しているものもありました。 この点や、グループ名に何かの交流を意味するような語が使用されていた点などから、このグループはただのクレジットカード情報販売グループではなく、 クレジットカード情報に関する犯罪者たちの交流場 としての役割を果たしていると分析しました。 4. グループの概要欄についての分析 次にグループの概要欄を確認したところ、概要欄には2種類の非常に類似したURLが貼り付けられていました。 URLの片方はグループのリンクで、もう片方はとあるユーザAが運営しているチャンネルのリンクでした。 そこで私はグループに関する調査/分析を終了し、「A」と「Aのチャンネル」の調査/分析を始めました。 5. グループ内でのAの立場に関する調査/分析 Aのチャンネルに関する調査から、グループとAには以下の類似性が確認できました。 AのチャンネルのURLとグループのURLが酷似している Aの名前の一部がグループ名の一部と重複している グループ内でのAの投稿の一部がピン止めされており、他の人物の投稿は1つもピン止めされていない Aのチャンネルは過去に名称を変更しており、変更前に使用されていた名称の一部がグループの説明にも使用されている 以上の点から、 Aはグループの設立者 か、そうでなくとも グループの中核を担っている人物 と分析しました。 6. Aの行っている"ビジネス"に関する調査/分析 Aはチャンネル上でいくつかのユーザをメンションしており、それらのユーザの一部はユーザ情報の概要欄にてAを紹介していました。それらの情報と、グループの概要欄にて示されていたAの紹介文、Aのチャンネル名などを総合的に評価した結果、Aはクレジットカード情報を使った 複数の犯罪ビジネス を展開していると分析しました。 なお分析に使用したユーザ、グループ、チャンネルの概要欄や名前には隠語が多く使用されていたため、このフェーズが最も大変でした。 インターンシップを通して学んだこと・感じたこと 今回のインターンシップでいくつかのTelegramチャンネルを調査/分析させていただき、犯罪者のエコシステムについて大きく3つを学びました。 犯罪者たちは調査を逃れるため、隠語を多用する そのため本格的に調査/分析する場合は隠語の知識が必須となる 1つの単語に対していくつもの隠語があるケースもある 隠語の理解には犯罪と関連するもの(e.g.クレジットカード)についての深い知識が必要となることもある 認証情報やクレジットカード情報に関する犯罪のマネタイズにはさまざまな手法がある 最近ではサブスク形式のマネタイズが多く見られ、サブスクの波が犯罪者界隈にも到来していると感じた 犯罪者コミュニティでの支払い手段は取引の匿名性のほかに、価値の変動の小ささや取引手数料などが重視されている また調査中に「販売されている情報を入手できれば被害者に被害を通知できるのに」という気持ちと、「犯罪者に金銭を提供してはいけない」という気持ちが芽生えたことで倫理面での葛藤を覚え、実際のセキュリティ現場でのジレンマのようなものを感じられたような気がします。 おわりに 実は私は、これまでもセキュリティニュースなどを見てTelegramチャンネルやグループの分析をやってみたいと思ったことが何回もありました。 しかし毎回調査時にミスしてしまったときのリスクを考えてしまって二の足を踏み、後回しにしてしまっていました。 そのため今回のインターンシップで実際にTelegramチャンネルやグループの調査/分析をさせていただけた経験は、非常に有意義なものになったと感じています。 今後は恐れず、ただしリスクも十分に考えて、しっかりとした倫理観も保ちつつこのような分野の調査/分析をしていきたいと思います。 また本記事で紹介したTelegramチャンネルの分析以外の体験でも、非常に興味深く面白い経験をさせていただいたと感じています。 特にCobalt Strikeに関する経験はなかなか他でできないもので、最近あまり手を動かして技術に触れられていなかったこともあり、とても楽しく過ごさせていただきました。 さらにインターンシップ中いくつかのイベントにも参加させていただき、NA4Secチームやほかのチーム、ほかのインターン生といった多くの方々と交流できました。 そこで得られた価値観やセキュリティに対する姿勢は私にとって強い刺激となり、今後見習いたいと感じました。 インターンシップの間、私に関わってくださった皆さま、本当にありがとうございました。 特に神田さん、益本さんにつきましては、2週間ずっとお世話になりっぱなしでした。 改めてありがとうございました。 「 セキュリティカンファレンス「Botconf 2025」に登壇してきた話 」にて、BotConf 2025での登壇に関するお話が掲載されています ↩ Cobalt Strike の調査/分析・ハンズオンで体験した内容の一部は、過去にインターンシップに参加された方が「 インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜 」にて紹介されています ↩ フィッシングサイトに関する調査/分析・ハンズオンで体験した内容の一部は、過去にインターンシップに参加された方が「 攻撃者はいかにしてフィッシングサイトを隠すか？（インターンシップ体験記） 」や「 フィッシングキットから生成されたサイトの調査 (インターンシップ体験記) 」にて紹介されています ↩

こんにちは、イノベーションセンターの加藤・岡本です。普段はコンピュータビジョンの技術開発やAI/MLシステムの検証に取り組んでいます。7月29日から8月1日にかけて、国内のセンシング技術や画像処理関連の主要な学会である MIRU（画像の認識・理解シンポジウム） が開催され、NTTドコモビジネスからはポスター発表で参加しました。本稿ではMIRU2025で気になった発表をいくつか紹介したいと思います。 MIRU2025概要 特殊な光学機器を用いた研究 1. イベントカメラを用いた可視光通信の高速化 (兵庫県立大学) 2. 符号化環境照明を用いた民生用カメラ撮影に対する情報埋め込みの実現 (大阪大学、York University) 3. 光飛行時間の直接計測による関与媒体に対して頑健な振動計測 (兵庫県立大学) 画像認識・VLMのロバスト化と評価 1. 不均衡なデータセットの継続学習における勾配一貫性正規化と動的な知識蒸留 (名城大学) 2. Unleahing the Potential of Complementary Spaces in Group Robust Classification (東京理科大学) 3. VELA: LLM-Hybrid-as-a-judgeにもとづく長文画像キャプション向け自動評価尺度 (慶應義塾大学) 最後に MIRU2025概要 MIRUはコンピュータビジョンや画像映像の認識と理解技術に関する国内最大規模の会議です。2020年ごろから年100件のペースで発表件数が増えており、今年は口頭発表88件、ポスター発表606件、参加者数は約1500名と過去最大の規模となりました。 MIRUの発表区分(招待講演等を除く)には口頭発表とインタラクティブ（ポスター）発表に別れており、口頭発表のみ査読があります。 本稿ではMIRU2025で気になった発表を紹介したいと思います。※以下で使用する全ての画像は原論文で掲載されている画像を引用しています。 特殊な光学機器を用いた研究 画像センシングを扱う学会ということもあり、単なるRGBカメラ以外の機器を用いた研究が多くみられました。そういった中から気になったものを3件ピックアップしました。 1. イベントカメラを用いた可視光通信の高速化 (兵庫県立大学) 可視光の点滅パターンによって通信する「可視光通信」に関する研究です。可視光通信は既存の電波に干渉しないため、病院や航空機内など電波の利用が制限されている場所でも使えるという利点があります。しかしながら既存のカメラではフレームレートに限界があるため、送れる情報量に制限があるという問題があります。 そこで本研究では、輝度の変化しか拾えない一方で高い時間分解能と高いダイナミックレンジを持つイベントカメラを用いて高速な点滅パターンを利用可能にしました。 イベントカメラによる取得データのイメージ（Event-based, 6-DOF pose tracking for high-speed maneuvers 1 より引用）。 回転する円盤を普通のカメラで撮るとフレームごとに全体の画像が保存されるが、イベントカメラで撮ると時間方向と空間方向に広がる輝度変化の点群として得られる。 イベントカメラを用いた研究は以前からありましたが、高い時間分解能を活かした高速な物体の検出や、高いダイナミックレンジを活かした明暗差の激しい環境での映像認識など、視覚データの理解に関するタスクがほとんどでした。そのためこのように通信へ適用した研究は個人的に新鮮でした。 2. 符号化環境照明を用いた民生用カメラ撮影に対する情報埋め込みの実現 (大阪大学、York University) この研究は盗撮やディープフェイクへの対策として、人間にはわからない程度に光源を変化させることで撮影動画にウォーターマークを埋め込もうという取り組みです。 こちらも前述と同様に光源点滅ではカメラのフレームレートに限界があるため、さまざまな色のLEDを集めたハイパースペクトル照明を作成し、光源スペクトルを操作することで1秒あたり15ビットの情報埋め込みを達成しています。 撮影した動画像に対してデジタル的に情報を埋め込む技術はステガノグラフィーと呼ばれ広く研究されてきましたが、物理的にその空間に情報を埋め込むというアイディアがとても独創的に感じられました。ステガノグラフィーで利用されているような微小な色の操作ではなく、人間とカメラセンサーのスペクトル感度の差に着目し光源のスペクトルを操作したという点も新鮮でした。 3. 光飛行時間の直接計測による関与媒体に対して頑健な振動計測 (兵庫県立大学) この研究は単一の光子を拾うことができるほど敏感なSPAD（Single Photon Avalanche Diode）センサーを活用したものです。 このセンサーをパルスレーザーと組み合わせると、往復時間から光の飛行距離がわかり、さらに光の飛行距離の変化からレーザーを当てた物体の振動がわかることを示しました。 レーザーを用いた振動計測には反射時のドップラー効果を用いたものや反射光のブレを見るものなどがありますが、本手法は光の飛行距離を計測しているので、間に半透明ガラスなどがあっても問題なく対象の振動を計測できるというところが既存の非接触観測に対する利点です。 SPADセンサーについてはとても感度の高い光センサーであるということしか知りませんでしたが、このセンサーを活用することで物体の振動を測れるほど精密に光子の到達時刻を認識できるということに驚きました。本研究の実験装置では1ピコ秒（光が0.3ミリ進む時間）の時間分解能で計測ができるようです。 画像認識・VLMのロバスト化と評価 画像認識モデルのロバスト化または、VLMの評価周りで気になったものを3件ピックアップしました。 1. 不均衡なデータセットの継続学習における勾配一貫性正規化と動的な知識蒸留 (名城大学) この研究は不均衡なデータセットに対して継続学習をする取り組みを行なっています。不均衡なデータで学習すると過学習や学習不足が発生する問題と、継続学習すると旧クラスにおいて破壊的忘却が起こる問題2つに対処しています。 これらの問題を解決するために本研究では、Gradient Reweighting(GR) 2 に着目しています。GRはクラス／タスク単位で勾配を動的に再重み付けし、少数クラスの信号を増幅しつつ多数クラスへの偏りと旧クラスの忘却を抑えます。 しかし、GRでは勾配の振れ幅が大きく、学習は不安定になりやすいという課題があります。 そこで本研究では、勾配ノルムを移動平均したものを用いることで、過去の勾配方向に一貫性を持たせ、破壊的忘却を抑制しています。また知識蒸留に関するロス関数の計算をする際に、学習の初期段階では新クラスの学習を優先し、後半では知識蒸留の影響を強めるために、知識蒸留に関するロス関数に重みをかけることで調節しています。具体的には、現在のエポック数を総エポック数で割った重みを用いています。 実験ではCIFAR-100-LT(ρ=100)・ImageNetSubset-LT・Food101-LTの三種のデータセットを用いて評価しており、全クラスをN∈{10,20}に等分し、継続学習を実施しています。継続学習時に入力するデータの順番は各クラスのサンプル数の降順に固定するIn-ordered、ランダム順で入力するShuffledを実施しています。実験の結果、提案手法は12条件中11条件でGRを凌駕しました。 継続学習に関する論文は以前から多く存在しますが、現場で課題となる不均衡データにおける課題を課題設定に含めており、より現実的な設定の問題に対処している点が個人的に面白いと感じました。 2. Unleahing the Potential of Complementary Spaces in Group Robust Classification (東京理科大学) この研究は既存のVision Language Model(VLM)に存在するバイアスを除去した場合、元々正しく答えられていた猫の画像を車のように答えてしまう課題の改善に努めています。ここでいうバイアスとは、例えば金髪の男性が映る画像に対してVLMに髪色を答えさせた場合、学習時の統計的偏りや言語的先入観などを優先してしまい、VLMが黒髪と答えてしまうことを指します。 この課題の改善のために既存のバイアス除去手法を(1)線形/非線形プロービング、(2)アダプター、(3)補空間への射影の３系統とみなし、それぞれの手法が非対象タスクに対してどの程度精度の維持ができるのかを調査しました。ここで(1)線形/非線形プロービングは事前学習済みモデルの最終出力層に線形層等を追加し線形層のみを学習する手法を指し、(2)アダプターは事前学習済みモデルにMLP等を追加し、追加したMLP等のみを学習する手法を指し、(3)補空間への射影は特定のグループ属性が張る部分空間を推定し、該当の成分のみを取り除いた特徴に置き換える手法を指します。 実験の結果、(1)線形/非線形プロービングや(2)アダプター系は、対象タスクの精度は上がる一方で、非対象タスクの精度が数％台まで落ちる“破滅的忘却”を頻発。対照的に(3)「グループ属性の補空間への直交射影」にもとづく方法だけが、非対象タスクの性能をほぼ維持できることを示しました。 この結果を受け著者らは(3)補空間射影系を後処理で較正するシンプルな追加損失を提案しました。提案手法では、射影前後で一般語彙（WikipediaやImageNet同義語集合など）のテキスト埋め込みが変わらないように制約し、変化を“グループ属性が張る部分空間”に閉じ込めるように最適化を行いました。この結果対象タスクと非対象タスク平均精度の調和平均が一貫して向上し、ゼロショットCLIP比で最大+14.2%改善しました。 バイアスの削除に取り組む研究は多く存在すると思うのですが、バイアス削除に伴って特徴量空間はどのように変化し、非対象タスクの認識に影響を与えるのかについて以前から関心が個人的にありました。この研究はこの疑問に対して体系的に検証しており、検証の結果既存の手法であると(3)補空間への射影以外は非対称タスクへ対応できないことを明らかにしました。またこの知見から新たな手法を提案しており、有用な示唆を与える研究だと感じました。 3. VELA: LLM-Hybrid-as-a-judgeにもとづく長文画像キャプション向け自動評価尺度 (慶應義塾大学) この研究では、VLMの長文画像キャプションタスクの新しい評価指標を提案しています。既存のキャプションタスクで用いられる評価指標（BLEU/CIDEr/CLIPScore 等）では文全体の構成や一貫性を十分に測れず、またLLM/MLLMを用いて評価するLLM-as-a-judgeでは、自己回帰・早期画像統合のため遅いという課題がありました。 本論文はこれを同時に解く自動評価尺度VELAを提案しました。提案手法ではQwen2.5 3B 3 とLong-CLIP 4 の特徴量をProjector層で結合し(1)詳細さ、(2)関連性、(3)流暢さの3観点について数値スコアを同時出力します。学習には著者らが新規に構築したLongCap-Arenaを使用しており、画像・長文参照・長文候補に加え、アノテーターが主に詳細さ・関連性・流暢さの観点で数値評価を付与したデータセットで合計32,246件の人手評価を含みます。 実験ではKendall’s τcにてGPT-4oを用いたLLM-as-a-judge手法や強力なCLIP系指標を上回り、約260ms/サンプルと既存LLM-as-a-judgeより約5倍高速化を達成しました。 かなりシンプルなモデル構成で詳細さ・関連性・流暢さの観点でより人間と相関があり、LLM-as-a-judge手法を上回る性能を達成している点が面白いと感じました。 最後に 本ブログでは、私たちが興味を持ったMIRU2025の発表についてご紹介しました。NTTドコモビジネスでは、今回ご紹介した分野に限らず、画像や映像、さらには音声言語も含めたさまざまなメディアAI技術の論文調査や研究開発に今後も積極的に取り組んでいきます。 Mueggler, B. Huber and D. Scaramuzza, "Event-based, 6-DOF pose tracking for high-speed maneuvers", IROS 2014. https://www.youtube.com/watch?v=LauQ6LWTkxM ↩ He, Jiangpeng : "Gradient Reweighting: Towards Imbalanced Class-Incremental Learning", CVPR 2024 ↩ Qwen: An Yang, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chengyuan Li, Dayiheng Liu, Fei Huang, Haoran Wei, Huan Lin, Jian Yang, Jianhong Tu, Jianwei Zhang, Jianxin Yang, Jiaxi Yang, Jingren Zhou, Junyang Lin, Kai Dang, Keming Lu, Keqin Bao, Kexin Yang, Le Yu, Mei Li, Mingfeng Xue, Pei Zhang, Qin Zhu, Rui Men, Runji Lin, Tianhao Li, Tianyi Tang, Tingyu Xia, Xingzhang Ren, Xuancheng Ren, Yang Fan, Yang Su, Yichang Zhang, Yu Wan, Yuqiong Liu, Zeyu Cui, Zhenru Zhang, Zihan Qiu : "Qwen2.5 Technical Report", Arxiv 2024 ↩ Beichen Zhang, Pan Zhang, Xiaoyi Dong, Yuhang Zang, Jiaqi Wang : "Long-CLIP: Unlocking the Long-Text Capability of CLIP", ECCV 2024 ↩

こんにちは。クラウド&ネットワークサービス部で SDPF のベアメタルサーバの開発をしている山中です。 先日、Google Workspace で利用できる Gemini API を活用して、日々の業務ログから日報を自動生成し、Slackに自動投稿する仕組みを構築しました。 その具体的な方法と、実際に導入してわかった想像以上の効果をご紹介します。 デイリースクラムの悩み、AIで解決しませんか？ やったこと：情報を集めて Gemini に日報を書かせる 1. 各種ツールから活動ログを収集 2. イベント情報を時系列で整理 3. プロンプトを作成し Gemini API を実行 4. Slack への自動投稿 想像以上の効果！情報共有が劇的に改善 シンプルに楽！「昨日何してたっけ？」からの解放 口頭の問題点を解決 完璧を求めない柔軟な運用 完璧じゃないからこそ面白いAIの活用法 テキスト文化との親和性 AIは人間をアシストする存在 デイリースクラムの悩み、AIで解決しませんか？ 「昨日はこれをやって、今日はこれをやる予定です」 スクラムで開発している皆さん、毎朝のデイリースクラムどうしていますか？ 短い時間で、やったことや今後の予定を口頭でサクッと共有する。 アジャイル開発におけるデイリースクラムは、チームの情報共有に欠かせません。 しかし、この短いミーティング、意外と悩みがつきものじゃないでしょうか。 マルチタスクに追われていると「昨日何やってたっけ？」と混乱する 口頭だと伝え漏れや解釈のずれが起きやすい 日報をちゃんと書いている人もいるけど、正直面倒くさそう… GitHub や Jira、Slack に記録は残っているものの、複数のツールを横断して情報を整理するのは意外と労力がかかります。 でもこの課題、Gemini を使って解決できました。 今回は、社内の Google Workspace で利用できる Gemini API（Vertex AI 1 ）を使って日報を自動生成し、Slack に自動投稿する仕組みを構築したので、その具体的な方法と効果をご紹介します。 やったこと：情報を集めて Gemini に日報を書かせる 今回作ったのは、チームメンバーの日々の活動ログを自動で収集し、それを元に Gemini が日報を作成してくれるツールです。 1. 各種ツールから活動ログを収集 まずは、GitHub や Jira といった業務ツールから、各メンバーの活動ログを収集します。 この部分は、APIを叩くだけの定型的な作業なので、AI や MCP（Model Context Protocol 2 ） サーバは使いません。 欲しい情報だけを素早く確実に取得するために、各種サービスで提供されている API 経由で情報を取得します。 収集するイベント情報は以下の通りです。 昨日から今日までという期間に絞って各種イベント情報を取得することで、日報生成の材料を集めます。 Slack の投稿：メッセージ内容とチャンネル名 Jira チケットコメント：コメント本文、チケット ID とタイトル Confluence ページの編集：ページタイトルと編集時刻 作成した GitHub PR：PR タイトルと本文、リポジトリ名 Google Calendar の予定：予定の件名と時刻 API は直接リクエストを送ってもよいですし、手に馴染みのある言語のライブラリを使って取得するのも良いです。 2. イベント情報を時系列で整理 集めたイベント情報を JSON 形式に変換し、時系列でソートします。 これにより、AI が異なるイベント同士を関連付けて解釈しやすくなる効果が期待できます。 以下は、収集したイベントデータの JSON 例です。 [ { "type": "slack_message", "timestamp": "2025-09-03T09:30:00Z", "channel": "example-dev", "text": "PR #123 のレビューお願いします！" }, { "type": "github_pr", "timestamp": "2025-09-03T11:45:00Z", "repo": "example-tool", "title": "ログイン機能のバグ改修", "body": "ログイン時の処理に XXX の考慮漏れがあったため、YYY の対処を導入" }, // 他のイベントが続く ] 3. プロンプトを作成し Gemini API を実行 ここが一番重要なポイントです。時系列で整理したイベント情報を元に、日報を生成するためのプロンプトを作成し、Gemini API に投げ込みます。 プロンプトの内容は以下の通りです。 ## 指示（Instruction） 与えられたイベントログから [メンバー名] の日報を作成してください。 この日報は、チームメンバーが [メンバー名] の業務状況を正確かつ簡潔に把握できるようにすることを目的とします。 ## 役割（Role） あなたは「チームの情報共有を円滑にし、連携を促進するサポーター」です。 読み手が内容をすぐ理解でき、行動につなげられるように整理・要約してください。 ## 目的 (Goal) - チーム全員が [メンバー名] の業務内容・進捗・課題を把握できること - 必要な連携やフォローを即座に行える状態にすること - 業務の透明性を高め、チーム全体で成果を称賛し合える文化を育むこと ## ルール（Rules） - 全体を通して「親しみやすさ＋ビジネス的な明確さ」を両立させること - 文体は「体言止め」「短文中心」で、冗長な表現を避けること - ノイズ（挨拶・雑談・無意味な作業ログなど）は含めないこと - 細かすぎる作業は省略し、業務の本質や意義が伝わる粒度でまとめること - 適度に絵文字を使用し、視覚的に読みやすくすること - 最後に「成果や頑張りを具体的に労う一文」を必ず入れること ### イベントログ（Event Log） [ここに時系列でソートした JSON データを挿入] ## 出力形式（Output Format） 以下のフォーマットに従って出力してください。 ``` [メンバー名] の日報（XX月XX日） *業務1* 1. 内容1 * 詳細1 * 詳細2 2. 内容2 * 詳細1 3. ... *業務2* 1. 内容1 * 詳細1 * 詳細2 2. 内容2 * 詳細1 3. ... <メンバーの士気が上がるよう、頑張りや成果などを具体的な内容とともに元気よく労う> ``` 4. Slack への自動投稿 Gemini が生成した日報を、デイリースクラムの時間に合わせて Slack の専用チャンネルに自動投稿します。以下のスクリーンショットは実際に投稿された日報の例です。 作成したシステムはローカル端末上で動かしており、イベント情報の収集や Gemini API の呼び出し、Slack への投稿など、全て自動化しています。 実装は Ruby で行いましたが、同じような仕組みはどんな言語でも構築できるはずです。 想像以上の効果！情報共有が劇的に改善 この仕組みを導入して、チームの情報共有は劇的に改善しました。 シンプルに楽！「昨日何してたっけ？」からの解放 日報が自動で生成されることで、朝イチから「昨日何してたっけ…？」と頭を悩ませる時間が非常に少なくなりました。 ゼロから考えるのではなく、自動生成された内容をベースに口頭で補足するだけで済むので、デイリースクラムにおける情報共有が本当に楽になりました。 口頭の問題点を解決 日報がテキストで残ることで、情報共有の精度とアクセス性が大幅に向上しました。 伝え漏れや解釈のずれがなくなる デイリースクラムに参加できないメンバーも、日報を読めば何があったかすぐにわかる マネージャーはチーム全体の動きを把握しやすくなる 完璧を求めない柔軟な運用 AI が生成する日報は100%完璧ではありません。しかし、デイリースクラムの目的は情報共有を円滑にすることであり、内容が少し違っていても、その場で口頭で修正すれば十分です。 「完璧な情報」ではなく「とっかかりの情報」の提供ツールとして AI を使うことで、デイリースクラムにおいて非常に効果的に機能しました。 ちなみに、日報生成にかかる費用は、メンバー1人あたり1日わずか2.5円程度。コストを気にせず利用できるのも大きなメリットです。 （モデルは gemini-2.5-flash を使用しています。） 完璧じゃないからこそ面白いAIの活用法 今回の取り組みを通して、改めてAIの活用について考えさせられました。 テキスト文化との親和性 リモートワークが普及し、日々のやり取りが Slack などのテキストに置き換わった現代において、 AI がテキスト情報を自動で集約し、可視化するこの仕組みは非常に理にかなっていると感じます。 AIは人間をアシストする存在 人間が自らの意思で AI に何かを聞くのではなく、スケジュール実行やイベントをトリガーに AI が動き、人間の作業を先回りしてアシストする。 これこそが、AIを最大限に活かす方法の1つかもしれません。 また、現状の AI は完璧に指示通りのロジックで処理をすることは苦手です。完璧なタスク処理を AI に任せるのではなく、「完璧じゃなくてもいいから、良い感じに手伝ってほしい」という領域にこそ、積極的に生成 AI を組み込んでいくことが良いと思います。 システムに AI を組み込むときは、 「どの部分を、決定的なロジック(必ず同じ結果になるような決まったプログラム）で作るか？」 「どの部分を、非決定的な処理（柔軟で予測できないAI）で任せるか？」 この線引きを意識して設計することが大切です。 これは既存のプログラミングとは少し違う、新しい発想力や設計の仕方が求められる、非常に面白い領域だと感じています。 今回の仕組みは、デイリースクラムに限らず、あらゆるミーティングや朝会で役立つはずです。皆さんのチームでも、ぜひ試してみてください。 Vertex AI ( https://cloud.google.com/vertex-ai ) ↩ Model Context Protocol ( https://modelcontextprotocol.io/docs/getting-started/intro ) ↩

みなさんこんにちは、イノベーションセンターの @Mahito です。 普段は社内のエンジニアが働きやすくなることを目標に、 コーポレートエンジニアのような活動やエンジニア向けイベントの企画・運営をしています。 今回は、本 NTT docomo Business Engineers' Blog のレビューに、 GitHub Copilot code review を利用し始めたことと、その学びについてお話します。 なお、GitHub Copilot code review を導入以降は投稿がないので、 これが GitHub Copilot code review の初レビュー記事となっております。 企業ブログにおけるレビューの重要性と難しさ 本ブログにおけるこれまでの取り組みと GitHub Copilot code review 導入の背景 仕組みによるレビュー スタッフ内でのレビュースキルの共有 GitHub Copilot code review の導入 GitHub Copilot code review の設定 GitHub Copilot code review の実行 textlint では指摘されなかった typo の指摘 サービス名の確認 GitHub Copilot code review を動かしての学び 1. 指摘の非決定性 2. 執筆者・レビュアーの負担軽減 3. レビュー観点の明示化によるレビュアーの観点共有 textlint と GitHub Copilot code review の使い分け まとめ 企業ブログにおけるレビューの重要性と難しさ まず、GitHub Copilot code review を導入した話の前に企業ブログのレビューについて少し説明します。 本ブログのように、現在さまざまな企業でブログが展開されています。 しかし、企業ブログでは記事を発信する際に以下のようにさまざまな観点からのレビューが必要となります。 内容は正確か 誤字脱字はないか 企業のブランドイメージや広報ルールに合致しているか 誤解を招く表現がないか 引用は正しくされているか etc... 誤字脱字には簡単なタイポから自社や他社の商標やサービス名の誤り（本来大文字にするところが小文字になっている等）なども含まれます。 また、投稿者が意図した内容と記事を読んだ人の間で解釈が異なることから問題になるケースもあります。 こうした問題を避けるためにも記事を公開する前のレビューが重要となります。 しかし、上記のような観点は機械的なレビューではカバーできないことも多く、 人の手によるレビューが必要となります。 一方、人によるレビューでは問題を見逃してしまうことや、 スキル・経験・意見の違いによって、レビューの結果のばらつきによる問題が生じることもあります。 例えば A さんには問題のない表現に見えたので指摘をしなかったが、B さんが見ると問題がある表現だった、ということがあります。 そのため、レビューワーのスキルや考え方の共有をしながら、 企業として必ず守らなければいけないルールのラインをレビュー全体で揃えていくといった難しさがあります。 本ブログにおけるこれまでの取り組みと GitHub Copilot code review 導入の背景 仕組みによるレビュー 本ブログでは記事の管理やレビューに GitHub を利用しています。 投稿者は記事を執筆した後 PR を出し、レビュアーが PR に記事の修正や改善の提案を繰り返しながら、記事をブラッシュアップしていきます。 (なお、GitHubを活用した記事公開プロセスについては、別記事 「開発者ブログをリニューアルしたついでにレビューと記事公開プロセスをいい感じにしたお話」 で紹介していますので、ご興味がありましたらご覧ください) 。 以前より、レビューには textlint を用いた文章確認の仕組みを用意しています。 textlint は、文章の誤字脱字や表記ゆれ、文法確認などを行うためのツールです。 textlint を用いることで、設定したルールに基づき、 文法的な誤りや表記ゆれを自動的に検出し、レビュアーが指摘する必要のある問題を減らすことができます。 例えば、1文が長すぎるといったところや、広報ルールに沿ってない表現（「様々」は「さまざま」にするなど）を自動的に検出し、指摘できます。 PR の作成や修正がされたタイミングで GitHub Actions を用いた CI も用意しており、 投稿者の手元や PR 上で常に文章確認をしています。 昨年には、textlint では対応できない誤字脱字などの誤りが一定数あることから、 LLM を用いることでより抜けのない校正ができるのではと考え、CI に組み込んだこともあります （ LLM校正CIを自社のブログに導入してみた で詳しく紹介しています）。 しかしながら、こちらは LLM のモデル更新が頻繁にあることや、プロンプト調整の難しさ、 さらに実際には指摘されるコメントの半数ぐらいが的外れな修正提案だったこともありお蔵入りとなりました。 スタッフ内でのレビュースキルの共有 上記のような機械的な仕組みを用いたレビューは、ある程度の効果はあるものの、 最終的には本ブログのスタッフによるレビューに頼ることとなっています。 一方、人によるレビューでは問題を見逃してしまうことや、 スキル・経験・意見の違いによって、レビューの結果のばらつきによる問題が生じることもあります。 例えば A さんには問題のない表現に見えたのでコメントをしなかったが、B さんが見ていれば気付ける問題だった、ということがあります。 本ブログスタッフでは、レビュースキルを共有するためにいくつかの取り組みを行っています。 例えば、新しくスタッフになってくれた人向けのドキュメント整備や、ペアレビューを実施することでレビューのスキルを共有しています。 また、レビューをしている際に不安な場合は、Slack で他のスタッフに相談することもあります。 他にも、今回のようにスタッフ自身がブログ記事を書いて、他のスタッフからのレビューを受けることで、 レビュースキルの共有がされることもあります。 GitHub Copilot code review の導入 先述の通り、一時的に導入した LLM 校正 CI はお蔵入りをしましたが、 そのアイデア自体は面白かったことや、スタッフのレビューを下支えするためにも再度 LLM を使ったレビューをできないかと考えていました。 2025年4月4日に GitHub Copilot code review がリリースされたため、活用の検討を始めました。 GitHub Copilot code review は、 GitHub Copilot がコードレビューをした上でフィードバックをくれる機能です。 また、GitHub Copilot code review は、 .github/copilot-instructions.md に Copilot に対する コンテキストを追加設定 することで、レビュー観点を明示的に指示できます。 上記で述べたように、新規スタッフにレビュースキルを共有するための取り組みの中で、 レビュー観点などについてはすでにドキュメント化されているので、 これを追加コンテキストとして GitHub Copilot code review に設定しました。 GitHub Copilot code review の設定 実際の設定にはスタッフ向けのレビューマニュアルからレビュー観点を抽出し、 抽出したものを Claude Code に与えて .github/copilot-instructions.md を作成してもらいました。 現在は Claude Code が出力した内容で日本語としておかしな箇所などを直したものを利用おり、 以下がその内容の一部です。 ### 2. 商標およびブランド名の検証 - **目的**: 商標名およびブランド名の適切な名称使用を確実にする - **ガイドライン**: - 企業および製品の正しい名称が使われているかを検証する - prh.ymlで既にカバーされている一般的な間違い（GitHub vs Github等）も確認する - 潜在的な商標侵害を特定する - 誤用される商標名やブランド名の修正を提案する - テック企業とその製品に特に注意を払う GitHub Copilot code review の実行 GitHub Copilot code review を実行するには、 GitHub 上でプルリクエストを作成し、レビュアーに対して GitHub Copilot code review を有効にする必要があります。 レビュアーに割り当てると、あとは自動的に GitHub Copilot code review が実行され、 PR のコメントとしてレビューコメントが追加されます。 冒頭でも述べたように、本記事が GitHub Copilot code review の初レビュー記事となります。 実際に本記事のドラフトに対して GitHub Copilot code review を動かして、 GitHub Copilot code review から指摘された内容をいくつかお見せいたします。 textlint では指摘されなかった typo の指摘 確かにここは「は」を入れたほうが自然な文となりますので修正しました。 この他にも文法的な指摘や、不要なスペースの指摘など我々の textlint の設定では拾われなかった細かい typo をいくつか指摘されております。 サービス名の確認 こちら指摘されている "Claude Code" については、ツール名としては正しいです。 Claude Code は Claude の API を利用しておりサービス名としては "Claude" が正しいのかも知れませんが、 今回はツールとして Claude Code を利用したことを伝えたいので、"Claude Code" のままにしています。 今回は過検知という結果になっていますが、 商標やサービス名についても .github/copilot-instructions.md に書いた内容で確認しているのがわかりました。 また、製品名やブランド名以外にツール名についても確認するよう追加指示の必要があるとわかりました。 GitHub Copilot code review を動かしての学び 実際に GitHub Copilot code review 動かしてみて、いくつかの学びがありましたので共有しておきます。 1. 指摘の非決定性 まず、GitHub Copilot code review を動かすたびに指摘が変わるケースに遭遇しました。 こちらは内容が変わるというよりも、前回のレビューでは指摘されず修正もされなかった箇所が次回のレビューでは指摘されることがありました。 それなら最初から指摘してほしかったという気持ちになりつつも、 私自身 1 度目のレビューで見逃していた箇所に再レビュー時で気づき、申し訳無さもありながらコメントすることもあります。 そういう意味で、GitHub Copilot code review を含む生成 AI もちょっと人間っぽい不確実さがあるなと感じました。 一応対策としては、GitHub Copilot code review が一度レビューを終えた後で、 再度 GitHub Copilot code review を実行することで、指摘箇所が変わることもあるので何度か動かしてみるのもありかなと思いました。 ただ、指摘箇所が変わるということもあり、 .github/copilot-instructions.md にも書いた指示内容が正確に反映されているのか分かりづらく、 このあたりは使いながら時間をかけて調整する必要があると感じています。 2. 執筆者・レビュアーの負担軽減 こちらは普段から CI に Linter や Formatter を導入されている方はわかると思うのですが、 GitHub Copilot code review を使い機械的な指摘を受けることで、 執筆者・レビュアー双方の心理的な負担を減らすことができます。 私がコードや記事を書いている際にも簡単なミスや typo の指摘を人にされると、 「こんな簡単なところの指摘させて申し訳ない」と思うことが多々あります。 レビュアーの立場でも「こんな些細なところの指摘をして直させるのは心苦しい（でも必要だし）」と思いながら指摘することがあります。 GitHub Copilot code review を使うことで、 Linter や Formatter のように記事内容をレビュアーが確認する前に GitHub Copilot code review が問題点を指摘してくれるため、 執筆者・レビュアー間でのやりとりが減り、双方の心理的な負担を減らすことができると感じました。 3. レビュー観点の明示化によるレビュアーの観点共有 こちらは当初想定していなかったメリットではありますが、 .github/copilot-instructions.md にレビュー観点を明示化することで、レビュアーの観点を共有しやすくなると感じました。 これまでもドキュメントに記載することで共有を図っていたのですが、 今回 GitHub Copilot code review 用に .github/copilot-instructions.md を作成することで、 レビューの要点をより明示でき、的確にレビュー観点をレビュアー内で共有できるようになったと考えています。 textlint と GitHub Copilot code review の使い分け GitHub Copilot code review がなんとなく使えることがわかりましたが、 では textlint は不要かというとそういうわけではありません。 GitHub Copilot code review は生成 AI を用いたレビューであり、 先述したようにその結果が必ずしも毎回一致するとは限りません（非決定性）。 例えば、textlint のルールとして紹介した「様々」という単語に対して、 GitHub Copilot code review は「さまざま」と修正を提案することもあれば、しない場合もあります。 このように結果が必ず一意になるように確認する場面（決定性）については、 textlint を用いた確認が有効です。 逆に、文脈などから判断が必要な場合においては、GitHub Copilot code review のような、生成 AI を用いたレビューが有効だと考えられます。 まとめ 本記事では、企業ブログにおけるレビューの難しさと、それを手助けする可能性として GitHub Copilot code review を活用する方法について紹介しました。 もちろん生成 AI の出力のため完璧でないことを前提にした運用となりますが、 これまでスタッフが確認してきたけど漏らしがちなところを GitHub Copilot code review にサポートしてもらえるのではないかと思っています。 なお、今回の記事は GitHub Copilot code review によるレビューを反映したうえでレビューアーに見てもらっていますが、 レビュアーからは記事をさらに良くするための指摘をいくつもされており、やはり人のレビューは大事だなと改めて感じています。 今回は企業ブログのレビューでの活用を紹介しましたが、 個人ブログでも活用できるかと思いますので、よろしければぜひ試してみてください。 この記事がどこかの企業や個人のブログの運営のお役に立てれば幸いです。

イノベーションセンターの加藤です。この記事ではWhisperによる音声認識の前処理と後処理にLLMとOCRを組み込むことで、映像の文字起こし精度の向上を図った際の検証結果を紹介します。 Whisperとは OCRの結果を盛り込み専門用語を認識させる 大規模言語モデルで全体の文章を調整する 各アプローチの融合 結果の考察 まとめ Whisperとは Whisper 1 はOpenAIによって提供されているオープンソースの音声認識モデルです。 色々なサイズのモデルが提供されており、最も大きいモデルであるlarge-v3は日本語を含む多言語に対応し高い認識精度を誇ります。 しかしもちろん完璧ではなく、Whisper(large-v3)で日本語の音声を書き起こしてみるとそれなりに誤認識が見られます。また、専門用語や人名など、あらかじめ知っていないと正しく書けない単語についてもうまく書き起こせないという音声認識共通の問題もあります。 そこで本稿では、Whisperに日本語やドメイン知識に関する事前知識をうまく盛り込み音声認識の精度を向上させる2つの手法を実験してみました。 できればオープンなデータで実験したかったのですが、スライドを映しながら喋る形式で、専門用語を含み、正解データとして読み上げ原稿がある動画を見つけられなかったため、社内勉強会の録画を使って2つの手法を試してみました（そのため評価指標しか出せません🙇）。約8分の映像に対して単語単位の誤り率（Word Error Rate, WER）を測定し、それぞれの手法を比較します。 OCRの結果を盛り込み専門用語を認識させる Whisperのプロンプトには直前に認識した文章やキーワードなどを埋め込める領域が存在し、ここに専門用語や人名を埋め込むと書き起こしの語彙をコントロールできます。 あくまで言語モデルの出力を誘導する程度の機能であり、専門用語の読みを明示的に指定できるわけではありませんが、以下の例のように常識的な読み方であればWhisperが正しく書き起こしてくれます。 さらに、文字起こしの対象が映像であるとき、映像に映っている文章が文字起こしの際のヒントになることがあります。特に講演などでスライドを画面に映しているときは発話内の専門用語が画面に表示されていることが多いのではないかと思います。 そこで発話を検出したタイミングの映像フレームをEasyOCR 2 で文字認識し、拾えた単語をWhisperプロンプトに埋め込む処理を追加しました。 その結果、Whisperに標準で実装されているビームサーチと比較して、WERが0.059から0.056に少し改善しました。 大規模言語モデルで全体の文章を調整する Whisperは一般的な大規模言語モデル（LLM）と同様に、入力と現時点の出力 から次の単語（トークン） としてあり得るものを確率 の形で予測します。 普通は最も確率の高いトークン を選択するか、確率に沿ってランダムに選択するかのどちらかですが、確率の高い候補を複数確保して文章全体でもっともらしいトークン列 を探索するビームサーチと呼ばれる手法も存在します。 このビームサーチで得られる複数の候補に対して、Whisperよりも大きなLLMを使ってより信頼度の高いもっともらしさを算出すれば、音声認識の結果を修正できそうです。 そこで、検出された各発話区間に対して上位5件の認識結果をWhisperのビームサーチから取得し、Sarashina2-7B 3 を用いて文章全体のもっともらしさ（Perplexity）が最適になるような認識結果の組み合わせを探索しました。 その結果、WERは0.059から0.048に改善しました。 各アプローチの融合 それぞれのアプローチは一長一短です。LLMによるアプローチではそもそもWhisperが専門用語を聞き取れなかったら修正は困難ですし、特に会話中に現れる人名は単なる日本語の一般知識だけではカバーできません。一方でOCRによるアプローチでは、Whisperが音声をチャンク分けして独立に認識する仕組みを採用しているために、単語単位では正しくても文章としてはおかしいことがよくあります。 そのため、両方を組み合わせることでこれらの弱点を補うことができそうです。 しかしながら、それぞれの手法を単独で使用した時は認識精度が向上したにもかかわらず、併用するとWERが0.059から0.077に悪化するという結果になってしまいました。 結果の考察 以上の結果を表にまとめました。 naive: ビームサーチのみ ocr: OCRによって取得した単語をWhisperのプロンプトに注入してビームサーチ llm: ビームサーチした結果の候補からLLMが選択 both: ocrとllmの併用 naive ocr llm both WER 0.059 0.056 0.048 0.077 併用による精度劣化の原因を考察するために、認識結果が悪化した典型的なサンプルを紹介します。 このようなスライドを映しながら話している場面で、認識結果は次のようになりました。 原稿（Ground Truth） 次に文法制約付き生成の既存手法のLimitationとして、 naive 次に文法制約付き生成の既存手法のリミテーションとして ocr 次に文法制約付き生成の既存手法のリミテーションとして、 llm 次に、文法制約付き生成の既存手法のリミテーションとして、 both 5.、6.、7. 併用（both）した時に出力がおかしくなっています。そこでこの時点で画面をOCRした時の結果と、OCRによって得たキーワードをプロンプトに注入したか否かでビームサーチの候補がどう変化したかをみてみます。 OCRによって得られたキーワード 背景、文法制約付き生成手法、2.、3、提案手法、4.、5.、まとめ キーワード注入なしでのビームサーチ結果（5候補） 候補 スコア（自信度） 次に文法制約付き生成の既存手法のリミテーションとして -0.062 次に文法制約付き生成の既存手法のリミテーションとして、 -0.069 次に、文法制約付き生成の既存手法のリミテーションとして、 -0.081 次に文法制約付き生成の既存手法の リミテーションとして -0.114 次に、文法制約付き生成の既存手法のリミテーションとして -0.136 キーワード注入ありでのビームサーチ結果（5候補） 候補 スコア（自信度） 次に文法制約付き生成の既存手法のリミテーションとして -0.245 5.、6.、7。 -0.914 5.、6.、7. -0.985 5.、6。 -1.068 5.、 -1.395 OCRがいくつかの文章を見落としているのは一旦無視して、箇条書き用の数字がキーワードとして抽出されていることがわかります。そしてビームサーチの結果がこのようなキーワードに引っ張られてしまい、自信度は低いもののまるで箇条書きの続きを出力するような「5.、6.、7」という候補を出力してしまっています。 このようにWhisperのプロンプト機能はコントロールが難しく、音声とは全く関係のない文章がプロンプトに引きずられる形で出力されてしまうことがあります。さらに後処理のLLMは音声認識の自信度を考慮していないので、このような変な文章を選択してしまうリスクが発生します。 この問題はLLMの文章選択の際にWhisperの自信度を考慮しながら文章全体のもっともらしさを最適化することで回避できますが、Whisperの出力する自信度とLLMの出力するもっともらしさのバランスは慎重に設定する必要がありそうです。 まとめ 本稿ではオープンソースの音声認識モデルであるWhisperの性能を向上させるために、OCRで抽出した専門用語のプロンプト注入と、LLMによる自然な出力文章の探索という2つのアプローチを紹介しました。いずれの方法も性能向上に寄与しましたが、プロンプト注入のアプローチは認識候補の品質を下げる傾向にあり、LLMによるアプローチと併用するためには別の工夫が必要そうでした。 OpenAI, Whisper ( https://github.com/openai/whisper ) ↩ Jaided AI, EasyOCR ( https://github.com/JaidedAI/EasyOCR ) ↩ SB Intuitions, Sarashina2-7B ( https://huggingface.co/sbintuitions/sarashina2-7b ) ↩

こんにちは、イノベーションセンターのメディアAI プロジェクト（以下、PJ）の小林、加藤、岡本です。普段はコンピュータビジョンの技術開発やAI/機械学習（ML）システムの検証に取り組んでいます。 我々メディアAI PJでは5月27日から30日にかけてグランキューブ大阪で開催されたJSAI2025（2025年度 人工知能学会全国大会）に参加しました。本記事ではJSAI2025で発表された「画像・3D AI応用関連」、「VLM(Vision Language Model)」、「ハルシネーション対策」に関する興味深かった研究をいくつか紹介したいと思います。 目次 目次 JSAI2025とは 画像・3D AI応用関連 深度情報を用いた画像識別における解釈性向上に関する一考察1 変電所設備を対象とした３次元物体検出4 重み付き残差接続による境界品質を考慮したゼロショットセグメンテーション手法の提案7 VLMに関する論文 Crosslingual Visual Promptにもとづくテキスト付き画像からの日常物体検索10 判断根拠を説明する視覚言語モデルの自己改善手法12 項目反応理論を用いた視覚言語モデルのマルチモーダルな推論能力および問題特性の評価17 ハルシネーション対策に関する論文 [アプローチA] 反論・再考プロンプトによるHallucination検出手法の提案19 [アプローチA] 反復サンプリングを活用したLLM推論時の外部情報検索機能の最適化22 [アプローチA] 長文コンテキスト質問応答における大規模言語モデルによる誤引用文の訂正手法の提案24 [アプローチB] LLM内部演算値を用いたLLM回答の信頼度定量化とOOD検知方式26 最後に JSAI2025とは JSAI（人工知能学会全国大会）は日本最大規模のAIに関する学術イベントであり、39回目の開催となりました。今年は史上最多の4939名(現地4032名、遠隔907名)の参加があったとのことで、昨今のAI技術への注目度の高さを感じられました。JSAIでは昨今注目を浴びている大規模言語モデルをはじめ、画像・音声処理、AIの応用・社会実装など数多くのセッションが開催され賑わいを見せていました。 本ブログではJSAIに参加したメンバで気になった発表を紹介したいと思います。 ※以下で使用する全ての画像は原論文で掲載されている画像を引用しております。 画像・3D AI応用関連 深度情報を用いた画像識別における解釈性向上に関する一考察 1 この研究では画像識別においてRGBと深度情報を融合し、異なるモディリティ間を統合的に扱うマルチモーダルモデルを一貫した解釈で特徴を捉えられるようにする手法を提案しています。 Vision Transformer（ViT） 2 などのモデルをベースにRGB、Depthを融合する従来の融合手法（Early-Fusion、Late-Fusionなど）では大きく以下の2つの課題があります。 RGB情報と深度情報それぞれが独立したエンコーダで学習されており、モダリティ間の相互作用が十分に考慮されていない 異なるモダリティ間で一貫した解釈を得ることが難しい 例えば、自動運転において歩行者を識別する際、深度エンコーダが歩行者に注目している一方で、RGBエンコーダがほとんど注目しないといったAttentionの不整合が生じることで、モデルの解釈性と信頼性が損なわれてしまいます。 これらの課題に対し、この研究では、RGBエンコーダと深度エンコーダ間でAttention Weightを相互に共有する新たなモデルを提案しています。この提案モデルに含まれるFusion機構（Share-Fusion）は、一方のエンコーダから出力されたAttention Mapをもう一方のエンコーダへ重み付けして反映させることで、双方のモダリティ間で相互作用を促し、注目箇所の矛盾を軽減することを目指します。これにより例えばRGBエンコーダが信号機に注目できなかった場合でも、深度エンコーダが信号機に注目していれば、RGBエンコーダも信号機に注目するように誘導し、より正確な予測とAttention Mapの一貫性向上を期待しています。 実験ではWashington大学提供のRGB-Dオブジェクトデータセット 3 を用いた画像分類タスクにおいて、Late-FusionモデルにAttention共有機構を加えた場合とそうでない場合で検証しています。 結果、画像分類精度において両エンコーダ間で相互にAttention情報をフィードし合うパターンが（0.7541）、従来のLate-Fusionモデル（0.7366）を上回る結果を示しました。提案のAttention共有機構がAttention Mapの一貫性向上に大きく寄与することが定量的に確認されました。 変電所設備を対象とした３次元物体検出 4 この研究では設備保守の自動化に向けて、変電所設備のLiDAR点群に対し、空間的配置を加味した3次元物体検出を検証しています。 研究では名古屋市内の変電所構内77kVエリアを据え置き型LiDAR（Leica BLK360）で測定し、この点群データに対し、「碍子（insulator）」「 可動スイッチ（connector）」「ラインスイッチの設備全体（whole）のオブジェクト」についてバウンディングボックス（BBOX）によるアノテーションを用いたものを実験データとし、2つの3次元物体検出手法を比較検討していました。 点群パターンマッチングを用いた3次元物体検出：対象とするデータラインスイッチは形状が普遍なため、wholeに含まれる点群と入力点群間でパターンマッチングを行い、検出を試しています。実験結果から、この手法は対象となる点群の大きさ、密度、欠損（オクルージョン）に検出性能が影響されると判明しています。特に碍子のような小さな個別のオブジェクトの検出は困難でした。 Transformerにもとづく3次元物体検出：Transformerを3次元物体検出に応用したアルゴリズムの1つである3DETR（3D Detection Transformer） 5 の適用を検討しています。3DETRは、PointNet++ 6 で点群から特徴量を抽出し、Transformerエンコーダ点ごとの埋め込み表現へと変換後、Transformerデコーダがクエリーに対するBBOXを出力するモデルです。広域の設備全体の点群を入力が困難であったため領域分割をし、データ拡張を実施していました。 実験の結果、事前学習モデルを利用したファインチューニングでは、検出性能が向上し、対象物体の種類や点群密度が異なる場合でも有効に機能することが明らかになりました。特に硝子やコネクタのような細かい設備を正確に検出できるだけでなく、点群の一部が欠けている場合でも、ある程度の位置推定が可能であることを示しています。 重み付き残差接続による境界品質を考慮したゼロショットセグメンテーション手法の提案 7 事前に学習していない物体を検出するゼロショットセグメンテーションにおいて、既存のRobust Segment Anything Model（RobustSAM） 8 の課題であるノイズのある劣化画像に対して頑健であると報告されています。一方で、RobustSAMはクリアな画像に対して物体の境界領域を正確に抽出できないことが指摘されています。この点に対して、本研究ではクリア画像と劣化画像の双方で精度を両立させる手法を提案しています。 RobustSAMはSAMを基盤として、SAMに劣化情報を除去する機構（Anti-Degradation Token Generation Module: AOTGおよびAnti-Degradation Mask Feature Generation Module: AMFG）を追加することで、雨や雪といったノイズが含まれる劣化画像に対しても頑健性を高め、高い精度でセグメンテーションを行うことが可能です。 しかし、RobustSAMはクリア画像に対してセグメンテーション領域が過剰に広がり、物体の境界を正確に推論できないという問題が確認されています。この研究ではその事象を定量的に評価するための指標である「Overflow Score (OS)」を定義していました。OSは、正解領域の輪郭付近に位置する領域の中で、予測領域が含まれている割合を示し、OSの値が大きいほど境界の外側を過剰に予測していることを意味します。評価実験では、RobustSAMはSAMに比べてOSが大きく、クリア画像・劣化画像ともに境界をうまく捉えきれていないことを定量的に示していました。 この課題に対し、研究は、劣化情報を除去する前の特徴量に境界情報が含まれている可能性に着目し、RobustSAMのAMFGに「重み付きの残差接続」のような機構を追加する新しいモデルを提案しています。 これにより、入力画像に応じて劣化情報を除去した特徴量を重視するか、除去前の特徴量を重視するかを柔軟に選択することが可能になります。 評価実験ではMSAR10kデータセット 9 と人工的に生成した劣化画像に対してIoUとOSを指標として評価しています。プロンプトが点の場合、クリア画像に対し提案手法のIoU：89.77%、OS：25.32%がRobustSAMのIoU：89.57%、OS：29.42%となり、有効性を示していました。劣化画像に対してもIoUは同等の精度（提案手法:89.08%, RobustSAM：89.27%）を保ちつつ、OSは2%優れる結果となっていました。 VLMに関する論文 Crosslingual Visual Promptにもとづくテキスト付き画像からの日常物体検索 10 ロボットが屋内外で撮影した画像の中から、ユーザーの自然言語クエリーに合致する日常物体を高精度に検索する手法を提案しています。日常物体を含む画像検索では、商品ラベルや標識などに含まれるscene text（画像中の文字情報）を考慮した検索が必要です。 例えば、「“Lipton” の前にある白い液体の入った容器」というユーザーからの自然言語クリエーがある場合、scene textを考慮することは不可欠です。しかし、従来のCLIP 11 やBEiT-3といったマルチモーダル検索は、視覚特徴と言語特徴の単純なマッチングに留まるため、容器ラベルなどのscene textを含む画像では文字情報を正しく活用できず、検索精度が低下しやすいという課題がありました。 そこで本手法では、画像内の文字領域をOCRで検出し、位置情報とともに特徴量化し、最終的に画像特徴量と統合するScene Text Visual Encoder（STVE）を導入しました。また、クエリーを「全文の意味」と「名詞句ごとの意味」に分けてエンコードし、両者を統合する Multi-Query Encoder（MQE）を設計しました。 これらによって、文字情報と視覚情報を統合した特徴量と、操作指示の意図を多粒度に捉えた特徴量をコサイン類似度で計算することで、scene textを含む日常物体検索において従来のモデルを大きく上回ることを定量・定性評価の両面から示しました。下の画像は定性評価での例であり、scene textを考慮した画像検索が従来のモデルに比べて可能であることを示しました。 判断根拠を説明する視覚言語モデルの自己改善手法 12 本研究では、Vision Language Model（VLM）が人間の主観に基づいて画像が美しいかを評価する画像の審美性評価タスクにおいて予測スコアとその判断根拠を同時に自然言語で生成し、自律的に性能を向上させる手法を提案しています。従来手法では、「スコア予測に偏ると説明文生成力が低下すること」「高品質な説明データを集めるには膨大な人手コストがかかること」「予測結果と生成される説明文の整合性を維持しづらいこと」の3つの問題がありました。そこで本手法では既存の画像に対してスコアが付与されたデータセットと指示学習済みVLMの能力を組み合わせ、自己改善によりVLMのスコア予測能力と判断根拠の説明能力を高め、また整合性の向上に努めています。 提案手法では、データセットの画像と正解スコアを条件としてVLMに説明文付きの応答を生成させ、「好ましい応答」と誤スコアを用いた「好ましくない応答」を生成し、両者を対比させるDirect Preference Optimization（DPO） 13 用の学習データを構築します。さらに、誤スコア応答中のスコア部分を正解値に置き換えることで、予測スコアと説明文の整合性を高めるためのDPOデータも自動的に作成し、説明の一貫性向上を図ります。これら二種のDPOデータセットで各々LoRAを適用したVLMモデルを別々に訓練した後、TIES-Mergingにより2つのモデルを重みレベルで統合する工程を繰り返すことで、スコア予測精度と説明整合性の双方を段階的に改善しました。 実験には画像の審美性評価の代表的ベンチマークであるAVA 14 とAADB 15 を使用し、各評価者の平均スコアを0から9まで10段階に離散化した上で、LLaVA-NeXT-7B 16 を中心とする0.5B～7Bパラメータの複数モデルにLoRAを適用して訓練しました。AVAデータに対してLLaVA-NeXT-7Bをベースとしたモデルでは、Zero-shotでのSpearman順位相関係数（SRCC）は0.446、GPT-4oを用いた説明整合性スコア（Cons）は3.36でしたが、4回目の反復後にはSRCCが0.739、Consが3.57へと大幅に向上し、説明文がスコアとより高い一貫性をもって生成されるようになりました。また、小型モデルでも同様の改善が確認され、提案手法の汎用性が示されました。 項目反応理論を用いた視覚言語モデルのマルチモーダルな推論能力および問題特性の評価 17 視覚言語モデル(VLM)の評価は、ベンチマークを通して画像とテキストを同時に扱うクロスモダリティーの能力を評価する必要があります。しかし、現状のベンチマークの問題には、画像やテキストのみをVLMに提供することで回答可能なショートカット問題が存在し、正しくVLMの性能を評価することが課題となっています。 そこで本研究では、MMMUデータセット 18 を「画像のみ」「テキストのみ」「両者併用」の３パターンでVLMに解かせ、正誤データをIRT（項目反応理論）モデルに入力し、各VLMの「画像処理能力」「テキスト処理能力」「両者統合能力」と各問題の難易度パラメータを同時に最尤推定しました。難易度パラメータはさらに、「選択肢由来の基本難易度」、「画像投入による難易度の低下量」、「テキスト投入による難易度の低下量」、「両者併用時による難易度の低下量」といった４種に分解し、各問題ごとに推定しています。 実験結果から「両者併用時による難易度の低下量」を用いることによって、テキストのみを用いて解けてしまうような問題の抽出と、画像とテキストどちらも正答を導く上で必要な問題の抽出を可能としました。 提案手法により抽出された画像を用いずにテキストのみを用いて比較的回答が導きやすい例。問題文のみから正答を導くことができる。 提案手法により抽出された画像とテキストの双方が必要な問題例。 ハルシネーション対策に関する論文 本章では大規模言語モデルのハルシネーション対策についてまとめました。モデルへの介入度合いによって次の2つのアプローチに分類しています。 アプローチA: 入出力の工夫のみ アプローチB: モデルデータにアクセスが必要 [アプローチA] 反論・再考プロンプトによるHallucination検出手法の提案 19 LLMに質問を繰り返した時の回答の揺らぎから信頼度を測る手法です。 質問を繰り返すアプローチとして有名な既存手法にSelfCheckGPT 20 と呼ばれるものがあり、これは高いサンプリング温度で回答を複数生成させて出力の一貫性を回答の確信度とみなすものですが、本手法ではより出力トークン数を抑えてコストの削減を狙っています。 本手法ではLLMのチャットセッションを3つ（Bot1, Bot2, Bot3）用意します。まずBot1に質問を投げ回答してもらい、Bot2にその回答に対する反論を考えてもらいます。そしてその反論をBot1に投げて再度回答してもらい、Bot3を用いて最初の回答と反論後の回答を比較して意見の一貫性を測ります。 もし意見が変化していなければBot1の回答には十分な信頼性を持つとみなし、反論に流され意見を変えていればハルシネーションを起こしているとみなします。 実験ではクイズを題材にした質問応答ベンチマークJAQKET 21 を用いて、知識問題に対してLLMがハルシネーションを起こしているかどうかを予測させました。その結果、出力トークン量を揃えた条件においてSelfCheckGPTよりも精度（Precision）は低く、再現率（Recall）は高くなることが分かりました。これはつまりハルシネーションを誤検知した数が多いということであり、ユーザーの反論に対してすぐに意見を翻してしまうというLLMの特性が如実に現れたといえます。 しかし再現率の高さから、回答の正確性が強く求められる分野ではこの手法が役に立つだろうと筆者は述べています。 [アプローチA] 反復サンプリングを活用したLLM推論時の外部情報検索機能の最適化 22 こちらはRAGを用いて回答の正確性を担保するアプローチです。RAGは具体的なソースに基づいて回答できるという利点がありますが、質問と関係のないソースを取得したり、ソースの読解に失敗して回答を間違えたりするという課題があります。 そこで本手法ではソース取得部分においては複数回質問することでソース検索用クエリーの一貫性を保ち、読解部分ではあらかじめテンプレートの回答例を作っておくことで回答の方向性を安定させるという複合的な方法で回答の信頼性を高めました。 実験ではWikipediaをもとにして作られたJEMHopQA 23 データセットを用いて、Wikipediaの検索を可能にした状態でLLMに回答させました。その結果、2つの工夫がそれぞれ回答の精度向上に寄与していることが示せました。 [アプローチA] 長文コンテキスト質問応答における大規模言語モデルによる誤引用文の訂正手法の提案 24 こちらもRAGアプローチで、LLMがソースとして利用した部分を正確に引用するための手法を提案したものです。 LLMに引用を任せてしまうと、時々勝手に文章を変えてしまうことがあります。そこで本手法ではLLMの出力した引用文が元ソースと一致しなかった時に、高い類似度の文章があればそれを抽出し、類似する文章が見つからなければLLMに引用文を自己修正させることを繰り返しています。 実験ではHotpotQA 25 と呼ばれる英語の質問応答データセットを用いて、回答の正確性と引用の質をそれぞれGPT-4oに判定させました。その結果、回答の正確性は既存手法より少し劣るものの、高々5回の自己修正で既存手法よりも高い質の引用文を提示できています。 [アプローチB] LLM内部演算値を用いたLLM回答の信頼度定量化とOOD検知方式 26 LLMが学習していないドメインに関する質問に対しては、LLM内部で計算される特徴ベクトルが正しく答えられた時の特徴ベクトルの分布から大きく外れるだろうという仮定に基づいた分布外（Out-Of-Distribution, OOD）検知手法に関する論文です。 質問文を入力している時または応答文を出力している時のLLMの各アテンション層のベクトル（アテンションベクトル）を抽出し、LLMが正しく答えられた質問応答に対するアテンションベクトルとのコサイン類似度を測ることで、その質問に対する応答の信頼性を見積もります。 実験ではあるドメイン（業務におけるQ&A）のデータに対してファインチューニングされたLLMを用いて、質問文がそのドメインに含まれているかどうかをアテンションベクトルを用いて判定させました。その結果、真陽性率・真陰性率ともに95%を超える高い正解率で判定できることを示しました。 本手法はハルシネーションそのものを検出できる訳ではありませんが、LLMをファインチューニングする時には想定していなかった質問内容を実用時に検出するという使い方ができそうです。 最後に 本ブログでは、私たちが興味を持ったJSAI2025の発表についてご紹介しました。NTTドコモビジネスでは、今回ご紹介した分野に限らず、画像や映像、さらには音声言語も含めたさまざまなメディアAI技術の論文調査や研究開発に今後も積極的に取り組んでいきます。 更家崚介, 清水良太郎, 後藤 正幸: "深度情報を用いた画像識別における解釈性向上に関する一考察", https://doi.org/10.11517/pjsai.JSAI2025.0_4N2GS705 ↩ Alexey Dosovitskiy, Lucas Beyer, Alexander Kolesnikov, Dirk Weissenborn, Xiaohua Zhai, Thomas Unterthiner, Mostafa Dehghani, Matthias Minderer, Georg Heigold, Sylvain Gelly, Jakob Uszkoreit, Neil Houlsby : "An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale", ICLR 2021 ↩ Peter Henry, Michael Krainin, Evan Herbst, Xiaofeng Ren, Dieter Fox : "RGB-D Mapping: Using Depth Cameras for Dense 3D Modeling of Indoor Environments", IROS 2011 ↩ 瀬川修 : "変電所設備を対象とした３次元物体検出", https://doi.org/10.11517/pjsai.JSAI2025.0_3N5GS704 ↩ Ishan Misra, Rohit Girdhar, Armand Joulin : "An end-to-end transformer model for 3d object detection", ICCV 2021 ↩ Charles R. Qi, Li Yi, Hao Su, Leonidas J. Guibas : "Pointnet++: Deep hierarchical feature learning on point sets in a metric space", NeurIPS 2017 ↩ 永見陽輝, 櫻井洸介, 山極綾子, 後藤 正幸 : "重み付き残差接続による境界品質を考慮したゼロショットセグメンテーション手法の提案", https://doi.org/10.11517/pjsai.JSAI2025.0_3N1GS701 ↩ Wei-Ting Chen, Yu-Jiet Vong, Sy-Yen Kuo, Sizhuo Ma, Jian Wang : "RobustSAM: Segment Anything Robustly on Degraded Images", CVPR 2024 ↩ Ming-Ming Cheng, Niloy J. Mitra, Xiaolei Huang, Philip H. S. Torr, and Shi-Min Hu : "Global Contrast Based Salient Region Detection", CVPR 2011 ↩ 戸倉健登, 是方諒介, 小松拓実, 今井悠人, 杉浦 孔明 : "Crosslingual Visual Promptにもとづくテキスト付き画像からの日常物体検索", https://doi.org/10.11517/pjsai.JSAI2025.0_1Win452 ↩ Alec Radford, Jong Wook Kim, Chris Hallacy, Aditya Ramesh, Gabriel Goh, Sandhini Agarwal, Girish Sastry, Amanda Askell, Pamela Mishkin, Jack Clark, Gretchen Krueger, Ilya Sutskever : "Learning Transferable Visual Models From Natural Language Supervision", PMLR 2021 ↩ 丹治直人, 山崎 俊彦 : "判断根拠を説明する視覚言語モデルの自己改善手法", https://doi.org/10.11517/pjsai.JSAI2025.0_4A3GS1003 ↩ Rafael Rafailov, Archit Sharma, Eric Mitchell, Stefano Ermon, Christopher D. Manning, Chelsea Finn : "Direct Preference Optimization: Your Language Model is Secretly a Reward Model", NeurIPS 2023 ↩ Murray, Naila and Marchesotti, Luca and Perronnin, Florent : "AVA: A large-scale database for aesthetic visual analysis", CVPR 2012 ↩ Shu Kong, Xiaohui Shen, Zhe Lin, Radomir Mech, Charless Fowlkes : "Photo Aesthetics Ranking Network with Attributes and Content Adaptation", ECCV 2016 ↩ Haotian Liu, Chunyuan Li, Yuheng Li, Bo Li, Yuanhan Zhang, Sheng Shen, Yong Jae Lee : "LLaVA-NeXT: Improved reasoning, OCR, and world knowledge", https://llava-vl.github.io/blog/2024-01-30-llava-next/ 2024 ↩ 上林駿希, 増井建斗, 新恭兵, 包含, 鹿島久嗣, 大谷まゆ, 竹内孝 : "項目反応理論を用いた視覚言語モデルのマルチモーダルな推論能力および問題特性の評価", https://doi.org/10.11517/pjsai.JSAI2025.0_3N6GS701 ↩ Xiang Yue, Yuansheng Ni, Kai Zhang, Tianyu Zheng, Ruoqi Liu, Ge Zhang, Samuel Stevens, Dongfu Jiang, Weiming Ren, Yuxuan Sun, Cong Wei, Botao Yu, Ruibin Yuan, Renliang Sun, Ming Yin, Boyuan Zheng, Zhenzhu Yang, Yibo Liu, Wenhao Huang, Huan Sun, Yu Su, Wenhu Chen: "MMMU: A Massive Multi-discipline Multimodal Understanding and Reasoning Benchmark for Expert AGI", CVPR 2024 ↩ 山里飛鳥, 小山航平: "反論・再考プロンプトによるHallucination検出手法の提案", https://doi.org/10.11517/pjsai.JSAI2025.0_1Win429 ↩ Potsawee Manakul, Adian Liusie, Mark Gales: "SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models", EMNLP 2023 ↩ JAQKET: クイズを題材にした日本語QAデータセット https://www.nlp.ecei.tohoku.ac.jp/projects/jaqket/ ↩ 藤田真伎, 駒田拓也, 吉村健, 藤本拓, 白水優太朗, 川口貴子: "反復サンプリングを活用したLLM推論時の外部情報検索機能の最適化", https://doi.org/10.11517/pjsai.JSAI2025.0_1Win443 ↩ 石井愛, 井之上直也, 鈴木久美, 関根聡: "JEMHopQA: 日本語マルチホップQA データセットの改良", 言語処理学会 2024 ↩ 萱場啓太, 山岡裕司: "長文コンテキスト質問応答における大規模言語モデルによる誤引用文の訂正手法の提案", https://doi.org/10.11517/pjsai.JSAI2025.0_2H4GS1102 ↩ https://hotpotqa.github.io ↩ 中川慎二, 小松亮太, 惠木正史: "LLM内部演算値を用いたLLM回答の信頼度定量化とOOD検知方式", https://doi.org/10.11517/pjsai.JSAI2025.0_1Win446 ↩

はじめに 背景 アーキテクチャ紹介 知見・ノウハウ まとめ はじめに こんにちは、イノベーションセンターの村田です。 NTTドコモビジネス株式会社は、日本最大級のネットワーク展示会である 「Interop Tokyo 2025（会場：幕張メッセ、会期：2025年6月11日〜13日）」 において構築される ShowNet に対し、全国の放送局からの映像を伝送するネットワークの一部をコントリビューションしました。 本記事では、映像伝送を実現したアーキテクチャ、およびその過程で得られた知見・ノウハウをお伝えします。 背景 Interop の準備から本番までは、次の3期間に分かれて進行します。 全国の放送局からの映像を伝送するネットワークについても、それぞれの期間に応じた検証・運用が行われました。 Pre-HotStage 期間（2025年5月12日〜29日） ShowNet を構築する前段階として、放送局の端末と渋谷の映像機器を接続し、映像伝送の可否確認やパフォーマンステストを実施。 HotStage 期間（2025年5月30日〜6月6日） ShowNet をゼロから構築・検証する期間であり、放送局の端末と幕張の映像機器を接続して、同様の映像伝送検証とパフォーマンステストを実施。 会期（2025年6月11日〜13日） 来場者へ ShowNet の披露が行われる中、放送局から幕張会場までの映像伝送を運用。 私たちがコントリビューションしたのは、上図のネットワークの赤い箇所となります。 全国の放送局から ShowNet までの映像伝送を安全に実施するため、ネットワークにはセキュア（閉域）かつ高信頼であることが求められました。 映像伝送を実現するために、以下のサービスを活用しました。 アクセスプレミアム フレキシブルモバイルアクセス（FMA） （以下、FMA） 放送局のモバイルネットワークに対し、交換機と仮想ゲートウェイを提供 Flexible InterConnect （以下、FIC） AWS や ShowNet 、FMA の仮想ゲートウェイに対し、閉域ネットワークを提供 Amazon Web Services (以下、AWS) Pre-HotStage 期間に、放送局端末と渋谷の映像機器をつなぐ模倣環境として活用 IOWN Open APN FIC から ShowNet までを、フォトニクスネットワーキングのオープンアーキテクチャで接続 アーキテクチャ紹介 私たちがコントリビューションしたアーキテクチャはこちらです。 FIC-Router 各放送局とバックアップ回線を AWS へ接続する仮想ルーター FIC-Port ShowNet からの物理回線を終端して FIC-Router へ接続するリソース AWS Direct Connect ゲートウェイ （以下、DXGW） FIC-Router と AWS を接続 AWS Site-to-Site VPN AWS と Pre-HotStage 拠点を接続 AWS Transit Gateway （以下、TRGW） 上記の AWS リソースを集約接続するルーター 放送局 3 局とバックアップ回線の計 4 本の接続に対し、FIC-Router ごとに個別の DXGW と異なる AS 番号を割り当て、経路を分離しました。 FIC-Router と各 DXGW、DXGW と TRGW、TRGW と Site-to-Site VPN はそれぞれ BGP により相互接続され、会期中はトラブル無く映像伝送を実現できました。 映像伝送するメインのネットワークは上図の通りですが、HotStage 期間中も Pre-HotStage 期間で作成した AWS への接続を維持し、接続検証やパフォーマンス評価として効果的に活用できました。 知見・ノウハウ 今回のコントリビューションを通じて得られた知見・ノウハウを2つ紹介します。 1つめは、FIC のモニタリング機能を活用したトラブルシュートの効率化です。 FIC は各 BGP コネクションの接続状況や受信経路をグラフィカルに表示します。 例えば、BGP コネクションが成立すると緑、不成立なら赤を示します。 HotStage 期間中、FIC-Router と ShowNet 間で 4 つの BGP コネクションを順に確立し ping 確認したところ、4 つめだけ疎通できない事象が発生しました。 ShowNet 側のルーターから FIC-Router の詳細状況を確認できず、原因特定が難しい状況でした。 しかし、FIC のモニタリング画面で 1 つの BGP コネクションが赤く表示されており、疎通不可原因がコネクション不成立によるものと特定できました。 これにより迅速な復旧が可能となり、現場対応の効率化につながりました。 2つめは、柔軟な検証・トラブル対応を可能にするネットワーク設計です。 Pre-HotStage 期間中の検証や接続確認の過程で、パフォーマンス測定やトラブルシューティング用の仮想マシンが必要になりました。 TRGW をハブとする構成にしていたため、必要な仮想マシンをすぐに各ネットワークと接続でき、突発的なニーズにも柔軟に対応できました。 実際に用意した仮想マシンは、検証用途だけでなく本番中の状況確認にも活用され、安定運用を支える重要な要素となりました。 まとめ 本記事では、全国の放送局からの映像を ShowNet へ伝送するネットワークのアーキテクチャと、そこで得た知見・ノウハウを紹介しました。 今後もネットワークとクラウドの連携検証をさらに進め、得られた知見をもとに、柔軟で高信頼なネットワーク構成の展開に取り組んでまいります。

NTTコミュニケーションズ開発者ブログチームの小林です。 私たちNTTコミュニケーションズ株式会社は、明日2025年7月1日より社名をNTTドコモビジネス株式会社と改め、NTTグループの法人向け総合ICT事業の中核として新たな出発を迎えることとなりました。 www.ntt.com これに伴い、1999年の設立より親しまれてきたロゴマーク（シャイニングアーク）と、NTT Comの名称については、本日で利用を終了します。 NTT Comの設立は、ちょうど26年前の1999年7月1日でした。長距離・国際通信事業を担う存在としてスタートを切り、いまその歴史に区切りを迎えることとなります。音声通信と固定回線が中心だった事業環境は、その26年の間に大容量のデータ通信と固定・モバイルの複合環境に変化してきました。クラウドやセキュリティなど扱う領域も広がり、私たちの開発者ブログでもそうした記事をたびたびお届けしてきました。 とはいえ、私たちの仕事は明日からも変わらず続いていきます。もちろんこのブログも続きます！（ドメイン、記事URLもそのままです）　ただちょっと見た目が変わります。せっかくなので、タイトルロゴだけ先行公開します。 ちなみにここまでのNTT Com Engineers' BlogのStatsです。 記事数： 543件 うち、2021年のリニューアル後に書かれた記事： 324件 累計はてブ数： 14604件 読者のみなさまのおかげで続けられています。ライターにとっても大きな励みになっています。ありがとうございます。 今回、同じくドコモグループのNTTコムウェア株式会社もNTTドコモソリューションズ株式会社に、NTTグループにおいても日本電信電話株式会社がNTT株式会社に、といったように複数社の商号が変わります。併せてCIも刷新します。新たなステージに進むNTTグループ、ドコモグループの今後にぜひご期待ください！

こんにちは、イノベーションセンターの安井です。 この記事では、Open XR Opticsという新しい光伝送技術が実装されたトランシーバーの実機検証結果をご紹介します。 本記事で以下を扱います。 1つの光信号を複数に分け、柔軟な帯域保証を可能にする新技術「Open XR Optics」 実機を用いた検証により、その基本性能、障害からの復旧挙動、そして実用上の注意点 5G基地局やデータセンター間接続など、将来のネットワークを支える技術の展望（可能性と課題） P2MP技術 Open XR Opticsとは 検証 検証構成 基本動作の確認 パワー 周波数 自動調整の完了に要する時間 障害復旧の挙動 CH番号を衝突させた場合の動作 ROADM を途中に入れた場合の干渉 今後の展望 1. 省電力・小型化 2. マネジメント・セキュリティ機能 3. 復旧時間短縮 P2MP技術 光ファイバ通信においてPoint-to-Multipoint（P2MP）とは、1つの局から複数のユーザと同時に通信するトポロジーを指します。 現在の主流方式はパッシブ光ネットワーク（PON） 1 です。 PONでは光スプリッターを用いて1本の光ファイバ回線を複数ユーザに分岐共有し、単一の局（OLT）から多数のエンドポイント（ONU） 2 へ通信します。 FTTHやモバイルフロントホール 3 で広く採用されています。 P2MP方式のメリットは、一本の光ファイバや装置で多数のユーザをまとめて収容できるコスト効率にあります。 通信事業者は機器やファイバ敷設の費用を大幅に削減できます。 一方でデメリットもあり、1波を時間で分割するTDM・TDMA方式 4 のため、ユーザ毎の帯域は同時アクセス数に左右され帯域保証が難しいです。 また従来型のGPONやXG-PON等 5 では下りに対し上り速度が遅く、映像配信やビデオ会議など上りを多く使う用途でボトルネックの原因となります。 さらに、TDMA制御による通信遅延およびその揺らぎ（ジッタ）が発生し、リアルタイム性が求められる用途では制約があります。 Open XR Opticsとは 近年、帯域保証型の光伝送方式の1つとしてデジタルコヒーレント方式が普及しています。 光信号の振幅や位相といった波の性質をデジタル信号処理で高度に制御し、従来よりも長距離かつ大容量の通信を可能にした技術です。 主に長距離のバックボーン回線や都市・DC間の大容量通信で広く利用されていますが、Point-to-Point（P2P）接続に限られており、P2MP構成を実現できません。 Open XR Opticsは、1つの光信号をデジタル信号処理によって複数のチャネル（サブキャリア）に分割することで、P2MP構成でも帯域保証型の光伝送を実現します。 各サブキャリアは独立に変調・復調・帯域制御が可能であり、異なる宛先ごとに必要な帯域を柔軟に割り当てて送信できます。 例えば400GbpsのHub側（集約側）トランシーバーからは、25Gbpsのサブキャリアを最大16本生成可能です。 Leaf側（各末端側）には必要な帯域分だけのサブキャリアが割り当てられ、P2MP接続が実現します。 PONとOpen XR Opticsの違いを下表にまとめました。 項目 パッシブ光ネットワーク（PON） Open XR Optics 通信方式 TDM/TDMA（時間分割） DWDM（波長分割） 帯域 共有（ベストエフォート） 専有（帯域保証） 遅延 TDMA制御による遅延・ゆらぎあり 極めて小さい 主な用途 FTTH（一般家庭向け） 5G基地局、企業拠点間接続 コスト 低コスト 比較的高コスト ここからは、Open XR Opticsの特徴をもう少し具体的に説明します。 柔軟な帯域制御と帯域確保: 400Gコヒーレント信号を25G単位のサブキャリアに分割し、必要に応じて1ユーザに複数サブキャリアを割り当てられます。 これにより、各Leaf側ノードへの帯域配分を需要に合わせ調整可能です。また1サブキャリアは専有帯域のため、他ユーザの影響でスループットが低下することはありません。 PONのようにフレーム単位でのTDMA制御が不要なため遅延も極めて小さいです。 双方向（Bidirectional: BiDi）伝送対応: 通常のコヒーレントトランシーバーのような2芯伝送だけではなく、1芯の光ファイバで1芯双方向通信（BiDi）を行うことが可能です。 PON等のアクセス系ネットワークではファイバのコストを抑える目的で、往復に別々のファイバを用意せず1芯で下りと上りを異なる波長に分けて同時伝送しています。 同様にXR OpticsでもHub-Leaf間は一本の光ファイバで接続可能で、異なるサブキャリア（波長）を上下に割り当てることでBiDiを実現します。 既存光インフラとの親和性: XR OpticsはPONと同様に光スプリッターを用いたP2MPですので、既存のアクセスネットワーク用ファイバをそのまま活かすことができます。 また、XR OpticsはCバンド帯 6 （波長1530 - 1565 nm）のコヒーレントDWDM技術 7 ですが、この波長帯は主流方式のGPON等では利用されていないため、既存のPONを使用するファイバにオーバーレイが可能です。 これにより、新規にファイバを引き直すことなく現行PON網に高帯域サービスを追加導入することも検討できます。 ただし、コヒーレントDSP（デジタル信号処理プロセッサー）を搭載したトランシーバは現状ではPON用ONUなどより高価で消費電力も大きく、搭載可能な装置も限られます。 つまり大量の宅内ONUを安価に配布するFTTH用途には不向きであり、むしろ高帯域を要求する5G基地局や企業の拠点間接続、メトロアクセス回線の集約などに適しています。 Open XR Forumのwhite paperでは、主に次のような利用シーンが想定されています。 今後さらに決定的なユースケースが現れることにも期待しています。 Open RAN 8 ／モバイルxHaul 9 向け: 基地局〜集約装置間をP2P、あるいは複数局をP2MPで束ねる 企業拠点間の専用線サービス PONオーバーレイ型専用線サービス: 既設PONファイバにCバンドを重畳し、中小拠点をP2MPで収容 メトロネットワーク集約: P2MPを柔軟に組み合わせて回線数を削減 次章では、実際にXR Optics機器を用いた検証環境を構築し、そのユースケース適性や動作検証結果を紹介します。 検証 実際に Open XR Optics のQSFP-DDトランシーバーをHub 1個/Leaf 2個（最大 100G x2）使用し、検証を実施しました。 住友電気工業株式会社から Open XR Optics対応スイッチ（FTU9100）や、Infinera社（現在Nokia社の傘下にあります）製のQSFP-DDトランシーバー等を借用しました。 下記写真でサイズ比較すると、同じQSFP-DDの400G OpenZR+ トランシーバーよりもヒートシンク部分が厚いです。 検証構成 Hub 側: QSFP-DD Open XR Optics（400G）トランシーバー 1個 Leaf 側: QSFP-DD Open XR Optics（100G）トランシーバー 2個 スプリッタ: 1:2（50:50） イーサネットテスター: 100Gポート x 4 で最大 200G の双方向試験が可能 基本動作の確認 Open XR Opticsのパワーや周波数設定はほぼ自動です。 下記のような仕様になっています。 パワー Hub：出力パワー指定が可能 Leaf：出力パワーは自動制御 ユーザが明示的に変更する手段はなく、リンクアップ時に自動調整されます 周波数 Hub：中心周波数を指定可能 Leaf：Hubの周波数を中心として自動割り当て スイッチ側でLeaf毎にCH番号を設定すること、HubとのリンクはLeaf毎に別々となります CH番号はHub側の電気レーンとサブキャリアの対応づけを示し、Leaf毎に割り当てるという意味になります 自動調整の完了に要する時間 スイッチ側にHubとLeafとしてのポートを設定した後、リンクアップするまでにパワーと周波数の自動調整にどの程度時間がかかるかを確認しました。 2分岐でリンクアップまで約2分30秒必要でした。 Leaf側トランシーバーは2個のまま、Hub側の設定のみ4分岐にしてみると約4分かかり、分岐数が増えるほど再調整に時間がかかる傾向のようです。 一般的なコヒーレントトランシーバーよりやや遅い印象です。 Hub側のパワーや周波数指定をリンクアップ後に変更する場合、再自動調整のため約2分30秒待つ必要があります。 障害復旧の挙動 Leaf側で物理的な障害が発生した際の動作を確認しました。 ケーブルを抜去し戻した場合、リンクの復旧には30秒要しました。 トランシーバー自体を抜去し戻した場合、自動調整のため約2分30秒かかりました。 いずれも当該LeafのみリンクダウンするためHubや他Leafの通信に影響は及ぼしませんが、やはり再調整を伴う場合は一般的なコヒーレントトランシーバーより復旧が遅くなります。 CH番号を衝突させた場合の動作 leaf側で設定するCH番号はLeaf毎に別々に設定する必要がありますが、故意に設定を重複させた場合の動作を確認しました。 CH番号を故意に重複させると、先に確立しているLeaf（Leaf1とする）はリンクアップしたままですが、後から設定したLeaf（Leaf2とする）はリンクアップしませんでした。 この状態を維持したままLeaf1をリンクダウンさせた場合、Leaf2が元々Leaf1で使用していたCH番号でリンクアップしました。 このことから、CH番号を重複させることで障害や誤設定を契機にリンクの乗っ取りが可能です。 ROADM を途中に入れた場合の干渉 実際のNW応用を想定し、OpenXR OpticsをROADM経由で接続した場合、自動調整機能がROADMと干渉しないかを確認しました。 ROADM区間は実際にデータセンター間の通信で利用している区間（約6km/4.4dB）を使用しました。 Hub側の送信光パワーは手動指定で常時一定のため、問題なくLeafまで到達できます。 Leaf側の自動調整は特に問題なく、ROADMのパワー自動調整機能との干渉は発生せず無事リンクアップしました。 今回は問題ありませんでしたが、ROADMの機種によってはROADMの受光可能範囲が狭めに制限されているため、OpenXR Opticsの自動調整されたパワーが合わずROADMのリンクに悪影響を及ぼす恐れがあります。 今後の展望 検証を通して、OpenXR OpticsがコヒーレントDWDM技術を用いてP2MPを実現したことを確認できました。 Open XR Opticsを実用レベルの運用に適用するは以下のような課題が考えられます。 1. 省電力・小型化 Leaf側でも消費電力や発熱が大きく、QSFP-DDのフォームファクターであるため搭載できる機器は限られます。 より小型・低価格になればアクセス系に適用しやすくなります。 2. マネジメント・セキュリティ機能 ユーザ毎の運用監視のためにサブキャリア単位での状況把握機能と、ユーザ毎のセキュリティを担保する機能が必要です。 今回の検証では未実装でしたが、サブキャリア毎の管理機能を含むマネジメント機能はOpen XR Optics Forumで検討中です。 3. 復旧時間短縮 分岐数が増えた際の再調整時間を数秒レベルに抑えられるかは、適用できるサービスレベルを左右します。 とはいえ概ね動作に問題はなく、多拠点を効率的に収容できる新たな光伝送方式として今後期待できます。 本記事が、Open XR Optics による P2MP 伝送や光伝送技術への理解の参考になれば幸いです。 今後も検証や標準化動向を追いかけ、最新情報を共有していきます。 光スプリッターという電源不要の受動素子で光ファイバを分岐し、一本の光ファイバを複数ユーザ間で共有するネットワーク方式。主に一般家庭向けのFTTHサービスで使用される。 ↩ OLT（Optical Line Terminal）はPONで通信事業者の収容局に設置される装置。複数のONUと通信し、ユーザ側へのデータ送受信を管理する。ONU（Optical Network Unit）はユーザ宅や拠点側に設置される装置。OLTと通信し、光信号を電気信号に変換してネットワーク接続を提供する。 ↩ 携帯電話基地局内の無線装置であるRU（Remote Unit）と基地局制御装置であるDU（Distributed Unit）を接続する区間。DUは複数のRUと接続し、通信を集約する役割を持つ。 ↩ 時間軸で複数ユーザーの通信を順番に切り替え、一本の回線を共有する通信方式。 ↩ GPONは下り最大2.5Gbps、上り最大1.25Gbpsの速度を提供するPONの一種。XG-PONはGPONの後継規格で、下り最大10Gbps、上り最大2.5Gbpsまで速度向上した規格。 ↩ 光通信で一般的に使用される波長帯域（1530〜1565 nm）。伝送損失が最も低い波長であり、長距離・大容量通信で広く用いられる。 ↩ DWDM（Dense Wavelength Division Multiplexing）異なる波長の光信号を一本の光ファイバ上で同時に高密度多重化し、伝送容量を大幅に向上させる技術。 ↩ 携帯電話基地局の無線アクセスネットワークをオープンな規格で構築する取り組み。さまざまなベンダー製品が混在可能で、ベンダーロックインを防ぐ目的がある。 ↩ モバイルネットワークにおけるフロントホール、ミッドホール、バックホールを総称した用語。フロントホールはRUとDU間、ミッドホールはDUとCU（Central Unit）間、バックホールはCUとコアネットワーク間の通信を表す。 ↩

こんにちは、NTT Com　イノベーションセンターのNetwork Analytics for Security（NA4Sec）プロジェクトです。 この記事では、2025年5月20日-23日に開催されたセキュリティカンファレンスBotconf 2025について紹介します。 Botconfとは Team NA4Secとは 講演内容 カンファレンスの様子 おわりに Botconfとは Botconf は"The Botnet & Malware Ecosystems Fighting Conference"の略称で、その名の通り、ボットネットやマルウェアエコシステムに特化した国際的なセキュリティカンファレンスです。 2013年より毎年フランスで開催されており、昨年はNice（ニース）、12回目となる今年はAngers（アンジェ） *1 で開催されました。 本カンファレンスでは、法執行機関・学術機関・CSIRT・脅威分析チームなどを中心に世界中のさまざまな組織から約400名が集結し、最新の分析結果について共有します。 特徴的なのは、その情報共有の深度です。 一部の講演は YouTube で公開される一方、TLP（Traffic Light Protocol） *2 への配慮が徹底されており、オープンな場では共有できない、クローズドなコミュニティだからこそ話せる貴重な情報交換が活発に行われます。 Team NA4Secとは 「NTTはインターネットを安心・安全にする社会的責務がある」を理念として、インターネットにおける攻撃インフラの解明・撲滅を目指すプロジェクトです。 NTT Comグループにおける脅威インテリジェンスチームとしての側面も持ち合わせており、有事において脅威インテリジェンスを提供し、意思決定を支援することもあります。 イノベーションセンターを中心として、NTTセキュリティ・ジャパンやエヌ・エフ・ラボラトリーズからもメンバーが参画し、日夜攻撃インフラ *3 を追跡しています。 今回、Team NA4Secから皆川、神田、鮫嶋の3名がBotconf 2025で講演してきました。 講演内容 NA4Secからは"Operation So-seki: You Are a Threat Actor…"というタイトルで、親ロシア派ハクティビスト *4 グループを長期追跡した分析結果について講演しました。 講演では、ハクティビストを追跡するための技術手法や、それによって明らかになった長期的な活動傾向について共有しました。 さらに、こうした政治的背景を持つ攻撃者と対峙する中で得られた学びとして、「脅威アクターの性質に合わせたインテリジェンス共有」の重要性を提言しました。 非常にセンシティブなテーマでしたが、講演後にはヨーロッパの法執行機関や軍の関係者の方が直接私たちの元へ訪れ、深い関心を示してくれました。 また、「インテリジェンス共有」のパートについては、フランスやインドのリサーチャーからも「我々も全く同じ問題意識を持っている」と声をかけられ、国を越えて意気投合できたのは大きな収穫でした。 現在、日本国内で能動的サイバー防御が大きな展開を見せる中でも、海外の有力な会社・組織と個別の繋がりを築くことができたのは大きな意義があると感じています。 登壇者の鮫嶋(左: @islairand )、神田(中央: @ashy0x41 )、皆川(右: @strinsert1Na ) 本講演で扱った情報の多くは会場限定となりますが、公式サイトに講演資料が掲載されていますので、ご興味のある方はぜひご覧ください。 https://www.botconf.eu/botconf-presentation-or-article/operation-so-seki-you-are-a-threat-actor/ カンファレンスの様子 カンファレンス会場は"Le Parc des Expositions d'Angers"という施設で、アンジェの中心部からバスで20分ほど離れた場所に位置しています。 会場内は広く、多数用意された座席も人気の発表時にはほぼ満席になるほどの盛況ぶりでした。 発表の合間にある休憩時間には、コーヒーを片手にあちこちで参加者同士の活発な交流が見られました。 メインカンファレンス2日目の夜には、立食形式のGala receptionが開催され、世界中の参加者と交流を深めることができました。 おわりに Botconfは、信頼できるコミュニティ内で最新の調査結果をTLPに基づき深く共有できる、世界でも数少ない貴重な場所だと改めて感じました。 次回（2026年）はフランスの北東部、Reims（ランス）で開催されるとのことです。 この記事を読んで少しでも興味を持たれた方は、ぜひ参加を検討してみてはいかがでしょうか。 *1 : フランス西部の都市で、パリから高速鉄道で約1時間30分。住みたい街ランキング上位としても知られる *2 : FIRSTが標準化した機密情報共有のプロトコル 。情報の機微性に応じて「RED（共有禁止）」「AMBER（組織内共有可）」などのレベルで区別し、機密情報の不用意な拡散を防ぐ仕組み *3 : 攻撃者の管理するマルウェアや C&Cサーバ など *4 : 政治的・社会的な意思表示や目的実現のために、ハッキングという手段を用いる活動家。"Hack"と"Activist"を組み合わせた造語

こんにちは、イノベーションセンターの福田です。 NTT コミュニケーションズ株式会社は、日本最大級のネットワーク展示会である 「Interop Tokyo 2025（会場：幕張メッセ、会期：2025年6月11日〜13日）」 において構築される ShowNet に対し、生成 AI と Model Context Protocol (MCP) による 5G コアオペレーション自動化のコントリビューションを行いました。 本記事ではその構築にあたって具体的にどのようなことを開発したのか、その実装を通して得た知見やノウハウを紹介します。 背景 どんなことをしたのか Model Context Protocol (MCP) とは？ サーバー・クライアント・ホスト アーキテクチャ 動かしてみてわかったこと MCP を利用することによるメリット MCP を利用する上での注意点 MCP のツールの網羅性 MCP のツール名について まとめ 背景 5G コアで設定するパラメータは標準の識別子や設定項目を網羅的に対応しようとすると、多数のパラメータ管理が必要になります。 さらにいくつかのパラメータを中心とした依存関係が形成されており、その依存関係にしたがって設定値を更新したり削除したりしなければなりません。 今回、この 5G コアのパラメータを生成 AI で全部あるいは一部を変更することを立案し、生成 AI によるオペレーション自動化にチャレンジするということになりました。 どんなことをしたのか こうした背景から、生成 AI が既存データから必要なデータの構造や値を把握して、オペレータの指示する通りに 5G コアのパラメータを処理する仕組みを作ることになりました。 まず始めに生成 AI の動作環境とモデルについて決めました。 今回、 5G コアの環境が Amazon Web Services 上で構築されるため、そちらに合わせて Anthropic PBC の Claude や Amazon.com, Inc. の Amazon Nova といったさまざまなモデルが利用可能である Amazon Bedrock を用いました。 生成 AI のモデルは Anthropic PBC が提供する Claude 3.7 Sonnet を用いることにしました。 当初、以下のサービスや機能を組合せて実現しようとしていました。 Amazon Bedrock にて機能提供されている Amazon Bedrock Agents による AI エージェント Amazon OpenSearch Service による Retrieval-Augmented Generation を組み合わせた構成を検討しました。 これらのマネージドサービスを用いることで開発工数を抑えながら、事実(既存のパラメータ)に基づいた生成ができると考えたためです。 なかでも Amazon Bedrock Agents には AWS Lambda の関数を設置し、その関数を事前に定義したパラメータで呼び出すことができるという機能があります。 始めはこの機能を用いることで必要なパラメータをやり取りすることを検討していました。 ところが、先述したとおり、 5G コアのパラメータ数が非常に多く用途毎に設定がわかれていました。 そのため、命令の度に柔軟にパラメータ数を幅広く増減させる必要があるのに対し、 Amazon Bedrock のパラメータ定義はデフォルトで5つしか設定できず(※ある程度上限緩和は可能)柔軟さに欠けることが判明しました。 そのため Amazon Bedrock Agents の代替手段の調査にのりだしました。 その中で昨今ホットな話題である MCP を用いることで柔軟にツールの利用やコンテキストの提供を実装可能だということがわかってきたため、 MCP での実装に切り替えました。 その結果 MCP を用いて 5G コアのパラメータを生成 AI が生成・設定可能な構成が実現しました。 さらにオペレータ側が自然言語による指示を実施すると生成 AI の方でその指示に合わせて各種パラメータ操作のオペレーションを実施するサービスを実装することに成功しました。 以下ではその実装を通して得られたノウハウや実際の構築例を通して MCP の使い所について共有します。 Model Context Protocol (MCP) とは？ まず、本題へ入る前に何度か出ている Model Context Protocol (MCP) について知らない方向けに解説をします。 もしすでにご存知であれば本章は読み飛ばしていただいて構いません。 Model Context Protocol (MCP) は Anthropic PBC が提唱する、 AI モデルが各種サービスやさまざまなドキュメントへのアクセス、写真や画像といったものを統一して扱えるようにするためのオープンなプロトコルです。 Anthropic PBC は公式ドキュメントの中で AI 用の USB-C ポートという表現を用いていますが、まさしくその表現の通り AI モデルがさまざまなものへアクセスするのに使用する統一的なインターフェースを提供します。 Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools. ref: Model Context Protocol - Introduction 最近では AIOps という AI によるシステムの運用を自動化するパラダイムが提唱されていますが、日々さまざまな機能の開発や改修が行われているサービスやシステムを AI が扱うにはそれらのサービスのさまざまな操作方法や知識を AI も取り込まなければなりません。 そこで AI モデルを開発する各社では生成 AI にツールを操作させたりコンテキストを提供する方法を提唱しています。 たとえば ChatGPT を提供する OpenAI では Function Calling という AI がツールを呼び出すためのインターフェースを定義しています。 MCP もそのうちの1つですが、 Function Calling が構造上、生成 AI の実行環境に合わせてその処理フローを実装する必要があるのに対し、以下に説明するクライアント・サーバーの構造を取ることで個別の処理フローを実装する必要がなくなっています。 サーバー・クライアント・ホスト MCP は以下の3つのコンポーネントからなります。 サーバー AI が利用したいサービスやシステムに MCP で通信させるためのインターフェースを提供する クライアント サーバーと接続するためのインターフェース ホスト IDE などの MCP を利用した処理を行うプログラム ref: https://modelcontextprotocol.io/introduction これらはアプリケーションやコンテナーで1つにまとめられる場合もあれば別々に運用されることもあります。 これらを適切に実装・提供して組み合わせることで AI がさまざまなシステムやサービスを操作できるようになります。 アーキテクチャ ここまで MCP について解説しました。 本項ではこの MCP を実際に 5G コアオペレーション自動化のミッションを解決するにあたってどのようにシステムに組み込んでいったのかをアーキテクチャの観点から解説します。 今回我々が自動化するにあたって作ったシステムは次の通りです。 5G コアのパラメータは Amazon Relational Data Service へ保管されており、その DB 自体は 5G コアが操作するものであったため直接書き込み操作はせず、変わりとして GitLab 上にパラメータが設置してあり、そのパラメータを操作すると 5G コアに設定が同期するようになっていました。 そこで、 DB については直接書き込みをしないようにリードレプリカを作成し、ここから最新の 5G コアパラメータを取得できるようにした上で生成した 5G コアパラメータを GitLab へ書き戻す、という構成をとることになりました。 この構成を元に、我々は以下のコンポーネントでオペレーション自動化システムを作成することにしました。 DB のリードレプリカから 5G コアパラメータを取得する REST API サーバー オペレータが生成 AI とやりとりし、生成 AI が指示された内容をもとに REST API サーバーや GitLab を操作する MCP ホスト AI モデルを提供する Bedrock このうち、 REST API サーバーは Amazon Elastic Kubernetes Service (以下、 EKS) を構築し、その上でサービスとして公開しました。 サービスは同一ネットワーク上からアクセスできるように Elastic Load Balancing における Network Load Balancer を使ってネットワーク内に公開しました。 また、 MCP ホストはパブリックな場所に Amazon EC2 の インスタンス を設置し、その上に Docker Compose 化して動作させました。 これによってユーザーがインターネットを通してインスタンスから MCP へアクセスできるようにしています。 今回、 REST API サーバーと MCP ホストは元々ローカル環境で開発・検証しやすいようにコンテナー化して Docker Compose にて検証基盤を立ち上げて検証できるようにしていました。 本来であればこの Docker Compose 環境と同じように EKS や Amazon Elastic Container Service で REST API サーバーと MCP ホストを配置すると思います。 ですが今回は短い期間で上記環境を動作させねばならなかったことや頻繁に変更を伴う検証をしながら実装したため、実装・スケジュール優先で確実に実現できる形で実施しています。 動かしてみてわかったこと 今回上記環境を構築してみていくつかわかったことがあるため紹介します。 MCP を利用することによるメリット 今回、 MCP を実装・利用してみると、実際に Anthropic が述べているような MCP は USB-C のようなものであるということが実感できました。 MCP 自体はまさしくさまざまなシステムを AI が操作しやすくするための標準化手法であり、その点こそ利用することのメリットになっていることを実感しました。 システムがどんなツールを提供しているのかや、どんなコンテキスト情報を与えられるのか、システムを上手く使うためにはどのようなプロンプトを提供する必要があるのかといったことを統一されたインターフェースで提供します。 これによって AI は各システムの実装差異であったりインターフェースの違いといったものを意識せずに統一した方法でアクセスできます。 ちょうどプログラミング言語におけるインターフェースと同じように中身を知らなくてもその操作方法さえわかってしまえばいいわけです。 MCP そのものは新しい技術ではなく既存技術の組み合わせで実現されているため、技術的な部分で押さえておかなければいけないところは少ないです。 ですが、標準化によって生成 AI が事前に知識がなくてもシステムを操作できることが示されたというところは押さえておく必要があります。 MCP を利用する上での注意点 MCP のツールの網羅性 実装途中で気付いたのですが、生成 AI が MCPでシステムを上手く操作できるかは、 MCP サーバが提供するツールの網羅性に左右されます。 たとえば今回使用した GitLab MCP Server でその網羅性が問題になりました。 今回、生成 AI が GitLab のリポジトリーからファイルを探索する際に ファイルの中身を取得する API を使っていました。 この API はディレクトリー名を指定すると 404 Not Found を返すような仕様になっていました。 このエラーを生成 AI はエラーがあったという事実だけを見てしまい、ファイル探索ができないと判断して所望のファイルを取得するところまで実施せず、探索を打ち切ってしまうようになっていました。 その影響でファイルが検索できずに新しい探索タスクを再度実施するという事象が発生するようになっていました。 そのため、パラメータ変更操作のようなファイルを特定する探索タスクがあるとその探索途中にエラーを認識しては再度探索をためすという操作を繰り返してしまい、全体として操作にかかる時間が長くなってしまうという事象が発生しました。 そこで我々の方で GitLab MCP Server へファイルをリストするツールを実装してみました。 すると生成 AI 側で探索タスクの処理内容を以下のように変更してくれました。 リストするツールを用いてファイルの位置を把握 ファイルの中身を取得する API を実行 これによってファイルの中身を取得する API でディレクトリー名を指定してエラーになるのを防ぐことができました。 さらにエラーの発生が抑えられることで探索の繰り返し頻度も少なくなり、生成 AI が実施する探索の時間を非常に短く抑えることに成功しました。 このように、提供される MCP サーバーのツールに網羅性がないと生成 AI は期待通りにシステムを操作してくれません。 さらに生成 AI が別の方法を試そうとするも提供できるツールは同じであるために何度も同じツールをつかってエラーを発生させるということを繰り返すようになってしまいます。 もし MCP サーバーを実装する場合は生成 AI にどんな操作をしてどんな値を返し、どんなエラーを返すのかというところを洗い出しておく必要がありあす。 MCP のツール名について 今回実装してみてツールの名前には名前空間の概念がないことに気が付きました。 そのため、 MCP サーバー側は提供するツールの名前衝突に十分気を付ける必要があります。 GitLab MCP Server を参考にすると、以下のようにツール名で switch している箇所が見受けられます。 /** * ref: https://github.com/modelcontextprotocol/servers-archived/blob/9be4674d1ddf8c469e6461a27a337eeb65f76c2e/src/gitlab/index.ts#L420-L500 */ switch (request.params. name ) { case "fork_repository" : { // ツールの処理 } case "create_branch" : { // ツールの処理 } // ... } たとえば MCP サーバー A がツール名 tool_a を持ち、同時に MCP サーバー B が同じツール名 tool_a を持っている状況で、双方を利用するように設定している場合は、クライアントが正しくツールを使い分けられない可能性があります。 MCP の中には各ツール定義でツールの説明を定義する description というものがあり、こちらを活用することでどういったツールなのかを生成 AI にヒントとして与えることができます。 内容が適切に設定されていれば AI も呼び出すツールを使い分けてくれるはずですが、実装・運用の際には利用する MCP サーバーの各 descirption の重複には気を付けておく必要があります。 /** * ref: https://github.com/modelcontextprotocol/servers-archived/blob/9be4674d1ddf8c469e6461a27a337eeb65f76c2e/src/gitlab/index.ts#L363-L369 */ return { tools: { { // ツール名 name : "create_or_update_file" , // ツールがどんなツールなのかの説明 description: "Create or update a single file in a GitLab project" , // ツールが受け取るパラメータのスキーマを定義 inputSchema: zodToJsonSchema(CreateOrUpdateFileSchema) } , // ... } } まとめ 本記事では 5G コアのオペレーション自動化のノウハウや知見と、その中で実感できた MCP の実体とその注意点について紹介しました。 今回、 MCP によって GitLab の操作や DB からのパラメータ取得を統一したインターフェースで扱えるようになり、実装にかかる時間が少なく済み、提供まで短い期間でありながらもシステムを構築して提供できました。 本来であればシステム毎に API を調査したり、その API を組み合わせて目的を達成するためのコードを書く必要がありますが、 MCP のツールという形によって生成 AI へ提供することで生成 AI 側が実現したいことに合わせてツールを組み合わせて呼び出してくれるため、こちらが作らなければならない API を少なく済ませられました。 また、実際に構築してみることで、以下の MCP の実装における注意点や良い部分などを知ることができました。 MCP による統一したインターフェースの実現 MCP の品質確保について MCP のツール名衝突の可能性 今回作成したものは ShowNet の映像伝送で使われるキャリア5Gのコアネットワークの構築・運用で実際に利用されました。 今回我々は 5G コア自動化オペレーションの部分を構築しましたが、実際に利用されたシステムについては NTTドコモの開発者ブログ にて紹介しております。 是非そちらもご覧ください。 今後も AI による自動化の推進やさまざまなネットワークとクラウドを接続する方法についての検証を進めつつ、サービスへの応用を検討していきます。

こんにちは。5G＆IoTサービス部の池です。IoT向けコネクティビティサービスの販売企画を担当しています。 これまで、「Active Multi-access SIM開発シリーズ」として、2回にわたりその特長や仕組み、開発秘話などをご紹介してきました。最終回となる今回は、モバイル回線に求められていることの変化、そしてActive Multi-access SIM(※)（以下、マルチアクセスSIM）の技術がこれからどのように進化していくのかについてお届けします。 これまでの記事はこちら 第1回： 1枚のSIMでキャリアを冗長化！Active Multi-access SIMの特長と仕組み 第2回： 開発の舞台裏〜Active Multi-access SIMが生まれるまでの挑戦と特許取得 ※ Active Multi-access SIM：SIM1枚でキャリアの冗長化が実現できるIoT向けモバイルサービス。通信の監視と通信障害を検知してキャリアを切り替える機能がSIM自体に実装されています。 市場の動向とお客さまのニーズの変化 マルチアクセスSIMの今後の展望 まとめ 市場の動向とお客さまのニーズの変化 近年、企業や店舗、工場などの通信環境において、モバイル回線の活用が拡大しています。 新しい拠点の立ち上げや、システムの更改をきっかけに、光回線を引かずに無線通信を採用するケースが増えているようです。 例えば、小売店では、これまで光回線を利用してマルチコピー機やATMなどのシステムを運用するのが一般的でした。 しかし最近では、 店舗のレイアウトなどの設置環境に左右されにくく、導入しやすいことから、モバイル回線を活用する動き が広がっています。 デジタルサイネージ（電子看板）も、その流れの1つです。ディスプレイを使って広告や店舗情報、キャンペーンなどを表示するデジタルサイネージは、小売店や商業施設での情報発信に欠かせない存在となっています。 もともとは光回線を前提としたものも多かったのですが、最近では通信料金がサービス料に含まれているモバイル回線対応型が増え、光回線を引く必要がない点が評価されています。これにより、 工事の手間や高額な工事費が不要になるだけでなく、設置場所の自由度も高まりました 。 最近では、そもそもモバイル回線を前提とした施設も増えているようです。 たくさんの店舗がそれぞれ有線で回線を準備しようとすると、配線が複雑になってしまい、管理が大変になります。そのため、施設全体でモバイル回線を活用することで、通信環境の整備や増設をスムーズにしようという流れがあるのかもしれません。 また、キャッシュレス決済の普及も進み、クレジットカードに加えて、2次元バーコード決済などの対応も求められるようになり、決済端末の世代交代が進んでいます。これに伴い、タブレット型のレジを導入する店舗も増え、モバイル回線を使って決済できる環境が整ってきました。 とはいえ、 通信が途絶えてしまうと決済ができなくなるという課題 もあります。 モバイル回線では SIM を用いてキャリアとの通信をしていますが、過去にキャリアの通信障害が発生した際には決済ができなくなり、大きな影響を受けた店舗もありました。最近では、現金を持ち歩かない人が増え、店舗側も（徐々にですが）キャッシュレス決済のみを採用するケースがあるため、「 通信が常に使える状態であること 」は、ますます重要になっています。 マルチアクセスSIMの今後の展望 「 1枚のSIMでキャリアを冗長化！Active Multi-access SIMの特長と仕組み [Active Multi-access SIM開発シリーズ 第1回（全3回）] 」でも述べましたが、マルチアクセスSIM の以下の特徴により上記のようなキャリアの通信障害にも対応できます。 1枚のSIMで2つのキャリアに接続可能 SIMの機能により自動でキャリアの切り替えが可能 IoTソリューションでは、離れた場所にあるデバイスから一定の間隔でデータをアップロードしたいというニーズも多くあります。そのため、万が一通信障害が発生して長時間に及んだ場合でも、現地での操作なしにキャリアを切り替えられる機能が求められています。マルチアクセスSIMは、 ファームウェアの改修などを行わなくても汎用端末で対応できる 点が評価されており、こうした課題の解決に貢献しています。 また、キャリア障害時の切り替えだけでなく、ローカル5G網と公衆モバイル網を自動で切り替えたいというご要望に応えるため検証を進めています。 お客さまのネットワーク環境に応じて適切なモバイル網を選択 できることで、より利便性の高い通信環境を構築できます。さらに、ローカル5G網とのマルチアクセスは、将来的に「IoT向けモバイルデータ通信サービス『 IoT Connect Mobile Type S 』」のオプションメニュー化し、商用提供することを検討しています。これにより、IoTデバイスの通信の柔軟性がさらに向上し、多様な環境での活用が期待されます。 本技術に関しては、こちらの記事「 ローカル5G網と公衆モバイル網への接続を切り替え可能なSIMアプレットの開発 」もぜひご参照ください。 ユースケース1 ：鉄道や自動車、バスなど、免許交付がされているローカル5Gエリアと公衆モバイルエリア間を移動する際、人手による操作を介することなくアクセスネットワークを自動で切り替えて通信を継続させる ユースケース2 ：ローカル5Gシステム障害のバックアップ回線として公衆モバイル網に自動で切り替えることで、冗長化による高可用性を維持させる 加えて、マルチアクセスSIMでは、サービス開発中から多くの問い合わせが寄せられていた 閉域接続への対応 も進めています。 特に、機密性の高い業務を扱う業種では、クラウド環境へのデータ保管や通信に対して慎重な姿勢を取る企業も少なくありません。製造業はその一例であり、製品設計や製造工程などに関わる独自ノウハウの流出リスクなどを警戒して、従来からニーズがある、 インターネットを経由しないセキュアな通信環境 = 閉域網 を活用しているケースも多く見られます。 また、IoTの特徴として、導入するデバイスの数や種類が多いという点が挙げられます。さらに、IoTデバイスは、低コスト・小型・軽量化が求められるため、セキュリティ機能を十分に搭載しにくい場合があります。そのため、デバイス側だけに依存せず、ネットワーク側でもセキュリティ対策を講じることが重要であり、その手段のひとつとして閉域網の活用が有効です。 昨今では、導入目的や活用範囲そのものが複雑化しているため、それぞれのセキュリティ要件や通信特性に応じたネットワークの対応が求められています。 こうした背景から、マルチアクセスSIMでも閉域接続へ対応することにより、より セキュアな通信環境と、キャリア障害時の自動切り替えによる高可用性の両立 が可能となります。 IoTでは、デバイスが遠隔地や人の手が届きにくい場所に設置されるケースも多く、万一通信障害が発生した際に、すぐに技術者が現地対応することが難しいという運用上の課題もあります。そのため、現地に人が行かなくても自律的に回線を切り替えられる仕組みが求められており、マルチアクセスSIMはこうした要望に応える機能を備えています。 マルチアクセスSIMは、商用サービスの提供開始以降、多くの引き合いをいただいており、フィールドテストなどのご支援をさせていただいています。その中で、一部のOSを搭載した端末においては、やや複雑な端末設定が必要となる場合があることも明らかとなり、ひとつひとつ解決を図ってきました。 こうして蓄積されたナレッジをお客さまに還元していくことで、今後ますます多くのIoTの冗長性の課題にお応えし、お客さまのビジネスの発展やDX推進に貢献できるよう、引き続き取り組んでまいります。 まとめ これまで3回にわたり、マルチアクセスSIMの技術と開発の裏側、そして市場の変化や今後の展望についてお伝えしてきました。 モバイル回線の活用が拡大する中で、通信の可用性はもちろん、柔軟性や導入のしやすさなど、多くのことが求められています。マルチアクセスSIMは、キャリアの冗長化を手軽・簡単に実現するコネクティビティサービスとして注目されています。 これからもお客さまのニーズに応え、より利便性が高く、魅力的な特長を持ったサービスを提供できるよう取り組んでまいります。 今後もNTTコミュニケーションズが提供するサービスにご期待ください！ 今回ご紹介したマルチアクセスSIMの詳細情報についてはこちらをご参照ください。 マルチアクセスSIMのオフィシャルサイト Active Multi-access SIM｜ドコモビジネス｜NTTコミュニケーションズ 法人のお客さま また、本サービスは1枚からWeb購入・検証可能です。まずは試してみたいという方はぜひ以下のページからお申込みください！ ドコモビジネスオンラインショップ IoT Connect Mobile® Type S｜ドコモビジネスオンラインショップ｜NTTコミュニケーションズ 記事に関するお問い合わせは、 iot-connect＠ntt.com 　までメールでご連絡ください。 ※お手数ですが、＠を半角文字に置き換えてください