AI活用率100％のQA組織をつくるまで

本記事は、LINEヤフーの技術カンファレンス「Tech-Verse 2026」のセッション「10x Speed With QA Agent Platform — How we scaled adoption from individual effort to organizational capability」の内容をもとにした記事です。

こんにちは。LINEヤフー株式会社 プロダクトQAユニットの上田洋平と福永誠です。

私たちは Tech-Verse 2026 で、QA組織のAIエージェント活用についてお話ししました。タイトルには「10x Speed」とありますが、この発表でいちばんお伝えしたかったのは、実はスピードの話ではありません。セッションのサブタイトルに込めた「How we scaled adoption from individual effort to organizational capability」——AI活用を、個人の努力から組織の能力へどう変えていったか、という話です。

AIが得意な人は、放っておいてもどんどん使いこなしていきます。難しいのはその先です。活用が一部の得意な人にとどまり、組織全体には広がっていかない。私たちの組織も例外ではありませんでした。本記事では、そこからどのようにして「全員が当たり前に使える」状態まで持っていったかを、ぶつかった壁も含めてお伝えします。

プロダクトQAユニットは、CTOドメインの横断組織に所属するQA専門組織です。福岡と東京に拠点があり、人数は20名ほどです。さまざまなプロジェクトを長期・短期で支援しながら、LINEヤフーのサービス品質を支えています。

QAというと「リリース前に不具合をチェックする人たち」というイメージを持たれることが多いのですが、実際の範囲はもっと広く、ユーザーが感じるサービスの品質から開発プロセスの品質まで、エンドツーエンドで品質に携わっています。

QAの業務では、プロジェクトが進む中で日々決まっていく事項、作られる成果物、そして文書化されない暗黙知まで、あらゆる場所に散らばった情報をキャッチアップし続け、テストの成果物に落とし込んでいきます。膨大な情報を正確な状態で維持し続けるのは、大変な作業です。一方で、この「膨大な情報を集めて分析する」という作業は、AIと非常に相性の良い領域でもあります。

この広範囲にわたる品質保証を効率化・加速させるために開発したのが、QA Agent Platform です。以下、QAAPと呼びます。

QA Agent Platform とは

QAAPは、OpenAIのコーディングエージェントである Codex（CLI / App）と組み合わせて使う、組織共通のテンプレートリポジトリです。QA用の専門スキルやセキュリティのガードレールをあらかじめ組み込んだGitリポジトリになっており、各メンバーはこれをForkして自分の環境に取り込むことで、同じ土台の上でAIエージェントを使えるようになります。GitHub Enterprise上で管理しているため社内の誰でも利用でき、セットアップでつまずきやすい箇所はシェルスクリプトが自動で設定します。

利用の流れはシンプルです。ユーザーがCodexにタスクを依頼すると、依頼内容に応じて社内のさまざまなMCP（Model Context Protocol）サーバーとつながって情報を収集し、QAの専門知識をインプットしたタスクごとの専門スキルがテスト成果物を作成します。そしてこのワークフローのあらゆるタイミングで、セキュリティリスクにつながる入力を監視・ブロックする多層防御が働いています。この多層防御については、後ほど詳しく紹介します。

QAAPを組織全体で使うようになり、次のような効果が出ています。

※ いずれもプロダクトQAユニットのQA業務（テスト実行を除く）を対象とした社内測定値です。

対象業務の作業時間は5割近く削減され、成果物の生成数は約1.5倍に増加し、成果物の7割近くをAIが代替するようになりました。生産性が向上したことで、人間がやるべき業務に集中でき、次のAI活用を考える時間も確保できる状態になっています。

ただし冒頭に書いたとおり、この数字そのものは本記事の主題ではありません。ここに至るまでに越えた「2つの壁」についてお話しします。

組織のAI活用を阻む、2つの壁

QA組織全体でAI活用を進める中で、私たちはいくつもの壁にぶつかりました。今回はその中から、多くの組織で同じことが起きているであろう2つに絞ります。

壁1: アクセルとブレーキを同時に踏む

