AIと品質：

AIシステムの品質保証とAIによるソフトウェア品質保証

概要

AIと品質の関係を、特に生成AIに焦点を当て、AIシステムの品質保証とAIを活用した品質保証の両面から取り上げる。AIシステムの品質保証では、関連する規格やガイドラインを踏まえつつ、上位ゴールとの整合確認や既存の品質原則・指標の活用といった従来から重要な取り組みに加え、AI特有の不確実性や出力の複雑さを考慮した品質保証が求められる。具体例として、変化に着目するメタモルフィックテストや、エージェントシステムに対する運用時の継続的品質保証を支えるハーネスエンジニアリングなどを紹介する。また、生成AIの特性や限界を踏まえながら、レビュー、テスト、欠陥管理などの品質保証活動そのものにAIを活用する方法についても扱う。本講演では、これらの全体像を整理した上で、主要な技術や考慮すべき課題を、研究・実践事例を交えて解説する。

業務上の経験や研究を主とした経歴

早稲田大学理工学術院教授、国立情報学研究所客員教授、株式会社エクスモーション 取締役、株式会社SI&C顧問。
IEEE Computer Society 2025年会長。日科技連 ソフトウェア品質管理研究会 運営小委員会 委員長。
JST CREST 信頼されるAI システム領域アドバイザ。ISO/IEC/JTC1 SC7/WG20 Convenor。
AIソフトウェア工学、情報教育の研究、教育、社会展開に従事。
IoT・AI・DXリカレント教育プログラム「スマート エスイー」事業責任者。

研究論文や著書

編著：

• AspectJによるアスペクト指向プログラミング入門（2004年、ソフトバンククリエイティブ）
• ソフトウェアパターン入門～基礎から応用へ～（2005年、ソフトリサーチセンター）
• コンポーネントベース開発テキスト（2006年、近代科学社）
• ソフトウェアパターン：パターン指向の実践ソフトウェア開発（2007年、近代科学社）
• 初級ソフトウェア品質技術者資格試験（JCSQE）問題と解説 第2版（2015年、日科技連出版社）
• Scratchでたのしく学ぶプログラミング的思考（2019年、マイナビ出版）
• ソフトウェア品質知識体系ガイド（第3版）－SQuBOK Guide V3－（2020年、オーム社）
• 初級ソフトウェア品質技術者資格試験（JCSQE）問題と解説 第3版（2022年、日科技連出版社）
• 機械学習工学 （機械学習プロフェッショナルシリーズ）（2022年、講談社）
• あそんで! まなべる! チャギントンプログラミング（監修）（2022年、ジャムハウス）
• アジャイル品質パターン「QA to AQ」 伝統的な品質保証からアジャイル品質への変革（2022年、翔泳社）
• AIプロジェクトマネージャのための機械学習工学（2023年、科学情報出版株式会社）
• Scratch真好玩-快快樂樂學編程（2023年、深圳）
• Guide to the Software Engineering Body of Knowledge（SWEBOK Guide）, Version 4.0,（2024年、IEEE Computer Society）
• 生成AIによるソフトウェア開発: 設計からテスト、マネジメントまでを全て変革するLLM活用の実践体系（2025年、オーム社）

訳書：

• ユースケースによるアスペクト指向ソフトウェア開発（2006年、翔泳社）
• 演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定と見積もりの正しい作法（2009年、日経BP）
• ゴール&ストラテジ入門: 残念なシステムの無くし方（2015年、オーム社）
• モダン・ソフトウェアエンジニアリング（2020年、翔泳社）
• 機械学習デザインパターン ― データ準備、モデル構築、MLOpsの実践上の問題と解決（2021年、オライリー・ジャパン）

その他（学位、表彰、学会活動、その他特記事項）

科学技術分野の文部科学大臣表彰 科学技術賞、KDDI Foundation Award 本賞、日本工学教育協会 経済産業省産業技術環境局長賞、Spirit of the Computer Society Award、IEEE Computer Best Paper Award、日本ソフトウェア科学会 基礎研究賞、情報処理学会 山下記念研究賞、電子情報通信学会 教育優秀賞ほか表彰多数。

