Instrumentsによる、エージェントを活用したアプリ体験のデバッグとプロファイリング

こんにちは AIツールエンジニアのErikです。 このセッションでは Instrumentsを使って Foundation Modelフレームワークで 構築した機能をデバッグする方法を紹介します。

Foundation Models APIを使うと アプリからオンデバイスおよび サーバベースの ジェネレーティブAIに直接アクセスできます。 これにより 自然言語を理解し コンテンツを生成してユーザーの 操作に応答する機能を構築できます。

最高のエクスペリエンスを生み出す機能は 静的ではありません。 コンテキストに応じて適応します。 Foundation Models APIは まさにそのために設計されています。 DynamicInstructionsを使うと モデルがアクセスできる 指示とツールを正確に指定できます。 リクエストの前に毎回再評価されるため モデルは常にタスクに適切な コンテキストを持てます。 この柔軟性によって 機能の応答性が高まりますが デバッグが難しくなる原因にもなります。 Large Language ModelsつまりLLMを 使った開発は 従来の開発とは異なります。 従来のコードは予測可能です。 LLMは非決定論的であり 同じ入力から 異なる出力が生成されることがあります。 機能がコンテキストを失ったり 応答が遅くなったりした場合 原因の特定は 簡単ではありません。 優れたツールが重要な違いを生みます。 このセッションが終わるころには Instrumentsを使って これらの問題を特定し 修正する方法がわかります。 そして自信を持って高速で信頼性の高い エクスペリエンスをリリースできます。 まず 従来のアプリ開発と LLMアプリ開発の概念を 比較 対照します。 正しい思考法を身につけるためです。 次に Instrumentsを使って エージェンティックなエクスペリエンスを Craftアプリで検証 デバッグします。 始める前に 「What's new in the Foundation Models framework」と 「Build agentic app experiences with the Foundation Models framework」 をご覧いただき 最新の追加事項を 理解しておくことをお勧めします。

LLMを使ったアプリ構築には 3つの課題があります。 これらは従来の ソフトウェア開発では見られません。

1つ目は確率的な出力です。 従来の関数に同じ入力を 2回与えると 同じ出力が得られます。 LLMはそうではありません。 同じプロンプトから まったく異なる2つの応答が生成され 標準的なユニットテストが 機能しなくなります。 出力がハードコードされた文字列と 一致するかアサートできません。 代わりに応答の品質と 意図を評価する必要があります。 2つ目はモデル間の通信です。 強力な機能は多くの場合 複数のモデルの連携に依存します。 たとえばレシピアプリでは 一方のモデルが写真の 食材を識別し もう一方がその結果から レシピを生成します。 モデル間でデータを 確実に流通させ 何か問題が起きたときに 適切に回復させることが 真の複雑さが生まれる部分です。 3つ目はオブザーバビリティです。 マルチモデルパイプラインで 問題が発生した場合 どこで問題が起きたか 特定するのが非常に困難です。 各ステップを可視化する必要があります。 モデルが受け取ったもの 判断の内容とその理由です。 このセッションはまさにその点について 説明します。 LLMアプリケーションの基本は 3つの動作です。 ユーザーがプロンプトを送信し モデルがそれを推論し ユーザーが応答を受け取ります。 シンプルで高速 多くの機能 (要約ツール ライティングアシスタント Q&Aインターフェース) に必要なものが揃っています。 多くの有用な機能はテキスト生成以上の ものを必要とします。 モデルが持っていない情報が 必要な場合があります。 現在時刻 データベースレコード 検索結果などです。 そこでツールコールの出番です。 ループはこのように機能します。 ユーザーがプロンプトを送信し モデルがそれを推論して ツールを呼び出します。 そのツールがアクションを実行し モデルが結果を受け取って 最終的な応答を生成します。 これによりループが再び始まります。 ステップが増えるほどレイテンシも増します。 各ステップは新たな障害の発生箇所です。 このループを理解することが すべての基礎であり Foundation Models Instrumentが 表示する内容の根拠になります。

LLMアプリ開発に必要な考え方を 説明しました。 次にInstrumentsを使って ブレインストーミング機能を Craftアプリ向けに デバッグ 検証します。 クラフトのコンパニオンアプリを 開発中で クラフトプロジェクトの 日誌をつけられます。

