AIで開発したものを動画で確認する | ソフトウェア検証エンジニアリングTIPS

AIが書いたコードを、誰がどう確かめるか

AIにコードを書かせると、開発はたしかに速くなります。一方で、AIが書いた大量のコードを人が一行ずつ読んで確かめる、という従来のレビューは追いつかなくなってきました。

この状況について、海外のブログで「ソフトウェア検証エンジニア（Software Verification Engineer）」という役割が提唱されています。検証エンジニアという職種自体は、自動車や医療機器などの分野で以前からある、作られたものが仕様どおりに動くことを確かめて記録する専門職です。Leonid Bugaev氏の記事は、この役割をAI開発の文脈で捉え直しています。要点は次のとおりです。

• AIが生成するコードの量は、人のレビューでは吸収しきれない
• 人は全行を読む代わりに、確かめるための環境、合格のルール、証拠の形を用意する
• ルールはAIへの指示文に書くだけでなく、実際に実行される検査にする
• 画面の変更なら操作の録画、システム間の連携なら実際の呼び出し結果を証拠にする
• 証拠がないものは「問題なし」ではなく「未解決」として見えるようにする

つまり、これからの確認は「コードを読むこと」から「動いた証拠を見ること」へ移っていく、という話です。

確かめる手法はいろいろある

AIの成果物を確かめる手法には、たとえば次のようなものがあります。当社でも、案件に応じて組み合わせています。

どれも大切ですが、自動テストの仕組みづくりや、監査のルールづくりには準備が要ります。そのなかで、今日からすぐに始められて、効果が高いのが最後の「動画プレビュー」です。

なぜ動画プレビューなのか

当社がAIに開発を任せてきた作業ログを読み返すと、AIの「できました」と実際の状態が食い違っていた場面がいくつも見つかりました。案件が特定されないよう細部は伏せますが、たとえば次のようなものです。

• 自動テストはすべて通過し、画面に画像が出ることも確認済み。ところが「仮の画像ではないですよね？」と聞くと、AIは「はい、仮の画像です」と答えた
• 「ボタンが押せない」不具合に、AIが2回続けて「直しました」と報告した。実際にはボタンは反応していて、押すたびに費用のかかる処理が裏で始まっていた。見た目が変わらないので、押せていないように見えていただけだった
• AIが画面なしの自動計測をもとに「直りました」と報告したが、実際のスマートフォンでは見出しが本文と同じ大きさのままだった

どれも、AIが見ていたものと、利用者が見るものがずれていたために起きています。テストの結果やコードは「AIが見たもの」です。利用者と同じ操作をして、画面がどう変わったかを録画すれば、このずれは一目でわかります。

動画には、静止画のスクリーンショットにはない強みもあります。

• 押す前と押した後で、画面がどう変わったかがわかる
• 読み込み中の表示や、処理が二重に動いていないかがわかる
• 技術に詳しくない人でも、見れば良し悪しを判断できる
• 「何を、どの順番で確かめたか」がそのまま記録として残る

この記事も、動画でプレビューしてみた

試しに、この記事自体の公開前確認を動画で行いました。

きっかけは、下書きを当社サイトに載せて読んだ担当者の「表示が崩れている」という一言です。見ると、見出しの大きさがばらばらでした。同じ階層の見出しなのに、大きく太く出るものと、本文と同じ大きさで出るものが混ざっていて、章の区切りが見えません。

そこで、確認の手順を決めて動画にしました。320・360・390・430ピクセルの4つのスマートフォン幅で記事を同時に開き、次の4つをチェックします。

タップした場所には丸い印を出し、場面ごとに「〇〇チェックをします」と字幕と音声で伝えます。各画面の下の判定（✓／✗）は、目視ではなく、その画面の中で実際に測った結果です。

▲ 修正前（約40秒・音声つき。再生バーのスピーカーで音が出ます）

見出しチェックは、4つの幅すべてで✗でした。さらに改行チェックで、担当者も気づいていなかった崩れが見つかりました。320ピクセルの幅で、見出しの最後の1文字だけが次の行に落ちています。

原因を調べると、見出しの大きさの崩れは、記事を表示するプログラムの小さな誤りでした。同じ見出しを何度も「一段下げる」処理にかけていたのです。この記事だけでなく、当社サイトの既存の記事にも同じ崩れが出ていました。プログラムの自動チェックは通っていたため、これまで見過ごされていたものです。

