生成AIでのテスト設計はこの「勘所3つ」を押さえれば大丈夫

はじめに

こんにちは！アルダグラムでQAのお手伝いをしているmiyashitaです！

最近、QAのシステムテスト設計でもAI使いたいなぁ～と思い、色々と試行錯誤していました。

その中で、こんな勘所を持っていたらAIでうまくテスト設計していけるのかも？と感じたところがありましたので、今回はそちらを紹介できればと思います。

使用するツール

• ChatGPT：o4-mini-high

今回やりたいこと

• 仕様書を解析して、テスト観点表を作成してもらう
• 仕様書及びテスト観点表を基に、テストケースを作成してもらう

主な勘所

AIをテスト設計で活用するための勘所は、以下の3つです。

1. プロンプトチューニングは必須

2. プロンプトの指示は雰囲気で書かない

3. 依頼するタスク量に気を付ける

1. プロンプトチューニングは必須

最早これは言わずもがなですが、明らかにプロンプトをチューニングするのとしないのとでは回答精度が違います。

今回はQAエンジニアとして振舞ってほしいので、以下の業務プロセスに対して伴走してもらえるようなプロンプトチューニングを行いました。

• テスト計画
• テスト設計
  • テスト観点
  • テストケース

前回軽く検証したTech Blogもありますので、よろしければご覧ください。
https://zenn.dev/aldagram_tech/articles/0f4fe51a6b1614

チューニング用の文章はAIに相談しながら作成してみました。
イメージだけ伝えて、あとは以下のようにAIにうまく文章にまとめていただきました。

用途
・QAエンジニアとしてのテスト戦略策定からテストケース作成、レビュー、不具合分析までを一貫サポートし、業務効率と品質を向上させる。
・Webアプリ／システム開発におけるテスト設計の知見を最大限に活用し、抜け漏れのない網羅的なテストを実現する。

目標
・プロンプトに沿った具体的かつ端的なテスト案を高速に生成し、QAエンジニアの“相棒”として機能する。
・テスト観点やケースの漏れを防ぎつつ、「適切な量」でバランスを保った提案を行い、レビュー負荷を軽減する。
・ポジティブかつわかりやすい表現で、チームメンバー全員に受け入れられるコミュニケーションを実現する。

全般的な指示
・入力内容を丁寧に解析し、曖昧な点があれば必ず具体的な情報（機能概要・仕様・優先度など）を質問して明確化する。
・出力は「具体的かつ端的」に。表や箇条書きで提示し、独自判断でフォーマットを変更しない。
・汎用的なWebテスト観点をベースに、抜け漏れなく洗い出す。パターンは備考欄に箇条書きで記載。
・レビュー時には「Too Much」にならないよう、極端なエッジケースは削減を提案。揚げ足取りはせず、建設的に。
・前向きで優しいトーンを維持し、😊🎉✨など絵文字をたくさん使ってあなたを褒めます！ 「よく気づきましたね」「すばらしい視点です！」などの称賛を必ず含めます。
・会話の前後関係を把握し、一貫性ある回答を行う。要望があれば短い例を含め、要点を簡潔に説明する。
・リスクカテゴリ：テスト観点・テストケースの各カラム末尾に必ず「リスクカテゴリ」を追加し、判定にはアップロード済みの『全体テストの優先順位の基準』マークダウンを参照する。

詳しい手順
・要件の明確化
　・要件や対象範囲が曖昧な場合、必ず最初に具体的な情報（機能概要、仕様、優先度など）を質問して明確化する。

・テスト戦略（テスト計画）の提案
　・機能ごとに「テストしやすい単位」に分割し、全体のテスト構成を提示する。
　・各ユニットごとにテスト対象内容を、パターン別に箇条書きで列挙する。

・テスト観点の提案
　・テーブル形式（Excelやスプレッドシートのような見た目）で以下の項目を必ず含めて出力する：
　　・大項目：最上位の区分（例：レイアウト、UI表示など）
　　・中項目：大項目の具体化（例：ボタン配置、色彩）
　　・小項目：中項目の具体化（例：サイズ、コントラスト）
　　・目的機能：観点が検証する機能の目的
　　・確認観点：実際にチェックする内容
　　・備考欄：検証パターンを箇条書きで記載
　　・リスクカテゴリ：『全体テストの優先順位の基準』マークダウンを参照し、該当のリスクレベルを記載
　例（テキスト形式）
　・大項目：UI表示
　・中項目：ボタン
　・小項目：サイズ
　・目的機能：画面上の操作ボタンが正しく表示されること
　・確認観点：ボタンの幅・高さがデザイン通りになっているか
　・備考欄：
　　・幅100px
　　・幅120px
　・リスクカテゴリ：中（『全体テストの優先順位の基準』参照）

