Railsのように考える: See through the Master

RailsTokyo#6での登壇資料です #railstokyo_meetup
https://railstokyo.connpass.com/event/400709/

Transcript

1. Railsのように考える See through the Master ENISHI TECH INC. 島田浩二(@snoozer05) 2026.09.17(Thu) - RailsTokyo#6
2. 島田浩二 @snoozer05
3. ENISHI TECH INC. Vision Organization Management Business Process IT Systems Execution Management Talent Development Teams
4. シンプリシティ― 持続可能かつ人間的で効果的なソフトウェア開発 Dave Thomas 著、島田 浩二 訳 2026年6月2日 刊行
5. https://www.snoozer05.org/pickaxe
6. 5 0 https://regional.rubykaigi.org/nagoya /
7. 今日、お話しすること
8. いただいたオファー “ 内容につきましては、AI時代に突 重要度が した現在、アーキテクチャの まっていると感じておりまして、改めてRailsも含めた アーキテクチャをテーマに、可能であればAIにも触れてお話しい 入 高 ただければと考えております
9. 依頼の背景 • AIがコードを書くようになった • 人間の仕事はアーキテクチャなどのより上位の仕事に移るとい う予測もある “ Most of the tactical work of writing, debugging, and maintaining code shifts to AI while engineers focus on higher-level work like architecture, system design, and strategic decisions about what to build. − 2026 Agentic Coding Trends Report
10. 今日の話 • アーキテクチャの話を入り口に • アプリケーション開発者はAI時代どうあったら良いか • 2026年9月時点での私の考えについて
11. アーキテクチャとは
12. アーキテクチャのよくある捉え方 「XXアーキテクチャ」がよく議論に 最近ではクラウドの構成図が「アーキテクチャ図」と呼ばれている アプリケーション全体、あるいはそれよりも大きなレベルの構造というイメージ
13. ⚠ 構造はアーキテクチャそのものではない • 構造は確かにアーキテクチャの重要な側面の1つではある • けれど、実際にはそれだけがアーキテクチャなわけではない
14. アーキテクチャの定義 ISO / IEC / IEEE : ある対象をその環境の中で捉えたときの基本的な概念または性質、および、 2 2 0 2 0 1 0 2 4 その対象の実現と進化ならびにそれに関連するライフサイクルプロセスを統制する原則
15. アーキテクチャの定義 ISO / IEC / IEEE : システムを成り たせる根本的な概念 性質 ある対象をその環境の中で捉えたときの基本的な概念または性質、および、 概念（コンセプト）の例 性質の例 • テナントをデータ所有 • 障害を局所化できる 隔離の単位として扱う つのアプリケーション • コンポーネントを独 して進化できる ・ 2 • 需要の変化に追従できる 2 0 2 0 1 0 2 立 • 操作を追跡できる 4 • システムを統合された として扱う ・ • 顧客データを隔離できる 一 • 注 と決済は異なるライフサイクルを持つもの として扱う 立 文 その対象の実現と進化ならびにそれに関連するライフサイクルプロセスを統制する原則
16. アーキテクチャの定義 ISO / IEC / IEEE システムを成り たせる根本的な概念 : 性質 それを実現し、制約し、進化させていくときに従う判断原則 判断原則の例 • 境界を超える依存は明 •後 する 互換性を保ちながら変更する • 本番反映は検証可能な経路を通す • 障害を境界の外へ波及させない ・ 2 2 0 2 0 1 0 2 立 4 示 方 • データはその所有境界を通して変更する
17. アーキテクチャの定義 ISO / IEC / IEEE システムを成り たせる根本的な概念 : 性質 それを実現し、制約し、進化させていくときに従う判断原則 構造・振る舞い・品質・開発〜運用を統制する制約・規約・仕組みなどで ・ 2 2 0 2 0 1 0 2 立 4 これらを具体化していく
18. Railsで考えるなら • この定義に沿うと、RailsのアーキテクチャはMVCやモノリスではない • それらはアーキテクチャを具体化した「構造」 • では、Railsのアーキテクチャとは
19. https://rubyonrails.org/doctrine/ja
20. たとえば、モノリスという構造は以下の原則を具体化したもの
21. でも、Railsの公式でRailsはMVCアーキテクチャだって… https://railsguides.jp/getting_started.html
22. MVCはアーキテクチャパターン アーキテクチャパターンとは… • 特定の性質（アーキテクチャ!!）を備える構造に名前が付けられたもの • 「XXアーキテクチャ」と名前がついているのは大体これ
23. 構造のパターンに「アーキテクチャ」と付くくらい密接… なら、あまり区別しなくてもよいのでは？ • これまでは… • けれど、AI時代にはここを区別して考えられることがより重要に思う • なので、なぜアーキテクチャの議論で構造が中心的だったかをまず分解し • それから、AI時代に考えるべきポイントを考察していきたい
24. アーキテクチャの議論で 構造が中心的だった理由
25. アーキテクチャの議論で構造が中 的だった理由 ① 構造は高レバレッジなアーキテクチャの具体化手段 構造は、それだけでアーキテクチャの関心ごとの多くをまとめて解決できる手段 例）マイクロサービスアーキテクチャは、次のような関 ※. トレードオフがあることにも注意は必要 • 変更容易性 • デプロイ容易性 • 障害分離 • スケーラビリティ 心 性 心 立 • チーム間の独 ごとをまとめて実現が可能 (※)
26. ① 構造は高レバレッジなアーキテクチャの具体化手段 ② 構造によって広範囲な影響を防ぐのが経済的だった 人が開発をする前提の世界では、以下が高コストだった • 規模なコードベースを理解する • 広範囲への影響を把握する • 多数の箇所を変更する • 変更結果を検証する そのため、「変更の局所化」「依存の制御」「境界の明確化」などを構造を用いてあらかじめ実現して 変更範囲を制御することに経済的価値があった 心 大 アーキテクチャの議論で構造が中 的だった理由
27. アーキテクチャの議論で構造が中 的だった理由 ① 構造は高レバレッジなアーキテクチャの具体化手段 ② 構造によって広範囲な影響を防ぐのが経済的だった ③ 構造自体も後から変えにくいため、慎重に考える必要があった 構造を一度作ると、コードやデータ、運用など、いろんなものの前提となる。 心 そのため、一度決定した構造を後から変えることが難しかった
28. アーキテクチャの議論で構造が中 的だった理由 ① 構造は高レバレッジなアーキテクチャの具体化手段 ② 構造によって広範囲な影響を防ぐのが経済的だった ③ 構造自体も後から変えにくいため、慎重に考える必要があった こうした理由から、構造は「早い段階で考えるもの」「大きな決定」「後戻りしにくいもの」 心 として、アーキテクチャの議論で中心的に扱われてきた
29. AIによる揺さぶり
30. アーキテクチャの議論で構造が中 的だった理由 ① 構造は高レバレッジなアーキテクチャの具体化手段 AIによって前提の一部が変化している部分 ② 構造によって広範囲な影響を防ぐのが経済的だった ③ 構造自体も後から変えにくいため、慎重に考える必要があった コードベースが大きくても変更範囲が広くても変更箇所が多くても AIは人よりもずっと低いコストでコード変更を実施できる 心 とすると、AI時代には高レバレッジなアーキテクチャの具体化手段である構造を より戦略的に作り直せる余地が出てきていると捉えられるかもしれない
31. とはいえ • 構造自体を変えるコストも全てが安くなったわけではない • コード以外の部分（データや組織、運用） • AIがコストを安くしたコードの変更に関しても、受け取る側のコ スト（理解と把握、妥当性判断など）は安くなっていない
32. ここまでの整理
33. 本質的な意味でのアーキテクチャは確かに重要になるかも • 構造を固定しておくことの経済的必然性がAIによる影響で一段下がる • → これまでには出来なかった戦略的判断や選択が出来る可能性がある • MatzがSpinelのコンパイラを短期間に4度書き直したように • しかし、そのレバーをうまく引けるには、人の側に、より本質的な意味で のアーキテクチャを捉え、判断していける力が必要 • 「アーキテクチャを考える」とは「構造を考える」ことではなく、「そのシステム で実現することは何か・そのためにどうなってなければならないか」を突き詰めて 考えること
34. 本質的なアーキテクチャを捉え 判断していけるようになるには
35. アーキテクチャを捉えて判断していけるようになるには 対象のことを「よくわかっている」必要がある 対象とは… 問題領域のこと 解決領域のこと • ユーザーは何をしたいのか • どんなときにどんな道具を使うのが妥当か • どんな制約があるのか • それぞれの道具のこと • 何を満たさないとならないのか • どんな問題をどのように解いているか • どんなことに気をつける必要があるか では、対象のことを「よくわかっていく」には…？
36. 対象のことを「よくわかっていく」には • 私たちに最初から示されている答え
38. 対象のことを「よくわかっていく」には • 私たちに最初から示されている答え • 『RailsによるアジャイルなWebアプリケーション開発』 アジャイル Rails 問題領域、すなわち 分たちのアプリケーションに ついてのことを「わかっていく」 場 解決領域、すなわちWebアプリケーションについて のことを「わかっていく」 場 足 足 自 ……アジャイルはともかく、Railsもそうなの？ 本当に？
39. Railsはそのための道具として作られている https://rubyonrails.org/doctrine/ja
40. 皿洗いから始めて厨房を任されるようになるまで舌を育てていく環境
41. 対象のことを「よくわかっていく」には • 私たちに最初から示されている答え • 『RailsによるアジャイルなWebアプリケーション開発』 アジャイル Rails 問題領域、すなわち 分たちのアプリケーションに ついてのことを「わかっていく」 場 解決領域、すなわちWebアプリケーションについて のことを「わかっていく」 場 私たち人は、Railsを使ってアプリケーションを開発していきながら 足 足 自 Railsについても、自分たちのアプリケーションについても、少しずつ「わかっていっている」
42. 理論構築としての RailsによるアジャイルなWebアプリケーション開発
43. Peter Naur “Programming as Theory Building”(1985) • プログラミングとは、コードを書くことではなく、問題に対する理論を 構築する活動 • 理論は人の中に構築されるもので、文書には写しきれない • コードやドキュメントは、その理論から作り出される提示の一つ • その人の中に理論があるかは、対象のプログラムが世界とどう対応する か、なぜこうなっているか、変更が来たときにどう対処できるかを説明 できることで確認できる
44. 理論を構築する：Railsアプリケーション開発者の場合 • 最初は「Railsではこう書くらしい」から始まる • そこから、開発を続けて経験を積む中で、以下の段階を進んでいく ① RailsでのWebアプリケーションの書き方を知っている段階 ② Railsが用意している解き方について、その意図がわかっている段階 ③ Railsとは違う解き方も必要に応じて選べる段階 私たち人は、Railsを使ってアプリケーションを開発していきながら Railsについても、自分たちのアプリケーションについても、少しずつ「わかっていっている」
45. AIはどうか？
46. 2 1 8 6 2 0 2 https://rubyonrails.org/ / / /llm-benchmarking-project
47. 現在のレポートからわかること • 要求を満たす能力は高い • 十分実用的な変更を作成できる • 一方で、Railsが提供する方法を使わずに、自前で実装してしまうケース がそれなりに存在する “ models might know Rails, but the tasks were deliberately small, and more than half the time the models reinvented the wheel instead of reaching for the framework. https://rubyonrails.org/ / / /agents-on-rails-stage- 2 9 9 6 2 0 2 「Railsらしい解き方を自然に選べる段階」とは、まだ言いにくい
48. 開発者としてのAI • モデルが良くなっていけば、「Railsの書き方を知っている」は上手にな っていくことが予測できる • Rails APIについての知識は増える • 一般的なRailsのイディオムを選ぶのも上手になる • コードからRailsの設計意図を推論する能力も上がるはず • 人との違いは、モデル自身は開発した経験によって更新されないこと • ドキュメントを残すことで前のセッションから引き継ぎを受けることはできる • けれど、モデル自体が変わっているわけではない • 基本的にセッションごとに新しい開発者がやってきてオンボーディングされている状態
49. 人にもAIにも自分たちのアプリケーションの「理論」が育たなくなる可能性？ モデルが世代交代するたびに「Railsや 」としてはどんどん優秀になる。 アプリケーションを で、セッションを重ねただけでは く育ててきた「よくわかっている」開発者にはならない 理論構築につながるアクティビティを がやらなくなることで、 の側に以前のようには理論が構 築されなくなる 一 方 人 一 ⇨ このアプリケーションを く育ててきた「よくわかっている」開発者にはなれない 長 人側 般的なWebアプリケーション開発のことを知っている新 人 AI側 長 人 AIに仕事を委譲した結果
50. AIに仕事を委譲した結果 人にもAIにも自分たちのアプリケーションの「理論」が育たなくなる可能性？ 2 0 4 7 5 4 7 3 7 4 3 5 3 4 1 0 8 0 2 https://x.com/t_wada/status/
51. アプリケーション開発者はAI時代 どうあったら良いか
52. アプリケーション開発者はAI時代どうあったら良いか • 正解はわからない… • けれど、自分たちのシステムに必要なアーキテクチャを捉え、判断して いけるには、自分の中に「理論」は必要 • 理論 = 問題領域と解決領域を「よくわかっている」こと • 理論は開発を通じて構築されていくもの。だから…
53. ① 開発者として、理論構築を 放さないような開発をしていってほしい “ The agent should move at the speed of the verification, not the speed of the typing — Dave Thomas 実装を任せても、検証と判断は手放さない 今は多くの が、どうしたらAIに実装を任せても の側に理論が残る（育つ）か模索している段階 • Geo rey Litt「Understanding is the new bottleneck」 参考 • dexhorthy「Why Software Factories Fail」 人 手 人 • jessitron「Who are we Now?」 ff 大 事だと思うこと
54. ② 理論に近づける環境、そして外れない環境を作っていってほしい（ にも、AIにも） 判断となぜを残して、理論に近づけ る材料を残す 理論を持っていなくても安全に開発 していけるような仕組みを作る 物の 、守るべきもの、判断の 仕 を残す • ADR • アーキテクチャ適応度関数 • README • Design Doc • SLO • CLAUDE.md • PR • CI/CD • AGENTS.md 人 方 見 理論を十分に持たない状態（AIも人も）でも開発に入っていけるようにする 方 大 事だと思うこと
55. アプリケーション開発者はAI時代どうあったら良いか • 正解はわからない… • けれど、自分たちのシステムに必要なアーキテクチャを捉え、判断して いけるには、自分の中に「理論」は必要 • 理論 = 問題領域と解決領域を「よくわかっている」こと • 理論は開発を通じて構築されていくもの。だから… • 開発を重ねながら、チームに、人に、そしてAIにすら、理論が育つよう な方法を模索していきましょう
56. …そして、これからの方々へ 開発を重ねる中で、Railsのやり方を知り、Railsのやり方に倣い、Railsの意図 を汲み、より良いアプリケーション開発者の道を進んでいきましょう 4 4 3 f b 2 2 8 4 6 5 e -b d -bef 0 5 d- 4 9 8 2 - 2 6 4 9 5 6 4 2 0 2 https://speakerdeck.com/moro/tidying-rails-controllers-and-views-as-rails-think- c d https://speakerdeck.com/palkan/kaigi-on-rails- -rails-way-or-the-highway
57. 6 3 https://speakerdeck.com/kakutani/opening-keynote-for-agilesamurai-basecamp?slide=
58. Railsのように考える See through the Master ENISHI TECH INC. 島田浩二(@snoozer05) 2026.09.17(Thu) - RailsTokyo#6
59. 参考文献 • Anthropic『2026 Agentic Coding Trends Report』 • ISO/IEC/IEEE 42010:2022 • The Rails Doctrine • Rails ガイド • Matz「Extreme Vibe Coding」 • Thomas & DHH『Agile Web Development with Rails』（2005） • moro「dynamic」 • Naur “Programming as Theory Building” (1985)／Cockburn『Agile Software Development』付録 B • Rails Foundation「Agents on Rails」 • Litt「Understanding is the new bottleneck」 • Dex Horthy「Why Software Factories Fail」 • jessitron「Who are we Now?」 • moro「Railsの気持ちを考えながらコントローラとビューを整頓する」 • palkan 「Rails Way, or the highway」 • 『アジャイルサムライ』（オーム社）『チームのひみつ』 • https://x.com/pragdave/status/2052915219047780523 • https://x.com/t̲wada/status/2080143534737457402