AIコード検出器：あなたのコードがフラグされる理由と修正方法

AIコード検出器があなたのコードを機械が書いたものと判定しました。この数値の意味、クリーンなコードがフラグされる理由、そして検出率を下げる編集について説明します。

この記事は英語原文の機械翻訳です。表現が硬い場合があります。英語の原文を読む

AIコード検出ツールは、ファイル、リポジトリ、または提出物がどれだけ機械生成に見えるかをスコア化します。ドキュメント全体のスコアに加え、ファイル単位または関数単位のハイライトを返します。自分のスコアが高かった場合、役に立つ対応は数値と言い争うことではありません。どの行がシグナルを担っているかを見つけ、そこを修正することです。

その判定には、居心地の悪い一面があります。検出ツールは表面的なパターンから推測しますが、コードは文章よりも表面的なパターンが少ないのです。人が書いた、クリーンで慣用的でコメントも充実したファイルは、生成コードとまったく同じに見えることがあります。生成コードは、まさにそう書く人々のデータで訓練されているからです。高スコアはよくあることで、カンニングの証拠にはなりません。

AIコード検出ツールが実際に測定しているもの

それはあなたの意図を読むのではありません。統計を読むのです。

文章用でもコード用でも、ほとんどの検出ツールは2つのことを見ます。次のトークンがどれだけ予測可能か（パープレキシティ）と、その予測可能性がドキュメント全体でどれだけ変動するか（バースト性）です。人間のコードは凸凹しています。退屈なループを書き、次に妙に具体的な名前の変わったヘルパーを書き、次にチケット番号に言及したコメントを書き、次にコピペした設定を4行書く。生成コードはより滑らかになりがちです。識別子の長さが一貫し、コメントのスタイルが一貫し、最初の行から最後の行まで構造が一貫しています。

その滑らかさがシグナルです。したがって、修正とはコードを悪くすることではありません。実際のプロジェクトが持つ自然な凸凹を表に出すことです。

もう一つはっきり言っておくべきことがある。検出器の出力は確率の推定値であり、著者であることの証明ではない。GPTZero自身のFAQでは、信頼度を「検出器の分類が正しい確率」と説明し、90%とは類似した文書において検出器が正しい判断を下す割合が90%であることを意味する例を挙げている（出典: gptzero.me）。これはツールの挙動についての記述であり、あなたのファイルについての記述ではない。Turnitinのドキュメントでは、誤検出を避けるため、1%から19%の範囲ではスコアやハイライトが付与されないように調整していると説明されている（出典: www.turnitin.com）。どのベンダーも同じトレードオフを公然と管理している。すなわち、生成されたテキストを捕捉し、誠実な作業を焼き払わないことである。

なぜ自分のコードがAIが書いたものとしてフラグが立つのか？

ほとんどのケースは4つの理由で説明できる。

定型コードは定型コードである。 CRUDハンドラ、テストの足場、設定ファイル、標準ライブラリのつなぎコードは、人間が入力してもモデルが入力してもほぼ同一である。著者性のシグナルはほとんど見つからないため、検出器は事前確率に頼る。

あなたのスタイルは一貫している。 すべてをdata、result、handleXと名付け、すべての関数に同じ簡潔な口調でコメントを付けるなら、あなたは意図せず生成されたように読める滑らかさを生み出している。一貫性は通常美徳である。ここではそれがあなたに不利に働く。

ファイルが短い。 短い入力では検出器が扱える材料がほとんどない。単一のユーティリティ関数はほとんどが事前確率であり、証拠ではない。

あなたは確かに、その一部にモデルを使った。 2026年にフラグが立つコードのほとんどは混在型だ。あなたがアーキテクチャを書き、アシスタントが3つのヘルパー関数を書き、あなたがそれらを軽く編集した。継ぎ目は実在し、セクション間の質感の変化として現れる。

何かを書き直す前に、まず適切にスコアを測ろう。DeAIzeのAI検出器は文書全体を採点し、各文をAI確率でハイライトする。だから推測するのではなく、どの行がシグナルを運んでいるかが見える。無料プランはサインアップで200語まで、カード不要。

修正方法：ファイル全体ではなく、フラグが立った領域を編集する

スコアをリンターのように扱おう。1つの関数が警告を出したからといって、リポジトリ全体を再フォーマットしたりはしない。

まずスコアを測り、次に編集する。 行単位または関数単位のビューを取得しよう。DeAIzeではそれが文レベルのハイライトだ。コードで言えば、ファイルではなく領域を指し示す。
サイズではなくシグナルで並べ替える。 冷たい部分に触れる前に、最も熱い3つの領域を修正する。冷たいコードの書き直しは無駄な労力で、リスクを増やすだけだ。
コメントを具体的にする。 これはコードにおいて最も効果の高い編集だ。// Initialize the clientを、あなたのプロジェクトにしか書けないメモに置き換えよう。チケット参照、既知の上流バグ、パラメータが無視される理由など。
対称性を崩す。 すべての関数が同じコメント形状なら、いくつかのコメントを削除する。すべての変数が完全な単語なら、明らかなものを短くする。構造が完全に並列なら、1つの分岐をインラインで処理させる。
自分の粗さを残す。 半分終わったTODO、インシデント後に追加した防御的チェック、日付が入った少し醜い回避策。それらは著者性のシグナルであり、本物だ。
再スコアして比較する。 数値が動いたなら、その編集を残す。動かなければ元に戻す。何のためにもならずコードを悪くした書き直しは、決して残さない。

