前回の Week in Review に、2026 年、お客様との AI-Driven Development Lifecycle (AI-DLC) ワークショップに多くの時間を費やしたことを書きました。これらのセッションに共通するテーマは、コストの可視性を高める必要があるということです。チームは AI の導入を急速に進めていますが、実験段階から本番環境に移行するにつれ、財務部門と経営陣は、誰がどのリソースをどの程度のコストで使用しているかを把握する必要があります。だからこそ 2026 年 4 月 13 日週、 Amazon Bedrock による IAM ユーザーとロール別のコスト配分のサポートの開始 を知って、とてもワクワクしました。これにより、IAM プリンシパルにチームやコストセンターなどの属性をタグ付けし、それらのタグを請求およびコスト管理コンソールでアクティブにすることができます。結果のコストデータは AWS Cost Explorer と詳細なコストと使用状況レポートに送信されるため、モデル推論の支出を明確に把握できます。チーム間でエージェントをスケールする場合でも、部門ごとに基盤モデルの使用状況を追跡する場合でも、 Claude Code on Amazon Bedrock のようなツールを実行する場合でも、この新機能は AI 投資の追跡と管理に大きな変革をもたらします。この設定に関する詳細は、 IAM プリンシパルコスト配分ドキュメント に記載されています。 それでは、2026 年 4 月 13 日週の AWS ニュースを見ていきましょう。 ヘッドライン Amazon Bedrock が Claude Mythos Preview の提供を開始 これまでで最も洗練された Anthropic の AI モデルを、Project Glasswing を通じてゲート付きリサーチプレビューとして Amazon Bedrock で利用できるようになりました。Claude Mythos は、サイバーセキュリティに焦点を当てた新しいモデルクラスを提供します。これにより、ソフトウェアの高度なセキュリティ脆弱性を特定し、大規模なコードベースを分析して、サイバーセキュリティ、コーディング、複雑な推論タスク全体で最先端のパフォーマンスを実現できます。セキュリティチームはこれを利用して、脅威が出現する前に重要なソフトウェアの脆弱性を発見して対処することが可能になります。現在、アクセスは許可リストに登録されている組織に限定されており、Anthropic と AWS はインターネットクリティカルな企業やオープンソースのメンテナーを優先しています。 エージェントの検出とガバナンスを一元化するための AWS Agent Registry (現在プレビュー中) AWS は Amazon Bedrock AgentCore を通じて Agent Registry を立ち上げました。AI エージェント、ツール、スキル、MCP サーバー、カスタムリソースを発見して管理するためのプライベートカタログを組織に提供しています。レジストリは、セマンティック検索、キーワード検索、承認ワークフロー、CloudTrail 監査証跡により、チームが既存の機能を重複することなく見つけるのを支援します。AgentCore Console、AWS CLI、SDK からアクセスできます。また、IDE からクエリ可能な MCP サーバーとしてアクセスすることも可能です。 2026 年 4 月 6 日週のリリース 2026 年 4 月 6 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 S3 バケットをファイルシステムとしてアクセス可能にする Amazon S3 Files の発表 – Amazon S3 Files は S3 バケットを、任意の AWS コンピューティングリソースと S3 データを直接接続する共有ファイルシステムに変換します。Amazon EFS テクノロジーに基づいて構築されているため、低レイテンシーのパフォーマンスで完全なファイルシステムセマンティクスを提供し、使用頻度の高いデータをキャッシュして、1 秒あたり数テラバイトの総読み取りスループットを実現します。アプリケーションは、コードを変更したりデータを移行したりすることなく、ファイルシステムと S3 API の両方から同時に S3 データにアクセスできます。 Amazon OpenSearch Service が Managed Prometheus とエージェントトレースのサポートを開始 – Amazon OpenSearch Service は、メトリクス、ログ、トレース、AI エージェントトレースを 1 つのインターフェイスに統合した、統合型オブザーバビリティプラットフォームの提供を開始しました。このアップデートには、Prometheus のネイティブ統合と PromQLクエリの直接サポート、RED メトリクスのモニタリング、LLM 実行の可視化を実現する OpenTelemetry GenAI セマンティック規約サポートが含まれています。運用チームはツールを切り替えることなく、スロートレースをログに関連付け、ダッシュボードに Prometheus メトリクスをオーバーレイすることができます。 Amazon WorkSpaces Advisor が AI を活用したトラブルシューティングで利用可能に – AWS は Amazon WorkSpaces Advisor を立ち上げました。これは、生成 AI を使用して IT 管理者が Amazon WorkSpaces パーソナルデプロイのトラブルシューティングを行うのに役立つ、AI を活用した管理ツールです。WorkSpace の設定を分析し、問題を自動的に検出して、サービスの復旧とパフォーマンスの最適化に役立つ推奨事項を提示します。 Amazon Braket が Rigetti の 108 量子ビット Cepheus QPU のサポートを追加 – AmazonBraket は、プラットフォーム上の最初の 100 量子ビット以上の超伝導量子プロセッサである Rigetti の Cepheus-1-108Q デバイスへのアクセス提供を開始しました。モジュラー設計は、位相誤差に対する耐性が強化された CZ ゲートを備えた、12 個の 9 量子ビットチップレットを備えています。Braket SDK、Qiskit、CUDA-Q、Pennylane などの複数のフレームワークをサポートしており、研究者向けのパルスレベル制御も可能です。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS のニュース こちらは、皆さんが関心を持つと思われる追加の記事とリソースです。 Amazo S3を使用した自動 AWS リージョン可用性チェックの構築 – Amazon S3をコアインフラストラクチャとして使用し、AWS リージョン全体でサービスの可用性を監視する自動化システムの実装に関するストレージブログ記事です。 Amazon Bedrock モデルのライフサイクルの理解 – 機械学習のブログ記事では、Bedrock の基盤モデルが入手可能になったり廃止されたりするまでの段階について説明しています。これは、チームがモデルのアップデートを計画したり、本番環境でのバージョン依存関係を管理したりするのに役立ちます。 AWS Lambda Managed Instances を使用したメモリ集約型アプリの構築 – コンピューティングのブログ記事では、Lambda マネージドインスタンスがプラットフォームを軽量ワークロード以上に拡張し、サーバーレスのメリットを維持しながらメモリを大量に消費するアプリケーションをサポートする方法について説明しています。 OpenClaw を AWS でデプロイ: お客様の AI ワークロードに適したオプションを選択 – Builder Center ガイドでは、OpenClaw の 4 つの AWS デプロイオプションを比較しています。4 つのオプションとは、個々のデベロッパー向けの Amazon Lightsail、より深い AWS 統合を必要とするスタートアップ向けの Amazon EC2、サーバーレスのマルチユーザーシナリオ向けの Amazon Bedrock AgentCore、VM レベルの分離と高度なオーケストレーションを必要とするエンタープライズ向けの Amazon EKS です。 Kiro スタートアップクレジットプログラム復活のお知らせ – Kiro はスタートアップクレジットの取り組みを再開します。対象となる初期段階の企業は、Kiro Pro+ を最大 1 年間無料で利用できるようになります。3 段階のプログラム (Starter、Growth、Scale) は、チームの規模に応じて 2〜30人のユーザーを対象としています。また、ローリングアプリケーションは世界中で受け付けています。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS の次のイベント (4 月 28 日、バーチャル) 午前 9 時 (太平洋標準時) に配信されるこのライブストリームに参加して、エージェンティック AI がビジネスの運営方法をどのように変えているかについて率直に議論しましょう。AWS CEO の Matt Garman、SVP の Colleen Aubrey、OpenAI のリーダーが、新しいエージェント機能、Amazon 社内での経験、新しいエージェンティックソリューションとプラットフォーム機能について語ります。 こちらのリンクから、今後開催される AWS 主導の対面および仮想イベント 、 スタートアップイベント 、 デベロッパー向けのイベント をご覧ください。 2026 年 4 月 13 日週のニュースは以上です。2026 年 4 月 27 日週にお届けする次回の Weekly Roundup もお楽しみに! – Micah 原文は こちら です。

