Vibe Codingで作ったコード、ちゃんと育てられてますか？

Smiles

2026年6月16日 17:48

AIでコードが書ける時代だからこそ

Claude や ChatGPT にお願いすれば、プログラミングをあまり知らなくてもコードが出てくる時代になりました。
「とりあえず動いた！」という体験、気持ちいいですよね。

でも、こんなこと起きていませんか？

1週間後に見返したら、自分で書いたコードなのに読めなかった
「ちょっと機能を足したい」と思ったら、どこをいじればいいか迷子になった
AIに「ここを修正して」と頼んだら、関係ない部分まで変わっていた

これ、コードが「動く」だけで「育てやすい状態」になっていないために起きることが多いんです。

その「育てやすい状態」に近づけるための作業を、リファクタリングと言います。

リファクタリングって何をすること？

一言でいうと、「動きはそのままで、コードの読みやすさや直しやすさを上げること」 です。

新しい機能を追加するわけでも、バグを直すわけでもありません。コードの「見た目と構造」を整えることです。部屋の模様替えに近いかもしれません。物は同じでも、配置を変えることで使いやすくなる、あの感覚です。

AIが生成するコードは「動くこと」を優先するので、こんな状態になりがちです。

変数名が `x` や `tmp` や `data2` など、意味がわからない
1つの関数がいろんなことをやりすぎている
同じような処理があちこちにコピペされている
コードの中に突然 `0.1` や `18` といった数字が出てくる

これ自体はAIの性質上しかたないことで、悪いことではないです。ただ、長く使うコードであれば、ここを少し整えておくと後がラクになります。

原則1：名前は「意味がわかるもの」にする

コードの読みやすさは、変数名・関数名でほぼ決まります。

よくある状態（Before）

# Python
def calc(d, r):
    x = d * r / 100
    return d - x

# R
calc <- function(d, r) {
  x <- d * r / 100
  d - x
}

`d` って何？`r` って何？`x` は？　コードを書いた直後はわかっていても、しばらくしたら自分でもわからなくなります。

読める状態（After）

# Python
def apply_discount(original_price, discount_rate_percent):
    discount_amount = original_price * discount_rate_percent / 100
    return original_price - discount_amount

# R
apply_discount <- function(original_price, discount_rate_percent) {
  discount_amount <- original_price * discount_rate_percent / 100
  original_price - discount_amount
}

「元の値段から割引額を引いている」というのが、コメントなしで伝わりますよね。Rは文字数が少なくても動くという良さが失われますが、誰が見てもわかるという点ではこのように分かる変数名と関数の活用が必要だなと思います。
（個人的にはRのPython化と呼んでいます）

名前のつけ方の目安：

変数は「それが何か」を名詞で → `user_age`（ユーザーの年齢）、`total_sales`（合計売上）
関数は「何をするか」を動詞で → `calculate_tax`（税を計算する）、`filter_users`（ユーザーを絞り込む）
はい/いいえで答えられるものは `is_` や `has_` で始める → `is_valid`（有効か）、`has_permission`（権限があるか）

原則2：1つの関数には1つの仕事だけ

AIにまとめてお願いすると、1つの関数に「読み込み」「整形」「出力」が全部入ることがあります。

まとめて詰め込まれた状態（Before）

# Python
def process_sales_data(filepath):
    import pandas as pd
    df = pd.read_csv(filepath)       # 読み込み
    df = df.dropna()                 # 空欄を除く
    df['total'] = df['price'] * df['quantity']  # 合計を計算
    df = df[df['total'] > 0]         # 絞り込み
    print(df.groupby('category')['total'].sum())  # 表示
    df.to_csv('output.csv', index=False)          # 保存

# R
process_sales_data <- function(filepath) {
  df <- read.csv(filepath)
  df <- na.omit(df)
  df$total <- df$price * df$quantity
  df <- df[df$total > 0, ]
  print(aggregate(total ~ category, data = df, FUN = sum))
  write.csv(df, "output.csv", row.names = FALSE)
}

これだと「表示の部分だけ変えたい」「保存先を変えたい」というときに、全部を読み解かないといけません。

役割を分けた状態（After）

# Python
def load_sales_data(filepath):        # データを読み込む
    import pandas as pd
    return pd.read_csv(filepath)

def clean_sales_data(df):             # データを整える
    df = df.dropna()
    df['total'] = df['price'] * df['quantity']
    return df[df['total'] > 0]

def summarize_by_category(df):        # カテゴリ別に集計する
    return df.groupby('category')['total'].sum()

def save_data(df, output_path):       # 保存する
    df.to_csv(output_path, index=False)

# 使う側でつなぐだけ
raw   = load_sales_data('sales.csv')
clean = clean_sales_data(raw)
print(summarize_by_category(clean))
save_data(clean, 'output.csv')

# R
load_sales_data <- function(filepath) {
  read.csv(filepath)
}

clean_sales_data <- function(df) {
  df <- na.omit(df)
  df$total <- df$price * df$quantity
  df[df$total > 0, ]
}

summarize_by_category <- function(df) {
  aggregate(total ~ category, data = df, FUN = sum)
}

save_data <- function(df, output_path) {
  write.csv(df, output_path, row.names = FALSE)
}

