こんにちは、アソビューの白井です。
これまでフロントエンドエンジニア兼スクラムマスターとして、プロダクト開発とチーム運営をしてきましたが、2026年4月に SRE チームへ異動することになりました。
今回は、畑違いの領域へ異動してから困ったこと、それを AI を利用してどう乗り越えていったかについて書いていこうと思います。
AI 時代のフロントエンドエンジニアとして、次の一手に迷っている方の参考になれば嬉しいです。
なぜ SRE へ
2026年3月、半年ほどやっていたプロジェクトが終わりチーム編成が変わるタイミングがありました。ちょうど Claude を使い始めていた時期で、使ってみると実装もほぼ任せられる状態で自分でコードを書くことは無くなってきており、自分はエンジニアとして今後どういう動きをすべきなのか...と悩むようになりました。
そこで、上長にも悩みを相談したところ「SRE にチャレンジしてみてはどうか？」と話を持ちかけられたのが始まりでした。
最終的に異動を決めたのは、以下の2つの理由です。
AI との知識差
スクラムマスターをしつつフロントエンドを深掘りしていく道も考えましたが、自分が深めたいと思っていた範囲は AI もすでにカバーし出していると感じ、その差は今後さらに広がっていくようにも思えました。しかし、最終的な意思決定をするのは人間。そして意思決定には、開発全体の仕組みまで含めた包括的な知識が必要だと思うようになりました。
自分の持ち味を活かす場所
今までアソビューではアプリケーション開発を3チームで経験していたので、様々なプロダクトに関わっていました。横断的な施策も多い SRE では、アプリチームにいた知見も活かせるのではないかと思いました。
また、フロントエンド出身の SRE メンバーは現時点ではいなかったので、SRE に移ることでプロダクトチーム・フロントエンドの目線で改善活動ができるのではないか、と考えました。
今後は一つのものを深めるよりも広げることが、自分にとってもプロダクトにとってもいい道になるはず、と考えて異動することにしました。
異動して大変だったこと
前提知識が足りない
まず、前提知識が圧倒的に足りませんでした。
AWS、Kubernetes、Nx、Argo CD、GitHub Actions ... どれもなんとなくの知識しかない状態。
設定一つとっても、何を意味するものなのか？これで何が変わるのか？調べるとまた分からないことが出てくる。なんだかエンジニアとして働き始めた時と似たような感覚でした。
フロントエンドの開発では、これらのレイヤーは「すでにそこにあるもの」で、普段そこまで意識していませんでしたが、それが自分で判断すべき対象に変わりました。
PR レビューで、何を見て何を指摘すべきか分からない
異動して最初に戸惑ったのが、Pull Request のレビューです。
プロダクトチームにいたころは、要件からなぜこの修正になってるのかが比較的分かりやすかったのですが、SRE ではそもそも何をしている修正なのか、なぜこのように修正されたのか、そこから紐解いていく必要がありました。
またプロダクトチームと比べて細かい修正が多く、PR の数も多い。1件ずつ「これは何だろう」と調べていくと、レビューだけで1日が終わってしまいます。
確認の観点が違う
アプリケーション開発では、基本的にはユニットテストと E2E テストが確認の中心でした。画面を操作して、期待どおりに動けば OK です。
一方、私が一部を担当することになった CI 移行（CircleCI から GitHub Actions への移行）で確認したいのは、「ビルドの実行基盤を変えても、出来上がるものが変わらないこと」です。そのため確認すべきは成果物であるコンテナイメージそのものになります。
仮に staging 環境で E2E を実行したとしても、設定ミスによっては production のみ問題が発生する可能性があります。
そのため、production のデプロイ前にコンテナイメージを確認し、意図した状態かを確認する必要がありました。
しかも対象は1プロダクトではありません。複数のプロダクトを順番に移行していくので、そのたびに同じ確認を繰り返すことになります。手作業でやりきるのはなかなか大変です。
どう向き合ったか
分からないことは、腹落ちするまで AI と掘る
まずやったのは、とにかく愚直に AI と対話することでした。
ポイントは、答えを1つもらって終わりにしないことです。返ってきた答えに対して、そういうものなんだ、ではなく「では、なぜここはこうなっているのか」と問いを重ねていきます。
「分かった気になる」で止めず、自分の言葉で説明できるところまでやります（AI は何度聞いても嫌な顔をしないので、遠慮なく聞けるのはありがたいですね）。
AI による PR レビューを定期実行して、下書きコメントを自分で確かめる
レビューの量と難しさに対しては、Claude Code に定期的にレビューを回してもらう形にしました。
やっていることはシンプルで、自分にレビュー依頼が来ている PR を列挙し、1件ずつレビュー観点を当てて、GitHub 上に pending（下書き）レビューとしてインラインコメントを残す、という手順を skill にしました。それを launchd で3時間おきに実行しています。
ここで大事にしたのは、下書きで止めること。
自分が PR を確認するときには、下書きコメントが並んでいます。それを1件ずつ読んで、
- 内容が分かるもの → 妥当か判断して、必要なら手を入れて Submit する
- 知らない話が出てきたもの → そこで初めて調べる。腹落ちしたら Submit する
- 的外れ・不要と判断したもの → 消す
という流れで処理します。
つまり、AI にやってもらったのは「レビューすること」ではなく「レビューすべき論点を先に洗い出しておくこと」です。判断は自分でします。「AI が言っているから」で Submit してしまうと、レビュアーとして機能しませんし、何より自分に何も残らず、次に活かせません。
この形にしてから、知らない領域の PR が「調べるきっかけ」に変わりました。論点が先に見えているぶん、どこを調べればいいかが明確なので、学習の効率も上がりました。
また、これにはレビューされる側のコストを下げるという目的もあります。
AI の生成する文章というのは、自分でルール化し調整していても分かりづらくなってしまうことがあります。完全自動レビュー投稿にしてしまうと、受け取り側が判断したり、読みづらい内容を理解する必要が出てきます。
そこをレビューする側が最終判断し「これはやっておいた方が良さそう」「これは問題なさそうだけどコメントだけ残しておきます」などと一言添えたり、読みづらい文章を修正・補足したりして、レビューされる側が対応しやすい状態を作ることも大事だなと感じています。
確認観点を skill にして、判断が必要なところだけ自分で確認する
実作業の CircleCI から GitHub Actions への移行の確認については、確認観点そのものを skill にしました。
やりたいことは「CircleCI で作ったコンテナイメージと、GitHub Actions で作ったコンテナイメージが同じか」の確認です。これを2段構えにしました。
まず、Amazon ECR に上がっている2つのコンテナイメージの digest（その内容から計算される識別子）を比べます。digest が一致していれば、中身は完全に同じです。そこで確認は終わりにできます。
一方で、digest が一致しないからといって中身が違うとは限りません。ビルド時刻など、成果物そのものとは関係のない情報の差でも digest は変わるからです。そのため、不一致だったときだけ、両方のコンテナイメージを取得して展開し、ファイルレベルで差分を取ります。
ここまでは毎回同じ手順なので、skill に任せています。自分がやるのはその先です。出てきた差分ファイルの一覧を見て、「これは環境変数のコミットハッシュが変わっただけだから問題ない」「これは中身が変わっているので調べる必要がある」を判断します。
実際、この確認で環境変数が staging のままになっているのを見つけたことがありました。気づかずに進んでいたら、障害につながっていた差分です。
この2段構えにしたことで、確認の大部分は digest 比較だけで終わり、自分の目と頭を使うのは本当に見るべき差分が出たときだけになりました。
skill にしたことで、次のプロダクトを移行するときは同じ手順がそのまま再現できます。手順を思い出すコストがなくなり、確認漏れも防げるようになりました。
※ 比較スクリプト自体は Claude に聞けばすぐ組めるので、ここでは載せていません。
空いた時間を学習に回す
PR レビューの定期実行も、確認観点の skill 化も、狙いは作業時間を削ることでした。そうして空いた時間を、最初に書いた「分からないことを AI と掘る」に回しています。
自動化の目的は「楽をすること」ではなく、「判断できるようになるための時間を作ること」です。レビューや方針判断は、知識がないとできません。作業に時間を取られていると、その知識を仕入れる時間がなくなります。
作業を減らす → 学ぶ時間ができる → 判断できる範囲が広がる → レビューや方針決めができるようになる。この順番で進めました。
AI に任せるもの、自分で持つもの
AI によって、学習のコストも作業のコストも確実に下がりました。任せようと思えば、かなりのところまで任せられます。
でも、任せきってしまうと、自分が判断できないままになります。
レビューコメントを読まずに Submit すれば、その PR で何が起きているかは分からないままです。コンテナイメージの差分を見ずに「差分なし」という結果だけ受け取っていたら、差分が出たときに判断できません。
今は、こういう線引きにしています。
- 手順が決まっているもの、繰り返しの作業は AI や skill に任せる
- 分からないことは深掘りして、判断材料となる知識を自分の中に蓄える
- AI が言ったからではなく、自分が理解したうえで判断する
知識がない領域ほど、AI の出力を鵜呑みにしたくなります。そこで踏みとどまって自分で確かめるかどうかが、4ヶ月後の自分の差になったと思っています。
まとめ
結果的に、異動して4ヶ月で GitHub Actions への移行作業、Java 共通ライブラリの作成・適用など、リリースまで持っていくことができました。
判断材料を自分に蓄えるほど、畑違いの領域でも自分で判断できる範囲は広がっていきます。AI で学習コストが下がった分、領域を越えるハードルは自分が思っていたより低かったと感じています。
とはいえ、まだまだ分からないことはたくさんあります。ただ、分からないことを分かるようにするサイクルは、AI のおかげでかなり速く回せます。越境を考えている方の背中を、少しでも押せたら嬉しいです。
最後に
アソビューでは、「生きるに、遊びを。」をミッションに、一緒に働く仲間を募集しています！
カジュアル面談のご希望も随時お受けしておりますので、お気軽にエントリーください！お待ちしております！
