How We Verify — 開発が加速する時代に、意味のある検証を設計する

GREE Tech Conference 2026で発表された資料です。
https://techcon.gree.jp/2026/session/TrackA-5

1. How We Verify 開発が加速する時代に、 意味のある検証を設計する グリーエックス株式会社 AIX推進室 室長 安立健人
2. 安立健人 / @ken11 グリーエックス株式会社 AIX推進室 室長 Glossom、MoneyForwardなどを経て2025年より 再度GREE X（旧Glossom）に復帰 現在はグリーエックス株式会社でAIのプロダクト 実装を推進 NLPを中心に機械学習モデルの作成からデプロイ 運用まで一気通貫のスペシャリスト 2022年にラスベガスで行われたAWS re:Inventに 登壇 2
3. AIによって変化した開発現場 3
4. 速く作れる。でも、たしかさは？ AI駆動開発で、実装速度は大きく上がった コードを書く、修正する、テストを書く、レビューする。 ここまでは、すでにAIを使うことが前提になりつつある。 では、できあがったコードの「たしからしさ」は、 誰が、どうやって確認するのか。 この問いから、AI時代の検証設計を考える。 4
5. 「人間がレビューする」で足りるのか 従来の答え AI駆動開発で起きがちなこと 別のエンジニアがレビューする。 チームで相互に確認する。 誰かがAIに書かせたコードを、 別の誰かがAIでレビューする。 人間同士の相互レビューに見えて、 実態は「AIスタンドバトル」になりうる。 人数を増やすことと、検証の意味を増やすことは同じではない。 5
7. 「たしかさ」とは 7
8. 何をもって「たしか」とするのか 手段から離れて、目的を問い直す • 実装にバグがない • 想定したユーザーだけが操作できる • 権限を越えた操作ができない • 攻撃されても突破されない • 想定した業務フローが成立する • ユーザーが期待する操作ができる 本当に確認したいのは、 「コードがきれいか」 だけではない プロダクトとして 期待した振る舞いをしているか 8
9. コードの検証を捨てる話ではない コードレベルの品質担保は、むしろAIで徹底する ユニットテスト 型チェック lint / 静的解析 既存コードとの整合性 コードレビュー 生成コードを理解し責任を持つ これらは「土台」。 そのうえで、コードの外側まで検証範囲を広げる。 ホワイトボックスをやめるのではなく、ホワイトボックスだけで終わらせない。 9
10. 検証は「作業」ではなく「設計」する AIに聞く 人間が設計する 「このコード大丈夫？」 「バグない？」 「セキュリティ問題な い？」 何が壊れたら困るのか 期待 何が成立していればよいのか 基準 何を観測すれば確認できるのか 証拠 「誰に検証させるか」より先に、 「何をどう検証するか」を決める。 10
11. AIは検証も変えた 11
12. AIは「検証する側」も変えた 開発だけでなく、検証の実行コストも下がっている これまで いま 「やった方がいい」 でも、人手と専門性 が必要 QA / E2E / ペネトレーションテスト / シナリオ確認 / ドキュメント作成 AIを「作る側」だけでなく、 「確かめる側」にも投入できる。 これまで現実的でなかった検証を、開発プロセスに組み込める。 12
13. 例: ペンテストが「工程」に入ってくる AWS Security Agent （AWS Continuum）を例に ソースを読むだけではなく、 動いているアプリを実際に攻める。 • 対象URL・認証情報・コード・ドキュメントを渡す • AIがアプリを理解し、複数手順の攻撃を試す • 成立した攻撃と再現手順を findings として残す スポット実施から オンデマンドの 外側検証へ ここで重要なのは 「AIが実環境で攻撃を試せる」 ようになったこと。 ポイント：高コストでスポット的だった検証を、開発プロセスに組み込みやすくなる。 13
14. 例: AIが「ユーザー」になれる ブラウザを、人間と同じ経路で操作する 1 一般ユーザーで ログイン 2 権限のないURLへ 直接アクセス 3 閲覧できないことを 確認 コードを読むのではなく、 実際の画面・認証・権限・状態を通して確かめる。 特に「認証・認可」「複数サービスをまたぐ処理」「画面遷移」は、リアルなE2Eで価値が出る。 14
15. 例: 「テスト」以外の仕事も、検証にできる 操作マニュアル / 利用シナリオ作成を例に アプリを開く シナリオ通りに操作 一見すると「資料作成」 画面遷移を確認 スクショを取得 資料化する 実際には「利用シナリオを通したE2E」 成果物を作らせる「過程」そのものを、 検証として設計できる。 AIを導入すると、既存の開発・運用プロセスを「検証機会」に変換できる。 15
16. 求められる「プロダクト視点」 16
17. AIをたくさん並べればいい、ではない 検証はプロダクトのリスクから逆算する 業務Webアプリの例 認証・認可 データ境界 業務シナリオ だから開発者が決める • このプロダクトで、何が壊れた ら困るか • どんな失敗モードを捕捉したい か • その失敗を最もよく観測できる 検証は何か UIの1pxのズレ 「多角的に見る」≠「無闇に増やす」 17
18. AI時代、開発者にはむしろプロダクト視点が必要になる ユーザー 業務 セキュリティ 運用 誰が、何をしたいのか どのフローが成立すべき か 何を守り、何を許さない か どの失敗を早く気づくべ きか 「これをテストして」と定義 できれば、 実行はAIに任せられる。 でも「何をテストすべきか」は、 プロダクトを理解しないと 定義できない。 意味のある検証項目を定義する能力が、開発者側に残る。 18
19. ボトルネックが変わる これまで AI駆動開発 次のボトルネック 実装できるか 実装コスト ↓ 何を期待するか ↓ ↓ ↓ テストする 人手があるか 検証実行コスト ↓ 何を検証するか 定義できるか 希少になるのは「検証する手」ではなく、 「意味のある検証を設計する頭」 19
20. まとめ 20
21. How We Verify 1. 期待を定義する プロダクトにとって、何が成立していればよいのか 2. 検証を設計する どの視点で、何を観測すれば「たしか」と言えるのか 3. AIで実行する コードだけでなく、QA・E2E・セキュリティまで検証範囲を広げる AIで作って、AIに適当にレビューさせるのではない。 人間が「何を確かめるべきか」を決め、AIを最大限投入する。 21
22. ご清聴ありがとうございました 22