こんにちは。
最近は AI のコード補助を前提 に、仕様 → 生成 → 手直し → 実行を高速に回す開発が増えました。この記事では、このスタイルを Vibeコーディング（= 周辺コードや命名の“雰囲気＝vibe”まで含めてAIに補完してもらう開発手法）と呼びます。
この前提に慣れてくるほど、動的型付け言語（特に規約やメタプログラミングの多い世界）での改修が以前よりしんどい と感じる場面が増えました。以下は、あくまで私のワークフローと現場設定での体感に基づくメモです。
前提（ふだんの開発環境）
- 主に Ruby / Rails と TypeScript を利用
- 仕様は kiro で作成し、実装は Claude Code で生成・編集
- もう少し詳しい流れはこちら
結論先出し：なぜ動的型がしんどく感じるのか
Vibeコーディング（AI補完前提）で改修すると、次の3点が特に効きます。
-
文脈の曖昧さがそのままコードに出る
引数・戻り値・例外の扱いが暗黙だと、AIが“それっぽい”推測で書き、破綻の発見が実行時に回りがち。 -
変更の波及を機械的に検知しづらい
型の制約やIDEの赤線が弱いぶん、部分修正 → 別箇所の静かな破壊が発生しやすい。差分レビューでも見落とす。 -
“暗黙の自動解決・メタプロ”がAIにとって暗黙知になりやすい
命名規約・コールバック・method_missing系DSLなどは近傍コードを読んでも手がかりが少ないため、誤推論が増えやすい。
小さな具体例（体感のイメージ）
- 返却ハッシュのキーや
nil許容を暗黙に変えてしまい、呼び出し側のNoMethodErrorや想定外nilで実行時に初めて落ちる。 - コールバックやメタプロ由来の副作用がエディタ上は見えにくいため、AIが安全側の変更を選びづらい。
TypeScriptでラクになる理由（ただし前提あり）
- 型＝ミニ仕様 がファイル内に明示され、AIの入力コンテキストに載りやすい
- IDE/CIの型チェックが AI提案の自動審査 になる
- 関連情報（型・実装・用例）を 同一ファイル/近傍に局所化 しやすい
- ライブラリAPIも型で露出するため、誤用のノイズが早く出る
注：TypeScriptでも
strict: true（特にnoImplicitAny/strictNullChecks）が前提。型の粒度が粗いと恩恵は限定的です。
ではRuby/Railsはやめるのか？— 現実的な対処
やめません。AIに“読み取りやすい情報”を増やす方向に寄せるのがコツでした。
-
明示化（暗黙より宣言）
- 公開メソッドや境界の入出力をコメント/ドキュメント（YARD など）で明示
- 可能なら RBS/Steep/Sorbet 等で重要な型だけでも置く
-
暗黙度を下げる設計
- 過度なメタプロや
method_missing依存を避け、明示的なサービス/モジュールで責務分離 - 入力DTO/出力DTO を作り、往復のshapeを固定
- 過度なメタプロや
-
情報の局所化
- 使い方（小さなUsage）や注意点を近傍に添える
- 1ファイルの責務を小さく保ち、AIが理解しやすいスコープにする
Vibeコーディングに適した言語の仮説
- 型情報が明示（推論任せにせず“書いてある”）
- 情報が局所化（型・実装・用例が近い）
- 暗黙より宣言（自動解決/メタプロが少ない）
この観点だと TypeScript / Go / Rust は親和性が高く、Ruby でも「明示化＋暗黙度の制御」で十分戦える、というのが今の実感です。
いまの運用指針（自分用メモ）
- 新規開発：まず TypeScript（最短で回る）
- 既存Rails：上記の“明示化パターン”を段階導入（境界の型・DTO・Usageを近傍に）
- レビューでは 型差分 / 公開API差分 を最初に確認
まとめ
AI と組むほど、人間が先に置く“明示情報”が仕事を楽にする と感じています。
言語選択の軸も「人間が気持ちよく書けるか」から 「AIが正確に読み取りやすいか」 へ、少しずつ重心が移動中。
二者択一ではなく、新規はTSで最短、既存Railsは“明示化”で戦う。当面はこの二軸で判断していきます。