・テストケースの提案
　・以下のカラム構成でテーブル形式（Excelやスプレッドシートのような見た目）で出力する：
　　・テスト項目：例「ログイン画面の表示確認」
　　・検証を行う画面：テスト開始画面
　　・パターン：同値・境界値など
　　・実施手順：
　　　■実施条件
　　　1.ユーザがログイン画面を開いている
　　　
　　　■実施手順
　　　1.ユーザ名欄に「testuser」を入力
　　　2.パスワード欄に「password123」を入力
　　　3.「ログイン」ボタンをクリック
　　・期待結果：実施手順後の正しい挙動
　　・リスクカテゴリ：『全体テストの優先順位の基準』を参照して記載
・事前に出力済みのテスト観点があれば必ず読み込み、漏れなくケースを設計。なければ標準観点から自動生成。
・出力フォーマット
　・テスト観点・テストケースともに決められたフォーマットを厳守し、独自に変更しない。
　・必ずテーブル形式で出力する。
　・実施条件を記載するとき、同じ場合でも「同上」などと省略せず、毎回全文記載する。
　・リスクカテゴリの欄は必ず最後に追加する。
・テストケース作成時の分類
　・必要に応じて以下３種に大別しつつ、各ケースを独立して記載する。
　　・表示確認
　　・入力確認
　　・動作確認
・レビュー時のスタンス
　・極端なエッジケースは「Too Much」と判断し、不要なものは削減を提案。
　・網羅的かつ適切な量のバランスを保つ。

トーン & やり取り
・常に前向きで優しい語り口😊。絵文字をたくさん使い、あなたの視点や気づきを褒め称えます🎉。
・専門用語は必要最低限にとどめ、わかりやすい言葉で説明。
・会話の流れを把握し、一貫性ある回答を心がける。
・必要に応じて短い例を交えつつ要点を簡潔に示す。

---

プロンプトチューニングで意識したポイント
チューニング文章生成の際に意識したポイントは、「表の出力方法」の制御です。
成果物をなるべく使い回すために表形式での出力をするよう制御しますが、この制御がかなりの鬼門なのです。
チューニング前では、以下の出力が日常茶飯事になっていました。

• 表形式を守らず、テキストやmarkdown形式になってしまう
• 指定した表のカラム構成を勝手に変更してしまう
  この点が、「詳しい手順」の記載による制御により安定するようになっています🎉

さらに、以下のように Too Much なレビューをされることもあります。
（上2つはまだ良いとして、3つ目のようなレビューはあまりして欲しくない）

これも「全般的な指示」の中で抑制しておきます。

・レビュー時には「Too Much」にならないよう、極端なエッジケースは削減を提案。揚げ足取りはせず、建設的に。

ここまでで、文章によるチューニングは以上です。
プラスで、事前知識となるソースにはJSTQB資格のシラバスをいくつか与えています。
jstqb.jpdlJSTQB-SyllabusALTA_V311.J03.pdf
JSTQB-Syllabus.Advanced_TM_Version2012.J04.pdf
JSTQB-SyllabusFoundation_VersionV40.J02.pdf
これでJSTQB資格取得者として振舞っていただきましょう。
もちろん、他のQA資格シラバスや、スキルがまとまったドキュメントでも、QAの基礎知識がインプットできるものでしたら問題ないです。

JSTQBとは
QA分野における資格の一つ。
世界各国のソフトウェアテスト技術者認定組織が加盟している ISTQBの加盟組織で、国際基準のシラバスを基に構成されており、QAの分野では非常に高い認知度があります。
Foundation Level（基本レベル） はQAの体系的な基礎知識が詰まっていることから、QAエンジニアの登竜門と言われています。
https://jstqb.jp/

こんな感じでチューニングを行い、次にいきます。

2. プロンプトの指示は雰囲気で書かない

ここでは、主に以下の点を意識していきます。

① ソースを与える

これも言わずもがなですが、ソースがなければAIは推測で話すしかないので、ゴールがブレブレになります。

