はじめに CVPR (Computer Vision and Pattern Recognition Conference) は、コンピュータビジョンとパターン認識の分野における最前線の研究成果を集める国際会議です。今年の論文提出数は13,008件で、昨年のCVPR 2024から約13％の増加を記録しました。その中で採択されたのは2,878件、採択率は22.1％です。この採択率は CVPR 2010以降で最も低い数字 となっており、例年以上の競争の激しさが伺えます。厳しい競争を勝ち抜いた論文の中から特に優れた14件の論文がBest Paper Award候補として選出されました。 本記事では 昨年 に引き続き、これらのAward候補となった論文の概要と、その技術的な特徴を紹介します。最先端の技術トレンドの全体像を把握し、皆様の研究開発の一助となることを願っています。 はじめに CVPR 2025の技術トレンド Award Candidatesの紹介 マルチビューおよびセンサーからの3Dデータ生成 FoundationStereo: Zero-Shot Stereo Matching VGGT: Visual Geometry Grounded Transformer MegaSaM: Accurate, Fast and Robust Structure and Motion from Casual Dynamic Videos TacoDepth: Towards Efficient Radar-Camera Depth Estimation with One-stage Fusion Convex Relaxation for Robust Vanishing Point Estimation in Manhattan World Zero-Shot Monocular Scene Flow Estimation in the Wild 3D Student Splatting and Scooping DIFIX3D+: Improving 3D Reconstructions with Single-Step Diffusion Models 画像と動画の生成 Navigation World Models 「マルチモーダル学習」と「ビジョン、言語、推論(Reasoning)」 Molmo and PixMo: Open Weights and Open Data for State-of-the-Art Vision-Language Models Generative Multimodal Pretraining with Discrete Diffusion Timestep Tokens その他注目論文 Descriptor-In-Pixel : Point-Feature Tracking For Pixel Processor Arrays The PanAf-FGBG Dataset: Understanding the Impact of Backgrounds in Wildlife Behaviour Recognition UniAP: Unifying Inter- and Intra-Layer Automatic Parallelism by Mixed Integer Quadratic Programming おわりに CVPR 2025の技術トレンド CVPR 2025の公式ニュース「 Three of the Hottest Topics in Computer Vision Today 」では、今年の提出論文における主要な技術トレンドとして以下の3つが挙げられています。これらを押さえることで、会議全体の方向性が見えてきます。 マルチビューおよびセンサーからの3Dデータ生成 : この技術は、複数の異なる視点から撮影された画像や、深度センサー（例：LiDAR、ToFセンサー）から得られる情報を統合することで、現実世界の物体やシーンの正確な3Dモデルを生成します。これにより、自動運転、ロボット工学、バーチャルリアリティ、拡張現実など、様々な分野で高精度な空間理解が可能になります。 画像と動画の生成 : この技術は、人工知能、特に深層学習モデル（例：GANs、Diffusion Models）を用いて、テキストの説明、既存の画像、またはランダムなノイズから、リアルな画像や動画を生成します。これにより、デザイン、エンターテイメント、コンテンツ制作、データ拡張といった分野で、これまでにない視覚的コンテンツの創造とカスタマイズが可能になります。 「マルチモーダル学習」と「ビジョン、言語、推論(Reasoning)」 : マルチモーダル学習は、画像、音声、テキストなど、複数の異なる種類のデータを同時に学習するAIの技術です。これにより、AIは単一のデータ形式からでは得られない、より深く包括的な理解を獲得します。特に「ビジョン（視覚情報）」、「言語（テキスト情報）」、そしてそれらを統合した「推論（Reasoning）」能力を組み合わせることで、AIは人間のように世界を認識し、状況を理解し、複雑な問題に対して適切な判断を下せるようになります。例えば、画像の内容を言語で説明したり、テキスト指示に基づいて画像を生成したり、あるいは視覚情報と言語情報を組み合わせて複雑な質問に答えたりする能力がこれに当たります。 Award Candidatesの紹介 今年の技術トレンドをふまえて、分野ごとにAward Candidates論文の概要を紹介します。 マルチビューおよびセンサーからの3Dデータ生成 FoundationStereo: Zero-Shot Stereo Matching 著者：Bowen Wen, Matthew Trepte, Joseph Aribido, Jan Kautz, Orazio Gallo, Stan Birchfield セッション：Oral Session 2A: 3D Computer Vision 提案手法は、ゼロショット汎化に優れたステレオ深度推定の基盤モデルです。多様で写実的な100万組の合成ステレオデータと、曖昧なサンプルを除く自動キュレーションにより学習をおこなっています。単眼深度推定の事前知識を活用するバックボーンや長距離コンテキスト推論を用いることで、ドメインをまたいで高精度かつ高いロバスト性を実現しています。 出典：FoundationStereo: Zero-Shot Stereo MatchingのFigure 2, URL: https://arxiv.org/abs/2501.09898 (2025年6月5日アクセス) 提案されたアーキテクチャでは、まず固定された DepthAnythingV2 から得られる単眼事前知識を活用し、マルチレベルCNNによる高周波特徴と組み合わせて特徴を抽出します。次に、Attentive Hybrid Cost Filtering（AHCF）により、抽出された特徴を効率的に統合し、コストボリュームを生成します。特に、Disparity Transformer（DT）は自己注意機構により、長距離のコンテキスト情報を効果的に捉える役割を担います。その後、GRUブロックは初期視差を反復的に精緻化し、最終的な視差マップを出力します。 VGGT: Visual Geometry Grounded Transformer 著者：Jianyuan Wang, Minghao Chen, Nikita Karaev, Andrea Vedaldi, Christian Rupprecht, David Novotny セッション：Oral Session 2A: 3D Computer Vision Visual Geometry Grounded Transformer (VGGT) という新しいフィードフォワード型トランスフォーマーモデルを提案しています。VGGTは数枚から数百枚の画像を入力として、カメラパラメータ、深度マップ、点群、トラッキング情報など、画像の3Dタスクを一括で高速に推定します。従来の3D再構成手法では最適化処理が必要でしたが、VGGTはポストプロセスなしで高精度を実現し、カメラ姿勢推定や点群再構成など複数のタスクで最先端性能を達成しています。さらに、下流タスクにも応用可能で、例えば新規視点合成や動画中の点追跡性能を大幅に向上させることができます。 出典：VGGT: Visual Geometry Grounded TransformerのFigure 2, URL: https://arxiv.org/abs/2503.11651 (2025年6月5日アクセス) 入力画像をDINOでトークン化し、カメラ予測用の「カメラトークン」を付加します。これらのトークンはフレーム単位と全体のアテンションを繰り返し適用され、専用のヘッド（Camera HeadやDPT Head）を通じ、最終的に各フレームのカメラパラメータ、深度マップ、点群、トラッキング特徴が出力されます。 MegaSaM: Accurate, Fast and Robust Structure and Motion from Casual Dynamic Videos 著者：Zhengqi Li, Richard Tucker, Forrester Cole, Qianqian Wang, Linyi Jin, Vickie Ye, Angjoo Kanazawa, Aleksander Holynski, Noah Snavely セッション：Oral Session 3A: 3D Computer Vision 従来の技術では、動きの多い動画やカメラの動きが少ない映像から、3D構造（奥行き情報）やカメラ位置を正確に推定するのは困難でした。特に、日常的な動画ではこれらの条件を満たさないことが多く、既存の手法では誤った結果になりがちでした。 この論文は、深層学習に基づくVisual SLAM（カメラ映像から自己位置推定と環境地図作成を同時に行う技術）の手法を改良。訓練方法や処理の仕組みに工夫を加えることで、複雑でダイナミックなシーンや、カメラの動きが自由で視差（位置による見え方の違い）が限定的な動画であっても、高速かつ安定して高精度な推定を可能にするシステムを提案しています。 出典：MegaSaM: Accurate, Fast, and Robust Structure and Motion from Casual Dynamic VideosのFigure 1, URL: https://arxiv.org/abs/2412.04463 (2025年6月5日アクセス) 本技術では、まず動画から数フレームごとに画像を取り出し、それぞれの画像間で似ている部分を検出し、それらの対応点の位置関係をもとに、カメラがどの方向に動いたかを推定します。 この際、歩いている人や動いている車は背景と関係ないため、動いている領域を識別し、計算から除外します。 また、各フレームごとに深度マップをモデルで推定し、それを使って空間の立体構造も考慮に入れながらカメラ位置を調整します。 これらすべての情報をまとめてAIが一括で最適化することで、何も手動調整しなくても、動画から正確なカメラの動きと、シーンの3D構造を得ることができます。 TacoDepth: Towards Efficient Radar-Camera Depth Estimation with One-stage Fusion 著者：Yiran Wang, Jiaqi Li, Chaoyi Hong, Ruibo Li, Liusheng Sun, Xiao Song, Zhe Wang, Zhiguo Cao, Guosheng Lin セッション：Oral Session 3A: 3D Computer Vision TacoDepthは、効率的で正確なRadar-Camera深度推定のための、ワンステージフュージョンモデルです。従来技術のマルチステージフレームワークが抱える時間的制約とロバスト性の問題を解決するため、グラフベースのRadar構造抽出器とピラミッドベースのRadarフュージョンモジュールを設計。これにより、中間深度を必要とせずに、効率性とロバスト性を向上させました。 出典：TacoDepth: Towards Efficient Radar-Camera Depth Estimation with One-stage FusionのFigure 3, URL: https://arxiv.org/abs/2504.11773 (2025年6月5日アクセス) 技術的なポイントとして、グラフベースのRadar構造抽出器がRadar点群の幾何学的構造とトポロジーを捉え、ピラミッドベースのRadarフュージョンモジュールが画像とRadarの特徴を階層的に統合します。また、Radar中心のフラッシュアテンションメカニズムを導入し、効率的なクロスモーダル相関を実現しています。nuScenesとZJU-4DRadarCamデータセットでの実験により、精度と処理速度が大幅に向上することを示しました。 Convex Relaxation for Robust Vanishing Point Estimation in Manhattan World 著者：Bangyan Liao, Zhenjun Zhao, Haoang Li, Yi Zhou, Yingping Zeng, Hao Li, Peidong Liu セッション：Oral Session 4C: 3D Computer Vision この論文は、人工物の多くは直交座標系に平行に作られているというマンハッタンワールド仮説における消失点の高精度な推定手法を提案しています。従来手法は計算コストが高いか、最適解を保証できないという課題がありました。本研究では、マンハッタンワールドと仮定することで、高精度な推定ができるようになりました。具体的に、誤差を抑えつつ複数の消失点と線分の関係を同時に求めるため、「Convex Relaxation」という数学的手法を用い、問題を解きやすい形に変換します。そして、「GlobustVP」という新しいアルゴリズムを提案し、高速かつロバスト性高く消失点を推定します。 出典：Convex Relaxation for Robust Vanishing Point Estimation in Manhattan WorldのAlgorithm 1, URL: https://arxiv.org/abs/2505.04788 (2025年6月5日アクセス) GlobustVPアルゴリズムは、画像内の線分から3つの消失点を段階的に求める手法です。 各ステップでは、残っている線から補助Tensorを作り、数理最適化（SDP）を使って消失点を一つ推定します。その消失点に最も合う線（inlier line）を抽出し、以後の処理から除外します。これを3回繰り返してVP1〜VP3を推定し、残りの線はoutlierとします。最後に、Manhattan Worldの条件（直交性）を満たすように消失点を調整する後処理を行います。 Zero-Shot Monocular Scene Flow Estimation in the Wild 著者：Yiqing Liang et al. セッション：Oral Session 5C: Visual and Spatial Computing 単眼RGB画像ペアからシーンフロー（3D構造と動きを同時に推定するタスク）を導出する手法です。ViTベースのネットワークでpointmapと3Dオフセットを出力し、未知のドメインでも高精度なシーンフロー推定を実現します。大規模・多様なデータセットとスケール適応型学習戦略により、ゼロショット汎化性能を大きく向上しました。DAVISのような現実世界のデータセットシーンにおいて、未知なデータセットながら高精度な動きを再現し、高い汎化性能を示しました。 出典：Zero-Shot Monocular Scene Flow Estimation in the WildのFigure 2, URL: https://arxiv.org/abs/2501.10357 (2025年6月5日アクセス) 図は、提案手法のシステム構成を示しており、2枚のRGB画像 C1（t1）と C2（t2）を入力として、3つの出力マップを同時に生成します。ViTベースのエンコーダを共有し、各フレームに対応したデコーダがクロスアテンションで情報を融合。出力ヘッドHX1とHX2が時刻t1, t2における3D点群（pointmap）を、HSがシーンフロー（3Dオフセット）を予測しています。学習時は点群・動き・オプティカルフローの3種の損失を用いて、幾何と動きの整合性を高めています。 3D Student Splatting and Scooping 著者：Jialin Zhu, Jiangbei Yue, Feixiang He, He Wang セッション：Oral Session 5C: Visual and Spatial Computing 3D Gaussian Splatting の定式化を見直し、Student Splatting and Scooping（SSS）という新たな手法を提案しています。従来のガウス分布の代わりに、位置、スケール、回転、裾の長さの自由度を与えた柔軟なスチューデントのt分布を用いた混合モデルを導入し、また、正の密度（Splatting）と負の密度（Scooping）の両方を扱うことで表現力を高めています。さらに、学習の安定化のための新しいサンプリング手法も導入しています。実験の結果、SSSは既存手法を品質およびパラメータ効率の両面で上回りました。 出典：3D Student Splatting and ScoopingのFigure 2, URL: https://arxiv.org/abs/2503.10148 (2025年6月5日アクセス) 著者らは、(a) トーラス形状のトポロジーを再構成できるかどうかを実験しています。正の密度のみを用いた場合、(b) 2つの要素では不十分であり、(c) 正しいトポロジーを捉えるには少なくとも5つの要素が必要です。一方、(d) 負の密度を使って中央の密度を打ち消すことで、正と負の要素を1つずつ用いるだけでトポロジーを正しく再現することができます。 DIFIX3D+: Improving 3D Reconstructions with Single-Step Diffusion Models 著者：Jay Zhangjie Wu, Yuxuan Zhang, Haithem Turki, Xuanchi Ren, Jun Gao, Mike Zheng Shou, Sanja Fidler, Zan Gojcic, Huan Ling セッション：Oral Session 6A: 3D from Single or Multi-View Sensors 本論文では、NeRFや3D Gaussian Splatting（3DGS）による3D再構成の限界を克服するため、単一ステップの拡散モデル「DIFIX」を活用した新手法「DIFIX3D+」を提案しています。DIFIXは、再構成中および推論時に画像のノイズやぼやけ、誤りを除去することで、写実的な新規視点合成を実現します。NeRFおよび3DGSの両方の手法に適用可能で、汎用的な補正ツールとして使えます。FIDスコアを従来のNeRFや3DGSの単体手法と比較し平均で2倍以上改善し、リアルタイム処理も可能です。 出典：Difix3D+: Improving 3D Reconstructions with Single-Step Diffusion ModelsのFigure 3, URL: https://arxiv.org/abs/2503.01774 (2025年6月5日アクセス) DIFIXモデルのアーキテクチャを示しています。劣化した3Dレンダリング画像と参照画像を入力とし、ノイズやぼやけ等を除去した高品質な画像を出力します。構造はU-Netを基盤とし、異なる視点の情報を統合する「Reference Mixing Layer」を備え、複数視点間の整合性を保ちながら画像品質を向上させます。事前学習済みのVAEエンコーダを固定し、LoRAでデコーダを微調整します。 画像と動画の生成 Navigation World Models 著者：Amir Bar, Gaoyue Zhou, Danny Tran, Trevor Darrell, Yann LeCun セッション：Oral Session 4B: Embodied Computer Vision Navigation World Model (NWM)は、過去の観測（過去から現在の一連のフレーム）とナビゲーション行動（平行移動、回転）に基づき未来の視覚情報を予測する、制御可能なビデオ生成モデルです 。Conditional Diffusion Transformer (CDiT) を採用し、標準的なDiTと比較して計算要件を大幅に削減しつつ、10億パラメータまで効率的にスケールする学習を実現しています 。NWMは、既知環境での軌道計画や未知環境において単一の入力画像から軌道を想像する能力を有し 、計画中に動的な制約を組み込むことも可能です。 出典：Navigation World ModelsのFigure 2, URL: https://arxiv.org/abs/2412.03572 (2025年6月5日アクセス) CDiTアーキテクチャは、CDiTブロックを複数層積み重ねた時間的自己回帰型のトランスフォーマーモデルです。各ブロックでは、Multi-Head Self-Attentionにより空間的整合性を確保し、現在フレームのクエリと過去フレームのキー/バリューを結びつけるMulti-Head Cross-Attentionによって時間的整合性を維持します。この二段階の注意機構により、計算効率を保ちながら空間・時間両方で一貫性のある未来のフレームの生成を実現しています。 「マルチモーダル学習」と「ビジョン、言語、推論(Reasoning)」 Molmo and PixMo: Open Weights and Open Data for State-of-the-Art Vision-Language Models 著者：Matt Deitke et al. セッション：Oral Session 1B: Interpretability and Evaluation プロプライエタリな視覚言語モデルに依存せず、完全にオープンな手法で高性能なVLM「Molmo」と、その訓練データ「PixMo」を構築・公開した研究です。PixMoは詳細説明を持つ画像キャプション、自由形式の画像質問応答、ポインティング（２次元座標(x, y)とそこにある物体が対となるデータセット）を含む多様なデータを含み、Molmoは学術ベンチマークや人間評価でClaude 3.5やGeminiを上回る性能を達成しました。 出典：Molmo and PixMo: Open Weights and Open Data for State-of-the-Art Vision-Language ModelsのFigure 2, URL: https://arxiv.org/abs/2409.17146 (2025年6月5日アクセス) 図は、Molmoのアーキテクチャを示しており、視覚エンコーダ（ViT）、コネクタ、トークナイザ、LLMという4つの主要モジュールから構成されています。ViTは画像を複数のクロップに分割し、パッチごとに特徴ベクトルを出力します。コネクタはそれらの特徴ベクトルをアテンションプーリングし、LLMの埋め込み空間に変換します。最終的にLLMが応答を生成します。ポインティング出力では、位置情報をHTMLライクな形式で埋め込み、画像内の対象を明示できます。 Generative Multimodal Pretraining with Discrete Diffusion Timestep Tokens 著者：Kaihang Pan, Wang Lin, Zhongqi Yue, Tenglong Ao, Liyu Jia, Wei Zhao, Juncheng Li, Siliang Tang, Hanwang Zhang セッション：Oral Session 6B: Scene Understanding, Image Editing and Multimodal Learning 画像と言語を扱うAIでは、従来の画像情報の形式がAIにとって直感的に理解しづらく、言語のように扱えない課題がありました。本論文は、AIが画像を生成する途中経過を利用し、文章のように意味がつながる新しい形式の視覚情報（DDT: Discrete Diffusion Timestep token）を開発しました。これによりAIの言語理解力と画像生成力を一つの仕組みで効果的に組み合わせ、高度な画像と言語の処理を実現します。 出典：Generative Multimodal Pretraining with Discrete Diffusion Timestep TokensのFigure 2, URL: https://arxiv.org/abs/2504.14666 (2025年6月5日アクセス) (a)の「Diffusion Timestep Tokenizer」は、画像をエンコーダと複数タイムステップ（アテンション等で特徴を精錬・属性を補完）で処理し、学習済みの代表的な画像パターン集であるコードブックを用いた量子化で再帰的・離散的なDDTを生成します。 (b)では、このDDTとテキストのトークン結合列を、LLaMA等の大規模言語モデル（LLM）が「next-token prediction」で処理し、画像とテキスト間の関連性を学習。この統一的予測機構が、画像理解や双方向生成などマルチモーダル処理の基盤を構築しています。 その他注目論文 Descriptor-In-Pixel : Point-Feature Tracking For Pixel Processor Arrays 著者：Laurie Bose, Jianing Chen, Piotr Dudek セッション：Oral Session 2C: Temporal Modeling and Action Recognition ※本記事を執筆している 2025/6/3 時点で論文が未公開のため、関連情報を記載します。 本論文は、ピクセルプロセッサアレイ（PPA）センサー向けの新しい点特徴検出・追跡手法「Descriptor-In-Pixel」を提案しています。この手法は、すべての計算をセンサー内部のピクセルプロセッサで実行します。特徴記述子を各ピクセルプロセッサに保存し、並列処理で高速な検出と追跡を実現。 SCAMP-7 PPAプロトタイプで3000 FPS以上を達成し、激しい動きにも対応します。これは、点特徴の検出と追跡を完全にインピクセルで実行する初の研究です。 出典：Descriptor-In-Pixel : Point-Feature Tracking for Pixel Processor Arraysのデモ動画, URL: https://lauriebose.github.io/DIP/ (2025年6月5日アクセス) The PanAf-FGBG Dataset: Understanding the Impact of Backgrounds in Wildlife Behaviour Recognition 著者：Otto Brookes, Maksim Kukushkin, Majid Mirmehdi, Colleen Stephens, Paula Dieguez, Thurston C. Hicks, Sorrel Jones, Kevin Lee, Maureen S. McCarthy, Amelia Meier, Emmanuelle Normand, Erin G. Wessling, Roman M. Wittig, Kevin Langergraber, Klaus Zuberbühler, Lukas Boesch, Thomas Schmid, Mimi Arandjelovic, Hjalmar Kühl, Tilo Burghardt セッション：Oral Session 2C: Temporal Modeling and Action Recognition 野生チンパンジーの行動認識における背景情報の影響を研究するためのデータセット「PanAf-FGBG」を紹介しています。本データセットは、同じ位置からカメラトラップ（野生動物の自然の行動を自動撮影する無人のセンサーカメラ）で撮影されたチンパンジーを含む前景映像と、含まない背景映像のペアで構成されています。これにより、背景情報が行動認識モデルの汎化性能に与える影響を定量的に評価できます。結果として、背景情報が動物の行動認識の強力な予測因子であることと、CNNとTransformerのアーキテクチャ間での影響度の違いを明らかにし、データセットの有用さを示しました。 出典：The PanAf-FGBG Dataset: Understanding the Impact of Backgrounds in Wildlife Behaviour RecognitionのFigure 1, URL: https://arxiv.org/abs/2502.21201 (2025年6月5日アクセス) 本研究で提案されたPanAf-FGBGの構成を示しています。チンパンジーを含む前景（FG）映像と、含まない背景（BG）映像のペア5070組で構成されており、アフリカ6か国・389か所のカメラから収集された21時間分の映像が含まれています。実験の結果、映像ペアのうちFGまたはBGのいずれか一方のみで学習したモデルと比較して、それぞれから抽出した特徴量を融合したモデルは、分布外データに対してより高い性能を示すことが確認されました。 UniAP: Unifying Inter- and Intra-Layer Automatic Parallelism by Mixed Integer Quadratic Programming 著者：Hao Lin, Ke Wu, Jie Li, Jun Li, Wu-Jun Li セッション：Oral Session 5B: Learning Systems and Medical Applications 大規模モデルの学習には、複数のマシンやGPUを用いた分散学習が用いられ、大きく層間並列（Inter-layer parallelism）と層内並列（Intra-layer parallelism）の2つのカテゴリに分けられます。既存の自動並列化(AP)手法は、層間並列と層内並列の2つのカテゴリを同時に最適化しないという問題を抱えており、UniAPは分散学習の並列戦略最適化において、これまで個別または階層的に扱われていた層間並列と層内並列を混合整数二次計画法（MIQP: Mixed Integer Quadratic Programming）により統合的に扱うことで、既存手法の限界を超え、より優れたパフォーマンスと効率的な最適化時間を実現した手法です。 出典：UniAP: Unifying Inter- and Intra-Layer Automatic Parallelism by Mixed Integer Quadratic ProgrammingのFigure 2, URL: https://arxiv.org/abs/2307.16375 (2025年6月5日アクセス) 層間並列と層内並列の自動並列化を統合し、これら2つのカテゴリの並列戦略を同時に最適化するために、UniAPはMIQPを用いています。この統合された最適化プロセスをUnified Optimization Process (UOP)と呼んでいます。UOPは、ハードウェアとモデルのプロファイリング結果、計算グラフ、コストモデルから得られた推定コストを基にMIQP問題を定式化し、最適な並列戦略（層の配置や層内戦略の選択）と最小のトレーニング時間（TPI）を探索します。 おわりに 本記事では、CVPR 2025のBest Paper Award候補論文を通じて、コンピュータビジョンとパターン認識分野の最先端の技術動向をご紹介しました。どの論文も大変興味深く、今後のAI研究開発の方向性を示唆するものであったと感じています。 現在、私の所属するAI開発部は10人の多様なバックグラウンドを持つメンバーで構成されており、今回の論文紹介も各メンバーが分担して取り組みました。私たちは最先端の研究成果を積極的に取り入れ、社会に貢献するAIの開発に日々邁進しています。 このような最先端のAI技術開発に情熱を傾け、私たちと共に未来を創造したいとお考えの方、ぜひ弊社の 募集要項 をご覧ください。皆様のエントリーを心よりお待ちしております。