ホワイトボックス単体テストにおける品質要求の拡張と既存テスト工程との補完関係

概要

ソフトウェア開発ではテストケースの整備は進んでいる一方、「何を検証すべきか」というテスト要求を明確化・構造化する重要性は十分に認識されていないと考える。AI駆動開発をはじめ、大規模言語モデル（LLM: Large Language Model）によるコード生成の普及に伴い、品質評価の根拠や検証観点が曖昧になることが予想される。
本研究では、テスト要求モデル（TRM: Test Requirement Model）を中間成果物として導入し、テスト要求の構造化が品質基盤として有効であることを二つの観点から実証する。
第1の観点はテスト生成精度の向上である。ソースコードのみを入力として生成したテストと、TRMを介して生成したテストを比較し、オープンソースソフトウェア（OSS: Open Source Software）および小規模プログラムを対象として、既存テストでは見落とされていた検証観点を体系的に補完できるかを評価する。
第2の観点は品質情報の伝達である。テスト要求とソースコードを対応付けて可視化することで検証範囲の把握の容易性を評価するとともに、TRM記述を非エンジニアが理解できるかを検証し、職種を越えた品質情報の共有可能性を示す。

ユースケースからのモデル化とFPによる複雑度可視化

～生成AIを使ったテスト設計支援

概要

上流品質の向上やテスト設計、開発規模の見積もりを人手で個別に実施する従来の手法では、成果物間の一貫性担保や根拠の説明に多大なコストがかかる課題がありました。
本発表では、Markdown形式の仕様書を入力とし、仕様解析、ユースケースや状態遷移モデルの導出、リスク分析、ファンクションポイント（FP）算出、そしてテストケース生成までを一気通貫で連続実行する、生成AI（LLM）を活用した自動化パイプラインの構築と実践例を紹介します。
本取り組みは、生成AIに完全依存するのではなく、中間成果物を「人間がレビュー・合意しやすい図表形式（状態遷移図やデシジョンテーブル）」として可視化し、各工程で必ず人が確認・修正・承認を行う「Human-in-the-Loop」の仕組みを取り入れている点が特徴です。これにより、経験の浅い担当者でも着眼点を掴めるようになり、見積もりやテスト設計の妥当性を客観的な根拠を持って説明可能になります。さらに、AIの出力と既存設計の比較による抜け漏れ検知や、分析の過程で要求仕様書の記述品質（一貫性や構造化）そのものが改善していくという、運用面における強力な副次的効果についても、開発中の画面を交えて詳しく解説します。

コンテキストエンジニアリングで実現するテスト観点生成の実践、
生成AIと過去テスト資産の活用

概要

生成AIをテスト設計に活用しようとしたが、期待通りの観点が出てこなかった。そんな経験を持つQAエンジニアは少なくないのではないでしょうか。
私が所属するQAチームでも同様の壁にぶつかりました。開発速度向上に伴いリーダーのレビュー負担が深刻化し、生成AIによる補助を試みましたが、出力品質は安定しませんでした。原因を分析した結果、問題はAIの能力ではなく「何をどう伝えるか」にあると気づきました。
そこで「コンテキストエンジニアリング」AIに渡すナレッジと思考プロセスを構造設計するアプローチを導入しました。チームの暗黙知（例：機能要件から導出した因子・水準の組み合わせ）を「プロダクト/テスト/ドメイン」の3層に形式知化し、人間のテスト設計プロセスを模した4STEPで段階的にAIへ渡す協働設計です。
2025年11月～2026年3月の実測では、観測可能な品質ギャップ（リーダー指摘＋本番流出）に対するテスト観点網羅率89.9%を安定達成しました。リーダーのレビューも「観点漏れの指摘」から「テスト設計の妥当性を議論する場」へと変化しました。
本発表では、この取り組みの設計思想・実践内容・成果を紹介します。「AIに何をどう渡すか」を狙って設計することで、生成AI活用の成果はコントロール可能であることを示します。

