AIQAのナレッジ構築について

2026/07/28時点のfreeeで運用しているAIQA（アイカ）のナレッジ構築に関する資料。

1. AIQAのナレッジ構築について 2026.07.28
2. ◆ 担当プロダクト：認証認可基盤 ◆ 経歴： - 2024.03.31 ⽴命館⼤学⼤学院 情報理⼯学研究科 修了 - 2024.04.01 freee株式会社⼊社 freee株式会社の新卒QAエンジニアの１⼈で、現在は freeeの認証認可基盤とAI駆動QAの推進を担当。 QAエンジニア 同じくフリー株式会社のren (@ropQa)⽒の設計したAI駆 動QA基盤を保守‧運⽤している。 川端宏知（tonchan） Hiroto Kawabata 2
3. • AIQA（アイカ）について • AIQAに必要なナレッジ アジェンダ • AIQAの現在のナレッジ構成 • プロダクト固有ナレッジの構築‧運⽤につ いて • 今後の展望 3
4. AIQA（アイカ）について
5. AI駆動QA基盤（AIQA / アイカ）について QA活動のすべてをプレーンテキストに置き換え、AIエージェントがQA活動を⾏うことを ⽬的としたAI駆動QA基盤 5
6. AI駆動QA基盤（AIQA / アイカ）について QA活動のすべてをプレーンテキストに置き換え、AIエージェントがQA活動を⾏うことを ⽬的としたAI駆動QA基盤 今回はここについて 話します 6
7. 全社で利⽤できる汎⽤基盤を⽬指して 現在、弊社は40以上のプロダクトを提供中 全てのプロダクトに対してAIQAが動作できる状態の汎⽤基盤を⽬指している 2つのアプローチで汎⽤基盤を⽬指している • 汎⽤化 ◦ どのプロダクトでも使える標準テストプロセスSkillsの整備 ◦ 多様なファイル形式（CSV, TSV, etc）への変換ツールなどの整備 • プロダクト固有化 ◦ プロダクト固有のナレッジを蓄積するためのテンプレート整備 ◦ プロダクト固有のSkillsを整備するための⽀援 7
8. AIQAに必要なナレッジ
9. 品質保証活動に利⽤しているナレッジ • 品質保証活動で利⽤するナレッジは⼤量に存在する ◦ テストベース（例：仕様書‧議事録‧コード‧過去のテスト成果物） 国際規格やシラバス（例：ISO‧IEC‧IEEE‧JIS‧ISTQB） ◦ ドメイン知識 ◦ アーキテクチャ ◦ etc... • 現在(2026/07/28)のAIの性能上全てのナレッジをコンテキストに⼊れることは難しい • またタスクによって、重要なナレッジと重要でないナレッジがあり区別する必要がある ◦ 「集められるだけ集める」のではなく、「何が必要か」を先に定義してから集める 9
10. AIQAに必要なナレッジをどう定義するか AIQAに必要なナレッジの定義 a. 特定のテスト⼯程でAIの成果物品質を変える b. MCPでは取得できない c. 陳腐化速度に対して再利⽤頻度が⾼い情報 例外：SSOT（⽤語定義‧仕様の⼀次情報）はMCPで取得可能でも必ず含める。全成果物の前 提となるため、毎回の参照成否に依存させない⽅がいい。 ※「成果物品質を変える」の判定 ＝ ナレッジ有無でのbefore/after⽐較が簡単。成果物がレビューを通るか を基準とする 10
11. AIQAの現在のナレッジ構成
12. 全体ナレッジとプロダクト固有ナレッジ • 全体ナレッジとプロダクト固有ナレッジに現在分かれている。 • 全体ナレッジ ◦ 標準テストプロセス定義 ◦ テストプロセスごとのルール 標準成果物テンプレート • プロダクト固有ナレッジ ◦ 補助テンプレートがあり、そのファイル‧ディレクトリ群を参考に埋める ▪ テスト戦略 ▪ ドメイン知識 ▪ 重篤度定義 ◦ 12
13. プロダクト固有ナレッジの補助テンプレート • プロダクト固有ナレッジテンプレート ◦ QA テストに関連するもの ◦ domain ▪ ドメインに関連するもの ▪ docs ▪ 仕様書や意思決定書など ◦ onbording ▪ オンボ資料 ◦ 13
14. プロダクト固有ナレッジの⽅針 ナレッジの運⽤⽅針を決めておかないとカオスな状態になりうるためざっくりとした⽅針を 作成している ナレッジの⽅針 • Evergreen∕ Snapshot に分ける ◦ 現在の正解を上書きするか、過去の記録を追加するかの違い • 情報の置き場所を明確に決める • 重複しない ◦ 同じ情報は1箇所だけ。必要ならリンクで参照。 • ⽭盾は Evergreen が 正 • SSOT を維持する ◦ ⼀意に正解を特定できる状態を保つ 14
15. プロダクト固有ナレッジの 構築‧運⽤について
16. プロダクト固有ナレッジをどう作るか • プロダクト固有ナレッジを作成しなければ成果物の品質向上が⾒込めず、⾃分たちの開発プ ロセスともマッチしない ◦ 国際規格などの知識だけを⼊れても、現状運⽤されている開発プロセスややり⽅がそれに 準じているとは限らず、不整合が発⽣する可能性がある • 最低限揃えた⽅が良さそうなものに関してはナレッジテンプレートにある ◦ しかしながら、テンプレートを⽤意するだけではナレッジは構築されなかった ◦ ナレッジ構築⾃体が属⼈化、個⼈のスキルやチームとの関わり⽅などに左右された 16
17. プロダクト固有ナレッジの構築がなぜ⾏われないか • そもそもナレッジの構築をするというタスク⾃体に問題があった • ナレッジ構築する⼈が増えない理由 ◦ そもそも何をナレッジとして揃えればいいかわからない ◦ 揃えたナレッジの活⽤⽅法や運⽤がわからない ◦ 構築はしたがナレッジが全てスナップショットになってしまい、運⽤コストが⾼い • 作成したナレッジをAI活⽤にうまく利⽤できない ◦ 作ったはいいが、AIQAにどう使わせるといいのかがわからない 17
18. ナレッジの構築‧運⽤‧利活⽤の⾃動化が鍵 • 全プロダクトに対してヒトが⽀援していくのには無理がある • ナレッジの構築‧運⽤‧利活⽤⾃体にAIを活⽤していく 対話形式での構築 安全なナレッジ運⽤ Skillsへの利活⽤ ‧ AIと対話形式でのリスト化 ‧リスクを抑えた最適提案 ‧ 構造をそのままSkillsへ freee内にある既存のナレッジ 群と仕様書をベースに、AIが ⾃動でインタビュー 社内規定やセキュリティリス クを徹底的に勘案。安全かつ 実⽤的な運⽤スキームを⾃動 で提案 蓄積されたナレッジの構造を ダイレクトに利⽤し、AIが⾃ 動で実⽤的な「Skills」を作成 する体制を整備 ‧ ⼀気通貫での作成 構築前の叩き台レベルまで、 すでにあるナレッジをフル活 ⽤して⼀括で作成 ‧ナレッジ起点のSkills提案 集約されたナレッジをベース に、常に最適な機能や解決策 を⾃動で提案 18
19. 今後の展望
20. AIQAのナレッジに関する今後の展望 • 今後の展望 ◦ ナレッジ構築の障害撤廃 ⼀部⾃動化まで進めたがまだ全てのタスクを⾃動化できたわけではない ▪ 暗黙知や古くなって使えなくなったナレッジの棚卸しなどまで⾃動化を⽬指す ◦ プロダクト横断機能への対応 ▪ 現状は単⼀プロダクトのナレッジしか想定できていない。 ▪ プロダクトを横断した機能群に対応するのが難しいため、全社と単⼀プロダクトの間 となる複数プロダクトナレッジにも対応できるような設計を⽬指す ◦ ナレッジ効果の測定 ▪ 現状、ナレッジの要否判定は⼈の感覚に依存している。 ▪ ナレッジ有無でのbefore/after⽐較や成果物のレビュー通過率を指標化し、「⼊れるべ ▪ きナレッジ」の判断を主観論争から切り離すことを⽬指す 20
21. ご清聴ありがとうございました