【前回のおさらい】職人技を再現し、人間同等の精度を叩き出した「5つのプロンプト術」

開発工程にて発見されたバグ／不具合を収集・分類し、その原因やパターンを突き止める“ODC分析”。

そのボトルネックとなっていたのは、欠陥情報に種別やトリガーといった複数の属性を一つずつ付与していく分類作業でした。

分析の前処理であるこの作業だけで、全体の工数の約8割を奪われていたのです。 

SHIFTはこの課題に対し、複数の生成AIプロンプトを組み合わせて適用することで、分類作業工数を劇的に短縮。

「AIは自信満々に間違える（情報が足りなくても無理やり決め打ちして回答する）」という壁を突破し、人間同等の精度（一致率約80％）を再現した、独自の“5つのプロンプト術”の流れと要諦は以下の通りです。

＜欠陥分類のAI化プロセス＞

＜プロンプト術の要諦＞ 

対象となる欠陥情報を分類する際、SQFに基づいた分類プロセス（上の01～05）を適用し、それぞれに応じたプロンプトで処理することで分類を実現しています。

各プロンプトのポイントを以下に記載します。

・整形プロンプトによる入力品質の均一化：
書き方がバラバラな障害票を、前処理として6項目の表形式に強制整形。
情報がない場合は勝手な想像を防ぐために「ない」と書かせることが重要で、かつ“空欄禁止”を徹底することで抜け漏れを防止します。 

・判断基準（優先順位）の仕様化：
AIによる解釈のブレを防ぐため、「要件定義 ＞ 設計書 ＞ プログラム」といった重み付けを明示。複数候補がある場合はこの優先順に従って1つを選択させます。

・「救済カテゴリ（あいまいさ）」の許容：
原因が複合している場合、無理な決め打ちによる誤分類を防ぐため、「アルゴリズムorチェック（あいまい）」といったあいまいなまま出力できる逃げ道を用意。人間が再鑑すべき対象をあぶり出す仕組みを構築しました。

・結果＋理由の必須化と自己整合チェック：
結果と同時に分類した理由を必ずセットで出力させ、矛盾がないかAI自身に自己チェックさせることで決め打ちの抑止とレビューの効率化につながります。 

・実際と潜在の2軸による行間読みの再現：
文面の手順だけに依存せず、「実際（事象通りのパターン）」と「潜在（どうテストすれば発見できたか）」の2つの軸でトリガーを分析させることで、人間に近い分類を再現しました。

このアプローチの本質は、AIに分類を丸投げするのではなく、人間が普段行っている暗黙の判断ルールを徹底的に言語化し、仕様としてAIに渡したことにあります。 

【Q&A】単発プロジェクトでも、ODC分析は役立つ？

今回JaSST’26 Kansaiでの登壇では、前回登壇したJaSST’26 Tokyoでいただいたご質問も紹介しました。 

JaSST’26 Tokyoの聴講者から「ODC分析は本来、中長期のデータを大量に蓄積してはじめて活きるものでは？単発のプロジェクトでも価値はあるのか？」という疑問が寄せられました。 

これに対するSHIFTの回答は、「AIによる高速化が、単発プロジェクトにおけるODC分析の活用可能性を大きく広げた」というパラダイムシフトの提示です。 

これまで欠陥の分類作業はあまりに重すぎたため、プロジェクトの進行中に都度分析を行うことは現実的ではなく、必然的に「中長期のデータをまとめて事後分析し、組織的なプロセス改善に活かす」というアプローチになりがちでした。 

しかし、AIによって分類コストが軽量化された現在、単一のプロジェクト進行中であっても、分類・分析作業を都度行うことで「いま、どこに品質リスクが偏っているか」「次に強化すべき観点は何か」を、迅速に把握し、翌日のテスト活動に活かせるようになっています。 

中長期で組織プロセスを改善するという本来の価値も発揮しつつ、目の前のプロジェクトを安全にゴールへ導くためのリアルタイムな武器としても使えるようになったこと。

これこそが、AI×ODC分析がもたらした大きな効果の一つといえます。

【現在の取り組み】ODC分析レポート作成までワンストップ化

今回、最新の取り組みとしてODC分析レポートまでのワンストップ化について紹介しました。 

前回のJaSST’26 Tokyo時点では欠陥分類のプロセスは「分類ステップを実施し、各ステップでユーザーがチェックを行う」という分業制でした。

現在では欠陥情報からの分類、分析、報告までワンストップで進める仕組みを整備しています。 

ワンストップ化をするにあたり、単に分類した結果をAIに渡し「これを分析して」と指示するだけでは、再現性が担保できず、毎回異なる分析結果が出力される可能性があります。

また、欠陥情報単体だけではプロジェクト特有のコンテキスト（文脈）が考慮されず、分析の精度が上がらないという課題もありました。  

そこでSHIFTは、対象プロジェクトの「背景情報」をAIにインプットしたうえで、 長年培ってきた 独自の品質保証標準である「SQF（SHIFT Quality Framework）」の分析観点をAIに組み込もうとしています。 

例えば、「画面系や帳票系の障害が多い」というファクトに対し、「単体テスト（UT）工程での画面系・帳票出力系の網羅テストが未実施、もしくは確認不足」という仮説をAIに立てさせ、具体的な改善提案までをワンセットで出力させます。 

SQFをAIにインプットすることで、AIは一定の観点に基づいて、安定して質の高い一貫した分析報告書を作成できるようになると考えています。

【新しい提案①】欠陥の起票時に自動で属性を付与する

ここからは、AI化した仕組みとその応用によって既存のプロセス改善などにつながる仕組みの示唆ということで2つの提案をしました。 

テスト活動のなかで報告された不具合情報を分析する場合、不具合を起票したメンバーが分類用の属性を判断、設定する運用フローを行うことは一般的です。 

品質の可視化や分析を精緻に行うためには、不具合ごとにできるだけ多くの属性を付与したいのが本音です。

しかし、入力項目を増やせば増やすほど現場の負担は増します。

属性を考えて設定する時間は数分でも、起票するメンバーの本質的ではない属性の判断作業が重なった場合、結果として適当な分類が付けられるなどして、継続的な分析運用は頓挫しがちになります。 

また、大規模なプロジェクトなどではすべてのメンバーが同じ分類基準を共有するということは難しいものです。 

この課題を解決するため、SHIFTはプロジェクト管理ツール「Jira」とODC分析APIをシームレスに自動連携させ、通常の手動テストプロセスの中にAIのタグ付けを組み込む仕組みを提案しています。 

Atlassian Forgeが自動でそれを検知してバックグラウンドでODC分析APIに問い合わせを行い、チケット上に分類タグを自動で反映するイメージです。 

この仕組みの最大のポイントは、完全にAI任せにするのではなく、「AIによる自動タグ付け ＋ 人間による簡単な再鑑」という形で持続的な分析運用のプロセスを構築している点にあります。 

これにより、現場の工数を増やすことなく、すべての欠陥データに品質分析用の属性が即時付与される理想的な環境の実現が期待されます。 

【新しい提案②】24時間稼働するAI×テストの自律サイクル

現在、SHIFTではAIが自律的にテストを設計し、実行するAIテストソリューション「ネムラナイ」を提供しています。

これにAI×ODC分析を組み込むことで、これまでにないスピードでテストの精度を自己向上させていく「24時間稼働する品質改善の自律ループ」の実現を目指しています。 

具体的なサイクルは以下の通りです。

1.夜間のAIテスト自動実行：夜間に、AIが自動でシステムテストを実行する。

2.AIによるODC分析：検出された不具合を、AIが即座にODC分析にかける。 

3.自律的な改善提案：分析結果から「仕様書のここが足りない」「このテスト観点が不足している」といった改善ポイントを自動で導き出す。 

4.翌朝のフィードバック：朝、AIテストを監視するオペレーター（人間）がその提案を確認し、テストの設計モデルやプロンプトを調整・アップデートする。

昨晩発生した不具合の分析結果が、翌朝には“次のAIテスト設計”へとダイレクトにフィードバックされ、日に日にテストの質が向上していく自律的なサイクルです。

【まとめ】職人の暗黙知を仕様化し、AIと共創する未来へ

AIに分類を丸投げするのではなく、人間が普段行っている暗黙の判断ルールを徹底的に言語化し、「仕様」としてAIに渡す。

これが、SHIFTの進めるAI活用の真髄です。 

SHIFTはこれからも、AIと人間の新しい共創のカタチを提示し、ソフトウェアテストの可能性を広げつづけていきます。 

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

契約と納期に向き合いつづけた19年

私が長年自分をエンジニアだと思えなかった最大の理由は、契約やプロジェクトという閉じた環境のなかで働いていたことにあると思っています。 

20代のころはSES、30代以降は準委任契約という働き方で開発に携わってきました。 