このアプリではクラフトの 進捗を記録したり 特定のクラフトについて 質問したり チュートリアルを生成したりできます。 最近 インタラクティブな ブレインストーミング機能のアイデアを思いつき 何を作るかの提案を ユーザーに届けます。 クラフターはモデルと対話して アイデアを絞り込み 決定する準備ができたら アプリがそのクラフトの 詳細なチュートリアルを生成します。 この機能は2種類の指示を使います。 1つはアイデアのブレインストーミング もう1つはチュートリアル生成です。 ブレインストーミングの指示には 2つのツールが含まれます。 GenerateCraftIdeaTool とSwitchToTutorialModeToolです。 両方の指示セットはPrivate Cloud Compute上の サーバモデルを使用し 一方はアイデアの素早い生成 もう一方はより詳細な チュートリアルの生成に使います。 Instrumentsで実際に見てみましょう。

プロジェクトはすでにXcodeで開かれています。 プロファイリングを開始するには メニューを開いてを選択します。 Xcodeがアプリをローカルでビルドします。 テンプレートチューザーから Foundation Modelsテンプレートを選択して をクリックします。 このInstrumentはデバイスから プロンプトと応答データを記録します。 センシティブな情報が含まれる 場合があります。 ロギングは本番環境ではオフですが トレース中はオンになります。 トレースファイルは安全な場所に 保管してください。 を選択して開始します。

アプリが起動しました 試してみましょう。 この画面を開くと モデルがいくつかのプロジェクトアイデアを 提案します。 Yarn PomPom Fabric Pouch そしてPaper Butterflyです。 Paper Butterflyが楽しそうですね これにしましょう。

うーん。 おかしいですね。 モデルがチュートリアルを 開始するはずでしたが 代わりにさらにアイデアを 提案してきました。 何かがおかしいです。 記録を終了してトレースを調べ 何が起きたか確認しましょう。

Instrumentsは一度に多くの情報を 表示します。 一緒に見ていきましょう。 上部のセクションにはトラックがあります。 トラックはタイムラインの アクティビティを表示します。 各トラックには複数のレーンを含められ レベルや領域を示すチャートが 表示されます。 タイムラインの下には詳細ビューがあります。 現在検査している範囲の サマリ情報が表示されます。

タイムラインのバーや 詳細ビューの行をクリックすると 右側にインスペクタが開き 選択した内容を 詳しく確認できます。

Foundation Models Instrumentの タイムラインには6つのレーンがあります。 セッション構造とレイテンシの 概要を素早く把握できます。 タイムラインの横には ツリー詳細ビューがあります。 モデルの思考の流れを 深く掘り下げられます。

Instructionsレーンは 指示とツールのセットが アクティブだった時間を示します。 1つのセットで複数のリクエストを カバーできます。 このレーンを見ると セッション全体で1セットの指示しか アクティブでなかったことがわかります。 しかし機能は2セット使うはずでした。 ハンドオフで何か 問題が起きたようです。

Model Inferenceレーンには 2種類のバーがあります。 黄色とオレンジです。 黄色のバーはシステムが 入力プロンプトの処理に 要した時間を表します。 オレンジのバーは 応答の生成に要した時間を表します。

タイムラインで概要を把握できますが 本当の力はツリービューにあります。 この記録中にログされた すべての情報を 階層構造に整理します。 セッション、リクエスト、モデル推論 指示、プロンプト、応答です。 指示セットが切り替わらなかった原因を 追跡しましょう。

セッション1には2つのリクエストがありました。 最初のリクエストは 以下で始まるプロンプトで 「Please generate 3 craft ideas.」 で始まりました。

そのリクエストは2つのモデル推論と いくつかのツールコールで構成されました。 すべてのモデル推論には 指示 プロンプト そして応答またはエラーが 必要です。 ツリー内のノードをクリックすると インスペクタに表示されます。

モデル推論の詳細には 指示のサマリが表示されます。 プロンプトとこの呼び出しを構成した 応答も確認できます。

スクロールすると時間の可視化と トークン使用量のメトリクスが表示されます。 これらは後ほど確認します。 信頼性とパフォーマンスの 最適化の話でまた触れます。

障害の原因に戻りましょう。 タイムラインからすでに 指示セットが切り替わらなかったことがわかり このモデル推論ノードの インスペクタで その指示に紐付いた プロンプトが確認できます。 Instructionsノードを選択して 設定を確認しましょう。

インスペクタには この指示に 1つのツールしか紐付いていないことが 表示されています。 プロンプトは switchToTutorialModeツールを参照していますが

そのツールはこの指示に 実際には設定されていません。

それがないと ブレインストームモードから チュートリアルモードへの切り替えができず クラフターがループに 閉じ込められます。

