ID:75195さん

### プロジェクト概要 - **目的**: パーソルキャリア社員約6,000人を対象とした社内向け生成AIチャットサービスの開発を進めました。 - **チーム構成**: フロントエンドエンジニア2名、インフラエンジニア1名、私（フルスタックエンジニア兼テックリード）の4名のエンジニアで構成されています。開発以外にも、推進チームや分析チームと連携し、PMとの協働でプロジェクトを進行しています。週1回の開発定例MTGではファシリテーターとして、メンバーのタスク管理、進捗確認や課題解決をサポートしています。 ### 自身の役割 - **技術面での貢献**: フロントエンド、バックエンド、インフラの各領域で実装や改善を担当しました。事業部側とのヒアリングや他チームとの認識合わせを通じて、要件定義、詳細設計、実装、コードレビューを一貫して実施し、プロジェクト全体を技術的にリードしています。 - **マネジメント面での貢献**: チームリーダーとして、開発全体のテックマネジメントを担当し、課題解決やプロジェクトの円滑な進行をサポートしています。また、他チームとの連携を密にし、プロジェクト全体のスケジュールと進捗管理を行なっています。 ### 背景と課題 - **課題**: 社内にはルールベースのチャットボットしか存在せず、自由な形式で質問できるサービスがありませんでした。そこで、社内業務の効率化を目的として、全社員が生成AIを活用できる環境の整備が求められていました。 ### 自身のバリューと成果 - **技術的工夫**: Azure基盤を活用し、LangChain、Azure OpenAI、Azure AI Searchを統合して生成AIを活用した社内チャットサービスを構築しました。GPT-3.5の最適化手法を導入し、高パフォーマンスを維持しつつ運用コストの削減に成功しました。現在は最新のAzure OpenAI GPT-4oへの移行も完了しています。 - **URL共有機能の実装**: 「個人プロンプトURL共有機能」を開発し、社員が自分のプロンプトテンプレートをURL形式で簡単に他のメンバーと共有できる仕組みを構築しました。これにより、効率的な知識共有と情報活用が促進され、操作の簡素化とデータ活用の幅が広がりました。また、共有されたプロンプトの利用状況をCosmos DBで追跡し、データに基づいた施策を推進できるようにしました。 - **プロンプトサジェスト機能**: AIに不慣れな社員のために、会話の流れに応じて次の質問を提案する「プロンプトサジェスト機能」を実装しました。これにより、生成AIとの対話がスムーズになり、AIの利用促進を図ることができました。Azure OpenAIの最新モデルGPT-4を活用し、精度の高い応答を実現しています。今後は、Structured Outputs機能の導入も検討し、さらなる効率化を目指しています。 - **社内文書検索機能の実装と改善**: RAG（Retrieval-Augmented Generation）を活用した社内文書検索機能を開発し、2024年3月にベータ版をリリース、9月には正式版をリリースしました。ベータ版では文書範囲や検索精度に課題がありましたが、正式版ではMicrosoft SharePointとAzure Blob Storageの連携を自動化するパイプラインを導入しました。さらに、ベクトル検索とフルテキスト検索を組み合わせたセマンティックハイブリッド検索を採用し、文脈に即した高精度な検索結果を提供しています。この機能により、非構造化データを含む膨大な社内文書から迅速に必要な情報を取得でき、業務効率化に大きく貢献しました。 - **LLM-as-a-Judge導入**: LLM-as-a-Judgeを導入し、生成された回答や検索結果を自動的に評価する仕組みを構築しました。これにより、データ処理のスケーラビリティを確保し、一貫性のある高精度なフィードバックが得られるようになりました。評価プロセスの効率化とリソースの最適化により、業務のさらなる効率化を実現しました。 - **データ連携の改善**: 社内のSharePointに保存された全社員向け文書を、Azure Blob Storageにリアルタイムで転送するパイプラインをAzure Functions上で構築しました。これにより、RAGを用いて全社の文書から迅速に回答を生成できる仕組みを整えました。 - **プロンプトテンプレート管理機能の強化**: キャリアアドバイザーやリクルーティングアドバイザーなど、業務フローに根ざしたプロンプトテンプレートを職種別に管理できる機能を追加しました。責任者とのヒアリングを複数回実施し、業務フローに必要なカテゴリーを定義、そのデザインをFigmaで作成し、仕様に落とし込みました。プロンプトテンプレートはSharePoint上のCSVファイルで管理し、データ同期によってユーザー権限の複雑性を回避しましたが、今後はアプリ上で権限管理を完結する仕様も検討しています。 - **技術負債の解消**: 初期構築段階ではNext.jsアプリケーションを一つのAzure App Service上にデプロイしていましたが、ファイルアップロード機能の追加に伴い、システムのリアーキテクチャを実施しました。具体的には、以下の改善を加えました: 1. **Azure App ServiceからAzure Container Appsへの移行**: コスト最適化とKubernetesによるスケール性、カスタマイズ性を強化するため、Azure App ServiceをAzure Container Appsに置き換えました。ゼロスケール機能により、効率的なリソース使用を実現しました。 2. **Next.js API Routeの分離**: ファイル解析やLLMとのチャット処理を担う部分を、FastAPIを用いてPythonベースで別サーバーに分離しました。これは、TypeScriptからPythonへの移行を通じて、Ragasなどのプロンプト評価ツールとの相性を考慮した結果です。 これらの技術負債の解消により、スケール性を向上させ、将来的な機能追加に対する柔軟性を確保しました。 - **成果**: 社内文書を活用した自動回答生成サービスを成功裏にリリースし、事業部とアナリティクスチームとの連携を強化しました。スケジュール通りのリリースを実現し、業務効率およびUXの向上に寄与しました。また、継続的なフィードバックを基に機能を改善し、社内での普及率を60〜70%まで向上させました。LLM-as-a-Judgeの導入により、評価プロセスのスケーラビリティや精度も向上し、業務効率化にさらに貢献しました。

