コードを書いたのはClaude、Codex、Kimi。それでも全repoが「自分の設計」になる

複数のLLM（Claude、Codex、Kimi）にコードを執筆させながら、ECUのリバースエンジニアリング、LLM監査ハーネス、医学文献検索AIという全く異なる三つのシステムを作った著者が、ふと気づいたことがあります。コードを書いた主体が異なるのに、三つのシステムの設計思想が不気味なほど一致していたのです。どれも「入力は信用しない」「主体を固定する」「証拠が揃うまで作用させない」「異常時は止める」という共通の制御則に従っていました。個々のメソッド名やコメント調子といった表層の「筆跡」は各LLMの癖が混ざりますが、もっと深い層に設計者本人の署名が残ります。

「AIの鬼」の観点からすると、ここに重要な転換点が見えます。従来のコード品質論は「誰が行を書いたか」で作者性を判定してきました。しかし複数のLLMをツールとして使い分ける時代では、その前提が崩れます。著者が「アーキテクチャ署名」と呼ぶものは、trust boundary、failure policy、ownership、停止条件といった設計者の価値観が組み込まれた層に現れます。工場で複数の職人が異なる工作機械で部品を作っても、工場長が定めた公差と検査規格によって最終製品には同じ工場の署名が残るのと同じです。つまり、LLMが候補案を大量に生成し、人間が選択圧をかけ続ける過程で、システム全体は人間の意思に適応した構造へ収束していくのです。

実務への含意は深刻です。中小企業がLLMやAIコーディングツールを単なる「コード生成機」として見なしているなら、その理解は根本的に間違っています。LLMは「考えるツール」ではなく「試し続けるツール」です。重要なのは、どの候補を採用し、どの案を葉いるかの基準をどこに置くか、失敗時のリカバリー構造をどう設計するかといった人間側の設計力です。その力があれば、複数のLLMを並行して使い、最終的には人間の意思だけが刻印された強いシステムが生まれるのです。