J.R.

システム構成

担当業務

• 2 段階アーキテクチャの設計：第 1 段階は決定的ルールで大半を変換（前処理 → Lark 構文解析 → AST → ルールエンジン → C# 生成）、第 2 段階はルール化できない CALL :ラベル のサブルーチンのみ LLM でメソッド化し、AI の適用範囲とリスクを最小化
• CMD 文法のモデリング：約 490 行の Lark（LALR）文法を設計・拡張。リダイレクトの任意位置出現、< > & | の曖昧性、%VAR:old=new% 置換、IF/ELSE の多様な括弧表記、日本語を含むラベル名など cmd.exe 特有の癖に対応
• 入力ゆれを吸収する前処理層（8 種）：改行コード混在、行末の閉じ括弧、複数行 ELSE、ECHO 内の記号、全角空白などを意味を変えずに正規化し、文法をシンプルに維持
• AST とルールエンジン：27 種の AST ノード、内蔵コマンド 33 種＋外部コマンド対応表 1,084 件（「ジョブプロセス」「ジョブフロー」の 2 つの呼び出しモード）。変数展開は文字列・引数行・整数式の 3 コンテキストで実装
• 生成 AI によるサブルーチン変換と「意味保存」検証：LabelMapper で .cs の TODO・.cs.ast の呼び出しノード・.cmd 原文の 3 者を対応付け、構造チェックと業務意味チェック（ERRORLEVEL・キャンセル処理・エラー分岐・ステータス設定の保持）を自動実施。不合格は理由を付けて最大 7 回再生成し、それでも不可なら TODO を残して人手確認へ
• コストと安定性：ラベルブロックの正規化内容の SHA256 をキーとする JSON キャッシュ、429/5xx の指数バックオフ、Chat Completions 非対応時の Responses API への自動フォールバック、temperature=0 で再現性を確保
• 品質サイクル：約 465 件のテストで文法層・変換層を検証。一括実行で出力される .cs.ERR を「CMD 原文の問題／文法の不足／コードの不具合／環境」の 4 種に分類し、よくあるエラーを一覧化してチームで共有

成果

• ✓ 移行の過程で、レガシー CMD に潜む不具合の可能性（例：& の欠落により GOTO が実際には実行されない、ECHO で SQL を書き出す際に < をエスケープしていない）を複数検出し、記録
• ✓ 例：117 行のデータ連携ジョブ CMD から 156 行の C# を自動生成。残る 11 件の TODO はいずれも対応表未登録の外部コマンドで、対応表の追加で解消可能

データフロー

レガシー CMD → 文字コード判定 → 入力正規化 → Lark 構文解析 → AST → ルールエンジン → C# 生成。TODO のサブルーチン → 3 者対応付け → LLM 生成 → 2 層検証（最大 7 回再試行）→ .label.ai.cs

システム構成

担当業務

• データ元の移行：旧人員名簿の廃止に伴い、クローラを新サイトへ移行。新しい画面構成と Microsoft SSO ログインに対応し、従来の役職表記との互換性を維持して下流の連携ロジックは無改修
• Selenium（Edge Headless）で自動ログインして組織ツリーを巡回し、社員検索で所属・役職を取得。paramiko の SFTP で社内 PC から Azure サーバへ一方向に連携
• 連携バッチ：新旧データの差分から SQL を自動生成・実行し、アカウントの追加・停止・再入社時のロック解除、部・課・役職を同期。Redmine REST API で状況報告系の権限グループを更新（ホワイトリスト対応）
• SendGrid で 3 種類の異常通知メールを実装。想定外の組織変更を検知した場合は処理を中断し、担当者の SQL 確認後に実行する 2 段階方式で本番データを保護
• コード内に分散していた部署マッピングを DB の設定テーブルへ集約。4 月の組織変更に向け、画面・申請フロー・権限グループを網羅するテストケースを設計・実施
• 本番障害の調査・修正：重複データによるロック誤判定、再入社ユーザの欠落、ネットワーク遅延によるタイムアウト、Edge ドライバ不一致
• 社内運用 PC と Azure VM の 2 環境へ本番リリース（バックアップ → デプロイ → SQL 実行を止めた試験運転 → 本稼働）。運用手順書（デプロイ・通知メール説明・障害対応・組織変更 SOP）を作成して引継ぎ
• Fortify / FOSSology によるセキュリティ・ライセンススキャンを実施し、JSON インジェクション、SQL インジェクション等の指摘を修正。OSS ライセンス一覧を整備

