author
authorDisplayName
Yasuyuki Matsumoto
category
Product
backend
frontend
ios
android
mainImage
published
published
publishedAt
Apr 24, 2026
slug
ai-dev-workstyle
tags
AI
frontend
backend
Android
ℹ️ はじめに
こんにちは。令和トラベルでエンジニアをしている松本（@ya2s_x）です。
最近、「AIで開発が変わった」と言われることが増えました。
でも実際のところ、何がどう変わったのかは、少し見えにくい気がしています。
コードを書く時間が減ったのか。
設計のしかたが変わったのか。
レビューは楽になったのか、それとも別のところが詰まり始めたのか。
“AIを使っている”の中身は、現場によってかなり違うはずです。
そこで今回は、社内の6人のエンジニアに、いまどんな開発環境で仕事をしているのかを聞いてみました。
通勤中にDevinで調査を進める人。terminalの中で複数のClaude Codeを並列に走らせる人。仕様を先にAIと詰めてから実装に入る人。話を聞いていると、それぞれのやり方は違うのに、確かに同じ変化の中にいることが見えてきます。
この記事では、そうした6人の働き方を手がかりにしながら、AI時代の開発環境で何が前に出て、何が後ろに下がったのかを見ていきます👀
🏃♂️ 今回登場する6人のエンジニア
アプリのテックリード
- Android Studio / Xcode を使いつつ、実装はCLI中心
- 調査や相談はブラウザから
- Claude Code、Gemini CLI、Devin を使い分ける
- 「一日中AIを使っている感覚」
バックエンド + SRE寄りのエンジニア
- ConductorからClaude Codeを中心に使う
- SlackからIssueを切り、設計、実装、PR、CI修正までつなぐ
- 必要に応じてCodexやDevinも使う
terminal中心のバックエンドエンジニア
- Ghostty、Neovim、zellij が中心
- 左にエディタ、右にClaude Code
- さらに複数paneでAIを並列実行
フロントエンド中心、一部バックエンドも見るエンジニア
Superset.sh、VS Code、Claude Code / Codex、Devinを使い分ける
- 通勤中にDevinで調査や小実装を進める
- 手元では要件整理や設計判断に集中
AI活用が組織にどう効くかまで見ているエンジニア
- コーディングの時間が減り、要件や仕様定義に時間を使う
- エンジニアの役割分担やPMとの関係まで変わっていると感じている
LLMアプリケーション開発を担うエンジニア
- VS Code + Claude Code CLI がメイン
- Claude Desktop、Codex CLI、Gemini CLIも用途別に併用
- cmuxでターミナルを管理
- 実装・調査・レビューだけでなく、デプロイやQA自動化、AI回答品質のスコアリングまで仕組み化
使っているツールは違っても、共通していたのは、AIがもう“たまに呼ぶ存在”ではないことでした。
常に横にいる。ときには自分より先に調べている。そんな距離感です。
🧑💻 AIに任せているのは、コードだけではなかった
6人の話を聞いていると、AIに任せているのは単なる実装だけではありませんでした。
むしろ実装の前にある整理や設計に深く使われていることです。
たとえば、こんな使い方です。
- Spec、Figma、API仕様、Slackをまとめて読ませて、詳細仕様を起こす
- Issueから spec_xxx.md を作り、その後 plan_xxx.md に落とす
- 調査 → プラン → fix → レビュー → レビューfix まで一連で依頼する
- 方針が50%ほど固まった段階で、実作業をAIに委譲する
「新しい設計や技術を導入するときは、『忖度なしで意見ください』と壁打ちする」
アプリ開発のテックリードは、Spec、Figma、API仕様、SlackをまとめてAIに読ませ、詳細仕様の作成からコーディングまで進めていました。レビューでも /code-review や /pr-review-toolkit を使い、観点洗い出しを支援させているそうです。
terminal中心のエンジニアは、Issueができたらまず
spec_xxx.md を作らせると言います。この段階では実装詳細には入らず、要件や影響範囲、エラーハンドリングを詰める。そのあと plan_xxx.md を作り、ようやく実装に進む。AIにいきなりコードを書かせるのではなく、仕様と計画を先に積む進め方です。フロントエンド中心のエンジニアは、設計がある程度見えているタスクをAIに委譲し、自分は最終的な設計判断やレビューに集中していました。逆に、設計が固まっていないものは手元のClaude / Codex や Devin の Ask / Plan で壁打ちしてから進めるそうです。
LLMアプリケーション開発を担うエンジニアは、ここをさらに一歩進めていました。
本番デプロイはSlackコマンドひとつでエージェントが完結。コードレビューはCIに組み込み、QAテストはブラウザ操作を自動化し、AIの回答品質は自動スコアリングで数値化する。ここまで来ると、AIは実装支援というより開発システムの一部です。
「どうコードを書かせるか」より、「どう仕様を整えるか」。
いまのAI活用は、そこに重心が移っているように見えました。
✨ コードを書く時間は減り、そのぶん別の仕事が増えた
6人とも温度差はありつつ、仕事の重心が「書くこと」から「定義すること」に寄っていました。
ほとんど手を動かさなくなった人
アプリのテックリードは、ドキュメント作成やコーディングでは、ほとんど自分自身で手を動かさなくなったと話します。
AI導入前とは比べられないくらい速く開発でき、並列化もしやすくなったそうです。
コードを書く楽しさの変化を感じた人
Conductorを使うエンジニアは、「コードを書かなくなった」とかなりはっきり答えていました。
その一方で、コードを書く楽しさを失った感覚もあり、あえてNeovimに入門したという話も印象に残りました。
「コードを書かなくなった。良くも悪くもコードを書く楽しさを奪われた感はあった」
もともと設計が重かった人
フロントエンド中心のエンジニアは、要件整理・設計のウェイトが50%ほど。
要件をどう設計に落とし込むか、どの粒度で責務を切るか、将来の変更に耐えられるか。そうした上流判断に時間を使っています。
実装より、環境設計とレビューに時間を使う人
LLMアプリケーション開発のエンジニアは、「エージェントを使って開発する」から「エージェントがデプロイまで行う」段階に来たことが大きいと話していました。
コードを書く時間よりも、エージェントが安全に動くための環境設計と、出力のレビューに時間を使うようになったそうです。
減ったのは“仕事”ではなく、コードを書くという工程でした。
その代わり、要件整理、設計、依頼の粒度調整、レビューが前に出てきています。
📝 速くなったのは、実装よりむしろ調査と判断かもしれない
AI導入の効果として、実装スピードの向上はもちろん大きいです。
ただ、今回の回答ではそれ以上に、調査や判断の速さが何度も出てきました。
速くなったものを挙げると、たとえばこんな感じです。
- 初期実装
- ボイラープレート作成
- CI修正
- PR作成
- Issue起票
- 調査タスク
- 技術選定や方針比較のための情報整理
「判断を下すために必要な情報収集が楽になりました」
LLMアプリケーション開発のエンジニアは、複数エージェントを並列で動かすとコンフリクトが起きやすいので、タスク分割の粒度設計に気を使うと話していました。また、「AIが自信満々に間違える」ことへの対処は常に必要で、出力をそのまま信用しない習慣は手放せないとも言います。
あるエンジニアは、複数リポジトリの過去1週間のPRから「知っておくと得する学び」をまとめたレポートを、Claude Codeのschedulerで自動生成していると言います。フルスタックで動く中で、全部の変更を追い切るのは難しい。そのレポートが、他のメンバーの活動から学ぶ助けになっているそうです。
フロントエンド中心のエンジニアも、特に調査タスクで恩恵を感じていました。自分より詳しく、しかも最新の情報まで整理してくれるので、技術選定や実装方針の比較がかなり速くなったと話しています。
アプリのテックリードも、新しい技術や設計に対して、いろいろな方法や観点を試しやすくなり、速く、うまい結論が出せるようになったと言います。
AIは“手”の代わりというより、考える前の整理を引き受ける存在になっている。そんな印象が残りました。
⚠️ 速くなったぶん、粗くもなりやすい
一方で、全員が楽観しているわけでもありませんでした。
AIで仕事が速くなったぶん、新しいボトルネックや粗さも出てきています。
たとえば、こんな話があります。
- タスク依頼やレビュー、動作確認で人間側が詰まる
- review側がボトルネックになりつつある
- AIが「終わった」と言っても、一部しか終わっていないことがある
- 一般論に流されて、そのリポジトリ固有の事情が抜ける
- 並列化が進むほど、1件あたりの詰めは薄くなりやすい
アプリのテックリードは、自分がタスク依頼やレビュー、動作確認でボトルネックになっていて、うまく並列化できていないと感じています。特にアプリ開発ではまだ手動確認が必要な部分も多いそうです。
terminal中心のエンジニアは、コードを書くスピードが上がったことで、review側がボトルネックになりつつあると話します。
Conductor中心のエンジニアは、複数依頼の取りこぼしを課題に挙げていました。
「終わったというメッセージを信じて次に行くと、実は一つ目しか終わってなかった、みたいなことがある」
フロントエンド中心のエンジニアは、以前より同時並行で多くの案件を進めるようになった一方、品質の作り込みは意識しないと落ちやすいと話していました。
AIで速くなることと、品質が自然に上がることは別です。
むしろ、速くなるほど品質設計が必要になるのかもしれません。
🤖 それでもAIレビューはかなり強い
前の章では粗さの話が出てきましたが、同時に、AIレビューの強さもかなり実感されていました。
良くなったこと
- 実装漏れが減る
- 観点の洗い出しが網羅的になる
- 自分では思いつかない実装方法が出てくる
- 今まで気づかなかった不具合を見つけられる
- 修正の往復が速い
悪くなりやすいこと
- deprecatedなパターンに引っ張られる
- スコープ外の変更をしようとする
- 一般論を押し付けてくる
- 目的からズレた修正を始めることがある
「AIのレビューの精度がもう人を越えてしまった」
LLMアプリケーション開発のエンジニアは、AIの回答品質を定量的に計測できるようになり、問題の検知からアラートまで自動化ループを整備できたことを大きな前進として挙げていました。一方で、AIが生成したコードはプロジェクト固有の文脈から外れやすく、specファイルを常に最新に保つ運用が必要だとも言います。
アプリのテックリードは、自分なら思いつかなかった方法で実装できたり、実装漏れが減ったりしたと言います。
terminal中心のエンジニアは、観点の洗い出しや設計選択肢の比較が良くなった一方、ノイズもあると見ています。
フロントエンド中心のエンジニアは、AIレビューの精度はもう人を越えてしまった、とまで表現していました。
局所品質や網羅性はAIが強い。でも、全体設計や責務分離、長期保守性は人間が見続ける必要がある。
この役割分担はかなり見えてきました。
💫 うまく使っている人ほど、プロンプトより前を整えている
6人の話を聞いていて、うまい人ほど気にしているのはプロンプトの言い回しというより、その前提となる環境でした。
やっていることを並べると、こんな感じです。
- IssueにSpecやFigmaなど必要なリンクをまとめる
- promptに貼るのではなく、SkillやMCP経由で一次情報にアクセスさせる
- 繰り返し作業や好みをskill / rule / Memoryに蓄積する
- PR説明や仕様を書いて背景・目的・制約を明示する
- 決定論的な処理はscriptやpluginに切り出す
「単に『これを直してほしい』と伝えるより、背景、目的、制約、変更したくない箇所、期待するアウトプットを明示したほうが、実装精度の一貫性もレビューの精度も上がる」
アプリのテックリードは、IssueにSpecやFigmaなど必要なリンクをまとめ、それをAIに読ませる形を取っています。
terminal中心のエンジニアは、promptに必要情報を全部載せるのではなく、SkillやMCP経由でAIが一次情報にアクセスできるようにしています。
Conductorのエンジニアは、繰り返し作業や類似パターンをskillやruleに書き、細かい好みはMemoryに保存するようにしているそうです。
うまくいっている人たちはみんな、会話の前にコンテキストの置き方を設計しているように見えました。
🔒 セキュリティも、「気をつける」から「そうなっている」へ
安全性への向き合い方も、かなり実務的でした。
基本として守っていること
- 個人情報や機密情報を流さない
- API key や secret を prompt に貼らない
- 許可されたAIエージェントだけを使う
- 利用規約やプライバシーポリシーを理解して使う
さらに踏み込んだ工夫
- 権限レベルでAIが見られる範囲を制限する
- 余計なライブラリをAIに使わせない
- promptで抑えるのではなく、そもそもできないようにする
LLMアプリケーション開発のエンジニアは、「個人の注意」より「仕組みで防ぐ」を優先していると話していました。事故が起きたら即日で再発防止のワークフローを入れる、というスタンスです。
terminal中心のエンジニアは、AIができることを権限レベルで制限するようにしていると言います。たとえばDBやBigQueryのログを見せる場合でも、promptで制限するのではなく、DBユーザーやサービスアカウントの権限そのものを絞る。
フロントエンド中心のエンジニアは、社内で許可されたAIエージェントだけを使い、余計なライブラリを使わせないことも意識しているそうです。
「気をつける」だけではなく、安全な枠組みを先に作る。
この考え方は今後さらに重要になりそうです。
👥 チーム開発では、コードより仕様や説明が重くなっている
チーム開発の変化も、それぞれ少し違う角度から語られていました。
起きていたこと
- コードレビューが細部より設計寄りになる
- PRDやSpec、設計書を先に作ってから開発する
- rulesやagent docsが整備される
- PR説明や仕様を書くことの重要性が上がる
- 「書く」より「情報を集めておく」意識が強くなる
アプリのテックリードは、コードレビューで細かなところより、仕様や設計が負債になりづらいかを見るようになったと言います。UIレイアウト実装などは以前ほど見なくなったそうです。
Conductor中心のエンジニアは、選択肢が複数あるものについては、先にPRDやSpec、設計書を作ってレビューしてから開発する流れになったと話していました。
フロントエンド中心のエンジニアは、「なぜその変更をするのか」「どの前提で判断したのか」を文章で残すことが以前より重要になっていると話していました。
LLMアプリケーション開発のエンジニアは、コードレビューをリスクベース化し、コアロジックは必ずエンジニアがレビューし、低リスクな変更はQAに任せて人間レビューを省略できるようにしていました。ドキュメントも「書くもの」ではなく、「AIと一緒に維持するもの」に変わってきているそうです。
さらに大きいのは、ノンエンジニアのメンバーがAIを使ってページ実装を自力でできるようになったことでした。CxO、セールス、マーケまで含めてAI活用の研修を実施し、全社共通基盤を整えている。
ここまで来ると、「エンジニアだけが開発する」という前提そのものが揺らぎ始めています。
💭 これから人間に残るのは、「何を作るか」を決める仕事
最後に、今後重要になるスキルについて聞くと、向いている先はかなり似ていました。
出てきたキーワード
- 言語化
- 抽象化
- 引き算
- 作らないことを考える力
- 全体を把握して判断する力
- 企画力
- 推進力
- 事業や市場を理解する力
「今、自分がこの事業をやるべきだと信じられるか」
LLMアプリケーション開発のエンジニアは、「AIに何を渡すか」を設計する力が重要だと話していました。プロンプトというより、コンテキスト設計・タスク分割・出力検証のサイクルを回せるかどうかが差になる。コードを書く速さよりも、何を作るべきか判断する力と、AIの出力を正しく評価できる審美眼のほうが重要になると。
アプリのテックリードは、メイン領域以外も解ける範囲を広げる必要がある一方で、言語化や抽象化、引き算や「作らないこと」を考える力はこれまで以上に必要になると話します。
Conductorのエンジニアは、少し大きな視点で、「今、自分がこの事業をやるべきだと信じられるか」が重要だと言っていました。市場や競合、技術、AI活用を含めて総動員しないと、自分たちがなぜ今それをやるのかを説明できない、という考えです。
terminal中心のエンジニアは、AIがさらに賢くなれば、一人が見る範囲がもっと広がるはずだと考えています。そのとき必要なのは、全体を把握して技術判断できる力だと。
フロントエンド中心のエンジニアは、プロダクトの方向性を定める力、企画力、推進力がより重要になると答えていました。
実装そのものが委譲しやすくなるほど、何を作るかを決める力の価値は、むしろ上がっていくのだと思います。
おわりに
今回話を聞いた6人は、使っている道具も、担当している領域も、AIとの距離感も少しずつ違っていました。
でも共通していたのは、AIがもう“未来の話”ではなく、日々の仕事の中に入っていることです。
- Specを先に起こしてから実装する
- 通勤中に調査を進める
- 複数のAIセッションを並列で回す
- レビューは細部より設計を重く見る
- コードを書く時間が減り、そのぶん仕様や意図を書く時間が増える
- デプロイやQA、品質監視までエージェントが担い始める
- ノンエンジニアも同じAI基盤で開発に参加し始める
そう考えると、いま開発環境で起きている変化は、単なるツールの置き換えではありません。
人間がどこで価値を出すかが、少しずつ変わってきているのだと思います。
でも、だからこそ人間には、前よりずっと「何を作るのか」を決める責任が残っていると考えられます。
令和トラベルでは一緒に働く仲間を募集しています
この記事を読んで会社やプロダクトについて興味を持ってくれた方は、ぜひご連絡お待ちしています！お気軽にお問い合わせください！
フランクに話だけでも聞きたいという方は、カジュアル面談も実施できますので、お気軽にお声がけください。
それでは次回のブログもお楽しみに！Have a nice trip ✈️
