AIが作ったコードは信頼できるのか正直に答える

当然の疑問に、正直に答える

前回の記事で「1行もコードを書かない」と書いた。読んだ人が当然抱くであろう疑問がある。

そのコードは、本当に信頼できるのか。

結論から言う。今の時点では、「仕組みとして担保できている」とは言えない。これが正直な答えだ。

以前、生成AIのみで開発を行うベンダーと仕事をしたことがある。そのとき「このコードは本当に大丈夫なのか」という疑問を持ち、自分で調査してリストを作った。6つの観点で構成されている。人的負債、認知的負債、プロセス負債、技術的負債、テスト負債、セキュリティ負債。

作りながら気づいた。これは発注者がベンダーを評価するフレームワークだが、自分自身に当てはめると、いくつかの項目で危険な状態にあると。

自分への監査結果を、そのまま書く。

AIが高速にコードを生成し続けると、気づいたときには「全体像を把握しているのはAIだけ」という状態になりやすい。

Librarian AIの開発で、実際にこの片鱗を感じた。1,500行を超えたコードベースを前に、「この処理がなぜここにあるのか」を即座に説明できない瞬間があった。

コードを書いているのはAIだが、システムの意図を保持しているのは人間でなければならない。その原則が揺らいでいた。

現状：仕組みがない。設計意図をログとして残す習慣が唯一の防衛線になっている。

テストコードはほぼ存在しない。「動いたからOK」が実質的な品質基準になっている。

個人開発の段階では許容できる。しかし、ユーザーを抱えた瞬間に致命的な負債に変わる。サービスを公開する前に、最低限の回帰テストを設計することは避けられない。

現状：明確な負債。公開前のマイルストーンとして設定する。

静的解析ツール（SonarQube等）の導入、セキュリティスキャン（Snyk等）の自動化、CI/CDへのテスト組み込み——これらはすべて「やっていない」が正確な答えだ。

ただし、これらのツールを今すぐ導入できる状況にはない。コストの問題もあるが、それよりも「運用できる体制が整っていない段階でツールを入れても形骸化する」という判断がある。

現状：意識はある。仕組みはない。時期を見て整備する。

隠すことはできた。

「AIで開発しています」「品質には気をつけています」で済ませることもできた。多くの発信がそうしている。

でも私は、それをしたくない。

理由は二つある。

一つは、読者への誠実さ。同じようにAIで開発を始めようとしている人が、「AI使えば品質も担保されるはず」という誤解を持ったまま進むことの方が、はるかに危険だと思うからだ。

もう一つは、自分自身への戒め。「書いた以上、やらなければならない」という構造を、意図的に作っている。公開することで、逃げ道を塞ぐ。

曖昧なままにしない。現時点での方針を書いておく。

今すぐやること

サービス公開前にやること

6ヶ月以内にやること

GitHub Actionsを使い、pushのたびにテストが自動実行される仕組みを作る（テストコードが存在して初めて意味を持つ。だから順番としてこれは最後になる）
セキュリティスキャンツールの評価・導入検討

完璧な状態になってから発信する、という考え方がある。

私はその逆を選んでいる。

できていないことを書く。それが今の自分の実力だからだ。そしてできるようになったら、またここに書く。その積み重ねが、ログになり、信頼になると考えている。

AIが作ったコードは信頼できるか。

仕組みで担保できるようになったとき、改めてこの問いに答える。