AIナビゲーション型フリースタイルテストの提案

- テスト技術不足を補う、仕様の詳細化不十分に起因するバグの検出手法 -

概要

本稿では、生成AIを活用し、テスト実行中にテスト観点や具体的な操作例・入力例を提示する「AIナビゲーション型フリースタイルテスト」を提案する。本手法は、テスト実行の具体化を支援し、経験の浅いテスターでも仕様漏れや曖昧さに起因するバグを検出可能とするものである。
筆者らの環境（小規模な開発・テスト兼任体制）におけるトラブル分析の結果、仕様漏れや曖昧さに起因するバグが全体の76%を占めていた。これらは仕様に明示されにくく、テスト観点の抽出や具体化がテスターの知識・経験に依存するため、見逃されやすい。
これまではテスト観点を事前に整理し共有することで対応してきたが、有識者は観点から具体的な操作や入力へ展開できる一方で、経験の浅いテスターにとっては観点のみでは具体化が難しく、十分なテストが実施できないという課題があった。
そこで本稿では、AIを活用したテスト実行支援を通じて、テスターの経験に依存せずに仕様漏れや曖昧さに起因するバグ検出を可能とする方法を示す。さらに、同様の課題を抱える現場に適用可能な実践的解決アプローチを示すことをねらいとする。

生成AI活用による対話型品質分析手法の確立と検証

概要

本発表では、ソフトウェア開発における品質分析への生成AI活用事例を報告する。リソースの限られた小規模開発チームでは、機能開発が優先される一方で、品質分析に十分な時間を確保することが難しい。従来の手動分析は多くの工数を要するうえ、分析結果が表面的な傾向把握にとどまり、具体的な改善策につながりにくいという課題があった。その結果、品質上のリスクを十分に把握できない懸念を抱えたままリリース判断を行わざるを得ないことが構造的な問題となっていた。
本手法では、生成AIを用いたメトリクスの自動集計と対話的な多角分析を組み合わせ、最小限のリソースで手動分析と同等以上の精度を確保した。これにより、分析工数を劇的に削減しつつ実効性の高いコード改善を促し、開発スピードの維持とプロダクト品質の担保を両立し続ける体制の構築を目指した。

生成AI活用による品質保証プロセスの変化と新たな品質課題

―大規模自治体案件での実践事例 ―

概要

自治体業務システム開発では、法改正や制度改定を契機とした大規模案件が増加し、品質保証部門ではレビューや実機確認の工数増、新規参入者増加に伴う品質低下リスクが重要課題となっている。弊社ではこれらの課題に対し、生成AIを品質保証プロセスに組み込む取り組みを推進してきた。
具体的には、専任チームを発足し、有識者依存度が高い作業や確認漏れが生じやすい作業を対象に、Microsoft 365 Copilotのエージェント機能で誰もが同一プロンプトを利用できるAIエージェントを整備した。あわせて、実践形式のワークショップ、検査計画書および各種チェックリスト改定によるインプロセス化、月次アンケートを通じた継続的改善を行い、生成AIの出力を前提に人が判断・評価するプロセスへ再設計した。
適用の結果、作業員69名に対し6か月で約5，920時間（1人あたり月約14.3時間）の効果を確認した。ドメインナレッジを取り込んだAIエージェントにより新規参入者でも有識者と同水準の確認が可能となった一方、判断責任の所在が曖昧になりやすく、AI任せによる確認不足など「人の判断品質」に起因する新たな品質リスクが顕在化した。
本発表では、生成AI活用を前提とした品質保証プロセスの実践事例と効果に加え、新たに見出された「人の判断品質」という品質課題への取り組みを紹介する。

生成AI駆動開発における三層品質体系と限定メトリクスPoCによる品質伝搬可視化の初期検証

概要

