本文へスキップ

05 / 05 · 2025.10 — 現在

株式会社◯◯(SES)

日本で SES として、レガシーシステムのモダナイゼーションに関わる開発に従事。ANTLR4 + RAG + MCP による COBOL 機能説明書の自動生成、大手電機メーカーの部門システム向け人員・組織連携ツールの開発、そして担当者として CMD → C# の「ルール+生成 AI」自動変換基盤を設計した。

職種
開発エンジニア(Python)
業種
受託開発・レガシーシステムのモダナイゼーション(SES)
所在地
日本
在籍
1年1ヶ月

主な成果

  • 1,084 件

    CMD → C# 変換で使う外部コマンド対応表(ほか内蔵コマンド 33 種、AST ノード 27 種)

  • 約 30 課

    人員・組織の自動連携ツールが対象とした組織規模(4 部)

  • 4 つ

    MCP でモデルに提供した検索ツール。COBOL 変数の業務上の意味を必要な分だけ参照

この会社での案件

PROJECTS · 3

2026.04 – 現在 · 担当者(アーキテクチャ設計・コア実装・レビュー)

レガシーバッチ(CMD/JCL)→ C# 自動変換基盤の設計・開発

長年稼働してきた Windows バッチ(CMD、Shift-JIS)を、自社バッチフレームワーク上の C# へ移行するための自動変換基盤。手作業での書き換えは工数が大きく業務ロジックの等価性担保も難しいため、「ルール変換+生成 AI 補完」の 2 段階方式を採用し、「変換できないほうが、業務ロジックを黙って変えるよりよい」を設計方針とした。

  • 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 種に分類し、よくあるエラーを一覧化してチームで共有
  • Python
  • Lark (LALR)
  • regex
  • Azure OpenAI
  • C# / .NET
  • pytest
  • Git

システム構成

2 段階変換アーキテクチャ
レガシー CMD スクリプトShift-JIS バッチ 第 1 段階 · 確定的な変換パイプライン 前処理8 種の正規化 LALR 構文解析Lark 約 490 行の文法 AST 変換27 種のノード C# 生成クラス / Main / using ルールエンジン + 変数展開内蔵 33 コマンド + 対応表 1,084 件 第 1 段階の成果物.cs(TODO を含む)· .cs.ast · .utf8.cmd 第 2 段階 · AI による CALL :LABEL の補完 3 者の対応付けTODO·AST·CMD キャッシュ照会SHA256 ハッシュ Azure OpenAItemperature 0 2 層検証構造 + 業務意味 フィードバック付き再試行最大 7 回、それでも不可なら TODO を残す 最終成果物.label.ai.cs(元の .cs は上書きしない)

2026.01 – 2026.03(3ヶ月) · Python 連携ツールの開発・テスト・本番リリース・運用引継ぎ(派遣)

部門向けプロジェクト管理システム 人員・組織自動連携ツール

大手電機メーカーのソフトウェア技術部門が、Redmine をベースに自作した部門向けプロジェクト管理・状況報告システム(Angular + Go + Redmine)。人員・組織データは社内人員名簿から取得する必要があるが、利用できる外部インターフェースがないため、Selenium でメンバーと組織構成を取得し、Redmine のアカウント・部/課組織・権限グループへ自動反映するツールを担当した(4 部・約 30 課)。

  • データ元の移行:旧人員名簿の廃止に伴い、クローラを新サイトへ移行。新しい画面構成と 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 ライセンス一覧を整備
  • Python
  • Selenium
  • paramiko
  • MySQL / MariaDB
  • Redmine REST API
  • SendGrid
  • Bash
  • PowerShell
  • Azure VM

システム構成