組織としては、みんなにもっとAIを使って業務を加速してほしい。これは強く踏みたいアクセルです。一方で、安全面では対処すべきリスクがあり、そこはしっかりブレーキを効かせたい。この一見矛盾する2つを、組織全体で同時に成立させる必要があります。

壁2: 一部の人だけでなく、組織全体へ広げる

アーリーアダプター気質の人は、放っておいてもどんどんAIを使いこなしていきます。それ自体はとても良いことです。ただ、そのノウハウは暗黙知になっていきがちです。誤解のないように補足すると、上手な人が意図的に隠しているわけではありません。むしろ、やり方を惜しみなく共有してくれる人のほうが多いくらいです。それでも、他の人が同じことを再現するのは、さまざまな要因で難しい。同じ悩みを持つ組織は多いのではないでしょうか。

この2つの壁に対して、私たちは「仕組み（Systems）」と「仕掛け（Initiatives）」の両輪で取り組みました。

壁1を「仕組み」で解く

まず壁1、アクセルとブレーキの話です。

先にお断りしておくと、アクセル側——QA業務をひと通りカバーするプリセットスキルの話は、それだけで1本の記事になる分量のため、今回は割愛し、また別の機会にご紹介できればと考えています。組織的なAI活用というテーマに直結するのは、むしろブレーキ側です。

リスク対応は、個人の注意力ではスケールしない

AIを取り巻く環境では、無視できないリスクが毎日のように出てきます。機密情報の取り扱い、プロンプトインジェクション、サプライチェーン攻撃などです。本来は業務効率化に向けてアクセルを踏み続けたいところですが、こうした問題が出てくるたびに急ブレーキを踏み、対応に追われることになります。

さらに組織の立場からすると、より困難な問題があります。その対応を各自が適切にできているか、リスクを理解して正しく使えているか——その実態を一人ひとり正確に把握するのは、現実的ではありません。つまり、対策を個人の注意力に任せるだけでは、組織として安全を担保できないのです。

そこで私たちは、リスクへのガードレールをあらかじめ組み込んだ基盤としてQAAPを整備しました。チームや利用者ごとにForkして、AIエージェントを使うときのホームベースにしてもらう運用です。ガードレールの整備・更新は大元のUpstream側で一元管理し、各自はSyncするだけで、組織全体の対策が揃う仕組みになっています。

多層防御——1つすり抜けても、次の層で止める

ガードレールの中身も紹介します。ベースにあるのは多層防御という考え方です。対策を何重にも張っておき、1つすり抜けても次の層で止める状態をつくっています。

例として、APIキーやトークンといったシークレットへのガードレールを見てみます。パーソナルアクセストークンを .env ファイルに平文で置いてしまうと、万が一端末やリポジトリが侵害された際に外部へ漏れるリスクが高まります。そのためQAAPでは、シークレットは1PasswordやKeychainなどの暗号化ストレージで管理し、必要なときだけ安全に取り出す方針にしています。

重要なのはここからです。この方針は、利用者一人ひとりの心がけに頼るのではなく、仕組みとして自動的に守られる形にしています。シークレットに対しては、3つの層でブロックを重ねる多層防御です。

• まず「入口」です。ユーザーがAIへプロンプトを送信する際、APIキーやトークンに共通するパターンの文字列を検知すると、データがAIへ渡る直前で送信を止めます。
• 次に「実行時」です。そもそも .env や環境変数からシークレットを直接読み出せないよう、Codexの実行ポリシーでブロックしています。
• そして「出口」です。万が一入口をすり抜けた場合に備えて、プルリクエスト作成前の静的チェックで、生成したコードやスキルが平文の秘密ファイルに依存・参照していないかを、入口とは別の角度から検証します。

ブロックするだけで終わらせない

もうひとつの工夫は、ガードレールに「教える」役割を持たせていることです。

ガードレールに引っかかったその場でアラートを出し、なぜブロックされたのか、どう対応すればよいのかを、ガイド資料への誘導つきで伝えます。実際に利用者からは「この通知をきっかけに、リスク対策の必要性や対処法を理解できた」という声がありました。リスクを自動で防ぎながら、利用者の理解も同時に進む構造です。

