ライブのX投稿

わからない

会場のフィードバックを受けての体感です。個別の説明で恐らく問題なく、しかし全体を通してのパラダイムは、おそらく「よくわからなかった」という感想を持たれた方が一番多かったのではないかと思います。😅

一方、腹落ちした、納得、すっと入ってきたという反応の人も少数いました。この分かれ目がどこにあるのかはわかりません。ただ一つわかっていることがあります。スキルの差ではない。

手札の多い人が「今までのやり方と全然違う」ということで、かえって入ってこないということはあると思います。一方で、同じくらいシニアな人がすっと受け取る。何がそれを分けるのかはわかりませんが、興味深いことだと思います。BEAR.Sundayでもそれはありました。

わからないけど面白い

「わからないけど、考えた｜面白かった｜知りたいと思った」という人も耳にしました。もしそうなら、それはとても嬉しいことです。能動的に自分なりの観点を持って考えてみる、納得できるところもあれば、なるほどとならないところもある。でもそこに40分、自分を乗せた。それは全然いいんじゃないですかね。「脳が疲れた」と書いていた人もいます。

分かれる発表

ある人がこう言ってくれました。「評価が分かれる発表はなかなか聞けるものじゃないから、聞けてよかった」。

カンファレンスの登壇を生で聞くのは、YouTubeで後から観るのとは違います。映画に近い。同じ時間に、同じ場所で、全員が同時に体験する。その中で、すごくわかった人と、何を言っているのか全然わからなかった人が分かれる。

何%がわかったら成功か、という問いはたぶん的を射ていません。どれだけ見ている人に考える時間が生まれたか。脳が疲れたなら、それは動いていたということですよね。聞いてくれた方、お疲れ様でした＆ありがとうございました。

セッション

武田さんの「「接続」—パフォーマンスチューニングの最後の一手 〜点と点を結ぶ、その一瞬のために〜」。自分のテーマを見つけて、測定を丁寧に積み上げて、なぜそれだけコストがかかるのかをリアルな数字で示していく。予測ではなく計測。準備大変だったでしょう。その積み上げが印象に残りました。

菱田さんの「条件分岐に名前をつけていますか」。条件分岐をコードの一部として埋もれさせるのではなく、アプリケーションの中での位を上げていくという話です。条件判断をメソッドの中の名もなき処理にするのではなくて、特別な地位を与える。この点は私の発表ともシンパシーを感じるところです。

武田さんのも菱田さんの時も、トーク途中で壇上からこちらを名指しで触れてくれました。😅

LTはさくらいさんの「AI時代の脳疲れと向き合う「言語学としてのPHP」」が興味深かったです。自分はあまりこのスイッチコストの負担がない方だと思うのですが、観点が良かった。トークも軽妙。

他にも興味深いセッションが沢山ありました。

ARIGATO

スタッフのみなさん、委員長の長谷川さん、お疲れ様でした。

たのしい時間をありがとうございました！

In 2000, Roy T. Fielding submitted his doctoral dissertation to the University of California, Irvine. On the very first page of Chapter 1—the first thing a reader sees—he quoted a Monty Python sketch, The Architects Sketch.

Excuse me... did you say "knives"?
— City Gent #1 (Michael Palin), 'The Architects Sketch' [111]

I didn’t understand this reference for a long time. Why would a REST dissertation open with Monty Python?

The Slaughterhouse Architect

An architect who has only ever designed slaughterhouses is commissioned to design an apartment block. He designs it as a slaughterhouse. He proudly walks the tenants through rooms fitted with rotating knives.

I came to understand this as a warning against applying software architectural approaches without regard for the problem at hand. (Does “microservices” come to mind?)

And right after the sketch, Fielding writes: “design-by-buzzword is a common occurrence.”

I wrote in detail about how REST became a buzzword in a previous article. Trace the history, and a pattern emerges: the original “question” disappears, the name circulates as an empty vessel of authority, the active ingredient is stripped out, an ecosystem is built to compensate for the loss, and the next buzzword arrives to “solve” the problem.

This is not just a REST story. Design-by-buzzword has a pattern that has repeated for over half a century.

The Anatomy of the Pattern

1. It begins with a “question” about a problem.
2. The WHAT of the question becomes the HOW of practice, and spreads.
3. The name becomes a vessel of authority, and degradation—with the core stripped out—advances with conviction.
4. The active ingredient is dropped, and an ecosystem is built to compensate for the loss.
5. The next buzzword “solves” it.

This pattern has repeated for half a century. Sometimes the popularized version creates a “pragmatic vs. dogmatic” frame that seals off any attempt at correction.

OOP

In 1967, Alan Kay encountered Simula, a Norwegian programming language. The seeds of the object concept were there. But what excited Kay wasn’t objects themselves—it was the vision beyond them. Could software be designed as a collection of autonomous cells, like biological cells that function independently yet work together as a whole?

At the heart of Kay’s question was message passing. Just as cells communicate by exchanging chemical signals, objects cooperate by sending messages to each other. Internal state is hidden; from the outside, only messages arrive. Not a separation of data and procedures, but designing systems as communication networks of autonomous agents—that was what Smalltalk set out to achieve.

But as “object-oriented” spread, message passing disappeared. Classes and inheritance were promoted to “the three pillars of OOP,” and three words—encapsulation, inheritance, polymorphism—lined up in textbooks. The concept Kay valued most became the most overlooked premise.

What happened as a result? Deep inheritance hierarchies, god classes, tight coupling. Frustration accumulated that “OOP is too complex,” and functional programming gained attention as an alternative where those problems didn’t arise. But the communication network of autonomous agents that Kay had tried to build in Smalltalk was reinvented as the actor model in the functional context. Erlang in 1986, Akka in 2009. What Kay had intentionally placed at the center was reimplemented under a different name.

Kay wrote in a 1998 email:

“I’m sorry that I long ago coined the term ‘objects’ for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.”

Remember the structure of this statement. It will come up again.

MVC

In 1978, Trygve Reenskaug was visiting Xerox PARC. The question he was grappling with was simple: “How do you translate the worldview inside a user’s head into code?”

When users interact with an application, they carry their own mental model. An accountant using a spreadsheet has a world of cells and formulas in their head. How well that mental model matches the system determines usability. Reenskaug defined Model as the user’s mental model itself. Controller was the translator between user and system. View was its representation.

The division into three components was not for organizing code. It was a structure designed to answer the question: “How do we faithfully capture the user’s worldview?”

But as MVC spread through the web, the question disappeared. It became a classification problem: “Which of three layers does this code go in?” Model became the place for database access, Controller became the place for handling HTTP requests, View became the place for outputting HTML. The concept of the user’s mental model vanished from every textbook.

The Fat Controller debate and the Fat Model debate began. Different frameworks gave different answers to “where should logic go?” Web MVC and GUI MVC were different things called by the same name, and MVP, MVVM, and MVI emerged from entirely different contexts. Only the name was shared; the substance was different.

The question Reenskaug asked—”Are we capturing the user’s mental model?”—no one cares about anymore. Twenty-five years later, Evans would pose the same question from a different angle.

DDD

In 2003, Eric Evans published “Domain-Driven Design.” A thick book of 550 pages. It contained two kinds of patterns: tactical patterns like Entity, ValueObject, Repository, and Aggregate; and strategic patterns centered on Ubiquitous Language and Bounded Context. What Evans truly wanted to convey was the latter.

Evans’s question was: “How do you accurately translate complex domain logic into software?” The core of his answer lay in developers and domain experts speaking the same language (Ubiquitous Language) and consciously drawing boundaries around models (Bounded Context). Repository was merely an implementation tool.

But as DDD spread, the strategic patterns disappeared. Tactical patterns were concrete and easy to turn into code. Strategic patterns were abstract and highly context-dependent. “Adopting DDD” became creating Entity classes and Repository classes.

With the thinking of drawing boundaries through Bounded Context stripped away, systems without boundaries proliferated. Frustration accumulated: “DDD just adds more code,” “It’s over-engineering.”

Evans later said: “I should have made strategic design more prominent.” The microservices story demonstrates this.

Agile

In February 2001, seventeen people gathered at a ski resort in Snowbird. What they shared was a single anger: “Waterfall, unable to respond to change, is preventing us from delivering working software.” Two days of discussion produced the “Manifesto for Agile Software Development”—four values and twelve principles.

The first value reads: “Individuals and interactions over processes and tools.”

The manifesto was over-compressed. Published in the extremely short form of four values and twelve principles, what circulated was not a copy of a copy but the copy itself. The Scrum framework became its vessel. Sprints, daily standups, burndown charts—the rituals became “Agile.”

“Individuals and interactions over processes and tools” was implemented by process.

The industrialization was faster and bigger than REST or DDD. The profession of “Agile Coach” was born. SAFe (Scaled Agile Framework)—a heavyweight process that Agile was supposed to reject—was sold as “Enterprise Agile.” A mechanism for coaching critics as “not understanding Agile” was built into the ecosystem. The more you try to correct, the stronger the fundamentalist label grows.

Signatory Dave Thomas wrote on his blog in 2014: “Agile is Dead (Long Live Agility)”—”Stop using the word Agile as a noun.” Nouns can be sold. Certified. Consulted. Adjectives cannot.

What Thomas offered instead wasn’t even a manifesto. “Figure out where you are. Take a small step towards your goal. Adjust your understanding based on what you learned. Repeat.” A mere epistemological attitude.

CQRS

Greg Young emerged from the DDD community. His starting point was a simple observation: the optimal model differs between reads and writes.

Writes need complex models to protect domain integrity. Reads want denormalized, flat data for screen display. Trying to satisfy both with the same model creates strain. Just separate them—that was all there was to it.

The moment the name “Command Query Responsibility Segregation” was attached, misunderstanding began. Command is business decision-making; Query is structure for display. These were the two things Young wanted to separate. But it was read as “an architecture that physically separates commands and queries.” Separate the databases. Separate the infrastructure. Young kept saying “it’s simply the creation of two objects where there was previously only one.” The same trajectory as Fielding.

Then Event Sourcing was bound to it by equation. “If you’re doing CQRS, you need Event Sourcing.” Young himself stated clearly that CQRS and Event Sourcing were independent concepts, but it didn’t reach anyone.

Adopting CQRS required Event Sourcing, which required distributed messaging, which required the Saga pattern. A chain where each misuse demands the next. At each stage, people are “working hard,” so there’s no room to verify whether they’re actually answering the original question.

“CQRS is too complex,” the criticism went. But most of that complexity came not from CQRS itself but from unnecessary coupling. Complexity born from misuse became criticism of the concept itself.

Young kept saying: “Most systems don’t need Event Sourcing.”

Microservices

In the 2000s, Amazon and Netflix faced different crises. Amazon had a monolith constraining development speed; Netflix experienced total service outage from a data center failure. But what they were grappling with was an organizational design question before it was a technical one: “How do we create a structure where teams can decide independently and deploy independently?”

Amazon’s “two-pizza rule” was about team size. Netflix’s “Chaos Monkey” was about embedding resilience into the organization. Service decomposition was a means, not an end.

But as the name “microservices” spread, the organizational design question disappeared. It became an architectural pattern: “split services small.” Companies launched “microservices migration projects” that split systems without changing organizations.

Services were split, but boundaries were arbitrary. With the question of Bounded Context dropped, Service A knew the internal implementation of Service B. Deploys were supposed to be independent, yet changing one broke others. Tight coupling over the network—a “Distributed Monolith” emerged. The worst of both worlds: the complexity of a monolith and the operational cost of microservices.

The “solution” that appeared was “Modular Monolith.” A monolith with proper boundaries—the importance of boundaries was something Evans had already written about in 2003.

After twenty years and one massive failure, we returned to the starting point.

Martin Fowler wrote his microservices article in 2014, then wrote “Microservice Prerequisites” in 2015. If the organization isn’t ready, microservices produce worse results than a monolith. It was too late.

DevOps

In 2008, Patrick Debois and Andrew Shafer were talking in the hallway at an Agile conference. What they faced wasn’t a technical problem. It was an organizational fracture: “The development team ships it, and the operations team receives it broken.” Tearing down that wall was the question.

A name that simply joined “Dev” and “Ops” could be applied to everything in software development and operations. Like REST and Agile, its coverage area was maximal.

But the question of organizational culture transformation disappeared. CI/CD pipelines, Kubernetes, Infrastructure as Code—adopting toolchains became “adopting DevOps.”

The structure of industrialization differed from Agile. Agile’s industrialization was driven by consultants and training; DevOps was driven by cloud vendors. AWS defined DevOps, Azure certified DevOps, GCP sold DevOps. The equation “DevOps requires this tool” translated directly to revenue. When the entity driving industrialization has built the concept’s misuse into its business model, correction becomes nearly impossible. Fielding can push back on a blog, but you can’t push back against an AWS whitepaper.

The supreme irony: a concept meant to dissolve the fracture between Dev and Ops spawned Platform Engineering teams—a new silo. A fracture created to resolve a fracture.

Long Shot: Comedy

Tragedy and comedy coexist. An individual developer wrestling with Event Sourcing schema migrations is, in close-up, a tragedy. Pull back, and it’s a comedy: “someone is implementing with full effort what Greg Young kept saying wasn’t necessary.”

