AIが書いたコードの画面を見ながら、変数の名前が何を指しているのか分からず、首をかしげて考えている開発者
AIコーディング約13分

AIに書かせたコードの命名を整える｜伝わる名前への直し方

AIに頼んだ関数が、一発で動いた。 ほっとしてコードを読み返すと、process(data) の中で result に item を詰めて、条件は item.flg。動くのは分かる。でも、何をしている関数なのかが名前から読めない——そんな経験、ありませんか。

レビューで「この flg って何？」と聞かれて、自分でも答えに詰まる。現場ではよくあることです。あなたの確認が甘かったわけではありません。AIはあなたの業務の言葉を知らないまま名前をつけているので、ここは人が少し手を貸してあげる所なんです。この記事では、ずれた名前を見つけて、AIと一緒に伝わる名前へ直す手順を整理します。

結論：AIが書いたコードの命名は、①ずれた名前を4つの型（ぼんやり名／業務の言葉とずれた英訳／同じものの呼び名ゆれ／中身とずれた名前）で見つける、②チームの「言葉の辞書」と関数の役割を渡して、AIに名前の候補を理由つきで3つずつ出させる、③人が選び、IDEのリネーム機能で「動作を変えない差分」だけを別コミットで直す、の3手順で整えます。名前を決めるのは、業務の意味を知っている人の仕事。AIは候補出しと抜け漏れ探しの相棒として使うのがちょうどいい距離です。

名前は、コードの中でいちばん安く直せて、いちばん長く効く場所です。 全部を完璧にする必要はありません。次に読む人がつまずきそうな数か所を直せれば十分です。

なぜAIのコードは「名前で読めない」になりやすいのか

AIの命名がずれるのは、AIが下手だからというより、材料が足りないからです。

つまり、命名のずれの多くは文脈の渡し不足です。既存コードへの文脈の渡し方は既存コードにAIを馴染ませる文脈の渡し方｜実務の型で詳しく書きましたが、命名はその中でもとくに「言葉」を渡すと効く所です。

3つの手順で整える

左から右へ3つの場面が並ぶ図。左はコードの書かれた紙を虫眼鏡で調べる場面で「見つける」、中央は吹き出しに名前の札が3枚並ぶ場面で「候補」、右は3枚の札から1枚を手に取る場面で「選ぶ」
ずれた名前を見つけ、AIに候補を出させ、最後は人が選ぶ。この順番で進めると迷いません

進め方はシンプルです。見つける → 候補を出させる → 選んで直す。 AIに「いい感じの名前に直して」と丸ごと頼むと、業務の意味を知らないまま別のぼんやり名に置き換わるだけ、ということが起きがちです。順番を分けるのがコツです。

手順1：ずれた名前を4つの型で見つける

まずは直す場所を見つけます。AIが書いたコードで多いのは、次の4つの型です。

① ぼんやり名 data、info、result、item、tmp、handle()、process()、Manager。どこにでも使えるけれど、何が入っているのか・何をするのかが名前から分かりません。

② 業務の言葉とずれた英訳 チームで「受注」と呼んでいるものが order だったり receivedOrder だったり salesOrder だったり。「締め」が close になって、画面を閉じる処理と見分けがつかない、ということもあります。

③ 同じものの呼び名ゆれ 既存コードでは customerId、AIの新しいコードでは userId、別の所では clientId。同じものなのか、別物なのかを読む人が毎回確かめることになります。

④ 中身とずれた名前 isValid() なのに中でデータを書き換えている、getOrders() なのに取得のついでに更新もしている。名前を信じて呼んだ人が驚く、いちばん気をつけたい型です。

たとえば、こんなコードがあったとします。

function process(data: any[]) {
  const result = [];
  for (const item of data) {
    if (item.flg && item.amt > 0) {
      result.push(item);
    }
  }
  return result;
}

process、data、result、item が①、flg と amt は略語で中身が読めません。動作は単純なのに、読む人は呼び出し元までさかのぼらないと意味が分からない状態です。

見つけるのは、AIに手伝ってもらっても大丈夫です。

このコードの中で、名前から役割が読み取りにくい変数・関数・引数を一覧にしてください。
まだ名前は変えないでください。
それぞれについて「①ぼんやり名 ②業務の言葉とずれた英訳 ③同じものの呼び名ゆれ ④中身とずれた名前」のどれに当たるかと、
そう判断した理由（コードのどこから読み取ったか）を書いてください。
とくに④（名前と実際の処理が食い違っているもの）は優先して挙げてください。

--- コード ---
（貼る）

ここで大事なのは、「まだ変えないで」と言うことです。いきなり直させると、一覧を見て判断する前に差分が出てきてしまいます。

手順2：チームの言葉を渡して、候補を理由つきで出させる

直す場所が決まったら、名前の候補をAIに出してもらいます。このとき渡すと効くのが、チームの「言葉の辞書」です。

立派な用語集でなくて構いません。よく出てくる業務の言葉と、コードでの呼び方を数行メモするだけで十分です。