# 使う側でつなぐ
raw   <- load_sales_data("sales.csv")
clean <- clean_sales_data(raw)
print(summarize_by_category(clean))
save_data(clean, "output.csv")

関数が小さくなると、AIに「この関数だけ直して」と頼みやすくなるのも嬉しい副産物です。
今まではRで自分の思うがままでコードを書いていましたが（それが快感でしたが）、リファクタリングでは一歩下がって誰でも分かる形で、必要な処理を関数化することで、他者と共有可能な形で視覚化することができるので、その変化は受け入れないといけないかな、と自分自身、複雑な気持ちでありながら感じています。

原則3：同じコードを2回書かない

同じような処理をコピペしていると、修正するときに「全部直さないといけない」問題が起きます。しかも1箇所直し忘れると、そこだけ古い動きになってしまいます。
Rではあるある！と共感いただける方が結構いるのかなと思っています。

コピペが増えた状態（Before）

# Python
print("==========")
print("売上レポート")
print("==========")

# ...処理...

print("==========")
print("在庫レポート")
print("==========")

# R
cat("==========\n")
cat("売上レポート\n")
cat("==========\n")

cat("==========\n")
cat("在庫レポート\n")
cat("==========\n")

1箇所にまとめた状態（After）

# Python
def print_header(title):
    line = "=" * 10
    print(f"{line}\n{title}\n{line}")

print_header("売上レポート")
print_header("在庫レポート")

# R
print_header <- function(title) {
  line <- strrep("=", 10)
  cat(line, "\n", title, "\n", line, "\n", sep = "")
}

print_header("売上レポート")
print_header("在庫レポート")

「区切り線を20個にしたい」となっても、`10` を `20` に直すだけ。これが DRY原則（Don't Repeat Yourself＝同じことを繰り返さない）の考え方です。

原則4：謎の数字に名前をつける

コードの中にいきなり `18` や `0.1` が出てきても、それが何を意味するかわかりません。これを「マジックナンバー（魔法の数字）」と呼びます。魔法みたいに意味不明、という皮肉です。

意味がわからない状態（Before）

# Python
if user_age >= 18:
    price = base_price * 0.9

# R
if (user_age >= 18) {
  price <- base_price * 0.9
}

`18` って成人年齢？ `0.9` って割引？何の割引？

名前をつけた状態（After）

# Python
ADULT_AGE     = 18
DISCOUNT_RATE = 0.1

if user_age >= ADULT_AGE:
    price = base_price * (1 - DISCOUNT_RATE)

# R
ADULT_AGE     <- 18
DISCOUNT_RATE <- 0.1

if (user_age >= ADULT_AGE) {
  price <- base_price * (1 - DISCOUNT_RATE)
}

名前をつけると「仕様の説明」にもなります。割引率を変えたいときも、`DISCOUNT_RATE` を1箇所直すだけでOKです。

原則5：コメントは「なぜ」を書く

コメントでありがちなのが、コードの内容をそのまま日本語にしてしまうパターンです。でも、読めばわかることをコメントにしても意味がありません。

コードの繰り返しになっているコメント（よくある例）

# Python
# ユーザーの年齢を取得する
user_age = get_user_age()

# 18以上かどうか確認する
if user_age >= 18:
    pass

コードを見ればわかりますよね。これだとコメントが邪魔になることすらあります。

「なぜそうしているか」を書いたコメント（良い例）

# Python
user_age = get_user_age()

# 酒税法の要件により、18歳未満にはアルコール商品を表示しない
if user_age >= 18:
    show_alcohol_products()

# R
user_age <- get_user_age()

# 酒税法の要件により、18歳未満にはアルコール商品を表示しない
if (user_age >= 18) {
  show_alcohol_products()
}

「なぜこの条件なのか」「なぜこの値なのか」という背景こそが、コメントに書く価値のあることです。

AIとの上手な付き合い方

リファクタリングもAIに手伝ってもらえます。こんなふうに使い分けると便利です。

コードを作るとき : 「〇〇をするコードを書いて」
整えるとき : 「このコードを読みやすく直して。変数名と関数の分割を意識して」
確認するとき :「このコードの問題点を教えて」

「とりあえず動くコードを作ってもらう」→「動作確認」→「読みやすく直してもらう」このサイクルを回すだけでだいぶ変わります。

タイミングはいつがいい？

何か追加したいときに、その前にちょっと整える
バグを直したときに、周りも見直してみる
「読みにくいな」と感じたとき、それがサインです

最初から完璧なコードを目指す必要はないです。「触るついでに少し整える」習慣で十分です。

まとめ

意味のある名前 | 名前を見ただけで何かわかるようにする
1関数1仕事 | 1つの関数に詰め込みすぎない
繰り返さない（DRY） | コピペより関数にまとめる
定数に名前をつける | 謎の数字をそのまま書かない
コメントは「なぜ」 | 見ればわかることより、背景を書く

Vibe Codingは「素早く形にする」のに本当に強いツールです。ただ、作ったあとに少しだけ「整える」意識を持つと、1ヶ月後の自分やAIがずっと助かります。

「知ってたつもり」でも、意外と実践できていないことが多いのがリファクタリングです。ぜひ一度、手元のコードを見直してみてください。

参考になったら、スキやフォローをいただけると嬉しいです。