このほかにも、npmは社内の安全なレジストリのみを使い、インストール時にスクリプトを自動実行させない設定を既定で有効にしています。また、AIエージェントならではの操作リスクへの備えとして、rm のような取り消せない削除コマンドは実行させず、ゴミ箱への移動など復元可能な操作に限定しています。「AIが誤ってすべて消してしまい、もう元に戻せない」という最悪のケースまで、設計の段階で防いでいます。

なぜ、ここまでやるのか

ここまでの内容は、セキュリティに詳しい方にとっては、ある意味当たり前のことに映ったかもしれません。にもかかわらず、なぜここまで細かく作り込んでいるのか。この部分が、このパートでいちばんお伝えしたいポイントです。

これらのガードレールには、共通する目的があります。次に挙げる「苦手な特性」に備えることです。

• 指示したとおり、正確にタスクを実行すること
• 大事な決まりごとを覚えておくこと
• 書かれている文章を読んで、正しく理解すること
• わからないことは、わからないと言うこと
• 足りない情報は、自発的に調べること

どれも、できて当たり前に見えるものばかりです。

しかしこれは、AIの話ではありません。人間の話です。

私（福永）自身にも、痛いほど当てはまります。「言わなくても分かるだろう。書いてあるから読むだろう。わからなければ、調べたり聞いたりしてくれるだろう。」——そうした期待がことごとくすれ違った経験は、誰にでもあるのではないでしょうか。そして、当たり前だと思っていたことほど、すれ違ったときに致命傷になります。

「AIは日々変わるのだから、いま作り込んでもすぐ陳腐化するのではないか」という疑問もあるかもしれません。たしかに、AI側の変化は非常に速いです。だからこそQAAPは、変わらないものに着目しました。AIを利用する側である、人間の苦手な特性です。

人の注意力に頼らず、仕組みで止める。 これがQAAPの一貫した設計思想です。

壁1の結論をまとめます。自動ブレーキを標準搭載し、利用者はアクセルに集中する。この役割分担で、アクセルとブレーキの矛盾を解きました。

ただし、仕組みを渡すだけでは、全員が使うようにはなりません。それが残る壁2です。

壁2を「仕掛け」で解く

ここからは、AI活用を一部の人から組織全体へ広げる話です。

先に種明かしをすると、私たちがやったことは「現状を知る → 打ち手を考えて改善する → 計測する」というループを回し続けた、それだけです。特別なフレームワークは何もありません。シンプルなカイゼンのループです。ただ、簡単そうに見えて、実際に回し続けるのはなかなか大変でした。順を追ってお話しします。

「やれることは一通りやってきた」つもりでした

実は、QAAPを開発する1年前から、生成AIの利活用推進は組織として行っていました。

• AI専用のSlack相談チャンネルを開設し、気軽に相談できる環境を整備
• テーマを絞った分科会を3ヶ月サイクルで運営し、アクティブラーニングの機会を提供
• ライトニングトーク会を開催し、アウトプットの機会を創出
• 毎月の全体集会で方針や最新トレンドを共有し、組織全体の理解を統一
• 目標設定に早期からAI関連項目を組み込み、メンバーの行動を後押し
• 1on1での個別フォローも適宜実施

場は作り、情報は惜しみなく発信し、個別のフォローもしていました。推進する側としては、やれることは一通りやってきたつもりでした。

しかし、その先のアクションは個人に委ねられており、行き着く先はいつも「各自で頑張る」でした。

組織全体のレベルが上がっている手応えは、正直に申し上げると薄いものでした。活用度合いにばらつきが出ている感覚はあるものの、個々がどのように使っているかまではわかりません。そこで一度、現在地を正確に知るために、組織としての利活用度合いを可視化することにしました。

現在地をデータで知る

作成したのは、AIスキル成熟度モデルです。DeNA社のAIスキル評価指標「DeNA AI Readiness Score（DARS）」を参考に、自部署用にカスタマイズしました。

• 参考: DeNA「全社のAIスキルを評価する指標『DeNA AI Readiness Score(DARS)』を導入開始」 https://dena.com/jp/news/5279/

Lv1〜2は、業務プロセスには組み込まれない補助的な使い方です。Lv3〜4になると、コンテキストエンジニアリングなどを駆使して、成果物や業務プロセスをAI主導で進められている状態です。