### プロジェクト概要 - **目的**: パーソルキャリア社内における法人データの分析基盤をGoogle Cloudに移行し、コスト削減とパフォーマンス向上を実現すること。 - **体制**: データエンジニア3名（私を含む）、データマネジメントチーム1名、PM1名で構成されるプロジェクトチーム。 ### プロジェクトにおける自身の役割 - Denodoを利用していた仮想データベースをGoogle CloudのBigQueryへ移行するプロジェクトをリードし、技術的なソリューション提案と実装を担当しました。 - 業務フローの抽出・整理を行い、移行の影響を最小限に抑えるためのPoCを実施し、転送パイプラインの設計・構築を行いました。 - 日本語のExcelやCSVファイルをBigQueryのテーブルに適切にマッピングする仕組みの設計、またデータ品質管理のための自動チェック機能の実装も手がけました。 ### 課題とその背景 - **課題**: Denodo基盤はAWSのEC2上で運用されており、コストの増大とパフォーマンスの低下が問題となっていました。特に、ファイルベースのデータ連携がパフォーマンスに悪影響を与え、リアルタイムなデータ処理が困難でした。 - **背景**: これを解決するため、Google Cloudへの移行を提案し、パフォーマンス改善とコスト削減を実現するためのPoCを行いました。その結果、Google Cloud基盤への移行が最適であると判断されました。 ### 課題解決に向けた自身のアプローチ - **PoCの実施**: Google Cloudに移行する際のパフォーマンスとコストの検証を行い、Denodoで実現していた機能をGoogle Cloud上で再現可能かを確認しました。 - **新しいデータフローの構築**: Denodoで行っていたファイルアップロード処理を、Google Cloud Storageへのファイルアップロードに切り替え、EventarcをトリガーにCloud WorkflowsとCloud Run Jobsを利用して、データの前処理からBigQueryへの転送を自動化しました。 - **データ品質の管理**: データのカラムやレコードの差分を自動検知し、Slackに通知する仕組みを構築し、品質の確保を図りました。 - **SalesforceデータのPoC**: Troccoを利用してSalesforceからのデータ転送の検証を行い、将来の導入に向けた技術的な可能性を確認しました。 ### 成果 - **パフォーマンスの向上**: データ更新頻度が月次から日次に改善され、リアルタイムに近いデータ処理が実現しました。 - **コスト削減**: DenodoからGoogle CloudのBigQueryに移行することで、従量課金モデルを採用し、運用コストを削減しました。 - **運用効率の向上**: 業務フロー全体の自動化を実現し、データマネジメントチームの負担を軽減しました。 ### 今後の展望 - **データ品質のさらなる強化**: dbtを導入して、データ変換プロセスの透明性を高め、品質管理をさらに強化する計画です。 - **データガバナンスの強化**: データの権限管理やアクセス制御を強化し、セキュリティと効率性を両立させる運用体制の構築を目指しています。 - **Denodo再導入の可能性**: Denodoの仮想データベース技術を活用し、将来的にはガバナンスの強化とクエリ自動化によるパフォーマンス向上も検討しています。

