エブリー開発本部の塚田です。 バックエンドやデータ基盤をメインに担当しています。 2026年4月に Amazon S3 の新機能として Amazon S3 Files が GA となり、続けて4月後半には Lambda からの利用にも対応 しました。 データエンジニア視点で見ると、「Lambda で並列データ処理を書くときに毎回悩んでいた、状態の持ち回り」がやりやすくなるんじゃないかと感じました。 本記事では、Lambda 上のデータ前処理パイプラインを S3 Files で組み直すとどう変わるか、を検討しました。 なぜ Lambda 前処理で「状態」が悩みの種だったのか Lambda はスケールが効き、起動コストも安いので、データ前処理を分散させる用途には便利です。一方で、Lambda が「ステートレスな関数」であるという前提と、データ処理に必要な「ある程度大きな共有データ・中間成果物のやり取り」が噛み合わないことが多く、設計時に悩む箇所でもあります。 これまで取りうる選択肢と課題感は以下があると思います。 各 Lambda が S3 から個別に GET/PUT : 起動ごとに DL コストがかかり、並列度を上げてもスループットが頭打ちになり、リクエスト課金も比例して膨らむ DynamoDB / ElastiCache を共有ストアにする : 大きめのオブジェクトには不向き、別サービスの運用も乗ってくる Lambda + EFS マウント : ファイル共有はできるが、S3 と二重管理になり、外部から覗きにくい EFS をマウントすれば「並列 Lambda が共有のファイルシステムを持つ」構成自体は以前から作れました。ただし EFS と S3 はそれぞれ別ストレージなので、「分析やバックアップは S3 側のオブジェクトでやるが、パイプラインの共有だけ EFS」というように二重管理になりがちで、ファイルとオブジェクトの間を行き来する同期スクリプトが必ずどこかで生えていました。 S3 Files が変えるもの S3 Files は内部的には Amazon EFS をベースにした NFS v4.2 のファイルシステム で、EC2 / Lambda / ECS / EKS から mount でき、書いたデータはマウント側からは即時に見え、S3 バケット側にも非同期で反映されます。 S3 Files は Mountpoint for Amazon S3 のような機能とは別物です。Mountpoint は S3 の API の上にファイルシステムの振る舞いを「見せる」アプローチなので、たとえばファイルの一部を上書きする操作が原理的にサポートされません。一方 S3 Files はファイルシステム側から見えるのは本物の NFS セマンティクスで、S3 側から見えるのは本物の S3 オブジェクトです。「両者は別物だが、その間の同期レイヤーを AWS が引き受けてくれている」という設計になっています。 ここまでが前提です。データ基盤側にとってこの仕様が嬉しいのは、次の2点あると考えています。 複数 Lambda が同時マウントできる ：並列ジョブ間の共有として使える 同じデータをファイル経由でも S3 API 経由でも読める ：パイプラインの内部処理はファイル世界で書いて、運用や監査は S3 世界で済ませられる 検証: 並列特徴量生成パイプラインを組んでみる 具体的なシナリオで Before / After を比較します。 シナリオ 入力: 新規レシピ 1000 件（メタデータと本文） 処理: 10 並列の Lambda が分担して特徴量を抽出する 共有して使うマスターデータ: 食材辞書 JSON（数十〜数百 MB） 既存レシピの埋め込みベクトル（数百 MB〜1 GB） 出力: 各 Lambda が抽出した特徴量を後段ジョブが集約 Before: 各 Lambda が S3 から個別 DL する構成 import boto3, json import numpy as np s3 = boto3.client( "s3" ) def handler (event, context): # コールドスタートのたびに、数百MB級のマスターを /tmp に取得 s3.download_file( "recipes-bucket" , "master/ingredients.json" , "/tmp/ingredients.json" ) s3.download_file( "recipes-bucket" , "master/embeddings.bin" , "/tmp/embeddings.bin" ) ingredients = json.load( open ( "/tmp/ingredients.json" )) embeddings = np.fromfile( "/tmp/embeddings.bin" , dtype=np.float32) features = build_features(event[ "recipes" ], ingredients, embeddings) # 結果は S3 に書き戻す body = serialize(features) s3.put_object( Bucket= "recipes-bucket" , Key=f "features/{event['job_id']}/{event['shard']}.parquet" , Body=body, ) この場合、以下のような問題点が考えられます Lambda コールドスタートのたびに数百 MB の DL が走る /tmp の 10 GB 制限に当たりかけることがあり、マスターを増やす際の考慮事項が発生 並列度を上げると、結局 S3 → Lambda の転送スループットがボトルネックになる マスターを更新したときに「全 Lambda がそれを見ている」状態を担保しづらい After: S3 Files をマウントして共有領域として使う /mnt/s3files に recipes-bucket をマウント済みとします。 import json, os import numpy as np # モジュールトップで一度だけ読み、コンテナ再利用時はそのまま使う INGREDIENTS = json.load( open ( "/mnt/s3files/master/ingredients.json" )) EMBEDDINGS = np.fromfile( "/mnt/s3files/master/embeddings.bin" , dtype=np.float32) def handler (event, context): out_dir = f "/mnt/s3files/features/{event['job_id']}" os.makedirs(out_dir, exist_ok= True ) out_path = f "{out_dir}/{event['shard']}.parquet" features = build_features(event[ "recipes" ], INGREDIENTS, EMBEDDINGS) write_parquet(out_path, features) boto3 の呼び出しが消え、純粋に「ファイルを読み、ファイルを書く」コードになっています。Lambda 関数内で s3.put_object を発行する必要がないので、リトライやマルチパートアップロードの考慮もパイプライン側のコードからは消えます。 書き出した特徴量は、後段の集約ジョブからは S3 API で s3://recipes-bucket/features/{job_id}/ を aws s3 ls するだけで一覧でき、運用者から見えるバケットの世界も自然なままです。 Before / After で何が変わるか 指標 Before（個別 DL） After（S3 Files） コールドスタート時の初期化 約 1 GB の DL が発生する マウント越しの mmap / page cache に乗る 並列実行時のスループット S3 → Lambda の DL 帯域がボトルネックになりやすい 各 Lambda が同じファイルをキャッシュ越しに参照 S3 GET リクエスト数 コールドスタート × オブジェクト数 ぶん発生 マスターは初回のみ、出力 PUT は不要 /tmp 使用量 DL したマスターぶん消費 マウント領域は /tmp を消費しない 特に効きそうなのは コールドスタート時の DL コスト と S3 リクエスト数 です。前者はマスターサイズに比例し、後者はそのまま月次コストに跳ねるため、並列度が高いシナリオほど差が広がります。 チェックポイント付きジョブとしての応用 並列処理の共有だけでなく、もう一つ価値が出やすいユースケースが 長時間ジョブのチェックポイント だと考えています。 Lambda は最大実行時間の制限がありますが、それを超える処理は分割して Step Functions で繋ぐ、というのがよくある構成かと思います。ステップ間で「どこまで処理が進んでいるか」を引き渡すのに様々な方法で考慮を入れることが発生します。S3 Files を使うと、これがそのままファイルとして書け、しかも S3 API から覗ける という性質を活かせます。 import json, os WORKSPACE = "/mnt/s3files/agents/recipe-tagger" def handler (event, context): job_id = event[ "job_id" ] state_dir = f "{WORKSPACE}/{job_id}" state_path = f "{state_dir}/state.json" os.makedirs(state_dir, exist_ok= True ) state = json.load( open (state_path)) if os.path.exists(state_path) else { "processed" : 0 , "results" : [], } # 中断された場合は、processed の続きから再開 for item in event[ "items" ][state[ "processed" ]:]: state[ "results" ].append(process(item)) state[ "processed" ] += 1 # 100件ごとにチェックポイントを永続化 if state[ "processed" ] % 100 == 0 : tmp_path = f "{state_path}.tmp" with open (tmp_path, "w" ) as f: json.dump(state, f) os.replace(tmp_path, state_path) # アトミックに置き換える with open (state_path, "w" ) as f: json.dump(state, f) return { "job_id" : job_id, "processed" : state[ "processed" ]} ポイントは、 チェックポイントが S3 API 側からも見える という点です。運用中に「いまどのジョブがどこまで進んでいるか」を aws s3 cp s3://recipes-bucket/agents/recipe-tagger/{job_id}/state.json で確認できます。 向く用途・向かない用途 検証を通じて見えた、自分なりの線引きです。 S3 Files が向く用途 並列ジョブが共通参照する大きめのマスターデータの配置先 並列ジョブの中間成果物を集約する 長時間ジョブのチェックポイント 既存のファイル前提コードを最小改修で S3 へ移すリフトアンドシフト 向かない用途 強整合性が必要なメタデータ管理 大量の小ファイル rename を伴うワークフロー ミリ秒レイテンシが要求されるクリティカルパス ファイル経由と S3 API 経由の両方から同じファイルに書き込む運用 おわりに すべての処理を S3 Files 経由にする必要はなく、並列ジョブの共有、チェックポイント、共通マスターの配布など、「これまでファイルシステムが欲しかったがゆえに EFS を別建てしていた / 自前で同期していた」箇所だけをピンポイントで置き換えるのが、効きの良い使いどころだと現状では考えています。