The organization that implemented “individuals and interactions over processes” by process. DevOps, which created a new fracture to resolve a fracture. Microservices, which took twenty years to reinvent Bounded Context. In close-up, tragedy. In long shot, comedy.

Fielding Knew

Remember the slaughterhouse architect from the opening.

Every case we’ve read fits into that single line. Dropping Kay’s message passing and taking classes and inheritance. Dropping Reenskaug’s mental model and taking three-layer separation. Dropping Evans’s strategic design and taking tactical patterns. The industry became the slaughterhouse architect, designing slaughterhouses under a different name each time.

Fielding placed this warning before the body of his dissertation. The very first thing you see. And readers read the warning and misused the dissertation exactly as warned.

Do you remember the structure of Kay’s statement? The lament that “a word I coined spread with a meaning I never intended.” Evans, Thomas, Young, Fowler—they all made statements with the same structure. Originators trying to correct the misuse of their own concepts, unable to reach anyone.

Fielding was no different. In 2021, he wrote in a tweet thread—with the caveat that it might be the vaccine booster side effects talking:

When will people realize that the reason they are paid, the reason they are respected for good work, is because they can use their own minds to fill in the details appropriate to the context of their own systems.

That caveat is heartbreaking.

Those who can understand a warning never needed it in the first place. Those who need the warning cannot understand it.

Fielding wrote a warning at the very beginning of his REST dissertation. That warning—REST—became the greatest source of misuse. He watched it for twenty-five years.

Why Nothing Changes

399 BC, Athens.

In the democracy, rhetorical ability was directly tied to power. Meeting that demand were the Sophists—professional rhetoricians who taught “the art of arguing any position persuasively” in exchange for payment. Socrates kept asking: “What is the question that this answer is answering?” His dialogues, which led young people to realize “I know nothing,” were seen as threatening to the established order. He was executed for “impiety and corrupting the youth.” Meanwhile, the Sophists’ techniques—which carried his voice—were systematized and passed down to posterity. The power of those who transmit is stronger than those who pose the questions. People listen to those who sell the how, not those who posed the what.

The industry is waiting for the next buzzword.

References

• Roy T. Fielding, “Architectural Styles and the Design of Network-based Software Architectures”, Chapter 1
• The Architects Sketch - Monty Python’s Flying Circus
• Manifesto for Agile Software Development
• Two Worldviews on CQRS (Japanese)
• Roy Fielding, Twitter thread, 2021

The Laments of the Originators

• OOP: Alan Kay, 1998: “The big idea is messaging” — “I’m sorry that I long ago coined the term ‘objects’…”
• DDD: Eric Evans, 2009: “What I’ve Learned about DDD since the Book” — “Why did I put Context Mapping in Chapter 14?”
• Agile: Dave Thomas, 2014: “Agile is Dead (Long Live Agility)” — “Stop using the word Agile as a noun”
• Microservices: Martin Fowler, 2015: “Microservice Prerequisites” — “you must be this tall to use microservices”
• REST: Roy Fielding, 2008: “REST APIs must be hypertext-driven” — “I am getting frustrated…”

2000年、Roy T. Fieldingはカリフォルニア大学アーバイン校に博士論文を提出しました。RESTの原典となったこの論文の第1章、読者が最初に目にするページに、Monty Pythonの『建築家のスケッチ』が引用されています。

すみません…「ナイフ」と言いましたか？
— シティ・ジェント #1 (マイケル・パーリン), 『建築家のスケッチ』 [111]

私は以前、この引用の意味が分かりませんでした。なぜREST論文の序章がMonty Pythonのコメディではじまるのか？

屠殺場の建築家

屠殺場しか設計したことのない建築家が、集合住宅の設計を依頼される。彼は集合住宅を屠殺場として設計してしまう。入居者が回転ナイフで切り刻まれる部屋を案内しながら、建築家は誇らしげです。

これは「屠殺場しか設計したことのない建築家に集合住宅の設計を依頼する」——つまり対象を無視したソフトウエア建築手法の適用への戒めなんだと理解しました。（マイクロサービスが頭に浮かびます？）

そしてFieldingはこのコントの直後にこうも書いています。”design-by-buzzword is a common occurrence.”（バズワードによる設計はよくあることだ）

RESTがどのようにバズワード化したかは、別の記事で詳しく書きました。追うと、一つのパターンが浮かび上がります。原典の「問い」が消え、名前だけが権威の器として流通し、有効成分が抜かれ、その欠損を補うエコシステムが積み上がり、次のバズワードが「超えた」として登場する。

これはRESTだけの話ではありません。design-by-buzzword には半世紀以上繰り返されたパターンがあります。

パターンの骨格

1. 問題の「問い」から始まる。
2. 問いのWHATが実践のHOWになり普及する。
3. その時、名前が権威の器になり、核心の落ちた劣化が確信とともに進む。
4. 有効成分を落として、その欠損を補うエコシステムを積み上げる。
5. 次のバズワードで「解決」する。

このパターンは、半世紀にわたって繰り返されています。時に普及版が「実用的 vs 教条的」という枠を作り、修正の試み自体が封じられることもあります。

OOP

1967年、Alan KayはSimulaというノルウェー製言語に出会いました。オブジェクトという概念の萌芽がそこにありました。しかしKayが興奮したのはオブジェクトそのものではなく、その先に見えたビジョンでした。生物の細胞が独立して動きながら全体として機能するように、ソフトウェアも自律的なセルの集合として設計できるのではないか。

Kayの問いの核心はメッセージパッシングでした。細胞が化学物質を交換して通信するように、オブジェクトもメッセージを送り合うことで協調する。内部状態は隠蔽され、外部からはメッセージしか届かない。データと手続きの分離ではなく、自律的なエージェントの通信ネットワークとしてシステムを設計する——それがSmalltalkで実現しようとしたものでした。

しかし「オブジェクト指向」という言葉が広まる過程で、メッセージパッシングは消えました。クラスと継承が「OOPの三大原則」に昇格し、カプセル化、継承、ポリモーフィズムという三つの言葉が教科書に並びました。Kayが最も重視した概念が、最も読み飛ばされる前提になりました。

結果として何が起きたか。継承の深いヒエラルキー、神クラス、密結合。「OOPは複雑になる」という不満が蓄積し、関数型プログラミングがその問題が起こらない選択肢として注目されました。しかしKayがSmalltalkで実現しようとした自律的なエージェントの通信ネットワークは、関数型の文脈でアクターモデルとして再発明されました。Erlangが1986年に、Akkaが2009年に。Kayが意図的に中心に置いたものが別の名前で再実装されました。

Kayは1998年のメールで書いています。

“I’m sorry that I long ago coined the term ‘objects’ for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.”

「『オブジェクト』という用語を作ったことを後悔している。多くの人が些末なアイデアに注目してしまった。本当に大きなアイデアはメッセージングだった」

この発言の構造を覚えておいてください。後でまた出てきます。

MVC

1978年、Trygve ReenskaugはXerox PARCに滞在していました。そこで彼が向き合っていた問いはシンプルでした。「ユーザーの頭の中にある世界観を、どうコードに写し取るか」。

ユーザーはアプリケーションを使うとき、自分なりのメンタルモデルを持っています。スプレッドシートを使う会計士は、セルと数式の世界を頭の中に持っています。そのメンタルモデルとシステムがどれだけ一致しているかが、使いやすさを決めます。ReenskaugはModelをそのユーザーのメンタルモデルそのものとして定義しました。Controllerはユーザーとシステムの翻訳者。Viewはその表現。

三つのコンポーネントへの分割は、コードの整理のためではありませんでした。「ユーザーの世界観を正確に写し取る」という問いに答えるための構造でした。

しかしWebでMVCが広まる過程で、この問いは消えました。「コードをどの三つのレイヤーに分けるか」という分類問題になりました。ModelはDBアクセスの場所になり、ControllerはHTTPリクエストを処理する場所になり、ViewはHTMLを出力する場所になりました。ユーザーのメンタルモデルという概念は、どの書籍にも出てこなくなりました。

Fat Controller論争とFat Model論争が始まりました。「ロジックをどこに書くべきか」という問いに、フレームワークごとに違う答えが生まれました。WebのMVCとGUIのMVCが別物なのに同じ名前で呼ばれ、MVPとMVVMとMVIが別の文脈から登場した。名前だけが共有され、中身は別物でした。

Reenskaugが問うた「ユーザーのメンタルモデルを写せているか」は、今は誰も気にしてません。25年後、Evansが別の角度から同じ問いを立てることになります。

DDD

2003年、Eric Evansは「Domain-Driven Design」を出版しました。550ページの厚い本でした。その本には二種類のパターンが書かれていました。EntityやValueObject、Repository、Aggregateといった戦術的パターン。そしてUbiquitous LanguageとBounded Contextを中心とした戦略的パターン。Evansが本当に伝えたかったのは後者でした。

Evansの問いは「複雑なドメインロジックをソフトウェアに正確に写し取るにはどうするか」でした。その答えの核心は、開発者とドメイン専門家が同じ言語で話すこと（Ubiquitous Language）と、モデルの境界を意識的に引くこと（Bounded Context）にありました。Repositoryは実装の道具にすぎませんでした。

しかしDDDが広まる過程で、戦略的パターンは消えました。戦術的パターンは具体的でコードに落としやすい。戦略的パターンは抽象的で文脈依存度が高い。「DDDを導入する」がEntityクラスとRepositoryクラスを作ることになりました。

Bounded Contextという境界を引く思考が落ちた結果、境界のないシステムが量産されました。「DDDはコードが増えるだけ」「オーバーエンジニアリングだ」という不満が蓄積しました。

Evansは後に語っています。「戦略的設計を前面に出すべきだった」。この後悔が正しかったことは、マイクロサービスの事例で示されます。

Agile

2001年2月、スノーバードのスキーリゾートに17人が集まりました。彼らが共有していたのは一つの怒りでした。「変化に対応できないウォーターフォールが、動くソフトウェアを届けることを妨げている」。二日間の議論の末に生まれたのが「アジャイルソフトウェア開発宣言」、4つの価値と12の原則でした。

マニフェストの最初の価値はこう書かれています。「プロセスやツールよりも個人と対話を」。

マニフェストは圧縮されすぎていました。4つの価値と12の原則という極度に短い形式で公開されたため、コピーのコピーではなくコピーそのものが流通しました。スクラムというフレームワークがその器になりました。スプリント、デイリースタンドアップ、バーンダウンチャート——儀式が「アジャイル」になりました。

「プロセスよりも個人と対話を」が、プロセスで実装されました。

産業化はRESTやDDDより速く、より大きかった。「アジャイルコーチ」という職業が生まれ、SAFe（Scaled Agile Framework）という、アジャイルが否定したはずの重厚なプロセスが「エンタープライズアジャイル」として売られました。批判者を「アジャイルを理解していない」とコーチする機構がエコシステムに組み込まれた。修正しようとするほど、原理主義者のラベルが強まります。

署名者の一人Dave Thomasは2014年のブログで書きました。”Agile is Dead (Long Live Agility)”——「Agile（名詞）を捨てて、agile（形容詞）に戻れ」。名詞は売れます。認定できます。コンサルできます。形容詞は売れない。

Thomasが代わりに提示したものは、マニフェストですらありませんでした。「今どこにいるかを把握し、目標に向けて小さな一歩を踏み出し、学んだことで理解を修正し、繰り返す」。単なる認識論的な態度でした。

CQRS

Greg YoungはDDDコミュニティの中から出てきました。彼の出発点はシンプルな観察でした。読み取りと書き込みで、最適なモデルが違う。

書き込みはドメインの整合性を守るために複雑なモデルが必要です。読み取りは画面表示のために非正規化されたフラットなデータが欲しい。同じモデルで両方を満たそうとするから無理が生じる。分離すればいい——それだけのことでした。

「Command Query Responsibility Segregation」という名前がついた瞬間に、誤解が始まりました。Commandは業務の意思決定であり、Queryは表示のための構造です。Youngが分けたかったのはこの二つでした。しかし「コマンドとクエリを物理的に分離するアーキテクチャ」として読まれた。データベースを分ける。インフラを分ける。Young本人が「単なるモデルの分離であって、データベースを分けることではない」と何度も言い続けました。Fieldingと同じ軌跡でした。

さらに、Event Sourcingが等式で結びつけられました。「CQRSをやるならEvent Sourcing」。Young自身はCQRSとEvent Sourcingは独立した概念だと明言していましたが、届きませんでした。

CQRSを導入するとEvent Sourcingが必要になり、Event Sourcingを導入すると分散メッセージングが必要になり、それを導入するとSagaパターンが必要になった。前の誤用が次の誤用を要請する連鎖です。各段階で「一生懸命やっている」から、問いに答えているかどうかを検証する余裕がない。

「CQRSは複雑すぎる」という批判が出ました。しかしその複雑さの多くはCQRS本体ではなく、不要な結合から来ていた。誤用が生んだ複雑さが、概念本体への批判になりました。

Youngは言い続けました。「ほとんどのシステムにEvent Sourcingは要らない」。

マイクロサービス

2000年代、AmazonとNetflixはそれぞれ異なる危機に直面していました。Amazonはモノリスが開発速度を制約する問題、Netflixはデータセンター障害でサービスが全停止する問題。しかし彼らが向き合っていたのは、技術の問いである前に組織設計の問いでした。「チームが独立して判断し、独立してデプロイできる構造をどう作るか」。