新卒一期生が感じたキャッチアップの壁とその打開策 こんにちは！フロントエンドエンジニアの一氏です。 2023年に新卒一期生として入社し、現在は Safie Viewer （セーフィー ビューアー）のフロントエンド開発を中心に業務に取り組んでおります。 先日、若手エンジニアの課題と乗り越え方というLTに登壇してきました。 【増枠】若手エンジニアの課題と乗り越え方 (2025/04/15 18:40〜) toggle.connpass.com 本稿では、LTで発表した新卒エンジニアとして入社後に直面したキャッチアップの壁、そしてそれをどのように乗り越えてきたのかをご紹介させていただきます。 新卒一期生が感じたキャッチアップの壁とその打開策 新卒エンジニアとして直面した課題：3つの壁 課題克服のための実践と打開策 そのほかやって良かったこと おわりに 新卒エンジニアとして直面した課題：3つの壁 入社後、業務を開始するにあたり、私は主に以下の3つの「壁」に直面しました。 サービスの壁 弊社の提供するクラウド録画サービス「Safie（セーフィー）」は、カメラをインターネットにつないで、スマホ・パソコンから、いつでもどこでも映像を確認することができるサービスです。また、他システムとの連携やAI解析による業務効率化や課題解決も行っています。 映像データの汎用性は非常に高く、小売・飲食・建設といった様々な業界で活用することが可能であり、それがSafieのサービスの強みになっています。しかし、裏を返せば映像データを活用したソリューションを実現するには理解すべき領域が非常に広いとも言えます。また、カメラというハードウェアが存在することで、カメラ自体のハードウェア・ソフトウェアの開発、カメラの販売方法や商流、カメラ特有の専門用語の理解も必要になります。 サービスの全体像、各機能の詳細、そしてそれぞれの業界における活用方法など、キャッチアップすべきドメイン知識の多さに、サービスの理解が最初の大きなハードルとなりました。 技術力の壁 私は新卒一期生として入社したため周りは経験豊富な中途入社のエンジニアのみでした。そうした環境下では、自身の経験や知識の不足を痛感する場面が多くありました。実装方法に迷ったり、既存コードの意図を把握するのに時間を要したりと、技術力における周囲との差を感じ、時に自身の成長速度に不安を感じることもありました。新卒の先輩がいない状況で、どのタイミングで質問をするべきか、適切なコミュニケーションの取り方に悩むこともありました。 オンボーディングの壁 私が入社した際の新卒研修のオンボーディングは以下の流れで行われました。 4~7月：エンジニア共通の研修 基礎知識習得（主にUdemy） チーム開発研修 8月：各チームに配属されてそれぞれオンボーディング チュートリアル 簡単なタスクから開始 新卒一期生として入社したこともあり、当時のオンボーディングは構築段階にありました。エンジニアとしての基礎知識の習得としてUdemyが活用されていましたが、長期間の動画視聴は集中力の維持が難しい側面もありました。また、チーム開発研修やその後のそれぞれのチームへ配属後、トレーナーや先輩社員への質問やレビュー依頼の頻度、タイミングについて手探りな部分があり、コミュニケーションの壁を感じることもありました。さらに、配属後のチームのオンボーディング資料が最新の状態に保たれていない箇所などもありました。 課題克服のための実践と打開策 これらの課題に対し、私は試行錯誤しながら以下の打開策を実行しました。 サービスの壁への打開策：あらゆるドキュメントを読む サービス理解を深めるため、社内に存在するあらゆるドキュメントを読み込むことを徹底しました。サービス紹介資料、詳細な仕様書、ヘルプページはもちろんのこと、Slackでの過去の議論やGithubのリポジトリ、ユーザーヒアリングの議事録に至るまで、関連性のありそうな情報はすべて参照しました。 自身で30分調査しても解決しない不明点については、周囲の詳しい先輩社員に質問することをルールとしました。そして、そこで得られた知識は個人のメモとして整理し、いつでも参照できるようにしました。 なお、古い仕様に関する情報が追いにくい場合もありましたが、その際は素直に担当者に確認することが最も効率的であると感じました。 技術力の壁への打開策：コードリーディングと幅広いタスクへの取り組み 技術力の向上に向け、自身の担当するタスクに関連する既存コードのリーディングに注力しました。実際に稼働しているコードを読むことで、チームのコーディング規約や設計思想を実践的に学び、サービスの理解も同時に深めることができました。 自身の技術的な引き出しを増やすことを意識し、比較的小さな機能追加や改修タスクに積極的に取り組みました。簡単なタスクから着実に成功体験を積み重ねることで自信に繋がり、より複雑な課題に取り組むための基礎力を養うことができたと感じています。複雑な機能も、分解すれば単純な要素の組み合わせであることを意識するようになりました。 オンボーディングの壁への打開策：自分たちで改善 オンボーディングプロセスの改善には、新卒メンバー自身が積極的に関わりました。Udemyでの基礎学習については、必須範囲を絞り込み、早期にチーム開発研修へ移行するフローを提案・実行しました。これにより、実践的な開発に早期に触れる機会を増やし、チーム開発研修中に必要に応じてUdemyでの学習に戻るスタイルを取り入れました。 チーム開発研修においては、レビュー依頼のガイドラインを明確化し、トレーナーが積極的にプルリクエストに関わる体制を構築しました。 また、日々の業務に関する雑談や、なんでも相談できる1on1の時間を設ける、日報に対してコメント返しすることで、質問や相談の心理的なハードルを下げる工夫を行いました。 チーム配属後のオンボーディング資料についても、新しくチームに参加するメンバーが随時更新していく運用を取り入れました。これにより、情報の鮮度を保ち、今後入ってくるメンバーがよりスムーズに立ち上がれるように改善を進めています。 そのほかやって良かったこと 上記の打開策に加え、以下の取り組みもキャッチアップにおいて有効であると感じています。 コーチング コーチングとは対話を通じて相手の能力やモチベーションを引き出し、目標達成を支援するコミュニケーション手法です。 上司との定期的なコーチングセッションを通じて、自身の現状や目指す姿、目標について対話する機会を持ちました。これにより、自分一人では気づけなかった視点を得ることができ、客観的に自身の成長課題や進むべき方向性を認識することができました。 よもやま（カジュアルなコミュニケーション） よもやま話とはとりとめのない話や、決まった話題がない話のことで、私の所属するチームではメンターと何を話しても良い1on1の場をよもやまと呼んでいます。初めは毎日30分、次第に頻度を減らして実施していました。 業務に直接関連しないことでもカジュアルに話せるよもやまのような場や、Gatherを活用したコミュニケーションは非常に有効でした。普段の業務では聞きにくい疑問点を解消したり、新たな気づきを得たりすることができ、なんでも話すことができるという安心感があります。心理的な安全性は、スムーズなキャッチアップにおいて非常に重要であると実感しました。 おわりに 新卒エンジニアとしてのキャリアをスタートするにあたり、サービスの理解、技術力の向上、そしてオンボーディングプロセスの活用といった様々な面で多くの課題に直面しました。しかし、これらの「キャッチアップの壁」は、主体的に学び、実践し、そして周囲と積極的にコミュニケーションを取ることで、一つずつ乗り越えていくことが可能です。 本稿でご紹介した私の経験が、これからエンジニアを目指す方々、現在キャッチアップに励んでいる若手エンジニアの方々のお役に立てれば幸いです。

はじめに こんにちは！セーフィー株式会社でサイバーセキュリティを担当している金原です。 前回、こちらの記事でセーフィーがどのようにセキュリティ戦略を策定しているか、その考え方についてお話しさせていただきました。 engineers.safie.link さて、今回はその続編として、策定した戦略を実行していくために不可欠な 「チームづくり」 について、私たちの考えとこれまでの取り組みをご紹介したいと思います！ はじめに 戦略を実行する「チーム」の重要性 基本的な考え方は「ちゃんとマネジメントする」 マネジメントは「セルフマネジメント」から 「個」から「チーム」へ：チームビルディング アジャイルな仕事の仕方を取り入れる チームを育成し、拡大していく おわりに 戦略を実行する「チーム」の重要性 前回お話ししたサイバーセキュリティ戦略ですが、策定した時点では、まだ多くの 仮説 を含んでいます。 また、脅威の状況やビジネス環境は常に変化するため、戦略も固定的なものではなく、継続的に見直していく必要があります。 そこで、私たちは以下のような、 小さく実行し、 フィードバックを得て、 学びを次に活かす というサイクルを、うまく実行できる、 フィードバック駆動のハイパフォーマンスなチーム になりたいと考えました。（このアプローチが戦略をうまく進めていける鍵になると信じてます） では、どうすればそのようなチームになれるのか？ その問いに答えていきたいと思います。 基本的な考え方は「ちゃんとマネジメントする」 セキュリティ問わず、ハイパフォーマンスなチーム作りに、特別な近道や魔法はありません。 私たちが大切にしている基本的な考え方は、 「ちゃんとマネジメントする」 ということです。 （当たり前のことを主張してすみません。でも大事なんです） マネジメントと聞くと「管理職」というキーワードから「管理すること」と捉えられがちなのですが、ここで言うマネジメントとは、単なる「管理」ではありません。 ドラッカーも言うように、マネジメントとは 「メンバーとチームの力を最大限に活かし、チームとして価値の高い成果を生む」 ための働きかけを指します。 これは、どの業務でも同じですよね。 ということで、まずは正しい理解を身に着ける（体系的な知識を得る）のがよいだろうということで、以下を実施しました。 ＜私たちの取り組み＞ マネジメント勉強会 を実施しました。チーム全員がそろって参加して、「マネジメントとは何か？マネジメントがなぜ重要なのか？」を学び、マネジメントについての目線合わせをしました。 勉強会の様子 具体的には以下の書籍を参考にしたスライドを作成して講義形式で開催しています。 （私自身が、著者の藤田勝利先生のマネジメント講座を受講した際にとても分かりやすく学べたので参考にしました） (出典)藤田勝利,新版-ドラッカー・スクールで学んだ本当のマネジメント,日経BP,URL: https://www.amazon.co.jp/新版-ドラッカー・スクールで学んだ本当のマネジメント-藤田-勝利/dp/4296108832 ,（2025年5月2日アクセス） (出典)藤田勝利,ノルマは逆効果 〜なぜ、あの組織のメンバーは自ら動けるのか〜,太田出版,URL: https://www.amazon.co.jp/ノルマは逆効果-〜なぜ、あの組織のメンバーは自ら動けるのか〜-藤田-勝利/dp/4778316614 ,（2025年5月2日アクセス） ＜チームからのフィードバック＞ マネジメントって苦手意識があったけど、ハードルが下がった。 マネジメントの目的が何かを知ることができてよい学びの機会だった。 マネジメントにあまり魅力を感じてなかったけど、今後必要なスキルだとわかった。 マネジメントは「セルフマネジメント」から マネジメントとは何かを学んだことで、何から始めたらいいか、が分かるようになりました。 チームをマネジメントする前に、まず私たち自身が 「セルフマネジメント」 できているかを見つめ直すことがマネジメントの出発点です。 では、セルフマネジメントとは具体的に何を意識することなのでしょうか？ それは、まず 自分自身を客観的に理解すること から始まります。 自分自身の強みや弱み、仕事の進め方を理解しているか？ 自身のセキュリティ知識・スキルレベルを把握し、常にアップデートする意識を持っているか？ 定期的に 内省 （振り返り）を行い、学びを得られているか？ そのためのツールとして、 1on1ミーティング などを効果的に活用できているか？ 自分という最も身近な資源を理解し、活かすことから全ては始まります。（と、ドラッカーも言っているはずです） 特にセキュリティ分野は変化が激しくストレスも多い仕事であるため、自分自身をモチベートして、継続的な学習意欲を維持することがとても大事だと考えています。 自分自身に向き合うという方法としては、1on1が使えるだろうということで、以下を実施しました。 ＜私たちの取り組み＞ 1on1勉強会 を実施しました。1on1の重要性や具体的な方法について、1on1を実施される側も含めて、こちらもマネジメントと同じくチームで共通理解を作りました。 勉強会で学んだことを、少しずつ1on1に取り入れて、私たちの1on1の型を作っていっています。とくに、セキュリティエンジニアとしてのキャリア形成やスキルアップをどのように進めていくかを対話し、支援していくことが大事になるだろうと思っています。 ＜チームからのフィードバック＞ 前職で1on1を実施していたが、なんとなくやっていた。進め方が分からないので最初から本題に入るとか…。これだと1on1をよい場にはできないんだという気づきを得ることができた。 1on1にも型があって、それをまずは実践して、守破離の流れで自分のものにできれば、今後のキャリアの役に立ちそう。 「個」から「チーム」へ：チームビルディング セルフマネジメントを意識できるメンバーになってきたら、次は 「チーム」として機能するための土台作り 、すなわち チームビルディング です。 （実際は、セルフマネジメントができているかにかかわらず、チーム組成のタイミングで実施するのがおすすめです） 実は、組織体制上の箱として組織を作り、そこに人を集めただけだと、それは単にグループであって、チームとは言えません。チームになるためには、共通の目的、相互理解、期待のすり合わせが必要で、それができて初めてチームになれるのです。 そのため、まずは正しい理解を身に着ける（体系的な知識を得る）のがよいだろうと考え、以下を実施しました。 ＜私たちの取り組み＞ 「ドラッカー風エクササイズ」という手法を使いました。 メンバーそれぞれが「 他のメンバーに期待すること 」や「 自分がチームに貢献できること（強み） 」「 大切にしたい価値観 」などを共有し、相互理解を深めました。 ※ 実際に使ったドラッカー風エクササイズのテンプレート（Miro）。一般的な4つの問い（四方）に真ん中の「個人の夢/目標」を入れているのが工夫ポイントです。人数分作成して、チームで対話しながら共有していきます。 チームビルディングを通じて共有された個性や期待を参考に、チームの「ミッション」や「大切にしたい価値観」を作りました。 チームの大きな方向性は「 セーフィーのサイバーセキュリティ戦略の作り方 」にある通りです。 これを組織の「意図」として捉え、チームのミッションと価値観に落とし込みました。 （記事での紹介は長くなるので割愛します！） ＜チームからのフィードバック＞ 一緒に仕事していても、意外とその人のこと知らないんだって気づいた。こういう機会があると、今後の仕事もちょっとやりやすくなりそう。 期待を伝え合うのはちょっと気恥ずかしいけど、このすり合わせが大事なんだと思った。ちょっとやる気が出たかも。 アジャイルな仕事の仕方を取り入れる さて、チームビルディングをしたぞ！明日から、いいチームワークで仕事ができるぞ！となればいいのですが、そう簡単ではありません。 仕事の仕方を少し工夫する必要があります。 フィードバック駆動のチームになるためのヒントは 「アジャイル」 です。 アジャイルとは何かの説明は本記事では省略しますが、アジャイルを取り入れようとしたときに気を付けないといけないのは、盲目的かつ表面的にプラクティスに従ってしまう 「フレームワークの罠」 です。 そして、この「フレームワークの罠」から逃れる方法は、「①意義のあるものにする」「②自分のものにする」の2つが大事になってきます。 ※ 脅威モデリングナイト#8 （金原登壇資料）より抜粋 「①意義のあるものにする」に関しては、すでにセキュリティ戦略とチームのミッション、価値観という理由付けができているので、ここでは「②自分のものにする」ためのプラクティスを考えます。 具体的には以下のような形で、プラクティスを取り入れました。 ＜私たちの取り組み＞ スクラム を採用しました。（わかりやすい＝自分のものにしやすい） スクラムのインベントの中で、今のチーム状況に合った以下の3つから始めています。 スプリント期間の設定 ：現在は2週間としています。 スプリントの始まりと終わりにイベントの実施 ：スプリントの開始時に「スプリントプランニング」を、終了時に「スプリントレビュー」を実施します。 タスクを可視化してデイリーで認識合わせ ：「カンバン」を利用して日々のタスクの状況をデイリーで共有しています。困っていることはここで可能な限り解消します。 ※ 実際に使っているカンバンです。弊社はNotionを使っており、「 Anthropic プロジェクトプランナー 」というテンプレートをカスタマイズして使ってます。プロジェクトとタスクでうまく整理できる良いテンプレートです。 特に重視しているのが 「スプリントレビュー」 です。 ここでは、2週間のスプリントで得られた成果や学びを、 経営層（正確にはCTO森本）に直接報告・デモンストレーション しています。 これにより、セキュリティに関する課題や進捗状況の透明性を高め、経営層からの理解とサポートを得やすくなると思っています！（そう願っています） なお、お気づきと思いますが、フィードバック駆動と言いながら「ふりかえり」をやっていません。これは現時点で私たちチームの人数が少数なのと、日々のコミュニケーションで常に改善を実施できている（デイリーでフィードバックができている）ことが理由です。 そして、これが完成形ではないので、これから徐々に自分たちの型を作っていきます！ ＜チームからのフィードバック＞ チームでタスクを共有して、2週間でやるとコミットしてるので、メリハリが生まれる。 カンバンで、チームのみんなが何をやっているかわかるので、タスクの調整がしやすくなった。 スプリントレビューで、自分たちのやっていることを把握してもらいやすくなった。 チームを育成し、拡大していく チームとして機能し始めたら、次に取り組むべきはメンバーの 成長支援 と、戦略実行のための チーム拡大 です。 なお、ここまでのチームづくりでは、セキュリティの話題はあまり出てきませんでしたが、ここまで整えてやっとセキュリティの話ができます。（お待たせしました） セキュリティチームの育成と拡大になりますので、サイバーセキュリティにどのようなキャリア（スキルセット）があるのかという全体像を把握した上で、セーフィーのサイバーセキュリティ戦略と個人の意図をうまく整合させて、成長につなげます。 ＜私たちの取り組み＞ SANSの「COOLEST CAREERS IN CYBER」を参考にしました。 (出典)SANS - Discover the Coolest and Most In-Demand Cybersecurity Careers, https://www.sans.org/cybersecurity-careers/20-coolest-cyber-security-careers/ （2025年5月2日アクセス） まずは、私を含めた ”今ここにいる” セキュリティチームのメンバーがそれぞれどのキャリアの意図なのか、それに必要なスキルセットは何かを「1on1」や「チームビルディング」を活用して明らかにして、成長の目標にします。 加えて、先に策定したサイバーセキュリティ戦略から、戦略実行に必要な人員とスキルセットを見定めます。（下の画像はコーポレートセキュリティの例です） コーポレートセキュリティの例 そうすると、現状のチームメンバーでカバーしきれないスキルセットやキャパシティ（リソース）が見えてきます。これが戦略とのギャップになります。 このギャップをベースに採用計画を立てて、今現在、積極採用しております！ ＜チームからのフィードバック＞ 目指すべき場と次のステップの具体的なイメージを持つことができた。 セキュリティ業務の大まかな全体像がつかみやすい。 現状のチームと戦略とのギャップが見えて、どういう強みや経験を持った人を採用したいかが言語化できた。 おわりに セーフィーのサイバーセキュリティ戦略を実行し、より高いレベルの「安心・安全」を実現するためのチームづくりは、まだ始まったばかりです。 今回お話ししたように、 「ちゃんとマネジメントする」ことを全ての基本とし、 そのうえで戦略に基づいた人材の育成と採用を進めること が、その核心にあると考えています。 セルフマネジメントから始め、チームとして機能させ、アジャイルに動き、成果を出していく。このプロセスを通じて、セーフィー全体のセキュリティ文化をより良いものにできるよう私たちセキュリティチームも成長していきたいと思います！ 私たちのこうした取り組みに少しでも共感し、 「セーフィーのセキュリティチームで一緒に仕事がしたい！」 と感じていただけたなら、ぜひ採用情報もご覧いただけると嬉しいです。 open.talentio.com 最後までお読みいただき、誠にありがとうございました。

