次の方法で共有


AI ワークロードに関与するワークロード チームペルソナ

AI ワークロードを構築するコンテキストでは、従来のコードデプロイとは異なり、非決定的なモデルでは、複数のロールとチーム間で反復的な実験とコラボレーションが必要です。 運用、アプリケーション開発、データ チームの早期統合は、相互理解を促進するために不可欠です。 このコラボレーションでは、技術的な進歩に対応するために、多様なスキルと継続的な学習が必要です。

効果的なコラボレーションは、ワークロードのニーズと特定の目標によって推進ツール、プロセス、人に影響します。 推奨される戦略は次のとおりです。

  • 明確なロールと説明責任の確立。
  • チームのスキル セットを適切なタスクに活用する。
  • 共有バックログの一部としての作業の追跡など、プロセスとサブプロセスを標準化する。
  • 一貫性と再現性を実現するために自動化に頼る。

ペルソナは、これらの戦略を具体化し、責任を標準化するための効果的なツールです。 この記事では、AI ワークロードに見られるペルソナの概念、ワークロード設計における利点について説明し、これらのチーム レベルのペルソナを効果的に定義して利用するための例とツールを示します。

ペルソナとは

ペルソナは、ワークロードの作成と実行に関与する人間とプロセスのサブセットを表し、ロールだけでなく、実際の動作と説明責任もキャプチャします。 個人は、コンテキストに応じて 1 つまたは複数のペルソナを体現できます。 興味深いことに、ペルソナは人である必要はありません。また、アーキテクチャ内のエージェント プロセスなど、無人プロセスにすることもできます。

ワークロードには、機能開発を推進するエンドユーザー ペルソナが含まれる場合があります。これらのペルソナは、この記事の対象ではありません。

通常、組織内のより静的な機能や位置であるロールとは異なり、ペルソナは動的で目標指向です。 これらは、アーキテクチャ コンポーネントなどのプロセスやツールにスキル要件をマップするために使用できます。 ペルソナは、主に責任の範囲を定義し、プロジェクト内でコンテキストを設定するのに役立ちます。 他にも次のような利点があります。

  • リソースギャップの特定ソリューションを採用、トレーニング、または再設計するかどうかを決定するのに役立ちます。 ワークロード チームに必要なペルソナを適合させる個人が不足している場合は、アーキテクチャの調整、プロセスの変更、または新しい担当者のオンボードが必要になる場合があります。 たとえば、シニア データ サイエンスペルソナが不足している場合は、汎用 SaaS AI ソリューションの信頼性を高めたり、サードパーティの AI ソリューションを組み込んだりすることで、アーキテクチャを再設計できます。

  • スキルの強化。 ペルソナを特定のアーキテクチャ コンポーネントにマッピングすると、教育の機会も促進され、スキルを強化するためのセッションやオンライン コースが提供されます。

  • 適切なレベルのアクセス権を確保します。 ペルソナを使用して、プロセス、アーキテクチャ、サービスにマッピングし、適切なアクセス レベルを確保することで、セキュリティとアクセスのニーズを定義する必要があります。

  • プロジェクトの計画とコミュニケーション プロジェクト計画では、ペルソナは主要な相互作用を特定し、同期会議のセットアップと全体的な計画を容易にします。 通常、ペルソナは、ユーザー ストーリー、機能、要件の追跡の階層に統合され、プロジェクト管理が合理化されます。

ペルソナを定義する方法

チーム メンバーの特殊化を特定し、AI 運用または設計における適切なロールに合わせます。 ペルソナのスキルの期待、チーム情報、関与するプロセスを文書化するテンプレートを作成します。

ベースライン テンプレートの例を次に示します。