① 顧客の社内ネットワーク · WINDOWS 運用 PC ② AZURE VM · 本番サーバー タスクスケジューラ → executor.ps1 先に Excel マクロで正社員ホワイトリストを出力 find_users_emails_and_departments Microsoft SSO ログインを自動化 組織ツリーを展開し部/課のメールを取得 → new_users / new_organization.csv generate_all_users_data メールアドレスごとに検索:所属 · 役職 · 氏名 → all_users_data.csv transport_csv paramiko で日時ディレクトリへ SFTP 送信 remove_old_dir 期限切れの CSV とログを削除 各ステップは独立したサブプロセス · 失敗したら後続を中止 社内人員名簿 社内人員名簿 (旧システム は廃止) 組織ツリー 社員検索 SFTP cron → executor.sh 当日の最新データディレクトリを検索 SFTP 受信ディレクトリ 専用アカウント · batchgroup 権限 manage_user_batch(11 ステップ) 1 csv_validator:ヘッダ · メール形式 · 危険文字 2 組織差分 → update_organization.sql 組織の想定外の変更 → 終了コード 2 → 中断して通知 3 人員差分 → update_users.sql 新規メンバー有効化 · 離脱者停止 · 再入社でロック解除 4 権限グループ差分 → curl スクリプト 状況報告グループ · 部門内の長のグループ · ホワイトリストグループは保持 5 SQL / スクリプト実行 → 旧ディレクトリを削除 2 段階実行 EXEC_UPDATE_USER_SQL_FLAG で直接書き込むかを制御 組織変更時はまず SQL を生成し、担当者の確認後に executor_after_confirmed.sh を実行 MySQL(Redmine DB) users · email_addresses 部門 / 部 / 課 · 役職 · config Redmine REST API グループメンバーの追加・削除 SendGrid 異常通知メール 3 種 システム担当者 SQL を確認後に手動で解放
顧客の社内ネットワーク · WINDOWS PC AZURE VM · DOCKER COMPOSE ブラウザユーザー 部門メンバー · 管理職 · 承認者 Apache(Bitnami)HTTPS リバースプロキシ /home /dashboard_* /project_mgmt → Angular /dashapi → Go API その他 → Redmine Angular 18 SPA nginx コンテナ · 13 画面 ダッシュボード / レポート / 統計グラフ プロジェクト申請 · 承認 · 権限ガード Go API(Gin) 40 超の REST API · OpenAPI Worker Pool で Issue を並行取得 トランザクション + 行ロック · 承認フロー Redmine Issue / Tracker / カスタムフィールド プロジェクト · メンバー · グループ · 権限 カスタム JS / CSS を注入 REST API API Key SendGrid 外部メール API 承認通知 拡張テーブルの読み書き MySQL(Redmine と同一 DB) Redmine 標準テーブル:users · email_addresses · groups_users · issues … 拡張テーブル:departments · sections · divisions · user_*(部門/部/課 × 役職) application_requests · application_operation_logs · config user_queries(検索条件の保存)· lock_table(排他制御) 異常通知メール 生成した SQL を実行 manage_user_batch(Python · cron)★ 担当 ① CSV 検証 → ② 組織差分 → ③ ユーザー追加 / 停止 SQL を生成 ④ 部/課組織と役職を同期 → ⑤ 状況報告用の権限グループを同期 組織構造に想定外の変更 → 終了コード 2 で中断 + メール通知 担当者の確認後に第 2 段階を実行(executor_after_confirmed) SFTP 受信ディレクトリ 専用 sftpuser · batchgroup cron が日付で最新フォルダを検索 社内人員名簿 Microsoft SSO ログイン · 組織ツリー ログインを模擬 + 巡回 cross_page_batch ★ 担当 Selenium + Edge Headless MS アカウントのログインを自動化 部 / 課ノードを順に展開してメールアドレスを取得 メーリングリストのホワイトリストで絞り込み リトライ · 明示的な待機 · ログ ホワイトリストは Excel マクロツール由来 CSV 成果物 new_users.csv new_organization.csv transport_csv paramiko SFTP アップロード タイムスタンプでリモートディレクトリを作成 SFTP

