この記事は Safie Engineers' Blog! Advent Calendar 17日目の記事です。 はじめに セーフィー株式会社 AI開発部でテックリードを務める橋本です。 本記事では、私が2025年の1年間を通じて 設計・実施してきたAI開発部の技術ミーティングの取り組みについてご紹介します。 これらのミーティングは、テックリードとして掲げた 「継続的な学びと成長の機会を提供し、組織全体の技術力を底上げする」 という目的のもと企画しました。 具体的には、以下の4つの活動を軸として運用しています。 論文読み （隔週 30分） コード読み （隔週 30分） 勉強会 （隔週 1時間） 成果発表会 （隔週 1時間） それぞれのミーティングに込めた意図と、2025年の実施状況について詳しくお話しします。 はじめに 論文読み ① エッジでのリアルタイム処理 ② 映像解析 ③ Multimodal & Reasoning コード読み 勉強会 ① エンジニアリングプラクティス・ドキュメンテーション ② ソフトウェア設計 ③ テスト・品質保証 ④ Pythonエコシステム・技術スタック ⑤ 組織論・キャリア 成果発表会 まとめ 論文読み AI開発部では、日進月歩で進化するAI技術やトレンドを素早くキャッチアップし、それを製品開発へ還元することを目指しています。したがって、業務課題に関連した論文を調査し、常に最新の動向を把握し続ける姿勢は不可欠です。 また、読んだ内容をチームにアウトプットすることは、発表者自身の理解を深めるだけでなく、聞き手となるメンバーの知見拡大にも寄与します。 2025年は、チーム全体で計31本の論文を取り上げ、議論を行いました。今年の選定テーマを振り返ると、当社の映像プラットフォーム事業に直結する以下の3分野が中心となりました。 ① エッジでのリアルタイム処理 リアルタイム性が求められるエッジデバイス（カメラ）内において、推論精度と処理効率を両立させる技術です。 最新の物体検出: YOLOv12, YOLOv13, YOLOE など、高速かつ高精度な検出モデル 軽量化・高速化: MobileMambaや量子化技術など、限られたリソースで高性能なモデルを稼働させる手法 高度なトラッキング: 混雑環境下での人物追跡や、IDスイッチの抑制技術 ② 映像解析 映像からオブジェクトや異常を「数値・構造化データ」として正確に抽出する技術です。 異常検知・安全管理: 建設現場の安全確認や、防犯用途での危険察知能力の向上 3D復元・深度推定: CameraHMR, Depth Anything V2など。単眼カメラの2D映像から、人物の姿勢や空間の奥行きを復元し、高度な判断につなげる技術 ③ Multimodal & Reasoning 数値データの抽出に留まらず、LLM/VLMを用いて映像の「文脈や意味」を理解・推論する技術です。 映像理解の深化: InternVideo2, MM-VIDなど。長時間映像から「何が起きているか」を言語化し、検索や要約を可能にする基盤技術。 推論能力の強化: DeepSeek-R1, Chain of Draftなど。AIが文脈を深く読み解き、ハルシネーションを抑えて確からしい判断を下すための基礎研究 コード読み プロダクトエンジニアにとって、設計力および実装力の向上は極めて重要です。 日常業務の進捗管理だけでは、コードレベルまで踏み込んだ品質や工夫を共有しきることは困難です。また、Pull Request上のレビューだけでは、レビュア以外のメンバーへのナレッジ共有が不足しがちであるという課題感がありました。 そこで、他者の優れた設計や実装に触れることで「自分も採用してより良いコードを書きたい」という意識を高め、自然とベストプラクティスを共有・実践したくなる文化を目指しました。 2025年は、 計22回 のコード読みを実施し、実装のベストプラクティスについて議論を深めました。 勉強会 論文読みで得た最先端の知識を、実用的なプロダクトとして落とし込むための「エンジニアリング力」を高めるべく、多岐にわたるテーマに取り組みました。 ① エンジニアリングプラクティス・ドキュメンテーション コードを書く以前の「どう伝えるか」「どうレビューするか」という基礎スキルに焦点を当てました。 Google Engineering Practice Google Technical Writing Course (One / Two / Error Message) 考える技術・書く技術 ② ソフトウェア設計 堅牢で保守性の高いソフトウェアを作るための設計理論について学びました。 クリーンアーキテクチャ ドメイン駆動設計 デザインパターン ③ テスト・品質保証 コードの信頼性を担保するためのテスト手法や、品質に対する考え方を深めました。 テストケース設計 コード品質の指標と管理 ④ Pythonエコシステム・技術スタック Pythonを中心とした、より実装に近い技術スタックや言語仕様を共有しました。 astral-sh/uv の活用 PyO3とmaturinによるPythonとRustの連携 Pythonコードのプロファイリング手法 最新のPython言語仕様 カラーマネジメントの基礎 ⑤ 組織論・キャリア マネージャーにも参加いただき、組織のあり方やキャリア構築についても視点を広げました。 高校野球から考える組織の進化 ～ティール組織とは～ 「量産型エンジニア」からの脱却：面接官が語る、個性を活かす採用面接の心得 成果発表会 2025年12月現在、AI開発部は13名体制となり、組織規模が拡大しました。 人数が増えるにつれ、開発業務において「お互いが何をしているのか詳細まで掴みにくい」という状態が生じがちです。 このミーティングは、開発の成果がある程度まとまった段階で、各メンバーが実務における成果を発表する場として設けました。発表者にとっては、プロジェクトの意義・目的・成果（事業貢献）を改めて言語化する機会となります。 仲間の成果を詳しく知ることは、チーム全体のモチベーションを高めるとともに、相互理解と連携の強化につながっていると感じています。 まとめ 2025年の活動を振り返ると、これらのミーティングは単なる知識のインプットにとどまらず、「論文ベースの最先端技術を、確かなエンジニアリング力で、着実に製品へ落とし込んでいく」という、AI開発部らしい文化の醸成につながりました。 今後もこのサイクルを定着させ、技術を楽しみながら、真摯にプロダクトと向き合える組織へと成長していければと思っています。

この記事は Safie Engineers' Blog! Advent Calendar 16日目の記事です。 みなさま初めまして、AI開発部の菅井です。 昨今、AI開発の現場では、単に精度の高いモデルを作るだけでなく、 「いかにしてAIをプロダクトとして使える形にするか」 というエンジニアリング力が強く求められていると感じます。 我々AI開発部においても例外ではありません。 素晴らしいモデルができても、それを動かすためのサーバー費用が莫大であれば、ビジネスとして成立しないからです。特にカメラ映像を扱う場合、データ量は膨大で、処理の遅延は許されません。 「いかに推論の実行速度を上げるか」 「どうすればクラウド（EC2）のインスタンスコストを極限まで安くできるか」 これらは、モデルのパラメータチューニングと同じくらい、私たちにとって重要な「試行錯誤」のテーマです。 今回は、gRPCを使ったAI推論サーバーにおいて実装方法によりどれくらいコスト差が生じるのかについて紹介します。 1. なぜ、gRPCの実装方法にこだわるのか？ 2. 想定ケース 3. 実装 共通：Proto定義 共通：擬似的な推論負荷 (Heavy Task) 共通：Clientの実装 ① 同期Pythonの実装 ② 非同期Pythonの実装 ③ 非同期C++の実装 4. ベンチマーク結果 測定環境 測定結果サマリ 考察 ① 同期Python vs ② 非同期Python ②同期Python vs ③非同期C++ まとめ 残された課題と今後の展望 PoCからプロダクトへ 1. なぜ、gRPCの実装方法にこだわるのか？ AI推論サーバーのコスト構造を考えた時、最も高価なリソースは「GPU」や「CPU」です。 しかし、一般的なWebサーバーの実装（同期処理）では、通信待ちやI/O待ちの間、この高価なリソースが「待ちぼうけ」をしてしまいます。 同期処理の無駄: 「データ受信待ち」の間、CPUは遊んでいる（のに課金される）。 Pythonの限界: 非同期にしても、GIL（Global Interpreter Lock）の制約で、マルチコアCPUを積んだ高価なインスタンスを使っても、1コアしか使い切れない。 これでは、いくら高性能なEC2インスタンスを契約しても、スループット（処理できるカメラ台数）は伸びず、コストばかりが膨れ上がってしまいます。 「高価なコンピュートリソースを、1ミリ秒たりとも遊ばせず、極限まで使い倒すにはどうすればいいか？」 その答えを見つけるために、今回は ①同期Python 、 ②非同期Python 、 ③非同期C++ の3パターンを実装し、それぞれのパフォーマンスとコスト効率を徹底的に比較しました。 なぜREST APIやWebSocketではなく、gRPCなのか？ 今回の「リアルタイム映像解析」において、gRPCを採用した理由は主に2点あります。 Bidirectional Streaming（双方向ストリーミング）: HTTP/1.1（REST）のような「1リクエスト1レスポンス」では、30FPSの映像を送り続ける際のオーバーヘッドが大きすぎます。gRPCなら、接続を維持したまま双方向にデータを流し続けられるため、低遅延な推論が可能です。 Schema Driven（スキーマ駆動）: PythonとC++という異なる言語間で高速に連携するためには、厳密な型定義（Protobuf）によるコード自動生成が不可欠でした。これにより、手動でのデータパース実装によるバグや性能劣化を防げます。 （※gRPC自体の基礎については、@S4nTo様から素敵な記事が投稿されておりますので、そちらも併せてご参照ください。 https://qiita.com/S4nTo/items/0ff0445542538ef49a05 ） よくある「カメラ映像を渡すから、あとの処理はAIエンジニアに任せた！」というパスに対して、我々がサーバーサイドの技術選定（エンジニアリング）でどこまで応えられるか。それはサービスの運用コストを 数分の一、あるいは十分の一 に削減できる可能性を秘めているのです。 2. 想定ケース 今回の記事で想定するシステム構成は以下の通りです。 クライアント: 多数のネットワークカメラ（またはゲートウェイ）。映像フレームを絶え間なく送信し続ける。 サーバー: AI推論サーバー（EC2インスタンス）。受け取った映像に対して物体検出を行い、BBOX（座標）などのメタデータを返す。 通信要件: プロトコル: gRPC (Bidirectional Streaming) 同時接続数: 1台のサーバーで可能な限り多く 遅延: リアルタイム性が求められるため、キュー詰まりによる遅延はNG。 この構成において、「Pythonの同期サーバー」「Pythonの非同期サーバー」、そして「C++の非同期サーバー」で実装した場合に、パフォーマンスにどれだけの差が出るのかを見ていきます。 3. 実装 共通：Proto定義 それぞれの実装パターンで用いるProtocolBufferの定義になります。 ObjectDetection というサービスが DetectStream というRPCメソッドを持つというものです。実際の画像ストリームを意識して書いていますが、今回の実装では処理自体はダミーのTaskを実行するため中身はほとんど使われません。 syntax = "proto3"; package camera_ai; // サービス定義 service ObjectDetection { // 双方向ストリーミング: // クライアントは映像フレームを送り続け、サーバーは推論結果を返し続ける rpc DetectStream (stream DetectRequest) returns (stream DetectResponse) {} } // リクエスト: カメラからの1フレーム分のデータ message DetectRequest { // 非同期処理ではリクエストとレスポンスの順序が保証されない場合や、 // クライアント側で結果をマッチングさせるためにIDが必須です。 uint64 frame_id = 1; // 画像データ (JPEG/PNG等のエンコード済みデータ、またはRawデータ) bytes image_data = 2; // 必要に応じて画像サイズなどを入れることもありますが、 // シンプルにするため今回は省いてもOKです。 // int32 width = 3; // int32 height = 4; } // レスポンス: 1フレームに対する推論結果 message DetectResponse { // リクエストの frame_id をそのまま返すことで、 // クライアントはどの画像の推論結果かを特定できます。 uint64 frame_id = 1; // 1枚の画像に複数の物体が写っているため repeated にします repeated Object objects = 2; } // 検出された個々の物体 message Object { string label = 1; // クラス名 (例: "person", "car") float confidence = 2; // 確信度 (0.0 - 1.0) BoundingBox bbox = 3; // 座標情報 } // バウンディングボックス (OpenCVのcv::Rectに合わせておくと楽です) message BoundingBox { int32 x = 1; int32 y = 2; int32 width = 3; int32 height = 4; } 共通：擬似的な推論負荷 (Heavy Task) GPU推論は非同期ですが、実際には画像の前処理（デコード・リサイズ）や後処理（NMS等）でPythonのCPUリソースが大量に消費されます。この「隠れたボトルネック」を再現するため、 sleep ではなく while ループでCPUを回します。 def heavy_inference_simulation (target_ms= 30 ): start = time.perf_counter() # 指定時間、CPUを空回しして負荷をかける while (time.perf_counter() - start) < (target_ms / 1000.0 ): pass return "Result BBOX" 共通：Clientの実装 まずはサーバーにいじめ抜くほどの負荷をかけるクライアントです。 Pythonの asyncio を使い、1台のマシンから複数のカメラ接続を擬似的に生成します。 async def main (): print (f "Starting Load Test with {NUM_CLIENTS} clients for {TEST_DURATION} seconds..." ) # クライアントタスクを全て起動 tasks = [] for i in range (NUM_CLIENTS): tasks.append(run_single_client(i)) # 全員同時にアクセスするとエラーになりやすいので、わずかに開始時間をずらす if i % 10 == 0 : await asyncio.sleep( 0.05 ) # 全タスクの完了を待つ await asyncio.gather(*tasks) ① 同期Pythonの実装 まずは比較対象となる、標準的な同期実装です。 protobufで定義された ObjectDetectionServicer.DetectStream にストリームを受けとった後の処理を書けばいいだけのシンプルな実装になります。 concurrent.futures.ThreadPoolExecutor を使い、1接続につき1スレッドを割り当てます。 特徴: 実装は一番簡単。 弱点: max_workers （スレッド数）が接続上限になる。それ以上の接続はキュー待ちになり、遅延が激増する。 class ObjectDetectionServicer (pb_grpc.ObjectDetectionServicer): def DetectStream (self, request_iterator, context): """ 双方向ストリーミングの実装。 request_iterator: クライアントから送られてくるリクエストのイテレータ """ print (f "[{time.ctime()}] New connection established." ) # クライアントから stream で送られてくるデータを1つずつ処理 for request in request_iterator: frame_id = request.frame_id img_data = request.image_data # ここに画像データ(bytes)が入る # --- ここで本来は推論を行う --- # 今回はダミーの推論時間を設ける(例: 30ms) heavy_inference_simulation(target_ms= 30 ) # ダミーの結果を作成 print (f "Sync processing frame_id: {frame_id}" ) # レスポンスを作成 response = pb.DetectResponse( frame_id=frame_id, objects=[ pb.Object( label= "person" , confidence=random.uniform( 0.8 , 0.99 ), bbox=pb.BoundingBox(x= 100 , y= 100 , width= 50 , height= 200 ) ) ] ) # 結果を返す yield response ② 非同期Pythonの実装 次に、 asyncio 版です。非同期版もPythonでは簡単に実装することができます。 ObjectDetectionServicer.DetectStream にasyncをつけて非同期に対応させる形になります。 推論部分を run_in_executor でスレッドプールに逃がし、イベントループを止めないように工夫します。 特徴: 接続自体は大量にさばける（C10k対応）。 現実: Pythonの GIL (Global Interpreter Lock) の制約により、複数のスレッドで計算しようとしても、同時に動けるCPUコアは実質1つだけ。CPUバウンドな処理（前処理等）が重なると詰まる。 class ObjectDetectionServicer (object_detection_pb2_grpc.ObjectDetectionServicer): async def DetectStream (self, request_iterator, context): loop = asyncio.get_running_loop() async for request in request_iterator: # 【工夫】重い処理を別スレッドに逃がして、イベントループを守る # しかし、Pythonコードである以上、GILの呪縛からは逃れられない... await loop.run_in_executor( None , heavy_inference_simulation, 30 ) yield object_detection_pb2.DetectResponse(...) ③ 非同期C++の実装 最後に、今回の主役であるC++実装です。 Pythonとは異なり、 CallDataやCompletionQueue について 理解する必要があるため、実装方法は少し複雑になります。 CallDataクラス Clientとの1つ接続ごとの状態とデータをを管理するクラスになります。 非同期処理では、処理がいったん中断されてスレッドが別の仕事に移るため、「関数のローカル変数」にデータを残しておくことができません。そのため、以下の情報をヒープメモリ上のオブジェクト（CallData）として保持し続けます コンテキスト: ServerContext 、 Request 、 Response などのデータ実体。 ステート（状態）: 現在その接続が「接続待ち」なのか、「受信中」なのか、「送信中」なのかを示す状態遷移（ステートマシン）。 ロジック: イベントを受け取った際に実行すべき処理内容（ Proceed メソッド）。 CompletionQueueクラス CompletionQueue は、gRPCライブラリ内部（カーネルやネットワーク層）と、アプリケーション（ユーザーコード）をつなぐ 連絡通路のようなものです。 非同期で行われた操作（データの読み込み、書き込み、接続確立など）が完了した際、その通知（イベント）がすべてこのキューに格納されます。 完全にスレッドセーフであり、複数のスレッドから同時にアクセスしても安全に動作するように設計されています。 ワーカースレッドは、このキューに対して Next() メソッドを呼び出し、「何か完了した仕事はないか？」と問い合わせます。イベントがあれば即座に取り出し、なければイベントが来るまで待機（ブロック）します。 CallDataクラスの実装例 class CallData { public : CallData (ObjectDetection::AsyncService* service, ServerCompletionQueue* cq) : service_ (service), cq_ (cq), stream_ (&ctx_), status_ (CREATE) { // インスタンス生成と同時に「接続待ち」状態に入る Proceed (); } void Proceed () { if (status_ == CREATE) { // 1. CREATE状態: // gRPCシステムに対して「次の接続要求が来たら、このCallDataを使ってね」と依頼する。 // タグとして `this` (自分自身のポインタ) を渡すのが定石。 status_ = PROCESS; service_-> RequestDetectStream (&ctx_, &stream_, cq_, cq_, this ); } else if (status_ == PROCESS) { // 2. PROCESS状態 (初期接続完了): // 新しい接続が確立された瞬間にここに来る。 // 重要: 次のクライアントのために、新しい CallData を即座に作って待機させる(Factoryパターン) new CallData (service_, cq_); // 最初の読み込みを開始する // 読み込みが終わったら、また `this` (自分) が呼ばれるようにタグ付けする status_ = READING; stream_. Read (&request_, this ); } else if (status_ == READING) { // 3. READING状態 (Read完了): // クライアントから request_ にデータが入った状態でここに来る。 // --- 推論処理 (Mock) --- // request_.image_data() を cv::Mat に変換したりする場所 HeavyInferenceSimulation ( 5 ); // 5msの重い処理をシミュレート response_. set_frame_id (request_. frame_id ()); auto * obj = response_. add_objects (); // objに結果をセットする // 結果を書き込む status_ = WRITING; stream_. Write (response_, this ); } else if (status_ == WRITING) { // 4. WRITING状態 (Write完了): // クライアントへの送信完了後にここに来る。 std :: cout << "Processed frame_id: " << response_. frame_id () << std :: endl ; // レスポンスをクリアして次のデータを読む response_. Clear (); status_ = READING; stream_. Read (&request_, this ); } else { // FINISH状態 assert (status_ == FINISH); delete this ; // 自分の役目は終わったので自決する } } // クライアント切断時などの後処理用 void Finish () { status_ = FINISH; stream_. Finish (Status::OK, this ); } // 外部からアクセスするタグ用のアクセサ // 処理が成功したか(ok)によって挙動を変える制御が必要 void OnEvent ( bool ok) { if (!ok) { std :: cout << "Client disconnected or finished reading/writing." << std :: endl ; Finish (); return ; } Proceed (); } ワーカースレッドの立ち上げとCompletionQueueの呼び出し例 // サーバーのメインクラス class ServerImpl { public : ~ ServerImpl () { server_-> Shutdown (); cq_-> Shutdown (); } void Run () { std :: string server_address ( "0.0.0.0:50051" ); ServerBuilder builder; builder. AddListeningPort (server_address, grpc:: InsecureServerCredentials ()); builder. RegisterService (&service_); // CompletionQueue (イベントキュー) の作成 cq_ = builder. AddCompletionQueue (); server_ = builder. BuildAndStart (); std :: cout << "Server listening on " << server_address << std :: endl ; // 最初の1つ目の CallData を投入して待ち受け開始 new CallData (&service_, cq_. get ()); // イベントループ void * tag; // イベントに紐付いたタグ (CallDataのポインタが入る) bool ok; std :: vector < std :: thread > threads; int thread_count = 15 ; // サーバーのCPUコア数に合わせるのが一般的 for ( int i = 0 ; i < thread_count; i++) { threads. emplace_back ([ this , i](){ std :: cout << "Worker Thread " << i << " started." << std :: endl ; void * tag; bool ok; // 複数のスレッドが、同じ cq_ (キュー) を同時に監視する。 // gRPCのCompletionQueueはスレッドセーフなので、競合は内部で解決してくれる。 while (cq_-> Next (&tag, &ok)) { // 空いているスレッドがイベントを拾って処理を実行 static_cast <CallData*>(tag)-> OnEvent (ok); } }); } // 全スレッドの終了を待つ（実際はCtrl+Cされるまで帰ってこない） for ( auto & t : threads) { if (t. joinable ()) t. join (); } } 今回の実装のイメージを以下に図示しています。 C++実装のイメージ Clientが DetectStream を呼び出すと ComletionQueue にイベント通知がされ、空いているWorker Threadが CallData を呼び出します。 CallData は Proceed により自身の状態をみながら処理を進めます。画像を渡されているのであれば、推論を実施して結果を Clinet に返します。 重要なポイントはCompletion Queueがスレッドセーフであり、各スレッドをまたいで使われている点であり、この仕組みが非同期実行を実現しているといえます。 各Worker Threadは空いている順からイベント通知のあった CallData を処理していきます。そのため、 CallData 1 が Worker Thread 1 で呼ばれることがあれば、 Worker Thread N で呼ばれることもあります。同期処理と異なるのは、このようにスレッドが特定のClientのストリームを占有せずに、各Worker Threadが協力して多くのClientのストリームを処理することにあります。 4. ベンチマーク結果 実際にそれぞれの実装方法でどれくらいの差が出るのかを確認していきます。 測定環境 項目 内容 マシン Intel(R) Core(TM) Ultra 7 155H (1.40 GHz)　16コア Python 3.10.18 CXX 17 推論負荷 5ms間のループ処理 クライアント 30台 ストリーム時間 10秒 ストリームFPS 10 測定結果サマリ 各々がRequestを受け取りResponseを返すまでの時間を計測した結果が以下になります。 実装パターン 平均時間 (Avg) 最速 (Min) 最遅 (Max) 評価 ① 同期 Python 63823.44ms 25.03ms 127814.19ms ❌ 破綻 ② 非同期 Python 45678.62ms 15.19ms 90461.10ms ❌ 破綻 ③ 非同期 C++ 13.157ms 5.611ms 71.566ms 🏆 成立 10FPSを遅延なく処理するためには 最遅Max が100ms以下である必要があります。 ③非同期 C++ は上記の条件を満たすので本マシンで 30台のクライアント をさばくことができることがわかります。 Client数のみを変えていき、 最遅Max を観測した結果を以下のグラフにしました。 処理時間(Max)の比較 ①同期Python 、 ②非同期Python が 1 00msを下回るClient数は2までなので、本マシンで 2台のクライアント しかさばけないことがわかります。 実装方法によってコストに 15倍の差 がでるという結果になりました。 考察 ① 同期Python vs ② 非同期Python 同じPython、同じGILの制約下にありながら、同期版だけが Max 127秒 （非同期版より30秒以上悪化）という遅延を記録しました。 その決定的な差は、 「スレッドを占有する時間の長さ」 にあります。 1. 20個の椅子と30人の客 今回のサーバー（16コア）では、Pythonのデフォルト設定により 約20個のスレッド が稼働していました。 ここに 30台のカメラ が同時に接続すると、何が起きるでしょうか。 2. 同期版の敗因：接続＝占有 同期実装では、「ストリーミング中の10秒間、スレッドをずっと占有」します。 開始直後: 20台がつながった瞬間、全スレッドが埋まります。 待ちぼうけ: 残り10台は、前の人の配信（10秒）が終わるまで、 接続することすら許されず待機 させられます。 結果: 「待ち時間10秒」＋「処理時間」が確定し、遅延が跳ね上がりました。 3. 非同期版の勝因：計算＝占有 非同期実装では、スレッドを占有するのは「推論している一瞬（5ms）」だけです。 高回転: 5msで席を立つため、20個のスレッドで30台を次々とさばくことができます。 結果: 「入り口での門前払い」が起きず、少なくとも接続とデータ受信はスムーズに行われました。 ②同期Python vs ③非同期C++ 続いて、同じ「非同期アーキテクチャ」を採用している両者の比較です。結果は、C++がPythonを 1200倍以上 の速度差で圧倒しました。 両者とも「スレッドプール」を使って計算を並列化しようとしています。しかし、実際のCPUコアの使われ方は対照的です。 Pythonの限界 (GIL): コード上でスレッドを15個立てても、Pythonの GIL (Global Interpreter Lock) の制約により、同時にPythonコードを実行できるのは 常に1スレッドだけ です。 15車線の高速道路があるのに、 工事規制で「たった1車線」しか通行できない 状態と同じです。30台のカメラから来るデータが、この細い1車線に殺到したため、大渋滞（90秒の遅延）が発生しました。 C++の真価 : GILが存在しません。15個のスレッドが、 15個のCPUコアすべてを同時に使用 して計算します。 15車線をフルに使って車がビュンビュン流れるため、30台程度の交通量では渋滞など起きようがありません。 まとめ 本記事では、同期・非同期のアーキテクチャの違い、そしてPython・C++という言語特性の違いが、システムのパフォーマンスにどれほど差をもたらすかを検証しました。 実験の結果、同じハードウェアを使っていても、実装方法を変えるだけで 「1台のサーバーに収容できるカメラ台数」が15倍以上変わり得る ことが確認できました。これは、クラウドインフラ費用が1/15になる可能性を示唆しており、エンジニアリングの工夫が事業の収益性に直結することを証明しています。 残された課題と今後の展望 今回は「非同期C++の可能性」にフォーカスしましたが、検証しきれていないテーマも残されています。 Python MultiProcessing: PythonのGILという障害は、マルチプロセス化によって回避する手段が存在します。メモリ消費量とのトレードオフにはなりますが、Pythonの生産性を維持しつつ性能を上げるアプローチとして検証の価値があります。 同期C++との比較: 「C++だから速い」のか「非同期だから速い」のかをより厳密に切り分けるため、同期C++実装との比較も興味深いテーマです。 これらを含めたさらなる検証は、次回の記事でお届けできればと思います。 PoCからプロダクトへ 実際のプロダクト開発は、今回のようなCPUループ処理よりも遥かに複雑です。 映像のデコード、リサイズなどの前処理、そしてGPUを用いた推論処理。これらを遅延なくパイプライン化するために、 NVIDIA DeepStream のような特化したツールキットを活用して、さらなる効率化を目指す道もあります。 しかし、どのような手段を選ぶにせよ、本質は変わりません。 AI開発者がモデルの精度だけでなく、 「実行速度」や「運用コスト」を意識した設計 を行うこと。 そのエンジニアリングへの意識こそが、AIを単なるPoC（概念実証）で終わらせず、持続可能なビジネス価値を生む「プロダクト」へと昇華させる鍵になるのです。

