AI生成コードの動作確認｜そのまま使わない最低限の型

AIが書いたコードを眺めて、「読んだ感じは問題なさそう」「テストも緑」。 それでも、そのままコミットしようとした指が、最後の一押しでふっと止まる——「これ、自分で一回も動かしてないな」。そんな夜、ありますよね。

レビュー（読んで確かめる）はした。でも、実際に動かして確かめるのは、まだしていない。 コードを読むのと、コードを動かすのは、見つかる問題が違います。読むだけでは気づけない「実行してみて初めて分かること」が、AI生成コードには特に残りやすいのです。

この記事は、AIが書いたコードを使う前に、最小の手間で実際に動かして確かめる「動作確認の型」をまとめたものです。大がかりなテスト整備の話ではありません。コミット前の数分でできる、地に足のついた確認の順番です。一度に全部やる必要はありません。まず効く所から、一緒に見ていきましょう。

結論：AI生成コードは「読んで大丈夫そう」と「テストが緑」だけで通さず、①一番小さい単位で自分の手で動かす → ②正常系の代表例を実データで1本通す → ③意地悪な入力を1〜2個入れて壊れ方を見る → ④副作用（既存データ・ファイル・外部通信）を確認 → ⑤ログとエラーの出方を見るの順で、実際に走らせて確かめます。AIは「もっともらしく動くが、実行すると静かにずれる」コードを書くことがあるので、動かすのは人の最終確認です。最後に「動作確認メモ」のテンプレとチェックリストを置きました。

読むのは机の上、動かすのは現場。 コミット前の数分の実行が、本番で起きる事故の何時間ぶんかを先に消してくれます。

なぜ「読んだ」「テストが緑」だけでは足りないのか

AIが書くコードは、文法は正しく、見た目はそれらしいのに、走らせると意図とずれることがあります。 読んでいるときは「ありそうな正しいコード」に見えるので、目が滑りやすい。レビューが効きにくいのは、AIのコードが「いかにも正解っぽい顔」をしているからです。

動かして初めて分かることには、たとえばこんなものがあります。

• サンプルでは動くのに、実際のデータの形（想定外の桁・全角・空欄）で落ちる
• 戻り値の型や並び順が、呼び出し側の期待と微妙に合っていない
• 既存のファイルやデータを、こちらの想定外に書き換えてしまう
• 外部APIを思ったより多く呼んでいて、レート制限や課金に触れる
• エラーは握りつぶされ、画面上は「成功したように見える」

そして「テストが緑」も、安心の決め手にはなりきれません。 AIが生成したテストは、AIが書いたコードの「都合のいい正常系」だけをなぞっていることがあるからです。コードとテストが同じ思い込みを共有していると、両方そろって緑のまま間違えます。だからこそ、テストとは別に、人が自分の手で一度動かす一拍が要ります。

つまり対策はシンプルです。 読んで終わりにせず、最小の手間で実際に走らせる。次の章から、その動作確認を5つの手順に分けて見ていきます。

動作確認の型：5つの手順

先に全体像を出します。上から順に、コミット前の数分でなぞれる流れです。

ポイントは、5つ全部を毎回フルでやらないことです。 小さな純粋関数なら①②だけ、本番のデータを触るなら④が要、外部APIを呼ぶなら⑤が要——というように、その変更で一番こわい所を選んでなぞれば十分です。全部やろうとすると続きません。続かない型は、型として失敗です。

では一つずつ見ていきます。

手順1：一番小さい単位で、自分の手で動かす

最初にやるのは、難しい検証ではありません。 「この関数（このスクリプト）を、自分の環境で一回走らせてみる」だけです。当たり前のようでいて、AIで速くなったときほど飛ばしがちな一歩です。

やること：

• 生成されたコードを、できるだけ小さい単位で呼び出してみる（関数1つ、コマンド1つ）
• いきなり全体に組み込まず、切り離して単独で動かす（試し用の小さなスクリプトやREPLでよい）
• 「そもそも起動するか・import が通るか・例外で即落ちしないか」をまず確認する

ここで早くもつまずくことは珍しくありません。 存在しない関数を呼んでいる、依存が入っていない、バージョンが合わない——AIは「動きそうな雰囲気」で書くので、こうした実行時のひっかかりは走らせて初めて見えます。小さく切り離して動かすほど、原因の切り分けも楽になります。

手順2：正常系の代表例を、実データで1本通す

動くことが分かったら、次は「想定どおりの入力で、想定どおりの結果が返るか」を、実際のデータに近いもので確かめます。

やること：

• サンプルではなく、現場で実際に来るデータに近い1件を入れてみる
• 本物に近いデータが用意できない現場（個人情報や本番マスク方針でテストデータが乏しいなど）では、手元で手作りした「確定値が分かる1件」でよい
• 出力の型・並び順・件数・単位が、呼び出し側の期待と合っているかを目で確認する
• 「だいたい合ってる」で流さず、1件ぶんは値を実際に突き合わせる（金額・日付・件数など）

