※ この投稿はお客様に寄稿いただいた記事です。 本稿は、NTTドコモ モバイルイノベーションテック部（以下、MIT 部）が AI-DLC TTT でフィジカル AI 領域の ML パイプラインを構築した取り組みの第 2 回です。 第 1 回：フィジカル AI 領域での ML 開発への適用 第 2 回：2 チーム並行開発の実験結果と知見（本記事） 第 1 回では、AI-DLC の Inception フェーズで要件を構造化し、設計レビューで 11 個の不整合を事前に検出した取り組みをご紹介しました。 第 2 回では、Construction フェーズでの 2 チーム並行開発の実験結果と、得られた知見についてご紹介します。 6. Construction フェーズ：パイプラインの実装（Day 2–3） Inception フェーズで作成した計画に沿って実装を進めました。 両チームとも同一のパイプライン構造を採用しつつ、細部の設計判断に違いが生まれました。 共通アーキテクチャ 両チームが構築したパイプラインの基本構造は以下で共通です。 図：データフロー（act_demos.npz → 座標変換 → 蒸留 → PPO → 評価） 蒸留 MLP の検証 MSE（Mean Squared Error）< 0.01 を両チームとも達成し、Isaac Lab 上での 1024 並列環境による PPO 学習を実行しました。これにより、パイプライン全体（蒸留→PPO→評価）が一通り接続された状態に到達し、以降はパイプラインの構築ではなく成功率の改善に集中できる段階になりました。 チーム間の設計判断の分岐点 テーマ設定の段階で、強化学習を最終段階とするパイプライン構造は共通ですが、ベースとなるモデルが模倣学習の直接的な出力ではなく RPD 論文に基づく蒸留を経由する設計であり、どのように変換を行うかは未検証でした。Inception フェーズに用いた論文などの事前知識でパイプラインの基本構造（蒸留→PPO→評価）までは両チーム共通でしたが、蒸留の入力次元や KL ペナルティの扱いについては複数の有力なアプローチが考えられ、机上では優劣を判断できませんでした。 そこで、それぞれのチームメンバーが AI-DLC の中で判断したアプローチを採用し、実験結果を比較検証する方針としました。全く同じとなる可能性もありましたが、今回は以下のような差異が生まれました。 設計判断 チームピンク チームブルー パイプライン起点 事前収集済みデモデータ（53 エピソード） ACT 学習→デモ収集から（後述の軌道修正あり） 蒸留 MLP 入力次元 28 次元（環境の全観測空間） 12 次元 → Actor 28 次元入力層の最初 12 列に部分ロード PPO への統合方式 蒸留 MLP 全体を Actor としてロード Actor 入力層の最初 12 列に蒸留重みをコピー、残り 16 列はランダム初期化 KL ペナルティ あり（adaptive β方式、3 パターン検証） なし（RSL-RL デフォルト設定に委譲） 検証の焦点 KL ペナルティの効果検証 蒸留初期化の効果そのものの検証 KL ペナルティの β は、蒸留で得た方策をどの程度信頼するかを制御するハイパーパラメータです。 β が大きいほど蒸留ポリシーからの逸脱にペナルティを強くかけ、小さいほど自由に探索できます。 チームピンクは β=1.0（強い制約）、β=0.5（中程度）、β=0（制約なし）の 3 段階で効果を検証しました。 チームブルーの「部分ロード方式」というのは、蒸留 MLP（12 次元入力）の重みを RSL-RL（Isaac Lab 上で強化学習を行うライブラリ）の ActorCritic（行動出力と価値推定を担うネットワーク構造）における第 1 層の重み行列（256 ニューロン × 28 次元入力）の最初 12 列にコピーし、残り 16 列はランダム初期化のまま学習させます。環境の全観測情報を活用しつつ、蒸留知識を初期値として活かすアプローチです。 7. AI-DLC による軌道修正：チームブルーのスコープ変更 Construction フェーズで、AI-DLC の価値が明確に現れた場面がありました。 チームブルーは当初、ACT モデルの学習からデモ収集までを含む、より上流からのパイプライン構築を目指していました。しかし Day 2 の実装開始直後、ACT 学習環境のセットアップに想定以上の工数がかかることが判明しました。3 日間という制約の中で、ACT の環境構築に時間を費やすとコアの蒸留→PPO→評価パイプラインの検証が間に合わないリスクが生じたのです。 この時点で、AI-DLC のプロセスに従い Inception フェーズに立ち戻りました。タスクリストの優先度を再評価し、以下の判断を行いました。 タスクリスト 変更前 変更後 TL-1 蒸留用データの準備（ACT 学習→デモ収集を含む） 「ACT 学習→デモ収集」を除外。事前収集済みデモデータ（53 エピソード）を起点に変更 TL-2 MLP の蒸留 維持 TL-3 PPO Fine-tune 維持 TL-4 評価と比較 維持 この軌道修正がスムーズだったのは、要件がタスクリストとして構造化されていたからです。「何を削って何を残すか」の判断基準が各タスクリストの優先度として明示されており、チーム全員が同じ根拠で合意できました。具体的には、TL-1（データ準備）が最高優先度であり事前収集済みデータ（53 エピソード）で着手可能である一方、ACT 学習は優先度が低くこの事前データで代替可能だったため、ACT 学習を除外するという判断に至りました。場当たり的な「間に合わないから削ろう」ではなく、構造化された優先度に基づく意思決定です。 結果として、チームブルーはコアパイプラインに集中し、蒸留あり/なしの比較実験（64% vs 90%）という本 TTT で最も価値のある知見を得ることに成功しています。 8. 実験結果：2 チームの比較 両チーム共通の比較基準として、ACT ベースライン（模倣学習のみ、人手デモ 10 件＋COSMOS,Mimic による増幅）の成功率は 45% です。 チームピンク：KL ペナルティの段階的検証 KL ペナルティの有無と強度を変えた 3 回の実験を実施しました。 条件 成功率 累積報酬 備考 蒸留初期化 + PPO + Full KL (β=1.0) 0% -6.72 std 減少を阻害、探索不能 蒸留初期化 + PPO + Mean-only KL (β=0.5) 0% 2.05 探索の早期停止 蒸留初期化 + PPO（KL なし） 11% 1.82 局所最適に陥る チームピンクの成功率が全条件で著しく低かった主因は、後に判明した座標変換の欠落（object_pos のロボットベース相対変換が未実装）でした。蒸留の教師データと RL 環境の座標系が一致していなかったため、蒸留 MLP が誤った方策を学習し、KL ペナルティがその誤りをさらに固定化する結果となりました。TTT 後にこの座標変換を修正し 97% に到達した詳細は後述します。 チームブルー：蒸留あり/なしの比較 RSL-RL をデフォルト設定に委譲し、蒸留初期化の有無を直接比較しました。 条件 成功率 累積報酬 備考 蒸留初期化 + PPO（部分ロード） 64% 56.69 蒸留 12 次元→Actor28 次元に統合 ランダム初期化 + PPO（蒸留なし） 90% 84.44 蒸留なしが最高性能 2 チームの結果が示す知見 蒸留初期化は reaching（接近）を加速するが、lifting（持ち上げ）への移行を阻害する局所最適を生む KL ペナルティは、蒸留ポリシーが偏った方策を学習している場合、探索を制限し逆効果になる 蒸留初期化自体が性能を制限する可能性がある（蒸留なし 90% vs 蒸留あり 64%） RPD 論文の前提（オンライン VLA 推論）を私達の実装（重み固定 MLP）に上手く適応できていない 今回の結果は単一タスク、単一条件での実験であり、RPD の手法自体の評価を確定するものではありません。しかし、2 チームが異なる実験設計（KL の段階的緩和 vs 蒸留あり/なしの直接比較）で同じ傾向を観測したことは、今後の検証を進める根拠にはなると考えています。 9. AI-DLC を ML に適用して得られた知見 方針転換と失敗の蓄積を支えるプロセス 各フェーズ（Inception、Construction、Operation、評価）で成果物が定義されているため、方針転換の判断が容易でした。チームブルーの軌道修正はその好例です。 設計レビューにより、実装前に 11 個の不整合を検出できました。ML 実装では「動くが正しくない」コードが生まれやすく、設計段階での整合性検証が手戻りの防止に直結します。 3 回の実験サイクルと失敗分析はすべて構造化ドキュメントとして残り、次の実験の判断根拠として蓄積されました。 実験サイクルの高速化 Kiro が論文の解釈や数式の意味を解説することで、強化学習、蒸留、Isaac Lab、RSL-RL といった専門領域の理解がチーム全員で揃いました。 この共有された理解が、実験サイクルの速度に直結しています。初回の失敗分析から修正、2 回目のパイプライン実行までが数時間で完了しました。速さの要因は 2 つあります。 Inception で実験の仮説と検証基準がドキュメント化されており、「何を変えて次を試すか」の起点が明確だったこと パイプライン全体の構造と各ユニットの役割を全員が把握しており、原因の切り分けと修正方針の合意に時間がかからなかったこと 一般的な ML 実験では仮説の修正から再実験まで数日かかることが多いですが、今回は 1 日で 3 サイクル回すことができました。 ドメイン専門家の役割をどう位置づけるか Kiro の支援により、ドメイン専門家がいないチームでも動作する ML パイプラインの構築まで到達できました。 一方で、「なぜこの手法がこのタスクで機能しないか」を正確に評価する局面や、RPD 論文の前提条件と実装の差異を見抜く局面では、深い理論的理解が必要でした。Kiro が出力したコードの妥当性を判断できない場面が繰り返し発生し、ML 実装の経験が浅い私たちにはかなり負荷が高かったのが実情です。 この経験から、AI-DLC は「専門家がいないと着手できない」状態を「専門家なしでもパイプラインを構築でき、専門家は品質の最終確認に集中する」状態に変えるフレームワークだと捉えています。AI が論文解釈、コード生成、設計レビューを担うことでチームの知識水準が引き上げられ、専門家がレビューすべき範囲が絞り込まれます。 Inception で生成された設計レビューレポートや実験分析レポートを専門家に共有すれば、常駐せずスポット参加でも的確なフィードバックが可能です。今回の座標変換の問題も、TTT 後に構造化された記録を読み返すことで数時間で原因を特定できました。 今後は、Inception で定義した受け入れ基準（座標値の範囲、入力次元の整合性、損失の収束条件など）を自動テストとして実装し、パイプラインの各段階で機械的に検証する仕組みを導入する予定です。ドメイン知識を実行可能なテストコードに変換すれば、専門家が不在でも品質の劣化を早期に検出できます。 （参考）TTT 後：AI-DLC の継続で 97% へ TTT は 3 日間で終了しましたが、AI-DLC のプロセスは継続可能です。TTT 後に得られた結果を補足します。 座標変換の欠落が真因だった TTT 後、構造化された実験記録を読み返し Inception に立ち戻りました。最優先だった TL-1（座標系変換）の実装を再検証したところ、object_pos の座標変換が欠落していることが判明しました。 ACT のデモデータは LeIsaac のワールド座標系で記録されている一方、RL 環境はロボットベース相対座標系を使用しています。この不一致が蒸留 MLP の学習を破綻させていました。 # 欠落していた変換（修正版で追加） object_pos -= [0.35, -0.64, 0.01] # LeIsaacのロボットベース位置 構造化された実験記録があったため、原因の切り分けは数時間で完了しました。 再蒸留の実装と結果 座標変換の修正に加え、TTT 中の観察（reaching は学習するが lifting が伸びない）に基づき、損失関数を Phase-weighted MSE に変更しました。lifting フェーズの重みを 5 倍にしています。 再蒸留を初期重みにロードし、KL なし PPO で 5000 イテレーション（1024 環境並列、約 52 分）を実行した結果です。 条件 成功率 ACT ベースライン（模倣学習のみ） 45% RL-Only（蒸留なし、ランダム初期化） 90% 再蒸留 + PPO 97% 再蒸留 + PPO は RL-Only（90%）を統計的に有意に上回りました（Fisher’s exact test, p=0.049）。 TTT 中に得た「蒸留初期化は逆効果」という結論は、座標変換バグに起因する誤りでした。前処理が正しければ、蒸留初期化は PPO の収束を加速し、最終成功率も向上させます。 構造化された記録が継続を可能にする TTT 後 1 日で 97% に到達できたのは、3 日間の実験記録、失敗分析、設計文書が構造化ドキュメントとして残っていたからです。コンテキストが消えず蓄積されること、失敗が次のサイクルの出発点になることが、AI-DLC を ML 実験に適用する最大の利点でした。 10. 成果と今後の展望 3 日間の定量的成果 カテゴリ 成果物 コード distill.py (~400 行), train_finetune.py (~500 行), evaluate.py (~450 行) — 合計 1,350+ 行 実験 蒸留チェックポイント, PPO 学習結果 (3 Runs + 蒸留あり/なし比較), 100 エピソード評価 ドキュメント タスクリスト, ユニット分割計画, 設計レビューレポート, 実験分析レポート — 計 30+ 文書 今後の展望 技術面では、蒸留データ品質の改善、実機（SO-101）への Sim-to-Real Transfer を計画しています。 プロセス面では、他チームへの AI-DLC プロセス展開、ML 実験における設計レビューテンプレートの標準化を進めます。 著者について 株式会社NTTドコモ 片岡 敬志郎 株式会社NTTドコモ R&D イノベーション本部 モバイルイノベーションテック部 ユースケース協創担当 フィジカル AI、ロボティクス領域における研究開発と社会実装を推進。AI-DLC TTT のテーマ選定を担当し、R&D 組織への AI-DLC 展開を推進中。

