AIっぽくないソースの書き方

愚痴を聞いてくれ

近年のAIの進化、ほんとに怖いレベルですよね。
最近ではChatGPTをはじめとした生成AIでコードを書く開発者がどっと増えました。

ただプロジェクトの品質が上がったか？と言われると、正直ビミョー。
というのも、自分の理解を超えた部分までAIに丸投げするケースを見かけるからです。

納期は短縮できても、品質が反比例している例が多い。
「これ、確認せずにAIに書かせたよね？」と一目でわかるソースが山ほどあるのが現状。

そんな「うぐっ」となったあなたに届ける、人間らしいソースを書くコツ。
AIを使うのはアリ。でも最終的な品質は自分が背負う________。
その覚悟を持ちましょう。

AI っぽさ全開のコード、ここを見ればわかる

1. 過剰で無意味なコメント

生成AIは解説を兼ねて出力するため、親切すぎるほどコメントを入れがち

function getEvenNumbers(arr) {
  // 新しい空の配列を作成します
  let result = [];

  // 配列の各要素をループします
  for (let i = 0; i < arr.length; i++) {
    // 要素が偶数かどうかをチェックします
    if (arr[i] % 2 === 0) {
      // 偶数であれば、結果の配列に追加します
      result.push(arr[i]);
    }
  }

  // 偶数だけを含んだ配列を返します
  return result;
}

大体こんな感じ。
コードの言い換えしかしていないコメントに存在意義はないのだよ。

2. 直訳すぎ・説明しすぎの命名

• どの変数もvalueやdata
• かと思えばcalculate_the_average_of_listのような長文関数名
• プロジェクトの命名規則と食い違うケース

可読性アップどころか違和感マシマシ。

3. 「整いすぎ」と「冗長」が交互に出現

人が書くコードには適度な省略と無意識のクセが混ざります。
AIまかせだとGitのコミットを後で眺めたとき、

完璧に教科書どおりな処理が続いたかと思えば
非効率な冗長すぎる防御的コーディングを延々とやる処理がある

みたいな極端な振れ幅が出がちです。
つまるところ、あるときは「めちゃくちゃ賢い処理」を書いたかと思えば、
次のコミットでは「なぜかすごく効率の悪いコード」を提出してくる。

今日〇〇君疲れてるのかな、、とかで収まらない振れ幅で
レビューを投げられるとさすがに気になります。

人間らしさを取り戻す 4 つのポイント

ていうか必ず自分の手を入れるんだ！！！！

1. フォーマット & スタイルを統一

自動整形ツールまたは自分の手で
プロジェクト規約どおりのインデント・改行・カッコ位置へ。

2. コメント & ドキュメントの取捨選択

価値の薄いコメントは削ぎ落とし、本当に伝えたい意図だけ残す。
プロジェクトに合わせるのがまず第一ですが長文はREADMEやGitのdescriptionに逃がす手もアリです。

3. 言語らしい・最新の書き方にアップデート

JSならvar → let / const、コールバック → async/await
Pythonならstr.format() → f-string、for ループ → 内包表記

AIは基本的に大量の学習データに基づいた平均的なコードを書きます。
場合によっては少し古いやり方やオーソドックスすぎる書き方になっていることもままある。
こういったところは最新のスタイルで書き直してこそプロの仕事。

4. 冗長ロジックをリファクタリング（最重要）

似た処理は関数化、深いネストはガード節で潰す
AIに任せきりにするのではなく 「もっとシンプルに書けない？」 を常に自問。
これを伝えたいがためにここまで書いたといっても過言ではない

【実例コード比較】AI 生成コード vs 手直し後コード

シンプルな例として、javascriptで配列の平均値を計算する関数をAIに
生成してもらった場合で考えてみます。生成AIが書いたコードと、
それをリファクタリングしたコードで比較してみます。

プロンプト
JavaScriptで、数値の配列を受け取り、
その平均値を求めて返す関数calculateAverageを定義してください。
加えて、[10, 20, 30, 40] というサンプル配列を使って関数を実行し、
結果をconsole.logに出力してください。
適切なコメントをコードに含めてください。

AI 生成バージョン

// 配列の平均値を計算する関数
function calculateAverage(numbers) {
  let sum = 0;
  for (let i = 0; i < numbers.length; i++) {
    sum += numbers[i]; // 各要素を加算
  }
  const average = sum / numbers.length; // 平均を計算
  return average; // 平均値を返す
}

const data = [10, 20, 30, 40];
console.log("平均値:", calculateAverage(data));

手直しバージョン

/**
 * 配列の平均値を返す
 * @param {number[]} numbers - 数値配列
 * @returns {number} 平均値（整数）
 */
function calculateAverage(numbers) {
  if (numbers.length === 0) return 0;
  const sum = numbers.reduce((acc, n) => acc + n, 0);
  return Math.floor(sum / numbers.length);
}

const data = [10, 20, 30, 40];
console.log("平均値:", calculateAverage(data));

どこが変わった？

• コメント
  AI版はコードをそのまま言い換えただけ。手直し版では冗長コメントを削り、代わりにJSDocで「何を・なぜ」を伝えています。

• 集計処理
  for ループを使うより、reduce のほうが配列を畳み込んで合計を得るという意図が一目でわかりますし、1行でスッキリ書けます。

• エラー処理
  AI 版は空配列だとゼロ割りでNaN。手直し版はガード節を入れて0を即返すので安全。

• 戻り値の仕様
  小数点以下を捨てたかったためMath.floorを追加。
  AI 版は小数が入るのでたとえばフロントエンドが「必ず整数」と思い込んで
  小数を切り捨てず表示するとレイアウト崩れが起きることも。

このように、可読性・安全性・要件適合性を後からちゃんと
「人間」がチェックして整えることで、人が書いた感と品質が向上します。

Q.ではこれを元にプロンプトを改善すれば人の手はいらない？

A.だめです。ちゃんと自分の手を使ってください。

なぜかというと、プロンプトは仕様書になり切れないからです。

プロジェクト固有のコーディング規約やチーム合意のスタイル、命名ルール
ドメイン知識やビジネス要件に紐づく微妙なニュアンス
これらを一枚のプロンプトで完全に同期させるのは無理があります。

プロンプトはあくまで最大公約数までしか縛れません。
その揺れ幅や実行責任を吸収できるのは、結局あなた自身の目と手なのです。

それにすべてをAIに任せきりにすると、アルゴリズムやロジックを深く考える機会を失い、
技術的スキルやノウハウの成長を阻害する大きなリスクもあります。

まとめ

AIの力を上手に借りつつ最終品質は自分で担保しましょう。
生成AIの登場でコーディングは格段に効率化しました。ちょっと命令するだけで
ある程度動くものがすぐ手に入ります。
しかし、そのまま鵜呑みにして提出するのは危険です。

実際、「動けばOK」ではなく「読みやすく保守しやすいコード」にすることが
プロの仕事ですよね。

AIの力を借りるの自体は悪いことではありません。
私もよく使っています、むしろ上手に使えば生産性向上の強力な味方です。
でも最終的なコード品質に対して自分が責任を持つことを私と約束してください。