ID:75413さん

# プロジェクト概要 カスタマーサポートの自己解決率向上を目的に、Google Dialogflow CX / Contact Center AI を用いたAIチャットサポートを、PoC から本番運用まで一貫して担当しました。段階的に4つのリリースに分けて展開し、決済サービス連携、ログイン状態に応じた会話履歴、越境ECの購入履歴連携などへ機能を拡張しています。テックリードとして技術方針の決定と、複数チームにまたがる合意形成を担当しました。 # チーム情報 フロントエンド3名・バックエンド2名（日本・インド）のチームをリード。加えて、CS部門、デザインシステム、セキュリティ、認証基盤、コンタクトセンター、外部ベンダー（Google）と横断的に連携。 # 開発・実装内容A：Dialogflow エージェントの CI/CD 基盤 **【課題】** チャットの会話フロー更新が手作業で、バージョン管理もなく、データ消失とデプロイ事故のリスクを抱えていました。またエンジニアが介在しないと更新できず、企画側のボトルネックになっていました。 **【打ち手】** GitHub Actions で CI/CD パイプラインを設計・実装。定期バックアップ、PR自動生成、承認を経たデプロイを組み合わせ、非エンジニアが安全に本番反映できる仕組みにしました。設計判断は ADR として文書化しています。 **【成果】** 手作業による高リスク運用を解消し、企画メンバーがエンジニアを介さず会話フローを更新できる状態になりました。 # 開発・実装内容B：チャット基盤の可観測性とインシデント対応 **【課題】** ベンダー側の障害時に、こちらから検知する手段がなく、ユーザー影響に気づくのが遅れる状態でした。 **【打ち手】** Playwright による E2E 監視を定期実行し、チャットの稼働状況を自動検知する仕組みを構築。あわせて Terraform とログベースメトリクスでアラートを標準化しました。実際に発生したベンダー起因の障害では、調査から Google へのエスカレーション、再発防止まで主導しています。 **【成果】** 障害検知が自動化され、ベンダー依存部分も含めた可用性の可視化ができるようになりました。 # 開発・実装内容C：クロスボーダー連携における認証設計 **【課題】** サーバー側の Dialogflow から、認証が必要な社内APIを呼び出す必要がありましたが、採用されている認証方式はブラウザセッション内でのみ成立する設計で、サーバー側からは原理的に実行できないという矛盾がありました。既存の解決策はなく、4つの組織にまたがる問題でした。 **【打ち手】** まず「認証を緩和する」案を検討しセキュリティレビューを通しましたが、API提供側のポリシーに抵触して却下されました。そこで代替として、フロントエンドを経由して認証を仲介する方式を新規に設計。OAuth/OIDC の仕様を実際に手を動かして学び、複数の実装案を PoC で比較検証した上で、セキュリティレビューを通過させ、関係チーム間の合意形成まで進めました。決定内容は ADR として残しています。 **【成果】** リリースを阻んでいた設計上の課題を、セキュリティモデルを崩さない形で解消し、実装可能な方針として確定させました。 # 開発・実装内容D：依存チームのバックエンド実装を自ら担当 **【課題】** チャット機能が別チームのバックエンドAPIに依存しており、そちらの進捗遅延で開発が停止しました。 **【打ち手】** 待たずに自分で該当リポジトリ（規約も実装ルールも異なる、未経験のコードベース）に入り、gRPC の RPC を実装。ユニットテストと grpcurl による疎通検証を行い、オーナーチームのレビューを経てマージしました。あわせて OIDC クライアントを汎用化し、以降の同種の連携で個別のインフラ設定が不要になるようにしています。 **【成果】** チーム間の受け渡し待ちを解消し、レビュアーからは数日分の工数削減と評価されました。

# 開発・実装内容A：自己解決率の向上による問い合わせ削減 **【課題】** ヘルプセンターの目的は、お客さまが自分で問題を解決できる状態をつくり、問い合わせ数を減らすことにあります。しかし、どの導線に手を入れれば自己解決につながるのかは、事前の想定だけでは精度が上がりませんでした。 **【打ち手】** 隔週で A/B テストを実施する体制を作り、施策ごとに効果を計測しながら改善を回しました。その中で成果が大きかったのが、お問い合わせを送信する前の導線で関連するガイドを提示する機能です。どのガイドが実際にクリックされたかを計測し、提示内容を継続的に改善しました。 **【成果】** 月間約17,000件の問い合わせ削減を達成しました。ガイド閲覧率 +2.62%、問い合わせ率 -3.26% という数値で効果を確認しています。 # 開発・実装内容B：AI を活用したコンポーネントのメジャーバージョン移行 **【課題】** コードベース全体にわたるメジャーバージョンアップグレードが必要で、更新対象のコンポーネントは20以上ありました。当初の見積もりでは、1四半期で全体の10%程度しか進められない想定でした。 **【打ち手】** コンポーネント単位でループを回す Claude Code の skill を作成し、移行作業を自動化しました。Chrome DevTools と連携させ、VRT（ビジュアルリグレッションテスト）で見た目の差分を自動的に検証する仕組みを組み込んでいます。生成された変更をそのまま採用するのではなく、検証を挟んだ上で取り込む形にしました。 **【成果】** 1四半期で全体の50%まで移行を完了させ、当初見積もりの5倍のペースで進めることができました。移行の進め方自体も、チーム内で再現可能な形にしています。 # 開発・実装内容C：問い合わせ対応を自動化する社内ボットの開発 **【課題】** ヘルプセンターには類似した依頼や不具合報告が繰り返し寄せられており、その調査と対応を毎回手作業で行っていました。過去に同じ事象のチケットが存在するケースも多く、それを探すこと自体にコストがかかっていました。 **【打ち手】** まず n8n でボットを構築し、既存の Jira チケットや不具合情報を横断して調査できるようにしました。関連するチケットの提示に加えて、コード上の該当箇所を特定し、修正案の作成や簡単な質問への回答まで対応できるようにしています。その後、LangChain を用いた社内ボットへ機能を拡張しました。 **【成果】** 繰り返し発生する依頼への対応が自動化され、チームが本来のプロダクト開発に集中できるようになりました。 # 開発・実装内容D：開発者体験の改善 **【課題】** CI/CD の実行時間が長く、フィードバックループが遅い状態でした。またローカルでの開発環境構築にも手間がかかっていました。 **【打ち手】** キャッシュの活用により CI/CD の実行時間を短縮。あわせて Docker 周りのスクリプトを整備し、ローカルで完結する開発フローを改善しました。AI ツールを活用するための Claude skill もチーム向けに整備しています。また、CDN を Fastly から Cloudflare へ移行しました。 **【成果】** CI/CD の実行時間を約20%短縮し、開発からリリースまでのリードタイムを改善しました。