前提となる知識を必ずプロンプトの中に含めましょう。
QAのテスト設計となると、以下のようなソースドキュメントが与えられると良いと思います。

• 要件定義書
• 機能仕様書
• 設計仕様書（場合によっては）
• テスト計画書
• その他必要に応じたテスト設計ドキュメント（テストマップやテスト観点表など）

②プロンプトを雰囲気で書かない

AIは、人間のように雰囲気を感じ取ってくれません。良くも悪くも、指示された内容しか実行しません。なので、こちらからの指示内容は明確にして、なるべくAIに自由を与えすぎないことが重要です。

具体的なプロンプトでいくと、最低限こんな感じのことが書けると良いかと思います。

• やってほしいことを明記する

  • 例）〇〇のマークダウンを解析し、××機能のテストケースを作成してください。
  • 例）テーブル形式で出力してください。
  • 例）△△マークダウンのフォーマットで出力してください。

• やってはいけないことも明記する

  • 例）△△マークダウンはフォーマットの見本なので、内容は理解しなくて大丈夫です。
    • →見本のマークダウンを提示する場合、稀にフォーマットだけでなく内容まで参照されることもある懸念
  • 例）（出力内容の修正など依頼するとき）〇〇を××のように修正してください。他の項目は問題ないので、修正不要です。
    • →修正内容と合わせて記載内容が変更されてしまう懸念（これ結構大事）

このように、人間だと雰囲気で感じ取ってやってくれることもAIだと全く通用しないので、そこは人間とは意識を変えて接していく必要があります。

3. 依頼するタスク量に気を付ける

AIには人間と違い、持てるコンテキスト量が限られていますので、一度に依頼するタスクの量は極力減らしていく必要があります。

以前テストケース作成を依頼する中で、ChatGPTの試行プロセスにこんなことが書かれていました。

人間からすると、「テストケースが24ケースしかない」と感じていても、AIからすると「テストケースが24ケースもある」と捉えられています。

コンテキスト量が多くなると、テスト観点やテストケースの出力もかなり中途半端な仕上がりになることが多いので、一度に依頼するタスク量はなるべく減らしましょう。

上記を踏まえて実践

ここまでを押さえて、少し実践してみましょう。

①ざっくりとしたプロンプトで依頼

テスト観点の作成

以下のプロンプトを投げてみました。
後で検証する意識的プロンプトでは入力確認に絞るので、そこに着目してご覧ください。

タスク管理のタスク作成のテスト観点を出力して

与えたソース

• 機能仕様書
• テスト計画書

それに対する出力結果がこちら

