ID:80987さん

#### AI Helpbot (2023年 - 現在) ##### 概要 - プロジェクトオーナー兼開発リードとして、インフラヘルプデスク業務の自動化システムを企画・実装 - チーム規模: バックエンドのみ 3名 - 対象ユーザー: 社内エンジニア約3000名 ##### 課題・背景 以下のような課題があり、このプロジェクトに至った: - 従来のヘルプデスク運用では同じ質問が繰り返され、オンコール担当者の負荷が高く、過去の知見が活用されていなかった - Slackでの問い合わせからJiraチケット作成まで手動で行われており、レスポンス時間が長く(平均15分)、担当者アサインも属人的だった - 組織の拡大に伴い、ナレッジの共有と迅速な問題解決が急務となった ##### 取り組み・実装 - **RAG実装**: OpenAI APIとVector Storageを組み合わせ、過去のJiraチケットやドキュメントから関連情報を自動検索し回答を生成するLLMシステムを構築 - **プラグイン設計**: Slackイベント処理を「start support」「urgent」などのワークフローごとにプラグイン化し、拡張性の高いアーキテクチャを実現 - **Jira連携自動化**: Slackからのコマンド入力でJiraチケットを自動生成し、適切な担当者へアサインする機能を実装 ##### 使用技術 - TypeScript (Node.js), Slack API, Jira REST API - Redis, OpenAI API (RAG / Embeddings / File API） - Jest, Yarn, Kubernetes ##### 工夫した点 - プラグイン設計により、新しいワークフローを既存コードに影響を与えずに追加可能な構造を実装 - OpenAI APIのレート制限対策として、Redisを用いたキャッシュ機構を実装し、同一質問への即時応答を可能にした - 定期的にslackの全メッセージを再学習させる（頻度はコストにより調整） - 一般的な回答を禁止するプロンプト（e.g. 社内ではOS upgradeが禁止されているのにupgrade手法を回答しないように制限する etc） - MCPを使い過去の類似スレッドを案内する（開発中）

#### Lista Project - サーバー権限管理システム (2025年 - 現在) ##### 概要 - LINE・ヤフー合併に伴う統合クラウド基盤のサーバーログイン権限管理システムの２代目プロジェクトリード - チーム規模: バックエンド5名、フロントエンド3名、インフラ2名 - プロジェクトスコープ: 10以上の社内チームとの連携、3環境(LINE/Yahoo/LY)横断システム ##### 課題・背景 以下のような課題があり、このプロジェクトは始まった - LINE・ヤフー合併に伴い、異なる認証システムとアクセス管理が混在し、統一的な権限管理が急務だった - 当初はLY合同環境専用で構築されたが、LINE/Yahoo/LYを横断する統合システムに拡張するため、旧環境の2システムを持つ自部署に移譲された - システムは Java で書かれていたが、メンバーは Java がほぼ未経験 ##### 取り組み・実装 - **マルチ環境アーキテクチャ設計**: LINE、Yahoo Japan、LYの3環境を横断し、各環境のKerberos/Active Directory等と連携するシステムを設計 - **連携API実装**: 枯れた既存システムを活用しながら新システムに融合できるインターフェイス設計 - **API Gateway統合**: 複雑なProxy構成により、各環境への認証・認可を統合的に管理するマイクロサービスアーキテクチャを実装 - **LDAP統合**: Python (FastAPI)を用いてWindows AD オブジェクトを管理し、ユーザー・グループの同期を自動化 - **Web UI開発**: TypeScript (React)で管理画面を開発し、権限申請・承認ワークフローを実装 ##### 使用技術 - Java (Spring Boot 3.2), TypeScript (React 18), Kafka 3.5 - Python 3.11 (FastAPI 0.104), LDAP, Windows Active Directory - 複雑な Proxy, API Gateway, Kubernetes - プライベートクラウド(Verda/Flava) ##### 工夫した点 - SpringBootの学習コストを下げるため Cline, Claude Codeをフル活用。ほぼJava未経験チームでのシステム受け入れを1ヶ月で完了。勉強会をリード。 - 段階的移行を可能にするため、既存システムと新システムのハイブリッド運用期間を設け、各チームが任意のタイミングで移行できる仕組みを構築 - 10以上のステークホルダーチームとの要件調整において、open communicationを徹底することで透明性の高いプロジェクト運営を実現 ##### 成果 - 複雑なステークホルダー環境下で、予定通りのスケジュールでプロジェクトを完遂中 - 移行期間中も開発生産性を維持し、サービス停止時間ゼロで移行を完了