このモデルでアンケートを実施したところ、半数以上がLv1〜2という結果でした。一方で、Lv3〜4に達してAI駆動で業務ができているメンバーもいる。「ばらつきがある」という感覚が、データとしてはっきり見えた瞬間でした。

得意な人にはどんどん先に進んでほしいと思っています。その上で、組織の観点では、その力が組織全体に還元されて底上げにつながってほしい。「各自で頑張る」を解消しない限り、組織として先には進めません。だからこそ仕組みを作り、先を行く人のナレッジやノウハウを全員が使える状態にする——そう判断できたのは、組織の現状をデータで知ることができたからだと考えています。

まる1日、全員で福岡に集まる

データは揃いました。次は打ち手です。

最初に実施したのは、QAAPを組織全体に使ってもらうための、まる1日かけたオフラインハンズオンでした。東京拠点のメンバーや、名古屋在住のリモート勤務のメンバーも含め、全員が福岡に集まりました。複数のプロジェクト側の業務も、可能な限り調整してもらいました。実施は2026年2月。会社全体がまだオンライン中心だった時期に、あえてオフラインでの開催に踏み切りました。

なぜオフラインにこだわったのか。「各自で頑張る」の正体は、課題を個人に抱え込ませる構造だからです。

相談が来ないのは、使いこなせているからではありません。わからないから、相談できないのです。ナレッジ共有を聞いても、わからないうえに深くは聞けないため、翌日自分の業務に落とし込むこともできない。結局「やれる人だけがやる」状態に戻っていきます。それは組織として健全ではない、と考えました。

だからこそ、同じ時間に、同じ場所で、目の前で、一緒にやる。わからなければその場で「これはどうやるのか」と聞けます。ハンズオンは各自の実業務に適用するところまで設計していたので、翌日からそのまま業務で使えます。最初からやれる人は、まだやれていない人のサポートを同じPCで行う。この空気感は、オンラインでは決して作れないと感じています。コストも調整も大変でしたが、全員が最低限体験する機会を作ることがこのフェーズではいちばん重要だと判断し、踏み切りました。

ハンズオンは、スタートラインにすぎない

では、ハンズオンを実施したことで、すべてがうまく回り始めたかというと、そうはいきません。

ハンズオンはあくまで、全員が同じスタートラインに立つきっかけにすぎません。そこで終わってしまうと、また「各自で頑張る」に戻ります。定着させるには、改善のループを回し続ける仕掛けが必要でした。

そこで、再び現状の可視化に立ち返りました。全員が同じ土台に乗った後は、レベル分類より具体的な利用実態の把握が重要になったため、QAAP利用アンケートに切り替え、そのアンケートのデータを3つの場に同時に流し込む形にしました。

1つ目は、メンバー全員が参加する隔週のQAAP定例です。方針やアップデートの共有に加えて、アンケートをもとにメンバー同士でディスカッションする時間を設けました。悩みを一人で抱え込ませないための工夫です。2つ目は、QAAP推進チームの定例です。「このスキルの出力精度が低い」「こういうスキルが欲しい」といった意見や改善提案を、基盤の改善に反映します。3つ目はリーダー定例です。アンケートの傾向を見ながら、活用が進んでいないメンバーの障壁を特定し、個別フォローの戦略を立てます。

1本のアンケートが、横展開・基盤改善・個別フォローという3つの改善を同時に回している構造です。

なぜ、急に回り始めたのか

ここで1つ疑問が湧くかもしれません。情報共有も、定例も、働きかけも、以前から行っていました。それなのになぜ、QAAPを全員が使えるようになった途端、ループが回り始めたのか。

答えは、QAAPという共通の仕組みができたことで、「共有の解像度」が変わったからです。

全員が同じ仕組みの上に乗っているため、共通の土台で具体的なディスカッションができます。他の人の工夫も、自分の環境でそのまま再現しやすくなります。以前から行っていた施策のループに、「具体性」と「再現性」が生まれた。これが決定的な違いだったと考えています。

取り組みの結果

