AWS のつなぐサービスの使い分け ── SQS・SNS・EventBridge・Step Functions・MQ・AppFlow

October 14, 2026October 28, 2026

概要

アプリケーションを部品に分けて作ると、部品と部品の間で「誰が、いつ、何を受け取るか」を決める仕組みが必要になります。AWS にはこの「つなぐ」役目のサービス（アプリケーション統合サービス）が複数あり、名前だけでは違いが分かりにくい分野です。

この記事では、キュー（Amazon SQS）、Pub/Sub（Amazon SNS）、イベントバス（Amazon EventBridge）、ワークフロー（AWS Step Functions）、既存のメッセージブローカーの移行先（Amazon MQ）、SaaS とのデータ連携（Amazon AppFlow） の 6 つを、「1 対 1 か 1 対多か」「受け手が取りに行くか、送り手が届けるか」「何を基準に振り分けるか」という観点で比較表にまとめます。あわせて、AWS Certified Solutions Architect – Associate（SAA）の範囲に含まれる AWS Serverless Application Repository・Amazon Elastic Transcoder・Amazon Kinesis Video Streams・AWS Device Farm を、名前と役割だけ整理します。

AWS Certified Cloud Practitioner（CLF）では第 3 分野「クラウドテクノロジーとサービス」のアプリケーション統合サービスに当たり、SAA では疎結合なアーキテクチャの設計で同じ判断を問われます。各サービスを実際に動かすのはサービス別の「基本のキ」記事で扱い、ここでは「どれを選ぶか」に絞ります。

クラウドおさる

猿山でも、伝言は「当番が取りに来る伝言箱」と「ほら貝で全員に知らせる」のを使い分けているでござる。AWS のつなぐサービスも、届け方の違いで選ぶのでござるな。

—

この記事のメリット

SQS・SNS・EventBridge・Step Functions・MQ・AppFlow の役割の違いを 1 つの表で説明できるようになります
「1 対 1 か 1 対多か」「プルかプッシュか」という観点で、キューと Pub/Sub を見分けられます
SNS と EventBridge、SQS と Amazon MQ のような、取り違えやすい組み合わせの選び分けが分かります
SNS と SQS を組み合わせるファンアウトなど、サービスを組み合わせる定番の形を把握できます
SAA の範囲に入る周辺サービス（Serverless Application Repository など）の役割と、提供状況の変化を確認できます

—

執筆者とキャラクター紹介

執筆者：土肥（とひ）

株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。

クラウドおさる

クラウドおさる

はじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。

クラウドおさる

基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。

クラウドおさる

猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。

技術解説

そもそも「つなぐ」サービスはなぜ要るのか

クラウドおさる

とひさん、プログラム同士は直接呼び出せばつながるでござる。わざわざ間に別のサービスを挟むのは、なぜでござるか？

土肥

いい質問だね！直接呼び出すと、呼ばれる側が止まっているときや混んでいるときに、呼ぶ側まで一緒に困っちゃうんだ。間に SQS や SNS を挟むと、送る側は「預けたら終わり」になって、受け取る側は自分のペースで処理できる。これを疎結合とか非同期の通信って言うよ。

クラウドおさる

なるほど。では間に挟むものは、どれを選んでもよいのでござるか？

土肥

そこが今日の本題なんだ。AWS の判断ガイドでは、アプリケーション統合サービスを「何に使うか」で分けて整理しているよ。まとめるとこんな感じ。

区分	どんなときに使うか	代表サービス
イベント	送り手と受け手を切り離し、イベントを複数の受け手に同時に送りたい	Amazon EventBridge / Amazon SNS
メッセージング	複数の宛先に一斉に送る（Pub/Sub）、または部品同士で確実に非同期で受け渡す（ポイントツーポイント）	Amazon SNS / Amazon SQS / Amazon MQ
ストリーミング	リアルタイムに流れてくる大量のデータを取り込んで処理する	Amazon Kinesis Data Streams / Amazon MSK
ワークフロー	一連の作業の順番・分岐・並列・再試行を管理したい	AWS Step Functions / Amazon MWAA
スケジュール	毎晩・毎時など決まった時刻にタスクを動かしたい	Amazon EventBridge（EventBridge Scheduler）

