ID:84106さん

## プロジェクト経験概要 約1,000人が利用する工場のインシデント管理システムについて、ISO22000の外部監査で既存の外注システムが業務実態と乖離していると指摘され、早急なリプレイスが必要となった。業務知識を持つ自分が内製する方が優位と判断して立候補し、PM兼リードエンジニアとして要件定義から設計・実装・運用まで担当。6ヶ月の予定を4〜5ヶ月で完遂した。 ## チーム情報 プロジェクト体制4名（自分、自チームのマネージャー1名、インフラ1名、依頼部門のマネージャー1名） - **自分**：PM兼リードエンジニア。要件定義、設計、実装、進捗管理、開発基盤整備、依頼部門との調整 - **自チームのマネージャー1名**：進捗管理に加え、DB操作に精通していたため旧DBから新DBへのデータ移行を担当（自分がアサインを提案） - **インフラ1名**：サーバー環境の構築・運用 - **依頼部門のマネージャー1名**：品質保証部門側の要件提示・レビュー担当 ## 開発・実装内容A：内製化の意思決定と開発方針の策定 ### 概要 外注での再構築ではなく内製を選択する判断と、限られた納期で実用性を担保する開発方針の策定。 ### 課題・問題点 - ISO22000の外部監査で指摘を受けたため、期限が明確に切られていた - 既存の外注システムは業務実態と乖離しており、同じ作り方では同じ問題が再発する懸念があった - 外注で作り直す選択肢もあったが、コストと要件適合性の両面で判断が必要だった ### 打ち手・使用した技術 - 業務知識を持つ自分が内製する方が、コスト面でも要件適合性の面でも優位と判断し、社内開発に立候補した - 限られた納期の中で実際に使われるものを作るため、最小機能でリリースしてユーザーのフィードバックを受けながら改善する方針を採用。仕様を固めきってから作るのではなく、実際の利用と並走させることで、業務実態との乖離が再発しない形にした ## 開発・実装内容B：部門への共同開発基盤の導入 ### 概要 開発基盤が存在しない状態からGit環境を新規に構築し、部門全体の開発体制を整備。 ### 課題・問題点 それまではローカル上でファイルを複製してバージョンを分ける運用になっており、変更履歴が追えず、複数人での並行開発ができない状態だった。内製開発を継続していくうえで構造的なリスクになっていた。 ### 打ち手・使用した技術 Git環境を部門に新規導入し、バージョン管理と共同開発の基盤を整備。このプロジェクト単体ではなく、部門としての内製化を継続できる状態を作ることを意図した。 技術：Git ## 開発・実装内容C：情報の乏しい独自フレームワークのキャッチアップ ### 概要 社内で採用されていた汎用性の低いフレームワークを、独学で習得しながら開発を進めた。 ### 課題・問題点 利用していたフレームワークは一般的な普及率が低く、Web上の情報も書籍もほとんど存在しない状態だった。当時はAIによる補助も実用に足るものがなく、調べても解決しない日が発生していた。 ### 打ち手・使用した技術 公式ドキュメントの精読と、フレームワーク内部のクラス実装を直接読み込むことで挙動を把握。仮説を立てて試すサイクルを回しながら習得し、期限内での実装につなげた。 技術：Java 8、JavaScript、MySQL、AWS EC2 ## 開発・実装内容D：依頼部門との要件調整とメンバーアサイン ### 概要 要件定義の推進と、メンバーの強みに応じたタスク配分。 ### 課題・問題点 - 依頼元の担当者は要望を数多く挙げてくる一方で、優先順位や工数感が共有されていなかった。認識のズレが手戻りに直結する状況だった - チームメンバーはアプリケーション開発の経験に差があり、一律に実装を割り振ると進行が滞る懸念があった ### 打ち手・使用した技術 - 依頼内容をまず受け止めて理解したうえで、優先順位と工数感を提示し、仕様について都度コミュニケーションを取りながら整理・主導した。信頼関係を作りながら進めることで、要望の取捨選択を合意できる状態にした - アプリ開発は不得手だがDB操作に精通しているメンバーを、旧DBから新DBへの移行担当に配置。強みが活きる領域に割り当てることでチーム全体の進行速度を確保した ## 成果 - 6ヶ月の予定を4〜5ヶ月で完遂 - ISO22000外部監査の指摘事項をすべて解消 - 利用者から感謝のフィードバックを獲得 - 0→1で要件定義から開発・運用までを主導した経験を社内LTで共有し、部門の内製化推進に貢献

