本記事では、2025年5月14日に開催されたオンラインイベント「【技術選定を突き詰める】Online Conference 2025」内のセッション「技術選定の審美眼 2025年版」の内容をお届けします。同セッションでは、タワーズ・クエスト株式会社の和田卓人（@t_wada）さんに、1990年代前半から現在にかけての技術の変化の歴史についてお話いただきました。ぜひ本編のアーカイブ動画とあわせてご覧ください。
和田：
和田卓人（t-wada）と申します。インターネット上ではt-wadaさんと呼ばれています。技術顧問としてコンサルティング業を多く手掛ける傍ら、技術書の出版や翻訳にも関わっています。SQLアンチパターンという本の第2版が7月上旬に発売されますので、是非よろしくお願いいたします。
本日の講演は、「技術選定の審美眼2025年版」です。2018年頃にDevelopers Summitで初演して以来、アップデートしながら続けてきたもので、今回も大幅にアップデートしました。
さて、技術選定はなかなか大変で、後悔することもあります。以前「JavaScript Fatigue」という言葉があったように、JavaScriptは変化が早すぎる技術領域として認識されていました。外から見ると非常に早く見えてしまいキャッチアップに疲れてしまう、というような状況が起こります。一方で限界集落のような技術もあり極端なコントラストが存在しますが、そういうほうが安定しているという考え方もあります。
変化が速すぎることは陳腐化の速さでもあります。本質的ではない変更を強いられ軽微な変化に消耗したり、重要な変化を見逃し先行者利益を逃すことにつながるため、どのような技術に手を出すかを見極める先見の明が重要です。最近で言えば、AI周りの進化が速すぎて、やはりAI疲れのようになってしまうこともありますね。
この講演は初演時のDevelopers Summitのテーマである「変わるものと変わらないもの」を骨組みとしています。今後、技術がどのように変化していくかは正直分かりません。だからこそ、過去を学んで近未来は予想できないか、そして未来に身軽に備えようという考え方です。どのような変化があったかを見ることで、直近で何が起こるかを予測する、という講演です。
技術の変化の歴史はよく振り子に例えられますが、私は螺線に例えます。一見すると同じところに戻ってくるように思えますが、角度を変えて見ると、同じ場所に戻るのではなく、少しずつの技術の積み上げや問題解決によって、技術が進化していくという考え方です。ただの繰り返しではなく、そこに差分があるという考え方が大事だと思います。過去の差分、背景、そしてそれを可能にした技術（イネイブラー） が重要です。この差分を見極める力こそが、ベテラン技術者の数少ないアドバンテージです。基本的に技術の世界は後発が有利で若者が有利です。シニアエンジニアが戦っていく道は、過去の周期を体験し、その差分を捉え「打率」を上げていくのが、ベテランの戦う道となるわけです。
激しい変化の歴史もあれば、その一方、技術の中には変わらないように見える強固なものもあります。まずはそちらから見ていきましょう。この講演は、私のソフトウェアエンジニアとして約27年間のキャリアに基づいて構築しています。データエンジニアリングは専門外のため言及はできませんが、私がこれまでに見てきた歴史をお話ししたいと思います。
変わらないもの：長生きしている3つの技術に学ぶ
私のキャリアの中で長く生きている、手堅いと考える技術領域は主に3つあります。それはUNIX、RESTおよびWeb、そしてリレーショナルデータベースおよびSQL、この3つです。なぜこれらが長く生きているのか、その共通点を探っていきましょう。
UNIXの哲学
UNIXはOSですが、UNIX哲学というものがあります。例えば、「Small is beautiful（小さいことは良いことだ）」、「Make each program do one thing well（一つのことをうまくやれ）」、「Keep it simple（単純にしろ）」といった価値観です。これに加え重要なのは、UNIXの世界ではOSはほぼすべてをファイルで表し、そのほとんどがプレーンテキストという点です。CPU情報、メモリ、ネットワークも、すべてファイルのように扱われます。
これは、すべてをプログラムとして扱う設計思想が背景にあります。UNIXプログラムは標準入力と標準出力でプレーンテキストを扱うフィルターとして書かれています。成功・失敗はメッセージではなく終了ステータスで示されます。そうやってプログラム同士をパイプで繋ぐことで、時間を超えた再利用が可能になります。例えば40年以上前に書かれたcatに、私がよくAIで使うclaudeコマンドに食べさせ、JSONで出力してjqに食べさせる、といったことをすると、プログラムが簡単に相互接続されます。これはかなりすごいことで、これこそがUNIX哲学の真髄です。
RESTとWebの哲学
RESTとWebの世界では、すべてがURLで示されるリソースです。UNIXがすべてファイルであるのと同様、RESTやWebの世界ではすべてがURLです。URLへの操作は、GET、POST、PUT、DELETEなど統一された少ない動詞で行われます。状態はステートレスで、状態遷移はハイパーリンクで、成功・失敗はHTTPステータスで示し、その厳格なルールを守ることで、サイトやサービスが繋がります。難しいと考えられていた分散システムですが、実は成功例は目の前にある、つまりWorld Wide Webであるという認識が2000年代中盤に広まりました。
リレーショナルデータベースとSQL
リレーショナルデータベース（RDBMS）は、関係代数という強固で数学的な背景を持っています。この世界では、すべてが関係（リレーション）です。テーブルも、SELECTクエリの結果もまたリレーションです。これは、系が閉じている、つまり演算が閉じているという意味です。できることが少なく、SELECT、INSERT、UPDATE、DELETEといった統一された操作のみです。SQLは最近ではRDBMSだけのものだけでなく、技術の螺線はNoSQLを経てNewSQLへと戻ってきており、この辺りは後ほどお話したいと思います。
3つに共通するもの
ここまで見てきた3つに共通するのは、制約が強いということです。インターフェースが狭く、できることが少なく、振る舞いの種類が少ない。その代わりに、実装が厳格なルールで統一されているため、相互接続性が高まっています。これにより、接続と再利用が時間を超えて可能になり、枯れていて安定しているというわけです。シンプルだと言っても良いでしょう。
この背景には、「すべては〜である」という抽象化がうまくいっているという点があります。この抽象化には「てこ」の効果があります。例えばUNIXは「すべてはファイルとフィルターである」と抽象化しました。だからこそ、/procのような、ファイルシステムだと思ったらハードウェア情報だった、というのも含めてすべてプログラムで扱えるようになっているのです。
RESTやWebの世界は「すべてはURLで示されるリソースである」と抽象化がされているからこそ、リソースを取得したければGETである、というように操作が決まっているのです。RDBMSとSQLは「すべては集合である」と抽象化がされています。そしてその集合に対する演算結果もまた集合に戻ってきます。このような、結果もまた同じ型になる性質を「閉包性（Closure Property）」と言い、これができると非常に強力です。例えばRDBMSでは、SQLの実行結果とテーブルを同一視できます。テーブル名を記述する箇所にSELECT文も書けるのはSELECT文とテーブルが同じ関係という概念を共有しているからです。UNIXでも、ファイルの中身とコマンドの実行結果を同一視することができます。だからファイルを扱うように、先行コマンドの出力結果をパイプで受け取り、ファイルと同じように扱える、という抽象化がなされています。これが変わらないものの抽象化の力です。
変わるもの：アーキテクチャの螺旋 7つの時代
さて、ここからは変わるものについてです。私が見てきた時代を7つに分け、Webシステムのアーキテクチャ（システムアーキテクチャやアプリケーションアーキテクチャ）がどのように螺線状に進化してきたかを分析していきたいと思います。相互に少しずつ重なる7つの時代、各時代に何があったのか、前の時代のどのような問題を解決したのか、そしてその時代に新たに生まれた問題はどのようなものだったのか、という形で整理していきます。
1.クライアント・サーバー時代
1990年代前半〜2000年、Visual BasicやDelphiの頃にはまだインターネットはありませんでした。当時はLAN上で、TCP/IPなどを用いデータベースサーバーとクライアントアプリケーションが直接繋がっていました。VBやDelphiなどで書かれたクライアントが、OracleやSQL Serverに直接繋がっており、UIが直接SQLを発行し、データベースとやりとりする二層アーキテクチャです。クライアントがUIを担当し、データベースサーバーがデータ保存と処理を行いますが、クライアントだけにロジックがあるわけではありません。ストアドプロシージャをご存知でしょうか。RDBMS内にプログラムを格納し、RDBMS上でプログラムを動かす技術です。例えば、データを扱うプログラミングは、VB側だけでなくストアドプロシージャ側でも実装されていました。この時代から後の技術的な課題が生まれました。
次の時代からは前の時代の課題を解決する形になるのですが、クライアントサーバー時代が抱えていたのは主に以下の課題でした。
2．初期WebとエンタープライズJava時代
次に、1995年から2004年頃の初期WebとエンタープライズJava時代です。厳密には異なりますが、ほぼ同じ時系列に存在するため混ぜています。PHPやPerl、ASP、JSP、Javaサーブレットなどのサーバーサイド技術、アプリケーションサーバー上で動くバックエンド技術が急速に発展しました。これにより動的なWebページの生成が可能になり、同時にWebブラウザやWeb標準（HTMLやCSS）も発展し始めます。バックエンドサーバーサイドにおいても、Javaなどを使ってJ2EEやEJB、つまり企業の基幹システムをCOBOLやCORBAからJavaで作り直したり、新規で開発したりする動きでした。当時はXMLが非常に流行し、何でもXMLで定義するというような時代でした。XML関連技術が多数登場し標準化されていきます。基幹システムであるため、堅牢性・信頼性のあるシステム構築が求められ、 SOA（サービス指向アーキテクチャ） という分散システムのような考え方が広まり、再利用可能な基幹システムを作ろうという時代でした。ちなみに、AI時代のA2Aプロトコルなどを見ると、SOAP時代やWSDL時代を思い出します。
これによりクライアントサーバー時代の課題を以下のように解決しました。
しかし、新たな技術的課題も出現しました。まず、まだSPAではないため、リンクをクリックするたびにページが完全にリロードされ、ユーザー体験に制約がありました。次に設計がステートフルだったことです。HTTPはステートレスですが、アプリケーションは状態を保持する必要があるため、サーバー側でセッションを維持して状態管理していました。これが、水平スケーリングを大きく阻害しました。さらに、初期のHTMLとCSSは表現力が乏しく、J2EEやSOAの世界ではXMLを大量に設定として記述する、複雑で重厚な時代でした。これは以前の汎用機時代の考え方を引きずっていた面もあり、結果として、重量級で複雑な分散システムになってしまったのです。
3．動的WebとREST APIの台頭期
次は、2004年から2010年頃の動的WebとREST APIの台頭期です。まず、Ajax（Asynchronous JavaScript + XML）という概念が2005年に提唱され、ブラウザ上でのJavaScriptによる非同期処理が可能になったことでJavaScriptが再注目されました。Google Mapsなどが登場し、皆が度肝を抜かれました。それまで、単なる装飾程度のものと認識されていたJavaScriptがアプリケーションも作れると認識されたのです。さらに、FlashやSilverlightといったブラウザのプラグインを導入することで、リッチなインターフェースや動画、アニメーションなどが実現可能になり、結果としてWebアプリケーションの使い勝手がデスクトップアプリに近づき、よりリッチな体験が可能になりました。
ではバックエンド側で何が起こったかというと、Ruby on Railsが2004年〜2005年に登場しました。 「Convention over Configuration（設定より規約） 」という思想を打ち出し、XMLによる大量の設定地獄をゼロコンフィギュレーションにしました。その開発速度と設計のシンプルさ、および「ビジネス初期は分散システムなど不要で、ちゃんと動くシステムを早く立ち上げられることが大事だ」という思想が当時の急成長していたWeb企業に響き、多数の事業の早期立ち上げに貢献しました。
以前の時代の課題を以下のように解決しました。
しかし、新たな技術的課題も発生します。当時はまだブラウザ間の互換性が課題で、特にInternet Explorerと他のブラウザ間での違いが大きく、開発の障壁となっていました。また、JavaScript（ブラウザ側）でリッチなシステムを作ろうとしても、モジュール化の標準がなく、グローバルスコープしかなかったため、かなり厳しい状況でした。JavaScriptアプリが大規模化するにつれてJavaScript自体の構造化・モジュール化の機能不足が露呈し、全く準備ができていない、かなり厳しい状態になってしまったのです。さらに、セキュリティのアタックサーフェスが増加し、Flashのプラグインが原因の問題も頻繁に発生しました。まだクラウドがない時代だったので、サーバーをスケールアウトするにも、ハードウェアを並べる必要があり非常に大変でした。
4．モバイル＆クラウド革命期
次は2008年から2015年頃、モバイル＆クラウド革命期です。この時代は情報量が非常に多く、たくさんの技術が登場します。特に2007年から2008年にiPhoneとAndroidが登場したのは決定的で、これによりモバイルアプリ開発の時代が始まりました。スマートフォンが常時接続・常時携帯デバイスとなったことで、ユーザー体験とサービス設計の変革が大きく進みました。また、バックエンドにおいては、APIが返すデータがXMLではなくJSONで良いのではないか、という考え方が明確になってきて、設定もデータもXMLではなくJSONを使うべきという考え方が広まったのです。そして、JSONを返すバックエンドに、iOSアプリ、Androidアプリ、WebのJavaScriptアプリといった3つのクライアントを繋げば良い、という話になったわけです。これはAPIファーストの考え方であり、それまで一人の開発者がしていたフロントエンドとバックエンドを担当していた状況から、徐々に分業するようになりました。
これとほぼ同時期に、AWS、Azure、Google Cloudなど、クラウドプラットフォームが台頭し、大きなゲームチェンジャーが多数出現します。NoSQLデータベースで水平スケーリングが可能になったり、Infrastructure as Codeという概念が登場し、PuppetやChefによってインフラ構築が手作業から自動化されるようになりました。そしてこの背後には、次の時代に開花するSPAの始まりがありました。Backbone.jsやKnockout.js、初期のAngularJSなどが登場し、これまでjQueryだけでは難しかったWebクライアント側の構造化や大規模化への対応が可能になってきたのです。
その結果、この時代には以下のことが解決されました。
しかし、この時代にも多くの課題が出てきました。まず一つ目は、モバイルプラットフォーム間の互換性。さらなる互換性の欠如が問題となりました。iOS、Android、ブラウザなど異なる環境すべてをサポートしなければならない状況でした。次にAPIファーストで皆がREST APIを作るようになりましたが、APIの仕様を明確に定義・共有する標準的な手法がなかったため、個々にAPI仕様を頑張って作成するしかありませんでした。また、REST API自体は、必要十分なデータを持ってくるように設計するのが難しく、オーバーフェッチングやアンダーフェッチングが特にモバイル側で顕著な問題となりました。クラウド環境側は一気にできることが増えたため、運用やデプロイが複雑化しました。これまでのやり方が通用せず、知識のギャップが生じたのです。開発環境と本番環境の差異によるデプロイ障害や、「手元では動くが本番環境では動かない」といった環境依存問題が発生しました。モバイルアプリ自体が抱えていた問題としては、アプリの審査プロセスが挙げられます。App Storeに配布する際、審査を通さなければならなかったため、これが開発プロセスのボトルネックになり始めました。
5．モダンWebフロントエンド期
次の時代は大きく重なり合う2つの側面、フロントエンドとバックエンドに分けています。フロントエンドは、モダンWebフロントエンド期（2013年から2018年）です。この時期に、React、Angular、Vue.jsの「三国時代」が到来し、モダンJavaScriptフレームワークが多数登場しました。Virtual DOMが登場し、画面操作の効率化や宣言的プログラミングが可能になっただけでなく、コンポーネントベースアーキテクチャ、つまり画面のコンポーネント指向開発ができるようになったのは革命的でした。技術面では、HTML5やPWAが登場し、オフライン対応やプッシュ通知など、ネイティブアプリに近づける努力が盛んに行われました。またNode.jsとnpmが大きく普及し、フロントエンド開発のツールチェーンが大幅に強化、TypeScriptも登場し、比較的大きなJavaScriptアプリケーションでも破綻せずに開発できるようになったのです。こうした複雑化するフロントエンドに対応するため、BFF（Backend for Frontend）パターンや、クライアント側でデータを取得するためのクエリ言語であるGraphQLもこの時代に登場しました。
これらの技術により以下が解決されました。
さて、技術的課題です。まず顕著だったのはJavaScript疲れです。モダンフロントエンドが非常に進化し、「また新しいものが出てきたのか」という疲労感が非常に高まりました。JavaScriptアプリが大規模化したことで、バンドルサイズが肥大化し、ブラウザへ送るJavaScriptのサイズが問題になり始めます。また、クライアントサイドレンダリング全盛の時代だったため、SEO対策が非常に困難でした。そしてクライアント側の処理が移行したことで状態管理をFluxやReduxといったアーキテクチャやライブラリで解決しようとしましたが、結果として大量のボイラープレートコードが生まれるようになりました。さらにAPIの技術が多数登場したため、技術選定に迷いが生じるようになりました。GraphQLでやるか、BFFを作るか、あるいは従来のRESTful APIにするか、といった設計選択が大きな課題となったのです。バンドラーやビルドプロセス周りも、WebpackやBabelなど多数存在し、それらを繋ぎ合わせて動かすのが辛いと感じるようになりました。JavaScript疲れは、大体このあたりの状況を指すことが多いです。
6．マイクロサービスおよび分散システム期
その頃バックエンドやサーバーサイドではマイクロサービスおよび分散システム期です。NetflixやAmazonなどがマイクロサービスアーキテクチャ事例を多数公開するようになりました。これをMartin Fowler氏が記事として執筆したり、Sam Newman氏がマイクロサービスアーキテクチャの本を出版したりしたことにより、一気にマイクロサービスアーキテクチャという言葉が広まったのです。前の時代と少し重なりますが、コンテナが登場し、DockerやKubernetesの登場によってコンテナ技術が一気に現実のものになりました。Terraformもこの時期に登場しています。現在使っているツール類がこの時代に生まれ始めたのです。
この時期にはクラウドインフラのプロビジョニングも自動化も進み、OpenAPIやSwagger、gRPCといったAPI設計やスキーマファーストと呼ばれる設計手法も普及しました。それだけでなく、マイクロサービスと一体となり、DevOps文化やCI/CDがどんどん普及したため、自律性のあるチームがマイクロサービスを個別に独立して開発できるようになりました。この仕組みができたことによって、ビジネスとソフトウェアとアーキテクチャが対応付けられるようになったのです。
この時代にドメイン駆動設計が再注目され、その境界付けられたコンテキスト（Bounded Context） という概念が、マイクロサービスの設計、組織をシステムに合わせる「逆コンウェイ戦略」という考え方にも繋がっています。
さて、この時代には以下の課題が解決されました。
しかし、問題はやはり発生します。人々は分散システムの難しさを痛感することになります。マイクロサービスも分散システムなので、リレーショナルデータベースのトランザクションのような強い整合性に頼ることができなくなり、結果整合性の世界を設計する必要がありました。これはかなり難しく、障害検出も困難で、組織の技術力を高めなければ対応できませんでした。「マイクロサービスがキラキラしているからやろう」という理由で導入し、挫折する人も多かったのです。もちろん、技術的に解決し先に進んでいくチームもありました。
またクラウド周りやインフラ周りの技術の増加により、認知負荷が増大し、複雑なCI/CDやモニタリングの問題に直面しました。「作った人が運用する」という価値観はありましたが、手が回らなくなるという状況がこの時代に多く発生しました。
7．再統合と最適化模索期
さて、現在です。分散環境での保証トランザクションは依然難しく、サーガパターンなどで対応が求められる「生々しい時期」です。この頃から、「マイクロサービスは本当に必要か？」という問いが生まれ、モジュラーモノリスへの揺り戻しが見られます。また、覚えることが多すぎるという課題に対しては、プラットフォームエンジニアリングという仕組みで、認知負荷を下げようという動きになってきました。
分散システムにおける整合性確保の問題は、NewSQLというデータベースの仕組みによっても解決の糸口が見え始めています。SpannerやAuroraといったNewSQLデータベースにより、分散環境でも強い一貫性を提供できるようになり、潮目が変わってきました。フロントエンドでは、Jamstack、Core Web Vitals、Island Architecture、エッジコンピューティングでのレンダリングなど、この時代にも様々な進化がありました。一方で、WebAssemblyが登場し、今後ますます活用が進み、投資する価値のある技術だと考えられます。また、ReactはReact Server ComponentsやNext.jsのApp Routerによって、クライアントとサーバーの境界が再定義され、サーバーサイドへの回帰が進んでいます。
現在進行形ですが、以下の課題を解決中です。
現在の技術的課題として、今まさにReact Server ComponentsやNext.jsによって作り方が変わってきている最中、それはそれで難しくなっています。マイクロサービスからモジュラーモノリスへ、あるいは、モノリスからモジュラーモノリスへの移行もやはり難しさを抱えており、エッジ、WebAssembly、AIをどう使うか、といった話ももちろん現代的な課題として出現しています。
集中と分散の螺旋（複雑性とシンプル性の循環）
ここまで見てきた歴史の中で、技術の螺線の具体例として集中と分散の螺線を挙げます。これまで「問題解決、新たな問題」という構成で技術の変化を見てきましたが、この中で明確な螺線の動きを示すのが集中と分散の螺線です。
初期Webは集中かつシンプルでした。しかしエンタープライズJavaによって分散・複雑に。Railsがこれを打破し、再び集中・シンプルな時代へ。しかしRailsのようなモノリシックな構造では大規模事業の限界が見え、企業は分散・複雑なマイクロサービスへと向かっていきます。そして現在は、モジュラーモノリスのようなアプローチや、AIアシスト開発によって、より少ない人数で価値に集中した開発が可能になり、再び集中・シンプルへの回帰が見られます。つまり、まだ螺線が回っているのです。
なぜ2回もわざわざ複雑な方向に向かったのか？という話ですが、まず、シンプルな初期Webのアーキテクチャでは基幹システムの要求に応えられなかったのです。大規模エンタープライズアプリケーションのような再利用性やスケーラビリティ、分散トランザクションといった要素が必要で、それらを追及した結果、SOAやEJB、J2EEなどを使った分散アーキテクチャが形成されました。では、なぜそれがRailsで螺線が戻ってきて、再び分散マイクロサービスへと移行したのかというと、Railsのような集中アーキテクチャはスタートアップ期には理想的でしたが、事業拡大によるモノリスの限界（組織のスケーリングや自律性といった課題）に直面したからです。現在、モジュラーモノリスを採用する企業が増えていますが、これもまたそれなりの難しさも増えてきているのが現状です。
ゲームチェンジャーとなる技術との向き合い方
ここからは、時代の変化の中で特にゲームチェンジャーとなり、新たな時代を拓いたり、革新的な概念として時代の変化を後押しした技術たちについて挙げていきます。なお、これは私のキャリア（Webのフロントエンドやバックエンド）で見てきたものなので、データエンジニアリング周りなどは見えていません。その中で挙げると、Rails、クラウド、スマートフォン、Docker、React、LLM/Agentic Codingです。
量的な変化が質的な変化をもたらす破壊的な技術は多いです。例えば、Railsの生産性はスタートアップ企業に必要な初速や仮説検証を可能にし、事業の立ち上げを劇的に変えました。クラウドの従量課金は、コスト構造やボトルネックを大きく変え、それまでの時代とは全く異なるビジネス環境を生み出しました。Dockerは圧倒的な速さと再現性をもたらし（当時）、LLM自体はその規模が質的な変化をもたらしました。これらは、不可能を可能にし、やりたいことが可能になりました。まさに、コードが事業そのものになる時代へと向かったのです。
一方で、量的な変化ではないものの、考えることを減らす変化も同時に起こりました。ReactはVirtual DOMにより、無考慮にデータ更新してもコストを気にせず、サーバーサイドレンダリングと同じ感覚で、クライアントのコードが書けるようになりました。これはReact Server Componentsなどで再び戻ってきているような感覚です。データの更新が一方向なので、混乱することなく「Source of Truth」という考え方が確立されました。Reactで手間は増えましたが、考えることは減り、心配も減ったのです。「手間を減らす」ことは非常に重要で、例えばチャット型AI自体も、壁打ち相手や叩き台作りとしてはとても有効です。文章もコードも書き始めが一番面倒ですが、それを考えるコストを劇的に下げてくれました。これこそが、チャット型AIの革命的な点だと私は考えています。
ゲームチェンジャーとなる技術をスルーするかどうかは、そのインパクトで判断しようと考えています。開発の労力を劇的に減らしたり、ジャンルそのものを不要にするようなインパクトのあるゲームチェンジャーはスルーすべきではありません。逆に、少し手間が減る程度の価値しかない技術は、公式技術の進化に追いつかれやすく競争力を失いがちです。つまり、できないことができているか、競合ができないことをできるかが、その技術が生き残るかの分かれ目です。CoffeeScriptは手間を減らしましたが、JavaScriptに追いつかれて競争力を失い、TypeScriptはJavaScriptにできないことを可能にしたため、今も生き残っているのです。
AIや大規模言語モデルはスルーできません。今まさに世界を不可逆的に変えつつあり、新人研修の現場でもAI利用が前提となっています。これは人間とAIが互いの強みを活かし、協働して作り上げる時代がきたことを意味します。壁打ち相手や議論相手として使いましょう。答えを求めるのでなく、議論をすることがポイントです。AIは知識の代替ではなく増幅器なのです。これが非常に重要です。私はよく公の場で「労力は外注できるが、能力は外注できない」と言っています。
さて、Agentic Coding（エージェント型のAIにコードを書いてもらう世界）は、まさに今が最新の状況です。去年の秋頃から現在にかけて、私の長いプログラマー人生の中でも、ここまでプログラミングの姿がすっかり変わった経験はありません。Tim O'Reillyが言うように、「The end of programming as we know it（我々が知っているプログラミングの終わり）」なのです。かつて、エンジニアに許された特別な時間だった「自分で考えて自分でコードを書く」は終わりました。AIが助手席から運転席に、人間が運転席から助手席に座るようになったのです。
「Vibe Coding」という言葉も登場しました。これは「Vibesを感じながらノリでコードを書く」ことで良いものができるという原義と、AIアシストコーディングを指す意味合いもあり、扱いが難しいのですが、AIに指示を出しながらコードを生成してもらうという時代が来ています。
プログラミングは変わったものの、不要になるわけではなく、むしろソフトウェアエンジニアリング、つまり要件決めや技術的な検討、議論の記録、タスク化といった意思決定を残し、長い時間変化に耐えるソフトウェアを作ることの重要性は増しました。AIは基本的に自走するが暴走するため、バージョン管理、テストの自動化、といったガードレールを設置することが非常に重要になっています。まるで速いミニ四駆のコースを設計するような、実践的な時代になってきています。
GitHub Copilot Agent Mode、Cline、Roo Code、Cursor、Claude Codeなど、多数のツールが登場しています。一番良いものを選びたいと思いがちですが、積極的に試して変化を感じることが重要です。どのツールが生き残るかは分からない時代なのです。不確実であることを前提として、AIアシストコーディングやAgentic Codingといった世界自体を体験しておくべきです。世界はすでに大きく変わりつつあり、それを肌感覚として知っておく必要があると思います。個人的にはClaude Max/Proプランで、AIエージェントが月額固定になったのは、かなり大きい変化でした。以前はエージェントにコードを書いてもらう度にコストに直結し不満を感じていましたが、固定額になったことで、AIの挙動を温かい気持ちでAIを見守れるようになり、プログラミングに対する感覚が大きく変わりました。
私の感覚では、Agentic Coding（エージェント型AIと一緒にコードを書く行為）は、Kubernetesのリコンシリエーションループに似ています。プログラミングが手続き的ではなく、宣言的なものになってきたからです。私たちはこういう機能になって欲しいといった望ましい状態を宣言的に定義し、そして、そのような機能になっているかどうかの評価をする「適応度関数（Fitness Function）」を与えます。様々な評価関数や適応度関数を使って、理想の状態と目的を与えるとAI自身が判断し、自律的に動くようにするのです。これによって、プログラミング自体もオートメーション（自動化）からオートノメーション（自働化）へと移り変わっていると感じています。機械が自律的に動き、何かまずいことがあった時だけ人間に知らせてくるというものです。これは、人間と機械が並列で仕事できるだけでなく、機械が自律的に複数並列で動くことができるということです。そうすると開発はどんどんスケールし、人間がすべてを詳細に管理する必要はなくなります。これにより開発の並列化が進み、全く異なる景色が見えてくるでしょう。今年の後半は、このようなガードレール設計や評価関数の設計が勝負になると考えています。
まとめです。「変わるものと変わらないもの」について話してきました。生き残る技術や時代を変化させた技術には特徴があり、その背後にある抽象化の力を理解することが大切です。また技術の変化は振り子ではなく螺線です。螺線の差分とそれを可能にした技術を理解することが重要であり、螺線のように軌跡を変えてきたゲームチェンジャーを見抜く目を養うことも重要です。技術のビッグウェーブにはきちんと乗りましょう。今、ビッグウェーブが来ています。それがAIやAgentic Codingです。これらはスルーできません。
私の講演は以上です。ありがとうございました。
アーカイブ動画・発表資料
イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。
▼動画・資料はこちら
※動画の視聴にはFindyへのログインが必要です。