実例。修正前、フラグが立ったヘルパー：

// Function to calculate the total price
def calculate_total_price(items):
    # Initialize total
    total = 0
    # Iterate through items
    for item in items:
        total += item.price
    # Return the total
    return total

その後、同じ動作で対称性が低い：

def order_total(items):
    # No discount logic here on purpose - pricing service owns that (TICKET-4412)
    return sum(i.price for i in items if not i.voided)

2番目のバージョンはより短く、より慣用的で、読者が確認できる理由を伴っています。それが本物の著者が残すものです。これは難読化ではなく、コードの動作を変えるものでもありません。これはあくまで例示であり、測定されたビフォーアフターではないことに注意してください。

検出率についての当社自身のテスト結果

2026-09-28に、私たちは2つのコーパスに対して検出器を実行しました。フラグ閾値は30%です。メタデータで生成済みとマークされていなかったために選ばれた61件のDeAIzeガイドからの709件の参照箇所の参照サンプルは、平均26%、中央値25%、範囲0%から69%を記録し、709件のうち239件の箇所がその閾値以上でした。人間の著作は独立して検証されていないため、これらの数値は人間の偽陽性率を確立できません。未編集のモデル出力、固定プロンプトから編集なしで生成された12件のDeepSeek箇所は、平均33%、中央値34%、範囲4%から46%を記録しました。

もう一度読んでください。これが正直なバージョンだからです。人間の著作が独立して検証されていない参照箇所と、未編集のDeepSeekモデル出力は重複する範囲にあり、平均値はほとんどの人が予想するよりも近いものでした。検出はきれいな分離器ではありません。解釈が必要なノイズの多い信号であり、だからこそ文ごとのハイライトがヘッドラインの数値よりも重要なのです。ツール間でスコアが変動する理由についてより広く知るには、AI Detector Accuracyをご覧ください。

これが間違った選択となる場合

自分が行っていない作業を自分の成果として偽って提出するために、これらを一切使用しないでください。課題、契約、またはコードレビューでコードが自分のものでなければならないとされている場合、誰かが差分を読んで、あなたが説明できない関数について説明を求めてきた時点で、AIコード検出スコアは最も小さな問題にすぎません。

以下の場合も、この作業全体をスキップすべきです：

ポリシーがAI支援を完全に禁止している場合。 スコアを下げるために編集しても、無許可の提出が許可されたことにはなりません。まず確認し、それから開示してください。
コードが端から端まで生成されており、あなたがそれを理解していない場合。 コメントを書き直しても、ウォークスルーではあなたを救いません。コードを学ぶか、提出しないでください。
あなたが評価されているのではなく、告発されている場合。 正式なプロセスが始まっているなら、正しい行動は書き直しではなく、文書化とあなたの下書きです。Academic Integrity Hearing AI では、パネルが実際に何を評価するかを扱っています。
あなたのチームが1つのスタイルガイドを共有している場合。 検出器を満足させるために共有リポジトリ全体で個人の文体を強制するのは、悪い取引です。フラグが立てられた領域だけを修正してください。

再提出する前の短いチェックリスト

全体のスコアだけでなく、どの領域がフラグを立てられたかを把握している。
すべての編集で動作が同一に保たれており、それを証明するテストがある。
コメントにプロジェクト固有の理由、チケット番号、または日付が含まれている。
何も追加していない定型コメントを削除した。
再スコアリングを行い、何が変わったかを説明できる。
提出物のすべての行を、メモなしで口頭で説明できる。

ファイルの一部にモデルを使用した場合は、開示が期待される場所でそう述べてください。どの部分が支援され、どのように検証したかについての短い注記は、あなたが弁護できないクリーンなスコアよりも、ほとんどの場合より良い結果です。

これがより広範なワークフローにどう当てはまるか

コードは表層的なパターンが薄いため特殊なケースです。同じ手法のほとんどは散文にも適用でき、humanize AI text ガイドではそのループをより深く解説しています。テキストをスコアリングし、フラグが立った文だけを書き直し、意味が保たれたと意味的類似度が示した場合にのみ書き直しを採用し、再スコアリングして前後の結果を報告します。サイトで使用されている例の段落では、92%のAIスコアが4%になりました。

コードの場合、ループはよりシンプルで、ほとんどを手作業で行います。検出器は慎重になるように調整されています。Turnitinのドキュメントによると、文書の50%をAIが書いた可能性が高いと識別した場合、実際には最大65%がAIによる文章である可能性があります（出典: www.turnitin.com）— ベンダーは点推定が信頼できないため範囲を広げています。すべてのコードスコアを同じように扱いましょう。確認する理由にはなっても、パニックになる理由にはならず、それ自体が判定結果になることは決してありません。

測定に関する注記：本記事の数値は、2026-09-28の私たち自身のローカル検出器による観察から得られたものです — 61件のメタデータ選択されたガイドからのn = 709参照パッセージ対n = 12の未編集DeepSeekモデルパッセージ、AIスコアの中央値はそれぞれ25%と34%。人間の著作性は独立に検証されておらず、同じガイドからのパッセージは相関しているため、これらの数値は人間の偽陽性率を確立するものではありません。方法：methodology。日付付き証拠：corpus observation, 2026-09-28。