Rubyと私の2025年、2026年の抱負、そしてAIの将来（翻訳）
いつもの私は、このブログ記事やメーリングリストで、ほとんどの場合ソフトウェア開発（多くは一般的なプログラミング言語、特にRuby）に関して徹底的に考え抜いたものだけを扱うことにしています。
しかしここしばらくは開店休業が続いていたこともあり、今回の記事は少しばかり個人的な内容で、いつもほど突き詰めていません。
原注
私のWebサイトでこのブログをたまたま目にした方や、私のメーリングリストにサブスクしたもののメーリングリストの目的を思い出せない方へ（私が何か月も記事を書いていなかったので無理もありません！）リマインダー:
私はウクライナ出身のソフトウェア開発者兼作家であり、現在は軍に勤務しています。私の著作や各種プロジェクト、講演の内容については以下でご覧いただけます。
この2年間に私の書いた記事の多くは、まったくもって一貫性を欠いていました。そうなった理由はいろいろなのですが、再び記事を書く理由（少なくともそうしようとする理由）もあります。
本記事は、私がこの奇妙極まりない時代に「何を書くべきか」を改めて振り返り、今も書く意義のあることに焦点を当てるための試みです。
しかし最初に昨年書いたものをいくつか紹介しておきたいと思います。Rubyがらみのものもあればそうでないものもあります（後者の方がずっと多く、ソフトウェア開発にはまるで無関係です）。
🔗 2025年に書いたもの
2025年のクリスマスにRuby 4.0がリリースされました。これは私が20年以上メインとして使い続けてきたプログラミング言語の新たな「メジャーバージョン」であり、私が（微力ながらも）コミッターであることに誇りを抱いている言語です。
昨年は（たまにissueトラッカーで少し議論した以外は）言語開発にあまり参加しませんでしたが、12月には恒例の解説付きChangelogを作成しました↓。
参考: Ruby 4.0 changes - Ruby Changes
この解説付きChangelogは、Ruby 2.6の時代からかれこれ8年間休むことなく継続しています。また、その後Changelogをそれ以前のRubyバージョンにも拡張して、「Ruby 2.0以来のあらゆる注目すべき変更点」を鳥瞰するリストに発展させました↓。
参考: Ruby Evolution - Ruby Changes
この「解説付きChangelog」でカバーしているのは言語の変更点（構文、セマンティクス、API）だけです。現在の最新バージョンであるRuby 4.0は、「メジャーバージョン」の変更にしてはメジャーな変更点はさほど多くありません（Rubyはセマンティックバージョニングに沿っておらず、Matzによれば今回のメジャーバージョンアップはRubyの30歳の誕生日を祝うためだけだそうです）が、私が独自に定めたChangelogのフォーマット（すべての変更をテストして解説し、デモンストレーションする）に乗せるために相当な作業量を必要としました。
今回もいつものように、新機能や更新を追いかけていて、振る舞いが明瞭でない部分や不足しているドキュメントを見つけました。この作業結果の部分をわかりやすくするため、今年からChangelogの末尾に追記することにしました↓。
参考: Side effects of the changelog -- Ruby 4.0 changes - Ruby Changes
この作業とは別に（後述する独立したいくつかの記事とも別に）、私は貴重な自由時間を、ウクライナ軍所属の著者たちによる現代のウクライナの詩を英訳することに当てました。これは私の個人的なプロジェクトである7uapoems（ウクライナの7人の詩人）の一環です。この方面の作業については私のプログラミング関連ブログ記事ではめったに言及していませんでしたが、これらの詩作や文学作品全般に関心を抱く技術者がこれほど多くいることにいつも驚かされます。
私はといえば、（読者の90%は興味がないかもしれませんが）ついにウクライナ語で小説を書き上げ、初めての出版で読者がついている様子を目にしました。
このことは、私が文章を書くパワーが（あるいは私の物書きとしての衝動がと言ってもよいでしょうが）昨年どの方面で使われたかを示しています。
🔗 2025年に書かなかったもの
ブログ記事やメーリングリスト（それも固定読者がついていた頃の）を放置することは今も不安でたまりません。
読者の皆さん、声の大きさばかりが目に付く現代のインターネットから見ればほんのわずかな人数ではありますが、それでもメーリングリストを購読してくださっている数百人の読者がいるからこそ、「私は生身の人々に話しかけているんだ、虚空に向かって叫んでいるんじゃないんだ」とたしかな実感を得られるのです。
では「なぜ」そうしなかったのか？
先ほどのセクションで理由については「多少なりとも」説明がついたかもしれません。2025年の私は他のメディアで他の話題について大量に書きまくりましたが、しかしそれだけでは説明しきれません。
もうひとつの理由は、言うまでもありませんが戦争です。私は現役の将校として勤務しています（私の「軍務」にはソフトウェア開発も含まれますが）。これによって私の自由時間と執筆のための精神的リソースは制約されています。2025年もウクライナにとって厳しい1年でした。理由はさまざまですが、多くは皆さんも既にご存知か、あるいは気に留めていなかったことでしょう。私たちのチームは大きな成果を達成していますが、その詳細やそこから得られる洞察について現時点では私から詳しく述べるわけにいきません。
現在私が軍務で用いている主要なプログラミング言語や専門知識はこれまでと異なります（Pythonとデータ処理）が、私が関わっているプロジェクトやその活動内容、達成事項については非公開とします。
しかし率直に申し上げると、これですらブログが更新されなかった理由としては不十分です。
実を言うと、私が執筆するときの「フォーメーション」は2通りしかありません。
フォーメーションその1は、（残念ながらめったに発動しませんが）脳裏にひらめいたアイデアや実験や説明を「急いで書き留める」形を取ります↓。
ポイントは、大きすぎない適度に小ぶりなアイデアと、それを書き留めるための空き時間が同時にやってくることです。このマッチングがうまくいかないと、単なる小ネタで終わってしまうか、逆にアイデアを実現するための実装が大規模になりすぎたり、調査や説明のために深掘りすることが避けられなくなったりします。
執筆のためのフォーメーションその2は、（惜しくも多くはこちらなのですが）膨大な思索や包括的なアイデア、あるいは広い領域を納得いく形で説明しようとするものです。私の頭はそのような形で働くようにできています。
まだ詩を書いていた頃（自己完結的な短い形式の詩です）の私は、長い間10〜20個のテキストに順繰りに手を加えるという書き方ばかりしていました。それらのテキストの口調やスタイルはさまざまだったと思うのですが、それでも私の内なるプランや意図に沿ったものでした。
しかし、プログラミング関連のブログ記事を書こうとして、特定のトピックや分野に関するシリーズ記事の執筆計画を立てようとすると、話がややこしくなってきます。読者からの反応が乏しい（もしくはネガティブな反応が多い）と、そのトピックは捨てられがちです。
私のブログには、長編連作記事の開始を華々しく打ち上げる記事がいくつもあり、中にはタイトルに「Part 1」とまで書いてあったりと恥ずかしい限りです。
かと思えば、「ついに書きたいものが見えた」と宣言しておきながらその後のフォローもないまま「軌道修正」と称した反省記事を出したこともありました（例）。
もちろん、「シリーズ記事」が当初の計画通りに無事完結したときもあります。かと思えば、反響が今ひとつで、読者がいるかどうかも定かでないまま終わった記事もあります（Rebuilding The Spellcheckerなど）。
シリーズ記事が当たったこともあります。最近の中で最も成功したのは、2023年秋に「uselessシンタックスシュガー」という少々おどけたタイトルを付けたシリーズ記事です↓。
実は、この予告記事は「フォーメーションその1」で書かれたものでした。公開後ただちに注目されて「"彼ら"が"私たちの"言語に追加した"役に立たない構文"は、実はそこまで"役立たずではない"」理由の説明がRedditに書き込まれ、それから2か月間、十分構造化されたシリーズ記事が週刊で公開されるほどに成長しました。
このシリーズ記事は偶然にもかなりバズりました。この成功は、自分の専門知識に加えて、私独自の視点も重要な役割を果たしたと実感できました。
さらに、言語の進化（つまりプログラミング言語の進化）についてのストーリーに私が魅せられていたことも重要だったと思えました。ただし、私が入れ込んでいたのは「プログラミング言語がいかにして人間のものの考え方やコードの書き方を規定するか」というストーリーです。
その後、「Ruby言語の進化」に関するまとまった文章を書くというアイデアが浮かびました（ブログ記事にするかもしれませんし書籍かもしれませんが）。私がメンテし続けているRuby changelogと先ほどの「uselessシンタックスシュガー」の共通点を抽出して、「Ruby言語はどのようにして今の構文になったか、時とともに構文がどのように変化したか」を一貫したストーリーで語るというものです。このアイデアはいくつかの方法で形にしました↓。
しかし早速、この種のコンテンツに熱中する読者層が不在であることを痛感しました。学術方面でなら見つかるかもしれませんが、少なくとも偶然記事にたどり着いた読者には見当たりませんでした。私は2024年秋にこのシリーズ記事のアイデアを批判的に再検討した結果、最終的にこのシリーズを断念することにしました。
翌2025年の私は、人間がコードを扱うことと、人間が自然言語で文章を扱うことの類似性についての漠然としたアイデアを執拗に考え続けていました。このテーマの広さと深さは手応えがありそうでした（Ruby関連の文章よりもプログラミング関連のコミュニティにアピールしそうに思えました）。しかしこのアイデアへの反応ははかばかしくなく、大胆にもタイトルに第1週と第2週と銘打った2本の記事を公開するにとどまりました。その後、アイデアの規模が大きすぎると特定の人々に刺さりにくくなるのではないかと思いいたりました。たぶん別のアプローチにすべきだったのでしょうし、おそらく今後そうするでしょう。
あるいは、私が注目している言語の微妙なニュアンスや、「優れたソフトウェアは、十分練り上げられた"フレーズ"が育つことで出来上がる」という私の信念は、遠からず忘れられていくのかもしれません。
それにここ数年、人々は自分でコードを書かなくなったようです。
🔗 ちょっとだけ余談: AIに関する私の見解
「AI」という略語で一括りにされている広大な技術領域について、私の考えを網羅的に逐一ここに書き記すつもりはありません。私の興味を掻き立ててきたのは常にAIの技術的・科学的な側面であり、AI周辺の分野で何度も仕事をしてきました（実を言うと、私が2003年に最初にフルタイムのソフトウェア開発者として数か月間勤務していた小さなスタートアップ企業は、当時のニューラルネットワーク技術を株式市場予測などに応用しようとしていました）。私はその方面のインサイダーではなかったものの、業界で長年培われてきたアイデアや意見についてはさんざん接触してきました。
しかしこのセクションでは以下を述べておけば十分でしょう。
私は今でも、AIの技術的な側面、すなわちシンプルな数学から「知性を錯覚させる（intelligence illusion）」振る舞いが生じることに、子どものような驚きを覚えます。今引用したのはBaldur Bjarnasonの著書のタイトルですが、彼の見解には深い敬意を抱いています。私は錯覚（illusion）という言葉を軽蔑的な意味では使っていません。AIを純粋に技術的な側面から見れば、人間の思考から生じる意表を突いた結果が、行列の乗算を繰り返すことで模倣可能という事実は実に興味深いことです。
それと同時に、規制を受けていない巨大企業や誇大な宣伝、そして悪意に満ちた権力者たちがこれらAI技術を使って私たちの世界に繰り返し及ぼしている経済・社会への影響によって生じる結果について、私も皆さんと同様に空恐ろしい気持ちを抱いています。
私には、今のAIはいつかはじけるバブルなのかどうかはわかりませんし、AIと社会がどこに向かっているのかを推測するのは控えておくことにします。しかし総じて、AIの未来は明るいものには見えません。
しかし1つだけ、避けがたいとまではいかなくても、少なくとも私の目から見てかなり可能性が高いと思えることがあります。すなわち、LLMや生成AIが、ありとあらゆる「情報関連の仕事」（クリエイティブな仕事、あらゆる「知的財産」の維持や変更、アート、ニュース、プログラミングなど）の現場で起きている変化は、20世紀初頭の第二次産業革命と非常に似通っているということです。
ソフトウェア開発で言えば、巨大な国際企業といえども、つい数年前までそこで行われていた業務は「職人技（craft）」に近いものでした。ここで言うcraftは、技法（art）の同義語ではなく、中世の職人のような感覚で使っています。すなわちギルドや徒弟制度の元で運営される、狭い分野の高度な技術を認定された専門家による手作業であり、個人の力量が最終製品の品質に大きく影響するような職種です。
たとえギルドがやがて巨大な国際企業に膨れ上がり、多くの場面で個人の影響力が「機械の歯車」のように矮小化されたとしても、品質に大きく影響するのは相変わらず個人の力量でした。
しかし今や状況は激変しようとしています。いや、もう激変しつつあります。LLM（大規模言語モデル）は今や、従来は人力に頼っていた情報関連の「生産現場」を「機械化」する役割を担っています。
完璧なアナロジーというものはありませんが、このアナロジーは多くの場面で予測や説明に役立ちます。
たとえば「工業製品は手作りの製品には敵わないのか？」という問いを考えてみましょう。手作り製品が品質面で勝つ可能性は高いかもしれませんが、それでも美しく磨きのかかった丈夫な木製の椅子を1週間かけて1脚生産するより、安手のプラスチック製椅子を1日に100脚生産する方が重宝されるでしょう。
あるいは、従来の「職人（的プログラマー）」の地位はどう変わるでしょうか？架空の工場で、一部の労働者はエンジニアに、残りは低賃金の機械オペレータに回される様子が想像できます。
中には、これまでの職を失わずに済む人もいるでしょう。手作業が求められる職種は、今日の世界にもまだ残されています。手技の粋を尽くして世に2つとない製品を作る仕事や、逆に、近所のおばあちゃんのために壊れたテーブルを応急修理する仕事、今後新しい機材を導入するために研究開発用のプロトタイプを半分手作業で作り上げる仕事などです。しかしこの種の職種への引き合いは今後大幅に減少するでしょう。
念のため申し上げますが、ここで述べているのは明るい未来を約束するような楽観的・進歩的な見方ではありません。20世紀の第二次産業革命は、雇用者と従業員の力関係のバランスが移り変わったこともあって多くの不平等を生み出しました。今回のAI革命では、「あらゆるものごとがやんわりと標的になりうる」ことを考えれば、第二次産業革命よりも悪化する可能性があります。私たちは長年ラッダイト（打ちこわし）運動という言葉を「進歩の素晴らしさを理解できない連中」を見下すときに使ってきました。しかし、そんな私たちの一部（もしかすると大多数）は、遠からずラッダイト運動の意義を身をもって思い知ることになるでしょう。しかも相当厳しい形で。
🔗 2026年に書くかもしれないこと
長々と愚痴を書くのは個人のブログ記事にそぐわないのではと思われそうです（上のセクションは、実は私の「AIについて思うこと」という別のドラフト記事を切り詰めたものです）。しかし、私が情熱を注いで執筆しているプログラミング関連の文章は、激変する状況によって露骨に影響を受けています。
私のアイデアの基本にあるのは、「コードを書くことを文章を書くことと同じように考える」というものです。コードを書く作業を（単語の寄せ集めではなく）統合された1つのフレーズのレベルで考えることで、コードの背後を支える構造の構築方法や、プログラミング言語の使われ方や進化によい影響を与えます。私はこの視点を「明晰なコード（lucid code）」と呼ぶこともあります。
私のこの考え方は、LLMが広まる前ですらなかなか世に受け入れられませんでした。たいていの場合、「やっぱり大事なのはアーキテクチャと高レベルの構造だよね」という結論で終わり、それらを支えているコードの話になると「単なる退屈な詳細」止まりでした。
しかし驚くべきことに、私の「フレーズを重視する」考え方は、複雑なproductionプロジェクトで実地テストにさらされたときに、開発速度やメンテナンス性で俄然メリットを発揮する傾向があるのです。長年かかりましたが、私はこの考え方を以前よりもうまく説明できるようになってきました。
しかし業界を襲うAIという地殻変動によって（もちろん、錯覚でなければですが！）何もかも吹っ飛ぶことになるかもしれません。なお、私の「フレーズを重視する」アプローチは、「LLMのトークン効率を重視する」形に応用することでLLM時代に返り咲けるかもしれません。しかし私は、この視点について非合理的な嫌悪感を覚えます。
そういうわけで、私は当面、今の自分が持つプログラミングの「職人技」に徹するつもりです。同時に、私の生産性を高めてくれる「コードで思考する方法」や、そのための言語・ツール・手法についてもこれまで通り執筆していく所存です。今後も私の記事に読者がついてくれることを、そして変遷著しいIT業界に私の居場所があり続けることを願っています。
おそらく今後執筆する内容は（もし実際に書くなら）、トピックを広げるよりも深掘りに専念することになるでしょう。プログラミング全般に関する私の思想的な見解を述べるよりも、私の経験に基づいた実用的な知見を共有する方に重点を置く所存です。
と言いつつも、実を言うと昨年夏から書き連ねてきた「思想的な」ドラフト記事がほぼ完成しつつあるのですが...おそらく今後数週間のうちに仕上げるかもしれません。
しかしそれが終わったら、私のテスト手法や、いくつもの大規模製品のテストスイートで作業した経験を集約したさまざまな知見についての執筆に専念できればと思っています（私が開発・公開したmoarspecというテストヘルパーライブラリ↓も含めるつもりです）。
それではまた次回にお会いしましょう。次の記事を近いうちに出せればと願っています。
そして、ウクライナへの支援をぜひよろしくお願い致します。
概要
元サイトの許諾を得て翻訳・公開いたします。
日本語タイトルは内容に即したものにしました。