AIがコードを書ける。だからこそ、確かめる責任まで手放さない

AIで、作る速度は確かに変わりました

私は、AIが得意な仕事を、以前と同じ手順で人だけが続ける必要はないと考えています。定型的な実装や修正の候補をAIに作ってもらい、人は目的や条件を考える。分からない部分の説明を求め、別の案と比較する。こうした使い方によって、少人数でも試せる範囲は広がりました。

一方で、速くなった仕事と、まだ必要な仕事は分けて見たいと思います。たとえば、入力して保存できる画面は短時間で作れても、誰がどの情報を変更してよいかは、画面の形だけでは決まりません。外部サービスへ送信できても、応答が途切れた後に同じ処理をやり直してよいかは、別に考える必要があります。

AIにテストを書いてもらうこともできます。それ自体は有効です。ただ、何を守るべきか、どの失敗が業務に大きな影響を与えるか、どの状態まで戻せれば再開できるかは、作ろうとしている仕事を知らなければ決められません。AIが速くしたのは、その判断を実現する手段の一部です。

速く作れたことと、どこまで確かめたかは別です。成果を小さく見せるための区別ではありません。できたことを正確に示し、次の確認へつなげるための区別です。

動いたことと、必要な条件を満たしたことは別です

システムが動いたかどうかは、必ず何らかの条件の中で確認されています。どの利用者で、どのデータを使い、どの順番で操作し、どの環境で試したのか。その条件を外すと、同じ結果になるとは限りません。だから私は、合格か不合格かを言う前に、まず確認した条件をそろえます。

たとえば、担当者のアカウントで主要な操作を一度試せたとします。それは大切な確認です。しかし、権限の異なる人が同じ操作をした場合、同じ処理が重なった場合、途中で通信が切れた場合はまだ試していないかもしれません。そこで起きる影響が大きいなら、公開前に確かめます。影響が限られ、元へ戻せるなら、利用者を絞って先に試す判断もできます。

すべての条件を同じ重さで確認しようとすれば、いつまでも使い始められません。反対に、正常な操作が一度通っただけで全面利用へ進めば、利用者が増えてから初めて問題に気づきます。必要なのは、起きやすさだけでなく、起きたときの影響と戻しやすさを見て、確認の順番を決めることです。

未確認であることは、直ちに失敗を意味しません。未確認の条件を、確認済みの範囲へ混ぜないことが重要です。何を試し、何を試していないのかを分けることで、次に何を確かめるべきかを私たち自身が見失わずに済みます。

AIに確認させても、確認の範囲までは決まりません

私は、AIによるコードレビューやテストも積極的に使います。自分では見落とした可能性を挙げてもらう。似た処理の違いを探す。想定していなかった入力例を出してもらう。人だけで確認するより、早く広く見られる場面があります。

それでも、AIが見ている範囲は確認する必要があります。コードだけを渡したなら、本番環境の権限設定や、外部サービス側で完了した処理までは見えていないかもしれません。要件に書かれていない業務上の例外は、テストの前提にも入らないことがあります。AIが問題を見つけなかったことと、利用に必要な条件をすべて確かめたことは同じではありません。

別のAIへ同じ材料を渡して確認し直すことにも意味はあります。ただし、前提と対象が同じなら、見えていない場所も共通する可能性があります。人が一度見た場合も同じです。エンジニアがレビューしたという事実だけで、安全性全体を保証することはできません。

確認者の数より、何を対象にした確認かを説明します。コード、設定、データ、外部との接続、実際に動く環境のうち、どこまでを見たのか。どの条件を試し、どの結果を得たのか。それが分かって初めて、AIや人による確認を次の判断に使えます。

失敗の仕方と、変更後の確認までが私たちの仕事です

私にとってエンジニアの仕事は、失敗しないコードを書くことだけではありません。問題が起きたときに気づけること、影響が広がる前に止められること、必要な状態へ戻せることも設計します。障害を完全になくすという約束ではなく、失敗したときに何が起きるかを放置しないという約束です。

特に、すでにデータが変わった後では、コードを直すだけで元に戻るとは限りません。送信先に登録された情報を確認する。重複や抜けを探す。利用者へ状況を伝える。代わりの手順で業務を続ける。こうした仕事は、エラーを修正する作業とは別に残ります。

変更を加えた後の確認も必要です。最初の公開時に動いた仕組みでも、機能の追加、接続先の変更、利用者の増加によって前提が変わります。どこを変えたら何を試し直すのか、問題があればどの版へ戻すのかを決めておくと、改善を止めずに進められます。

そして、作った本人だけが操作方法や復旧方法を知っている状態を完成とは呼びません。設計のすべてを文書にするのではなく、次の人が判断に必要な記録を残します。どこに重要な設定があり、どう公開し、何を監視し、困ったときに誰と確認するのか。引き継げる状態まで含めて、使い続けられる仕組みにします。

AIに任せても、確かめる責任までは手放しません

確認結果を渡すとき、私は「テスト済みです」「問題ありません」だけでは終えないようにします。確認した項目、条件、環境、得られた結果を示します。加えて、試していない条件、問題が起きた場合の影響、次に確認することも伝えます。

たとえば、「限られた担当者と仮のデータで主要な操作を確認しました。別の権限と通信中断時の処理は未確認です。今回は社内の限定利用にし、その二点を確認してから対象を広げます」と説明できれば、未確認があっても次の行動を決められます。

未確認を伝えると、品質が低いと思われるのではないか。開発が止まるのではないか。そう感じることはあります。しかし、分からないことを隠したまま利用範囲を広げれば、問題が起きたときに、技術だけでなく説明そのものへの信頼を失います。未確認を隠さず、今回使える範囲を示します。

確認結果を言葉にすることは、誰かへ報告するためだけの作業ではありません。後から自分が変更するとき、別のエンジニアが引き継ぐとき、どの前提まで戻って考えればよいかを残す作業でもあります。理解できていない判断を、AIの回答だけで埋めないための記録です。

私はAIを、実装を代わってくれる道具としてだけでなく、案を広げ、見落としを問い、考えを確かめる相手として使います。ただし、返ってきた答えを採用する理由と、その答えが通用する範囲は自分で持ちます。説明できなければ、もう一度調べるか、試す範囲を小さくします。

AIに多くを任せても、何を守り、どこまで確かめるかという判断まで手放しません。 速く作れることを活かしながら、分からないことを分からないままにせず、自分の言葉で説明できるところまで向き合います。