不具合を残した同じプログラムを、入力を変えて十回ずつテストする実験を1,000組行いました。各組の一回目で全件合格したのは371組。十回のうち一度でも全件合格すればよいとすると、994組が条件を満たしました。変えたのは、テストに使う入力と結果の選び方です。プログラムの計算内容は同じで、不具合は一つも直していません。小さなPythonプログラムでこの実験を行い、量子回路研究で報告された評価方法と比べてみます。AI生成コードの採用でも、合否だけを見て判断すると、同じ取り違えが起こり得ます。資料と検証範囲模擬実験の初回実行は2026年9月11日です。9月19日に同じコードと入力生成条...

2つのゲーム、実際の意思決定ログ、9画面ダッシュボード、そして再利用できる出発点。ゲームの見た目は良くなっていた。次は、プレイ体験も本当に良くなっているという、より確かな証拠が欲しかった。よくある不満はこうだ。強化した武器は気持ちよく使えるのに、遭遇する敵の多くを簡単にしすぎてしまう。敵の体力を増やすのは簡単だった。本当の問題を見つけるには、もう少し手間がかかった。私はCodexの助けを借りて、実際のゲームエンジンを中心にしたローカルのプレイテストラボを作った。Nightshift Hollowsでは、JevがAPI経由で移動と強化の判断を行った。Starfall Salvoでは...

1. はじめにこれまで、プログラミング言語やフレームワークについては、書籍などで基礎を学び、実務を通して知識を身につけてきました。一方、ソフトウェアテストについて体系的に学ぶ機会はなく、過去のテストケースや自身の経験をもとにテストケースを作成していました。実装者がテス...

要約欠落検知長時間動くAIエージェントは、会話や作業履歴をいつか圧縮します。圧縮そのものは問題ではありません。危険なのは、完成条件、禁止操作、消費済み承認、外部writeの有無などが要約から抜けても、次のrunが「前回の続き」として実行を始めることです。byte列のhashだけでは、元会話と要約が違うことしか分かりません。必要なのは、再開に不可欠な情報を構造化して取り出し、圧縮後にも同じ不変条件が残っているかを検査するsemantic checksumです。この記事ではTypeScriptのmanifest、圧縮前後の照合、fail-closed、負試験までを組み立てます。 ...

◀前の記事へ 次の記事へ▶︎続きをみる

1. はじめに消費税率変更のような、頻繁に改正が入る制度対応のテスト工程を任されるとしたら、どう備えるか。この手の案件で必ず出てくるのが、「税額計算のロジックは、当時の担当者しか経緯を知らないレガシーコードに埋まっている」という状況だ。仕様書はなく、テストもない。触れば動くので誰も触っていない。だが税率が変わる以上、いつかは触らざるを得ない。こういうコードに手を入れる前提として、まず「保護テスト基盤」を作っておきたい。改修前の挙動をそのまま資産化しておけば、実際の税率変更作業に入ったときに「この変更で意図せず他の挙動まで壊していないか」を機械的に確認できる。これがCharacte...

先日、Tamachi.sre #6 で LT をしてきました。タイトルは「SRE への勘違いに気づいた後の話」です。 Tamachi.sre#6 (2026/09/17 19:05〜)# 開催概要 * 日時：2026/09/17 * 会場：株式会社ログラス オフィス * 参加費：無料 Tatamachi-sre.connpass.com 続きをみる

Coding Agentに実装を任せていると、テストも簡単に増えていきます。コードを変更する。AIが変更に合わせてテストを書く。テストを実行してGreenになる。便利です。ただ、最近少し気になることがあります。そのテスト、本当に必要だったのだろうか。「変更し...

Hooksを使う理由CLAUDE.mdやSkillに書いた指示はお願いであって、強制ではない確実に実行されるのはHooksだけであるそのため、品質を担保するチェックは、確実に実行されるHooksに置くことを原則とした下記、各タイミングと実行、内容であるタイミング実行内容ファイル修正時Hookslint、typecheck、関連する単体テストコミット時Hooks単体テスト全体、結合テストマージ時CI全テスト＋E2E 1.ファイル修正時のチェック（変更したファイルに関連する単体テストのみを実施）開発用ブランチでファイル修正...

