AIネイティブ経営論 第2回：AIがコードを書く時代、人は何を検証するのか

AIにコードを書かせること自体は、もう特別な実験ではありません。要件を読み、複数のファイルを変更し、テストを実行し、失敗を修正する一連の作業を、エージェントに任せる開発環境が増えています。ここで経営と開発の責任者が問い直すべきなのは、誰が何行書いたかではありません。変更が何を意味し、どの条件で正しいと判断し、問題が起きたときにどこまで戻せるかです。

実装量が増えても、品質責任は自動では移らない

人がコードを書いていたとき、実装者は仕様の曖昧さや境界条件に気づく機会を持っていました。AIエージェントは、曖昧な依頼でももっともらしいコードに変換できます。その速さは価値ですが、未確定の業務ルールをコードとして固定する危険も含みます。コードが動くことと、業務上正しいことは別の判定です。

レビュー担当者が差分を読むだけでは、問題を見つけられない場合があります。期待する振る舞いが仕様に書かれていなければ、レビューは文体や実装パターンの確認に偏ります。テストが生成コードと同じ前提から作られていれば、同じ誤りを二重に承認することもあります。人の仕事は、AIの出力を眺めることから、判断の根拠を検証できる仕組みを用意することへ移ります。

「ソフトウェアが複雑になるほど、テストは実装の後工程ではなく、設計を明確にするための道具になる。」

これは特定のAI製品の性能を述べたものではありません。AIが生成した変更にも、何を保証し、何を保証しないかを先に定義する必要があるという、テスト設計上の原則です。

検証ピラミッドを、AI向けに組み替える

従来のテストピラミッドは、粒度の小さいテストを厚くし、統合テストや画面を通したテストを目的に応じて重ねる考え方です。Agentic Engineeringでは、この構造に仕様評価と運用観測を加えます。AIに任せる範囲が広がるほど、コードの内側だけでなく、入力から業務結果までを検証対象にしなければなりません。

このピラミッドの下段は、AIが比較的自動化しやすい領域です。上段へ進むほど、組織の目的やリスク許容度を踏まえた判断が必要になります。評価用の入力を誰が選び、合否を誰が説明し、評価集合が現実をどの程度代表するかは、コード生成器だけでは決まりません。

• 仕様：成功条件だけでなく、してはいけないことと判断を保留する条件を書く
• テスト：正常系、境界値、権限、障害、悪意ある入力を別々に扱う
• 評価：固定した評価例と新しい事例を分け、評価の変更履歴を残す
• レビュー：差分の美しさではなく、意図、影響範囲、証拠、未検証部分を確認する
• 運用：異常を検知した人が停止、切り戻し、再開を判断できる状態にする

仕様はAIへの指示書ではなく、検証可能な契約である

「顧客対応を自動化する」「安全に更新する」といった目標は、そのままではテストできません。対象者、入力の出所、許される操作、例外時の通知先、完了の定義に分解して初めて、AIの提案を評価できます。仕様に含まれる曖昧さを人が引き受けず、プロンプトの工夫だけで解消しようとすると、後から判定基準が変わり続けます。

仕様のレビューは、開発の速度を落とすための会議ではありません。後から大量の差分を読み直す代わりに、先に検証の境界を固定する作業です。とくに顧客データ、金銭、権限、法令対応に触れる機能では、AIが自信ありげに回答したことを承認理由にしてはいけません。

テストを増やすだけでは、検証にはならない

AIはテストコードも生成できます。だからこそ、テスト件数だけを品質指標にすると判断を誤ります。実装とテストが同じ誤解に基づいている場合、テストは安心感を生むだけで、仕様の欠落を発見しません。テストには、何を壊すために作ったのかという意図が必要です。

実務では、独立した観点を意識して組み合わせます。生成した実装に対して別のモデルや人がテストを提案しても、それだけで独立性が保証されるわけではありません。入力データ、評価者、判定ルールのどこが共通しているかを記録し、検証の弱点を説明できる状態にします。

レビューの対象は差分から変更の物語へ

