なぜAI開発はコード生成から知識管理へ変わるのか。Azure新機能から読み解くエージェント設計の現在

AIがコードを生成するフェーズは終わった。AIにどのような知識を持たせ、どう動かすかを設計するフェーズだ。開発者の役割は、コードを書くことからエージェントのアーキテクチャを設計することへシフトしている。

$10億規模の投資。数千のAPI連携。秒単位のスケール。これらを実現する鍵は、単一のプロンプトではない。Azureの新機能や最新のエージェントフレームワークが示すのは、知識の構造化こそが次世代開発の主戦場になるという事実だ。

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。

無料で始める

知識を自動選択するスキルとサーバーレスなエージェント

AI開発における転換点は、Azure Functions Skillsの登場だ。これはnpm製のプラグインとして提供され、Claude CodeやGitHub Copilot CLIといったコーディングエージェントに、Azure固有の判断知識を流し込める。

この新しいスキル群は、どの設定が最新のベストプラクティスか、デプロイ前に何をチェックすべきかといった生きた知識をエージェントに教え込む。実測で11個のスキルが用意されており、作成から運用までをカバーする構造だ。

さらに、Serverless Agent Runtimeの仕組みがある。これは、ドット・エージェント・エムディー（.agent.md）というファイルでエージェントの挙動を定義し、通常のFunctionsアプリとしてデプロイする。

実行はMicrosoft Agent Frameworkが担い、インフラ管理を意識せずにエージェントを動かせる。

不定期なイベントへの即応性が重要だ。顧客のプロフィールが更新された瞬間に、最適な車種を提案するエージェントを動かす。

そんなワークロードも、待機中はコストゼロでスケールするサーバーレス環境なら現実的だ。既存システムからのイベントをトリガーにして、AIが自律的に判断を下す。

しんたろー：
Azureがここまで踏み込んできたのは驚いた。開発者がドキュメントを読み漁る代わりに、エージェントに直接「知識のプラグイン」を刺す感覚だ。
Claude Codeでコードを書いている身として、こういう公式の知識ベースがCLIから直接叩けるのは、開発体験を根本から変えるインパクトがある。

開発環境の境界線とCLAUDE.mdの二層構造

AIエージェントを使いこなす上で、コンテキストの管理が重要だ。特にClaude Codeでは、CLAUDE.mdの書き方一つでAIの挙動が変わる。設定ファイルをグローバルとプロジェクト直下の2層構造で管理する。

グローバル設定（~/.claude/配下）に書いた内容は、全てのセッションで読み込まれる。ここに事業戦略や長大なコーディング規約をベタ書きすると、無関係な作業でも毎回トークンを大量に消費する。

これを解決するのがアット・インポート（@インポート）だ。必要な時だけ外部ファイルをインライン展開することで、AIの推論精度を保ちつつ、コストを抑えられる。

また、スラッシュコマンド、スキル、MCP（Model Context Protocol）ツールの違いを理解する。例えば、画像生成を行いたいとき、特定のコマンドを暗記する必要はない。

CLAUDE.mdに「画像生成は特定のスキルで行う」というルールを書いておけば、AIは自然言語の依頼から自動的に最適なスキルを選択する。開発者はツールの呼び出し方ではなく、ツールの役割を定義することに集中する。

ここで注意が必要なのは、意味的な矛盾の検出だ。AIに「既存の内容とマージして」と指示しても、それが論理的に正しいとは限らない。

さらに、MCP接続のライフサイクルも実務では重要だ。設定を変更しても、セッションを再起動するか再接続コマンドを打たない限り、古いキャッシュが使われ続ける。

しんたろー：
CLAUDE.mdを育てていくのは、新人を教育するのに似ている。必要な時に参照できるマニュアルを整理しておく感覚だ。
僕も最初は全部グローバルに書いて失敗した。@インポートを使い始めてから、AIのレスポンスが速くなり、的外れな回答も減った。

エージェント間のバトンタッチとオーケストレーション

複数のエージェントを連携させるマルチエージェントの世界では、ハンドオフ（Handoff）という概念が鍵を握る。一次窓口のエージェントが内容を判断し、専門のエージェントにタスクを引き継ぐパターンだ。

