そもそも、なぜ「クラス」が推奨されていたのか？
Pythonを学習していると、必ずと言っていいほど「クラス（オブジェクト指向）」の壁にぶつかります。「プログラムは、データと処理を一つにまとめたオブジェクトで管理すべきだ」——そう教わった方も多いでしょう。
かつてのプログラミング（特にJavaなどの影響が強かった時代）では、カプセル化が正義でした。関連するデータと関数を一つの「クラス」という箱に閉じ込め、外部から勝手に中身をいじらせない——これが大規模開発における安全策だったのです。
しかし2026年現在、このスタイルには現代の開発において「重すぎる」という弱点があることが広く認識されています。
self.xxxが今どんな状態か、常に把握し続けなければならない- クラス内のメソッドが複雑に絡み合い、一部を直すと別の場所が壊れる
- AIコーディングツール（CursorやCopilotなど）にコードの一部を説明するのが面倒
AI時代に「関数型」が選ばれる決定的な理由
AIエディタを駆使した「バイブコーディング」の世界では、もっとも重要なのはコードの独立性（疎結合）です。AIと対話しながら爆速でコードを組み上げるこのスタイルにおいて、クラスを極力使わない「関数型寄り」の書き方が選ばれるようになっています。
理由① AIへの指示がピンポイントで通る
関数型の書き方は、「入力を受けて、結果を返すだけ」の独立した関数の集まりです。AIに「この関数のロジックだけ直して」と頼む際、クラス全体の文脈や他のメソッドとの依存関係を伝える必要がありません。AIは極めて正確に、その関数だけをアップデートしてくれます。
理由② 「データ」と「処理」を分ける潔さ
モダンなPythonでは、dataclasses（データクラス）でデータの形だけを決め、実際の処理は「ただの関数」に任せるスタイルが主流です。
- データクラス：データの入れ物（不変の状態）
- 関数：データを加工して新しい値を返す部品
この役割分担により、「どこでデータが変わったのかわからない」というバグが劇的に減ります。
具体例：スクレイピングで見る「書き方」の差
商品ページから情報を抜くコードで、2つのスタイルを比較してみましょう。
【昔の正攻法】オブジェクト指向
class ProductScraper:
def __init__(self, url):
self.url = url
self.data = None
def fetch(self):
# ページを取得してself.dataに保存する処理
pass
def get_price(self):
# self.dataから価格を計算して返す
passこの書き方だと、get_priceを呼ぶ前に必ずfetchを呼ばなければならない、という「隠れたルール」が生まれます。コードが増えるにつれ、この「暗黙の順序」が複雑さの原因になっていきます。
【今のトレンド】データクラス＋関数
from dataclasses import dataclass
@dataclass(frozen=True)
class Product:
title: str
price: int
def fetch_html(url: str) -> str:
# HTMLを取得して返すだけ
pass
def parse_product(html: str) -> Product:
# HTMLからProductデータを作って返すだけ
pass一つ一つの関数が独立していて、パズルのピースのように組み合わせられます。「HTMLの取得が失敗したかも？」と思えばfetch_htmlだけを見ればいいし、「解析ロジックを変えたい」ならparse_productをAIに投げればいい。この「見通しの良さ」こそがモダンPythonの正体です。
まとめ：まずは「関数」から書き始めよう
もちろん、クラスが完全に不要になったわけではありません。大規模なフレームワークを作る際などには今でも強力な武器です。
しかし、日々行うスクレイピング、自動化ツールの作成、アフィリエイトの効率化といった現場においては、「シンプルな関数」を並べる方が圧倒的に速く、安全で、AIとの相性も抜群です。
「クラスを作らなきゃ一人前じゃない」という思い込みは、もう捨てていい。これからのAI時代、あなたのバイブ（直感）を形にするのは、レゴブロックのように組み替え自由な「関数型」のスタイルかもしれません。
さあ、あなたのコードから self を少し減らしてみませんか？
プログラミング情報サイト「In-Output」" width="1280" height="905" >