## プロジェクト経験概要 メインプロダクトである3モール分析SaaS（楽天・Amazon・Yahoo）の検索機能において、状態管理の複雑さに起因するパフォーマンス低下とバグ多発が発生していた。リプレイス方針の中で、UI刷新だけでは根本解決しないと判断し、状態管理の再設計を中心に据えて改修を担当した。入社直後の案件であり、型のない既存コードの解析から着手した。 ## チーム情報 開発チーム3名（マネージャー1名、フロント・バックエンド2名） - **自分（フロント・バックエンド2名のうち1名）**：検索機能の状態管理設計、コンポーネント設計、実装 - **マネージャー1名**：リプレイス方針の決定、進捗管理、設計相談 - **エンジニア1名**：フロント・バックエンドの実装を分担 ## 開発・実装内容A：分散した状態管理の再設計 ### 概要 パフォーマンス低下とバグの根本原因である状態管理を再設計。設計・実装を担当。 ### どのような機能の開発・実装か 複数の検索条件を保持し、条件の変更に応じてデータを取得・表示する検索機能全体の状態管理。 ### 課題・問題点 - 親子コンポーネントがそれぞれ別々にStateを保持しており、どこで何が管理されているか追えない構造になっていた - 一部の処理でしか使わない値が常に更新対象になっており、不要な再レンダリングと再フェッチが多発していた - 結果として表示速度が劣化し、バグの温床にもなっていた ### 打ち手・使用した技術 - 分散していたStateを親コンポーネントに集約し、状態の所在を一元化して再レンダリングを最小化 - 一部処理にのみ使う値を分離し、無関係な更新でデータ取得が走らないようにした - 表示用のStateと実際に検索へ渡すStateを分けて管理し、意図しないタイミングでのフェッチを防いだ - 操作から表示までのフロー全体を見直し、ボトルネックとなる処理を再設計した 技術：TypeScript（Vue 3 / Nuxt 3） ## 開発・実装内容B：型のない既存コードの仕様可視化 ### 概要 改修の前提となる既存仕様の解析を担当。 ### 課題・問題点 既存コードには型がなく、さらに複数箇所でパラメータが上書きされていたため、コードを読むだけでは実際の挙動を把握できなかった。ドキュメント化されていない隠し仕様も多く、当時はAIによるコード解析の精度も十分ではなかった。 ### 打ち手・使用した技術 コード全体にログを仕込み、実際のデータの流れを追跡することで隠し仕様を可視化した。把握した仕様を新しい設計に反映することで、既存の顧客体験を損なわずに内部構造を刷新できる形にした。 ## 開発・実装内容C：レイアウトの刷新 ### 概要 検索条件のUI配置を見直し、画面の情報量を確保する再設計を担当。 ### 課題・問題点 検索条件が左ナビゲーションに配置されており、データ表示領域が圧迫されていた。分析ツールとして一度に見られる情報量が少なく、操作性の面でも顧客から使いにくいとの声が上がっていた。 ### 打ち手・使用した技術 左ナビゲーションを廃止し、検索条件を画面上部に集約するレイアウトへ変更。分散していた検索条件を統合することで操作を一元化し、あわせてデータ表示領域を広く確保した。 ## 成果 - 既存版と新規版で同一フローを比較し、操作から表示までの速度を約2/3に短縮 - 顧客から「サクサク動くようになった」との評価を獲得 - レイアウト刷新により表示領域が広がり、後続でYoY比較などのUI拡張が実装可能になった

