ODC分析自動化により実装と運用をうまくやるには ーMCPとSkillsを使ったAI適用事例のご紹介

プロジェクトの背景

筆者が担当する大規模な車載ソフトウェア開発では、OTA (Over The Air：無線によるソフトウェア更新) を控えたプロジェクトにおいて、「どの機能にリスクが多く潜んでいるか」を早い段階で見極めたい場面があります。そこで、過去の不具合の分布を構造的に読み解ければ、リスクの所在に当たりを付けられるだろうと考えました。そのための手段として、ODC分析に着目しました。

当初、ODC分析の属性付与には専門知識が要り、担い手が限られるとの印象がありました。冒頭で触れたように、専門家が組織内にいない現場は多く、本事例もそうした状況からの出発でした。そこで、JiraチケットのODC属性付与をAIで自動化することに取り組みました。その結果、AIによる分類処理は1件当たり約2分。専門家が手作業で行うと、1件当たり10分以上を要することが想定される分類作業を大幅に短縮できたのです。

以下では、まずODC分析について説明し、具体的にどのように自動化していったのかを説明してから、その過程での課題や今後の展望などについてご紹介していきます。

ODCとは何か

ODC (Orthogonal Defect Classification) は、1992年にIBMが提唱した欠陥分類・分析の手法です。欠陥を複数の属性で分類し、その分布から開発プロセスのどこに構造的な弱点があるかを読み解くことに狙いがあります。
ODC分析の背景やその詳細は、杉崎眞弘氏の連載記事：ODC分析についてのよもやま話をご覧ください。

ここからは、技術的な解説（※1 ）を含め、ODC分析をどのように自動化していったのかをお話します。

まず、用語の定義から説明します。本記事では、IBMが提唱した分類体系そのものを「ODC (Orthogonal Defect Classification) 」、欠陥に属性を付ける行為を「ODC属性付与」、付与結果を用いて開発プロセスを分析する活動を「ODC分析」と呼び分けることにします。

（※1）本事例では「ODC属性付与」とその自動化まで行いました。このため、その後に実施すべき、付与結果のパターンを読むシグネチャ分析や、その先の予防プロセスであるDPP (Defect Prevention Process) は言及しません。

ODCの属性は記録するタイミングによって2グループに分かれます。欠陥登録時には検出活動 (Activity) / トリガー (Trigger) / インパクト (Impact) を、欠陥修正時には混入時期 (Age) / ソース (Source) / 欠陥タイプ (Defect Type) + タイプ識別子 (Qualifier) / 修正対象 (Target) を記録します。

何を自動化したか：ODC属性付与を4つのフェーズで実施

本事例で自動化するのは、Jiraチケットへの ODC属性付与と、その分析準備に当たる一連の作業までが対象です。

具体的には次の4つのフェーズに分けて実施し、フェーズ 1～3で属性の付与・検証を、フェーズ 4で結果のレポート化を行いました（図表2）。

• フェーズ 1：ODC属性の初期付与
• フェーズ 2：論理整合チェック
• フェーズ 3：デュアルレビュー検証
• フェーズ 4：統計レポート生成

AIを使い、どう自動化したか

今回のAIを使用した自動化では、MCP (Model Context Protocol) とAgent Skills（以降、Skillsと記します）という二つの仕組みを組み合わせて動かすことにしました（図表3）。それぞれの役割を整理しておきます。

MCP は、AIが必要とする外部データをリアルタイムに取得するための仕組みです。本事例ではJira MCPを通じてチケット情報を動的に取得しています。これにより、人手で行わずにデータが取得できるようになりました。
つまり、AIを利用することで「Jiraを検索できる手足」を持つことになり、チケット本文・コメント履歴・関連リンク先チケットを参照しながらODC属性を判断できるのです。

Skillsは、AIへの指示をルールとして言語化し、カプセル（データの隠ぺい）化する仕組みです。
ODCの属性付与方法（どのType / Qualifierか、何をSourceとするかの判断基準）・確信度の管理基準・フェーズ間の手順をSkills内に定義しておくことで、呼び出す側が個々の属性の判断基準を知らなくても安定した出力ができるようになります。