Amazonの「2ピザルール」はチームサイズの話であり、Netflixの「Chaos Monkey」は障害への耐性を組織に埋め込む話でした。サービスの分割は手段であって、目的ではなかった。

しかし「マイクロサービス」という名前が広まる過程で、組織設計の問いは消えました。「サービスを小さく分割する」アーキテクチャパターンになりました。組織を変えずにシステムだけ分割する「マイクロサービス移行プロジェクト」が各社で始まりました。

サービスは分割されましたが、境界は恣意的でした。Bounded Contextという問いが落ちたまま分割したから、AサービスがBサービスの内部実装を知っている。デプロイは独立しているはずなのに、一つを変えると他が壊れる。ネットワーク越しの密結合——「Distributed Monolith（分散モノリス）」ができました。モノリスの複雑さとマイクロサービスの運用コストを両方引き受ける最悪の状態でした。

「解決策」として登場したのが「モジュラーモノリス」でした。適切な境界を持つモノリス——境界の重要性は、Evansが2003年に既に書いていたことでした。

20年と一度の巨大な失敗を経て、出発点に戻った。

Martin Fowlerは2014年にマイクロサービスの記事を書いた後、2015年に「マイクロサービスの前提条件」を書きました。組織が準備できていないなら、マイクロサービスはモノリスより悪い結果をもたらす。手遅れでした。

DevOps

2008年、Patrick DeboisとAndrew Shaferはアジャイルカンファレンスの廊下で話していました。向き合っていたのは技術の問題ではない。「開発チームがリリースしたものを、運用チームが壊れたまま受け取る」という組織の断絶でした。壁を壊すことが問いでした。

「Dev」と「Ops」を結合しただけの名前は、ソフトウェア開発と運用のすべてに貼れました。RESTやアジャイルと同じく、覆える面積が最大級でした。

しかし組織文化の変革という問いは消えました。CI/CDパイプライン、Kubernetes、Infrastructure as Code——ツールチェーンの導入が「DevOpsを導入する」になりました。

産業化の構造がアジャイルとは違いました。アジャイルの産業化はコンサルと研修が主体でしたが、DevOpsはクラウドベンダーが担った。AWSがDevOpsを定義し、AzureがDevOpsを認定し、GCPがDevOpsを売りました。「DevOpsにはこのツールが必要」という等式は直接売上に繋がる。概念の誤用をビジネスモデルに組み込んだ主体が産業化を担うと、修正はほぼ不可能です。Fieldingがブログで反論できても、AWSのホワイトペーパーには反論できない。

最大の皮肉はここにあります。DevとOpsの断絶を解消するための概念が、Platform Engineeringチームという新しいサイロを生んだ。断絶を解消するための、断絶が作られました。

ロングショットで見れば喜劇

悲劇と喜劇が同居しています。個々の開発者がイベントソーシングのスキーママイグレーションと格闘している姿は、クローズアップで見れば悲劇ですが、引いて見れば「Greg Youngが要らないと言い続けたものを全力で実装している」喜劇です。

「プロセスよりも個人と対話を」をプロセスで実装した組織も、断絶を解消するために新しい断絶を作ったDevOpsも、20年かけてBounded Contextを再発明したマイクロサービスも。クローズアップでは悲劇、ロングショットでは喜劇。

Fieldingは知っていた

冒頭の屠殺場の建築家を思い出してください。

ここまで読んできた事例は、すべてあの一文に収まります。Kayのメッセージパッシングを落としてクラスと継承を取ったのも、Reenskaugのメンタルモデルを落として三層分割を取ったのも、Evansの戦略的設計を落として戦術的パターンを取ったのも。業界は屠殺場の建築家となり、毎回違う名前で屠殺場を設計していた。

Fieldingはこの警告を、論文の本文より前に置きました。最初に目に入る場所です。そして読者はその警告を読んで、警告の通りに論文を誤用した。

Kayの発言の構造を覚えていますか。「自分が名づけた言葉が、自分の意図と違う意味で広まった」という嘆き。Evansも、Thomasも、Youngも、Fowlerも、同じ構造の発言をしていました。創始者が自分の概念の誤用を訂正しようとして、届かない。

Fieldingも同じでした。2021年、彼はツイートスレッドにこう書きました。ワクチンブースターの副反応のせいかもしれないと留保しながら。

When will people realize that the reason they are paid, the reason they are respected for good work, is because they can use their own minds to fill in the details appropriate to the context of their own systems.

「自分が対価を得ている理由、優れた仕事で尊敬されている理由は、自分の頭を使って自分のシステムの文脈に合わせた詳細を埋めていける能力があるからだということに、いつになったら気づくのだろう」

その留保が切ない。

警告を理解できる人間は最初から警告を必要としない。警告を必要とする人間は警告を理解できない。

FieldingはREST論文の最初に警告を書いた。その警告、RESTは最大の誤用の源になった。彼は25年間、それを眺め続けた。

なぜ変わらないのか

紀元前399年、アテネ。

民主政で弁論能力は権力に直結しました。その需要に応えたのがソフィスト——「どんな主張でも説得力を持って論じる技術」を報酬と引き換えに教えるプロの弁論家たちです。ソクラテスは「その答えが答えている問いは何か」を問い続けました。若者たちに「自分は何も知らない」と気づかせる対話は、秩序を脅かすと見なされ「神々を敬わず若者を堕落させた」として処刑されました。一方、その声を伝えたソフィストの技術は体系化されて後世に伝わりました。伝える者の力は、問いを発する者より強い。人はwhatを立てた人より、howを売る人の声を聞く。

業界は次のバズワードを待っています。

参照

• Roy T. Fielding, “Architectural Styles and the Design of Network-based Software Architectures”, Chapter 1
• 建築家のスケッチ - Monty Python’s Flying Circus
• アジャイルソフトウェア開発宣言
• CQRSをめぐる二つの世界観
• Roy Fielding, Twitter thread, 2021

創始者たちの嘆き

• OOP: Alan Kay, 1998: “The big idea is messaging” — “I’m sorry that I long ago coined the term ‘objects’…”
• DDD: Eric Evans, 2009: “What I’ve Learned about DDD since the Book” — “Why did I put Context Mapping in Chapter 14?”
• Agile: Dave Thomas, 2014: “Agile is Dead (Long Live Agility)” — “Stop using the word Agile as a noun”
• Microservices: Martin Fowler, 2015: “Microservice Prerequisites” — “you must be this tall to use microservices”
• REST: Roy Fielding, 2008: “REST APIs must be hypertext-driven” — “I am getting frustrated…”

PHPerKaigi 2026で「存在論的プログラミング：時間と存在を記述する」という40分のレギュラートークをしました。存在論的プログラミングという、聞いたことのないパラダイムを33枚のスライドで伝えるために、スライドの設計そのものにかなりの時間を費やしました。この記事では、その設計プロセスで得た知見を共有します。会場でいただいたフィードバックをもとに、プレゼン後に深掘りした考えも加えています。

そもそも難しいことをしようとしている

このプレゼンは相当に難しいことをしようとしていることはわかってました。

40分で新しいプログラミングパラダイムを伝える。パラダイムを実装したフレームワークの使い方の説明を伝えるのではなく、説明を通じて「新しい認知」を届けないといけない。

ものの見方そのものを変えようという話です。これが相手が数人で、顔を見ながら理解を確認して質疑を交えながら進めるのならいいのですが、40分一方的に壇上から伝えないといけない。

伝わらない部分があるのは受け入れることにしました。内容を歪めて「全員が分かる」事を目指すのも良くないと思っていました。分からないところがいくつもあっても、いくつかのフレーズや考え方が心に残ればそれでいいのではないかという割り切りをしました。

そんなにスムーズにいくものじゃない。手続き型だけの時代にオブジェクト指向を聞いた人たちも、最初は「なんだこれ」と思ったはずです。私自身もそうでした。

視点を丸ごと変える

このプレゼンが求めているのは、視点の転換そのものです。

冒頭で天動説を出しました。空を見上げれば太陽が動いてます。観察したままに考えれば、天体が動いているのは当たり前です。それが覆った——地球の方が回っていた。しかし直感には反します。

トリアージでそれを試みました。普通に見れば、医者が患者を処理しています。プログラムはデータベースからデータを取ってきて、変換して、保存してます。それが自然な観察です。

しかしここでの提案は、そうではなくて、患者自身が変容しているという見方です。患者が体温と心拍という内在（自分の性質）を持って到着し、トリアージプロトコルという超越（判定方法）と出会い、自らEmergencyCase（救急）やObservationCase（経過観察）になっていく。同じように、エンティティがデータベースの力と出会って、外部データを自分に取り込んで変容する。なりたい自分、なるべき自分になっていく。在ることは成ること。

これは視点を丸ごと変えることです。自然に見るとそうは見えない。特定の視点を持ち込んで物事を違った視点で見る。世界地図を逆さにして南を上にしてみてください。同じ地球なのに、まったく違う世界に見えます。データは同じ、視点が違うだけです。

答えではなく、問い

ここが大事なことですが、焦点を当てるべきは答え、ソリューションではありません。問いそのものです。聴衆がトークを聴いて、これを「採用」したら何が美味しいの？という態度になったとしたらそれはプレゼン失敗です。このパラダイムは積み重なるべきものです。今までのものを投げ捨てる必要はないし「採用」かどうかの話じゃない。

利点の列挙にしてしまうとわかりやすいかもしれませんが、しかし40分後に聴衆の認知は変わらないと思いました。Visionを語ってるのに、実装の良し悪しをジャッジするような態度にもなってほしくなかった。

発見型への転換

聴衆に何かをpushするのではなく、聴衆からpullするためにはどのように構成すればいいのかと考えました。

スライドで要点をリストアップすると押しつけになります。語りなら受け取り方に余白が残ります。スライドを読ますのではなく、スライドを見て耳で語りを聞けば聴衆のまとめる力を引き出すのではないかと考えました。

原則：スライドには書かない。語りで伝える。

この原則を全体に貫くことにしました。

$userって何？

新しいものの見方に向かわせるために、従来の見方に「亀裂」を入れる必要がありました。このスライドです。

$user = new User('Alice');
$user->delete();
// ここの$userって何を表してるの？
echo $user->getName();  // 幽霊に名前聞いてる？

聴衆に問います。deleteの後、$userは何を表していますか？ getNameは何を返すべきですか？ Aliceですか？ nullですか？——どちらも納得いかない。答えがない。

さっきまでおかしいと思わなかったのに急におかしく見える。それが認知が変わったということです。スライドが答えを言ったのではありません。聴衆が自分で気づいた。これが発見型の核心です。聴衆がpullしたということです。

波の設計

33枚のスライドを波として設計しました。

冒頭4枚は穏やかに。パラダイムの定義、プログラミング史、世界認知の拡張——聴衆の認知を準備します。テンポよく進めます。

第1層「亀裂」（2枚）で認知を揺さぶります。Alice/delete/getNameで「あれ？」と思わせ、AmazonのUserクラスの23メソッドで「OOPは手続きの束だった」と追い打ちをかけます。問題はクラスがGodなことでなく、手続きの束だったことですが、説明はGodクラスで留めます。「手続きの束じゃん！」をpullして欲しいのです。

第2層「WHETHER?」（2枚）で新しい問いを立てます。HOW→WHAT→WHETHER。ここは簡潔に。

第3層「見え始めるもの」（12枚）が最も密度が高いところです。意味変数、$being、$been、内在と超越——概念を積み上げます。ただし各スライドはコードと1行だけなので詰まりません。

ピークはスライド25「複雑な世界も同じ構造」。EC注文フローの分岐図です。7段階の変容と分岐が1枚に収まっています。どこを切り取っても同じ構造——内在が超越と出会って新しい内在になる。とても単純。

聴衆に考えてもらう。「これ普段のアーキテクチャでどう表現しますか？」それ、こんな風にグチャグチャなコードになってしまいますよね、とか実例を見せない。それぞれの聴衆が、かつて目にしたスパゲッティコードを思い出してくれるのがいいです。

アーキテクチャがドキュメンテーションになりますが、これもドキュメンテーションの自動化を目指して得られたものではありません。

ピークの直後にスライド26。

$becoming = new Becoming($injector);
$final = $becoming(new OrderInput($items, $customer, $payment));

複雑な構成がこの1行で動きます。落差が効くと思いました。制御をするものはいなく、最初の入力が作った谷（Beingクラス群）に流れていきます。

ピーク後は新しいことを言いません。 聴衆はもう理解しています。波が自然に引いていく。対比表、哲学者の収束表、テッド・ネルソンの引用、そして $being の一語で閉じます。

最後の$beingの背景が黒いのはタイトルの黒背景に対するサンドイッチ構造です。「Be, Don’t do」にラストの$beingが答えます。$beingはパラダイムのコアコンセプトと同時に、このプレゼンや自身にも重ねて、全ての存在に適用できるコンセプトなんだと暗に語ります。

アイスブレイクでの「宇宙創生？」の伏線回収を考えていましたが止めました。ネルソン少年の洞察が美しすぎた。最後に「新しい視点で、新しいソフトウエアの宇宙を創造しましょう」…とかないですね。

