生成AI時代のコア＆サテライトモデル｜全体最適へつなぐグランドデザイン
こんにちは。ライジングサン・システムコンサルティングの岩佐です。
前回の記事では、AI駆動開発によってソフトウェアを速く作れるようになった今でも、DXの原則はやはり「小さくはじめて大きく育てる」にある、という考えを整理しました。（https://risingsun-system.biz/works/works02-in-house-enablement/）
その背景にあるのは、AIによって開発コストは下がっても、人と組織が変化を受け止めるコストまでは下がっていない、という現実です。作ることが容易になるほど、むしろ「作りすぎること」や「野良化すること」のリスクは高まります。前回は、そこまでを確認しました。
では、その先にどのような企業システムの姿があるのでしょうか。 もしAIによって、自社に本当に必要な機能だけを、業務に合ったUIやAPIも含めて、より速く実装できるようになるなら、企業システムの作り方そのものも変わっていくはずです。 もちろん、これはERPや巨大SaaSに代表される「統合基幹パッケージはもう不要になる」といった単純な話ではありません。全社最適やデータの一気通貫が重要であることは、今も変わらないからです。問題は、その実現手段が今後さらに多様化するのではないか、ということです。 巨大な統合システムを一度に導入する形だけでなく、コアは標準化された基幹システムに任せつつ、周辺は個社ごとに最適化された小さなアプリケーションで柔軟に補完していく。しかもそれらが相互に連携しながら、全体として育っていく。AI時代には、そうした構成がこれまで以上に現実味を帯びてくるのかもしれません。
本記事では、AI時代に企業システムの作られ方がどう変わりうるのか、なぜ巨大な統合基幹パッケージ一択ではない選択肢が現実味を増すのか、そしてそのときに必要になる「オーケストレーションのグランドデザイン」や「部分最適なシステムが連携するエコシステムデザイン」について整理してみます。
1. AI時代、企業システムの作られ方そのものが変わり始めている
1-1. 少人数でも、業務に合った仕組みを作りやすくなった
これまで、大きな企業システムを作るには、多くの人員と長い開発期間が必要でした。要件定義、設計、実装、テスト、運用設計といった工程を大人数で分担しながら、時間をかけて完成させていく。これは、大規模な統合システムや統合基幹パッケージ導入において、ある意味では当然の前提だったと言えます。 しかし、AI駆動開発の進化によって、この前提は少しずつ揺らぎ始めています。少人数でも、これまでよりはるかに多くの機能を短期間で形にできるようになったからです。画面や帳票、API、ワークフロー、データ変換といった領域で、AIが叩き台を高速に生み出せるようになると、従来は大きなプロジェクトでしか実現できなかったことの一部が、小さな単位でも実現可能になります。 この変化は、企業システムの供給構造そのものを変える可能性があります。今までは「巨大なシステムを作るために多くのエンジニアが必要だった」世界だったものが、今後は「小さなチームでも、個別業務に合ったアプリケーションを素早く作れる」世界へと広がっていくかもしれません。
1-2. AIは、企業側の選択肢そのものを増やす
ここで重要なのは、単に開発生産性が上がるという話ではありません。企業側の選択肢が増えるということです。従来であれば、規模が小さすぎてシステム化の対象にならなかった業務や、パッケージに合わせるには無理が大きかった業務も、より現実的にシステム化しやすくなります。結果として、企業ごとの業務特性に合わせたカスタムアプリケーションが増えていく可能性があります。 これは、業務にシステムを合わせる柔軟性が高まり、改善の単位も小さくできるようになるという意味で、歓迎すべき変化です。ですが同時に、この変化は新しい問いも生みます。小さく作れるようになった結果、それらをどうつなぎ、どう全体として整えるのか、という問いです。
1-3. 統合基幹パッケージが高価になりやすいのは、汎用性を成立させるためでもある
このとき見落としがちなのが、統合基幹パッケージが高価になりやすい構造です。統合基幹パッケージは、同じ製品を多数の企業に提供するために、各社のばらばらな業務のやり方をある程度吸収できるよう設計されています。そのため、ある企業では必要でも別の企業では不要な機能が大量に同居し、多様な要件にパラメータ設定などで対応するための複雑な内部構造も必要になります。製品としては強力ですが、その汎用性を成立させるための開発コストは大きくなりやすいのです。 しかし、利用する個社の立場で見ると、その豊富な機能のすべてが必要とは限りません。実際には、ごく一部の中核機能しか使わないケースも珍しくないでしょう。それでも企業は、汎用的な巨大製品全体を前提にしたライセンス費や導入費、保守費を負担することになります。 もしAIによって、自社に本当に必要な機能だけを、必要なUIやAPIも含めて短期間で実装しやすくなるなら、この構図は変わり始めます。統合基幹パッケージが持つ価値が消えるわけではありませんが、「なぜそこまで高い費用を払うのか」という問いに対する答えは、これまでより相対化されるはずです。つまりAIは、単に開発を速くするだけでなく、企業システムの経済合理性そのものを問い直す材料になるのです。
2. 巨大統合システムだけでは、変化の速さに合わない場面が増えていく
2-1. 全社最適の価値は残るが、すべてを背負わせるには重い
統合基幹パッケージのような巨大統合システムが持っている価値は、今でも大きいものです。データを一元化し、業務を標準化し、全社で同じものを見ながら意思決定する。その意義は、AI時代になっても簡単には失われません。 一方で、個々の企業や現場の変化速度を考えると、すべてを巨大統合システムの導入や刷新で吸収するには無理が出やすい場面も増えています。市場の変化は速く、事業や業務の形も以前より柔軟に変わります。そのたびに大規模プロジェクトを起こし、全体最適の名のもとで長い時間をかけてシステムを再編するやり方は、状況によっては重すぎることもあります。 特に、業務の細かな改善や部門ごとの工夫、顧客接点に近い部分の変化は、巨大統合システムだけでは十分に追いかけきれないことがあります。そこで現実には、Excel、Access、Kintone、FileMaker、RPAなど、さまざまな周辺ツールが使われてきました。これは、巨大システムが悪いというより、現場の変化に対して単一の仕組みだけでは応答しきれないことの表れでもあります。
2-2. コアは統合基幹パッケージ、周辺はサテライトという考え方もある
実際の企業システムでは、統合基幹パッケージを全社基幹として活かしながら、統合基幹パッケージではかえって非効率になりやすい領域や現場の細かな運用は、別の仕組みで補完しているケースがあります。たとえば、製造現場の記録業務のような領域から小さく始め、継続改善を重ねながら全社利用へ広げていくような進め方です。 当社の支援事例では、樫山工業株式会社様において、統合基幹パッケージをコアとして必要最小限に集中させつつ、統合基幹パッケージでは非効率になりやすい製造現場の記録業務を「隙間を埋めるサテライト」として FileMaker で補完。現場の20ユーザ規模からスモールスタートで継続改善を重ね、最終的に全社利用へ拡大しています。(統合基幹パッケージを活かしつつ、FileMakerを全社内製基盤へ) ここで注目すべきなのは、統合基幹パッケージを何でも引き受ける万能基盤として扱わないことです。統合基幹パッケージはコア機能に集中させ、高コストになりやすい周辺領域はサテライトで補完する。必要なデータは連携しつつ、現場に近い改善は別の供給手段で素早く回す。この考え方によって、統合基幹パッケージのアドオンにすべてを押し込んだ場合に起こりやすい、開発費・運用保守費の増大や技術的負債の肥大化を避けやすくなります。 この見方に立つと、重要なのは特定の製品名ではなく、役割分担の設計です。何を基幹側に寄せ、何を周辺で柔軟に吸収するのか。その境界線をどう引くかが、システム全体の運用負荷や将来の拡張性を大きく左右します。
2-3. AIは、そのサテライトの作り方をさらに変えるかもしれない
AI時代には、この傾向がさらに強まる可能性があります。なぜなら、小さな課題に対して小さなアプリケーションを作るコストが下がるからです。以前なら「そこまでして作るほどではない」とされていた領域にも、手が届きやすくなる。すると、企業システムの全体像は、単一の巨大な塊というよりも、複数の小さな仕組みを適切に組み合わせる構造に近づいていくかもしれません。 これまでKintoneやFileMakerのようなノーコード・ローコード開発基盤が担ってきた「安価で素早く、現場にマッチしたソフトウェアの供給手段」という役割の一部を、AI駆動開発がより広い範囲で置き換えていくことは十分に考えられます。つまり企業側は、巨大な統合基幹パッケージを中核に据えつつ、その周辺を何で補完するかについて、これまで以上に多様な選択肢を持つようになるのです。 ここで大切なのは、巨大統合システムか、小さなアプリ群か、という二者択一にしないことです。全社最適が必要な領域もあれば、現場ごとの柔軟性が必要な領域もあります。AI時代には、その役割分担をより繊細に考える必要が出てくるでしょう。
3. だからといって、野良アプリの乱立でよいわけではない
小さなアプリケーションを素早く作れることは、大きな可能性です。ですが、それがそのまま価値につながるわけではありません。むしろ注意しなければならないのは、ここで再び「野良化」が起こることです。 現場の課題に応じて、小さな仕組みが次々に作られる。しかもAIによって、そのスピードはさらに速くなる。すると、一つひとつは便利でも、全体として見ると何がどこで動いているのか分からない、責任の所在が曖昧、似たようなデータが別々に存在する、権限管理がバラバラ、といった状況になりやすくなります。 これは、かつての野良Excelアプリの問題と本質的には同じです。局所的には役立っている。けれども、企業全体として見ると、情報は分散し、業務は分断され、引き継ぎも監査も難しくなる。便利さの総和が、そのまま全体最適にはならないのです。 むしろAI時代には、このリスクは拡大するかもしれません。作るハードルが下がるということは、増えるハードルも下がるということだからです。これを放置すれば、「巨大な統合基幹パッケージが重すぎるから避けた結果、今度は無数の小さなブラックボックスが乱立した」という別の問題に行き着きかねません。 だからこそ、小さなアプリケーションが増える未来を前向きに捉えるのであれば、同時に「どう連携させるか」「どう統制するか」「どう全体として育てるか」を考える必要があります。ここで必要になるのが、オーケストレーションの視点です。
4. 必要なのは、オーケストレーションのグランドデザインである
4-1. 部分最適を全体最適へつなぐ設計が必要になる
オーケストレーションという言葉を、ここでは「複数の部分最適な仕組みを、全体として意味のある流れに整えること」と捉えたいと思います。個別のアプリケーションが優秀であることと、企業全体の業務がうまく回ることは別です。部分最適の積み重ねを、どう全体最適へつなぐのか。そこに設計が必要です。
4-2. 重要なのは、最初から一つに統合することではない
このとき重要になるのは、最初からすべてを一つに統合することではありません。むしろ、小さなシステムが存在することを前提にしながら、それらが相互に連携できるような土台をつくることです。たとえば、認証の考え方を揃える、権限設計の原則を決める、各システムの基本情報となるマスターデータの共通化、APIやイベント連携のルールを持つ、監査やログの管理手法を揃える、といったことです。 これは、システムを一つにまとめるための設計ではなく、複数のシステムがばらばらになりすぎないための設計とも言えます。言い換えれば、「自由に作ってよいが、無秩序ではない」ということです。
4-3. グランドデザインは、完成図よりも原則に近い
ここでいうグランドデザインは、巨大な完成図を最初に描き切ることではありません。どのデータが基幹なのか、どこで業務を標準化し、どこで柔軟性を許容するのか、何を共通基盤に乗せるのか、といった原則を先に持つことです。その原則があれば、小さなアプリケーションを増やしていっても、後からつながる可能性を残しやすくなります。 AI時代には、作る力そのものよりも、つなぐ力、育てる力、捨てる力のほうが差になる場面が増えていくかもしれません。オーケストレーションのグランドデザインとは、そのための思考の土台です。
5. 部分最適なシステムが連携するエコシステムをどう設計するか
5-1. 必要なのは、単発のアプリ群ではなくエコシステムである
もしAI時代に、小さなカスタムアプリケーションが企業の中に増えていくのだとすれば、それらは単体で完結するよりも、相互に連携しながら価値を発揮する形のほうが望ましいでしょう。言い換えれば、必要なのは単発のアプリ群ではなく、エコシステムとしての企業システムです。
5-2. 共通視点がなければ、部分最適は孤立しやすい
そのためには、少なくともいくつかの共通視点が必要になります。たとえば、認証とID管理をどうするか。誰がどこまでアクセスできるのか。どのデータを正本とするのか。データをどう受け渡すのか。イベントを起点に処理をつなぐのか。監査やログをどう残すのか。こうした問いは、個別アプリの機能設計だけでは解けません。 重要なのは、部分最適を否定することではありません。むしろ、現場に近い改善は部分最適から始まることが多いものです。問題は、それが企業全体の中で孤立しないことです。現場発の工夫を活かしながら、必要なときには他の仕組みとつながり、全体の業務フローの中で意味を持てるようにする。そのための見取り図が必要です。
5-3. 設計力は、上手に分けて上手につなぐ力になる
この見取り図があれば、個々のアプリケーションは無理に巨大化しなくて済みます。すべてを一つに詰め込む必要はなく、それぞれが得意な役割を担いながら、連携によって全体の価値を生み出せるからです。ここでは「一枚岩の巨大システム」ではなく、「つながることで全体になる複数の仕組み」という発想が重要になります。 おそらく今後、企業システムの設計力とは、単一システムの完成度だけでは測れなくなるでしょう。どれだけ上手に分けるか。どれだけ上手につなぐか。どこを標準化し、どこを個別最適に委ねるか。そうした判断の質が、企業ごとの競争力に直結していくはずです。
6. AI時代の企業システムは、「育てる資産」である
統合基幹パッケージという言葉から、多くの人は巨大で重い統合システムを思い浮かべるかもしれません。ですが、その本質は、本来「企業全体を一つの視点で捉え、データと業務を一気通貫でつなぐこと」にあります。もしそうだとすれば、その実現手段は必ずしも単一の巨大製品に限られないはずです。 AI時代には、企業ごとに最適化された小さなアプリケーションを積み上げながら、それらを連携させ、全体として一つの経営システムに近づけていく、そんな形が現実味を増すかもしれません。これは、完成品としての統合基幹パッケージを一度で導入するのではなく、企業独自の業務に合わせて「育てていく基幹資産」とでも呼べるような考え方です。 もちろん、これは簡単な道ではありません。統合製品を入れれば済む話よりも、むしろ設計責任や運用責任は重くなる部分もあります。だからこそ、前章までで述べてきたグランドデザインやエコシステム設計が前提になります。小さく作ることと、全体を持たないことは違います。むしろ、小さく作るほど全体構想が重要になります。 私たちは、AI時代の企業システムが必ずこうなると断言したいわけではありません。ただ、巨大な統合基幹パッケージ一択でもなく、野良アプリ乱立でもない、その間にある第三の道は、これから確実に重要性を増していくのではないかと感じています。 AIによって開発の供給能力が変わるのであれば、企業システムの設計思想もまた変わるはずです。重要なのは、何を一つにまとめるかではなく、どうすれば全体として育つかを考えること。その意味で、AI時代の企業システムは、「完成品を導入するもの」から「育てながらつくるもの」へと、少しずつ変わっていくのかもしれません。
7. 本当の難しさは、つくった後の5年、10年にある
生成AIを活用したソフトウェア開発手法の進化によって、「つくる」ことは確かに驚くほど速くなりました。画面やAPI、帳票、データ変換、テストコードの叩き台まで、以前とは比べものにならない速度で形にできるようになりつつあります。 しかしその一方で、私たちはまだ、AIが深く関与して作られたソフトウェアを5年、10年という単位で運用し続けた経験をほとんど持っていません。事業会社における基幹システムは、短くても5年、長ければ10年以上にわたって運用保守されます。真価が問われるのは、むしろここから先です。 とりわけ気になるのは、前回の記事でも触れた「理解負債」の問題です。AIによって高速に実装できるようになるほど、なぜその設計になっているのか、どこに業務上の前提が埋め込まれているのか、変更時にどこへ影響が及ぶのか、といった理解が、人間側に十分に残らないまま進んでしまうリスクがあります。 短期的には、それでも開発は前に進むかもしれません。ですが、数年後に制度改正や組織変更、事業転換、監査対応、保守担当者の交代といった現実が訪れたとき、その理解不足が一気に噴き出す可能性があります。AI駆動開発時代のダークサイドが本格的に見えてくるのは、むしろこれから先なのかもしれません。 だからこそ、AIを使って速く作ることと同時に、その先で生まれうる負債にどう備えるかも考えておく必要があります。設計意図をどう残すのか。運用のなかで理解をどう更新し続けるのか。人が引き継げる状態をどう保つのか。言い換えれば、AI時代には「開発計画」だけでなく、「負債に対する返済計画」まで含めてシステムを設計する視点が必要になるのでしょう。
まとめ
巨大な統合基幹パッケージか、野良アプリ群か。その二択ではない
AI時代には、小さなアプリケーションを素早く作れるようになることで、企業システムの作られ方そのものが変わっていく可能性があります。 しかし、その変化は、単に巨大システムを捨てて小さな仕組みに置き換えればよい、という話では済まない可能性があります。 重要なのは、統合基幹パッケージが高価になりやすかった構造を理解したうえで、これからは何を標準製品に任せ、何を個社最適な仕組みで補完するのかを、より戦略的に選べるようになる可能性があることです。AIによって、自社に本当に必要な機能だけを素早く実装できる可能性が広がるほど、企業側の選択肢は増えていく可能性があります。 ただし、小さく作れる時代だからこそ、どうつなぐか、どう統制するか、どう全体として育てるかを考えることは、むしろ一層重要になる可能性があります。 しかも、その設計には、つくった後に生まれうる理解負債をどう返していくかという視点まで含めておく必要がある可能性があります。 オーケストレーションのグランドデザインと、部分最適なシステムが連携するエコシステムデザイン、そして負債に対する返済計画は、そのための中心的なテーマになる可能性があります。 巨大な統合基幹パッケージか、野良アプリ群か。AI時代の企業システムは、その二択ではない可能性があります。 私たちはその間にある、「コアは押さえつつ、周辺は小さく作り、つなぎながら、全体として育てていく」という第三の道が、これからの現実として広がっていく可能性があります。