※本記事は、ITU（国際電気通信連合）とCOIA（Open Intelligent Computing Industry Alliance）が主催するウェビナー「Challenge Launch: Generative AI Applications for Enterprise Scenarios Using OPEA」の内容を基に作成されています。本ウェビナーは、Intel ChinaのソフトウェアエンジニアリングおよびクライアントプロダクトグループのテクニカルディレクターであるDr. Shan Wang氏、ZTEのオープンソース・標準化エンジニアとして通信ネットワーク向けAI分野を専門とするLeah Yuan氏、およびITUのVishnu氏が登壇しました。チャレンジの詳細およびウェビナーの動画はhttps://competition.aiforgood.itu.int よりご覧いただけます。本記事では、ウェビナーの内容を要約・構成しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈についてはオリジナルの動画をご視聴いただくことをお勧めいたします。
1. ウェビナー開会・登壇者紹介
1-1. セッションの目的・概要・登壇者紹介
Jaying： 本日は「AI for Good AI・機械学習・5Gウェビナー」にお集まりいただき、誠にありがとうございます。ITU（国際電気通信連合）のJayingと申します。本日のセッションは、「OPEAを活用したエンタープライズシナリオ向けジェネレーティブAIアプリケーション」と題したチャレンジのローンチウェビナーです。このチャレンジは、既存の技術やモジュール式のAIコンポーネントを組み合わせることで、現実のビジネスシナリオにおける実践的な課題を解決することを目的としています。本ウェビナーでは、登壇者の皆さまから、OPEAプラットフォームの概要、参加者が取り組むべきタスクの内容、評価方法、ロジスティクスの詳細、そして優勝者への賞品についてご紹介いただきます。
それでは、本日の登壇者をご紹介します。まず、Intel Chinaのソフトウェアエンジニアリング・クライアントプロダクトグループのテクニカルディレクターである Dr. Shan Wang です。Dr. Wang からは、参加者が使用するOPEAプラットフォームの紹介をしていただきます。次に、ZTEのオープンソース・標準化エンジニアであり、通信ネットワーク向けAIの分野を専門とされている Leah Yuan です。Leah からは、チャレンジの課題内容、参加者が取り組むべきタスクの詳細、およびチャレンジのロジスティクスについてご説明いただきます。最後に、Q&Aセッションの進行は私の同僚である Vishnu が担当します。それでは早速、Dr. Wang にバトンをお渡しします。Dr. Wang、カメラとマイクをオンにしてください。
2. エンタープライズAI導入の障壁と課題
2-1. ジェネレーティブAI普及の波と企業導入を阻む三大障壁——セキュリティ・コスト・技術複雑性
Shan Wang： それでは、OPEAプラットフォームについてご説明します。まず背景からお話しします。2022年頃からジェネレーティブAIが世界的に非常に注目されるようになりました。その最初の波は、個人消費者向けの利用から始まりました。しかし、企業がジェネレーティブAIを導入しようとすると、個人利用とは異なる多くの障壁に直面します。ユーザー調査のデータをもとに整理すると、企業がAIを採用する際に直面する課題として、技術的な複雑性、コスト、データの可用性、そしてセキュリティといった要因が挙げられます。
まず技術的な複雑性についてです。企業はAI技術そのものに関心があるわけではなく、AIを使って自社にどのような価値をもたらせるかに関心があります。しかしAI技術は日々、あるいは年単位で急速に変化しており、その変化についていくこと自体が大きな負担となっています。次にコストの問題です。企業がAIを導入しようとすると、高価なGPUやAIインフラの購入が必要になるのではないかという懸念が生まれます。そのコストの高さが、AI領域への参入を妨げる大きな要因となっています。また、AIの専門人材をどのように確保するか、あるいは外部から招聘するかという問題も企業にとっての課題です。
2-2. 企業が「内部展開型AI」を必要とする理由と、OPEAが目指す解決アプローチ
Shan Wang： 特に重要な課題として、セキュリティの問題があります。私が実際に顧客と話す中で強く感じてきたことですが、企業は自社の内部データや社内文書がインターネット上に流出することを非常に恐れています。インターネット上の大手企業が公開している大規模言語モデルをそのまま使うことへの抵抗感が強く、これが企業のAI導入における最大の障壁の一つとなっています。企業が求めているのは、個人利用とは異なり、社内のプライベートクラウドにLLMを内部展開するアプローチです。
このような課題に対処するために、私たちが提案するのがオープンエコシステムを活用した解決策です。企業がジェネレーティブAIを導入しようとすると、まずデータの準備という課題に直面します。社内の機密データをベクターデータベースやストレージに格納するためのISV（独立系ソフトウェアベンダー）との連携が必要になります。次に、そのデータを使ってモデルを構築する際、公開されている汎用モデルは企業固有の知識を持っていないため、社内データでファインチューニングを行い、自社専用モデルを構築する必要があります。さらに展開の段階では、システムインテグレーターやOEMハードウェアベンダー、OS（オペレーティングシステム）ベンダーなど、多くのベンダーと個別に対応しなければなりません。しかし企業が本当に求めているのは、こうした多数のベンダーと個別にやり取りすることではなく、自社にAIの価値をもたらしてくれる一つの統合されたソリューションです。
こうした背景から生まれたのが、OPEA（Open Platform for Enterprise AI）です。OPEAの目標は、仕様・コンポーネント・マイクロサービス・リファレンスフロー・評価ベンチマークを提供することです。また、エンタープライズAIインフラのパフォーマンスを計測・評価するためのベンチマークツールもオープンソースプロジェクトの中に含まれています。OPEAのスローガンは「オープンエコシステムによってジェネレーティブAIソリューションの開発・展開を企業に可能にする」というものであり、セキュリティ・安全性・スケーラビリティ・コスト効率・アジリティというエンタープライズが必要とするすべての要件を満たすことを目指しています。
3. OPEAの設計思想とRAGワークフロー
3-1. RAGを中心とした処理フローの全体像——データ準備・埋め込み・検索・再ランキング・LLM推論・ガードレール
Shan Wang： 企業がモデルを構築する際の最初のアプローチはファインチューニングですが、ファインチューニングにはAIインフラへの投資が必要であり、コストが高くなります。そこでOPEAが優先的に採用しているのが、RAG（Retrieval-Augmented Generation：検索拡張生成）という、よりコスト効率の高いアプローチです。OPEAはRAGを活用することで、企業がファインチューニングを行わずともジェネレーティブAIを利用できるようにしています。もちろんファインチューニングも選択肢として許容していますが、あくまでも第一優先はRAGです。
RAGの典型的な処理フローをOPEAの文脈で説明します。まず企業が保有するデータ——社内文書、画像、動画、メール、チャット履歴、技術データベースなど——はすべて社内の機密情報であり、インターネットを通じた外部からのアクセスは許可されていません。これらのデータはまずデータ準備のプロセスを経て、埋め込み（embedding）処理によってベクターデータベースにマッピングされます。
次に、ユーザーがクエリを入力すると、そのクエリはまずベクターデータベースに問い合わせを行います。このとき、元のクエリはそのままLLMに渡されるのではなく、埋め込み・検索・再ランキング（reranking）という一連のプロセスを経て、LLMが理解しやすい新たなクエリ——いわゆるプロンプトエンジニアリングの産物——へと変換されます。この再ランキング後のクエリがLLMに入力されます。
LLM推論のコンポーネントは「LM Inference」と呼ばれるボックスとして構成されており、オープンソースモデルも外部の商用モデルも利用可能ですが、いずれのモデルも企業のプライベートクラウド内に展開されます。LLMからの出力はガードレール（guardrail）を通過することで安全性が確保され、最終的にユーザーへの応答として返されます。このように、ベクターデータベースを経由するフローは企業の内部データに基づく検索を担い、LLMへのクエリは汎用的な言語理解を担うという形で、両者が連携する構造になっています。
3-2. RAGとファインチューニングの使い分け——コスト・優先順位・フィードバックによるモデル改善
Shan Wang： RAGフローにはもう一つ重要な側面があります。ユーザーからのフィードバックです。LLMからの応答が十分でない場合、そのフィードバックをもとにファインチューニングによってモデルを改善するという仕組みも、OPEAは許容しています。つまり、RAGを第一手段として使いながら、必要に応じてファインチューニングで補完するという段階的なアプローチが可能です。
RAGが第一優先とされる最大の理由はコストです。ファインチューニングにはトレーニングのためのGPUやAIインフラへの追加投資が必要ですが、RAGはそれを必要としません。社内データをベクターデータベースに格納し、クエリ時に検索・参照するだけで済むため、企業のセキュリティ上の懸念を解消しながら、低コストでAIを活用できます。また、クラウドインフラを活用することでスケーラビリティと信頼性の課題にも対応できます。こうした理由から、現時点においてRAGはエンタープライズAIの実現手段として最もコスト効率の高い方法であるとOPEAは位置づけています。
OPEAのスローガンである「オープンエコシステムによってエンタープライズのジェネレーティブAIソリューションの開発・展開を可能にする」は、まさにこのRAGを中心とした設計思想を体現しています。セキュリティ・安全性・スケーラビリティ・コスト効率・アジリティというエンタープライズが必要とするすべての要件を、ファインチューニングなしに、あるいは最小限のファインチューニングで満たすことができる——それがOPEAの核心的な価値提案です。
4. OPEAのアーキテクチャと技術スタック
4-1. ソフトウェアスタック上の位置づけ——低レイヤーフレームワークとアプリケーション層を橋渡しするミドルウェア
Shan Wang： OPEAがAIソフトウェアスタック全体の中でどのような位置づけにあるかをご説明します。スタックの最下層には、PyTorchやTensorFlowといった汎用的なAIフレームワークがあります。その上にはvLLMやTGI（Text Generation Inference）などの推論サービングフレームワークが位置し、さらにその上にはLangChain、Haystack、LlamaIndexといったアプリケーション開発フレームワークがあります。OPEAはこれらの低レイヤーフレームワーク群と上位のアプリケーション層との間に位置するミドルウェアとして機能します。
このミドルウェアとしての役割が重要です。OPEAの上位にはさまざまなエンタープライズ向けアプリケーションが構築されますが、それらを開発するISV（独立系ソフトウェアベンダー）は、どの推論サービングフレームワークを使うべきか、どのアプリケーションフレームワークを選ぶべきかといった低レイヤーの技術的詳細を意識する必要がありません。OPEAのAPIとマイクロサービスを呼び出すだけで、エンタープライズ向けAIアプリケーションを構築できます。これがOPEAの提供する本質的な価値です。
4-2. ハードウェア・OS・GPUライブラリ層の構成とオーケストレーション——Docker ComposeからKubernetesまで
Shan Wang： OPEAのアーキテクチャをボトムアップで詳しく見ていきます。最下層にはCPUやGPUといったハードウェアがあり、複数のベンダーの製品に対応しています。その上にはLinuxのオペレーティングシステム層があります。OPEAはさまざまなLinuxディストリビューションと互換性があり、Red HatやOpenEulaなど、中国国内で使われているディストリビューションも含めてサポートしています。
OSの上にはGPUドライバとGPUライブラリの層があります。使用するGPUによって必要なライブラリが異なります。NvidiaのGPUを使用する場合はCUDA、AMDの場合はROCm、Intelの場合はoneAPIをそれぞれ使用します。OPEAはこれらすべてに対応しており、ベンダーロックインなく複数のハードウェア環境で動作します。
その上にオーケストレーション層があります。OPEAはシングルマシンへの展開と、複数マシンによるクラスタ展開の両方をサポートしています。シングルマシンの場合はDocker Composeを使ってマイクロサービスを展開し、クラスタ環境ではKubernetesやその他のクラウドソフトウェアを使用します。このオーケストレーション層の上に、OPEAの核心的な価値を提供するマイクロサービス群が構築されます。
4-3. マイクロサービス群の構成——推論・ASR・埋め込み・再ランキング・ガードレール・テキストto画像
Shan Wang： オーケストレーション層の上に位置するのが、OPEAが提供する多数のマイクロサービス群です。これらがOPEAの最も重要な価値提供コンポーネントであり、図中では黄色いボックスとして表されています。
最も主要なマイクロサービスは推論（Inference）サービスです。OPEAはDeepSeek、Qwen、Llamaをはじめとする複数のオープンソースモデルおよび商用モデルをサポートしており、サービングフレームワークとしてはvLLM、llama.cpp、TGI（Text Generation Inference）などを利用できます。これらの技術的な詳細はすべてInferenceマイクロサービスの中にカプセル化されており、アプリケーション開発者はその内部を意識することなく、APIを呼び出すだけで推論機能を利用できます。
推論以外にも多様なマイクロサービスが提供されています。ASR（Automatic Speech Recognition）マイクロサービスは音声をテキストに、あるいはテキストを音声に変換する機能を提供します。RAGワークフローで必要となる埋め込み（Embedding）、検索（Retrieval）、再ランキング（Reranking）の各プロセスもそれぞれ独立したマイクロサービスとして提供されており、アプリケーション開発者はゼロから実装することなくこれらを呼び出すだけで利用できます。ガードレール（Guardrail）マイクロサービスはLLMの出力を安全に保つための機能を提供しており、アプリケーションにガードレールを組み込みたい場合も、自前で実装する必要はありません。さらに、テキストから画像を生成するText-to-Imageマイクロサービスも提供されています。これら20以上のマイクロサービスはすべてOpenAI APIと互換性を持っており、既存のOpenAI APIを使用したアプリケーションを持っている場合、OpenAI APIの部分をOPEAのAPIに置き換えるだけで、プライベートクラウド内での動作に切り替えることができます。
4-4. パイプラインの仕組みとChat Q&Aの具体例——7マイクロサービス連結とMega Services・Flowwise・Dify等の選択肢
Shan Wang： OPEAのアーキテクチャは、マイクロサービス層・パイプライン層・アプリケーション層という3層構造になっています。マイクロサービスは個々の機能単位ですが、実際のAIアプリケーションを実現するためには、複数のマイクロサービスを連結してひとつのタスクを達成する「パイプライン」が必要になります。
具体例として、OPEAのリポジトリに含まれるChat Q&Aアプリケーションを挙げます。このアプリケーションは企業内部のドキュメントに基づいて質問に回答するチャットボットで、ChatGPTに似た使い勝手を持ちながら、社内専用のドキュメントに特化して動作します。このChat Q&Aアプリケーションは7つのマイクロサービスから構成されています。これら7つのマイクロサービスをどのように連結するかを定義するのがパイプラインの役割です。
パイプラインの実装方法には複数の選択肢があります。OPEAが内部的に提供するMega Servicesというパイプライン機能、GenAI Studioという別リポジトリのツール、そして外部のサードパーティツールとしてFlowwiseや、中国で広く使われているDifyなども利用できます。これらを用いてマイクロサービスをチェーンのようにつなぎ合わせることで、目的のAIアプリケーションが完成します。アーキテクチャの最上位層には、このようにして構築されたさまざまなアプリケーションや事例が位置しています。
4-5. GitHubリポジトリ構成と評価ツール——genai-examples・genai-comps・genai-infra・genai-eval
Shan Wang： OPEAのソースコードはGitHub上で公開されており、リポジトリはいくつかのサブディレクトリ（サブリポジトリ）で構成されています。まずgenai-examplesは、OPEAのAPIを活用したAIアプリケーションの書き方を示すサンプルコードが収録されています。参加者が独自のAIアプリケーションを開発する際は、このgenai-examplesのコードを参照し、自分のシナリオに合ったサンプルを選んで改変することが最も効率的なアプローチです。
次にgenai-compsは、先ほど説明した黄色いボックスで示されるすべてのマイクロサービスが格納されているディレクトリです。genai-infraには、マイクロサービスをクラウドネイティブ環境で展開するために必要なコンテナ化関連のソフトウェアがすべて収録されており、OPEAのクラウドネイティブスイートとして機能します。そしてgenai-evalは、OPEAが提供する評価・ベンチマークツール群です。エンタープライズAI向けのソリューションを構築した際に、レイテンシや同時実行数（コンカレンシー）などのシステムパフォーマンス指標を計測・評価するためのツールがここに収録されています。これらのツールを活用することで、自身が構築したソリューションのパフォーマンスを定量的に把握し、改善することができます。
5. OPEAの主要機能・最新機能・パートナーエコシステムと実導入事例
5-1. 20以上のOpenAI互換API・対応モデル・最新追加機能——AIエージェント・MCP・A2A・マルチモーダル・ナレッジグラフ
Shan Wang： OPEAはオープンソースプロジェクトとして、コミュニティの貢献者たちとともに継続的に機能を拡張しています。現時点で提供している主要機能のうち、選抜したものをご紹介します。これはすべての機能を網羅したリストではなく、代表的な機能を示したものです。
コア機能としては、まずAIエージェントのサポートがあります。単純な質問応答にとどまらず、複数のステップにわたるタスクを自律的に実行するエージェント機能をOPEAは提供しています。また、Image-to-Videoの変換機能もサポートしており、マルチモーダルな処理にも対応しています。対応する大規模言語モデルについては、DeepSeek、Qwen、Llamaなどをはじめとして、毎年新しいモデルが登場するたびに対応モデルを追加しようとしており、オープンエコシステムとしてより多くのモデルをサポートするためにコミュニティからの貢献を歓迎しています。
RAGの機能面では、ナレッジグラフのサポートが新たに追加されています。従来のベクター検索に加えて、ナレッジグラフを活用することでより構造化された知識の検索と参照が可能になります。マルチモーダル対応も強化されており、テキストだけでなく画像や音声を含む複合的なデータを扱う能力が向上しています。セキュリティ面では、エンタープライズ利用に適した安全性を確保するためのコードが継続的に追加されています。
さらに、近年注目されているMCP（Model Context Protocol）およびA2A（Agent-to-Agent）プロトコルのサポートも追加されています。MCPはモデルが外部ツールやデータソースと連携するための標準的なプロトコルであり、A2Aは複数のAIエージェントが相互に連携して動作するための仕組みです。これらの最新技術トレンドをOPEAはいち早く取り込み、エンタープライズ環境での活用を可能にしています。
5-2. COIAとLinux Foundation傘下のオープンエコシステム、InfosysとNetAppの実導入事例
Shan Wang： OPEAはオープンソースプロジェクトである以上、多くのパートナー企業の支援が不可欠です。アーキテクチャの各層——ハードウェア層、Linux OSシステム層、GPUドライバ・ライブラリ層、推論層、モデル層——にはそれぞれ多数のベンダーが関わっており、各層のベンダーからの協力を得てOPEAは成り立っています。ハードウェアベンダー、モデルベンダー、OS層ではRed HatやOpenEulaといったディストリビューションのベンダーなど、幅広いパートナーがOPEAを支えています。
また、Linux Foundationの傘下においてCOIA（Open Intelligent Computing Industry Alliance、オープンインテリジェントコンピューティング産業アライアンス）というアライアンスを設立しています。このアライアンスは今回のチャレンジの主催母体でもあり、Intel、H3C、ByteDance、China Mobile、Alibabdaなど多数の企業が参加しています。OPEAのソースコードはGitHub上で公開されており、Linux Foundationのインキュベーションプロジェクトとして運営されています。
実際の導入事例として2つをご紹介します。1つ目はInfosysです。InfosysはRAGとOPEAを活用して社内従業員向けのアシスタントシステムを構築しました。Infosysの従業員はこのシステムを使うことで、社内文書、社内コンテンツ、事前営業活動に関する情報、ポリシーの検索など、さまざまな質問に対してAIを通じて回答を得ることができます。重要な点は、このシステム全体がInfosysの社内に展開されており、インターネットや外部からはアクセスできない完全なプライベート環境で動作しているということです。これはまさにOPEAとRAGを活用したエンタープライズAIの理想的な実装例です。
2つ目はNetAppです。NetAppはOPEAのソフトウェアと、Intel XeonサーバおよびNetApp A20ストレージサーバを組み合わせて、オールインワンのハードウェアアプライアンスを構築しました。このアプライアンスは他の企業に販売されるもので、ソフトウェアとハードウェアが一体化されているため、技術的な専門知識を持たない企業でも容易に導入して社内AI推論環境を構築できます。すべての企業が高い技術力を持っているわけではないという現実を踏まえ、OPEAを活用したオールインワン製品によってその障壁を取り除いた好例です。
なお、OPEAの機能をより具体的に確認したい方のために、YouTubeでオンラインデモを公開しています。また、プロジェクトへの貢献や技術的な質問がある場合は、GitHubのリポジトリやコミュニティのウェブサイトを通じてコントリビューターに問い合わせることができ、回答を得ることができます。
6. チャレンジの背景・目的・タスク内容
6-1. 主催体制とAIネイティブアーキテクチャへの移行潮流——通信・交通・スマートエネルギーへの波及
Leah Yuan： 皆さん、こんにちは。声が聞こえていますか？ありがとうございます。Dr. Shanが説明してくださったOPEAについて、皆さんにはすでに明確なイメージを持っていただけたかと思います。それがこのチャレンジに参加するうえで最も重要な前提知識となります。ここからは、チャレンジの詳細についてご説明します。
本チャレンジはCOIA（Open Intelligent Computing Industry Alliance）が主催しており、ZTEとIntelがこのアライアンスの重要なメンバーとして運営に携わっています。また、ITUのFG-AI（Focus Group on AI）からも多大なサポートをいただいています。チャレンジの詳細はすでにウェブサイトに掲載されていますが、本日は背景・タスク内容・参加に必要な情報について順を追ってご説明します。
まず、現在のAI革命における最新トレンドを確認しておきたいと思います。私たちは今、企業がLLMをはじめとする高度なAI機能を、セキュアに・効率的に・コスト効率よく基幹業務システムへ統合することへの圧力が急速に高まっている局面を目の当たりにしています。例として通信ネットワークを取り上げると、デジタルトランスフォーメーションの基盤インフラである通信ネットワークは、AIをネットワーク全体に深く統合したAIネイティブアーキテクチャへのパラダイムシフトを経験しています。そしてこのAIネイティブアーキテクチャへの移行は、通信ネットワークだけにとどまらず、インテリジェント交通システムやスマートエネルギーグリッドなど、他の重要インフラセクターにも広く波及しています。
Leah Yuan： こうしたトレンドに直面しながらも、企業がLLMを自社の基幹システムに統合しようとする際には、依然として多くの課題が立ちはだかっています。断片化した技術スタック、パフォーマンスとTCO（総保有コスト）のバランス、クラウドネイティブ展開やKubernetesオーケストレーションがもたらす複雑性、大規模AIモデルの評価の難しさ、そして実験的なプロトタイプを実際のエンタープライズスケールの展開へと移行させるためのエンジニアリング上の課題などが挙げられます。こうした課題を解決する手段こそがOPEAです。OPEAはこれらの課題に対処するための標準的でモジュール式のフレームワークを提供しています。OPEAをひとことで表現するならば、AIのためのレゴセットです。LLM、RAGパイプライン、ベクターデータベース、推論エンジン、オーケストレーションツール、そしてジェネレーティブAIアプリケーションを評価するためのツール群という、AIパイプラインを構築するためのモジュール式のビルディングブロックを提供しています。
6-2. 参加者のミッションと対象産業領域——通信・教育・金融・医療・製造・法務・公共サービス
Leah Yuan： 参加者の皆さんに与えられたミッションは、OPEAを使用してドメイン特化型のジェネレーティブAIアプリケーションを設計・プロトタイプ化・実証することです。このミッションを遂行するにあたって、念頭に置くべき4つの要件があります。これについては次のセクションで詳しくご説明しますが、まずはどのような産業領域が対象となるかを見ていきましょう。
本チャレンジはITUの文脈で開催されるため、通信ネットワークが最も典型的なシナリオの一つとなります。通信ネットワーク向けには、AIネイティブなネットワーク最適化、予測保守、インテリジェントなトラフィック管理、自動化されたカスタマーサポートといったソリューションが考えられます。しかしこれらはあくまでも例示に過ぎず、OPEAを使えばこれらすべてが実現可能であり、さらに参加者の皆さんの想像力次第でより革新的なソリューションを生み出すことができます。
通信以外にも幅広い産業領域が対象です。教育、金融、法律サービス、医療、製造、カスタマーサポート、公共サービスなど、多岐にわたる分野でOPEAを活用したソリューションを開発することができます。そしてこれらの例に縛られる必要もありません。ビジネス価値があり、優れたパフォーマンスを持つソリューションであれば、他のどのような産業領域や分野を選んでも構いません。参加者の皆さんには、自由な発想でAIが価値をもたらせるシナリオを探し、自分たちだけのオリジナルなAIソリューションを創出していただくことを期待しています。
6-3. 解決策に求められる4つの要件——モジュール活用・実業務課題・成果物の完成度・パフォーマンスとUX
Leah Yuan： 参加者の皆さんがソリューションを構築するにあたって、特に意識していただきたい4つの要件があります。
第1の要件は、OPEAのモジュール式コンポーネントの活用です。LLMやRAGといったOPEAのモジュール式コンポーネントを使用して、エンタープライズのニーズに合わせたソリューションを構築してください。既存のOPEAブループリントをベースに改変することも、新しいパイプラインをゼロから構築することも可能です。いずれの場合もOPEAの再利用可能なコンポーネントを活用することが前提となります。
第2の要件は、選択する産業領域の実用的な価値です。取り組む垂直ドメインは、実際のビジネス上のペインポイントに対処し、測定可能なビジネスインパクトを示せるものでなければなりません。単なる技術デモにとどまらず、現実の企業課題を解決できるソリューションであることが求められます。
第3の要件は、成果物の完成度です。ソリューションの構築が完了したら、ソースコードと包括的なドキュメントを含むプロトタイプとして提出してください。コードだけでなく、ソリューションの内容を適切に説明するドキュメントが伴っていることが重要です。
第4の要件は、パフォーマンスとユーザビリティの実証です。プロトタイプは典型的なエンタープライズのハードウェア上で動作するよう最適化されており、明確なパフォーマンス指標と優れたユーザー体験を備えていることを示す必要があります。技術的な完成度だけでなく、実際に使いやすいソリューションであることを証明することが求められます。
7. 評価基準・提出要件・ハードウェア制約
7-1. 採点基準——創造性・技術実装・プロトタイプ品質の配点とボーナス点（最大140点）
Leah Yuan： 提出されたソリューションの評価は、複数の専門家が定められた基準に基づいてスコアリングする形で行われます。評価の軸は大きく3つあり、合計100点満点に加えてボーナス点が最大40点加算される構造になっています。
まず最も配点が高いのが技術実装で、40点が割り当てられています。OPEAのコンポーネントをどれだけ適切に活用し、技術的に堅牢なソリューションを実装できているかが問われます。次に創造性とビジネス価値に30点が配点されています。どれだけ革新的なアイデアを持ち、かつ実際のエンタープライズの課題に対して測定可能なビジネスインパクトを示せるかが評価されます。3つ目はプロトタイプの品質で、30点が割り当てられています。提出物の完成度、ドキュメントの充実度、ユーザー体験の質などが総合的に評価されます。
これら100点に加えて、最大40点のボーナス点が設けられています。ボーナス点の対象となるのは3つの観点です。1つ目はオープンソースへの貢献で、Apache 2.0またはMITライセンスのもとでコードを公開しているかどうかが評価されます。2つ目はナレッジシェアリングへの貢献です。チャレンジを通じて得た知見や技術的な学びを広く共有しているかどうかが問われます。3つ目はハードウェア最適化です。典型的なエンタープライズのハードウェア制約の中で、いかに効率的にソリューションを動作させているかが評価されます。これらのボーナス点すべてを獲得できれば、最大140点という高スコアを狙うことができます。
Shan Wang： 補足として強調しておきたいのですが、採点基準はチャレンジのページで公開されており、複数の専門家が基準に基づいてスコアリングします。そして何よりも大切なのは、提出物の最低条件として、アプリケーションが実際に動作することです。どれだけ優れたアイデアや丁寧なドキュメントがあったとしても、ソリューションが実際に動かなければ評価の対象になりません。提出前に必ず動作確認を行ってください。
7-2. 提出物の要件とハードウェア制約——ソースコード・README・技術レポート・デモ動画・RAM/CPU/展開条件
Leah Yuan： 提出物として必要なものは以下の通りです。まず完全に機能するソースコードで、ワンクリックで展開できる能力（one-click deployment capability）を備えていることが求められます。次にREADMEファイルが必要で、システムの概要、セットアップ手順、ハードウェアおよびソフトウェアの要件、期待される動作結果を含む包括的なドキュメントを記載してください。また、システムアーキテクチャ、使用したコンポーネント、展開戦略、ユースケースの関連性を説明する技術レポートも必要です。さらに、プロジェクトはApache 2.0またはMITライセンスのもとでオープンソースとして公開することが推奨されます。最後に、ソリューションの内容を短時間で把握できるデモ動画を準備することが望ましいとされています。
提出方法については、主催者側が用意するGitHubオーガニゼーションにリポジトリを作成し、そこにコードを含む提出物一式をプッシュする形となります。主催者はそのリポジトリにアクセスし、ダウンロードして評価を行います。詳細な提出先については、ウェブサイトで随時更新される情報を確認してください。
ハードウェア制約については、エンタープライズシナリオという性質上、典型的な企業環境を想定した制限が設けられています。RAMは64GB以下、CPUは4コア以内に収める必要があります。GPUの使用は任意であり、必須ではありません。展開はシングルノードのみとされており、マルチノードのクラスタ構成は対象外です。また、クリーンな環境へのインストールが10分以内に完了できるよう、インストールの容易さも求められています。これらの制約は、高価なインフラを持たない一般的な企業でもソリューションを実際に導入・運用できることを担保するためのものです。参加者はソリューションを設計する段階からこれらの制約を念頭に置き、最適化を図ることが求められます。
8. スケジュール・賞品・参加メリット
8-1. タイムラインと賞金——登録開始から表彰まで、延長の可能性と各賞の内容
Leah Yuan： 続いてチャレンジのスケジュールについてご説明します。登録はすでに2月14日から開始されており、本日のウェビナーはその開幕を告げるオープニングウェビナーとして位置づけられています。登録開始後は競技フェーズに入り、参加者の皆さんはソリューションの開発と提出に向けて取り組んでいただくことになります。競技フェーズは6月5日までを予定しており、4月中にはOPEAを使ったソリューション実装に関してさらに詳しく学べるメンタリングセッションを開催する予定です。疑問点や実装上の困りごとがあれば、このセッションを積極的に活用してください。
その後、6月5日から6月19日の期間に評価フェーズが設けられ、提出されたソリューションを専門家が審査します。評価が完了した後、ジュネーブで開催されるAI for Goodグローバルサミットの場で受賞者を発表する予定です。ただし、現時点ではタイムラインが延長される可能性が高いと見ています。例えば8月まで延長することで、参加者の皆さんがより十分な時間をかけてコーディングや提出準備に取り組める環境を整えたいと考えており、そのほうがより高いクオリティの成果が期待できると判断しています。タイムラインに変更が生じた場合は随時お知らせしますので、ウェブサイトを定期的にご確認ください。また、スケジュールの延長に伴い、表彰の場がジュネーブのAI for Goodグローバルサミットから、北京で9月に開催されるFGIN（ITUのフォーカスグループ会議）に変更される可能性も高いとお伝えしておきます。
賞品については、合計6名の受賞者が選ばれます。1位は1名で、賞金5,000スイスフランに加え、中国で開催されるFGIN会議への航空券と宿泊費が提供されます。2位は2名で、それぞれ3,000スイスフランが授与されます。3位は3名で、それぞれ1,500スイスフランが授与されます。受賞者のソリューションは理想的にはジュネーブのAI for Goodグローバルサミットでショーケースされる予定ですが、前述のスケジュール延長の可能性を踏まえると、北京のFGIN9月会議での発表となる公算が高く、COIAからのサポートも予定されています。
8-2. 参加による副次的メリット——ITU認定証・論文発表機会・国際ネットワーキング・提供リソース
Leah Yuan： 賞金や特典以外にも、このチャレンジに参加することで得られる副次的なメリットは多岐にわたります。まず、参加者全員に参加証明書が発行されます。さらに受賞者には、ITUが発行するグローバル認定の認定証が授与されます。このITU認定証は国際的な認知度を持つものであり、キャリアにおいても大きなアピールポイントになるでしょう。
また、チャレンジを通じて開発したソリューションや得られた知見を論文として発表する機会も提供されます。研究者や学生の参加者にとっては、自身の研究成果を国際的な場で発表できる貴重な機会となります。
さらに、チャレンジへの参加を通じて、国際的な専門家、大臣、シニアIT専門家、グローバルな通信業界のリーダーたちとのネットワークを築くことができます。こうした人脈は、チャレンジが終わった後も長く価値を持ち続けるものです。
計算リソースについても、必要に応じてCPUおよびGPUが提供されます。リソースが必要な場合は主催者に連絡し、利用申請を行ってください。参加に必要な各種リソースはすべて公開されており、ウェブサイト上のリンクからアクセスできます。今日この瞬間から、エンタープライズAI革命の一翼を担うソリューションの設計・構築・展開に取り組んでいただけることを、私たちは心より期待しています。すべての方が参加資格を持っており、質問やアドバイスが必要な場合はいつでもZTEのLeahまたはIntelのShanにご連絡ください。
9. Q&Aセッション
9-1. エンタープライズシナリオの固有性とRAGが選ばれる理由——決定論性・コスト・知識ベース型アプローチ
Vishnu： ありがとうございました。LeahとShanの素晴らしいプレゼンテーションに感謝します。参加者の皆さんからの質問を受け付けながら、私たちが長年コンペティションを運営してきた経験から、よく寄せられる質問についてあらかじめ議論しておきたいと思います。まず最初の質問です。このチャレンジのテーマである「エンタープライズシナリオ」の固有性についてお聞きしたいと思います。エンタープライズシナリオは、他の種類のデプロイメントやシナリオとどのように異なるのでしょうか？ShanあるいはLeah、参加者がテーマをより深く理解するためにご説明いただけますか？
Shan Wang： 私からお答えします。エンタープライズシナリオの最も重要な特性は「決定論性（determinism）」だと考えています。つまり、企業はAIがいかなるミスも犯すことを許容しません。同じ入力に対しては常に同じ出力が返ってくることが求められます。個人利用のAIとは異なり、企業がAIを推論に活用する場面では、回答のブレや不確実性は許容されないのです。私が実際に顧客と話してきた経験からも、この決定論性への要求は非常に強いと感じています。もちろんセキュリティ、プライバシー、コスト効率なども重要な要素ですが、最も根本的な特性は決定論性であると言えます。
Vishnu： なるほど、それがまさにファインチューニングではなくRAGベースのソリューションを採用している理由でもありますね。RAGはよりクエリベースで知識ベース型のアプローチであり、ファインチューニングと比べてより決定論的にエンタープライズの知識を取得できる。だからこそRAGベースのソリューションを選択されているのではないでしょうか？
Shan Wang： おっしゃる通りです。加えて、RAGはファインチューニングと比較してはるかにコストが低いという点も大きな理由です。ファインチューニングにはトレーニングのためのGPUや追加のインフラ投資が必要ですが、RAGにはそれが不要です。決定論性とコスト効率、この2点がRAGを第一優先とする主な理由です。
9-2. 開発アプローチ・成熟度の期待値・提出方法と採点プロセス
Vishnu： 次の質問です。ソリューション開発のステップについて、特にOPEAをまったく知らない状態から始める参加者にとって重要な情報だと思います。現在利用可能なブループリントの種類、対応するワークフロー、そしてソリューションの種類——たとえばInfosysのようなQuery & Answerなのか、AIネイティブなトラブルシューティングのようなワークフロー自動化なのか——を踏まえて、ゼロから開発を始める場合の重要なステップを教えていただけますか？
Shan Wang： 最も効率的なアプローチをお伝えします。まずGitHubからOPEAプロジェクトをダウンロードし、自分のパソコンや個人のクラスターにデプロイしてみてください。次に、OPEAが提供するシンプルなサンプルを実際に動かして体験してみることが大切です。その上で、AIを使って解決できるシナリオをブレインストーミングしてみてください。そして、自分のシナリオに最も近いOPEAのサンプルを選び、そのコードを自分の要件・シナリオに合わせて修正していく——これが最も手軽で効率的なアプローチだと思います。
Vishnu： ありがとうございます。次に、提出されるソリューションに求められる成熟度についてお聞きします。デモを求めているのか、プロトタイプなのか、それとも製品レベルのものを期待しているのでしょうか？学生の参加者の場合、常に完璧に動くとは限らず、時に失敗することもあります。どのレベルの成熟度が期待されていますか？
Shan Wang： 理想的には成熟したソリューションを求めていますが、参加者の数や候補作品の状況にもよります。もし成熟したソリューションがなかった場合は、創造的で革新的なアイデアを重視します。OPEAのサンプルの中で最も成熟しているのはChat Q&Aです。しかしチャットボットそのものは創造性があるとは言えません。これまでも多くのチャットボットが存在してきました。企業が利用でき、課題を解決できるシナリオを考え出し、最もクリエイティブなソリューションを評価します。成熟したソリューションが理想ですが、最終的には成熟度と創造性の両方を兼ね備えたエンタープライズ向けソリューションを期待しています。
Vishnu： 最後にLeahへの質問です。提出方法について教えてください。GitHubリポジトリとして提出するのか、ZIPファイルやDockerイメージで提出するのか、具体的にどのように、どこに提出すればよいのでしょうか？
Leah Yuan： 非常に重要な質問ですね。提出先については、主催者側がGitHubオーガニゼーションを用意しますので、そこにご自身のGitHubリポジトリを作成してプッシュしてください。私たちがそのリポジトリにアクセスし、ダウンロードして評価を行います。提出物の内容については、スライドをご確認いただきたいのですが、コードに加えてソリューションの説明も必要です。具体的には、READMEと技術レポートをすべての提出物に含めてください。詳細な提出先については、ウェブサイトを更新してご案内する予定です。
Shan Wang： 補足させてください。採点基準についてはチャレンジのページで公開しており、複数の専門家が基準に基づいてスコアリングを行います。そして改めて強調しておきたいのですが、どのような提出物であっても、最低条件はアプリケーションが実際に動作することです。提出する以上は、ソリューションが実際に動くことを必ず確認してください。
10. クロージングと今後の案内
10-1. リソース提供・メンタリングセッション・参加呼びかけ
Vishnu： LeahとShan、そしてQ&Aセッションにご協力いただいたすべての皆さんに感謝申し上げます。最後まで本セッションにお付き合いいただいた参加者の皆さんにも御礼申し上げます。
Jaying： チャレンジはすでにウェブサイトで公開されており、動画のウォールにもチャレンジへのリンクを掲載しています。このチャレンジにご興味のある方は、今すぐご参加いただけます。ソリューションの開発を開始し、登壇者からご説明いただいた基準に従って、ポータルサイトに結果を提出してください。計算リソースについては、必要に応じてCPUおよびGPUを提供します。リソースが必要な場合はご連絡いただき、必要な内容をお知らせください。今後もさらにセッションを予定していますので、AI for Goodのプログラムページで詳細をご確認ください。また、4月中にはOPEAを使ったソリューション実装についてより深く学べるメンタリングセッションも予定しています。実装上の疑問点や困りごとがあれば、このセッションをぜひご活用ください。皆さんと将来のセッションでお会いできることを楽しみにしています。本日はご参加いただき、誠にありがとうございました。またお会いしましょう。