はじめに こんにちは！ クオリティマネジメントオフィスQCD第2グループ 吉田と申します。 セーフィーでは様々なプロダクトがありますが、主にSafie Viewer for モバイルのQAを担当しております。 今回はモバイルチームのリグレッションテストケース改善見直しについて書かせていただきたいと思います。 先日Safie Viewer for PCの方でもリグレッションテストケースの改善についての記事を公開しましたが、今回はモバイルチームとしての取り組みを共有したいと思います。 Safie Viewer for PCの記事も合わせてご確認ください！ https://engineers.safie.link/entry/regression_test はじめに リグレッションテストとは? モバイルチームの現状 取り組み 現在 今後について リグレッションテストとは? 改めてリグレッションテストについてはJSTQBのシラバス(41p)で下記の様に定義されています。 修正および変更でコードの一部に対して行った変更が、同一コンポーネント、同一システム内の他コンポーネント、または他システムの振る舞いに意図せず影響を及ぼす場合がある。変更には、オペレーティングシステムやデータベース管理システムの新しいバージョンなど、環境の変更も含まれる。そのような意図しない副作用をリグレッションと呼ぶ。 リグレッションテストでは、テストを実行して、そのような意図しない副作用を検出する。 Safie Viewer for モバイルでは、現在月一で定期的にリリースを行っており、1リリースで大小様々な機能を追加、不具合改修を行っております。 リリースを繰り返す中で、悪い影響(意図しない影響)を与えていないか、既存の機能が問題なく動いているかを毎回実施しており、ここが実はすごく重要なテストになっております。 SafieViewer for PCのテックブログでも触れていましたが、毎月リリースをということで機能を追加すれば、それだけ次のリリース以降で確認するリグレッションテストケースに追加されていくことになり、月一のリリースの中で、実は一番時間がかかっているのもリグレッションテストだったりします。 モバイルチームの現状 そんな状態で、どんどんテストケースが追加していくと当然ながらテスト時間も追加していきます。 そうして行く内にどうなるかというと、簡単に言うと「あれ、今まで時間内に終わっていたけどもしかしてテストが終わらない…?でもリリースは迫っている、残業するしかない！！？？」みたいなことがおこり得ることになります。 実際のテストケースですが、私が入社した2022年12月では600ケース程度だったものが、約2年経った2024年10月時点では1300ケース近くと約2倍に増加しておりました。 ※初期からテストケースの修正は重ねてはいるので、粒度は違いますが、それだけ多く追加されているということです。 さらにAndroidとiOSでアプリ同時リリースをしているので単純に2倍の時間がかかります。 リリース 実施項目数 2022年12月 (v3.18.0) 623 2024年5月 (v4.13.0) 903 2024年10月 (v4.18.0) 1353 取り組み さて、どうしようかと考えた時モバイルチームでは下記を取り組みました。 ①自動化テストケースへの置き換え 以前から片手間で推進していた自動化を強制的に、メンバー全員でMagicPodによるリグレッションテストケースの自動化導入をすることで、手動でしかできないテストケース以外は自動化に置き換え、効率化を進めました。 こちらはQCD第1グループの森重さんが中心になって進めてくれたおかげで3割程度が自動化で回せるようになっています!!こちらは森重さんの方でまた新たに記事にしてくれるはず！！ 自動化の理解が浅かったメンバーの育成から開始して結果としてモバイルチーム全体で大きな取り組みになりました！ ②テストケースの優先度の見直し 今までも優先度自体は付与していたのですが、基準をより詳細にすることでチーム内で確認できるように再定義しました。 リリース後に不具合が出たらユーザー影響が高い機能(再生、デバイス設定、データ作成)などは優先度を高(Critical)に、毎回確認する必要がないようなエラー系や、閾値の確認などは優先度は低(Low)にするなど。 再定義することでPJメンバーとも認識の共有もできたと思っています。 また、今回新たに【Medium01】【Medium02】としてローテーションという優先度を設定しました。 これはリリース単位で毎回ではなく、ローテーションして実行するというケースです。 例えばモバイルアプリにはイベントを検知したらプッシュ通知が飛ぶようになっているのですが、このイベントには種類が複数あります。 プッシュ通知が飛ぶという機能の仕組み自体は一つのイベントで確認できるので、複数のイベントを分割することで、1回に確認する量を効率化させる調整をしました。 この様に新たな優先度を設定することでテスト内容を見直し、重要な機能により注力してテストを実行する様に調整をいたしました。 現在 取り組みを始めた後、1リリースに1300近くあったテストケースは900ケース弱くらいまで整理することができました！！ 自動テストを除外すると、現在約700ケース程を手動テストで実施しています。 また、実施にかかる工数自体も削減でき、リソースが逼迫するということもなくなりました。 【Medium01】/【Medium02】などのローテーションのケースに関しても、現状では大きな問題はなく、引き続き追加されるケースについては精査を続けて行きたいと思っています。 リリース 実施項目数 実施工数 2024年10月 (v4.18.0) 1353 18h 2024年12月 (v4.20.0) 897 10h 2025年2月 (v4.22.0) 707 8.4h 今後について 改めてになりますが、本取組はただテストケースが多いから減らしたいということではなく、リグレッションテストは大事なテストだという大前提の元、どこがお客様にとってよりリスクになりうる機能なのかに重点を置き、効率よく品質のいいものを素早く提供したいという軸の見直しとなります。 お客様にとってあまり使われていないような機能の挙動をひたすら叩くよりは、より使われる機能に対して、重点をおいて確認をしていきたい。 また、そのような使われていない機能の確認は自動化に置き換えてそちらで担保をしていくなど、QCDチームも日々研鑽しております。 自動テストについてもメンバー全員の理解力と技術力が向上し、問題解決にかかる時間も短縮されるなど、成果も出てきています。 これからも日々研鑽しながらよりよいテスト活動をしていきたいと思っています。 セーフィーではエンジニアを積極的に募集しています。どのような職種があるのか気になる方はこちらをご覧ください！ safie.co.jp カジュアル面談から受け付けておりますので、気軽に応募いただければと思います！ 皆様のご応募、心よりお待ちしております！ 最後までお読みいただき、ありがとうございました

はじめに セーフィー株式会社 AI開発部 でテックリードを務めます橋本です。 テックリードとしてキャリアを積む中で、避けては通れないテーマの一つが「レバレッジの効いた仕事」です。つまり、自分一人のアウトプットを超えて、チームや組織全体により大きなインパクトを与える働きが求められるようになります。 その中でも、特に重要だと感じているのが「組織力の強化」、つまり チーム開発 です。どれだけ自分が手を動かしても、個人の力には限界があります。しかし、自分が持つ知識やノウハウ、考え方をメンバーに共有し、仕組みとして浸透させることができれば、その効果は現在だけでなく、将来のチームにも大きなレバレッジを生むと考えています。 私の前職は、個人主義が強い研究職の文化に身を置いており、チーム開発や組織に働きかける経験はほとんどありませんでした。実際、チームの成長のために良かれと思って行った発言が、批判的に受け取られ、防衛的な反応を招いてしまったこともありました。結果として、チームに良い影響を与えたいという気持ちとは裏腹に、うまくいかないと感じることがありました。 本記事では、そうした課題感から学び始めた チーム開発やコミュニケーションに関する書籍 を紹介し、読書を通じて得た気づきや学びを紹介したいと思います。 はじめに 読んだ本 「何回説明しても伝わらない」はなぜ起こるのか？ NVC人と人との関係にいのちを吹き込む法 サーチ・インサイド・ユアセルフ ヤフーの１on１ ダイアローグ――対立から共生へ、議論から対話へ 学習する組織――システム思考で未来を創造する おわりに 読んだ本 「何回説明しても伝わらない」はなぜ起こるのか？ 著者: 今井 むつみ 出版社: 日経BP 発売日: 2024/5/9 概要 思考のスキーマについて、分かりやすく解説しています。聞き手は、自分が発した言葉そのものではなく、これまでの経験や価値観を手がかりに「意味を補完・再構成」して受け取ります。これが、何回説明しても伝わらない大きな理由だと述べています。 気づき これまで、聞き手が正しく理解してくれることを想定して、説明力を付けることを意識していました。しかし、本書を通じて、聞き手の頭の中に再構成された情報に注意を向けることが重要だと気付きました。 NVC人と人との関係にいのちを吹き込む法 著者: マーシャル・B・ローゼンバーグ 出版社: 日本経済新聞出版 発売日: 2018/2/17 概要 Non-Violent Communication（NVC、非暴力コミュニケーション）について提案しています。何かを依頼するときや、相手と対立が生じているとき、私たちの内面では「観察」「感情」「ニーズ」「要求」というプロセスが起こっています。自分と相手の内面のプロセスに注意を向けることで、対立を避け相互理解を深められると述べています。 気づき 何か依頼するとき、私たちは、現状のままで依頼が受け入れられないと「開発効率が悪化する」「不具合の原因になる」といった不安（感情）を根底に持っています。今までその感情を伝えることを考えたことはありませんでしたが、本書を通じて重要性に気づきました。 サーチ・インサイド・ユアセルフ 著者: チャディー・メン・タン 出版社: 英治出版 発売日: 2016/5/17 概要 Google のエンジニアの視点で、マインドフルネスとその効果、その能力を高めていく実践法を、科学的な知見に基づき解説しています。特に「マインドフルネスとは、今この瞬間に注意を向ける能力」であることを、エンジニアにも馴染みやすい表現で丁寧に伝えています。 気づき これまで紹介してきた本では「内面に注意する重要性」が強調されていましたが、本書では、その注意力をどう高めるか、具体的な方法が示されており、理解が深まりました。 ヤフーの１on１ 著者: 本間 浩輔 出版社: ダイヤモンド社 発売日: 2025/2/19 概要 ヤフー社が実践してきた1on1ミーティングのノウハウを紹介しています。1on1の目的はメンバーの成長支援であり、沈黙や問いかけによって、メンバー自身の気づきを引き出すことが重視されています。また、コミュニケーションを「意図が伝わり、相手の行動が変わること」と定義している点も特徴的です。 気づき コーチングの重要性は頭では理解していたものの、実践できていないという自覚がありました。1on1の目的や沈黙の価値を改めて認識し、設計を見直したいと感じました。また、伝えたつもりで終わらせず、相手が動ける状態になるまで責任を持つ姿勢の重要性にも気づきました。 ダイアローグ――対立から共生へ、議論から対話へ 著者: デヴィッド・ボーム 出版社: 英治出版 発売日: 2007/10/2 概要 物理学者である著者の経験から生まれた本書では、対話（ダイアローグ）の本質が語られます。ダイアローグとは、個々の意見をぶつけ合うのではなく、集団で意味を紡ぐ参加型思考です。組織が陥りやすい「断片化」（考えや価値観がバラバラな状態）を乗り越え、全体が「コヒーレント」（一貫性を持った状態）になることで、組織の力が本当に発揮されると述べています。 気づき 断片化が進むと、チームのエネルギーが分散し、レバレッジが効かなくなるという点が非常に腑に落ちました。テックリードとして、メンバーが同じ方向を向けるように、意識的に対話の場を作っていきたいと感じました。 学習する組織――システム思考で未来を創造する 著者: ピーター・M・センゲ 出版社: 英治出版 発売日: 2011/6/22 概要 組織が学習するとは、個人や組織が持っている前提や思い込み（スキーマ）を更新することだと定義しています。そのためには、組織内でダイアローグを行い、共通認識を作ることが重要です。また、システム思考を用い、組織の課題がどこにあり、どこにレバレッジポイント（少ない力で大きな変化が起きる場所）があるのかを具体例を交えて解説しています。 気づき これまで読んできた本で語られていた「スキーマ」「対話」「内面への注目」と、組織開発が密接に関係していることを理解できました。特に、システム全体を捉え、どこに働きかければ最大の変化を生むかを考えるレバレッジ思考は、テックリードとして実践していきたい重要な視点です。 おわりに 本記事では、チーム開発やコミュニケーションに関する書籍を通じて、私自身が得た気づきや学びをまとめました。 特に印象的だったのは、チームメンバーとの関係性、対話の質、そして内面への理解といった、一見すると曖昧で目に見えない部分こそが、チームの力を最大化する鍵であるということです。説明が伝わらない、対立が生まれる、チームが同じ方向を向けないといった問題は、単に個人のスキルだけでは解決できない、もっと深い要因があるのだと分かりました。 もし、同じような課題や悩みを感じている方がいれば、今回ご紹介した書籍や学びが少しでも参考になれば幸いです。 最後になりますが、書籍の選定に際し、当社CTOの森本数馬、および鎌倉マインドフルネス・ラボの宍戸幹夫様よりご助言をいただきました。この場を借りて、心より感謝申し上げます。

はじめに セーフィーの髙木 @hitsan です。 今年の4月に新卒3期生が入社しました。セーフィーでは約3週間の全体研修を行い、職種別研修に分かれます。職能別研修である開発本部での新卒エンジニア研修は7月末まで実施し、そのあと各チームに配属という流れです。 新卒3期生のエンジニア研修がスタートしたので研修内容について説明します。 はじめに セーフィーの新卒エンジニア研修 研修の基本的な考え 新卒研修の目的を再定義 活躍するエンジニアって？ Mission Vision Value カリキュラムの紹介 コーディングルール作成 カンファレンス参加 セキュリティハンズオン チーム開発 キックオフの様子 おわりに セーフィーの新卒エンジニア研修 今年は去年と同様、7名の新卒エンジニアが入社しました。 今年の新卒研修は今までのカリキュラムを踏襲しつつ、目的の再定義やいくつかのアップデートを行っています。 研修の基本的な考え 成長機会とサポートをしたうえで、研修の運営そのものは新卒エンジニアが自分達で考えて実行するというスタイルで研修を進めます。 例えば、以下のようなことも新卒エンジニアで考え提案して合意を得るところから研修がスタートします。 進捗報告のやり方 会議体設計 研修のスケジュール決め 新卒研修の目的を再定義 新卒研修の目的は「エンジニアとして活躍できるように成長すること」と定義しています。新卒研修の目的としては一般的だと思いますが、成長できるかどうかを意思決定の基準にする、という意図があります。意思決定の基準を提示する意図は以下のとおりです。 成長につながるなら貪欲にチャレンジすることができる 判断に迷ったときに新卒が立ち返る指標になる 研修中は常に自分たちの成長を意識してもらいます。 活躍するエンジニアって？ エンジニアとして活躍するために今回の研修で身に付けてほしいことは以下の3つです。 プロダクト思考 エンジニアのマインド 基礎スキル さらに分解するとこんな感じです。 プロダクト思考 ユーザー体験 プロダクトマネジメント エンジニアのマインド チームプレイ 学習し続けること 成果をアピール 基礎スキル ソフトウェア ファームウェア セキュリティ 品質マネジメント etc.. セーフィーのエンジニアとして意識してほしいことですが、そもそもエンジニアとして働くために重要な項目をピックアップしました。研修中のカリキュラムもこれを身に付けられるように組んでいます。 実際のカリキュラムはこんな感じです。 プロダクト思考 チーム開発 テクニカルサポート研修 エンジニアのマインド チーム開発 チームビルディング ブログ執筆 カンファレンス参加 基礎スキル チーム開発 Udemy AWSハンズオン セキュリティハンズオン コーディングルール作成 Mission Vision Value 新卒エンジニアのチームビルディングの一環としてチームのMission Vision Valueを今年から策定しました。 Mission エンジニアとして活躍できる状態になる Vision プロダクト思考を体得する Value ユーザー体験を追求する 不確実性と正しく向き合う 研修期間にアップデートしてもらうことを前提にしているため現時点では最低限のMVVしか用意してません。研修が終わった時点でどのようになりたいかを考えて定期的にアップデートしてもらいます。 カリキュラムの紹介 カリキュラムをいくつか紹介します。 コーディングルール作成 去年まではリーダブルコードの要約を課題にしていましたが、今年はこれを読んだうえでどのようなコードを書くか考えてもらいます。 書くことのルールは以下のとおりです。 できること、取り組めそうなことを記載する できない、わからないことは記載しない 研修中アップデートしていく このようにした目的は以下のとおりです。 学んだことをどう生かすか考えてほしい 自身のスキルを客観的に見れるようになってほしい カンファレンス参加 去年もいくつかのカンファレンスに参加してもらいましたが、今年は1件以上の参加とその報告してもらいます。外部からインプットする習慣を身に付けてもらうこととエンジニア文化に触れてもらうことが目的です。 セキュリティハンズオン こちらも今年からはじめたものです。セキュリティエンジニアの金原さんに講師をやってもらい脆弱性体験ハンズオンとリスク評価ワークショップをやってもらいます。金原さんが執筆された記事があるのでよければ こちらの記事 もご参照ください。 チーム開発 毎年やっている課題で研修の大部分を占めるものになります。こちらは例年通り「社内の不を解決するプロダクトの開発」がテーマです。 去年の研修の内容はこちらをご覧ください。 新卒研修の紹介とチーム開発前にやったこと 2024年新卒エンジニア研修-アジャイル開発編 2024年新卒エンジニア研修-isai connectについて 2024年新卒エンジニア研修-isai connect開発のアウトプット_サーバーサイド 2024年新卒エンジニア研修-フロントエンド開発編 2024年新卒エンジニア研修-インフラ構築編 2024年新卒エンジニア研修-isai connect開発のアウトプット_デバイス編 2024年新卒エンジニア研修-新卒研修の成果発表とその後 キックオフの様子 最後に初日の研修キックオフとトレーナー顔合わせの様子をお見せします。 新卒、トレーナーを集めて本記事で説明した研修の概要と目的、期待値を共有しました。以下の画像はキックオフの様子です。 キックオフMTGの様子 研修のキックオフをした後は新卒とトレーナーの顔合わせです。全員で14名いるので3チームに分けて行いました。 トークテーマは以下のとおりです。 最近のささやかな楽しみ 何でセーフィーに入ったの？ 自己紹介を深掘ろう！ 新卒研修って実際どう？ トレーナーとの顔合わせ 顔合わせの後は24卒が定期的にやっている勉強会に参加してもらいました。トレーナーの1年間の成長が感じられていいですね。 勉強会の様子 おわりに セーフィーの新卒エンジニア研修の組み立て方について解説しました。どのような考えで研修をやっているか分かっていただけたのではないでしょうか？ 今後、新卒エンジニアの記事も投稿されます。温かく見守っていただけると幸いです。 25年度新卒研修に関する記事はこちらをご覧ください。 2025年、新卒エンジニア研修はじめました ← 本記事 Notion初学者のためのショートカット活用術：業務効率を上げる第一歩 100人をマネジメントした指揮者が 新卒で挑戦した「不確実性」と向き合うチームビルディング 新卒一年目のエンジニアが感じた、プレ開発で見えたチームの“成長” ゼロから学んだフロントエンド実装 毎日の日報報告をワンボタンで ハッカーの視点を身に付ける！新卒が学んだセキュリティ研修