生成AI駆動開発では、生成AIが要件理解、設計、実装、テスト生成、修正まで担うため、従来の人手中心の品質管理では開発速度に追従しにくく、不具合原因が入力、AIの推論・判断、成果物のどこにあるかを切り分けにくい。また、成果物品質だけでは、生成AI特有の揺らぎや再現性を十分に評価しにくい。そこで本発表では、品質を人間入力品質（HIQ）、AIプロセス品質（AICQ）、AI成果物品質（AIPQ）の三層で捉え、品質劣化を品質伝搬として可視化する枠組みを提案する。あわせて、限定した優先メトリクスを用いたPoCを通じて、品質差への反応、原因特定、人間レビューで見つかる不具合の検出、是正前後の局所改善をどこまで捉えられるかを初期検証する。発表では、メトリクス定義カード、品質伝搬可視化テンプレート、暫定判定・是正結果サマリを示し、生成AI駆動開発に対する品質管理を、概念論ではなく現場で試行可能な評価枠組みとして議論する。

AIを用いた開発における予期せぬテスト失敗パターンの観察と、古典的プロセス改善による対策

概要

対話型AIコーディングエージェントと人間がペアで実装を進める「AIペアプログラミング」が急速に普及している。AIは人間の数倍速でコードを生成するため、生成速度と人間のレビュー速度の非対称が生じ、CI/E2Eテストによる自動化された品質ゲートが安全網として重要になる。しかしこの安全網は、テスト失敗が本物の不具合を示す信頼できるシグナルである場合にのみ機能し、「環境差で稀に落ちる」等のノイズが混入すると、アラート疲れや対症療法の蓄積を招き、開発体制そのものが崩壊しかねない。
本発表では、単独開発者とAIエージェントが恒常的にペアを組み、V字モデル準拠のテスト管理SaaSを立ち上げから開発した実践を報告する。予期しないE2Eテスト失敗を観察して6パターンに分類し、古典的な根本原因分析（RCA）に基づくプロセス改善を適用した。手段は、(1)AIが新規セッション開始時に必読する教訓集の整備、(2)伝統的な「ポカ除け」としての自動チェックへの組み込み、(3)対症療法の禁忌化、の三つに集約した。
結果として、約4週間でCI失敗率を大きく低減した。本実践から、根本対処を繰り返すプロセス改善はAI時代にも普遍である一方、AIはセッションごとに文脈をリセットするため、改善の「適用ポイント」を教訓集とポカ除けへ移す必要があることを、定量データとともに示す。

過去不具合を次のレビューに生かす

― 9,827件の不具合分析に基づくレビュー観点抽出と知識基盤化の実践 ―

概要

過去の不具合票は、次のレビューで本当に使える資産になっているでしょうか。本発表では、大量の不具合票を対象に、件数集計で終わりがちな不具合分析を、次の開発のレビューで使える知識へ変換した取り組みを紹介します。生成AIを使って不具合内容を読み解き、発生条件、期待結果、実際結果、原因、ODC分類、技術タグなどをそろえ、表記ゆれや記述粒度の違いをならしました。そのうえで、不具合内容を機械的に比較しやすい形に変換し、意味が近い不具合同士のまとまりを探りました。固定カテゴリを先に当てはめるのではなく、実際の不具合の近さから傾向を見つけ、最終的に16個のレビュー観点として整理しました。たとえば「仕様解釈・条件確認漏れ」「画面表示・遷移の不整合」など、抽象的な標語ではなく、具体的な過去不具合にたどれる観点にした点が特徴です。さらに、レビュー観点、不具合、ODC分類、技術タグの関係をグラフ型の知識基盤として結び、対象仕様の説明から関連しそうな観点、根拠事例、確認項目、テスト条件案を提示するプロトタイプを試作しました。当日は、知識化した情報の妥当性や再利用できる範囲について、現時点で確認できた結果と課題を示します。すべてを完成形として示すのではなく、過去不具合を“保管する情報”から“次のレビューを動かす情報”へ変えるための、現場適用に向けた現在進行形の試行錯誤を共有します。

レビューナレッジの構造化・コンテキスト化による生成AIコードレビューコメントのノイズ削減

概要

