# タイトルコール ようこそ世界が広がるソフトウェア品質で、このチャンネルでは、 エンジニアリングマネジャー兼QAリーダーのサミーが、 ソフトウェアテストやソフトウェアの品質放送を中心に、 日々奮闘していることや考えていることをお話します。 毎日お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、テストや品質の世界を広げていきます。 # 📣11/13 20時からKaitouさんと生放送、12/6オフ会 2点お知らせです。 1つ目は、11月13日、木曜日ですね。 20時から、怪盗さんと生放送を行います。 「とけるデザイン」という本がありまして、 その本を題材にというか、 UI、UXについてお話をしていきたいと考えております。 そして2つ目は、12月6日にオフ会を行います。 場所は都内で、ソフトウェアレスト自動化カンファレンスの ライブビューイングと、あと私も登壇させていただきますので、 目の前で登壇しているところをお聞きいただけます。 登壇の内容とかも聞けますというところと、 あとそのカンファレンスの後はですね、 リンコーヒーという形式で色々ディスカッションですね、 そのカンファレンスの感想だったり、 何か深掘りしたいところとかあれば、 ディスカッションするという時間になっています。 そして夜は懇親会でご飯を食べながらゆっくり お話できたらなと思っておりますので、 ぜひコンパスからお申し込みお待ちしております。 この放送の概要欄に今後のイベントだったり、 あとコンパスのURL等入っておりますので、 そちらをご確認ください。 # ISTQBのTesting with Generative AIシラバスとは？ こんにちは、さみぃです。 今日もテストしていますか? 今回はですね、今気になっていること というトークテーマなんですけれども 最近見つけたシラバスがありまして ISTQBのTesting with Generative AI というシラバスが 割と最近出たんですね。 最近といっても2025年の7月ぐらい だったかなと思うんですけれど 今このシラバスがめちゃくちゃ 気になっております。 あとまずISTQBとはなんですけど インターナショナルソフトウェア テスティングクオリフィケーションボーディング の略だと思います。 要はインターナショナルなソフトウェア テストの認定資格とか ガイドラインとかを作っている 組織とか団体とかです。 いろんな種類のシラバスがあって ちょっとちゃんと数えてないんですけど 30とかそういうぐらいの種類が あるんじゃないかなと思います。 テスト自動化のシラバスだったり とか テストアナリストとかテストマネージャー とかモバイルテストとか いろいろあります。 今回ですね、私まだちょっと ちゃんとこの Testing with Generative AIのシラバス 読めてないので ちょっと詳細なことは 言えないんですけれど 代わりにノートブックエレムに このシラバスのPDFを入れて 音声での解説をしてもらいました。 この次のチャプターに 音声解説を載せております。 びっくりしたんですけど 音声30分ぐらいあります。 まだ私も最初の数分しか 聞いてないんですけど 経齢条件を作らせたら いいんじゃないかとか どういうふうにAIを活用するのか ということが書いてあって おしゃべっていて、これはぜひですね ちゃんとシラバスも 読まないといけないな というふうに思いました。 なので今回この放送で 音声解説をアップロード というか載せている意図としては ぜひ他の方にも このシラバスの存在を 知ってもらいたかったというのと 読まなきゃと思っていただきたいのと この放送をきっかけに シラバスを読むという行動を ネクストアクションに つながったらいいなと思って 今回この放送にしております。 私もまたこのシラバスを読んで これはぜひ共有したいなとか ここ良かったなと思ったことがあれば 別途放送で共有できればな というふうに思っております。 ということで次のチャプターは ISTQBのTesting with Generative AIの シラバスの音声解説です。 # 概要の音声解説 こんにちは。今日の探究へようこそ。 今回はソフトウェアテストという、品質を支える非常に重要な、しかし普段はあまり光が当たらない分野にですね、 生成AI、いわゆるGenAIがどのような変革をもたらそうとしているのか、深く掘り下げていきます。 情報源はソフトウェアベストの専門資格として知られる ISTQBが公開した、生成AIによるテスト、CTGenAIの最新シラバスV1.0です。 これはまさにこの分野のプロフェッショナル向け 最先端ガイドラインと言えるでしょう。私たちのミッションは、この文章から、GenAIがテストの実務をどう変えつつあるのか、 どんな新しいスキルが求められ、まあどのようなリスクに注意すべきなのか、その確信となる知識をあなたにお届けすることです。 ソフトウェア開発とか品質保証に関わる方、 あれは技術の最前線に強い関心を持つあなたにとって、きっと刺激的な時間になるはずです。 まさにその通りですね。あのGenAIの進化のスピードは本当に目覚ましくて、多くの技術分野に影響を与えています。 ソフトウェアテストもその影響から逃れることはできません。 今日の探究を通じて、GenAIがテストにもたらす具体的な変化、 そしてこれからのテスト専門家に求められるであろう考え方やスキルセットについて、 あなたと一緒に明らかにしていければと思います。 では早速このISTQBシラバスを紐解いていきましょうか。 まず基本の基ですけど、ここで言う生成AIっていうのは具体的に何を指すんでしょう? AIと一口に言ってもいろいろありますよね? そうですね。 AIの歴史をたどると、まずルールベースの記号AIから始まって、 データからパターンを学ぶ古典的機械学習、 そしてより複雑な関係性を捉えるディープラーニングへと進化してきました。 そのディープラーニング技術、特に大規模言語モデルLLMですね。 これを活用してテキスト、コード、画像、音声といった全く新しいコンテンツを生成するのが生成AIというわけです。 膨大なデータで事前学習されてて、人間が書いたような自然な文章を作り出したり、 あとは文脈を深く理解したりする能力を持っているのが特徴です。 LLM、最近本当によく耳にします。 ソフトウェアテストっていうその文脈で、特に理解しておくべきLLMの基本的なコンセプトってありますか? いくつか重要な概念がありますね。 まずトークン化。これはテキストをモデルが処理できる最小単位、トークンって言うんですけど、 それに分割するプロセスです。 モデルが言語を数値的に扱うための基本的なステップですね。 次にコンテキストウィンドウ。これはですね、モデルが一度に処理できる情報。 いわばワーキングメモリーのサイズのようなものです。 例えば長いテストログ全体を一度に分析させようとしても、 このウィンドウサイズを超えた部分は考慮されない可能性があるので、その限界を知っておくことが非常に重要になります。 なるほど。一度に扱える情報量に制限があると。 これは実務で意識しないといけない点ですね。 その通りです。そしてもう一つ、非常に可能性を秘めているのがマルチモーダル能力です。 これはテキストだけでなく、画像や音声といった複数の異なる種類のデータ、 モダリティって言いますけど、これを同時に扱える能力を示します。 テストにおいては特にGUI、つまり画面のテストで強力な部置になります。 スクリーンショット、画像ですね。それと要件定義、テキスト。 これを組み合わせて分析できるビジョンランゲージモデルを使えば、 例えば画面デザインが仕様通りかとか、表示されている文言が適切か、みたいなそういうチェックを支援させることが可能になります。 画像とテキストを一緒に扱えるというのは、テストの幅が格段に広がりそうですね。 具体的にテスト担当者はこれらの能力を日々の業務でどう活用できるんでしょうか? はい。シラバスには実に多様な活用例が挙げられています。 例えば、要件分析の支援ですね。 要件定義書を読み込ませて、曖昧な記述とか矛盾点を指摘させるといった使い方です。 また、テストケース、テストデータ、テストスクリプトの生成補助。 これは非常に期待されている分野ですね。 ユーザーシナリオから基本的なテストケースのコシを生成したり、 境界値分析のようなテスト技法に基づいてテストデータを提案させたり、 あるいは、テストケース記述から自動化スクリプトのテンプレートを生成させたり、 さらにテスト結果の分析。 膨大なテストログから異常なパターンを検出分類したり、 発見された欠陥レポートの要約を作成したりといった支援も考えられます。 テスト関連文書のサポートなども含めて、文字通りテストプロセス全体にわたって活用できるポテンシャルがあると言えます。 まさにプロセス全体に影響が及ぶんですね。 利用形態としては、よくあるチャットボットのような対話型だけなんでしょうか? 主に一つの形態が考えられますね。 一つはおっしゃる通り、AIチャットボット。 自然言語で質問を投げかけたり、指示を出したりして、対話的に応答を得る手軽な方法です。 テストに関する疑問点の解消とか、比較的簡単なタスクの依頼に適していますね。 もう一つは、LLM搭載のテストアプリケーション。 こちらはテスト管理ツールとか自動化ツール自体に、APIなどを介してLLMの機能が組み込まれている、そういう形態です。 よりシームレスに、例えばテストケース生成とか欠陥分析といったタスクを、ツールの一機能として実行できます。 どちらの形態を利用するにしても、その効果を最大限に引き出す鍵は、AIに対する指示、すなわちプロンプトの質にかかっています。 そのプロンプトが重要だという話、よく聞きます。 ここがGAIを使いこなす上での何か肝になりそうですね。 ただ、漠然とテストケースを作ってとお願いするだけでは、期待する結果は得られない、ということでしょうか。 まさにその通りです。良い結果を得るためには、AIに何をさせたいのかを明確かつ、具体的に伝える必要があります。 シラバスでは、効果的なプロンプトの構成要素として、6つ挙げていますね。 役割、ロール、AIにどのような専門家、例えば経験豊富なモバイルアプリのテスターとしてといった、なりきってほしいか。 コンテキスト、背景情報ですね。これからテストするECサイトの新機能についてとか、指示、インストラクション、実行してほしい具体的なタスク、 以下のユーザーストーリーに基づいて受け入れテストケースを生成してください、みたいな。 入力データ、処理対象の情報、ユーザーストーリーのテキストそのものとかですね。 制約、コンストレインツ、守ってほしいルール、出力は表形式でとか、セキュリティに関するテストは含めないでください、など。 そして出力形式、アウトプットフォーマット、期待する応答の形です。 過剰書きでとか、JSON形式でとか、これらを意識的に構造化することが推奨されています。 非常に具体的ですね。なんか、まるで料理のレシピのように、材料とか手順、注意点を細かく指定する、そんなイメージでしょうか。 ああ、良い例えですね。優れたレシピが良い料理を生むように、練られたプロンプトが良い結果を引き出すわけです。 さらに、プロンプトの質を高めるためのテクニックもいくつか紹介されています。 例えば、プロンプトチェーニング。これは、複雑なタスクをいきなりAIに丸投げするんじゃなくて、より小さなステップに分解して、 各ステップの出力を人間が確認・修正しながら、その結果を次のステップの入力として渡していくという手法です。 一歩ずつ、AIと対話しながら精度を高めていくアプローチと言えますね。 一度に完璧を目指すんじゃなくて、段階的に精度を上げていくわけですね。 他にはどんなテクニックが? 対しては、こういうテストケースを出力してほしいという例を2、3個示すわけですね。 例がゼロならゼロショット、一つならワンショット、複数ならフューショットと呼ばれます。 特定のフォーマット、例えば、ギブン・ウェン・ゼン形式で知られるガーキンスタイルでテストケースを書きたい場合なんかに特に有効です。 例を似せることで、AIにこういう風にやってほしいと教えるわけですね。 なんか人間に教えるのと似ていますね。 そうかもしれませんね。 そしてもう一つ非常に興味深いのがメタプロンプティングです。 これはAI自身に対して、このタスクをうまく実行するためのもっと効果的なプロンプトを考えて提案してと依頼したり、 今使っているこのプロンプトを改善するにはどうすればいいとアドバイスを求めたりするアプローチです。 いわば、AIと協力してプロンプト自体を最適化していくという少し高度な使い方ですね。 AIにプロンプト作成を手伝わせる。それは賢い使い方ですね。 これらのプロンプト技術は実際のテスト作業のどの場面で応用できるんでしょうか。 はい。シラバスの第2.2節には具体的な応用シナリオが豊富に紹介されています。 例えばテスト分析の場面。 先ほど話に出たマルチモダルな能力を活用して、ユーザーストーリーのテキストと画面デザインのワイヤフレーム画像を入力として受け入れ基準を生成させることができます。 あるいはプロンプトチェーニングを使って、まず要件定義書から曖昧な箇所を特定させて、 次のステップでその曖昧さを解消するための質問リストを生成させるといった段階的な分析も可能です。 テスト設計実装のフェーズでは、Few-Shotプロンプティングを使って、特定の記述スタイル、例えばゲーキン形式ですね。 そのテストケースを効率的に生成させたり、あるいはリスクレベルとか機能間の依存関係といった情報を入力として、 テストケースの実行優先順付けをAIに提案させたりといった活用が考えられます。 自動リグレッションテストの文脈では、キーワード駆動テストのような特定のフレームワークに合わせたテストスクリプトの作成支援とか、 テスト実行後に生成される大量のログレポートを分析させて、失敗したテストの傾向とか要件をまとめさせるといった使い方も有効でしょう。 テストモニタリングにおいても、日々のテスト実行データから主要なメトリクス、例えばテストケースの消化率とか欠陥検出密度とかですね。 それを計算してわかりやすく要約させるといった使い方が可能です。 本当に多岐にわたる応用が可能なんですね。 ただこれだけAIがいろいろなものを生成してくれるようになると、その結果をそのまま信じて使うわけにはやっぱりいかないですよね。 AIだって間違う可能性はあるわけですから。 ああ、その点は非常に重要です。 AIの生成物を鵜呑みにせず、人間が評価し、必要であればプロンプトを改善していくこの反復的なフィードバックループが不可欠です。 シラバスでは、その評価のための指標として、精度、アキュラシー、適合率、プレシジョン、これは生成されたものがどれだけ的確かということですね。 再現率、リコール、生成されるべきものがどれだけ網羅されているか。 関連性、Relevance、タスクの目的に合致しているか。 多様性、Diversity、結果が変なっていないか。 実行成功率、Execution Success Rate、生成されたテストスクリプトが実際にエラーなく実行できるか。 時間効率、人間が手作業で行う具合と比較してどれだけ時間を短縮できたかなどを挙げています。 これらの指標を参考に、例えば同じタスクに対して複数のプロンプト、まあABテストですね。 それを試して結果を比較したり、生成された内容を専門家がレビューしたり、実際にテストを実行した担当者からのフィードバックを収集したりして、継続的にプロンプトを改善していく姿勢が求められます。 これだけ強力なツールとなると、光の部分だけでなく影の部分、つまりリスクも当然ありますよね。 シラバスでは具体的にどのようなリスクが指摘されていますか? ええ、大きく分けてモデル自体の性質に起因する問題、それからデータプライバシーとセキュリティに関する懸念、そして環境への影響という3つのカテゴリーでリスクが議論されています。 まず、LNM特有の問題としてハルシネーションがあります。 これはあたかも事実であるかのように、もっともらしい嘘とか不正確な情報を生成してしまう現象です。 次に推論エラー、これは論理的な思考とか計算が不得意で、誤った結論を見継ぎ出してしまうことです。 そして、訓練データに含まれる偏りを反映してしまうバイアスですね。 これにより、公平性とか客観性に欠ける結果を出力する可能性があります。 これらがテストの現場で起こると、具体的にどのような問題につながるのでしょうか? 例えば、ハルシネーションによって、実際には存在しない要件に基づいたテストケースを生成してしまうかもしれません。 推論エラーによって、複雑な依存関係を持つ機能のテスト順序を間違って提案するかもしれませんね。 バイアスによって、特定のユーザーグループばかりを想定したテストデータが生成されて、他のグループに対するテストが手薄になるかもしれません。 これらは当然、テストの品質とか網羅性を一時的に損なう可能性があります。 それは困りますね。どうすれば、そういったリスクを発見して対処できるのでしょうか? まず、検出する方向としては、生成されたテストケースとかドキュメントを、元の要件定義書や設計書と付き合わせて、矛盾がないか確認する。 その分野の専門知識を持つ担当者、ドメインエクスパートですね。その方が内容をレビューする。 同じ指示で複数回生成させてみて、出力の一貫性をチェックする。論理的な整合性を検証するといったアプローチがあります。 軽減策としては、やはりプロンプトの工夫が重要です。明確な指示と十分なコンテクストを与えること。 複雑なタスクはプロンプトチェーニングで分割して、各段階で検証すること。 可能であれば、複数の異なるLLMモデルを使って結果を比較検討することなどが有効です。 加えて、LLMの非決定性、つまり同じ入力に対しても実行するたびに出力が微妙に変化する性質も考慮が必要です。 これは創造性を求められるタスクでは利点にもなりますが、テストのように一貫性が重要な場面では問題になることもあります。 これに対しては、応答のランダム性を調整するテンプラチャーというパラメータを低く設定する。 あるいは乱数生成のシード値を固定する、といった技術的な対策である程度出力を安定化させることが可能です。 なるほど、モデル固有の癖の対処法があるわけですね。 では次にデータプライバシーやセキュリティ面のリスクについてはいかがでしょうか。 テストでは未公開の製品情報とか、場合によっては匿名化されていても顧客に関連するデータとか、機密性の高い情報を扱う場面も少なくないと思うんですが。 これは非常に深刻かつ注意が必要なリスク領域ですね。 まず、プロンプトとして入力した情報とかAIからの応答に深まれる情報を通じて、意図せず機密情報が外部に漏洩してしまうリスクがあります。 特にインターネット経由で利用できる公開LLMサービスを使う場合は、入力データがどのように扱われるか、 例えばモデルの再学習に使われたりしないかなどを規約等で十分に確認する必要があります。 また、組織内で誰がどのデータをどのようにAIに利用しているか把握できなくなって、 ガバナンスが効かなくなるデータ利用の制御不能な状態とか、GDPRのようなデータ保護規制へのコンプライアンス違反のリスクも無視できません。 さらに、悪意を持った第三者による攻撃のリスクも存在します。 シラバスではデータ抽出攻撃、これは巧妙なプロンプトを使ってモデルが学習したデータの一部を不正に引き出す攻撃ですね。 プロンプトインジェクション、不正な指示をプロンプトに埋め込むことでモデルに意図しない動作をさせたり、有害な応答を引き出したりする。 データ汚染、もしモデルの訓練データにアクセスできる攻撃者がいれば、そこに悪意のある情報を混入させる。 そして、悪意のあるコード生成、AIに不正な動作をするプログラムコードを生成させるよう誘導するといった攻撃ベクトルが指摘されています。 聞いているだけで少し怖くなりますね。これらに対してどのような対策が考えられるんでしょうか? 基本的な対策としてはですね、まずデータ最小化の原則、つまりAIに渡す情報は本当に必要な最小限に留めること。 次に個人情報や機密情報は可能な限り匿名化、仮名化すること。 そしてデータの保管や転送時には暗号化を施し、厳格なアクセス制御を行うこと。 さらにこれらのリスクと対策について、実際にAIを利用する担当者への十分なトレーニングを行うことが挙げられます。 加えてAIが生成した成果物、特にテストスクリプトのような実行可能なコードは必ず人間の専門家がレビューするプロセスを確立すること。 利用するLLM環境についても、セキュリティ要件に応じて信頼できるクラウドサービスを選定するか、 あるいは機密性の高いデータを扱う場合は自社環境内、オンプレミスですね、そこに閉じたモデルを構築するかなどを慎重に検討すること。 そして定期的なセキュリティ観察を実施することなどが重要です。 これらは技術的な対策だけでなく、ホーム、コンプライアンス部門との連携も不可欠な領域です。 環境負荷についての言及もありましたね。 AIの利用が地球環境に与える影響についても考慮が必要だと。 はい。LLMの訓練には膨大な計算能力が必要ですが、私たちが日常的に利用する際、 推論時ですね、その時にも相当量の電力が必要です。 これがエネルギー消費とそれに伴うCO2排出という環境負荷につながります。 タスクの複雑さ、一般にテキスト生成よりも画像生成のほうが負荷が高いと言われますが、それとか利用頻度によってその度合いは変わります。 シラバスで引用されている研究によれば、例えば画像を1枚生成するのに必要なエネルギーが、 スマートフォンのフル充電1回分に匹敵するという、そういう試算もあるようです。 ですから無駄なAPI呼び出しを避けるとか、タスクに対して過剰に高性能なモデルを使わないといった 環境負荷を意識した利用がこれから求められるようになります。 こうした多岐にわたるリスク全体に組織として対応していくためには、ISO42001、AIマネジメントシステムに関する国際企画ですね。 とかEUAI ACT、EUの包括的なAI規制法案、NIST AIRMF、これは米国国立標準技術研究所が作成したAIリスク管理フレームワークですが、 こういった関連する規制や標準、ベストプラクティスの動向を常に把握して、自社の状況に合わせて適切な方針とかガイドラインを定めていくことが重要になってきます。 企業がテストでLLMを活用する場合、単にチャットボットとして対話的に使うだけでなく、もっとシステムとして本格的に組み込むような構成も考えられるのでしょうか。 その通りです。個別のタスク支援を超えて、LLM搭載テスト基盤というより統合されたアプローチがあります。 これはユーザーが操作するインターフェース、フロントエンドですね。それとデータ処理やLLMとの連携を担うバックエンド。 そしてLLMモデル自体が共通して動作するシステムです。バックエンドでは通常のデータベースに加えて、文書の内容とか意味的な関連性に基づいて高速に情報を検索できるベクトルデータベースが重要な役割を果たすことがあります。 これにより、例えば過去の膨大なバグレポートとかテスト仕様書の中から、現在取り組んでいるタスクに最も関連性の高い情報を効率的に探し出して、LLMの入力コンテキストとして提供するといったことが可能になります。 ベクトルデータベースですか。より賢く情報を扱えるようになるわけですね。さらに高度な活用技術もあるんでしょうか。 はい、いくつか注目すべき技術があります。一つはRAG、Retrieval Augmented Generationです。これは、LLMが回答を生成する際に、単に内部の学習済み知識だけに頼るのではなく、先ほどのベクトルデータベースなどに格納された外部の最新情報、例えば社内の最新ドキュメントとか特定のナレッジベースですね、それをリアルタイムで参照しながら回答を生成する技術です。 これにより、LLMの回答の正確性とか、組織固有の文脈への適合性を大幅に向上させることができて、ハルシネーションのリスク低減にもつながると期待されています。 次に、LLM搭載エージェントという考え方。これは、特定のテスト関連タスク、例えば特定パターンのバグ報告の自動起評とか、テスト環境のセットアップ手順の実行とかですね、そういったものを人間からの指示を受けて、 反自律的に、あるいは完全に自律的に実行するように設計されたソフトウェアコンポーネントです。将来的には、複数の専門エージェントが連携して、より複雑なテストプロセス全体を自動化効率化することも構想されています。 そして、ファインチューニング。これは、既存の汎用的なLLMとか、より軽量なSLM、スモールランギージモデルですね、それを特定の組織の専門用語、ドネイン知識、あるいは特定のタスク、例えば自社製品に関する技術的な質問への回答とか、それに合わせて追加学習させる手法です。 これにより、モデルの性能をその組織の固有のニーズに最適化することができます。これらの高度な技術を効果的に開発し、デプロイし、運用管理していくための一連のプラクティス全体を、LLM Ops、ラージランギージモデルオペレーションズと呼びます。 モデルのバージョン管理とか、性能監視、継続的な再学習などを体系的に行うための考え方ですね。RAGやファインチューニングといった技術は、より文脈に即した正確な出力を促すことで、結果的にリスク低減にも貢献するかもしれません。 RAGやエージェント、ファインチューニング。かなり高度な活用が見えてきましたね。では、いざテストチームとしてこれらの技術を導入しようと考えた場合、何から手をつければよいんでしょうか。 いきなり全てを導入するのは現実的ではなさそうですし、一方で、現場のメンバーが個人的に便利なツールを勝手に使い始めてしまう、いわゆるシャドーAIのリスクもあると、調査には書かれていますね。 おっしゃる通り、無計画な導入は混乱とかリスクを招きかれません。シラバスでは、まず組織として明確な戦略を立てることを強く推奨しています。 具体的には、全AI導入によって何を達成したいのか、具体的な目標を設定すること。例えば、テストケース作成工数を年間15%削減するとか、新規機能に関するテストカバレッジを10%向上させるとかですね。 そして、その目標達成のために、どのようなLLMやSLMを選定するのか。選定に当たっては、モデルの性能、特定のタスクに対する精度とか音速度とか、それだけでなく、コスト、API利用料とか運用費、ファインチューニングの容易さや可否、提供されているセキュリティ機能、ライセンス条件などを総合的に評価する必要があります。 さらに、AIに与える入力データの品質をどう確保するか。不正確な情報を与えれば、不正確な結果しか返ってきませんからね。チームメンバーに対するトレーニングをどのように実施するか。導入効果を測定するための指標、KPIですね。それを何にするか。そして、無視できないコンプライアンスや倫理に関するガイドラインをどう定めるか、といった要素を戦略に盛り込むべきです。 実際の導入プロセスは、多くの場合、段階的に進めるのが現実的でしょう。シラバスでは、例えば発見フェーズ。まず、全AI技術について学び、小規模なツール使用とか実験を行う。開始と利用定義フェーズ。具体的なユースケースをいくつか特定し、限定的な範囲でパイロットプロジェクトを実施する。 そして、活用と反復フェーズ。効果が確認されたユースケースから本格的な導入を展開し、効果測定と現場からのフィードバックに基づいて、継続的にプロセスとかツールを改善していく、といった段階的なアプローチが考えられるとしています。 シャドウAIのリスクを抑制するためにも、早い段階で組織としての方針、何を使っても良いか、何は禁止か、利用時の注意点は何か、などをちゃんと示して、利用ガイドラインを整備周知することが極めて重要です。 なるほど。トップダウンでの戦略と、段階的な導入、そしてガイドラインが鍵になるわけですね。そうなると、テスト担当者自身にも、これまでとは違う新しいスキルが求められることになりますよね。 まさにその通りです。これまで議論してきたように、まずプロンプトエンジニアリングのスキルは、GNIを使いこなす上で必須と言えるでしょう。AIの能力を最大限に引き出すための、的確な指示を与える技術です。 そして、利用するAIモデルの特性、つまり得意なこと苦手なこと、そして限界を正しく理解すること。AIが生成したものをそのまま受け入れるんじゃなくて、常に批判的な視点で評価する能力も、これまで以上に重要になります。 単にAIを使えるというだけでは不十分で、これまで培ってきたドメイン知識、テスト対象のシステムとか業務に関する深い理解ですね。それとテスト専門知識、テスト設計技法とか品質保障の原則に関する知識、これらの新しいAIスキルと融合させて、相乗効果を生み出すことが求められます。 加えて、先ほどリスクのところで触れたデータセキュリティに対する高い意識とか、環境不快の配慮といった視点も、これからのテスト専門化には欠かせない要素になってくるでしょう。これらのスキルは、単に研修を受けるだけでなく、日々の業務の中で実際にAIツールを使いながら試行錯誤する、あるいは組織内で成功事例や失敗事例、効果的なプロンプトのパターンなどを共有するナレッジシェアリング活動などを通じて、実践的に育成していく必要があります。 テスト担当者の役割そのものも、将来的に変化していく可能性が高いということでしょうか。 そのように考えられますね。テスターは、単にテストを設計し実行する作業者というだけじゃなくて、AIを効果的に活用するための指示を出し、その出力を検証・評価し、時にはAIを教育する、いわばAI支援テストスペシャリスト、あるいはAIテストオーケストレーターのような役割へと進化していく可能性があります。 テストマネージャーの役割も同様に変化するでしょう。従来のテスト計画策定とかチーム管理、リスク管理に加えて、AIを活用したテスト戦略を立案したり、AI利用に伴う新たな種類のリスク、ハルシネーションとかバイアス、情報漏洩とかですね、それを評価管理したり、組織内でのAI利用に関するガバナンス、ルール策定とか、 特殊状況のモニタリング、倫理的配慮など、それを確立推進したりといった、より戦略的管理的な役割が重要性を増してくると考えられます。将来的には、人間とAI、あるいは複数のAIエージェントが共同するハイブリッドなチームをいかに効果的にマネジメントするか、という新しいスキルも求められるようになるかもしれませんね。 さて、今回の探究も終わりに近づいてきました。ISTQBのシラバスを通して見えてきたのは、生成AIがソフトウェアテストの分野に、例えばテストケース作成の劇的な効率化とか、これまで人手ではカバーしきれなかった領域へのテストカバレッジ拡大といった大きな可能性をもたらしていること。 しかしその一方で、その力を引き出すためには、効果的なプロンプトを作成するスキルとか、AIの生成結果を盲信せず悲観的に評価する能力といった新しいスキルセットがテスト担当者に求められるということですね。そして、ハルシネーションやプライバシー侵害、バイアスといった決して無視できないリスクも内在しており、それらに対する慎重かず計画的な対策が不可欠であることも明らかになりました。 結論として、GNAIは人間のテスターを不要にする魔法の杖ではなく、むしろ人間の能力を拡張し、より複雑で高度な品質保証活動に集中させてくれる、まあ強力な相棒、あるいはツールと捉えるのが現時点では適切だと言えそうです。 え、非常に的確なまとめだと思います。GAIは強力なツールですが、あくまで使いこなすのは人間であり、その責任も人間にあるという視点が重要ですね。そして最後に、今日の探求を踏まえて、あなたに一つ問いを投げかけてみたいと思います。 これまでの議論は、主に個々のテストタスクをGAIでどのように支援効率化できるかという視点が中心でした。しかし、もしこの技術がさらに進化し、特定のテスト領域、例えばセキュリティテストとかパフォーマンステストですね、それに高度に専門化したAIエージェント群と、人間のテスト専門家がより緊密に協調して働くシステムが実現したとしたら、 それは近い将来、ソフトウェアの品質保証というプロセス全体をどのように再構築し得るでしょうか。そしてその結果として、私たちはどのような新しい形のテスト、あるいはこれまで想像もしなかったような品質保証の在り方を目の当たりにすることになるのでしょうか。 あなたご自身の業務や興味のある分野に引き寄せて、ぜひこの問いについて少し思いを巡らせてみてください。 非常に示唆に富む問いですね。AIとの共同が当たり前になった未来のテストの姿を想像せずにはいられません。 今日の探究にご参加いただきありがとうございました。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回は番外編になります。 11月10日からVoicyトークリレーが始まります。 私は1日目のトップバッターということで放送しておりまして、 放送タイトルはVoicy活用術参戦です。 あと初回ということもありまして、今回のトークリレーについての紹介もしておりますので、 ぜひお楽しみにしていてください。 いつもと違って8時くらいかな、朝に公開予定です。 今回の放送を聞いて、なるほどな、確かにな、学びになったな、 そして今日も放送を聞いたような合図でいいねを押していただけると、とてもとても励みになります。 最近ですね、ホノルルさんだったり、あとアサミKさんからもたくさんいいねをいただいていて、 とても嬉しく思っております。ありがとうございます。 それではまた明日お会いしましょう。ごきげんよう。