データフロー

社内人員名簿 → Selenium クローラ（社内 PC）→ CSV → SFTP → 差分 SQL / Redmine REST API（Azure VM）→ アカウント・部課組織・権限グループ

システム構成

担当業務

• モデル能力の検証と方針転換：Gemma-3 4B の COBOL 理解力をベンチマーク。Colab で LoRA 微調整を試みたがメモリ制約で完了せず。業務辞書が顧客ごとに変わるため、再学習が不要な RAG へ転換
• 知識ベース構築：データベース設計書・用語集・表／ファイル／ジョブフロー定義を {key, value} に統一し、「ファイル → レコード → 項目 → 集団項目」の階層で意味単位に分割。key のみを multilingual-e5-small で埋め込み ChromaDB に格納し、検索前に OCCURS の添字を除去してエイリアスと階層パスを整備
• COBOL 構文解析：Cobol85.g4 から Python 用 Lexer / Parser / Visitor を生成。Shift_JIS→UTF-8 変換、行番号除去、$SET 等の方言指令を前処理で処理。解析木を LLM 向けの簡略 AST に変換し、REDEFINES / OCCURS / COMP / 88 レベルに対応した変数抽出器を実装
• 呼び出し階層の解析：PERFORM から呼び出しグラフを構築し、RTN / EXT ペアのうち出口だけの EXT 段落を除外。トポロジカルソートで下位から上位への解析順序を決定
• MCP 連携：FastMCP でベクトル検索を lookup_field / lookup_record / batch_lookup_fields / get_subroutine_summary の 4 ツールとして公開。数百の変数定義をすべてコンテキストに詰め込まず、モデルが使用中の変数だけを検索
• 生成とプロンプト調整：サブルーチンごとに入力・出力・作業変数と呼び出し先を抽出し、MCP で定義を検索、下位の要約を渡して Gemma-3 が Markdown を生成。プロンプトの制約で空項目を省略させ、MOVE の直訳ではなく業務の言葉で説明させる

成果

• ✓ 2 本のプログラム（13.7 KiB / 13.5 KiB）からそれぞれ約 6.5 KiB / 6.7 KiB の説明書を生成し、検索された用語は期待どおりであることを確認
• ✓ 「静的解析＋RAG＋ツール呼び出し」の分担構成を確立。サブルーチン単位に分割して下位から解析することで、4B の小型モデルでもコンテキストを超える長いプログラムを扱え、変数説明が正しい業務名称に対応

データフロー

知識ベース（設計書 → 意味単位に分割 → 埋め込み → ChromaDB）⇄ MCP ⇄ COBOL ソース → 前処理 → ANTLR4 → AST → PERFORM 呼び出しグラフ → トポロジカルソート → Gemma-3 がサブルーチンごとに生成 → 機能説明書 .md

システム構成

担当業務