## プロジェクト経験概要 CS業務が逼迫する中、既存のFAQ型チャットボットでは対応が頭打ちとなっており、RAG構成のAIチャットボットへ刷新するプロジェクト。開発メンバーとして参加し、フロントエンドからAPI・DB設計、プロンプト設計、運用分析の仕組みまでを担当した。リリース後の運用も継続して担当している。 ## チーム情報 開発チーム4名 ## チーム情報 開発チーム4名（マネージャー1名、インフラ1名、フロント・バックエンド2名） - **自分（フロント・バックエンド2名のうち1名）**：チャットUIの実装、API・DB設計、プロンプト設計、分析・運用機能の設計と実装。DynamoDB・Lambda・CDKなどアプリケーション寄りのAWSリソース設計も担当 - **マネージャー1名**：進捗管理、CS部門との調整 - **インフラ1名**：ネットワークおよび共通基盤の設計・構築 - **エンジニア1名**：フロント・バックエンドの実装を分担 CS部門とは、要件のヒアリングおよびリリース後の運用連携先として関わった。 ## 開発・実装内容A：FAQ型からRAG構成への刷新と配信方式の設計 ### 概要 既存チャットボットの刷新にあたり、アーキテクチャと配信方式を設計。 ### どのような機能の開発・実装か ユーザーの質問に対し、関連性の高い社内ドキュメントを検索して回答を生成するチャットボット。既存Webサービスに外部JSとして差し込む形で配信する。 ### 課題・問題点 - 既存のFAQ型チャットボットは決まった質問にしか答えられず、CS業務の負荷軽減に限界があった - 既存システムが古いNode環境で動作しており、最新パッケージが利用できず型システムもないため、内部に実装すると開発効率とメンテナンス性が悪化する - ライセンス更新の判断が保留されており、刷新するか継続するかを決める必要があった ### 打ち手・使用した技術 - **RAG構成の採用**：ユーザーの質問と関連性の高いドキュメントを動的に引き出す必要があったため、ベクトル化による検索を前提としたRAGが最適と判断 - **Reactによる外部JS配信**：サーバー不要な構成にすることで、古い既存環境に手を入れずに導入でき、かつ他のWebサービスにも同じJSを差し込んで再利用できる形にした。チームがReact/TypeScriptに慣れていた点も選定理由 - **Bedrock + AWS集約**：ベクトルDBを含む周辺環境がマネージドで提供されるため運用コストが低く、既存システムもAWSに集約されていたため運用を統一できる。当時ドキュメントと事例が充実していた点も評価した 技術：TypeScript（React）、Amazon Bedrock ## 開発・実装内容B：チャット履歴のDB設計とセキュリティ担保 ### 概要 チャット履歴を保持するDynamoDBの設計と、アクセス制御の設計・実装を担当。 ### どのような機能の開発・実装か チャットの会話履歴の保存・取得、および長期データのアーカイブ。 ### 課題・問題点 - チャット履歴は件数が増え続けるため、設計を誤るとScanが発生してコストとレイテンシが跳ね上がる - 問い合わせ内容には顧客情報が含まれる可能性があり、アクセス範囲を絞る必要があった - 古い履歴も分析用途で残したいが、DynamoDBに保持し続けるとコストが増大する ### 打ち手・使用した技術 - アクセスパターンを先に整理し、Scanを避けられる形でPK/SKを設計 - 一定期間を過ぎたデータはS3へアーカイブし、分析時はAthenaでクエリする構成にしてコストを抑制 - Lambda単位でIAMのアクセス権限を分離し、必要最小限の権限のみを付与 技術：Amazon DynamoDB、Amazon S3、Amazon Athena、AWS Lambda、AWS CDK ## 開発・実装内容C：レスポンス形式の構造化 ### 概要 プロンプト設計と、AIレスポンスの制御を担当。 ### 課題・問題点 LLMの出力は形式が安定せず、そのまま表示すると読みにくかったり、UI側でパースできないケースが発生する。 ### 打ち手・使用した技術 プロンプトをMarkdown形式で送り、Markdown形式で返させることで出力を構造化。フロントエンド側でそのままレンダリングでき、回答の可読性と表示の一貫性を担保した。 ## 開発・実装内容D：精度改善と有人対応のフィードバックループ設計 ### 概要 AIが完全ではない前提に立ち、運用しながら精度を上げる仕組みを自ら提案・実装。 ### どのような機能の開発・実装か - 利用状況とよくある質問を定期バッチで解析し、結果をCSへ送る仕組み - 回答できなかった問い合わせをSlackへ通知し、人に引き継ぐ仕組み ### 課題・問題点 RAGは投入するドキュメントの質に精度が依存するため、リリースして終わりでは改善が進まない。またAIが答えられない質問が必ず発生するため、顧客が行き止まりになる導線を残せない。 ### 打ち手・使用した技術 - 定期バッチで利用率とよくある質問を解析し、結果のみをCSへ連携。CSが自ら集計する工数を削減しつつ、ヘルプセンターの拡充に活用できるようにした - 回答できなかった場合はSlackへ通知し、人が対応に入れる窓口を設計・実装。完全自動化を目指さず、人の介入ポイントを残す設計とした 技術：AWS Lambda、Slack API ## 成果 - メールでの問い合わせ件数を25%削減 - CS業務に「まずチャットボットで」という新しい運用フローを定着させた - 解析結果をヘルプセンターの拡充に活用する改善サイクルを構築 - リリース後の運用も継続して担当