そこでは、お客様から求められた役割や工程のなかで成果を出し、次の契約につなげていくことが求められます。

私自身も、自分がどうありたいかを考えるより、期待された成果を出すことに意識が向いていました。

これまで24案件に携わり、多くの開発現場を経験してきました。短い案件では2ヶ月ほどで次の現場へ移ることもあり、都度必要な知識や技術を学んできました。 

資格も19個取得しましたが、各現場で得たスキルが次の現場でも活用できるとは限りません。 

経験は増えていく一方で、それらが一本の線としてつながる感覚をもてずにいました。 

30代前半のころには、ドメイン駆動設計（DDD）やエクストリームプログラミング（XP）といった開発手法にも強い憧れを抱いていました。

ただ、当時の私にはそれらが遠い世界の話に見えていました。 

DDDもXPもプロダクトやチームを成長させていくための手法なので、契約や工程ごとに役割が区切られる自身の環境との接点を見いだせなかったのです。 

同じように、勉強会やカンファレンスに参加しているエンジニアたちも遠い存在に見えていました。

専門性が高いこともそうですが、それ以上に、技術やエンジニアリングに対して自分なりの軸をもっているように見えました。 

一方の私はエンジニアリングそのものよりも、与えられた役割で成果を出すことに意識が向いていました。

その結果、私は40歳を超えるまで、自分をエンジニアと呼ぶことに後ろめたさを感じつづけていました。

新規プロダクト開発の成功の裏にある失敗

そんな私が変わる転機となったのは、40代になって参画した、ある新規プロダクト開発プロジェクトでした。

プロジェクト自体は無事にリリースできたものの、その裏には大きな失敗がありました。 

私はPMを務めながら、プロダクトオーナーアシスタント、スクラムマスター、さらにはQAリードまで、重要な役割をすべて自分一人で抱え込んでいました。 

権限を委譲できず、自身の高稼働によって何とかリリースまでたどり着いた結果、強い属人化を生み出してしまったのです。

さらに効率化を目的に、チームを「仕様策定チーム」「実装チーム」「QAチーム」の3つに細分化しました。 

仕様策定チームが考えたものを実装チームがつくり、その成果物をQAチームが検証する。

一見すると合理的な体制でしたが、その結果、知識や判断が特定のメンバーへ集中し、チーム全体でプロダクトに向き合う機会を阻害してしまったのです。 

最終的にプロジェクトは成功し、お客様にも納得いただくことができました。しかし私のなかに残ったのは達成感よりも、そのやり方に再現性がないという強い危機感でした。 

プロジェクトは終わっても、プロダクトの成長はつづいていきます。それにもかかわらず、属人化やチームの分断によって、リリース後のプロダクト成長に大きな課題を残してしまったのではないか。

そう考えたとき、私のなかには大きな苦しさが残りました。 

「プロジェクトの成功が、必ずしもプロダクトの成功ではない」。この痛切な気づきから、私はリリース後もつづくプロダクトの成長に向き合えるエンジニアでありたいと思うようになりました。

遠い世界は地つづきだった。40代で知ったエンジニアの世界

プロダクト成長に向き合うエンジニアリングの経験がないため、自分の環境を飛び出して、勉強会やカンファレンスへ参加するようになりました。 

誰かに求められたからではなく、自分が実現したいことを見つけるためです。そこで私は知ったつもりになっていたことを基礎から学び直しました。

アジャイル、プロダクトマネジメント、QA、SRE、さらにはAI技術まで、自分の役割にとらわれずあらゆる領域の話を聞きに行きました。そこには、異なる開発組織や企業で挑戦をつづけるエンジニアたちがいました。  

彼らとの交流を通じて、私は自分の見えていた世界の狭さを知り、同時に、外の世界にはどれほど豊かな知識と選択肢が広がっているかを知りました。  

なかでも大きかったのは、自分が知っているつもりだったDevOpsやスクラムを学び直したことです。 

役割の分断をなくし、チーム全体で価値を届けるという考え方に触れたとき、自分が進めていたチームの分断や役割の抱え込みが、まさにアンチパターンとして語られていることを知りました。 

そして、この外の世界への越境を通じて得た最大の気づきは、かつて私が遠い世界だと思っていたものが、実は自分の環境と地つづきだったということです。  

さまざまな人と話すうちに、どんな環境にもそれぞれの前提条件や壁があることがわかりました。大切なのは、その環境のなかで「自分は何を選び、何に挑戦するか」だったのです。  

私の世界は決して孤立していたわけではありません。自ら挑戦することで、足元の環境からでも世界を変える一歩を踏み出せるのだと確信しました。

エンジニアリングへのオーナーシップを取り戻す

外の世界で得た学びは、私の行動を大きく変えました。その知見を自身の環境へもち帰り、実践するようになったのです。

もちろん、外で知った手法をそのまま持ち込んですぐに成功するほど甘くはありません。 

しかし、自分の置かれた環境で「実現したいもの」を探索し、試行錯誤を繰り返すこと自体に大きな価値があることに気づいたのです。

その挑戦のプロセスが、私自身の環境を少しずつ豊かにしていきました。  

かつての私は、契約や与えられた役割という枠組みのなかでしか、自分を定義することができませんでした。  

しかし外の人たちとの交流によって自分を相対化できたいま、私は置かれた環境や与えられた役割ではなく、「何を実現したいか」を起点に自らを考えられるようになりました。 

この結果、役割に閉じず、何に向き合いたいかを考えることができました。 

そして世界が広がったことで、これまで断片的だと思っていた経験や、属人化を招いた苦い失敗のなかにも価値を見いだせるようになったのです。 

エンジニアとしてのオーナーシップは、何歳からでももつことができます。私は40歳を過ぎてから、ようやく自分のことをエンジニアだと胸を張っていえるようになりました。  

「いまから、ここからでも」。自分自身のあり方は更新していけると思っています。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

「フロントエンドをイチゲキで実装したいよね」からはじまった挑戦

システム開発において、不具合が多く発生しがちなのがフロントエンドです。ユーザーの目に直接触れる部分であるため、ここに不具合があるとシステム全体の品質が低いとみなされてしまいます。 

「AIを使って、フロントエンドの開発を高品質かつ高速に、イチゲキで完了させられないか」——。

そんな想いから生まれたのが「イチゲキ実装」という取り組みです。 

昨今のAIツールは進化しており、プロンプトを投げるとコードを吐き出してくれるツールも登場しています。

しかし、受託開発を行うSHIFTがもっとも重視しているのは「お客様との合意形成」です。 

「これからどんな画面ができるのか」を事前に示し、お客様とイメージをすりあわせるためにはデザインデータが必要です。

そこで、私たちはFigmaで作成したデザインを、信頼できる唯一の情報源（SSOT：Single Source of Truth）としました。

ぶつかった3つの壁と、3度の失敗の歴史

プロジェクト開始後、いざFigmaのデータをAIに渡してイチゲキで実装させようとしましたが、大きく3つの壁に直面しました。

1.曖昧な設計書：自由な仕様書をAIに読ませると、足りない情報をAIが勝手に推測してしまい、出力が毎回ばらついた。 

2.車輪の再発明：予め作成済みのボイラープレートコードを無視し、AIが独自の部品をつくり出してしまった。

3.目視の限界：AIが生成したアプリの画面と元のFigmaを、人間が目視で確認する方法は見落としの温床になる。

これらの壁を越えるために重ねた、3つの失敗をご紹介します。 

失敗①：DevinにFigma MCPをそのまま渡した

最初に、私たちはDevinにFigmaのデザインURLをそのまま渡して「MCPを使って、この通りに実装して」と指示しました。

結果は、ステッパーや入力フォームの見た目が崩れ、実行するたびに出力が変わる不安定な状態でした。

実は当時Devin上で動いていたFigma MCPは公式製ではなくサードパーティ製だったという落とし穴もありましたが、根本的な原因は、Figmaがもつ膨大な情報量をAIが処理しきれず、情報の読み飛ばしが発生。デザインの再現性は低く、出力も不安定でした。

失敗②：JSONファイルによる中間データの抽出

次に、必要な情報だけを抽出したJSONファイルをAIに読み込ませました。出力のブレは減りましたが、Figmaのレイヤー構造や命名規則に強く依存しており、見た目の再現性は不十分でした。

失敗③：Figma Makeの導入

Figma公式の「Figma Make」を試したところ、UIの再現性は劇的に向上しました。

しかし、生成されたコードと私たちが予め用意していたボイラープレートの規約の違いから、その後のロジック追加作業が困難になるという新たな問題が発生しました。 

また、当時はFigma MakeにGitリポジトリを直接渡せなかったため、「Figma Makeでコード生成 → Devinでボイラープレートを適用」という二段階の手順が必要となり、「これではイチゲキといえない」という課題が残りました。