APIが 200 OK を返した。でも、その後ろで動く処理まで成功したとは限りません。非同期処理では、APIがリクエストを受け付けた後に、キューやワーカーを介して処理が続きます。例えば、こんな流れです。APIは「受け付けた」というところまでしか保証していません...

最終回です。生成が成功したあとに何をしたか、という話をします。slide-forge の共通契約に、たった 1 行こう書かれています。API success is not visual QA.（API の成功は、視覚 QA ではない）この 1 行のために、今回 5 件の欠陥が見つかりました。 1. 検査は 2 段構えGate 1（オフライン）Gate 2（視覚 QA）いつ生成前生成後何を見る座標・文字量・重なりの計算サムネイル画像コストAPI を呼ばない（無料）画像を読むコマンド--dry-run --strict...

テストケース群が「十分か」を判定する仕組みを作っています。社内では QA Gauge と呼んでいます。テストケースを生成する AI ではなく、提出されたテストケース群に過不足がないかを判定する AI です。まだ「委譲できた」とは言えない段階なので、この記事はその実況の 1 本目になります。一言でいうと、QA の「判断」を LLM に委譲できるか。判定器そのものより先に、判定結果を評価する仕組みを作っている、という話です。 なぜ作ろうと思ったかきっかけは、QA の関与が局所的になっていることでした。QA チームが見られるのは依頼された案件だけで、本当は全案件に関与したい。ですが ...

テストケース群が「十分か」を判定する仕組みを作っています。社内では QA Gauge と呼んでいます。テストケースを生成する AI ではなく、提出されたテストケース群に過不足がないかを判定する AI です。まだ「委譲できた」とは言えない段階なので、この記事はその実況の 1 本目になります。一言でいうと、QA の「判断」を LLM に委譲できるか。判定器そのものより先に、判定結果を評価する仕組みを作っている、という話です。 なぜ作ろうと思ったかきっかけは、QA の関与が局所的になっていることでした。QA チームが見られるのは依頼された案件だけで、本当は全案件に関与したい。ですが ...

生成AI製品のPoC (概念実証) の合否が「担当者の印象」で決まることがある。デモが雰囲気よく見えた、応答がそれっぽかった、で採用判断をしてしまう。この記事は、AIサポート (カスタマーサポート自動応答) のPoCの成功指標を開始前に固定し、重み付きの評価ケース通過率で合否を判定する測定設計の記録である。対象は、LLMの応答品質をPoCで判定したいエンジニアと評価担当。判定をLLMジャッジに委ねる構成で、ジャッジ自身の出力もスキーマ検証する前提の話をする。検証日: 2026-09-03。評価対象は日本語のサポート応答、判定器はLLM + Valibot 1.4.2による出力検証。...