ここで効くのは、抽象的に「動いた」と言わず、具体的な1件で答え合わせすることです。 たとえば「2026-01-15 の売上が 1,200 円のはず」という確定した1件を通して、ぴったり一致するかを見る。大事なのは本物のデータかどうかより、正解が自分で分かっている1件であることです。サンプルデータだけで確認すると、AIが暗黙に置いた前提（税込か税抜か、丸めの方向、タイムゾーン）がそのまま素通りしてしまいます。確定値の1件は、そのズレを一番安く見つけてくれます。

手順3：意地悪な入力を1〜2個入れて、壊れ方を見る

正常系が通ったら、ここがいちばん収穫の多い手順です。 わざと崩れた入力を1〜2個入れて、コードがどう壊れるかを、本番より先に見ておきます。AIのコードが一番漏らしやすいのが、この異常系です。

入れてみたい意地悪な入力の例：

• 空・null・0・負の数（空文字列、空配列、null、マイナス金額）
• 極端に大きい/小さい値（桁あふれ、1件もない、件数が想定の何倍も）
• 想定外の形（全角数字、前後の空白、改行混じり、文字コードの違い）
• 同じ処理を2回（連打・リトライで二重登録や二重課金にならないか）

見たいのは「落ちないこと」だけではありません。 落ちるときに、ちゃんと分かる形で落ちるかです。エラーを握りつぶして「空の結果を正常そうに返す」のが一番こわい。意地悪な入力を1個入れて、期待どおりのエラーや、安全な既定値（空配列を返すなど事前に決めた振る舞い）になればOK。静かに変な値が返ってきたら、そこが直す所です。

ひと手間かけられるなら、ここで入れた意地悪な入力を1個、既存のテストに足して残すのがおすすめです。AIが書いたテストは正常系に寄りがちなので、そこに異常系を1本足しておくと、その場の確認が次回以降の自動チェックに化けて、続けやすくなります。

この手順は、コードを読むだけでは絶対に拾えません。動かすからこそ見つかる穴です。

手順4：副作用を確認する——余計な所に手を出していないか

動作の正しさとは別の軸で、「頼んでいないことまでやっていないか」を見ます。AIは「便利だから」と、こちらが想定していない動きを足すことがあります。

確認したいこと：

• 既存のデータ・ファイルを書き換え/削除していないか（テスト用のデータベースやコピーで試すと安全）
• 外部への通信が増えていないか（思っていないAPIを呼んでいないか、回数は妥当か）
• グローバルな状態・設定ファイル・環境変数を勝手に変えていないか
• 一時ファイルやキャッシュを、想定外の場所に残していないか

ここで大事なのは、本番データでいきなり試さないことです。 副作用を確かめるときこそ、コピーや使い捨ての環境で動かします。「動作確認のつもりが本番のデータを書き換えてしまった」では、確認の意味が逆転してしまいます。

ただ、本番しか触れない・検証DBが無い小規模な現場もあります。コピー環境が用意できないときは、最低でもドライラン（実行せず処理内容だけ出す）／読み取り専用の接続で開く／更新系の行を一度コメントアウトして流すといった形で、書き換えや通信が起きるかどうかだけでも目で確かめておく。ゼロにはできなくても、副作用の有無を見てからにするだけで事故はぐっと減ります。外部APIを呼ぶコードなら、回数や対象を一度ログで見ておくと、レート制限や課金の事故も先に防げます。

手順5：ログとエラーの出方を見る

最後に、「うまくいかなかったとき、それに気づける作りになっているか」を見ます。これは将来の自分を助ける確認です。

見ておきたいこと：

• 処理の節目で、何が起きたか分かるログが出ているか（少なすぎても多すぎても困る）
• エラーが起きたとき、握りつぶさずに分かる形で表に出るか（catch して何もしない、になっていないか）
• ログに鍵・パスワード・個人情報を出していないか（出力側の情報漏えい）
• 失敗したときに、途中まで進んだ状態が中途半端に残らないか

AIは正常系を中心に書くので、失敗時の見え方は手薄になりがちです。 意地悪な入力（手順3）を入れたときに、ログとエラーがどう出るかをあわせて見ておくと、この手順は一度で済みます。本番で困るのは「失敗したのに、失敗したと気づけない」ときです。そこだけは、先に確かめておくと安心できます。

ありがちな落とし穴と、その回避

動作確認をするときに、つまずきやすい所を先に潰しておきます。