（※なお、発表直後の2026年7月頃にFigma Makeへローカルコード連携機能のベータ版が追加されたとのことです）。

これらの失敗から得た教訓は、「ただツールを使うだけではなく、AIが迷わず高品質なコードを出力できる環境（下ごしらえ）を人間側が整えることこそが本質である」というものでした。

AIのポテンシャルを最大化する、5つの「下ごしらえ」

失敗を踏まえて、私たちは見た目（UI）の実装精度を高める3つの下ごしらえと、機能（ロジック）やテストに効く2つの下ごしらえを考案しました。

【下ごしらえ①】Figma Code ConnectでデザインとReactコードを宣言的に紐付ける

Figma Code ConnectはFigma上のデザイン要素と、あらかじめ用意したReactコンポーネントを明示的に紐付ける仕組みです。

AIは通常、Figma上のボタンが既存コードのどれに当たるかを知らないため、似たコードを探すか、見つけられずに勝手につくってしまいます。 

Code Connectを用いることで、Figma MCP経由で「このデザインコンポーネントはこのコードを使う」「Figmaのバリアント（disabledなど）はReactのこのpropsに対応する」という情報がLLMに正確に渡るようになります。 

SHIFTでは、標準で用意されている70〜80個のコンポーネントすべてに対して定義ファイルを作成しました。

膨大な作業に見えますが、「最初の1個をテンプレートとして人間がつくり、残りの定義ファイルはすべてAIに自動生成させる」ことで効率的にすべての定義ファイルを作成しました。

【下ごしらえ②】デザイントークンとコードを繋ぐ「デザインシステムルールファイル」の構築

デザイン上の色や文字サイズ（デザイントークン）を、実際のコード（Tailwind CSSのクラス）にどう変換するかをAIに教える仕組みです。

ここではFigma MCPの標準ツールである「create_design_system_rules」を実行。このツールはFigmaデザインを見るのではなく、既存のコードベースを解析してマッピングルールを自動生成します。 

このルールファイルをAIに読み込ませることで、例えば「STD-16N」といった抽象的なデザイントークンから、迷わず正確なTailwindクラスを出力できるようになりました。

【下ごしらえ③】AIが読み取れる階層構造や命名規則を定めた「デザインガイドライン」の徹底 

どれだけツールを連携させても、元のFigmaデザインが整理されていなければ意味がありません。

そこで、デザイナーとエンジニアが協働するためのデザインガイドラインを策定しました。 

・レイヤー名の統一：Figma上のレイヤー名をReactコンポーネント名と揃え、AIの誤認を防ぐ。 

・階層構造の最適化：デザイナー向けの深いグループ階層をあえて整理し、AIが読み飛ばさないように階層を浅く保つ。 

・アクセシビリティ情報の“仕込み”： Figmaのメモ（アノテーション）機能にalt属性やaria-labelを記載。実装時、Figma MCPがその情報を自動取得し、AIがReactコードへ反映する。 

 【下ごしらえ④】備考欄を廃止し、AIの推測を排除する「構造化テンプレート」 

曖昧な指示を排除するため、設計書の備考欄を廃止しました。代わりに、ボタンの活性化条件や強制的に初期化する項目など、書くべき内容を専用のカラムに細かく分割した“構造化テンプレート”を用意。 

また、全角変換など100%結果が決まっている単純な処理は共通部品に仕込んでおき、AIには「設計書に指定があればプロパティをONにするだけ」と指示しました。 

設計書の構造化により、セクションごとにサブエージェントを立ち上げて並列実装させることも可能になり、開発スピードが飛躍的に高まりました。

【下ごしらえ⑤】SHIFTのノウハウを凝縮した「テスト設計ガイドライン」 

SHIFTが長年培ってきた、900項目にも及ぶ“標準テスト観点”をガイドライン化しました。最大の特徴は、「機能コードを実装させる前に、テストコードを先に書かせる（テストファースト）」点です。 

構造化された設計書とテストガイドラインをAIに渡すことで、自動テスト仕様書と手動テスト仕様書を振り分けて生成させ、そこから自動テストコードを出力させます。

更地に家を建てる前に強固な測定器を置いておくように、AI自身にクリアすべき合格ライン（テスト）を先にセットさせ、そのテストをパスするコードを書かせることで、ロジックの不具合を抑え込んでいます。

目視チェックの極小化を目指す。自動検証ループの飽くなき探求

5つの下ごしらえによってAIのコード生成精度は劇的に向上しましたが、最後に検証（レビュー）の壁が立ちはだかります。

数百画面に及ぶ開発では、人間の目視による確認はどうしても見落としが発生します。 

目視チェックをなくすために考案したのが、ビジュアルギャップ検証です。一般的な画像同士のピクセル比較では、1ピクセルずれただけで全てエラーとなり実用的ではありません。 

そこでSHIFTでは、「Figmaデザインから変換したHTMLのDOM構造」と「Playwrightでアプリ画面を表示して抽出したDOM構造」を直接比較する構造比較を採用しました。

これにより「このボタン要素が欠落している」「テキストが違う」といった具体的な差異を検出できるようになりました。

さらに、検出したギャップレポートをAI自身に読み込ませ、自動修正させるループを構築しました。

「自分で間違いを見つけ、自分で直す」というサイクルを、デザインと実装の差異が解消されるまでまわしつづけるのです。

人間の目視チェックをゼロにするためのSHIFTの執念が、この自動検証ループに込められています。

手作業12時間が4時間に。一度つくった下ごしらえは組織の共通資産になる

これら5つの下ごしらえとビジュアルギャップ検証による“自動検証ループ”により、イチゲキ実装は現場に大きな変化をもたらしました。

入力フォームを例にとると、これまで人が手作業で行い10〜12時間かかっていた実装作業が、4時間程度まで短縮されました。 

また、明確なルールとガイドラインを設けたことで属人化が排除され、安定した品質の確保につながりました。

AIとの対話回数が減ることで、コストも削減されるという副次的な効果も生まれています。 

これらの下ごしらえは、一度構築すればほかのプロジェクトでも活用できる “組織的な標準化”の結晶です。 

AIは単にプロンプトを投げるだけで完璧な結果を返してくれる魔法の杖ではありません。

質とスピードを両立させるための鍵は、人間がコードベースとプロセスを整え、標準化を推進する“下ごしらえ”にほかならないのです。 

下ごしらえを制する者がAI駆動開発を制す。 

SHIFTが失敗の歴史を糧につかみ取ったこの教訓は、AI駆動開発時代を生きる開発チームにとって、広く役立つものだと確信しています。 

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

「最初から人間が書いた方がはやかった」という手戻りの罠

AI駆動開発によって、実装未経験のジュニアメンバーであっても、一定レベルのコードを圧倒的なスピードで量産できる環境が整いつつあります。

しかし、これは裏を返せば、「人間側の指示のあいまいさが、そのまま成果物の品質や設計のばらつきに直結する」という新たなリスクの顕在化を意味します。 

つまり、これからのAI駆動開発の主戦場は「いかに早く書かせるか」から「いかに手戻りなく制御するか（開発品質をいかに標準化するか）」へと移行しつつあります。 

この課題を解決するカギとして、私たちは仕様（Spec）をIssueに落とし込んで開発を制御する、“Issue駆動開発”という新たな開発手法への転換を考えました。

本記事において、Issueとは「AIが迷わず自律実行し、1〜2日程度で完遂できるアトミック（最小単位）な作業チケット」と再定義します。

具体的には、JiraやGitHub Projectなどのタスク管理ツールで用いられるチケットをイメージしてください。

しかし、「そもそもチケットをどのように記述すべきかが標準化されていない」というケースもあるでしょう。

チケットの書き方が開発者ごとに属人化していると、AIへのインプットが統一されず、アウトプットの品質もばらつきが生じます。

Issue駆動開発は、チケットに「何を、どう書くか」という記述のフォーマットを仕組みとして定義し、AIへのインプット品質を揃える“Issue設計”のプロセスを踏みます。

詳しくは後述しますが、AIにタスクを渡す前に、設計の妥当性を人間同士で議論し合意形成する“Issue設計レビュー”を徹底することで、指示の属人性を排除し、AIが迷わず完遂できるレールをあらかじめ敷いておくのです。

ただしIssue駆動開発は、Issueだけで開発を進めるわけではありません。そうすると、AIはそのタスクの範囲内だけで閉じた、局所最適な解決を図ろうとするからです。

その結果、リポジトリ全体で見たときのシステム整合性が崩壊し、コードの重複や責務の混乱といった技術的負債が一気に蓄積してしまいます。

これを防ぐためには、判断基準や一貫性を担保するSpecの責務と、作業境界や完了定義を示すIssueの責務を切り分け、双方が同期するループ構造を構築することが重要です。

AI駆動開発では暗黙知は通用しない。2つの失敗事例と解決策