# プロジェクト概要 分散型の暗号資産取引所をゼロから立ち上げ、海外向けにローンチしました。資産を預かる中央集権型ではなく、決済はすべてコントラクト上で行う非カストディアル型の設計です。親会社の子会社という体制の中で、エンジニアリング組織の責任者として組織の立ち上げと技術方針の決定を担当しつつ、自身も実装を担当しました。3ヶ月で初期プロダクト、1年でアルファ版を公開しています。 # チーム情報 フロントエンド4名・バックエンド3名の計7名の組織をマネジメント。採用、評価制度の設計、技術方針の決定、コードレビュー、仕様策定を担当し、親会社との契約交渉やステークホルダーとの調整も担いました。 # 開発・実装内容A：GraphQL から決済までの一連の処理設計 **【課題】** 20近いマイクロサービスが非同期に連携する構成で、フロントエンドからのリクエストが最終的にブロックチェーン上の決済に至るまで、複数のサービスとメッセージキューを経由します。全体を通した処理の流れと責務分担を設計する必要がありました。 **【打ち手】** GraphQL のエンドポイントから、各サービス間の通信、そしてブロックチェーンとのやり取りを経て決済が完了するまでの一連の処理を設計・実装しました。サービス間の通信は、同期的な応答が必要な処理には gRPC を、注文の状態遷移のように順序と再処理の保証が重要な処理には Kafka を、という基準で使い分けています。取引所という性質上、処理が途中で失敗した場合に状態の不整合が残ることが最も避けたいリスクだったため、非同期処理側にイベントログとして履歴が残る構成を選びました。フロントエンドとの境界には GraphQL を置き、複数サービスにまたがるデータ取得をクライアント側から一度のリクエストで扱えるようにしています。 **【成果】** 非カストディアル型の取引フローを、フロントエンドからオンチェーン決済まで一貫して動作する形で構築しました。 # 開発・実装内容B：分散システムにおける障害の特定 **【課題】** オーダーマッチングの処理が期待通りに完了しないケースが発生していましたが、複数のサービスとメッセージキューをまたぐため、どこで失敗しているのかがログだけでは特定できませんでした。 **【打ち手】** Datadog による分散トレーシングで処理の流れを可視化し、あわせて問題を再現するためのスクリプトを自作しました。メッセージキューの挙動を検証する社内向けのテストツールも開発し、再現性のある形で原因を切り分けられるようにしています。 **【成果】** 再現手段のなかった間欠的な障害を、原因を特定できる状態にしました。作成したテストツールは、以降の同種の調査でもチーム全体が利用しています。 # 開発・実装内容C：技術選定の見直し（Nim から Go への移行） **【課題】** 初期のサービスは、最初のエンジニアが得意としていた Nim で書かれていました。言語自体は効率的で優れているものの、採用市場に経験者がほとんどおらず、新しくジョインしたメンバーのオンボーディングに時間がかかることが組織の成長を制約していました。 **【打ち手】** 言語としての良さと、チームとしての持続可能性を比較した上で、以降の新規サービスは Go と TypeScript で実装する方針に切り替えました。 **【成果】** オンボーディングのコストが下がり、採用と開発の両面でスケールしやすい体制になりました。 # 開発・実装内容D：フロントエンド基盤の整備 **【課題】** 取引所は複数の Web アプリで構成されており、それぞれで UI を作り込むと一貫性の担保も保守も難しくなります。また、開発環境の構築に時間がかかり、新規メンバーの立ち上がりが遅い状態でした。 **【打ち手】** Next.js と Storybook で共通の UI コンポーネントライブラリとデザインシステムを構築し、2つの Web アプリを同じ基盤の上に展開しました。あわせて、開発環境のセットアップを自動化する社内ツールを作成しています。 **【成果】** UI の実装方針が統一され、新規メンバーの環境構築にかかる時間を半減させました。 # 開発・実装内容E：開発プロセスの改善 **【課題】** 実装に着手してから仕様の認識齟齬が発覚し、手戻りが発生するケースが目立っていました。チケットの粒度や記述内容もばらつきがあり、着手前に何を作るのかが曖昧なまま進むことがありました。 **【打ち手】** 実装前に仕様を固めるフローを整備し、Jira チケットの書き方と粒度を揃えるルールをチームに導入しました。あわせてドキュメントを整備し、評価制度と四半期ごとのレビューを設計・運用しています。 **【成果】** 手戻りが減り、チーム全体の開発速度が30%向上しました。評価とフィードバックの仕組みが整ったことで、メンバーの定着にもつながっています。