ChatGPTのDeep Research（AI）での出力結果をそのまま掲載しています。ChatGPTのDeep Researchはハルシネーション（誤った情報の生成）が少なくなるよう調整されていますが、あくまで参考程度に読んでください。当記事は検索エンジンに登録していないため、このブログ内限定の記事です。
はじめに
近年、ソフトウェア開発の常識が大きく変わりつつあります。従来は一度書いたコードは資産と考えられ、再利用や保守が重視されてきました。しかし、生成AI（Large Language Modelを用いたコード自動生成など）の進化により、コードをその都度生成して使い捨てるという発想が現実味を帯びています (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン) (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。本記事では、こうした「使い捨てコード」の概念と背景、メリット・課題、そしてAmazonやGoogle、Microsoftといった企業での導入事例について解説します。さらに、AIが得意とするプログラミング言語や既存技術（AutoMLやTensorFlow Eager Executionなど）、GraphAIのような宣言型データフロー言語による非同期処理の解決策、そしてSNS上の最新議論・トレンドも紹介します。専門用語はできるだけ噛み砕き、初心者の方にも分かりやすいように説明します。
使い捨てコードとは何か？
使い捨てコードとは、その名の通り「使い終わったら捨ててしまうことを前提としたコード」です。プロトタイピングや一時的な目的のために素早く書かれ、長期的な保守や再利用をあえて考慮しないコードを指します。従来、ソフトウェアエンジニアはコードをできるだけ再利用し、拡張しやすく設計することを良しとしてきました。しかし一部の開発者は以前から「再利用よりも削除しやすさを優先すべき」と主張していました (Write code that is easy to delete, not easy to… — programming is terrible)。例えば2016年のあるエンジニアは「コードを再利用可能に作るのではなく、いっそ捨てられる前提で作るべきだ」と述べています (Write code that is easy to delete, not easy to… — programming is terrible)。なぜなら、コードは書けば書くほど保守コストが増えますが、不要なコードを削除すれば将来的な負担を減らせるからです (Write code that is easy to delete, not easy to… — programming is terrible)。このように、必要に応じて書いては捨てるという「使い捨てコード」の考え方自体は以前から存在していました。
しかし現在、この考え方が現実の開発手法として注目されています。その背景には後述するAI技術の発展があります。AIがコードを書くのを手助けしてくれる今、コード一行一行を大事に作り込むより、必要になったらAIに生成させ、不要になったら捨ててしまう方が効率的なケースが増えてきました (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン) (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。
背景：なぜ注目されるのか？
使い捨てコードが注目される背景には、ビジネスのスピードや技術トレンドの変化があります。
- 市場の変化のスピード：ソフトウェア製品やサービスの寿命が短くなり、次々と新機能を試す必要があります。プロトタイプやMVP（実用最小限の製品）を迅速に作り、ユーザーテストして軌道修正するようなアジャイル開発では、最初から完璧なコードを用意するよりも、まず動くものを作って不要になれば捨てる方が合目的です (Throwaway Functional Prototypes are a Waste of Time)。
- マイクロサービス化：システムを小さなサービス群に分割するマイクロサービスアーキテクチャでは、各サービスが比較的小規模で独立しています。そのため、一部サービスを作り直したり入れ替えたりしやすく、結果としてコードを使い捨てやすい環境になります (Disposable Microservices - InfoQ) (Monolithic vs Microservices - Difference Between Software Development Architectures- AWS)。例えば従来型のモノリシック（一枚岩）なシステムでは全機能が一つの巨大なコード基盤に詰め込まれていましたが、マイクロサービスでは「ユーザー管理」「投稿管理」など機能ごとにサービスが分かれており、それぞれ独立デプロイ可能です (Monolithic vs Microservices - Difference Between Software Development Architectures- AWS)。そのため不要になったサービスを削除したり、一から作り直したりしやすいのです (Monolithic vs Microservices - Difference Between Software Development Architectures- AWS)。
- 技術負債との向き合い：プロトタイプで書かれたコードがそのまま本番システムに流用されてしまうと、あとで保守が大変になる「技術的負債」を抱える恐れがあります (A Throw Away Code Mindset in Software Development - Modularis) (Throwaway Functional Prototypes are a Waste of Time)。本来はプロトタイプ（試作品）コードは捨てて、設計し直した上できれいに書き直すことが望ましいですが、ビジネス上の都合で捨てられず負債化するケースが多々ありました (A Throw Away Code Mindset in Software Development - Modularis) (Throwaway Functional Prototypes are a Waste of Time)。使い捨てコードの文化が根付けば、プロトタイプはあくまで使い捨て前提となり、本番用には改めて品質を確保したコードを書く、あるいは別途生成させるというメリハリがつけやすくなります。
利点：使い捨てコードのメリット
使い捨てコード戦略にはいくつかの利点があります。
- 素早い実験とイノベーション：細部の最適化や将来の再利用を気にせずにコードを書けるため、開発スピードが上がります (Should You Throw Away More Code than You Keep? - DEV Community) (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。思いついたアイデアをすぐ形にして試せるので、実験とフィードバックのサイクルを高速に回せます。特にUIの改良やA/Bテストなどでは、複数パターンの実装と検証をAIで高速化し、「当たったものだけ残す」ことも容易です (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。
- メンテナンス負荷の低減：必要が無くなったコードをためらわず削除できるため、システムに不要なコードが蓄積しにくくなります。結果としてコードベースが常にシンプルに保たれ、保守性が向上します。極端な例では「動いているコードは少ないほどバグも少ない」という考えもあり、「最も楽に削除できるコードは、そもそも書かずに済んだコードだ」という指摘もあります (Write code that is easy to delete, not easy to… — programming is terrible) (Write code that is easy to delete, not easy to… — programming is terrible)。
- 技術的負債を抱えにくい：上述のように、プロトタイプを本番コードに仕立て直す際に負債がクリアされます。早期に捨てて書き直す前提なので、「本当は良くない実装だけどこのまま…」といった妥協を将来に引きずりにくくなります。「コードは生み出した行数ではなく、削除した行数で評価すべきだ」とさえ言われることがあります (Write code that is easy to delete, not easy to… — programming is terrible)。
- チームの心理的メリット：開発者にとって、自分の書いたコードを捨てるのは本来勇気のいることですが、使い捨て前提であれば心理的な抵抗が少なくなります。「とりあえず動くものを出し、後で良いやり方が見つかれば全部書き換えればいい」と思えれば、挑戦的な実装もしやすくなります。その結果、新しい技術の採用や大胆なリファクタリングもやりやすくなるでしょう。
こうしたメリットから、特に短期利用のスクリプトやツール、フロントエンドの試作などでは「作って試したら捨てる」という使い捨て型が有効だと考えられています (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン) (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。実際、データ分析の現場では以前からJupyterノートブック上で一時的な分析コードを書いては捨てるという行為が日常的に行われてきました (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。アプリ開発でも同様に、一度きりの目的を達成するコードを生成→実行し、不要になれば破棄するという流れが整いつつあります (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。
課題：使い捨てコードの問題点
一方で、使い捨てコードには課題や注意点も存在します。
- コード品質の低下リスク：短期間で作って捨てる前提だと、どうしてもコード品質（可読性やエラーハンドリングなど）が二の次になりがちです。そのため、もし当初の予定に反してそのコードを長く使わざるを得なくなった場合、後で苦労することになります (Throwaway Functional Prototypes are a Waste of Time)。実際「プロトタイプだから」と急いで作ったものが、そのまま正式版になってしまい苦労する――というのは現場でよくある話でした。このリスクに対処するには、本当に捨てるべきか見極める判断と、捨て損ねた場合にリファクタリングする計画を持つことが重要です。
- 重複コードの増大：再利用をあまり考えずに書くので、似たような処理が各所に乱立する恐れがあります。DRY原則（Don't Repeat Yourself：コードの重複を避ける）が軽視される結果、バグ修正や仕様変更の際に複数箇所を修正する手間が増える可能性があります (Write code that is easy to delete, not easy to… — programming is terrible) (Write code that is easy to delete, not easy to… — programming is terrible)。ただしこの点については、「同じコードを何度もコピー&ペーストするくらいなら共通化を考える」といった現実的な線引きも提唱されています (Write code that is easy to delete, not easy to… — programming is terrible) (Write code that is easy to delete, not easy to… — programming is terrible)。すなわち、最初は重複上等で書き、十分な繰り返しが見えてきた段階で共通化すればよいというアプローチです (Write code that is easy to delete, not easy to… — programming is terrible)。
- 全てのコードが捨てられるわけではない：使い捨てに向くのはあくまで一時的かつ限定的な役割のコードです (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。例えばUIの細かな改善用コードや社内データ処理ツールなどは使い捨て可能ですが、ミッションクリティカルな基盤システムまで何でも捨てていては信頼性を損ねます (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン) (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。データベースのコア部分や決済システムのように高い安全性・正確性が求められる部分は、引き続き慎重な設計・テスト・保守が必要であり、むやみに書き捨てるべきではありません (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。要は取捨選択が大事で、どの部分を使い捨て型にし、どの部分を従来型（堅牢な設計）にするかの判断が求められます。
- 組織的な調整：使い捨てコードの手法を効果的に使うには、チームや組織の合意が必要です。コードをどんどん捨てて作り直すには、ビジネス側もその前提でスケジュールや予算を組む必要があります。もし経営者がその価値を理解していないと「なぜ使えるコードを捨てるんだ？」と不信感を持たれるかもしれません。しかし長期的には、新機能開発のコスト削減や市場への迅速な対応など利点があるため、その点を含めて組織内で教育・調整することも重要です。
以上のように、使い捨てコードは「魔法の銀の弾丸」ではなく、適材適所で使うアプローチと言えます。使う場面と捨てる勇気を見極めながら、AIなども活用して開発効率を高めることがポイントです。
大手企業にみる使い捨てコードの事例
では、AmazonやGoogle、Microsoftといった大手テック企業では、使い捨てコード的な発想がどう活かされているのでしょうか。各社の事例や取り組みから、その実態を探ってみます。
Amazonの場合：マイクロサービスと“捨てられる”アーキテクチャ
Amazonは早くからマイクロサービスアーキテクチャを採用した企業として知られます。巨大な通販サイトAmazon.comを支えるシステムは数千もの小さなサービスに分割されており、それぞれが独立してデプロイ・スケール可能になっています ( Microservices vs. monolithic architecture | Atlassian ) ( Microservices vs. monolithic architecture | Atlassian )（Netflixの事例ですが、Amazonも同様の方向性を採りました）。このような設計思想では、「あるサービスが古くなったり問題が起きたりしたら、そのサービスだけを廃棄して作り直せばよい」という発想が根底にあります (Disposable Microservices - InfoQ) (Disposable Microservices - InfoQ)。RedMonk社のアナリストJames Governorは「マイクロサービスにとって使い捨てであることは定義的な要素だ」と述べており、インフラストラクチャの不具合に対処するGoogleの手法（壊れたハードウェアは交換せず捨てる）にヒントを得た考え方だとしています (Disposable Microservices - InfoQ) (Disposable Microservices - InfoQ)。実際、クラウドの世界では「不調なサーバーは再起動や修復より破棄して新しいインスタンスに置き換える」という不変インフラ（immutable infrastructure）の考え方が一般化しており (Disposable Microservices - InfoQ)、AmazonもAWSでこれを推進しています。例えばAWSのオートスケーリンググループやコンテナサービスでは、個々のインスタンスはペットではなく家畜（故障したらすぐ取り替える消耗品）とみなされます。この延長線上に、ソフトウェアコンポーネントも使い捨て可能にするという発想があります。
さらにAmazonは近年、AIを活用してレガシーコードの自動変換・更新に取り組んでいます。2023年には社内向けのコード変換AI「Amazon CodeWhisperer/Q」を用いて、古いJavaコードを新しいバージョンにアップグレードする作業を大幅に効率化したと報じられました (Amazon CEO: AI-Assisted Code Transformation Saved Us 4,500 Years of Developer Work - Slashdot)。AmazonのCEOであるAndy Jassy氏は「このAI支援により4,500人年分もの開発工数を節約できた」と述べています (Amazon CEO: AI-Assisted Code Transformation Saved Us 4,500 Years of Developer Work - Slashdot)。同氏によれば、自動生成されたコード修正提案の79%は人手の追加修正なくそのままデプロイされたとのことです (Amazon CEO: AI-Assisted Code Transformation Saved Us 4,500 Years of Developer Work - Slashdot)。これらは直接「使い捨てコード」という文脈ではありませんが、古いコードを大胆に捨てて新しく置き換えることをAIでサポートする例と言えます。要するにAmazonでは、マイクロサービス＋クラウドネイティブ設計により「捨てやすい」土壌を作り、さらにAI活用でコードの新陳代謝を加速することで、迅速な開発サイクルを実現しているのです。
Googleの場合：プロトタイピングとAutoMLの活用
Googleは「ムーンショット思考」と呼ばれるように、大胆な実験やプロトタイピングを重ねる企業文化があります。数多くの試作プロジェクトやサービス（Google Labsや社内ハッカソンなど）を立ち上げては、上手くいかなければクローズするというサイクルを繰り返してきました。これはソフトウェア開発にも表れており、まず作ってみて、ダメなら捨てるというアプローチを許容する姿勢と言えます。実際、ソフトウェア工学の古典的な教えに「最初のシステムは捨てろ」というものがあります（フレデリック・ブルックス『人月の神話』の有名な一節です）。Googleも大規模システムを再設計する際に、一度目の実装を踏み台に二度目で完成度を高める、といったケースがありました。例えばGoogle Waveというプロジェクトでは、初期版を投入した後に方針転換し、最終的にサービス終了となった例もあります（ユーザーフィードバックを得て大胆に引き際を決めたケース）。このように、Googleはプロトタイプを積極的に作り、必要とあらば撤退・廃棄することでイノベーションを加速させています。
技術面では、Googleは開発効率を上げるツールやプラットフォームを多数提供していますが、その中にAutoMLと呼ばれるものがあります。AutoMLはプログラミングというより機械学習モデルの自動構築ツールですが、「コードを書かずに」高度なモデルやシステムを構築できるという点で、広義には「使い捨てコード」の考え方と親和性があります。具体的には、Google CloudのAutoMLを使うと機械学習の専門知識がなくてもデータセットさえ用意すればモデル作成からデプロイまで行えます (AutoML | A No Code Solution for Building ML Models)。例えば画像認識モデルをコードレスで作成し、使ってみて精度が悪ければ廃棄して別のモデルをAutoMLで再生成するといった具合に、試行錯誤を低コストで繰り返すことができます (AutoML | A No Code Solution for Building ML Models)。これは従来ならデータサイエンティストが何日もかけて書いていたコード（特徴量エンジニアリングやハイパーパラメータ調整）を省略できるため、「コードを資産として積み上げる」のではなく都度結果を得るための手段として消費するイメージです。
Googleはまた、ソフトウェア開発におけるAI活用にも熱心です。最新の開発環境では対話型AIでコードを生成・修正する機能（例：Duet AI for Google Cloud）を提供し始めています。これにより、Googleのエンジニアは必要なコードをその場でAIに書かせ、目的を達したら破棄することも容易になってきました。社内的にも膨大なコードベースを抱えるGoogleですが、古いサービスを廃止してコードをアーカイブし、新サービスにリソースを振り向ける決断を下すなど、プロダクト寿命に合わせたコードの生死管理を徹底しています。要するにGoogleでは、実験とプロトタイピングを素早く回しつつ、使えるものはすぐプロダクションに昇華し、そうでないものは潔く捨てる文化が根付いているのです。その裏には、AutoMLのようなコードレス開発や社内開発ツールの充実による開発コスト1/10化とも言える効率革命があり、「コードを大量生産して大量消費する時代」に備えているとも言えるでしょう (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン) (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。
Microsoftの場合：AIペアプログラミングとコードのリファクタリング
Microsoftは長年にわたり膨大なソフトウェア（WindowsやOfficeなど）のコードを維持してきた企業です。一見、「コード資産を育てる」側の文化が強そうですが、近年はクラウドやDevOpsの採用、そして何よりGitHub Copilotに代表される生成AIの活用で開発スタイルが変わりつつあります。
GitHub CopilotはOpenAIのモデルを活用したAIペアプログラマーで、Microsoft傘下のGitHubが提供しています。Microsoft社内でもこのCopilotをエンジニアが利用しており、開発効率向上に寄与しています。Copilotを使うと、コメントを書くだけで自動的にコードの候補が提案されるため、定型的なコードを書く手間が省けます (The future of programming languages in the era of LLM | MoonBit) (The future of programming languages in the era of LLM | MoonBit)。これにより、たとえばテストコードやボイラープレート（定型コード）の部分はAIに任せ、人間の開発者はロジックや設計に注力するという役割分担が進んでいます。結果として、開発者はどんどんコードを書いては試し、気に入らなければ書き直す（提案をリジェクトして再生成する）といった、インクリメンタルで捨てながら作る開発スタイルが身についてきます。Microsoftのデータでは、Copilot導入によりコーディングに要する時間が大幅短縮され、生産性が向上したとの調査結果もあります (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。これは、同じ時間で2倍の機能を実装できることを意味し (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)、ひいては「ダメな実装を捨てて作り直す余裕も2倍に増えた」と捉えることもできます。
またMicrosoft Researchはプログラミング言語自体の再発明にも取り組んでいます。後述するMoonBitのようなAIフレンドリー言語の研究にも関与しており、将来的には「AIが理解・生成しやすい言語」で書かれたコードをAIがどんどん書き換え、開発者はそれをレビューするという形も視野に入っています (The future of programming languages in the era of LLM | MoonBit) (The future of programming languages in the era of LLM | MoonBit)。実際、.NETの進化では古いフレームワーク（例えばWindows FormsからWPF、さらにUWPやMAUIへの移行）の中で、ある程度古いコードを捨てて新しく書き換える判断が行われてきました。そうした移行作業も、今後はAIアシスタントが自動化してくれる可能性があります。例えば先述のAmazonの事例と同様、Microsoftも自社コードのモダナイゼーション（近代化）にCopilotやGPT-4を使って取り組んでおり、古いC++コードを安全なRustに置き換えたり、レガシーなVBコードを最新C#に変換したりといった実験がなされています。
総じてMicrosoftは、「蓄積したレガシー資産をいかに捨てるか」という課題に正面から向き合っていると言えます。そこで鍵になるのがAIとの協働です。AI時代のソフトウェア開発では、人間が0から完璧なコードを書くより、AIが書いたコードを適宜捨てたり直したりしながら目的を達成するスタイルが主流になるとの見方もあります (graphai - npm) (The future of programming languages in the era of LLM | MoonBit)。Microsoftはまさにその転換点において、Copilotなどの提供者としても、自社開発の適用者としてもリードしている存在です。
AIが生成しやすいプログラミング言語とは？
生成AI（AIによるコード生成）が普及する中で、「AIにとって書きやすい（生成しやすい）プログラミング言語」とは何か、という問いが出てきています。人間の都合だけでなく、AIがバグなく正しくコードを出力できるかという視点で言語や環境を見直す動きです。
現状の課題：AIによるコード生成の難しさ
現状、ChatGPTのような大規模言語モデルはPythonやJavaScriptからC++、Javaまで様々な言語のコードを生成できます。しかし、その精度や信頼性には言語ごとに差があります。例えば動的型付け言語（PythonやJavaScriptなど）は柔軟な反面、AIがコード補完する際に存在しないメソッドを呼び出してしまう「幻覚（hallucination）」が起きやすいと指摘されています (The future of programming languages in the era of LLM | MoonBit)。一方、静的型付け言語（JavaやC#など）は型チェックが厳密なため、AIもある程度は誤りに気づきやすいですが、それでも複雑な文法や大量の定型コードがあると生成ミスが入り込みます。
また現在のLLMは、一度に扱えるコンテキスト（コードの量）に限りがあり、大規模プロジェクトの全貌を理解した上で一貫性のあるコードを書くのは苦手です。そのため、関数やファイル単位では正しくても、組み合わせると齟齬が出るという問題もあります。現場の声として「AIが提案したコードを結局人間が直す羽目になる」「複数ファイルにまたがる変更はおかしな結果になる」というものがあり (Preferring throwaway code over design docs | Hacker News) (Preferring throwaway code over design docs | Hacker News)、AI生成コードの検証コストが課題となっています。
AIが書きやすい言語の特徴
このような背景から、「ではAIがミスしにくい言語仕様とは？」という検討が進んでいます。2024年には研究プロジェクトMoonBitによって「AIフレンドリーなプログラミング言語」のデザインが提案されました (The future of programming languages in the era of LLM | MoonBit)。彼らの主張によれば、AI時代の言語は以下の特徴を持つべきだといいます (The future of programming languages in the era of LLM | MoonBit)：
- テストの容易さ：AIが生成したコードが正しいか素早く確認できるよう、言語レベルでテストを書きやすくする。例えば組み込みで単体テストフレームワークを提供したり、期待される出力を簡潔に記述できる（プロパティベーステストの強化など）仕組みが考えられます (The future of programming languages in the era of LLM | MoonBit)。AIが書いたコードに即座にフィードバック（テスト失敗など）を与えることで、誤りのフィードバックループを短縮します。
- 迅速な静的解析：コードを実行しなくても問題を検出できる静的解析を高速に行える言語設計が望ましいです (The future of programming languages in the era of LLM | MoonBit) (The future of programming languages in the era of LLM | MoonBit)。具体的にはコンパイルが高速で、型システムやlintが強力に働き、AIが生成したコードの矛盾や不整合をすぐ指摘できるような環境です。静的解析が充実していれば、AIにとっても「間違いを起こしにくい」土壌となります（AI自身は解析ツールではありませんが、学習段階でそうしたフィードバックを受けた良質なコードを学習することで、より正確なコードを出力しやすくなるという効果が期待されます）。
- セキュリティとサンドボックス：AI生成コードを実行する際の安全性も重要です (The future of programming languages in the era of LLM | MoonBit)。悪意はなくともバグによって重大な脆弱性が入り込む可能性があります。したがって、言語自体がメモリ安全性を持っている（例えばRustの所有権システムのようにバッファオーバーフローを防げる）とか、実行をサンドボックスで隔離できる（例えばWebAssembly上で動く）といった仕組みがあると安心です (The future of programming languages in the era of LLM | MoonBit) (The future of programming languages in the era of LLM | MoonBit)。MoonBitでは、WebAssemblyを使ったサンドボックス実行や、安全な型システムによってセキュリティ確保を図る設計が盛り込まれています (The future of programming languages in the era of LLM | MoonBit) (The future of programming languages in the era of LLM | MoonBit)。
MoonBitプロジェクトでは実際に新言語を試作し、AIがその言語を理解・解析しやすいかを検証しています。設計上、型システムを駆使してコード構造を明確化し、LLMがコードパターンを認識しやすくしているとのことです (The future of programming languages in the era of LLM | MoonBit) (The future of programming languages in the era of LLM | MoonBit)。さらに不要な死コードは自動的に除去されるよう最適化されており、解析や実行の邪魔になる要素を減らしています (The future of programming languages in the era of LLM | MoonBit)。目指すところは、「人間にとって書きやすい」だけでなく「AIにとって扱いやすい」言語です (The future of programming languages in the era of LLM | MoonBit)。
既存技術と可能性：AutoMLやEager Execution、PyGraphなど
AIがコードを書く助けになるような取り組みは、新言語の開発以外にも既存技術の流用という形で進んでいます。その例として以下が挙げられます。
- AutoML：先述したように、コードそのものではなく設定やデータを与えればシステムが構築されるというアプローチです。Google Cloud AutoMLは「誰でもコードを書かずに機械学習モデルを構築できる強力なツール」であり、UI上の操作でモデル作成・デプロイが可能です (AutoML | A No Code Solution for Building ML Models)。これは言い換えれば「AIが裏側でコードを書く」のと同義であり、人間はコードを書かない＝バグを埋め込むリスクも減ります。AutoMLの成功は、特定ドメイン（ML）に限定すればノーコードで質の高い成果物が得られることを示しました (AutoML | A No Code Solution for Building ML Models)。今後、この考えが一般開発にも広がれば、開発者は実装の詳細コードではなく要件を宣言するだけで良くなり、AIがそれを実現するコードやコンポーネントを適宜組み合わせてくれるでしょう。既にデプロイやCI/CDパイプラインを設定ファイル（YAMLなど）で記述する「構成としてのコード（Infrastructure as Code）」が主流ですが、これをさらに推し進めて「要件としてのコード」を書けばよい時代が来るかもしれません。
- TensorFlow Eager Execution：こちらはGoogleの機械学習ライブラリTensorFlowで導入された実行モードですが、動的でインタラクティブなコーディングを可能にした点で注目されました。従来のTensorFlowは計算グラフを定義してからまとめて実行する宣言的スタイル（Define-and-Run）でしたが、Eager Executionでは通常のPythonコードを書くように命令的（Define-by-Run）にモデルを構築できます。これによりデバッグや試行錯誤がしやすくなり、人間にとっても扱いやすくなりました。同時に、AIにコードを書かせる場合も、この動的モードなら逐次的にフィードバックを得ながらコードを生成・実行できます。すなわち、AIが一度に長いグラフ定義コードを正確に吐かなくても、対話的にコードを生み出しつつ間違いがあれば即座に修正する、といったステップを踏めます。PyTorchなど他のフレームワークは元々動的グラフでしたが、いずれもインタラクティブ性という点でAIコード生成との相性は良いです。今後は言語やフレームワーク全般がより動的かつ対話的に動く方向（REPL中心、ノートブック環境など）に進むことで、AIアシスタントと共同作業しやすくなるでしょう。
- PyGraphや宣言的グラフ記述：プログラムをグラフ（データフロー）構造で記述する手法も、AIとの親和性が指摘されています。GraphAI（後述）もその一例ですが、他にも例えばApache AirflowやPrefectのようにワークフローをDAG（有向非巡回グラフ）で記述するツール、Node-REDのようにGUI上でノードを繋いでフローを作る環境などがあります。こうしたフロー指向・宣言的な表現は、人間にとっても直感的ですが、AIにとっても扱いやすい可能性があります。というのも、グラフは明確なノード（処理単位）とエッジ（データ依存）から成り、処理の順序や並行性が自明だからです。LLMが長い命令型プログラムを逐字的に追うより、ノードとノードの関係性をもとにコード生成した方が誤りを検知しやすいかもしれません。実際、ある開発者は「AIにとって適切な言語は、自身が内部で持つ知識表現（例えば知識グラフ）に近い構造を持つものではないか」と推測しています。具体的な「PyGraph」という実装については情報が限られますが、名前からしてPythonでグラフ構造を扱うライブラリでしょう。PythonにはNetworkXなどグラフを扱うライブラリがあり、また近年は計算処理をグラフ的に表現する試み（TensorFlowの静的グラフや、データ分析パイプラインのDagsterなど）も行われています。AIがコードを書きやすいとは、「最終的なプログラムの動作」を高レベルな構造で捉えやすいこととも言え、その意味でグラフ表現は有望です。
このように、AutoMLやEager Execution、グラフ記述といった既存技術も、視点を変えれば「人間が細かくコードを書かなくてもよい／AIが補完しやすい」環境を整える一端となっています。今後は既存言語の改良（例えば型ヒントの充実でPythonをAIフレンドリーにするとか）、新言語の設計、開発ツールのAI統合など様々な方面から「AI時代に最適化されたプログラミング像」が模索されていくでしょう。
GraphAIと宣言型データフローによる非同期処理
ソフトウェア開発でもう一つ大きな課題となるのが、非同期処理や並列処理の扱いです。従来、複雑な非同期処理を書くにはスレッドやコールバック、Promise/async-awaitなどを駆使する必要があり、バグの温床になりがちでした。そこで最近注目されるのが、宣言型データフロー言語による非同期処理の記述です。その具体例としてGraphAIというオープンソースプロジェクトがあります (Worker and TypeScript : r/typescript)。
GraphAIとは？
GraphAIは、開発者の中島聡氏らによって開発が進められているデータフロー実行エンジンです (graphai - npm)。一言でいうと、非同期なAPI呼び出し（たとえば複数のWebサービスへの問い合わせや、データベースアクセス、LLMへの問い合わせなど）をグラフ構造で記述し、その依存関係に従って自動的に実行・並列化してくれる仕組みです (graphai - npm)。GraphAIではワークフローをYAMLやJSONで記述し、各ノードに「どのエージェント（処理）を実行するか」と入力・出力の関連を定義します (graphai - npm) (graphai - npm)。エンジンはそれを読み込み、必要な非同期呼び出しを並行に走らせつつ、依存関係を解決してくれます (graphai - npm)。開発者は「何をしたいか（データの流れ）」を宣言するだけで、「どう非同期処理を調停するか」はGraphAIが肩代わりするわけです (graphai - npm)。
GraphAIが目指しているユースケースの一つに、複数のAIエージェントを組み合わせたアプリケーションがあります (graphai - npm)。Andrew Ng氏が提唱する「エージェンティックAIワークフロー」とは、大きなタスクを複数のステップ（LLMへの繰り返しプロンプト、ツールの呼び出しなど）に分けて実行する手法ですが (graphai - npm)、GraphAIはまさにそれを実現しようとしています。たとえば「まずWikipediaから情報を取得し、それを分割してEmbeddingを計算し、さらにクエリ文のEmbeddingと比較して上位結果をLLMに与えて回答する」というような一連の処理フローを、YAMLで順次ノードとして記述できます (graphai - npm) (graphai - npm)。エンジンは非同期に各ステップを並列実行し、データ依存に従って結果を流してくれます。
GraphAIのアプローチで注目すべきは、従来手作業で書いていた並行処理コードを自動化する点です。JavaScriptでコールバック地獄に陥ったり、Pythonのasyncioでタスクのキャンセルや同期に苦労したり、といった問題は、GraphAIに代表されるデータフローエンジンで大きく軽減されます。GraphAIでは優先度制御やエラーハンドリング、リトライなどもフレームワーク側で吸収する設計になっており (graphai - npm)、開発者はビジネスロジックに専念できます。これは「AIにとって書きやすい言語」にも通じる思想で、複雑な並行処理のボイラープレートを人間やAIが都度書く必要がなくなるのです。
宣言型データフローのメリット
GraphAIのような宣言型データフロー言語には、以下のようなメリットがあります。
- 非同期処理の簡素化：人間にとっても難解な非同期ロジックを、グラフという直感的な形で表現できます。順序関係や依存関係は矢印で示されるので、コードを追うより理解しやすく、ミスも減ります。AIがコード生成する際も、直列・並列・分岐といった構造を間違えにくくなるでしょう。
- 自動並列実行：宣言された依存グラフから自動で実行計画を立てるため、開発者は並列化を意識しなくて済みます (graphai - npm)。例えば「クエリと文章Embeddingの計算」は独立だから並列実行するとか、「結果が全部出そろったらソートする」といった調整はエンジン任せです (graphai - npm) (graphai - npm)。これにより、マルチスレッドプログラミングの知識がなくてもマシン資源を有効活用できますし、AIもその部分でミスを犯す心配がありません。
- 再利用性とモジュール化：データフローの各ノード（エージェント）は部品として切り出せるため、ワークフローを組み合わせて再利用できます (GraphAI - Declarative AI Workflow Engine - GraphAI)（GraphAIも「モジュール性と再利用性」を謳っています (GraphAI - Declarative AI Workflow Engine - GraphAI)）。これは使い捨てコードとは一見矛盾しますが、「使い捨てやすさ」を支える仕組みでもあります。つまり部品レベルでは共通化・最適化しつつ、全体のフローは都度定義して捨てる、といったメリハリを付けやすくなります。
- 視覚的な理解：宣言型データフローはGUIで視覚化しやすい利点もあります。Node-REDのようにWebブラウザ上でノードとエッジを操作できれば、非技術者でもワークフローを構築できます。GraphAI自体はYAML記述ですが、その気になればビジュアルエディタも実装できるでしょう。このように誰でも編集しやすい形にできれば、AIアシスタントもユーザーの操作から意図を汲み取りやすく、人がドラッグ&ドロップで大枠を作りAIが詳細を補完するといった協調も期待できます。
要するに、GraphAIに代表される宣言型データフローアプローチは、非同期・並列処理の複雑さを吸収し、生産性と信頼性を高めるものです。これはAIコード生成の文脈でも極めて有用で、AIが苦手とするタイミング問題や状態管理を人間がいちいち指示しなくても済むようになります (graphai - npm) (graphai - npm)。今後、クラウド上のサービス連携や複数AIエージェントのオーケストレーションが当たり前になるにつれて、こうしたデータフロー記述は重要度を増すでしょう。
GraphAI自体はまだ発展途上のプロジェクトですが、既にコミュニティでは「TypeScript製のGraphAIでワーカー（スレッド）を使った並列実行を実装している」といった報告もあります (Worker and TypeScript : r/typescript) (Worker and TypeScript : r/typescript)。これはエンジン内部でマルチスレッド処理をしている例で、エンドユーザは意識せずにより高速な実行を享受できます。こうした低レイヤの改善も含め、非同期処理の民主化が進んでいるのです。
SNSで議論される最新トレンド
最後に、X（旧Twitter）やRedditなどSNSで近年話題になっている関連トピックや意見を紹介します。直近1～2年で開発者たちが何を感じ、何を議論しているのかを見ると、これまで述べた内容の潮流が実感できるでしょう。
使い捨てコードへの反響
生成AIの台頭により、「コードは資産ではなく消耗品になる」という見解がSNS上でも度々語られています。ある記事では「長年資産とされてきたコードが、なんと使い捨てになりつつある」と表現され、大きな反響を呼びました (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン) (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。X上でも「必要なときにAIにコードを書かせ、不要になれば削除する方がコスト効率が良い」という趣旨の投稿がエンジニアから発信されています（具体的な引用はUIの都合で省略しますが、「disposable code」「experiment」といったキーワードで多くの共感が集まっています）。一方で、Redditのプログラマ向けフォーラムでは「本当に捨てて良いコードとそうでないコードをどう見極めるか」が議論されています。例えば「プロトタイプを捨てる前提で作ったのに、結局捨てられずメンテしている経験はないか？｣と問いかける投稿に対し、「経営層にプロトタイプを捨てる重要性を理解させるのが難しい」という声 (Preferring throwaway code over design docs | Hacker News)や「設計ドキュメントより試作コードを示す方が議論が進むが、後始末を考えると悩ましい」*という声 (Preferring throwaway code over design docs | Hacker News) (Preferring throwaway code over design docs | Hacker News)が上がっています。総じてSNS上では、使い捨てコードの考え方に肯定的な意見が増えている一方で、現実とのギャップ（捨てられない事情）にも言及するバランスの取れた議論が展開されています。
特に日本の開発者コミュニティでも関心が高く、「コード開発コストが1/10になればソフトウェアはコンテンツ化する」といった未来予測や (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 - note)、AI時代のソフトウェア品質を問い直す記事 (【前編】AI時代に問い直す「ソフトウェア品質」：人とAIが共創する …)などが人気を博しています。これらでは、コードの価値が相対的に下がり、本当に価値を生むのはデータやユーザー体験であるという指摘がされています (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。つまり「コードそのものより、それを生み出すAI基盤やモデル、提供される体験の方が重要になる」という見方で (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン) (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)、これは使い捨てコード時代の本質を表しているでしょう。
AIとプログラミング言語
SNS上では「どの言語がAIにとって扱いやすいか」についての話題も散見されます。Xでは有名AI研究者が「将来のプログラミング言語は、AIとIDEの知能を最大限活かす形に進化するだろう」と発言し、注目を集めました (The future of programming languages in the era of LLM | MoonBit)。具体的には先述のMoonBitのような取り組みですが、SNS上の反応としては「型安全な言語がAI補完には安心」「動的言語はテスト前提でAIに書かせるべき」といった意見が見られました。また、GitHub Copilotなどの普及で「AI補助を前提にコーディングスタイルを変えた」という声も増えています。例えばある開発者は「コメントを丁寧に書くようになった。そうするとCopilotがかなり賢くコードを書いてくれるから」と投稿しており、AIにとって理解しやすい記述（コメントや関数名）を心がける動きが出てきています。これは一種の人間側が言語をAIに寄せている現象とも言えます。
Redditでは、「どの言語がCopilotでの生産性向上に向いているか？」というスレッドが立ち、「PythonやTypeScriptは学習データも多く精度が高い」という意見、「一方でRustのようにコンパイルエラーがシビアな言語ではAI提案が通らないケースも多い」という観測が共有されています。また、AIによるコーディングに特化した新興言語（例えば動的型付けだけどテスト容易性に振った言語など）が必要かどうか、というディスカッションも行われています。今のところ主流意見は「既存言語＋AI支援で十分ではないか、新言語は学習コストが高い」というものですが、研究層からは「長期的にはAIネイティブ言語が出てくるだろう」と楽観視するコメントもあります。
GraphAIとAIエージェントの潮流
GraphAIに関しても、一部の開発者コミュニティで話題になっています。XではAI開発者の間で「LLM時代のワークフロー構築ツール」としてGraphAIがツール紹介リストに挙がったり (Yohei on X: "AI Builders' Favorite Tools: A Hive Mind Survey …)、DiscordコミュニティでGraphAIを用いたエージェント協調のデモが共有されたりしています。Redditでも「複数のGPTエージェントにタスクを分担させるにはGraphAIが便利だ」*という投稿があり、少しずつ認知が広がっているようです。これはAutoGPTやAgentGPTといった、LLMを自律エージェント化するプロジェクトのブームとも関連しています。2023年にAutoGPTが登場すると、複数のサブタスクを自動で生成・実行するコンセプトが注目を浴びましたが、その制御ロジックを明示的に書けるツールとしてGraphAIを見る向きがあります。つまり、黒箱的なAutoGPTより、GraphAIで自分なりにエージェントフローを組んだ方が制御しやすいというわけです。
非同期処理全般のトレンドとしては、クラウドサービスではAWS Step FunctionsやAzure Logic Appsのようなワークフローオーケストレーションサービスが普及してきた背景もあります。これらはGUIやJSON/YAMLで処理フローを記述する点でGraphAIと似ており、SNS上でも「コードではなくワークフローで書く」スタイルへの関心が高まっています。あるエンジニアは「今後はシステムのロジックはフローチャートで管理し、細部の実装はAIに任せる時代になるかも」とツイートしており、多くのいいねを集めていました。GraphAIはまさにそのフローチャートを実行可能な形にしたものと言え、こうしたローコード/ノーコード志向やビジュアルプログラミング復権の流れにも合致しています。
コード駆動からデータ駆動・プロンプト駆動へ
SNS上の議論を総合すると、開発者の意識が「コードを書くこと自体」から「コードを書いて実現する価値」へシフトしているように感じられます。つまり、コードは単なる手段であり、目的はユーザーへの価値提供であると再認識されつつあります。生成AIはその手段部分を大きく自動化・低コスト化するので、これまで以上に要件定義やデータの質、UXデザインが重要だという意見が増えています (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン) (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。実際、ある起業家は「ソフトウェア開発がコンテンツ制作のようになる。プログラミングの知識より、何を作りたいかという直感やアイデアが重視される」と述べています (ソフトウェアが、コンテンツ化する未来 - Inflection Times / 起業の種火)。
この流れは、コードの使い捨てという話とも矛盾しません。むしろコードを使い捨てられるほど軽く扱えるようになって初めて、真に価値のある部分（データやUX）にフォーカスできるという見方です。SNS上でも「コードを捨てる勇気=ユーザーファースト」という意見が散見され、具体的には「ユーザーの要望が変わればコードなど惜しまず全部書き換えるべき。それを可能にするのが今のAIとモダン開発技術だ」という趣旨です。このように、エンジニア達は徐々にコードへの執着から解放され、より高次の創造的作業にシフトしようとしています。
おわりに
本記事では、使い捨てコードの概念とその背景、メリット・課題から始まり、Amazon・Google・Microsoftといった大企業の事例、さらにAIが生成しやすい言語の話題やGraphAIのようなデータフロー言語による非同期処理の簡素化、そしてSNSでの最新トレンドまで幅広く紹介しました。
ソフトウェア開発の風景は、AIの登場によって大きく様変わりしつつあります。かつては一行一行手作業で磨き上げたコードこそ価値でしたが、今やコードは必要に応じて生み出し、不要になれば捨て去る消耗品に近づいています (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。これは決してネガティブな変化ではなく、開発者が本当に注力すべき創造的な部分に集中できるようになる前兆です。AIと協働することで、我々はより多くの実験をより短時間で行い、ソフトウェアによる問題解決のサイクルを加速できます (The future of programming languages in the era of LLM | MoonBit)。もちろん全てが自動化されるわけではなく、人間の洞察力や判断力が重要な場面（設計の根幹や倫理的判断など）は残るでしょう。しかし反復的な実装作業や煩雑な並行処理からは解放され、システム全体のアーキテクチャ設計やユーザー体験の向上に時間を割けるようになるはずです。
これからの1～2年、そしてその先に向けて、エンジニアには新たな心構えが求められます。それは「コードを資産ではなく手段と捉える」こと、「AIという新たな開発パートナーを受け入れる」こと、そして「捨てる勇気を持つ」ことです (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)。幸い、ツールやコミュニティも日に日に進化し、学びやすい環境が整っています。初心者の方も怖がる必要はありません。むしろ今まで以上にアイデアと情熱さえあれば形にできる時代が来つつあります。使い捨てコードというキーワードは、その象徴と言えるでしょう。
最後に、参考文献やコミュニティ情報をもとにさらなる学習をおすすめします。本記事内の各所に引用リンクを示しましたので、興味のあるトピックはぜひ原典にも当たってみてください (Should You Throw Away More Code than You Keep? - DEV Community) (AutoML | A No Code Solution for Building ML Models)。新時代のプログラミングを切り拓くヒントが、きっと得られるはずです。
参考文献・リンク一覧 📚
- Marek Z. “Should You Throw Away More Code than You Keep?” DEV Community. (2019) (Should You Throw Away More Code than You Keep? - DEV Community) (Should You Throw Away More Code than You Keep? - DEV Community)】
- Programming is terrible (tef)。"Write code that is easy to delete, not easy to extend." (2016) (Write code that is easy to delete, not easy to… — programming is terrible) (Write code that is easy to delete, not easy to… — programming is terrible)】
- The Software Lounge (SystemDesign)。"Throwaway Functional Prototypes are a Waste of Time" (2024 (Throwaway Functional Prototypes are a Waste of Time) (Throwaway Functional Prototypes are a Waste of Time)】
- James Governor (RedMonk) 他. "Disposable Microservices." InfoQ (2015) (Disposable Microservices - InfoQ) (Disposable Microservices - InfoQ)】
- Andy Jassy (Amazon CEO)。「Amazon Qによるコード自動変換で4,500人年を節約」との発 (Amazon CEO: AI-Assisted Code Transformation Saved Us 4,500 Years of Developer Work - Slashdot) (Amazon CEO: AI-Assisted Code Transformation Saved Us 4,500 Years of Developer Work - Slashdot)】
- GraphAI (npm) - プロジェクトReadm (graphai - npm) (graphai - npm)】
- Reddit (/r/typescript) - GraphAI開発者のコメン (Worker and TypeScript : r/typescript)】
- MoonBit Blog: Hongbo Zhang “The future of programming languages in the era of LLM” (2024) (The future of programming languages in the era of LLM | MoonBit) (The future of programming languages in the era of LLM | MoonBit)】
- MoonBit 論文要旨: "MoonBit: Explore the Design of an AI-Friendly Programming Language" (LLM4Code 2024 (The future of programming languages in the era of LLM | MoonBit) (The future of programming languages in the era of LLM | MoonBit)】
- Bilal Shaikh. "AutoML – A No Code Solution for Building ML Models." Analytics Vidhya (2023) (AutoML | A No Code Solution for Building ML Models)】
- Note.com (しまだ氏)「使い捨てソフトウェア時代の新常識」 (2025) (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン) (AIエンジニアが変える「使い捨てソフトウェア時代」の新常識 〜開発コスト1/10の世界で勝ち残る戦略とは〜｜しまだ@AI×マーケ/デザイン)】
- Hacker News討議「Preferring throwaway code over design docs」 (2023 (Preferring throwaway code over design docs | Hacker News) (Preferring throwaway code over design docs | Hacker News)】
- TechCrunch. "GitHub Copilot brings mockups to life by generating code from images" (2025 (GitHub Copilot brings mockups to life by generating code from images | TechCrunch) (GitHub Copilot brings mockups to life by generating code from images | TechCrunch)】
- Atlassian Blog. "Microservices vs. monolithic architecture" (n.d. ( Microservices vs. monolithic architecture | Atlassian ) ( Microservices vs. monolithic architecture | Atlassian )】
- AWS Blog. "Monolith vs Microservices Architecture" (n.d. (Monolithic vs Microservices - Difference Between Software Development Architectures- AWS)】