## プロジェクト経験概要 急成長中のTikTok Shopが日本市場に参入したことを受け、新規EC市場向けのBIツールを0→1で立ち上げるプロジェクト。約3ヶ月でのリリースが必要な一方、将来の既存環境刷新やグローバル展開を見据えた保守性・拡張性の両立も求められた。フロントエンドリードとして参画し、UI・プラン体系の再設計、コンポーネント設計、API設計、権限制御の設計を担当した。 ## チーム情報 開発チーム4名（マネージャー1名、インフラ1名、フロント・バックエンド2名） - **自分（フロント・バックエンド2名のうち1名）**：フロントエンドリード。UI/プラン体系の再設計、コンポーネント設計の主導、API設計、権限制御設計、ライブラリ選定を担当。CloudFrontのキャッシュ設定などアプリケーション寄りのAWSリソース設計にも関与 - **マネージャー1名**：進捗管理、社内調整 - **インフラ1名**：ネットワークおよび共通基盤の設計・構築（技術選定はチームで議論のうえ主導） - **エンジニア1名**：フロント・バックエンドの実装を分担 中国拠点のクローリングチームとは、データ提供元として仕様調整を行った。 ## 開発・実装内容A：UI・プラン体系のシンプル化 ### 概要 既存BIツールの複雑性を反省点として、新規プロダクトのUIとプラン体系を再設計。設計は自分が主導。 ### どのような機能の開発・実装か 分析データを閲覧する画面構成と、その利用範囲を決めるプラン体系。 ### 課題・問題点 - 既存BIツールはページ遷移によるドリルダウンが複雑で、顧客が目的のデータに辿り着きにくかった - プランが機能×カテゴリ単位で10以上あり、顧客が何を買えばよいか判断できず、意思決定コストが高かった - 新規市場への参入である以上、既存プロダクトの失敗を繰り返さず、かつ3ヶ月でリリースする必要があった ### 打ち手・使用した技術 「顧客の意思決定コストを下げる」ことを設計方針の中心に据え、以下を採用した。 - UIをテーブル・検索・詳細ページの3画面に集約し、多段のドリルダウンを排除 - プランを4プラン×全カテゴリ解放に再設計し、機能単位の購入判断を不要にした 技術：TypeScript（Next.js） ## 開発・実装内容B：短期間と保守性を両立する設計基盤の構築 ### 概要 3ヶ月という制約下で品質を担保するため、フロントエンド・バックエンド共通の設計基盤を構築。コンポーネント設計は自分が主導。 ### どのような機能の開発・実装か 型定義の共通化、コンポーネントの再利用構造、APIの設計。 ### 課題・問題点 短期間での0→1開発では、実装速度を優先すると型の不整合や実装の重複が発生し、リリース後の保守コストが跳ね上がる。一方で設計に時間をかけすぎると納期に間に合わない。 ### 打ち手・使用した技術 - DTOとOpenAPIでフロントエンド／バックエンドの型を共通化し、実行時バリデーションも含めて仕様のズレを防いだ - コンポーネントを横展開しやすい構造で設計し、開発速度と画面間の一貫性を両立させた - サーバーコンポーネントとクライアントコンポーネントの責務を分けて設計した 技術：TypeScript（Next.js / NestJS）、OpenAPI ## 開発・実装内容C：権限制御の多層設計 ### 概要 プラン体系に応じた表示・データ制御を、フロントエンドとバックエンドの多層で設計・実装。 ### どのような機能の開発・実装か 契約プランに応じて閲覧可能なデータ・機能を制御する仕組み。 ### 課題・問題点 フロントエンド側に権限判定ロジックを持たせると条件分岐が肥大化し、シンプルな設計方針と矛盾する。一方でフロントのみの制御ではAPIを直接叩かれた際に防御できない。 ### 打ち手・使用した技術 - バックエンドで権限フラグを管理し、レスポンスに含めて返す - フロントエンドは受け取ったレスポンスを起点に表示を制限するのみとし、判定ロジックを持たせない - 公開APIでないエンドポイントはNestJSのミドルウェア（Guard）で保護し、API直叩きを防いだ 技術：NestJS（ミドルウェア／Guard） ## 開発・実装内容D：実装課題への技術提案 ### 概要 実装・検証の過程で見つけた課題に対し、自ら代替案を提案・実装した。 ### 課題・問題点と打ち手 - **TikTokのサムネイル取得が不安定**：テスト中に表示崩れが頻発したため、Iframeによる表示を代替案として提案・採用し、ユーザー体験を担保した - **Cookieとキャッシュの競合**：ログイン機能の実装時にCookieのドメイン制約とCDNキャッシュの相互作用に気づき、通信経路とCloudFrontのキャッシュ設定（GETのみ対象、Cookieを含めない等）を整備した - **ライブラリ選定**：グラフ・ORM・Excel出力など、同一機能で複数の選択肢がある領域は、バンドルサイズ・保守性・使いやすさを比較して軽量なものを選定した 技術：Amazon CloudFront、Amazon ECS、AWS CDK ## 開発・実装内容E：中国拠点チームとの仕様調整 ### 概要 データ提供元である中国拠点のクローリングチームと、API仕様の調整を担当。 ### 課題・問題点 提供されるドキュメントが中国語であり、かつクローリング由来のデータのため取得が不安定なケースがあった。言語の壁により仕様の認識齟齬が発生しやすい状況だった。 ### 打ち手・使用した技術 AI翻訳を用いてSlackでのやりとりとドキュメント読解を行い、エンドポイント・リクエスト／レスポンスのパラメータを技術仕様として整理して伝達することで、言語に依存せず認識を揃えられる形にした。 ## 成果 - 約3ヶ月で0→1リリースし、シンプルなUIとプラン体系で新規EC市場へ参入 - リリース後、顧客の採用が進行中 - AWSの担当営業から取材を受け、マネージドサービス活用とCDKによる開発速度・運用効率の改善事例として紹介された