この記事は  Safie Engineers' Blog! Advent Calendar  の15日目の記事です。 はじめに こんにちは、セーフィー でサーバーサイドエンジニアをしている金成といいます。 今回は AWS ECS Blue/Greenデプロイをサービスに導入してみたので、そちらについて共有させてください。 AWS ECS Blue/Green デプロイは今年になって有効化された機能で、今迄は ECS ではローリングリリースのみ、Blue/Green デプロイをやる場合は CodeDeployを使う必要がありました。 今回の機能追加で、ECSのサービス設定の変更と関連リソースを追加することで、ECSの設定のみで Blue/Greenデプロイができるようになりました。 今回、我々のチームで運用しているサーバーについて、適用してみました。 はじめに 背景とモチベーション リリースの手法 ローリングリリース Blue/Green デプロイ B/G デプロイのフロー ECS における B/G デプロイの選択肢 Lifecycle Hooks によるリリース安全性向上 制限事項とハマりポイント 1. B/G → ローリングへの切り替え時 2. ALBリスナールールの制限 現状の課題と今後の展望 おわりに 背景とモチベーション 現在、我々のチームでは、認証サーバーの運用をしています。 こちらは多くのサービスで利用されるため、リリースの際の障害のリスクを最小限に抑えることが課題でした。 特に、環境差分に起因する障害や考慮漏れなどはstaging環境でのチェックから漏れやすく、サービスの安定性を脅かすリスクとなっていました これらの課題を解決するため、我々は既存のデプロイ手法を見直し、より安全性の高いリリースプロセスへと改善を図ることにし、新たに導入された Blue/Green デプロイを利用することにしました。 リリースの手法 ローリングリリース 現在、ECSのデフォルトでよく採用されているのは ローリングリリース です。 一部のサーバーから新しいバージョンを段階的に適用していくデプロイ方法です。サービスを停止せずにデプロイすることができます。 Blue/Green デプロイと比べるとロールバックに時間がかかり、一時的に新旧サーバーが混在するデメリットはありますが、インフラの構成自体はシンプルで管理しやすいです。 Blue/Green デプロイ Blue(旧環境)と Green(新環境) を作成し、トラフィックを切り替えることでデプロイする手法で Blue環境は落とさずに、一定時間残すため、問題発生時のダウンタイムが少なくなります。ローリングデプロイの切り替えにはタスクの起動を待つ必要がありますが、トラフィックの切り替えで済むため、早くロールバックができます。一方、インフラの構成が増え、デプロイの複雑さは増します。また、管理するリソースが増えます。 認証サーバーのようにサービスレベルが高い、リスクを最小にしたい場合には、ロールバックを早く確実に実現できる Blue/Green デプロイは有効な選択肢になると思います。 B/G デプロイのフロー B/G デプロイは、以下の手順で進みます。問題発生時の 切り戻しポイントが明確 で、手順5〜6の間であれば、即座にBlue環境（旧環境）にトラフィックを戻すことが可能です。 初期状態 : Blue環境 (旧バージョン) にトラフィックが流れている。 Green環境 (新バージョン) を構築。 テスト用トラフィックをGreen環境に流し、 動作検証 を実施。 本番トラフィックをGreen環境へ一部または全体に 段階的に移行 。 トラフィックがGreen環境に 100%切り替え 。 一定期間の監視後、Blue環境を 停止 。 出典: Amazon ECS blue/green service deployments workflow Webページ https://docs.aws.amazon.com/AmazonECS/latest/developerguide/blue-green-deployment-how-it-works.html (2025年12月9日アクセス) ECS における B/G デプロイの選択肢 AWSでは、ECS環境でB/Gデプロイを実現する方法として、以下の2種類が提供されています。 CodeDeploy を使う （従来の方式） ECS B/G デプロイを使う （ECS サービス設定に統合された新しい方式） 比較項目 CodeDeploy 連携 ECS B/G デプロイ (NEW) トラフィック移行 豊富 (Canary, Linear, AllAtOnceなど比率を自由に設定可能) 現状は AllAtOnce のみ 。 設定管理 CodeDeploy側で設定。 ECSサービス定義に統合され、 管理がまとまる 。 戦略切り替え 複雑。 ローリング ↔ B/G の変更がサポート されており比較的楽。 検証フック Lifecycle Hooks (固定タイムアウト) Lifecycle Hooks (柔軟なタイムアウト設定が可能) 我々は、 設定管理の容易さ と、将来的な ローリングリリースへの切り戻しの容易さ を評価し、 ECS B/G デプロイ を選択しました。 Lifecycle Hooks によるリリース安全性向上 ECS B/G デプロイおよび CodeDeployには、 Lifecycle Hooks という非常に重要な機能があります。 これはデプロイの特定のステージ（例: トラフィック切り替え前）で、カスタムの 検証ステップ（AWS Lambda）を実行し、その検証が成功するまでデプロイの進行をブロックできる機能です。 フックの利用イメージ: 新しいGreen環境にトラフィックが流れる前に、Health Checkや簡単なSmoke Test用のLambdaを実行し、環境起因の設定ミスがないかを自動的に検証できます。 これにより、トラフィックを本番環境に切り替える前に、設定ミスなどによる障害リスクを大幅に低減し、より安全 にデプロイを進めることが可能になります。 Safieでは、簡単なSmoke Test用のLambdaを本番トラフィック切り替え前に実行し、チェックした上でデプロイできるように変更しました。 制限事項とハマりポイント 導入にあたり、いくつかの注意点と制限事項に直面しました。 1. B/G → ローリングへの切り替え時 B/Gデプロイ設定を解除しローリングに戻した直後のデプロイで、内部的にB/Gデプロイの設定（例: ロール）を参照し続けることがありました。この影響で、新規デプロイができなくなる事態が発生しました。（1敗） => 不必要なIAMロールの削除は慎重に行う 必要があります。 2. ALBリスナールールの制限 ALBの設定で、リスナールール数の上限があります（アカウントやリージョンにより異なる可能性あり）。B/Gデプロイではトラフィック切り替えにリスナールールを利用するため、多くのリスナールールを使用している既存のALBでは、B/Gデプロイの導入が難しい場合があります。 現状の課題と今後の展望 ローリングリリースから Blue/Greenデプロイに切り替えることで、素早いロールバック、デプロイ前の検証ができるようになりました。 ただし、検証はごく簡単なもので、特定のユースケースの考慮漏れをカバーできず、選択できるデプロイ戦略にも制限があります (例えば, CodeDeployと違いカナリアリリースはできない)*1 今後の展望として、E2E/統合テストとの組み合わせや、AWS ECS 今後の機能追加に合わせてより柔軟なデプロイができるように検討をすすめる予定です。 もし、似た課題をもつ方がいれば、導入を検討してみてはいかがでしょうか？ おわりに 最後になりますが、セーフィーではエンジニアを積極的に募集しています。気になる方はこちらをご覧ください！ https://safie.co.jp/teams/engineering/ カジュアル面談から受け付けておりますので、気軽に応募いただければと思います！ 最後までお読みいただき、ありがとうございました。 *1 2025/10/30 ~ で AWS ECS は リニアデプロイ と カナリアデプロイのサポートを開始してます ( https://aws.amazon.com/jp/about-aws/whats-new/2025/10/amazon-ecs-built-in-linear-canary-deployments/ )

この記事は Safie Engineers' Blog! Advent Calendar  14日目の記事です はじめに はじめまして！エンジニアリングオフィスの山崎麻衣子（ @ymzaki_m4 ）と申します。 セーフィーには2025年3月に入社し、開発本部の組織開発全般に携わっています。 （エンジニアリングオフィスのお仕事については、昨年の記事も良ければご覧ください！） engineers.safie.link 今回は、私がこれまで取り組んだ 「組織の横連携強化」 に関する施策についてご紹介します。 組織の拡大によって生じ始めた課題と、その解消に向けた最初の一歩。組織マネジメントで同じような悩みを抱える方の、何かちょっとしたきっかけになれば幸いです。 はじめに 強力な組織の実現へ：課題を探る 本質的な課題を特定：浮き彫りになった2つの壁 「横のつながり」を生む：GL横断ミーティングの実行と設計 組織変革の第一歩と、次の目標 おわりに 強力な組織の実現へ：課題を探る 開発本部の今年度（FY25）の目標の1つとして、 「強力な組織」の実現 が掲げられていました。 セーフィーのさらなる事業成長を促進するためには、将来の成長を実現しうる仕込みや組織体制の整備を進める必要がありました。 そのためには、現状の成長速度に満足せず、組織文化の醸成、個人の成長支援、情報連携強化など、多面的な成長を強力に推し進めることが重要となります。 こうした状況下で入社した私がはじめに取り組んだことは、開発本部の部室長、グループリーダー（GL）との1on1で、 組織の現状を多角的に把握 することでした。 約3週間かけて計25名の部室長やGLに対してヒアリングを実施しました。 現在の組織の取り組みや課題などについて、採用、オンボーディング、育成、評価、文化醸成、開発プロセスなどの幅広い切り口でお伺いしました。 業務の合間を縫って快く応じてくださり、みなさんが抱いている想いや組織の現状を把握することができました。（ありがとうございました！） 本質的な課題を特定：浮き彫りになった2つの壁 ヒアリング内容は 構造化・抽象化 し、開発本部全体の本質的な課題を特定しました。 これらの課題を基に、解決のための道筋を考え、直近で実施すべき具体的な施策を策定しました。 まず、組織として課題感が大きいものを以下の4つのテーマに分類しました。 組織運営の基盤強化 人材育成・成長の仕組み化 業務効率と生産性向上 組織文化と帰属意識の醸成 さらに、短期・中長期に分類し、課題の関連性と施策の優先順位を探っていきました。 その結果、直近で取り組むべき課題が以下の2つであると特定するに至りました。 組織の明確な方向性・ビジョンが不足している 役割や権限が不明確で、横のつながりが薄い これらの2つの課題を解決していくにあたり、まずは「既存のリソースを活用してすぐに実施可能で、直接的に効果が見込めるもの」に取り組み、着実に成果へとつなげていきます。一方で、「根本的解決に時間を要し、新たな仕組みや文化の醸成が必要なもの」についてはバックキャスティングで計画を策定し、この両輪で課題解決を推進します。 そこで、まず着手したのが 「GLの横連携強化」 でした。 GLという組織の中核を担う存在が積極的に連携することで、組織の一体感を醸成し、グループを超えて成果や付加価値を創出し続けられる組織を目指したいと考えました。 また、GLの半数以上から共通課題として挙げられたのが「GL役割と権限の定義の曖昧さ」や「部門・チーム間の情報共有と連携の弱さ」であり、これらが組織の方向性の不明確さや横のつながりの希薄さにつながっているとも考えられました。 この短期的な基盤強化が、長期的な成長のための「土台」を固める上で必要だったのです。 開発本部FY25下期キックオフ（2025年7月開催）での説明資料より（一部改変） 「横のつながり」を生む：GL横断ミーティングの実行と設計 「GLの横連携強化」を進めるために、 「GL横断ミーティング」 の定期開催を企画しました。 この会議は「組織の中核を担うGLが、自身のチームを超えて組織全体を理解し、相互に協力しながら、より良い組織を共に創っていくための、 主体的な場 」と定義し、GLの中で有志を募って始めることとしました。 企画の検討にあたって特に意識した点は以下の4点です。 一方的な情報提供ではなく、双方向の対話やワークを中心とした設計にする 毎月の開発本部会で実施内容を全体共有することで、活動の透明性を高める 各回でテーマを明確に定め、明日からの活動につながるアウトプットを意識する アウトプットや実施後アンケートを踏まえ、会議自体の改善を繰り返す また、目指す状態とそのためのステップを意識しながら、段階的なロードマップを設定しました。 会議は8月から開始し、月1回以上の頻度で継続的に開催しました。 はじめは「相互理解と安心できる場の醸成」をテーマに、参加者同士の交流を重視しました。回を重ねるごとに「実践と改善のサイクル」を重視し、具体的な現場の課題解決のための議論や、マネジメントスキル向上を意識した学習を取り入れ、組織への貢献を視野に入れていきました。 11月末までで全6回開催しましたが、当初からGLのみなさんが意欲的に参加してくださり、会議への満足度が高い状態が維持できています。（ありがとうございます！！） また、要望も踏まえて会議の運営やコンテンツを調整することで、マネジメントスキル向上などへの貢献度も高められていることをアンケート結果を通じて感じることができました。 組織変革の第一歩と、次の目標 「GL横断ミーティング」は、GL同士が 部門やチームを超えて課題を共有し支え合う ための「横のつながり」を強化し、 ラインマネジメント能力の向上 という成果も出始めていると感じています。 今後はさらに、長期施策として 「組織ビジョンの策定と言語化」 を進めたいと考えています。 「実行力と創造力を兼ね備え、事業成長に必要な変化に迅速に対応できる組織」を目指し、その想いを言語化して社内外に示すことで、想いに共感したメンバーが集まる「異才一体」な強い組織となり、さらなる事業成長に貢献できるように取り組んでいきます！ また、これまでの取り組みを通じて、セーフィーは 自ら考え、判断し、行動することで、自律的に価値を創造する メンバーのスタンスを大切にしてくれると強く感じることができました。 これからも組織課題に真摯に向き合い、改善プロセスを継続的に推進していきます。 おわりに 本記事では、私が取り組んだ組織変革の第一歩についてご紹介しました。 まだ道半ばでやりたいことも数多くあるので、いつか別の機会にご紹介できればと思います。 ついでに宣伝です！セーフィーでは 一緒に働く仲間を募集中 です！ 少しでもご興味を持っていただけたら、ぜひ以下の採用サイトを覗いてみてください。 safie.co.jp 最後まで読んでいただき、ありがとうございました。