クラウドおさる

SNS がイベントとメッセージングの両方に入っているでござる。ひとつのサービスが 1 つの区分に収まるとは限らないのでござるな。

土肥

その通り！判断ガイドも「目的別のサービスを組み合わせるのが合う場合がある」と言っているよ。たとえば EventBridge や SNS のイベントを SQS のキューに流して、受け手の前のバッファにする使い方が定番なんだ。ストリーミングは別の記事で扱うから、ここではそれ以外を見ていこう。

キュー：SQS は「1 対 1・受け手が取りに行く」

クラウドおさる

まず SQS でござる。キューとは何でござるか？

土肥

SQS はメッセージを預けておく「待ち行列」のサービスだよ。送り手（プロデューサー）がキューにメッセージを入れて、受け手（コンシューマー）が自分の都合のいいときにキューから取りに行く。この「受け手が取りに行く」形をプル型って言うんだ。公式ドキュメントでも、SQS は通常 1 つのサブスクライバーを通じてメッセージを処理する、と説明されているよ。

クラウドおさる

取りに行ったときに、キューが空っぽだったらどうなるのでござる？

土肥

取りに行く操作（ReceiveMessage）には 2 つのやり方があるんだ。すぐに返事をもらうショートポーリングと、メッセージが来るまで最大 20 秒待つロングポーリング。ロングポーリングにすると空振りの返事が減るから、コストも下げられるよ。

クラウドおさる

伝言箱の前で少し待っていれば、何度も箱をのぞきに行かずに済むでござるな！

土肥

そうそう！それから、キューには 2 つの種類があるよ。

キューの種類	配信の性質	向いている場面
標準キュー	少なくとも 1 回配信（at-least-once）	順番が多少前後しても困らない大量の処理
FIFO キュー	1 回のみの処理（exactly-once processing）、送った順を守る	注文の受付など、順番と重複防止が大事な処理

クラウドおさる

1 つのメッセージを 1 人の当番が取りに来て片付けるのが SQS でござる。順番を守りたいなら FIFO、と覚えるでござる。

Pub/Sub：SNS は「1 対多・送り手が届ける」

クラウドおさる

SNS は通知のサービスと聞いたでござる。SQS とは何が違うのでござるか？

土肥

SNS はトピックにメッセージを送ると、そのトピックを購読（サブスクライブ）している全員に、SNS のほうから配ってくれるんだ。1 つのメッセージが複数の宛先に届く1 対多で、送り手側から届けるプッシュ型だよ。これを Pub/Sub（パブリッシュ／サブスクライブ）って呼ぶんだ。

クラウドおさる

配る相手には、どんなものが選べるのでござるか？

土肥

大きく 2 種類あるよ。アプリケーション同士でやりとりする A2A と、人に直接届ける A2P だね。

種類	届け先の例
A2A（Application-to-Application）	Amazon SQS、AWS Lambda、HTTP/HTTPS エンドポイント、Amazon Data Firehose
A2P（Application-to-Person）	E メール、SMS（テキストメッセージ）、モバイルプッシュ通知

クラウドおさる

ほら貝を吹けば、山じゅうの猿に一度に届くのと同じでござるな！

土肥

うまいね！ただ、ほら貝と違って、SNS はその場で届けるのが仕事だから、受け手が忙しくて後で処理したいときは困るよね。そこで SNS の配り先に SQS のキューを並べるファンアウトっていう組み合わせがよく使われるんだ。SNS で一斉に配って、それぞれのキューで受け手が自分のペースで処理する形だよ。

クラウドおさる

SQS と SNS は名前が似ているでござるが、SQS は「取りに行く・1 対 1」、SNS は「届ける・1 対多」で真逆でござる。ここを取り違えないようにするでござる。

イベントバス：EventBridge は「中身を見て振り分ける」

クラウドおさる

EventBridge も「複数に届ける」なら、SNS と同じでござるか？

土肥

似ているけど、得意なことが違うんだ。EventBridge のイベントバスは、受け取ったイベントの中身をルールのイベントパターンと照らし合わせて、一致したものだけをターゲットに送る「振り分け係（ルーター）」なんだよ。たとえば「EC2 インスタンスの状態が running になった」というイベントだけを拾う、みたいな条件を書けるんだ。