## プロジェクト経験概要 SaaSでありながら申込書ベースの手売りに依存しており、新規リード獲得の導線と人員リソースが逼迫していた。新規プロダクトの契約形態が既存と異なることを機に、自動決済の導入を自ら提案・立候補し、プロジェクトリーダーとして参画。エンジニアは自分1名の体制で、要件定義から決済基盤・外部システム連携の設計・実装、部署横断の合意形成、リリース後の運用体制整備までを一貫して担当した。 ## チーム情報 プロジェクト体制4名（マネージャー1名、エンジニア1名、事業管理2名） - **自分（エンジニア1名）**：プロジェクトリード。要件定義、Stripe決済の設計・実装、Salesforce/HubSpot/GA4連携の設計・実装、LP実装、テスト設計、部署横断の合意形成、ドキュメント整備まで一貫して担当 - **マネージャー1名**：進捗管理、社内調整の後ろ盾 - **事業管理2名**：売上計上・契約フローの要件提供、テスト検証、リリース後の契約対応 エンジニアは自分1名のため、フロントエンドからバックエンド、外部システム連携まで全工程を単独で実装した。法務・営業・マーケティングとは要件確認およびレビューの形で連携した。 ## 開発・実装内容A：決済プロバイダの選定とStripe決済基盤の実装 ### 概要 決済プロバイダの選定から、申込〜決済〜継続課金までの基盤設計・実装を単独で担当。 ### どのような機能の開発・実装か 新規顧客がWeb上で申し込みから決済まで完結できる導線と、その後の継続課金を処理する仕組み。 ### 課題・問題点 - 従来は営業による手売りのみで、Web上で決済できる導線が一切なかった - サービスを気軽に試してもらう機会がなく、新規リードの獲得手段が営業のリソースに依存していた - 決済という失敗できない領域のため、セキュリティ基準やコスト構造も含めた選定判断が必要だった ### 打ち手・使用した技術 Stripeを以下の理由で選定した。 - APIファーストで設計されており、既存アプリケーションへの組み込みが柔軟 - ドキュメントが充実しており、少人数でも短期間で実装可能 - 審査までの日数が短く、スピード重視の要件に合致 - Checkoutがノーコードで利用でき、決済フォーム実装のコストを削減できる - PCIセキュリティ基準を満たしており、自社でカード情報を保持しなくてよい - コストが決済手数料のみで、固定費が発生しない 技術：TypeScript（Next.js / NestJS）、Stripe ## 開発・実装内容B：分断された業務システムの自動連携設計 ### 概要 手動運用されていたSalesforce・HubSpot・GA4を、決済フローに統合して自動連携する設計・実装を単独で担当。 ### どのような機能の開発・実装か 決済完了を起点に、売上計上データのSalesforce登録、マーケティングデータのHubSpot連携、GA4での計測を自動で行う仕組み。 ### 課題・問題点 既存システムがそれぞれ独立して運用されており、以下の状態だった。 - Salesforce：営業が手動で入力 - HubSpot：API連携ではなくフォーム経由の手入力 - GA4：LPの外注先が個別に設定 売上計上の整合性を人力で担保しており、部署をまたいだ手作業が発生していた。さらに、システムごとに時刻の粒度が異なる（Stripeは秒単位、自社とSalesforceは日単位）など、仕様の差異を吸収する必要があった。 ### 打ち手・使用した技術 各部署に要件をヒアリングし、業務フロー全体を把握したうえで、決済完了イベントを起点に各システムへ自動連携する設計に統合した。新規に好きな形で作るのではなく、既存の業務制約と各システムの仕様差を吸収する形で要件を満たすことを設計方針とした。 技術：Salesforce、HubSpot、GA4、Google Tag Manager ## 開発・実装内容C：複雑な課金タイミングのテスト設計 ### 概要 継続課金の日付計算に関するテスト設計と実施を単独で担当。 ### 課題・問題点 月の日数差（31日・30日・2月）、うるう年、月末締めなど、継続課金には境界条件が多数存在する。決済は誤りが直接顧客の請求に影響するため、網羅的な検証が必須だった。 ### 打ち手・使用した技術 Stripeのテスト用シミュレーション機能を用いて、時間を進めながら各境界ケースを網羅的に検証。また、Salesforce側の検証では、自分が実際の業務フローを再現してテストデータを作成し、事業管理側が内容を確認するだけで済む形に整えることで、他部署の検証負荷を下げた。 ## 開発・実装内容D：部署横断の合意形成とドキュメント整備 ### 概要 エンジニア以外の部署を巻き込んだ合意形成と、社内への技術継承を担当。 ### 課題・問題点 決済は事業管理・法務・営業・マーケティングと関係部署が多く、それぞれ関心事が異なる。認識のズレが手戻りに直結する構造だった。 ### 打ち手・使用した技術 マネージャーと事業管理を起点に巻き込み、そこから先は各部署のスコープで連鎖的に対応してもらう形で進めた。説明は「プラン仕様」「Stripeの仕組み」「既存システムの仕様」の3軸に分けて並行して行い、非エンジニア部署でも判断できる粒度に翻訳した。リリース後はドキュメントを整備し、社内勉強会で仕組みを共有して属人化を防いだ。 ## 成果 - 自動決済経由の申込が0から立ち上がり、目標の10%を達成しながら増加中 - 人力で担保していた売上システム間の整合を自動化し、部署をまたいで活躍した人材として人事部から社内表彰を受けた - 運用体制をシステム面は自分、契約対応は事業管理が担当する形に整理し、継続運用できる状態にした