概要乱数はUnity標準のクラスが用意されていますが、各所で直接参照することはせず、インタフェース経由でアクセスするようにしています。直接参照インタフェース経由乱数アルゴリズムの変更面倒くさい実装クラスの改修、或いは差し替えで対応できる特定条件時のテスト相当難しいスタブで対応できる 準備乱数を使いたい処理が定義されているレイヤーにインタフェースを定義します。namespace MyGame.Domain{ /// <summary> /// 乱数生成器のインターフェース /// </su...

はじめに少し前に AIネイティブ開発でQCDはどう変わったか — 直近2週間を実測データで評価する という記事を書きました。人間中心の時代と比べて、AIが自走する体制で品質・コスト・納期がどう変わったかを、リリース記録と問い合わせ記録の突き合わせで評価したものです。その記事は、こんな問いで締めていました。現在こなしているのは不具合対応や画面高速化といった、比較的小規模で独立性の高いタスクが中心です。この体制が大規模な機能開発——複数サービスを跨ぐ新機能や、数週間規模の設計を要する開発——でも同じQCDを出せるのか。 ここはまだ未知数です。本記事はその回答編です。あれから2...

はじめにイノベーション開発チームのkuniです！現在はITトレンドのリプレイスPJに従事しています。最近の開発ではAIエージェントに実装を任せることが多く、PRやテストコードが増えるようになりました。アウトプットが多くなった反面、CIの稼働時間が増えるという問題が発生しました。今回はCIの稼働時間を、CIの目的を維持したまま削減した話をしたいと思います。最終的にはCIの1runあたりの稼働時間を144分から39分（73%削減）にすることができました。この記事では、実際に行った3つの対応を紹介します。!記事に載せているコードは、要点だけを抜き出したものです。実際のコ...

はじめにテストの根っこは、「なぜそのテストをするのか」の判断にあると考えています。技法を選ぶことも、値を決めることも、期待値を書くことも、その判断に続く作業です。LLMにテスト設計をさせると、テストケースは揃います。ところが、テストを選んだ理由は成果物から見えないことが多い。そしてレビューのためにコンテキスト（会話の履歴）を切ると、会話の中でだけ述べられていた理由は、レビューに届かなくなります。以前の記事「生成AIにどう根拠を残させるか — ハルシネーション対策の話」の続きとして、この理由をどう残すかを書きます。 「なぜそのテストをするのか」が根っこである理由テストは全部...

設定ファイルの検査ツールを作っています。README の1画面目にこう書いてあります。指摘は、公式ドキュメントが「エラーになる」「スキップされる」「無視される」と明記しているものだけ。この方針の帰結として、あえて検査しないものの一覧があります。いちばん分かりやすいのはこれ。未知のキー。 公式が「スキーマは最新 CLI に遅れる」と明記しているので、検査すると新機能を使うたびに誤検出する。良い規則だと思っています。いまも思っています。そしてこれが、自分の製品が4箇所で壊れた行を数日間配っていた理由です。 検査は通っていた有料ガイドに章を足そうとして、先に自分の製...

🌱 はじめに2026年8月27日に発売された『QAエンジニア入門 〜チームで品質を高める連携のしかた』（岩崎 駿 著）を読みました。テスト手順書の書き方について、誰にも教わることがなく「自分だけ分かればいいや」という手順書を作成しておりました。改めて再学習のために備忘録として残します。https://gihyo.jp/book/2026/978-4-297-15832-3「自分だけ分かればいいや」で書いた手順書は、次のような困り方をします。3か月後の自分が読んでも、どのアカウントで試したのか分からないレビュー時に「その手順で本当に不具合が再現するのか」を追えない他の...

APIから応答を受け取った直後でも、その中身が最新とは限りません。キャッシュや集計処理を経たデータなら、「今取得した」と「今の状態を表している」は別の話です。この記事では、ダッシュボードの更新時刻を表示する小さな関数を作り、境界値を固定したテストで確かめます。対象はJavaScriptでAPIの取得結果を表示する開発者です。通信、ウォレット接続、外部ライブラリは使いません。 まず、何の時刻かを分ける同じ「更新時刻」というラベルに、次の値を混ぜないようにします。名前意味それだけでは分からないことreceivedAtMsこのクライアントが応答を受信した時刻デ...

GitHub Actions で Node.js プロジェクトの CI を構築する 概要Node.js プロジェクトに GitHub Actions で CI を導入し、「Pull Request を出したら自動で Lint・型チェック・テストが走る」状態をゼロから構築するハンズオンです。最小構成から始め、複数バージョンでのマトリクス実行、キャッシュによる高速化、必須チェック化まで段階的に進めます。この記事のワークフローは、パブリックに公開されている GitHub Actions・npm の仕様のみに基づいています。 環境Node.js（LTS 系。この記事では Ac...

PoCで動いた最適化モデルを、本番システムとして動かし続けるための本です。100行のシフト最適化PoCを題材に、モデルのテスト設計、入力データのバリデーション、実行不能の仕様化とシミュレーション評価、非同期API化と可観測性、解の説明責任・human-in-the-loop・ドリフト監視・効果検証までを扱います。求解だけで終わらせず、現場で使い続けられるシステムへ育てます。

こんにちは、ヤプリでQAをしている今西(@TKNW_Hitsuji)です。 弊社ではQAフェーズになって考慮できていない仕様が見つかり、リリース後の後追い対応、場合によってはリリース遅延という状態になったことが過去数件ありました。 リリース後の振り返りで、それらほとんどは仕様策定のフェーズで発見・議論できていれば未然に防げた問題であったという結論が多く、どうにかできないかと悩んでいました。 そこで、仕様策定フェーズの段階で、QAフェーズの観点から内容を見て指摘・議論できれば先にあげたような状態は起きないはずという仮説を立てて、社内のQAナレッジリポジトリに、/create-test-plan …

こんにちは、d_arisan です。株式会社RebaseでQAとして参画しています。今回は、テスト設計のプロセスそのものをAIスキルとして組み立て、実務で回してみた話を書きたいと思います。うまくいった部分だけでなく、「半自動化したことで新しく発生した面倒」まで含めて共有できればと思います。3行サマリQA専任が少人数のまま複数プロダクトを見る限界がきて、QAプロセスごとAIスキルにした金銭の計算が絡む大規模施策を、リリース後の不具合報告なしで通せたただし検証コストは消えず、属人化は「スキルを書ける人が限られる」に置き換わっただけだったなお本記事は個人の実践記録で、参画先...

こんにちは、d_arisan です。株式会社RebaseでQAとして参画しています。今回は、テスト設計のプロセスそのものをAIスキルとして組み立て、実務で回してみた話を書きたいと思います。うまくいった部分だけでなく、「半自動化したことで新しく発生した面倒」まで含めて共有できればと思います。3行サマリQA専任が少人数のまま複数プロダクトを見る限界がきて、QAプロセスごとAIスキルにした金銭の計算が絡む大規模施策を、リリース後の不具合報告なしで通せたただし検証コストは消えず、属人化は「スキルを書ける人が限られる」に置き換わっただけだったなお本記事は個人の実践記録で、参画先...

AIが書いたコードを、そのまま工場のラインに入れることはできない。Webのアプリなら、バグが出てもロールバックすれば済むことが多い。だがFAのコードは装置を物理的に動かす。誤動作は機械の破損や、最悪の場合は人の安全に関わる。だからAIに書かせるほど、検証の工程が重くなる。この記事では、自分がAI生成コードを実機に入れる前に通している検証の流れを書く。大きく3段あって、仕様トレース、机上トレース、独立レビューの順で絞り込んでいく。特別な道具はいらない。Claude Desktopの機能と、自分の目でできる範囲の話だ。 前提：生成しっぱなしにしないまず心構えとして、AIが出したコード...

初めにどうも、某自社開発系の会社でエンジニアをしている者です。私は去年の年末ごろ、業務の方でAIエージェントが絡んだ機能の開発を担当していました。その際、AIエージェントの運用設計（AgentOps）、特にその中核となる「評価方法」についても設計する機会を頂けました。今でも勿論そうですが、当時は情報がかなり少なく自分でも一次情報を求めて奔走していました。この記事では、AgentOpsを設計する際に実際に調べた事やそこで得られた知見を備忘録的にまとめたいと思います。こういった0から1を考える際、生成AIに頼り切るのはまだ難しい現状があると思います。この記事では評価設計の知...

🌱 はじめに2026年8月27日に発売された『QAエンジニア入門 〜チームで品質を高める連携のしかた』（岩崎 駿 著）を読みました。観点について綺麗にまとめられていたので、備忘録として残します。https://gihyo.jp/book/2026/978-4-297-15832-3本記事で言う「観点」は、テストで何を確認するかの切り口（テスト観点）を指します。説明が具体的になるよう、オンラインショップ（商品を検索してカートに入れ、クーポンを使って購入するEC（電子商取引）サイト）を題材にします。!例文の - は観点が抜けた確認、+ は観点を踏まえた確認を表します例文...

🌱 はじめに2026年8月27日に発売された『QAエンジニア入門 〜チームで品質を高める連携のしかた』（岩崎 駿 著）を読みました。観点について綺麗にまとめられていたので、備忘録として残します。https://gihyo.jp/book/2026/978-4-297-15832-3本記事で言う「観点」は、テストで何を確認するかの切り口（テスト観点）を指します。説明が具体的になるよう、オンラインショップ（商品を検索してカートに入れ、クーポンを使って購入するEC（電子商取引）サイト）を題材にします。!例文の - は観点が抜けた確認、+ は観点を踏まえた確認を表します例文...

Our industry partner focuses on quality assurance for industrial systems across multiple domains, including maritime systems, such as overwater vessels and autonomous underwater robots (AURs). Despite the strong performance of vision-language models (VLMs) in scene understanding, image captioning, and object recognition, their use in AUR software operating in underwater environments is underexplored. Therefore, in this context, it is important to evaluate the quality of VLMs for integration into

はじめにこんにちは。ウェルスナビで QA を担当している船場です。本記事では QA エンジニアが後工程のテストの実施以外でも品質向上に貢献した次の 3 つの取り組みについて紹介します。仕様共有のミーティングを「共同レビューの場」にするテストレベルごとの担当チームの振り分けテスト設計技法をチーム全員の仕様理解のために活用 想定読者テストの実施だけでなく、開発プロセスの改善にも関わりたい QA エンジニアシフトレフトに取り組みたいものの、具体的な始め方が分からない QA エンジニアQA チームと連携し、開発工程から品質を作り込む方法を検討しているエンジニア、P...

はじめにこんにちは。ウェルスナビで QA を担当している船場です。本記事では QA エンジニアが後工程のテストの実施以外でも品質向上に貢献した次の 3 つの取り組みについて紹介します。仕様共有のミーティングを「共同レビューの場」にするテストレベルごとの担当チームの振り分けテスト設計技法をチーム全員の仕様理解のために活用 想定読者テストの実施だけでなく、開発プロセスの改善にも関わりたい QA エンジニアシフトレフトに取り組みたいものの、具体的な始め方が分からない QA エンジニアQA チームと連携し、開発工程から品質を作り込む方法を検討しているエンジニア、P...

借金は、返すこと以上に新たに借りないのが重要である。技術的負債でも同様で、解消が大変なことはもちろんだが、それ以上に解消したはずの負債が知らないうちに積み増されるのが一番キツい。誰かが地道に前に進めてくれているのに、別の誰かが悪気なく新たな負債を生みうる。また、一旦解消しても数年後に負債が復活することもある。AI コーディングの時代になって負債の解消は進めやすくなったが、確率的な手法に頼るかぎり、負債が新たに生まれるリスクは避けきれない。これを防ぐため HERP Hire のコードベースでは、技術的負債の解消が後戻りしない「Ratcheting」と呼ばれる仕組みを入れてみた。...

Human evaluation provides a direct measure of the quality of LLM-generated web applications. However, fitting human judgments through automated evaluation remains challenging. Static benchmarks can credit functionality that exists in source code but is unreachable at runtime. Interactive benchmarks exercise the application, yet incomplete exploration can cause them to miss implemented functionality and confound application defects with agent execution failures. To address these limitations, we p

フロントエンドカンファレンス福岡2026に参加した。2018年、2019年の開催から7年ぶりのオフライン開催で、会場は九州産業大学。自社がシルバースポンサーとしてブースを出すので、地元ということもあってブース対応要員として参加した。なので全部のセッションを聞けたわけではなかったが、合間に聞いた3つはどれも気づきがあってよかった。フロントエンドカンファレンス福岡は参加が初めてだったが、違う側面からテストを捉え直すことができていい機会だった。https://note.com/kaonavi_devs/n/n2d7ebe51b32b続きをみる

デブサミ福岡2026の登壇資料ですhttps://event.shoeisha.jp/devsumi/20260911/session/7157