クラウドおさる

イベントは、どこからやってくるのでござるか？

土肥

3 つの入口があるよ。

イベントの出どころ	受け取るイベントバス
AWS のサービス（EC2 の状態変化など）	すべてのアカウントにあるデフォルトイベントバス
自分で作ったアプリケーション	自分で作るカスタムイベントバス
SaaS パートナー（Salesforce、Zendesk、Datadog など）	パートナーイベントソースを関連付けたパートナーイベントバス

土肥

それに EventBridge には、決まった時刻や間隔でターゲットを動かす EventBridge Scheduler もあるんだ。cron 式やレート式で書けるし、1 回だけの実行も作れるよ。1 つのソースから 1 つのターゲットへつなぐ EventBridge Pipes という機能もあるね。

クラウドおさる

長老会の掲示板に届いた知らせを、「バナナの話は倉庫番へ、雨の話は見張りへ」と中身で振り分ける係でござるな！

土肥

そうそう、その通り！ちなみに 1 つのルールに付けられるターゲットは最大 5 つなんだ。それから最近は、ルールの代わりに受け手側が「サブスクライバー」を作って、バスがイベントを保持して再生もできる新しいカスタムイベントバスも用意されているよ。従来のルール型は「Classic」と呼ばれるようになったけど、どちらも使えるんだ。

観点	Amazon SNS	Amazon EventBridge
届け方	トピックの購読者全員に配る	ルールのイベントパターンに一致したターゲットに送る
得意なこと	メール・SMS など人への通知、大量の宛先への一斉配信	AWS サービスや SaaS のイベントを中身で振り分ける、スケジュール実行
SaaS との連携	―	パートナーイベントソースからイベントを受け取れる

クラウドおさる

「全員に配る」なら SNS、「中身で振り分ける」「SaaS や AWS サービスのイベントを拾う」「決まった時刻に動かす」なら EventBridge でござる。

ワークフロー：Step Functions は「手順の順番を管理する」

クラウドおさる

Step Functions は、メッセージを運ぶのとは違うのでござるか？

土肥

そうなんだ。Step Functions は「受け取ったら A をして、結果によって B か C に分かれて、失敗したらもう一度やり直す」といった一連の手順そのものを管理するサービスだよ。この手順をステートマシン（ワークフロー）と呼んで、1 つひとつのステップをステートって言うんだ。

クラウドおさる

SQS や SNS でも、順番に処理をつなげられそうでござるが…。

土肥

つなげることはできるけど、「今どこまで進んだか」「失敗したら何回やり直すか」を自分で作り込むことになるんだ。Step Functions なら、分岐（Choice）、並列（Parallel）、データの各項目に同じ処理を繰り返す（Map）、失敗時の再試行（Retry）や代わりの処理（Catch）を定義の中で書けるよ。ワークフローには 2 つのタイプがあるんだ。

観点	Standard ワークフロー	Express ワークフロー
最大実行時間	1 年	5 分
実行のされ方	1 回だけ実行	非同期で実行すると 1 回以上実行されることがある（同期で実行すると最大 1 回）
料金の決まり方	ステートの移行数	実行回数と実行時間
向いている場面	承認待ちを含む業務処理など長い処理	大量のイベントを短時間でさばく処理

クラウドおさる

「次に何をするか」「失敗したらどうするか」を順番どおりに見張る当番が Step Functions でござる。伝言を運ぶ係とは役目が違うのでござるな。

Amazon MQ：既存のメッセージブローカーをそのまま移す

クラウドおさる

キューなら SQS があるのに、Amazon MQ は何のためにあるのでござるか？

土肥

Amazon MQ は、Apache ActiveMQ や RabbitMQ といったオープンソースのメッセージブローカーを AWS がマネージドで動かすサービスなんだ。オンプレミスでこれらのブローカーを使っているシステムは、AMQP や MQTT のような業界標準のプロトコルで話しているよね。Amazon MQ に移せば、メッセージングのコードを書き換えずにクラウドへ持っていけるんだ。

