技術的負債と、AIと、これからの基盤づくり―アクルのインフラが向き合っていること

こんにちは！株式会社アクルの採用担当です。

アクルが提供する不正検知・認証プラットフォーム「ASUKA」※は、現在、45,000サイトに導入されています。このインフラを担っているのが、インフラエンジニアの鍋島さんです。

45,000サイトという数字は、インフラとして見れば「中規模」です。ただ、決済に関わる以上、止めるわけにはいきません。 インフラ領域の担当としてはまだ1人ですが、これから体制を強化していくタイミングにあります。EC2からECS（Fargate）への移行、TerraformによるIaCの推進など、いままさに仕組みを作り替えている最中のリアルを聞きました。

※「ASUKA」について詳しくは、こちらの記事をご覧ください。

鍋島さん｜インフラエンジニア。決済業界未経験で4年前にアクルに入社。 ASUKAのインフラ設計・構築・運用を担当し、現在はEC2からECS（Fargate）への移行やTerraformによるIaC推進を進めている。

主な技術スタック
AWS（ECS/Fargate、EC2、Aurora、Lambda、API Gateway、WAFなど）、Terraform、Datadog/CloudWatch、GitHub Actions、Rails/PostgreSQL、Claude Code

「自由」だけでは言い表せない働き方

――まず、鍋島さんが今どんな業務を担当しているか教えてください。

鍋島：ASUKAのインフラの構築・運用を任されています。インフラチームというと聞こえはいいのですが、インフラ領域の担当としては、今のところ1人です。ただ、これから体制を作っていく段階なので、最終的には他のエンジニアメンバーとも協力しながら、会社として必要なインフラを作っている、という感覚です。

――ASUKAは45,000サイトに導入されていると伺いました。インフラから見て、これはどのくらいの規模感ですか。

鍋島：規模感としては、中規模くらいだと捉えています。大規模な会社だと、スケールが100倍くらい変わってくると思うので、そう考えると、学習しながら本番の業務経験を積むにはちょうどいいサイズだと感じています。

――1日の流れを教えてください。

鍋島：最近は新しい仕組みの構築が中心です。自分の新規構築案件を持ちながら、他のメンバーが新機能を開発する際のインフラ部分のヘルプもしています。定常的な運用、たとえばアラートの調査といった対応は、AIにかなり任せられるようになったので、以前より時間はかなり減っています。

アクルはフレックスタイム制（コアタイムは11時〜15時）を採用しています。私自身は朝6時頃から働き始めて、15時を過ぎたあたりで一区切りつけることが多いのですが、これは私個人の働き方の一例です。コアタイムの範囲内であれば、それぞれのペースで進め方を組み立てられます。

日々の業務連絡はSlackでのやり取りが中心で、進捗確認は週1回の1on1で行っています。厳格なスクラムのような運用はしておらず、会議は最小限に抑えて、それぞれが自分でタスクを組み立てて進めるスタイルです。

――一見、時間の使い方はかなり自由に見えますね。

鍋島：そこは、「自由」という言葉だけで片づけてしまうと、少し実態とのギャップがあるかもしれません。オンコール対応があるので、アラートが鳴ったら気づけるように、スマホは手元に置くようにしています。時間の使い方は柔軟ですが、その裏側には「サービスを止めない」責任がセットになっている、というのが正確なところだと思います。

――過去3年間、夜間・休日の呼び出し実績がないとのことですが、実際はどうなのでしょうか。

鍋島：1番重いレベルのアラートについては、自動架電によるエスカレーション体制が組まれています。そのレベルでは、過去3年間、夜間・休日に呼び出された実績はありません。これは「たまたま鳴っていない」のと「鳴らないように作ってきた」のと、両方が理由だと思っています。AWS側で問題が起きる確率がゼロではない以上、そこは完全にコントロールできるわけではありません。ただ、防げる部分については対応してきた結果でもあります。

鳴ったときのために、インシデントの手順書やエスカレーションの手順は用意されています。会社全体で用意されているものに加えて、過去に実際にあった障害の対応記録も蓄積されています。

――オンコールの体制について、もう少し詳しく教えてください。