## プロジェクト経験概要 データ分析企業において、独自データの提供インターフェースをBIツールからAIエージェントへ移行するという事業戦略のもと、新規プロダクトを0→1で立ち上げるプロジェクト。リードエンジニアとして課金モデル・権限体系の設計を主導し、あわせてtool実装と開発基盤の整備を担当した。 ## チーム情報 3名体制（マネージャー1名、エンジニア2名） - **自分**：バックエンド主担当。課金・権限のDB設計と実装、tool実装、技術選定への関与、CI/CD整備 - **マネージャー1名**：PMとの折衝、要件・方針の意思決定 - **エンジニア1名**：フロントエンド中心（自分は設計・レビューを担当） 事業部・営業とは、課金プランの提案先およびレビュー相手として連携した。 ## 開発・実装内容A：クレジット消費型の課金モデル設計 ### 概要 AIエージェント利用の課金プランを設計し、事業部へ提案・採用された。設計は自分が単独で担当。 ### どのような機能の開発・実装か 複数toolsを組み合わせて顧客の要望に応えるエージェントに対し、利用量に応じてクレジットを消費させる仕組み。tools別の重み×呼び出し回数×データ取得期間の係数でクレジットを算出するモデルを設計した。 ### 課題・問題点 - 機能別課金は、複数toolsを一つの窓口で組み合わせる要件と構造が合わない - 純粋な従量課金は、LLMのトークン量に加えデータ量の重みなど変数が多く、tool追加のたびに管理コストが増える - 変数が多いと顧客の感覚と乖離し、営業が説明できない ### 打ち手・使用した技術 「顧客が理解できる粒度」と「tool追加への拡張性」の両立を判断軸に置き、変数を3つに絞ったクレジット消費モデルを採用した。他社のクレジット型課金事例を調査して要件適合性を検証したうえで設計。事業部から「営業が説明しやすい」「要件を満たしている」と評価され採用に至った。 ## 開発・実装内容B：契約・権限・クレジットのDB設計 ### 概要 既存SaaSのユーザー権限を維持しつつ、新規プロダクトを別体系で管理する契約・権限・クレジットのデータモデルを設計・実装。自分が単独で担当。 ### どのような機能の開発・実装か 契約とプランに応じてエージェントの利用可能範囲を制御し、クレジットの付与・消費・残高を管理する基盤。 ### 課題・問題点 - PoC段階のプロダクトで、プラン体系や集計ロジックが今後変わる可能性が高い - 既存SaaSの権限体系に新規プロダクトの権限を載せると既存顧客に影響が出るリスクがある - 正規化を進めるとJOINが増え、参照系のパフォーマンスが劣化する ### 打ち手・使用した技術 仕様変更への追従性を最優先に、以下の方針で設計した。 - **正規化を徹底し、変更点をDB側に閉じ込める**：プランと権限はIDマスタとして切り出し、それに紐づくデフォルトクレジットや有効期限をテーブルで管理。プラン変更をコード修正なしでマスタ更新のみで吸収できる構造にした - **集計ロジックをアプリケーション側に寄せる**：集計結果を持たず、消費・付与のトランザクションデータのみを保持。集計方法が変わってもデータ移行が不要になる - **クレジットはサイクル単位で管理**：契約更新の周期ごとに残高を管理し、契約自体は積み上げ式で履歴を保持する形にした - **既存権限は変更せず、新規側を独立体系に**：契約とプランを起点に権限を導出する構造にすることで、将来の統合時にもマッピングで対応可能にした - **正規化のトレードオフをインデックスで補完**：常にJOINされるカラムやORDER BY対象に単一・複合インデックスを設定し、参照性能を担保した 技術：Amazon RDS ## 開発・実装内容C：エージェントのtool実装と技術選定 ### 概要 エージェントフレームワーク・実行基盤の技術選定に関与し、toolの設計・実装を担当。 ### どのような機能の開発・実装か 自分が実装したのは2つのtool。 - 商品名やURLなどの入力を自社の商品IDに名寄せ・変換するtool - 変換したIDをもとに自社の商品データを検索するtool ### 課題・問題点 0→1かつ少人数体制のため、評価・観測基盤を自前構築すると立ち上げが間に合わない。またAIエージェント領域はフレームワークが乱立しており、選定を誤ると保守コストが跳ね上がる。 ### 打ち手・使用した技術 - **Mastra採用**：候補としてStrands Agentsも検討したが、ドキュメントの充実度と利用実績の成熟度で優位と判断。TypeScriptで統一でき、チームの既存スタックと整合する点も評価 - **Bedrock AgentCore採用**：評価・観測基盤をLangfuse等で自前構築するより、マネージドサービスに乗る方が運用コストを抑えられると判断 技術：Mastra、Amazon Bedrock AgentCore、AWS Lambda、AWS CDK ## 開発・実装内容D：CI/CDと開発基盤の整備 ### 概要 自発的に提案し、単独で整備。 ### 課題・問題点 新規立ち上げで開発基盤が未整備。コードスタイルの揺れによるレビュー負荷の増大と、デプロイの属人化が発生する見込みだった。 ### 打ち手・使用した技術 GitHub ActionsとAWS CDKでデプロイパイプラインを構築し、ワークフローファイルを自分で作成。フロントエンドはECS、バックエンドはAgentCore Runtimeへデプロイする構成にした。あわせてlinter・Formatter・huskyでコミット時の自動チェックを整備し、レビューの論点を設計に集中させられる状態を作った。 技術：GitHub Actions、AWS CDK、Amazon ECS、Bedrock AgentCore Runtime ## 成果 - 設計した課金プランが事業部に採用（営業が説明しやすい・要件適合と評価） - PoCをリリースし、既存AI機能より自由度が向上したとのフィードバックを獲得

個人事業として植物ブログ運営を主体に園芸関連商品の販売を行い、小規模ビジネスを展開。 SEOを意識した記事作成とSNS広告による集客で年間90万PV規模のメディアに成長させ、読者ニーズに応じて植物ショップ検索アプリ「Botanispot」を開発した。