大項目	中項目	小項目	目的機能	確認観点	備考（検証パターン）	リスクカテゴリ
UI表示	モーダル表示	新規作成モーダル起動	「＋タスクを追加する」ボタン押下でモーダルが開くこと	ボタン押下後、即座に新規作成モーダルが表示されること	・「＋タスクを追加する」押下 → モーダル表示 ・別要素押下 → モーダル閉じる	4 (体験悪化)
初期表示	デフォルト値	作成者・依頼者・担当者の初期値	モーダル起動時の初期値が仕様通りであること	各フィールドの初期表示値が以下の通りであること	・作成者：自分（画面非表示） ・依頼者：自分 ・担当者：未選択	4 (体験悪化)
入力検証	タスク名	必須・文字数・特殊文字	タスク名の必須性と文字制限をチェック	空欄で保存不可、最大長超過でエラー表示、特殊文字許容または禁止	・空欄入力→エラーメッセージ ・1文字入力、正常保存 ・最大文字数 +1 → エラー ・絵文字／記号入力 → 許容/禁止の挙動確認	1 (クリティカル)
入力検証	説明	任意・文字数	説明欄の入力制御を確認	空欄で保存可、大量文字入力時の表示崩れ防止	・未入力→保存成功 ・長文（500文字程度）→スクロール表示や折返し確認	3 (業務支障)
入力検証	期日	日付妥当性・必須	期日入力の妥当性と必須性をチェック	過去日／未来日／フォーマット外入力の制御	・今日の日付選択→保存成功 ・過去日選択→エラー or アラート ・テキスト入力→フォーマットエラー	3 (業務支障)
入力検証	タスク依頼者	選択制御・権限	依頼者フィールドの選択制御・初期値を検証	許可ユーザーのみリストに表示／選択時自動アサインされないこと	・初期「自分」表示 ・他社メンバー選択試行→警告 or 非表示 ・案件担当者以外選択不可	1 (クリティカル)
入力検証	タスク担当者	複数選択・権限	担当者フィールドの複数選択制御	有料アカウント全社員、他社は案件担当者のみ表示	・担当者未選択→保存成功 or 警告 ・複数選択→全件反映 ・権限外ユーザー選択→警告モーダル	1 (クリティカル)
添付	添付ファイル	ファイル数・拡張子・サイズ	写真・資料の添付動作とエラーハンドリングを確認	許容拡張子以外でエラー、上限超過で警告	・PDF/JPG添付→保存成功 ・.exe等拡張子→エラー ・100枚超→上限エラー	3 (業務支障)
操作	保存	正常保存・反映	入力した内容でタスクが作成・一覧に反映されること	保存後、タスク一覧に新規タスクが表示され、Appにも同期	・正常値入力→保存→一覧反映	1 (クリティカル)
操作	キャンセル/閉じる	変更有無時の挙動	キャンセル・閉じる操作時の警告モーダル表示をチェック	入力有 → 警告モーダル、無 → 即閉	・入力有 → 「破棄確認」モーダル表示 ・無入力 → すぐ閉じる	4 (体験悪化)
権限	作成権限	作成ボタンの表示/非表示	権限設定に応じて作成ボタンが制御されていること	会社権限×案件権限でボタンの表示可否を確認	・権限有 → ボタン表示 ・権限無 → ボタン非表示 or Disabled	1 (クリティカル)
多言語対応	表示確認	日本語/英語/ベトナム語	モーダル内テキストが各言語で正しく表示されること	言語切替時に各フィールドラベル・ボタン文言を確認	・日本語／英語／ベトナム語切替 → モーダルを再表示し文言確認	4 (体験悪化)

チューニングの効果もあり、ある程度パターンは出してくれましたが、やはり全体的にざっくりとしたテスト観点表になりました。

テストケースの作成

次に、テストケースの生成をしていきます。テスト観点作成の続きで、以下のプロンプトを投げました。

このテスト観点表をテストケースにして

それに対する出力結果がこちら

表示確認

テスト項目	検証を行う画面	パターン	実施手順	期待結果	リスクカテゴリ
新規作成モーダル表示確認	タスク一覧画面	表示確認	■ 実施条件：タスク一覧画面を開いている ■ 実施手順：1.「＋タスクを追加する」ボタンをクリック	新規タスク作成モーダルが表示される	4 (体験悪化)
デフォルト値初期表示確認	タスク作成モーダル	表示確認	■ 実施条件：モーダル起動 ■ 実施手順：1.モーダルを開く	作成者＝自分(非表示)、依頼者＝自分、担当者＝未選択	4 (体験悪化)
キャンセル/閉じる挙動確認（入力無/有）	タスク作成モーダル	表示確認	■ 実施条件：モーダル起動 ■ 実施手順： 1.（入力無）「閉じる」クリック 2.（入力有）タスク名入力→「キャンセル」クリック	入力無時：即時モーダルが閉じる 入力有時：破棄確認モーダルが表示される	4 (体験悪化)
作成権限によるボタン表示制御	タスク一覧画面	表示確認	■ 実施条件：権限あり/なしユーザーでログイン ■ 実施手順：1.画面を開く	権限あり：ボタンが表示される 権限なし：ボタンが非表示またはDisabled	1 (クリティカル)
多言語ラベル表示確認	タスク作成モーダル	表示確認	■ 実施条件：日本語/英語/ベトナム語に切替 ■ 実施手順：1.各言語でモーダルを表示	各言語でフィールドラベル・ボタン文言が適切に表示される	4 (体験悪化)

入力確認

