AI で作ったコードを受け取るとき、発注側が決めておく 5 つの受け入れ条件

業務アプリや SaaS の開発で、AI を使って作る前提の見積もりが増えました。速く安く作れるのは歓迎できる一方、発注する側には新しい悩みが出ています。コードを読めない自分が、何をもって「完成」と認めればよいのか、という悩みです。

この記事では、AI が書いたコードを受け取るときに、事業責任者が発注前に決めておきたい受け入れ条件を 5 つに絞って整理します。コードの良し悪しを自分で判定する話ではありません。「何を確認できたら受け取るか」を、作り始める前に合意しておく話です。

AI が書いたコードは、人が書いたコードと同じ確認でよいのか

まず、調査で何が言えているかを確認します。AI コードレビューツールを提供する CodeRabbit は、公開リポジトリの PR 470 件（AI が共同で書いたもの 320 件、人だけのもの 150 件）を分析し、結果を自社のブログで公表しています。同社の発表によると、PR 1 件あたりの指摘は、AI が関わったものが 10.83 件、人だけのものが 6.45 件で、約 1.7 倍でした（CodeRabbit の調査レポートの紹介）。

中身の分類では、次の見出しが付いています。

Logic and correctness issues were 75% more common in AI PRs.

出典：State of the AI vs. Human Code Generation Report（CodeRabbit）

同社は、ここでいう「ロジックと正確性」に、業務ロジックの誤りや制御の流れの不備が含まれるとしています。業務アプリで怖いのは、画面は動くのに、料金の計算や在庫の引き当て、承認の流れといった業務のルールだけが間違っている状態です。

ただし、読むときの注意が 2 点あります。1 つは、これが同社の分析であることです。もう 1 つは、PR を AI が書いたか人が書いたかの判定に限界があることです。同社自身が、人だけと分類した PR にも AI が関わったものが混じる可能性を認めています。数字は「AI のコードは確認を厚くした方がよい」という方向を示す材料として受け取るのが妥当だと、私たちは考えています。

テストが通ったから完成、とは言えない理由

「自動テストが全部通っている」と報告を受けると、安心したくなります。ここにも落とし穴があります。

2024 年 12 月に公開された論文（Mathews、Nagappan）は、人が書いた不具合入りのコードを使い、LLM を使ったテスト生成ツール（Codium CoverAgent、CoverUp）が不具合を見つけられるかを調べました。著者らは、生成されたテストが不具合を検出できないことが多く、不具合のあるコードの動きをそのまま正しいものとして検証してしまうこともあると報告しています（arXiv:2412.14137）。

これは、特定のツールを対象にした研究で、すべての AI 開発に当てはまるとは言えません。また、対象は人が書いたコードで、AI が書いたコードとテストの組み合わせを直接調べたものではありません。そのうえで、発注側の備えとして、私たちは次のように考えています。実装を書いた AI に、そのまま「テストも書かせて」「通ったから完成」にすると、確認になっていない場合があるということです。テストが通ったという報告は、何に対してテストしたのかとセットで受け取る必要があります。

発注前に決めておく 5 つの受け入れ条件

条件 1：業務ルールを「例」で書く

要件を文章で渡すより、具体例で渡す方が、合意の精度が上がります。たとえば次のような形です。

• 会員ランクがゴールドで、3 万円の注文なら、送料は無料になる
• 同じ商品を在庫 1 点のときに 2 人が同時に注文したら、後の人にはエラーを表示する
• 承認者が不在のとき、申請は代理承認者に回る

こうした「入力と期待する結果」の組を、発注前に 10 件から 20 件ほど書き出します。これが、あとで完成を判断する物差しになります。業務の例外こそ書くべきです。書かれていない例外は補われにくいと、私たちは考えています。現場しか知らないルールは発注側が持ち込む必要があります。

条件 2：テストは、要件から作られたものか確認する

納品時に、テストが何から作られたかを聞きます。確認したいのは次の点です。

• 条件 1 の例が、そのままテストになっているか
• 実装を書いたのと同じ AI の出力だけで、テストを作っていないか
• 失敗するはずの入力（不正な値、権限のない操作）のテストがあるか

すべてを自分で検証する必要はありません。「この例のテストはどこにありますか」と聞いて、示してもらえれば十分です。

条件 3：人が目で確認する範囲を決める

AI が書いたコードのすべてを人が読むとは限りません。だからこそ、どこは必ず人が確認するかを決めておきます。業務アプリなら、次のような箇所が候補になります。

• お金に関わる計算（料金、割引、税、請求）
• 権限と認証（誰が何を見られるか、変更できるか）
• 外部システムとの連携（在庫、会計、決済）
• データの削除や一括更新

こうした箇所は、人が読んで確認したことを、誰が・いつ行ったかとあわせて記録してもらう、と合意しておくと、後から経緯をたどれます。

条件 4：納品物の範囲を決める

動くアプリだけを受け取ると、運用が始まってから困ります。納品物として、次のようなものを求めておくことを勧めます。

• ソースコードとその管理場所の引き継ぎ
• 条件 1 の例をもとにしたテストと、その実行手順
• 環境の構築手順と、必要な設定値の一覧（秘密情報そのものは別の方法で受け渡す）
• AI に与えた作業ルールの文書（AGENTS.md や CLAUDE.md のような、AI への指示書がある場合）

最後の項目は、開発会社を変えるときに効きます。AI への指示書には、そのプロジェクトで守る約束事が書かれているためです。

条件 5：不具合が見つかったときの直し方を決める

受け入れ後に不具合が見つかることは、AI を使うかどうかにかかわらず起きます。決めておきたいのは、次の 3 点です。

• 不具合の報告から修正までの連絡手順と、目安の期間
• 直したときに、同じ不具合を再発させないテストを足すこと
• 無償で直す範囲と、追加費用になる範囲

AI が関わると修正は速くなりますが、速く直ることと、再発を防げることは別です。再発を防ぐテストを足してもらう、という約束があるだけで、運用の安心感は変わります。

受け入れ条件を、見積もりの段階で話題にする

ここまでの 5 つは、納品の直前に持ち出すと、揉めやすくなります。見積もりと要件定義の段階で、次のように話題にしておくことを勧めます。

1. 業務ルールの例を、一緒に書き出す時間を取る
2. テストと人の確認の範囲を、見積もりの項目として分けて出してもらう
3. 納品物の一覧を、契約前に合意する

こうしておくと、AI を使って速く作る利点を活かしながら、「作ったものが業務に合っているか」を、発注側が自分の言葉で確認できます。

まとめ

AI が書いたコードを受け取るときの受け入れ条件は、次の 5 つです。

1. 業務ルールを例で書く
2. テストが要件から作られたかを確認する
3. 人が目で確認する範囲を決める
4. 納品物の範囲を決める
5. 不具合が見つかったときの直し方を決める

調査が示すのは、AI のコードには確認を厚くする余地があるということと、テストが通っただけでは確認にならない場合があるということです。何をもって完成とするかを、作り始める前に決めておくことが、発注側にできる有効な備えの 1 つだと、私たちは考えています。

Urchin&Company では、SaaS・業務アプリ開発として、要件定義から公開後の改善まで一貫して支援しています。AIプロトタイプ・MVP開発で、動くものを見ながら要件を固めることもできます。