
みなさんこんにちは!プロダクト開発グループの山崎です。 以前、こちらの記事でご紹介した「システム改善チーム」に所属しています。
弊社では、日々の業務へのAI導入を積極的に推進しています。一般的に「AI駆動開発」というと、新規機能実装のリードタイム短縮にフォーカスされがちですが、カスタマーサポートからの問い合わせ対応や、既存プロダクトの運用保守・バグ修正を主軸とする私のチームにおいても、AIの活用は業務プロセスの最適化に多大な効果をもたらしています。
弊社では、課題チケットの管理にヌーラボ社の「Backlog」を利用しています。本記事では、このBacklogを経由した問い合わせ対応や日々の運用改善タスクにおいて、3つの主要AIツール(Claude Code/ Devin / GitHub Copilot)をどう適材適所で使い分けているか、私個人の実務をベースにご紹介します。
また、「コスト・生産性・中長期的な運用保守のバランス」という観点から、AI導入による業務フローの変化と課題についても触れていきます。
1. 問い合わせ対応におけるAIツールの使い分けと現在地
サポートチームからBacklogにチケットが起票された際、各AIツールをどのように活用しているかをまとめました。 以前は自律型AIである「Devin」を機能ごとに使い分けていましたが、今現在はコスト面などを考慮し、主にClaudeを利用する形へとシフトしています。
問い合わせ対応における各AIツールの役割と使い分け
- Devin
- 主な用途: 調査、複数ファイルの網羅的な修正、定型作業の自動化
- 利用機能:
Ask(事象調査や仕様把握)、Playbooks(デプロイ作業等) - 現在の立ち位置: 自律的な課題解決能力は極めて高いものの、運用コストがかさむため、アクティブ作業時間を消費する大規模な実装(
Session機能)での利用は縮小傾向にあります。
- Claude(Claude Code)
- 主な用途: 調査、複数ファイルの網羅的な修正、(定型作業の自動化)
- 利用機能: ローカル環境(CLI)での対話型コード修正、
Skills(※DevinのPlaybooksからの移行を検討中) - 現在の立ち位置: コストパフォーマンスに非常に優れており、現在のフローにおける「調査・実装フェーズ」の主力ツールとして利用しています。
- GitHub Copilot
- 主な用途: 既存ロジックの微修正、テストコードの補完
- 利用機能: エディタ上でのリアルタイムなインラインコード補完
- 現在の立ち位置: 局所的なサポートに限定して活用しています。
所感:DevinとClaudeの「自律性」の違いについて
過去に実施した「ライブラリのバージョンアップタスク」における両者の挙動の比較です。
- Devin(Session機能)の場合
- 同一の指示に対し、依存関係エラーの解析・解消から全CIチェックの通過に至るまで、人間の介入なしに完遂した。
- Claudeの場合
- バージョンアップの基本手順自体は実行可能。
- ただし、複雑な依存関係エラーが発生した際、エラーの解析と解消に至らず、プロセスが停止(人間の介入が必要)するケースが見られた。
利用コストの観点からClaudeへのシフトを進めていますが、予期せぬエラーへの対応力や、タスクを最後まで自律的に完了させる「課題解決能力」においては、Devinに優位性があると考えています。
2. Backlogの問い合わせから対応完了までのフロー
1. 起票および初動調査(手動)
サポートチームからBacklogへチケットが起票されたのち、まずはエンジニア自身でCloudWatch等のログ解析や類似チケットの照会を行い、事象の把握と根本原因の特定を実施します。この初動フェーズにおいてもAIを補助的に利用することはありますが、初手から頼りきりになるとかえってノイズ(誤った推論)に引っ張られる可能性があるため、あくまで手動での調査を主軸としています。
2. 既存仕様の深掘り調査と実装方針の策定
特定した原因箇所をもとに(または初動調査で原因特定に至らなかった場合)、Devinの「Ask」機能や「Claude」を活用して既存仕様の深掘り調査を行い、実装方針を策定します。
3. 一部調査を含む網羅的なコード改修およびテストの実装
方針策定後、Devinの「Session」機能(一部の調査作業を含む)や「Claude」を用いて、影響範囲を網羅したコード改修を実行させます。
かつては改修後の軽微な追加修正やテストコード生成を「GitHub Copilot」で補完していましたが、現在は、テストコードの実装についてもDevinやClaudeへ統合させており、一連のプロセスでのCopilotの出番は少なくなっています。
※なお、DevinのSession機能はACU(アクティブ作業時間)の消費によるコスト肥大を招きやすいため、タスク規模に応じてClaudeと最適に利用配分しています。
4. 定型タスクの自動化
修正に伴うデプロイ作業やNode.jsのバージョンアップといった定型タスクについては、Devinの「Playbooks」機能やClaudeの「Skills」機能を活用し、プロセス全体の自動化を図っています。
%%{init: {"flowchart": {"htmlLabels": false}}}%%
graph TD
A{" Backlog課題起票 "} --> B[" エンジニアによる手動対応\nログ解析・類似チケット等による事象把握 "]
B --> C{" 仕様調査・実装方針の策定 "}
C --> D[" 既存仕様の把握や原因に関する深掘り調査\n(Devin Ask / Claude Code) "]
C --> E[" 一部調査を含む網羅的なコード改修\nおよびテストコードの実装\n(Devin Session / Claude Code) "]
D --> E
E -.- Note[" ※ACU消費・料金肥大を防止するため\n要件規模に応じてツールを最適配分 "]
E --> F{" デプロイ作業 "}
F --> G[" デプロイ等 定型タスクの自動化\n(Devin Playbooks / Claude Skills) "]
classDef default fill:#ffffff,stroke:#cccccc,stroke-width:2px,color:#333333;
classDef humanTask fill:#e3f2fd,stroke:#64b5f6,stroke-width:2px;
class B humanTask;
classDef aiTask fill:#f3e5f5,stroke:#ba68c8,stroke-width:2px;
class D,E,G aiTask;
classDef noteStyle fill:#f9f9f9,stroke:#999,stroke-width:1px,stroke-dasharray: 5 5;
class Note noteStyle;
3. AI導入による開発プロセスの変化と今後の課題
AIを駆使した運用フローの定着により、開発生産性の面で明確な向上が見られる一方で、組織の運用体制における新たな課題も浮き彫りになっています。
AI導入による開発体験の向上
- 割り込みタスクの占有時間短縮と認知負荷のシフト
- 導入前: これまで、新機能開発中の割り込みタスク(問い合わせ調査やバグ修正など)が発生すると、事象調査から実装・デプロイまでエンジニアの思考が長時間奪われ、メイン業務への復帰時に大きなタイムロスと認知的負荷の増大を招いていました。
- 導入後: 調査や仕様確認をClaudeやDevinに委譲し、デプロイ等も自動化することで、割り込み1件あたりの対応時間が大幅に短縮されました。さらに、負荷の総量が消えたというより「手を動かす実装の負荷」から「方針を立てて検証する負荷」へと認知リソースの使い所がシフトしたことで、全体としての疲労感も軽減しています。
- ツール選定における費用対効果(ROI)意識の定着
- 導入前: 導入初期は解決能力の高い特定ツールへタスクを集中させる傾向があり、運用コストの最適化が課題となっていました。
- 導入後: 「高機能・高コストなDevin」と「安価・ローカル完結のClaude」の特性をエンジニア自身が比較検討する等、タスクの性質に応じた最適なツール選定を行うリテラシーが組織全体に定着してきています。
- 上流工程へのリソース集中
- 導入前: 従来は、構文のエラー解決やライブラリの仕様調査、定型コードの記述といった「How(手段)」の部分に多くの時間を奪われ、本質的な設計に十分な時間を割けないケースがありました。
- 導入後: 実装プロセスをAIへ委譲することで、エンジニアは「何を・なぜ作るのか(What/Why)」という要件定義やアーキテクチャ設計など、より抽象度が高くやりがいのある業務にフォーカスできるようになっています。
- 未知の領域やレガシーコードに対する心理的ハードルの低下
- 導入前: 過去の複雑な仕様や、ドキュメントが不足している古いコードベースへの介入は、心理的な不安(デグレのリスク)が大きく、調査に多大な労力を要していました。
- 導入後: AIの高度なコード解析能力により、複雑なロジックの紐解きや影響範囲の特定が容易になったことで、専門外のドメインやレガシーシステムに対しても、自信と安全性をもってアプローチできるようになっていると実感しています。
- AIとの「壁打ち」を通じた自律的なスキルアップ
- 導入前: これまでは実装方針に迷った際、シニアエンジニアの空き時間を待って相談やレビューを行う必要があり、それが作業の停滞になることがありました。
- 導入後: AIを「いつでも相談できるペアプロのパートナー」として活用し、実装前に方針の壁打ちやロジックの妥当性検証を行うことで、手戻りを防ぐと同時にエンジニア自身の設計スキル向上にも繋がっています。
課題:AI依存の防止
恩恵の一方で、どのAIツールの活用にも共通する課題として、AIへの「過度な依存」が実感としても挙げられます。
AIの進化により、ドメイン知識が不足している非担当領域であってもコード改修自体は容易になりました。しかし、エンジニア自身の仕様理解が伴わないまま実装を進めると、後工程において様々な課題が顕在化します。
ここでは、実際に発生した課題と、それに対してチームでどう向き合っていくべきかという対策の一例をご紹介します。まだ試行錯誤中の取り組みも含まれますが、AI活用における一つの参考として読んでいただければと思います。
- レビューや技術的ディスカッションの形骸化
- 課題: 問い合わせ経由のバグ調査やPRレビューにおいて、AIの出力結果に依存しているため、質問や指摘の意図を正確に汲み取れず、自律的な問題解決や技術的なディスカッションが停滞する。
- 対策: 事象の根本原因と要件をエンジニアが紐解いて修正方針(設計)を立案し、AIはその方針に基づくコーディングのサポート役として協調させる。エンジニアが常に実装のオーナーシップを保持し続ける。
- 動作確認の非効率化
- 課題: テスト環境での動作確認時、画面の仕様や操作フローに対する理解不足から、確認作業自体に想定以上の工数がかかる。
- 対策: 修正作業へ着手する前に、既存仕様やシステムのドメイン知識を能動的にキャッチアップするプロセスをフローに組み込む。
- 非機能要件の考慮漏れ
- 課題: AIは機能要件(動くこと)の達成を優先しがちなため、プロジェクト特有のセキュリティ基準(脆弱性対策)や、データ量増加に伴うパフォーマンスの懸念を見落とし、潜在的なリスクを埋め込んでしまう。
- 対策: コード生成を委譲する際も、非機能要件を前提条件として明示し、レビュー時に「セキュリティやデータ増加時のパフォーマンス劣化リスク」を人間が必ず検証する。
- 予期せぬ挙動・不具合発生時のトラブルシューティング長期化
- 課題: ロジックの振る舞いをブラックボックス化したまま実装を進めると、バグ発覚やリリース後の障害対応において、原因箇所の特定や影響範囲の調査に膨大な時間がかかってしまう。
- 対策: AIの提案に対して、「なぜそのアプローチが有効なのか(Why)」を自身の言葉でPRの概要等に言語化し、実装に対するコントロールとシステム挙動の理解はエンジニアが保持し続ける。
実装スピードだけを追求して要件定義や仕様理解を疎かにすると、その後のプロセスで必ず破綻します。
そのため、最低でも「どの処理がボトルネックであり、どう解消すべきか」という最初の方針はエンジニア自身が定義した上で、AIの出力に対して設計意図との整合性をレビューし、自身のドメイン知識とAIの支援を組み合わせて最適化していく。
あくまでエンジニアが主体性を失わずに開発をリードする姿勢が、AI駆動開発では特に重視すべきポイントだと考えています。
おわりに
AIツールの導入は、単に「コードを書くのが速くなる」というだけでなく、「日々の運用保守や割り込みタスクの苦痛を取り除き、チームを健全に保つ」という点において絶大な効果を発揮しています。
課題はまだありますが、それ自体がエンジニアとして向き合いがいのあるテーマです。AIツールを日常的に使いこなし、個人やチームの成長を加速させる開発体制やプロダクトの成長を一緒に牽引いただけるエンジニアを募集しています。ぜひ採用ページよりご応募をお待ちしております!
📩 お問い合わせ・採用情報
本ブログを読んでいただきありがとうございます。 もし内容にご興味を持っていただけましたら、以下よりお気軽にお問い合わせ・ご応募ください。
スマートホームの導入をご検討中の企業様へ:
アクセルラボへご興味を持たれたみなさまへ:
アクセルラボでは採用を強化しています。 私たちの技術やビジョンに共感し、スマートホームの未来を共に創っていきたい方のご応募をお待ちしています。
