Next.js
イベント
該当するコンテンツが見つかりませんでした
マガジン
技術ブログ
はじめに # Deno 2.9 リリースおめでとうございます。 Deno 2.9 | Deno Electron 大好きな自分としても気になるのはやはり Deno Desktop です。 Tauri と同様 WebView をバックエンドにする構成と Electron と同様 Chromium ベースの構成を選べるとのことで、これは試すしかないと思いました。 公式ドキュメントは以下にあります。 https://docs.deno.com/runtime/desktop/ --> Caution Deno ブログには以下のように書かれており、2.9 時点ではデスクトップ機能は実験的段階です。 deno desktop is experimental in 2.9. The surface described here is stabilizing and some platform features are still landing. 使ってみる # まずは 2.9 にアップグレードしておきます [1] 。 deno upgrade main.ts に Deno.serve を使って普通にサーバープログラムを書きます。 main.ts Deno.serve(() => new Response( "<!DOCTYPE html><h1>Hello from Deno desktop </h1>", { headers: { "content-type": "text/html" } }, ) ); 同じディレクトリで deno desktop main.ts を実行します。 $ deno desktop main.ts ⚠ deno desktop is experimental and subject to change Check main.ts Compile main.ts to hello.dylib Embedded Files hello.dylib └── main.ts (430B) Files: 1.91KB Metadata: 1.38KB Remote modules: 12B Downloading laufey webview backend for aarch64-apple-darwin (v0.4.0) Download laufey-webview-aarch64-apple-darwin.tar.gz 97.44KiB/97.44KiB Codesigning bundle with identity "-" hello.app/Contents/MacOS/laufey_webview: replacing existing signature hello.app/Contents/MacOS/hello.dylib: replacing existing signature Bundle hello.app 最後の出力で、ルートに hello.app (macOS のアプリ実行ファイル)が生成されており、起動できます（Windows の場合は、hello.exe が生成されます）。 Deno のコンセプト通り、追加のモジュールや設定なし(Out of the box)でデスクトップアプリが生成されました。 Deno Desktop の開発体験 # HMR (Hot Module Replacement) オプション付きで起動することで、ローカルの開発サーバを立ち上げ、コード変更を検知してアプリ内容を即時更新してくれます。 deno desktop --hmr main.ts ⚠ deno desktop is experimental and subject to change Compile main.ts to file:///Users/kondoumh/Library/Caches/deno/desktop/5f4a00908e99d886/hello.dylib Embedded Files hello.dylib └── main.ts (422B) Files: 1.9KB Metadata: 1.38KB Remote modules: 12B Running desktop app with HMR (watching /Users/kondoumh/dev/deno-study/desktop/hello) Runtime loaded successfully from: /Users/kondoumh/Library/Caches/deno/desktop/5f4a00908e99d886/hello.dylib Runtime started [desktop] dylib path: "/Users/kondoumh/Library/Caches/deno/desktop/5f4a00908e99d886/hello.dylib" Listening on http://127.0.0.1:52958/ main.ts のコードを書き換えると、保存後すぐに画面へ反映されます。 --> Information Electron では HMR は標準では利用できず、別途 Forge などで開発サーバーを起動する必要があります。 https://developer.mamezou-tech.com/blogs/2024/01/29/electron-forge-introduction/ UI の ローカル HTTP サービスによる実現 # Electron (Forge など) ではローカルサーバーの利用は開発時が中心で、配布後は file:// でアセットを読む構成が一般的です。 これに対し Deno Desktop は、配布後のバイナリでもローカル HTTP サーバーを内部起動し、空きポートを自動割り当てして UI を描画します。サーバーはプロセス内で閉じており、外部公開はされません。ポート衝突を意識せずに済むのも良い点です。 この「開発時もビルド済みバイナリでも、同じ HTTP 実行モデルで UI を提供する」設計により、 開発時とデプロイ時の挙動に差がない コンテンツはブラウザとデスクトップで同じ動きをする Next.js などのフレームワークがそのままデスクトップアプリの中で動く といったメリットが得られます。 https://docs.deno.com/runtime/desktop/serving/ DevTools の起動 # Electron や Tauri と同様、DevTools によるデバッグが可能です。BrowserWindow を起動し、 openDevtools メソッドを呼ぶだけです。 const win = new Deno.BrowserWindow({ title: "My Deno Desktop App", width: 800, height: 600, }); win.openDevtools(); https://docs.deno.com/runtime/desktop/devtools/ --> Information いまのところ、DevTools のフルサポートはバックエンドを cef にしている時のみです。 以下のように、指定して起動する必要があります。 deno desktop --hmr --backend=cef main.ts バックエンドとフロントエンドの通信(Bindings) # Electron の IPC 通信は render.js と main.js を preload.js 経由でブリッジする必要があり、かなり面倒です。Deno デスクトップでは BrowserWindow にバインドした関数を bindings というグローバルオブジェクトにより簡単に呼び出すことができます。 Deno ランタイムとレンダリングバックエンドはスレッドやプロセスとして動作し、呼び出しはプロセス内チャネルを介して行われます。このサンプル構成ではソケットベースの IPC を直接扱わずに済むため、Electron の ipcMain / ipcRenderer、Tauri の invoke と比べて見通しよく書けるのが利点です。 実際のコードで見てみましょう。 const win = new Deno.BrowserWindow({ title: "Bindingsのテスト", width: 800, height: 600, }); // ========================================== // 1. バックエンド側：フロントから呼ばれる関数を登録 // ========================================== win.bind("getSystemInfo", async (userName) => { console.log(`[Deno側] フロントエンドから呼ばれました！ 引数: ${userName}`); // Denoの機能を使ってOSの情報を取得 const denoVersion = Deno.version.deno; const os = Deno.build.os; // 少し重い処理をシミュレート（0.5秒待つ） await new Promise(resolve => setTimeout(resolve, 500)); // フロントエンドに返すデータ（JSON化できるものなら何でもOK） return { message: `こんにちは、${userName}さん！`, os: os, denoVersion: denoVersion }; }); // ========================================== // 2. フロントエンド側：画面のHTMLを返す // ========================================== Deno.serve(() => { const html = ` <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Bindings Test</title> </head> <body> <h1>Deno Desktop Bindings</h1> <button id="btn">システム情報を取得</button> <pre id="result">ここに結果が出ます</pre> <script> // ボタンが押された時の処理 document.querySelector('#btn').addEventListener('click', async () => { const resultArea = document.getElementById('result'); resultArea.textContent = "取得中..."; try { // 💡 bindings を使ってバックエンドの関数を呼び出す const data = await bindings.getSystemInfo("kondoumh"); // 結果を画面に表示 resultArea.textContent = JSON.stringify(data, null, 2); } catch (error) { resultArea.textContent = "error: " + error.message; } }); </script> </body> </html> `; return new Response(html, { headers: { "content-type": "text/html" }, }); }); アプリ画面です。 システム情報を取得 ボタンをクリックするとしばらく呼び出し中になり、結果が表示されます。 結果が表示された状態。 アプリを起動しているバックエンドでは次のようにログが出ています。 [Deno側] フロントエンドから呼ばれました！ 引数: kondoumh すごくシンプルです。OS のネイティブ機能と Web UI を簡単に連携できるのがいいですね。 https://docs.deno.com/runtime/desktop/bindings/ メニュー の利用 # アプリケーションメニューの実装。 BrowserWindow の setApplicationMenu メソッド内でメニューオブジェクトを定義して渡します。 BrowserWindow にイベントリスナーを登録してメニューがクリックされた時の振る舞いを実装します。 role などは Electron と同じですね。 win.setApplicationMenu([ { submenu: { label: "File", items: [ { item: { label: "New", id: "new", accelerator: "CmdOrCtrl+N", enabled: true, }, }, { item: { label: "Open…", id: "open", accelerator: "CmdOrCtrl+O", enabled: true, }, }, "separator", { item: { label: "Save", id: "save", accelerator: "CmdOrCtrl+S", enabled: true, }, }, { role: { role: "quit" } }, ], }, }, { submenu: { label: "Edit", items: [ { role: { role: "undo" } }, { role: { role: "redo" } }, "separator", { role: { role: "cut" } }, { role: { role: "copy" } }, { role: { role: "paste" } }, ], }, }, ]); win.addEventListener("menuclick", (e) => { const detail = (e as CustomEvent).detail; switch (detail.id) { case "new": console.log("New clicked"); break; case "open": console.log("Open clicked"); break; case "save": console.log("Save clicked"); break; } }); コンテキストメニューの実装。 Deno.MenuItem の配列を作成して、BrowserWindow の showContextMenu に座標とともに渡します。 const contextMenu: Deno.MenuItem[] = [ { item: { label: "Copy", id: "copy", enabled: true } }, { item: { label: "Paste", id: "paste", enabled: true } }, "separator", { item: { label: "Properties…", id: "props", enabled: true } }, ]; // Trigger from a right-click. The webview may not forward the browser // `contextmenu` event, so handle the secondary mouse button on the window. win.addEventListener("mousedown", (e) => { if (e.button === 2) { win.showContextMenu(e.clientX, e.clientY, contextMenu); } }); win.addEventListener("contextmenuclick", (e) => { if (e.detail.id === "copy") { console.log("Copy clicked"); } if (e.detail.id === "paste") { console.log("Paste clicked"); } if (e.detail.id === "props") { console.log("Properties clicked"); } }); --> Information ここではメニューのクリックイベントでログを出力していますが、ログ自体はアプリを起動しているターミナル側に出ますのでご注意ください。 https://docs.deno.com/runtime/desktop/menus/ フレームワークを利用した開発 # Deno.serve() を利用したサンプルを見てきましたが、Deno デスクトップでは、以下のフレームワークとともに利用可能です。これらのプロジェクトのディレクトリで deno desktop を起動すると、フレームワークを自動検出してアプリを構成します。多くのモダンフレームワークがサポートされています。 Next.js Astro Fresh Remix Nuxt SvelteKit SolidStart TanStack Start Vite ローカルで動いてるのに SSR を使うというのがなんとも不思議な感じですが、ちゃんと動いてセキュアであればヨシ！という感じでしょうか。 https://docs.deno.com/examples/next_tutorial/ Next.js のアプリを作成します。 deno run -A npm:create-next-app@latest 作成したプロジェクトディレクトリへ移動して実行します。 cd <project-dir> deno desktop -A Next.js のアプリが、外部サーバーなしでまるっとデスクトップ内で動いてるのは不思議な感じです。 https://docs.deno.com/runtime/desktop/frameworks/ バックエンドの選択について # デスクトップアプリは配布するバイナリのサイズも重要です。小さいに越したことはありません。 Electron は Chromium を内包するため、インストールされたバイナリサイズは300MBぐらいの大きさになったりします。 Deno Desktop の場合、OS にプリインストールされている WebView を使えば70MB程度です。CEF(Chromium) だとやはり300MB程度になります。 OS 依存の WebView だと、Windows と Mac で微妙に CSS や JS の挙動が変わるクロスブラウザ問題が発生するため、そのための対応やテストも必要になります。機能が少ないうちは WebView でもいいかもしれませんが、機能が増えてくるとテストの手間も何倍にもなっていきます。 Deno Desktop の場合、最初は軽量な WebView でスタートし、クロスブラウザが重荷になってきたら、ちょっと配布サイズは大きくなるけど、CEF にスイッチできるのがいいかなと思います。 https://docs.deno.com/runtime/desktop/backends/ --> Information Tauri だとこの辺、Servo ベースの自前 WebView プロジェクト Verso 待ちですが、Deno は既存の Chromium を選択可能にしているあたり、現時点での割り切りが感じられますね。 Electron との比較 # 既存 Web アプリをデスクトップ化したいユースケースでは、Deno Desktop はかなり有力です。 一方で、Electron の WebContentsView のような高度なマルチビュー構成を前提にしている場合は、現時点では Electron のほうが適しています。たとえば VS Code や Figma のように、複数ビューを細かく制御するタイプのアプリです。 ざっくり整理すると次のような感触です。 単一ウィンドウ中心 + 既存 Web 資産活用: Deno Desktop はかなり良い 複雑なウィンドウ/ビュー管理: Electron が依然強い --> Information マルチビュー構成の対応の弱さは Tauri も同様です。 https://developer.mamezou-tech.com/blogs/2025/12/01/porting-an-electron-app-to-tauri2/ Electron の WebContensView 構成については以下の記事をご参照ください。 /blogs/2024/08/28/electron-webcontentsview-app-structure/ https://docs.deno.com/runtime/desktop/comparison/ さいごに # 以上、Deno Desktop 機能を一通り試しました。 Out of the box でここまでデスクトップ開発体験が整っているのは率直に驚きです。タスクトレイやメニュー、Bindings など、アプリらしさを出すための API が最初から揃っているのも好印象でした。 Tauri と違ってアプリ側をすべて TypeScript で書けるため、既存 Web アプリをベースに「メニューやタスクトレイを追加し、OS 機能と連携する」用途ではかなり相性がよいと感じます。最小構成なら、デスクトップアプリ化自体は1時間もかからないはずです。 --> Information Tauri も JS の API を生やして、Rust 知らない勢を取り込もうとしてはいます。 Deno のキラー機能になる可能性もありますね。experimental から安定版へ向けて、今後の熟成がとても楽しみな機能です。 2026年7月6日現在の最新は 2.9.1 です。 ↩︎
このブログは、東海旅客鉄道株式会社（以下、JR 東海）中央新幹線推進本部 リニア開発部 藤原 海渡氏と、アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションマネージャー 西部 信博、プロフェッショナルサービス本部 正村 雄介、森田 和真による共著です。 1. はじめに JR 東海では、中央新幹線の保守・運用として、山梨リニア線において超電導リニアの電気設備保守の省力化・高度化を進めています。本活動の一環として、状態監視保全（Condition Based Maintenance、以下 CBM）の実現を目的に、AWS 上に IoT プラットフォームを段階的に構築してきました。機械学習の運用（MLOps）も IoT と切り離さず、この IoT プラットフォームの中に統合する方針としています。変電所・開閉所・トンネル区間など設置環境が多様な拠点に、エッジコンピュータやセンサデバイスといった種類の異なる IoT 機器が分散して設置される中で、構成情報を継続的に把握し遠隔から運用していくことが、保守業務の品質を左右する重要なテーマになっています。 本記事では、IoT プラットフォームの概要と構築にあたっての工夫点や得られた知見についてご紹介します。 2. 全体像 2-1. 本システムで実現したいこと（論理アーキテクチャ） IoT プラットフォームで実現したいのは、現地に出向かなくても設備の状態をデータで捉え続けることです。具体的には、次の能力を備えることを目指しました。 機器のメーター情報をデジタル化して取り込み 動作音や電流値をもとにした設備状態の数値化 メーター情報や各種計測情報を統合した状態把握 2-2. 構築した AWS アーキテクチャ（物理アーキテクチャ） 電気設備保守における IoT プラットフォームでは、多様な拠点に設置された IoT デバイスから設備のデータを取得し、エッジで処理した結果と必要なデータのみをクラウドに連携する構成としています。 エッジとクラウドにまたがる IoT システムでは、現場での即時処理とクラウドでの一元管理を両立させる構成が鍵になります。本アーキテクチャでは、 AWS IoT Greengrass がエッジ側の処理ランタイムとして現場固有の推論・前処理を担い、 AWS IoT Core がそのエッジとクラウドをつなぐ通信のハブとなります。クラウド側では AWS IoT SiteWise が設備データをモデル化して時系列で管理し、 Amazon SageMaker AI がエッジ推論向けの異常検知モデルの学習を担います。これらのマネージドサービスを組み合わせることで、通信・運用基盤そのものの開発を最小化し、設備保守の本質的な作り込みに集中できる構成になっています。 この IoT プラットフォームの設計思想は、「処理はできる限りエッジに寄せ、設備も機器も同じ階層モデルで構造化し、その構成を一元的に運用し続ける」 という点に集約されます。以降の 3 つの工夫は、いずれもこの思想を具体化したものです。 3. 工夫①：エッジ処理を中心とした状態監視システムの構築 実装に落とすうえで、まず向き合ったのがデータ取得と通信の制約です。電気設備の状態を正しく捉えるには高いサンプリングデータ・カメラ画像・動作音などが必要ですが、これらをそのままクラウドへ転送すると、通信回線の制約・通信コスト・クラウド側の処理負荷のいずれもが課題となります。 通信量の最適化（3-1）とエッジでの機械学習推論（3-2）という 2 つのアプローチで、この課題に取り組みました。 3-1. エッジ処理と通信量の最適化 Greengrass のコンポーネントとして、カメラ画像からのメーター値読み取り、動作音の特徴量抽出、機械学習モデルによる異常推論などを実装し、クラウドには集計値・推論結果と必要最小限の分析用データだけを送る構成としています。 また、標準コンポーネントに加え、現場固有の処理（カメラ機種ごとの画像切り出しやノイズ除去など）をプライベートコンポーネントとして実装することで、デバイスや設置環境ごとに柔軟な処理を実現しました。 3-2. 機械学習モデルの構築とエッジへのデプロイ 状態監視の中核は、設備の異常検知モデルをエッジ上で推論実行することです。モデルを Amazon SageMaker AI で学習・構築し、オープンソースの ONNX （Open Neural Network Exchange）形式へ変換したうえで、 Greengrass コンポーネントとしてエッジにデプロイしています。これによりモデルを軽量化し、計算資源の限られたエッジコンピュータ上でも無理なく推論を実行できる構成を実現しました。 4. 工夫②：多様な拠点・設備・機器のモデル化 中央新幹線では、監視対象となる拠点・設備が多様であり、それを監視するエッジ構成（IoT 機器やネットワーク）もまた多様になります。そこで 、これらの多様な設備や機器群を共通の構造（モデル）に落とし込み、保守員が一貫した方法で管理できるようにすることを目指しました。 4-1. 拠点・設備のモデル化 拠点・設備は、 AWS IoT SiteWise の Asset Model を活用し、「エリア」→「拠点」→「設備」という階層構造でモデル化しています。これにより、保守員は監視ダッシュボード上で拠点や設備種別を横断して状態を俯瞰したり、特定の設備にドリルダウンしたりといった操作を、共通の枠組みで行えるようになりました。 4-2. エッジ構成のモデル化 エッジ構成は、ネットワーク機器・コンピュータ・センサといった種別に分類したうえで、各機器のハードウェア構成（CPU・メモリや、NIC・USB などの外部接続インターフェース）を共通の属性としてモデル化しています。ネットワーク構成についても、NIC や USB を介した機器間の接続関係としてモデル化し、物理配置は階層的な属性（エリア／拠点／ゾーン／フロア／詳細位置）として表現しています。 5. 工夫③：IoT 機器と機械学習モデルの一元管理・自動運用 拠点とデバイスの数が増えるにつれ、運用上の最大の課題となったのが、モデル化した構成を実体に合わせて正確に把握し続けることです。 以下のようなオペレーションを行うには、正確な構成情報が不可欠です。 ソフトウェアの一括更新 機器のリプレース IP アドレス管理 新規拠点の構築 こうした情報を台帳と現場の作業記録に頼って管理すると、機器が増えるほど負担も増し、台帳と実機の乖離も広がっていきます。そこで 、これらの構成情報を一元管理する仕組みを新たに構築しました。 5-1. 構成情報の自動収集と一元管理 IoT 機器の構成を、実値で最新化し続ける仕組みとして IoT 構成管理システムを構築しました。エッジの構成情報を自動で集約し、機器の物理配置情報も紐付けることで、一元管理を実現しました。 IoT 構成管理システムのアーキテクチャ IoT 構成管理システムは Web アプリケーションとして実装しました。バックエンドは AWS AppSync による GraphQL API と Amazon DynamoDB で構成し、フロントエンドは Next.js で実装して AWS Amplify Hosting でホスティングしています。サーバーレスのマネージドサービスと、Next.js をはじめとする既成のフレームワーク・コンポーネントを最大限に活用したことで、少ない実装コストで素早く立ち上げられました。インフラの運用負荷を抑えられる点も、少人数での継続運用に寄与しています。 エッジ構成の自動収集 構成管理で主となる課題は、機器の構成を実体に合わせて常に同期し続けることです。OS バージョン、 Greengrass の外で動くネイティブアプリケーション、ネットワーク情報まで含めてエッジの構成全体を収集対象としたのが特徴です。これらを集める「構成情報収集機能」を Greengrass コンポーネントとして実装し、 AWS IoT Core 経由でクラウドへ送信して構成管理データベースを定期的に最新化することで、エッジの構成を一元的に把握できるようにしました。これにより、保守員は台帳と実機の乖離を心配することなく運用できます。 5-2. 機械学習モデルのビルド自動化と運用効率化 電気設備の異常検知では、設置環境によってデータの特性が異なるため、設備ごとに特化したモデルの方が精度を得やすい一方、運用面では多数のモデルのライフサイクル管理が新たな課題となります。 そこで 、 Amazon SageMaker Pipelines による学習パイプラインと、 AWS Step Functions による Greengrass コンポーネントへのビルドパイプラインを組み合わせ、学習から配信までの各作業を自動化しています。学習 – ONNX 化 – コンポーネント化 – 配信までを一連の流れとしてスムーズに回せるようにしました。 また、学習済みモデル自体を Greengrass コンポーネントとして扱うことで、IoT 機器のソフトウェア構成管理の枠組みにそのまま乗せられるようにし、IoT と機械学習を別管理にしない運用を実現しています。 6. Professional Services との伴走による内製化の推進 本取り組みは、リニア開発部と AWS Professional Services が伴走する形で進めてきました。週次のスプリントで要件整理・設計・プロト開発・QA を協働で行うことで、リニア開発部のメンバーが IoT・機械学習・Web アプリケーションそれぞれの実装ノウハウを段階的に獲得することができ、開発スピードと内製化の両立につながっています。 リニア開発部自身が運用と改善を主導できる体制を作るうえで、伴走型の開発スタイルは非常に有効でした。 7. まとめ JR 東海では、中央新幹線の将来運用を見据えた電気設備保守の高度化に向け、IoT プラットフォームを段階的に構築・拡充してきました。この取り組みは、次の 3 つの柱に支えられています。 エッジ処理を中心とした状態監視システムの構築（通信量最適化＋エッジでの機械学習推論） 多様な拠点・設備・機器のモデル化（設備データ＋機器／ネットワーク／接続関係） IoT 機器と機械学習モデルの一元管理・自動運用（構成管理＋MLOps） 今後は、将来の営業線運用に向けて、生成 AI を活用した開発・運用ナレッジの継承支援機能追加を検討しています。IoT と機械学習を横断する高度な専門知識を組織に定着させ、現場作業や障害対応の場面で必要なナレッジに素早くアクセスできる環境を整えることを目指しています。 おわりに 本ブログでご紹介した JR 東海の取り組みや関連する AWS サービスに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。 著者について 東海旅客鉄道株式会社 藤原 海渡 (Kaito Fujiwara) 中央新幹線推進本部 リニア開発部 在来線の電気設備保守、リニア電気設備の運用・保守・開発、営業線システムの検討を経て、現在は AWS を活用した IoT プラットフォームと MLOps の推進を担当しています。 アマゾン ウェブ サービス ジャパン合同会社 西部 信博 (Nobuhiro Nishibe) カスタマーソリューションマネージャー カスタマーソリューションマネージャーとして、エンタープライズのお客様を中心に、技術・非技術問わずクラウドジャーニーにおける課題の特定から解決までをご支援しています。好きな AWS サービスは Kiro と AWS IoT シリーズです。 正村 雄介 (Yusuke Shomura) プロフェッショナルサービス本部 IoT コンサルタントとして、製造業や鉄道事業者のお客様を中心に、IoT・生成 AI を活用したシステムの構築をご支援しています。通信分野の研究者を経て AWS に入社しました（工学博士）。好きな AWS サービスは AWS IoT Core と Amazon Bedrock です。趣味は読書とコーヒーです。 森田 和真 (Kazuma Morita) プロフェッショナルサービス本部 アソシエイトデリバリコンサルタントとして、金融や鉄道事業者のお客様をはじめとして、クラウド基盤・生成 AI 基盤に関連したご支援を中心に行っています。好きな AWS サービスは Kiro と Amazon Bedrock AgentCore です。
はじめに こんにちは、クラウドエースの第三開発部に所属している金子です。 昨今、フロントエンド開発では依存ライブラリの脆弱性対策が重要になっています。 そこで、担当しているプロジェクトの依存ライブラリの脆弱性対策として OSV-Scanner を導入しました。 この記事では、OSV-Scanner を選んだ理由と、実際にプロジェクトに導入・運用する手順を紹介します。 対象読者 フロントエンドの依存ライブラリの脆弱性対策に関心がある方 GitHub Actions でセキュリティスキャンを実装したい方 OSV-Scanner の導入や運用方法を知りたい方 なぜ今、対策が必要
動画
該当するコンテンツが見つかりませんでした
書籍