この記事は セーフィー株式会社 Advent Calendar 2025 の13日目の記事です！🎄 はじめに こんにちは！ セーフィー株式会社 基幹システム開発部 戦略グループの佐々木です。 約１年前、セーフィーの中途採用の選考を受けようとしていた私は途方に暮れていました・・・ なぜなら 「セーフィーの基幹システム開発部とはなにか」 についての情報が、募集要項以外にほぼ見つけられなかったからです。 過去の私と同じように「基幹システム開発部に興味はあるけど、情報が全然見当たらないな・・」とお困りのみなさんへ、セーフィーの基幹システム開発部についてご紹介したいと思います！ はじめに セーフィーにおける「基幹システム」 基幹システム開発部について 基幹システム開発部ってどんな雰囲気？ おわりに セーフィーにおける「基幹システム」 みなさんは「基幹システム」と聞いてどんなシステムを思い浮かべるでしょうか？ セーフィーにおいて、基幹システムは 「企業活動に必要不可欠な最小限の業務を取り扱うシステム」 と定義されています。 と言われても、ちょっとイメージがわきにくいですよね。 セーフィーは、クラウド録画サービスというSaaSビジネスを展開しつつ、カメラデバイスなどの「モノ（ハードウェア）」も取り扱っている点が特徴です。 そのため「企業活動に必要不可欠な最小限の業務」として、以下のような領域を定義しています。 「モノ」を管理する領域：SCM、サービス/製品保証管理 「サブスクリプション」を管理する領域：契約管理 「モノ」「サブスク」から請求を管理する領域：請求管理 営業活動を支える領域：SFA/CRM 企業活動の根幹を支える領域：会計管理、組織管理、データ分析/活用 では、これらの領域について、それぞれどのようなシステムを利用しているのでしょうか？ 利用システムを領域ごとにグルーピングすると以下のような形となります。 このように様々なシステムを組み合わせながら、日々の業務、ひいては顧客のセーフィー利用を支えているのが、セーフィーにおける「基幹システム」です。 基幹システムについては過去のテックブログでも紹介していますので、興味を持たれた方はぜひこちらもご覧ください。 「モノ」×「サブスク」業務システム紹介！ 基幹システム開発部について ここまでご紹介してきた基幹システムのうち、CRMシステム群、契約・請求・会計管理システム群を管理しているのが「基幹システム開発部」です。 （注：データ分析基盤はデータドリブン推進室が担当しており、そちらも過去記事で紹介されています。 What is データ分析基盤 ） 基幹システム開発部のMissionは 「持続可能で柔軟な基幹システムを提供し、企業の成長と経営効率化を支える」 であり、セーフィーのさらなる成長を支えるための基盤づくりに取り組んでいます。 基幹システム開発部は以下の3グループで構成されています。 開発第１グループ 開発第２グループ 戦略グループ それぞれのグループの役割は以下の通りです。 開発第１グループ 主にSalesforceに関する開発・保守を担当しています。 セーフィーではSalesforceを幅広い領域で活用しており、営業からカスタマーサポートまで、様々な部署の業務を支える大切な基盤となっています。 開発第１グループでは、社内の要望を元に開発・リリースを行っているほか、現在はSCM業務の改善を目的とした「山桜プロジェクト」（製品・在庫管理システムの強化）に内製で取り組んでおり、社内ユーザーであるCS本部のメンバーと密に連携しながら開発を進めています。 ユーザー部門と一体となってのプロジェクト運営は、セーフィーの基幹システム開発における大きな醍醐味のひとつです。 開発第２グループ 主にECサイトやZuora、請求書管理ロボに関する開発・保守を担当しています。 契約管理・請求管理という顧客影響が大きいシステムも担当しており、日々のデータの整合性確認、月次決済の確認といった重要な業務も多く担当しています。 ベトナム子会社の業務システム開発やECサイトの保守など、幅広い領域のプロジェクトを担当する開発第２グループですが、2026年からは会計領域へのSAP導入を行う「欅プロジェクト」も本格スタートし、セーフィーの成長を支えるための大きなプロジェクトが今後数年続く見込みです。 戦略グループ 主に基幹システム全体の戦略企画や、開発プロジェクトにおけるプロジェクトマネージャー（PM）としての役割を担当しています。 前述の山桜プロジェクト・欅プロジェクトのPMや、子会社の業務システム構築プロジェクトのPM、代理店向け自社開発システムのプロダクトマネージャー（PdM）といった形で、各メンバーがそれぞれのプロジェクトの推進役を担っており、部門横断的な課題の解決をリードしています。 基幹システム開発部ってどんな雰囲気？ 私が入社後すぐに感じたのは、「落ち着いたおだやかな人が多い」雰囲気でした。 一方で、システムに関する議論ではそれぞれのバックグラウンドを基に様々な意見が飛び交い、よりよい基幹システム構築に向けた熱い思いを日々感じています。 また、育児中のメンバーも多く、裁量労働制をいかして柔軟に子育てと両立しているメンバーも多いです。 プロジェクト単位での活動が多い基幹システム開発部ですが、隔週で開催されている「基幹システム開発部会」では、全員が一言話す「チェックイン」が冒頭に設けられており、「子供の時の夏休みの思い出」「老後の夢、生き方」「便利なフリーソフト」など多岐にわたるテーマを元にお互いの人となりを知る良い機会となっています。 ボルダリング部に参加しているメンバーの報告や、お子さんとのトカゲの飼育エピソード、育休明けのパパメンバーと赤ちゃんの登場など、「異才一体」のセーフィーらしく、いろいろなジャンルのエピソードが飛び出す笑いが絶えない時間で、私も毎回とても楽しみにしています。 おわりに 基幹システム開発部についてのご紹介はいかがでしたでしょうか？ この記事を読んだ皆さんの基幹システム開発部への解像度が少しでも上がっていたらうれしいです。 セーフィーのさらなる成長を支えるため、基幹システムは今まさに進化の時を迎えています・・・！ さらなる成長を見据える 今のセーフィー「だからこそ」味わえるダイナミックな基幹システム再構築 に、あなたも一緒に取り組んでみませんか？ 基幹システム開発部では、一緒に働いていただける仲間を絶賛募集中です！ 興味を持っていただけた方は、ぜひ採用サイトもご覧ください。 safie.co.jp

この記事は Safie Engineers' Blog! Advent Calendar 12日目の記事です。 はじめに そのテストコード、まだ全部「手」で書いていますか？ 今はどんな生成AIを使っているのか？ なぜ「全自動」ではないのか？ 実践！Claude Codeを使ったテスト半自動化4ステップ このワークフローがもたらした、時間以上の「価値」 おわりに：AIとの協業が当たり前になる未来へ はじめに こんにちは！セーフィー株式会社でサーバーサイドエンジニアをしている坂上( @Bobtaroh )です。新卒2年目となり、私を含め同期のエンジニアたちも、それぞれの配属先で一生懸命に業務をこなしています。 本記事では、同じく新卒2年目であるフロントエンド開発を担当している東條さんにインタビューを行い、開発現場で話題の「Claude Code」を活用した テスト半自動化のワークフロー について紹介します。 「AIに全部任せる」のではなく、あえて「半自動化」を選ぶその理由と、具体的な実践手法について深掘りしました。 そのテストコード、まだ全部「手」で書いていますか？ テストコードは、アプリケーションの品質担保に不可欠ですが、その実装は時としてエンジニアの負担になることもあります。セーフィーのフロント開発チームでは、特に以下の課題がありました。 大規模なデザインシステム移行をやっていて、工数見積もり上、テストを後回しにしていた テストを実装する箇所多かった 配属されてから開発したコンポーネントが40~50ほどあり、1コンポーネントあたり1000行ほどのテストが必要だった テストの中には、作業に近い単純な実装が多く存在し、エンジニアのモチベーションがあまり上がりづらい側面も少々あった これらの課題を抱えていた時に、世間ではCoding Agentが注目を集め始め、弊社でも社内ツールとしてGeminiやClaude Codeの利用環境が整備されました。それを機に、今回のテストの半自動化ワークフローを組むことに至ったとのことでした。 今はどんな生成AIを使っているのか？ 昨今、Claude Code以外のさまざまな生成AIが登場していますが、以下の4つの生成AIに関して、どのように使い分けているのか、東條さんに聞いてみました。 Gemini 相棒的な存在 Gemini単体でタスクをお願いすることはなく、調べるためのツールとして使うことが多い 会議中に出てきた分からないことについても聞くことがよくある Claude Code 部下に近い存在 以下の仕事を投げている テストの実装 新規開発の雛形作成 複雑な実装の解説依頼 Github Copilot 以前使っていたが、今は完全に使用していない Bedrock Chat Geminiが導入される前までは主流だったが、今は使用していない 2025年12月現在では、主にGeminiとClaude Codeを使用しているとのことでした。 なぜ「全自動」ではないのか？ 現在のテスト半自動化に至るまでには様々な試行錯誤がありました。 弊社でClaude Codeが利用可能になる前までは、Github Copilot Agentを使って、One-shotのプロンプトでテストを生成させる手法を試みました。しかし、プロジェクト固有のルールが守られなかったり、意図しないコードが生成されたりと、結果として出力の6〜7割を人間が書き直すことになっていました。 Claude Codeが利用可能になった当初では、劇的な変化はありませんでした。Github CopilotでSonnet 4モデルを使用することができていたため、Github Copilotで培った仕組みをそのまま流用していたとのことです。hooksやmemoryの分散化の利用を試みましたが、管理が難しく、チーム開発になかなか向かないということがわかりました。 現在では、Subagentsを用いて、設計、実装、スタイルレビューと統合の4つに工程を分けることで、半自動化まで進めることができたとのことです。 実践！Claude Codeを使ったテスト半自動化4ステップ Claude Codeを使った半自動化の詳細説明をします。 この半自動化では、主に Subagents の機能を使っています。Subagentsとは、メインの会話に左右されずに特定のコンテキストを保持し、適切な権限のものと、特定の領域に特化して精度を向上させることができる再利用可能なエージェントのことです。公式サイト( https://code.claude.com/docs/ja/sub-agents )では、以下の4つの利点が挙げられています。 コンテキストの保持 特化した専門知識 再利用性 柔軟な権限 この機能とClaude Codeのファイル仕様に従って、以下のファイル構成で実現しています。 .claude ├── agents # Agentの定義が詰まったディレクトリ │ ├── consolidate-text-fixes.md │ ├── generate-test-spec.md │ ├── implement-test.md │ ├── investigate-test-pattern.md │ ├── review-test-first.md │ ├── review-test-second.md │ ├── review-test-third.md │ └── search-translation-key.md └── commands # ワークフロー(コマンド)を実行させる定義が詰まったディレクトリ └── test-workflow.md commandsディレクトリで定義したワークフロー(test-worklow.md)では、以下のような構成になっています。 🔽実際のtest-workflow.mdの中身を見る。(ここをクリック！) --- name: test-workflow description: テスト設計・実装・レビューの一連のワークフロー --- # テスト実装ワークフロー管理エージェント このエージェントは、テストの設計から実装、レビューまでの一連のワークフローを管理します。**各フェーズで適切なサブエージェントを呼び出し**、高品質なテストコードを作成します。 ## ワークフロー概要 1. **テスト設計** → 2. **テスト実装** → 3A. **並列テストレビュー** → 3B. **統合修正・最終調整** → 4. **最終確認** テスト設計後にユーザーレビューを求め、ユーザーの修正後承認を得てからテスト実装以降のフェーズに進みます。 ## 実行手順 ### Phase 1: テスト設計 📝 **使用エージェント**: `generate-test-spec` 1. 対象ファイルを分析 2. テスト設計書を作成（`<fileName>テスト設計書.md`） 3. **ユーザーに設計書のレビュー・修正を依頼** 4. 承認を得たら次フェーズへ ### Phase 2: テスト実装 💻 **使用エージェント**: `implement-test` 1. テスト設計書を基にテストコードを実装 2. テストを実行してカバレッジ確認 3. エラーがある場合は修正（最大3回試行） ### Phase 3A: 並列テストレビュー 🔍 3つのテストレビューエージェントを**並列実行**して、その結果を結合した問題の分析と改善方針を1つ作成します： #### Review 1: 基本修正分析 **使用エージェント**: `review-test-first` - 動的import、getState、非同期処理などの基本的な問題を分析 - 改善方針と具体的な修正内容を提案 - **ファイル修正やテスト実行は行わない** #### Review 2: DOM・マッチャー・設定分析 **使用エージェント**: `review-test-second` - detectChanges、translate関数、MockStoreValueなどの問題を分析 - 改善方針と具体的な修正内容を提案 - **ファイル修正やテスト実行は行わない** #### Review 3: spyOn・配列・追加ルール分析 **使用エージェント**: `review-test-third` - 専用マッチャー、spyOn配置、DOM要素取得などの問題を分析 - 改善方針と具体的な修正内容を提案 - **ファイル修正やテスト実行は行わない** #### レビュー結果ファイル生成 - レビュー結果ファイル名: `<fileName>レビュー結果.md` - 管理のためレビュー対象ファイルと同ディレクトリに生成 - 加工は行わず各レビューエージェントから返却された結果を結合する ### Phase 3B: 統合修正・最終調整 🛠️ **使用エージェント**: `consolidate-test-fixes` - **前フェーズで作成したレビュー結果ファイルを渡します** 1. **実際の修正実行**: 統合された修正計画に従ってファイルを修正 2. **テスト実行**: 修正後のテストを実行して動作確認 3. **最終調整**: エラーがあれば原因分析して再修正 4. **最終確認**: もう一度並列テストレビューを行い、修正が完了しているかを確認する 5. **レビューファイルの削除**: 不要になったレビューファイルを削除する ### Phase 4: 実装最終確認 ✅️ 実装内容が設計書から乖離した内容になっていないかを確認 ## 注意事項 ### 各フェーズ共通 - エラーや問題が発生した場合は詳細をユーザーに報告 ### テスト実行コマンド ```bash npm run test <project> --specs=<testFile> --agent # e.g. npm run test viewer --specs=hoge.component --agent ``` YOU MUST: **テスト実行時は必ず`npm run test <project> --specs=<testFile> --agent`を使用し、他のコマンド実行を試みないこと、特に`--agent`オプションを追加しないとテストが終了しません** - `<project>`: プロジェクト名（`viewer`, `myportal`, `core`, `sdk`のいずれか） - `<testFile>`: `.spec.ts`を除くテストファイルパス。例：`example.component` ### 品質基準 - カバレッジ: 95%以上 - すべてのテストケースが成功すること - コードスタイルがプロジェクトの規約に準拠していること ## トラブルシューティング ### テストが失敗する場合 1. エラーメッセージを確認 2. consolidate-test-fixesエージェントで再修正を試行 3. 3回試行しても解決しない場合は`investigate-test-pattern`エージェントを使用して同様の実装がないか調査してから再修正 ### レビューで問題が見つからない場合 1. 該当するレビューエージェント（review-test-\*）を再実行 2. 特定の問題に焦点を当ててレビューを指示 3. 新たなレビュー結果でconsolidate-test-fixesを再実行 全体の流れとしては、以下の4ステップです。 テスト設計 まず generate-test-spec エージェントが対象コードを分析し、テスト設計書を作成します。ここで重要なのが 「人間の承認」 を必須にしている点です。設計書がプロジェクトの意図と合致しているかをエンジニアが確認し、修正を経てOKが出て初めて実装フェーズへ進むようにしています。 テスト実装 承認された設計書を元に、 implement-test エージェントがコーディングを行います。ここではテストの実行とカバレッジ確認までを自律的に行い、エラーが出れば自己修正するように指示しています。 ここで工夫した点は、実装内容に直接関係しない弊社特有のルール（命名規則やスタイル）はあえてこの工程では指示しないことです。ルールを厳格に守らせようとすると、肝心な処理に関わるロジックの精度が落ちてしまう傾向があった経験があったためです。これによって、まずは純粋な処理のみに集中させることで、本来のコーディングスキルを存分に発揮してもらい、 Claude Codeが自信を持って 実装してもらえるようになったとのことです。 並列トリプルレビュー 実装されたコードに対し、3つの異なる専門家エージェントが 並列で レビューを行います。 Reviewer A: 基本的な構文や非同期処理のチェック Reviewer B: DOM操作やマッチャーの正確性チェック Reviewer C: SpyOnやモック定義など、高度なルールのチェック この過程では、2番目のステップの出力結果をもとに、処理内容には関係ない弊社特有のルールに沿っているかの確認のレビューを行い、提案のみを行います。コード編集は行いません。 これによって、以下の3つのメリットがあったとのことです。 複数の項目をAgentに投げると、細かい見落としが多くなる傾向にあったが、Subagentsで分けることで、特定の観点に絞ることができ、精度が上がった 並列実行することで、実行速度が向上した 処理内容のレビューは考慮せずに、スタイルレビューに限定させたことで、この過程で弊社特有のルールや表現を入れ込むことができた 統合修正・最終調整 3匹のレビュアーから上がってきた指摘事項を consolidate-test-fixes エージェントが集約し、実際のコード修正に適用します。最後に改めてテストを回し、設計書との乖離がないかを確認して完了となります。 このワークフローがもたらした、時間以上の「価値」 この「半自動化」を導入した結果、テスト実装にかかる時間は 体感で約20%短縮 されました。数字だけ見ると劇的な変化ではないように見えるかもしれません。しかし、東條さんは「時間短縮以上の価値がある」と語ります。 並行処理による生産性向上 AIがコードを書いている間、人間はSlackの返信やBacklogの整理、あるいは他の複雑な実装の考察など、別のタスクをこなせるようになりました。0から1の面倒な記述をAIが肩代わりしてくれることで、脳のメモリを他の業務に割けるようになったそうです。 品質の向上 AIとの対話の中で、「そのエッジケースは考慮しましたか？」と逆に指摘されることもあり、一人で書くよりもテストの網羅性が上がったといいます。 おわりに：AIとの協業が当たり前になる未来へ 今回は、新卒2年目が実践する、生成AIを用いたテスト半自動化ワークフローについて紹介しました。今回紹介したワークフローを導入したことで、2025年6月〜2025年12月までに完了するという目標だった予定が、2ヶ月早く終えることができたとのことです。 今後は、このノウハウをチーム全体から開発部署全体に広げつつ、さらなる精度の向上に取り組んでいきたいとのことです。 また、生成AIをテスト自動化以外のことで使っていきたい分野はあるかを聞いてみました。 「勉強に使いたいなと思っています！10時に出勤して、10時〜12時はエージェントに任せている間に、優雅にコーヒーを飲みながら最新技術のキャッチアップに費やしたいなと思ってます。そして、もっと使うエージェントを増やして、10や20匹のAgentに対して指示を出して、操ってみたいなという野望もあります。」 最後に、これからAIを使いこなしたいと考えている後輩や学生エンジニアへのアドバイスをもらいました。 「使いこなし方こそ、生成AIに聞いたら良いと思います！笑。バイブコーディングが流行っていますが、やはり、読む力は引き続き必要になっていくのではないかと思っています。大切なのは、AIに使われるのではなく、使いこなす側になること。AIが出してきた成果物に対して、自分の頭で考え、疑い、責任を持つ。エンジニアとしての『思考力』が、これからの時代こそ重要になると思います。」 AIはあくまでツールであり、最後に品質を保証するのはエンジニア自身です。この当たり前の原則を忘れずに、AIを「賢い部下」のような立ち位置で活用し、協力していくスタイルこそが、これからの開発のスタンダードになっていくのかもしれません。 いま改めて、AIとの向き合い方を意識的に考えることが最も重要だと気付かされました。 以上、新卒2年目が実践するテスト半自動化に関するご紹介でした。