私たちはIssue駆動開発を確立するまでに、2つの壁に直面しました。

壁1：変更範囲の肥大化

最初の壁は、変更範囲の肥大化です。人間同士であれば「今回はここだけ移行すればいい」という暗黙知が働きます。しかし、AIエージェントにはその前提が通用しません。

AIは気を利かせて推論を勝手に拡大し、スコープ外の関連クラスまで一気に書き換えてしまいます。

その結果、数十ファイルに及ぶ巨大な変更が含まれたプルリクエストが生成され、レビュー不能な状態に陥ってしまいました。 

そこで、散在するロジックの共通化といった大きなタスクを、実装単位まで細分化しました。

その上で、チケット内に「変更を許可するファイル」と「変更を絶対に禁止するファイル」を明記し、達成すべき期待結果（完了定義）をテンプレートに沿って記述。

AIが余計な推論を行わず、定められた範囲で動作できるようにしました。

壁2：作業の重複とコンフリクト

2つ目の壁は、複数のAIを並行して稼働させたときに起きた“作業の重複とコンフリクト”。

例えば、新しい画面の実装において、フロントエンドのタスクチケットとバックエンドのタスクチケットを、それぞれ別々のAIエージェントに同時に割り当てて開発を依頼しました。 

すると、フロントエンド担当のAIが「まだAPIがない」と判断し、勝手にAPIまで実装してしまいました。

プルリクエストの段階で作業の重複が発覚し、コンフリクト解消に無駄な時間を費やすことになります。 

この解決策として、関連するタスクを束ねる“親Issue”という概念を導入しました。親Issueに全体設計、スコープ、使用するテーブルなどの共通ルールを握らせます。

そして、個別のタスクである“子Issue”を実装するAIには、必ず事前に親Issueを確認するよう指示します。 

これにより、並行して走るAIエージェント同士が全体の文脈や順序依存を理解し、作業重複を早期に検出・回避できるようになりました。

これらの失敗から得られた教訓は、AI駆動開発においては「人間同士の暗黙知に依存してはならない」ということです。

システムの境界を定義・言語化し、AIが脱線することのないようにレールを敷くこと。これが、手戻りの削減につながる重要な考え方です。

実践！仕様と実装を乖離させない、Issue駆動開発のプロセス

ここからは、私たちのチームが実践している、具体的な開発プロセスの全貌をご紹介します。このプロセスは、人間が行う「上流のIssue設計」と、AIエージェントが自律的に実行する「下流の自動実装・同期」の2つのフェーズに分かれています。

【Issue設計】

1.仕様書を用意：要件定義書や基本設計書などのドキュメントを、リポジトリ内に格納し、一元管理します。

2.機能単位で抽出：仕様書をもとに、画面単位や機能単位（親チケットの粒度）で整理を行い、既存実装の調査や問題となりそうなポイントの洗い出しを行います。

3.Issueに分解：機能Issue単位に分解し、依存関係、見積もり、完了定義を明確にします。

★Issue設計レビュー：AIにタスクを渡す前に、「完了定義に漏れはないか」「作業境界は正しいか」「このチケット記述で、開発メンバー全員が同じ認識をもてるか」をチームメンバー間でレビューし、合意を形成します。

4.チケット自動生成：タスク管理ツールのAPIを介して、一括でチケットを生成します。

【実装・同期プロセス：後半】

5.実装（自動化）：システムがチケットの完了定義を読み込み、AIエージェントがコードの自動生成からプルリクエストの作成までを自動で完遂します。
もし誤った実装が発生した場合は、実装用プロンプトの修正だけでなく、「Issueの粒度が適切だったか」と設計フェーズまで遡って改善を回します。 

6.レビュー・merge：レビュー専用のエージェントを用意し、標準のGit hooksなどを活用してレビュー作業を自動化。レビュー指摘を集約したMarkdown形式のドキュメントを用意し、日々の知見を蓄積していきます。 

最後に行うのが、実装完了後の仕様同期です。開発の現場では、実装が進むにつれて設計書が陳腐化していく実態との乖離が大きな課題でした。 

そこで私たちは、AIが実装完了した際のソースコードの差分を検出し、リポジトリ内の仕様書ドキュメントに対して自動で書き戻し（追記・更新）を行うコマンドを構築。 

この双方向同期ループを回しつづけることで、ドキュメントがつねに“システムの現在地”を示しつづけるようになり、次のIssue設計も常に最新かつ正しい仕様前提で進められます。 

仕組みがエンジニアの力量差をカバー。開発チーム全体の“品質の下限”を引き上げる

Issue駆動開発を導入した最大の成果は、AIモデルの性能や開発メンバーのスキルへの依存を抑えられることです。

私たちは、高度な推論やアーキテクチャの決定といったプロセスをIssue設計という人間の上流フェーズを主に切り出しています。 

そのため、異なるAIモデル（Anthropic、OpenAI、Googleなど）を利用しても、出力品質のブレが少なくなります。

実際、私たちのチームで実施した検証においても、最上位モデル（例：Claude 3 Opus）と中位モデル（例：Claude 3.5 Sonnet）を比較した際、最終的な実装品質に予想以上の差は見られませんでした。 

優秀な特定のエンジニアの個人スキルや、過剰に高性能なAIモデルの力に依存する開発から脱却し、仕組みによって開発チーム全体の“品質の下限（ボトムライン）”を引き上げる。

これが、Issue設計の真の価値です。 

AI時代のエンジニアの役割は、ハーネスエンジニアリングのデザイナーへ

仕様、実装、テスト、そしてドキュメントへの同期までもが完全に自動同期ループする未来の開発環境において、エンジニアが担うべき専門領域は、自らコードを書くことではなく、ハーネスエンジニアリングへとシフトしていく可能性があります。 

ハーネスとは、自律的に動くAIエージェントが暴走しないように敷く「制御用のレールと境界線の仕組み」です。

今後のエンジニアに求められるスキルは、コードを書く力ではなく、このハーネスをデザインし、適材適所にエージェントを配置して監督する能力が重要になると考えられます。 

そして、ハーネスエンジニアリングという新たな役割を担ううえで、エンジニアが実際に行うもっとも重要な役割が、先述のIssue設計レビューなのです。

これまでは出来上がったコードをレビューしていましたが、それでは手戻りコストが大きすぎます。 

これからは、AIにタスクを渡す前のチケット作成段階において、「完了定義は妥当か」「作業境界は正しく閉じているか」「実装方針に問題はないか」を人間同士で事前に議論し、合意形成を行う必要があります。 

現在、私たちは個人が受けたレビュー指摘などをMarkdownで蓄積し、自分特化のレビュー指摘エージェントをつくるなど、個人の特性に応じた最適化を実験しています。

今後は、個人の知見をチーム全体へ共有し、組織の資産として統合することを課題としています。 

標準化によって“品質の下限”を引き上げると同時に、個人のナレッジによって“品質の上限”を引き上げる。この両輪を回すことが今後の最適化に繋がると考えています。 

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

「計画通りのモノづくり」が揺らぐ、VUCA時代真っ只中の現代

プロジェクトマネジメントの世界で30年以上の経験をもつ私は、かつて成果物主義が当たり前だった時代を肌で知っています。

当時は、あらかじめ決めた要件を完成させ、QCD（品質・コスト・納期）に忠実であれば、お客様に喜ばれました。開発者も「つくり終えたらゴール！」と信じていたんです。 

なぜなら、当時は画一化された大量生産・大量消費の時代だったからです。

右肩上がりの経済成長のなかでは、成功の形もある程度決まっており、5年計画のプロジェクトであっても、完成時にはまだその価値が有効でした。 

しかし2020年代に入り、世界は一変しました。パンデミックによるリモートワークの急激な普及や、地政学的なリスクによるサプライチェーンの分断など、私たちの予測を超える大きな変化が日常的に起きています。

人々の価値観は多様化し、「これが正解」という画一的なニーズは姿を消しました。

こうした変化の激しい時代において、計画通りにモノをつくるだけではお客様の求める価値に追いつけません。

例えば、「RPAシステムをつくろう」とプロジェクトを進めていたのに、数ヶ月後には「生成AIの登場で前提がすべて変わってしまった」というようなゲームチェンジが平気で起こります。 

30年前の成功体験に縛られてQCDを満たした成果物を生み出しても、それが実際のビジネス環境で使えなければ価値はありません。

成果物のみに着目する手法では、変化のはやい時代への対応がむずかしくなる場合があります。

成果物から価値へ。世界基準が示すパラダイムシフト

では、そもそも成果物と価値は何が違うのでしょうか。 橋の建設をイメージしてください。つくられた橋そのものは目に見える“成果物”です。

しかし、橋をつくる真の目的は、「渋滞を解消したり、人々の生活を向上させたりすること」のはずです。橋がスケジュール通りに完成しても、目的が達成されなければ価値を提供できたとはいい難いでしょう。 

