AIのコードに自分の名前を置けるか

動いているコードを一瞬信用しかけた

いま自分がやっている仕事のひとつに、すでに動いている業務システムの改修を、AIに手伝わせるというものがある。派手なものではない。請求や入金の管理のように、数字を一つ取り違えると金額と信用にそのまま響く、地味で神経を使う領域が多い。

実際の案件を少し単純化して書く。入金の消込に似た判定機能を、AIに実装させたときのことだ。

銀行の入金明細と、こちらが出した未入金の請求書を突き合わせる。振込名義や金額、請求先が一致するものを「これは入金があったようだ」という候補として画面に並べ、経理担当者が中身を確認してから入金済みにする。そういう機能のはずだった。

出てきたコードは整っていた。テストも通っていた。最初に用意したテストデータは金額も名義も完全に一致していて、画面にはそれらしい候補がきれいに並んだ。見た目だけなら、何も問題はなかった。

変数の名前も自然で、自分が書いてもこうするな、と思うような書きぶりだった。

一瞬信用しかけた。ここまできれいに動いているなら、細かいところは大丈夫だろう、と。全部を読み直すのも面倒で、そのまま取り込んでしまおうかという気持ちが確かにあった。

念のため、同じ顧客に同じ金額の請求書を二件作って試してみた。すると、生成されたコードは、古いほうの請求書へ迷いなく入金を割り当てた。

そこで手が止まった。

コードを確認すると、条件の一致度が高い請求書を、そのまま入金済みに変えて請求残高をゼロにしていた。候補として並べ、人間が確認するという工程がまるごと抜けていた。

古いほうへ割り当てるのも、一つの合理ではある。だが、それは仕様で決めた規則ではなかった。

きれいに動いている。だが、正しくはなかった。

このコードを、自分の名前で外に出していいのか。

AIは処理だけでなく、責任の位置も変えていた

正直に言えば、AIの実装はプログラムとしてはむしろ合理的だった。

条件が決まっているのなら、機械的に確定してしまったほうが速い。確認画面もいらない。担当者がひとつずつ目視して、ボタンを押す手間も消える。効率だけで言えば、AIの書き方のほうが上だ。

それでも、人間の確認をわざわざ残していたのには理由がある。

データだけでは判断できない例外が、この手の業務には必ず紛れ込む。同じ金額の請求書が複数あることもあれば、振込名義が契約者の名前と違うこともある。何件かの請求をまとめて振り込む顧客もいれば、振込手数料を差し引いた額で入金してくる顧客もいる。数字の上では一致して見えても、事情を知っている担当者が見れば「これはあの会社の分だ」「これはまだ消せない」と分かるものがある。機械には見えない但し書きが、業務の側にある。

誤って消し込めば、厄介なことになる。本当は入金されていない請求書が入金済みに見え、その裏で別の請求書が未入金のまま残る。月次の決算にも、督促の連絡にも響く。しかも自動でまとめて処理された後だと、どこで取り違えたのかを後から追うのが難しい。だから候補を出すところで一度止めて、担当者が理由を確認してから消し込む。
最終的な業務責任を、人間の側に置いておく。そういう設計だった。

一手間に見えるあの確認は、無駄な操作ではなく、責任を区切るための線だった。

AIは、その一工程を省略しただけに見える。だが実際にやっていたのは、誰が最後に判断するのかという、仕様そのものの書き換えだった。最終判断の位置を、人間から自動処理へ静かにずらしていた。しかも、人間の確認を消しておきながら、その結果を誰が引き受けるのかまでは決めていなかった。

AIのコードで本当に怖いのは、動かないことではない。動かないコードはすぐ気づく。怖いのは、ちゃんと動くコードが、仕様の意味をこっそり変えてしまうことのほうだ。

コードだけを読んでも、正しさは決まらない

コードレビューでふだん見るのは、処理が正しいか、バグはないか、保守しやすいか、テストは足りているか、といったことだ。どれも大事だし、慣れれば目が勝手に拾う。

けれど今回のコードは、コードだけを見るぶんには、大きな問題がなかった。

「一致度が高い入金を、そのまま消し込んで確定する」という処理は、きれいに実装できる。テストも問題なく書ける。レビューのチェック項目を上から順に潰していっても、たぶん全部にマルがつく。

問題は、その処理をしていいかどうかだった。

そしてそれは、コードの中には書いていない。判断するには、いったんコードから離れて、仕様に、さらにその奥の業務に戻らなければならない。なぜここに確認工程があるのか。誰が何に責任を持つ約束になっているのか。それを知らないまま、行を一つずつ追っても、ズレは見つからない。

これは、AIに指示を出した自分の側の問題でもある。「一致する入金を消し込んで」とだけ頼めば、AIはそれを「一致したら消込まで確定しておく」と受け取る余地がある。人間の担当者なら、業務の流れを知っているから、言われなくても最後の確定は自分の役目だと分かる。AIはその暗黙を共有していない。だから、確認工程が何のためにあるのかを知っている人間が、最後に照らし合わせるしかない。

