はじめに
はじめまして、村尾と申します。
2026年1月にセーフィーへ入社し、気付けばもう5ヶ月が経ちました。
フロントエンドエンジニアとして、日々プロダクト開発に携わっています。
セーフィーに来る前は、愛知県のスタートアップで7年間、フルスタックエンジニアをしていました。
当時から AI には触れていましたが、ここに来てから景色が大きく変わったので、今回は新入社員の等身大の目線で、その変化について書いてみようと思います。
「セーフィーで実際 AI はどう使われているのか」が気になっている方の、雰囲気を掴むヒントになれば幸いです。
まず印象的だったのは「AI 活用に必要なツールが揃っていた」こと
入社して特にありがたかったのは、AI 関連のツールに会社がきちんと予算を付けてくれていた ことです。
たとえば、
- Figma の Dev シート（開発者向けの有償ライセンス）
- Claude のチーム契約
- Gemini
- Notion AI
これらのツールが「使ってよい」ではなく、最初から揃っている状態で入社できました。
前職では Figma が導入されておらず、AI ツールも GitHub Copilot のみという環境でした。
それ自体が悪いわけではありませんが、振り返ってみると 「AI を使え」と言うだけでなく「使うためのもの」が用意されている ことの効果は大きいと感じます。
ツールが揃っていないと、結局は個人の工夫に依存してしまいがちだからです。
その上で、社内では AI を活用したさまざまな取り組みが走っています。
ここでは代表的なものを3つ紹介します。
取り組み① プロトタイプ開発ワーキンググループ
セーフィーには 「プロトタイプ開発ワーキンググループ」 という社内の取り組みがあります。
開発本部のエンジニアが数名ずつのチームに分かれて、企画から実装までを一気通貫で行う活動で、Claude を活用して効率よくプロトタイプ開発を進める ことが特徴のひとつになっています。
少し前に第3回のレポートが Zenn に出ています。
そして私はいま、第4回に参加中 です。
ちょうどリーンキャンバスを埋めながら「何を作るか」を固めているフェーズです。
入社5ヶ月という時期に、こうした活動へ自然に手を挙げて参加できること自体、セーフィーの「迷ったときはやってみる」というカルチャーを体現していると感じます。
業務時間を割いてこうした活動に参加できる環境が用意されているのは、素直にありがたいと感じています。
取り組み② Claude Code ライブコーディング社内勉強会
開発本部では「生成AI活用推進プロジェクト」が走っており、その一環でClaude Code を使ったライブコーディングの社内勉強会 が開催されました。
2人のエンジニアが30分で実際のダッシュボードに2機能を実装してみせるデモ会で、私も当日リアルタイムで参加しました。
レポートはこちらです。
人によって AI との向き合い方や進め方が異なるのが印象的で、自分の取り組み方を振り返るきっかけになりました。
取り組み③ ランチ勉強会
セーフィーには ランチ勉強会 という、昼休みに集まって気軽に学ぶ場もあります。
テーマは毎回さまざまで、AI に関する回も定期的に開かれています。
業務時間の中で新しい技術に触れる導線が複数用意されている 点は、入社してはじめて実感できたセーフィーらしさのひとつでした。
強制ではなく、選択肢として用意されているのが特徴的だと感じます。
私の日々の開発スタイル
ここからは話を個人レベルに落とし、担当プロダクトと、そこで普段どのように開発を進めているかを紹介していきます。
担当しているのは「Safie Manager（セーフィー マネージャー）」
メインで担当しているのは Safie Manager（セーフィー マネージャー） というプロダクトです。
簡単に言えば、セーフィーのクラウドカメラと、それを使う人のアカウントを
一元管理するための Web アプリケーション です。
チーム単位でカメラへのアクセス権を制御したり、SSO・2段階認証・IP制限といったエンタープライズ向けのセキュリティ機能を備えていたりと、複数拠点・多人数でカメラを運用する企業のお客様に使われています。
プロダクトと独立して運用される「デザインシステム」
私の担当するフロントエンドは React のモノレポ構成 で、複数のアプリやパッケージが同居しています。
その中でもセーフィーに入って個人的にありがたかったのは、
プロダクトとは独立した形でデザインシステムが存在する ことでした。
複数のプロダクトをまたいで UI の一貫性を担保するための共通基盤です。
私は Manager の開発と並行して、デザインシステム側のコンポーネント改修にも携わっており、
プロダクト側とデザインシステム側を行き来するのが日常になっています。
プロダクトの片手間ではなく、独立した取り組みとして運用されている おかげで、
共通コンポーネントが整備された状態でプロダクト側の開発に取り組めるため、開発のしやすさに直結していると感じます。
このデザインシステムに AI を絡める話については、記事の後半で改めて触れます。
Claude Code を中心にした開発
普段の開発は、Claude Code を中心に据えて進めています。
多くの開発現場と同様に、扱う情報は複数のサービスにまたがっています。
- チケット管理: Backlog / GitHub Issues
- 仕様・ドキュメント: Notion
- デザイン: Figma
これらを MCP サーバーや CLI 経由で Claude Code から触れるように繋いで 開発しています。
たとえば、
- Backlog や GitHub のチケットを Claude に読ませて要件を整理する
- Figma MCP でデザインを参照しながらコンポーネント実装のたたきを書く
- Notion MCP で関連ドキュメントを引きに行く
- GitHub CLI 経由で PR の Draft 作成まで Claude に任せる
といった動かし方が日常になっています。
入社直後に効いたのは「既存コードを読む時間の短縮」
セーフィーはクラウドカメラを軸に複数のプロダクトを展開しており、把握すべきドメイン知識の幅が広いのが特徴です。
そのうえ、入社直後はドメイン知識はもとより既存コードベースの設計も頭に入っていない状態です。
「この関数はどこから呼ばれているのか」「この状態はどう流れているのか」を追いかけるのに、
新入社員は非常に多くの時間を使うものです。
ここで Claude には大いに助けられました。
- 改修チケットに着手する前に、関連ファイルを読ませて全体像を整理してもらう
- 知らない実装パターンに出会ったときに、コードベース内の類似実装を探してもらう
- 「この処理を変えたいが影響範囲はどこまでか」をコードベース全体に対して尋ねる
こうした使い方で、新入社員にとっての「コードを読む時間」を大きく短縮できた ことは、
入社初期にもっとも効果を感じた点かもしれません。
「分からなくて手が止まる」時間が明確に減りました。
実装は「壁打ち＆たたき生成」から入る
新しい機能やコンポーネントを書くときは、
仕様の整理 → 設計 → コードのたたき までを Claude と一緒に進めることが多いです。
ただし出てきたコードをそのまま採用することは少なく、プロジェクトの規約に合わせて自分で整えることを前提に組み立てています。
Claude のコードは「8割を書いてくれるパートナー」のような感覚で、残り2割の「プロジェクトに馴染ませる」部分は人間が担う、という分担です。
周辺作業も Claude に寄せている
実装そのものに加えて、
- コミットメッセージの整形
- PR 説明文のドラフト
- 進捗ログの記録（毎日の作業を Claude に書かせる仕組みを自作しました）
- タスクリストと GitHub / Backlog の同期
- 1日の振り返り（「今日終わり」と話しかけると一日分まとめてくれる）
中でも気に入っているのが 進捗ログの自動記録 です。
Stop hook（Claude Code のセッション終了時に発火するフック）を仕込んでおき、Python スクリプトでセッションの会話を投げて要約 → 日次の Markdown に追記する、という構成です。
設定側はこれだけ。
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "python3 ~/.claude/hooks/session-progress.py"
}
]
}
]
スクリプト側がやっていることは、
- セッションの会話ログを読み込む
- 2〜5行の箇条書きに要約させる
- 時刻つきでログを追記する
の3つだけです。
上で挙げた「1日の振り返り」もこのログを読みに行く形で動かしているので、ログさえ自動で溜まっていれば他はスキルで繋ぐだけ という構造に落ち着きました。
こうした周辺作業も、自作のスキルやサブエージェントを書いて Claude 側に寄せています。
ここを自動化できると、書きたいコードや考えたい設計に集中できる時間が伸び、体感としても効果が大きい部分です。
最近は「一気通貫」で任せることも増えてきた
最初のうちは、要件整理・実装・PR 作成といった工程ごとに区切って Claude を呼んでいました。
ですが最近は、軽微なタスクであれば
チケットを渡すだけで Draft の PR 作成まで一気に通してしまう ことも増えています。
たとえば、
- 「サイドメニューの文字の折り返し場所を制御できない」といった小規模な改修
- 「SelectBox のアイコンを少し縮小する」
- 「ラベル余白のデザイン差分修正」
このくらいの粒度であれば、最初から最後まで Claude に任せ、
私はレビューに集中するだけで成立することが多くなっています。
おそらくもっと大きな粒度でも成立するとは思うんですが、少しずつ試しながらやっていっている最中です。
さらに PR には GitHub Copilot の自動レビュー も入れています。
Claude が実装し、Copilot が一次レビューを入れ、最後に人が確認するという流れです。
工程を区切って使う段階から、目的を渡して結果を受け取る 段階へ、少しずつシフトしてきている感覚があります。
正直なところ、自分の手でコードを書く時間は減っており、少し寂しさを感じることもあります。
ただ、その分 設計や要件定義に使える時間が増えた 効果の方が大きく、
エンジニアとしては歓迎すべき変化だと考えています。
次にやりたいこと：デザインシステム用の MCP サーバーの構築
ここまで Claude を使った開発について書いてきましたが、
普段触っていて「ここはまだ改善の余地が大きい」と感じている部分もあります。
それは、Claude がセーフィーのデザインシステムを正確には把握していない ことです。
たとえば、
- 「ボタンを作って」と頼んだときに、デザインシステムにあるはずの共通コンポーネントを使わず、素の
<button>で書いてしまう - 似たコンポーネントが複数あるときに、どれを使うべきかを判断できない
- Props を勝手に推測して、実在しないプロパティを書いてしまう
出力されたコードを後から直す回数を減らしたい、という課題感が常にあります。
ここを デザインシステム用の MCP サーバー で解消したいと考えています。
コンポーネントの仕様・Props・使用例・「どんなときにどれを使うか」のガイドを
MCP 経由で Claude が直接参照できるようにし、
「デザインシステムを正しく使える AI」 に育てることを目指します。
これがうまく動けば、
- 新入社員でも、デザインシステムをすぐ正しく使えるようになる
- レビューでデザインシステム由来の指摘が減る
- デザイナーが意図したコンポーネントが、AI 経由でもきちんと選ばれる
といった効果が見込めるはずで、まだ構想段階ですが、近いうちに着手したいテーマです。
形になればまた Zenn でご報告します。
おわりに
セーフィーに入って5ヶ月、振り返ってみると、最初はあまり活用できていなかった AI でしたが、今はAI を業務に組み込むことが前提となっている環境 で働けていると実感します。
- AI 活用に必要なツールに、きちんと予算が付いている
- 全社的な取り組みも、現場のチケットも、AI を前提に動いている
- 新入社員でも、プロトタイプ開発 WG のような取り組みに自然に手を挙げて参加できる
そうした環境の中で、私自身も Claude を中心とした開発スタイルへ少しずつシフトしてきました。
そして次は、自分の関わっているデザインシステムを AI が正しく扱える状態をつくる ことに取り組んでいくつもりです。
「AI をきちんと業務に取り込んでいる会社で働いてみたい」
「デザインシステム × AI に興味がある」という方には、
セーフィーの開発環境はきっと魅力的に映ると思います。
気になった方は、ぜひ採用ページもご覧ください。
ここまで読んでいただき、ありがとうございました。
Discussion