つまり、成果物とは「つくって渡すもの」であり、価値とは「受け取った人（受益者）に起きる変化や効果（意図した状況の実現）」なのです。

“価値重視”へのパラダイムシフトは、プロジェクトマネジメントの世界標準であるPMBOK®ガイドにも明確に表れています。 

第6版までは、いかに成果物を計画通りにつくるかというプロセスが重視されていました。しかし、第7版から第8版にかけて、PMBOK®ガイドは“価値重視”へと大きく舵を切りました。 

「価値こそがプロジェクト成功の最大の指標である」と明記され、成果物を生み出すことではなく、価値をどう実現するかに焦点が当てられるようになったのです。 

PMBOK®ガイドの変遷について詳述した記事も、ぜひご一読ください。

一方、アジャイル開発の指針ともいえる「アジャイルソフトウェア開発宣言」も、本質的に追求しているのは価値の最大化です。

例えば、それに記された12の原則には、「価値のあるソフトウェアをはやく継続的に提供する」「開発の後期であっても要求の変更を歓迎する」といった項目があります。 

ウォーターフォールしか知らない人から見れば、開発後期の仕様変更は「とんでもないこと」かもしれません。しかし、お客様の競争力という価値を守るためには、変化を味方につける必要があります。

アジャイルは単なる開発手法ではなく、価値を最大化するためのマインドセットなのです。

アジャイル対ウォーターフォールではない。開発手法は向き不向きでフラットに選ぶ

ここで陥りがちなのが「いまの時代はすべてアジャイルでやるべきだ」という誤解、およびアジャイルの形骸化です。アジャイルとウォーターフォールは対立するものではありませんし、両者に優劣があるわけではありません。 

現在、「アジャイルを推進すること」自体が目的化してしまっている企業が散見されます。

アジャイルという言葉だけを輸入し、実態はウォーターフォール開発というような「なんちゃってアジャイル」では、変化への対応力は得られません。 

重要なのは、アジャイルかウォーターフォールかの二元論ではなく、目的（価値の実現）にあわせて最適な手段を選ぶことです。 

実際、プロジェクトの特性によって適した手法はまったく異なります。

ゴールが明確で、変更がほぼ発生せず、絶対に失敗が許されないようなインフラ構築などは、緻密な計画を立てて進めるウォーターフォールが適しているケースが多くあります。 

一方で、正解がどこにあるかわからず、試行錯誤しながら新しいサービスを生み出すようなイノベーション度の高いプロジェクトでは、短いスパンで反復し、変化に対応しやすいアジャイルが適しています。 

日本市場ではウォーターフォールが圧倒的に多い一方で、欧米ではプロジェクトの特性にあわせて両者が約半々で使い分けられています。そして、両者の違いがわかっている企業は業績が抜きんでています。 

私は、日本企業がアジャイルをフラットに選べるようになるよう啓蒙したいと思い、活動をつづけています。

お客様が本当に実現したい価値は何かを見極め、それにもっとも適したアプローチをフラットな視点で提案・実行してほしいですね。 

方向性を共有し、リスクも分担する。発注者と受注者を超えた、真のパートナーシップへ

価値を重視するプロジェクトにおいて、もっとも重要なキーワードが“協働”です。 

従来の成果物重視のやり方では、プロジェクトの初期段階で要件を合意し、あとは完成時に出来栄えを確認するだけでした。

しかしVUCAの時代では、数ヶ月もコミュニケーションを取らなければ、完成したころには「いまほしいのはこれじゃない」というズレが生じやすくなっています。 

価値を実現するためには、刻一刻と変わる状況をお客様と共有し、つねに期待値をすりあわせつづける密なコミュニケーションが不可欠です。 

そして、協働を進めるためには、「発注者が命令し、受注者が従う」という固定的な役割意識を見直すことが重要です。 

何をつくるか（What）の要件を固定するのではなく、何のためにつくるのか（Why）という方向性を深く共有すること。そして、成功の果実だけでなく、プロジェクトに伴うリスクも両者で分担すること。

このような真のパートナーシップがあってはじめて、変化を恐れずに最善の解決策を模索することができます。

この協働の輪は、開発チームの内部だけにとどまりません。チーム内の壁を越えたら、次はチーム間の壁、そして最終的には発注側・受注側を含めた組織全体の壁を越えていく必要があります。 

多様な意見を尊重する敬意をもち、ともに成長を目指し、最終的には事業の利益や本来の目的を達成する。この一体感をもった組織づくりが、価値創出を支える基盤の一つになると考えています。

価値に向き合ってはじめて得られる。全員が幸せになる、三方よしの未来

つくって終わりの関係から価値を共創する関係へとシフトすると、プロジェクトの景色は一変します。 

「納品したから終わり」ではなく、「世に出したこのプロダクトを使って、次にどんな価値を生み出そうか」と、未来をいっしょに語りあえるようになります。

そこには、単なるベンダーとお客様という関係を超えた、長期的で安定的な信頼関係が生まれます。 

価値に向き合うことは、関わるすべての人を幸せにする”三方よし”の未来をもたらします。 

1.　お客様にとっての価値：変化に強い事業運営が可能になり、市場での競争力と成長を手に入れます。 

2.　開発チーム（受注者）にとっての価値：「いわれたからつくる」というやらされ仕事から解放され、「自分の仕事が誰かの役に立っている」という納得感と熱量を得られます。 

3.　個人（エンジニア・PM）にとっての価値：お客様の事業を深く理解し、幅広い課題解決に挑むことで、圧倒的な自己成長と新たな機会を獲得できます。 

「何をつくったか」ではなく「何を起こしたのか」。 

プロジェクトの真の成功は、生み出されたプロダクトが実際に使われ、人々の生活やビジネスに意図した状況をもたらしたときにはじめて達成されます。

成果物の先にある効果までをともに見届ける姿勢こそが、これからの不確実な時代を生き抜くための強力な武器となるのです。

SHIFTはこれからも、お客様と真のパートナーとして向き合い、変化に強いチームをつくり上げながら、お客様・チーム・社会の“三方よし”を実現する価値創出に挑みつづけていきます。 

あなたもいま、目の前にあるプロジェクトの成果物から視線を上げ、その先にある価値を見つめ直してみてはいかがでしょうか。 

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

AI活用を前提とした短納期プロダクト開発の幕開け

村田製作所 中矢氏：AIを活用した新規プロダクト開発は、チャレンジングな状況でスタートしました。というのも、私たちが越えなければならない高いハードルが同時に3つ存在していたんです。 

1つ目は、半年後にはリリースが求められるというビジネス上の要求があったことです。決められた期間内でのリリースが求められていました。 

2つ目は、村田製作所内でも事例の少ない、商用向けWebシステムの開発だったこと。確立された正解がないなかで、走りながら学習し、プロダクトを形にしていく必要がありました。 

そして3つ目のハードルが、AI活用を前提とした新しいチーム開発への挑戦です。そのために、村田製作所の内製開発メンバーと、SHIFTのメンバーによるスクラムチームを結成しました。 

村田製作所はAI駆動開発に力を入れて実装速度向上を狙い、SHIFT側には、村田製作所の別システムを開発した知見を活かして要求分析での支援を行ってもらう。これらを掛け合わせることで、短納期を乗り切ろうと考えました。

また、このプロジェクトでは、AIを使ってはやくつくるための環境も用意していました。内製チームには「開発速度を1.5倍以上向上する」という目標が課せられていたため、AIと親和性の高い技術スタックを採用しました。 

例えば、AIがプロジェクト全体を横断して参照しやすいようにソースコードを単一のリポジトリで管理するモノレポ構成を採用しました。

また、責務や関心を分離するクリーンアーキテクチャを取り入れ、AIが構造を理解しやすく、制御しやすい状態をつくりました。 

さらに、開発者の意図したコードをAIが高い精度で出力できるよう、仕様駆動開発（SDD）を取り入れたり、AI用のハーネス（実行環境）を整備したりと、生成速度と品質をコントロールする機構を初期段階でつくり込みました。 

この仕組みが功を奏し、プロジェクトが走りはじめると、開発初期から目標としていた「開発速度の1.5倍以上の向上」をあっさりと達成できたんです。

人間の手による従来の開発と比べて、スプリントごとに生み出される成果物（インクリメント）の量は目に見えて増えました。 

このスピード感には、プロダクトオーナー（PO）やステークホルダーからの評価も上々で、短納期のプロジェクトの達成も見えてきました。

スピードを追求した“先回り実装”は、すべて無駄になった

SHIFT 髙橋：AIの圧倒的な速さに刺激され、私たちは「もっと開発速度を上げられるのではないか」と考えるようになりました。そこで、従来の進め方を変える、新たな挑戦をしました。 