ツリーの後続ノードを見ると これはサイレントな障害でした。 モデルは入力を受け付け続け ツールコールを行いましたが エラーは発生しませんでした。 何か問題が起きたという 明確なシグナルはありませんでした。 発見が難しいバグです。 根本原因が明らかになったので Xcodeに戻って修正します。 Instrumentsで見つけた内容をもとに 調べるのは BrainstormDynamicInstructionsの 定義です。 Instructionsブロックで SwitchToTutorialModeツールが プロンプト内で言及されていますが toolsetにはGenerateCraftIdeasToolしか リストされていません。

追加しましょう。

再コンパイルしてInstrumentsで 再実行します。 修正が実際に機能しているか 確認するためです。

アプリに戻り タブに移動します。 先ほどと同様に モデルが新しいクラフトを提案します。 選ぶのは… necklaceにします。

できました。 UIがチュートリアルモードに 切り替わりました。 モデルが移行を行い このクラフトの完全な チュートリアルを生成しました。 Instrumentsに戻って この新しい記録を見てみましょう。 すべてが効率的に実行されたか 確認します。

Instructionsレーンに 2つの異なる指示が表示されています。 このエクスペリエンス中に アクティブだったものです。

最初はブレインストーミングの指示 2つ目はチュートリアル生成の 指示です。

先ほど説明したブレインストーム エクスペリエンスの設計と 一致しています。 ツリービューを掘り下げて この移行の実際の経緯を見ましょう。

最初の指示セットには generateCraftIdeaと switchToTutorialModeツールの 両方が含まれています。 モデルが切り替えに必要なものを すべて持っていたことが確認できます 修正が機能しました。 指示の変更はRequest 2の 2番目のモデル推論の後に発生しました。

その推論によってswitchToTutorialModeへの ツール呼び出しが発生し 選択したクラフトが 引数として渡されました。

そして次のリクエストで 指示が正しく切り替わり チュートリアルジェネレーターへ 選択したクラフトが コンテキストとして渡されました。

infoカラムはより詳しく見るべき ノードを素早くフラグするのに最適です。 エラー、長い時間、大きな トークン数などが対象です。 Request 1の最初のモデル推論が 予想より少し時間がかかっていたので 確認してみましょう。

メトリクスと時間のセクションが この推論のトークン使用量を詳しく示します。 これらの数値は エクスペリエンスの効率を 理解し改善するための 出発点です。

3つの主要なメトリクスで パフォーマンスを測定できます。 Time to First Tokenはプロンプトを 受信後にモデルが 応答の生成を開始するまでの 時間を測定します。 Time to First Tokenが高いと ユーザーは空白の画面を 見続けることになります。 これを下げるにはプロンプトを 短くします。 Tokens per Secondは応答の 全体的な生成速度を測定します。 異なるプロンプト設定間での パフォーマンスのベンチマークや 変更後のリグレッション検出に 使用します。

Total Latencyはリクエストを 送信してから 最終的な応答を受け取るまでの 完全な時間です。 ユーザーが最も直接的に 感じる数値です。 Total Latencyの体感を下げるには ストリーミングを活用して 部分的な結果を早く表示します。

トレースの実行が 最適化の出発点です。 これらのメトリクスは時間と リソースの使われ方を正確に示し 適切な修正策を示します。 モデル推論ノードを使って トークン使用量の全体像を把握します。

このセッションではInstrumentsを使って Foundation Modelフレームワークで 開発したエージェンティックなエクスペリエンスを デバッグする方法を紹介しました。 バグを修正したら次はEvaluationです。 「Meet the Evaluations framework」を ご覧ください。 構造化された評価を使って プロンプトの品質を 測定し改善する方法がわかります。

改善されたFoundation Models Instrumentを使い始めるには Xcode 27をインストールします。 次にアプリを実行してプロファイルする デバイスで 最新のOSリリースに アップデートします。 このInstrumentはFoundation Model フレームワークで使用する あらゆるモデルをサポートします。 Foundation Models APIは あなたの出発点です。 実験し 構築し 何が可能かを確かめましょう。 期待どおりに動作しない場合は Foundation Models Instrumentが デバッグをサポートします。 フレームワークの動作を コンテキスト内で直接可視化できます。 エージェンティックなアプリエクスペリエンスに 関する関連セッションと Evaluationフレームワークも ぜひご活用ください。 完全なドキュメントを探索して フレームワークのすべての機能を 活用してください。 ご参加ありがとうございました。 改善されたFoundation Models Instrumentを 使ってインテリジェントな エクスペリエンスの開発と デバッグをお楽しみください。