AI がソフトウェア開発を永遠に変えた — Andre Baltieri と築く Agentic な未来 [MVP]

人工知能はソフトウェア開発を、これまでほとんど見られなかったほどの速さで変えつつあります。開発者はすでに、すべてのコードを自分で書く段階から、コードの生成、未知のシステムの説明、テストの作成、アプリケーションのデバッグ、反復作業の自動化を行える AI アシスタントと協働する段階へと移行しています。
しかし Microsoft MVP の Andre Baltieri によれば、それはまだ始まりにすぎません。
M365.FM のこのエピソードでは、Mirko Peters が Andre を迎え、従来型のソフトウェア開発から AI 支援開発への移行、コーディングエージェント、エージェント型アーキテクチャ、Microsoft Agent Framework、.NET、RAG、コンテキストエンジニアリング、セキュリティ、生成 AI の経済性について深く掘り下げます。

2003 年の .NET から AI 時代へ
Andre は .NET と C# の初期の時代を振り返ります。当時、Microsoft の新しい技術を学ぶには、公式トレーニングを購入し、別の都市まで移動することが珍しくありませんでした。その後ソフトウェア開発は、デスクトップ、Web、モバイル、クラウド、コンテナー、マイクロサービス、サーバーレスコンピューティングへと進化してきました。
Andre は、AI への移行は根本的に異なると主張します。AI は単に別のプラットフォームやフレームワークを導入するのではなく、人間がソフトウェアと対話する新しい方法をもたらすからです。

AI アシスタントと AI コーディングエージェントの違い
IDE 内の AI アシスタントと、作業をエージェントに委任することの間には重要な違いがあります。
アシスタントはコードを説明したり、リファクタリングを提案したり、質問に答えたり、開発者がアプリケーションを理解する手助けをしたりできます。一方エージェントは目標を受け取り、計画を立て、作業をより小さなタスクに分割し、ツールを使用し、追加のエージェントを調整して、ソリューションの重要な部分を実装できます。
Andre は、この変化がすでに自身の開発ワークフローを変えつつあると説明します。以前なら手作業で書いていたコードの多くを、今では AI が生成しています。

仕様駆動型ソフトウェア開発
エージェントの能力が高まるにつれて、仕様の重要性も増しています。
開発者はすべての実装詳細を記述する代わりに、要件、アーキテクチャ、制約、期待される動作を定義し、各部分の実装方法をエージェントに決めさせることができます。
これにより、開発者の注意はコードを作ることそのものから、何をなぜ作るべきかを定義することへと移ります。

Microsoft Agent Framework
会話は、既存のアプリケーションに AI の機能を取り入れるうえでの Microsoft Agent Framework の役割へと進みます。
Andre は、このフレームワークが Semantic Kernel と AutoGen に関連する機能を統合し、モデルの接続、ワークフローのオーケストレーション、MCP の利用、RAG の実装、データ取り込みの処理、アプリケーション機能の AI への公開のためのツールを開発者に提供すると説明します。
特に .NET 開発者にとって、これは必要な統合コードの量を大幅に減らすことができます。

AI 時代においても .NET が重要な理由
Python は依然として AI 開発で主要な言語の一つですが、Andre は .NET と C# が企業向け AI アプリケーションにおいて非常に有利な立場にあると強く主張します。
.NET は急速に進化を続けており、Microsoft の AI ツールも、C# 開発者に最新の AI 機能へのネイティブなアクセスを提供するようになっています。
何年にもわたって .NET で業務ロジックを実装してきた組織は、大きな優位性を持っている可能性があります。必ずしもすべてを作り直す必要はなく、既存の機能を選択的にエージェントや AI 搭載アプリケーションに公開できるからです。

決定論的ソフトウェアからエージェント型システムへ
従来のアプリケーションは主に決定論的です。
「X が起きたら Y を実行する」という形です。
エージェント型システムは別のモデルに基づきます。
「ここに目標がある。それを達成するために必要な行動を決定せよ」という形です。
これは重要なアーキテクチャ上の転換です。すべての可能な経路を明示的に定義する代わりに、開発者は目標、ツール、コンテキスト、権限、制約、そして AI が動作できる境界を定義するようになっています。