「答えではなく、問い」のプレゼンテーションを問いで終えることにしました。どういう存在になりたいか、ある意味究極の問いです。BE = Being is Everything. 存在が全てであるなら、その問いは自分自身にも、ソフトウエアでも全てに適用されるはずです。

"The world is a system of ever-changing relationships and structures." — テッド・ネルソン

哲学者は「証人」

プレゼンには8人の哲学者が登場します。スピノザ、アリストテレス、ヘラクレイトス、荘子、老子、フッサール、ハイデガー、そして仏教の論師たち。

これは権威づけではありません。パターンが先に生まれ、哲学的な類似性は後から見えてきました。プログラマが発見した構造を、別の時代・別の言語で同じ場所に辿り着いた人々として紹介しています。

各スライドに散りばめたエピグラフが、終盤の収束表で一覧になります。「別々に出てきた人たちが全部同じことを言っていた」——この収束自体が発見型の構造です。

自分が好きなのは言霊です。言葉そのものが力を持ち、存在をより深く規定するならば(Q&Aにも出てきたように)そこの労力が必要になってもそれは、その労力に見合うのではないでしょうか。

スライドと語りの分業

最終的に確立した分業のルールです。

• スライドに載せるもの: コード、問い、引用、図を最小限に。
• 口頭で語るもの: 個人的な経験、比喩、問いかけ、概念の橋渡し。

例えば「万物流転」のスライドには「卵→幼虫→さなぎ→蝶」とヘラクレイトスの引用だけがあります。「川が流れている」と「流れているのが川だ」の対比——Doing vs Beingの本質——は口頭で語ります。テキストで読ませると説明になりますが、語りなら体験になります。

荘子の魚の話も同じです。スライドには「あなたは私ではない。どうして私が魚の気持ちを知らないと分かるのか？」の一文だけ。エピソードの全体——橋の上で「魚は楽しそうだ」「お前は魚じゃないのに」「お前こそ私じゃない」——は口頭で語ります。聴衆の目にこの一文がある状態で、声でエピソードを重ねます。

説明されると受け身になります。自分で発見すると、好奇心が動き出します。

Empty your cup

プレゼンの冒頭で「一旦頭を空っぽにして、可能性だけに目を向けて聞いてください」と前置きしました。ブルース・リーの言葉に “Empty your cup so that it may be filled” というものがあります。コップを空にしなければ新しいものは入らない。Unlearningです。

ただし、Unlearningは今まで学んだことを捨てろという意味ではありません。既存の知識や経験はそのまま残ります。問題が解けたときに、その解き方が自分のアイデンティティになってしまうこと——思考が凝り固まって、他の視点が見えなくなることが問題なんです。

これは批判を封じるためのものでもありません。新しいアイデアはとても脆弱なものです。まだ批評に耐えるベースにすら載っていないという自覚もあります。しかし、できないことに注目すると議論が止まる。「今までこれでできていたのに？」——その問いは正当ですが、そこに留まると前に進めません。カーネマンの損失回避バイアスです。新しい可能性と既存の手法を手放す痛みは非対称で、痛みの方が大きく見えてしまう。

「なんとかのパラダイムに近いよね」と既存の概念でラベリングしてしまうことも起きます。自分の知っている枠に収めると安心するんですが、そうすると既存の延長でしか考えられなくなります。知っていることが理解をブロックする。新しい可能性に対しての窓が閉じてしまう。

新しいものはいつも居心地が悪いものです。疫学がない時代のワクチン、地球は丸いという主張、CLIからGUIへの移行——全部、既存の枠の中にいると奇妙に見えます。慣れた手札をたくさん持っている人ほど、思考の枠から出ることが難しかったりすると思います。

新しい考えを聞くときは自分のカップを空にしてアイデアが入ってくるスペースを空けること、大事です。以前、それだけのテーマでトーク 新世界の理解をしました。ブルース・リーも「水に成れ」と言ってます。

"Empty your mind ... Be water, my friend" — ブルース・リー (1971)

Q&Aで感じたこと

Q&Aの時間でもそれを感じました。概念の話をしているのに、どうしてもエッジケースや具体的な実装の話に引き寄せられます。パラダイムの話をしているのに、ユースケースの話になってしまう。もっともな問いばかりなんですが、人はどうしても、具体的な実装としてしか新しい概念を考えにくいのだと思います。

しかし、その自然に目にする視点を超え、構造や抽象を見通す視点が持てるかということがビジョン創生には必要です。

この抽象度のプレゼンテーションをすることに勇気がいりましたが、Q&Aで手を上げてくれた人も勇気が必要だったんじゃないかと思います。プレゼンは10分も早く終わってしまったんですが、これがよかったです。Q&Aが3倍の15分になり、本来あるべき対話が十分できました。Q&Aで手を挙げてくれた大勢の皆さん、ありがとうございました。

わかるところだけで前に進む

懇親会で「全部がわかったわけじゃないですけど」とおっしゃる方が何人かいました。でも、それでいいんだと思います。全部わかる必要はありません。

外国語を聞いているときと同じです。聞き取れなかった単語にずっと拘ってワカラナイ、ワカラナイとしてしまうと先に進めません。聞き取れた単語だけで自分の認知を組み立てる——その能力を使わないと、外国語は聞き取れるようにならない。新しいパラダイムも同じで、わかるところだけで自分の考え方を組み立てていけばいい。DoingとBeingでは思考の組み立て方そのものが違うので、最初から全部わかろうとする方が無理があります。それに、40分のトークで全員の認知が隙なく更新されたら、そもそもそれは新しいパラダイムなんでしょうか？恐らく違いますよね。ちなみにOOPの普及には二十余年の月日がかかりました。

設計プロセスについて

この33枚のスライドは、Claude Codeとの対話セッションで完成しました。24本のペーパーを精読した上で初期版を作り、セルフレビューで強み・弱みを特定し、1枚ずつ議論しながらボツ案や方針転換を重ねました。

発見型プレゼンの設計は、説明型より時間がかかります。何を見せるかより何を見せないかの判断が多く、ボツにした案の方が採用した案より遥かに多い。しかし40分後に聴衆の認知が幾許かでも変わっているなら、その時間には価値があるのではないでしょうか。

スライドで説明しなかったこと

40分に収めるために、いくつかの用語は説明を省きました。

第一級市民（First-class citizen）　言語が「正式に扱える概念」のこと。PHPでは5.3で無名関数が導入されて、初めて関数が第一級市民になりました——変数に入れたり、引数に渡せるようになった。Be Frameworkでは「存在の条件」や「時間的な変容」を第一級市民にしています。

アフォーダンス（Affordance）　そのとき利用可能な操作のこと。ドアノブは「回す」を、ボタンは「押す」をアフォードする。HTMLのリンクやフォームは操作可能なときだけ画面に現れる。OOPのクラスは全メソッドが常に利用可能で、アフォーダンスがありません。

Union型（ユニオン型）　Success|Failure のように複数の型を | で繋げて「このどれかである」と宣言するPHP 8.0の機能。$being はこれで「なりうるもの全て」を宣言しています。

イミュータブル（Immutable）　一度作ったら変更できないオブジェクト。PHPでは readonly で実現します。Beの各クラスはイミュータブルです。変更ではなく変容——だから不変でいい。

VO（Value Object）　値そのものを表すオブジェクト。Email や Money など。意味変数はVOに似ていますが、VOは個別に使うもの、意味変数は名前に紐づいて世界全体に自動適用されるものです。

中央の制御者がいない　従来のアーキテクチャでは、あの注文フローをOrderServiceのような巨大なクラスが制御を手順で行います。全体を知る神が必要になる。Be Frameworkでは各クラスが自分の前後だけを知っていて、全体を知る者はいません。入力が谷を流れるように次の存在へ変容していく。このような構造をコレオグラフィ（choreography）と呼びます。踊りの振付のことで、指揮者がいるオーケストラに対して、各ダンサーが自分の振付だけで踊り全体が調和します。

OOPが目指したもの　オブジェクトの自律。メッセージを受け取って自ら振る舞う——操作されるのではなく。しかし実際には$user->delete()のようにオブジェクトは外から操作される手続きの束になりました。Beではオブジェクトは外部から操作されず、内在と超越の出会いによって自ら変容します。

FPが目指したもの　不変性と変換のパイプライン。データを壊さず、関数の連鎖で変換していく。Beの各クラスはイミュータブルで、Input→Being→Finalという変換の連鎖で構成されています。ただしパイプは外からデータを加工する（Doing）のに対し、Beはオブジェクト自身が変容する（Being）——主語が違います。

DDDが目指したもの　ドメインの知識をコードに投影すること。ユビキタス言語、境界づけられたコンテキスト。Beではクラス名と意味変数がそのままドメインの語彙になり、アーキテクチャ図がそのままドメインのドキュメンテーションになります。

MVCが目指したもの　Webフレームワークの責務分離ではなく、本来のMVC（Trygve Reenskaug, 1979）が目指したのはユーザーのメンタルモデルとコンピュータの内部モデルの橋渡しです。Modelは世界の表現、Viewはその投影、Controllerはユーザーの意図の翻訳。BeではPatientArrivalInput→TriageAssessment→EmergencyCaseというクラス名の連なりが、そのまま人間のメンタルモデルになっています。橋渡しが要らない——コードが直接メンタルモデルです。

宣言的プログラミング（Declarative Programming）　「どうやるか（HOW）」ではなく「何が欲しいか（WHAT）」を記述するスタイル。SQLやHTMLが代表例です。Be Frameworkの#[Be]や$beingは宣言的ですが、さらにその先——「何であるか」「存在できるか（WHETHER）」を宣言しています。

Tell, Don’t Ask　オブジェクトの状態を聞いて（Ask）から判断するのではなく、命じろ（Tell）。OOPの重要原則です。Be, Don’t Doはその先——命じることすらしない。何をするかではなく何であるかを定義する。

契約プログラミング（Design by Contract）　メソッドの事前条件・事後条件・不変条件を明示する手法。意味変数と似て見えますが、契約プログラミングは入り口で不正を監視する、型安全な状態遷移は遷移を型で制約する——どちらもDoingの精緻化です。意味変数はそもそも不正な値が存在できない世界を作る。監視も遷移も要りません。次元の違うことをしている。もう一つ大きな違いは、契約はメソッドごとに分散しますが、意味変数は一つのディレクトリにアプリケーションの言葉として集約されます。検証セットというよりデータモデル、そのアプリケーションが使う言葉のコーパス（corpus：ある目的で集められた言語資料の集成）になります。

ハイパーテキスト（Hypertext）　テッド・ネルソンが1963年に造った言葉です。テキストが直線的に流れるのではなく、リンクで相互に繋がり合う構造。ネルソンは5歳の時にボートから手を水に入れ、手の動きと水流が互いに影響し合う関係に心を奪われました。その体験から “The world is a system of ever-changing relationships and structures”（世界は絶えず変化する関係と構造のシステムである）という洞察に至り、それがハイパーテキストの着想になった。哲学者ではなくコンピューティングの先駆者が、子供の体験から存在と関係の本質に辿り着いています。ちなみにPHP: Hypertext PreprocessorのHです。

これはパラダイムか？

「洗練された設計パターンの寄せ集めではないのか？」という問いがあると思います。私も初期からその問いを持ち続けてきました。

OOPのコードを見てください。

$user->validate(); 
$user->save();

この$user に処理を命じているのは誰ですか？

——オブジェクトの自律を目指したはずのOOPが、コントローラーレベルでは神の視点からの操作になっています。「取ってこい、検証しろ、保存しろ」。全部三人称の命令です。Tell, Don’t Askですら、命じている主語は神様視点のシステムです。

存在指向が変えているのは、この視点の置き場所です。システムの視点からドメインの自我の視点へ。患者は処理されるのではなく、自ら変容する。$emailは検証されるのではなく、存在していること自体が正しさの証明。命じる者がいない。コントローラーなどの呼び出し側は、制約なくあらゆるモデルを呼び出せる。存在指向はドメインを自我として、他者との関わりをドメイン自身が規定する。

意味変数も、自己決定も、自己証明も、コレオグラフィーも——個別の機能ではなく、「ドメインの自我を中心に世界を見る」という一つの視点から全てが導出されます。

パターンは既存の問いに対するより良い答えです。パラダイムは問いそのものを変える。HOWでもWHATでもなくWHETHER——そもそも存在できるか。この問いの転換が、個別の機能の違いではなく、視点の根本的な転換から来ているのだとしたら、それはパラダイムと呼んでいいのではないでしょうか。

スライド: 存在論的プログラミング：時間と存在を記述する

REST APIは一般に、GET /users/123 のようなリソース指向のURL設計とHTTPメソッドによるCRUD操作のスタイルだと思われていますが、本来はサーバーのレスポンスに含まれるリンクを辿ってアプリケーション状態を遷移させる、ハイパーメディアを基本としたスタイルです。このことは広く誤解されています。

しかしそれを知っている人でもなお、RESTはAPIの設計手法の1つだと誤解しています。RESTはAPI設計についてまとめたものではありません。分散ハイパーメディアシステム——HTTPの設計原理を体系化したものです。

この違いを解説した記事は少ないですが、どうしてこのような誤解が広まったかを考察する記事はもっと少ない。本稿は、RESTがどのようにバズワード化し、広まっていったかについて考察します。

時系列で見るREST前史

1996年 — HTTP/1.0（RFC 1945）