ペルソナ テンプレート
🔹 ペルソナ名: [ペルソナ名の挿入]
🔹チーム: [このペルソナを担当するチーム]
🔹主な対話: [このペルソナが対話する他のチーム]
🔹コンポーネント アクセス: [プロセスとシステム コンポーネントのセキュリティとアクセスの要件]
🔹プロセス: [ペルソナが責任を負う、または貢献するプロセス]
🔹スキル: [モデル トレーニングや検索インデックスの最適化などのドメインやテクノロジの詳細を含む、タスクを完了するために必要なスキル。

ツール

テーブルを使用すると、各ペルソナの情報を整理して視覚化するのに役立ちます。 利点は、より詳細な情報を得るための他のテーブルを作成してリンクできることです。 たとえば、サービスと環境 (Dev、Stage、Production) ごとに ID ベースのアクセス制御が指定されている別のテーブルにアーキテクチャ コンポーネントをリンクできます。

Tradeoff. ペルソナが少なすぎると、最小限の特権アクセスでロールベースのアクセス制御を実装し、作業の責任を効果的に分散することが困難になる可能性があります。 逆に、ペルソナが多すぎると、管理オーバーヘッドが増加します。 5 から 10 個のペルソナから始めるとバランスが取れ、操作に必要なペルソナのみを追加する必要があります。

カードを使用してペルソナを定義することもできます。 これらのカードには、テーブルまたはクイック サマリーと同じ情報が含まれています。 これらのカードは、Microsoft PowerPoint を使用するか、マークダウン ファイルのセットとして作成できます。

場合によっては、一連のツールを組み合わせて使用できます。 たとえば、ペルソナ カード内の各アーキテクチャ コンポーネントは、各サービスと環境のセキュリティとロールベースのアクセス制御を表マッピングしたマークダウン ファイルを開くことができます。 リファレンス例については、「 MLOps アクセラレータ: ID RBAC」を参照してください。

ペルソナの例

カードを使用して、ペルソナがプロセス内でアクセスする必要があるサービスを定義し、各ペルソナに必要な前提条件スキル (個人またはエージェント) を概説できます。

重要

ここで定義されているペルソナはベースラインの例として機能しますが、テーブル、ペルソナ テンプレート カード、グラフなどのツールを使用して独自のペルソナを作成することをお勧めします。

これらのペルソナは、特定のプロセス、組織、およびユーザーと一致することが重要です。

AI データ エンジニア (P001)
チーム: データ インジェスト チーム
🔹 主要な対話: AI 開発チーム
🔹 コンポーネント アクセス: Azure Data Factory、Azure Databricks、Azure SQL Database、Azure Storage
🔹 プロセス: DataOps、ETL、ELT
🔹 スキル: SQL、Python、PySpark
BI アナリスト (P003)
チーム: 分析チーム
🔹 主な対話: データ インジェスト チーム
🔹 コンポーネント アクセス: Power BI、Azure Data Explorer、Azure Storage
🔹 プロセス: データ分析、データ ウェアハウス プロセス
🔹 スキル: SQL、Python、PySpark
判別 AI データ科学者 (P004)
チーム: AI チーム
🔹 主な相互作用: データ インジェスト チーム、DevOps チーム
🔹 コンポーネント アクセス: Azure Machine Learning、Azure Databricks、Azure Storage、Azure Key Vault
🔹 プロセス: MLOps、MLflow
🔹 スキル: Azure Machine Learning、Python、モデル トレーニング
GenAI データ科学者 (P006)
チーム: AI チーム
🔹 主な相互作用: データ インジェスト チーム、DevOps チーム
🔹 コンポーネント アクセス: Azure AI Studio、Azure OpenAI、Azure AI Search、Azure Storage、Azure Key Vault
🔹 プロセス: GenAIOps
🔹 スキル: Azure Machine Learning、Python、Model(LLM、SLM) の知識、微調整、RAG、Agentic の概念
GenAI チャット 開発者 (P007)
チーム: エンジニアリング チーム
🔹 主な対話: AI チーム
🔹 コンポーネント アクセス: Azure WebApps、Azure API Management、Cosmos DB、Azure Container Apps、Azure Functions
🔹 プロセス: DevOps、イベント ドリブン処理、マイクロサービス
🔹 スキル: Web アプリケーション アーキテクチャ (フロントエンド/バックエンド)、React、Node.js、HTML、CSS
BuildAgent MLOps (P009)
チーム: エンジニアリング チーム
🔹 主な対話: AI チーム
🔹 コンポーネント アクセス: Azure Machine Learning、Azure Devops、GitHub
🔹 プロセス: ラムダ、OUTER ループ MLOps のプロセス/サービス
🔹 スキル: Python、Pyspark

ユース ケース: AI プロセスのペルソナ

AI ワークロードに関連する主なプロセスは次のとおりです。

  • DataOps では、データインジェストと準備に重点を置いています。
  • MLOps には、機械学習モデルの運用化が含まれます。
  • GenAIOps は、既存のモデルを検出して評価し、ワークロード コンテキストに合わせて調整することに関連します。
  • 内部ループは、研究中または外部ループ監視によってトリガーされる開発環境のソリューションを改良します。
  • 外部ループは、継続的な監視と評価を使用して、必要な改善点を特定して、ソリューションを開発から運用環境に移動します。

これらのプロセスにペルソナをマッピングすると、各ペルソナのコンテキストが提供されます。 これは、ペルソナがスキルアップを必要とする可能性があるプロセスを特定するのに役立ちます。

運用環境内の DataOps、MLOps、GenAIOps を示す図。

この画像は、運用環境内の DataOps、MLOps、GenAIOps のワークフローを示しています。 継続的インテグレーション/継続的デプロイ (CI/CD) プラクティスを使用して、インジェストからモデルのデプロイと評価に至るデータ フロー。 重要なタスクには、データ モデルの絞り込み、バッチ評価、エンドポイントのデプロイ、リアルタイム モデル評価、およびモデルの微調整が含まれます。 例のペルソナは、ワークフロー全体に参加します。

ユース ケース: アーキテクチャ設計のペルソナ

プロセスをサポート アーキテクチャに接続すると、ペルソナが対話する必要があるサービスを特定するのに役立ち、潜在的なスキルアップの領域が強調表示されます。

この接続を視覚化するには、アーキテクチャ コンポーネントの接続方法を示すグラフィカルイメージを作成します。 これは、データ フローとサービス間の相互作用、およびデプロイでのフローの自動化方法を示しています。 この視覚的支援は、利害関係者がアーキテクチャとその中のさまざまなペルソナの役割を理解するのに役立ちます。

次の図は、Azure での最新の分析のためのラムダ アーキテクチャを示しています。

Azure での最新の分析用のラムダ アーキテクチャの図。

次のステップ

次に、評価ツールに進み、設計を評価します。