AEMなど大規模なCMSの構築プロジェクトでは、テスト工程に入ってから不具合がまとまって見つかることがあります。こうした際、見つかった不具合はBacklogなどのツールで起票され、内容の確認、原因調査、修正方針の判断を進めていくのが一般的ではないでしょうか。Business Architects（以下、BA）でもそのような形でプロジェクトが進行しています。

このやり方の場合、起票の件数が増えると、担当したエンジニアにタスクが集中することになります。担当エンジニアでないとコードの背景や仕様を追いにくく、他のエンジニアが手を出せないことが理由です。その結果、特定のメンバーに調査や修正の負荷が集まり、対応待ちのチケットが溜まっていく原因になります。

BAの開発現場でも、こうした状況に直面することがあります。そこで試したのが、AIを使った不具合の一次切り分けです。ソースコードやエラーログ、設計書をもとにした原因候補の整理、確認すべき箇所の絞り込みをおこなうことで、担当エンジニアの負荷をどこまで減らせるかを模索していました。

この記事では、CMS開発の現場で実際に試したAI活用の方法と、使ってみて分かった注意点を紹介します。AIを使えばバグ対応が自動で解決するわけではありません。設計書やログ、実装ルールを整えたうえで、人が判断するための材料を増やす。そのような使い方をしてはじめて、AIは調査や切り分けを支援する手段になります。

大規模CMS開発でバグ対応が滞る理由

大規模CMS開発では、機能ごとに担当エンジニアを分け、それぞれが実装の背景や仕様を理解しながら開発を進めることがあります。

担当エンジニアに集中するリスク

開発中は、この体制が効率的に機能します。認証機能はAさん、コンテンツ管理はBさん、ワークフローはCさん、というように分かれていることで、担当エンジニアが自分の領域を深く理解し、判断も早く、実装も進めやすいからです。

一方で、テスト工程に入り不具合が見つかると、同じ体制がボトルネックになることがあります。不具合の原因を調べるには、該当機能の仕様やコードの背景を追う必要があります。そのため、修正や調査はどうしても「その機能を担当したエンジニア」に集中してしまうからです。

機能によって不具合の件数にも偏りがあります。複雑な処理を持つ機能ではチケットが多くなり、比較的シンプルな機能では少なくなりがちです。結果として、一部の担当者に調査や修正のタスクが集まり、Backlog上に対応待ちのチケットが溜まっていくことになります。

他のメンバーに余力があったとしても、担当外の機能にはすぐに手を出しにくいものです。コードを読み解き、仕様を確認し、影響範囲を判断するのにどうしても時間がかかってしまうからです。BAが支援した大規模CMS開発の現場でも、こうした状況はよく起きていました。

「担当外のメンバーでも一次切り分け可能に」という発想

そこで、「機能を担当したエンジニアでなければ対応できない」という前提を疑い、AIを使って調査の一部を分担できないかを試すことにしました。

具体的には、機能を担当していないエンジニアが、Claude Codeを使いソースコードを読み解き、不具合として報告された内容の原因を一次切り分けする運用を行いました。AIにソースコードと不具合の内容を渡すと、「この処理の、この条件分岐が怪しい」「このメソッドの戻り値が想定と異なる可能性がある」といった分析を返してくれます。

もちろん、AIの分析だけをそのまま信用するわけではありません。軽微なものであれば修正まで進められるケースもありましたし、エンジニアに確認してもらうケースも当然ありました。ただ、「ゼロから調査する」のと「AIによる一次切り分け結果をもとに確認する」のでは、エンジニアの負担は大きく変わりました。

確認すべき箇所を絞った状態で担当者に渡せるようになったことで、チーム全体のバグ対応効率も実感として向上しました。担当外のメンバーでも一次切り分けを担える。特定のエンジニアに集中していた対応を一部でも分散できる。そこに、AIをバグ対応に取り入れる意味がありました。

実践：AIを使ったバグフィックスの3つのアプローチ

ここからは、実際のプロジェクトで試したAIの活用方法を紹介します。主に行ったのは、ソースコードの解析、エラーログの分析、設計書を使った仕様との差分確認の3つです。

アプローチ1：ソースコード解析による一次切り分け

もっとも多く行ったのが、ソースコードの解析による一次切り分けです。不具合の報告内容、具体的には再現手順、期待される動作、実際の動作とあわせて、対象のソースコードをAIに渡します。するとAIは、該当する処理を追跡し、原因となりそうな箇所を整理してくれます。

条件分岐の漏れ、変数の型不一致、設定値の誤りといったシンプルなバグは、AIでも原因候補を整理しやすい領域でした。一方で、複数の機能が絡む複合的なバグや、実行環境に依存する問題は、AIが原因候補を絞り込んだうえで、担当エンジニアに引き継ぐ形をとりました。

