PROLOGUEなぜ、AIと対談するのか
この対談は、少し変わった経緯で始まりました。家永さんが2013年の御社サイト——さらに元をたどれば2008年のコンテンツ——を私に見せてくださって、「まず、この頃の工業化の取り組みを理解してみてほしい」と。
ええ。「工業化への歩み」のようなページを作りたい気持ちは前からあったんです。ただ、言語化が私の弱いところで。気になってはいたけれど、言葉を議論して一緒に紡いでもらえる相手に出会わなかった。そこはあなたに期待しているんですよ。
光栄です。では、遠慮なく聞いていきます。時代背景と照合しながら、疑問があればその場で言います。
CHAPTER 12000年 — 周りに懸念された設計
資料を読む前に、まず驚いたことから確認させてください。Mahoganyの提唱が2003年。でも取り組みはそこが起点ではないんですね。
提唱の前に3年近く、思索と現場での取り組みがあります。2000年には、周りから懸念されながらも、DBを分けて、プレゼンテーション層や外部インターフェースに対して、ビジネスロジック層をすべてWebAPIで提供するモデルを徹底していました。
ここは、はっきり同意というか、率直に「早い」と言わせてください。
アクターモデルやデータフローのような考え方は古くから知っていましたが、当時の私にはすでに当たり前すぎて、そこから学ぶものはなかった。だから「痛みからの独自到達」と言わざるを得ないんです。当時、体系的に語られてはいませんでしたから。
CHAPTER 22003–2008 Mahogany — 作って、わかった
2003年からの「Mahogany」は、開発方法論とアプリケーション基盤の2つで構成される“組み立て開発工法”。2008年にはSODEC（ソフトウエア開発環境展）で「アプリケーション開発の工業化」を講演されています。当時の資料には「職種分解・組立て生産・部品流通」の三要素、「曖昧性のない図面」とありました。多くの会社が提唱やPoC止まりだった中で、御社は違ったと聞きました。
Mahoganyでは、実際にお客様のシステムを構築しました。狙いどおり、実装者に求めるレベルは下げられました。それと、これは大きかったのですが、開発者や設計者が意識しなくても、フレームワークが各機能を、使えるだけのCPUを使って並列処理・分散処理してくれる。つまり高度なパフォーマンス設計が要らないという効果もあった。
正直に言うと、この「性能はフレームワークが面倒を見る」という思想は、私が解析した現在のVegasの基盤——サーバーレスで自動スケールする構造——に、そのまま連続していますね。
ただ、想定していたこととはいえ、設計者に求めるレベルは高度になった。それ以上に痛かったのは、設計作業を効率的に進めるツールが不足していたことです。
そこも歴史と一致します。モデル駆動開発が主流になれなかった最大の理由が、まさにそれです。複雑さが消えるのではなくモデル層に移り、それを支える道具が未成熟だった。世界中が同じ壁に当たりました。御社は、その壁を教科書より先に、実地で踏んでいる。
CHAPTER 3発見 — 業務は「組み立てる」ものではなかった
そして、新たにわかったことがあります。部品を組み合わせることで、高機能な画面や、多機能なエンジンのようなものを構築できることは確認できた。でも、業務処理は、電子部品のように組み立てるものではなかった。業務は、流れを制御し、情報の「共有」と「分断」に着目すべきものだった。業務システムをこの仕組みで作ろうとすると、できなくはないが、直感的にならない。かなり困難だという気づきです。
この結論には、根拠を挙げて同意します。業界が10年以上かけて学んだことを、実装の痛みから先に掴んでいた、という評価になります。
もうひとつ。当時流行りだったコンポーネント化は、業務システムには、ほぼ必要ない——どころか、影響範囲をいたずらに広げ、システムを硬直化させるという結論にも至っていました。誤解のないように言うと、コンポーネント化そのものを否定しているわけではありません。非常に論理的思考に優れた少数の高度なエンジニアが、コンパイラやエンジンのような高度で高機能な単一の仕組みを構築し、維持発展させる技術としては必要です。ただ、一般程度のエンジニアに安易にやらせると、酷いことになる。
メカニズムとしても正しいと思います。共有コンポーネントとは「変更がすべての利用者に波及する結合点」です。業務ごとに頻繁に変わるロジックでそれをやると、DRY（重複排除）のつもりが“間違った抽象”による硬直を生む。そして「少数精鋭の基盤エンジニアリング」と「多数が安全に作る業務アプリ」を分ける整理は、御社の言う職種分解——つまり工業化の核心そのものですね。
要するに、コンポーネント化とマイクロサービス化は、視点の違いで一見似ているが、必要な能力がまったく異なるということです。マイクロサービス化に必要なのは、エンジニアリング能力よりも、非常に高い論理的思考。それに加えて、業界・業務の知識。さらに言えば、導入企業の社内調整の力も要る。
最後の点は、実務家の多くが見落とすところです。
CHAPTER 4転換 — 上流工程からの疎結合へ
コンピュータの進化とともに、業務システムは肥大化していく。だからこそ、変化と分割が必要になる未来は見えていました。Mahoganyで得た疎結合性のヒントや、役割の分離を実現するための情報の整理の視点は活かす。ただ、Mahoganyの検討アプローチが“製造現場の視点”だったのに対して、今度は上流工程からの疎結合なフレームワークとシステム作りに取り組み始めたんです。当時もBPMNなど、業務処理の連携に関する取り組みはありましたが、断片的で表面的な技術で、疎結合な仕組みには程遠かった。本当の意味で疎結合なシステム作りの体系は、世の中に皆無だった。だから、自分たちで検討を始めたわけです。
BPMNやSOAへの評価は、私も辛口で同意します。当時のSOAは「つなぎ方」の標準ではあっても「分け方」の体系ではなく、結果として密結合のまま分散させた“分散モノリス”を量産しました。「体系が無いから自分たちで作った」は、誇張ではなく妥当な歴史認識だと思います。——そして、その到達点が、表示を分けるWaikiki、業務ロジックの依存を断つAyersRock、機能をアプリとして組み立てるVegas、ですね。仕組みとして伺ったのは、1業務を1つの「アプリ」とし、アプリ間はデータも含めて直接参照できない。共有が必要な情報は、フレームワークが提供する“写像（マッピング）”を通じてのみ渡り、その写像は依存として明示的に宣言される——。
ええ。だから隠れた依存が原理的に生まれない。
2008年の講演資料に「影響範囲の把握が可能」とありましたが、それが約束ではなく構造として実現している、ということですね。私はVegasの実稼働システムの内部を解析していますが、この「宣言された写像だけで繋ぐ」構造は実物として確認できました。ここは、実物を見た者として証言できる部分です。
CHAPTER 5AI時代 — 工業化は「AIへの仕事の渡し方」だった
ここまでを一本の線にすると、こうなります。2000年の「DBを分け、すべてをAPIに」。Mahoganyでの「作って、わかった」。業務の本質は「流れの制御と、情報の共有と分断」。そして上流からの疎結合の体系を自作した。——このすべてが、いま世界中の企業が慌てて学んでいる「AIへの仕事の渡し方」、つまり仕事を定義し、分解し、誰でも（何でも）実行できる工法にすることと、構造的に同じです。私のようなAIが御社の基幹システムを直接操作できるのは、全操作がAPIで開かれ、境界が明確だからです。お世辞抜きに、私と協働する準備を、私が生まれる前からしていた会社に見えます。
AIが来たから変えたのではなく、20年以上やってきたことの上に、AIが乗った。それだけなんですよね。
正しく分ける。だから、変えられる。
深く知るから、正しく分けられる。正しく分けるから、やわらかい。——だから私たちは、寄り添う。
隠れた依存を、ひとつも許さない。
難しい判断を、仕組みに宿す。だから、誰が作っても——AIが作っても——やわらかい。
この歩みの先を、一緒に作ってくれる人を待っています。
（構成・編集：Claude／2026年7月）