はじめに 本ブログは、株式会社第一興商と Amazon Web Services Japan が共同で執筆しました。 株式会社第一興商 （以下、第一興商）では、通信カラオケ「DAM」シリーズにおける採点機能の高度化に取り組んでおり、AWS Professional Services と共同で、人間の聴感に即した歌声評価 AI モデル「聴感採点モデル」を開発しました。この技術は、DAM のフラッグシップモデル LIVE DAM WAO! に搭載されている採点機能 精密採点Ai Heart の中核として活用されています。 2026 年 6 月 25 日〜6 月 26 日に幕張メッセで開催された AWS Summit Japan 2026 では、第一興商のブースにてこの聴感採点モデルの仕組みと実装をご紹介いただきました。本記事は、AWS Summit Japan 2026 での展示内容をもとに再構成したものとなります。 第一興商とは 株式会社第一興商は、業務用カラオケ機器「DAM」シリーズの開発・製造・販売を手がける企業です。カラオケ事業においてはトップクラスのシェアを有し、最新機種「LIVE DAM WAO!」では AI 技術を活用した多彩な機能を搭載しています。 写真提供：株式会社第一興商 カラオケ採点における課題 従来のカラオケ採点は、音程・リズム・ビブラートなどの音響パラメータを機械的に評価する方式でした。この方式は一定の精度を持つ一方で、以下のような課題がありました。 人間の感性との乖離 : 機械採点は音程を重視しているため、一定以上の音程精度を持つ歌に対しては妥当性がある一方で、人間が「心地よい」と感じる歌声の微妙なニュアンスを十分に評価できない 「採点歌い」への対応 : 機械的に高得点を狙う歌い方（いわゆる「採点歌い」）に対して過大評価してしまう傾向がある 音程偏重の評価 : 細かな音程のズレに対して過度に厳しい評価となる一方、声質や表現力といった人間の感性に関わる要素が反映されにくい これらの課題を解決するため、第一興商は AWS Professional Services と共同で、人間の聴感に基づく歌声評価 AI モデルの開発に着手しました。 聴感採点モデルの開発アプローチ 本プロジェクトは 2019 年から約 4 年にわたり、AWS Professional Services の Machine Learning Research Scientist および Data Analytics Consultant がプロジェクトに参画し、機械学習モデルの設計・開発だけでなく、教師データの品質向上のための統計手法の導入や、大規模データ処理基盤の構築など、幅広い技術支援を提供しました。以下では、その中で取り組んだ主な実験・技術的アプローチについて解説します。 教師データの収集：一対比較法による聴感ラベリング 聴感採点モデルの開発において最も重要かつ困難な工程は、「人間の聴感」を定量的に表現する教師データの作成でした。 当初は 5 段階尺度法による評価を試みましたが、審査員によるブレが大きく十分な精度が得られませんでした。そこで、2 つの歌声を聴き比べて「どちらが良いか」を判定する 一対比較法 を採用しました。絶対値で点数を付ける方式に比べて審査員間の判断のばらつきが小さく抑えられるため、整合性が高くスケール可能な評価が可能になりました。約 15 万回に及ぶラベル作業を通じて、高品質な聴感評価の教師データを構築しました。 一対比較の結果を Bradley-Terry 法（BT 法）により聴感スコアに変換しました。BT 法では、すべてのペアを網羅的に比較する必要がなく、グラフが連結していればスコアを推定できるため、大規模データへのスケーリングが可能です。 特徴量抽出：Audio Embedding Generator 歌唱音源から特徴量を抽出する方法として、オープンソースの深層学習モデル Audio Embedding Generator を使用しました。これにより、音声データを 1 秒ごとに 128 次元のベクトル表現に変換します。 大規模なエンベディング処理を効率化するため、AWS のコンテナサービスを活用し、最大 1,000 並列での処理基盤を構築しました。これにより、約 13 万ファイルのエンベディング処理を 1.5 時間で完了できるようになりました。 モデルの学習と試行錯誤 学習モデルには AutoGluon Tabular を使用し、聴感評価結果と音源特徴量を組み合わせて学習を行いました。 最適なモデル構成を見つけるため、時間集約特徴量の種類、マルチモーダル特徴量の組み合わせ、トレーニングサンプルの選択方法、モデリング手法（分類・回帰）といった複数の設計軸について、それぞれの組み合わせパターンを網羅的に実験し、精度を比較検証しました。 AWS アーキテクチャ概要 聴感採点モデルのシステムは以下のコンポーネントで構成されています。 機械学習モデル構築（Amazon SageMaker AI） : 聴感評価モデルの学習・評価を Amazon SageMaker AI 上で実施。P3 系 GPU インスタンスを活用し、深層学習モデルの効率的な訓練を実現しています。 教師データ管理（Amazon SageMaker Ground Truth） : 一対比較法によるラベリング作業のプラットフォームとして活用しました。 データ保存（Amazon S3） : 歌唱音源データ、エンベディング特徴量データ、モデルアーティファクトの保存に使用しています。 大規模エンベディング処理 : AWS Fargate for Amazon ECS を活用した並列処理基盤により、大量の音声ファイルのエンベディング処理を最大 1,000 並列で高速に実行しています。 AWS Professional Services との共同開発の成果 上記の実験を経て、開発された聴感採点モデルは以下のような特性を実現しています。 「心地よい」歌声の識別 : AI 聴感スコアの上位には「いまいちな」歌声が混入しにくい特性を実現しました 「採点歌い」への耐性 : 機械採点が高得点であっても、「採点歌い」のような不自然な歌声には低い AI 聴感スコアを付与する結果を得ました コンテスト上位歌唱の適切な評価 : 実際のカラオケ大会におけるデータにおいて、プロ審査員が上位と評価した歌手に対する AI 聴感スコアの評価が適切に向上しました 人の聴感に近い学習データの収集は、本プロジェクト最大の難所でした。当初は評価のばらつきに苦労しましたが、AWS Professional Services が一対比較法を提案し、開発本部の全社員を対象に数か月かけて評価を実施することで、人の聴感に近い高品質な学習データを準備できました。また、製品化にあたっては DAM 端末のスペックに合わせてモデルを大幅に軽量化する必要があり、この移植・軽量化の工程でも AWS Professional Services が継続的に技術支援を行いました。これらの取り組みにより、新機種の発売時期に合わせてプロジェクトを推進できました。 AWS Summit Japan 2026 での反響 AWS Summit Japan 2026 の第一興商ブースでは、精密採点Ai Heart の開発プロセスをモニターで紹介するプレゼンテーションに加え、実際にワンコーラス歌唱でチャレンジできる「透明カラオケボックス」を設置しました。90 点以上を獲得された方にはオリジナルステンレスマグボトルをプレゼントする企画としたところ、2 日間でのべ 300 名以上の方にご参加いただきました。 「なぜ AWS Summit にカラオケが？」と多くの来場者に足を止めていただき、精密採点Ai Heart の背景にある機械学習技術と、それを支える AWS のアーキテクチャに関して、多数のご質問と好意的なご反応をいただきました。「普段何気なく楽しんでいるカラオケの裏側で、これほど本格的な機械学習モデルが動いているとは思わなかった」「15 万回もの人手による聴感評価を積み上げて教師データを作っている点に驚いた」「カラオケも AWS で動いているんですね」といった感想を数多くいただき、身近なエンターテインメントサービスにおける AI 活用の実例として、多くのビルダーの皆様と対話できる貴重な機会となりました。 おわりに 第一興商の聴感採点モデルは、AWS Professional Services との共同開発により、従来の機械採点では実現できなかった「人間の感性に寄り添った歌声評価」を実現しました。採点品質の核となる 15 万回の聴感ラベリングはあえて人間の耳で一つひとつ積み重ね、その貴重なデータを最大限活かすためのモデル構築・運用基盤に AWS の機械学習サービスを活用することで、カラオケ体験をより豊かなものにしています。 今後の展望としては、聴感モデルでは補いきれなかった「得点に対する納得感」をさらに追求していく予定です。今後の精密採点シリーズに是非ご期待ください。 著者について 執行 里恵（Rie Shigyo） 株式会社第一興商 開発本部 コンシューマ事業部 応用技術課 聴感採点モデルの企画・開発を主導。 中本 翔太（Shota Nakamoto） アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト サービス業界のお客様を中心に、幅広い業種業態のお客様をご支援しています。  

