便利さを増やすほど、設計は小さくなるべきだ: AIエージェント時代の抽象化の新しい勘所

便利なものは、いつも重い

コードを書くとき、私たちはつい「便利さ」を足し算しがちです。delegate が欲しいならフレームワークごと入れる。修正を速くしたいなら、AI エージェントを丸ごと導入する。どちらも発想としては自然です。だが、ここに少し奇妙な逆説があります。便利な道具が強力になるほど、本当に価値があるのは、機能を足すことではなく、境界を保つことです。

たとえば、Ruby で delegate を使いたいとき、Rails 以外の場所でも同じ書き味を求めることがあります。でも、そのためだけに巨大な依存を抱えるのは大げさに感じる。そこで小さなモジュールを作るという発想が出てきます。一方で、AI エージェントはコード修正を爆速にする可能性を持ちますが、導入すればすぐに開発が楽になるわけではありません。むしろ、どこまでを任せ、どこからは人間が握るのかという境界設計が、以前より重要になります。

この2つは一見別の話です。片方は Ruby の API 設計、もう片方は開発フローの話に見えるでしょう。けれど、深く見ると同じ問いを扱っています。**「強力な外部能力を、どうやって自分のコードや自分のチームの形に無理なく取り込むか」**です。

---

本当のテーマは、機能ではなく摩擦の設計

ソフトウェア開発では、便利なものを採用するときに、しばしば「何ができるか」だけを見ます。ですが、長く効く設計はむしろ「何が増えるか」を見ています。依存関係、認知負荷、変更時の影響範囲、レビューの難しさ、失敗したときの回復コスト。これらが静かに積み上がると、便利さはいつの間にか重さに変わります。

delegate がまさに象徴的です。委譲は「余計な中継コードを減らす」ための道具ですが、本質は単なる省略記法ではありません。あるオブジェクトの責務を、別のオブジェクトに自然に橋渡しするための構造です。読み手にとって重要なのは、どこに責務があるかが明確になることです。便利だから使うのではなく、責務の境界が整理されるから使う。ここを取り違えると、短いコードを書くための機能が、かえって責務の所在を曖昧にしてしまいます。

AI エージェントも同じです。生成速度が上がると、見かけ上は摩擦が減ります。しかし、実際には別の摩擦が生まれます。指示の精度、修正の検証、差分の理解、意図のすり合わせです。人間が手を動かす時間は減っても、人間が判断する時間は消えません。むしろ判断の密度が上がる。つまり、AI は作業を消すのではなく、作業の種類を変えるのです。

ここで大切なのは、摩擦をゼロにすることが目標ではないという点です。摩擦には有害なものと、健全なものがあります。退屈な定型作業の摩擦は減らすべきですが、設計上の曖昧さに対する摩擦は残すべきです。良い抽象化とは、面倒を隠すことではなく、面倒の種類を選ぶことなのです。

---

小さな delegate と大きな AI が教える共通原理

ここで、あえて両者を同じレンズで見てみましょう。delegate を導入するか、AI エージェントを使うかは、スケールの違う選択に見えます。しかし、両方とも「外部の能力を内部で再利用する」行為です。違うのは、委譲先がコードか、人間か、モデルかという点だけです。

このとき役に立つのが、抽象化の3層モデルです。

1. 構文の抽象化

   • 余計な記述を減らす
   • 例: delegate で中継メソッドを省略する

2. 認知の抽象化

   • 意図を読みやすくする
   • 例: 「このオブジェクトはこれを他者に委ねている」と一目でわかる

3. 運用の抽象化

   • 変更や拡張の手続きを単純にする
   • 例: AI エージェントに修正案を出させ、レビューで採否を判断する

失敗しやすいのは、構文の抽象化だけを見て満足してしまうことです。コード行数が減ると気持ちはよくなりますが、認知の抽象化が弱ければ、あとで誰かが「結局どこで何が起きているのか」を追いかけ回すことになります。AI でも同じで、修正速度が上がっただけでは不十分です。運用の抽象化、つまり「どう確認し、どう戻し、どう安全に使うか」まで含めて設計されて初めて、生産性は本物になります。

便利さとは、何かを省略することではない。省略しても意味が壊れないように、境界を先に決めておくことだ。

この視点で見ると、小さな delegate モジュールを作るという行為は、単なる軽量化ではありません。それは「必要なぶんだけの抽象化を、自分の文脈に合わせて持ち込む」ための選択です。AI エージェントの導入も同様で、ただ最新技術を入れるのではなく、チームの制約に合わせて役割を限定することで、初めて強みが活きます。

---

速さは、自由ではなく責任の再配置

AI エージェントの魅力は、明らかにスピードです。修正案をすばやく出し、テストを回し、手作業より短時間で変更を進められる。だが、スピードが上がると、人間側の責任は消えるどころか、形を変えて戻ってきます。以前は「書く」ことに使っていた時間が、今度は「見極める」ことに移るからです。