近年の生成AIの普及により、生成AIにコードレビューを担わせる試みが広がっています。しかし、素朴な指示による自動レビューは精度が低く、ノイズが多発し、かえって開発者の認知負荷を増大させてしまうのが実情です。
本セッションでは、自社の生成AIコードレビューシステムにおいて、AIの出力のうち「人間が有用なバグ指摘であると判定した割合（適合率）」が15～18%にとどまっていた状態から、87.8%へ改善させた実践手法を報告します。
成功の鍵は、人間が暗黙的に処理していた「いつ観点を適用するか（トリガー）」と「何を投稿対象とするか（深刻度評価）」等のナレッジを、生成AIが実行可能な形式知として各観点に付与することでした。具体的には『1レビュー観点のコンテキスト化』と、観点名を「テスト対象・テスト技法」ではなく「欠陥・ハザード」という視点で統一する『レビュー観点全体の構造化』の2つのアプローチに取り組みました。
AIによる的外れな指摘を減らし、1PRあたりのコメント数が2.3件から0.7件に削減され、生産性向上に寄与する状態を確立した実践ノウハウを共有します。

ベテラン知を継承するAI：OT品質保証を支える「品質ナレッジ検索システム×Agent」による品質向上の実践

概要

鉄道をはじめとする長期間運用されるOT（Operational Technology）システムの品質保証において、熟練技術者の経験に依存してきた品質判断に対し、判断根拠を提示し、品質判断支援を行うナレッジ基盤の構築と実践について報告する。
OT分野の品質判断では、障害記録に加え、議事録、仕様書、熟練者ナレッジなど多様な知識を横断的に参照する必要があるが、これらは組織内に分散しており一貫活用が困難であった。この課題に対し、先行発表では、障害記録を主な知識源として、類似する事例をキーワード検索により参照可能なレビュー支援システム（QAA1.0）を構築し、業務支援を実現していた。
本研究のQAA2.0活用では、生成AIの導入により類似事例の見落とし防止と初動対応負荷の軽減を達成した。さらに進化版であるQAA3.0では、複数のAgentを導入し、各種知識の統合的活用に加え、記録作成支援、熟練者ナレッジ抽出、知識の構造化・可視化、仕様書の即時参照を統合することで、判断根拠を含めた一貫した品質判断支援を実現した。
現在、設計/品質保証部門・鉄道事業者にてトライアル運用を実施しており、類似事例探索精度の向上、参照知識の網羅性向上、判断根拠の明確化等の効果を確認している。本取り組みは、OT品質保証におけるAI活用を業務支援にとどめず、品質判断を支える知識循環基盤へと発展させる可能性を示す。

“安全に失敗を体験できる場”としての「すごろQ」

-頻出する課題を可視化し、経験知を共有するゲームの提案-

概要

ソフトウェア開発の現場では、失敗の中にこそ本質的な学びがある。
しかし、「どこでどのような問題が起こりやすいのか」を体系的に学ぶ機会は少ない。また、プロジェクトで頻出するトラブルやその対処方法といった経験知は属人化しやすく、若手や新規メンバーへ十分に伝わりにくい。その結果、同じような問題が繰り返されることも少なくない。
本発表では、この課題に対する取り組みとして、プロジェクトを疑似体験できるすごろく形式のゲーム「すごろQ（すごろきゅ～）」を紹介する。
「すごろQ」は、開発工程を盤面上で進みながら、実際の現場で頻出するトラブルを疑似体験し、参加者同士で解決策を考え話し合うことで、経験知を共有するゲームである。「安全に失敗を体験できる場」として、知識だけでは得られない学びや、参加者同士の対話を促すことを目的としている。
これまでの実施結果から、ゲームを通じて他者の視点や判断基準を知ることができたこと、経験豊富な参加者の知見を共有できたことなどの効果が確認できた。一方で、ゲームで使っている言葉の難しさやゲーム性など、改善すべき課題も明らかになった。
本発表では、それぞれの現場で経験知を共有するための「場づくり」を工夫するきっかけとなるよう、「すごろQ」の設計思想、ゲームの仕組み、試行結果から得られた知見をお伝えする。