### プロジェクト概要（目的・人数・体制） 社内でセキュアに利用可能な生成AIチャットサービスの開発（SaaS）を行いました。開発体制はアジャイル開発で、メンバーは全員がフルスタックエンジニアであり、計4名で構成されていました。私は副業としてテックリードの役割でジョインいたしました。 ### 自身の役割 機能開発において、フロントエンド、バックエンドの実装、インフラ構成の改善を行いながら、チームのテックマネジメントも担当いたしました。開発では、要件定義、詳細設計、実装、レビュー、テックマネジメントを行いました。Google Cloudのインフラ基盤を、サービス開発当初からゼロベースで構築いたしました。 ### 課題 生成AIを活用した社内向けチャットサービスをSaaSとしてリリースするにあたり、セキュアでスケーラブルなインフラ構築が求められていました。 ### 工夫 - 社内での知見が強いVercelやFirebaseに依存せず、Google Cloud上でインフラをゼロから構築いたしました。 - プロトタイプはVercelとSupabaseで構築されていましたが、Vercelのコスト面（プライベート接続にはProプランからEnterpriseプランへの乗り換えが必要）を考慮し、Cloud RunとCloud SQLでより低コストで同様の仕組みが実現できることを確認し、移行を実施しました。また、SupabaseはBaaSとして最低限の機能を提供していましたが、メール送信テンプレートの数が固定されていたり、SDKがトランザクションに対応していなかったりするなど、長期運用において問題があると判断いたしました。これを受け、メール送信にはResend、認証・認可にはNextAuth.js、ORMにはDrizzle ORM（TypeScript）、Gorm（Go）、SQLAlchemy（Python）を言語ごとに選定し実装いたしました。 - フロントエンドにはNext.jsを、アプリケーションサーバーにはEcho（Go）、LLMサーバーにはPythonのgRPCサーバーを使用して構築いたしました。 - 前提として、スピード感のある開発が求められていたため、社内知見を活かしつつ最適な技術選定が求められていました。 - フロントエンドには社内知見の多いReactベースのフレームワークであるNext.jsを選定。 - バックエンドにはまずベースのアプリケーションサーバーにはGoを採用いたしました。これは、ベースとなるサーバーで型安全性、並行処理の強み、ビルドスピード、コンテナイメージの軽量化等のメリットをバランス良く享受できる点が理由です。 - LLMサーバーはベースとして依存リソースへの処理を抽象化できるLangChainを採用しているため、技術選定がPythonかNode.jsとなりますが、今後ローカルLLMや独自LLMを利用する可能性を考慮し、Pythonを選択いたしました。 - オブザーバビリティの観点から、GoとPythonサーバーにはGoogle Cloud Traceを導入し、API内の各処理のボトルネックを可視化できるようにいたしました。 - 負荷対策とセキュリティの柔軟性を考慮した設計を行いました。 - **負荷対策**： - ファイルアップロードをGoogle Cloud Storageの署名付きURL付与後、フロントエンド側でアップロードを実施する仕組みにし、ファイルがアプリケーションサーバー上でメモリ展開されることを回避する設計にしました。 - ファイルアップロードをPub/Sub経由で処理することで、ファイルの複数アップロードによるCloud Runのスケール限界に到達するリスクを軽減する設計としました。 - 現状はコスト削減のため、Cloud SQLに対し、ベクトルDBとメタデータDBの役割を持たせていましたが、今後リードレプリカを導入し、Read/Writeの負荷を分散させる予定です。 - **セキュリティ**： - Cloud Load Balancingに対し、Cloud ArmorによるWAFを適用し、不正なアクセスを検知できるように設計いたしました。 - 以降の処理はCloud Run同士の通信はIAMで、Cloud RunからCloud SQLへはAuth Proxyによる接続とすることで、通信において外部から公開アクセス可能な状態を回避する設計としました。 - PostgreSQLに対して、RLSを適用しました。それによってDB内ではユーザーが所属する組織以外のデータには確実にアクセスできないようになっています。 - その他 - **権限管理機能**： - 文書やプリセット(チャットの各種設定をまとめて管理する機能)に対する個人やチーム単位での閲覧権限や編集権限を中間テーブルで権限判定させる機能の開発を行ったが、純粋に中間テーブルの処理で毎回権限判定をさせるとバリデーションを毎回Repository層まで伝達する必要がある上、複雑なJOIN(あるいはEager Loading)の実装をORM上で実現させる手間が発生してしまいます。 - そこで、Casbinを用い、権限に関する設定をポリシー定義として管理をし、APIエンドポイントに紐付けたミドルウェア上でアクセス許可・拒否の判定を行うことで、実装自体もなるべくビジネスロジックへの依存を避け、抽象的に管理をし、また、汎用性を持たせられるようにしました。 - ポリシー定義をRedis等のDB内で持つと権限マスターの二重、三重管理によりデータ不整合が発生するリスクがあるとみて、現状はポリシーをメモリ上で管理をする形とし、こちらは100万件のデータに対するポリシーも100~200MBで処理できるとして問題ないとして見積もっています。ただ今後更にメモリ使用量が増えることを見据え、ポリシー定義をRedisやPostgreSQL上に移すための準備を進める予定です。 ### 成果 - サービスのゼロからの立ち上げに成功し、現在もtoBサービスとしてスケールを続けられる仕組みを構築いたしました。 - サービスのスケーラビリティとセキュリティを両立させ、利用企業の生産性向上に寄与いたしました。