Microsoft Agent Frameworkのオーケストレーションパターンがバージョン1.0に到達したことで、この実装が現実的になった。

ハンドオフの肝はツール・コーリング（tool calling）だ。現在のエージェントが、特定のツールを呼び出すことで次の担当者へ遷移する。ここで技術的にハマりやすいのが、エージェントIDとツール名の紐付けだ。

実装時には、固定の文字列でツール名を指定するのではなく、利用可能なツール一覧から動的に解決する仕組みを構築する。また、配送状況の確認から返金の案内へ、といった連鎖的な委譲を行う場合、どこでタスクが完了したか（DONE）を明確に定義する。

開発者の仕事は、個別のロジックを書くことから、このエージェント間の責任分界点を設計することへ移っている。

また、埋め込みブラウザの挙動にも注意する。開発環境に内蔵されたブラウザは、普段使っているブラウザとセッションやログイン状態を共有しない。

しんたろー：
エージェント同士が会話して仕事を進める様子は見ていて面白いが、管理は大変だ。結局、人間がワークフローの設計図をしっかり書いておかないと、AIは無限ループに陥ったり、責任を押し付け合ったりする。
コードを書く時間より、こういう遷移図を考えている時間の方が最近は長い。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。

無料で始める

開発者が「アーキテクト」として生き残るためのアクション

AI開発の主戦場は知識の構造化とワークフローの設計に移行した。これからの開発者が取るべき具体的なアクションは、以下の3点だ。

第一に、スキルの分離と共通化だ。Azure Functions Skillsのように、特定のドメイン知識を「スキル」として切り出し、複数のエージェントで共有できる形にする。

第二に、知識ベースの段階的な公開（Progressive Disclosure）だ。CLAUDE.mdの例で見た通り、全ての情報を一度に与えるのではなく、必要な時に必要な分だけ読み込ませる構造を作る。

第三に、決定論的な処理と非決定論的な処理の切り分けだ。Azureの状態を確認するような収集スクリプトは、PowerShellなどの決定論的なコードで書く。一方で、その結果を受けて「次に何をすべきか」という判断は、AIの非決定論的な推論に任せる。

AIにコードを書かせるのは、誰でもできることになった。これからの差別化要因は、AIが正しく、効率的に、そして自律的に動けるための「舞台装置」をいかに美しく設計できるかにかかっている。

FAQ

Q1: Azure Functions SkillsとMicrosoft Agent Frameworkは併用すべきですか？

はい、併用を推奨します。Azure Functions Skillsは「Azure環境の構築や運用に関する専門知識」をエージェントに注入するためのプラグインであり、知識の辞書です。一方でMicrosoft Agent Frameworkは、複数のエージェントがどう協力し、どうタスクを引き継ぐかという行動の規律を制御する基盤です。インフラの自動化をAIに行わせるための「知識」をSkillsで与え、複雑な業務フローを複数の専門エージェントで分担させる「仕組み」をFrameworkで構築することで、自律的なAIシステムが完成します。

Q2: CLAUDE.mdをグローバルとプロジェクトで分けるメリットは何ですか？

最大のメリットは、コンテキストの最適化とコスト効率の向上です。全てのプロジェクトで共通するコーディング規約や、自分の開発スタイルなどをグローバルなCLAUDE.mdに全て書いてしまうと、小さなスクリプトを書くだけのセッションでも毎回膨大なトークンを消費し、AIのレスポンスが遅くなります。共通ルールはグローバルに、プロジェクト固有の仕様はローカルに配置し、さらに@インポートを駆使して必要な情報だけをオンデマンドで読み込む構成にすることで、AIの「集中力」を削ぐことなく、正確な推論を引き出すことが可能です。

Q3: Handoffの実装で最も注意すべき点は何ですか？

エージェントIDとツール名の一貫性、そして動的なツール解決です。Handoffは内部的にtool callingを利用してエージェント間の遷移を実現しますが、多くの開発者が「表示名」をそのままツール名として使おうとして失敗します。SDK側で生成されるツール名には特定の規則があるため、固定の文字列をハードコードするのではなく、システムから渡される利用可能なツール一覧（options.Tools）から、目的の機能を動的に検索して呼び出す実装にします。これを怠ると、エージェントが次の担当者を見失い、タスクが途中で頓挫する原因になります。