はじめに AIを活用した開発が一般化するにつれて、API利用料を日常的に意識する場面が増えてきました。 最近では、ノートPC上で動作する自律型 AI エージェント（例：OpenClaw など）や開発支援ツールを常時稼働させ、外出先からスマートフォン経由で指示を与えるような利用スタイルも増えつつあります。 このような環境では、API利用料はバックグラウンドで継続的に増加するため、 「気づいたら想定以上の課金が発生していた」 という状況が起こり得ます。 しかし実際の運用では、以下のような課題があります。 API利用料を確認するために OpenAI Platform（管理コンソール）を毎

はじめに はじめまして。2025年9月に入社したshun-itoと申します。所属は基幹システムグループ インフラシステムチームです。担当業務はオフィス及びデータセンターのネットワークの設計・構築・運用・保守です。 趣味はバスケやボウリングなどで体を動かすことと、お酒（最近は特にクラフトビールと日本酒）を飲むためにお出かけすることです。 これまでの経歴と転職のきっかけ 前職では某事業会社（非IT系）の子会社に在籍しており、セキュリティ系システムのインフラ部分（ネットワーク、サーバ）の設計・構築を担当しておりました。 前職での私のポジションは顧客（親会社のシステム部）の要望のヒアリングや進捗報告、システム開発ベンダーへの依頼や進捗管理を担当しておりました。ですので、自分で手を動かしてシステムに触れる機会があまり無く、ステークホルダーとのコミュニケーションを取る時間が業務の大半を占めておりました。 私は自分の手でシステムに触れる方が性に合っていると感じ、ベンダーへ委託するよりも内製で業務を遂行する会社に転職したいと考えるようになりました。また、前職では運用・保守は担当していなかったので、より幅広い工程に携わりたいとも考えておりました。 業務を内製化していること・自身の技術領域（主にネットワーク）と一致していること・できるだけ幅広い工程に携われることの3点を軸として転職先の候補となる会社を調べていたところ、ニフティにたどり着きました。 ネットワークエンジニアとして当然ニフティは存じ上げており、転職活動の早い段階で候補に上がりました。他にも候補は何社かありましたが、他の会社と比較すると求められるスキルや経験が私の持つものと共通点が多く志向性が合いそうだと考えて応募し、幸いにも内定を頂くことができました。 入社して感じたこと 応募した職種は文字通り「ネットワークエンジニア」でしたので、概ね予想していた通りの業務内容ではありました。 しかし、一口に「ネットワークエンジニア」と言いましても、やはり会社によって採用している技術領域には僅かな違いがあります。先ほど「求められるスキルや経験が私の持つものと共通点が多かった」と申し上げましたが、僅かに違う技術領域の習得は必要になりましたので、慣れるまでの苦労はありました（ニフティに転職するまでは、CiscoやJuniperの機器を使用したオンプレのネットワークの経験しかなく、AWSやAzure等のパブリッククラウドを使用した経験がありませんでした） ただ、オンボーディングの内容が体系的にまとめられており、何をどの順番で習得していけばいいのかが分かりやすかったのが大きな助けになりました。 今後の目標・抱負 実は私は僭越ながらも「リードエンジニア候補」という枠で入社させていただきました。過去にもチームリーダーの経験（あまり自覚は無いですが周りからはそう見られていたようです）はありましたが、ニフティのリーダークラスの方々を見ていると、知識の広さや深さ、そして判断の速さに驚かされる機会も多いです。そういった方々が身近にいらっしゃることは大変心強いのですが、その一方で将来的には自身がそのような立ち位置に付いていることを期待されていると考えると「本当に自分で大丈夫かな・・・？」と不安になることもあります。 今後は技術や知識を身に着けていくことはもちろん、リーダーシップを発揮できるようなコミュニケーションスキルも身に着けていき、期待に応えられるようにリーダーとして活躍していきたいです。 最後に ここまで読んでいただきありがとうございました。 ニフティは提供サービスが多く、その分採用している技術領域の幅が広いので自分に合ったチームが見つかりやすい会社だと思います。 「自分の得意分野で活躍したい」という想いも「新しいことにチャレンジしたい」という想いも叶えられる環境があります。 少しでもニフティにご興味を持っていただけたのであれば、ぜひ応募していただき、カジュアル面談や面接でお話してみませんか？ 皆さんと一緒に働ける日をお待ちしております！