前に「なぜを失ったプロジェクトは正しく失敗する」という話を書いたことがある。要件どおりに作り、テストも通り、それでも誰にも使われないものができあがる。あれと構造は同じだ。正しさが、目的から切り離されたところで独り歩きしている。

コードの正しさは、コードの中だけでは決まらない。そのコードが何のために存在するのかまで見ないと、正しいとは言えない。

全部読んだかではなく、説明できるか

少し前に、「AIのコードは全部読むな、リスクを読め」ということを書いた。AIが5人分も10人分もコードを吐くようになった以上、全行を精読していたら人間のほうがボトルネックになる。だから危ない場所だけ開く、と。

その考えは今も変わっていない。ただ、今回のことで一歩進んだ。全部読まないなら、では何を確認できたら、自分の成果物として外に出せるのか。

自分の中で残ったのは、3つだった。どれも、自分の言葉で説明できるかどうかで測る。

一つめは、何をAIに任せたのか。AIに渡したことで消えたのは、単なる入力や転記の作業なのか、それとも人間の判断そのものなのか。作業と判断では、まるで重さが違う。

二つめは、間違ったときに戻せるのか。誤って外に出たとき、影響がどこまで及び、後から取り消せるのか。金額、請求、医療、権限のように、やり直しのききにくい処理に触れていないか。

三つめは、最終判断を誰が持つのか。この処理を最後に確認するのは誰で、問題が起きたとき説明に立つのは誰なのか。今回のコードで引っかかったのは、まさにこの三つめだった。経理担当者が持つはずだった判断が、気づかないうちに自動処理へ移っていた。

面白いのは、この三つを確かめるために、すべての行を同じ密度で読む必要はないことだ。まず、仕様と責任に触れる処理はどこかを特定する。そこはコードもテストもデータの流れも、深く見る。それ以外は流し読みでいい。どこを深く読むかを決めるために、この処理が業務のどこに触れていて、誰の責任に関わるのかを先に押さえる。全部読むな、リスクを読め、というのはそういうことだった。

少なくとも、この三つを自分の言葉で説明できないコードに、自分の名前は置けない。

全部読んだという事実だけでは、もう十分な基準にならない。何を任せ、何が起き、誰が引き受けるのかを説明できることが、最低限の基準になる。

署名とは、作者を名乗ることではない

AIがコードを書くようになると、「誰が作ったのか」という問いは急にぼやける。

プロンプトを書いた自分なのか。実際に生成したAIなのか。レビューして直した人間なのか。それとも会社なのか。
まじめに考えるほど、線は引けなくなる。

けれど実務では、作者を決めることよりずっと切実な問いがある。
問題が起きたとき、誰が説明するのか、だ。

顧客に納品するとき。GitHubにマージするとき。リリースを承認するとき。そこに自分の名前が残るなら、その名前は「自分が一行ずつ書きました」という意味ではない。「この成果物を確認し、この状態で外に出してよいと判断しました」という意味だ。

何か起きたときに、顧客の前に立って説明するのは自分だ。AIが書いたので分かりませんとは言えない。生成したのはAIでも、外に出す判断をしたのは自分だからだ。その一点で、名前の重さは変わらない。

これは、値付けの話ともつながっている。以前、価格とは技術料ではなく責任料だと書いた。「この金額をいただくからには、ここまでの責任を持ちます」と言い切れる状態を作ることが、値付けだった。署名もこれと同じで、著作の証明ではなく、責任を引き受けた印なのだと思う。

だから、自分が書いたか、AIが書いたかは、署名できるかどうかの本質ではない。中身と影響を自分が説明でき、問題が起きたとき逃げずに前へ出られる。そのときだけ、そこに名前を置ける。

自分の名前を置けるところが、品質の最終ラインになる

AIの出力は、これからも良くなる。コードだけではない。仕様書も、提案書も、契約書のたたき台も、設計資料も、AIが先に形にする時代になっていく。

そうなると、人間の仕事は、成果物をゼロから作ることではなくなっていく。もうかなり、そうなっている。

それでも、最後に名前を置く仕事は残る。
むしろ作る手間が減った分、この仕事の比重は上がっていく気がする。

なぜこの仕様なのか。何を自動化したのか。どこに人間の判断を残したのか。間違ったとき何が起きるのか。問題が起きたとき、自分の言葉で説明できるのか。そこまで確かめられた成果物にだけ、自分の名前を置く。逆にそこが埋まっていないものは、どれだけきれいに動いていても、自分にとってはまだ未完成だ。

出来上がりの見た目は、人間が作ってもAIが作っても、もう区別がつかなくなってきている。差がつくのは見た目ではなく、その裏側を誰かが引き受けているかどうかだ。

冒頭のコードは、結局そのまま取り込まなかった。自動で消し込む処理を外し、候補を出すところで止めて、消込の確定は経理担当者に戻した。地味な差し戻しだが、あそこで名前を置けるかどうかの線はそこにあった。

問うべきなのは、「このコードを書いたのは誰か」ではない。
「このコードに誰が名前を置けるのか」だ。

その内容と影響を説明できず、結果を引き受けられないなら、どれだけきれいに動いていても、まだ完成とは言えない。
自分の名前を置けるところが、AI時代の品質の最終ラインになる。