はじめに こんにちは。 my route 開発部でバックエンドチームのリーダーをしている yf です。 my route 開発部では、昨年 7 月に組織体制が変わり、新しい形で開発を進めています。 その変化に備えて、6 月から少しずつ進めてきた取り組みが、 半年たった今、チームの空気や仕事の進め方に確かな変化をもたらしています。 この半年で扱ったテーマは約 40。 一つひとつは小さな改善ですが、積み重ねることで 「開発の役割」や「プロダクトとの向き合い方」が大きく変わってきました。 本記事では、私たちがどんなステップを踏み、 なぜその変化が起きたのかを、時系列[^1]で振り返ります。 この記事はこんな人向け 開発が「実装担当」に閉じてしまっていることに違和感がある方 仕様やスケジュールが決まった状態で渡ってきて、Why を理解しづらいと感じている方 プロダクト思考を持ちたいが、日々の開発で手応えを持てていない方 組織改善をしたいが、何から手を付ければいいかわからないリーダー・サブリーダー 「誰かを責める」のではなく、「構造を変える」アプローチを探している方 私たちが半年間かけて試行錯誤してきた取り組みが、 同じような悩みを持つチームのヒントになれば幸いです。 当時の状況と、なぜそうなっていたのか 取り組みを始める前、開発部には次のような状況がありました。 要件や仕様が、開発フェーズの後半で共有されることが多かった 開発期間が限られ、品質改善や振り返りに十分な時間を取れなかった スケジュールや設計の背景（Why）が、開発側に伝わりにくかった 結果として、実装を中心に進めざるを得ない進め方になっていた これは、特定の誰かの判断ミスというよりも、 "役割分担とプロセスの構造がそうさせていた状態" だったと振り返っています。 プロデューサーはプロダクトを良くしようとする責任感から、 設計やスケジュールをできるだけ具体化しようとしていました。 一方で、その分、開発に共有されるタイミングが遅くなり、 開発側には「How（どう作るか）」を中心とした情報が渡る構造になっていました。 その結果、 "なぜこの機能を作るのか（Why）を理解した上で改善提案を行う余地が少なくなり、" 開発が実装中心の役割に閉じてしまっていたのです。 この状況を変えるために、 私たちは "開発組織から、プロダクト組織へ" という 大きな方向転換に踏み出しました。 半年間の全体像 目的定義 → プロセス設計 → 運用定着 → 連携強化 → 品質と戦略 → 組織文化として定着 まず、私たちが向き合っていた「仕事の流れ」の変化を、Before / After で示します。 ■ 6 月 —— “目的と役割の再定義” 組織変革の起点 まず取り組んだのは、 “私たちはどこに向かうのか“ “チームリーダーは何を担うのか“ という意図合わせでした。 開発に関わる関係チームのリーダー全員（PDM・QA・バックエンド・モバイル）で、理想像の輪郭を描き直しました。 主なテーマ 独立プロダクト組織としての目的定義 リーダー役割の再整理 過渡期の案件対応 仕事の流れ図（AS-IS）の棚卸し チーム役割の再設計 会議体・Slack などコミュニケーション設計 この段階で、別の部である Engineering Office にも参画してもらいました。 開発部の中だけでは前提になっていた考えや、 見落としていたプロセスの歪みを、 第三者の視点から言語化・整理してもらえたことは、 その後の設計を進めるうえで大きな支えになりました。 6 月 あらためてひとこと - “まず揃えないと、何も始まらない” この時点では、具体的な施策よりも "前提が揃っていないまま進むことの危険性" を強く感じていました。 早く手を動かしたい気持ちを抑え、 あえて立ち止まって目的と役割を言語化したのは、 後戻りしないための投資だったと思っています。 ■ 7 月 —— “仕組みの再設計に着手” 新しい仕事の流れの原型ができた 6 月に定義した理想を、実際のプロセスに落とし込んだ月です。 スプリント導入（計画・中間・レビュー・レトロスペクティブ） チーム間連携会の常設 Jira運用ルールの再構築 ストーリーチケット作成基準の統一 Git ブランチ戦略の見直し リリースフロー整備 成果物レビューの仕組み化 問い合わせ・障害の暫定ルール化 “会議体・プロセスがゼロから設計されていくスピード感“ があり、 部全体の透明性が大きく向上しました。 7 月 あらためてひとこと - “理想を、現実の流れに落とす” 6月に描いた理想は、そのままでは机上の空論でした。 リーダとして意識したのは「誰がやっても迷わない仕組み」になっているか。 プロセスを設計することは、メンバーの思考コストを下げることだと実感した月でした。 ■ 8 月 —— “新プロセスの定着と運用強化” Jiraと仕事の流れが形になってきた 新プロセスの試験運用 新規案件でのトライアル導入 UI 定例、Slack などコミュニケーション基準化 問い合わせ・ツール改修フローの改善 ロードマップレビューの開始 プロセスが回り始めたことで、 “現場から自然と改善提案が出る状態“ が生まれはじめました。 8 月 あらためてひとこと - “仕組みは、使われて初めて意味を持つ” 新しいプロセスは、導入しただけでは根付きません。 この月は「守らせる」よりも "使ってみてどうだったかを聞く" ことに注力しました。 現場から改善案が出始めたとき、組織が一段階変わった感覚がありました。 ■ 9 月 —— “プロダクト思考と横断連携の強化” チーム間連携が日常化 ストーリー分割ワーク 役割を越えたアイデア提案の促進 リソースアサイン管理の透明化 AI 活用案件の相談 リリース承認ルートの改善 リーダー陣の視点が “「自分の領域」から「プロダクト全体」“へ 大きくシフトした月でした。 9 月あらためてひとこと - “役割を越えることを、許可する” プロダクト全体の話をするとき、役割を理由に遠慮が生まれる場面がありました。 リーダとして意識したのは、「それはあなたの領域じゃない」という空気を消すこと。 横断連携は、仕組みだけでなく心理的安全性があって初めて機能すると学びました。 ■ 10 月 —— “運用・リスク管理の高度化” 問い合わせ・障害・運用プロセスが進化 問い合わせ・障害フローの再整備 運用体制の検討 目的起点の進め方ワーク アジャイルトレーニング準備 他部門との連携強化 “リスクを未然に防ぐ動き” が自然と発生する組織へと変化しました。 10 月 あらためてひとこと - “問題が起きる前提で、組織をつくる” 問い合わせや障害は、ゼロにはできません。 だからこそ "起きたときにどう振る舞えるか" を考えるフェーズに入りました。 個人の頑張りに依存せず、組織として耐性を持つことを意識し始めた月です。 ■ 11 月 —— “品質・戦略・成長のフェーズへ” 技術とビジネスがつながり始めた スプリントへの QA 導入方針の確定 セキュリティ監査オーナーの役割整理 ポストモーテム文化の定着 UI/UX 改善の進め方刷新 フィールドワーク成果の共有 “案件をこなす組織” から “プロダクトを成長させる組織” へと進化。 11 月 あらためてひとこと - “技術は、ビジネスとつながってこそ価値になる” 品質やUXの議論が増えたことで、技術がプロダクト価値にどう貢献するかを 言葉にする機会が増えました。 リーダとしては、技術的な正しさと、事業としての判断をつなぐ役割を より強く意識するようになりました。 ■ 12 月 —— “半年の蓄積が組織文化に変わり始めた” 目的起点で動ける組織に UI/UX 改善の長期方針の確立 QA 導入プロセスの実運用 ロードマップレビューの定着 工程ごとのリードタイム測定開始 6 月に掲げた “自律したプロダクト組織になる” という目標が、実際の動きとして現れてきました。 半年で生まれた “4 つの変化” ① 情報の透明性 プロダクト全体の状態が誰にでも見えるようになった。 ② 早期リスク検知 問い合わせ・障害・運用課題が芽のうちに見つかるようになった。 ③ 横断連携の活性化 PDM・QA・バックエンド・モバイルが互いに提案しあう文化が育った。 ④ 再現性のあるプロセス “誰がやっても前に進む” 仕組みが整った。 12 月 あらためてひとこと - “文化は、後から気づくもの” 何か劇的なイベントがあったわけではありません。 ただ振り返ってみると、目的から考え、自然と連携し、改善を回す "当たり前の動き" が定着していました。 組織文化は、作ろうとして作るものではなく、 積み重ねの結果として生まれるのだと感じています。 もともとの課題は、どこまで変わったか 取り組みを始めた当初、私たちは 「開発が実装中心の役割に閉じてしまっている」という課題を抱えていました。 半年間の取り組みによって、 Why を共有したうえで議論できる場が増え スケジュールや設計の背景を前提に、改善提案が出るようになり 開発が「決められたものを作る」だけの立場ではなくなってきた といった変化が確かに生まれました。 一方で、 すべてが理想通りに解消されたわけではありません。 プロダクト全体の意思決定への関与や、 戦略レイヤーでの議論は、まだ発展途上です。 それでも、 「なぜやるのかを考えながら作る」ことが当たり前になり始めた という点で、 当初感じていた課題は、確実に別のフェーズへ進んだと感じています。 次の半年へ これからは、 “プロダクトをつくる組織“から“プロダクトを成長させる組織“ へさらに進化していきます。 グロースハック文化の定着 権限移譲と育成の体系化 プロダクト戦略の内製化 インシデント学習ループ強化 開発体制の継続アップデート 内部だけで議論すると主観に偏り、問題の本質を見誤ることがあります。 そのため今回は、部を横断して取り組めたことも私たちにとって大きな追い風となりました。 半年で大きく変化した組織が、次の半年でどこまで成長できるのか。 私自身、とても楽しみにしています。 さいごに my route 開発部では、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！ [^1]: 半年で扱った 40 のテーマを月別の代表例として抜粋しています。