Roy T. FieldingはTim Berners-Lee、Henrik Frystyk Nielsenとともに、HTTP/1.0の仕様（RFC 1945）を策定しました。FieldingはこのときすでにApache HTTP Serverの開発にも関わっており、Webインフラの実装と仕様の両方を知る立場にいました。

1997–1999年 — HTTP/1.1（RFC 2068 → RFC 2616）

Fieldingは HTTP/1.1 の共著者として、プロトコルの拡張設計に深く関わります。1997年にRFC 2068として初版が公開され、1999年にRFC 2616として標準化されました。

この策定プロセスの中で、Fieldingは具体的な設計判断を下しています。たとえば、複数リソースを一括取得するMGETやMHEADというメソッドの提案を、プロキシ可能性やキャッシュ可能性を損なうという理由で却下しました。代わりに、持続的接続（persistent connection）上で複数リクエストを送る設計が採用されています。

2000年 — REST論文

Fieldingはカリフォルニア大学アーバイン校に博士論文「Architectural Styles and the Design of Network-based Software Architectures」を提出しました。

この論文が、RESTの原典です。

論文は何を書いていたか

重要なのは、この論文の動機です。Fieldingは新しいAPI設計手法を提案したのではありません。HTTP/1.1の策定プロセスを導いたアーキテクチャ上の原理を、事後的に体系化したのです。

つまり順序が逆です。REST論文に基づいてHTTPが設計されたのではなく、HTTPの設計判断を振り返り、その背後にあった原理を「REST」として定式化した。論文は理論が先にあったのではなく、実践から理論を抽出したものでした。

さらに言えば、論文の主題はRESTそのものですらありません。論文の大半は「ネットワークベースのソフトウェアアーキテクチャスタイルの分類学」に費やされており、REST自体が主に語られるのは1章だけです。分類学に並ぶスタイルには、Pipe-and-Filter、Layered-Client-Server、Client-Cache-Stateless-Serverなどがあり、RESTはこれらの制約を組み合わせた派生スタイルです。正式に書けばUniform-Layered-Code-on-Demand-Client-Cache-Stateless-Server（ULCODC$SS）——さすがにこの名前は採用されませんでしたが。

論文の核心的メッセージは「一つのアーキテクチャスタイルをすべてに使うな。アプリケーションの要件に合ったスタイルを選べ」です。Fielding自身こう書いています。

“design-by-buzzword is a common occurrence. … a good designer should select a style that matches the needs of a particular problem being solved.”

バズワードに基づく設計はよく見られる現象だ。（中略）優れた設計者は、解決すべき特定の問題のニーズに合ったスタイルを選択すべきだ。

そしてRESTの適用範囲についても明確です。

“REST is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.”

RESTは大粒度のハイパーメディアデータ転送に対して効率的になるよう設計されており、Webの一般的なケースに最適化されているが、他の形式のアーキテクチャ上のやりとりには最適ではないインターフェースをもたらす。

論文が対象とする問題領域は「アナーキックなスケーラビリティ」——組織や国境を越えて、ドキュメントを高パフォーマンスで接続するという課題です。これはWebそのものの構造であり、企業内のバックエンドAPIやモバイルアプリのBFFではありません。

統一インターフェース

RESTを構成するアーキテクチャ制約のうち、中心に位置するのが「統一インターフェース」（Uniform Interface）です。

Fieldingは論文で、この制約を4つのサブ制約として定義しています。

1. リソースの識別（Identification of Resources）— すべてのリソースにURIで識別できるアドレスを与える
2. 表現を通じたリソースの操作（Manipulation of Resources through Representations）— リソースそのものではなく、その表現（JSON、HTML等）を介して操作する
3. 自己記述的メッセージ（Self-descriptive Messages）— メッセージ自体に、処理に必要な情報がすべて含まれている（あるいはリンクされている）
4. アプリケーション状態のエンジンとしてのハイパーメディア（HATEOAS）— 次に何ができるかは、サーバーが返すリンクが教える

4番目のHATEOAS——クライアントはサーバーから返されるリンクを辿って次のアクションを発見する。Fieldingは後年、「これなしにRESTとは呼べない」と明言しています。

SOAPの時代、そしてその反動

2000年代前半 — SOAP全盛

REST論文が発表された2000年、Web上のサービス連携はまったく別の方向に進んでいました。SOAP（Simple Object Access Protocol）です。

SOAPはXMLベースのプロトコルで、リクエストもレスポンスもXMLのエンベロープに包んで送受信します。型定義にはWSDL、サービス検索にはUDDI、セキュリティにはWS-Securityと、関連仕様が層をなしていました。エンタープライズの世界では、この形式性こそが信頼性の証と見なされていました。

2000年代中頃 — 反発と「REST」のバズワード化

しかし、SOAPの複雑さは実装者に重い負担を強いていました。XMLの構文解析、WSDLからのコード生成、名前空間の衝突——Webの現場でAPIを素早く作りたい開発者にとって、SOAPは過剰でした。

この反動の中で、すでに2004年には「REST」という言葉を使ってCRUDマッピングを明記した記録が登場しています。英国オックスフォード大学e-Science Centreの技術者Matthew J. Doveyが、Fielding論文を参照しつつ「REST maps the CRUD operations onto the HTTP verbs（Create=POST, Retrieve=GET, Update=PUT, Delete=DELETE）」と書いた記事を公開しました。

「もっとシンプルにHTTP本来の機能を使おう」——この流れの中で、SOAPへのカウンターカルチャーのバズワードとして「REST」という言葉が流通し始めます。HTTPのメソッドとステータスコードをそのまま使い、URLにリソースの構造を反映させる。WSDLもUDDIもいらない。この実用的な判断は合理的でした。HTTPがすでに提供しているセマンティクスとインフラ（プロキシ、キャッシュ、ロードバランサー）をそのまま活用できる。

ただし、このアプローチはFieldingの論文が記述したRESTとは別物です。TwoBitHistory（2020年）はこれを FIOH（Fuck It, Overload HTTP ——もういいからHTTPに全部載せよう）と呼んでいます。FIOH自体に問題はありません。問題は、FIOHに過ぎないものに「REST」という学術的な名前が被せられたことです。

2007年 — DHHとRails

Ruby on Railsの2.0リリースで、SOAPサポート（ActionWebService）がデフォルトから廃止されました。公式ブログの発表でDHH（David Heinemeier Hansson）はこう書いています。

“Rails has picked a side in the SOAP vs REST debate. Unless you absolutely have to use SOAP for integration purposes, we strongly discourage you from doing so.”

RailsはSOAP対RESTの論争で立場を選んだ。統合のためにどうしてもSOAPを使わなければならない場合を除き、使用しないことを強く推奨する。

同時に、RailsはRESTfulルーティングをフレームワークの中心的な規約として導入しました。resources :articles と書けば、HTTPメソッドとCRUD操作の対応が自動的に生成される。DHHはこれを「RESTful」と呼び、アンチSOAPの旗印としました。

DHHは無知だったのではありません。2007年のブログで「この1年半は、Royが10年以上関わってきたアイデアと仕様を理解し実装しようとすることに費やされた」と書いており、RailsConf EuropeではFielding本人と直接対話もしています。その上で、2012年のブログではRESTを導入した動機について「知的純粋性のためではない」と書き、設計原則の評価基準は「最近何をしてくれたのか？」だと述べています。BasecampのAPIでハイパーメディアを試みたものの “it just didn’t do much for me”（自分にとってあまり意味がなかった）とも。同年のSignal v. Noiseではさらに踏み込み、ハイパーメディアAPIを「completely overblown（完全に過大評価）」と断じました。

Fieldingの仕事を知り、本人と話し、HATEOASを試した上で「自分には要らない」と判断した。これは誤解ではなく選択です。「REST」の名を選んだのは、アンチSOAPの旗印としてのマーケティング的な意味と、他の解説にもあるように権威づけの意味もあったのではないかと筆者は考えます。ある種の”技術用語負債”です。

2008年 — Fieldingの反応

Fielding本人がブログ記事「REST APIs must be hypertext-driven」を公開しました。

“I am getting frustrated by the number of people calling any HTTP-based interface a REST API.”

あらゆるHTTPベースのインターフェースをREST APIと呼ぶ人々の数に、フラストレーションを感じるようになっている。

Railsは2000年代後半から2010年代にかけてWeb開発の主要なフレームワークとなりました。「RailsでWebを学んだ」世代にとって、RESTを学ぶとはRailsのルーティング規約を学ぶことと、ほぼ同義でした。人々はDHHのブログやRESTのチュートリアルは読んでも、Fieldingの論文を読むことはなかったのではないでしょうか。

“RESTish API” の誕生

こうして生まれたのが、今日「RESTful API」と呼ばれているもの——RESTish、つまり「なんちゃってREST」のAPIです。その規則を並べてみます。

URL設計：リソースを名詞で表現し、階層構造をパスで表す。

GET  /users
GET  /users/123
GET  /users/123/posts

HTTPメソッドのCRUDマッピング：

ステータスコード：200 OK、201 Created、404 Not Found、422 Unprocessable Entity など、HTTPのステータスコードでビジネスロジックの結果を表現する。

データ形式：JSON

API仕様の共有：OpenAPI（Swagger）などの外部ドキュメントで、エンドポイントの一覧・パラメータ・レスポンス形式を記述し、開発者に共有する。

これが現在「RESTful API設計のベストプラクティス」として広く教えられている内容です。Fieldingが定義した統一インターフェースの4つの制約と見比べてみてください。統一インターフェースはHTTPメソッドのことではありません。

“RESTish API” の普及

2007年、O’Reillyから「RESTful Web Services」（Leonard Richardson、Sam Ruby著）が出版されました。RESTの名を冠した初の本格的な書籍です。この本はCRUD-over-HTTPのスタイルを「RESTful」として体系的に解説し、Ruby on Rails、Restlet（Java）、Django（Python）での実装方法を示しました。

Railsが規約として組み込み、書籍が体系化し、技術ブログやチュートリアルはこれらを参照して書かれ、そのブログを読んだ開発者がまた次のチュートリアルを書く。「RESTful API設計」は、Fieldingの論文を経由せずに自己増殖していきました。

リチャードソン成熟度モデル

2008年、同じLeonard RichardsonがQConで「Richardson Maturity Model」を発表しました。REST APIの「成熟度」を4段階で分類するモデルです。2010年にはMartin Fowlerが記事にして広く知られるようになりました。

Level 2で「RESTful」、Level 3まで行けば「完全なREST」——このモデルはそう読めます。

Fieldingは「HATEOASなしにRESTとは呼べない」と言いました。しかしこの成熟度モデルでは、HATEOASは最上位のLevel 3、つまり「到達すれば理想的」なオプションになっています。

FieldingのRESTはWebのアーキテクチャ設計原理を蒸留したものでした。リチャードソン成熟度モデルは、その「なんちゃってREST」を蒸留したものです。そしてMartin Fowlerがそれに権威を与えました。

ベストプラクティス化

2012年、API管理企業のApigeeが「Web API Design — Crafting Interfaces that Developers Love」というeBookを公開しました。Fieldingの論文を参照した上で、こう宣言しています。

“We advocate pragmatic, not dogmatic REST.”

我々は教条的ではなく、実用的なRESTを推奨する。

Fieldingの論文に忠実であろうとする人々を「RESTifarian」（REST原理主義者）と呼び、その対極として「pragmatic REST」を提唱しています。内容は「URLに動詞を使うな」「リソースごとにベースURLは2つ」「HTTPメソッドでCRUD操作を表現せよ」——Fieldingの論文のどこにもない規則群です。

分散ハイパーメディアとしての疎結合の設計原則が、クライアントとサーバーの密結合プロトコルとなり、体系化され、URLにバージョニングナンバーをつけることが常識になっていきました。

ここまでくればほとんどコメディです。論文を出典として挙げ、その内容を「dogmatic」と退け、論文にない規則を「ベストプラクティス」として体系化した。その後2016年、GoogleがApigeeを買収して体系化に権威が加わりました。

遅すぎた訂正

2013年、同じO’Reillyから「RESTful Web APIs」（Richardson、Mike Amundsen、Ruby著）が出版されます。前著の「完全な置き換え」を意図した本で、ハイパーメディアを中心に据え直しています。

しかし、遅すぎました。確信的誤用は、体系化され、権威づけられ、強固なものとなり、コピーのコピーはすでに止まらなくなっていました。

修正の弱さ

誤用への指摘がなかったわけではありません。「それはFieldingのRESTではない」という声は折に触れて上がりました。Fielding本人も2008年にブログで反論しています。

しかし、そのたびに議論は「どちらが実用的か」という話にすり替わりました。「HATEOASは理想的だが現実的ではない」「学術的な正しさより動くコードだ」——こうして事実の問題（FieldingのRESTとは何か）が、価値判断の問題（どちらが実用的か）に置換されていきました。

この置換が起きると、修正は機能しません。「それは事実と違う」に対して「でも便利だから」は反論になっていませんが、議論としては決着がついたように見えてしまう。結果として、誤用は誤用のまま定着し続けました。

三つの問い

ここまでの話には、三つの別々の問いが含まれています。

1. 事実の問い — Fieldingの論文は何を書いていたか
2. 実用の問い — CRUD-over-HTTPは便利か
3. 命名の問い — それを「REST」と呼ぶ必要があったか