最近、社内で生成AIの利活用状況を組織単位で可視化できるようになりました。横軸にAI利用率、縦軸に利用回数の中央値を取った分布の中で、私たちプロダクトQAユニットは一番右上——利用率100％、利用頻度の中央値も全ユニットトップに位置しています。全員がAIエージェントを使いこなしている状態です。

もちろん、最初からこうだったわけではありません。地道な改善ループを回し続けた結果として、ここに行き着きました。そして、全員が当たり前に使える状態になっただけでなく、冒頭に紹介した数字——テスト実行を除くQA作業時間49.4％削減、成果物生成数1.54倍、AI代替率68.1％——という成果にも、はっきりと表れています。

DORAレポートとの答え合わせ

ここで、レポートを1つ紹介させてください。Four Keysで有名な、Google Cloud の調査研究チーム DORAです。DORAが2025年のレポートで、次の結論を出しています。

Successful AI adoption is a systems problem, not a tools problem. （AI導入の成功は、ツールの問題ではなく、組織のシステムの問題である） AI's primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. （ソフトウェア開発におけるAIの主たる役割は増幅器である。うまくいっている組織の強みを増幅し、苦戦している組織の機能不全を増幅する）

出典: DORA | State of AI-assisted Software Development 2025

• https://dora.dev/research/2025/

ここでいう「組織のシステム」とは、開発組織を支える基盤的な能力のことです。組織のシステムが整っていればAIは強みを増幅し、整っていなければ機能不全を増幅する。このレポートを読んだとき、自分たちがやってきたことの答え合わせをしてもらったように感じました。

One Last Thing——危機感と、率先垂範

最後に、この取り組み全体を振り返って、結局これが重要だったと感じていることが2つあります。危機感と、率先垂範です。

これは私（上田）自身の話です。ユニットリードという立場ですが、正直に申し上げると、2025年12月頃まで、私はAIエージェントを使っていませんでした。先ほどの成熟度モデルで言えば、Lv2〜3の間くらいだったと思います。一方で、当時から社内で「生成AI担当大臣」と呼ばれていた福永は、AIエージェントを使いこなしていました。

2025年の年の瀬、福永がSlackの雑談部屋で、AIエージェント入門のYouTube動画を共有していました。1時間30分という長さに気が進まない思いもありましたが、年末で時間もあったため視聴し、実際に自分で触ってみたところ——衝撃が走りました。目の前で、パラダイムシフトが始まっている。ものすごいスピードですべてを塗り替えていくAIを、使い倒す側に回らなければ、この先、組織も個人も生き残れない。強い危機感が生まれた瞬間でした。

ただ、危機感だけでは組織は動きません。そこで2つ目の率先垂範です。仕組みや仕掛けを動かす人間が、率先して先頭に立ち、行動によって模範を示すこと。「AIでスピード10倍だ」と言っている本人がAIを使っていなければ、説得力はまったくありませんし、誰もついてきません。言い出しっぺが、とことん触って、使って、詳しくなる。そうすることで戦略の具体性が増し、話に説得力が生まれます。これが何よりの推進力になると考えています。

おわりに

組織的なAI活用を阻む2つの壁に、仕組み（Systems）と仕掛け（Initiatives）の両輪で向き合ってきた話でした。技術的な壁はQAAPという基盤で吸収し、人間心理的な壁は、改善のループで愚直に向き合い続ける、ということです。

本記事の後半は、エンジニアリングというよりマネジメントの話に聞こえたかもしれません。ただ、LINEのCTOを務めた池邉智洋さんが、CTO就任時のインタビューで「マネジメントって、実はエンジニアリングだな」と語っています（エンジニアtype「【LINE新CTO池邉智洋】生粋の技術屋が組織マネジメントに苦しんだ過去から学んだ"開発チーム戦"時代の生き抜き方」）。組織戦略を立てたり、人と向き合ったりすることも、結局はエンジニアリング。だとすれば、本記事の後半でお話しした仕掛けの話も、エンジニアリングなのだと私たちは考えています。

• 出典: https://type.jp/et/feature/19656/

AIの活用が「各自で頑張る」で止まっている組織は、少なくないと思います。本記事が、その次の一歩を考えるきっかけになれば幸いです。