エンジン	対応しているプロトコル
Amazon MQ for ActiveMQ	AMQP、MQTT、MQTT over WebSocket、OpenWire、STOMP、STOMP over WebSocket
Amazon MQ for RabbitMQ	AMQP 0-9-1、AMQP 1.0、JMS 1.1 / 2.0 / 3.1

クラウドおさる

では、新しく作るアプリなら、どちらを選べばよいのでござる？

土肥

公式ドキュメントでも、Amazon MQ は「従来のメッセージブローカーからの移行を検討している企業に最適」と説明されているんだ。既存のブローカーやプロトコルを引き継ぐ必要がないなら、サーバーレスの SQS や SNS のほうが、ブローカーのサイズを決めたりせずに使い始められるよ。

クラウドおさる

「既存の ActiveMQ や RabbitMQ を、コードを書き換えずに移したい」と書かれていたら Amazon MQ、新しく作るなら SQS や SNS、でござる。どちらも「キュー」なので取り違えやすいでござるぞ。

AppFlow：SaaS とのデータ連携

クラウドおさる

最後の AppFlow は、どんなものをつなぐのでござるか？

土肥

AppFlow は、Salesforce、Zendesk、Slack、ServiceNow のような SaaS アプリケーションと AWS のサービスの間でデータをやりとりするフルマネージドの統合サービスだよ。コードを書かずに「フロー」を作って、たとえば Salesforce のデータを Amazon S3 や Amazon Redshift に流し込めるんだ。

クラウドおさる

フローは、いつ動くのでござるか？

土肥

3 つから選べるよ。手動で動かすオンデマンド、決まった間隔で動かすスケジュール、SaaS 側で新しいレコードができたときなどに動くイベントだね。転送するデータは保存中も転送中も暗号化されるよ。

クラウドおさる

EventBridge も SaaS とつながると聞いたでござる。どう違うのでござる？

土肥

いいところに気づいたね！ EventBridge は SaaS で「何かが起きた」というイベントを受け取って処理を動かす係、AppFlow は SaaS にたまっているデータそのものを AWS に運んで分析などに使う係、と分けて考えるとわかりやすいかな。

名前と役割だけ押さえる周辺サービス

クラウドおさる

SAA の範囲には、ほかにも見慣れない名前が並んでいたでござる。

土肥

深掘りはしないけど、名前と役割だけ押さえておこう。提供状況が変わっているものもあるから気をつけてね。

サービス	役割	提供状況などの注意
AWS Serverless Application Repository	サーバーレスアプリケーションを検索・デプロイ・公開するリポジトリ。AWS SAM テンプレートで公開し、Lambda コンソールと統合されている	―
Amazon Elastic Transcoder	Amazon S3 に置いたメディアファイルを、各デバイスで再生できる形式に変換する	2025 年 11 月 13 日にサポート終了。以降はコンソールにもリソースにもアクセスできない。移行先として AWS Elemental MediaConvert が案内されている
Amazon Kinesis Video Streams	カメラ・スマートフォン・ドローンなどのライブ動画を取り込み、保存・再生・リアルタイム処理する	―
AWS Device Farm	AWS が用意した実際のスマートフォンやタブレットで、Android・iOS・ウェブアプリをテストする	米国西部（オレゴン）リージョン `us-west-2` でのみ利用できる

クラウドおさる

Elastic Transcoder はもう使えないのでござるな。動画の変換と聞いたら、今は MediaConvert のほうを思い浮かべるでござる。

迷ったときの選び方

土肥

最後に、ここまでの話を 1 つの表にまとめるよ。

サービス	一言でいうと	何対何	届け方	CLF	SAA
Amazon SQS	キュー	1 対 1	受け手が取りに行く（プル）	範囲内	範囲内
Amazon SNS	Pub/Sub	1 対多	送り手側から配る（プッシュ）	範囲内	範囲内
Amazon EventBridge	イベントバス	多対多（ルールで振り分け）	一致したターゲットに送る	範囲内	範囲内
AWS Step Functions	ワークフロー	―	手順の順番・分岐・再試行を管理する	範囲内	範囲内
Amazon MQ	マネージドなメッセージブローカー	キューもトピックも	ActiveMQ・RabbitMQ のプロトコルで受け渡す	一覧に無し	範囲内
Amazon AppFlow	SaaS データ連携	SaaS ↔ AWS	フロー（オンデマンド・スケジュール・イベント）	範囲外	範囲内