鍋島：当番制で順番に対応する、という形ではなく、自動架電によるエスカレーション体制を組んでいます。新しく入る方がすぐにオンコールに入るわけではなく、業務を任せられると判断したタイミングから参加してもらう形にしています。あと、これまでは障害が起きたときにサーバーに入って再起動する、という対応も一部あったのですが、コンテナ化を進めていく中で、そういう対応自体をなくしていく方向で進めています。

積み上がった技術的負債を、いま塗り替える

――EC2からECS（Fargate）への移行を進めているそうですね。なぜこのタイミングなのでしょうか。

鍋島：ASUKAは、私が入社する前から動いているプラットフォームです。当時の技術的な制約の中で作られたもので、サービスが大きくなるにつれて、技術的な負債として積み重なってきた部分があります。今は、そこを新しい基盤に入れ替えて、これからの拡大に耐えられるようにしている段階です。

新しい機能自体は新しい仕組みの上で作られているので問題はないのですが、機能がどんどん増えていく中で、土台側のインフラを新しくしないと苦しくなってくる、というのが実態に近い言い方だと思います。

――これから、具体的にどんなテーマに取り組んでいく予定ですか。

鍋島：SLOやエラーバジェットの設計、監視・アラート設計の見直し、Terraformの標準化、データベースの継続的な更新、負荷試験環境の整備など、決めなければいけないことはまだたくさん残っています。完成した環境を運用する、という感じではなく、こうしたテーマの一つひとつに、自分の判断で関われる状態です。

「AIが決める」時代に、自分は何を決めるのか

――事業会社のインフラを見るというのは、これまでSIerやSESで働いてきた方にとって、どんな違いがありますか。

鍋島：一番大きいのは、100%自社サービスのインフラに、継続的に関われることだと思います。案件ごとに環境が変わるSIerやSESの仕事とは違って、同じ基盤を長く見続けられるので、自分が手を入れた結果がそのまま次の設計にもつながっていきます。

――入社してまず何に着手してもらうことになりますか。

鍋島：目安としては、最初の3か月くらいで環境やドキュメントを把握してもらいつつ、AWSからの対応通知やIAM権限の付与、コスト監視、脆弱性診断の一次対応といった、定常運用の引き継ぎを進めてもらいます。障害調査にも並走してもらう形です。4か月目以降からオンコールにも参加してもらって、1年後を目安に、さっき話したようなテーマのどれか一つを、自分がオーナーとして推進できている状態になっていてほしいと思っています。

――「オーナーとして推進する」というのは、具体的にはどんなイメージですか。

鍋島：自立して動けている状態です。社内では、事業企画側からアプリケーションだけでなくインフラを含めた対応の要望が来ることがあります。そうした要望に対して、自律的に対応を進めていける状態になっていてほしいと思っています。

――技術選定は、実際どうやって決まりますか。少人数だと関われる場面も多そうです。

鍋島：今はマネージャーの太田さんと相談しながら決めています。意見が分かれることはあまりなく、話し合って最後は納得できる形にしています。最近はAIの提案を参考にすることも増えました。ただ、AIの提案をそのまま信じるわけではなく、前提が実際の状況に合っているかどうかを確認しながら判断する、というのが実際のところです。会社としてClaude（Claude Code含む）を導入していて、エンジニアだけでなくビジネス側のメンバーも使っています。インフラの領域でも、Terraformのコード生成やアラート調査などで活用していて、そうした流れの中で技術選定の仕方も変わってきています。

――新しい技術に触れられる環境については、どう感じていますか。

鍋島：やりたいことをやらせてもらえる、という点は大きいと思います。新しい技術や外部のツールを試すための予算も出ますし、AIも含めて新しいものをすぐ試せる環境です。加えて、インフラという領域に関わる以上、実際に世の中でビジネスとして使われているサービスの規模を、実態として経験できるというのも大きいと思います。

――インフラとアプリケーションの境界について、意識していることはありますか。

鍋島：あまり厳密に分けないようにしています。アプリ側の担当者もTerraformで新しい環境を構築することがありますし、逆にインフラから入った人がアプリケーションのコードを触ることも歓迎しています。領域を限定しすぎない方が、結果的にサービス全体の改善につながると思っています。

決済を知らないまま、決済の会社に飛び込んだ