• 業務メインサービス（Gin + MongoDB）の設計・開発を担当。router / controller / service / model の階層構成で、型式・エンティティ・装備・データ辞書・テンプレート・想定バージョンなど 17 モジュール・約 100 本の API を実装
• 推演エンジンのライフサイクル管理を設計：ポートの動的割り当て、想定のエンジン入力へのエクスポート、os/exec によるプロセス起動と登録、goroutine での終了監視と資源の自動回収により、複数推演の並行実行に対応
• WebSocket Hub でタスク単位のルームによる想定の多人数共同編集を実装：読み書き 2 つのコルーチン＋ハートビート、想定ツリーをフラット化したインデックスキャッシュ、差分コマンドのリアルタイム配信
• オペレータサービスの開発：想定 JSON → 外部シミュレーションエンジン XML 変換（3,000 行超）、GeoJSON による領域・交差・和集合の空間演算。態勢のフレーム単位録画と、一時停止・倍速・タイムライン再生を実装
• Go でエンジンコンソールを開発し、TCP でスケジューラと接続してエンジンコマンドを中継。推演の開始／停止／一時停止／再開の HTTP API を提供
• Tornado + SciPy でレーダー信号生成サービス（線形 FM パルス、クラッタ、エコー）を開発。バックグラウンドスレッドで非同期生成し Docker で配備

データフロー

想定編集（Vue + Cesium）⇄ WebSocket 共同編集 → Gin メインサービス → オペレータサービス（JSON → XML）→ エンジンコンソール（TCP）→ シミュレーションエンジン → 態勢返送 → 3D 表示／録画再生

システム構成

担当業務

• ZeroMQ（REQ + DEALER）と Protobuf でプラットフォーム連携層を実装。推演制御、ユニット／任務／損害の照会、航路、発艦、編成など 38 本の API をラップし、Runner が固定ステップで「観測 → 判断 → 指令」を回して勝敗を採点
• 赤軍の防御エージェントを開発：知覚 — 情報融合 — ミサイル／火砲／レーザーの火力配分 — 攻撃検証という段階的な意思決定。青軍の侵攻エージェントも開発：複数の行動案、無人機部隊の発進と飽和攻撃
• 参加 16 エージェント（ルール／機械学習／深層学習）の配備・評価を担当。依存関係や実行上の問題を切り分け、代表的な戦略を分解して技術共有を実施
• エージェントの態勢を MQTT で配信し、PyQt5 でリアルタイム監視ツールを開発。タブごとに赤・青のユニットと損害を表示し、ラウンド単位でのオフライン保存と振り返りに対応

データフロー

C++ 推演プラットフォーム ⇄ ZeroMQ + Protobuf ⇄ Runner（観測 → 判断 → 指令）→ 赤／青エージェント → MQTT → PyQt5 リアルタイム監視

システム構成

担当業務

• トラフィック処理経路の開発に参画：キャプチャプローブ → Kafka → プロトコル解析エンジン → PostgreSQL。Redis の有効期限イベントで 10 秒窓のフロー集約と一括登録を実現し、DB 書き込み負荷を大幅に低減。Redis の TTL で機器のオフライン検知を実装
• 5 タプル・MAC・プロトコルのファンクションコードに基づくホワイトリスト検知エンジンを実装し、ビットマップで「通信行動の異常」と「内容の異常」を区別。IEC104 ASDU や OPC のインターフェース／ファンクションコードまで踏み込んだルール照合、時間帯指定でのホワイトリスト自動学習にも対応
• 資産管理、ホワイト／ブラックリストポリシー、アラート、レポートなどの Django REST API を担当。Celery Beat でレポート出力、ポリシーバックアップ、期限切れデータの削除、プローブのヘルスチェックなどの定期ジョブを実装
• Suricata を組み込み、unified2 アラートを解析。約 1,000 件（996 件）の産業系脆弱性シグネチャでブラックリスト検知を実現
• Kafka Connect（Debezium CDC）で Pilosa のビットマップインデックスへデータ同期し、トラフィック統計と多次元検索を支援
• （カスタム版）IEC 61850 の SCD ファイルを解析し、変電所の IED 通信ベースラインとトポロジを自動生成

成果

• ✓ プロトコル解析は CPU 負荷の高いバイト単位の処理。解析ライブラリは Cython で記述してホットパスを C 拡張にコンパイルし、C に近い性能と上位への Python インターフェースを両立。納品は .so のみで、コアコードの保護にもなる

データフロー

