はじめに お久しぶりです！3年目社員の藤岡、山本です。 2026年4月15日〜17日に東京ビッグサイトで開催中の「 AI・人工知能EXPO【春】 」に参加してきました。会場の雰囲気と印象に残ったセッションの学びをまとめます。 生成AIに加えて、AIエージェントやフィジカルAIまで幅広いテーマが扱われており、単に最新技術を眺めるだけでなく、「AIをどう業務に組み込むか」を考えるうえでも刺激の多いイベントでした。 前回は、2025年夏に開催された AI博覧会 Summer 2025 に参加し、その内容を社内ブログ記事としてまとめています。ぜひ、そちらも参照ください！ 前回の記事：AI博覧会 Summer 2025 に参加してきました！ AI・人工知能EXPO 会場入口の様子1 AI・人工知能EXPO 会場入口の様子2 AI・人工知能EXPOとは 開催日： 2026年4月15日（水）〜 17日（金）10:00〜17:00 会場： 東京ビッグサイト（西展示棟） 関連URL： AI・人工知能EXPO【春】公式サイト AI・人工知能EXPO【春】 は、NexTech Week 2026内で開催されている日本最大級のAI技術専門展です。今回のNexTech Week 2026では、全46講演、300社が出展しており、生成AI、AIエージェント、RAG、AIインフラ、ロボットなど、業務活用に直結する技術・サービスが幅広く集まっていました。 前回のイベントとの違い 前回参加した AI博覧会 Summer 2025 が生成AIの活用事例や社会実装によりフォーカスしていたのに対して、今回は AI エージェント、データ基盤、ロボティクスまで含む、より広い技術領域を扱っていたのが印象的でした。会場も東京ビッグサイトで3日間開催と規模が大きく、関連展示までまとめて見られる構成でした。 なぜ参加したの？ 現在、山本と藤岡は社内の AI CoE（Center of Excellence） というバーチャルチームに所属し、AIの社内活用推進や、実際の開発への導入支援を行っています。そのため、AI関連の最新情報をキャッチアップしたいという思いから、今回のイベントに参加し、社内に持ち帰れる学びやヒントを得ることを目的にしました。 ニフティで社外イベントに参加するには 今回も前回のイベント参加時と同じように ・藤岡・山本 「前回より大きい日本最大級のAIイベントがあるらしいんですが、行ってもいいですか？」 ・上司 「いいね。ぜひ知見持って帰ってきてください！」 社外イベントへの参加は、まずはこんな感じで気軽に相談すればOKが出ることが多いです。参加して得た知見を社内に持ち帰って共有する文化があるので、「行って終わり」ではなく、学びをチームや会社の成長につなげやすいのもニフティらしさだと感じています。 現地の様子 会場は東京ビッグサイトで、セミナーと展示を行き来しながら回れる構成でした。AIエージェントや生成AIに関するセッションの注目度は高く、業務効率化だけでなく、組織変革や新しい働き方までテーマが広がっているのが印象的でした。 まずはセミナーを中心に回りながら、気になるブースや関連領域の展示も見て回りました。 会場内の展示エリア入口の様子 セッション 特に印象に残ったのは、以下の2つのセッションです。 アプローチはそれぞれ違うのですが、どちらも「これまでAIとどう付き合ってきたか」「これからどう共存していくか」を改めて考えるきっかけになる内容でした。 1. フィジカルAIがもたらす産業変革 NVIDIAの荒井 謙さんは、フィジカルAIを「現実世界と相互作用し、自律的に判断・行動するAI」として整理し、ロボットや自動運転に限らず幅広い領域に広がる概念だと紹介していました。 実現には、モデル学習、実世界でのデプロイ、デジタルツイン／シミュレーションの3つの計算環境が重要で、現実データ収集のコストや危険を補うためにシミュレーションや世界基盤モデルの活用が鍵になります。 現在はまだ立ち上がり期ですが、生成AIと同様に今後急速に発展し得る領域として、監視・点検・製造・物流などへの波及も含め継続してウォッチしたいと感じました。 セッションの様子 2. なぜ企業はClaudeを選ぶのか——Anthropicの安全性という価値 Anthropic Japanの岡田 大志さんによる講演では、Claudeを「便利な生成AI」としてではなく、 企業が重要な仕事を任せられるAI として成立させるために、 安全性をどう設計し、どう検証し、運用に組み込むか が語られていました。 特に印象に残ったのは、Constitutional AI（憲法AI）やRed Teamなどで判断基準やテストを体系化している点に加えて、 安全性を優先できるように組織の仕組み自体にもガードレールを入れている 点です。たとえば、公益性を組織の目的に組み込むことや、長期的な利益を担保するための独立した仕組み（株主の意向が強く働きやすい場面でも、安全性へのコミットが揺らぎにくい構造）が紹介されていました。 AI活用バーチャルチームメンバーとして、社内展開を考えるうえでも、ツール単体の機能比較ではなく、アクセス統制・監査・データ保護・人の確認といった ガバナンス込みで設計する重要性 を改めて感じました。 セッションの様子 企業展示ブース 展示エリアには多くの企業が出展しており、生成AI、AIエージェント、データ基盤、ロボティクスなど幅広いテーマのブースが並んでいました。実際に見て回ると、単なる技術デモではなく、 教育・運用・現場導入まで含めてAIをどう業務に組み込むか を具体化した展示が多かったのが印象的でした。 展示ブース入口の様子 1. 株式会社KIZASHI 株式会社KIZASHIのブースでは、生成AIパスポート風の問題に答えながら「生成AIリテラシー診断」を体験でき、いまの理解度を手触り感をもって把握できる展示になっていました。生成AI活用普及協会（GUGA）に認定されている取り組みとのことで、学習コンテンツと診断をセットで提供している点も印象的でした。 ブースの様子 体験後にはノベルティで「生成AIパスポート」の書籍もいただけました。 そして何より、ブース内の診断を実際に受けてみたところ……なんとランキング5位にランクイン。会場でその場のノリのまま挑戦できる感じも含めて、かなり楽しかったです。 5位に入賞…！（名前は藤岡のニックネームです） 2. FlashIntel Japan株式会社 FlashIntel Japanのブースでは、CS（カスタマーサポート）業務を主戦場にした音声AIエージェントの展示が行われていました。音声モデル Chroma と FlashAI Voice Agents を軸に、営業コールや問い合わせ対応など「電話」を起点にした業務を、ナレッジベース化〜FAQ生成〜応対への反映まで一気通貫で支える構成がわかりやすかったです。 ブースの様子 特に印象に残ったのは、デモで体験できた“人に近い自然な音声”と低遅延な受け答えでした。 当社でもCSを内製で運営していることもあり、「一部でも試してみると面白そうだな」と素直に感じました。 FlashIntel Japan のデモ画面 他のEXPOも隣接して同時開催 NexTech Week 2026【春】は、AI・人工知能EXPOを含む 合計5つの展示会 で構成されています。1回の来場登録でまとめて見られるので、AI単体というより「周辺の技術・人材・実装」まで一気に俯瞰できるのが良さでした。 ブロックチェーン EXPO ：Web3、NFT、DAOなど、ブロックチェーン技術のビジネス活用を扱う展示会。 量子コンピューティング EXPO ：量子計算の研究から産業応用まで。まだ先の技術に見えつつも「触れておく価値」がある領域。 AI時代の人材・組織改革 EXPO ：旧「デジタル人材育成支援EXPO」。リスキリングや人材開発、組織づくりなど、導入を支える“人と仕組み”側の展示。 ヒューマノイドロボット EXPO ：人と共に働く次世代ロボットの実装・活用にフォーカスした新設EXPO。 ヒューマノイドロボット EXPOの様子1 ヒューマノイドロボット EXPOの様子2 今回のイベント参加で学んだこと 今回のイベントで特に印象的だったのは、フィジカルAIが想像以上に実用段階へ進んでいたことです。これまではXなどで見かける「まだ使えないロボット」の印象を持っていましたが、実際には着実に技術が前進しており、世界基盤モデルのような考え方も含めて、今後さらに広がっていきそうだと感じました。また、AI活用は特定の業界に閉じた話ではなく、さまざまな分野へ発展しており、業種が違っていても参考にできるアプローチが多くありました。現場ごとの多様なニーズに応える製品も多く、AIがより具体的な業務課題の解決に近づいていることを実感しました。 反省点 ブースがかなり多いので、あらかじめ自分たちが興味のある分野を絞っておくことで、当日落ち着いて回ることができると感じた フィジカルAIが世間的に注目されているのは知っていたが、事前知識不足により内容が難しく感じた こんなところにあのキャラクターが,,,! まとめ AI・人工知能EXPO【春】 は、最新技術を眺める場であると同時に、 これからの仕事の進め方をどう変えていくか を考える場でもありました。今回の参加を通じて強く感じたのは、AI活用の価値は新しい技術そのものよりも、それを現場の業務や組織の流れの中でどう定着させるかにあるということです。セッションや展示で得た気づきを、単なるイベント参加の思い出で終わらせず、今後の業務や社内でのAI活用推進にどうつなげていくかが大切だと改めて感じました。 ニフティのAI活用について ニフティでは、所属部署や職種を越えて有志が集まるAI活用のバーチャルチームが活動しています。日々の開発や業務改善の延長線上でAIを活用し、技術トレンドを「見て終わり」にせず、実際の業務にどう生かすかまで試せる土壌があります。だからこそ、AIに興味がある方、業務の中で新しい活用を試してみたい方、技術を使って働き方を変えていきたい方は、ぜひ一緒に挑戦しましょう！実際に手を動かしながら社内のAI活用を前に進めていける仲間を募集しています。 AI活用バーチャルチームについては、こちらのインタビュー記事でも紹介されています。 AI活用バーチャル チーム のインタビュー記事  