設計パターンは死んでいない
AI が生成するコードは、数十年にわたるソフトウェアエンジニアリングの知識を不要にするものではありません。
AI は新しい機能を実装する方法を、既存のコードベースを調べることによって学ぶことが多いため、クリーンコード、保守性、テスト、アーキテクチャ、設計パターンは依然として重要です。
雑なコードは、さらに雑なコードを生み出しかねません。AI エージェントが実装の大部分を担う場合でも、開発者はアーキテクチャとエンジニアリングの原則を理解しておく必要があります。

確率的ソフトウェアという問題
従来の開発者は、同じ入力が同じ出力を生むことを期待します。
一方、生成 AI は確率的です。同じ要求でも、実行のたびに異なる実装、回答、動作が生じることがあります。
Andre は、これによって開発者はテストと検証を考え直す必要があること、そして AI 機能が大量のユーザーに公開される場合には、強固なガードレールがますます重要になることを論じます。

プロンプティングよりもコンテキストエンジニアリングが重要
最新のモデルを選ぶことが、必ずしも最も重要な決定ではありません。
Andre は、コンテキストがすべてだと主張します。開発者は、AI に適切な情報を提供できるほど、ビジネス上の問題と技術環境の両方を理解している必要があります。
コンテキストが少なすぎると弱い結果になります。多すぎると、モデルを圧倒してしまいます。課題は、本当に重要な情報を見つけることです。

RAG、データ、コンテキストウィンドウ
組織が AI システムに自社の知識を扱わせたい場合、Retrieval-Augmented Generation（RAG）は特に重要になります。
しかし RAG システムの構築は、単にドキュメントをベクトルデータベースに入れることではありません。データはクリーニング、構造化、チャンク分割、検索を行い、モデルのコンテキストへ適切に挿入する必要があります。
Andre は、自身の教育プラットフォームの例を紹介します。そこでは、ユーザーが概念を検索し、関連する箇所に直接移動できるよう、動画レッスンを文字起こしして索引化していました。

メモリと AI コンテキストの管理
長時間続く AI との会話は、もう一つの課題、すなわちメモリをもたらします。
コンテキストウィンドウが埋まるにつれて、会話は要約または圧縮される必要があります。Andre は、AI システムが最も重要な情報を必ず保持すると想定するのではなく、開発者がこのプロセスを能動的に管理すべき理由を説明します。
時には、驚くほど単純な解決策が最善です。タスクを終えて会話を閉じ、クリーンなコンテキストで再開するのです。仕様書や Markdown ファイルも、コーディングエージェントに永続的なプロジェクトのコンテキストを提供できます。

セキュリティ、権限、最小権限の原則
AI エージェントにツールや企業データへのアクセスを与えることは、重大なセキュリティ上の影響をもたらします。
Andre は、エージェントを人間の ID と同様の原則で扱うことを推奨します。つまり、デフォルトではすべてを閉じ、エージェントが本当に必要とするものだけを公開するということです。
AI システムに無制限のデータベースアクセスを与える代わりに、開発者は特定のタスクに必要な情報だけを返す、厳密に制御された機能を公開すべきです。これは、エージェントが企業データを読み取ったり変更したりできる場合に特に重要になります。

プロンプトインジェクションと AI ガードレール
プロンプトインジェクションは、AI を搭載したアプリケーションにおける新たな攻撃対象領域をもたらします。
ユーザーは意図的にプロンプトを操作したり、想定された文脈の外にある情報を取り出そうとしたり、企業のリソースを消費させたり、設計者が想定しなかった行動を AI に取らせようとしたりすることがあります。
議論では、システム指示、アプリケーションレベルの制限、制御された機能、ID、権限、そして追加のセキュリティ境界を確立するための Azure AI Foundry などのプラットフォームの重要性を探ります。

AI FinOps ― すべてに生成 AI を使わない
この会話から得られる最も実践的な教訓の一つは、AI がある作業を実行できるからといって、その作業を AI に実行させるべきとは限らないということです。
Andre は、生成的なワークロードと決定論的なワークロードを区別します。毎回同じように実行されなければならないものであれば、従来のプログラミングの方が、より速く、安く、信頼性が高い場合があります。
彼は次の例を挙げています。