スイッチのミラーポート → プローブ（Scapy）→ Kafka raw_packets → Cython 製プロトコル解析エンジン → Redis 10 秒フロー集約 → PostgreSQL → ホワイトリスト検知 → alerts → Django + Vue。Suricata がブラックリスト検知を並行実行。PostgreSQL →（Debezium CDC）→ Pilosa

システム構成

担当業務

• Ray ベースの分散アルゴリズム調整中台を構築（主担当）：Actor モデルで 10 種類以上のアルゴリズム機能（アダルト・暴力テロ識別、OCR、局ロゴ、ロゴ、顔検索、動画コピー検出、クロスモーダル検索など）を統合的に編成
• メッセージ信頼性：Kafka の自動コミットを無効化し、1 バッチ処理後に commit（at-least-once）。puller Actor の数はクライアントが検出したパーティション数に合わせ、1:1 で起動
• GPU リソースの分割：num_gpus=0.2 の小数指定により、1 枚の GPU で 5 つのモデルインスタンスを並行稼働（クラスタは 1 台・Tesla T4 × 4）
• 「電文層 — ルーティング層 — モデル層」の 3 層抽象を設計：電文層は ray.wait で推論バッチを流れるように再構成し、ルーティング層は購読 algo_id とモデル能力の積集合で動的に振り分け。新しいモデルは Actor を 1 つ足すだけで既存コードに触れない
• SWIG 4.0 で C++ アルゴリズムライブラリを Python 拡張モジュール化（主担当）：画像は numpy のメモリポインタで渡し C_CONTIGUOUS を検証して、言語間のデータコピーを排除
• 華為 Ascend Atlas ACL 推論 SDK（C++11 / CMake）の開発に参画：デバイス／Stream 管理、FFmpeg のデマルチプレクスと DVPP ハードウェアデコード。ベクトル検索を AscendFaiss から Milvus へ移行し、CANN ドライバ 3 バージョンに対応。複数チップ並列検索時の OpenMP スレッド数不一致によるインデックス削除失敗を特定・修正
• モデルのデュアルプラットフォーム展開：PyTorch → ONNX（opset 11）→ TensorRT 7 INT8（Tesla T4 向け）／Ascend ATC の .om オフラインモデル。同一の業務コードで NVIDIA と Ascend の両方を支え、累計 17 のモデルパッケージを保守
• 自社開発の OCR 機微コンテンツ識別：PSENet によるテキスト検出 + CRNN(LSTM) 認識 + 角度分類。認識結果は DFA アルゴリズムで約 2 万語の辞書と高速に照合

成果

• ✓ 10 種類以上のアルゴリズム機能を同一の調整中台で提供。GPU 版と Ascend 版の SDK アーカイブで合計 17 のモデルパッケージ
• ✓ ベクトル検索の基盤を Milvus に統一し、GPU 系と Ascend 系で検索インターフェースを共通化

データフロー

Kafka タスク → Puller ×N（パーティションと 1:1）→ 電文層 → ルーティング層（algo_id ∩ モデル能力）→ モデル Actor プール（1 枚あたり ×5）→ 結果 Kafka。C++ SDK は SWIG 経由で接続、ベースデータ → Milvus + MySQL

システム構成

担当業務

• Tornado サービスがテキスト／画像／動画の 3 モダリティ入力に対応：動画は 25 フレームごとに 1 枚抽出し、クロスモーダルのデュアルタワーモデルで 512 次元の特徴に統一、動画特徴はフレーム平均
• gRPC で Milvus を検索して TopK 候補を取得し、複数条件ロジックエンジン（AND／OR／NOT／包含）で集合演算、RRF（逆順位融合）で再ランク、ラベル一括付与、Redis で 2 次キャッシュ
• 性能改善 4 段階：gRPC 単発照会 → 並行バッチ API → 論理条件の前置絞り込み → マルチスレッド分割照会（100 件／バッチ）＋ np.dot によるバッチ行列内積。ベース照会を N 回の逐次 gRPC から ⌈N/100⌉ 回の並行バッチへ集約
• 同種のオフライン製品として、動画の特定物体フィルタも担当：フレーム抽出 → SDK で 512 次元特徴 → gRPC で Milvus 検索 → 後処理 → Docker 納品