本記事は、2025 年 9 月 25 日に公開された Improve Solana node performance and reduce costs on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 Solana Agave v2.0.14 は 2024 年 10 月 18 日にリリースされました。 それ以降、Solana ノードのオペレーターから、mainnet-beta の最新スロットとの同期を維持するのに苦労することがあるという報告がありました。 Solana の StackExchange で「catch up」を検索すると、この課題に関する多数の投稿が見つかります。 以前の投稿 では、AWS で Solana ノードを実行する方法を説明しました。 この投稿では、より高速な運用と初期同期のためにノードを設定する方法を解説します。 さらに、 Amazon Elastic Compute Cloud (Amazon EC2) で Solana ノードのデータ転送のコスト効率を高めるための実験的なトラフィック最適化手法を共有します。 Solana Agave v2.x における変更点 Solana Agave v2.x における最も重要な変更の 1 つは、新しい中央スケジューラです。 これは v1.18.x にも存在していましたが、デフォルトでは無効になっていました。 v2.x のアップデートにより、中央スケジューラがデフォルトで有効になりました。 Solana Agave クライアントのコアコンポーネントとして、中央スケジューラはトランザクション処理アーキテクチャを大幅に変更します。 これは、以前の 4 スレッドによる処理モデルに代わるシングルスレッドによる調整メカニズムである Scheduling Thread を導入します。 この変更について詳しくは、 Introducing the Central Scheduler: An Optional Feature of Agave v1.18 を参照してください。 この変更は、推奨される最小 CPU クロック速度に大きな影響を与え、トランザクション処理の最適なパフォーマンスのために、要件が 2.8 GHz から 3.2 GHz に増加しました。 これに基づき、 以前のブログ記事 で Solana ノードを実行するための推奨 AWS インスタンスタイプを更新し、 R7a および I7ie EC2 インスタンスファミリーに切り替えました。 これらのインスタンスファミリーは、さまざまな構成で Solana ノードを実行するために必要な 384 GiB から 1.5 TiB 超の RAM も提供します。 Agave v2.2.15 では、処理ロジックの「ホットパス（頻繁に実行される処理経路）」からブロックストレージ操作を削除することに焦点を当てた、その他の重要なパフォーマンス最適化が導入されました。 これにより、ブロックストレージデバイスに必要な 1 秒あたりの入出力操作数 (IOPS) とレイテンシーが削減され、クラウド上で Agave クライアントを実行するコストがさらに削減されました。 アジア太平洋 AWS リージョンにおける Solana の同期における課題の克服 Solana Agave ノードが起動時に事前ダウンロードされたスナップショットを持っていない場合、クライアントは信頼できるバリデーターノードからそのスナップショットをダウンロードします。 これらのノードは --known-validator フラグで設定され、 Anza RPC ノード起動コマンドの例 に示されています。 しかし、これらの信頼できるバリデーターは、北米またはヨーロッパの AWS リージョンに配置されていることが多く、東京、香港、ソウル、シンガポールなどのアジア太平洋リージョンで実行されているクライアントにとって問題となります。 これらの場所でのスナップショットのダウンロード速度は、通常、北米またはヨーロッパリージョンのクライアントと比較して遅くなります。 スナップショットをダウンロードした後、Agave はスナップショットのスロットが最新より 2,500 スロット以上遅れているかどうかをチェックします。 この差が 2,500 より大きい場合、クライアントはスナップショットを再ダウンロードし、同期プロセスがさらに遅延します。 この問題は GitHub issue #24486 に記録されています。 デフォルトでは、 maximum_local_snapshot_age パラメータは 2,500 に設定されています 。 スナップショットの再ダウンロードを避けるためにこの値を増やすことはできますが、この方法は推奨しません。 Solana は 400 ミリ秒ごとに新しいスロットを生成する (1 分あたり約 150 スロット) ため、この値を高く設定しすぎると、ノードが最新のスロットに追いつかなくなる可能性があります。 アジアパシフィックリージョンで Solana ノードを実行する際のスナップショットダウンロードパフォーマンスを向上させるには、以下を推奨します。 信頼できるノードを特定する: validator.app を使用して、アジア太平洋地域のあなたの場所に近い 信頼できるノードの識別子 を見つけます。 これらの識別子を agave-validator 起動コマンドの --known-validator フラグのパラメータとして設定します。 警告 マークが付いているバリデーターノードの使用は避けてください。 スナップショットソースを制限する: --only-known-rpc フラグを使用して、信頼できるノードからのみスナップショットをダウンロードするようにクライアントを設定します。 最小ダウンロード速度を設定する: --minimal-snapshot-download-speed フラグを使用して、必要な最小スナップショットダウンロード速度を定義し、低速なソースからのダウンロードを防ぎます。テストでは、104,857,600 (100 MiBps) を使用しました。 これらの最適化を実装することで、初期同期を高速化し、アジア太平洋リージョンにおける Solana ノードのデプロイをより高速で信頼性の高いものにすることができます。 Agave RPC ノードのデータ転送コストの最適化 Solana Agave クライアントは、 Turbine と呼ばれるデータ伝播プロトコル により、大量のアウトバウンドデータトラフィックを生成します。 近年、月間トラフィック量は増加しており、 RPC のみとして構成されたノード であっても、現在は 100 TiB から 200 TiB 以上の範囲になっています。 これらのコストをより効果的に管理するために、Solana ノードの同期を維持するために最小限必要なアウトバウンドデータスループットを決定するための一連の実験を実施しました。 まず、ノードの「Slots Behind」メトリクスを 1 分ごとにチェックし、初期同期が完了した後に実行するスクリプトを作成しました。 1 分間隔は、Solana ノードが正常に同期しているか、遅れ始めているかを確実に検出できるのに通常十分です。 「Slots Behind」メトリクスがゼロに達し、ノードが完全に同期されたことを示すと、別のスクリプトがユーザー定義の帯域幅制限を MiBps 単位で適用します。 「Slots Behind」メトリクスが 10 を超えると、ノードが追いつくまで制限が一時的に解除されます。 運用効率を維持するために、システムはこれらの制限から内部ネットワークトラフィックを除外します。 標準的な内部 IP 範囲 (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、169.254.0.0/16) 内のトラフィックは制限の対象外とし、内部 IP を使用する AWS アプリケーションが正常に機能することを確保します。 この機能は RPC ノードに対して非常に効果的ですが、コンセンサスノードには実装すべきではありません。 コンセンサスノードでアウトバウンドトラフィックを制限すると、パフォーマンスが低下するため、最適なネットワーク参加のためには推奨されません。 このトラフィック最適化手法をテストするために、 eu-central-1 リージョンで 5 台の i7ie.12xlarge EC2 インスタンスを使用して 5 日間の比較テストを実施しました。 4 つのノードにトラフィックシェーピングスクリプトを設定し、1 つのコントロールノードには制限を設けず、「Current Slots」と「Slots Behind」のメトリクスを収集して、ノードの同期速度と安定性を比較しました。 テストの結果、ノードは 20 MiBps という低いアウトバウンドトラフィック帯域幅 (月間約 6.5 TiB) で同期を維持でき、最適な価格対パフォーマンス比は 40-50 MiBps で達成され、推定データ転送コストを 85% 以上削減できることが示されました。 テスト期間全体を通じて、5 つのノードすべてが同期を維持し、アウトバウンド帯域幅を削減してもノードの同期状態に影響しないことが確認されました。 驚くべきことに、Agave v2.2.16 でアウトバウンドトラフィック帯域幅を 20-50 MiBps に制限したノードは、制限のないコントロールノードと比較して最大 5%より一貫して同期を維持しました。 Agave RPC ノードのトラフィックシェーピングの設定 これらの結果に基づき、AWS Blockchain Node Runners の Solana ブループリントに動的トラフィックシェーピングを導入しました ( Optimizing Data Transfer Costs を参照)。 その実装の主要な部分は以下のとおりです。 net-rules-start.sh はトラフィックシェーピングを有効にします。 #!/bin/bash # Specify max value for outbound data traffic in Mbps. LIMIT_OUT_TRAFFIC_MBPS=20 # Step 1: Create nftables rules to mark packets going to public IPs # Create table if it doesn't exist if ! nft list table inet mangle >/dev/null 2>&1 ; then nft add table inet mangle fi # Create chain if it doesn't exist if ! nft list chain inet mangle output >/dev/null 2>&1 ; then nft add chain inet mangle output { type route hook output priority mangle\ ; } fi # Check if specific private IP return rule exists if ! nft list chain inet mangle output | grep -q "10\.0\.0\.0/8.*172\.16\.0\.0/12.*192\.168\.0\.0/16.*169\.254\.0\.0/16.*return"; then nft add rule inet mangle output ip daddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } return fi # Check if mark rule with value 1 exists if ! nft list chain inet mangle output | grep -q "meta mark set 0x00000001"; then nft add rule inet mangle output meta mark set 1 fi # Step 2: Set up tc with filter for marked packets INTERFACE=$(ip -br addr show | grep -v '^lo' | awk '{print $1}' | head -n1) # Check if root qdisc already exists if ! tc qdisc show dev $INTERFACE | grep -q "qdisc prio 1:"; then tc qdisc add dev $INTERFACE root handle 1: prio fi # Step 3: Add the tbf filter for marked packets # Check if filter already exists if ! tc filter show dev $INTERFACE | grep -q "handle 0x1 fw"; then tc filter add dev $INTERFACE parent 1: protocol ip handle 1 fw flowid 1:1 fi # Check if tbf qdisc already exists on class 1:1 if ! tc qdisc show dev $INTERFACE | grep -q "parent 1:1"; then tc qdisc add dev $INTERFACE parent 1:1 tbf rate "${LIMIT_OUT_TRAFFIC_MBPS}mbit" burst 20kb latency 50ms fi net-rules-stop.sh はすべてのトラフィックシェーピングを削除します: #!/bin/bashINTERFACE=$(ip -br addr show | grep -v '^lo' | awk '{print $1}' | head -n1)# Remove tc rulestc qdisc del dev $INTERFACE root 2>/dev/null# Remove nftables rules# Delete the entire mangle table (removes all chains and rules)nft delete table inet mangle 2>/dev/nullexit 0 ; 簡単にするために、自動化スクリプト net-rules-start.sh と net-rules-stop.sh は systemd サービス net-rules.service を通じて制御されます。 [Unit] Description="ipables and Traffic Control Rules" After=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/opt/instance/network/net-rules-start.sh ExecStop=/opt/instance/network/net-rules-stop.sh [Install] WantedBy=multi-user.target net-syncchecker.sh は、内部からアクセスする API を使用してノードの同期ステータスをチェックし、net-rules サービスでトラフィックシェーピングのオンとオフを切り替えます。これは 1 分ごとに呼び出す必要があるため、 systemd timer や cron のような他のサービス を使用してスケジュールできます。 #!/bin/bash INIT_COMPLETED_FILE=/data/data/init-completed MAX_SOLANA_SLOTS_BEHIND=10 # Check if jq is available if ! command -v jq &> /dev/null ; then echo "Error: jq is required but not installed" exit 1 fi TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") if [ -z "$TOKEN" ] ; then echo "Error: Failed to get EC2 metadata token" exit 1 fi EC2_INTERNAL_IP=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/local-ipv4) # Start checking the sync node status only after the node has finished the initial sync if [ -f "$INIT_COMPLETED_FILE" ] ; then SOLANA_SLOTS_BEHIND_DATA=$(curl -s -X POST -H "Content-Type: application/json" -d ' {"jsonrpc":"2.0","id":1, "method":"getHealth"}' http://$EC2_INTERNAL_IP:8899 | jq .error.data) SOLANA_SLOTS_BEHIND=$(echo $SOLANA_SLOTS_BEHIND_DATA | jq .numSlotsBehind -r) if [ "$SOLANA_SLOTS_BEHIND" == "null" ] || [ -z "$SOLANA_SLOTS_BEHIND" ] then SOLANA_SLOTS_BEHIND=0 fi if [ $SOLANA_SLOTS_BEHIND -gt $MAX_SOLANA_SLOTS_BEHIND ] then if systemctl is-active --quiet net-rules ; then systemctl stop net-rules fi fi if [ $SOLANA_SLOTS_BEHIND -eq 0 ] then if ! systemctl is-active --quiet net-rules ; then systemctl start net-rules fi fi fi 本番環境で使用する前に、この投稿のコードまたは AWS Blockchain Node Runners について: これらのスクリプトを安全な環境でレビューおよびテストしてください 必要に応じて入力検証を追加してください 適切なエラー処理とログ記録を実装してください 必要最小限の権限でスクリプトを実行してください まとめ この記事では、Solana Agave v2.x で導入された変更により必要な CPU クロック速度が増加したことを確認し、アジア太平洋地域における Solana Agave クライアントの同期時間を改善する方法を検討し、Solana RPC ノードのデータ転送コストを最適化する方法を紹介しました。 これらの最適化をご自身のノードでテストするか、 AWS Blockchain Node Runners イニシアチブの Solana ブループリント を使用してください。 さらに質問がある場合は、 AWS re:Post で「blockchain」タグを付けて質問するか、 Solana StackExchange でディスカッションに参加するか、 Solana コミュニティ にお問い合わせください。 著者について Tao Gong Tao はブロックチェーン技術の愛好家です。AWS 上で革新的なソリューションを構築するために顧客と協力し、ビジネス上の課題を克服し、AWS サービスを効率的に採用できるよう支援しています。 Jinsong Zhu Jinsong は AWS のシニアソリューションアーキテクトで、大手 Web3 および暗号資産企業向けに高性能、低レイテンシー、コスト最適化されたクラウドソリューションの設計を専門としています。 Nikolay Vlasov Nikolay は、AWS Worldwide Specialist Solutions Architect 組織における分散型台帳技術インフラストラクチャのグローバルリードです。顧客が AWS 上で分散型ウェブおよび台帳技術のワークロードを実行できるよう支援しています。

