2025アドベントカレンダー『APIテスト』
このマンガは『ソフトウェアテスト Advent Calendar 2025』24日目の記事です。
……力尽きたので解説は別途書きます～＞＜
【MCP】AIからPlaywright MCPや別のMCPサーバーの自動的な使い分けをさせてみよう【ローカル】
こんにちは！ 作者です。
作者はすっかりとハードウェアの人をやっており、今も趣味でロボット作りの真っ最中です(笑)
ついについに！帽子がつきました！
— Matsu(まつ)@Testerchan (@mty_mno) 2025年9月7日
アップリケだけつくってます✨
やっぱり帽子があるとかわいい…
あと、ハロがPCのブラウザを操作できるようにしました。ハロが何かを教えたかったりオススメしたかったりしたらブラウザを開いて見せてくれます🥰 pic.twitter.com/YHG5Th2jA6
さて、機能拡張としてこのロボットにMCPの機能を付けました。
その時にAIからmcpサーバーの使い分けをする最小構成をつくったりしたので、ブログでもそこを公開しようと思い立ちました。
MCPって何がうれしいの？
AIにやってもらいたいこととして
「これやっておいて」
といったら、AI側でそれを実現できるツールをよしなに選択してイイカンジにやっておいてほしいわけです。
「MCPの概要を教えて」
といったら、検索ツールに接続して結果をイイカンジに教えてくれたり、
「洗濯機回しておいて」
といったら、検索ではなく、洗濯機をスタートさせてもらいたいわけです。
なんだけど、今まではツールへの指示方法がバラバラだからそれぞれで実装が必要で大変、という現実がありました。
それを「同じにしたらいいじゃん」というのがMCPなわけです。
なので本来やりたいこととしては
「AI側が目的を達成できるツールをよしなに選んで実行できること」
これになります。
実際にAIに出し分けさせるような例が少なめ？
MCPの簡単な例を探していると、MPCサーバー実装してクライアント実装して直接叩いて結果が出る……が多い気がしました。
AIからよしなにツール使い分けは？となりましたので、簡易的な例を作ってブログに置いておこうと思った次第でした。
Playwright MCPとBrave search MCPの使い分けをやってみる
まずはコード。
これでAIに
「テスターちゃんの概要を教えて？」
と言えばBrave search MCPが呼び出されますし
「https://hotel-example-site.takeyaqa.dev/ja/ にアクセスして、宿泊予約をクリックして、どんなプランがあるか教えて」
と言えばPlaywright MCPでブラウザがゴリゴリ動いてプランを教えてくれます。
メッセージを投げるだけで、AI側でよしなにツールの使い分けをしてくれる というわけです。
import { Agent, run, MCPServerStdio } from "@openai/agents"; // Brave（検索）— 同一PCで子プロセス起動（stdio） const brave = new MCPServerStdio({ name: "brave", // 公式サーバーを使うなら: "npx -y @brave/brave-search-mcp-server" fullCommand: "npx -y brave-search-mcp", env: { BRAVE_API_KEY: process.env.BRAVE_API_KEY }, }); // Playwright（ブラウザ操作）— 同一PCで子プロセス起動（stdio） const playwright = new MCPServerStdio({ name: "playwright", fullCommand: "npx -y @playwright/mcp@latest --browser=chromium", env: { // 画面を表示したい時は headless を使わない（デフォで表示されます） // 明示したいなら次行をコメント解除: HEADLESS: "0", }, }); await brave.connect(); await playwright.connect(); try { const agent = new Agent({ name: "local-mcp-agent", model: "gpt-4o-mini", instructions: ` あなたはMCPツールを使ってユーザーの依頼を解決します。 - Web/ニュース/画像の検索: 「brave」を使う。 - 実ブラウザ操作（遷移/クリック/入力/待機など）: 「playwright」を使う。 - 出典URLや実行手順を簡潔に示し、日本語で答える。`, mcpServers: [brave, playwright], }); const query = process.argv[2] ?? "https://hotel-example-site.takeyaqa.dev/ja/ にアクセスして、宿泊予約をクリックして、どんなプランがあるか教えて"; const result = await run(agent, query); // きれいにして標準出力（JSONのみ） process.stdout.write(JSON.stringify({ output: result.finalOutput }) + "\n"); } catch (e) { console.error(e?.stack || String(e)); process.exitCode = 1; } finally { await Promise.allSettled([brave.close(), playwright.close()]); }
前準備
- node.js v20以上のインストール
- npmのインストール
- Brave Search API keyのゲット (不要な場合はコードからBrave事態を取ってしまえばよいです)
- OpenAI API keyのゲット
必要なもののインストール
npm i @openai/agents
playwrightのブラウザもインストール
npx playwright install chromium
API keyの設定
windowsのpowershellだと以下
$env:OPENAI_API_KEY = "<あなたのOpenAI APIキー>" $env:BRAVE_API_KEY = "<あなたのBrave APIキー>"
macなどだと以下
export OPENAI_API_KEY="あなたのOpenAI APIキー" export BRAVE_API_KEY="あなたのBrave APIキー"
実行
以下の様に入力すると、AIがよしなにplaywright MCPを選択して自動テスト練習サイトを開き、プラン情報を取得してくれます。
node index.mjs "https://hotel-example-site.takeyaqa.dev/ja/ にアクセスして、宿泊予約をクリックして、どんなプランがあるか教えて"
以下の様に入力すると、AIがよしなにBrave search MCPを選択して検索結果を教えてくれます。
node index.mjs "テスターちゃんについて教えて"
説明
このコードはOpenAI Agent SDKを使っています。
また、このコードではコードを実行している同じPC上でのMCPサーバー実行をさせています。(標準入出力を使用)
サービスの追加
以下の様に、使いたいMCPサーバーを追加していけばよいです。
// Brave（検索）— 同一PCで子プロセス起動（stdio） const brave = new MCPServerStdio({ name: "brave", // 公式サーバーを使うなら: "npx -y @brave/brave-search-mcp-server" fullCommand: "npx -y brave-search-mcp", env: { BRAVE_API_KEY: process.env.BRAVE_API_KEY }, }); // Playwright（ブラウザ操作）— 同一PCで子プロセス起動（stdio） const playwright = new MCPServerStdio({ name: "playwright", fullCommand: "npx -y @playwright/mcp@latest --browser=chromium", env: { // 画面を表示したい時は headless を使わない（デフォで表示されます） // 明示したいなら次行をコメント解除: HEADLESS: "0", }, }); await brave.connect(); await playwright.connect();
fullCommandは、自分のPCで動かすときのコマンドです。
envには渡したい環境変数を書きます。(braveだとapi keyなどですね)
外部公開されているサービスとやり取りしたい
外部の公開MCPサーバーとやり取りしたい場合はこんな感じにすればよいです。
const playwright = new MCPServerStreamableHttp({ name: "playwright", url: "https://~~~~~~~~~~~~~~~~~", // 認証をかけている場合はヘッダも渡せる // requestInit: { headers: { Authorization: "Bearer xxx" } }, });
playwrightなど、他のPCで実行してるんだけどどうアクセスしよう……
という人はngrokを使うのもよさそうです。
(ローカルPC上で動いているモノを外部公開できるサービス)
……って、やろうとしたらウィルス判定されているし……。
AI側の設定
const agent = new Agent({
name: "multi-mcp-agent",
model: "gpt-4o-mini",
instructions: `
あなたはMCPツールを使ってユーザーの依頼を解決します。
- Web/ニュース/画像の検索: 「brave」を使う。
- 実ブラウザ操作（遷移/クリック/入力/待機など）: 「playwright」を使う。
- 出典URLや実行手順を簡潔に示し、日本語で答える。`,
mcpServers: [brave, playwright],
});
まずnameは、任意で自分でつける名前です。
modelは今は安いやつを使っていますが、任意で変更ができます。
instructionsは、AIの役割を指示しています。実際の処理したいクエリはコマンド実行時に与えています。
mcpServersに上で設定したサービス名(braveやplaywright)を列挙します。
これだけでよしなにAIが使い分けをしてくれます。
最後に
よくよく考えたら、AIツールを開発している人にしか需要がないかもしれません(汗)
けど、これで僕が作っているハロが世界のリソースに手を延ばせるぞ……ふふふ……。
新卒向けのソフトウェアテスト入門の資料が公開されました！
こんにちは！ 作者です。
2025/8月現在勤めている会社で、開発エンジニアの新卒研修を担当していました。
資料が公開されましたのでここにも共有します。
資料や動画は、ぜひぜひ勉強会や社内の研修などでご自由にお使いいただければ幸いです～！
ただし、以下の注意は守ってくださるようお願いします。
- 受講者から参加費や授業料など金銭を集めるような場での利用（会場費や飲食費など勉強会の運営に必要な実費を集める場合は問題ありません）
- 出典を削除または改変しての利用
QAとは&ソフトウェアテスト入門
勉強会の動画(2時間くらいあります)
他、開発エンジニア向けの新卒研修全部
なにそれ？あなたの知らないテストの言葉第4回「プロパティベーステスト」
ベリサーブ様での連載第4回は「プロパティベーステスト」です。
このテストの方法は開発者向けの方法です。
通常のテストは代表的な値と期待結果を決めてテストを行います。
プロパティベーステストは、テスト対象が「こうなるはずだ」というルール（性質）を決めて、自動的に生成したデータをじゃんじゃんと入れて、そのルールが常に成り立つかを確認するテストの方法です。
例えば、ひらがなとカタカナ以外の文字列は削除されるようなゲームの名前入力欄があったとしたら、特定の「ああああ」といった名前での確認が従来の方法で、プロパティベーステストは「出力はひらがな、カタカナ、または空白になる」というルール（性質）を決めて、文字の全集合から文字列を入れまくってそのルールが破綻するものがないかテストします。
これ以上書いてしまうと怒られそうなので、よければ記事を見てください～！
なにそれ？あなたの知らないテストの言葉：第３回「メタモルフィックテスティング」
最近マンガを描いていないように思われがちですが、月間連載で「なにそれ？あなたの知らないテストの言葉」というマニアックなテスト用語解説マンガの連載を行っています。
いまさら気づいたのですが、ログインしないと読めない仕組みだったのですね……＞＜
自由に見れる記事なのかと思っていました(^-^;
さて、第３回はメタモルフィックテスティングについて書きました。
会員限定だとこちらのブログで内容を書いてしまったら「報酬は没収だ！」と言われかねませんねｗ 控えておきます。
メタモルフィックテスティングは、期待結果が正しいのか判定する方法(テストオラクル)がない場合に有効な手法として提案されました。
通常のテストでは期待結果を用意して合否を判定します。しかしAIの出力など、期待結果を知ることが難しい場合があります。その場合に、入力に変化を加えた際の出力の変化との関係性を疑似的なテストオラクルとしてテストの合否を判定します。
そのことについてマンガや記事で説明をしていますので良ければ見てみてください！
マンガがたまったら書籍化を打診していきたいと目論んでいます(笑)
老後資金&FIREシミュレーターを作った【ご自由に改造してお使いください】
こんにちは。テスターちゃん作者です！
最近マンガを描いていない……わけではなく、テスターちゃん外伝的なものを月一で連載しています。こちらはまた別のブログでかきますね！
老後資金&FIREシミュレーターを作った【ご自由に改造してお使いください】
体調不良で寝ていたのですが、その際にFIRE含め退職後の老後にどれくらいのお金が必要なのか突然気になりました。
そこで、ChatGPTでDeep Researchを行い、その結果を使ってWEBアプリ「老後資金&FIREシミュレーター」を作ってみました。
ブラウザだけで完結し、特にデータ通信することもありません。
ご自由に遊んでみてください！
作者が独身ということもあり、家族の設定はありません。
気になる方がいましたら、お好きなように改造してお使いください。
あと、仕様書も作っていますｗ
少し難し目にはなりそうですが、ソフトウェアテストの研修などにもご自由にお使いください～！！
↓WEBアプリ画像です。
趣味・徒然なるままに
今回はテストの話はしませんので悪しからず。
やっていた大きな仕事が一区切りついたのでようやく人心地がついたといったところです。
他にもやることがあるにはありますが、急に手持無沙汰にはなりましたので思い浮かぶままに文を書こうと思い立ちました。
趣味についてです。
- 人生を彩るためには趣味が大切
- FIREを目指している人もリタイア前に趣味を持っておいた方が良いのでは？
- そう言われても趣味がないんだが？
- 何かをつくる趣味の醍醐味は、妄想が具現化すること
- 趣味発見の天敵は「面倒くさい」
- 同じぐらい残念な考え「タイパ」
- 今までやった「作る趣味」を簡単に紹介
人生を彩るためには趣味が大切
ようやく空いた週末。
プラモデルを作り、ゲーム開発をしていたらあっという間に休日が終わってしまいました。
趣味の活動にいそしんでいたわけです。
ここ半年ほどは土日も働いたり、休んでもボーっとYouTubeを見ていたら休日が終わっていたことが多かったです。そんな休日はエネルギーを充電したというより「自分なにをやっていたんだろう……？」と人生のろうそくを無為に溶かしてしまったような気持ちが強かったです。
趣味に時間を使った日は充実感が違います。
プラモデルを作って「かっこいいなー」とやっていただけなのに妙な達成感があります(笑)
ああ今日は楽しかったな、と思いながらこの話を書いています。
MPが回復したという実感があります(笑)
他の人はどうかは知らないけれど、僕にとっては心の栄養補給をするためにも、日々を楽しむためにも趣味は必要不可欠なモノなのでしょう。
FIREを目指している人もリタイア前に趣味を持っておいた方が良いのでは？
FIREはFinancial Independence, Retire Earlyの略で、経済的に自立して早期リタイヤをすることを指します。
「働くのがイヤだから早く生涯生活できる分を稼いでさっさと退職したい」というモチベーションで目指している人が多いと感じています。
話は変わりますが父は退職して家でテレビを見てゴロゴロしています。
仕事をしているときは「早く年金生活して好きなことをしていたい」とよく言っていました。
けどいざ退職すると、趣味がなく、やりたいこともないようでかなり暇を持て余していました。テレビを見ているのですが、見たいものもなくずっと繰り返して孤独のグルメを見ていました。
最近になって母に連れられて近所の卓球の集まりに参加して楽しんでいるようです。
何が言いたいかというと、やりたいことがないのに時間ばかり得ても暇を持て余してしまうということです。
暇というのは想像以上に苦痛とのことです。
話を戻します。
FIREを達成して時間を得られたとしましょう。
毎日が日曜です。
よって、それが今の生活の延長だと仮定すると、今、日曜日にやっていることを毎日繰り返すことになるでしょう。
僕は半年ほどニート生活をしてみたことがありますが、その際はDIYとゲーム作りを繰り返していました。
じゃあ無目的にYouTubeを見続けている人は？
おそらくFIRE後は毎日それを繰り返します。
それが楽しくて人生の潤いにつながっているならいいですが、そうでないのなら、楽しみ（趣味）を見つけたほうが日々の充実には良さそうです。
そう言われても趣味がないんだが？
よく言われるのが以下です。
「子どものころ好きだったものはなんですか？」
子どものころ好きだったけど、いつの間にかやめてしまった、お金がなくてできなかったことは何でしょうか？
それらをリストアップすると心惹かれるものが現れたりします。
僕なんかは昔アーケードゲームが好きだったことを思い出し、それらをDIYで作ったりしたことがあります。
これをすればよい、と勧められたらいいのですがそういった気の利いたことは思い浮かびません。
自分のことを書くので、もし興味がわいたなら手を出してみてはいかがでしょうか。
まず趣味は大きく鑑賞系と実践系の二つにわけられます。
鑑賞系はスポーツ観戦や映画、アートなどがあります。
実践系は何かを作ったり、スポーツを実際にやったり、旅をしたりなどが挙げられます。
実践系の趣味は、何かをつくる趣味や己のスキルを磨く趣味、といったようなものがありそうです。
僕は「つくる趣味」に偏っています。
何かをつくる趣味の醍醐味は、妄想が具現化すること
妄想したものが形になる。
簡単な物でももちろん嬉しいし、時間がかかったものだと出来たときに本当に感動します。
作っている過程も楽しいです。
「あれをしよう」
「これをしたらもっとよくなるのでは……」
そんなことをアレコレ考えるのも楽しいですし、それが少しずつ形を成していくのは達成感があります。
僕の先ほどの例だと、その昔喫茶店で見たテーブル筐体をこの手で作り上げて、それが目の前に物体として現れたわけです。
そのうえで食べ物を食べながらゲームをしたりしました。
子どものころの思い出が蘇ります。
ゲームであれば、その昔好きだったものをこの手で作り上げて、自分でできるように作ったりもできます。
僕は高校のころBM98という音ゲーが好きで、それをVRで再現したこともありました。
BMSFitness on SideQuest Oculus Quest Games & Apps including AppLab Games ( Oculus App Lab )
想像力と工夫次第でなんでもできるのがこの趣味の良いところです。
趣味発見の天敵は「面倒くさい」
趣味は「やってみよう」からはじまります。
それを邪魔するのが「面倒くさい」です。
面倒くさいと思った時点で、行動せずに終わります。
趣味というのは何か楽しみを見つけて「もっとやってみよう」と続いていきます。
楽しみを見つける前に「面倒くさい」と思ってやめてしまうと、結局は何も趣味になりません。
まずやってみる。
やってみて「自分に合わないや」と思うならいいです。
「やってみたいけどなんか面倒くさくて……。いいや、ポテチ食いながらYouTubeでもかけとこ」
これが一番残念な結果です。
同じぐらい残念な考え「タイパ」
趣味にタイパ（タイムパフォーマンス）を持ち込むと途端に面白くなくなります。
例えば映画鑑賞。
「並行して映画を２本流して、かつ1.5倍速で見る」
どうでしょうか？
映画を楽しみたいというより、映画を消化したいだけになっていませんか。
DIYやお絵描きでも、タイパを考え始めたら自分で作る必要なんてなくなるかもしれません。
過程を楽しみたいのか、結果だけが欲しいのか、です。
趣味というものは過程そのものを楽しむものです。
今までやった「作る趣味」を簡単に紹介
簡単に紹介をしますので、ご興味があったら試してみてください。
お絵描き
自分が想像したものを絵にできるのは楽しいです。
最初は好きなキャラや絵を写すことからはじめるのがよいです。
ちなみに僕は趣味が高じて仕事になりました(笑)
そのうち、趣味を仕事にすることについての話も書きたいところです。
プラモデル
最近のプラモデルは出来が良く、色分けもされていて（ロボット系は）色塗りしなくてもカッコいいです。
バイクや車などのプラモデルは色を塗ったほうがより本物っぽくなります。
僕はよくロボットのプラモデルを作りますが、そのアニメはどれも見たことがありません。
カッコいいと思った！
だから買った！
作った！
カッコいい！
これだけです(笑)
DIY
僕の作業台です。
カラーボックスに板を載せただけ。
パソコンのデスクもカラーボックスに板を載せたものです。
これ、引っ越しの時にとても楽なのですよ(笑)
「広い机がほしい」
「引っ越しが多いので引っ越しのとき楽なのがいい」
そう考えてこれに行きつきました。
これも立派なDIYです。
のこぎりで切ったりなど、こったものを作る必要なんかありません。
「こういうものが必要だな」
と思ったものをとりあえず作ってみるとよいです。
レジンアート
昔、レジンで小物を作ったり置物をつくったりするのにハマりました。
よくレジンでアクセサリーを作っている人はいます。
光で固めるUVレジンやアクセサリー作成用の小物はどこでも手に入るのではじめやすいです。
僕がやっていたレジンは、エポキシレジンという２つの液を混ぜて固めるレジンでした。
好きな作家さんがいて真似をしたかったのです。
レゴブロック
小さい頃はレゴブロックが好きでした。
けどクリスマスか誕生日しか買ってもらえなくて……。
そんなことを思い出してレゴブロックを買って作ったりもしました。
確かにこの値段は特別な日にしか買えないとは思います。
パーツが細かいので、プラモデルよりも難易度は高めです。
ミニチュアづくり
ミニチュアといってもお菓子の箱のミニチュアです(笑)
今あるきのこの山から、その昔好きだったハンコください（きのこの山みたいなお菓子）まで作っていました。
なんでやっていたか？
小さくてかわいいからです(笑)
＊＊＊
このような感じです。
メジャーなものから「なんでそんなことしてるの？」まであります。
一番大切なことは、自分が楽しいかどうかです。
趣味に人なんて関係ありません。
「やりたい！」を最優先して、気の向くままやってみましょう！
プログラミング初心者ほど趣味のVibe codingをしよう
現在、趣味で横シューティングゲームを作っています。
これはVibe codingという手法……もといノリで作っていますので、今日はその辺の話をします。
Vibe codingとは
Vive codingとは、バイブス(音楽用語 : ノリ、雰囲気という意味)とAIに身を任せ、AIに全部コードを書いてもらうコーディング方法です。何か修正してもらっても差分は読まず「すべて承認」し、エラーメッセージが出たらそのエラーメッセージをコピペして直してもらいます。バグがなくならない場合は、回避できるまでランダムに変更を依頼するのです。
いうなれば音楽の即興演奏のように、自然言語によるAIとの即興コーディングスタイルです。
……いや、冗談とかではなくて。
発端となった投稿は以下です。
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…
— Andrej Karpathy (@karpathy) 2025年2月2日
妄想したことを伝えるとそれ通り動くものができる世の中になった
以下を見てください。妄想の絵です。妄想を走り書きしているので汚いのはご勘弁をｗ
↓実際にできたもの(3番目の動画)
https://x.com/mty_mno/status/1919610487249256651/video/3
最近のAIのコーディング能力はすさまじく、思ったことを伝えると大体想像したものができてきます。(私はo4-mini-highを使っています)
今朝は、会社に行く前にガンダムに出てくるビット（敵を追尾して攻撃するドローン(厳密には違うけど怒らないで))を作りたいと思い、以下のように頼んだ結果、37秒で妄想が具現化しました。ちなみにコードは読んでいません。
このコードを私が自分で実装するとしたら、出社前のちょっとした時間にはできません。少なくとも土日に腰を据えてようやく出来上がるといったところです。
これがコードを知らない人だったら、実現方法の調査からはじまりかなりの時間を費やすことでしょう。
しかし今はやりたいことをAIに伝えるだけで、コードを読まなくても（知らなくても）、妄想したものを具現化できる世の中になってきたわけです。
もちろん仕事上のコードでは非常に危険ですが、日曜大工よろしく、趣味としてのモノづくりをするには最高です。
プログラミング初心者ほど趣味のVibe codingをしてみるといい
このブログを読む人はテスターの方が多いと思います。
「プログラミングは知らないんだけど……ちょっと触ってみたい気もする」という人が結構いらっしゃるかと思っています。
そういった人ほど、ちょっと暇な時間に作りたいものを想像して、AIと即興のプログラミングをしてみるとよいです。
ゲームのような大掛かりのものではなく、javascriptなど準備がほとんどいらないもので（これもAIに聞けばpythonのセットアップでもなんでも丁寧に教えてくれます）試してみるとよいです。
今まではプログラムをはじめるまでの心理的障壁が高かったと思います。
思いのほか、非常に簡単に始められます。
それこそ「ちょっとやってみようかな」レベルでできてしまいます。
youtubeの視聴時間集計のextentionを作ってみたい？
作れます。
気になっていたテストコードというものを書いてみたい？
書けます。
dockerとやらを試してみたい？
いけます！
妄想したものが実際にモノになって動くと「おおお～！」と興奮すること間違いなしです！
ソフトウェア関係の「やってみたかったこと」へのハードルが大幅に下がりました。
まずは細かなお作法は置いておいて、バイブスに身を任せて色々と書きながら遊んでみるとよいです。
そうしているうちに、プログラミングへの心理的な障壁も減っていきます。
日曜大工ならぬ、日曜プログラミングという趣味になるかもしれませんｗ
以下はおまけ。思い浮かぶままに。
バグの直し方
最近は触っていて「そんなバグ作るなよ～」というものはほとんど見なくなりました。
けどやっぱり試しているとバグを見つけます。例えば先ほどの例ですと、実は一回でできたわけではなかったです。オブジェクトの向きやビームの向きが違いました。
どうやって修正するかというと、コードも読んでませんのでAIに全部頼みます。
他にもエラーコードが表示されるときがあります。
そのときもエラーコードを張り付けて修正を頼みます。
それでもうまく直せないバグは一からやり直す
うまく直せないバグも現れます。
私の場合、主人公を狙う敵弾が主人公からずれてしまうという問題があり、AIに質問をしまくりましたが直りませんでした。
仕方がないのでコードを読んで問題点を見つけて修正しました。
こんな苦労をするなら自分で描いたほうが早い……とmixi2でつぶやいたりしましたが、他の人から聞くには
「AIにイチからまた書かせた方が早い」
との意見をもらいました。
これはその通りで、そもそもAIの出力にはそんなに時間がかかりません。
なので「今まで描いたコードを消すのがもったいない」もありません（そもそも正しく動かないんだし）
なので今までのことを整理して、最初から「こういう仕様です」と伝えて作り直す方が問題個所を見つけるよりも早そうです。
即興で作っているのでテストコードが書きにくい
そもそも趣味で遊んでいるコードなのでそれはそうです。
それに、もし「作ったコードからテストコードを書く」になってしまうとマッチポンプになります。
なので、テストコードを書く場合は妄想したもののふるまいを書いたテストコードを先に書いて、そこからそれが通るプロダクトコードを書くことになりそうです。
ただ、テストコードも必要なコードを書くならバイブス言ってないでしっかりとしたプロセスで開発を進めるのが良いです。
Vibe codingはさておき、AIでコードを書く全般についてTDDの相性がよさそうだとは考えています。
慣れているつもりでも「え、そんな書き方があったの」が出てきて学べる
シューティングゲームの場合、画面外に弾が出た場合は削除します。
難しいことはなく、画面の座標を超えたらオブジェクトを削除すればいいです。
ロジックも簡単なので調べることなく自分なら書いてしまいます。
ですがAIに頼んだら
「カメラの外に出たら自動的に呼ばれるメソッド」
なるものが存在していて1行で完了！
そんな便利なものがあることをそもそも知りませんでした。
AIに書いてもらったことによってその存在を知ったわけです。
こういう場面が何度もありました。
というより自分で書くより処理がいいじゃん……となりました＞＜
レビューやテストの重要性が増す
最後にバイブスに身を任せるVibe codingから少し離れて、AIによるコーディング全般に目を向けます。
AIによって動く成果物が提出されるわけです。
つまり最初の要求や要件定義と、それと対になる「検証」「妥当性確認」が人間側の役割になります。
こうなってくると、AIが作ったものをいかに効率よく検証するか、どのように妥当であるか確認するかの技術がより求められてきます。
我々テスターの今やっている仕事がメインになる可能性があります。
プロダクトによらない部分のテストケースはAIで
こんにちは！ 作者です。
マンガはどうした！というお声をいただきそうですが、次回は4/25(金)に公開されますので今しばらくお待ちください～。
プロダクトによらない部分のテストケースはAIで
ある日の朝会で、SSID(wifiの名前のようなもの)が日本語だと接続できない問題が上がりました。
そこで「SSIDの文字種による接続テスト」をしようとなったので、その場でAIにポイ。
1分ほどでテストケースの作成完了です。
その場でみんなでレビュー。
期待結果の「正常に接続できること」はプロダクト自体の挙動を与えていないので「それはそう」ではありますが、文字種のパターン部分は人が出しても大体同じでした。（加えるとしたら別言語パターン）
そのほか、接続エラー時の挙動やステルスSSIDなどの接続テストも必要だけれど、今は文字種での接続目的のテストなので別途テストです。
朝会が終わるまでに「SSIDの文字種による接続テスト」のテストケースはレビューを含めてサクッとできあがったのでした。
プロダクトによらない部分のテストケースづくりはAIでよさそう
「まつさん、何を食わせたのですか？」
と聞かれたのですけど、ブログに書いた通り「文字種でパターンを出して」しか与えていません。
今回のSSIDのように、プロダクトに依存しない一般的な部分については別途資料を与えずともパターンを出してくれそうです。
他にログイン時や入力ボックスへの入力パターンも出せそうです。
プロダクトに依存する部分（制限文字数など）を含めたい場合はプロンプトやドキュメントで与えてあげる必要は出てきます。
全体的にまとめてテストケースを吐かせるとパターンが雑になるというのは今のところ観測していて、今回の様にプロダクトに依存しない部分、一般的によくありそうな部分を切り出してケース作成もよさそうな作戦です。
そうですね……AIを新人さんに例えて「新人さんに作成を任せるならどのケース？」なんて考え方をしても面白いかもしれませんねｗ
今後はMCPとつなげてテスト実行……と夢が広がります！