成果

• ✓ 顧客向けカスタマイズのオフライン版を累計 3 件納品（Docker イメージ）
• ✓ 類似度計算を 1 件ずつの比較から単一の行列内積に変更し、しきい値による早期打ち切りを併用

データフロー

3 モダリティ入力（テキスト／画像／動画）→ フレーム抽出 → クロスモーダル符号化（512 次元）→ gRPC · Milvus → ロジックエンジン → RRF 再ランク → ラベル付与 → Redis キャッシュ → JSON

システム構成

担当業務

• データ収集モジュール：RESTful API でクローラサービスを連携し、画面から収集タスクを実行、結果を MongoDB に保存
• データ処理モジュール：OpenCV の画像処理・FFmpeg の動画処理を Tornado で API 化し、Vue 画面から操作可能に。ファイルの分割アップロード（レジューム対応）を設計
• モデル欠陥分析モジュール：初期ラベリングと人手確認を GUI 化。複数データセット・モデルを入力して PR 指標を算出し、PDF レポートを自動生成
• フロント・バック両方を担当し、ページコード修正や UI 改善も実施

システム構成

担当業務

• 2 段階認識：Mask R-CNN（R-101-FPN）で生徒を検出 → ResNet18 で行動分類（6 クラス、信頼度 0.95 未満は「不確定」）。検出モデルに直接分類させるより精度が高く、行動クラスの変更時も小さな分類器だけ再学習すればよい
• リアルタイム分析：OpenCV で RTSP ストリームを読み、映像タイムスタンプが実時間より遅れたらフレームを間引いてリアルタイム性を確保。クラスごとに独立した GPU プロセスを起動し、起動前に nvidia-smi で空きメモリを確認
• フレーム間追跡と本人識別：5 秒窓の双方向重なり率による追跡を自作。face_recognition（dlib）の 128 次元特徴をクラスの顔データベースと照合し、同一トラック内で最頻の生徒 ID を採用して、うつむき・横顔でも本人を識別
• 机に伏せる・横を向くのリアルタイム警告：生徒の顔画像（base64）を切り出して警告に格納。最新結果とフレームごとの履歴は MongoDB に分けて保存
• Tornado バックエンド：アカウントと 3 種のロール、警告・レポート（生徒・授業・学年・学校の 4 階層）、WeChat ミニプログラム API と外部プラットフォーム向け公開 API。プロダクトマネージャーのプロトタイプに合わせて API の項目仕様を設計
• scikit-learn で行動データを分析し、生徒ごとの週報・月報・学期レポートを作成して保護者の WeChat ミニプログラムへ配信
• 社内のデータ注釈・学習プラットフォーム：動画の切り出し → Mask R-CNN による事前注釈（labelme JSON 生成）→ 人手修正 → 切り抜き → データセット作成 → ResNet18 学習（再開対応、loss／精度の曲線）→ 検証。授業全体のオフライン分析がリアルタイム版の原型
• 納品：コアの追跡アルゴリズムを Cython で .so にコンパイルし、supervisor による常駐化とドングルによるライセンス管理で、複数顧客へオンプレミス展開

成果

• ✓ 同一コードで 3 顧客向けのカスタム API、外部向けの公開 API、WeChat ミニプログラムを同時に提供
• ✓ データ生産を Web ツール化し、モデルによる事前注釈で手作業を削減。アルゴリズム担当以外も注釈に参加可能に

データフロー

カメラ RTSP → OpenCV 読み込み／フレーム間引き → Mask R-CNN 検出 → ResNet18 行動分類 → 顔認識 + 追跡／投票 → MongoDB → Tornado 画面／リアルタイム警告／WeChat ミニプログラム

システム構成

担当業務

