ID:79960さん

# プロジェクト概要 - ある政府機関内で従業員が利用する、社内向けチャットアプリケーションのPoC開発 - ハルシネーションを防ぎ、一次情報データに基づいて業務課題を解決するのがポイント - ユーザーに使ってもらいながら改善を続け要件を固めていく # チーム構成・役割 - PM1名、AIエンジニア3名 - 私はソフトウェアエンジニア兼SRE兼AIエンジニア。プロジェクト途中から参画。手も動かすが技術顧問寄りの役割。 # 技術要素 - ミドルウェア: Amazon OpenSearch Service - フレームワーク: MCP Python SDK - Container PaaS: AWS ECS - コーディングツール: Claude, Serena # 難しかったこと・学び - 当初既存のチームでプロジェクトが進んでいたが、静的なRAGでセマンティックサーチを実装する方向で進んでいた。直近と今後のエージェントシステムの発展を踏まえて、Reasoning model APIが検索機能を持ったMCP Serverを呼ぶ構成を提案した。検索のチューニングの問題をMCP Serverコンポーネントの責務にすることができ、将来的なreasoning modelの精度向上にも追従できるシンプルな構成となった。 - OpenSearchが提供するlexicalな検索でもユーザー価値につながりそうだったので、semantic な検索とスコープを分けることができ、ビッグバンリリースを防ぐことができた。 - エージェントシステムの全体的な構成を決めてPoCを手早くやれたので、他のAIエンジニアがプロンプトエンジニアリングや検索のチューニングに集中しやすい土台を作れた。

# プロジェクト概要 - ある金融機関におけるリアルタイム自動トレーディングシステムの構築 - 限られた予算、期間、レガシーな環境で重要な価値にフォーカスしてデリバリしきる - 前任者のPoC実装を掘り起こしつつ、信頼性の高いソフトウェアにリプレイスしプラスアルファの機能を付加してリリースする # チーム構成・役割 - 私1名 (バックエンドエンジニア兼SRE) # 技術要素 - IaC: Terraform - Observability: AWS Application Signals - Container PaaS: AWS ECS - ミドルウェア: Redis, S3 - 言語: Python - CI/CD: AWS CodeBuild, CodePipeline - Webフレームワーク: FastAPI - コーディングツール: Claude, terraform-mcp-server, awslabs.aws-documentation-mcp-server, awslabs.terraform-mcp-server, serena - Git Repository: CodeCommit # 難しかったこと・学び - IaCで管理されていないレガシーな構成のAWS環境中で、新規作成する部分はTerraform化していき、徐々に適用範囲を広げられるようにしていくこと。 - 社内セキュリティや予算、期間の制約があり要件が見えづらい中で、[モノリスファースト](https://martinfowler.com/bliki/MonolithFirst.html)な考え方で設計すること。 - 「自分でコードを書かず、AIに書かせる」を徹底すること。自分で書く方が効率良い状況になってしまっていたとしたら、何かプロセスに改善の余地があると考える。 - レガシーな環境であったり制約が多く気が滅入りそうであっても、「AIコーディングのスキルを得る」という学びの機会を自分で作り出してプロジェクトに前向きでいること。 - AIコーディングでは、大規模開発で重要なプラクティスを守ることで生産性向上につながることが学びであった。例えば、 - CI/CDへの初期投資や、小さな実装でインクリメンタルなリリースを心がけること。 - テスト駆動開発で設計の意図をAIに伝えたり、ガードレールとしてのテストでAIが迷走しないようにすること。 - 動的型付け言語であっても静的解析を導入して、シグネチャからコードの意図を伝えること。 - レイヤリングや単一責任の原則をしっかり考えて、設計意図がAIに伝わるようにすること。 - 今回はモノリスなシステムであったこと、AIが理解・実装しやすいコードを書くという点で、ドメイン駆動設計を丁寧にやることが生産性向上に寄与した。([データサイエンス要素のあるDDDについてのブログ記事](https://rickey1227.hatenablog.com/entry/2025/07/24/153418)) - コーディングのコストが下がったからこそ、細かい設計の議論をClaudeに壁打ちしながらやれて、ソフトウェア品質の向上につながった。 # 成果 - 価値を絞ったプロダクトを、デッドラインまでにリリースしきった。収益向上という形で価値を出せてクライアントに感謝してもらえた。 - ビジネスサイドとのコミュニケーションが難しい環境下ではあったが、SLOの目線合わせをして後任の方たちが運用出来る状態に出来た。