ここで重要なのは、速さを単純な効率として扱わないことです。速さとは、意思決定サイクルを短くする能力です。書くのが速くなっただけでは意味がありません。検証し、学び、修正方針を更新するサイクルが短くなるときに初めて、開発は本当に速くなる。AI エージェントの価値は、コード生成そのものよりも、試行錯誤の回転数を上げるところにあります。

ただし、その回転数を上げるには、むしろインターフェースが必要です。何を任せるか、何を任せないか。どのファイルを触ってよいか、どこから先は人間レビュー必須か。どの変更は自動で受け入れず、どういう失敗パターンでは即座に止めるか。これらが曖昧だと、速さはむしろ危険になります。

これは delegate と驚くほど似ています。委譲は「何でも丸投げする」仕組みではありません。どのメソッドを公開し、どの責務を外に見せるかを決める行為です。つまり、delegate は依存を増やすのではなく、依存の見え方を制御するための道具です。AI エージェントもまた、能力を増やすのではなく、仕事の分担を可視化するために使うとき、真価を発揮します。

---

では、何を小さく保つべきなのか

ここで実践的な問いに落とし込みましょう。便利なツールを導入するとき、何を小さく保てばよいのか。答えはシンプルです。**「依存は大きく、接点は小さく」ではなく、「能力は大きく、接点は小さく」**です。

この違いは重要です。依存を大きくするというのは、内部でどれだけの複雑さを抱え込むかという話です。一方、接点を小さくするというのは、その複雑さを外部に見せる面積を絞ることです。小さな delegate モジュールはまさに後者です。Rails の全部を持ってくるのではなく、委譲という一点だけを、必要十分な形で取り込む。AI エージェントも同じで、全面自動化を目指すのではなく、修正提案や定型変更など、明確に切り出せる仕事から任せる。

これを実務の言葉にすると、次のような設計指針になります。

• 能力の導入は広く、責務の公開は狭くする
• 強力な道具ほど、使いどころを限定する
• 再利用したいのは実装ではなく、意図と境界である

この考え方は、個人開発にもチーム開発にも効きます。個人なら、便利さを得るために過剰な土台を背負わずに済みます。チームなら、誰が触っても予測可能な接点を保てます。AI を使う場面でも、同じ原理で「任せる範囲」を狭めるほど、むしろ安心して速度を出せます。

たとえば、以下のように段階を分けると扱いやすくなります。

1. 提案だけ任せる: AI に修正案を出させる
2. 限定的に任せる: 影響範囲の小さいファイルだけ変更させる
3. 検証まで含めて任せる: テスト実行と失敗時の再修正を委ねる
4. 判断は人間が握る: 最終的なマージ判断や設計変更は人間が行う

この分離は、delegate の設計にも通じます。何を外に委ね、何を内部に残すかを明確にすると、コードも運用も軽くなる。逆に、この線引きがないまま便利さだけを追うと、後で修正不能な複雑さが蓄積します。

---

Key Takeaways

• 便利な道具を入れるときは、機能ではなく境界を設計する。 何ができるかより、何をどこまで見せるかが重要です。
• 摩擦をゼロにしようとしない。 退屈な摩擦は減らし、曖昧さを知らせる摩擦は残すべきです。
• 抽象化は3層で考える。 構文、認知、運用のどこを改善したいのかを切り分けると失敗しにくくなります。
• AI エージェントには、仕事の一部だけを任せる。 提案、限定変更、検証など、段階的に責任範囲を広げるのが安全です。
• 小さく保つべきなのは依存ではなく接点です。 強力な能力ほど、外部に見せる面積を絞ると安定します。

---

便利さの次に来る問い

私たちはしばしば、「何を使うか」に夢中になります。しかし、本当に成熟した設計は、使うものを増やすほど、自分の責任範囲をはっきりさせます。delegate を小さく作ることも、AI エージェントを慎重に試すことも、突き詰めれば同じ態度です。強いものを取り込むときほど、自分の側を小さく整えるという態度。

ここには、開発の本質に近い問いがあります。私たちが求めているのは、単なる自動化でも、単なる省略でもありません。欲しいのは、複雑さを無制限に増やさずに、能力だけを拡張する方法です。そのためには、便利さを足す前に、まず境界を決める必要がある。

結局のところ、賢いチームや賢いコードベースとは、何でも抱え込むものではありません。必要な強さを、必要な大きさで受け止められるものです。そこに気づいた瞬間、delegate のような小さな仕組みも、AI エージェントのような大きな道具も、同じひとつの原理で見えてきます。便利さとは、世界を広げる力ではなく、境界を保ったまま世界を広げる技術なのです。