大規模ITシステム開発。1,000人が取り組んだ働き方改革

概要

1000人を超える大規模ITシステム開発組織において、マネジメント改革を実施した事例を報告する。
対象組織は大規模、かつミッションクリティカルなITシステムの保守、開発を行っている。開発者一人は複数のシステムを担当しているため、複数の開発と保守を同時にこなす必要がある。これにより、日々複数の仕事を並行して実行するバッドマルチタスク、多く会議が発生していた。
本施策は、2022年ソフトウェア品質シンポジウムで発表された「大規模ソフトウェア開発における『人中心』の品質マネジメント改革」で報告された「つながりフローボード」と「7つの規律」を採用した。担当は一つ一つの仕事に集中して仕事の質を上げ、生産性を倍増した。マネジメントが定例会議での問題報告を待つのではなく、毎日の朝会で問題を小さいうちに拾って解決し、大きな問題を発生させていない。
施策の実施によって、次のように、生産性・品質向上の両立、開発者が「自信と誇りを持って働ける」職場を実現した。
① 生産性の向上：日々の集中タスク完了数が平均1.5倍に向上
② 社員ESの向上：開発者の心理的安全性の向上とモチベーションの向上
③ 組織文化変革の浸透：IT部隊全体の3分の1、約1,000人が活用

開発チームと品質保証チームが共に歩む品質向上サイクル

概要

「QA活動は、開発の足を引っ張る負荷なのか？」
QAが一方的にルールを押し付ける構造のままでは、本質的な品質向上は望めません。
QAは開発を縛るものではなく、開発を「支援する武器」であるべきです。
本発表では、QAと開発チームの間の壁を取り払い、現場が自発的に品質を高め出す「自律的・継続的な品質向上サイクル」の確立プロセスを明かします。

【発表の主なポイント】

• 心理的安全性を確保し、信頼関係を築く「6つの工夫」
• 形骸化を防ぎ、改善を循環させる「5ステップのプロセス」
• 体制変更やメンバー交代に左右されない「ともに歩む品質文化」の定着

QAと開発が対立するのではなく、協調して組織全体の品質を自律的に高めるための、明日から使える実践的メソッドを公開します。

TPI NEXTに基づいた『動物診断』を用いたテストメンバーの特性可視化によるソフトウェア開発の改善

概要

テスト現場の品質・納期改善に取り組み、TPI-NEXTを活用した自己診断の仕組みを構築。
メンバーの特性を可視化することで、役割分担やチーム運営の見直しにつなげ、品質向上と納期改善を実現した。
講演では、TPI-NEXTの16キーエリアをベースにした48問の自己診断をもとに、思考タイプ・行動タイプを9分類する「動物診断」の設計と運用、さらに診断結果を現場の改善行動へ落とし込むまでの実践を紹介する。
単なる診断で終わらせず、チームの課題を見える化し、具体的な改善につなげるための考え方と工夫を、現場視点でお伝えする。

ISO/IEC 42001が要求するAI利用者の「力量」とその具体的実現手法

- 「言語技術」の適用によるAIマネジメントシステム品質向上への論証 -

概要

生成系AIの社会実装が進む中、その出力品質や信頼性を組織的に管理・維持することは継続的な課題となっています。国際規格「ISO/IEC 42001」ではAI利用者の「力量（Competence）」確保が要求されていますが、具体的なスキルの獲得手法は各組織の裁量に委ねられています。
本提案では、高コンテキストな人間の対話と低コンテキストなAI間のコミュニケーション様式の差異に注目し、潜在するリスクを「品質劣化の七層モデル」として構造化しました。その上で、規格が求める「力量」を具現化するためのアプローチとして、論理的対話スキルである「言語技術」を応用したボトムアップの解決策を提示します。
具体的には、以下の2つの実践的手法を取り上げます。

1. 「問いの型」：指示を「主題・根拠・まとめ」に構造化し、属人性を排して入力品質を高める技術（規格 8.1 運用に寄与）
   