見出しの誤りを一行直し、あわせて見出しの行の長さを揃える指定を加えてから、同じ手順でもう一度撮りました。

▲ 修正後（同じ手順で撮り直した動画）

4つの幅、4つのチェックすべてが✓になりました。修正前と修正後を同じ手順で撮っておくと、「何が直ったのか」を言葉で説明しなくても伝わります。次に記事のデザインを変えたときも、同じ手順で撮り直せば、ほかの箇所が崩れていないかを確かめられます（リグレッションの確認）。

良い動画プレビューにするポイント

難しい準備は要りません。次の点を押さえると、確認に使える動画になります。

1. 利用者と同じ操作を決める：「目次をタップする」「問い合わせフォームに入力して送信する」のように、利用者が実際にする操作を選ぶ
2. タップした場所を見せる：どこを押したかが映っていると、操作の再現になる
3. いくつかの画面幅を並べて撮る：スマートフォンは機種によって幅が違い、崩れ方も変わる
4. 「〇〇チェックをします」と字幕と音声で伝える：見る人が、今なにを確かめているかを迷わない
5. 判定を画面の中で測って表示する：「はみ出していないか」など測れるものは、目視に頼らず数字で判定する
6. 途切れずに、通しで撮る：静止画をつないだコマ送りでは、変化や二重の動きが見えない
7. 修正前と修正後を、同じ手順で撮る：直ったことを比べて示せ、次の変更でも使い回せる

6つ目には注意が必要です。当社のログには、AIが「録画しました」と言いながら、実際は操作のたびに撮った静止画をつなげたコマ送りだった例もありました。

動画プレビューの作り方

当社では、録画も音声づくりも、AIエージェント（Claude Code や Codex）に任せています。人がやるのは、最初にAPIキーを用意することと、できた動画を見て判断することだけです。読み上げの音声は、Googleの Gemini API にある音声生成（TTS）を、エージェントに直接呼び出させます。

1. Gemini APIキーを用意する（最初の1回だけ）

Google AI Studio で Gemini のAPIキーを発行します。キーは、エージェントが動くパソコンの環境変数 GEMINI_API_KEY に設定します。

# ~/.zshrc などに追記する（キーの値はチャットやコードに貼らない）
export GEMINI_API_KEY="発行したキー"

# ~/.zshrc などに追記する（キーの値はチャットやコードに貼らない）
export GEMINI_API_KEY="発行したキー"

エージェントへの指示文やリポジトリにキーを書き込むと、そこから漏れる原因になります。環境変数に入れておけば、エージェントはキーの値を知らなくても、$GEMINI_API_KEY を参照して呼び出せます。

2. Claude Code / Codex に頼む

あとは、エージェントに次のように頼みます。

この画面の確認を動画にしてください。Playwrightで、スマートフォンの4つの幅を並べて開き、目次をタップする操作を再現して録画してください。場面ごとに「〇〇チェックをします」と字幕を出し、同じ文を Gemini TTS で読み上げた音声を重ねて、mp4にしてください。判定は画面の中で測って、✓／✗で表示してください。

エージェントは、録画のスクリプトを書き、字幕の文ごとに Gemini TTS を呼んで音声ファイルを作り、ffmpeg で映像と音声を合成します。Gemini TTS の呼び出しは、たとえば次のような形です（2026年10月時点の公式ドキュメントの例をもとにしています。モデル名や書き方は変わることがあるので、最新のドキュメントを確認してください）。

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.8-flash-tts",
    "input": [{ "type": "user_input",
      "content": [{ "type": "text", "text": "改行チェックをします" }] }],
    "response_format": { "type": "audio" },
    "generation_config": { "speech_config": [{ "voice": "Kore" }] }
  }' \
  | jq -r '[.steps[] | select(.type=="model_output") | .content[] | select(.type=="audio")] | last | .data' \
  | base64 --decode > step1.wav

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.8-flash-tts",
    "input": [{ "type": "user_input",
      "content": [{ "type": "text", "text": "改行チェックをします" }] }],
    "response_format": { "type": "audio" },
    "generation_config": { "speech_config": [{ "voice": "Kore" }] }
  }' \
  | jq -r '[.steps[] | select(.type=="model_output") | .content[] | select(.type=="audio")] | last | .data' \
  | base64 --decode > step1.wav

