コード一貫性分析: AI貼り付け提出物の検出

「一貫性のある」コードとは何か

実務的なエンジニアには習慣がある。関数全体でブール値の命名方法が同じだ（isReadyかis_readyかreadyか、だが一貫している）。エラーハンドリングのパターンは一つを好む。同じ標準ライブラリツールを繰り返し使う。TODOやコメントは同じ声を持つ。

優秀なエンジニアでさえ、コードは雑然としている。だが、その雑然さは一貫した方法で雑然としている。この一貫性こそが、私たちが「一貫性」（コヒーレンス）と呼ぶものだ。

一貫性のないコードとは何か

複数のプロンプトから組み立てられたLLM貼り付け提出物は、特に予測可能な方法で一貫性に欠ける：

• ある関数はtry/exceptを使い、次はオプショナルチェーンを使い、第三は黙ってエラーを抑える。
• 変数命名スタイルが変わる：同じファイル内でuserId、user_id、uidが混在する。
• コメントは「明らかなことを説明する」（LLMの特徴）と「全く存在しない」（人間の特徴）の間を行き来する。
• イディオムレベルが揺れ動く：教科書的なジェネリック型付きソリューションの隣に、Stack Overflowからコピーされたスニペットが並ぶ。

それぞれ単独では、疲れた候補者かもしれない。4つすべてが一緒にあるなら、それは別の話だ。

分析はどのように実行されるか

ClarityHireの一貫性チェックは、LLM審判への1つのプロンプトで候補者の最終提出物を審査する：「これは単一の著者の仕事に見えるか、それとも組み立てられたものか?」審判はスコア、気付いた特定の矛盾、そして信頼度を返す。

重要な点として、審判は候補者のアイデンティティを一切知らない。コードだけを見る。

なぜこれは「AI検出」ツールより優れているのか

ほとんどの「これはAIか」検出ツールは信頼性に欠ける。特にコードに関しては（LLMと人間は似たようなPythonを書く）。一貫性分析は問題を全く別の角度からアプローチする：「私たちはAIが書いたかどうかは気にしない。それが1つの精神で1人の著者によって書かれた統一されたソリューションであるかどうかが重要だ。」このフレーミングの方がはるかに答えやすく、採用マネージャーが実際に知りたいことにはるかに適合している。

一貫性フラグにどう対応するか

それを候補者に彼らのコードを説明するよう促すきっかけとして扱い、20分間のライブフォローアップを行う。正直な候補者なら簡単に説明できる。不誠実なものはできない。いずれにせよ、何かを学ぶことになる。