こんにちは。サーバサイドエンジニアの村田 ( @naofumimurata )です。 この度、Safie API を利用するMCP (Model Context Protocol) サーバである「Safie API MCP Server」を作成・公開しました。 github.com 本記事では使い方などを簡単に紹介したいと思います。 MCPサーバとは Safie API MCP Server の概要 使い方 事前準備 利用例 まとめ MCPサーバとは Model Context Protocol とは、Anthropic社が発表したアプリケーションがLLMにコンテキストを提供する方法を標準化するオープンプロトコルです。 LLMに対してMCPで機能を提供する MCPサーバ を用意することで、LLMから外部APIを呼び出してその結果をLLMに与えて判断させるといったことが可能になります。 MCPを利用できるクライアントとしては、Anthropic社が提供するClaude Desktopをはじめとして ClineやVS Code GitHub Copilot Agentなどでも利用可能です。直近だとOpenAIもMCPのサポートを発表しました。 MCPサーバ実装も既に様々なものが公開されており、多くのクライアントで多くのMCPサーバが利用できる様になってきています。 github.com Safie API MCP Server の概要 Safie API を利用してデバイスの情報取得や操作を行う機能を提供します。 (Safie API リファレンス: https://developers.safie.link/reference/api ) 現時点で提供している機能（Tools）は以下の通りです。 list_devices デバイス一覧を取得します get_device_image 指定されたデバイスから画像を取得します list_device_media 指定されたデバイスで録画されている映像（メディア）の一覧を取得します get_device_location 指定されたデバイスの現在のGPS位置情報を取得します get_device_thumbnail 指定されたデバイスの最新サムネイルを取得します list_device_standard_events 指定されたデバイスの標準イベント情報一覧を取得します 詳しくは README をご参照ください。 使い方 事前準備 Safie APIを利用するにあたり、以下のドキュメント、記事を参考にSafie Developersへのディベロッパー登録とアプリケーションの作成、認証情報（OAuth2 アクセストークンまたはAPIキー）の発行を行なってください。 developers.safie.link engineers.safie.link 認証情報発行後、Claude Desktop等のAIツールに以下の設定を追加することで、利用可能となります。(Python 3.10+, uv が手元にインストールされている必要があります) OAuth2アクセストークンを利用する場合: { "mcpServers": { "Safie API": { "command": "uv", "args": [ "run", "--with", "git+https://git@github.com/SafiePublic/safie-api-mcp-server.git", "safie-api-mcp-server" ], "env": { "ACCESS_TOKEN": <発行したOAuth2アクセストークン> } } } } APIキーを利用する場合: { "mcpServers": { "Safie API": { "command": "uv", "args": [ "run", "--with", "git+https://git@github.com/SafiePublic/safie-api-mcp-server.git", "safie-api-mcp-server" ], "env": { "API_KEY": <発行したAPIキー> } } } } 利用例 それでは、実際に使ってみた例をご紹介しましょう。今回は社内にあるオフィスコンビニの商品棚の状況についてLLMに聞いてみたいと思います。 AIツールはClaude Desktop を利用し、モデルは Claude 3.7 Sonnet を利用しました。 ちゃんとLLMがSafie API MCP Serverを実行して答えを返してくれました。 プロンプトにはあえてデバイスを特定するIDを入れなかったのですが、デバイス一覧取得（list_devices）をまず実行してオフィスコンビニに設置してあるカメラを特定し、その後、対象カメラに対して画像取得（get_device_image）を実行、取得した画像から答えを返してくれました。 まとめ 本記事では、Safie APIを利用するMCPサーバである「Safie API MCP Server」について概要と利用方法について紹介しました。 ぜひ、使ってみてください！ なお、本実装はプレビュー版であり一部の機能のみを試験的に提供しています。 サポート対象外となりますのでご了承の上、お使いください。 セーフィーではエンジニアを積極的に募集しています。どのような職種があるのか気になる方はこちらをご覧ください！ safie.co.jp カジュアル面談から受け付けておりますので、気軽に応募いただければと思います！ 皆様のご応募、心よりお待ちしております！ 最後までお読みいただき、ありがとうございました

はじめに こんにちは！セーフィー株式会社でサイバーセキュリティを担当している金原です。 セーフィーは「映像から未来をつくる」というビジョンのもと、クラウド録画サービスを提供しています。私たちのサービスは、防犯・見守りに留まらず、業務効率化や現場DXなど、様々なシーンで社会の「安心安全」を支えています。 この「安心安全」を実現する上で、サイバーセキュリティは極めて重要な要素です。お客様の大切な映像データを守り、サービスを安定して提供し続けることは、私たちの事業の根幹を成すものです。そして、単に守るだけでなく、セキュリティを競争優位性に繋げていくことも目指しています。 そのために、私たちはセキュリティ戦略を策定し、全社で取り組んでいます。 今回の記事では、私たちがどのようにセキュリティ戦略を考え、構築しているのか、その全体像をご紹介します。この記事が、セーフィーのセキュリティへの取り組みに興味を持ってくださる方や、同じようにセキュリティ戦略の策定に取り組む企業の担当者の方にとって、少しでも参考になれば幸いです。 はじめに なぜセキュリティに「戦略」が必要なのか？ 私たちが考える「戦略」とは？ セーフィーのセキュリティ戦略のコンセプトとゴール 戦略を形にする「打ち手」 戦略を推進する「ストーリー」とは？ 今後の展望と仲間募集 おわりに なぜセキュリティに「戦略」が必要なのか？ まず「セキュリティ対策」と聞くと、ファイアウォールの導入、脆弱性診断、従業員教育など、具体的な施策を思い浮かべる方が多いかもしれません。もちろん、それらは非常に重要です。 しかし、セキュリティの世界は広大で、やるべきことは無数にあります。技術は日々進化し、脅威の手法も巧妙化しています。限られたリソースの中で、場当たり的に対策を進めていては、本当に重要な課題に対処できなかったり、対策の効果が薄れたりする可能性があります。 どこに向かうのか（ゴール）、なぜそこに向かうのか（目的）、そして、どのような道筋で進むのか（計画）。これらを明確にする 「戦略」 がなければ、迷子になってしまいます。 だからこそ、私たちはまず立ち止まり、腰を据えて「セキュリティ戦略」を考えることから始めました。 では、私たちは「戦略」をどのように捉えているのでしょうか？ 私たちが考える「戦略」とは？ 一般的に、戦略とは「目標達成のための中長期的な計画や方針」を指しますが、私たちは楠木建先生の著書『ストーリーとしての競争戦略』の考え方を参考に、戦略を 「人を動かすストーリー」 として捉えています。（事業戦略の本ですが、考え方は様々な戦略に応用できるものです） ストーリーとしての競争戦略 出典：Amazon https://www.amazon.co.jp/ストーリーとしての競争戦略-―優れた戦略の条件-Hitotsubashi-Business-Review/dp/4492532706 （2025年4月9日アクセス） この本では、優れた戦略には、顧客や従業員の心を動かすような「面白いストーリー」が必要だと説かれています。なぜなら、戦略を実行するのは「人」だからです。どれだけ立派な計画も、実行するメンバーが共感し、ワクワクできなければ、絵に描いた餅になってしまいます。 この考え方に基づき、私たちは以下のステップで戦略ストーリーを練り上げました。 徹底的に自分たちに向き合う まずは自分自身に「何を成し遂げたいのか」「どんな状態が理想か」を内省して問いかけ、そのあとじっくり腰を据えてチームメンバーと対話を重ねました。 コンセプト（目的）を磨く 対話を通じて、「これだ！」と確信が持てる戦略の核となるコンセプト（目的）を考え抜きました。 ゴール（競争優位）を設定する コンセプトの先に、どのようなビジネス上の価値（ゴール）を実現したいのかを明確にしました。 ストーリーで繋ぐ コンセプトとゴールを、具体的なアクションプラン（打ち手）を含んだ、誰もが情景を思い描けるような一連のストーリーとして紡ぎました。 セーフィーのセキュリティ戦略のコンセプトとゴール こうして生まれたセーフィーのセキュリティ戦略の コンセプト（目的） は、 「バランスの取れた本当の意味での高セキュリティの実現」 です。 ここで言う「バランス」とは、 「生産性を落とさず、柔軟に現場にセキュリティを適用すること」 を意味します。セキュリティを強化するあまり、開発スピードが落ちたり、従業員の業務が煩雑になったりしては本末転倒です。事業の成長を加速させつつ、セキュリティレベルも高めていく。この両立こそが、私たちが目指す「バランス」です。 そして、このコンセプトが目指す ゴール は以下の2つです。（2つ作っちゃいました） セキュリティを事業戦略上の重要な差別化要素にする セキュリティの専門家でなくてもセキュリティを向上させることができる文化を作る 単に「守る」だけでなく、セキュリティの高さを顧客への提供価値や信頼に繋げ、全従業員が当たり前のようにセキュリティを意識し、実践できる。そんな状態を目指しています。 戦略を形にする「打ち手」 コンセプトとゴールを実現するための具体的な 打ち手（アクションプラン）の中心となるのが、「セーフィー版セキュリティ成熟度モデル」 の構築と運用です。 セーフィー版セキュリティ成熟度モデルの概要図は以下になります。このモデルは、大きく以下の2つの領域に適用されます。（図中のLevelは、サンプル値です） 1. コーポレートセキュリティ: 従業員や社内システム、オフィス環境など、企業全体のセキュリティ。NIST CSF をベースにしています。 2. プロダクトセキュリティ: お客様に提供する セーフィーのサービス自体のセキュリティ。OWASP SAMM をベースにしています。 セキュリティ対策には、NIST CSF や OWASP SAMM など、世界的に参照されている優れたフレームワークが存在します。私たちはこれらのフレームワークを積極的に活用しています。 しかし、これらのモデルをそのまま導入するだけでは、セーフィーのカルチャーやビジネスドメイン、開発プロセスに完全にフィットするとは限りません。そこで、これらの一般的なモデルをベースにしつつ、セーフィーの実情に合わせてカスタマイズ（ セーフィー化 ）し、独自の解釈を加えた「セーフィー版 セキュリティ成熟度モデル」を作成・運用しています。（概要図には、大枠のカテゴリしか記載がありませんが、実際にはカテゴリの中で、何をやるかをカスタマイズしている形になります。今回は説明しません。） さらに、各カテゴリの施策の優先度付けには「The Sliding Scale of Cyber Security」という考え方を導入し、「Architecture（設計思想・基盤）」から段階的に強化していくアプローチを取っています。 各施策の進捗状況は、私たちが定義した 成熟度レベル (Level 0〜4) で可視化し、継続的な改善を促しています。例えば、「Level 1: 方針やルールが文書化されている」状態から、「Level 3: チームで自律的に運用されている」状態へ、そして最終的には「Level 4: 継続的な改善が回っている」状態を目指します。 戦略を推進する「ストーリー」とは？ コンセプト、ゴール、打ち手。これらを繋ぐことで、私たちを突き動かす 「ストーリー」 になります。ストーリーの核心は、先ほど説明した 「セーフィー版セキュリティ成熟度モデル」 と、全社一丸となって、安心安全な未来を作り上げていくという 「組織文化」 です。 セキュリティは、特定の部署や担当者だけのものではありません。 セキュリティはみんなの仕事 です。開発、運用、営業、管理部門など、すべての社員が当事者意識を持ち、それぞれの立場でセキュリティ向上に貢献できる文化を醸成すること。セキュリティを向上しつつも、生産性を維持してお客様に価値を届けていくこと。そのための仕組み（メカニズム）があること。 このような組織文化を踏まえ、コンセプトとゴールを結んだ戦略ストーリーが以下のような形になります。（簡単化のために、抽象度を上げています。本当はもっと細かい打ち手があります） このストーリーに共感し、共に汗を流してくれる仲間がいるからこそ、戦略は前に進みます。今はまだきれいなストーリーにはなっていませんが、戦略自体も定期的に見直すことで徐々に筋のいいストーリーに仕上げていく予定です。 （ストーリーの中の詳細な打ち手や、具体的な取り組み状況については、また別の記事でご紹介できればと思います！） 今後の展望と仲間募集 セーフィーのセキュリティ戦略はまだ始まったばかりです。中期的なロードマップに基づき、コーポレート・プロダクト両面で様々な施策を計画・実行しています。 例えば、 コーポレートセキュリティ: サプライチェーンリスク管理の強化、全社的な脆弱性管理プロセスの確立、ゼロトラストに基づいたアクセス管理の導入など プロダクトセキュリティ: 脅威モデリングに基づくセキュリティ要件の定義、セキュア開発トレーニングの実施、SAST/DAST/ペネトレーションテストの強化など これらの取り組みを加速させ、より高いレベルのセキュリティを実現するためには、新たな仲間の力が必要です。 セーフィーでは、セキュリティエンジニアをはじめ、様々なポジションでエンジニアを積極的に募集しています！ セキュリティへの情熱を持ち、戦略策定から実行まで幅広く携わりたい方 急成長する事業環境の中で、セキュリティの側面から貢献したい方 「映像から未来をつくる」というビジョンに共感し、安心安全な社会の実現に貢献したい方 少しでも興味を持っていただけたら、ぜひ下記の採用ページをご覧ください。カジュアル面談も大歓迎です！ https://open.talentio.com/r/1/c/safie/pages/76312 おわりに 今回は、セーフィーがどのようにセキュリティ戦略を考え、構築しているのか、その一端をご紹介しました。 私たちの取り組みが、セーフィーという会社や、セキュリティという仕事に興味を持つきっかけとなったり、他社のセキュリティ担当者の方々の戦略策定のヒントになったりすれば、これほど嬉しいことはありません。 最後までお読みいただき、ありがとうございました！

本記事では、GoogleスプレッドシートからSlackAPIとSlackApp（Slackbot）を使って通知を送る仕組みの作り方を、SlackAPI・GAS初心者にも分かりやすく画像付きで解説します。 はじめに なんでやろうと思ったか 用語解説 SlackAppとは？ Slackbotとは？ Slack APIとは？ Slackbot作成～Token発行まで 動作確認 テスト用データ作成 GASの設定 SlackIDを取得してみる このSlackIDって正しいの？？？ DMを送信してみる 直書きtokenをなんとかする 仕上げ 終わりに はじめに なんでやろうと思ったか Slackにて、ある特定（かつ大勢）の人達に連絡をする機会があり、対象者リストを元に連絡用チャンネル作って連絡を実施していました。 この業務ですが、めんどくさいポイントが複数ありました。例として数個あげるなら、 招待する人数が多いと招待する作業だけで骨が折れる 目が滑って抜け漏れが発生しやすい リマインドで何回も@channelするのも腰が引けるetc…. こういった連絡系のタスクを楽にできないかと考えた結果、「対象者リストにはメアドも記載されているので、わざわざ手打ちせずとも対象者リストを元に連絡作業をボタン1つで完了できるようにすればいいんじゃない？」と考え、作成に至りました。 また、SlackAPPやSlackAPIを使う事が初めてだったので備忘録として残しておこうと思い、執筆する運びとなりました。 用語解説 SlackAppとは？ Slackが提供する開発者用の拡張プラットフォーム全体のことを指します。WebhookやSlashコマンド、イベントハンドラーなど複数の機能をパッケージ化できます。 例えば外部サービス（Googleカレンダー、GitHub、Trelloなど）から通知を受け取ることができたり、ワークフローの自動化が実現できます。 slack.com Slackbotとは？ Slackbotとは、SlackAppの機能の1つで、Slack上で自動的にメッセージを投稿したり、ユーザーの指示に従って情報を提供するBotのことです。 Slackbotを使うことで、定型的な通知やリマインダーなどを自動化し、作業の効率化を図ることができます。 slack.com Slack APIとは？ Slack APIとは、Slackの機能をプログラムから利用するための仕組みです。 Slack APIを使えば、外部のアプリケーションやサービスからメッセージを投稿したり、Slackのデータを取得したりすることができます。 今回はこのSlack APIを使って、スプレッドシートの情報をSlackへ送信する仕組みを作ります。 api.slack.com Slackbot作成～Token発行まで まずはSlackアプリを作成します。 Slack APIページ へアクセスして、新しいSlackアプリを作成します。 赤枠で囲った 【Create New App】 を押下します Create an App のポップアップウィンドウが表示されるので 【From scratch】 を押下します アプリ名とワークスペースを入力する画面が表示されるので、該当箇所に必要な情報を入力します。 今回は「Slackbot_test」というアプリ名で作成します。ワークスペースは各自の環境を選択してください。 入力後、 【Create App】 を押下します。 今しがた作成したアプリ名の設定画面が表示されます。 これでSlackアプリ自体の作成は完了です！簡単ですね アプリにScopeの設定を行います。左側メニューから「OAuth & Permissions」を選択し、Scopes項目の赤枠で囲った 【Add an OAuth Scope】を 押下します。 ここでどういうアクションを許可するか設定します。 今回作りたい物を分解すると ①スプシ上のセルに書き込まれているメアドを参照して、紐づいているSlackIDを取得後( users:read ) ②SlackID宛にリマインドメッセージを飛ばす( chat:write ) となるので、 chat:write 、 users:read の2つを追加します Scopeを設定したら、このアプリをワークスペースへインストールします。 インストールすることで、Slack ワークスペース上でアプリを使用できるようになります。 「OAuth & Permissions」の上の方にある「OAuth Token」項の 【Install to xxx(ワークスペース名)】 を押下します。 SlackAppが ワークスペースにアクセスする権限をリクエストしてくるので、許可してあげましょう 無事このアプリ用のOAuth Tokenが発行されました！（黒くフィルターされている箇所にTokenが表示されています） このTokenを使用することで、SlackAPIを利用することができます 動作確認 本当にAPIを使用できるかどうか、実際にテストしてみましょう テスト用データ作成 Googleスプレッドシートの準備 新しいGoogleスプレッドシートを作成し、テストデータをセルへ書き込んでいきます。 とりあえず以下画面のようなデータを作成しました。 GASの設定 GASにSlackAPP用のライブラリを設定します。 スプレッドシートからGASを開き、画面左側にあるライブラリの”＋” をクリック → 以下のスプリクトIDを入力し、検索します。 1on93YOYfSmV92R5q59NpKmsyWIQD8qnoLYk-gkQBI92C58SPyA2x1-bq SlackAPPが見つかったら【追加】ボタンを押下します。 追加後、以下画面のようにライブラリ欄に「SlackAPP」が追加されている事を確認してください これでGASの設定は完了です SlackIDを取得してみる 以下のようなスクリプトを作成しましたので、このコードをGASへ張り付けます。 ※あくまでテストなのでtoken直書きになっていますがご承知おきください (後ほど隠す方法も記載します) function GetSlackUserId (){ // トークン const slack_OAuth_token = "xoxb-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ; // スプレッドシートの B2 からメールアドレスを取得 const sheet = SpreadsheetApp . getActiveSpreadsheet () . getActiveSheet () ; const email = sheet . getRange ( "B2" ) . getValue () ; const url = "https://slack.com/api/users.lookupByEmail" const options = { "method" : "post" , "contentType" : "application/x-www-form-urlencoded" , "payload" : { "token" : slack_OAuth_token , "email" : email } } ; const response = UrlFetchApp . fetch ( url , options ) ; let res = JSON . parse ( response ) ; let user_id = res . user . id ; // 取得結果をシートの C2 に書き込む sheet . getRange ( 2 , 3 ) . setValue ( user_id ) ; } 貼り付けたら、赤枠の「▷実行」ボタンを押下します。 スプシの構成通りなら、実行ログに「実行完了」と表示されます。 スプシを見てみましょう。SlackID欄にIDが書き込まれているはずです [ やったぜ このSlackIDって正しいの？？？ という事で、ぱぱっと確認してみます。 ①まず、生成されたC2セルのSlackIDをコピーします。 ②Slackアプリ上で、新規DMを作成します。 ③送信先入力欄に先ほどコピーしたSlackIDを張り付けます 直接メアドや登録名を記入せずとも、コピペだけで宛先欄にユーザーが表示されることが確認できます DMを送信してみる 上項でメアドからSlackIDを取得できる事は確認できました。次は、SlackBotを介してメッセージを送ってみましょう。 前項のSlackIDを取得するスクリプトに手を加え、以下のようなスクリプトを作成しました。やっている事は簡単で、 ①誤実行防止用のメッセージボックスを表示後に ②B列に入っているメアド取得 ③slack_message_textで送信したい文章を作ってから ④B列のメアドをGetSlackUserId()に渡して個々のSlackIDを取得 ⑤個々のSlackIDを元に、slack_App.postMessageでSlackID宛にDMを飛ばす ⑥行数分④～⑤を繰り返す 以上です function SlackBot () { //誤実行防止 let result = Browser . msgBox ( "Slackに通知文を送信します。よろしいですか？" , Browser . Buttons . OK_CANCEL ) ; if ( result == "cancel" ){ return; } const slack_OAuth_token = "xoxb-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ; const slack_App = SlackApp . create ( slack_OAuth_token ) ; let sheet = SpreadsheetApp . getActiveSpreadsheet () . getActiveSheet () ; // スプレッドシート最終行の行番号を取得 let lastRow = sheet . getLastRow () ; // B列の2行目から最終行までを指定 let emailRange = sheet . getRange ( 2 , 2 , lastRow - 1 , 1 ) ; // (開始行, 開始列, 行数, 列数) // 空白を除く let emails = emailRange . getValues () . filter ( row => row [ 0 ]) ; // 送信文 let slack_message_text = "test" for ( let email of emails ){ let user_id = GetSlackUserId ( email [ 0 ] , slack_OAuth_token ) let slack_message = "<@" + user_id + ">" + slack_message_text slack_App . postMessage ( user_id , slack_message ) ; } } function GetSlackUserId ( email , token ){ const url = "https://slack.com/api/users.lookupByEmail" const options = { "method" : "post" , "contentType" : "application/x-www-form-urlencoded" , "payload" : { "token" : token , "email" : email } } ; const response = UrlFetchApp . fetch ( url , options ) ; let res = JSON . parse ( response ) ; return res . user . id ; } 上記スクリプトでGASを実行すると、作成したSlackアプリからメッセージが届きます こんな感じ 直書きtokenをなんとかする 先ほど上の方でも触れましたが、token丸出しは余りにもセキュリティ意識や見栄えが悪すぎるため、この丸出し状態をなんとかします。 GASでは 「プロパティ」 として公開したくない情報を管理できる方法があります。 GASの画面左側にあるメニュー一覧から、赤枠の設定アイコン（歯車マーク）を押下して、プロジェクトの設定画面を開きます プロジェクトの設定画面最下段に、 スクリプト プロパティ項 があります。 【スクリプトプロパティを追加】 ボタンを押下します プロパティ欄に分かり易い名称を付け、値欄にtoken等を格納します。 入力後、【スクリプトプロパティを保存】を押下します。 プロパティを登録して満足してはいけません(1敗) GASスクリプト内の直書きtokenにプロパティを適応する作業を行います function SlackBot () { ： const slack_OAuth_token = "xoxb-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" ; //直書き状態から ↓↓↓↓↓↓↓↓↓ const slack_OAuth_token = PropertiesService . getScriptProperties () . getProperty ( "SlackOAuthToken" ) ; //プロパティサービスを適用 ： } プロパティサービスを使うためには、PropertiesServiceというクラスを使用します。getScriptPropertiesというメソッドを使用することで、スクリプトプロパティに登録済みのプロパティを取得することができます。 最後に、getPropaties()メソッドでプロパティ名を指定することによって、値を秘匿した状態で使用することが可能になります。 詳しくは コチラ をご参照ください developers.google.com 最終系は以下の通りです。 function SlackBot () { //誤実行防止 let result = Browser . msgBox ( "Slackに通知文を送信します。よろしいですか？" , Browser . Buttons . OK_CANCEL ) ; if ( result == "cancel" ){ return; } const slack_OAuth_token = PropertiesService . getScriptProperties () . getProperty ( "SlackOAuthToken" ) ; const slack_App = SlackApp . create ( slack_OAuth_token ) ; let sheet = SpreadsheetApp . getActiveSpreadsheet () . getActiveSheet () ; // スプレッドシート最終行の行番号を取得 let lastRow = sheet . getLastRow () ; // B列の2行目から最終行までを指定 let emailRange = sheet . getRange ( 2 , 2 , lastRow - 1 , 1 ) ; // (開始行, 開始列, 行数, 列数) // 空白を除く let emails = emailRange . getValues () . filter ( row => row [ 0 ]) ; // 送信文 let slack_message_text = "\n test" for ( let email of emails ){ let user_id = GetSlackUserId ( email [ 0 ] , slack_OAuth_token ) let slack_message = "<@" + user_id + ">" + slack_message_text slack_App . postMessage ( user_id , slack_message ) ; } } function GetSlackUserId ( email , token ){ const url = "https://slack.com/api/users.lookupByEmail" const options = { "method" : "post" , "contentType" : "application/x-www-form-urlencoded" , "payload" : { "token" : token , "email" : email } } ; const response = UrlFetchApp . fetch ( url , options ) ; let res = JSON . parse ( response ) ; return res . user . id ; } 仕上げ これで一通りの仕組みが出来上がりました。 ですが、現状わざわざGASを開いて都度「実行」を押しているので、ここをもっと簡単に実行できるようにします。 スプレッドシートの「挿入」から図形描画を選択し、任意の図形を作成します。 作成したら「保存して閉じる」を押下します。 以下のように、シート上に図形が作成されます。 　図形をクリックすると、右上にメニューアイコンが出てきます。アイコンを押下し、「スクリプトを割り当て」を押下します。 この図形をクリックしたときに実行したいスクリプトを入力する画面が表示されます。 　作成したスクリプトの「SlackBot」関数を指定します 「確定」を押下後、スプレッドシート画面が表示されます。 これで、図形を押下すればSlack通知を送れるようになりました。 　以下画像は、実際に図形をクリックした時の画面です。 終わりに 以上で、GoogleスプレッドシートからSlackAPIとSlackApp（Slackbot）を使ってSlackに通知を送る仕組みが出来上がりました！ とはいえ、上記スクリプトにはまだまだ手を加えるべきポイントがあります。 例えば・・・ メアドが存在しない場合の例外処理 その他エラーが発生した場合の例外処理 スクリプト実行時のタイムスタンプをセルに追加する 送信文がGAS内にべた書きになっている 等々 もし機会があれば、本記事を元にGoogleフォームのアンケート機能と組み合わせて、回答確認 & リマインドの発展系バージョンもご紹介できればと考えています。 本記事を参考に、日常業務の中で発生する連絡・リマインド作業がある方の助けになれば幸いです。 セーフィーではエンジニアを積極的に募集しています。どのような職種があるのか気になる方はこちらをご覧ください！ safie.co.jp カジュアル面談から受け付けておりますので、気軽に応募いただければと思います！ 皆様のご応募、心よりお待ちしております！ 最後までお読みいただき、ありがとうございました

はじめに こんにちは。セーフィー株式会社で内定者インターンをしている戌亥です。汎用的なコンポーネントの開発をしている中で起こったトグルボタンを実装バグの紹介とその原理、解決法についてご説明しますので、ぜひ参考にしてください。 はじめに 背景 ラベルボタン 起こったバグ 検証 バグが起こっていた原理 解決法 まとめ 最後に 背景 インターンのReactを用いた個人開発課題の中で汎用的なコンポーネントを先にある程度作ってしまおうと考えました。その際にラベルボタン方式でトグルボタンを実装しようとしたのですが、clickイベントが2度実行されてしまうバグが発生しました。React側の問題かと思って調べてみるとlabel要素自体の仕様が関わっていることがわかったので、色々検証を行いました。 ラベルボタン トグルボタンを実装する方法にはJavaScriptで実装する場合とHTML/CSSのみで実装する場合の2パターンがあります。 JavaScriptで実装する場合は、ボタンにする要素がクリックされたときに<要素>.classList.toggleなどでclassをつけたり外したりすることでONかOFFかの状態を保存できます。 HTML/CSSで実装する場合は、label要素を非表示化したcheckboxに紐づけることでONかOFFかの状態を保存できます。 本来label要素はforで指定したidを持つ要素と連動しますが、forで指定していない上にlabel要素の中にcheckboxなどの紐づけられる要素がある場合、それに紐づきます。このようにlabel要素で囲んで実装するボタンを個人的にラベルボタンと呼んでいます。ラベルボタンのメリットはforやidを指定しなくていいので、複製する際などにidをわざわざ振らなくてもいいところです。 < style > input [ type = "checkbox" ] { display : none ; } label > span { padding : 10px 20px ; margin : 5px ; background-color : #357c9c ; color : white ; border : 2px solid #ed7d31 ; cursor : pointer ; display : inline-block ; } label :has(: checked ) > span { background-color : #ed7d31 ; } </ style > < label > < input type = "checkbox" > < span > ラベルボタン </ span > </ label > ソースコード1：ラベルボタンの例 起こったバグ 実際のコードは割愛しますが、先ほどのサンプルコードのような要素をReactコンポーネントで作成し、安易にonClickにイベントを紐づけました。その結果、ボタンをクリックしたときに紐づけた関数が2回実行されるということが起きました。 まずReact環境に起因するのかどうかを判断するために、純粋なhtmlファイルをエクスプローラーで開いただけの環境にしました。そこでaddEventListenerを用いてclickイベントを紐づけたところ、同じ挙動が発生したため、Reactに起因することではないことがわかりました。 またラベルボタンではなくidでlabel要素を紐づけて行ったところ、1回のみの実行となったため、ラベルボタンの時のみに起こることがわかりました。 再現できるソースコード2ではボタンのlabel要素のclickイベントに「Hello, world.」とコンソール出力するだけの設定をしています。図1はラベルボタンをクリックしただけの状態ですが、2回出力されていることがわかります。対して図2はidに紐づける方法ですが、1回のみの出力となっていることがわかります。 <!DOCTYPE html> < html > < head > < meta charset = "utf-8" > < style > input , input [ type = "checkbox" ] { display : none ; } label > span { padding : 10px 20px ; margin : 5px ; background-color : #357c9c ; color : white ; border : 2px solid #ed7d31 ; cursor : pointer ; display : inline-block ; } label :has(: checked ) > span { background-color : #ed7d31 ; } input [ type = "checkbox" ] : checked + label > span { background-color : #ed7d31 ; } </ style > </ head > < body > < div id = "test1-1" > < label id = "test1-2" > < input type = "checkbox" id = "test1-3" > < span > ラベルボタン </ span > </ label > </ div > < div id = "test2-1" > < input type = "checkbox" id = "test2-2" > < label for = "test2-2" id = "test2-3" > < span > 紐づけボタン </ span > </ label > </ div > < script > function hw () { console . log ( 'Hello, world.' ) ; } window . addEventListener ( 'load' , function () { const labels = document . querySelectorAll ( 'label' ) ; [ ... labels ] . map (( label ) => { label . addEventListener ( 'click' , hw , false ) ; }) ; } , false ) ; </ script > </ body > </ html > ソースコード2：テスト環境 図1：ラベルボタンのクリック時の実行結果 図2：紐づけボタン（idとforで紐づけたトグルボタン）のクリック時の実行結果 label要素の挙動について正確な仕様を調べたところ、「label要素がクリックされたとき、その中に含まれるフォームコントロールに対してclickイベントを発火する」[1]ということがわかりました。このフォームコントロールとはlabelable elementと呼ばれるbutton，input，meter，textarea等といったlabel要素に紐づけられる要素のことです。 検証 次にソースコード3のhtmlファイルでイベントの流れを調べていきます。 <!DOCTYPE html> < html > < head > < meta charset = "utf-8" > < style > input , input [ type = "checkbox" ] { display : none ; } label > span { padding : 10px 20px ; margin : 5px ; background-color : #357c9c ; color : white ; border : 2px solid #ed7d31 ; cursor : pointer ; display : inline-block ; } label :has(: checked ) > span { background-color : #ed7d31 ; } input [ type = "checkbox" ] : checked + label > span { background-color : #ed7d31 ; } </ style > </ head > < body > < div id = "test1-1" > < label id = "test1-2" > < input type = "checkbox" id = "test1-3" > < span > ラベルボタン </ span > </ label > </ div > < div id = "test2-1" > < input type = "checkbox" id = "test2-2" > < label for = "test2-2" id = "test2-3" > < span > 紐づけボタン </ span > </ label > </ div > < script > function returnPhase ( phase ) { switch ( phase ) { case 1 : return 'Capturing' ; case 2 : return 'Target' ; case 3 : return 'Bubbling' ; } } function sample ( event ) { const ev = { type : event . type , evented : event . target , handled : event . currentTarget , phase : returnPhase ( event . eventPhase ) , } console . log ( ev ) ; } window . addEventListener ( 'load' , function (){ const targets = document . querySelectorAll ( 'body *' ) ; [ ... targets ] . map (( target ) => { target . addEventListener ( 'click' , { handleEvent : sample // イベントに紐づけさせる関数 } , false // captureフェーズで発火させる場合はtrue ) ; }) ; } , false ) ; </ script > </ body > </ html > ソースコード3：検証用環境 こちらが今回検証するラベルボタンの部分 < div id = "test1-1" > < label id = "test1-2" > < input type = "checkbox" id = "test1-3" > < span > ラベルボタン </ span > </ label > </ div > ソースコード4：ラベルボタンの部分 < div id = "test2-1" > < input type = "checkbox" id = "test2-2" > < label for = "test2-2" id = "test2-3" > < span > 紐づけボタン </ span > </ label > </ div > ソースコード5：比較用の紐づけボタンの部分 図3：ラベルボタンのDOＭ要素イメージ図 こちらは今回イベントに紐づけるためのサンプルとして作った関数（sample）です。 function sample ( event ) { const ev = { type : event . type , // イベントの種類 evented : event . target , // イベントの自体の発火元 handled : event . currentTarget , // 伝播された現在の発火元 phase : returnPhase ( event . eventPhase ) , // どこのフェーズで発火したか } console . log ( ev ) ; } ソースコード6：sample関数 図4：実装したレイアウト（まだクリックしていない状況） バグが起こっていた原理 イベントの処理の伝達にはCaptureフェーズ、Targetフェーズ、Bubblingフェーズが存在します。全体の流れとしてはラベルボタンをクリックするとまず、Captureフェーズ（赤矢印）でwindow→document→body→div→label→spanとターゲットまで伝達が上がってきます。次にTargetフェーズ（緑枠）でspanタグに到達します。その後、Bubblingフェーズ（青矢印）で伝達が下りていきます。 図5：CaptureフェーズからBubblingフェーズ デフォルトだとaddEventLisetnerの第三引数がfalseになっているのでBubblingフェーズでイベントが実行されます。そのため子要素から親要素へと処理が行われていくようになります。 図6：CaptureフェーズからBubblingフェーズの詳細 sample関数を紐づけているdiv要素以下に注目すると、span要素がクリックされ、Captureフェーズでspan要素まで到達します。①Targetフェーズでspan要素がイベント発火します。②Bubblingフェーズでlabel要素がイベント発火します。③Bubblingフェーズでdiv要素がイベント発火します。 図7：label要素によるcheckboxのクリック後の流れ label要素でclickイベントが発火したため、子要素で一番最初に見つかるlabelable elementのcheckbox要素がクリックされます。このクリックにおいても①Targetフェーズでcheckbox要素がイベント発火します。②Bubblingフェーズでlabel要素がイベント発火します。③Bubblingフェーズでdiv要素がイベント発火します。これによってlabel要素と、それより親の要素は2回イベント発火することになります。 図8：ラベルボタンをクリックした図 図9：紐づけボタンをクリックした図 図8のコンソール画面を見ると、説明の通りまずspan要素のバブリングが行われています。その後checkboxがクリックされ、checkboxからバブリングが起きていることがわかります。 図9のコンソール画面を見るとspan要素がクリックされた後、先ほどと同じようにTargetフェーズでspan要素がイベント発火し、Bubblingフェーズでlabel要素、div要素とイベント発火しています。こちらはforで指定したcheckboxがクリックされ、Targetフェーズでcheckbox要素が、Bubblingフェーズで親要素であるdiv要素がイベント発火しています。 label要素はクリックされたときに、子要素またはforで指定したcheckbox等をクリックする仕様がありました。つまりcheckboxのバブリング上にlabel要素があるときは、label要素のクリックとcheckboxのクリックの2回イベント発火します。ラベルボタンはcheckboxのバブリング上にあるから2回発火し、紐づけボタンはcheckboxの兄弟要素であってバブリング上にはないために1回のみの発火になっていました。 解決法 clickイベントが2回発火する原因はバブリング上にlabel要素自身があったためなので、主に取れる手法は ①label要素をバブリング上から外す ②バブリングが伝わらないようにする ③clickイベントではなくchangeイベントを使う の3つのうちのどれかで解決できます。 ①バブリング上から外す場合、紐づけボタンのようにlabel要素の親子関係に対象のlabelable elementを置かずにidとforで紐づけます。 ②バブリングが伝わらないようにする場合、これはいくつか方法があります。 （1）stopPropagationを使う （2）preventDefaultを使う （3）targetを参照する ②（1）ソースコード7のようにsample関数を書き変えてevent.stopPropagation()を実行することで、イベントの伝播をそこで止めることができます。これは他の紐づけ関数に対しても伝播を止めてしまうことになるため、あまり推奨されていません。図10はstopPropagationを実装した後のラベルボタンをクリックしたときの図です。図6の①と図7の①だけ実行されていることがわかります。伝播は中断してもlabel要素の挙動によるcheckboxのクリックは中断されないようです。またこの場合はcheckboxにclickイベントを設定する必要があります。 function sample ( event ) { event . stopPropagation () ; const ev = { type : event . type , // イベントの種類 evented : event . target , // イベントの自体の発火元 handled : event . currentTarget , // 伝播された現在の発火元 phase : returnPhase ( event . eventPhase ) , // どこのフェーズで発火したか } console . log ( ev ) ; } ソースコード7：event.stopPrpagationの実装例 図10：②(1)実装後のラベルボタンをクリックした図 ②（2）ソースコード8のようにsample関数を書き換えてevent.preventDefault()を実行することで、label要素のクリックされたら紐づいたlabelable elementをクリックするという本来の挙動を止めることができます。それによってlabelボタンのclickイベントは発火しますが、checkboxはクリックされないため新たにclickイベントが発生しなくなり、2重発火を防ぐことができます。しかしトグルボタンとして利用する場合は、label要素がcheckboxがクリックしないため切り替えることができなくなります。 function sample ( event ) { event . preventDefault () ; const ev = { type : event . type , // イベントの種類 evented : event . target , // イベントの自体の発火元 handled : event . currentTarget , // 伝播された現在の発火元 phase : returnPhase ( event . eventPhase ) , // どこのフェーズで発火したか } console . log ( ev ) ; } ソースコード8：event.preventDefaultの実装例 図11：②(2)実装後のラベルボタンをクリックした図 ②（3）event.targetはバブリングの位置に関わらず、イベントのトリガーとなった要素を参照します。checkboxがクリックされた場合はevent.targetにcheckboxが格納されているため、checkboxのクリックによるバブリング中か、ラベルボタンのクリックによるバブリング中かが判別できます。どちらかのときだけ実行するとしておくことで2重実行を防ぐことができます。またこの場合はlabel要素ではなく、checkboxにclickイベントを設定する方がどの場合でも使えるのでお勧めです。 function sample ( event ) { if ( event . target ! == event . currentTarget ) return; const ev = { type : event . type , // イベントの種類 evented : event . target , // イベントの自体の発火元 handled : event . currentTarget , // 伝播された現在の発火元 phase : returnPhase ( event . eventPhase ) , // どこのフェーズで発火したか } console . log ( ev ) ; } ソースコード8：event.preventDefaultの実装例 図12：②(3)実装後のラベルボタンをクリックした図 ③changeイベントを使う場合、label要素自身のchangeイベントは存在しないので、必ずcheckbox等のchangeイベントがバブリングした場合のみイベントが発火します。checkboxはクリックされると状態がON・OFF切り替わるので、changeイベントにすることで同一イベントの2重発火を避けることができます。 まとめ label要素でforを指定せず、checkbox等を囲ってボタンを作るとclickイベントが2重発火します。 2重発火する原因はcheckbox等がlabel要素の親子要素にあり、ボタンのクリック時のバブリングで1回、label要素の仕様によるcheckboxのクリック時のバブリングで1回の計2回label要素でclickイベントが発火するためでした。 対策としてはイベントのトリガーになった要素を参照したり、clickイベントからchangeイベントに変えたりするとボタンに紐づいた処理の2重実行を避けることができます。 トグルボタンの実装からJavaScriptのイベントに関して掘り下げた記事でした。ぜひ参考にしてください。 最後に セーフィーではエンジニアを積極的に募集しています。どのような職種があるのか気になる方はこちらをご覧ください！ safie.co.jp 皆様のご応募、心よりお待ちしております！ 最後までお読みいただき、ありがとうございました。

はじめに セーフィー株式会社 で画像認識AIの開発をしているおにきです。 画像認識AIシステムを構築する際AIのコンピューティング処理を「どこで」「いつ」「どのようなデータに対して」行うか、すなわちサービングパターンを選択することは、システムの性能、コスト、拡張性に大きな影響を与えます。本記事では弊社のクラウド録画サービスを例に、画像認識AIのサービングパターンについて詳しく解説します。適切なサービングパターンを選択することで、より効率的で高性能なシステムを構築できるようになります はじめに 画像認識システムのサービングパターンのための要素 コンピューティング タイミング トリガー 入力データ形式 組み合わせのパターン 1.エッジ（カメラ内）動画認識 2.エッジ（AI Box）動画認識 3.エッジ（カメラ内）静止画認識 4.エッジ（AI Box）静止画認識 5.クラウドストリーミング動画認識 6.クラウドストリーミング静止画認識 7.クラウドストリーミング外部トリガー認識 8.クラウドバッチ外部トリガー動画認識 9.エッジ（カメラ内）・クラウドハイブリッド認識 まとめ 最後に 画像認識システムのサービングパターンのための要素 弊社のクラウド録画プラットフォームSafieでは、ネットワークに接続されたカメラが常時映像をクラウドにアップロードし、それを保存する仕組みとなっております。 コンピューティング コンピューティングとは画像認識の主たる処理で画像を入力して認識結果のメタ情報（物体位置など）を出力する処理であり、それをどこで行うかで場合分けを行いました。 エッジ（カメラ内） カメラ（イメージセンサー）と同じハードウェア内にあるCPUもしくはNPU（Neural Processing Unit）で画像認識処理を行います。スマホは防犯カメラの内部で画像認識を行うパターンです。多くの場合、カメラの電力面・コスト面の制約により計算性能が限られます。 エッジ（AI Box） カメラとネットワーク上で近い箇所に別途ハードウェア（AI Box）を設置して画像認識を行う場合です。防犯カメラと同じネットワーク内にJetsonやオンプレGPU PCなどをおいて画像認識処理を行うパターンです。通常カメラ内でのエッジ処理に比べると大きな計算性能を持っています。複数台のカメラに対して1つのAI Boxで認識を行うこともできます。 クラウド カメラから送られてきた画像をクラウド上のコンピューティング環境で画像認識処理を行うパターンです。CPU・GPUなど様々な計算性能を持つインスタンスを選択できますが、エッジ（カメラ内）、エッジ（AI Box）と異なり大きなランニングコストがかかります。 タイミング 画像認識処理を行うタイミングによって以下の3つのパターンに分類することができます ストリーミング 画像データがコンピューティングモジュールに送られたタイミングで処理するパターンです。 バッチ 画像データをストレージに保存しておいて、あるタイミングでまとめて処理を行うパターンです。本稿では触れませんが、バッチ処理は細かく分けると非同期と同期の2種類にさらに分けることができます。 トリガー 処理を行うタイミングは以下の2パターンに分類できます。 一定周期 あらかじめ定められた周期で処理を行います。 外部・UI 外部のセンサーによるイベントやUIからのリクエストをトリガーとして処理を行います。 入力データ形式 静止画 静止画を入力データとして認識処理をします 動画 動画を入力データとして認識処理をします。 ※動画は複数枚の静止画として考えることができますが、動画を入力データとして用いる場合はトラッキングなどフレーム間をまたがった処理を行います。 組み合わせのパターン 前述の要素の組み合わせからパターンを検討します。組み合わせによっては、実現性がないものもあります。以下に弊社で利用および利用を計画している代表的なパターンを記載します。 コンピューティング タイミング トリガー 形式 # パターン名 エッジ（カメラ内） エッジ（AI Box） クラウド ストリー ミング バッチ 一定 周期 外部・UI 画像 動画 1 エッジ（カメラ内）動画認識 ○ ○ ○ ○ 2 エッジ（AI Box）動画認識 ○ ○ ○ ○ 3 エッジ（カメラ内）静止画認識 ○ ○ ○ ○ 4 エッジ（AI Box）静止画認識 ○ ○ ○ ○ 5 クラウドストリーミング動画認識 ○ ○ ○ ○ 6 クラウドストリーミング静止画認識 ○ ○ ○ ○ 7 クラウドストリーミング外部トリガー認識 ○ ○ ○ * * 8 クラウドバッチ外部トリガー動画認識 ○ ○ ○ ○ 9 エッジ（カメラ内）・クラウドハイブリッド認識 ● ● ○ ○ ○ ○：利用 ●：両方同時に利用 *:どれかを利用 1.エッジ（カメラ内）動画認識 カメラ内で動画の認識を行います。カメラ内のAI処理は計算性能が小さいため、比較的小さいモデルを利用して動画認識を行います。 ・動きを伴う分析（人・車両・ベルトコンベア上のモノ） ・姿勢・アクション検出 ・属性（人・車種） ・認証（顔・ナンバープレート） 2.エッジ（AI Box）動画認識 AI Boxで動画の認識を行います。認識できるタスクとしては先述のエッジ（カメラ内）動画認識と同じになりますが、より大きいモデルを利用して精度を向上させることができます。 ・動きを伴う分析（人・車両・ベルコンベア上のモノ） ・姿勢・アクション検出ト ・属性（人・車種） ・認証（顔・ナンバープレート） 3.エッジ（カメラ内）静止画認識 認識間隔が数分など比較的長い認識のパターンです。エッジ（カメラ内）動画認識に比べて計算時間に余裕があるため、1フレームあたりの計算量がある程度大きくても実行可能です。またメーター読み取りなどカメラごとに違うカスタマイズしたモデルも実行可能です。 ・メーター読み取り 4.エッジ（AI Box）静止画認識 認識間隔が数分など比較的長い認識のパターンです。エッジ（カメラ内）静止画認識に比べてより大きなカスタマイズモデルを利用することもできます。 ・メーター読み取り 5.クラウドストリーミング動画認識 クラウドでストリーミングで動画を認識するパターンです。サーバーのインスタンスにつねに大きな負荷を掛けるため大きなランニングコストになります。ランニングコストが問題にならない高付加価値な認識機能やPoCなどでは利用できるパターンです。 ・動きを伴う分析（人・車両・ベルトコンベア上のモノ） ・姿勢・アクション検出 ・属性（車種） はできる 以下は映像の解像度が低いため精度で不利 ・属性（人） ・認証（顔・ナンバープレート） 6.クラウドストリーミング静止画認識 クラウドでストリーミングで静止画を認識するパターンです。複数のデバイスを一つのインスタンスで認識する場合にはカメラごとに認識タイミングをずらすなどの工夫は必要ですが、動画に比べると負荷が低くランニングコストはかなり低くなります。クラウドで処理する場合1つのインスタンスで多数のカメラの静止画を分析するため、カメラごとにカスタムモデルを利用する場合には認識ごとにモデルの切り替えコストが大きくなることに注意が必要です。 ・人検出 ・河川氾濫判定 ・マルチモーダルLLMによる認識 7.クラウドストリーミング外部トリガー認識 外部のセンサーなどをトリガーとして、動画もしくは静止画の認識を行うパターンです。例えば、車両を検出するセンサーが反応した際に、クラウド側で車両のナンバープレートを認識するなどのパターンがあります。 ・ナンバープレート認識（外部センサーとの組み合わせ） 8.クラウドバッチ外部トリガー動画認識 クラウド上に撮りためた動画データをUI上で認識期間を指定して認識するパターンです。ある期間における人の動きや交通量を改正したい場合に利用するパターンです。クラウドストリーミング動画認識と比べるとある一定の期間の動画データに対してのみクラウドで認識を行うので比較的コストを低く抑えることができます。 ・期間を限った人の流れ認識 ・期間を限った交通量分析 9.エッジ（カメラ内）・クラウドハイブリッド認識 カメラ内でリアルタイム性が必要な画像認識を行い、更に詳細な認識をクラウド側で行うパターンです。リアルタイム処理はカメラ内で行い、クラウドでの詳細認識は低頻度であるためランニングコストを抑えることができます。一方で、システムが複雑なため開発難易度が上がるというデメリットもあります。 ・顔認証 エッジ（カメラ内）：人検出、顔切り出し クラウド：顔特徴量マッチング ・車番認識 エッジ（カメラ内）：車両検出、ナンバープレート切り出し クラウド：ナンバープレート認識 まとめ 本記事では画像認識システムのサービングパターンにおける要素を示し、その組み合わせから実際に利用できる主なサービングパターンを挙げました。本記事で扱った要素の組み合わせは、主にSafieのシステムを想定しています。みなさんが扱うシステムによって事情は異なってくるとは思いますが、要素に分けて組み合わせで考えることで比較検討を行い適切なシステムを選択することができると思われます。 最後に セーフィーではエンジニアを積極的に募集しています。どのような職種があるのか気になる方はこちらをご覧ください！ safie.co.jp カジュアル面談から受け付けておりますので、気軽に応募いただければと思います！ 皆様のご応募、心よりお待ちしております！ 最後までお読みいただき、ありがとうございました。

はじめに こんにちは。 セーフィー株式会社 先行開発Gの井上です。 今回は、タイトルの通り llama.cpp を使用して MiniCPM-o-2_6 をローカル環境で動作させる方法 について解説します。ローカルでの動作環境を簡単に構築できる手順を紹介しますので、ぜひ参考にしてください。 はじめに 用語解説 llama.cppとは？ MiniCPM-o-2_6とは？ CMakeとは？ CMakeを使用する利点 PCスペック・環境 実装の前準備 CMakeの導入方法（Windows 11基準） MiniCPM-o-2_6の用意 llama.cppの導入方法 Windows 11環境での導入手順 実行してみる 実行結果 ①　Developers Summit 2024 Summerでの集合写真 所要時間 質問文 回答 ②　セーフィーが掲げる映像プラットフォームの概念図 所要時間 質問文 回答 最後に 最近のマルチモーダルAIの発展に伴い、ローカル環境でも手軽に動作させたいというニーズが増えています。MiniCPM-o-2_6 はオープンソースのマルチモーダルAIであり、ローカルでの実行も可能です。本記事では llama.cpp を使用し、Windows 11 環境で MiniCPM-o-2_6 を動かす手順をまとめました。 また、環境構築に CMake を利用することで、ビルドや依存関係の管理が簡単になり、手軽にセットアップできる点も魅力です。CMake を活用することで、複雑な設定をすることなくスムーズに環境を構築できるため、本記事の方法を採用しました。 用語解説 llama.cppとは？ llama.cpp は、オープンソースの軽量な LLM（大規模言語モデル）推論フレームワークであり、Meta社が公開した LLaMA（Large Language Model Meta AI）シリーズのモデルをローカル環境で実行するために開発されました。このフレームワークは、特に低リソース環境向けに最適化されており、GPU を使用しなくても CPU 上で高いパフォーマンスを発揮できるのが特徴です。llama.cpp は C++ で実装されており、Windows、Linux、macOS などの主要なプラットフォームで利用可能です。 MiniCPM-o-2_6とは？ MiniCPM-o-2_6 は、オープンソースのマルチモーダル大規模言語モデル（MLLM）であり、テキスト、画像、音声などの複数のモダリティを処理することが可能です。このモデルは、エッジデバイスでの運用にも適した軽量な設計がされており、比較的低スペックなマシンでも動作できるのが特徴です。また、OCR（光学文字認識）機能が強化されており、最大1344×1344ピクセルの画像を処理可能なため、画像解析や視覚情報の理解にも活用できます。 llama.cpp はローカルで LLM を実行する際に非常に有効なツールであり、特に 軽量・シンプルな導入が可能 な点が優れています。そのため、本記事では llama.cpp を使用して MiniCPM-o-2_6 を動作させる方法を選択しました。 CMakeとは？ CMake は、プログラムのビルドを管理するためのクロスプラットフォームツールです。C++ などのプロジェクトでコンパイル・ビルドを簡単に行うために使用されます。 CMakeを使用する利点 CMake を使用する最大の利点は、クロスプラットフォーム対応であり、Windows、Linux、macOS など異なる OS でも統一的なビルド環境を提供できる点です。また、柔軟なビルド設定が可能で、CMakeLists.txt を記述することで、複雑なプロジェクトの管理が容易になります。 さらに、CMake は依存関係の管理にも優れており、外部ライブラリを簡単に導入し、統一されたビルド環境を構築することができます。これにより、異なる開発者や異なる環境でのビルドの再現性が向上し、開発の効率化が期待できます。 また、CMake を使用することで、ビルドの自動化や再利用性が高まり、同じ設定を異なる環境でも適用できるため、複数のプロジェクトや開発チーム間での統一した開発環境を維持しやすくなります。加えて、CMake は Visual Studio、Makefile、Ninja など、多くのビルドシステムとの互換性があり、環境に応じたビルドが容易に行える点も大きな利点です。 PCスペック・環境 CPU: Intel(R) Core(TM) i7-1355U 1.70 GHz メモリ: 32.0 GB OS: Windows 11 64bit エディタ：VisualStudioCode 実装の前準備 CMakeの導入方法（Windows 11基準） CMake公式サイト から最新のバージョンをダウンロード インストーラーを実行し、システム環境変数にパスを追加 ここで自分は「Add CMake to the system PATH for the All user」を選択しました。 保存先を聞かれるので、任意の好きな場所を選択 インストール完了後、ターミナルで cmake --version を実行し、正常にインストールされたことを確認 cmake version 3.31.4(筆者の環境）と出ました！ これでCmakeの準備は完了です！ MiniCPM-o-2_6の用意 今回必要なモデル Model-7.6B-Q4_K_M.gguf mmproj-model-f16.gguf モデルの導入手順 HuggingFace に上記MiniCPM-o-2_6モデルのggufファイルが公開されているのでダウンロードします huggingface.co 上記サイトへアクセスします 赤枠で囲ってあるFiles and versionを押下します モデル一覧が表示されます。 ここで、 今回必要なモデル 項に記載している2つのモデルをダウンロードします。 ダウンロード後、どこか分かり易い場所へ一時保管しておきます llama.cppの導入方法 下準備が全て完了したので、ここからはいよいよllama.cppの導入方法について解説していきます！ github.com といっても、llama.cppのgithubからクローンしてCmakeを実行するだけで構築できちゃいますので、作業自体は下準備項よりも早く終わります Windows 11環境での導入手順 ローカルに作業用ディレクトリを作成します。 mkdir llama_test cd llama_test 作成したllama_testディレクトリ上で llama.cpp のリポジトリをクローン。 完了後、llama.cppディレクトリへ移動します。 git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp llama.cppディレクトリ上で以下コマンドを入力し、CMakeを使用してビルドを行います cmake -B build cd build cmake --build . --config Release ※cmake --build . --config Release　はかなり時間がかかります 上記コマンドを上から順に実行すると、llama.cppに「build」フォルダが作成されます。 モデルの準備項で用意しておいた2つのモデルをbuildフォルダに格納します。 格納場所はどこでもOKです。自分は以下の場所にモデル格納用のディレクトリを作成し、格納しました。 llama.cpp/build/bin/ models/MiniCPM-o-2_6/ 画像保管場所を用意します。 次項にも記載していますが、画像を解析させるために画像のパスを教えてあげる必要があります。任意の場所に画像用フォルダを作成し、指定できるようにしておきましょう。 筆者は以下のように画像保管フォルダを作成しました。 llama.cpp/build/bin/ images/ これで実行準備が全て完了しました！次項から早速触ってみましょう！ 実行してみる 実際にモデルを動作させるために、以下のコマンドを実行します。 ※筆者はbuildディレクトリ上で実行しているので、以下のパス構成になっています。逐次書き換えてください ./bin/Release/llama-minicpmv-cli -m **./bin/models/MiniCPM-o-2_6/Model-7.6B-Q4_K_M.gguf** --mmproj **./bin/models/MiniCPM-o-2_6/mmproj-model-f16.gguf** -c 8192 --temp 0.7 --top-p 0.8 --top-k 100 --repeat-penalty 1.05 --image **./bin/images/001.png** -p "how many people are in the image" --n_predict 8192 今回解析してもらう画像は次の2つです 実行結果 ①　Developers Summit 2024 Summerでの集合写真 2024年にブース出展したDevelopers Summit 2024 Summerでの集合写真です！ この時のブース出展では、 Safie One や Safie GO 360 、 Safie Pocket2 Plus をブースに展示していました。 展示したプロダクトについても是非ご確認ください！ safie.jp safie.jp safie.jp 所要時間 1分以内(50秒程) 質問文 how many people are in the image 回答 There are four people in the image. They appear to be standing behind a booth, possibly promoting or demonstrating something related to 'safie'. Each person is holding up pamphlets with Japanese text and pictures of owls on them. The setting includes posters and banners about 'safie' technology, suggesting it might be an event or exhibition where they are showcasing their product or service. The individuals seem engaged in presenting information about the company's offerings, as evidenced by the materials they're holding and the visual aids set up around them. There is also a table with more pamphlets available for visitors to take. The overall atmosphere indicates a professional presentation aimed at informing attendees about 'safie' technology or services. In summary: Four people are visible in the image. They appear to be part of a promotional event for their company, possibly called 'safie'. Their actions suggest they're explaining features related to owls and video management. 画像には4人が写っています。彼らはブースの後ろに立って、おそらく「safie」に関連した何かを宣伝またはデモンストレーションしているようです。それぞれが日本語の文字とフクロウの絵が描かれたパンフレットを掲げている。この設定には「セーフィー」テクノロジーに関するポスターやバナーが含まれており、自社の製品やサービスを紹介するイベントや展示会である可能性があることを示唆しています。 彼らが手にしている資料や周囲に設置された視覚補助具からわかるように、各個人は同社の製品に関する情報の提示に熱心に取り組んでいるように見えます。訪問者が手に取れるパンフレットが置かれたテーブルもあります。全体的な雰囲気は、参加者に「安全」テクノロジーやサービスについて知らせることを目的とした専門的なプレゼンテーションを示しています。 要約すれば： 画像には 4 人が表示されます。 彼らはおそらく「safie」と呼ばれる、自社のプロモーションイベントの一部であるようです。 彼らの行動は、フクロウとビデオ管理に関連する機能を説明していることを示唆しています。 ②　セーフィーが掲げる映像プラットフォームの概念図 セーフィーの事業紹介にも掲載していますので、興味があれば以下サイトも確認してみてください safie.co.jp 所要時間 2分程 質問文 describe the image 回答 The image is a detailed infographic in Japanese, featuring various applications of video data. The central element is the logo and name "safie," which appears to be a platform for integrating diverse analysis applications related to video data. Surrounding this central theme are several circular images with corresponding text labels that illustrate different use cases: Restaurants : There's an image showing tables in a dining area, possibly indicating how video data can help monitor customer behavior or optimize operations. Hospitals : An image of hospital beds suggests the application could involve patient monitoring and facility management within medical settings. Street View / Tourism Locations : This includes images that might represent tourist spots or public spaces where surveillance or crowd analysis is beneficial. Additionally, there are other applications mentioned: Business Facilities Crime Prevention Construction Sites Flood Monitoring The infographic also mentions practical uses like sending out educational videos and calculating parking fees based on footage. Each application area has a visual representation to help understand its context better within the overall platform's capabilities. Overall, it appears that "safie" is designed as an integrated solution for various industries looking to utilize video data efficiently across multiple sectors such as hospitality, healthcare, security, education, and more. 画像は、映像データのさまざまなアプリケーションを紹介する、日本語の詳細なインフォグラフィックです。中心となるのは「safie」というロゴと名前で、映像データに関連する多様な解析アプリケーションを統合するプラットフォームと思われる。 この中心テーマの周囲には、さまざまな使用例を示す対応するテキスト ラベルが付いたいくつかの円形の画像があります。 レストラン : ダイニング エリアのテーブルを示す画像があり、映像データが顧客の行動の監視や業務の最適化にどのように役立つかを示している可能性があります。 病院 : 病院のベッドの画像は、このアプリケーションに医療現場での患者の監視と施設管理が含まれる可能性があることを示唆しています。 ストリートビュー / 観光地 : これには、監視や群衆分析が有益な観光地や公共スペースを表す可能性のある画像が含まれます。 さらに、他のアプリケーションについても言及されています。 商業施設 防犯 建設現場 洪水監視 インフォグラフィックでは、教育映像の送信や映像に基づいた駐車料金の計算などの実用的な用途についても言及しています。各アプリケーション領域には視覚的な表現があり、プラットフォーム全体の機能内でそのコンテキストをよりよく理解できるようになります。 全体として、「safie」は、ホスピタリティ、ヘルスケア、セキュリティ、教育などの複数の分野にわたって映像データを効率的に活用したいと考えているさまざまな業界向けの統合ソリューションとして設計されているようです。 最後に 本記事では、ローカル環境で llama.cpp を使用して MiniCPM-o-2_6 を動作させる方法 について解説しました。 ローカルで LLM を実行する方法を探している方にとって、有益な情報になれば幸いです。 セーフィーではエンジニアを積極的に募集しています。どのような職種があるのか気になる方はこちらをご覧ください！ safie.co.jp カジュアル面談から受け付けておりますので、気軽に応募いただければと思います！ 皆様のご応募、心よりお待ちしております！ 最後までお読みいただき、ありがとうございました

はじめに セーフィー株式会社AIソリューションプラットフォーム推進室の植松です。 2024年12月に実施した セーフィーアドベントカレンダー でCTO 森本からご紹介がありましたとおり、AIソリューションプラットフォームが 経産省プロジェクト（IR資料） として採択されたことをきっかけに、このプラットフォーム化に会社としてさらに注力して取り組むことになりました。 engineers.safie.link その注力施策の一つとして、今年の1月から新たに部署を作りプロジェクトを進めていますので、今一度全体像と、事業ロードマップ、経産省プロジェクトにおける実証実験の取り組み状況、認知施策についてお話しできればと思います。 はじめに AIソリューションプラットフォーム全体像 事業ロードマップ 経産省プロジェクトにおける実証実験について テーマ1. 鹿島建設様 テーマ2. 清水建設様 テーマ3. 慶睦会様 認知施策 生成AIの取り組みについて 最後に AIソリューションプラットフォーム全体像 こちらは 2024年12月期第3四半期決算資料 でも展開させていただきましたが、データ利用を簡単に、AI生成・再学習を簡単に、ビジネスを簡単に〜AIビジネスを量産できる仕組みを我々のプラットフォームとして提供し、データホルダーとAI開発者の連携を実現するような場の構築、提供を行うことを想定しています。 事業ロードマップ まずは国内、映像データの活用はファーストステップですが、それに留まらず海外展開や、映像に音声・センサデータなどのデータを組み合わせたマルチモーダル対応を進めていく予定です。 事業化に関するもう少し深掘りした話については、 IR noteの方でも記事にしております ので、ご興味ある方はそちらもご覧いただければと思います。 note.com 経産省プロジェクトにおける実証実験について AIソリューションプラットフォームの開発と合わせ、３つの実証実験を行うことでプラットフォームの確からしさを立証していこうと考えています。 残念ながらプロジェクト途中のため写真が公開できないのですが、どのテーマも現場の課題をデータ活用によりなんとか解決したい、という各社の熱い思いを持って取り組んでいます。 テーマ1. 鹿島建設様 クレーン作業において、荷物を持ち上げる時（玉掛け作業）の不安全行動を防ぐため、3.3.3運動（玉掛けして3秒確認、玉掛け者は3m以上離れる、荷の安定確認を30cm以内にする）ということを基本としているのですが、その状態が守られているかを検知したい、という事象に取り組もうとしています。 また、安全な状態を保つこと（囲いがあるか、開口部が開きっぱなしになっていないこと、立ち入り禁止箇所がきちんと守られていること、など）に対しても現在どの事象に対して取り組むか？を整理しています。 テーマ2. 清水建設様 トンネル工事において、コンクリートを運んでくる生コン車や、トンネルの一部を構成するセグメントと呼ばれるものを載せた車などが、いつ入ってくるか？がわからず、待機状態が長いのでそれをもっと効率化するため検知したい、という事象に取り組もうとしています。 テーマ3. 慶睦会様 介護施設で転倒してしまった場合に介助しにいく必要がありますが、特に夜間は待機しているスタッフも少なく、何度も見回りにいく負荷も高いため、転倒時に通知がくるような仕組みを作ってスタッフさんの負荷を減らしたい、という事象に取り組もうとしています。 いずれのテーマも、実際に実証実験現場に伺うことで、取り組もうとしている課題以上に様々にAIを量産できたらやれそうなことが沢山出てきます。やむなく今回はテーマを絞っていますが、プラットフォーム化でさらに課題解決に繋げられそうだと感じています。 認知施策 プラットフォームをシステムとして作ると同時に、それをプラットフォームとして使ってくださるデータホルダー（お客様）、AI開発者を集める施策が必要となってきます。 昨年から弊社主催のカンファレンス、通称レゾサミ（ レポートはこちら ）を行っています。 note.com 今までは主にデータホルダーであるお客様向けでしたが、今年はAIソリューションプラットフォームという軸で上記の実証実験や、AI開発者様と実施している取り組みを紹介していく登壇やデモブースを設け、さらにAI開発者の方も興味を持っていただけ楽しめるようなイベントを設計していく予定です。 また、セーフィーでは様々な業界向け展示会に出展しており、直近ですと リテールテックJAPAN にこの取り組みを展示する予定です。 messe.nikkei.co.jp それらに加え、AIの展示会への登壇や技術系の認知施策にも取り組んでいきたいと思います。セーフィーにはショールームもあるので、そこにもこのプラットフォームの内容がお目見えする予定ですので、興味のある方は是非会社の方にもお越しいただければと思います。 本Tech Blogでも今後定期的にプロジェクトのアップデートや実際の仕組み、開発状況などをお伝えしていきます。 生成AIの取り組みについて 経産省プロジェクトとしては、AIモデルを簡単に作れる、いわゆるMLOpsと呼ばれる仕組みを中心に取り組んでいるのですが、同時に生成AIを活用した仕組みに関しても合わせてプラットフォームとして提供できないか、ということを並行して検討しています。 まずはデモとしてお客様の反応を確認しつつ、ビジネスとしてうまく軌道に載せられるような探索を繰り返していきたい、と考えています。 最後に セーフィーが様々な大企業の方々にご支援いただいてここまで大きく成長できたように、今度はこのAIソリューションプラットフォームを使ってスタートアップの方の支援ができるような形を目指しています。 AIソリューションプラットフォームを構築し、またプラットフォームを使って様々なプロダクト・サービスを提供するには、AIだけでなくその他領域のエンジニアやプロダクトマネージャーも合わせて必要です。 サーバ・フロントエンドエンジニアはもちろん、映像データを取得するために欠かせないカメラやその周辺デバイスを担当するIoTエンジニア、ユーザ動向の調査に欠かせないデータ分析エンジニア、様々なオペレーションを支える業務システムエンジニア、品質を上流からもささえるクオリティマネジメント担当、各領域のプロダクトマネージャーなど、様々なポジションで採用をかけています。 この記事を読んで興味を持っていただいた方、カジュアルに話してみたい、等で結構ですので、 是非こちらの採用サイトから コンタクトいただけると幸いです！ safie.co.jp

はじめに セーフィーの髙木( @hitsan8 )です。 セーフィーは2025年2月13、14日に行われたDevelopers Summit 2025（以下デブサミ）にブーススポンサーとして参加しました。 デブサミとは2003年から開催されているITエンジニアのための祭典です。今年のテーマは「 ひろがるエンジニアリング 」です。 event.shoeisha.jp 多くの方にセーフィーを知ってもらうために2023年から参加し続けて今年で3回目になりました。 この記事はデブサミのブーススポンサー参加レポートになります。 はじめに ブースのデザイン アニマルマスクのデモ 展示パネル さいごに ブースのデザイン 2024年にロゴをリニューアルしたのでブースで使用する備品、ノベルティを一新しました。 去年までは白をベースにしたデザインでしたが、今年はコーポレートカラーであるセーフィーブルーを基調としたデザインに仕上げています。 例えばバナースタンドはこのようなデザインになっています。 実際のブースに並べてみるとこんな感じになります。 全体の色味をそろえたので統一感がでたのではないでしょうか。 実際にお客さんに説明している様子はこんな感じでした。 ブースではアニマルマスクのデモとパネルの展示をしました。 こちらもそれぞれ紹介していきます。 アニマルマスクのデモ プライバシーマスクという機能があり、これは個人の特定を防ぐために映像の一部を隠す機能です。 通常は映像を隠すためにモザイク処理することが多いですが、今回は検出した人の上に動物のイラストを被せてアニマルマスクとして展示しています。 会場では三脚を使って俯瞰で撮影するようにしました。 この画角がセキュリティカメラっぽいですね。 実際にアニマルマスクを動かすとこんな感じです。 自分の顔が動物になっているのでお客さんの目を引くことができました。 こちらはお客さんや他のブースの方々から面白い、かわいいというお声をいただきました。さらに、内部のアルゴリズムやセキュリティについて興味を持たれた方も多かったです。 展示パネル 今回はアニマルマスクのパネルと技術スタックのパネルを展示しました。 どちらもコーポレートカラーを基調としたデザインにしています。 このパネルは動物たちの質問にセーフィーくんが回答してくれるという内容になってます。 楽しそうな雰囲気が伝わってきますね。 技術スタックのパネルはエンジニアの方々に好評でした。 「セーフィーではこれを使ってるけどうちの会社ではこれを使ってる」みたいな会話が生まれていました。 さいごに 2日間のブース出展を無事に終えることができました。実際にプロダクトを見てもらい、その場でフィードバックをもらえたので非常によい体験でした。 スタッフの感想としては アニマルマスクでエッジの処理にも興味を持ってもらえてよかった。 会場が広くてきれいだったのでおどろいた。 大変だったけど楽しかった。 ノベルティがかわいいと好評でよかった。 今後の改善点として挙がったのは アニマルマスクの動物を検出した人の属性で振り分けけてもよかったかもしれない 生成AIも組み合わせたら面白かったかも マスコットのぬいぐるみを置きたい ゲーム要素も入れたかった セーフィーは今後も認知拡大のため継続的にイベントに参加します。 セーフィーはエンジニアを積極的に募集しています。ご興味がある方は採用ページをご覧ください。 safie.co.jp

はじめに こんにちは！セーフィー株式会社でデバイス開発をしている杉本です。 セーフィーでは普段の業務以外にも、エンジニアのスキルアップのために様々な取り組みを行っています。その一つの取り組みとしてエンジニアの「やってみたい！」をボトムアップで実現する活動をしています。 今回はコンセプトの立案からプロトタイプのユーザー検証まで行うプロト開発WG(ワーキンググループ)の活動をご紹介します！ はじめに プロト開発WGの目的 やったこと 他部署からのフィードバック やってみて 最後に プロト開発WGの目的 セーフィーはクラウドカメラサービスを提供しており、様々な現場のユーザーの課題に向き合って新プロダクトの企画・開発を進めています。 営業、企画からの提案で開発をすることが多いのですが、エンジニアだからこその気付きもあります。ユーザーが気付かないような視点からエンジニアが提案ができる組織を実現すべく、プロト開発WGを開催しています！ 今回のワークショップの目的は以下のとおりです。 エンジニア自身でユーザーの課題の仮説を立てて検証し、プロト開発の知見を得ること 業務で使用する技術以外の技術領域にチャレンジしてスキルの幅を広げること やったこと プロト開発WGではコンセプト(仮説)の立案、プロト開発、ユーザー検証の大きく3つのプロセスで進めており、今回のプロト開発WGではデバイス開発部の有志メンバーにて計5か月の期間で実施しました。 コンセプト(仮説)の立案　約2カ月 ユーザーの想定課題 想定課題に対するユーザーへの提供価値 プロト開発　約2カ月 コンセプトを実現するための技術検討 コンセプトを試すためのプロトを開発 ユーザー検証　約1ヶ月 ユーザーにプロトを試してもらい、フィードバックを得る フィードバックから課題を抽出して改善の方向性を特定する コンセプトの立案ではエンジニアならではの視点でアイデアが合計12個出てきたのですが、そこからの絞り込みが苦労しました。ユーザーの課題をどう解決できるのか、どれだけユーザーにとって価値があるのか、などの深堀をしてコンセプトの絞り込みを進めました。 最終的には提供価値だけでなく、技術的に実現ができそうか、他社とは違いがありそうか、今後も活用できそうかの4つの観点で5段階で点数付けをしてコンセプトを1つに決定しました。 このような議論を通じてエンジニアが提案できる組織につながるような視点を養うことができたのではないかと思っています！ また、本活動で実際に立案したコンセプトや開発プロトタイプについてはありがたいことに商品化検討のステップにつながっているので、残念ながら本ブログでご紹介することができません。 ただ、ユーザーの課題に着目してコンセプトをエンジニア自身が考えたため、大変ながらも楽しくプロトタイプの開発ができました！ 他部署からのフィードバック ユーザー検証に協力いただいた各部署の方から本活動についてたくさんのフィードバックがありましたので一部抜粋して公開します！ とてもいい活動だと思いました。営業側では思いつかない視点もありありがたいです。 提案内容が突拍子もないものではなく、既にある機器の拡張や改造で行けるという、夢と現実のはざまの大変バランスの良い所を攻めているので、商品化の可能性が高いと思いました！ 技術オリエンテッドな提案は営業企画としても刺激されるとおもいます。なにより活動メンバーが楽しそうにしていたのが印象的でした！ 非常に面白かった。今すぐ商品に繋がらないことも多いと思いますが、このようなことをやって今後の商品につながる種をいっぱい作って欲しいです。 営業、企画スタートではなく、開発から発信したほうが固定概念に縛られないモノが作れる場合があるし、営業・企画が暗黙のうちに諦めたり後回しにしたものが作られたりするので、今後も継続してほしいです。 想定機能を型にすることで、もっとイメージしやすいです。「こんなこともできることだ」を直感でき、ペーパーより商品に対する理解が深くなる。また、実現可能性も参考になります。 日々とてもお忙しい中、アイディアを形にする時間を取るのは非常に大変だったと思いますが、ここまでWowのあるものを短期間で仕上げており本当に素晴らしいと思いました。 開発側の方がお持ちのアイディアと顧客課題をうまく紐づける活動をしていきたいと考えているので、こういった事がやりたい！これってニーズありそう？といった話はお気軽にしていただければと思います！ 非常に有意義な時間でした！プロトタイプと言いつつ、商品建て付け考えればそのまま売れるのではと思うくらいのクオリティだったのですぐ企画と連携して進めていきたいくらいです。 最終的にプロトタイプの実機デモと合わせて、セーフィー全社員向けのプロト開発WGの報告会を実施しました。 ありがたいことに、オフライン、オンラインのハイブリッドで開催したのですが、100名以上の方に参加いただいて報告会の後も質問が絶えないなど大盛況で終えることができました！ 全社員向けのプロト開発WG報告会の様子 やってみて 参加メンバーにて本活動の振り返りを実施しましたので一部抜粋して公開します！当初の目的についてはおおむね達成できた結果となり、一安心です！ 提案したプロトタイプ4つのうち、3つは具体的にユーザーの現場でのPoCにつながるなどエンジニアのボトムアップの活動から実際の商品化に向けて動き出すという予想以上の結果を出すこともできました！ 反省点としては記載の通りですが、通常業務をしながら本活動の時間をなかなか割くことができずにプロトタイプの開発に苦労してしまったことです。良かった点を活かしつつ次回の活動では改善をしていきたいと思います！ Keep 全員しっかり関わりながら、期間内にコンセプト立案～開発～実機デモまでやりきることができた 業務ではあまり使わないプロダクトや技術の知見が得られた 営業、企画への実機で技術提案をすることで、プロダクト化に向けた前向きな議論ができた Problem プロジェクトなどの主務の忙しい時期と重なると本活動に割り当てる時間が確保するのが難しく、進捗がない時期が発生してしまった トライ＆エラーでの実装となり、予想よりも開発に時間がかかってしまった Try 開発期間は2ヶ月ではなく3～4ヶ月は確保する 新しい技術に挑戦するため、開発期間に余裕が必要なため タスクと担当を明確にして計画を立てて進捗管理する トライ&エラーでの開発が前提だが、計画を立てて進めることで効率的に開発をするため 本活動はトライアルとしてデバイス開発部にて閉じて実施したのですが、他の部署からも参加したいという声が挙がってきており、ゆくゆくは開発本部横串での活動に広げていきたいと思っています。 最後に 本記事では、プロト開発WGの活動についてご紹介させていただきました。 セーフィーではエンジニアを積極的に募集しています。どのような職種があるのか気になる方はこちらをご覧ください！ safie.co.jp カジュアル面談から受け付けておりますので、気軽に応募いただければと思います！ 皆様のご応募、心よりお待ちしております！ 最後までお読みいただき、ありがとうございました。

はじめに こんにちは。 セーフィー株式会社でサーバーサイドの開発をしている金成です。 今回は、サーバーチームで「マイクロサービスアーキテクチャ第2版 」 を題材に、輪読会を開催したので、紹介させてください はじめに 背景 実装/実行 やってみて 終わりに 背景 セーフィーは、サービスの拡大と開発者の増加に伴い、工数の増加やリリースリスクの増大など、開発生産性の問題を抱えています。この問題の解決のために、組織の再編やコードベースの分割によるマイクロサービス化が進行しています。 私を含め開発チームのメンバーには、マイクロサービスとはなんなのか？何を目指してるのか？どういったメリット・デメリットをもたらすのか？などイメージがついていない部分がありました。 そこで、今回の「マイクロサービスアーキテクチャ第2版」を参考に輪読会を開催し、このトピックに対する理解度を深めようとしました。 実装/実行 開催の形式は、下記の通りです 週1回 30-45分で開催 1つの章を取り上げ、参加者は事前に読む 議論したい話題を取り上げ、自由に議論する 議論した内容を簡単に残し、後で見れるようにする 全16章、4ヶ月ほどかけて全ての章で実施しました。 議題は マイクロサービスにおける一番の目的は何か、どんな指標を持つべきか REST/RPC/GraphQL/メッセージキューの使い分け サーガパターンとその適用するケース コンウェイの法則と逆コンウェイ戦略について などがあり、技術的な側面から組織面まで様々な議論をしました。 弊社ではドキュメント管理にnotionを利用してるので、下記のようなテーブルを作成して、議題を管理しています。 下記のように笑顔の絶えない議論が展開され、4ヶ月間笑いが絶えることはありませんでした。 — アットホームな職場の写真サンプル(ﾀﾉｼｲﾖ, ｺﾜｸﾅｲﾖ) やってみて 輪読会後にアンケートをとったところ、下記のような結果が得られました。 よかったところ マイクロサービスへの理解が深まった 参加者の実務経験から周辺知識を補うことができた 対話の機会が増えた 問題点・改善点 事前の準備の時間が足りなかった 発言の機会が足りなかった 時間が足りなかった 事前準備や議論のファシリテーションには問題が残りますが、マイクロサービス化への理解を深めるという当初の目的を達成できたこと、リモートが多い弊社で対話の機会を増やせたことは一定プラスになったかと感じてます。 終わりに 自分の思い付きから企画した輪読会でしたが、参加してくれたメンバーの満足度は概ね高く、やってよかったと感じました。 実は、私もこの秋からマイクロサービス化を進めるチームに参画しています。マイクロサービスについて知らないままだと、仕事がうまく進められません。だから「マイクロサービスアーキテクチャ」を読む必要があったんですね。 セーフィーではエンジニアを積極的に募集しています。気になる方はこちらをご覧ください！ safie.co.jp この記事を読んでもし興味を持っていただけた方は、ぜひ採用サイトもご覧ください。 カジュアル面談のみでも大歓迎ですので、お気軽にご連絡ください。 最後までお読みいただき、ありがとうございました。

はじめに こんにちは！QCDグループに所属している小熊です。 Safie Viewer for PCのQA（システムテスト）を2019年9月頃から担当しているのですが、悩みのタネであった「度重なるバージョンアップによって増え続けるリグレッションテスト項目」の解消を目指してトライしてみたことについて書こうと思います。 セーフィーにおけるQCDグループはどういう事をしているのか？を紹介している記事もございますので、是非こちらもご確認ください！ engineers.safie.link はじめに リグレッションテストについて 暗黒時代 「整理整頓」時代 その後（現在） まとめ リグレッションテストについて Safie Viewer for PCは月イチで新バージョンがリリースされており（過去はもっと頻繁に（2～3週間に1回程度）リリースされていた）、その度に新機能追加や不具合修正などが既存機能に悪い影響（意図していない影響）を与えていないことを確認する必要が有ります。 Safie Viewer for PCは歴史が古いこともあって機能数が多くて思わぬところに開発影響が出たりするため、範囲や対象を絞り込まずに全てのテスト項目の実施（フルリグレッションテスト）をリリース毎に行っています。 暗黒時代 リリース毎に新機能もしくは改修が入るので、リグレッションテスト項目内容もそれに合わせて更新し続ける必要があります。 具体的には新機能は一度リリースされたら既存機能に含まれるのでその内容をリグレッションテストに落とし込んでいるのですが、その度にテスト項目は増え、増え、増え、と増え続け、これまで一番ひどかった時期の項目数をピックアップしたら下記表な感じでした。 リリース月 実施項目数 2022年7月 1083 2022年12月 1230 2023年3月 1584 2023年8月 2102 1年で実施項目数が約2倍！こりゃだめだ。。 この件について頭を悩ませていたポイントを下記にまとめてみました。 テストの実施に時間がかかる 項目ごとに優先度を割り振り、優先度低い項目は毎回は実施しないようにしていたがそれでも限界 テスト項目の視認性が悪くてやりにくい テスト項目のメンテナンスに時間がかかる 1と共通点が多い問題、メンテナンス後に項目レビューするのも大変 テスト自動化対応しにくい テスト自動化対応しにくい 自動化できる／できない（しない）の精査、自動化した後の管理が大変 これとは別に新機能／改修向けのテストの準備や実施が有り、特にテスト期間中はテスト項目消化に追われていた（探索的テストなど、他のことに割く工数が無い） これらによって改善活動（テスト項目の整理整頓）にリソース割くのが困難、改善しないので更に項目が増えていき、さらにリソースが逼迫するという悪循環に陥ってました。 「整理整頓」時代 暗黒時代の中、ただ手をこまねいていたわけでは無く、課題解決のためにはどのような方針で整理整頓する必要があるのかをQAメンバー全員で議論や準備を少しずつ進めていたところ、ある転機がやってきました。 engineers.safie.link ↑の記事にあるテスト管理ツールの導入イベントです。 これまでスプレッドシートでテスト項目を作成＆実施していたものを管理ツールで行うことが決定、せっかく管理ツールへの移行に工数割くなら準備してきた改善案を適用した内容でやってやろうじゃないかとなり、テスト実施にかかる以外の工数をほぼ全振りして整理整頓対応することとなりました。 その時の整理整頓の活動方針は これまでのテスト項目を優先度付けして、優先度高い内容を移行する新項目のメイン機能（骨格）とする 1で決めたメイン機能チェックは、なるべくシンプルにまとめる（肉付け） 肉付けの際は「自動化できる（自動テストのみで完結できる内容）」「できない or 困難（メンテナンスに時間かかるなど）」のように自動化可否を分けて（混在しないように）行う の3点です。 特に①と②の対応に苦心しました。 どの機能を骨にして（いわゆる優先度付け）どれだけ肉付けするかは、「これまでで実施してきた項目」から「どれだけインシデントが検知できてきたか」の分析を行ってその結果を指針にしたり（新しい項目によって実施工数は減ったけどリリース後に見つかるバグが増えた、は許されない）、①や②の対応後に「これまでのインシデントが検知できる内容になっているか」の見直しを行ったり、それをメンバー間でレビューしあったり（①②の実施は各メンバーの感覚によってバラつきが有るので）、とにかく試行錯誤の連続でした。 また、テスト項目での記載内容によってちょっとでも項目を減らすように工夫しました。たとえば「画面AでボタンAの確認」「モーダルBで機能Bの確認」とぶつ切りになっていた2つの項目を「画面AでボタンAを押下した後のモーダルBで機能Bの確認」のように一連の流れで網羅できるような1つの項目へ組み替えたりです。 その後（現在） 整理整頓を頑張り始めてから、その後項目数はどうなったでしょうか。 リリース月 実施項目数 2023年8月 2102 2024年5月 641 2024年12月 665 ピークから3分の1以下まで減りました（拍手！） ただし気を抜くとあっという間に以前に逆戻りしてしまう（実際、5月から少しずつ増えている）ので活動の継続は必要なのと、浮いた工数をどのように有効活用していくかも今後の課題のひとつです。 まとめ 今回の対応が最適解とせず、メンバー内で整理整頓（①～③）への共通認識ができている今の内に更なる改善目指し、これからも試行錯誤進めていこうと思っています。（そのことをまたお話できたら良いなぁ）

はじめに セーフィー株式会社 でサーバーサイドエンジニアをやっております石塚です。 今回はGoogle Chromeの拡張機能に入門したので備忘録として残しておこうと思います。完全にプライベートで利用するための拡張機能を実装したので、ゆるりと呼んでいただけると幸いです。 はじめに 拡張機能の作り方 インストール ローカルで実行 実装 最後に 拡張機能の作り方 今回はGoolge Chrome向けの拡張機能を実装する方法を紹介します。 Google公式の拡張機能ドキュメント があります。詳しくはこれを参照してください。基本的にはHTML, CSS, JavaScriptで実装可能なので簡単に構築することができそうです。他には他に WXT や Extention.js , plasmo などの拡張機能向けのフレームワークを使う方法もあります。 今回は plasmo を選択しました。”the all-in-one platform that makes it easy for browser extension developers to create, test, and publish amazing extensions.“とあったので全部入りかつ簡単に導入できそうという安易な理由です。 インストール 動作環境は以下の通りです。 macOS Sonoma 14.7 node v18.16.0 npm 9.5.1 まずはプロジェクトを作成します。今回はnpmを使いますが公式ではpnpmの使用が推奨されているようです。 npm create plasmo 対話形式でプロジェクト名や説明などを設定します。 しばらく待つとプロジェクトが作成され、以下のようなディレクトリ構造になっているはずです。 / < PROJECT_NAME > ├── README.md ├── assets │ └── icon.png ├── package.json ├── popup.tsx ├── tsconfig.json └── yarn-error.log 意外とシンプルな構造ですね。 ローカルで実行 まずはローカルで実行してみましょう。 # 筆者の環境では不足していたので追加 $ npm install sharp # 実行 $ npm run dev > extention-sample@ 0 . 0 . 1 dev > plasmo dev 🟣 Plasmo v0. 89 . 4 🔴 The Browser Extension Framework 🔵 INFO | Starting the extension development server... 🔵 INFO | Building for target: chrome-mv3 🔵 INFO | Loaded environment variables from: [] ( node:29924 ) [ DEP0040 ] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead. ( Use `node --trace-deprecation ...` to show where the warning was created ) 🟢 DONE | Extension re-packaged in 1734ms! 🚀 ビルドされ、開発サーバーで実行可能な状態になっているのでブラウザから拡張機能を有効化して動作確認してみます。 chromeの右上の3点リーダーから「拡張機能」、「拡張機能を管理」に進みます。拡張機能のページの右上に「デベロッパーモード」があるので、このトグルボタンをおして有効化します。 「パッケージ化されていない拡張機能を取り込む」から先ほどビルドの成果物を選択します。 ./build/hrome-mv3-dev に出力されています。 取り込むと以下の画像のようになります。 ブラウザから拡張機能をピン留めしてクリックすると作成した拡張機能が確認できます。 これで最低限の開発ができるようになりました！ 実装 今回はサンプルとしてページがロードされたときにコンソールにURLを出力してみます。 mkdir contents code contents/content.ts 新しくcontents.tsを編集します。今回は以下のような実装にしました。 export {} ; window . addEventListener ( "load" , () => { const url = new URL ( window . location . href ); console .log( "URL:" , url. origin + url. pathname ); } ); ホットリロードが有効なのでコンソールを表示しながらページをリロードするとアクセスしているURLが表示されます！ ビルドの成果物にはHTML, JavaScript, manifest.json（それから画像ファイル）が含まれています。manifest.jsonは拡張機能に必須のファイルですが、これはplasmoが生成しています。manifest.jsonの内容はpackage.jsonで定義できます。 このままではあまり意味のある拡張機能ではないですが、ビルドしていつでも使えるようにしてみましょう。 npm run build ./build/chrome-mv3-prod/ にビルド成果物が出力されます。 これをブラウザの拡張機能のページから読み込むと開発サーバーが起動していないときでも使えます。 拡張機能を広く公開するにはパッケージ化したり、Googleウェブストアで公開したりしないといけないですが、ここでは紹介しないのでぜひ 公式のヘルプページ などを参照して公開してみてください。 最後に 簡単ですが、Google Chrome拡張機能の作り方について紹介しました。 シンプルにHTML, CSS, JavaScriptで実装する方法もありますが、フレームワークを使うとフレームワーク特有のお作法があったりと学習コストが増える分、いろいろとよしなに作ってくれます。 30分から1時間程度あれば簡単な拡張機能は作れると思いますので、年末年始に作ってみるのはいかがでしょうか？ セーフィーではエンジニアを積極的に募集しています。気になる方はこちらをご覧ください！ https://safie.co.jp/teams/engineering/ この記事を読んでもし興味を持っていただけた方は、ぜひ採用サイトもご覧ください。 カジュアル面談のみでも大歓迎ですので、お気軽にご連絡ください。 最後までお読みいただき、ありがとうございました。

メリー・クリスマス、セーフィーCTOの森本です。 こちらは Safie Engineers' Blog! Advent Calendar の25日目のエントリーです。 早いもので、昨年 創業以来10年の開発組織の振り返り について掲載してからもう1年が経ちます。昨年の記事の最後でも触れた通り、メンバーのお陰で事業、組織、プロダクト、内部的な仕組みなど全てにおいて様々な課題を乗り越え再成長軌道に載せると共に、その先の更なる成長へ向けての仕込みも適宜進められていると実感しています。特に大きなチャレンジであったシステム刷新も専任チームを組成し、一歩一歩ですが進められている状況となっています。 さて、今回のエントリーではシステム刷新とは別の、先々に向けた重要な取り組みの一つである AIソリューションプラットフォーム について紹介します。 はじめに AIソリューションプラットフォーム概要 実現したいこと AIソリューション開発における課題 システム構成イメージ 目指すべき姿 経産省PJへの採択 今後に向けて まとめ 最後に はじめに 図1 当社は主にB2B領域でクラウドレコーディングサービスを提供しています。 様々な業界のお客様の現場で、防犯だけでなく業務改善用途でも幅広く活用されており、既に27万台を超えるカメラがお客様環境で常時稼働しており、それらのカメラで録画された総量35PBを超える膨大な映像データが当社システム上で管理されています。 単純な録画視聴に加え、特に業務改善観点では映像データの解析なども重要で、既に複数の 汎用的用途のソリューション の提供は行っているものの、お客様からも業界、課題に特化、もしくはお客様に特化したデータ活用のご要望を幅広く頂いており、より広範囲で効率的に様々なソリューションの開発、提供を進められるような仕組みの整備が急務となっています。 尚、データ活用という観点ではAIの利用は当然考慮に入れる必要がありますので、如何にAIを活用したソリューションの提供を効率的に行えるかも重要な要素と捉えています。 AIソリューションプラットフォーム概要 実現したいこと 図2 冒頭で触れた通り、我々は映像データを活用し、我々のサービスをご利用頂いている様々な業界のお客様の現場課題の解決を進めて行きたいと考えています。ただ、様々な業界が存在し、その中の課題もまた多様な状況で、これらを我々単独で実現するのが不可能に近いのは明白です。（図2参照） だからこそ我々は我々のシステムをプラットフォームと定義し、APIやSDKを活用してデータを活用できるような機能を既に提供してきています。 developers.safie.link 今後に向けてはこれを更に発展させ、他のAI開発者も容易にお客様の課題解決につながるAIソリューションの開発と展開を行える仕組みを整備し、多面的にこれらの活動を進めていく事が必要だと感じています。 大前提として、AIソリューションの開発には適切なデータ活用が必要ですので、我々はまずはそれらを促進する為に何を実現する必要があるかの整理を行ってきました。 AIソリューション開発における課題 図3 適切なデータ活用を実現するための仕組みの整理を行っている中で、AI開発者とデータホルダー（我々に取ってのカメラをご利用頂いているお客様）がそれぞれ課題を抱えている事がわかりました。（図2参照）例えばデータホルダーで言うと、そもそもデータ提供を行うメリットが不明確だったり、いざデータを提供するにも手間がかかります。また、昨今は個人情報やプライバシーにも十分に配慮をする必要があります。一方で、AI開発者側はAIモデルを開発しようにもデータの収集に手間がかかったり、いざAIモデルを準備してもアプリケーションとして提供する環境が必要となります。 これらの課題がデータ活用の促進とAIソリューションの開発効率を高めるための課題となっている事がわかりました。 システム構成イメージ 図4 データホルダー、AI開発者の抱える課題を解決するため、我々は当社が管理する映像を教師データとして活用し、効率よく且つ一気通貫でAIソリューション開発が行える仕組みを提供すると共に、開発したAIソリューションが当社のカメラやクラウドプラットフォーム上に直ぐに展開でき、実行可能な環境を整備していきます。（※大前提として当社が管理するデータはデータホルダーに帰属していますので、その活用にはデータホルダーの合意が必須です） これによって、データホルダーはデータの取り回しやセキュリティについてあれこれケアする必要がなくなり、一方でAI開発者はAIモデル開発にできるかぎり集中し、データ収集に工数を割く必要も無ければ、アプリケーションの展開先も当社の環境を活用することにより素早く顧客に価値提供を行う事ができるようになります。 我々としては、わざわざデータ収集しなくとも、データホルダー環境に展開済みのカメラによって録画されたデータを活用できるのも非常に重要な点ですが、開発したAIソリューションを稼働中のエッジAIカメラやクラウドシステム上に展開し素早く利用して頂く状況に繋げられる点も非常に価値がある点であると捉えています。 目指すべき姿 図5 我々は、先ほどの仕組みによりデータホルダー、AI開発者の抱える課題を解決し、AIソリューションの効率的な開発、展開を可能としていく事だけでは、目標とする様々な業界の課題解決の実現には不十分だと考えています。 AI開発者がどこにどのような課題が存在するか十分に分かっていないケースがあれば、一方でデータホルダーも課題解決に向けてどのAI開発者と連携すればよいか不明確なケースがあると推測しています。 これらの状況を解決するために、上記に加え、データホルダーとAI開発者の連携を実現するような場の構築、提供を行う必要性も感じており、合わせて整備を行っていくことを考えています。 このようなデータホルダーとAI開発者間の多対多のコラボレーションの実現こそが、先程の仕組みの効果を適切に発揮させるために必要であると捉えています。 経産省PJへの採択 我々は上記で説明したAIソリューションプラットフォームについて、数年前より検討を進め少しづつ進めていましたが、この度、国立研究開発法人新エネルギー・産業技術総合開発機構（以下「NEDO」）が公募した「ポスト5G情報通信システ厶基盤強化研究開発事業／データ・生成AIの利活用に係る先進事例に関する調査（調査類型1）」に採択されることが決まりました。 safie.co.jp データ活用に対しての国としての課題感、危機感の現れでもあると捉えています。我々としてはこれはもちろん好機ではありますが、一方で国策の一貫に選定頂いた責任と自負を感じつつ、開発活動を加速して行きたいと考えています。 今後に向けて AIソリューションプラットフォームの開発を進め、2025年中には外部に公開できるよう準備を行うべく進めています。 図6 合わせて、その有効性を示すべく実際のデータホルダー、AI開発者にもご協力頂き、AIソリューションプラットフォームの効果の実証も進めていきます。 更に、有効なコラボレーションの場として成立させていく必要があり、その為にはよく知って頂く事が必須だと捉えていますので、認知向上に向けた取り組みも順次行っていきます。 テックブログでも継続的に具体的な取り組みについてアップデートする想定で検討を進めています。 まとめ 我々はお客様の様々な現場課題の解決を多面的に推し進めるため、それぞれの抱える課題の解決を行える仕組みの整備と、データホルダーとAI開発者の多対多のコラボレーションの場を提供すべくAIソリューションプラットフォームの整備を進めて行きます。 これらの仕組みを活用しデータ活用を多面的に進めて行くことにより、様々なお客様がAIの有用性を実感できるような社会の実現を目指して行きます。 最後に 今回はAIソリューションプラットフォームの紹介となりましたが、セーフィーでは他にも更なる成長へ向けて様々な開発に関わる取り組みを行っています。それらに一緒に関わってくれるエンジニアさんを絶賛募集しています！！！！

この記事は Safie Engineers' Blog! Advent Calendar 24日目の記事です。 はじめに こんにちは、セーフィー 企画本部 デザインセンターの碇石（いかりいし）です。 2024年10月30日、デザインシステムを用いたUIリニューアルがついに公開されました。対象プロダクトは、エンタープライズ向けに多台数のカメラを統合管理できるSafie Manager（セーフィーマネージャー）です。 まず、デザインシステムについては、2019年12月頃から開発を進めていました。2023年に入ってからSafie Managerを含む管理ツールの開発を行っている開発チーム内でフレームワーク移行の話が上がり、そのタイミングに乗せる形でデザインシステムを用いたUIリニューアルプロジェクトが始動。 手探りでスタートしたこのプロジェクトは約1年10ヶ月の開発期間を経て無事公開となりました。 はじめに 開発体制 戦略：手探り感満載の初動期 ターゲットユーザー 目的 UX課題 具体方針 構造：オブジェクト指向（OOUI）で再設計 サイトマップとデータ管理の流れの型化  骨格〜表層：作っては壊しを繰り返して磨き上げるUX 画面構成（ゾーニング） WF〜デザインカンプ マイクロインタラクション まとめ さいごに safie.co.jp 最適なUXを考える上で、デザインセンターでは日頃からJesse James Garrett 氏が提唱する5段階モデルを用いる事が多く、今回のプロジェクトもこちらをベースにデザイン制作までを振り返ってみようと思います。 UXの5段階モデル 開発体制 フレームワーク刷新を含む大型リニューアルはセーフィーとしても初めての試みとなるのですが、このプロダクトは初期リリースの後デザイナー不在となり開発チームのみで守っていたプロダクトなのです。 そういった背景もあり、このチームにおいてはエンジニアとデザイナーの共同開発は実質初めての状態。今回のプロジェクトのためにディレクターとデザイナーをアサインしました。 PdM 1名 フロントエンドエンジニア 9名 デザインディレクター 1名 デザイナー 2名 戦略：手探り感満載の初動期 UXの5段階モデル - 戦略 -  日頃から使い勝手に関する足元の課題感は多く、この機会にしっかり解決していきたい意志をエンジニアと共に意識を合わせ、再設計に当たり、ターゲットユーザーのすり合わせと目的、現状のUX課題の抽出を行いました。 ターゲットユーザー 企業の管理者 情報システム部など会社のシステムを管理する人物 スーパーバイザーやマネージャーなど、現場の監督責任者にあたる人物 利用用途 複数店舗を跨いで多台数カメラの設定および操作権限を管理する 目的 フレームワークの刷新（Nuxt2→React） デザインシステムの適用 【ポイント】UXの改善（あるべきを考え、使い勝手の負を解消する！） 今回のリニューアルのポイントは、最適なUXの実現です。ユーザビリティ *1 を担保することはもちろんのこと、複雑な仕様に対しユーザーがストレスなく利用できる状況を目指します。 UX課題 一貫性が無く、学習コストの高い操作体験 予測しづらい機能名称 つぎはぎ的に追加されたナビゲーションメニュー 生かされていない一等地のホーム画面 具体方針 構造の最適化 骨格の最適化（ナビゲーション） 機能名称の最適化 今回はUIのリニューアルなので、機能要件はそのままに、ユーザーニーズに則したUXの検討に向けて構造〜骨格の再設計を実施します。 構造：オブジェクト指向（OOUI）で再設計 UXの5段階モデル - 構造 -  Safie Managerでは、管理するオブジェクト（データ）が多くそれぞれを結合させることでカメラデバイスの管理や管理権限の組み合わせの自由度を実現させています。 その一方で複雑な機能にインターフェースが追いついておらず、例えばオブジェクトが選ばれていないのにタスク選択のUIが出っ放しになっており、実行ボタンはdisableになっている、、 実行不可の理由が分からないというストレスをユーザーに与える可能性のある箇所や、操作画面の初期状態から「この操作は無効です」というようなエラー表示がされているなど、散見していました。 また、一覧上の操作においては単一の場合でも一時的にオブジェクトを選択状態にしなくてはならず効率の面で課題がありました。 旧UIのオブジェクト操作のインタラクション 設計の基本思想としてオブジェクト指向（OOUI）を意識し、オブジェクトを選択→タスクの選択→結果という流れに調整しながら、インタラクションを含めた形で基本的な負を改善する事ができました。 整理したオブジェクト操作のインタラクション サイトマップとデータ管理の流れの型化  仕様理解もかねて、現行の構造も明らかにしながらデータ管理の流れを型化。全体像でBeforeAfterのイメージをすり合わせ、ナビゲーション構造はこのサイトマップを元に再設計を行いました。 サイトマップ ナビゲーション構造の再設計 データ管理の流れの型化 この辺りは、今後画面を作っていく中での指針となる部分なので細かく確認を交えながら設計していきました。 骨格〜表層：作っては壊しを繰り返して磨き上げるUX UXの5段階モデル - 骨格〜表層 - 型化したデータ管理の流れを元に各画面を制作していきます。このフェーズになってくるとイメージが具体化していくので、実装に向けた細かい調整に移っていくところではありますが、画面構成をユーザーニーズに立ち戻り一度壊して再考するといった場面も多く発生しました。 画面構成（ゾーニング） ゾーニング 画面構成はプロダクト全体で統一されるため、デザイン主体で設計しています。 ヘッダー プロダクト共通で固定化されています。デザインシステムがまだ反映されていないプロダクトにも既に展開されているUIになります。 ナビゲーションメニュー プロダクト固有のメニューが並びます。作成したデータなど可変するものをメニューに並べることはNGというルールを設けています。 コンテンツエリア 制約は特にないですが、横幅指定が画面幅100%を基準値とし、設定画面など横幅の長さによりコンテンツが見づらい、使いづらい場合に1040pxを最大値とするルールを設けています。 WF〜デザインカンプ UIComponentがある事で、より具体的な形で情報設計をする事ができます。見た目がデザインカンプなので、この段階で作って壊してっていうのは大変なのでは、、と思われるかもしれませんが、実際の作業負荷はそこまででもなかったりします。 ただ、エンジニア側からのFBや提案の際、現状の制作環境としてFigmaの編集権限をもっていないエンジニアにとっては改めてWFを作って伝えなければいけない環境だったので、画面要件を決めるまでのラリーが何度も繰り返されたのは、今回のプロジェクトの中でも一番大変だった部分なのではないかと思います、、 デザインFIXまでの流れ マイクロインタラクション disable時にリストをhoverすると、選択不可の理由がToolTipにより表示されるなどの細かいインタラクションを検討しながら最後の仕上げを行なっていきました。全ての画面に行き届いていない状況ではありますが、このToolTipが出ることで安心感が高まったように思います。 disableのオブジェクトをhoverした時 まとめ 今回はデザインを作るまでの話を5段階モデルに沿って振り返ってみました。改めて振り返ってみると、初動の「ユーザーを知る」ここの紐解きが甘すぎた事が今回の一番の反省点です。 実はこの5段階モデルの考え方もOOUIも、エンジニアには全く共有していないまま進めており、前提となる意識の部分で噛み合わない瞬間がしばしばあったように思います。 一方で、プロジェクトやデザインに対するエンジニアの思いの強さを肌で感じルことができ、プロジェクトが進行するにつれてプロジェクトメンバーの一体感が強くなったように思うのはすごく嬉しかったです。 現在、絶賛プロジェクトメンバーと振り返りを行っており、ユーザー理解が十分にできていればプロダクト特性を捉えた大胆な操作体験も実現できたかも？などなど後悔することもありますが、運用フェーズではデザイナーとエンジニアの連携強化に向けた相互理解の場や勉強会の実施など、前向きな取り組みを始めようとしています。 手探り感のある進行に全力で頑張っていただいたプロジェクトメンバーには感謝しかありません、、今後のエンハンス開発に向けて今回の反省を活かした共創体制を築いていきたいと思っています。 さいごに デザインセンターでは、今回のプロジェクトのキーとなるデザインシステム「Pantograph」を順次主要プロダクトに反映しています。 デザインシステムの全体像や、開発秘話を掲載しておりますので、よろしければ合わせてご覧ください。 note.com note.com セーフィーではデザイナー3期生を募集中です。 safie.co.jp *1 : ユーザビリティ＝「使いやすさ」ではなく「利用可能性」と考え、有効さ、効率、満足度の度合いで判断しています。