重要なのは、AIだけで完結しないケースでも、「原因候補がある程度絞り込まれた状態」でエンジニアに渡せるという点です。エンジニアがゼロから調査する場面を減らし、確認と判断に集中しやすくなる利点がありました。

アプローチ2：エラーログ解析による原因推定

AEMのようなエンタープライズCMSでは、大量のエラーログが出力されます。人手でログを追うと、膨大なログの中から原因となる箇所を見つけるだけでも時間がかかります。

そこで、必要な範囲のエラーログをAIに渡し、原因候補の整理や関連するログの確認に活用しました。AIは大量のログの中から、エラーの発生順序や関連する例外を整理し、「このNullPointerExceptionが起点で、後続のエラーはすべてこの影響を受けている可能性がある」といった分析結果を返してくれます。

ここで大きな差が出たのがログ出力の質でした。適切なログ出力が設計されている処理では、AIがログを追って原因候補を整理しやすくなりました。一方で、ログ出力が不十分だった処理では、AIも「この先の情報がないため特定できない」といった回答にとどまりました。当然の話ですが、AIにとっても「ないものは分析できない」のです。

この経験から、ログ出力設計の重要性を改めて痛感しました。

アプローチ3：設計書を使った仕様との差分確認

3つ目に行ったのが、ソースコードだけでなく設計書もAIに渡し、仕様と実装の差分を確認する方法です。不具合の報告内容、対象のソースコード、関連する設計書をあわせて渡すことで、コードの動きだけでなく、設計書に書かれた期待動作と照らし合わせて確認できるようにしました。

ソースコードだけをAIに渡した場合、AIは「コードとしてどう動くか」を追うことはできますが、「仕様として正しいかどうか」までは判断できません。

たとえば、ある処理が特定の条件で分岐している場合、その分岐が正しい仕様なのか、それとも実装ミスなのかは、仕様を知らなければ判断できません。ソースコードと設計書をあわせてAIに渡すことで、「設計書ではAという挙動が期待されているが、実装ではBという挙動になっている」というように、仕様と実装の差分を確認しやすくなります。

実際のプロジェクトでは、設計書がある機能とない機能でAIの分析結果に差が出ました。設計書がある場合は「仕様と実装の乖離」をAIが指摘できることがあります。一方で、設計書がない場合は「コードの挙動はこうなっています」という事実の整理にとどまり、それが正しいのかどうかは人が判断する必要がありました。

AIを使って分かった、事前に整えておきたいこと

ここまで紹介したように、AIはソースコードやログを読み解き、不具合の原因候補を整理するうえで有効でした。

一方で、AIに任せればすべて解決するわけではありません。実際に使ってみると、AIで調査しやすくするためにはいくつか条件があることも分かりました。
特に重要だと感じたのが、設計書、ログ出力、実装標準・コーディングルールの3つです。

ポイント① 設計書が整っていること

設計書がなければ、AIは「コードとしてどう動くか」を追うことはできても、「仕様として正しいかどうか」までは判断できません。

特に大規模CMS開発では、システム開発水準の設計書が求められます。Web制作でよく使われるワイヤーフレームと補足資料だけでは、AIに渡しても十分な精度が出ない場面がありました。機能の入出力、条件分岐、ユーザー種別ごとの挙動、エラー時の処理フローなどが明記された設計書があってこそ、AIは「仕様との差異」を指摘しやすくなります。

ポイント② ログ出力が適切に設計されていること

エラーログを使った原因推定では、ログの内容がそのまま分析の材料になります。たとえば、次のような情報が残っているかどうかで、AIが整理できる範囲は変わります。

• どの処理でログを出すのか
• 正常時・異常時に何を出すのか
• ユーザーIDや権限情報、対象コンテンツ、処理結果を追えるのか

こうした情報が残っていれば、AIもログを起点に原因候補を整理しやすくなります。反対に、ログが不十分な場合は、AIも人間と同じように手詰まりになります。AIに分析させる以前に、必要な情報がログとして残っていることが前提になります。

ポイント③ 実装標準・コーディングルールが明文化されていること

複数人が開発に関わるプロジェクトでは、修正の積み重ねによってコードの一貫性が崩れやすくなります。AIをコード品質のチェックやレビュー補助に使う場合も、何を基準に判断するのかが明確でなければ、指摘の精度は上がりません。