クラウドおさる

弊猿なりにまとめると、「何対何か」「取りに行くか届けるか」「何で振り分けるか」の 3 つを順に考えれば、だいたい決まるのでござるな。

土肥

その通り！実務ではこれを組み合わせることも多いから、「どれか 1 つ」にこだわりすぎないのもポイントだよ。

—

新卒・未経験の方へ

AWS を仕事にしたい方へ ── 新卒・未経験から

この記事を書いているのは、AWS の設計・構築を仕事にしている現役エンジニアです。運営元の株式会社ジェニュインでは、新卒・未経験の方も募集しています。異業種や文系からインフラエンジニアになり活躍しているメンバーもいます。

✓システム開発・WEB エンジニア / インフラ構築などの職種で、未経験から応募できます
✓未経験から入社した社員の声を含む社員アンケートを掲載
✓応募フォームから 1 分で応募できます

採用ページを見る

実践

ハンズオンガイド4 ステップ画面 3 枚

コンソールの横に開いて、チェックしながら進めましょう。

ガイドを開く

別タブで開きます。チェックはこのブラウザに保存されます。

課金が発生しない範囲で、SQS・SNS・Amazon MQ のコンソールの作成画面を開き、技術解説で整理した選択肢が実際にどう並んでいるかを確認します。この実践ではリソースを作成しません。 各画面の最後にある作成ボタンを押す手前で画面を離れます。

前提条件

AWS マネジメントコンソールにログイン済みであること（SQS・SNS・Amazon MQ のコンソールを閲覧できる権限）
リージョンは ap-northeast-1（東京）を使用します
作成するリソースはありません。「キューを作成」「トピックの作成」「ブローカーを作成」などの最終の作成ボタンは押さないでください

手順 1: SQS のキューの種類を確認する

AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。

上部の検索バーに SQS と入力し、表示された「Simple Queue Service」を選択します。

右上の「キューを作成」をクリックします。

「詳細」の「タイプ」に、以下の 2 つが並んでいることを確認します。

標準（少なくとも 1 回の配信）
FIFO（送った順を守り、1 回だけ処理する）

SQS の「キューを作成」画面のタイプ選択（標準と FIFO が並んでいる状態）

続けて画面を下へスクロールし、「設定」に「可視性タイムアウト」「メッセージ保持期間」「メッセージ受信待機時間」などの項目が並んでいることを確認します。「メッセージ受信待機時間」が技術解説で触れたロングポーリングの待ち時間で、受け手が取りに行くプル型ならではの設定です。

確認が済んだら、画面下部の「キューを作成」は押さずに、ブラウザでこのページを離れます。

手順 2: SNS のトピックの種類と配信先を確認する

上部の検索バーに SNS と入力し、表示された「Simple Notification Service」を選択します。

左側ナビゲーションの「トピック」を選択し、右上の「トピックの作成」をクリックします。

「詳細」の「タイプ」に FIFO と スタンダード が並んでいることを確認します。SQS と同じく、順番を守る FIFO と、順番を問わない標準の 2 種類が用意されています。

SNS の「トピックの作成」画面のタイプ選択（FIFO とスタンダードが並んでいる状態）

確認が済んだら、画面下部の「トピックの作成」は押さずに、このページを離れます。

SNS で配信先（エンドポイント）を指定するのは、トピックを作った後の「サブスクリプション」です。技術解説の表のとおり、SQS・Lambda・HTTP/HTTPS・E メール・SMS などを配信先に選べます。

クラウドおさる

SQS の作成画面には「受信待機時間」のように受け手が取りに行くための設定があり、SNS は配り先を後から購読で足していく形でござった。プルとプッシュの違いが画面の項目にも出ているでござるな。

手順 3: Amazon MQ で選べるブローカーエンジンを確認する

上部の検索バーに MQ と入力し、表示された「Amazon MQ」を選択します。

ブローカーが 1 つも無い場合はサービスのトップページが表示されるので、「ブローカーの作成」の下にある「開始方法」をクリックします（ブローカーがある場合は、ブローカーの一覧で「ブローカーの作成」をクリックします）。

