AIでのコード調査をスキル化しても残った手戻りとその原因

はじめに
今回とった手法
実際に使用した際の問題点
まとめ

はじめに

【エンジニア募集中】フルリモート可◎、売上/従業員数9年連続UP、平均残業8時間、有給取得率90％、年休124日以上 etc.　　詳細はこちらから＞

業務AI化の取り組みの一環として、ソースコード調査・解析のAI化に挑戦しました。現在もAIを使って改修やバグ修正を行っていますが、調査が不十分なまま着手して手戻りが出たり、要件を満たしきれなかったりすることがあります。原因の一つは、AIの使い方が各自の裁量に任されている点だと考えました。そこで使い方を仕組みに落とし込み、個人間の差をなくして調査の質を高めることを目的としました。

今回とった手法

業務では主にClaude Codeを利用しているため、調査・解析の手順をスキルとして2本実装しました。

　・調査用：改修依頼を受けた際に、対象箇所と現仕様を特定し、影響範囲の見落としをなくす

　・バグ対応用：原因の当たり付けを属人化させず、修正方針と報告文まで用意する

実際に使用した際の問題点

いずれも、スキルの出力そのものより出力を受け取ったあとの工程に原因がありました。

1. 警告を見逃して手戻りが発生した
スキルは影響範囲に関する警告を出していましたが、確認する担当者がそのうちの一つを見逃し、実装後に手戻りが発生しました。出力には重要度が付いているため改善策として、最も重要度の高い警告は対応方針を決めてからでないと次に進めない運用にしました。読む側の判断に委ねず、進行を止める条件として扱う形です。

2. 確認していないことを断定した報告文になった
報告文の根拠はコードと仕様書の参照に限られ、実際に画面を操作して確認した動作は含まれません。そのため、誤った内容もあたかも確認済みであるかのように書かれていました。完成度が高い文章ほど、検証されないまま信じられてしまいます。報告文の妥当性を人が必ず確認する工程を入れるべきでした。