クリックから記述へ

昨年開催した Autodesk DevCon では、少し抽象的なかたちで、AI エージェントに対して計画している(当時、計画していた)アプローチや取り組みをご案内しました。その際、API を使ったアプリの方向性として、従来のユーザー インターフェースを持つスタイルから、AI エージェントから駆動するスタイルへの変化について触れています。

An aerial view of a city at night with illuminated streets and buildings, featuring Japanese text that translates to 'Select and click' and 'Execute while documenting'.

まだプレビューのかたちですが、Revit 2027 MCP サーバー Fusion MCP サーバー などの登場もあり、最近になって、オートデスクの取り組みも実態をともなってきた印象です。まずは、APS を利用しない簡単な例を挙げて「選択してクリック」から「記述して実行」の変化をご紹介しておきたいと思います。

ユーザーインターフェースを持つ Web アプリ:

次に示すのは、オートデスクのオフィスが置かれている主要都市を選択して、その都市の現在の天気情報(天候、温度、湿度)を地図上に表示する Web アプリの例です。

A detailed map of East Asia showing Japan, with a weather widget displaying cloudy conditions and temperature information.
  • オートデスクのオフィスは、本社のある米国・サンフランシスコを筆頭に、世界中に27か所存在しますが、アプリ例では、この内、独断で18都市を選んでドロップダウン メニューを構成しています。

アプリは、HTML で定義されるユーザーインターフェースを持ち、ページ左上のドロップダウン メニューで都市名を選択することが出来ます。

都市名を選択すると、天気情報の取得に OpenWeather の Weather API を、地図の表示には Microsoft のAzure Maps を利用して、選択した都市があるエリアを表示します。

AI エージェント駆動用の MCP サーバー:

一般的な AI エージェントにとって天気情報の取得は標準的なスキルですが、ここでは、あえて、前述の Web アプリを MCP サーバー化して、単純に AI エージェントから呼び出せるようにしてみます。

MCP サーバーに用意したツール実装は次の2種類です。

  • getCitiesWhereOfficeTool ツール
    • 現在の天気情報を取得するオートデスク オフィスがある主要都市名を JSON 配列で返します。このツールは、特に外部の API 呼び出しはしていません。
  • getCurrentWeatherWithMapTool ツール
    • 英語都市名で指定された主要都市の現在の天気を取得、Azure Maps の Web SDK で HTML ファイルを生成します。返される JSON には、緯度、経度、天気、気温、湿度の順で現在の天気情報が含まれます。このツールは、内部で OpenWeather Weather API と Microsoft Azure Maps を呼び出します。

上記ツールを持つローカル MCP サーバーを Claude Desktop に設定後、オートデスク オフィスがあり、かつ、天気情情報を取得可能な都市名を「オートデスクのオフィスがあって現在の天気を取得出来る主要都市の一覧は?」のプロンプト入力で確認します。

次に、ロンドン オフィスの天気情報を確認します。ここで使用したプロンプト入力は、「オートデスク ロンドン オフィスの現在の天気情報を教えて」と、レスポンス後の「Azure Mapsでも教えて」の2つです。

  • 天気情報の取得と当該都市の地図取得は、別ツールで実装すべきですが、前述の Web アプリ相当の実装とするため、便宜上、1つのツールにまとめています。
  • 地図を埋め込んでいる HTML の表示には、サンドボックス環境となる iframe を使用する Claude Desktop の Artifacts 領域の制約で Azure Maps の外部 CDN 参照が制限されるため、ここでは現在の実装を大きく変えない目的で、外部の Google Chrome を利用して HTML をそのまま表示しています。

ここまでの例で、「選択してクリック」から「記述して実行」の変化を感じていただけるはずです。AI エージェントを利用を前提にした「記述して実行」を強く意識する理由は、拡張した結果を容易に得ることが出来てしまうためです。

下記は、「取得したオートデスクのオフィスの天気情報をPowerPointプレゼンテーション資料にして」をプロンプト入力とした例です。

結果として、18都市の現在の天気情報を地域別に PowerPoint プレゼンテーション資料にまとめてくれます。

内部的には、getCitiesWhereOfficeTool ツールで18都市を得た後、個別の都市に対して getCurrentWeatherWithMapTool ツールを呼び出しています。もちろん、こちらで実装した MCP サーバーには、PowerPoint を操作したり、プレゼンテーション資料を作成したりするツールはありません。

  • 上記例では Azure Maps の地図はプレゼンテーション資料に反映されていませんが、getCurrentWeatherWithMapTool ツールが 地図を埋め込んだ HTML を生成しています。

AI エージェントを利用するエンド ユーザーは、API や開発の知識を持たない場合がほとんどと思います。当然、API 呼び出しを意識することはありません。場合によっては、PowerPoint に精通していないことも考えられます。

にもかかわらず、間接的に MCP サーバーを介して API を呼び出し、プレゼンテーション資料を得る結果を享受出来ています。言わば、究極のノーコード ソリューションとも言えるかと思います。

これが、オートデスクが「選択してクリック」から「記述して実行」にアプリが変化するだろうと考える理由であり、APS に新しいビジネスモデル(API への課金)を導入した理由でもあります。開発ビジネスの視点では、API 利用の選択肢が増える、と考えることが出来るわけです。

Discover more from Autodesk Developer Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading