GitHub × AIエージェントで実現するQAナレッジの資産化と業務活用
会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。
レビュー投稿日の情報になります
株式会社ヤプリ / Kugo Imanishi
メンバー / QAエンジニア
最終更新日投稿日
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 10名以下 | 2025年3月 | B to B |
| ツールの利用規模 | 10名以下 |
|---|---|
| ツールの利用開始時期 | 2025年3月 |
| 事業形態 | B to B |
アーキテクチャ
アーキテクチャの意図・工夫
【アーキテクチャ選定意図】
- ツール使用想定メンバーがエンジニア以外だったため、Web検索(AIセッションでも可)で解決策を見つけやすいツール をできるだけ利用
- 過去の経験からスプレッドシートなどの別サービスからAIエージェントに情報を渡す過程が面倒かつ煩雑になりやすいと思っていたので、如何に 楽に既存のQA観点やテストケースの情報を渡せるか を重要視
- 入力されるプロンプトやコンテキストによってアウトプットのブレが出にくいようにClaude Codeの SKILLやSUBAGENTといった機能でそれらの懸念をカバー
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
【背景】
- AIエージェントを使ってQA観点やテストケースを自動生成する取り組みを進める中で、出力がプロダクト固有のQA観点を欠いた汎用的なものになってしまう (インプットとしては仕様書とPRの情報を参照)
- 「その機能ならではのQA観点や過去の不具合情報などの知見」を渡すことで改善の傾向 が見られた
- 各機能のQA観点やテストケース自体の管理がスプレッドシートで管理されている+メンテナンスフローが上手く構築できていなかった ため、AIエージェントに情報を渡しにくかったり、嘘の情報をインプットして出力させてしまう可能性があった
【 (上記受けての) 課題】
- QA観点やテストケースの管理がスプレッドシートになっており、AIエージェントによる自律参照が困難
- メンバーによるQA観点やテストケースの メンテナンスコストが高く、現状の開発スピードに追加・更新が追いついていない
- 最新の仕様に追いついていないのでAIに情報を渡しても アウトプットの精度が低くなる 可能性が高い
どのような状態を目指していたか
【理想】
- QA観点やテストケースの管理・改善をAIに完全移譲
- QAメンバーがQA観点やテストケースの新規追加や提案された改善のレビューを担う、より上流の活動が業務としてのスタンダードになること
導入の成果
GitHubでQA観点やテストケースを管理するようになってから、以下の変化が生まれている
- QA観点やテストケースの 変更履歴が追いやすい
- スプレッドシートでは誰がいつ何を変えたかの追跡が手間だったが、GitHubのコミット履歴により観点の変遷が明確になった
- AIエージェントの出力精度が向上
- GitHub上で管理された最新のQA観点をAIへのインプットとして活用することで、仕様書に記載のない弊社独特のQA観点が出力されるようになった
- QA観点やテストケースの メンテナンスサイクルの高速化
- インプット間での矛盾や記載不足といったドキュメントの不備をAIエージェント側で検出できるようになったため、これまでできていなかった開発速度に合わせたドキュメント更新が可能になった
導入時の苦労・悩み
【前提】
- 導入時点でQAチームメンバーの 9割がGitHubでのソースコード (今回だとドキュメントがメイン) 管理未経験
【導入時の苦労】
- GitHubの操作に不慣れなメンバーから「CLIでの操作が覚えられない」「初期設定が難しい」という声が上がり、整備した仕組みがなかなか浸透しない
【アクション】
- QAチーム内で勉強会を定期的に開催
- オンボーディング用のドキュメントを作成
- 不定期や相談制で個別サポートを実施
導入に向けた社内への説明
上長・チームへの説明
【チームへの説明】
- スプレッドシートから脱却が可能 になり、なおかつ メンテナンスコストも減る
- GitHubにQAノウハウを蓄積することで テスト設計業務をAIに任せられる ようになるので、浮いた時間を別のQA活動に充てられる
- QAとしてGitHubを扱える状態になっていると開発陣とのコミュニケーションやE2Eテスト自動化への参画がスムーズになるため キャリア的にプラス となる
【上長への説明】
- 追加・改善の仕組みが上手く回ることで、組織全体からアクセスできる弊社独自のQAナレッジ集が出来上がり、開発段階から参照することで シフトレフトな体制を目指せる
- QAナレッジが個人に閉じない状態になるので、経験年数に左右されずにどの開発に対しても一定程度の品質を担保できる ようになる
※開発チームが既にGitHubを利用しており費用面でのツッコミは特になし
活用方法
【利用場面】
- 開発→QAに依頼されたタイミング
- PRがあればどのプロジェクト単位でも利用可能
- 既存のQA観点やテストケースを見直し・確認したいタイミング
- SKILLやSUBAGENTを使わずとも、管理できているQA観点やテストケースについてはいつでも確認が可能
よく使う機能
- コード管理
- GitHub MCP Server
ツールの良い点
- 追跡対象が いつ・誰に・どのように変更されたか が視覚的に追いやすい
- mainにマージするにはレビューを必須にしているので、追加時の質や体裁が一定程度維持できる
- GitHub MCP Serverを利用できるので、AIエージェントの一つのセッションから 同じ組織の別のリポジトリ(サーバーやフロント、アプリなど)の実装情報を参照できる
ツールの課題点
- エンジニア以外がゼロから セットアップするハードルが高い
- ネット上にGitHubの使い方記事は豊富にあるが、QA現場の実情だとその記事を読むこと自体がハードルになるケースが多い
※弊社では1人当たりセットアップ完了 (GitHubの設定〜手元のコードエディタでgitコマンドが叩けるようになるまで) まで、およそ1~2時間の個別サポートを実施
ツールを検討されている方へ
GitHubはエンジニア向けのツールというイメージが強いかもしれませんが、AIの登場によって
- 多少は効率的に導入手順を調べられるようになってきている
- ドキュメントの更新〜PRを出すまでの作業を任せられる
というように エンジニア以外の現場での活用ハードルも大幅に下がってきている と感じます。
どのQA組織にとっても、自社QAナレッジをいかに上手く活用・メンテナンスしていくかは長年の課題になっている現状も踏まえて、GitHubで管理するアプローチを検討してみると良いかもしれません。
株式会社ヤプリ / Kugo Imanishi
メンバー / QAエンジニア
株式会社ヤプリ / Kugo Imanishi
メンバー / QAエンジニア
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法