2026年10月1日、サイバー対処能力強化法（いわゆる能動的サイバー防御法）の主要部分が施行されます。 届出と報告の義務がかかるのは、国に指定された基幹インフラ事業者（2026年7月1日時点で15分野258者）のうち、一定の重要システムを使う事業者だけです。 ただ、この記事を読んでいただきたいのは、その事業者だけではありません。 たとえば、こういう立場の方です。 基幹インフラ事業者に、システムやサービスを納めている 自社は指定されていないが、同じ業種で、規模だけが基準に届いていない 今回は対象外だが、次の改正で対象になりそうだ（医療分野は、すでに追加が決まりました） グループ会社に、指定された事業者がある 少しでも心当たりがあれば、ここから先はぜひ「自社の課題」としてお読みください。届出や報告の義務は課されません。しかし、説明を求められる側にはなる可能性があります。 ここで扱うのは、難しい条文の解説ではありません。実務において最も重要となる一点に絞ってお伝えします。それは、「いざ報告を求められたときに、提出できるログが手元に残っているかどうか」ということです。 目次 10月1日に何が変わるのか 対象外の会社にも、話は届きます いま、日本で実際に起きていること なぜ、攻撃側だけが有利なのか 「見えていない」理由は、能力ではなく構造です では、どう変えられるか 1. コスト:「絞る」必要をなくす 2. 見えない範囲:「全部残して、全部検索する」 3. 速度:「アラート」ではなく「調査結果」を受け取る 日本では、ここが最初の条件になります 「Elasticって、本当にセキュリティの会社なの？」と疑問に思われる方へ RFI・RFPに書くべき5項目 いまお使いのSIEMを、止める必要はありません まとめ 出典 10月1日に何が変わるのか 変わるのは「守り方」ではなく「説明責任」です。対象事業者にかかる主な義務は2つ。重要な機器の届出と、サイバー攻撃を受けたときの報告です。 報告で注目したいのは、対象が被害発生時だけではないことです。その原因となり得る事象を知ったときも、報告の対象になります。異常な認証、見慣れない通信、消えたログ。気づける状態になっていなければ、報告のしようがありません。 そして報告では、「どのシステムが影響を受けたのか」「どんな攻撃だったのか」「業務にどう影響したのか」を説明します。 これを説明する土台が、ログです 。 侵入経路も、活動が始まった時期も、横移動の有無も、後から確かめるにはログが要ります。残っていなければ、「わかりません」と書くことになります。 対象外の会社にも、話は届きます これは推測ではありません。政府の基本方針にそう書かれています。 本法に基づく措置は、特別社会基盤事業者はもとより、電子計算機の使用者に対する周知など中小企業も含めて広く様々な事業者が対象となり得るため、必要な周知・広報を行う。 （内閣府「サイバー対処能力強化法に基づく基本方針の概要」令和7年12月） 届け方は、大きく2つです。 1. 供給する側は、すでに制度の中にいます サイバーセキュリティ基本法 第7条第2項は、情報システムの供給者に対して、利用者の安全性に配慮した設計・開発と、維持管理に必要な情報の継続的な提供を求めています（努力義務）。経済産業省と内閣官房国家サイバー統括室は2026年3月31日に、こうした事業者を「サイバーインフラ事業者」と位置づけたガイドラインも策定しました。 さらに、経済安全保障推進法の枠組みでは、基幹インフラ事業者が重要設備を導入・委託する際の「導入等計画書」に、供給者だけでなく委託の相手方や再委託の相手方についても同等の事項を記載します。会社名だけでなく、代表者や役員の情報まで含まれます。 二次請けで入っているだけでも、すでに書類の中にいる可能性があるということです。 2. 報告のとき、ログを聞かれます 侵入経路が自社の提供したシステムだった場合、そこで何が起きたかを確認できるのは、ベンダー側だけということがあります。 「この時間帯の認証ログを見せてください」「この通信は正常ですか」、そうした確認を求められる可能性があります。そのときログが残っていなければ、「わかりません」と答えることになります。 ※ 制度の細部（対象事業者の範囲、届出内容、期限など）は、内閣官房・NISCおよび内閣府の公表資料で最新の内容をご確認ください。 いま、日本で実際に起きていること 現場の数字を見ておきます。すべて警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（令和8年3月公表）からの引用です。 ランサムウェア被害報告は226件。 高止まりが続いています。 被害企業の約6割は中小企業です。 「うちは狙われるほど大きくない」は成り立ちません。業種別では製造業が約4割。 感染経路について回答が得られた組織では、VPN機器からの侵入が6割を超えました。 メールの添付ファイルではありません。インターネットに露出した機器の未修正の脆弱性や、漏えいした認証情報から入られています。 復旧に総額1,000万円以上かかった組織が5割を超えています。 1か月未満で復旧できたのは5割強。約半数が1か月以上、影響を受け続けています。 なぜ、攻撃側だけが有利なのか 警察庁の報告書は、RaaS（Ransomware as a Service） を被害拡大の背景として明記しています。 RaaSは、一言でいうと**攻撃の「フランチャイズ」**です。開発・運営グループが実行役に道具一式を渡し、身代金の一部を受け取ります。 高度な技術的専門知識を有していない者であっても、ランサムウェア攻撃の実行が可能になるなど、攻撃者の裾野の広がりが見られている（警察庁） 狙っているのは、天才ハッカーとは限りません。道具を借りてきた加盟店かもしれない、ということです。 ここに非対称があります。攻撃側は道具代を一度払えば、何度でも試せます。一件成功すれば元が取れます。守る側は毎年払い続けても、「終わり」が来ません。 速度も違います。CrowdStrikeの2026年版Global Threat Reportによると、金銭目的の攻撃の平均ブレイクアウトタイムは29分（侵入から横移動を始めるまでの時間）。最短27秒という記録も報告されています。 侵入されてから隣のシステムへ移られるまで、30分ありません。この時計の差が、そのまま被害の大きさになります。 「見えていない」理由は、能力ではなく構造です ログが見えていないと聞くと、担当者のスキル不足を思い浮かべるかもしれません。でも実務では、原因はたいていそこではありません。 単年度予算がライセンス数を決める — 入れられなかった端末が、そのまま入口になる 取り込み量への課金 — 予算に収めるには、取り込むログを減らすしかない 保持期間が短い — ログが消えたあとに侵入が発覚すれば、見たい期間はもう手元にない 製品がつぎはぎ — 攻撃者は壁を破らず、製品と製品の 継ぎ目 を通る 「ログを取っていないのではありません。取れない値付けになっているだけです。」 取り込んでいないログは、検知もできないし、報告もできません。 では、どう変えられるか 1. コスト:「絞る」必要をなくす Elastic Cloud Hosted とセルフマネージドの構成では、使うリソース（ノードのメモリ量と稼働時間など）に対して課金されます。取り込んだデータ量そのものには課金されません。「取り込む量を増やすと、その分ライセンス費が上がる」という関係になりません。予算を理由にログソースを外す判断を、しにくくなります。 ※ Elastic Cloud Serverless の Security は取り込み量ベースの課金です（Essentials $0.09/GB〜、Complete $0.11/GB〜）。リソース課金なのは Hosted とセルフマネージドの構成です。 2. 見えない範囲:「全部残して、全部検索する」 Elasticの中核は検索エンジンです。古いデータを安いストレージ階層に置いたまま、復元作業なしでそのまま検索できます。「バックアップから戻すのに3日」がなくなります。 調査は必ず過去にさかのぼります。10月1日以降は、説明のためにもさかのぼります。 規模の目安として、米国カリフォルニア州雇用開発局（EDD）の事例があります。約14,000エンドポイント、月80,000件超のアラート、守っているレコードは 8,500億件 です。 3. 速度:「アラート」ではなく「調査結果」を受け取る Attack Discovery は、バラバラのアラートを1つの攻撃のストーリーにまとめる機能です。従来アナリストが手作業でつなげていた部分を、AIが先にやります。 「AIの判断を信じていいのか」という疑問は正しいです。Attack Discoveryでは、まとめの元になった関連アラートや元データをたどれます。アナリストが確認してから判断します。 大事なのは、AIが答えを出すことではありません。調査を始める場所を、早く見つけられることです。 日本では、ここが最初の条件になります 日本で必ず出る質問があります。「そのデータはどこに置かれますか」です。 Elasticは、クラウドだけでなく、セルフマネージドやオンプレミス、閉域環境でも動きます。AIの部分も選べます。Elastic Managed LLM のほか、 外部のLLMや、自社で管理するLLMを接続できます 。AIを使うために、必ずデータを外部のLLMサービスへ送らなければならない設計ではありません。 政府調達のISMAP、金融のFISC安全対策基準、医療の3省2ガイドライン。日本の要件はどれも「データの置き場所」と「説明できること」を問います。この2つは、機能の1つではなく 入口の条件 です。 ※ ISMAPへの登録有無は、ISMAPポータルの最新のクラウドサービスリストでご確認ください。ここでは要件の説明にとどめています。 「Elasticって、本当にセキュリティの会社なの？」と疑問に思われる方へ Elasticは検索エンジンの会社として知られています。この疑問は自然です。そこでElastic自身の主張ではなく、 第三者が公表した評価 を並べます。 評価レポート 公表 位置づけ Gartner® Magic Quadrant™ for SIEM 2025年10月 Visionary The Forrester Wave™: Security Analytics Platforms, Q2 2025 2025年6月 Leader （2回目）。14項目で最高点、Federated Searchでも最高スコア The Forrester Wave™: XDR Platforms, Q2 2026 2026年6月 Strong Performer IDC MarketScape: Worldwide SIEM 2026 （doc #US54126826） 2026年6月 Leader IDC MarketScape: Worldwide XDR Software 2025 （doc #US52997325） 2025年9月 Leader AV-Comparatives Business Security Test （2026年3〜6月期） 2026年7月 Malware Protection 100%（16製品中で唯一） 。Real-Worldも399/400（99.8%）で最高スコアに並ぶ 正確に書いておきたい点が2つあります。 Forrester XDRは Strong Performer です。 すべての評価で1位、ではありません。 AV-Comparativesの誤検知について。 一般的な業務ソフトを対象としたFalse Alarm Testは0件でしたが、Real-World Protection Testでは12件の誤検知が記録されています。「テスト全体で誤検知ゼロ」ではありません。 そしてもう1つ。 Elasticの検知ルールとエンドポイント保護は、GitHubで公開されています （elastic/detection-rules、elastic/protections-artifacts）。買う前に「どこまで検知できるのか」を自分の目で監査できます。閉じた製品では、これができません。 RFI・RFPに書くべき5項目 RFI（情報提供依頼書）とRFP（提案依頼書）は、製品を選ぶときにベンダーへ出す文書です。大事なのは、RFPに書いていない条件には、ベンダーは答えないということ。書けば全社が必ず答え、できる会社とできない会社がその場で分かれます。 以下は「Elasticの機能一覧」ではありません。どのベンダーを選ぶにしても、要件定義書に書いておくべき5項目です。 全量の取り込み — すべてのログソースを対象にできる。予算の都合で外す必要がない 全履歴の検索 — 数年分を1つのクエリで検索できる。復元作業を必要としない 開かれた文脈 — 他社製品のアラートやテレメトリーも含めてAIが推論できる 監査できるAI — 結論の元データをたどれる。アナリストにも監査部門にも説明できる 設置場所を選べる — クラウド、オンプレミス、閉域環境 第2項は、10月1日以降の説明責任に直結します。 第5項は、閉域要件があるだけで候補が数社に絞られます。 いまお使いのSIEMを、止める必要はありません 「既存のSIEMにすでに投資していて、簡単には変えられない」、ほとんどの組織で当てはまります。 EASE（Elastic AI SOC Engine） は、既存のSIEMやEDRの上で動くサーバーレスのパッケージです。撤去は不要で、既存環境からアラートを取り込み、Attack DiscoveryとAIアシスタントを使えます。大きな稟議を通す前に、自社のアラートで結果を確かめられます。 将来の移行には Automatic Migration があります。例えば、SplunkのSPLで書かれた検知ルールをES|QLに翻訳し、Elastic提供の1,300以上の検知ルールに対応付けます。ただし「部分的に翻訳」「翻訳できず」という状態もあり、手を入れてからでないと導入できないルールもあります。全部が自動で移るわけではありませんが、ゼロから書き直す手間はかなり減ります。 まとめ 1. 問われるのは、守れているかではなく、説明できるかです。 取り込んでいないログは、検知も説明もできません。 2. ログが見えていない理由は、能力ではなく構造です。 取り込み量への課金が、そのまま可視性の穴になっています。 3. 判断材料は、他社の事例より自社のアラートです。 既存のSIEMを止めずに検証できます。 10月1日、義務が始まるのは、ごく限られた事業者です。貴社ではないかもしれません。 ただ、その事業者が報告書を書くとき、材料を求められるのは外側の会社です。政府の基本方針も「広く様々な事業者が対象となり得る」と書いています。 義務がない側には、まだ準備する時間があります。 出典 統計・法制度 記載 出典 ランサムウェア226件、中小企業約6割、製造業約4割、VPN機器6割以上、復旧費1,000万円以上が5割超、1か月未満の復旧5割強、RaaS 警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（令和8年3月） https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07_cyber_jousei.pdf ブレイクアウトタイム29分、最短27秒 CrowdStrike「2026 Global Threat Report」 https://www.crowdstrike.com/en-us/global-threat-report/ 届出・報告義務、「広く様々な事業者が対象となり得る」の引用 内閣府「サイバー対処能力強化法に基づく基本方針の概要」令和7年12月 https://www.cao.go.jp/cybersecurity/pdf/kihonhoushin_gaiyou.pdf 15分野258者（2026年7月1日時点）、導入等計画書に委託・再委託の相手方も記載 内閣府「経済安全保障推進法における特定社会基盤役務の安定的な提供の確保に関する制度（説明会資料）」2026年7月7日 https://www.cao.go.jp/keizai_anzen_hosho/suishinhou/infra/doc/infra_setsumeikai.pdf 医療分野の追加 厚生労働省「基幹インフラ制度への医療分野の追加について」 https://www.mhlw.go.jp/content/10808000/001703605.pdf 供給者の努力義務、「サイバーインフラ事業者」ガイドライン（2026年3月31日） 経済産業省・内閣官房国家サイバー統括室 https://www.meti.go.jp/press/2025/03/20260331001/20260331001.html Elasticの製品・事例 記載 出典 8,500億件、約14,000エンドポイント、月80,000件超のアラート EDD導入事例 Attack Discoveryの元データ確認とアナリストによる検証 Elastic Docs: Attack discovery 外部LLM・自己管理LLMの接続 Elastic Docs: LLM connectors 1,300以上の検知ルール、部分翻訳・未翻訳の状態 Automatic Migration ／ Elastic Docs EASEが既存SIEM／EDRの上で動く Elastic AI SOC Engine 発表 Serverlessの取り込み課金、Hostedのリソース課金 Serverless ／ Cloud Hosted The post 2026年10月1日、基幹インフラに攻撃の報告義務。ログを聞かれるのは誰か、そしてその準備 first appeared on Elastic Portal .