音声の長さがわかれば、その場面を何秒見せるかも決められます。この記事の2本も、場面ごとの音声の長さに合わせて、各場面の長さを決めています（この記事の2本の音声は、手元ですぐ試せる macOS 標準の読み上げ機能で作りました）。

3. 一度作ったら、スキルに登録する

動画が一度うまく撮れたら、その手順をエージェントの「スキル」として登録しておくことをおすすめします。スキルは、作業の手順書とスクリプトをひとまとめにしたものです。登録しておくと、次からは「動画プレビューを撮って」の一言で、同じ品質の動画が届きます。毎回指示を書き直す手間がなくなり、担当者やAIが替わっても、確かめる内容が揃います。

登録のやり方は簡単で、決まった場所にフォルダを作り、SKILL.md という手順書を置くだけです。

SKILL.md には、いつ使うスキルかの説明と、手順を書きます。録画のスクリプトは同じフォルダに置いておきます。

---
name: video-preview
description: 画面の確認を、タップの再現・字幕・読み上げ音声つきの動画にする。UIの変更を報告するとき、修正の前後を比べるときに使う。
---

# 動画プレビュー

1. 確認する画面のURLと、チェックする項目（改行・タップ・見出し・表など）を決める
2. record.mjs を実行し、320/360/390/430px の4幅を並べて録画する
3. 字幕の文ごとに Gemini TTS（環境変数 GEMINI_API_KEY）で音声を作る
4. ffmpeg で映像と音声を合成し、mp4 にする
5. 修正前と修正後を同じ手順で撮り、両方を報告に付ける
6. 撮れていないこと（本番環境、ログイン後の画面など）は報告に「未確認」と書く

---
name: video-preview
description: 画面の確認を、タップの再現・字幕・読み上げ音声つきの動画にする。UIの変更を報告するとき、修正の前後を比べるときに使う。
---

# 動画プレビュー

1. 確認する画面のURLと、チェックする項目（改行・タップ・見出し・表など）を決める
2. record.mjs を実行し、320/360/390/430px の4幅を並べて録画する
3. 字幕の文ごとに Gemini TTS（環境変数 GEMINI_API_KEY）で音声を作る
4. ffmpeg で映像と音声を合成し、mp4 にする
5. 修正前と修正後を同じ手順で撮り、両方を報告に付ける
6. 撮れていないこと（本番環境、ログイン後の画面など）は報告に「未確認」と書く

いちばん手軽なのは、うまく撮れた直後に、そのままエージェントに「今の手順をスキルにして」と頼むことです。実際に動いたスクリプトと、途中でつまずいた点がそのまま手順書に残ります。

動画だけでは足りないこと

動画プレビューは強力ですが、それだけで全部が確かめられるわけではありません。

• 作る役と確かめる役を分ける：作ったAIは、自分の成果物に甘くなりがちです。当社では別のAIに、読むだけの立場で確認させています。この方法で、通信が不安定なときに費用のかかる処理が重複して動きうる不具合が見つかりました。実装したAIのテストは、その誤った動きを「正しい挙動」として固定していました
• 確かめていないことを書く：動画に映っていない操作や環境は、確かめていないことになります。「本番環境での動作はまだ確かめていません」のように、未確認の範囲を報告に書いてもらいます
• 人にしか判断できないこと：お金や権限が関わる判定の設計が妥当か、仕上がりがブランドの意図に合っているかは、事業を知っている人が判断します

動画は、こうした確認の入り口として、人が状況をすばやく掴むための証拠です。

まとめ

• AIが書いたコードの確認は、「コードを読むこと」から「動いた証拠を見ること」へ移っている
• 確かめる手法はいろいろあるが、すぐ始められて効果が高いのが動画プレビュー
• 利用者と同じ操作を、スマートフォンとパソコンで、字幕つき・通しで撮る
• 修正前と修正後を同じ手順で撮れば、何が直ったかが伝わる

当社のAI製コードの本番化・運用支援では、AIで作ったアプリの公開前の確認や、動画プレビューを含む確認の仕組みづくりをお手伝いしています。「AIで作ったものを、このまま使ってよいかわからない」という段階から、お気軽にご相談ください。