#### TLS/Certificate Manager Project (2019年 - 現在) ##### 概要 - プライベートクラウドにおけるAWS ACM相当のTLS証明書マネージドサービスの企画・設計・開発リード - 対象規模: 20万以上のTLS証明書エンドポイントを管理 - チーム規模: バックエンド4名、フロントエンド2名 ##### 課題・背景 以下のような課題があり、このプロジェクトに至った: - LINEとYahoo Japan合併により、20万以上の証明書が分散管理され、期限切れリスクと運用負荷が増大していた - 手動での証明書申請・更新作業が大きなボトルネックとなり、1件あたり平均30分の作業時間が必要だった - CA/Browser Forumの証明書有効期限短縮方針(2年→1年→90日→47日)への対応が困難で、将来的な運用破綻が予測された - AWS ACM相当のマネージドサービスがプライベートクラウドに存在せず、開発者の生産性が低下していた ##### 取り組み・実装 **フェーズ1: 自動購買システム(2019-2023年)** - 証明書申請システムを開発し、Private Cloud の Openstack Designate と連携し申請から発行までの全プロセスを自動化 - Pythonで安定運用するための Pipeline を実装し、エラー時の復帰を簡単に実行できるようにした **フェーズ2: 可視化システム(2023-2024年)** - 社内20万の TLS endpointをスキャンし、証明書の有効期限を自動収集・可視化するシステムを構築 - Vue/Kibanaでダッシュボードを開発し、証明書の期限切れリスクをリアルタイムで可視化・通知 **フェーズ3: Private Cloud Component 化(2023-現在)** - AWS ACM相当の「Flava Certificate Manager」をゼロから設計・実装 - Kubernetesで高可用性・スケーラブルなシステムを実現 ##### 使用技術 - Python 3 (Django, FastAPI) - Go - Kubernetes, Docker - Openstack Designate/Keystone - Vue.js / React ##### 工夫した点 - data drivenな企画。リサーチ後にもっともコスパの良いものを優先度高く実施 - 自動化に必須な人間の動きを変える点は丁寧に現場に説明、納得感を持って進めてもらう - 現場の意見を積極的に採用しモチベーションUP - 段階的実装により、各フェーズで価値を提供しながら、最終的なフルマネージドサービスへと進化させた - GlobalSignとの良好な関係を築き、協業体制を受け入れてもらい積極的なサポートをしてもらった ##### 成果 - 証明書申請の95%を作業時間ゼロで処理 - LY統合クラウドにおけるAWS ACM相当のCertificate Managerを構築し、開発者生産性を大幅向上 - 日経コンピュータ4ページ特集、日経クロステック2記事、LINEヤフーTech Blog 2記事で紹介される **メディア掲載:** - 日経コンピュータ 2025年10月30日号（4ページカラー特集） - 日経クロステック Web記事 2件 - 「LINEヤフー、Webサイトの証明書購買を自動化　申請の9割を作業時間ゼロに」 https://xtech.nikkei.com/atcl/nxt/column/18/00678/102300167/ - 「Webサイトの証明書購買を自動化　可視化により有効期限の短縮に備え」 https://xtech.nikkei.com/atcl/nxt/mag/nc/18/020600004/102200194/ - LINEヤフー Tech Blog 2件 - 「SSL証明書の購買を自動化した話」 https://techblog.lycorp.co.jp/ja/20231219a - 「20万以上のSSL証明書の有効期限を見える化した話」 https://techblog.lycorp.co.jp/ja/20241225c