優れたレビューは、コードを一行ずつ読むことだけでは成立しません。変更の目的、選んだ設計、検証した範囲、残したリスク、戻し方が一続きになっている必要があります。AIが多数のファイルを変更したときも、提出物をこの物語に整形できれば、レビュー担当者は重要な判断に集中できます。

• 変更の目的と対象外の範囲を、チケットや仕様と結び付ける
• 生成、修正、テスト実行、手動判断の履歴を必要な粒度で残す
• 変更によって新しく生じる権限、データ、コスト、障害のリスクを列挙する
• テストが通っても確認できていない前提を明示する
• 承認者が判断を再現できるよう、評価結果と失敗例を添える

レビューで問うべきなのは「AIが書いたか」ではなく、「この変更を、どの証拠に基づいて本番へ進めるのか」です。

生成主体を理由に無条件で拒否するのも、生成主体を理由に信頼するのも、品質責任を手放すことに変わりありません。

可逆性は、失敗を許すための経営インフラ

AIエージェントを使う組織では、失敗をゼロにするより、失敗を小さく発見し、影響を限定し、確実に戻すことが重要になります。可逆性は単なるGitの操作ではありません。データの版、設定の変更、外部APIの副作用、通知済みの内容まで含めて、どこまで復旧できるかを設計します。

可逆性が高いと、エージェントの利用範囲を安全に広げる余地が生まれます。反対に、戻せない変更を自動化するなら、実行前の承認や権限分離を強める必要があります。自律性の高さは、実行権限の大きさではなく、検証と回復を含む制御能力で評価すべきです。

運用監視が品質責任の最後の層になる

リリース時にテストが通っても、品質が確定するわけではありません。実際の入力、利用者の行動、外部サービスの変化によって、想定外の組み合わせが現れます。エラー率だけでなく、処理の完了率、保留へ回った割合、手動訂正、権限拒否、評価基準からの逸脱を、業務に合わせて観測します。

監視の通知先も設計対象です。開発者だけにアラートを送っても、業務停止の判断はできません。業務責任者、セキュリティ担当、サービス運用者が、それぞれ何を見て、どの条件で停止や切り戻しを依頼するかを決めます。

品質責任を組織の役割として割り当てる

AIに実装を任せると、品質の問題が開発チームだけに集まりやすくなります。しかし、リスク許容度は経営と業務の判断であり、データの扱いは管理者と法務、復旧の可否は運用の責任です。役割を分けても、最終的な説明責任が消えるわけではありません。誰が判断し、誰が実行し、誰が異常を止めるかを明記します。

この役割表は、組織の規模に応じて兼務できます。ただし、同じ人が複数の役割を担う場合も、判断の種類は混同しないことが大切です。実装を速く進めた担当者が、そのままリスク受容の承認者になるなら、独立した確認が必要な領域をあらかじめ定めます。

小さく始めるなら、まず検証の証拠を揃える

最初から全社共通のAI開発標準を作る必要はありません。反復頻度が高く、入力と出力を確認でき、誤りの影響を限定できる一つの業務を選びます。そこで仕様、評価例、レビュー記録、監視、切り戻しを一周させ、どの証拠が不足していたかを振り返ります。

• 対象業務の目的と、AIが触れてよいデータやツールを定義する
• 代表例だけでなく、失敗例と判断保留の例を評価集合へ含める
• 実装差分とテスト結果を、仕様の版と結び付ける
• 本番前に停止条件と復旧手順を確認し、担当者を決める
• 導入後は結果を見て、許可する範囲を少しずつ見直す

ここで得たい成果は、AIが何行のコードを書いたかではありません。変更を安全に通す時間、問題を発見するまでの時間、復旧に必要な手順、未検証の前提を説明できるかです。これらを記録すると、開発速度と品質を同じ会話の中で扱えるようになります。

次に解くべき問い

よくある質問

参照した一次情報

記事情報

関連記事

• 2026.09.10｜解説AIネイティブ経営論 第4回：AIの仕事は本当に利益につながっているか
• 2026.09.10｜解説AIネイティブ経営論 第5回：AIネイティブ経営を小さく始めて広げる
• 2026.09.07｜解説【AIエージェント記憶の解剖】都度の作業代行から、経験が複利で蓄積する自律チームへ

改訂履歴