• AIに「動作確認して」と任せて終わりにする：AIは「動きました」と報告しがちですが、それは確認の代わりにはなりません。最後に動かすのは人、が動作確認の前提です。
• テストが緑だから動かさない：テストとコードが同じ思い込みを共有していることがあります。テストとは別に、自分の手で1回は走らせる。
• 本番データでいきなり試す：副作用の確認こそコピーや使い捨て環境で。環境が無ければドライランや読み取り専用で代えてもよい。試した結果が本番を壊しては本末転倒です。
• 「だいたい合ってる」で値を突き合わせない：1件でいいので、具体的な値で答え合わせをする。抽象的な「動いた」は一番すり抜けます。
• 正常系だけ通して満足する：一番収穫があるのは意地悪な入力。正常系で止めると、本番の想定外がそのまま残ります。

落とし穴の多くは、「動いてるっぽい」で止めてしまうことから来ます。 動作確認は、コードを疑う作業ではなく、自分が安心してコミットするための作業です。最後の数分を、自分のために使いましょう。

明日からやること（小さく始める3つ）

全部を一度に習慣化しようとすると続きません。まずこの3つから。

1. コミット前に、実データ1件で答え合わせをする：具体的な1件の値が合うかを見るだけ。手順2が片付くだけで、仕様のずれの多くが消えます。
2. 意地悪な入力を1つだけ試す：空・0・想定外の値を1個入れて、壊れ方を見る。手順3の一番おいしい所が拾えます。
3. 本番データではなくコピーで動かす癖をつける：試すときは使い捨て環境で。環境が無ければドライランや読み取り専用で代えてもOK。手順4の一番重い事故（既存データの破壊）を防げます。

この3つだけでも、「そのまま使う」が「一度動かしてから使う」に変わります。 慣れてきたら、最小単位での実行（手順1）やログの確認（手順5）も足していけば十分です。

コピーして使う「動作確認メモ」

新しい生成コードを使う前に、関係する行だけ埋めて手元に置いてください。全部やる必要はなく、その変更でこわい所だけで十分です。

# 動作確認メモ

## ①最小単位で動かす
- 単独で走らせた：（はい／まだ）
- 起動・import・即落ちの有無：

## ②正常系を確定値で
- 通した1件（実データ／手作りの確定値）：
- 出力の型・並び・単位は期待どおりか：
- 突き合わせた具体値（例：金額・日付）：

## ③意地悪な入力
- 入れた値（空・0・負・想定外の形など）：
- 壊れ方（落ちた／既定値／静かに変な値）：

## ④副作用
- 既存データ・ファイルへの変更の有無：
- 外部通信の有無・回数：
- 試した環境（コピー／ドライラン等、本番ではないか）：

## ⑤ログ・エラー
- 節目のログは出るか：
- エラーは握りつぶされていないか：
- ログに機密・個人情報が出ていないか：

動作確認チェックリスト

コミットやプルリクの前に、1項目ずつ「○／要確認」を付けながら使ってください。一度に全部でなく、今日はその変更でこわい所だけで十分です。各区分に「いつ省けるか」も添えたので、当てはまる所だけチェックすれば終わりです。

①最小単位で動かす（毎回やりたい最低ライン）

• コードを単独で一度走らせたか
• 起動・import・即落ちがないか確認したか

②正常系を確定値で（純粋関数なら①②だけで十分）

• 確定値が分かる1件（実データ／手作り）を通したか
• 出力の型・並び順・件数・単位が期待どおりか
• 具体的な1件の値を突き合わせたか

③意地悪な入力（②と並んで一番おいしい所）

• 空・null・0・負・極端な値を入れたか
• 想定外の形（全角・空白・改行）を試したか
• 落ちるときに分かる形で落ちるか確認したか

④副作用（本番データ・ファイルを触らないなら免除）

• 既存データ・ファイルを書き換えていないか
• 外部通信の有無と回数を確認したか
• コピー環境、無ければドライラン等で副作用を見たか

⑤ログ・エラー（外部通信や失敗の影響が小さいなら後回しで可）

• 節目で分かるログが出るか
• エラーを握りつぶしていないか
• ログに鍵・個人情報が出ていないか

最後に

AIに書かせたコードを自分で動かすのは、AIを信用していないからではありません。 最後にコミットするのが自分だから、自分の手で一度確かめておく——それだけのことです。読んで確かめるレビュー・検証チェックリストと、この動作確認は、別々の網で別々の穴を拾います。両方そろうと、AIコーディングはぐっと落ち着きます。

そして、動作確認のいい所は、なるべく前の工程で渡す前提と地続きなことです。書く前に渡す前提と制約で「完成の判断基準」を先に決めておくと、ここでの動作確認はそのまま答え合わせになります。

5つの手順のうち、今日できたのが1つでも、それはもう「そのまま使わなかった」という確かな一歩です。 コミット前のあと数分を、未来の自分のために使っていきましょう。

関連用語

• ハルシネーション
• LLM