受注 = order（顧客から注文を受けたもの。取り消し前も含む）
請求確定 = invoiceConfirmed（締め処理で金額が固まった状態）
顧客 = customer（user はログインアカウントの意味で使う。混ぜない）
金額 = amount（税込。税抜は amountExcludingTax）

この数行があるだけで、AIの出す名前はぐっとチームに馴染みます。用語そのものの整理から始めたいときは、AIにドメインモデル・用語を整理させる｜認識のズレを早めに潰すの進め方が使えます。

聞き方の例：

下のコードの名前を、チームの言葉に合わせて整えたいです。まだコードは書き換えないでください。

対象：process、data、result、item、flg、amt

それぞれについて、
- 名前の候補を3つ
- それぞれの候補がどんな意味に読めるか（読む人がどう受け取るか）
- 下の「言葉の辞書」とずれていないか
を挙げてください。
flg のように、コードから意味が確定できないものは、推測で名前を決めずに
「確認が必要」と書き、何を確かめれば決められるかを書いてください。

--- チームの言葉の辞書 ---
（貼る）
--- このコードがやっていること（1〜2行） ---
請求対象になる受注だけを抜き出す
--- コード ---
（貼る）

ポイントは2つあります。

1つ目は、候補を1つではなく3つ出させること。1つだけだと「それでいいか」を判断する材料がありません。3つ並ぶと、「この関数がやっていることに一番近いのはどれか」を比べて考えられます。

2つ目は、意味が分からないものは「確認が必要」と言わせること。上の例の flg は、コードだけでは「確定済み」なのか「削除済みでない」なのか分かりません。AIはそれらしい名前（isConfirmed など）を自信ありげに出してきますが、それは仮説です。仕様書や呼び出し元、データを見て、人が裏を取ります。ここを飛ばすと、ぼんやりしていた名前が、間違った意味のはっきりした名前に変わってしまい、かえって誤解を生みます。

確認が取れたら、たとえばこう整います。

function filterBillableOrders(orders: Order[]): Order[] {
  const billableOrders: Order[] = [];
  for (const order of orders) {
    if (order.isInvoiceConfirmed && order.amount > 0) {
      billableOrders.push(order);
    }
  }
  return billableOrders;
}

動作は1行も変わっていません。でも、関数名を見ただけで「請求対象の受注を絞り込む」ことが伝わります。

手順3：人が選び、動作を変えない差分だけで直す

名前を決めたら、直し方にも少しだけ気を配ります。

直したあとは、テストを流して、挙動が変わっていないことを確かめて終わりです。

ありがちな落とし穴と、その回避

明日からやること（小さく始める3つ）

  1. 今日AIに書かせたコードから、ぼんやり名を1つだけ見つける：data や result を1つ探すだけで大丈夫です。
  2. チームの「言葉の辞書」を5行だけ書く：よく出る業務の言葉と、コードでの呼び方。次からAIに毎回貼れます。
  3. その1つの名前について、AIに候補を3つ出させて、自分で選ぶ：IDEのリネームで直して、名前だけのコミットにします。

この3つで、「なんとなく読みにくい」が「ここをこう呼べば伝わる」に変わっていきます。

コピーして使う「命名の見直しチェックリスト」

# 命名の見直しチェックリスト

## 1. 見つける
- [ ] ① ぼんやり名（data / info / result / item / tmp / handle / process）はないか
- [ ] ② 業務の言葉とずれた英訳はないか
- [ ] ③ 同じものを違う名前で呼んでいないか（例：customerId / userId / clientId）
- [ ] ④ 名前と中身がずれていないか（isXxx なのに書き換える、getXxx なのに更新する）
- [ ] 意味の読めない略語（flg / amt / cnt など）はないか

## 2. 候補を出させる
- [ ] チームの「言葉の辞書」を渡した
- [ ] 関数がやっていることを1〜2行で添えた
- [ ] 候補を3つずつ、読まれ方の説明つきで出させた
- [ ] 意味が確定できないものは「確認が必要」とさせ、人が裏を取った

## 3. 選んで直す
- [ ] 名前は人が選んだ（業務の意味に一番近いもの）
- [ ] IDEのリネーム機能で直した
- [ ] 名前の変更だけのコミットにした（動作の変更と混ぜない）
- [ ] APIのキー・DBのカラム・公開関数の名前は、変える前にチームで相談した
- [ ] テストを流し、挙動が変わっていないことを確かめた

最後に

名前を直す作業は、目に見える機能が増えるわけではありません。 でも、半年後にこのコードを開く誰か——それは未来の自分かもしれません——が、呼び出し元をさかのぼらずに意味をつかめる。それは、チームの時間を静かに守る、ちゃんと価値のある仕事です。

名前を整えたコードを同僚と一緒に画面で見ながら、すぐに意味が伝わって笑顔でうなずき合っている二人の開発者

一度に全部きれいにしなくて大丈夫です。今日は、ぼんやりした名前を1つ見つけて、AIに候補を3つ出してもらうだけ。意味を知っているのはあなたで、候補を広げるのはAI。その分担で、コードは少しずつ「読めば分かる」ものになっていきます。

よければ、こちらも

関連用語