それまでは、画面とAPIをセットでつくって動作検証しながら進めていました。しかし、AIを使えばコードがあっという間に書けてしまう。

それなら、「先のフェーズで必要になるであろうAPIを、いまのうちに全部つくってしまおう」と考えたのです。

我々は最初から用意されたデザインを見て、「将来必要となるAPIであれば、簡易的なものであれば、AIで一気につくれば効率的だ」と捉えてしまったのです。 

最初は、この試みが成功したかのように見えました。5本ものAPIを一気につくり上げることができたからです。 

しかし、その後に要件がなくなったり、仕様が変わったり、そもそもそれまでつくってきたAPIで十分代用ができることがわかり、先行してつくった5本のAPIは、すべてが使われなくなりました。 

さらに、ただ無駄になっただけではありません。コードベースには使われないソースコードや、これまでと違う形式での仕様記述が残ってしまいました。人間にもAIにも読みづらい技術的負債となってしまったのです。

失敗から気づいた「YAGNI」原則の重要性。そしてアプローチの転換へ

SHIFT 髙橋：この失敗から、AIでどれだけはやくコードが書ける時代になっても、ソフトウェア開発の原則は変わらないと痛感しました。

それが「YAGNI（You Aren’t Gonna Need It）」原則、つまり「それはいまつくる価値があるのか？」という問いです。 

「最初からデザインがあるからつくる」のではなく、「スプリントごとに、いまつくる必要があるものを吟味し、一つずつ確認しながら進める」という当たり前の進め方の重要性をあらためて学ぶことができました。 

村田製作所 中矢氏：私たちの失敗の要因は、PO とデザイナーが作った初期デザインを、確定仕様のように扱ってしまった点にありました。

実際には、初期デザインはPOの頭の中のイメージを具現化しただけの“初期仮説”に過ぎなかったのです。 

プロダクトの中心となるコア機能については比較的確度が高かったものの、その周辺機能に関しては、ビジネスの状況やユーザー理解が進むにつれて変動しやすい特性をもっていました。

先回りしてつくった5本のAPIは、まさにこの「変動しやすい周辺機能」に関するものでした。 

この失敗を通して、私たちはリファインメントの進め方を根本から見直しました。これまでは、「この仕様をシステムとしてどうつくるか」「機能の振る舞いをどう実装するか」を主に議論していました。 

しかし、この失敗を経てからは「これは本当に必要な機能なのか？」「ユーザーに届けたい価値は何か？」をチーム全体で問い直す場へと再定義しました。

問い直すことで掴んだ、短納期リリースの成功

村田製作所 中矢氏：POを交えたリファインメントの結果、初期デザインに従うだけではなく、以下のような判断をPOとともにすることができるようになりました。 

・価値の不確かな機能のスコープアウト：主要な業務フローから外れる、ユーザー価値が曖昧な機能は思い切ってスコープから除外する。 

・管理機能の廃止と既存機能での代替：管理者用の特別な制御や画面を重厚に開発するのをやめ、既存の運用フローや簡易的な機能で充足させる。 

・簡易スクリプトによる代替：利用頻度やユーザー価値が低い機能については、システムとしての作り込みを行わず、バッチスクリプトなどでの代替を採用する。

「いま必要のないものはつくらない」「つくるにしても、もっともシンプルかつ最適な形を探る」。リリースするプロダクトのあるべき姿をチーム全体で考えることができたことが、その後の開発における大きな転機となりました。 

一連の経験を通して、私は「AIは増幅器である」という言葉の意味を身をもって知りました。AIは、開発速度を増幅してくれる反面、私たちが目的を見失えば「本来あるべき姿とのズレ」まで増幅してしまうんです。

今回、私たちはAIの速さに流されず、プロダクトのあるべき姿を問い直しました。その結果、不要なものをつくる時間を削り、短い期間のなかで本当に価値のある形に洗練させてリリースすることができました。

AI時代にこそ求められる、人間がプロダクトに向き合う価値

SHIFT 髙橋：今回のプロジェクトを振り返ると、もし従来通りの人間の手による開発だったなら、求められていた半年という短納期のリリースには間にあわなかったと思います。

AIの速さは、間違いなくプロジェクトを支える巨大な力でした。 しかし、速さを追い求めるあまり、無駄なものまでつくってしまった。

実装速度を上げるのはAIの役割ですが、「いま何をつくるべきか」「価値あるプロダクトとは何か」に向き直り、軌道修正するのは人間の役割なのだと強く実感しました。

また、DevとPO、内製とベンダーといった立場を超えて、いっしょにプロダクトのあるべき姿を考え、対話できたからこそ、最適な形でのプロダクトのリリースを迎えられたと思っています。 

AIによって誰もが簡単に、高速にモノをつくれる時代になりました。だからこそ、コードを書く前の対話が何よりも重要になります。

立場を超えて「これは本当に必要なのか？」と問い直せるチームの文化。それこそが、これからのAI時代にいままで以上に求められることになると信じています。 

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

年間約100万件にのぼる電話対応。品川区が取り組む自治体DX

品川区 西澤氏：現在の自治体は「深刻な担い手不足」と「業務量の増大」という二つの課題に直面しています。

日本の人口減少と高齢化により、2050年には高齢者の割合が約2.6人に1人になると予測されています。これにより、自治体職員の担い手不足が深刻化しています。

特別区（東京23区）の採用倍率はここ10年で3分の1まで低下しました。

職員の確保がむずかしくなるなか、年々変わる法制度への対応や、多様化する住民ニーズへの対応など、行政特有の業務は増えつづけています。

一方で、住民対応業務の多くにはアナログな業務がまだ残っており、住民との主要な接点も窓口や電話に集中しています。

そこで品川区が着目したのが生成AIを使った電話対応の自動化でした。

AIで対応できない内容は人へ引き継ぎながら、定型的な問い合わせはAIが担い、職員は判断を伴う対応に集中できる体制への移行を目指しています。

品川区の代表電話には年間約100万件の電話が寄せられており、戸籍住民課や税務課、国保医療課といった窓口系部署への問い合わせが大半を占めています。

そのため、本実証実験では、代表電話からの転送件数がもっとも多かった戸籍住民課の転入手続きを対象に設定しました。

「AIと人の役割分担」を明確に切りわけ

品川区 西澤氏：戸籍住民課のAs-Is（現状）の電話対応は、代表電話で受付担当者が要件を確認したあと、担当課へ転送し、オペレーターがFAQやマニュアルを参照しながら回答するという流れです。

回答がむずかしい場合は職員へエスカレーションしており、人手中心の対応を行っています。

To-Be（AI導入後）では、住民からの電話を直接AIが受けて要件を聞き取り、AIがFAQやマニュアルを参照して定型的な問い合わせに回答します。

AIが答えられない場合のみ人間のオペレーターへ、さらにむずかしければ職員へ転送する仕組みを実現しようと考えました。

以下の5点に期待し、Amazon Connectを採用することに決めました。

この取り組みでは、最初からすべてをAIに任せようとは考えていません。「何をAIに任せ、何を人が担うのか」という役割分担を切りわけていきました。 

AIには、一般的な問い合わせへの回答とマニュアルに沿って答えられることを任せ、AIがわからないことは人につなげてもらいます。

個別事情への配慮や例外的なケースの判断、専門部署との連携が必要な業務は人が担う領域として定義しました。

AI活用の現場で直面した3つの課題

品川区 西澤氏：この取り組みを進めるなかで、大きく3つの課題に直面しました。

1つ目は「条件や属性をどう聞き出すか」。
行政手続きは複雑な手続きフローや条件が絡みあっており、申請者の属性によって必要な案内や必要書類などが変わってきます。

例えば転入手続きでも、新規転入なのか、外国籍なのか、代理人による申請なのかによって必要書類が異なります。そのため、申請者の属性を正しく把握する必要がありました。 

2つ目は「知識や制度をどう読ませるか」。
元々使っていたExcelベースの業務マニュアルは、セルの結合が多かったり、画像データを使っていたりして機械可読性がよくありませんでした。

人間向けにつくられたものを、どのようにAIが扱える形にするのかが課題となりました。 

3つ目が「ハルシネーションをどう防ぐか」。 
転入手続きの問い合わせであっても、会話の流れのなかでマイナンバーカードや児童手当、国民健康保険といった関連手続きの話題に及ぶことがあります。

こうしたスコープ外の内容について、AIが誤った案内をしてしまうリスクをどのように抑えるかも重要なテーマでした。

多段階対話設計とAIネイティブ変換で挑んだ解決策

SHIFT 寅野：現場でみえてきた課題に対して、どのような技術的アプローチを実施したのか、2つご紹介します。

まず1つ目は、属性ベースの多段階対話設計です。 

問い合わせ者の属性の組み合わせによって、必要な案内が変わってくるため、一問一答形式では問い合わせ者の正しい属性を把握することができません。