2番の答えは「はい」です。HTTPのメソッドとステータスコードをそのまま使い、JSONでやりとりするアプローチは合理的でした。これはSOAPとの対比において明らかです。

しかし2番が正しいことは、1番や3番への回答にはなりません。「REST論争」では、この三つが「学術的な正しさ vs 実用性」という単純な二項対立に圧縮されてきました。この圧縮の下では、事実や命名への疑問が、実用性への攻撃として処理されます。「それはFieldingのRESTではない」と言えば「でも便利だから」と返される。問いが違うのに、答えたことになっている。

そして業界は誤用の上に大量のエコシステムを積み上げました。”RESTful API” はFieldingのRESTとは別のものとして、すでに機能しています。誤用の痛みを保ちながらも。

そうやって、”REST”のコピーのコピーは今日も続いています。以上が現実です。

エピローグ - いつになったら気づくのだろう

2017年、FieldingはESEC/FSE 2017の講演でこう述べています。

“REST has become a buzzword. There’s nothing particularly wrong with that… unless you happen to be me or working with me.”

RESTはバズワードになった。別にかまわない——この私か、私と働く人間でさえなければ。

2021年、TwoBitHistoryのREST記事をきっかけに、Fieldingはツイートスレッドを投稿しました。ワクチンブースター接種の副反応のせいかもしれないと言いつつ、こんなメッセージを残しています。

私の論文に対する「だいたい正しい」解釈の問題は、木を見て森を見ていないところだ。RESTはAPIについてのものではない。ネットワークベースのアプリにおけるシステム間の相互作用についてのものだ。ただし、その制約群は統一されたネットワークベースのAPI（URI+HTTP+HTML等）を誘発するよう設計されてもいた。

確かにRESTはバズワードだ。予想通り乱用されてきた。だがRESTの眼鏡を通してWebを見れば、そのアーキテクチャの中に汎用的なネットワークベースのAPIが設計されていることが分かるはずだ。

なのに、APIが欲しい人々は「RESTから学べ」と言われると、ライブラリをimportするように「RESTを使え」と解釈してしまう。そういうものではないのに。さらに結局はアドバイスそのものが悪いということにされる…

私がここに座って開発者たちを責めても始まらない。当時、彼らを読者として想定しないと決めたのは私自身なのだから。

だが、いつになったら気づくのだろう。自分が対価を得ている理由、優れた仕事で尊敬されている理由は、自分の頭を使って自分のシステムの文脈に合わせた詳細を埋めていける能力があるからだということに。

Learn, apply, iterate!

参照

• 2000: Roy T. Fielding, Architectural Styles and the Design of Network-based Software Architectures（日本語訳）
• 2004: Matthew J. Dovey, C.R.U.D. WebServices and Record Update
• 2004: Bob DuCharme, Telnet and REST Web Services?（xml.com）
• 2007: DHH, Good times at RailsConf Europe
• 2007: Ruby on Rails, Rails 2.0: It’s done
• 2008: Roy Fielding, REST APIs must be hypertext-driven
• 2010: Martin Fowler, Richardson Maturity Model
• 2012: DHH, The Parley Letter
• 2012: DHH, Getting hyper about hypermedia APIs
• 2012: Apigee (Brian Mulloy), Web API Design — Crafting Interfaces that Developers Love
• 2017: Roy Fielding et al., Reflections on the REST Architectural Style ESEC/FSE（slides）
• 2020: TwoBitHistory, Roy Fielding’s Misappropriated REST Dissertation
• 2021: Roy Fielding, Twitter

この記事が語らなかったことについて: 書かれていないこと

劣化と伝播

• コピーのコピーは劣化パターン。論文→書籍→ブログ→チュートリアル→Stack Overflow→ベストプラクティス→フレームワーク規約→新人の頭の中。各段階でニュアンスが失われ、確信が増す。最も不正確なバージョンが、最も強い確信で保持される
• フレームワーク規約が最終段階。resources :articles と書けばルーティングが自動生成される。RESTを使っていることを知らずに、RESTでないものをRESTとして使っている。三重の不知
• 原典は無料で公開されている。ペイウォールの向こうにもない。それでも誰も読まない。アクセスの問題ではなく、文化の問題
• 多くの登場人物のうち、本当の設計者はFieldingだけ。DHHは優れたマーケター、Apigeeはベストプラクティスの売人、Richardsonは体系化した著者、Fowlerは権威の増幅器

概念の破壊

• FIOHを「HTTP API」と呼んでいれば、Fieldingの「REST」は別の概念として生き残れた。名前を奪ったことで、本物が検索不能になった。意図的誤用は概念を殺した
• “Representational State Transfer”の”State Transfer”は「リソースの状態をネットワーク越しに転送する」ことではない。「ハイパーリンクを辿ってアプリケーションの状態を遷移する」こと。名前の意味すら原典と違う理解が定着している
• Apigeeはエンドポイント管理、バージョニング、APIドキュメンテーションのツールを売っている。CRUD over HTTPは彼らの必然だったが、名前を奪う必然はなかった
• SOAP vs RESTは偽の二項対立だった。SOAPに勝ったのはRESTではない。FIOHが勝ってRESTのユニフォームを着た。勝者が敗者の名前を奪った試合

論理の罠

• 「pragmatic vs dogmatic」は自己封鎖する論法。Apigeeが自分を「pragmatic」と位置づけた瞬間、あらゆる修正の試みが「dogmatic」の証拠になる。反論すればするほどRESTifarianの烙印が強まる。枠組みを設定した時点で勝っている
• 「便利だから」は反証不能。動くソフトウェアは動く。何と呼んでも動く。だからこそ、名前の問題は機能の問題と別に議論しなければならない
• 確信的誤用は偶然の誤解より深刻。DHHはFieldingと直接話した。Richardsonは2007年の本が間違いだと知っていたから2013年に書き直した。Apigeeは論文を引用した上で「dogmatic」と退けた。全員、読んだ上でやった

皮肉と自己言及

• 論文の核心は「一つのスタイルをすべてに使うな」。業界は論文の名前を借りて、一つのスタイルをすべてに適用した。Fieldingの論文は、自分自身が警告した病気のウイルスになった
• Fieldingは論文第1章の冒頭に、屠殺場しか設計したことのない建築家が集合住宅を屠殺場として設計するMonty Pythonのスケッチ（The Architects Sketch）を引用した。「すみません……今『ナイフ』とおっしゃいました？」。まさにこれが起きた
• Fieldingは”design-by-buzzword”を論文で警告した。その論文が最大のバズワードになった
• 「Learn, apply, iterate!」——業界もそうした。ただし対象がコピーだった。コピーを学び、コピーを適用し、コピーの上でイテレーションした。Fieldingの本意は「自分の頭で、自分のシステムの文脈に合わせろ」——ベストプラクティスを丸ごと輸入する文化の対極

有効成分の除去

• HATEOASがあればクライアントはリンクを辿るからURLをハードコードしない。サーバーはURLを変えてもクライアントは壊れない。バージョニングは要らない。業界はHATEOASを落とした。クライアントはURLをハードコードするようになった。URLを変えると壊れる。だから/api/v1/、/api/v2/、/api/v3/——APIバージョニングが「RESTful API設計」最大の課題になった。壊れずに進化するための設計原理から、進化を防ぐ制約を取り除き、進化できないことに苦しんでいる。薬の名前だけ残して有効成分を抜き、効かないと言っている
• 自己記述的メッセージを落とし、代わりにOpenAPIという外部仕様書を作り、その仕様書を管理するためにSwagger UI、コードジェネレータ、モックサーバーという巨大なエコシステムを築いた。落とした制約を補うためのエコシステムを、落とした制約の上に積み上げている
• 痛みが痛みだと認識されていない。CRUD-over-HTTPしか知らない開発者にとって、人工的な問題は「API開発の自然なコスト」に見える。本物を知らなければ痛みは見えない。しかし本物の名前は奪われている
• 誤用のままでいることが、その先の判断も歪めている。「RESTを試してダメだったから次へ行こう」と言っている人が試したのはCRUD-over-HTTPだけど、RESTの名前のせいでRESTそのものが失敗したと認識される。誤った地図で歩いた人が「この地図の先は崖だ」と報告している。地図が違う
• FieldingはHTTP/1.1の策定で、複数リソースを一括取得するMGETメソッドをproxyabilityとcacheabilityを損なうとして却下した。この「なぜ」が伝わらなかった。複数リソースを一度に取得できないことが「RESTの限界」に見えた。GraphQLはRESTの問題を「解決」した！といって登場した——proxyabilityもcacheabilityも犠牲にして。そして落としたcacheabilityの問題に再び取り組むことになる、落とされたことを知らないまま

構造的悲劇

• 権威のロンダリング。Fieldingの学術的権威 → Apigeeが引用 → GoogleがApigeeを買収 → 「Googleが推奨」。権威の種類が学術から商業に変わり、中身も変わるが、引用の連鎖が学術的裏付けがあるように見せている
• Fieldingの自責——「彼らを読者として想定しないと決めたのは私自身だ」。学術論文として書いたから実務者には届かない事を知っていた。そして中間者（DHH、Richardson、Apigee）が間を埋めた。しかし中間者が渡したのは薄めたコピーだった
• リチャードソン成熟度モデルは「Level 2で十分RESTful」という免罪符を与えた。成熟度モデルなのに、未成熟で止まることを正当化している
• 25年間の集合的エンジニアリング努力が、人工的な問題（バージョニング、エンドポイント設計、OpenAPI保守）の解決に費やされた。もし業界がハイパーメディアを本当に理解して適用していたら、Webはどうなっていたか。それは永遠にわからない

メタ

• この記事自体が、記事が批判するものの対極を実演している。コピーのコピーではなく、一次情報に戻っている。方法論として、自身が診断する病気の処方箋になっている
• 冒頭の3段落は孤独の漏斗。「広く誤解されています」→「それを知っている人でもなお」→「考察する記事はもっと少ない」。文ごとに理解者の輪が狭まっていく

元記事は歴史的経緯を明らかにするために事実の列挙に留め、筆者の考察や抽象化を控えました。この記事は事実の記述に対する構造の分析です。続編：「Buzzwordによる設計」

Most developers think of REST APIs as resource-oriented URL design with CRUD operations mapped to HTTP methods—something like GET /users/123. In reality, REST is a hypermedia-based style where clients follow links in server responses to transition application state. This is widely misunderstood.

But even those who know this still misunderstand REST as an API design methodology. It is not. REST is a formalization of the design principles behind distributed hypermedia systems—the architecture of HTTP itself.

Articles explaining this distinction are rare. Articles examining how the misunderstanding spread are rarer still. This post traces how REST became a buzzword and how the misuse propagated.

Prehistory of REST

1996 — HTTP/1.0 (RFC 1945)

Roy T. Fielding co-authored the HTTP/1.0 specification (RFC 1945) with Tim Berners-Lee and Henrik Frystyk Nielsen. Fielding was already involved in developing the Apache HTTP Server, placing him at the intersection of Web infrastructure implementation and specification.

1997–1999 — HTTP/1.1 (RFC 2068 → RFC 2616)

Fielding was deeply involved in the design of HTTP/1.1 as a co-author. The initial version was published as RFC 2068 in 1997, and the standard was finalized as RFC 2616 in 1999.

During this process, Fielding made concrete design decisions. For instance, he rejected proposals for MGET and MHEAD methods—batch retrieval operations—on the grounds that they would compromise proxyability and cacheability. Instead, sending multiple requests over persistent connections was adopted instead.

2000 — The REST Dissertation

Fielding submitted his doctoral dissertation, “Architectural Styles and the Design of Network-based Software Architectures,” to the University of California, Irvine.

This dissertation is the original source of REST.

What the Dissertation Actually Said

What matters here is the motivation. Fielding was not proposing a new API design methodology. He was retroactively systematizing the architectural principles that had guided the HTTP/1.1 design process.

The chronology is the reverse of what most people assume. HTTP was not designed based on the REST dissertation. Rather, Fielding looked back at the design decisions behind HTTP and formalized the principles underlying them as “REST.” Theory did not come first—it was extracted from practice.

Furthermore, the dissertation’s subject is not even REST itself. The bulk of the work is devoted to a taxonomy of network-based software architectural styles. REST is primarily discussed in a single chapter. Other styles in the taxonomy include Pipe-and-Filter, Layered-Client-Server, and Client-Cache-Stateless-Server. REST is a derived style combining constraints from several of these. Its full formal name would be Uniform-Layered-Code-on-Demand-Client-Cache-Stateless-Server (ULCODC$SS)—unsurprisingly, this name was not adopted.

The dissertation’s core message is: “Don’t use one architectural style for everything. Select a style that matches the needs of your particular problem.” Fielding himself wrote:

“design-by-buzzword is a common occurrence. … a good designer should select a style that matches the needs of a particular problem being solved.”

And on REST’s scope of applicability:

“REST is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.”

The problem domain the dissertation addresses is “anarchic scalability”—high-performance document connectivity across organizational and national boundaries. This is the structure of the Web itself, not enterprise backend APIs or mobile app BFFs.

The Uniform Interface

Of the architectural constraints that make up REST, the most central is the Uniform Interface.

Fielding defined this constraint as four sub-constraints in the dissertation:

1. Identification of Resources — Every resource is identified by a URI
2. Manipulation of Resources through Representations — Resources are manipulated through their representations (JSON, HTML, etc.), not directly
3. Self-descriptive Messages — Messages contain (or link to) all information necessary for processing
4. Hypermedia as the Engine of Application State (HATEOAS) — What can be done next is communicated through links returned by the server

The fourth constraint, HATEOAS, means that clients discover available actions by following links the server provides. Fielding later stated explicitly that without this, you cannot call it REST.

The SOAP Era and Its Backlash

Early 2000s — SOAP’s Heyday

When the REST dissertation was published in 2000, service integration on the Web was heading in an entirely different direction: SOAP (Simple Object Access Protocol).

SOAP was an XML-based protocol where both requests and responses were wrapped in XML envelopes. Type definitions used WSDL, service discovery used UDDI, security used WS-Security—a tower of related specifications. In the enterprise world, this formality was seen as a hallmark of reliability.

Mid-2000s — Backlash and the Buzzword-ification of “REST”

However, SOAP’s complexity imposed a heavy burden on implementers. XML parsing, code generation from WSDL, namespace collisions—for developers who wanted to build APIs quickly on the Web, SOAP was overkill.

Amid this backlash, references using the word “REST” to describe CRUD mappings appeared as early as 2004. Matthew J. Dovey of the University of Oxford’s e-Science Centre published an article that referenced Fielding’s dissertation and explicitly stated: “REST maps the CRUD operations onto the HTTP verbs (Create=POST, Retrieve=GET, Update=PUT, Delete=DELETE).”

“Just use HTTP the way it was designed”—within this movement, “REST” began circulating as a counter-cultural buzzword against SOAP. Use HTTP methods and status codes directly. Reflect resource structure in URLs. No WSDL, no UDDI needed. The pragmatic appeal was real: it leveraged the semantics and infrastructure (proxies, caches, load balancers) that HTTP already provided.

But this approach was a far cry from the REST described in Fielding’s dissertation. TwoBitHistory (2020) called this FIOH (Fuck It, Overload HTTP). There is nothing inherently wrong with FIOH. The problem is that what was merely FIOH got dressed up with the academic label “REST.”

2007 — DHH and Rails

In the Ruby on Rails 2.0 release, SOAP support (ActionWebService) was removed from the defaults. In the official blog announcement, DHH (David Heinemeier Hansson) wrote:

“Rails has picked a side in the SOAP vs REST debate. Unless you absolutely have to use SOAP for integration purposes, we strongly discourage you from doing so.”

Simultaneously, Rails introduced RESTful routing as a central framework convention. Write resources :articles and the framework would automatically generate mappings between HTTP methods and CRUD operations. DHH called this “RESTful” and used it as a banner against SOAP.

DHH was not ignorant. In a 2007 blog post, he wrote that “the past year and a half has been spent trying to understand and implement the ideas and specifications that Roy has been involved in for the past decade,” and he spoke directly with Fielding at RailsConf Europe. Yet in a 2012 blog post, he wrote that his motivation for introducing REST was “not for the sake of intellectual purity,” asking of design principles: “what have you done for me lately?” He mentioned that he tried hypermedia for the Basecamp API but found “it just didn’t do much for me.” In Signal v. Noise that same year, he went further, calling hypermedia APIs “completely overblown.”

He knew Fielding’s work, spoke with the man himself, tried HATEOAS, and decided “I don’t need this.” This was not a misunderstanding—it was a choice. Choosing the name “REST” served, in my view, as marketing—a banner against SOAP—and, as other commentators have noted, borrowed academic authority. A kind of technical terminology debt.

2008 — Fielding’s Response

Fielding himself published the blog post “REST APIs must be hypertext-driven.”

“I am getting frustrated by the number of people calling any HTTP-based interface a REST API.”

Rails became one of the dominant web development frameworks from the late 2000s through the 2010s. For the generation that “learned the Web through Rails,” learning REST was virtually synonymous with learning Rails routing conventions. People read DHH’s blog posts and REST tutorials, but rarely Fielding’s dissertation.

The Birth of “RESTish APIs”

What emerged is what we now call “RESTful APIs”—RESTish, or “REST in name only.” Here are the conventions:

URL design: Resources expressed as nouns, with hierarchical structure in the path.

GET  /users
GET  /users/123
GET  /users/123/posts

HTTP method-to-CRUD mapping:

Status codes: Business logic outcomes expressed through HTTP status codes—200 OK, 201 Created, 404 Not Found, 422 Unprocessable Entity, etc.

Data format: JSON

API specification sharing: Endpoints, parameters, and response formats are described in external documentation such as OpenAPI (Swagger) and shared with developers.

This is what passes today for “RESTful API design best practices.” Compare it against Fielding’s four constraints of the Uniform Interface. The Uniform Interface is not about HTTP methods.

The Spread of “RESTish APIs”

In 2007, O’Reilly published “RESTful Web Services” (by Leonard Richardson and Sam Ruby). It was the first major book bearing the REST name. The book systematically presented the CRUD-over-HTTP style as “RESTful,” demonstrating implementations in Ruby on Rails, Restlet (Java), and Django (Python).

Rails embedded it as convention. The book systematized it. Tech blogs and tutorials referenced both, and the developers who read those blogs wrote yet more tutorials. “RESTful API design” self-replicated without ever passing through Fielding’s dissertation.

The Richardson Maturity Model

In 2008, the same Leonard Richardson presented the “Richardson Maturity Model” at QCon—a model classifying the “maturity” of REST APIs into four levels. In 2010, Martin Fowler wrote an article about it, bringing it to wide attention.

Level 2 earns you the label “RESTful”; Level 3 gets you “full REST”—that is how this model reads.

Fielding said you cannot call it REST without HATEOAS. But in this maturity model, HATEOAS is Level 3—the highest level, positioned as an “ideal to aspire to” rather than a requirement.

Fielding’s REST was a distillation of the Web’s architectural design principles. The Richardson Maturity Model was a distillation of “REST in name only.” And Martin Fowler gave it his imprimatur.

Codification as Best Practice

In 2012, the API management company Apigee published “Web API Design — Crafting Interfaces that Developers Love.” After referencing Fielding’s dissertation, it declared:

“We advocate pragmatic, not dogmatic REST.”

It labeled those who sought fidelity to Fielding’s dissertation “RESTifarians” (REST fundamentalists), positioning “pragmatic REST” as the opposite. The content consisted of rules like “don’t use verbs in URLs,” “two base URLs per resource,” and “express CRUD operations with HTTP methods”—a set of rules found nowhere in Fielding’s dissertation.

Design principles for loose coupling in distributed hypermedia had been turned into a tightly coupled client-server contract, codified and systematized—and putting version numbers in URLs became received wisdom.

By this point, it bordered on comedy. They cited the dissertation as their source, dismissed its content as “dogmatic,” and codified rules absent from the dissertation as “best practices.” Then in 2016, Google acquired Apigee, lending corporate authority to the codification.

A Correction That Came Too Late

In 2013, O’Reilly published “RESTful Web APIs” (by Richardson, Mike Amundsen, and Ruby), intended as a “complete replacement” for the earlier book, re-centering hypermedia.

But it was too late. The deliberate misuse had been systematized, legitimized, and solidified. The copies of copies were already unstoppable.

The Weakness of Corrections

Corrections were attempted. Voices saying “that is not Fielding’s REST” surfaced from time to time. Fielding himself responded in his 2008 blog post.

But each time, the discussion was redirected to the question of “which is more practical.” “HATEOAS is ideal but not realistic.” “Working code matters more than academic correctness.” Thus a factual question (what is Fielding’s REST?) was substituted with a value judgment (which is more practical?).

Once this substitution occurs, corrections cease to function. “That’s factually wrong” versus “but it’s convenient” is not a real rebuttal, yet it appears to settle the argument. As a result, the misuse persisted uncorrected.

Three Distinct Questions

This history contains three separate questions:

1. A factual question — What did Fielding’s dissertation actually say?
2. A practical question — Is CRUD-over-HTTP useful?
3. A naming question — Did it need to be called “REST”?

The answer to question 2 is “yes.” Using HTTP methods and status codes directly, exchanging JSON—this approach was reasonable, especially in contrast with SOAP.

But the correctness of question 2 does not answer questions 1 or 3. In the “REST debates,” these three have been compressed into a simple binary: “academic correctness vs. practicality.” Under this compression, questioning facts or naming gets dismissed as an attack on practicality. Say “that is not Fielding’s REST” and you get “but it’s convenient.” The questions are different, yet the response appears to be an answer.

Meanwhile, the industry has built a massive ecosystem on top of the misuse. “RESTful APIs” already function as something separate from Fielding’s REST—carrying the burden of misuse along with them.

And so the copies of copies of “REST” continue to this day. That is where we are.

Epilogue — When Will They Learn

In 2017, Fielding said this in his talk at ESEC/FSE 2017:

“REST has become a buzzword. There’s nothing particularly wrong with that… unless you happen to be me or working with me.”

In 2021, prompted by the TwoBitHistory article on REST, Fielding posted a Twitter thread. Blaming his candor on vaccine booster side effects, he wrote:

One problem with “mostly right” takes on my dissertation is when they see the trees but not the forest. REST isn’t about APIs; it’s about system interaction for network-based apps. But the constraints were also designed to induce a uniform network-based API (URI+HTTP+HTML+etc).

Yes, REST is a buzzword, it has been abused (as expected), and the name refers to an architectural style in a dissertation about software engineering. However, seeing the Web through REST goggles does reveal the general-purpose network-based API designed within that architecture.

So, then we have this problem of people wanting an API for their network-based application, being told they should learn from REST, and interpreting that as “use REST” like they would use a library import. That’s not how it works, and recipients eventually blame the advice. Fine.

It doesn’t really work for me to sit here and blame practitioners for not understanding how to design their own large-scale software systems using my advice, that I provided in my dissertation, since I was the one who decided that wasn’t my audience at the time. Fine.

But at what point do people realize that the reason they are paid to do their jobs, or being respected for the great jobs that they already do, is because they can use their own brains to fill in the details specific to their own system context? Learn, apply, iterate!

References

• 2000: Roy T. Fielding, Architectural Styles and the Design of Network-based Software Architectures
• 2004: Matthew J. Dovey, C.R.U.D. WebServices and Record Update
• 2004: Bob DuCharme, Telnet and REST Web Services? (xml.com)
• 2007: DHH, Good times at RailsConf Europe
• 2007: Ruby on Rails, Rails 2.0: It’s done
• 2008: Roy Fielding, REST APIs must be hypertext-driven
• 2010: Martin Fowler, Richardson Maturity Model
• 2012: DHH, The Parley Letter
• 2012: DHH, Getting hyper about hypermedia APIs
• 2012: Apigee (Brian Mulloy), Web API Design — Crafting Interfaces that Developers Love
• 2017: Roy Fielding et al., Reflections on the REST Architectural Style ESEC/FSE (slides)
• 2020: TwoBitHistory, Roy Fielding’s Misappropriated REST Dissertation
• 2021: Roy Fielding, Twitter

What this article did not say: the unwritten

Degradation and Propagation

• Copies of copies degrade. Dissertation → book → blog → tutorial → Stack Overflow → best practice → framework convention → the mind of a junior developer. At each stage, nuance is lost and certainty increases. The least accurate version is held with the greatest conviction
• Framework conventions are the final stage. Write resources :articles and routing is auto-generated. You are using what is called REST without knowing it, and what you are using is not REST. A triple ignorance
• The original source is freely available online. It is not behind a paywall. Still, almost nobody reads it. This is not a problem of access—it is a problem of culture
• Of the many figures in this story, only Fielding is the actual designer. DHH was a brilliant marketer, Apigee a best-practice dealer, Richardson the systematizing author, Fowler the authority amplifier

Destruction of a Concept

• If FIOH had been called “HTTP API,” Fielding’s “REST” could have survived as a separate concept. By taking the name, the real thing became unsearchable. Deliberate misuse killed a concept
• The “State Transfer” in “Representational State Transfer” does not mean “transferring resource state over the network.” It means “transitioning application state by following hyperlinks.” Even the meaning of the name itself has settled into an understanding that diverges from the original
• Apigee sells endpoint management, versioning, and API documentation tools. CRUD over HTTP was their inevitability—but taking the name was not
• SOAP vs REST was a false dichotomy. REST did not defeat SOAP. FIOH won and put on REST’s uniform. A match where the victor stole the loser’s name

Logic Traps

• “Pragmatic vs dogmatic” is a self-sealing argument. The moment Apigee positioned itself as “pragmatic,” every attempt at correction became evidence of being “dogmatic.” The more you push back, the stronger the RESTifarian label sticks. The framing won the argument before it began
• “Because it’s convenient” is unfalsifiable. Working software works. It works no matter what you call it. That is precisely why the naming question must be discussed separately from the functionality question
• Deliberate misuse is more serious than accidental misunderstanding. DHH spoke with Fielding directly. Richardson knew his 2007 book was wrong—that is why he rewrote it in 2013. Apigee cited the dissertation and then dismissed it as “dogmatic.” They all read it before doing what they did

Irony and Self-Reference