ステップ 1 の「ブローカーエンジンの選択」に、以下の 2 つが並んでいることを確認します。

RabbitMQ
Apache ActiveMQ

Amazon MQ の「ブローカーエンジンの選択」画面（RabbitMQ と Apache ActiveMQ が並んでいる状態）

SQS・SNS の作成画面と違い、Amazon MQ では既存のメッセージブローカーと同じエンジンを選ぶところから始まります。この先の画面ではブローカーのインスタンスタイプやデプロイモードを選びますが、ブローカーを作成すると課金が始まるため、ここで画面を離れます。

クラウドおさる

試験では「1 対 1 か 1 対多か」「既存のブローカーを移すのか」「SaaS のデータを運ぶのか」という観点で、SQS・SNS・EventBridge・MQ・AppFlow を選ばせることが多いでござる。SNS と EventBridge、SQS と MQ の取り違えには気をつけるでござる。

—

まとめ

選ぶ手がかり	選ぶサービス
受け手が自分のペースで取りに行く、1 対 1 の受け渡し	Amazon SQS
順番と重複防止が大事なキュー	Amazon SQS（FIFO キュー）
1 つのメッセージを複数の宛先・人に一斉に届ける	Amazon SNS
1 つの通知を複数のキューに配り、それぞれで後から処理する	SNS + SQS（ファンアウト）
AWS サービスや SaaS のイベントを中身で振り分ける	Amazon EventBridge（イベントバス）
決まった時刻・間隔で処理を動かす	Amazon EventBridge（EventBridge Scheduler）
手順の順番・分岐・並列・再試行を管理する	AWS Step Functions
既存の ActiveMQ・RabbitMQ を、コードを書き換えずにクラウドへ移す	Amazon MQ
Salesforce などの SaaS のデータを S3・Redshift に運ぶ	Amazon AppFlow

つなぐサービスは、送り手と受け手を切り離して非同期にやりとりさせ、片方の停止や混雑がもう片方に波及しないようにする
SQS は「1 対 1・プル」、SNS は「1 対多・プッシュ」、EventBridge は「ルールで振り分け」。届け方の違いで選ぶ
Step Functions はメッセージを運ぶのではなく、手順そのものを管理する
Amazon MQ は既存のメッセージブローカーの移行先。新しく作るならサーバーレスの SQS・SNS が候補になる
Amazon Elastic Transcoder は 2025 年 11 月 13 日にサポートを終了しており、移行先として AWS Elemental MediaConvert が案内されている

各サービスを実際に動かしてみたい場合は、Amazon SNS でトピックを作成しメッセージを配信すると AWS Step Functions でワークフローを定義し実行するで手順を解説しています。

—

参照先

キャリア相談

独学の先に、AWS の仕事がある ── ジュニアおさるのキャリア相談

CLF には受かったけれど、次に何をすればいいのか分からない。独学で AWS を学ぶジュニアおさるの相談に、株式会社ジェニュイン代表の土肥が答えています。

✓資格はゴールか、CLF の次に何から手を付けるか
✓EC2 の次に作ってみる構成と、IaC・コスト管理
✓実務経験ゼロでも、面接で話せる「これまで」の作り方

相談を読む

新卒・未経験の方へ

AWS を仕事にしたい方へ ── 新卒・未経験から

✓システム開発・WEB エンジニア / インフラ構築などの職種で、未経験から応募できます
✓未経験から入社した社員の声を含む社員アンケートを掲載
✓応募フォームから 1 分で応募できます

採用ページを見る

この記事が気に入ったら
フォローしてね！

Follow @osaru_cloud Follow Me

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

土肥康太郎

株式会社ジェニュイン（https://genuine-pt.jp)の代表取締役.

2018年〜インフラエンジニアとしてキャリアをスタートし、オンプレミスのネットワーク・サーバ環境で3年半、クラウド環境で4年半の8年間エンジニアとして従事。
2021年に佐藤氏の創業した株式会社Luxyを引き継ぎ、代表に就任。
その後アガルートグループ内の株式会社ジェニュインと合併。
合併後同社代表に就任。