2. 「分解スキル」：出力を「事実」と「意見」に峻別し、客観的に妥当性を検証する読解技術（規格 9.1 評価に寄与）
   

これらの提案手法は、誰もが実践可能なヒューリスティックス（経験則）です。トップダウンのルール整備と並行して、利用者個人の対話スキルを底上げすることが、組織のAIマネジメントシステムを実効的に機能させる戦略的基盤となり得ることを論考します。

AI搭載システムのための品質チェックリストの構築と適用

― 確認観点の明確化と軽量な運用の実現

概要

近年、ソフトウェアプロダクトへのAI機能の組み込みが加速している。しかし、AI搭載システムには推論性能の変動といった固有の品質リスクがあり、従来のソフトウェアテストの枠組みだけでは十分に対応できない。我々の組織でも、AI固有の品質リスクに対していつ、何を確認すべきかの指針がなく、対応が属人的になっていた。加えて、専任担当者を置けないという組織的な制約もあり、軽量な運用になるような仕組みが求められていた。
本取り組みでは、AIプロダクト品質保証ガイドラインのチェックリスト74項目を自社プロダクトの特性に照らして精査し、対象32項目を選定した。同チェックリストは品質軸ごとの構成であるため、開発プロセスのどのタイミングで何を確認すべきかが不明瞭であった。そこで、選定した項目を開発プロセスの5つのフェーズに対応づけて30項目に再構成した。さらに、チェック内容の用語を自社の開発文脈に合わせて具体化し、上流から下流へのトレーサビリティを備えた品質チェックリストを構築した。
構築した品質チェックリストを3件のAI搭載機能の開発に適用した結果、未確認の品質リスクの可視化や対応アクションへの寄与が見られた。また、軽量さに関わる結果では、全体のチェックが2時間程度で完了し、専任担当者を置かずとも運用できる負荷に抑えられていることが示された。

AI プロダクト品質保証ガイドライン(QA4AI)の自社適用と RAG システムにおける定量評価の実践

概要

本取り組みでは、AI プロダクト品質保証ガイドライン(QA4AI)を起点に自社の RAG 形式ヘルプチャット機能開発へ適合させ、期待値分解に基づく多面的スコア評価を設計し、社内初の AI 機能リリースを達成した。
その際の品質保証計画では次の課題に直面した。

• 社内に知見が蓄積されておらず、従来のQAプロセスが適用できない
• AIの出力結果に対し合否判定の基準が確立できない
• AI性能を測る専門指標の算出(Ragas等)では、ビジネス責任者の判断材料となりづらい

上記課題に対し、計画・実践した施策を報告する。品質管理エンジニアを開発側とビジネス側の"橋渡し役"に位置づけ、以下の三点を設計した。

• QA4AI の自社適合による「合意形成フレームワーク」の構築
  
• AI出力結果における「QAエンジニア目線でのスコア評価」の新規設計
  
• スコア低位群の分析に伴う、対象機能が固有に持つ不得意領域の特定
  

対象はWebアプリケーション上のヘルプチャットという汎用的な構成であり、同種機能を持つ他システムへの転用も想定できる。さらに、約1年の運用データの分析から、事前設計した評価セットでは捉えられない実ユーザー入力固有の品質課題が浮かび上がった。スコア評価の限界と、より広い視点の設計必要性についても報告する。

AIエージェントを用いた STAMP/STPA の実施と導入検討の支援

概要