メルペイ インターンでの挑戦と学び：EGP Cardsと向き合った3ヶ月間 こんにちは。メルペイのGrowth Platformでフロントエンド・エンジニアとしてインターンをしている @Yusaku （宮田 優作）です。 この記事は、 Merpay & Mercoin Advent Calendar 2025 の25日目の記事です。 私は2025年10月からインターンを開始し、今月で3ヶ月目になりました（図1）。 この記事では、インターン期間中に取り組んだタスクと得た学びについて紹介します。 図１：オフィスで撮影した私の写真 チームについて 私が所属する Growth Platform Frontend チームは、Engagement Platform（通称EGP）という社内向けマーケティングツールを開発しています。 このツールを使うことで、マーケターや プロジェクトマネージャーは、ポイントやクーポンなどのインセンティブ配布、ランディングページ（LP）の作成・公開、キャンペーン作成といった CRM業務をコーディング不要で簡単に行うことができます（図2）。 図2：EGPのノーコードエディタ（EGP Content） 今回のインターンではEGP Cardsという機能の向上に取り組みました。EGP Cardsは、Web・iOS・Androidのクロスプラットフォームで利用できるカード型のコンポーネントを作成・公開する機能です。 EGP Cardsは、いわゆるWebページのエディタ機能（EGP Pages）とは異なり、サーバがUIの構造を返却するというServer Driven UIアーキテクチャを採用しています。エディタ上で作成されたコンポーネントのコンテンツはJSONファイルとして保存され、各プラットフォームで共通のUIとして描画されます（図3）。 Server Driven UIとEGP Cardsのアーキテクチャについては、同じくGrowth Platformチームの@togamiさん、@Stefanさんの記事をそれぞれご覧ください。 WYSIWYGウェブページビルダーを支える技術とServer Driven UIへの拡張 Supercharging User Engagement: How Mercari is Using Server-Driven UI to Reduce Time-to-Market 図3：EGP Cardsの編集画面 タスク1 – Dry Run for EGP Cards タスク概要：Dry Runとは？ Dry Runとは、変数を設定し、そこにデータを挿入することで、状態をエミュレートできる機能のことです。これにより、API呼び出しを記述したり実機で動作確認を行ったりする前に、コンテンツの挙動を確認することができます。 このタスクでは、EGP CardsでDry Run機能を利用できるようにする実装を行いました（図4）。 図4：今回実装した、EGP CardsのDry Run機能 動作の仕組み Dry Run機能は、以下の流れで動作します。 利用者がDry Runを有効化し、フィールドにモックデータを入力する エディタが構造ツリーを再帰的に走査し、動的にJavaScriptのコードを評価して変数を値に置換する 置換された値がキャンバス上に表示される 実装の流れ 以下の流れで実装を進めました。 EGP Pagesに既に実装されていたDry Run機能について、コードリーディングやロギングを行い、実装ロジックを理解する EGP Cards特有の仕様を理解した上で、同様に利用できるDry Run機能を実装する コーディングの際には、EGP PagesとEGP Cardsで共通利用できそうな処理を探し、適度にファイルを切り出すことで、可読性・保守性を意識した実装を心がけました。 タスク2 – Content Agent Improvement for EGP Card 背景：Content Agentの課題 EGPのノーコードエディタ（EGP Content）は、CardsのほかにもPagesやE-mailsなど、複数の種類のコンテンツを扱うことができます。 また、EGP ContentにはAIエージェント（通称 Content Agent）が導入されており、対話を通じてコンテンツの要約や書き換えを行うことができます（図5）。 一方で、当時のContent Agentは、コンテンツ種別ごとのエディタ仕様を十分に理解していないという課題がありました。その結果、UIが崩れたコンテンツを生成してしまい、利用者の期待通りのアウトプットを提供できない可能性がありました。 図5：Content Agentの会話処理パイプライン 実装の流れ この課題を解決するため、以下の流れで実装を進めました。 EGP Cardsの仕様やデータ構造を記述したプロンプトを作成する 作成したプロンプトを、Content AgentのAgent Layerで条件付きで注入する EGP Cardsには、メディアクエリに対応していないことや、すべての要素がFlexで構成されていることなど、いくつかの制約があります。これらの制約や期待される出力をプロンプトに明示することで、Content AgentがCardsに適したコンテンツを生成できるようにしました（図6）。 図6：EGP CardsでContent Agentを利用する様子 学んだこと チーム開発におけるアウトプットの出し方を学んだこと Dry Run 機能の実装を通じて、チーム開発におけるアウトプットの出し方について多くの学びがありました。実装の正しさや機能の完成度だけでなく、Pull Request（PR）の切り方やレビューの受け方が、チーム全体の開発効率や生産性に大きく影響することを実感しました。 具体的には、バグ修正やリファクタリングであっても、PRのサイズが大きくなりすぎる場合やタスクのスコープ外に及ぶ場合には、別のPRとして切り出すことでレビューコストを抑えられることを学びました。また、コードやPRコメントには、なぜその実装にしたのか、どのような選択肢があり、何をしない判断をしたのかといった実装意図を明示することが重要です。これにより、レビュワーとの認識齟齬を防ぎ、建設的なレビューにつながると感じました。 レビューを受けた際にも、指摘内容をすぐに修正として反映するのではなく、まずはレビュワーの意図を正しく理解することが重要です。場合によっては背景や前提条件をすり合わせた上で議論することで、より良い設計や実装にたどり着けることを学びました。これらの経験を通じて、個人としてコードを書く力だけでなく、チームで価値を届けるためのコミュニケーションや姿勢の重要性を強く認識しました。 メルカリカルチャーを実体験として理解できたこと メルカリでは、情報の透明性やフラットな意思疎通によって、個人に大きな裁量が与えられていると言われることが多いです。実際にインターンを通じて、その点を強く実感しました。一方で、個人的に特に印象に残ったのは、英語を前提としたグローバルな開発環境です。 これまで参加してきたインターンはすべて日本語環境だったため、ドキュメントやコミュニケーション、議論の場がすべて英語になる経験は非常に新鮮でした。グローバルなチームである以上、英語でのスムーズな意思疎通が求められることは理解していましたが、実際に業務の中でそれを実践し、議論や開発を進められたことに大きなやりがいを感じました。 実際の業務では、英語で書かれたREADMEや仕様書を読み込んだ上でPull Requestを作成し、設計意図や懸念点を英語で説明・議論しました。認識の齟齬を防ぐため、必要に応じて日本語での補足も行いながら、主体的にコミュニケーションを取ることを意識しました。この経験を通じて、メルカリのカルチャーは単なるスローガンではなく、日々の業務に根付いたものだと感じました。 技術的挑戦を通じて、学びの広がりを再認識できたこと これまで私は、フロントエンドを主な技術領域として、インターンや個人開発に取り組んできました。そのため、フロントエンド領域における学びは、徐々に頭打ちになりつつあるのではないかと感じていました。 しかし、EGPというツールに触れたことで、その考えは大きく変わりました。EGPは非常にインタラクティブでリッチなUIを持つだけでなく、その裏側では、ノーコードによるコンテンツの作成・配信の仕組みや、安全かつ効率的にAI Agentとやりとりを行うための設計など、複雑で奥深いロジックが支えられていることを知りました。 タスクでは、ある程度抽象度のある状態で要件を受け取り、自分で具体的な実装タスクへ分解した上で設計・実装を進めました。また、EGPの使い方をキャッチアップしている最中に、イメージのプレビュー機能があることで利用者体験が向上するのではないかといった改善提案も行いました。 さらに、Content Agentの改善では、今回のCards向け実装に閉じることなく、将来的にPagesやE-mailsなど他のContent typeにも展開しやすいよう、Typeごとにプロンプトを切り出す設計とし、可読性や拡張性を意識しました。エンジニアがプロダクトの将来を見据えて設計・実装することが、利用者体験の向上や業務効率化につながり、結果として事業価値に直結する点は、メルカリならではの魅力だと感じています。 おわりに 今回のインターンでは、EGP Cardsという機能の向上に取り組みました。インターンを通じて、技術的なスキルだけでなく、プロダクトの価値やチームとの関わり方を含めてエンジニアリングに向き合う姿勢を学ぶことができました。 実務を通して得たこれらの学びを、今後の開発や自身の成長につなげていきたいと考えています。最後までお読みいただきありがとうございました。