そこで、問い合わせ内容の確認を終えると、問い合わせ者の属性確認を進めるという多段階の問い合わせ対応フローを設計しました。

Amazon Connectの標準機能にAmazon Bedrockを組み合わせ、 AIが利用者の回答に応じて必要な情報を確認する仕組みを設計しています。

従来のルールベースのチャットボットではなく、業務マニュアルをベースにしたRAG（検索拡張生成）と、AIオペレーターとして定義されたふるまいをAIエージェントが活用し、まるで人間のオペレーターのように「ご本人の手続きですか？」「転出証明書はおもちですか？」といった形で対話を進めながら属性を確認していきます。  

一方で、こうした対話を実現するには、AIが業務知識を正しく理解できることも欠かせません。

そこで必要になったのが2つ目のアプローチである業務マニュアルのAIネイティブ変換です。

既存のExcelベースの業務マニュアルは、セルの結合があったり、補足情報が欄外にあったりと、人間が文脈を補いながら読むことを前提につくられていました。

そのため、そのままRAGに取り込んでも、AIが正確に理解できず、適切な回答を生成できませんでした。 

そこで、AIエージェントが正しく回答できることに加え、職員の作業負担を最小限に抑える形で、Amazon Simple Storage Service（S3）に格納された業務マニュアルを、AWSとAmazon Bedrockを使ってAIネイティブな形式へ自動的に変換するアーキテクチャを構築しました。

ハルシネーションを防ぐために、変換プロセスのなかで決定木モデリングやセマンティックチャンキングも実施しています。

また、転入手続きに関する問い合わせ中に児童手当などスコープ外の質問があった場合には回答しないよう、ガードレールも設定しました。

自治体、SIer、プラットフォーマーの専門知を結集

品川区 西澤氏：今回の実証実験は、品川区とSHIFTさん、AWSさんとともに取り組んでいます。

自治体の業務現場における課題解決に向け、自治体とSIer、プラットフォーマーの方々と本取り組みを進められたことは、品川区にとっても非常によい機会になったと考えています。 

SHIFT 寅野：西澤様と同感です。技術的な対応が困難なところも、AWSのアーキテクトや、SHIFT社内の生成AIのスペシャリストの方々の力をいただきながら進めることができました。

各領域の専門家の力を結集して推進でき、よいプロジェクトになったと感じています。 

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）  

開発スピードの加速が招く “QA業務のボトルネック化”をどう防ぐか

近年、AIを活用した開発手法の進化により、プロダクトの企画から市場投入までのサイクルは劇的に高速化しています。ビジネスの競争力を高めるうえで、このスピード感は大きな追い風になっています。

しかし、その反面、開発される機能の量は爆発的に増加し、それに伴って品質を検証すべきテスト範囲も規模が拡大しています。 

開発のスピードがどれほど加速しても、つくられたプロダクトが正しく動くかを確認するQA業務の多くは、依然として人の稼働時間に依存しています。

限られた人員と時間のなかで膨大なテストをこなさなければならない旧来型のQA業務は限界に近づき、事業成長を阻むボトルネックになりつつあるのです。 

この課題を解決するうえで重要なのは、単純な人員の増強ではありません。人海戦術によるアプローチを脱却し、AIを活用してテストプロセスそのものの構造を抜本的に変革することにあります。

AI時代におけるQAの“あるべき進め方”とは？

SHIFTにおける従来のQA業務は、お客様から機能仕様書などのプロダクト情報をいただき、テスト計画やテスト設計（テストケースの作成）を行った後、お客様のレビューを経てテストを実行し、品質情報をフィードバックするという流れでした。

現在、私たちが取り組んでいるのは、この一連のプロセスのなかで、従来は人手で行っていたテスト設計と実行をAIで実施する取り組みです。

勤務時間やアサイン調整、キャッチアップによるリードタイムの増加など、人手でのテストの制約を取り除くことで、品質フィードバックをさらに高速化します。 

今回は、特に熟練の思考力が求められるテスト設計を、AIでどのように実現したのかに焦点を当てます。

機能テストを対象に「対象とするシステムを限定せず、弊社のテスト設計プロフェッショナルと遜色のない品質のテストケースをつくり出すこと」を目指しました。

AIへのインプットは、開発ドキュメントと弊社エンジニアが作成するテスト方針の2つに絞りました。

プロの暗黙知を体系化した「SQF」とAIの自己採点で、高品質を担保する

弊社の現場で運用するためには「人が理解し、必要に応じて修正できる成果物であること」が必要でした。そのため、アウトプットはテストコードではなく、自然言語で書かれたテストケースであることを要件としました。 

また、テストケースの書き方や粒度はこれまで手動のテスト設計で実践してきたとおり、SHIFT独自の品質保証標準「SQF」に準拠する必要があります。これにより、カバレッジやテスト実行時の可読性を担保します。 

SQFは、世界的品質保証標準（ISTQB、ISO／IEC／IEEE 29119）と年間4,000件の支援経験から得たナレッジを融合させたもので、テスト熟練者の深い思考プロセスや検証の観点、粒度の細かさ、正確な記述方法などを体系化した、いわば「プロの暗黙知を言語化したナレッジ集」です。

これを実現できたポイントは、大きく2つ挙げられます。 

1つ目は、SQFに基づいてテスト設計のプロセスを徹底的に分解したこと。 

AIへインプットを丸投げしても、成果物は安定しにくくなります。そこで、「スコープ決定」「ケース生成」「自己レビュー」といったSQFに準拠した役割ごとに、専用のAIエージェントを直列に配置したのです。 

さらに、このサイクルを何度も回し、過去のサイクルの成果物をブラッシュアップできるような構造としました。 

2つ目のポイントは、AIの実行プロセスに「三段階の実行レベル」を組み込んだことです。 

実行レベルの一段階目では、最初のAIエージェントが、インプットとなる機能仕様書やテスト計画書の妥当性を入念にレビューする段階とします。

また、テスト設計に必要な情報が不足していると判断した場合は、弊社のエンジニアが仕様情報を整備、またはテスト計画書を修正します。 

二段階目では、AIエージェントがテストケースを一通り生成します。ここでは、全体の構成や網羅性に抜け漏れがないかを確認し、案件で求められる品質に到達する見込みが立っているかを全体像から評価します。 

三段階目では、そのテストケースに対して、SQFに基づく10個の観点に基づき、AI自身が成果物を「100点満点」で自己採点します。

もし点数が基準に満たなければ、過去のサイクルの成果物をベースに、AIが自律的に修正とブラッシュアップを実行します。 

この自己採点とブラッシュアップのループは、スコアの向上が見られなくなる（精度が頭打ちになる）まで、何度も何度も自動で繰り返されます。 

単一のプロンプトを用いたAIへの丸投げではなく、妥協を一切許さずにAIの限界まで品質を高めつづけるこの仕組みこそが、人間の熟練者に匹敵するテストケースを生み出す源泉なのです。

12,000ケースのテスト設計期間を半分以下に

この新たなテスト設計手法は、実際の開発現場ですでに高い成果を上げています。 

例えば、12,000ケースに及ぶ大規模なプロジェクトにおいて、このAI駆動のアプローチを適用した結果、人手がつくるのと遜色のないクオリティを維持したまま、通常であれば1ヶ月を要するテスト設計期間を、わずか0.4ヶ月へと削減することに成功しました。 

私たちは、この取り組みで得られた知見と技術をSHIFTのサービスに組み込み、お客様への価値提供につなげていこうと考えています。今後の発信にもぜひご注目ください。 

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

このページの閲覧には JavaScript を有効にする必要があります。

]]> https://recruit-wp-prod.shiftinc.biz/career/library/id1552/ Wed, 19 Aug 2026 00:00:00 +0000 https://recruit-wp-prod.shiftinc.biz/?post_type=library&p=57295 JaSST’26 Tokyo 登壇レポート

全体工数の8割を占める欠陥分類。手作業と属人化の壁

石井：今回はAIを活用してソフトウェアテストの欠陥分析を劇的に効率化した取り組みについてお話しします。 

まずは、この話のベースとなっている「ODC分析」についてご紹介します。ODC分析とは、テストや本番運用で発生した欠陥（不具合）の情報を分類し、傾向の可視化と品質改善につなげる強力な分析手法です。 

従来、欠陥分析には、統計的分析（数の偏りを見る分析）と原因分析（なぜなぜ分析）の2つがありました。ODC分析はこの中間地点に位置しています。

約300件程度の不具合情報から全体の傾向を把握しつつ、一つひとつの欠陥の意味を捉えて改善アクションにつなげることができる、品質改善の切り札ともいえる手法です。

有用な手法であることは間違いありませんが、ネックになるのは、欠陥を分類しタグづけする作業が重労働であることです。お客様からいただくバグデータには、最初からきれいにタグがついているわけではありません。 