# プロジェクト概要 - 企業の個社レベルのとある属性データを、オープンデータと自社保有のプライベートデータから予測し、自社プロダクトで提供するプロジェクト。 - CTO肝いりのプロジェクトで、とても困難だが成功すれば経営インパクトが大きい課題。 # チーム構成・役割 - メインはエンジニア3名と機械学習エンジニア1名 (私) - 全員がリーダーである位置づけで、チームの立ち上げを含め問題設定からデリバリまでをチームで自走するプロジェクト - プロダクトマネージャー陣を巻き込みつつ、レビュワーのCTOに壁打ちして進めるスタイル - 私自身が役割として心がけていたことは、 1. ビジネス課題を機械学習の問題に定式化することや技術面でチームをリードすること。 2. アジャイルなチーム作り。エンジニア組織内でも実験的な取り組みだったので、組織全体の価値観は大事にしつつも、既存のプラクティスを疑って自チームに適したプラクティスを生み出すこと。そのためのコミュニケーションの土台作り。 # 技術 - 欠損や量的・質的特徴の混在する構造化データであったこと、予測値は「XXX〜YYYくらい」といった幅をもった出力とすることで顧客との期待値調整をしたいという要件があったので、「LightGBMを用いたConformalized Quantile Regressionによる区間予測」という問題設定に落とし込んだ ([ブログ記事](https://rickey1227.hatenablog.com/entry/2024/11/10/200458)) - 正解データが得られるのは上場企業の一部だが推論対象のメインターゲットは非上場の中小企業、という共変量シフトを含む問題設定であった。加えて、推論対象全体のうちで精度の高いサブセットから順次リリースしていき、そのサブセットの範囲を広げていきたいという要件もあった。すなわち、アウトプットの品質は重要だがインクリメンタルなデリバリにより社内外からのフィードバックをプロダクトに活かせるリリースの仕組みを考えてほしい、という強い要件があった。そのため、adversarial validationを応用したselective predictionの手法を独自に考案した ([ブログ記事](https://rickey1227.hatenablog.com/entry/2025/03/03/014507)) # 難しかったこと - 不確実性下の予測問題やselective predictionなど馴染みない機械学習分野の研究にキャッチアップしつつ、エンジニアチームの中でペアプログラミングを通じて機械学習の考え方をチームに伝授すること。 - 機械学習の技術レベルに凹凸のあるチームであっても、チームだからこそ最大のアウトプットが出せるようにするにはどうしたら良いかを考え続けること。データや要件を理解することとチームの成長の両立を考え、基礎集計や線形回帰などのシンプルなモデルから入って徐々にステップアップしていくことを大切にした。行レベルのエラー分析やどういうデータを使えそうかの議論では、個々のメンバーの意見を上手く発散出来てユニークなアイディアが出せるようなコミュニケーションを心がけた。 - チャレンジングな課題であることはわかっていたので、「どうやったら成果につながるか粘り強く考えつづける」「未知の課題を楽しみポジティブに取り組むこと」などのマインドを持てるようにチームのコミュニケーションをリードすること。エンジニア組織全体として、開発プロジェクトの経験は厚いが技術的不確実性の高い機械学習プロジェクトの経験値が少ない状態であったので、チーム内での自分たちなりのコミュニケーションの取り方を試行錯誤することを大切にした。結果、元々コミュニケーションを非常に重視しているエンジニア組織であったが、その中でもトップレベルでコミュニケーションが密なチームになれたと思う。 - 成果が上手く出せないかもしれない機械学習タスクにチャレンジしたり、論文実装などの技術的不確実性のあることへ挑戦するというのは、機械学習エンジニアにとってはありふれたことであっても、ソフトウェアエンジニアにとっては勇気が必要なことであった。考え方を丁寧に説明したり技術的な面白さを伝えることで、他メンバーも機械学習の技術面に熱意を持ってくれるようになった。 # 成果 - 転職のためプロジェクトの途中でチームを去ることとなってしまい心残りではあったが、コミュニケーションの活発なチームの土台や問題設定・技術選定をしっかり固められたため、後続メンバーであるジュニアな機械学習エンジニアやソフトウェアエンジニアもこの土台を元にリリース対象企業を広げていくことが出来ていた。 - 単にこのプロジェクトの課題を解くだけでなく、ソフトウェアエンジニアが多い(機械学習エンジニアが少ない)技術組織で、両エンジニアの混成チームでPoCも含めて機械学習システムを作っていく道筋を組織に残すことが出来た。

