こんにちは、Yappli開発部 YappliQAグループの今西(@TKNW_Hitsuji)です。
2026年3月20日に開催された JaSST Tokyo 2026 で、
「AIエージェント×GitHubで実現するQAナレッジの資産化と業務活用」
というテーマで登壇してきました。本日はその内容と参加レポートをメインに記していきます。
登壇資料
はじめに
今回のセッションでは、QAナレッジが属人化しやすく、再利用しづらい という課題に対して、GitHubでナレッジを管理・改善しながら、AIエージェント経由で日々の業務に活用していく取り組みを紹介しました。
AI活用の話をすると、「どのモデルがよいか」「どのツールが強いか」に話題が寄りがちです。
一方で実務では、モデルそのものよりも何をインプットとして渡せているか が出力品質に大きく効いてくる場面が少なくありません。
今回の発表では、そうした課題意識をもとに、既存のQA資産をAIが扱いやすい形へ整備し、GitHub上で改善サイクルを回していく方法についてお話ししました。
なぜこのテーマで話そうと思ったのか
もともと私たちは、実装PRと仕様書をもとにAIへQA観点を生成させる取り組みを進めていました。
ただ、実際に試していく中で、出力に対して次のようなもどかしさがありました。
- 期待していた観点と少しずれる
- 一般論としては正しいが、今見たい粒度ではない
- 情報量が多すぎたり、逆にほしい観点が抜けたりする
この原因を整理していくと、AIに渡していたインプットは 仕様書 と PR が中心で、その機能に対する既存のQA観点そのもの が不足していることに気が付きました。
AIは一般的なQA観点を出すことは得意でも、チームやプロダクトに蓄積された具体的なQA基準までは、何も渡さなければ知りようがありません。
そこで、このギャップを埋めるために、既存のQA資産をAIが参照できる情報として扱える状態にしようと考えました。
上記の既存のQA資産を流用してAI活用を進めることに新規性や他組織での汎用性を感じたため、このテーマでプロポーザルを投稿することにしました（その結果採択）。
取り組んだこと
既存のQA資産を、AIが読める形に変換
発表の大きな柱の一つが、既存の機能QA観点をAIが扱いやすい形式へ変換したことです。既存の機能QA観点を CSVからMarkdownへ変換 し、その後 Gemini CLI のカスタムコマンドで YAML 形式の観点ファイルへ一括変換 する流れを取りました。
この変換を行った狙いは、単にファイル形式を変えることではありません。
人が読むために作られていた情報を、AIが検索しやすく、絞り込みや再利用をしやすい知識 に変えることが目的でした。
その結果、仕様書や実装差分だけでは拾いづらかった観点、たとえば過去の不具合から得た注意点や、実務で蓄積されたQA Tipsのような暗黙知も、AIの出力に反映しやすくなりました。
既存観点をフィルタとして利用
変換した既存観点は、単に保管するだけではなく、観点生成時のフィルタとして利用する 形にもしています。
これは実務上かなり重要でした。
仕様書やPRだけをインプットとして与えた場合、AIは広く妥当な観点を出してくれる一方で、対象機能に対して「本当にそこを見たいのか」というズレが起こることがあります。
そこで、対象機能に紐づく既存観点をフィルタとして加えることで、出力をその機能に寄せやすくしました。
結果として、観点の量をただ増やすのではなく、必要な方向に観点を絞り込む ための土台になっています。
GitHubで管理する意味
もう一つの柱が、QAナレッジをGitHub上で管理し、改善のサイクルを回せるようにしたことです。
GitHubで管理することで、少なくとも次の価値があります。
- 変更履歴を追える
- レビューを通じて品質を高められる
- 使って終わりではなく、改善内容を再び資産に戻せる
- 特定の個人の頭の中に閉じない形で共有できる
QA観点はどうしても、日々の検証や不具合対応の中で個人に蓄積しやすい情報です。
一方で、それがスプレッドシートや口頭共有のままだと、更新のきっかけや責任範囲が曖昧になりがちです。
GitHubに置くことで、コードやドキュメントと同じように、レビューされ、更新され、履歴が残る対象 として扱えるようになります。
AIの出力結果から「このQA観点が足りない」「このQA観点はもう古いので更新」といったように、それらをPRとして資産側へ戻せるのが大きい点でした。
発表で伝えたかったこと
今回の発表で一番伝えたかったのは、上記のAIアプローチ自体もそうですが、意外にもAI活用は地味な実践の積み重ねなので諦めず改善を続けよう という点です。
世間的な期待として「AIを使うからには大きな成果が短期(例えば2~3ヶ月)ででますよね？」という圧のようなものがあると個人的には考えている（もちろん成果を出すことも大事）のですが、
実際のQA現場でAIを使って感じるのは、短期での大幅な効率化やコスト削減は難しい現実です。何度もインプットやプロンプトを微調整をした上で少しずつ精度が上がって使える出力が増えていく、そのような感触です。
個人的にも弊社QAチームでのAI活用も苦労した（現在進行形でしている）のもあって、今回の登壇では「AI活用を諦めないで」を裏テーマのように設定して、資料にもメッセージを残していました。
JaSST Tokyo 2026に参加して感じたこと
JaSST Tokyo 2026 に参加してまず感じたのは、AIに関する話題が非常に大きな比重を占めていたことです。どのAIセッションでも、AIと共にQA活動をよりよいものにするにはどうすればよいかを、それぞれの立場で真剣に考え、実際に手を動かしていることが伝わってきました。
JaSST は QA の最前線の実践と情報が集まる場でもあるため、そうした発表を通して、弊社がAI活用において今どのあたりにいるのかを見つめ直す機会にもなりました。感触としては、活用の進み具合は想像以上に前へ進められている一方で、悔しいことにAIの力をまだ十分には引き出せていない、というものでした。
今回の参加を通じて、来年までにAI活用でどこまで到達したいのか、その目標感とそこへ向かうモチベーションを得られたことは、個人的にも大きな収穫でした。
おわりに
実は今回、JaSST Tokyoへの初プロポーザル＆初採択という実績を残しています。推測にはなるものの、採択理由として
- QA業務の中でAI利用が可能であること（＋色々試行錯誤していたこと）
- JaSST TokyoでAI関連が採択される流れがきていたこと
- 会社としてエンジニアのイベント参加を歓迎していること
の3点が噛み合った結果だと捉えています。このような恵まれた環境に感謝しつつ、来年も登壇できるようにこれから仕込みをしていこうと思います。
興味がある方はぜひ、カジュアル面談にきてくれると嬉しいです。
open.talentio.com