### プロジェクト概要（目的・人数・体制） 契約書や帳票をデータとして管理できるAI搭載の管理サービスの開発(SaaS)に従事いたしました。開発体制はアジャイルで進行し、メンバーはフロントエンドエンジニア2名、バックエンドエンジニア4名の正社員6名で構成されていました。さらに、マネージャーや業務委託メンバー、企画メンバーとも連携を図りながらプロジェクトを推進いたしました。 ### プロジェクトにおける自身の役割 私は、機能開発においてフロントエンドおよびバックエンドの実装、インフラ構成の改善を担当すると同時に、技術面での開発リーダーの一員としても活動いたしました。具体的には、要件定義、詳細設計、実装、レビュー、リリース、運用保守を主導いたしました。 ### 当時の背景/抱えていた課題等 当時、サービスは0→1フェーズを終え、1→10へのスケール段階にありました。このスケール段階において機能拡充が求められておりましたが、サービスのスケール性には限界がありました。特に、AI搭載の処理サーバーがKubernetesのポッド上で動作していたものの、直列処理しかできなかったため、AWS Lambdaに基盤を移行することでコストダウンとスケール性の向上を同時に実現する必要がありました。 ### 課題に対して自身が発揮したバリュー及び成果 - **工夫**: - **チームの知見強化によるサービス品質向上**: - 毎週の輪読会を主催し、TypeScriptやGo言語、システム運用に関する文書や書籍を題材にチーム内の知見を深め、共通の参照基盤を構築いたしました。これにより、サービス開発速度と品質の向上に貢献いたしました。 - さらに、TypeScript、Go、Pythonのテストコード基盤を改善・構築し、カバレッジを向上させ、サービスの品質向上にも寄与いたしました。 - **機能拡充**: - 企画メンバーと連携を図り、間接的に顧客ニーズを把握し、また一方で、顧客からの問い合わせや不具合通知に迅速に対応するための運用体制を構築いたしました。 - 権限管理機能の開発では、権限判定のコアロジックを実装し、これをチームに展開することで、開発の効率化を図りました。 - 電子署名サービスとのAPI連携機能の開発に際しては、DocuSignとの連携時に先方とのミーティングをファシリテートし、機能実現に向けた課題を解決いたしました。 - **スケール対策**: - AWS Lambdaを用いて基盤を再設計し、並列処理の導入によるスケール性向上とコスト削減を実現いたしました。 - チーム内で4つのLambdaを構築し、R&Dチームとのインタフェースを共有しながら開発を進行させました。 - PythonとGoのLambdaを基盤で構築し、チームに展開することで、開発を効率的に進めました。 - 負荷テストを行った際に、バルクインサート処理でデッドロックが発生する問題がありましたが、インサートのソート順とトランザクション分離レベルの見直しによって問題を解決いたしました。 - **成果**: - 成功裏に基盤移行を完了し、これによりサービスのスケール性とコスト効率が大幅に向上いたしました。移行後も安定したサービス運用を継続し、新たな機能を迅速に追加できる体制を整えることができました。