AI時代、ソフトウェアは３層で考える 株式会社エブリーでCTOを務めている今井( @imakei_ )です。 本記事は AIブログリレー 第9本目 です。これまで自分は、組織OSや組織デザイン、AI活用の評価といった「AIを活かす土台」を、主に組織の側から書いてきました。今回はその視点を、作られるソフトウェアの側に移します。 結論を先に言うと、AI時代は ソフトウェアの作り方そのものを変える 必要があり、その鍵は ソフトウェアを3つの層で捉え、「長く残す Core」と「捨てて作り直せる Disposable な部分」の境界をどう引くか にある、と考えています。そしてこの境界を引く作業は、組織の回で触れた「オントロジー」を、今度はプロダクトの世界観として定義していく作業でもあります。難しいですが、だからこそ面白い。順に書きます。 「作って長く保守する」前提が崩れる きっかけは、Tuan-Anh Tran氏の "Architecture for Disposable Systems" という記事です。要点はシンプルで、 コーディングエージェントによって生成が安くなると、ソフトウェアは「作って、使って、捨てる」ものへと変わっていく 、というものです。 これまでは「一度作って、長く保守する」のが当たり前でした。作り直しが高くつくからこそ、丁寧に設計し、負債を返し、長期を見据えて磨いてきた。ところが、エージェントが数分で同等の代替物を作れるなら、その前提は崩れます。生成が安くなると、むしろ「保守し続けること」のほうが高コストになる。壊れたら直すより、捨てて作り直す——そういう作り方が合理になっていきます。 だとすれば、 ソフトウェアの作り方も、この変化に合わせて組み替えないといけません 。全部を等しく丁寧に磨く発想から、「何を残し、何を捨てるか」を設計する発想へ、です。 Core と Disposable の境界を、どう引くか ここが本題です。当然ながら、すべてを Disposable にできるわけではありません。参考記事は、ソフトウェアを三つの層で整理しています。長く生き残る Core （耐久コア＝中核のロジックやデータモデル）、それらをつなぐ Connectors （契約＝インターフェース）、そしてその上で動く Disposable な層 （UIやグルーコード）です。 大事なのは、 Disposable な部分を安心して捨てたり作り直したりできるのは、Core と Connectors が堅いからこそ 、という点です。逆に言えば、AIに任せられる範囲を広げたい——つまりAIを活かしたい——なら、まず「捨てない中心」をきちんと定義することが先になります。境界が曖昧なままAIに作らせると、捨てていいものと捨てられないものが混ざり、結局作り直せなくなる。 AIを活かすための第一歩は、実は「何を残すか」を決めることなのです。 そしてこの「捨てない中心を定義する」作業は、連載で書いてきた オントロジー の話とそのまま地続きです。組織の回では、会社の現実を「名詞・動詞・ルール」として定義する話をしました。同じことをプロダクトの側でやると、 そのソフトウェアの世界観を定義する ことになります。何が中心的な概念（名詞）で、どんな操作（動詞）が許され、どんな制約（ルール）があるのか。この世界観こそが Core であり、それを外に見せる形が Connectors です。 世界観がきちんと定義されていれば、その上に乗るUIや繋ぎこみは、AIに生成させ、要らなくなったら捨てて作り直せばいい。 世界観（オントロジー）を定義することが、そのまま Core と Disposable の境界を引くことになる ——ここが、組織の話とソフトウェアの話がつながるポイントだと考えています。 とくにアプリ開発では、境界がくっきりする ここまでは一般論ですが、自分の出身でもあるアプリ（モバイル）開発では、この Core と Disposable な層の境界が、より生々しくはっきりします。 サーバーサイドと違い、アプリは 利用者の端末にインストールされ、古いバージョンが世の中に残り続けます 。サーバーのように「作り直して即差し替え」とはいきません。だからこそ、簡単には捨てられない中心が明確です。クライアントとサーバーの通信契約（＝アプリにおける Connectors にあたる部分）、ローカルに溜まったデータのスキーマとマイグレーション、認証やセッションといったローカルの状態——このあたりは、Disposable にはできない Core です。ナビゲーションの構造も、Deep Link や通知の入口として外部と繋がっている限りは、簡単には作り変えられない Core 寄りの存在です。逆に、個々の画面やレイアウト、View まわりのコードは、生成して作り直せる Disposable な層に寄っていきます。 つまりアプリエンジニアの価値は、 一枚一枚の画面を手で磨くこと から、 アプリの世界観（ドメインモデル・状態の契約・デザインシステム）を定義すること へ移っていきます。ここで強調したいのは、これまで培ってきたUXやインタラクションへのこだわりが不要になるわけではない、ということです。むしろその感性を、 デザインシステムやコンポーネント、レビューの基準として Core 側に埋め込む 。そうすれば、生成された画面もその基準を満たすようになります。手で守っていた品質を、仕組みとして守る側に回る——これは、アプリエンジニアにとってむしろ面白い変化だと自分は思っています。 ここがいちばん難しい とはいえ、この境界を引く作業はかなり難しい。いくつか挙げます。 まず、 何を Core に置き、何を Disposable に落とすかの線引き そのものが難しい。間違えると、捨てられるはずの場所に大事なロジックが紛れ込み、まるごと作り直す羽目になります。 次に、 Connectors は「完璧に」保ち続ける 必要があります。Disposable 側を雑に作れるのは Connectors が堅いからこそで、「中は AI に任せて雑でいい」と「境界は完璧に」という 非対称な厳しさ を同時に成立させないといけません。 さらに、 データやユーザーの状態は簡単には捨てられません 。UIやロジックは作り直せても、蓄積されたデータや利用者からの信頼は作り直せない。捨てていいものと、絶対に捨ててはいけないものを見極める目が要ります。 そして最大の逆説は、 「作り直せる」前提が、かえって設計判断の重みを増す ことです。実装を磨く負担は減る一方で、「どこに境界を引くか」という判断の一発勝負の重要性が上がる。手を動かす難しさが、考える難しさへ移っていく、とも言えます。 だからこそ、これからのソフトウェアづくりは面白い この難しさは、そのまま面白さの裏返しだと思っています。 エンジニアの腕の見せ所が、 「実装をどれだけ丁寧に磨けるか」から、「世界観を定義し、何を残し何を捨てるかの境界を設計できるか」へ移る 。コードの美しさそのものより、捨てられる構造を見抜いて設計する力が問われる。かなり知的な挑戦であり、設計者としての醍醐味が詰まった仕事です。 忘れてはいけないのは、 Disposable を受け入れることは「雑に作る」ことではない という点です。むしろ逆で、「きれいに捨てられるように、世界観と境界を丁寧に設計する」という、より高度な仕事を求められます。 もう一つ、心構えとして大事なのは、 自分が書いたコードへの執着を手放せるか です。時間をかけて磨いたコードほど、捨てるのは惜しい。でも、これからは「惜しくて捨てられないコード」こそがリスクになり得ます。愛着の対象を、個々の実装から、それを生み出し続けられる世界観や境界のほうへ移していく。作品としてのコードから、更新され続ける仕組みとしての設計へ——この切り替えができる人にとって、これからのソフトウェアづくりはとても面白い時代になると思います。 おわりに AI時代のソフトウェアづくりは、「長く磨き上げる」一辺倒から、「世界観を定義し、Core と Disposable の境界を引く」営みへと変わっていきます。それは簡単ではありませんが、難しいからこそ、考えることそのものが面白くなる。組織で定義してきたオントロジーを、今度はプロダクトの世界観として引き直していく——その境界設計にこそ、これからのソフトウェアづくりの面白さがあると感じています。 出典・参考 本記事における「Disposable Systems」の考え方は、以下の記事を参考にしています。 - Tuan-Anh Tran, " Architecture for Disposable Systems "

セーフィー株式会社でサーバーサイドエンジニアを務めている尹です。 近年、AI エージェントやプロンプトエンジニアリングといった言葉が広く使われています。私自身、バックエンドの開発や社内ツールの自動化を進める中で、プロンプトの「使い捨て」に課題を感じていました。 通常、プロンプトはその場で書いて使い捨てるものとして扱われがちです。しかし、開発で繰り返し使う指示ほど、毎回ゼロから書き直すのは非効率で、書く人によって品質もばらつき、変更履歴も残りません。本来であれば再利用できるはずの指示が、資産として蓄積されずに失われてしまう――これが私の感じていた課題です。 本記事では、こうした使い捨てのプ

大規模なネイティブアプリ開発では、実装力だけでは解けない課題があります。iOSとAndroidが並走し、WebやBFF（Backend for Frontend）とも連携しながら機能を届ける。その一方...