# プロジェクト概要 - B2B SaaSプロダクト企業の開発組織において、機械学習エンジニア・ソフトウェアエンジニアとしてプロダクトの様々な機能の開発・運用を行う - 組織全体のエンジニア採用 # チーム構成・役割 - エクストリームプログラミングというアジャイルソフトウェア開発の方法論を導入している100名弱ほどのエンジニア組織 (ソフトウェアエンジニア、機械学習エンジニア、SRE、テストエンジニア) - ステークホルダーは主にプロダクトマネージャー、デザイナー、カスタマーサクセス、社内の業務エキスパートなど - 4,5名のチームでプロダクトの各機能の開発 - 技術領域はフロントエンド、バックエンド、インフラ(SRE領域・IaC・CI/CD)、機械学習、運用 - デザイナーやPdMと一緒にプロダクトの機能を考えたり、チームや組織作りに貢献することも職責 - 全員がリーダーという位置づけで、プロダクト作りやチームビルディングに必要なことをやる # 技術要素 - 言語: Kotlin, Python, Rust, F#, Dart, Java, TypeScript, Go - CI/CD: Buildkite, Argo CD, GoCD, Jenkins, AWS CodeBuild, CodePipeline GitHub Actions - Container PaaS: GKE, ECS - Kubernetesスタック: Helm, Skaffold, Argo Rollouts, Istio - IaC: Terraform, Ansible - Observability: Datadog, Google Cloud Logging - ミドルウェア: MySQL, PostgreSQL, ElasticSearch, GCS, S3 - 開発プラクティス: ドメイン駆動設計, テスト駆動開発, ペアプログラミング, トランクベース開発, マイクロサービス・マイクロフロントエンド設計, など # 成果 - 自分が開発した機能でプレスリリースが出たり、ユーザーフィードバック、売上につながったりする達成感や、PdM・デザイナーと共に喜びを分かち合えたこと - 大規模なプロダクトを経営戦略に沿ってアジャイルに開発し続けるための技術や組織に対する目線を養えたこと - チームに奉仕する姿勢やコミュニケーション・リスペクトを大切にする姿勢を持てるようになったこと - ソフトウェア技術・設計スキルの向上

# プロジェクト概要 - 技術選定や学習・推論の仕組みを主に私がリードしたプロジェクトは以下2つ: ## 1. ニュース記事への企業タグ付け - プロダクトに既に組み込まれているニュース記事に対する企業タグの推論APIの改善 - ほぼルールベースに近いAPIだったので、学習パイプラインの構成から大きくリプレイスしてニューラルな仕組みに寄せるプロジェクトに設計 ## 2. 社内向けwebアプリケーションでのコンテンツへのタグ付け - 社内のオペレーターが使う業務用webアプリケーションで、人事系ドメインのテキストコンテンツにタグをつけるプロジェクト - 新規に発足したプロジェクト # チーム構成・役割 - 4,5名の機械学習エンジニアチーム - プロダクトマネージャーや社内の業務エキスパートがステークホルダー - 業務課題の定式化からモデリングのPoC、学習パイプライン構築、推論APIのサービング、インフラの構成管理、他の既存MLシステムを含めた運用などをやる # 学習・推論の仕組み ## 1. ニュース記事への企業タグ付け - 学習: - NER + entity linkingのパイプライン - NER: BERT-CRF を約1万件の学習データで fine tune - Entity linking: 人手で作成したルールベースの辞書 + BM25 - Sentence-BERT などの学習済みエンコーダの類似度計算は精度が良くなかった - [BLINK](https://aclanthology.org/2020.emnlp-main.519)などの当時標準的だった entity linking の学習済みモデルは日本語版が存在しなかった - 推論: - 1日1回のバッチ推論 ## 2. 社内向けwebアプリケーションでのコンテンツへのタグ付け - データ: コンテンツのテキストデータが特徴、タグは約1万件のマルチラベルで、タグ名と説明文のメタデータつき - Extreme Multilabel Classification に近い枠組み (コンテンツとタグの距離学習) で解く - ネットワークアーキテクチャ: コンテンツとタグでそれぞれ別の dual encoder からなる siamese network (Sentence-BERT を fine tune) - triplet selection: オフラインとオンラインの両方 # 技術スタック - MLフレームワーク: pytorch-lightning, transformers, faiss - 学習パイプライン: Jenkins - 推論API: FastAPI - 実験管理: MLFlow Tracking Server - モデルレジストリ: GCS - Container PaaS: GKE - 構成管理: Helm # 難しかったこと・学び - 精度評価について、一見してF1で測って大きな変化がなくとも、RecallとPrecisionの大小関係が改善前後で逆転している場合など、ユーザー体験が大きく変わる場合があった。特にモデルの試行錯誤のフェーズでは複数の指標をトラッキングしたりドメインエキスパートと頻繁に話すことが重要だった。 - 低頻度だが分類ラベル自体が更新の対象となるため、これを考慮した学習・推論の仕組み作りをする必要があった。 - 当時は sentence-transformers の実装が未成熟で、オンラインの triplet selection などを自前で実装する必要があった。 # 成果 - 「学習データが少なくとも基盤モデルの fine tuning により高精度のアウトプットを出す」という技術スタックを組織として持てていない状態だったので、組織としてそこにチャレンジすべきという提案が出来て、成果につなげることが出来た。 - 実験管理などチームでこれまで導入していなかった機械学習のプラクティスを導入出来た。 - 私自身があまり馴染みない研究分野でも大まかな全体像を掴み、標準的なアプローチで取り組めた。チームへ知見を還元することも出来た。

- 機械学習やデータ解析に関する受託常駐プロジェクトを行う企業でのクライアントワーク - クライアントは小売、マーケティングリサーチ、交通、大学の研究室、金融、製造など - やっていたこと: データ集計可視化、機械学習、統計学、データ分析基盤構築、簡易なweb開発、OJTでのジュニアの育成、技術営業など