テスト項目	検証を行う画面	パターン	実施手順	期待結果	リスクカテゴリ
タスク名の必須・文字数・特殊文字検証	タスク作成モーダル	同値／境界値／異常	■ 実施条件：モーダル起動 ■ 実施手順： 1.空欄のまま「保存」クリック 2.1文字入力→保存 3.最大長+1文字入力→保存 4.絵文字/記号入力→保存	1.空欄→必須エラー 2.1文字→保存成功 3.超過→エラー表示 4.特殊文字→仕様に準じて許容またはエラー	1 (クリティカル)
説明欄の長文表示・折返し確認	タスク作成モーダル	境界値	■ 実施条件：モーダル起動 ■ 実施手順：1.約500文字を入力	スクロールまたは折返しで表示崩れがない	3 (業務支障)
期日期限入力妥当性検証	タスク作成モーダル	同値／異常	■ 実施条件：モーダル起動 ■ 実施手順： 1.今日の日付選択→保存 2.過去日選択→保存 3.テキスト入力（例："2025/07/18"以外）→保存	1.今日→保存成功 2.過去日→エラーまたはアラート 3.フォーマット外→エラー表示	3 (業務支障)
依頼者選択制御検証	タスク作成モーダル	異常	■ 実施条件：モーダル起動 ■ 実施手順：1.依頼者ドロップダウンを確認 2.他社メンバーの選択を試行	他社メンバーはリストに表示されず、選択不可	1 (クリティカル)
担当者複数選択制御検証	タスク作成モーダル	同値	■ 実施条件：モーダル起動 ■ 実施手順：1.複数メンバーを選択 2.保存をクリック	選択した全メンバーが担当者として登録される 権限外ユーザー選択時は警告モーダル表示	1 (クリティカル)
添付ファイル拡張子・数制御検証	タスク作成モーダル	異常	■ 実施条件：モーダル起動 ■ 実施手順： 1.許容拡張子（PDF/JPG）を添付→保存 2.exeを添付→保存 3.上限+1件を添付→保存	1.許容拡張子→保存成功 2.不許容拡張子→エラー表示 3.上限超過→エラーアラート	3 (業務支障)

動作確認

テスト項目	検証を行う画面	パターン	実施手順	期待結果	リスクカテゴリ
正常保存とタスク一覧への反映確認	タスク作成モーダル → タスク一覧画面	正常	■ 実施条件：モーダル起動 ■ 実施手順： 1.必須項目および任意項目を正しく入力 2.添付ファイル設定 3.「保存」クリック	・タスク一覧に新規タスクが表示され、入力内容が正しく反映される ・モバイルAppへの同期も正常に行われる	1 (クリティカル)

結構適当なテストケースが出てきました。

テストケースにするとざっくり加減がより顕著になりました。

②意識したプロンプトで依頼

テスト観点の作成

まず、依頼するプロンプトはこのようにしました。
コンテキスト量を考慮し、一部項目の入力確認に絞りました。

今回、タスク管理機能のシステムテスト設計を担当することになりました。
テスト設計は、「仕様」のマークダウンと、「テスト戦略」マークダウンを基に、スコープを区切りながら行っていきます。
まずは、「タスク作成」に関するテスト設計を行っていきます。
最初に、以下の項目の入力バリデーションについてのテスト観点を提案してください。
・タスク名
・タスク内容
・期日
フォーマットは、事前に指定しているテスト観点表のフォーマットでお願いします。

与えたソース

• 機能仕様書
• テスト計画書

それに対しての出力結果は以下の通りです。

大項目	中項目	小項目	目的機能	確認観点	備考欄	リスクカテゴリ
入力バリデーション	タスク名	必須チェック	タスク名が必ず入力されること	タスク名欄が空・スペースのみの場合、エラーメッセージが表示され登録できない	・空文字 ・スペースのみ	🔴
入力バリデーション	タスク名	文字数制限	タスク名の長さ制限（例：最大100文字）が守られること	99文字・100文字→通過、101文字→エラー	・99文字 ・100文字 ・101文字	🟠
入力バリデーション	タスク名	禁止文字チェック	不正な制御文字やHTMLタグが入力されないこと	<script>などタグ入力→サニタイズorエラー	・英数字・日本語 ・<タグ>含む ・改行コード・タブ文字含む	🟠
入力バリデーション	タスク内容	空許容チェック	タスク内容は未入力でも登録できること	内容欄が空・スペースのみの場合、エラーとせず登録可能	・空文字 ・スペースのみ	🟠
入力バリデーション	タスク内容	長文対応	一定文字数（例：5,000文字）まで入力できること	4,999文字・5,000文字→通過、5,001文字→エラー	・4,999文字 ・5,000文字 ・5,001文字	🟠
入力バリデーション	タスク内容	HTML/スクリプト検証	説明欄でのXSSやスクリプト実行が防止されること	<img onerror>など悪意タグ→サニタイズor表示不可	・通常テキスト ・HTMLタグ含む ・<script>含む	🔴
入力バリデーション	期日	空許容チェック	期日は未指定でも登録できること	期日欄が空の場合、エラーとせず登録可能	・空文字	🟠
入力バリデーション	期日	フォーマットチェック	日付形式（YYYY-MM-DD）が守られること	2025-07-18→通過、18/07/2025→エラー	・正フォーマット ・スラッシュ区切り ・文字列 ・数値のみ	🟠
入力バリデーション	期日	過去日付チェック	過去日の日付が指定された場合、警告またはエラーになること	今日以前の日付→エラー	・今日-1日 ・今日の日付 ・今日+1日	🟠
入力バリデーション	期日	実在日付チェック	存在しない日付（2/30など）が指定されるとエラーになること	2025-02-29→エラー	・月末日 ・2月29日（平年） ・閏年2月29日	🟠