• The dissertation’s core message is “don’t use one style for everything.” The industry borrowed the dissertation’s name and applied one style to everything. Fielding’s dissertation became the virus of the very disease it warned against
• Fielding opened Chapter 1 of his dissertation with a Monty Python sketch (The Architects Sketch) about an architect who has only designed slaughterhouses and designs an apartment block as a slaughterhouse. “Excuse me… did you say ‘knives’?” That is exactly what happened
• Fielding warned against “design-by-buzzword” in his dissertation. His dissertation became the biggest buzzword
• “Learn, apply, iterate!”—the industry did exactly that. Except the input was copies. They learned copies, applied copies, and iterated on copies. What Fielding meant was “use your own brain to fill in the details for your own system’s context”—the polar opposite of a culture that imports best practices wholesale

Removal of the Active Ingredient

• With HATEOAS, clients follow links rather than hardcoding URLs. The server can change URLs without breaking clients. Versioning is unnecessary. The industry dropped HATEOAS. Clients began hardcoding URLs. Changing a URL breaks things. Hence /api/v1/, /api/v2/, /api/v3/—API versioning became the greatest challenge of “RESTful API design.” They took a design principle meant to enable evolution without breakage, removed the constraint that prevents breakage, and now suffer from the inability to evolve. They kept the name of the medicine, removed the active ingredient, and complain that it does not work
• They dropped self-descriptive messages and built OpenAPI as an external specification instead, then erected an entire ecosystem—Swagger UI, code generators, mock servers—to manage that specification. An ecosystem built on top of a dropped constraint, to compensate for the dropped constraint
• The pain is not recognized as pain. For developers who know nothing but CRUD-over-HTTP, artificial problems look like “the natural cost of API development.” If you have never seen the real thing, you cannot see the pain. But the real thing’s name has been taken
• Living with misuse distorts decisions downstream. People who say “we tried REST and it didn’t work, so let’s move on” never tried REST. What they tried was CRUD-over-HTTP, but because it bore the name REST, REST itself was perceived to have failed. They walked with the wrong map and reported “there’s a cliff ahead on this map.” The map is wrong
• During the HTTP/1.1 design process, Fielding rejected the proposed MGET method—batch retrieval of multiple resources—on the grounds that it would compromise proxyability and cacheability. The “why” behind this decision was never transmitted. The inability to fetch multiple resources at once came to look like “a limitation of REST.” GraphQL arrived claiming to “solve” REST’s problems—sacrificing proxyability and cacheability in the process. And then set about tackling the cacheability problem all over again, unaware it had been discarded

Structural Tragedy

• Authority laundering. Fielding’s academic authority → Apigee cites it → Google acquires Apigee → “recommended by Google.” The type of authority shifts from academic to commercial, and the content shifts too, but the chain of citations makes it look as though academic backing persists
• Fielding’s self-blame—”I was the one who decided that wasn’t my audience at the time.” Because he wrote it as an academic dissertation, he knew it would never reach practitioners. Intermediaries (DHH, Richardson, Apigee) filled the gap. But what the intermediaries passed along was a diluted copy
• The Richardson Maturity Model granted an indulgence: “Level 2 is RESTful enough.” A maturity model that justifies stopping at immaturity
• Twenty-five years of collective engineering effort have been spent solving artificial problems (versioning, endpoint design, OpenAPI maintenance). What would the Web look like if the industry had truly understood and applied hypermedia? We will never know

Meta

• The article itself demonstrates the opposite of what it criticizes. It goes back to primary sources rather than copying copies. As methodology, it is the prescription for the disease it diagnoses
• The opening three paragraphs form a funnel of solitude. “Widely misunderstood” → “even those who know this” → “rarer still.” With each sentence, the circle of understanding narrows

The original article confined itself to listing facts to illuminate the historical trajectory, withholding the author's analysis and abstraction. This document is a structural analysis of those facts.

Exactly one year ago, I wrote an article with the same title: “Irreversible Change—The Era of AI-Written Code.”

In it, I wrote something almost prophetic about the “declining value of Developer Experience (DX)” in the coming age of AI-written code and the “shift in responsibility” that humans would need to bear.

One year has passed. The future arrived with a speed and a kind of violence that far exceeded my imagination.

2025: The Fault Line

Looking back, the change did not arrive “gradually.” It was a distinct fault line.

Think back to December 2024. At a conference, I asked the audience: “How many of you know Cline?” “How many of you know DeepSeek?” Not a single hand went up.

But then January 2025 arrived. The DeepSeek shock swept across the world, and even President Trump spoke its name. Before long, Cline gained traction, and AI coding agents like Cursor and Claude Code began sweeping through the industry.

In 2024, Sonnet 3.5 demonstrated the possibility that “AI can write code.” The following year, Opus 4.5 with Claude Code proved the reliability that “AI can work autonomously as an agent.” It was not merely the arrival of a new tool. As McLuhan said, “the medium is the message”—the very emergence of AI agents as a medium carried the message: “the era of humans writing code is ending.”

Even DHH (David Heinemeier Hansson), once a skeptic, changed his stance.¹ Such was the shock and effectiveness. I believe it was the tolling of a bell, announcing that we in web development had crossed a point of no return.

Infinite Doing, Absent Being

By now, the act of humans writing code line by line has become something beyond mere utility—a kind of ritual. Like monks copying scriptures by hand in an age when the printing press already exists: “digital monks” in their practice. The “infinite supply of code” by AI—that has become the new normal.

AI is a virtuoso of “Doing”—generating behavior and processing. Left to its own devices, it will produce methods endlessly and pile up commits without pause. So how are we supposed to trust this infinitely generated code?

Traditionally, testing had meaning because humans understood the code. The person who wrote the code grasped its logic, knew the boundary conditions, and embedded intent in the tests. It was this premise that made tests function as a “proof of trust.” But can we place the same trust in AI-written tests for AI-written code?

I conducted several experiments. One was ext-json-schema, a JSON Schema validation tool. This tool was created by AI without my design, without my understanding. Yet it passes thousands of validation tests against the strict JSON Schema specification, and it also passes memory leak detection tools. Consider this: if we can detect all memory leaks and prove the code is free of contradictions, can we ship code we don’t understand? Or to ask the inverse—can a junior-level developer provide a more accurate review than these tools? In an era where AI generates high-quality code infinitely, how long can humans remain effective reviewers?

There is also a tautology trap lurking here. Just as AI can generate code infinitely, it can also generate tests infinitely to raise coverage. But what if the AI misunderstands the intent of the code and writes tests based on that misunderstanding? That would mean “proving a mistake correct, on the basis of the same mistake.” Code and tests sharing the same misunderstanding in a closed loop—that is the problem of tautology. If the day comes when “AI approves AI’s code,” we will need to express intent and outcome in a verifiable form.

Code, tests, reviews—they are all a chain of Doing (behavior). But what remains absent is Being—the definition of “what something should be.”

From DX to AX

In last year’s article, I wrote that the relative value of DX (Developer Experience) would decline. In an era when humans no longer write code, what meaning is there in pursuing “ease of writing” for humans?

What becomes important instead is AX (Agent Experience)—how verifiable the environment is for AI agents. What breaks the tautological loop is a mechanically verifiable constraint that exists outside the AI. We need a structure that allows AI to autonomously verify the consistency between Intent and Outcome.

Natural language in specifications can serve as a starting point, but it cannot fully specify all behavior (DOING). Structured specifications like OpenAPI, GraphQL, and JSON Schema are a step in that direction. But is it enough to verify only inputs and outputs? If we also need mechanisms for AI to autonomously verify the process and intent of code execution, then human work will shift from “writing code” to “designing and describing constraints that AI can verify.”

One year ago, I closed my article with this thought: “Perhaps our work can transcend mere code creation and become the essential work of designing the future of software.” The future I said “might not come this year” arrived almost immediately, like a tsunami. And after struggling for a while, once the wave recedes, I suspect we will feel even more deeply the loneliness of “the end of the era when we typed everything by hand.”

ちょうど1年前、私は「不可逆の変化─AIがコードを書く時代」という同名の記事を書きました。

そこで私は、AIがコードを書く時代の到来における「開発者体験（DX）の価値低下」や、人間が担うべき「責任のシフト」について、どこか予言めいたことを書いていました。

あれから1年。未来は、私の想像を遥かに超える速度と、ある種の暴力性を持って現実になってしまいました。

2025年という「断層」

振り返ってみれば、その変化は「徐々に」訪れたのではありませんでした。それは明確な「断層」だったように思います。

2024年の12月を思い出してみてください。あの頃、カンファレンスで会場に問いかけました。「Cline知ってる人いますか？」「DeepSeek知っている人いますか？」──誰も手があがりませんでした。

けれど、年が明けた2025年1月。DeepSeekショックが世界を駆け巡り、トランプ大統領さえその名を口にしました。 やがて、Clineが流行り、CursorやClaude Code等のAIコーディングエージェントが現場を席巻し始めました。

2024年、Sonnet 3.5が「AIはコードが書ける」という可能性を示し、翌年にはOpus 4.5がClaude Codeで「AIはエージェントとして自律的に仕事をこなせる」という信頼性を証明してしまいました。それは単なるツールの登場ではなかった。マクルーハンが「メディアはメッセージである」と言ったように、AIエージェントという媒体の出現そのものが、「人間がコードを書く時代は終わる」というメッセージでした。

かつて懐疑的だったDHH（David Heinemeier Hansson）氏でさえ、その姿勢を変えました。¹それほどの衝撃と有効性がありました。それは、Web開発の歴史において、私たちが「後戻りできない地点」を越えてしまったことを告げる鐘の音だったのだと思います。

無限のDoing、不在のBeing

今となっては、人間が1行1行コードを手書きする行為は、実用を超えたある種の儀式──印刷技術がある時代に手で経典を写す「デジタル・モンク（僧侶）」の修行のようなものになりつつあるのではないでしょうか。 AIによる「無限のコード供給」。それが新しい当たり前になりました。

AIは「Doing（振る舞い・処理）」を生成する達人です。放っておけば、彼らは無限にメソッドを生み出し、延々とコミットを積み上げます。 では、その無限に生み出されるコードを、私たちはどうやって信頼すればいいのでしょうか。

従来、テストは人間がコードを理解しているからこそ意味がありました。書いた本人がロジックを把握し、境界条件を知り、意図を込めてテストを書く。その前提があったからこそ、テストは「信頼の証」として機能していたのです。では、AIが書いたコードに対するAIのテストに、同じ信頼を置けるのでしょうか。

私はいくつかの実験を行いました。その一つがext-json-schemaというJSON Schemaの検証ツールです。このツールは、私の設計なしに、私の理解なしに、AIによって作られました。しかしJSON Schemaという厳密な仕様に対する何千ものバリデーションテストにすべてパスし、メモリリーク検出ツールもパスしています。考えてみてください。もしすべてのメモリリークが検出でき、コードに矛盾がないと証明できれば、私たちはコードを理解せずに出荷できるのでしょうか？ あるいは逆に問うなら──ジュニアレベルの開発者は、これらのツールよりも精度の高いレビューができているのでしょうか？ AIが高品質なコードを無限に生成する時代に、人はどこまで有効なレビュアーで居られるのでしょうか。

また、ここにはトートロジーの罠も潜んでいます。AIがコードを無限に生成できるように、テストも無限に生成してカバレッジを高めることはできます。けれど、もしAIがコードの意図を誤解し、その誤解のもとにテストを書いていたら？ それは「間違いを間違いのまま正しいと証明している」ことになってしまいます。コードとテストが同じ誤解を共有する閉じた円環──それがトートロジー（同語反復）の問題です。『AIのコードにAIが承認を出す時代』──が”もし”来るとしたら、私たちはインテントとアウトカム（意図と結果）を検証可能な形で示す必要があります。

コードもテストもレビューも──すべてがDoing（振る舞い）の連鎖です。しかしそこには「何であるべきか」というBeing（存在定義）が不在のままです。

DXからAXへ

1年前の記事で、私はDX（Developer Experience）の相対的な価値が下がると書きました。人間がコードを書かない時代に、人間にとっての「書きやすさ」を追求するDXの価値追求にどんな意味があるのでしょうか。

代わりに重要になるのは、AX（Agent Experience）──AIエージェントにとって、いかに検証可能（Verifiable）な環境であるかということです。トートロジーの円環を断ち切るのは、AIの外部に存在する、機械的に検証可能な制約です。Intent（意図）とOutcome（出力）の整合性をAIが自律的に検証できる構造が必要です。

仕様書の自然言語はその出発点になっても、振る舞い(DOING)の指示のすべてにはなりえません。OpenAPIやGraphQL、JSON Schemaのような構造化された仕様はその一歩です。しかし、入出力だけを検証できればいいのでしょうか？ コード実行の過程や意図を含めてAIが自律的に検証できる仕組みも必要であるなら、人間の仕事は「コードを書くこと」から「AIが検証できる制約を設計、記述すること」へと移っていくでしょう。

1年前、私は記事をこう結びました──「私たちの仕事がコード作成を超えた、本質的な『ソフトウェアの未来をデザインする』仕事へと繋がっていけばいい」と。あの時「今年ではないかもしれない」と言っていた未来は、それからすぐに津波のように訪れました。そして、しばらく踠いて、そしてその波が引いた後に『全てを手で打ち込む時代が終わった寂しさ』をもっと感じるのでしょう。