• 統計エンジンのバックエンド（Tornado、約 1,650 行・21 ルート）：授業／教師／生徒の一覧・詳細・履歴トレンド、授業態度の時系列カーブ、模範授業 TopN
• Elasticsearch クエリ：bool + terms + range の組み合わせ、terms 集計に avg サブ集計をネスト（授業ごとの教師の平均 happy 確率・語数・話速）、大きな結果は scan / scroll で走査。CV と ASR の複数ソースをアプリ層で統合して並べ替え
• 管理画面のフロントエンド（vue-element-admin 4.4）：ロール別の動的ルーティング権限、データ大画面、授業／教師／生徒の一覧と詳細、ランキング、トレンド、絞り込み。ECharts で可視化、Docker 化と複数環境設定
• アルゴリズム分析に参画：生徒の発話比率・まとまった表現・感情のポジティブ度から約 30 秒の「ハイライト」区間を抽出し、ノイズ・教材音声の混入・保護者の同席などの異常も印付け。保護者向けの学習状況レポートに利用

データフロー

ページ収集 SDK → OSS → ASR / CV / VAD Worker → Elasticsearch → 分析・統計エンジン → 管理画面 + MQTT リアルタイム警告

システム構成

担当業務

• 推論フロー：ランダムフレーム抽出 → YuFaceDetectNet による検出と 5 点ランドマーク → アフィン変換で整列 → 遮蔽・姿勢ぼけ・年齢の 3 モデルでフィルタ → ResNet18 で特徴抽出しコサイン類似度で照合。最年少の顔（17 歳未満）を採用して生徒本人を特定し保護者を除外
• 複数フレームワークの混在推論：検出・特徴抽出は PyTorch、遮蔽・姿勢・年齢は MXNet Gluon、すべて CPU で実行。v1.0 から v3.4 まで継続改善（dlib 68 点 + Laplacian ぼけ検出 → モデル・整列の刷新 → 品質モデル 3 種の追加 → 全件検索と動画検証の書き直し）
• Redis に特徴を保存し、全体・増分・指定人の 3 種類の検索に対応。全件の総当たり比較はコードのコメントで約 4,000 万回と見積もり
• 商用ライセンス制御：呼び出し回数・有効期限・日次上限を AES 暗号化して Redis に保存、SETNX で分散ロック、デバイス SN を検証。コアモジュールは Cython で .so にして納品
• 設定は「コマンドライン引数 > 環境変数 > JSON / YAML」の優先順位で読み込み。Docker で配備し、ビルド時に OSS からモデル重みを取得

データフロー

動画 → ランダムフレーム抽出 → 顔検出・整列 → 遮蔽・姿勢・年齢フィルタ → 特徴抽出 → コサイン照合／Redis 特徴 DB → 認証・検索結果

システム構成

担当業務

• YOLOv5s による主検出（UI 要素 7 クラス）とルールによる画面種別の判定。スクリーンショット 1 万枚超といいね／コメントアイコン 1 千枚超を自前で注釈し、k-means でアンカーボックスを算出
• 投稿詳細：PaddleOCR（PP-OCR、DB 検出 + CRNN 認識）でレイアウト位置から投稿時刻・広告文・ポスター ID を取得。QR コードをデコード。右下を切り出して YOLOv5 でいいね／コメントのアイコンを検出し、3 層 CNN で数字を認識
• Tornado + PyTorch + PaddlePaddle のサービス：token と MD5 による完全性検証、nanoid によるリクエスト追跡、元画像は OSS、全結果と処理時間を Elasticsearch へ保存して本番の異常応答の調査に活用
• PP-OCR のモデルバージョンを更新し、ポスター ID と投稿時刻の認識率を向上

成果

• ✓ 数字認識の 3 層 CNN：学習 98.95% ／ 検証 98.25% ／ テスト 84.45%

データフロー

スクリーンショット送信 → token / MD5 検証 → YOLOv5 で UI 検出・分類 → PaddleOCR + QR + いいね数認識 → JSON 返却。全結果を Elasticsearch へ