#### ファイルシステム自動修復ツール開発 (2020年) ##### 概要 - Linuxサーバーのファイルシステム障害の自動修復ツールを単独で設計・開発 - 対応ファイルシステム: XFS, EXT4 - 対象サーバー: プライベートクラウド内数百台のLinuxサーバー ##### 課題・背景 以下のような課題があり、このプロジェクトに至った: - Linuxサーバーのファイルシステム障害発生時、手動復旧作業により平均60分以上のサービス停止が発生していた - 複数のファイルシステム（XFS/EXT4）への対応や、障害レベルに応じた適切な修復手順の判断が属人的だった - 復旧作業の結果記録が標準化されておらず、ナレッジの蓄積と共有が困難だった ##### 取り組み・実装 - **段階的修復ロジック設計**: 軽度の通常修復から、重度障害対応の強制修復まで、段階的にエスカレーションするロジックをBashスクリプトで実装 - **ファイルシステム自動検出**: XFS、EXT4を自動判別し、適切な修復コマンド(xfs_repair, fsck)を選択する機構を実装 - **構造化ログ出力**: 修復結果をJSON形式で出力し、curlで社内リポジトリへ自動アップロードする仕組みを構築 - **耐障害性テスト**: `dd`コマンドでboot sectorやsuperblockを意図的に破壊し、ツールの修復能力を検証 ##### 使用技術 - Bash, jq (JSON処理) - parted (パーティション情報取得) - xfs_repair (XFS修復), fsck (EXT4修復) - curl (API通信) - dd (テスト用データ破壊) ##### 工夫した点 - Safe Bootで使えるコマンドだけに限定して実装 - 障害の重度を自動判定し、軽度なら通常修復、重度なら強制修復を適用するエスカレーションロジックを実装 - 修復結果をJSON化することで、後続の分析やダッシュボード表示に活用できる構造を実現 - `dd`を用いた破壊テストにより、本番環境での信頼性を事前に検証 ##### 成果 - ファイルシステム障害復旧時間を平均80%短縯(平均60分 → 12分) - 復旧作業の標準化とナレッジベース構築により、属人性を排除 - 深夜・休日対応の削減により、運用コストを年間約500時間削減

**東北物語 - 観光庁総合観光ポータル (2014年 - 2016年)** - **概要** - 東北6県の総合観光ポータルサイト - **規模**: 担当7名 - **役割** - 観光庁入札プロポーザル - 企画、Webデザイン、開発、運用 - **成果** - CMSの基礎部分を単独で構築, 最新外部ライブラリの積極採用 - **技術スタック** - PHP, JavaScript, Vue.js, MySQL, CentOS, Ubuntu

#### SRE: インフラプロジェクト群 (2010年 - 2018年) **Docker本番導入 (2016年)** - 富士通初の本番Docker利用 - Nifty Cloud上8台のVM移転 - 旧ネットワーク構成のエミュレート, 社内監査人に Docker の技術を説明するところから始めて説得 **クラウド移行・スケーリング (2016年 - 2018年)** - 主要クラウドサービス調査・導入（AWS, GCP, Azure, Nifty Cloud, K5） - GKE/ECS等コンテナサービスの本番導入（富士通初） - ハイブリッドクラウド構成の設計・実装, チーム勉強会の主催 **オンプレミスインフラ最適化 (2015年 - 2018年)** - Zabbix/Slack/LINE連携による監視自動化 - 自動復旧アクション構築 - 夜間メンテから昼間メンテへの移行（自動化・冗長化）, サーバ設定自動バックアップ **ネットワーク IP address range 移転 (2016年 - 2017年)** - IP adress 不足解消のための IP address 移転 - 10台以上の本番サーバー移転, 最小停止時間での実施 - Fortigate Firewall, Barracuda Load Balancerの運用