大規模かつ複雑な現代のシステムでは、構成要素の故障や制御不備の有無に関わらず、構成要素間の相互作用によりハザードが生じ得る。このような背景の下、STAMP/STPA（以下、STPA）は、相互作用と安全制約に着目し不安全要因を特定できる手法として注目されている。一方で、実務適用には課題も多く存在する。
本発表では、当社での教育の整備と実製品への適用経験をもとに、STPAの適用場面を 「①：高い安全性が要求され厳密な実施が必要なケース」「②：①以外で品質（信頼性や使用性など）向上のために新たに活用したいケース」の2つに整理する。①ではUCA記述時のコンテキストの検討が経験に依存しやすい点、②ではSTPAと製品の両知識の活用が前提となり導入前試行による効果把握が難しい点が課題となる。
これらに対し、①向けには人の確認・スクリプト処理・AIエージェント実行を組み合わせ、コンテキスト想起・根拠整理を支援する半自動ワークフローを提案する。②向けには、最小限の入力から主要成果物を一括生成し、導入判断を支援する全自動ワークフローを提案する。
実製品レベルの試行では、①で大幅な工数削減と検討過程の追跡が可能であること、②で対象システムの制約条件から主要成果物を自動生成できることを確認した。本発表では、これらの結果をSTPAの社内展開に向けた実践的知見として報告する。

生成AIの活用でFMEAの作成期間とリソースを劇的に削減

概要

本発表では、FMEA（故障モード影響解析）をより効率的に作成するための手順の見直しについて、その検討内容を紹介する。
FMEAは、車載システムの信頼性および安全性の確保に不可欠な手法である一方、作成・レビューに多大な労力を要し、属人化や表作成作業の肥大化、多人数レビューの非効率化といった課題を抱えている。そこで、入力情報の整理からレビュー対応に至る従来プロセスを可視化し、無駄な作業の抽出と生成AIによる代替可能性の分析を行った。
その結果、従来は複数の工程を必要としていた作業を、生成AIの活用によって大幅に簡素化できることを確認した。また品質面においても、従来は担当者の経験や知識に依存していたのに対し、生成AIはナレッジベースに基づき、網羅的かつ一定品質の案を提示できることが分かった。
さらに、本手法を顧客システムに適用して評価を行ったところ、一部に物理的妥当性を欠く出力が見られたものの、プロンプトの改善により補正可能であることを確認した。一方で、人手では想定しにくい故障モードを提示するなど、新たな価値も確認された。

Human CapitalとToken Capital

～AIエージェント時代にソフトウェア工学はどう変わるのか～

概要

生成AIとAIエージェントの登場により、ソフトウェア開発は「人の能力」を中心とした時代から、「人とAIが協働する知的生産」の時代へと移行しつつります。本講演では、従来のHuman Capitalに加え、AI活用を支えるToken Capitalという新たな資本概念に基づき、品質管理、開発生産性、人材育成、組織設計、コスト管理の変化を光と陰の両面から整理し、AI時代に求められるソフトウェア工学の新たな役割を考察します。

業務上の経験や研究を主とした経歴

1986年 日本アイ・ビー・エム株式会社に入社、サービス事業、東京基礎研究所等を経てグローバル技術職のトップであるIBMディスティングイッシュトエンジニアに認定され、IBMグローバルサービス事業CTO、スマーターシティ事業CTOを歴任。
2016年より、日本マイクロソフト株式会社に入社、執行役員CTO。2018年からはマイクロソフトディベロップメント株式会社の代表取締役社長も兼務。
2021年11月よりパナソニックに入社し、2023年4月より執行役員シニアヴァイスプレジデントCTOとして同社の研究開発組織をリード。2026年4月より、パナソニックホールディングス株式会社の執行役員グループCAIOに就任し、コネクト社CTOと兼務。

研究論文や著書

• 「継続的デリバリーのソフトウェア工学」（日経BP）
• 「The DevOps 逆転だ！」「The DevOps ハンドブック 理論・原則・実践のすべて」「The DevOpe 勝利をつかめ！」（日経BP)
• 「ソフトウェアシステムアーキテクチャ構築の原理」（SBクリエイティブ）

他 共著・完訳書、学会誌・一般誌への寄稿等多数

その他（学位、表彰、学会活動、その他特記事項）

• 情報処理学会、ソフトウェア科学会、プロジェクトマネジメント学会、IEEE Computer Society, ACMの正会員
• NPO法人 ソフトウェアテスト技術振興協会 理事
• 2001-2007年 日科技連 ソフトウェア生産管理（SPC）研究委員会（現SQiP）元 副委員長