はじめに こんにちは。 @Sakamoto です。 この記事は、 Merpay & Mercoin Advent Calendar 2025 の4日目の記事です。 2025年9月からメルコインでフロントエンドのインターンを始め、12月初めでちょうど3か月になりました。期間中はメルコインに加え、メルカリNFTの開発にも参加しました。 本記事では、インターン期間中に取り組んだタスクを振り返り、そこで得た学びや気づきをまとめます。 チームについて 今回のインターンではメルコインとメルカリNFTでフロントエンドエンジニアとして参加しました。それぞれ扱うプロダクトの特性が大きく異なるため、求められる視点や進め方にも違いがありました。 メルコイン 暗号資産交換業としてガバナンスやリーガルと関わりが深く、単に機能を実装するだけでなく、背景となる法律や制約を理解したうえで開発を進める必要があります。 メルコインのフロントエンドチームはお客さま対応のための社内ツールのフロントエンド開発、LP（ランディングページ） の作成などを担当しています。 メルカリNFT NFTの売買を可能にするプロダクトを持つチームで、2025年1月に提供を開始し、現在も毎週のように新機能が追加されています。 そのため、よりスピード感のある開発が求められる環境でした。 メルカリNFTのフロントエンドチームは主にメルカリNFTのフロントエンド開発を担当しています。 取り組み概要 メルコイン 社内ツールのフロントエンド改修 メルカリNFT 買取機能の実装・改善 メルカリNFTのくじをメルカリアプリ内から購入できるようにするための対応 リリース後のメモリ監視 その他 Web3領域のドメイン知識の習得 社内の多職種の方とのコミュニケーション エンジニア業務でのAI活用 ここでは太字の6つについてまとめようと思います。 社内ツールのフロントエンドの改修 背景 メルコインで進行しているプロジェクトの一部として、口座の状況、暗号通貨の配信価格など、お客さまからのお問い合わせに必要な情報を確認できる社内ツールの改修を担当し、フロントエンドの仕様整理から実装、QAチームとのテストケースの調整まで、一連の開発プロセスに関わりました。 やったこと 社内ツールの改修にあたって、 表記揺れがないか バリデーションに過不足はないか エラーハンドリングが適切か UIの整合性があるか API連携が正しいか 変更に柔軟に対応できる設計か といったポイントを確認し、後工程での手戻りが起きにくい状態まで仕様書のレビューを行いました。 その上で自分の実装スピードや改修範囲を考慮し、適切なバッファを含めて工数見積もりを行いました。 実装では、各マイクロサービス間の通信にはgRPCが使われているため、Protocol Buffersの定義からモックを作り、UIとの接続を進めると同時にCypressでのE2Eテストも作成・改修に取り組むことができました。 またQAチームとはテストケースや指摘内容を確認しながら、仕様と実装の齟齬をなくすことに努めました。 学び gRPCやProtocol Buffers、Cypressといったこれまで触れる機会の少なかった技術に取り組んだことで、フロントエンド以外の領域にも一部理解が広がりました。 あわせて、仕様書の精度をどう高めるか、どの程度のバッファを見込んで工数を組み立てるか、レビューされやすいコードにするにはどんな書き方がよいかなど、プロダクト開発全体を俯瞰する視点も身についたと感じています。 買取機能の実装・改善 背景 メルカリNFT内のGMV（流通取引総額）を伸ばすための施策として、NFTくじを購入したお客さまが買取依頼を出せる機能の追加をしました。 それに伴い、商品詳細ページに新しいUIや状態管理が必要となり、この部分の改修を担当しました。 また、このタスクがメルカリNFTのコードを触る最初の機能開発だったため、既存コードや周辺仕様のキャッチアップを素早く進める必要もありました。 やったこと 仕様書を確認し、商品詳細ページのどのタイミングで買取ボタンを表示するか、どの状態をどう見せるかといったUIの出し分けを整理しました。 その上で、実装した内容の品質を担保するためにVRT（Visual Regression Test）を活用し、Playwrightを用いたインテグレーションテストも追加・修正しました。 学び Playwrightを使ったインテグレーションテストやVRTの活用など、これまで触れる機会のなかったテスト手法を実際に使いながら理解を深められました。 また、買取前後でUIが複雑に変化する仕様だったこともあり、コンポーネントの責務をどう分けるか、保守性と可読性をどこまで両立できるか、といった設計面の学びも多かったです。 スピードが求められる環境の中でも、既存実装の調査や理解を並行して進めることの重要性を実感しました。 リリース後のメモリ監視 背景 メルカリNFTでは、サービスを安定して提供し続けるために、リリース後のリソース状況の監視や挙動の確認を継続的に行っています。 特にメモリ使用量は、トラフィックの増減や特定機能の利用状況によって変動しやすいため、定期的に観測し、必要に応じて挙動を調査する運用を行っています。 今回の取り組みでは、本番環境のメモリ使用状況をより細かく把握し、どのタイミングでどう増減しているのかを整理しながら、今後の安定した運用につなげるための調査を進めています。 やったこと まずは「いつ・どんな状況でメモリが増えるのか」を把握するために、各Podのメトリクスを確認し、傾向を調査しました。 その上で、なぜそのような増加が起こるのか仮説を立て、順に検証を進めました。 Datadogからログやメトリクスを細かく確認しつつ、他チームにも相談し、Node.jsやNext.jsの内部挙動、キャッシュやSSR周りの可能性など、さまざまな観点から情報を集めることで検証の方向性を調整しています。 学び 日々の調査の中で得られる学びは非常に多いと感じています。 Node.jsやNext.jsが内部でどのようにメモリを使うのか、CPU・GCの仕組み、キャッシュの扱いなど、技術的な理解が大きく深まりました。 同時に、進行中の問題を扱う際のコミュニケーションの取り方や調査内容のまとめ方、仮説の立て方と検証の進め方、進捗が見えにくいタスクをどうやって周囲と共有するかなど、機能開発とは異なるスキルも求められることを実感しています。 Web3領域のドメイン知識の習得 メルコインとメルカリNFTの両方に関わる中で、Web3に関する基礎知識を継続的に身につけることを意識してきました。 暗号資産やNFTの基本概念をはじめ、法規制やコンプライアンス、チェーンの仕組み、トランザクションの流れ、ウォレットの挙動など、業務に必要な知識は社内ドキュメントとして多く整理されています。 日々の開発と並行して、それらの資料を自分から探して読み、背景となるドメイン理解を深めるようにしてきました。 Web3は学ぶ範囲も広く、継続して取り組みたい領域です。 社内の多職種の方とのコミュニケーション もう一つ意識的に取り組んでいたのが、社内の多職種の方とのコミュニケーションです。 プロダクト開発では、さまざまな職種と連携しながら仕様の確定やリリースに向けた調整を進める必要があります。 そのため、日々のやり取りだけでなく、会社の施策として実施されているチービルやメンターランチの機会を活用しつつ、自分からも声をかけて1on1やランチの機会をつくるようにしていました。 チーム全体が話しかけやすい雰囲気を持っていたこともあり、積極的にコミュニケーションを取ることができました。 また、普段どのように技術をキャッチアップしているのか、どんな観点で仕様を見ているのか、なぜ今のキャリアを選んだのかといった話を聞くことで、自分の知らなかった考え方や知識に触れる機会も多くありました。 開発スキルだけでは得られない学びが多く、視野を広げるきっかけになったと感じています。 エンジニア業務でのAI活用 CursorなどのAIツールも積極的に活用し、コード全体の構造を素早く把握したり、関連部分の洗い出しを効率よく進めるようにしていました。 開発・実装では、メンターの方からのアドバイスも参考にしながら、どの情報を渡すと意図が正確に伝わるかといった点を意識するようにしました。 仕様を明確にまとめてコンテキストとしてAIに渡すことで、実装の方向性がぶれにくくなり、提案されるコードの品質も安定するようになりました。 また、AIから返ってくるコードはそのまま使うのではなく、自分の考えとの違いを確認したり、なぜその書き方になるのかを読み解くことで理解を深めるきっかけにもなりました。 結果として、実装を効率化するだけでなく、コードの設計方針を比較しながら学べる良い教材のような存在にもなっていたと思います。 まとめ 3か月を通して、メルコインとメルカリNFTのそれぞれ異なる特徴を持つプロダクトの開発に携わり、多くの学びを得ることができました。 機能実装だけでなく、仕様の詰め方、テストの考え方、多職種とのコミュニケーションなど、エンジニアとして必要なスキルを幅広く経験できた期間だったと感じています。 残りの1か月も、これまでの学びを活かしながら、より深い理解と確かなアウトプットを積み重ねていきたいと思います。 明日の記事は @Fabさんです。引き続きお楽しみください。