まとめると、MCPが「データを引く」役割を担うのに対し、Skillsは「引いたデータをどう判断・整形するか」を規定します。

この二つを組み合わせることで、「Jiraからデータを取得し (MCP) → ODC分析手法に従って分類・検証・レポート化する (Skills) 」という一連の流れを自動化できました。

次に、今回の取り組みを行う前の課題として挙げた「専門知識を持つ人がいない」ことに対して、この仕組み、特にSkillsでどう乗り越えたのかを説明します。

Skills化による専門知識のカバー

ODC分析においては「このチケットの欠陥タイプ (Defect Type) はFunction（機能）なのかInterface（インターフェース）なのか」といった判断一つでも、専門知識を用いた欠陥の文脈理解・プロジェクト固有の用語理解・前後チケットの確認が必要となります。ですが、こういった分析ができるメンバーは社内でも限られており、プロジェクトメンバー全員でスキルを身に付けるために工数を取ることは難しい状況でした。

そこで、ODCの属性付与の方法をSkillsの中にカプセル化し、呼び出す側が個々の属性の判断基準を知らなくても安定した出力ができるよう、自動化したのです。

自動化を行う活動を4つのフェーズに分け、フェーズ 1～3を検討工程、フェーズ 4のレポート作成として、実装していきました。

本来ODCの属性は、欠陥を起票・修正した担当者自身が記録するのが望ましいです。しかし、今回は開発担当者によるODC属性記録を置き換えるのではなく、既存チケットに対する後追いで、ODC分析や、属性記録のばらつきを確認するアプローチを取りました。

また、ODC分析の手順だけでなく、同じ基準で判定するように品質基準を固定し、分類できないと判断した内容は分類不能のタグを付与するようにしています。これに加えて、プロジェクトで頻出するキーワードをデータベースに蓄積する機能もSkills内に実装しました（図表4）。

図表4：Skills化によって達成した内容一覧

「継続学習」ではなく「用語蓄積」

プロジェクト固有の用語や略称を蓄積する役割であり、モデルがセッション間で重みを更新する意味での「継続学習」ではありません。セッション外にある辞書ファイルに知識を積み上げ、次回のSkills呼び出し時に読み込むことでODC分類の精度を維持する「用語蓄積」の仕組みです。

ここで紹介する4つのフェーズはODCの属性体系を踏まえつつ、工程情報や確信度管理を含む運用ルールを追加したものです。各フェーズで必要となるデータは、MCPを通じてJiraから動的に取得し、取得した内容をSkillsのルールに従って処理しています。それでは以下に各フェーズを概説します。

フェーズ 1：ODC属性の初期付与

Jira MCPで取得したチケット情報を基に、欠陥タイプ (Defect Type) ・タイプ識別子 (Qualifier) ・混入時期 (Age) ・検出活動 (Activity) ・トリガー (Trigger) ・インパクト (Impact) ・ソース (Source) ・修正対象 (Target) の8属性を初期付与します。各属性には必ず確信度ランク (S/A/B/C) と根拠テキストをセットで記録します。

この設計の狙いは、情報が不足しているチケットに高い確信度を付けさせないことです。根本原因が空欄であれば確信度Sランクを付与できないためです。判断の強さを入力情報の多さにすることで、見かけ上の精度だけが高く見える状態を防ぎます。

フェーズ 2：論理整合性チェック

フェーズ 1で付与したODC属性の組み合わせが整合ルールに照らして妥当かを確認します。8属性を個別に再判定するのではなく、属性間の整合性を6つのルールで検証します（図表5）。

図表5：論理整合性チェックをする際の6つのルール
出典：Orthogonal Defect Classification v 5.2 for Software Design and Code, IBM, September 12, 2013.