例えば300件のバグに対して、「修正対象は何か」「トリガーは何か」など、5〜10個のメトリクス（指標）を一つずつ人間の目で見て判断し、タグを付与していく必要があります。

実は、ODC分析の全工程において、この分類作業だけでも工数の約80％を占めており、期間にして約2週間もかかっていたんです。

山腰さん、現場ではこのあたりに課題があったようですね。 

山腰：そうなんです。ODC分析には大きく「分類」と「分析」の2つの工程があります。分類は膨大なバグデータにタグをつける作業です。

初心者にはむずかしく、現場では有識者への再鑑（ダブルチェック）依頼が飛び交うなど泥臭い苦労がありますし、教育コストもかかります。 

一方で、その分類後に「ここが怪しい」と深掘りしていく分析工程には、専門的な知識と経験が必要で、非常に属人的な作業になっています。 

しかもプロジェクトが終わればメンバーは分散してしまうため、2つの工程それぞれにおいて「プロジェクトごとに分類者の教育が必要」「分析できる有識者が限られる」という根深い属人化の課題を長年抱えていました。

石井：そこでAIが登場するわけですね。 

山腰：はい。分類にはコツがありますし、一方の分析にも実は有識者特有の“思考パターン”が存在することに気づいたんです。

どちらの工程もパターンがあるなら、AIの得意分野ではないか？と考えたのが今回の取り組みのきっかけでした。 

一番のボトルネックであり、全体の工数の8割を占めていた分類の壁。今日はそのなかでも特に、膨大な分類作業そのものをAIで自動化することについてどんな試行錯誤があったのか、詳細をお話しできればと思います。

自信満々に間違えるAI。分類自動化に立ちはだかった“5つの壁” 

石井：では実際にAI化を担当された吉澤さんに伺います。当初からスムーズに進んだのでしょうか？ 

吉澤：いえ、最初は全く上手くいきませんでした。まずAIに分類させる試みについて、直面した“5つの壁”をご紹介します。 

1つ目は、「入力の問題」です。障害票の書き方は、お客様やプロジェクトによって異なります。情報が揺らいだままAIに渡すと、前提情報がそろわず精度が落ちてしまうのです。 

山腰：現場のリアルな話をすると、綺麗に1件1枚のチケットになっているとは限りません。

なかには、Backlogで「こういうバグが出ました」「これってこういうことですか？」というチャットのやり取りが延々とつづいているものを読み解かなければならないこともありました。 

吉澤：2つ目は、「基準の問題（思考の壁）」です。人間が分類するときは、「要件定義書とプログラムの両方を直した場合は、根本原因である要件定義の方を重く見よう」といった暗黙の判断基準をもっています。

しかし、AIには「何を重く見るのか」という基準が共有されていないため、解釈がブレてしまうという課題がありました。 

そして3つ目が、「判断の問題」です。情報が足りない場合に、AIが勝手に決め打ちをしてしまうことがありました。 

山腰：ここが一番厄介でしたね。AIは、情報が足りなくて判断できない場合でも、「わかりません」とはいわないんですよ。 

複数の原因が絡みあっていて人間でも意見が割れるようなケースでも、AIは無理やりどれか一つを選び、自信満々に回答してくるんです。中身を見ると全然違うじゃないか、ということが多発しました。 

吉澤：さらに4つ目として、「結果の問題」がありました。AIの分類結果だけを出されてもその理由が見えないと、人間がレビューをする際に判断に困ってしまい、結果的に差し戻しが増えてしまうという課題です。 

最後の5つ目は、「応用の問題」です。AIは障害票に書かれている手順や内容を強く参照する傾向があるため、人間なら行間を読んで補完する“潜在的な検出パターン”を拾いにくいというケースがありました。

逃げ道を用意する？欠陥分類の精度を飛躍させる5つのプロンプト術

石井：そうした壁を、プロンプトの工夫でどう乗り越えたのでしょうか？ 

吉澤：前提として、ここで扱うプロンプトとは「AIに何を、どの形式で、どんな基準で出させるかという指示」のことです。 

1つの大きなプロンプトにすべての指示を詰め込むとAIの出力が不安定になるため、私たちは先ほどの壁に対応する「5つのプロンプト（整形から各分類までの5段階）」に分割して処理するアプローチをとりました。 

まず1つ目は、「入力品質の均一化」です。1つのプロンプトで処理するのをやめ、前処理として整形専用のプロンプトを挟みました。

どんな障害票が来ても、必ず「ID」「タイトル」「事象」「発生条件」「原因」「対処内容」という6項目の表形式に整理させます。 

ポイントは、「要約しすぎないこと」と「空欄を禁止すること」です。情報がない場合は「ない」と書かせることで、後続の分類プロセスへ渡すデータのばらつきを抑えました。

2つ目は、「判断基準のルール化」です。AIの解釈ブレを防ぐため、「要件定義 ＞ 設計書 ＞ プログラム」といったように、人間が暗黙で使っている優先順位をAIの仕様として明示しました。

もし複数の修正対象がある場合は、この優先順位に従って代表を一つ選び、選ばなかった他の要素は理由として保持しておくよう指示しています。 

石井：先ほど厄介だったといっていた、AIが自信満々に間違える問題はどう解決したんですか？ 

吉澤：3つ目の工夫「あいまいさの可視化」で解決しました。これが一番のポイントかもしれません。 

原因が複数絡みあっていたり、情報が不足していたりする場合に無理やりどれかを選ぶことを禁止しました。その代わり、「アルゴリズムかチェックか、どちらかあいまいである」というような救済カテゴリーを用意したんです。 

山腰：人間が分類していても、迷うものは必ず出てきます。その場合、有識者に再鑑を依頼していました。 

選択肢を増やしてあえて「あいまいです」と報告させることで、人間が後から再鑑する対象を全件ではなくグッと絞り込むことができたんです。 

吉澤：4つ目は、「結果と理由をセットで出力させること」です。分類結果だけを出力させると、なぜその結論に至ったのか人間にはわかりません。

そこで、分類した理由の出力を必須にし、さらにAI自身に「選んだ結果と理由に矛盾がないか」の整合チェックをさせました。 

山腰：これによって、「AIはどう考えて間違えたのか」が見えるようになりました。

間違えた理由がわかれば、「こういうときはこっちを選ぶんだよ」とプロンプトに具体例を追加してチューニングできます。間違いの傾向も見えて、精度向上のために非常に役立った工夫ですね。 

吉澤：最後の5つ目は、「AIに行間を読ませる」工夫です。

障害票に書かれた手順だけをなぞるのではなく、「実際（障害票通りのテストパターン）」と「潜在（そうテストすれば発見できたと判断されるパターン）」の2軸で分類させるようにしました。 

例えば「ログアウトして別ユーザーでログインしたら不具合が起きた」という事象から、「同一機能を別端末で同時操作しても起きたはずだ」といった潜在的な検出パターンをAIに推測させるんです。

これも理由を必須にすることで、より人間に近い深い分類ができるようになりました。

人間の思考を仕様化。わずか1時間で分類できるようになった

石井：結果として、どのくらいの成果が出たのでしょうか？ 

山腰：分類作業にかかっていた工数が、2週間からわずか1時間へと劇的に短縮されました。 

また、精度に関しても、人間2人が分類しても100%は一致せず、だいたい80％程度の一致率なんです。現在のAIの分類精度は、人間同士がやった時の精度とほぼ同等レベルにまで到達していると実感しています。

吉澤：今回学んだのは、AIに分類を丸投げするのではなく、「人間が普段行っている分類ルールや判断プロセスを整理し、仕様として言語化すること」が重要だということです。 

山腰：工数削減だけでなく、属人化の解消という当初の悩みにも光が見えました。 いまでは、ODC分析をこれからはじめる初心者に対して、AIが教育係として機能しています。

AIのおかげで分析のハードルが下がり、より多くの人が品質改善に関われるようになる。この裾野の広がりに、とてもワクワクしています。 

石井：最後に吉澤さん、今後のビジョンや取り組んでみたい野望はありますか？ 

吉澤：今後は分類だけでなく、その後の分析プロセスにもAIを適用していきたいです。 

分析にも、ある程度のパターンがあります。ベストプラクティスとの比較や異常値の発見、共通項を見つけ出すといった作業はAIの得意分野です。

AIと人間が互いの強みを活かすことで、より高度な品質保証の形を追求していきたいと考えています。 

石井：ありがとうございます。吉澤さんが執筆を担当したSHIFTの書籍『SHIFT流 AI時代のソフトウエアテスト』にも、これからの時代に品質保証の精度を高めるヒントが多数記載されています。 

同書に書ききれなかった“AI時代のエンジニアの生存戦略”や“エンジニアの真の価値”について言及した記事も、ぜひご一読ください。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）