――鍋島さんは、決済業界の経験がないまま、スカウト経由でアクルに入社されたそうですね。当時、不安はありませんでしたか。

鍋島：正直、最初の段階ではあまりありませんでした。自分が担当するインフラの非機能要件（可用性や性能、セキュリティなど）を実現するうえで、決済の基本的な知識が最初から必須というわけではなかったからです。

ただ、その後は違いました。社内の会話についていくためには、決済に関する知識が必要になる場面が出てきます。判断に関わる場面でその機能自体を理解していないといけない、ということもあって、その都度勉強する必要がありました。

――キャッチアップには、どのくらい時間がかかりましたか。

鍋島：すぐに、というわけではなく、必要になったタイミングでその都度キャッチアップしていく形でしたが、そうした中で全体像がつかめてくるまでには、2〜3週間くらいかかった感覚があります。本を読んだこともありますが、正直あまり役に立った記憶はなくて。それよりも、社内のログや資料を読み込んで、わからない単語が出てきたら調べる、というやり方の方が身についた感覚があります。私が入社したときも、クレジット研修や商品研修はあったのですが、内容は今の方がアップデートされていて、当時より立ち上がりやすいと思います。AIと社内資料を組み合わせれば、さらにキャッチアップはしやすくなっていると思います。

――リモートワークの中で、社内のコミュニケーションはどのように成り立っていますか。

鍋島：業務のやり取りが多いのはマネージャーの太田さんが中心で、部署をまたいだ定例のミーティングは、今のところ多くありません。ただ、筋トレ部※1に参加しているので、代表も含めて、業務では接点のないメンバーと話せる機会になっています。年に2回ある「Akuru ALL CONNECT」※2も、部署や役職を越えて色々な人と話せるので、そういう場は大事にしたいと思っています。

※1筋トレ部について詳しくはこちらの記事をご覧ください。

※2「Akuru ALL CONNECT」について詳しくはこちらの記事をご覧ください 。

アクルには、こうした部活動や、年2回開催される全社総会「Akuru ALL CONNECT」もあり、部署や役職を越えて交流できる場になっています。

↑ 筋トレ部プロジェクトの締めくくり、フィナーレイベントであるスパルタンレースに参加したメンバー

――どんな人と働きたいですか。

鍋島：運用を仕組みで改善することが好きな方です。具体的に言うと、繰り返し発生する作業を自動化できる人ですね。目安として、同じことを3〜4回くらい繰り返すようであれば、それは自動化していい、という基準で考えています。自分だけでなく、チームの複数人に関わるような箇所を見つけて改善してくれる人だと、なお良いと思っています。

あとは、自律的に動ける人。逆に、指示されたことだけをこなす、受け身の姿勢だと合わないと思います。

――必須スキルとしてクラウドインフラ(AWS、GCP、Azureなど )での設計・構築・運用経験があがっていますが、それ以外に重視していることはありますか。

鍋島：TerraformやECS、SREとしての経験は必須にしていません。クラウド環境での設計〜運用経験があれば、コンテナやIaCは入社後にキャッチアップしてもらう前提です。EC2中心の経験からコンテナやIaCに広げていきたい方や、アプリ開発など他分野からインフラに転向したい方も歓迎しています。ただ、設計を一度もしたことがない、という方だと難しいかもしれません。あとは、難しい障害にぶつかったとき、最後まで向き合って対応をやり切った経験があると、心強いなと思います。

完成されていないからこそ、託せることがある

――完成された環境ではなく、これから作るフェーズ。その面白さはどこにあると思いますか。

鍋島：経験を積むという意味では、裁量が大きいことだと思います。新しいことをやるための自由度があって、新しいサービスや、AIのような新しい外部ツールもすぐに試せる環境です。予算も出るので、成長という意味では、かなりおすすめできる環境だと思っています。

完成された基盤を運用するのではなく、まだ整っていない仕組みを、自分の手で形にしていく。オンコールの実態も、裁量の大きさも、鍋島さんは飾らずに話してくれました。

そこに面白さを感じられるかどうかが、この仕事に合うかどうかの分かれ目かもしれません。アクルのインフラを、鍋島さんと一緒につくっていきたい。そう思った方は、まずはカジュアルにお話できればうれしいです。