2025.10 – 2025.12(3ヶ月) · 方式設計・実装・検証(個人主導)

ANTLR4 + RAG + MCP による COBOL 機能説明書の自動生成

お客様の中核バッチは数十年前に書かれた COBOL プログラムで稼働しており、設計書が無く、TR1-HINSHU のような略称変数の業務上の意味はデータベース設計書や用語集に散らばり、COBOL に詳しい人材も減っている。COBOL ソースを入力すると、業務担当者にも読める日本語の機能説明書(Markdown)を自動出力することが目標。確定的な処理(構文・レイアウト・呼び出し関係)はプログラムに任せ、モデルは「意味を与えて文章にする」ことだけを担当させる設計とした。

  • モデル能力の検証と方針転換: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 の直訳ではなく業務の言葉で説明させる
  • Python
  • ANTLR4
  • ChromaDB
  • SentenceTransformers
  • MCP (FastMCP)
  • Gemma-3 4B
  • Hugging Face Transformers
  • Google Colab
  • WSL

システム構成

知識ベース + MCP + 説明書生成パイプライン
① オフライン · 知識ベース構築(一度だけ) 資料 DB 設計書 · 用語集 表/ファイル/ジョブフロー定義 意味単位に分割 ファイル→レコード→項目→集団 {key, value} に統一 key(項目 ID)のみ埋め込み 埋め込み multilingual-e5-small 日・中・英で検索 ChromaDB エイリアス:OCCURS 添字を除去 階層パスを保持 MCP サーバー(FastMCP) lookup_field · lookup_record batch_lookup_fields · get_subroutine_summary ベクトル検索をツール化 ② オンライン · 説明書生成(プログラムごとに 1 回) COBOL ソース Unisys 系方言 前処理 Shift_JIS → UTF-8 行番号除去 · 方言指令 ANTLR4 構文解析 Cobol85.g4 → AST 呼出グラフ+整列 PERFORM · EXT 除外 下位から上位へ Gemma-3 4B サブルーチンごとに生成 機能説明書 .md(日本語) 必要な変数定義だけ検索 確定的な処理はプログラムへ(構文・レイアウト・呼び出し関係)、モデルは「意味を与えて文章にする」だけ

システムデータフロー

抽象的な図示・内部の詳細は含みません
  1. レガシー CMD スクリプト

    Shift-JIS・自治体システム

  2. 正規化 + Lark 構文解析

    8 種の前処理・約 490 行の文法

    ▲ 担当範囲

  3. ルールエンジン

    内蔵 33 + 外部 1,084 件

    ▲ 担当範囲

  4. C# コード生成

    .cs・未対応は TODO

  5. LLM 補完 + 2 層検証

    CALL :ラベル・最大 7 回再試行

    ▲ 担当範囲

  6. 成果物

    .label.ai.cs・失敗は TODO のまま

ここで学んだこと

日本で長く働くために、2024 年 7 月に来日し、まず日本語学校で日本語を学んで N2 を取得しました。2025 年 11 月の退学後、SES として日本の開発現場に入りました。

三つの案件は、いずれも「レガシーシステムを理解しやすく、移行しやすくする」ことが軸です。COBOL の案件では、RAG の品質が分割の粒度と検索キーの設計で決まることを実感しました。人員同期ツールでは、社内ネットワークが隔離され API もない条件下で、一方向の送信・2 段階実行・通知によって本番データを守りました。CMD → C# 変換では、「確定的なことはプログラムに任せ、生成 AI はルールで書けない最小単位だけを担当し、出力は必ず検証する。変換できないなら TODO を残し、業務ロジックを黙って変えない」という原則を確立しました。

TECH STACK

  • Python
  • Lark
  • ANTLR4
  • Azure OpenAI
  • MCP
  • ChromaDB
  • Selenium
  • C# / .NET
  • Redmine REST API
  • MySQL / MariaDB
  • Azure VM