たとえば、既存処理との一貫性、処理の重複有無、共通化すべきかの判断基準、ハードコーディングの禁止事項、保守性の観点などを明文化しておく。そうしたルールをAIに渡すことで、「既存の共通処理と重複している」「設定ファイルに外出しすべき値がハードコーディングされている」といった観点で確認しやすくなります。

AIの分析結果をバグ対応に活かすために、BAが決めたこと

AIの回答は常に正しいわけではありません。実際のプロジェクトでAIを使う中で、BAでは、AIの分析結果をそのまま採用するのではなく、調査の仮説として扱うことを前提にしました。

AIが示した原因候補をどのように確認するか。どこまでを担当外のメンバーが切り分け、どこから技術リードや仕様責任者に確認するか。こうした運用ルールを決めておくことで、AIを安全にバグ対応へ組み込めるようになります。

AIの回答は「仮説」として扱う

AIの回答をそのまま採用してはいけない、という話は、すでに多くの場面で言われています。ただ、実際の開発現場で不具合対応のチケットが溜まってくると、AIが出した原因候補をそのまま信じたくなる場面もあります。

そこをぐっとこらえ、AIの分析結果はあくまで「仮説」として扱う。BAの現場では、そのまま採用するのではなく、必ずログ・コード・仕様で裏取りするプロセスを踏むようにしました。

実際のプロジェクトでは、AIが自信を持って提示した原因候補が誤っていたケースもありました。AIはコードの字面から論理的に推論しますが、実行する環境固有の挙動やキャッシュの影響、外部システムとの連携タイミングなど、コードだけでは読み取れない要素で結論が変わることがあります。

判断が難しい場合は、仕様の責任者や技術担当者に確認します。AIの分析結果を「ここまではAIで切り分けた。この先は確認が必要」という形でエスカレーションすることで、確認する側も状況を把握しやすくなります。

遠回りに見えるかもしれませんが、結果としては、この進め方がもっとも確実でした。

AIに渡した情報の前提を明確にする

AIの回答は、「何を渡したか」によって大きく変わります。ソースコードだけを渡した場合と、設計書、エラーログ、実装標準もあわせて渡した場合では、AIが確認できる範囲が変わります。

そのため、AIに依頼する際は、「今回渡している情報は何か」「渡していない情報は何か」を明確にしておくことが重要です。たとえば、設計書を渡していないのであれば、AIの回答はコード上の推測にとどまります。エラーログが不足していれば、原因候補の整理にも限界があります。

こうした前提を整理し、AI含めてチームで共有しておくことで、AIの回答をどこまで参考にしてよいかを判断しやすくなります。なお、ソースコードや設計書をAIに渡す際は、社内で利用が許可されたツールを使用し、機密情報の取り扱いルールに従うことは大前提なのは言うまでもありません。

AIで得た調査観点をチームに残す

AIを使って調査を進めると、「この種類のバグでは、まずこの順番で確認したほうがよい」「このコンポーネントを修正するときは、この設定ファイルもあわせて見る必要がある」といった調査の観点が見えてきます。

こうした観点をその場限りにせず、AIに渡す指示やルールとして残しておくことで、次に同じような不具合が起きたときにも活用しやすくなります。AIへの指示テンプレートとして整備したり、プロジェクト内メンバーで共有できる形に残しておけば、担当者が変わっても、過去の調査で得た知見をもとに切り分けを始められます。

特定のメンバーの頭の中にしかなかった暗黙知を、チームで使える形にしていくことも、AIをバグ対応に取り入れる効果のひとつです。

まとめ：AI×バグフィックスは「ツール」ではなく「仕組み」である

AIをバグフィックスに活用してみると、AIそのものの性能だけでなく、プロジェクト側で何をどこまで整えているかが大きく影響することが分かりました。

設計書が整っていなければ、AIは仕様との差分を十分に確認できません。ログ出力が不十分であれば、原因候補を追う材料が足りません。実装標準やコーディングルールがなければ、AIがコード品質を確認する基準も曖昧になります。

AIをバグ対応に活かすには、設計書、ログ設計、実装標準といった情報を整えたうえで、開発プロセスの中に組み込むことが欠かせません。AIがバグを自動で直してくれるのではなく、人が判断するための材料を増やし、調査や切り分けを進めやすくする。そのような使い方をしてこそ、バグ対応の負荷を下げる手段になります。

Business Architectsでは、AEMをはじめとする大規模CMS構築の現場で、AI活用も含めた開発プロセスの改善に取り組んでいます。バグ対応を特定の担当者の頑張りだけに頼るのではなく、設計、実装、テスト、運用まで含めて品質を高めていくことが、これからの開発現場ではより重要になると考えています。

開発プロセスの品質向上にお悩みの方は、ぜひお気軽にご相談ください。