GitHub × AIエージェントで実現するQAナレッジの資産化と業務活用

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

レビュー投稿日の情報になります

株式会社ヤプリ / Kugo Imanishi

メンバー / QAエンジニア

最終更新日2026/05/01投稿日2026/05/07

ツールの利用規模	ツールの利用開始時期	事業形態
10名以下	2025年3月	B to B

アーキテクチャ

【アーキテクチャ選定意図】

ツール使用想定メンバーがエンジニア以外だったため、Web検索(AIセッションでも可)で解決策を見つけやすいツール をできるだけ利用
過去の経験からスプレッドシートなどの別サービスからAIエージェントに情報を渡す過程が面倒かつ煩雑になりやすいと思っていたので、如何に 楽に既存のQA観点やテストケースの情報を渡せるか を重要視
入力されるプロンプトやコンテキストによってアウトプットのブレが出にくいようにClaude Codeの SKILLやSUBAGENTといった機能でそれらの懸念をカバー

【背景】

AIエージェントを使ってQA観点やテストケースを自動生成する取り組みを進める中で、出力がプロダクト固有のQA観点を欠いた汎用的なものになってしまう (インプットとしては仕様書とPRの情報を参照)
- 「その機能ならではのQA観点や過去の不具合情報などの知見」を渡すことで改善の傾向 が見られた
各機能のQA観点やテストケース自体の管理がスプレッドシートで管理されている＋メンテナンスフローが上手く構築できていなかった ため、AIエージェントに情報を渡しにくかったり、嘘の情報をインプットして出力させてしまう可能性があった

【 (上記受けての) 課題】

【理想】

GitHubでQA観点やテストケースを管理するようになってから、以下の変化が生まれている

QA観点やテストケースの 変更履歴が追いやすい
- スプレッドシートでは誰がいつ何を変えたかの追跡が手間だったが、GitHubのコミット履歴により観点の変遷が明確になった
AIエージェントの出力精度が向上
- GitHub上で管理された最新のQA観点をAIへのインプットとして活用することで、仕様書に記載のない弊社独特のQA観点が出力されるようになった
QA観点やテストケースの メンテナンスサイクルの高速化
- インプット間での矛盾や記載不足といったドキュメントの不備をAIエージェント側で検出できるようになったため、これまでできていなかった開発速度に合わせたドキュメント更新が可能になった

【前提】

【導入時の苦労】

【アクション】

【チームへの説明】

スプレッドシートから脱却が可能 になり、なおかつ メンテナンスコストも減る
GitHubにQAノウハウを蓄積することで テスト設計業務をAIに任せられる ようになるので、浮いた時間を別のQA活動に充てられる
QAとしてGitHubを扱える状態になっていると開発陣とのコミュニケーションやE2Eテスト自動化への参画がスムーズになるため キャリア的にプラス となる

【上長への説明】

追加・改善の仕組みが上手く回ることで、組織全体からアクセスできる弊社独自のQAナレッジ集が出来上がり、開発段階から参照することで シフトレフトな体制を目指せる
QAナレッジが個人に閉じない状態になるので、経験年数に左右されずにどの開発に対しても一定程度の品質を担保できる ようになる

※開発チームが既にGitHubを利用しており費用面でのツッコミは特になし

【利用場面】

開発→QAに依頼されたタイミング
- PRがあればどのプロジェクト単位でも利用可能
既存のQA観点やテストケースを見直し・確認したいタイミング
- SKILLやSUBAGENTを使わずとも、管理できているQA観点やテストケースについてはいつでも確認が可能

追跡対象が いつ・誰に・どのように変更されたか が視覚的に追いやすい
mainにマージするにはレビューを必須にしているので、追加時の質や体裁が一定程度維持できる
GitHub MCP Serverを利用できるので、AIエージェントの一つのセッションから 同じ組織の別のリポジトリ（サーバーやフロント、アプリなど）の実装情報を参照できる