特に「混入時期 (Age) × 検出活動 (Activity) 」は流出判定に用い、「本来はもっと上流で検出されるべきだった欠陥ではないか」を判断するための重要なルールとして扱っています。

フェーズ 3：二重視点による検証と、分類不能チケットの扱い

一つのセッション内で、QA視点と開発視点の二つの観点からチケットを独立して確認し、判断の一致・不一致を検証できるようにします。各チケットには最終的に以下のいずれかの状態を付与します（図表６,7）。

図表7：フェーズ 3の分類結果

フェーズ 4：統計レポートと人間レビューの統合

フェーズ 4では分析結果を集計し、欠陥タイプ (Defect Type) 分布・混入工程と発見工程のギャップ・Escalated / Ambiguous の比率と傾向をレポートとして出力します。Ambiguous や Escalated となったチケットは人間レビューの対象とし、追加情報を補完するか「分析不能」として記録するかを判断します。

トークン制約の実態

MCPとSkillsを組み合わせたことで「呼べば一定の手順で正しく動く」仕組みは構築できました。しかし、数千件規模のJiraチケットを継続的に処理しようとすると別の壁が見えてきました。それが、トークンに対しての制約です。

MCPを通じてJiraから返却されるJSON (JavaScript Object Notation) ペイロード（送受信されるデータ本体）は1件当たり数KB〜数十KBになりやすく、今回の実装では二重視点確認（フェーズ 1〜3）を導入しているため、コンテキスト消費量がどうしても増えてしまいます。

実測すると、フェーズ 1〜3を1バッチで安定して処理できた件数は5件でした（※2）。それ以上になるとセッション継続が難しくなるため、申し送りを挟んだバッチ分割が必要になることが分かりました。

（※2）Claude Sonnet 4.6を使用

暫定対応

このトークンによる制約を回避するために2つのアプローチを試みました。
結論から言えば、残念なことにいずれも根本解決にはなりませんでした（図表8）。

アプローチ　その1：Excelエクスポートによる静的読み込み

最初に試みたのは、JiraチケットをあらかじめExcelにエクスポートし、それを分析入力として使う方法です。リアルタイムのMCP呼び出しを減らすことで、セッション当たりのトークン消費を抑えることが狙いでした。

しかし、今回のODC分析では「関連リンク先のチケットを動的に追跡し、経緯を確認する」ことが精度に大きく影響する環境であったため、スナップショットであるExcelでは十分に解析できませんでした。

アプローチ　その2：MCP取得フィールドの厳格な制限

次に試みたのは、MCP経由で取得するフィールドを必要最小限に絞り込む方法です。不要フィールドを削ることで、1件当たりのデータ量を減らしてトークン消費を抑える狙いでした。

ある程度の削減効果はありましたが、根本的な解決にはなりませんでした。それは今回のチケット構成でODC分析する際に確信度の高い判断をするために必要な情報であるDescription、コメント履歴といったテキストフィールドは、それ自体のサイズが大きく、削減できる余地が限られていたからです。

削れる部分を削っても、分析に必要な情報を残した時点でペイロードサイズはある水準を下回らず、1バッチ5件という制約は変わりませんでした。

図表8：暫定対応のまとめ

現在の運用

本記事を執筆した時点では、1バッチを5件に分割し、セッションを切り替えながら継続処理する暫定運用を行っています。さらに、各バッチ終了時に申し送り文書を生成し、次バッチで読み込んで作業を継続するようにしています（図表9）。

図表9：現在の運用

プロンプトドリフトへの注意

セッションが長引くと初期指示から徐々に逸脱するプロンプトドリフトが起こりやすくなります。フェーズ 1〜3を1バッチ5件に抑えているのはこのリスクへの対処でもあります。現状は「分析手順の自動化」は達成できていますが、「自律的に運転し続ける基盤」には至っていません。フェーズ間チェックを省くと不整合なCSVが次工程に流れ、申し送りを省略すると重複処理や判断の引き継ぎ漏れが実際に確認されています。

現状の課題に対して改善したいこと