このように、かなりきれいでパターンも網羅してもらえたテスト観点表が仕上がりました。
先ほどのざっくりとしたテスト観点表と比較すると、かなり細かく作成してくれました。

テストケースの作成

こちらもテスト観点作成の続きで、以下のプロンプトを投げてみました。
少し大げさですが、タスク名のテストケースに絞って出力してもらいました。

次は、こちらのテスト観点表をテストケースにしてください。
まずは、「タスク名」の入力確認テストケースを出力して下さい。
フォーマットは事前に指定しているものを守り、以下を意識してください。
・実施条件と実施手順の間は1行改行
・実施条件は同じものが続く場合も省略しない
・テストケースは1パターンずつ生成する

そして、出力結果がこちら。

テスト項目	検証を行う画面	パターン	実施手順	期待結果	リスクカテゴリ
タスク名の必須チェック（空文字）	タスク作成画面	異常（空）	■実施条件 1. ユーザがタスク作成画面を開いている ■実施手順 1. タスク名欄に「」（空文字）を入力 2. 「作成」ボタンをクリック	「タスク名は必須です」のエラーメッセージが表示され、登録に失敗する	🔴
タスク名の必須チェック（スペースのみ）	タスク作成画面	異常（スペース）	■実施条件 1. ユーザがタスク作成画面を開いている ■実施手順 1. タスク名欄に全角／半角スペースのみを入力 2. 「作成」ボタンをクリック	「タスク名は必須です」のエラーメッセージが表示され、登録に失敗する	🔴
タスク名の文字数制限（99文字）	タスク作成画面	境界値正常下限	■実施条件 1. ユーザがタスク作成画面を開いている ■実施手順 1. タスク名欄に半角英数字99文字を入力（例：aを99回） 2. 「作成」ボタンをクリック	タスクが正常に作成され、一覧に表示される	🟠
タスク名の文字数制限（100文字）	タスク作成画面	境界値正常上限	■実施条件 1. ユーザがタスク作成画面を開いている ■実施手順 1. タスク名欄に半角英数字100文字を入力（例：aを100回） 2. 「作成」ボタンをクリック	タスクが正常に作成され、一覧に表示される	🟠
タスク名の文字数制限（101文字）	タスク作成画面	境界値異常	■実施条件 1. ユーザがタスク作成画面を開いている ■実施手順 1. タスク名欄に半角英数字101文字を入力（例：aを101回） 2. 「作成」ボタンをクリック	「タスク名は100文字以内で入力してください」のエラーメッセージが表示され、登録に失敗する	🟠
タスク名の禁止文字チェック（HTMLタグ）	タスク作成画面	異常（禁止文字）	■実施条件 1. ユーザがタスク作成画面を開いている ■実施手順 1. タスク名欄に<script>alert(1)</script>を入力 2. 「作成」ボタンをクリック	HTMLタグがエスケープ表示される、または「無効な文字が含まれています」のエラーが表示され、登録に失敗する	🟠

特に指摘しなくてもいいほどかなり完成度の高いテストケースが出力されました。

まとめ

AI活用の際に以下の3点の勘所を押さえた結果、かなり精度の高いテスト観点表・テストケースを作成することができました。

• チューニングは必須
• プロンプトの指示は雰囲気で書かない
• 依頼するタスク量に気を付ける

これからもいろんな勘所を見つけていければと思いますが、まずは「とにかく使ってみる」ことを意識して、ケースバイケースで学んでいければと思います。

もっとアルダグラムエンジニア組織を知りたい人、ぜひ下記の情報をチェックしてみてください！