この記事は  Safie Engineers' Blog! Advent Calendar 2025 11日目の記事です。 はじめに 今年も残すところあとわずかとなりましたね。AI開発部の田中です。 現在は、複数のカメラ映像を統合して解析するシステムのR&D（研究開発）に取り組んでいます。 画像認識AIの分野ではPythonが主流ですが、 「Pythonでロジックを書いたら、処理が遅すぎてリアルタイム性が確保できない」 という壁にぶつかったことはありませんか？ 今回は、6台のカメラを使った リアルタイムマルチカメラトラッキング を実装する過程でまさにその問題に直面し、一部の処理を Rust に置き換えることで劇的な高速化を実現した話を紹介します。 「Rustは難しそう」と思っている方でも、Pythonと連携させるだけなら意外とハードルは高くありません。ぜひ最後までお付き合いください。 はじめに リアルタイムマルチカメラトラッキングとは システム構成と技術スタック 1. 推論部（映像のデコード・AI推論） 2. 統合部（トラッキング・ID統合） Pythonでの限界とRustへの転換 なぜRustを選んだか PyO3とmaturinを使った実装フロー 前提ツール 1. プロジェクトのセットアップ 2. Rustコードの実装 (src/lib.rs) 3. Pythonからの呼び出し (main.py) 4. ビルドと実行 導入結果：10倍以上の高速化を実現 まとめ リアルタイムマルチカメラトラッキングとは リアルタイムマルチカメラトラッキング（オンラインマルチカメラトラッキング）とは、RTSPなどで接続した複数のカメラから現在の映像を取得し、リアルタイムに以下の処理を行う技術です。 検出 : カメラごとに被写体の領域（バウンディングボックス）を検出 追跡 : カメラ内で被写体を追跡し、カメラ内のIDを割り当て 特徴抽出 : 被写体の見た目の特徴量（ReID特徴量など）を抽出 統合 : 全カメラの情報を統合し、エリア全体で「被写体がどこにいるか」を一意に特定 これらを 「次のフレームの映像が来る前」 に完了させる必要があります。 今回目指したスペックは、 「ネットワークカメラ6台、各20FPS」 です。つまり、全カメラの処理を 50ミリ秒（1000ms / 20fps）以内 に完了させなければ、遅延が発生してしまいます。 システム構成と技術スタック システムの大まかな構成図は以下の通りです。 処理は大きく「推論部」と「統合部」に分かれています。 1. 推論部（映像のデコード・AI推論） GPUリソースを最大限に活かすため、NVIDIAの技術を採用しています。 DeepStream SDK GStreamerベースのマルチメディアフレームワーク。動画のデコードやDNN推論をパイプライン処理で高速に実行可能です。 DeepStream Python Apps DeepStreamをPythonから制御するためのバインディングです。 【出典】NVIDIA-AI-IOT, deepstream_python_apps, GitHub https://github.com/NVIDIA-AI-IOT/deepstream_python_apps （2025年11月23日アクセス） 2. 統合部（トラッキング・ID統合） 推論結果を受け取り、ロジックベースで被写体の同一性判定を行います。 Python : 全体の制御・グルーコード Rust : 計算コストの高いマッチング処理を担当 PyO3 & maturin : PythonとRustを繋ぐためのツール群 【出典】PyO3 Project, PyO3 User Guide, Webページ https://pyo3.rs/main/index.html （2025年12月10日アクセス） 【出典】PyO3 Project, maturin, GitHub https://github.com/PyO3/maturin （2025年12月10日アクセス） Pythonでの限界とRustへの転換 推論部に関しては、DeepStreamの恩恵によりPythonバインディング経由でも十分高速でした。 問題が発生したのは、後段の「統合部」です。 複数のカメラから検出された被写体の位置や特徴量を総当たりで比較し、同一被写体判定を行う処理（マッチング処理）において、Pythonの処理速度がボトルネックになりました。 カメラが増え、被写体が増えれば増えるほど計算量は指数関数的に増加します。 純粋なPython実装でテストしたところ、被写体が多いシーンでは処理に 数百ミリ秒 かかってしまいました。目標の50ミリ秒を大幅に超えており、映像はカクつき、処理落ちは避けられない状態です。 なぜRustを選んだか NumPyなどを使ったベクトル化も検討しましたが、条件分岐を含む複雑なロジックだったため、コンパイル言語への置き換えを検討しました。そこで白羽の矢が立ったのが Rust です。 C++並みの高速性 : メモリ安全性を担保しながら爆速で動く。 PyO3のエコシステム : Pythonとの連携が非常に容易で、既存のPythonコードの一部だけをRust関数に置き換える「部分的な導入」がしやすい。 「全体を書き直すのは無理だが、重いループ処理だけRustに任せよう」という戦略です。 PyO3とmaturinを使った実装フロー ここからは、実際に今回採用した開発フローを紹介します。 パッケージ管理には、最近話題の高速なツール uv を使用しました。 前提ツール uv : Pythonのパッケージ管理・プロジェクト管理ツール Rust : コンパイラ言語（cargoなどが含まれます） 1. プロジェクトのセットアップ maturin を使えば、Rustのプロジェクト作成からPythonパッケージとしてのビルドまで一気通貫で行えます。 # 作業ディレクトリへ移動 cd ${WORK_DIR} # maturinのインストール（uv toolを使用） uv tool install maturin # PyO3バインディングを含む新規プロジェクト作成 # --mixed オプションでPythonとRustのハイブリッド構成を作成 uvx maturin new -b pyo3 --mixed study_maturin cd study_maturin # 仮想環境の作成（Python 3.12指定） uv venv -p 3 . 12 2. Rustコードの実装 (src/lib.rs) デフォルトで生成されるコードです。 use pyo3 :: prelude :: * ; /// 2つの数値を足して文字列として返す関数 #[pyfunction] fn sum_as_string (a: usize , b: usize ) -> PyResult < String > { Ok ((a + b). to_string ()) } /// Pythonモジュールとしての定義 #[pymodule] fn study_maturin (m: & Bound < '_ , PyModule > ) -> PyResult < () > { // Pythonから呼べる関数として登録 m. add_function ( wrap_pyfunction! (sum_as_string, m) ? ) ? ; Ok (()) } 3. Pythonからの呼び出し (main.py) ビルドされたRustの関数は、通常のPythonモジュールと同じようにimportして使用できます。 import study_maturin def main (): a = 2 b = 3 # Rustで実装された関数を呼び出し result = study_maturin.sum_as_string(a, b) print (f "The sum of {a} and {b} is: {result}" ) if __name__ == "__main__" : main() 4. ビルドと実行 開発モード（ maturin develop ）でビルドすると、現在の仮想環境にパッケージがインストールされます。本番性能を出すため --release を付けています。 # キャッシュクリア（念のため） uv cache clean # リリースビルドでインストール uvx maturin develop --release # Pythonスクリプト実行 uv run main.py 実行結果: The sum of 2 and 3 is: 5 このように、非常に少ない手順でRustの関数をPythonから呼び出すことができました。 今回は単純な足し算ですが、実際の業務ではここに「マルチカメラのID統合ロジック」を実装しました。 Rust側で構造体を定義してPythonのクラスとして扱ったり、型ヒント（.pyiファイル）を生成してVSCodeでの補完を効かせたりすることも可能です。 導入結果：10倍以上の高速化を実現 統合部のボトルネックとなっていた解析ロジックをRustに置き換えた結果、パフォーマンスは劇的に改善しました。 Before (Python) : 1フレームあたり 300ms超 （ピーク時） After (Rust) : 1フレームあたり 30ms以内 約10倍以上の高速化 を達成し、目標としていた「6台・20FPS（50ms以内）」の処理時間を余裕を持ってクリアすることができました。これにより、リアルタイムで滑らかなトラッキングが実現できています。 まとめ 「Pythonは遅い」と諦める前に、ボトルネック部分だけをRustにオフロードするアプローチは非常に有効でした。 特に PyO3 と maturin （そして uv ）のエコシステムのおかげで、PythonエンジニアにとってもRust導入の敷居はかなり低くなっていると感じます。 今回はロジックの一部のみの置き換えでしたが、今後はRustで処理する領域を広げ、システム全体の堅牢性とパフォーマンス向上に挑戦していきたいと思います。

この記事は Safie Engineers' Blog! Advent Calendar 10日目の記事です こんにちは！Safie（セーフィー）でモバイルアプリの開発をしている河原( @rui_qma )です。 🚀 はじめに：なぜComposeでドラッグ＆ドロップが必要なのか 従来のViewシステムとの壁 AndroidチームではAndroid ViewベースのUIから Jetpack Compose ベースのUIへの移行を進めています。 弊社のプロダクト「 Safie Viewer （セーフィー ビューアー）」のカメラ一覧画面には、カメラの順番をドラッグ＆ドロップ（D&D）によって並び替える機能があります。 従来のAndroid Viewでは、 RecyclerView に ItemTouchHelper を組み合わせることで、D&Dによる並び替えが公式APIとして簡単に実現できていました。 しかし、Jetpack Composeでは、2025年11月現在、 LazyVerticalGrid （または LazyColumn ）内で同様のD&D並び替え機能を「公式APIだけで」実現するための専用のコンポーネントはまだ提供されていません。( composeBom : 2025.11.01で確認) 本記事では、この「Composeでドラッグ＆ドロップによる並び替えが可能なグリッド」を、公式API未提供の中でどのように作り込むか、その設計と実装手法について解説します。 🚀 はじめに：なぜComposeでドラッグ＆ドロップが必要なのか 従来のViewシステムとの壁 ✨ 実現したい機能の要件定義 📦 Step0: 土台となるComposableを用意 👆Step1: 要素の長押し検出と触覚フィードバック 実装のポイント ↔️Step2: 要素をドラッグして移動する 実装のポイント 🔄Step3: ドラッグによる要素の入れ替え処理 実装のポイント 💫Step4: 入れ替わる際のアニメーションを実装 実装のポイント ⬇️Step5: リストの上下端到達時の自動スクロール 実装のポイント 🎉 まとめと今後の展望 👀将来的な見通し 💻 実装コード ✨ 実現したい機能の要件定義 今回の記事で実装を目指すD&D並び替えグリッドの要件は以下の5点です。 要素を 長押し したタイミングでD&D可能状態にし、 触覚フィードバック を実行する。 ドラッグに沿って要素を移動させる。 順番の入れ替わりが発生した場合、 アニメーション で視覚的に表現する。 ドラッグ位置がリストの上下端に達した場合、 リスト自体を自動でスクロール する。 ドラッグ終了時に要素を定位置に戻す。 これらの機能を、土台となるComposableから段階的に実装していきます。 📦 Step0: 土台となるComposableを用意 今回の設計方針としてLazyVerticalGridをラップするComposableを作成し(DraggableGridと命名)、このComposableの中で状態の管理及びD&D機能の拡張を進めていきます。 @Composable fun DraggableGrid( list: List < String >, modifier: Modifier = Modifier, itemContent: @Composable (item: Camera, modifier: Modifier) -> Unit , ) { val lazyGridState = rememberLazyGridState() LazyVerticalGrid( modifier = modifier, columns = GridCells.Fixed( 3 ), state = lazyGridState, horizontalArrangement = Arrangement.spacedBy( 12 .dp), verticalArrangement = Arrangement.spacedBy( 12 .dp), ) { items(list) { id, modifier -> itemContent(id, modifier) } } } 👆Step1: 要素の長押し検出と触覚フィードバック 要素の長押しを検知する処理を実装します。 実装のポイント ドラッグ対象のCompose要素に Modifier.pointerInput を追加 pointerInput内でジェスチャー検出関数 detectDragGesturesAfterLongPress で長押しを検出 onDragStart に長押し時の処理、 onDrag にドラッグ中の処理を実装する 触覚フィードバックは performHapticFeedback を呼び出すことで動作するため、以下のように実装することによってユーザーに長押し状態であることを知らせることができます。 Developers ... val haptic = LocalHapticFeedback.current LazyVerticalGrid( modifier = modifier.pointerInput( Unit ) { detectDragGesturesAfterLongPress( onDragStart = { offset -> // ドラッグ開始時に行いたい処理をここに実装する haptic.performHapticFeedback(HapticFeedbackType.LongPress) // 触覚フィードバック }, onDrag = { change, dragAmount -> // ドラッグ中に行いたい処理をここに実装する change.consume() // ドラッグイベントの消費 }, onDragEnd = { // ドラッグ終了時に行いたい処理をここに実装する }, onDragCancel = { // ドラッグがキャンセルされた時に行いたい処理をここに実装する } ) }, ... ↔️Step2: 要素をドラッグして移動する Step1で記述したdetectDragGesturesAfterLongPressのコールバックにドラッグに関する処理を実装していきます。 実装のポイント onDragStartでドラッグ対象のインデックスを取得 onDragでドラッグ量を加算して保持 ドラッグ対象要素に対して Modifier.offset でドラッグ量を指定して移動 onDragEnd, onDragCancelでドラッグ量を初期化 （今回は簡単に実装するためにComposable内でインデックスやオフセット等の状態を管理していますが、Stateクラスの作成などViewとは分離して管理することをオススメします） val density = LocalDensity.current var draggingIndex by remember { mutableIntStateOf( 0 ) } var dragOffset by remember { mutableStateOf(Offset.Zero) } LazyVerticalGrid( modifier = modifier.pointerInput( Unit ) { detectDragGesturesAfterLongPress( onDragStart = { offset -> // ドラッグ開始位置のインデックスを取得 draggingIndex = lazyGridState.layoutInfo.visibleItemsInfo.find { info -> val rect = Rect(info.offset.toOffset(), info.size.toSize()) rect.contains(offset) }?.index ?: - 1 haptic.performHapticFeedback(HapticFeedbackType.LongPress) // 触覚フィードバック }, onDrag = { change, dragAmount -> dragOffset + = dragAmount change.consume() // ドラッグイベントの消費 }, onDragEnd = { dragOffset = Offset.Zero }, onDragCancel = { dragOffset = Offset.Zero } ) }, ... ) { itemsIndexed( items = list, key = { index, item -> item }, ) { index: Int , item: String -> val dragging = draggingIndex == index val modifier = if (dragging) { Modifier .offset( x = with(density) { dragOffset.x.toDp() }, y = with(density) { dragOffset.y.toDp() }, ) .zIndex( 1f ) // ドラッグ中のアイテムを前面に表示 } else { Modifier } itemContent(item, modifier) } } 🔄Step3: ドラッグによる要素の入れ替え処理 ドラッグ中アイテムの 中心位置 が他要素の領域に入ったタイミングで、リストの順番を入れ替える処理を実行します。 実装のポイント 要素入れ替えコールバック(ex: onListChange)を定義し、並び替えの処理を実装する ドラッグ中アイテムの中心位置を算出する 中心位置が他要素の領域内に存在する場合、要素入れ替えコールバックを実行する 実際の入れ替えロジックは複雑になるため、ここでは詳細を割愛しますが、リスト変更を親に委ねるコールバック設計が重要です。詳細な実装は コチラ を参照ください。 💫Step4: 入れ替わる際のアニメーションを実装 要素が入れ替わったことをユーザーにわかりやすく伝えるため、アニメーションを追加します。 このStepに関しては標準で提供されている機能を利用することで、手軽に実装することができます。 実装のポイント アイテムにキーを設定する 入れ替えられる側の要素に Modifier.animateItem() を設定する itemsIndexed( items = list, key = { index, item -> item }, // Compose側でアイテムを特定するためのキー ) { index: Int , item: String -> val dragging = draggableGridState.draggingIndex == index val offset = draggableGridState.dragOffset val modifier = if (dragging) { Modifier .offset( x = with(density) { offset.x.toDp() }, y = with(density) { offset.y.toDp() }, ) .zIndex( 1f ) } else { Modifier.animateItem() // 入れ替えられる側にアニメーションを設定 } itemContent(item, modifier) } ⬇️Step5: リストの上下端到達時の自動スクロール 例えば「1番目から100番目に移動したい」といった大幅な移動を行いたい場合、現状は1回のドラッグにつき最大1画面分しか移動できないため、複数回のドラッグが必要になります。 この問題を解決するため、ドラッグによってリストの上下端まで持っていった場合はリスト自体のスクロールも行う機能を実装します。 実装のポイント ドラッグ中の要素がリストの上下端からどれだけはみ出しているかを算出する はみ出している場合は、はみ出した量に応じたY軸移動量を算出する リストと要素の両方を同時にY軸移動量分だけ移動する（同期する） この実装はパフォーマンスと競合回避の観点から複雑な部分であり、スクロールと要素移動を同時に行う同期処理に工夫が必要です。詳細な実装は コチラ を参照ください。 🎉 まとめと今後の展望 本記事では、Jetpack Composeにおいて標準で提供されていない機能を、 Modifier.pointerInput を活用してゼロから作り込む手法を解説しました。 タッチイベントの検出、オフセットによる位置調整、 Modifier.animateItem() によるアニメーション、そして自動スクロールを組み合わせることで、従来のAndroid Viewの RecyclerView + ItemTouchHelper に匹敵する、高度なUXを実現することができました。 この実装には手探りの部分が多く、リファクタリングやパフォーマンス改善の余地は十分にあると考えていますが、本記事が皆様のCompose実装の手助けとなれば幸いです。 👀将来的な見通し 執筆時点では自前での実装が必要でしたが、ロードマップにはドラッグ＆ドロップに関する記載があるため、将来的には標準機能としてサポートされる可能性が高いです。 出典：Jetpack Compose のロードマップ https://developer.android.com/jetpack/androidx/compose-roadmap?hl=ja （2025年12月3日アクセス） それまでは今回解説したような自前の実装を行うか、あるいは、従来のAndroid Viewの ItemTouchHelper を ComposeView でホストして利用するという選択肢も一つの回避策となります。状況に応じて、最適なアプローチを選択してください。 💻 実装コード 執筆にあたって実装したコード全体は、以下のGitHubリポジトリで公開しています。是非参考にしてください。 https://github.com/ruiqma/DraggableGridSample モバイルチームは開発する仲間を募集しています！ open.talentio.com open.talentio.com

この記事は Safie Engineers' Blog! Advent Calendar 2025 9日目の記事です。 はじめに こんにちは、エンジニアリングオフィスの横道 ( @m_yokomichi )です。 2025年、AI技術は私たちの予想を超えるスピードで進化を遂げました。いまや生成AIを使いこなせるか否かは、個人の生産性だけでなく、 エンジニアとしてのキャリア、ひいては企業の競争力そのものを左右する と言っても過言ではありません。 今後、活用できる層とそうでない層の差は広がる一方です。そのため、生成AIの活用は私たちセーフィーにとっても全社の重要課題であり、開発本部として組織的に向き合うべきテーマとなっています。 本記事では、開発本部全体で取り組んでいる「生成AI利用促進プロジェクト」について、以下のポイントを中心にご紹介します。 組織課題を解決するための「5つの戦略軸」 ボトムアップで進める実際の活動内容 導入による具体的な成果と今後の展望 単なるツールの導入事例ではなく、「組織文化をどう変えていくか」という観点での全貌をお伝えします。 はじめに 私たちが直面していた「5つの壁」 1. 情報収集の「非効率性」 2. 技術検証・導入の「属人化」 3. ナレッジの「サイロ化」 4. 活用機運の「温度差」 5. 技術的取り組みの「認知不足」 解決への戦略的アプローチ：5つの軸 プロジェクト全体構想図 軸1：情報収集活性化 📡 軸2：技術検証・導入 🛠️ 軸3：ナレッジデータベースマネジメント 📚 軸4：生成AI活性化 🔥 軸5：社外発信 📢 実際の活動と想定外の反響 20名の有志が集結 分科会による自律的な運営 成果と今後の展望 主な成果 今後のロードマップ おわりに 私たちが直面していた「5つの壁」 生成AI活用を組織的に推進しようとした際、私たちは大きく分けて5つの問題領域に直面していました。これらは、多くの開発組織が共通して抱える悩みではないでしょうか。 1. 情報収集の「非効率性」 外部の技術動向を個人がバラバラに追っているため、組織としてのインプットが非効率でした。「隣のチームも同じ調査をしていた」という車輪の再発明が起きており、組織としてのスピード感が損なわれていました。 2. 技術検証・導入の「属人化」 「この新機能を使いたい」と思っても、導入プロセスや評価基準が不明確でした。結果として、意欲あるメンバーの技術選定に時間がかかり、有益な技術の導入による機会損失が発生していました。 3. ナレッジの「サイロ化」 Aさんは高度なプロンプトを知っているのに、Bさんは同じ課題で躓いている。成功事例や失敗事例（アンチパターン）が共有されず、ノウハウが個人の頭の中だけに留まっていました。 4. 活用機運の「温度差」 「便利そうだけど、自分の業務での使い所がわからない」というメンバーも多く、一部の感度が高い層だけが活用している状態でした。 5. 技術的取り組みの「認知不足」 せっかく先進的な取り組みをしていても、それが外部に伝わっていなければ採用やブランディングには繋がりません。また、外部コミュニティとの接点が薄く、フィードバックを得る機会も不足していました。 解決への戦略的アプローチ：5つの軸 これらの課題を打破するため、私たちは「5つの軸」を定義し、戦略的なアプローチを開始しました。 プロジェクト全体構想図 まず、以下のサイクルを回すことで、生成AI（AI技術）の導入・定着を目指しました。生成AI利用促進チームがハブとなり、開発本部全体を巻き込んでいます。 ここからは、具体的な5つの軸について解説します。 軸1：情報収集活性化 📡 目的： 組織的な「アンテナ」の感度を高め、技術選定を高速化する 個人の努力に依存していた情報収集を、組織の活動へと昇華させました。 トレンドの定点観測: 最新ツールや事例をチームで分担して調査 導入ジャッジ: 利用方法が明確なものは「実務検証」へ、未導入技術は「企画」へとスムーズに移行させるフローを確立 軸2：技術検証・導入 🛠️ 目的： 新技術を「安全に」「素早く」試せる環境を作る 「使ってみたい」を「使える」にするための環境整備です。 環境整備: アカウント管理やLLM Proxy基盤の構築 ガイドライン策定: セキュリティや個人情報の取り扱い、機密情報の保持に関するルールを明確化し、安全に利用できる環境を提供 軸3：ナレッジデータベースマネジメント 📚 目的： 知見を「資産」化し、車輪の再発明を防ぐ DB構築: ベストプラクティス、失敗事例、プロンプトライブラリを一元管理 メンテナンス: 情報の鮮度を保つため、陳腐化した情報の更新フローを整備 テンプレート化: 開発、分析、ドキュメント作成など、用途別の「再利用可能なプロンプト」を整備 軸4：生成AI活性化 🔥 目的： 組織全体の「熱量」を上げ、文化を作る イベント開催: 勉強会、LT（ライトニングトーク）、ハッカソンなどを企画 横展開: 成功事例を部門を超えて共有し、「自分もやってみよう」という空気を醸成 軸5：社外発信 📢 目的： 取り組みを「価値」に変え、新たな知見を呼び込む アウトプット: 技術ブログやイベント登壇を通じた発信 還流: 社外からのフィードバックを社内に取り込み、さらなる改善につなげるサイクル 実際の活動と想定外の反響 戦略は描けましたが、私一人で実行できるものではありません。そこで開発本部全体からメンバーを公募したところ、予想外の反応がありました。 20名の有志が集結 当初は数名集まれば良いと考えていましたが、 約20名ものメンバーが手を挙げてくれました。 開発本部のエンジニアたちが、いかにこの課題に熱意を持っていたかの表れであり、非常に嬉しい誤算でした。 分科会による自律的な運営 メンバーの自主性を尊重し、前述の5つの軸ごとに「分科会」を組成しました。 週次・隔週で定例MTGを行い、それぞれの強みを活かしてアクションプランを実行しています。トップダウンではなく、現場のエンジニアが主導するボトムアップ型のプロジェクトとして機能しています。 成果と今後の展望 2025年9月の発足から数ヶ月、土台づくりに注力してきましたが、すでに目に見える変化が起きています。 主な成果 利用率の向上: Claude CodeのMaxプラン等の高度な機能を利用するメンバーが前月比で増加傾向。 学習文化の定着: 開発本部の 約半数 が生成AI勉強会に参加。 ナレッジベース稼働: 独自のデータベースが構築され、日々知見が蓄積されている。 ポータルサイト開設: ツールやガイドライン、最新情報を集約した「生成AIポータル」を公開。 今後のロードマップ 📍 短期（FY25年度内） 技術検証: LLM Proxy基盤の構築、Claude Teamプランへの移管。 活性化: LT大会の実施（11/27、12/11予定）、ハンズオン・ハッカソンの開催。 ナレッジ: プロンプトライブラリのカテゴリ拡充（コードレビュー、設計支援など）。 📍 中長期（来年度以降） 効果測定: 単なる利用者数ではなく、コード品質や開発速度など「生産性指標」への貢献を可視化。 全社展開: 開発本部で培ったノウハウを他部門へ横展開し、全社的なDXを支援。 文化の定着: 新入社員向けの「生成AI活用研修」などを通じ、AI活用を空気のような「当たり前」にする。 おわりに 生成AIを組織で活用できている状態にするには、個人の「点」の活動だけでは限界があります。組織全体で戦略的に取り組み、「面」の活動にすることで初めて、知見の標準化や文化醸成が可能になります。 今回ご紹介した「5つの軸」はあくまでセーフィーの一例ですが、組織的なAI活用に悩む皆様のヒントになれば幸いです。 セーフィー開発本部では、今後もイベント等を通じて知見をオープンにしていきます。「うちではこうしているよ！」という他社の皆様、ぜひ情報交換させてください！

この記事は  Safie Engineers' Blog! Advent Calendar  の8日目の記事です。 こんにちは、セーフィー株式会社でサイバーセキュリティを担当している金原です。 前回の記事「 セーフィーのサイバーセキュリティ戦略の作り方 」では、私たちが目指す「セキュリティが当たり前の文化」と「そこに到達するための戦略」についてお伝えしました。今回は、戦略の具体的な打ち手の一つ、 「脅威モデリング」 について深掘りします。 「脅威モデリング」と聞くと、専門用語が多くて「難しそう」「時間がかかりそう」と感じてしまうことはありませんか？ 正直に言うと、私たちも最初はそうでした。 しかし、試行錯誤してたどり着いた結論はシンプルです。脅威モデリングの本質は 「関係者同士の対話を促進するコミュニケーションツール」 だということ。 今回は、一般的な脅威モデリングの手法を解説しつつ、それを「セーフィーではどう解釈し、運用しているか」という 実践的なナレッジ（＝セーフィー流の型） をセットで公開します。これから脅威モデリングを始めたい方、もっと活用していきたい方の「生きた教科書」になれば幸いです。 そもそも「脅威モデリング」って何？ なぜ今、私たちがこれを推すのか 脅威モデリングの進め方（解説とセーフィー流の実践） 4つの重要な質問 【問1】私たちは何に取り組んでいるか？ ～モデルを作る～ 【問2】何が問題になりうるか？ ～STRIDEでリスクを見つける～ 【問3】それに対して何をするのか？ ～リスク評価と対策～ 【問4】十分にうまくできたか？ ～ふりかえり～ セーフィーでの活用事例 1. セキュリティレビューへの「部分導入」 2. 「すぐに始められる」テンプレートの用意 3. 生成AIを「副操縦士」にする さいごに そもそも「脅威モデリング」って何？ 一言でいうと、 「システムを作る前に、攻撃者の視点を踏まえ『起きたら困ること』を分析し、対策を考える活動」 です。 通常、開発の現場では「どんな機能を作るか（要件）」や「どうやって作るか（設計）」に集中しがちです。そこに 「何が問題になりうるか（セキュリティリスク）」 という視点をプラスします。 なぜ今、私たちがこれを推すのか 理由は大きく2つあります。 「シフトレフト」の世界標準だから NISTの「SSDF」やOWASPの「SAMM v2」など、主要なガイドラインで推奨されています。設計段階でリスクを潰すことで、手戻りを防ぐためです。 生きたセキュリティ教育になるから（★最重要） 私が特に重視しているのはこちらです。脅威モデリングを行うには、エンジニア、PM、セキュリティ担当者が集まって会話をする必要があります。 「ここのデータって、どういう流れでDBに入るんだっけ？」 「このAPI、認証なしで叩けたらマズいよね？」 こうした会話自体が、座学の研修よりもはるかに効果的な 「生きたセキュリティ教育」 になります。ドメイン知識とセキュリティ知識が、対話を通じてチーム全体に染み渡るのです。 脅威モデリングの進め方（解説とセーフィー流の実践） では、具体的にどう進めればいいのでしょうか？ 基本は以下の 「4つの重要な質問」 に答える形で進めていきます。 ここで大事な心構えは 「完璧を目指さない」 こと。セーフィーでは、 「間違ってもいいから、まずはホワイトボードに絵を描いて話そう」 を合言葉にしています。 4つの重要な質問 【問1】私たちは何に取り組んでいるか？ ～モデルを作る～ まずは、システムの「形」を可視化します。一般的には、データフローダイヤグラム（DFD）が推奨されます。 ■DFDの書き方（いきなり詳細を描かない） DFDは「データがどこから来て、どこへ行くのか」という流れに注目した図です。 以下の5つの要素で図を表現します。 プロセス (Process) ：処理や機能（丸） データストア (Data Store) ：DBやファイルなどのデータが留まるところ（二本線） 外部エンティティ (External Entity) ：ユーザーや連携システム（四角） データフロー (Data Flow) ：データの流れ（矢印） 信頼境界 (Trust Boundary) ：インターネットと社内LANの間などの境界線（点線） よくある落とし穴が、「最初から詳細に描こうとして挫折する」ということ。私たちは 「抽象から具体へ」 という2ステップをおすすめしています。 ① コンテキストダイヤグラム でまずは「外」と「中」を分ける システム全体を1つの「箱」として捉え、外部（ユーザーや連携システム）とのやり取りだけを描きます。これだけで「守るべき範囲」が明確になります。 ② レベル0ダイヤグラム で内部構造を分解する 次に、箱の中身を主要なプロセスに分解し、データの保存場所（データストア）を描き足します。 ここで最も重要なのが 「信頼境界（Trust Boundary）」 という点線です。ここをデータがまたぐとき、脅威が発生しやすくなります。 必要に応じて、ここからさらにレベル1…、のように詳細化していきます。 ■セーフィー流の実践（厳密さよりも「対話の種」） 教科書通りの記号（丸や二本線など）を使おうとすると「これであってる？」と手が止まりがちです。私たちの現場では、 「ホワイトボード（またはMiro）に10分ぐらいで描けるレベルでいい」 としています。 厳密な記法より、 「データの流れ（線）」 が合っていればOK。 詳細な設計図である必要はない。先ほどの 「信頼境界（点線）」をまたぐ場所 がわかれば、そこが攻撃ポイントだと判断できる。 加えて、一度で終わりにせず、徐々に詳細度を上げていくスタイルを取っています。 📘 もっと学びたい方へ 具体的なDFDの作り方は、書籍『データフローダイアグラム いにしえの技術がもたらす システム設計の可能性』（大嶋和幸、松永守峰 / 翔泳社）が非常に参考になります。 【問2】何が問題になりうるか？ ～STRIDEでリスクを見つける～ モデルができたら、次は「ここが攻撃されたらどうなる？」を考えます。 ここでのポイントは、高度なハッキング方法を語るのではなく、 「起きたら困ること」 を洗い出すことです。攻撃手法の話になると専門家しかわからなくなりますが、「困ること」なら関係者全員で議論できます。 ■STRIDEフレームワーク 脅威を見つける切り口として、 「STRIDE（ストライド）」 というフレームワークを使うと便利です。以下のような「問いかけ」をしながら問1で作成したDFD上に付箋で書き出していくとスムーズです。 頭文字 脅威の種類 問いかけの例 具体例（Webアプリ） S Spoofing (なりすまし) 私たちまたはユーザーは、なりすましが起きて何が困るか？ 他人のアカウントでログインされる T Tampering (改ざん) 私たちまたはユーザーは、データ改ざんが起きて何が困るか？ DBの値や通信内容を書き換えられる R Repudiation (否認) 私たちまたはユーザーは、否認できる状態で何が困るか？ 「操作していない」と言い逃れされる I Information Disclosure (情報漏洩) 私たちまたはユーザーは、データ漏洩が起きて何が困るか？ 個人情報や機密データが漏れる D Denial of Service (サービス拒否) 私たちまたはユーザーは、システムの停止/遅延が起きて何が困るか？ システムがダウンして使えなくなる E Elevation of Privilege (権限昇格) 私たちまたはユーザーは、権限を越えた操作ができて何が困るか？ 一般ユーザーが管理者操作を行う ■セーフィー流の実践：「思考停止を防ぐカンペ」として使う STRIDEを事前にすべて暗記する必要はありません。私たちは上記のような具体例をいくつか添えた表を「問いを立てるためのカンペ」として使っています。 レビューの場で問いかけるためのトリガーになれば十分です。エンジニアが「あ、それだとこういうことが起きると困りますね」と気づけば、それが立派な脅威分析です。専門用語を覚えるより、 「困ること」を言語化できること を重視しています。 📘 もっと学びたい方へ STRIDEやセキュア設計については、書籍『セキュアなソフトウェアの設計と開発 脅威モデリングに基づく普遍的アプローチ』（ローレン・コンフェルダー / 秀和システム）がおすすめです。 【問3】それに対して何をするのか？ ～リスク評価と対策～ 脅威がたくさん出てくると、「全部直すなんて無理！」となってしまいますよね。 大事なのは、「同時にすべてを対策することはできない」 という前提に立つことです。リソースも時間も有限ですから、優先順位をつける必要があります。 リスクマップ： 「発生確率」×「影響度」で定性的に評価して優先度を決めます。 対策： リスク「高」のものから順にチケット化し、バックログに積みます。 ■リスクマップの例 ■セーフィー流の実践：必要に応じて評価方法を変える 教科書的には厳密にスコアリングして評価することが推奨されがちですが、全てのリスクでそれをやるとスピードが落ちてしまいます。 セーフィーでは、対象システムや情報の重要度に応じて「評価方法（物差し）」を使い分けています。 スピード感や柔軟性が求められる通常の機能は、「定性評価（高・中・低）」でスピーディに判断し、対策の要否を決めます。一方で、決済周りや特に重要な基盤システムは、「定量評価（ CVSS や OWASP Risk Rating Methodology 等）」を用いて厳密にスコアリングし、監査にも耐えうる根拠を残します。もちろん、2つを組み合わせるケースもあります。 「スピード重視」と「厳密さ」のメリハリをつけること。これを私たちは大切にしています。 📘 もっと学びたい方へ リスク評価の深掘りには、書籍『脅威インテリジェンスの教科書』（石川朝久 / 技術評論社）が参考になります。 【問4】十分にうまくできたか？ ～ふりかえり～ このふりかえりは飛ばされがちですが、実は脅威モデリングを組織やチームに浸透させるためには、とても重要な問いになります。 対策が妥当かどうかの評価も大事ですが、「脅威モデリングの進め方自体がどうだったか」 のふりかえりで経験学習のサイクルを回します。 ■セーフィー流の実践（10分で終わらせる「タイムボックス」） ふりかえりの手法は多数ありますが、セーフィーでは軽量に実施できる「＋/Δ（プラス/デルタ）」を採用して、 「10分間」 という時間を区切って実践しています。理由は、重くすると続かないからです。継続性が大事。 「DFDのスコープが広すぎて議論が発散したね」 「××さんが詳しいから、次は呼ぼう」 こうした小さな改善の積み重ね（アジャイルなアプローチ）が、チームのセキュリティ筋肉を育てていきます。 📘 もっと学びたい方へ ふりかえりの手法や有用性を学ぶなら、書籍『アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット』（森 一樹／翔泳社）がおすすめです。 セーフィーでの活用事例 ここまで脅威モデリングの手法とセーフィー流の実践をお伝えしました。では、これを具体的にどのように現場に落とし込んでいるのか？私たちの現在の取り組みを紹介します。 1. セキュリティレビューへの「部分導入」 これまでチェックリストベースで行っていたセキュリティレビューの一部に、脅威モデリングを取り入れ始めています。 開発者から説明を受ける際、セキュリティチームが手元で簡易的なモデルを作り、「ここのデータの流れ、信頼境界またいでるけど大丈夫？」といった対話をします。 チェックリストだけでは見えない重要箇所のレビューができますし、静的なアーキテクチャ図よりもデータやプロセスの流れが整理できるので、開発者からも好評です。私自身も、多くのセキュリティレビューを実施する中で、「あれどうなってたっけ？」となったときに、レビュー時に作成したモデルを見ることで思い出すことができて助かってます。 セキュリティレビューで作った脅威モデルの例 2. 「すぐに始められる」テンプレートの用意 「準備が面倒」という心理的ハードルを下げるため、オンラインホワイトボードツール（Miro）に 「脅威モデリングテンプレート」 を作成しました。 DFDのパーツとSTRIDEの付箋、そして「進め方」があらかじめ配置されています。これを開けば、すぐに議論に入れる状態を作っています。 脅威モデリングテンプレート（Miro） 3. 生成AIを「副操縦士」にする ここが最近のホットトピックです。私たちは 生成AI（Gemini等） を積極的に活用しています。 ゼロから「どんな脅威がある？」と考えるのは、認知負荷が高い作業です。そこで、システムの概要やユースケースをAIに与えて、 「DFDのドラフト」や「想定される脅威リスト」 を出力させます。 もちろんAIの出力は完璧ではありません。しかし、 「AIが出した80点の回答」を、人間のエンジニアが「セーフィーの現場知識（ドメイン知識）」で修正・補完して100点にする というプロセスは、ゼロから考えるより圧倒的に効率的です。 例えば、「小規模なIoTクラウドカメラシステム」というお題でGeminiに出力させた例がこちらです。（注：セーフィーのシステムではありません） Geminiが出力したモデル（Mermaid） Geminiが出力したリスクの一例 「カメラの物理的盗難」といった、IoTならではのリスクまで指摘してくれています。これを叩き台にすることで、議論のスタート地点を大幅に進めることができます。 さいごに 脅威モデリングを組織に浸透させるために一番大切なこと。それは、 「最初から完璧を目指さない」 ことです。 最初から正解の図を作ろうとすると手が止まってしまいます。「間違っててもいいから、まずはホワイトボードに絵を描いて話そう」。このスタンスこそが、セキュリティ文化を作る第一歩だと私は信じています。 この記事を読んで、「ちょっと面白そうだな」と思った方は、ぜひ次の設計レビューで 「これ、攻撃者に狙われたとして、起きたら困ることは何ですかね？」 と問いかけてみてください。 セーフィーでは、こうした「対話」を大切にしながら、セキュリティを「専門家だけの仕事」から「従業員みんなの仕事」に変えていこうとしています。 「一緒に文化を作っていきたい！」という方がいれば、ぜひカジュアルにお話ししましょう！ https://safie.co.jp/teams https://open.talentio.com/r/1/c/safie/pages/71628

この記事は Safie Engineers' Blog! Advent Calendar の7日目の記事です。 情報システムグループの松尾です。 以前、当ブログにて、情シスチームがアジャイル型の仕事の話へ変革した際の記事を書かせていただきました。 engineers.safie.link 今回はその続編として、アジャイルなチーム作りをさらに進める中で生まれた、 「もやもやリスト」を用いた継続的改善（カイゼン）の取り組み についてお話しします。 「隠れた負債」への気付き 心理的ハードルを下げる「もやもやリスト」 登録コストを下げる「仕組み」 「もやもや」から生まれた具体的なカイゼン 1. 入社フローにおけるプロセスの標準化 2. 障害対応の脱属人化（クロスファンクショナルなチームへ） リーダー任せにしない、持続可能な運用に向けて 「隠れた負債」への気付き スプリントを回す中で、日々の業務に埋もれがちな「小さな違和感」を放置することでも問題が発生することに気づきました。 「これは後で対応したほうがいいね」と会話には出るものの、タスク化されずに流れてしまい、忘れた頃に同じトラブルが発生して手戻りになることがありました。 これはアジャイルで言うところの 「透明性」 が欠けている状態であり、見えない技術的負債がチームに蓄積されている状態でした。 そこで私たちは、「完璧な解決策」を最初から求めるのではなく、まずは 「小さな違和感をチームで検知し、カイゼンする仕組み」 を作ることにしました。方針は以下の2点です。 ストックする（透明化）: 「やらなきゃ」「ちょっと気になる」を可視化する場所を作る 振り返る（検査と適応）: 定期的に見直し、再発防止の仕組みに変える 心理的ハードルを下げる「もやもやリスト」 この仕組みを回すため、Notionにデータベースを作成しました。 ここで重要なのは、 「タスク」として登録するのではなく、「もやもや」として登録すること です。 「タスク登録」と言われると、「完了条件は？」「期限は？」と考えてしまい、登録の心理的ハードルが上がってしまいます。 アジャイルなチームには心理的安全性が不可欠であるため、 「もやもやリスト」 という名前にすることで、未完成の状態でも気軽に放り込めるようにしました。 登録コストを下げる「仕組み」 運用も、徹底的にハードルを下げる工夫をしました。 手動登録: 朝会や雑談で出たものはその場で追加 Slack連携による自動登録: Slack上で課題らしき発言があった際、特定のスタンプを押すと自動的にNotionの「もやもやリスト」に起票される これにより、フロー情報として流れてしまいがちなSlack上の会話を、強制的にストック情報として蓄積する仕組みを整えました。 リストに入った項目は、2週間に一度のサイクルで棚卸しを行います。ここで初めて 「見守り（今は何もしない）」 か 「進捗中（タスク化する）」 かを判断します。 チームのリソースには限りがあるため、「もやもや」は全ての項目を改善するのではなく、現時点で は現状維持でも問題ないとチームで判断できたものは一旦、「現在の対応で継続する」 とすることもありました。 「もやもや」から生まれた具体的なカイゼン このサイクルを回すことで、実際にどのような改善が行われたかをご紹介します。 1. 入社フローにおけるプロセスの標準化 新入社員向けのITオリエンテーションについて、毎月の振り返りを通じてプロセスを改善しました。 作業フローの統一: 雇用形態ごとにバラバラだった手順を統一し、複雑性を排除（オペレーションミスの削減） フィードバックの反映: PC郵送時や代替機貸与時の「ヒヤリハット」をリストから拾い上げ、事前対策フローを追加 一度決めたルールを再確認し、発生した事象に合わせてフロー自体をアップデートし続けています。 2. 障害対応の脱属人化（クロスファンクショナルなチームへ） ネットワーク障害は、どうしても特定のエキスパートに依存しがちな領域です。しかし、アジャイルなチームは「誰かがいないと回らない」状態を良しとしません。 そこで、「もやもやリスト」に上がった障害対応を振り返り、 「従業員の業務を止める時間を極力短くする（MTTRの短縮） 」ことにフォーカスを絞った初動対応マニュアルを作成しました。 これにより、 ネットワーク専任担当者以外でも一次切り分けが可能になり、チーム全体での対応力が向上しました。 リーダー任せにしない、持続可能な運用に向けて 「もやもやリスト」の運用は、現在はグループリーダーである私がファシリテートすることが多いですが、長期的には チームメンバーの誰もが課題を発見し、自律的に改善サイクルを回せる（自己組織化）」状態 を目指していきたいと考えています。 今後は運用ルールのドキュメント化を進め、誰でもこのプロセスを運用できるようにしていきます。また、溜まっていく 「見守り」ステータスの棚卸しも定期的なイベントとして組み込み、「もやもやリスト」を健全に保つ仕組み を作っていく予定です。 来年以降も、こうした小さな「カイゼン」を繰り返し、変化に強い情シスチームを作っていきたいと思います。

この記事は セーフィー株式会社 Advent Calendar 2025 の12月6日の記事です。 こんにちは！ セーフィー株式会社のAndroidエンジニアのジェローム( @yujiro45 )です🎄 昨年、私が書いた「 AndroidでSceneViewを使って、3D/ARを表示する 」という記事で、アプリに3D/AR機能を簡単に実装できるライブラリを紹介しました。 しかし現在、SceneViewはメンテナンスされておらず、コントリビューターさんの GitHubでのコメント によれば新しいリリースの予定はありません。 出典：Github, https://github.com/SceneView/sceneview-android/issues/623#issuecomment-3097955731 (2025/11/12アクセス) 本記事では、 Android XR の新しいライブラリ「 SceneCore 」を使って、アプリ内に3D/ARを表示する方法を説明します。 Android XRとは Android XRのEmulator作成方法 SceneView vs SceneCore 3Dモデルを表示する SceneView SceneCore ExoPlayerの動画を表示する SceneView SceneCore まとめ Android XRとは Android XR は、AR/VR向けのヘッドセットやスマートグラス用に作られた、AI搭載のAndroid OSです。アプリを3D空間に表示・操作でき、開発ではCompose for XRやSceneCoreなどのライブラリを使って実装します。 Android XRのEmulator作成方法 Android XRは、XRが対応した端末でしか使えないので端末持っていない場合は、XRのEmulatorを作成しないといけないです。 セッションの作成は、Android XR デバイスでのみサポートされています。互換性のないデバイスでセッションを作成しようとすると、結果は失敗します。 https://developer.android.com/develop/xr/jetpack-xr-sdk/add-session Android StudioのデバイスマネージャーでXRのカテゴリがあります。そこで、XRのEmulatorを簡単に作成できます。 SceneView vs SceneCore 3Dモデルを表示する 💡この記事では、SceneCoreの最新版（執筆時点）である 1.0.0-alpha08 を使用しています。 SceneViewは最新版の 2.3.0 を使用しています。 SceneViewとSceneCoreの違いを理解するため、両方のライブラリで「ドロイド君」の3Dモデルを表示してみましょう！٩( 'ω' )و 出典：Sketchfab, https://sketchfab.com/3d-models/android-7c30eda007684abbb78ea4b99d22fc2c 　(2025/11/12アクセス) SceneView SceneviewexampleTheme { val engine = rememberEngine() val modelLoader = rememberModelLoader(engine) // 3Dモデル用のノードを作成 val modelNode = ModelNode( // 3Dモデルの読み込み (/res/raw) modelInstance = modelLoader.createModelInstance(R.raw.android) ).apply { // 3Dモデルの初期設定 scale = Scale( 1 / 40f ) position = Position( 0f ) } Scene( modifier = Modifier.fillMaxSize(), engine = engine, modelLoader = modelLoader, childNodes = rememberNodes { // モデルノードの追加 add(modelNode) } ) } 結果） 詳細は、以前の記事「 AndroidでSceneViewを使って、3D/ARを表示する 」で説明しているので、ぜひ読んでください〜😃 SceneCore Subspace { val session = LocalSession.current ?: return @Subspace val capabilities = LocalSpatialCapabilities.current var entity by remember(session) { mutableStateOf<GltfModelEntity?>( null ) } LaunchedEffect(session, capabilities.isContent3dEnabled) { // Full Spaceモードに切り替え if ( ! capabilities.isContent3dEnabled) { session.scene.requestFullSpaceMode() return @LaunchedEffect } // 生成は1回だけ if (entity == null ) { // 3Dモデルの読み込み (app/src/main/assets/models/android.glb) val model = GltfModel.create(session, Paths. get ( "models" , "android.glb" )) // 3Dモデルを作成する entity = GltfModelEntity.create(session, model).apply { // Positionを設定する setPose(Pose(Vector3( 0f , 0f , - 1.5f ), Quaternion.Identity)) // Scaleを設定する setScale( 0.2f ) } } } // Lifecycle管理 DisposableEffect(session) { onDispose { entity?.setEnabled( false ) entity?.parent = null entity = null } } } 結果）Android XRで3Dモデルを表示できました〜！ SceneViewとSceneCoreの主な違いは以下となります。 SceneView SceneCore 3D Space Scene Subspace 3Dオブジェクト Node Entity 3DモデルのPath /res/raw/ app/src/main/assets/models/ Lifecycle対応 rememberEngine / rememberModelLoader / rememberNodes を使用すると、Compose がライフサイクルを面倒みるためlifecycleを対応するのは不要です。 SceneCore の Entity は XR側で自動破棄されないため、Composableの終了やセッション切替時に DisposableEffect(session) 内で明示的に解放しないといけないです（メモリリーク防止のため）。 3Dオブジェクトの追加方法 Scene を使うと、中に Node を作成できます。 childNodes = rememberNodes { add(modelNode) } のように Node を追加すると、表示されます。 GltfModelEntity.create(session, model) を呼ぶと、3Dモデル用の Entity が作成され、 .add() しなくても表示されます。 3Dスペースモードを切り替える 不要 Android XRのEntityを使う時、 session.scene.requestFullSpaceMode() のように、Full Spaceモードに切り替えないといけないです。 ExoPlayerの動画を表示する 出典：Pexels,  https://www.pexels.com/ja-jp/video/13299023/ 　(2025/11/12アクセス) SceneView SceneViewで以前の記事「 AndroidでSceneViewを使って、3D/ARを表示する 」で書いた通りで、Materialを作成しないといけないです。 class ExoPlayerVideoMaterial( engine: Engine, exoPlayer: ExoPlayer, private val materialLoader: MaterialLoader, ) { // SurfaceTexture作成 private val surfaceTexture = SurfaceTexture( 0 ).apply { detachFromGLContext() } // SurfaceTexture→Surface作成 private val surface = Surface(surfaceTexture) // Textureのために、FilamentのStream作成 private val stream = Stream.Builder() .stream(surfaceTexture) .build(engine) // Texture作成 private val texture = VideoTexture.Builder() .stream(stream) .build(engine) // VideoTextureを使ったMaterialInstance作成 val videoInstance get () = materialLoader.createVideoInstance(videoTexture = texture).apply { setExternalTexture(texture) } init { // ExoPlayerのSurface設定 exoPlayer.setVideoSurface(surface) } } SceneviewexampleTheme { // ExoPlayerの設定 val player = remember { ExoPlayer.Builder(context).build().apply { repeatMode = Player.REPEAT_MODE_ALL } } // さっきの作成したExoPlayerVideoMaterial val videoMaterial = ExoPlayerVideoMaterial(engine, player, materialLoader) val videoNode = PlaneNode( engine = engine, // 動画は16:9のため size = Size( 16f , 9f ), // NodeのMaterialInstance設定 materialInstance = videoMaterial.videoInstance, ) ARScene( //... childNodes = rememberNodes { // ノードの追加 add(videoNode) }, ) } 結果） SceneCore ExoPlayerの .setVideoSurface() を使うと Surface に再生できます。SceneCoreには SurfaceEntity があり、 Surface を提供するため、ExoPlayerを接続してXRで再生できます。 Subspace { val session = LocalSession.current ?: return @Subspace val capabilities = LocalSpatialCapabilities.current val context = LocalContext.current // 作成した SurfaceEntity を保持 var surface by remember(session) { mutableStateOf<SurfaceEntity?>( null ) } // ExoPlayer はコンポーザブルのライフサイクルに合わせて1つだけ val player = remember { ExoPlayer.Builder(context).build().apply { repeatMode = Player.REPEAT_MODE_ALL } } // Lifecycleのため DisposableEffect(session) { onDispose { player.clearVideoSurface() player.release() surface?.setEnabled( false ) surface?.parent = null surface = null } } LaunchedEffect(session, capabilities.isContent3dEnabled) { // Full Spaceモードの切り替え if ( ! capabilities.isContent3dEnabled) { session.scene.requestFullSpaceMode() return @LaunchedEffect } if (surface == null ) { // SurfaceEntity val surfaceEntity = SurfaceEntity.create( session = session, pose = Pose( // Positionを設定する Vector3( 0f , 0f , - 1.5f ), ), // 動画は16:9のため shape = SurfaceEntity.Shape.Quad(FloatSize2d( 16f , 9f )), ) // Scaleを設定する surfaceEntity.setScale( 0.25f ) // 最初の黒塗りを避けるため、1フレーム目まで非表示 surfaceEntity.setEnabled( false ) // ExoPlayerをSurfaceEntityに接続して再生（res/raw/video.mp4） val uri = RawResourceDataSource.buildRawResourceUri(R.raw.video) player.setVideoSurface(surfaceEntity.getSurface()) player.setMediaItem(MediaItem.fromUri(uri)) player.prepare() player.addListener( object : Player.Listener { override fun onRenderedFirstFrame() { screen.setEnabled( true ) } }) player.play() surface = surfaceEntity } } } 結果）Android XRで動画を表示できました！🎉 動画を表示するために、 SceneView と SceneCore の主な違いは以下となります。 SceneView SceneCore ExoPlayerの表示方法 VideoNode がコメントアウトされているので、動画再生用の Material を作成必要があります。 SurfaceEntity を使うと、簡単に動画再生できます。 まとめ SceneViewはメンテナンスされていないので、SceneCoreは有力な代替です。書き方はおおむね似ており、Googleが作っているライブラリです。ただし前述のとおり、Android XRに対応したデバイスでのみ動作します。一般的なスマートフォンでは実行できませんが、ぜひEmulatorで試して遊んでみてください！ モバイルチームは開発する仲間を募集しています！ open.talentio.com open.talentio.com

この記事は  Safie Engineers' Blog! Advent Calendar  の5日目の記事です。 はじめまして、クオリティマネジメントオフィス QCDグループの稲員です。 この記事を書こうと思った理由ですが、 2025年1月にセーフィーのQAチームにジョインしてしばらく経ちましたので、おじさんのQAエンジニアがセーフィーのQAチームでどんなことに取り組んできたか振り返ろうと思いました。 チームのテスト活動を改善するためにどのような施策を実行してきたのかを共有することで、QAエンジニアの方々や開発チームの方々にとって何かしらのヒントになれば幸いです。 MagicPodでのテスト自動化 QAフローの改善 スクラムの改善 MagicPodでのテスト自動化 QAを担当することになったシステムはちょうどテスト自動化をやろうというフェーズだったため、そのキャッチアップから行いました。 採用しているツールが「MagicPod」というもので、下記のような特徴があります。 AIによるスクリプト作成支援＆自動修復 インストール不要な手軽さと、クラウドの端末やブラウザを使ってすぐにテスト作成可能 Webアプリ・モバイルアプリに対応 MagicPodは手軽さと直感的な操作ができるということで、こちらは低い学習コストで実装できるようになりました。MagicPodに詳しいメンバがオンボーディングをしてくれたのも大きかったです。 共有ステップや変数の活用、上手なデータ分割などテクニカルに使いこなそうとするとまた技術は必要になってきます。 一通りテストの自動化が完了できて、日々の運用にのせるというところが実現できたのはチームメンバの作業時間を日々固定で押さえたのが良かったと思います（強制労働） 日々固定の時間を確保して良かったポイントは以下です。 実装で困っているところを質問して解消しやすい 実装を進めるモチベーションになる 全件成功した朝は気持ちが良いです。鳥も猫もうれしそうです。 この「自動化の時間」があるおかげか、テスト自動化実装が終わった後に大きめの改修があってもテスト自動化は腐ることなく、運用を継続できています。 QAフローの改善 他に取り組んだのがQAフローの改善です。 部の目標であったテストにまつわる”工数削減”、”品質向上”、および現場の”不”の解消という軸で改善に取り組みました。 施策の一部 工数削減の方では自分でもっとこうしたいなと感じたことや、振り返りミーティングでメンバーから話題に上がったものを改善事項としてピックアップしました。 上記の改善が落ち着いてからはNotebookLMを使ってナレッジをまとめよう、非機能要件のテスト観点をシステマティックに盛り込もう、AIに不具合分析させよう、AIにテストケースレビューさせよう、などに取り組んでいます。 テスト設計で変えたところですと、改修内容によってはテストケースの粒度を大きくしてテストケース作成の工数を減らすようにしました。 テスト実施の方ではお客様はFirefoxをほとんど使用されていないという事がデータから分かったため、リグレッションテストは自動テストに任せて、手動でのテストを大きく減らしました。 テストの時間はいくらでもかけられますが、必要十分なテストを少ない時間でやるということを意識しています。 スクラムの改善 最後にスクラムの改善ということで朝のデイリースタンドアップの中に「チェックアウト」のコーナーを作るようにしました。 チェックアウトは”何を話しても良いよ”というコーナーで当番制です。 QA関係のお話をすることもあれば、好きな漫画や映画、最近話題の○○、おしゃれになりたいんやけどみんなどこで服買ってる、アタック25形式のクイズ勝負やろうや、猫の肛門から分泌される”肛門液（？）”がなんか足に付いててすごい臭いんですが、などなど朝から笑いが起きたりしていて楽しみな時間になっています。 これはチームの心理的安全性を高めるのに一役買っていると思います。 これらの取り組みを通じて、チーム全体が改善活動に対する意識を高め、より良いQAプロセスを追求する文化が醸成されつつあります。現状に満足せずに今後も継続的に改善を重ねていく予定です。 この数か月は、単にテストをするだけでなく、新しいチームとして成長するための基盤を築く期間でした。今後もより良いプロダクト品質とテスト品質を追求し、開発チームと共にお客様のカメラ管理を楽にする素晴らしいプロダクトを世の中に届けていきたいと思います。

この記事は  Safie Engineers' Blog! Advent Calendar  の4日目の記事です。 こんにちは。カルチャー＆コミュニケーション室の おかだみかこ です。 カルチャー＆コミュニケーション室は、社長直轄組織として社内外の広報活動等を担当しているチームです。「映像から未来をつくる」というセーフィーのビジョン実現に向けて「セーフィーカルチャー」を推進する活動も内包しています。 私は2025年4月、ちょうど当社の社員数が500名を超えたタイミングでセーフィーに転職しました。セーフィーが上場した2021年から比べると社員数は2倍以上。ビジネスも組織も圧倒的なスピードで成長している会社に入社したなあと思ったのを覚えています。 一般的に、組織が拡大すると「隣のチームが何をしているか分からない（サイロ化）」や「経営の意図が伝わらない」といった課題が生まれがちです。 多くの企業では社内報といえばテキストが多いと思いますが、私たちは「映像データ」を扱うテック企業として、テキストでは削ぎ落とされてしまう「熱量」や「文脈」こそが重要だと考え、「動画」による社内コミュニケーションを行ってきました。ということで、今回は私が担当している社内動画メディア「空フク」についてご紹介します。 「空フク」とは 現状把握のためのアクション 現在までに実施したこと 信頼関係をレバレッジする「公式発信」よりも「知っている人」 「動画の弱点」を補完する＋αの要約テキスト コミュニケーションは続けること 「空フク」とは 端的にいうと、「空フク＝動画社内報」と考えていただくとイメージがしやすいかと思います。スタートしたのは2023年10月で、今まで2年以上に渡り継続して社内向けの発信を続けてきました。 「空フク」は通称で、正式名称は「空飛ぶフクロウ~Safie's company newsletter~」です。セーフィーのシンボルマークでもお馴染みの「フクロウ」は知恵の象徴とされています。「空フク」の名前には、社員一人ひとりが持つ知恵をシェアし、お互いの知恵の循環を通じて、社内コミュニケーションを活発にしていきたいという想いが込められています。 空フクは2つのカテゴリで構成されています。 Sadoxサロン 社長の佐渡島さんがスピーカーとして語るコンテンツ フクロウたちの知恵泉 社員の活躍、部署の取り組みを語るコンテンツ 左：Sadoxサロン「2030年目指すこと_ストレッチ組織の課題と解決にむけて」 右：フクロウたちの知恵泉「デザインセンター_ロゴデザインの思想と、セーフィーがつくるデザインとは」 現状把握のためのアクション 私が担当になってまず行ったのはアンケートです。社員の「空フク」活用状況を知り、今後の企画において参考とするために行うことにしました。 結果として、90％以上の人が認識しており、社員の2/3は何らかのコンテンツは見たことがあるというポジティブな回答が得られました。一方で「見たことがない！」という社員も少なからずいる状況がわかりました。見る機会がなかった人は大きく分けると以下の3つに分類されることも把握できました。 忙しく見る時間がない 更新タイミング不明 そもそも存在を知らなかった 届ける相手である「社員」の皆様の声を確認したことで、実際に活動の方向性を決めることにも繋がったため、初手でアンケートをとったことは非常に有用でした。 現在までに実施したこと アンケートを実施した5月から現在まで、まずは短期目線ですぐにできることからアクションを行ってきました。大きく分けると「告知の工夫」と「さまざまな社員が登場する企画」です。このブログでは「告知の工夫」にフォーカスしてもう少し詳しくお話ししたいと思います。 信頼関係をレバレッジする「公式発信」よりも「知っている人」 突然の話ですが、友人から手紙を渡されたとしたら、そりゃ必ず目を通しますよね。それと同じで同じチームや関係性の深いメンバーからのSlackは目につくと思うのですが、あんまりよく知らない人からの全体に向けたSlackは見落としがちではないでしょうか。 「空フク」の告知は社内のSlackを活用して発信していますが、全体メンションでの私からの告知は、情報の「ノイズ」として処理されてしまう可能性があると感じていました。 そこで着目したのが、社内における「ソーシャルグラフ（人間関係のつながり）」の活用です。担当者から言われるより、普段関わりのある同僚から「出演したので見てください」と言われた方が、圧倒的に視聴意欲が湧くはず。 アナログな手法ですが、「出演者に告知協力をお願いする」というフローを組み込むことで、「点」の発信を「面」の広がりに変える工夫を取り入れました。 最近も、出演者からではないのですが、社員の方が面白いよとご自身のチームに発信していただいたことでアクセスが急増したケースがありました。そういう循環をもっと増やしたい。そのための前提としては社員の皆様が「これいい！」と思ってもらうコンテンツが重要です。企画自体も力を入れていますが、引き続き良いコンテンツ作りには特に時間を割いていきたいと感じました。 「動画の弱点」を補完する＋αの要約テキスト 映像は圧倒的に得られる情報量が多いのがメリットです。一方で、「忙しい時に手を止めて動画を見るのは正直しんどい。倍速だとしても」というのは正直あるのではと思います。 そのため、空フクNotionページで公開する際に、興味があるトピックかどうかを数秒で判断できるように「動画で話されていること」を箇条書きで添えるようにする工夫もはじめました。 また、要約の作成にはNotebookLMに編集した映像を読み込ませて、そこからテキスト案を検討することで効率化も進めています。 コミュニケーションは続けること 担当を引き継ぐ際に前任担当者のコメントで最も印象に残ったことは「継続して発信し続けることを大事にしてきた」という話です。首がもげそうになるくらい同意をしました。それは、私もコンテンツの発信は継続して続けていくことが大事だと思っていたからです。 現在、セーフィーは開発本部を含めた5つの本部、500人以上の社員がいる会社に成長し、ビジネスも組織も更なる飛躍に向けてみんなで歩みを加速させています。 最後になりましたが、社内の戦略や開発秘話なども含まれるため、「空フク」を見ることができるのは社員だけの特権です。セーフィーのお仕事にご興味がある方は 採用サイト もぜひご覧ください。 safie.co.jp この記事を読んでいただいた方が、仲間となり動画を見たり、はたまた出演者として登場したりとする日が来るのを楽しみにしています。 今後もより「面白い」「役立つ」「楽しい」空フクの発信を期待していただけると嬉しいです！

はじめに この記事は Safie Engineers' Blog! Advent Calendar の3日目の記事です。 こんにちは、技術広報のたかぎ（ @hitsan ）です。 2024年の中盤から技術広報をはじめ、2025年はセーフィーにとって 「技術広報活動を本格始動させた年」 という、非常に大きな節目の1年となりました。 これまでも技術発信は行ってきましたが、今年は発信数を増やすことに注力しました。 本記事では、セーフィーの技術広報が掲げるミッションと、2025年に取り組んだ具体的な施策について振り返ります。 はじめに セーフィーにおける技術広報のミッション ファンを増やし、すごいを広げる 2025年の活動 1. イベント登壇数を増やしたよ 2. 技術広報専用Xアカウントをつくったよ 直近のイベント情報 BASEとセーフィーが語るバックエンド開発の技術的負債解消への道のり 生成AIで業務を改善しNight！ さいごに セーフィーにおける技術広報のミッション ファンを増やし、すごいを広げる 技術広報として掲げている最大のミッション、それは 社内外にセーフィーのファンを増やすこと です。 この言葉には2つの意味が込められています。 「セーフィーって技術的に面白い会社だね」と認知してもらうこと。 エンジニア自身が自分たちの開発しているプロダクトはすごいと胸を張れる状態を作ること。 どれほどがプロダクトが良くても伝わらなければファンは増えません。このミッションを達成するために、以下のような3年計画を策定しました。 年度 フェーズ 2025年 発信文化の醸成 2026年 聞き手を意識した発信 2027年 テックブランドの確立 2025年の活動 2025年のテーマは「土壌づくりと発信文化の醸成」です。 文化を作るためには、まず行動の総量を増やす必要があります。そこで打席数を増やしました。 発信数（打席）が増えれば、「自分たちは技術発信をする組織だ」という認識が生まれる 第三者の目に触れることで、「自分たちが当たり前にやっていることは、実はすごいことなんだ」と気づける これらを実現するために、具体的に実行した施策をご紹介します。 1. イベント登壇数を増やしたよ 今年はイベントへの参加・開催数は昨年と比較して2倍になりました。 2024年までは依頼があれば登壇するというスタンスでした。2025年からは他社と共催してイベントを企画するようになりました。 企画から行うことで、ターゲット層や伝えたい技術テーマをコントロールできるようになり、以下のようなトピックを深く掘り下げることができました。 映像解析アプリケーションの開発プラットフォーム構築の紹介 若手エンジニアの活躍 大規模プロダクトにおける技術的負債の解消 企画から携わることで、参加者からのフィードバックをエンジニアへ直接還元するサイクルも作れています。 2. 技術広報専用Xアカウントをつくったよ 先月、セーフィー技術広報アカウント（ @SafieDev ）を新たに開設しました。 はじめまして！このアカウントは、セーフィーの技術情報やエンジニアの取り組みを発信するアカウントです🎉 エンジニアの皆さんが気になる情報をお届けします。 ぜひお気軽にフォローしてください！ #セーフィー #エンジニア #開発者 #技術広報 — セーフィー技術広報 (@SafieDev) 2025年11月7日 これまでは企業公式アカウントから発信していましたが、以下の理由から独立させました。 エンジニア、PdM、デザイナーに特化した情報を届けたい エンジニアの日常的な取り組みや試行錯誤も発信したい 企業の公式アカウントよりも高頻度で投稿したい アカウントを分けたことで、テックブログの更新情報やイベント情報に加え、開発現場の空気感が伝わるような発信を強化しています。ぜひフォローをお願いします！ 直近のイベント情報 12月は注目のイベントを2件開催します。ぜひご参加ください。 BASEとセーフィーが語るバックエンド開発の技術的負債解消への道のり 明日、12/4(木)にBASE株式会社様と共催でバックエンドの技術的負債にフォーカスしたイベントを開催します。セーフィーからは、大規模リアーキテクチャの取り組みについて紹介予定です。 safie.connpass.com 生成AIで業務を改善しNight！ 12/15(月)には、生成AIを活用した業務改善イベントを開催します。 こちらはLTやセッションではなく、ワールドカフェ形式を採用。参加者全員で業務改善のアイデアをディスカッションする参加型イベントです。 safie.connpass.com さいごに 2025年の活動を振り返りましたが、正直に言えば、全員が自然と発信する文化にはまだ到達できていません。 今年はイベントという場を用意し、打席数を増やすことには成功しました。しかし、それが組織全体の習慣として定着し自走していくまでには、まだいくつものハードルがあります。 まだまだ手探りですが、これからも走り続けるので2026年のセーフィーの技術発信にも、ぜひご期待ください。

この記事は Safie Engineers' Blog! Advent Calendar 2日目の記事です。 はじめに 私にできること 新たに作ったもの アプリの紹介 作ったきっかけ 作り方 AWS Bedrockでお題を生成 Next.jsでUI実装 AWS Amplifyでデプロイ 終わりに はじめに こんにちは！セーフィーに25新卒で入社し、AI開発部に配属された川上です。 学生時代は研究で、人の歩き方を解析するAIの開発をしていました。 そして配属前に行われた研修では、社内備品を管理するアプリTreasure Collectionを開発しました。（Treasure Collectionの記事は後日掲載されるのでぜひご一読ください。） この記事では私が新たな技術領域を身に付けるためにアプリの開発に挑戦した話をしたいと思います。 私にできること 先に述べたように、学生時代はPythonをつかって映像の研究をしていました。そして研修のTreasure Collectionの開発では、入社するまでに体験したことがなかったフロントエンド領域を担当しました。研修を終えて、フロントエンドとバックエンド（データ処理）の領域を経験したエンジニアになれました。 しかしながら、インフラ領域が分からないという気づきも得ました。 Treasure CollectionはWebアプリで、デプロイなどのインフラ回りはすべてチームメンバーが実装してくれました。フロントエンドの技術は身につけられましたが、アプリをユーザーに届ける方法が分からないという状況になりました。 新たに作ったもの これから、研修を終えた後に開発した ice-breaker というWebアプリの紹介をします。このアプリを作ったことで新たな技術領域を体験でき、ユーザーに作ったものを届けられるようになったのでそこを共有できればと思います。 アプリの紹介 ice-breakerはミーティングなどの冒頭で行うアイスブレイク・チェックインのお題を提供します。 アイスブレイクとチェックインは少し異なるものですが、大まかに以下のように説明できます。 アイスブレイク、チェックインとは 目的：集まりの冒頭で、参加者の間の緊張をほぐし、場に活気や一体感を生み出すこと。 特徴：「場」の雰囲気づくりに焦点を当てる。 多くの場合、ゲームや簡単なアクティビティ形式で行われる。 参加者同士が気軽に話せるきっかけを提供し、本題に入る前の心理的な障壁を取り除く。 このアイスブレイク、チェックインはセーフィーに入社してから何度も行ってきました。そしてこの度、アイスブレイク、チェックインに役立つアプリを開発しました。 アプリにアクセスすると次のような画面が表示されます。 画面左側の“話題を生成”ボタンを押すとボタンの下にお題が表示されます。 参加者一覧に名前を入力し”追加”ボタンを押すと参加者が追加されていきます。 “次の発表者”ボタンを押すとボタンの左に次の発表者が表示され、発表済みに発表者が追加されます。 “次の発表者”ボタンを何度か押して、全員が発表済みに追加されると”終了！全員話し終わりました”と表示されます。 作ったきっかけ 配属前に行っていた研修の週次定例の冒頭に、10分程度のアイスブレイクを行っていました。 アイスブレイクのお題はその都度考えていたために、お題に困ることがありました。 また進め方はお題を考えた人が最初に発表して、発表した人が次の発表者を指名するという方式をとっていました。この進め方はアイスブレイクが盛り上がるいい方法でした。しかし、「全員発表した？」と確認したり「次誰にしよう」と悩んだりして、時間を使ってしまうためにアイスブレイクの予定時間を少し超えてしまうという問題もありました。 行っていたアイスブレイクのよさを保ちながら、困りごとを解決するためのアプリを作ってみようと思ったことがこのアプリを作ったきっかけです。 作り方 ここからはアプリの作り方を説明します。 AWS Bedrockでお題を生成 まず、アプリの核となるお題の生成についてです。 お題の生成は生成AIで行っています。生成AIはAWS Bedrockから利用しました。AWS Bedrockにアクセスし、APIキーを発行します。 Next.jsでUI実装 UIはNext.jsで実装しました。Next.jsを使った理由は研修で唯一身につけたフロントエンドの技術スタックだからです。 アプリの構成は以下のようになっています。 src/app/ ├── page.tsx # メインUI（クライアントコンポーネント） ├── api/ │ └── bedrock/ │ └── route.ts # Bedrock API呼び出し（サーバーサイド） └── components/ ├── addNames.tsx # 参加者追加コンポーネント └── participants.tsx # 参加者表示コンポーネント UIはシンプルなのですべての紹介は控えますが、工夫したことを2つ紹介します。 同じ話題が表示されないようにプロンプトを改善 api/bedrock/route.ts ではAWS BedrockのAPIにプロンプトを含んだ、API Requestを送信しています。そのコードは以下のようになっています。 import { BedrockRuntimeClient, ConverseCommand } from "@aws-sdk/client-bedrock-runtime"; import { NextRequest, NextResponse } from "next/server"; export async function POST(request: NextRequest) { try { const url = "xxx"; const history = (await request.json()).history || []; const payload = { "messages": [ { "role": "user", "content": [{"text": "ちょっと変わったアイスブレイクの話題を1つ返して。" + "過去の話題履歴: " + history.join(", ") }] } ], "inferenceConfig": { "temperature": 1.0, "maxTokens": 500, "topP": 1.0, } }; const response = await fetch(url, { method: "POST", headers: { "Content-Type": "application/json", "Authorization": `Bearer ${process.env.NEXT_PUBLIC_API_KEY}` }, body: JSON.stringify(payload) }); const data = await response.json(); return NextResponse.json({ output: data }); } catch (error) { console.error("API Error:", error); } } 過去の話題履歴を page.tsx と連携してプロンプトに含めながら話題を何度か生成したときに同じ話題が表示されないようにしました。 Next.jsのサーバーサイドからAPI Rrequestを送信 以下のコードは page.tsx に実装した、話題を生成するときに実行される関数です。この関数ではまず api/bedrock にAPI Requestを送信します。これはNext.jsのサーバーサイドで実装されているAPIです。 const onGenerate = async () => { setloading(true); const data = await fetch("/api/bedrock", { method: "POST", headers: { "Content-Type": "application/json", }, body: JSON.stringify({ history: history, }), }) .then((res) => res.json()) .then((data) => { setResult(data.output.output.message.content[0].text); setHistory([...history, data.output.output.message.content[0].text]); }) .catch((error) => { console.error("Error fetching data:", error); }); setloading(false); }; 先に説明したようにAWS BedrockへのAPI Requestの送信は api/bedrock から行われます。 このようにAPIを経由してAWS Bedrockを利用していることには理由があります。それはAWS Bedrock への API Requestの送信はフロントエンドから行えないからです。セキュリティ上の理由でその仕様になっています。 今回開発に用いたNext.jsでは別途バックエンドサーバーを立てずにサーバーサイドにAPIエンドポイントを立てることができます。図らずも、開発中に生じた課題が解決され、スムーズな開発を進めることができました。 AWS Amplifyでデプロイ ローカル環境で動作確認を完了したら、デプロイの準備です。 デプロイはAWS Amplifyで行いました。AWS Amplifyを使って想像以上に手軽にデプロイを行えました。 AWS AmplifyへはGithub経由でアプリをデプロイできます。 作成したアプリをGithubへpushしたら以下のAWSのマニュアルに従って設定を行います。 https://docs.aws.amazon.com/ja_jp/amplify/latest/userguide/setting-up-GitHub-access.html#setting-up-github-app 設定後にAWS Amplifyにアクセスし、以下の流れでAWS Amplify上にアプリを作成します。プロバイダーはGithubを選択しました。 ここまで進めて、問題がなければすべてのアプリから、デプロイが始まっていることが確認できます。5分程度待つと、デプロイ済みに変わっていました。 この時点でもアプリはデプロイされアクセスすることができますが、もう一つ必要な設定があります。 環境変数の設定です。 すべてのアプリから、デプロイしたアプリをクリックします。サイドメニューのホスティング、環境変数を選択して、以下の画面に遷移します。 ここで変数はローカル環境で使う.envファイルで決めた変数名です。値は取得済みのAWS BedrockのAPIキーを入力します。 ここまで行うとアプリはローカルと同じように動作します。デプロイ・リリースの完了です。 終わりに この記事では私が初めて自身の力でデプロイを行ったアプリの紹介をしました。 アプリを作ってみて考えたことが大きく2つあります。 1つ目はソフトウェアサービスの理解度が上がったことです。これまではどうやったらサービスとして動作するんだろうという漠然とした疑問を抱えながら開発などを行っていました。そこをどうやったらいいか、手段を1つでも知れたことはとても良いことだと思います。 2つ目は別のAWSサービスも利用したいと思ったことです。私はAI開発に長い間携わってきましたが、それらはローカル環境のマシンで動作させるだけでした。これを機にオリジナリティを持ったAIを使ったアプリをユーザーに届けてみたいと思いました。 私がセーフィーに入社して8カ月経ちましたが、その間新しい技術領域を体験し身に着けながら課題解決に取り組めています。この記事を読んでいただいた人にとって、セーフィーで働きながらどのように技術を身に着け成長できるかが伝わると幸いです。

この記事は Safie Engineers' Blog! Advent Calendar  1日目の記事です。 はじめに そもそも「1on1」とは？ 定義の再確認 1on1 のゴール（ありたい姿） 人にフォーカスした対話型1on1のすすめ 具体的な質問例１：「最近どう？」をより良くする工夫 具体的な質問例２：未来志向への誘導 1on1 は組織開発の最前線 最後に はじめに セーフィーの VPoE 兼 開発本部 エンジニアリングオフィス 室長の武田です。 2023年にセーフィーに入社し、エンジニア組織の組織開発に取り組むエンジニアリングマネージャーとして活動しています。セーフィーでは創業当初から 1on1 文化 が根付いており、私自身2025年には600件以上の1on1を実施しました。前職を含めたエンジニア組織開発の経験と、コーチングや本質行動学などの学びを活かしたトライ＆エラーから得た、1on1の本質をご紹介します。 そもそも 「1on1」とは？ 定義の再確認 私が考える1on1の定義は以下の通りです。 💡 1on1とは？ 1on1とは、メンターとメンティーが定期的にマンツーマンで行うミーティングのこと。 人事評価を目的とした面談とは異なり、 人の成長促進と組織の活性化 を主な目的とする。上司・部下の関係性に限らず、人と組織の成長を促すための対話の場である。 この1on1の定義には 「これが正解」という型はありません。 1on1では「業務の話はすべきではない」という一般的な風潮もありますが、私はその限りではないと考えます。 なぜなら、メンティーが目の前の業務で困っているのに、それを解決してくれるかもしれない人に聞けないのはフラストレーションがたまるだけ。無理にキャリアの話に誘導するより、 メンティーが本当に求めている話 をすることが、結果的に成長につながります。 1on1 のゴール（ありたい姿） では、目指すべき1on1のゴール（ありたい姿）は何でしょうか。 それは 「次も1on1をしたい」 と思ってもらえる状況を作ることです。 1on1は、一度きりのイベントではなく 継続してこそ意味のあるもの になります。 前向きさを維持し、対話を重ねることで初めて、人の成長と組織の活性化という目的に近づけます。 メンターのスタンス メンティーの状況に合わせて臨機応変に対応する 具体的な行動 業務の話も、キャリアの話もする。コーチングもすれば、ティーチングもする 重視すること その瞬間や1on1直後に心地よい時間を作ることではない、時にはネガティブなフィードバックも必要 目指す状況　 対話後、時間経過と共に気づきがあり、行動変容を促し、結果が伴うこと。そして、対話が継続できていること。 人にフォーカスした対話型1on1のすすめ 「次もやりたい」と思ってもらうためのコツ、それは 「対話しやすい状況」 を作ることです。 対話しやすさの鍵は、「事（コト）」ではなく 「人（ヒト）」にフォーカス した質問をすることにあります。 ✅ 「事」への質問 vs. 「人」への質問 例えば、メンティーが「釣りに行ってきました」と話した場合の質問例です。 質問の焦点 具体的な質問例 メンティーの受取られ方 事　(コト)　 - どこ行きましたか？ - 釣れましたか？　　　　 事実の深堀り 人　(ヒト)　 - 楽しめましたか？ - 釣り好きなんですか？ 自分に向き合ってくれている と感じ、話しやすくなる 人の 感情（楽しい、好きなど）に寄り添う 質問を意識するとより話がしやすくなります。 例えば仕事で失敗したときはなぜ失敗をしたのか？ではなく、その時どう思った？どう感じたか？なぜそう感じたのか？メンターの自分はどう思ったか（例えば悲しかったとか）など、お互いの感情を深堀しシェアすることでより人に向き合えるようになります。 具体的な質問例１：「最近どう？」をより良くする工夫 1on1 の初めに「最近どう？」から始まることはよくあると思います。 ただ、この「最近どう？」だけでは、少しもったいないです。 最初の導入として、ぜひ メンターの所感 を付け加えてほしいです。 そうするとメンティーはより話しやすくなります。これは、 メンターの気持ち（感情）を先に伝えている ことで、共感を生みやすくスムーズな対話につながる効果があります。 より良い質問例 ポイント 最近どう？ 〇〇定例での××の発表良かった。内容もだけど イキイキ話していて感動したよ ポジティブな所感 を伝え、話すきっかけを作る 最近どう？ 残業時間が多くなっているようなので ちょっと心配 懸念点（心配） を伝え、安全な場で話すことを促す ❌ 注意すべき質問例 「最近どう？元気がないように思うけど大丈夫？ 何かあった？ 」は良い質問ではありません。 なぜなら「何かあった？」は、 事の深堀り につながるからです。本当に元気がないときは、日常の小さなことの積み重ねであることが多く、「特別なことはありません」という回答で対話が終わってしまう可能性があります。 　　〇 最近どう？元気がないように思うけど大丈夫？ 心配です。 心配している気持ちを正直に伝えて反応を待ちましょう。 補足 ちなみに私は1on1が始まる前にその人のGoodポイントを探すという事前準備をよくやります。ネガティブな情報は広がりやすいですが、ポジティブな情報はなかなか表に出てきません。1on1でポジティブ情報が交換できれば組織全体の雰囲気にもつながります。ぜひ、EMはポジティブ情報を常に拾って1on1につなげてほしいと思います。 具体的な質問例２：未来志向への誘導 1on1は過去の振り返り（ふりかえり）になりがちで、ワクワクしにくい傾向があります。過去の結果は分かりきっているからです。 できるだけ 未来の話 に誘導しましょう。 質問例 目的 前回から今回までの 自己満足度、何点 ありますか？（100点満点で） メンティーの現状認識を引き出す （例：60点と回答）40点足りていないけど、その 40点を増やすためには何が必要ですか？ 私も一緒に協力できることありますか？ 次回までの Next Action をメンティー主体で決め、 未来の話 へ誘導する ここでのポイントは、メンティー側だけでなく、 メンター側のNext Actionも決めること （小さなことでOK）。お互いのコミットメントにより、一体感が生まれます。 1on1 は組織開発の最前線 会社や組織は人の集まりであり、 組織＝人 です。 1on1は、その人のことを知るための 一番の手段 であり、組織開発の最前線です。1on1が機能することで情報が流通し、組織が活性化するきっかけになります。 ぜひEM（エンジニアリングマネージャー）の皆さんには、この1on1を使いこなしてほしいと思います。 正解がないからこそ面白い！ この記事が、あなたの1on1を楽しむきっかけになれば幸いです。 📝 まとめ：人に向き合う1on1の5つの要点 1. 基本スタンス　 1on1のやり方に正解はない (メンティーの状況に臨機応変に対応する) 2. 目的　　 人（と組織）が成長するために、人（と組織）に向き合う時間。 3. ゴール　 「次も1on1をしたい」 と思ってもらうこと（継続による成長と成果） 4. コツ 　　 「事」ではなく 「人」にフォーカス した質問で、より 共感と気づき を与える 5. 価値 　　 組織開発の最前線として、 情報流通と組織活性化 のきっかけとなる 6. 願い　　 1on1 自体を楽しもう！ 最後に 本記事では、私が取り組んでいる1on1の実践の一部をご紹介しました。 1on1 は奥深く自分自身もまだまだ足りていない部分があり、常にふりかえりを実施中です。 また、ポイントはほかにもある（例えば、1on1 の情報をどう他の人にシェアして組織変革に使っていくか）と考えており日々奮闘中です。またいつか別の機会にご紹介できればと思います。 最後に宣伝です！セーフィーでは 一緒に働く仲間を募集中 です！ 少しでもご興味を持っていただけたら、ぜひ以下の 採用サイト を覗いてみてください。

はじめに こんにちは。セーフィーでサーバーサイドエンジニアをしている金成です。 本記事は、ffmpegを初めて使う方や、360度カメラのデワープ処理について学びたい方を対象にしています。専門的な知識は不要ですので、ぜひお気軽にお読みください。 セーフィーでは、半天球カメラなど、魚眼レンズを用いて広範囲を撮影する360度カメラの映像も取り扱っています。そのため、このようなカメラの画像や映像をデワープ (歪みを補正し、歪みの少ない映像に変換すること) するユースケースが存在します。仕事をする過程で、ffmpegのビデオフィルターを使った変換について調べたのでこちらで共有いたします。 はじめに ffmpegとvfオプションについて デワープの具体的な手順 まとめ ffmpegとvfオプションについて ffmpegは、動画や音声を記録・変換・再生するソフトウェアで様々な処理を行うことができます。その中でも、vfオプション(video filter オプション) は、入力に対し、映像を拡大する、一部分を切り取る、色を補正するなどの処理(フィルター) を適用することができる機能です。 簡略化すると、下記のようなシンタックスでオプションを指定することができます。 -vf <フィルタ名>=<フィルターごとのオプション> (実際にはもっと複雑な指定が可能です。詳細は公式サイトをご参照ください。 https://ffmpeg.org/ffmpeg-filters.html) 例えば、cropフィルターであれば、下記のようなコマンドで画面の一部を切り取った映像を作ることができます。 ffmpeg -i input.mp4 -vf crop=500:500:100:100 output.mp4 vfオプションの中には、v360フィルターがあり、360度カメラで撮影された魚眼などの映像をデワープされた映像に変換することができます。 デワープの具体的な手順 360度カメラの映像と環境の準備 今回は、ffmpegコマンドを使った360度カメラの変換について説明します。 利用するツールのバージョンは下記になります。 ffmpegのバージョンは7.1.1です。 デワープのためのffmpegコマンドの記述 デワープのためのffmpegコマンドの記述 今回は、v360フィルターを使って、半天球カメラなどで撮影された「魚眼 (fisheye)」形式の映像を歪みを補正した映像に変換します。 v360フィルターは下記のようなシンタックスで構成されており ‘v360=<入力の形式>:<出力の形式>:<key=valueで指定したオプション> といった形式で指定できます。 例えば、下記のコマンドであれば指定したオプションで、魚眼 (fisheye) の映像からデワープされた通常の映像に変換されます。 ffmpeg -i input.mp4 -vf ‘v360=fisheye:flat:v_fov=50:yaw=50’ output.mp4 v360フィルターでは、下記のような入力/出力先が用意されています。 e / equirect => Equirectangular projection flat / gnomonic / rectilinear => regular video fisheye => 魚眼 pannini => Pannini projection. and etc 入力/出力形式ごとに必要なパラメーターが変わり、様々な変換を行うことができます。 v360のフィルターでは、共通でyaw/pitch/roll などのカメラの視点をコントロールするオプションや、カメラの回転を制御するオプションがあります。 今回使用する flatフィルターでは、特にデワープ後の調整を行うため、出力するカメラの画角を以下のオプションで制御できます。 v_fov (垂直画角) h_fov (水平画角) d_fov (対角画角) これらのオプションを利用することで、変換後の映像を細かく調整することが可能です。 コマンドの実行例 例1: 上下の振り向け ffmpeg -i input.mp4 -vf v360=fisheye:flat:v_fov=50:pitch=<角度> output.mp4 例2: 左右の振り向け ffmpeg -i input.mp4 -vf v360=fisheye:flat:v_fov=50:yaw=<角度> out.mp4 例3: 右に振り向けた映像の左半分だけを切り取る ffmpeg -i input.mp4 -vf v360=fisheye:flat:v_fov=50:yaw=30,crop=iw/2:ih:0:0 output.mp4 まとめ このように魚眼の映像など360度カメラで撮影した映像は、簡単にデワープすることができます。画像や動画の変換に役立てていただければ幸いです。 セーフィーでは、このような映像解析技術を活用し、より高度なサービスを提供しています。興味をお持ちいただけましたら、ぜひ採用情報もご覧ください。

はじめに こんにちは、データドリブン推進室でデータエンジニアをやっている鶴です！ みなさん、LightdashのTable calculation機能って使ってますか？ 自分はLightdashを触っていて[+Table calculation]という表記を見かけた際に 「Table calculationってことは表計算機能のことか〜 Tableauとかにもある出力した結果データの中で集計したりするやつかな あると便利だよな…そのうち使う機会くるっしょ〜」 みたいなこと考えてあまり触らずスルーしてました… 同じような方もいらっしゃるのではないでしょうか？ 実はLightdashのTable calculation機能はちょっと面白い機能になっているのでここでご紹介したいと思います！ はじめに Table calculationを触ってみよう テンプレート機能もあります 実はこれだけじゃなかったTable calculation 最後に We are hiring! Table calculationを触ってみよう まずはQuerying from tablesから見たいテーブルを選択し、Resultの右上にある[+Table calculation]を押してみると… こんな画面が出てきます。 つまり出力したデータを使ってSQLを書いて集計する、という感じなんですね。 やはり表計算といえばウィンドウ関数ということで書いてみます！ 今回サンプルで用意したスーパーマーケットデータで売上前日比を作ってみます。 ※本記事に登場する「さくらマート」は、サンプルデータ用に作成した架空の名称であり、実在のいかなる店舗・団体とも一切関係ありません SQLはこんな感じです。編集画面で文字を入力するとサジェストしてくれるので便利です。 ${sample_supermarket_sales.sum_of_total_price} / LAG(${sample_supermarket_sales.sum_of_total_price} OVER(${sample_supermarket_sales.sale_date_day})) このデータはソートを設定しているので一旦ORDER BYは記載せず進めてみます。 フォーマットはパーセント表示にしましょう。 保存して実行するとこんな感じになりました！ またこの作った項目を直接フィルターに設定することができます！ 右上のボタンを押すと[Filter by 売上前日比]があるので押してみると… フィルター欄に追加されました！ これを使って前日売上比100%越えの日を出してみる、なんてこともできます。 テンプレート機能もあります ウィンドウ関数はSQLに慣れていない方だと正直難しい部分がありますよね… ですがLightdashにはテンプレートが用意されてます！ [Sum of total price]の右上のボタンを押すと、Add quick calculationにテンプレートがあります。 Percent change from previous(前からの変化率)をクリックしてみます。 項目が自動で作成されました！ 一応内容を確認するため項目右上を押し、Edit calcultationをクリックします。 内容的には先ほど自分が作ったクエリの内容に近いロジックがあり、それに対して1を引いている形になります。 なお、注意して欲しいのがLAG関数のORDER BYの箇所がDESCになっています。 日付で昇順にしたいためここは消しておきましょう。 ここは見たいものによると思うので適宜調整してください！ 実行した結果はこうなりました。正直こっちの方がわかりやすいですね！w このようにテンプレートをうまく使うとサクッと作れます。 他にもテンプレートはあるのでぜひ公式ドキュメントの 解説ページ をご確認ください。 また今の時代はChatGPT先生やGemini先生などに聞けばわかりやすく教えてくれますし、作ってくれます。有効に活用していきましょう！ 実はこれだけじゃなかったTable calculation さて、ここまで触ってきたTable calculationですが察しの良い方はこのことに気づいているかもしれません… 　SQLで書けるってことはSQLでやれることは割と何でもできるのでは…？ そうです、何でもできます。 たとえばこのようなCASE文を書いてバナナフラグを立てることもできます(Result typeはbooleanにしてます) ストアと商品の文字列を結合するようなテキスト計算もできます(Result typeはstringにしてます) なんか自分が思ってた表計算と違う…！！！！ 集計した項目をさらに好きなようにデータ加工・計算できるので面白いと思います。 また少し前の Lightdashアップデート で作成した表計算項目を再利用できるようになりました。 つまりこうやって先ほど作成したバナナフラグとストアと商品の項目も合わせることが可能です。 作成した表計算結果をさらに計算して…みたいに広げていけるので柔軟性が上がっていいですね！ 最後に Table calculationは定義されたメトリックで対応できなかった集計やデータ加工をカバーする機能となっていて利用される方はこういう機能があると認識されておいた方が良い機能だと思います！ ただ公式ドキュメントにも 記載 がありますがこのTable calculationは一時的なニーズに対応するものとしては良い機能ですが、繰り返し再利用されている場合はdbt側の定義に追加して管理するようにした方が良いので管理者は適宜チェックしておきましょう。 We are hiring! 現在、データドリブン推進室では データエンジニア/アナリティクスエンジニアを大募集中 です！ セーフィーのデバイスやアプリケーションからは1日あたり数十億件のログが発生し、データ量は線形的に増加しています。 このような超ビッグデータを効率的に処理し、ビジネスの意思決定に繋げるための仕組みを一緒に作ってみませんか？ ご興味のある方は セーフィー採用サイト を覗いてみて下さい！ よいLightdash Lifeを〜それではまた！

こんにちは！セーフィーでハードウェア開発を担当している持丸です。 ご存じの通り、「セーフィー」はクラウド録画サービスやソフトウェアを事業の中核とする会社です。 そして当然のように、クラウドやソフトウェアの技術をベースとしたエンジニアの割合が多い会社になります。 しかし、お客様に最高の体験をお届けするためには、映像の入り口となるカメラをはじめとした「ハードウェア」の存在が欠かせません。 今日は、普段あまり語られることのない、セーフィーのハードウェアへの熱い想いと、その品質を支える取り組みについてご紹介したいと思います。 すべては「お客様に寄り添う」ために 「ただ仕入れる」だけでは終わらない、セーフィーの製品評価 仕組みで支える品質。製品評価プロセスの標準化 不具合解析こそ、腕の見せどころ おわりに すべては「お客様に寄り添う」ために 私たちハードウェア担当が最も大切にしているのは、 「お客様に寄り添った製品（ハードウェア）を提供していく」 という、とてもシンプルな方針です。 お客様がどのようなシーンで、どのような課題を解決したいのか。 それを深く理解し、機能や性能はもちろんのこと、長期にわたって安心して使える品質、そして安全性を兼ね備えた製品をお届けすること。 それが私たちの使命です。 セーフィーが提供するハードウェア製品には、他社から購入した製品（一部をセーフィー向けにカスタマイズしたものを含む）と、自社で開発した製品の2種類があります。 今回は、特に他社製品をお客様にお届けする際の、私たちのこだわりについてお話しします。 「ただ仕入れる」だけでは終わらない、セーフィーの製品評価 他社製品を選定する上で、私たちは特に以下の2つのプロセスに多くの時間を費やしています。 お客様の利用シーンの把握と理解 提供する製品の設計思想の読み取り Fig1 なぜなら、この2つのステップを疎かにすると、「思い込み」によって後々大きな問題を引き起こしかねないからです。 「普通はこうのはずだ」といった思い込みを排除し、お客様の本当のニーズと製品の特性を正確に結びつける。 そして、関係者全員がその共通理解の上に立つことが、プロジェクト成功の鍵を握っています。 この考え方に基づき、私たちは以下のようなステップで製品の評価を進めています。 お客様の要求内容を明確にし、文書化する（ユーザー情報） 選択する製品の仕様（機能、性能、品質など）がお客様の要求を満たせているかを確認する（製品情報） カタログスペックだけでは確認できない項目を洗い出し、評価・検証を実施する（追加評価） Fig2 仕組みで支える品質。製品評価プロセスの標準化 「言うは易し、行うは難し」ですが、これらの製品評価プロセスが担当者のスキルや経験だけに依存してしまうと、品質にばらつきが生まれてしまいます。 そこで私たちは、誰が担当しても一定の品質を担保できるように、評価プロセスを前述のように標準化し、専用の入力フォーム（下記参照）や手順書を整備しています。 利用シーンの把握: 製品設置要件確認シート 製品の設計・安全思想の把握: 設置ガイドの確認シート、製品認証の確認シート 製品性能・品質の確認: 製品性能の確認シート、製品品質の確認シート Fig3 さらに、ソフトウェアエンジニアが多く在籍するセーフィーの特性を踏まえ、各シートの入力方法や注意点をまとめた手順書を準備しました。 これは、普段から設置業務、部材に触れている担当であれば用語にも精通していますし、どこにどういった情報があるかもすぐわかります。 しかし、頻度の低い人が作業を始めようとすると、思いのほか時間がかかったりもします。このような背景に対応するための手順書を作成しています。 Fig4 これらを用いることにより、ハードウェアの専門家でなくても、スムーズかつ網羅的に検証を進められる環境を整えています。 加えて、使用上の注意、安全上の注意、認証前提といった文言、用語、表現が各社で幅広く単純な検索ではマッチしないものには生成AIを用いることを想定し、対象項目を調査できるようにキーフレーズを併記しています。 多くの人が実感している通り、生成AIによる調査のメリットは、網羅的な抽出ができることにより、調査範囲が不十分なことによる抜け、漏れの発生を防ぐことができます。 しかしながら、調査者の経験・知識が少ない場合には、生成AIに入力するフレーズが十分でなく、このメリットが十分に享受できないケースの発生があります。 これらから、フレーズ例を併記し、出力結果が限定されすぎないようにしています。 Fig5 不具合解析こそ、腕の見せどころ このように確認を行った製品であっても販売後に、残念ながら何らかの不具合が発生することもあります。そんな時こそ、私たちハードウェア担当の腕の見せどころです。 解析の進め方で一番やりがちなことは、つい経験と勘に頼って解析を進めてしまうことです。 当たればよいのですが、当てが外れると原因究明が困難になることも多々あります。 我々は製造メーカーではなく、大量に世の中に製品を出荷しているわけではないので、解析ができる不具合対象機が数台程度であることが常です。 慎重にことを進めることが重要になります。 このようなことも踏まえながら、経験豊富なエンジニアも、そうでないメンバーも、同じ情報を残しながら解析を進められるよう、体系的な不具合解析フローを構築しています。 不具合報告の確認（不具合報告確認シート） 不具合品の外観（外観確認報告シート） 不具合再現（再現確認報告シート） 不具合品の分解（分解確認報告シート） 不具合品の解析（解析報告シート） 各シートには、HWエンジニアの経験してきた確認項目がリストされ、その内容を順次チェックしていくつくりになっています。 これにより、後戻りのない、的確な原因究明と、再発防止に繋げています。 Fig6 おわりに 今回は、セーフィーのハードウェアへの取り組み、特に他社製品を評価する際のプロセス及び不具合解析についてご紹介しました。 これは、 HWエンジニアを抱えるセーフィーだからこそのアプローチです 。 私たちの目標は、この HWエンジニアの経験や見識に裏打ちされた仕組み をさらに進化させ、HWエンジニア以外のメンバーを含めた全体の底上げをすることでお客様に品質の高いハードウェアを届けられるようにすることです。 次回は、もう一つの柱である「自社開発製品」について、詳しくお話ししたいと思いますので、お楽しみに！