現在の運用が抱える本質的な課題は「セッションが使い捨てになりやすいこと」です。この課題に対し、各社のAIプラットフォームは「エージェントの実行状態を管理する基盤」を提供し始めています。

長時間タスクの継続・フェーズ間の状態管理・実行履歴の追跡といった機能を基盤側が担うことで、現在手動で対処している部分の多くを環境側に移せる可能性があります。

こうした自律エージェント基盤の利用が、ODC分析の継続運用における制約を緩和する有力な候補だと捉えています。

自律エージェント基盤があれば、ODC分析の運用において以下の3点の課題が改善できると想定しています。

• コンテキスト制約の緩和： プロンプトキャッシングや文脈圧縮により、長時間タスクが継続しやすくなる（ただし物理的なコンテキストウィンドウ制約が消えるわけではない）
• フェーズ遷移制御の環境移管： 現在手動で実施しているCSVスキーマ確認や申し送り生成を、環境側のチェックとして設計できるようになる
• 観測可能性の向上： セッショントレーシングにより、イベント履歴・トークン使用量・ツール実行の詳細を追跡できるようにすることで、分析過程の監査性を高める

ただし永続学習は別論点

重要な注意点として、こうした自律エージェント基盤は「セッションをまたいだ永続学習」を保証するものではありません。

セッションはデフォルトで一時的であり、セッション間の継続記憶には別途エージェントメモリのような機能が必要です。「セッション内で処理を継続しやすくする基盤」と「セッションをまたいで知識を保持・再利用する仕組み」は分けて設計する必要があります。

現実的な運用像

完全に自動完走するより、自律実行と人間ゲートを組み合わせる運用が現実的です。対象スコープの確定・重大な流出リスクを伴うチケットの最終判断・品質ゲート承認は、人間が責任を持つべき局面です。

自律エージェント基盤の価値は「全部AIに任せる」ことではなく、繰り返し処理と制御の一部を環境基盤側に移し、人間が判断すべき論点に集中できるように自動化環境を構築することにあります。

AIがコードを生成する時代に向けて、ODC分析の価値も変化することでしょう。それは「分析対象の質の変化」という観点においてです。
人間が書いたコードの不具合であれ、AIが生成したコードの不具合であれ、チケットが起票されさえすれば同じODCのフレームワークで分析できます。

むしろ注目すべきは、AIが生成したコードに特有の欠陥パターンが人間のそれと異なる可能性があるという点です。

例えば、欠陥タイプ (Defect Type) の分布がどう変化するか、混入時期 (Age) の傾向が変わるかといったことは、ODC分析で検証できる具体的な問いです。
AIがコードを生成する開発環境で不具合チケットが起票される限り、ODCの8属性による分類は有効に機能します。
そして「分布の違いが見えてきた時」こそ、AI駆動開発に固有のプロセス改善の論点が浮かび上がることでしょう。これこそAIがコードを生成する時代におけるODC分析の位置付けになることでしょう。

最後に今回の事例でMCPとSkillsで実施したことと、今後について表にまとめました（図表10）。

図表10：観点ごとで見たMCPとSkillsによる実装のまとめ（MCPとSkillsによる実装の特徴整理）

今回の事例で、今後必要となることはSkillsの洗練に加えて、長時間運用・フェーズ制御・観測可能性・用語知識の管理まで含めた実行基盤だと認識しています。

今回、MCPとSkillsの組み合わせが「分析作業の自動化」を実現したように、自律エージェント基盤へと進化することで、「継続運用の自動化」を支える有力なインフラとなるよう、今後も取り組みを進めていきたいと思います。

本記事が、これからAIを活用してODC分析の自動化に取り組む方々にとって役立てば幸いです。

■参考資料■

・Chillarege.com – “ODC (Orthogonal Defect Classification) Concept”
・ Anthropic News – “Model Context Protocol”
・Anthropic Engineering – “Equipping Agents for the Real World with Agent Skills”
・ Anthropic Engineering – “Managed Agents”