OCIでAIデモを作るパートナーイベント、「Partner AI Demo選手権」参加レポート

今や「AI」という言葉を聞かない日はないと感じるほど、私たちの生活にAIは急速に浸透してきています。とはいえ、このAIを使って「何ができるのか」ということについては、まだまだ試行錯誤の段階にあるのも事実です。

私たちクラウドエンジニアにとっても、AIは決して無関係な存在ではありません。しかし、「AIをどう活用すればよいのか」といった具体的なイメージが湧かないというのが正直なところでした。少なくとも、この記事を書いている時点ではそうでした。そんなとき、日本オラクル主催で行われる「Partner AI Demo選手権」の案内をもらいました。この記事では、イベントに参加して気づいたAI活用の視点についてお話しします。

Partner AI Demo選手権

日本オラクルでは、OPNパートナー企業向けに、その時々のトレンドをテーマとした勉強会・ワークショップを定期的に開催しています。2026年3月10日に開催された回では「AI」をテーマに、各社がAIを活用したデモを発表するPartner AI Demo選手権が行われました。

イベントの告知が行われたのは2025年12月2日で、そこから約3か月の準備期間を経て、私たちはこのイベントに臨みました。エントリーは「短編部門」と「長編部門」の2部門に分かれていました。審査は、本イベントの参加者および日本オラクルの社員が行い、以下の観点をもとに投票する形式でした。

共通

• 1.オリジナリティ（斬新さ・独自性）
• 2.課題設定＆リアリティ（実在し得る顧客シナリオか）
• 3.タイムマネジメント/表現力（時間内に分かりやすく伝え切る）
• 4.エキサイティング（インパクト・驚き）
• 5.顧客訴求力（欲しい/買いたい度・売りやすさ）

短編部門（3分程度）

• A.ビジネス的ポテンシャル（価値が短時間で伝わるか）
• B.技術スキル/完成度（デモの実装力・動作/見せ方）

長編部門（10分程度）

• A.売上インパクト（想定売上/ビジネス貢献）
• B.Oracle技術の活用度（Oracle/OCI AIならではの価値）
• C.横展開可能性（再利用性・Enablement観点）

今回、ラックからはOracle Cloud Infrastructure（以下、OCI）チームの石井真帆、小林夢居、AIチームの加藤央彬の、部署を横断した3名でチームを編成して出場しました。石井と小林は、これまで業務においてAIの実装に取り組んだ経験がほとんどありませんでした。加藤はAIに詳しいものの、OCIのAI機能についてはあまり触ったことがない状態でした。そのため、まずは石井と小林はAIに触れてみることを、加藤はOCIのAIに触れてみることをそれぞれ目的とし、挑戦しやすい短編部門にエントリーしました。

作成したデモの概要

普段、あまりAIを意識せずに業務をしていると、「どんなデモを作ったらよいのか」という点について、なかなか具体的なイメージが沸きませんでした。チーム内にはAIに詳しいメンバーもいましたが、全員が共通してイメージできるテーマはなかなか思いつきません。そこでまずは、身近なところから考えようと、自分たちの課題解決に役立つものをテーマにデモを作ることにしました。

デモタイトル

"規程"と"実績"で答える申請アシスタント

このデモで解決したかったこと

このデモでは、私たちが日々の業務で感じていた、次の2つの課題を解決したいと考えました。

• 社内制度は規程集に記載されているものの、利用条件や手続きが複雑に書かれており理解しづらい
• 過去の実績を踏まえて、今回の申請が承認されそうかを事前に確認したい

これらの課題を踏まえ、規程集と過去の承認・差戻し実績のデータをもとに、自然言語でこれから申請したい内容を確認できる仕組みを考えました。申請前に否認される可能性があるかを確認することで、社内申請における手戻りや確認工数の削減、さらには承認プロセス全体の効率向上を目指しています。

デモの概要

社内制度の申請について、チャット形式で質問し、回答を生成するデモを作成しました。回答には根拠となった規程や過去の実績データもあわせて表示するようにしています。今回のデモでは、社員同士のコミュニケーションを活性化させることを目的とした、「コミ活」という制度を題材にしました。ランチ会や飲み会などに対して会社から補助金が出る制度について、チャットで問い合わせができるようになっています。

使用した機能・技術

検索+AI処理（検索拡張生成（Retrieval-Augmented Generation：以下、RAG））

• OCI Generative AI
• Autonomous AI Database
• Select AI
• OpenSearch
• Object Storage

API連携

• API Gateway

入口、アプリ

• Load Balancer
• Compute
• OCI Functions

環境構築

今回の構成の特長や工夫した点について紹介します。環境構築にあたっては、RAG構成をベースに、構造化データ（過去の承認データ）と非構造化データ（規程データ）を組み合わせて扱う点を意識しました。

Select AI

今回のデモでは、Autonomous AI Database 26ai上にSelect AIを実装し、データベースには過去の承認データを取り込む構成としました。環境構築にあたっては、Select AIの回答精度を高めるために、主に2つの工夫を行っています。

テーブル・列コメントの付与によるデータ理解の補強

1つ目の工夫は、テーブルや列へのコメント付与です。各テーブル・列に対して、以下の情報をコメントとして明示的に付与しました。

• データが何を意味しているのか
• どのような用途で使われるのか
• 検索時のルールや注意点

これにより、Select AIは単にカラム名やデータ型を見るだけでなく、データの意味まで含めて理解できる状態になります。実際にコメントを付与したあとは、生成されるSQLがより意図に沿ったものになり、回答のブレが大きく減少するなど、すぐに効果を実感することができました。

フィードバック機能を使った継続的な精度向上

2つ目は、Select AIのフィードバック機能の活用です。DBMS_CLOUD_AI.FEEDBACKパッケージを利用し、Select AIの回答に対して明示的なフィードバックを行いました。具体的には、以下の対応を行っています。

• Select AIが生成したSQLが想定どおり正しい場合は、そのSQLを受け入れるフィードバックを実施
• 回答が想定と異なる場合は、正しいSQLクエリの提示や、自然言語で改善点を伝えるフィードバックを実施

これらのフィードバックを蓄積していくことで、Select AIはどのような回答が正解なのかを学習していきます。

実際に使ってみて感じたこと

回答精度向上のために行った2つの工夫のうち、コメント付与については効果がすぐに現れ、回答内容が明確に改善されました。データの意味を明示することが、Select AIの理解度向上に直結していることを実感しました。

一方で、フィードバック機能については即効性があるわけではなく、フィードバックを送信してから回答の修正が反映されるまでに時間がかかるケースもありました。また、一度は想定どおりの回答に修正された場合でも、問い合わせ文を少し変えると期待通りに動作しないこともあり、フィードバックによる改善は一朝一夕ではないという印象を受けました。ただし、フィードバックを継続して与えていくことで、少しずつ回答の精度が向上していくことも確認できたため、Select AIのチューニングには時間をかける必要があると感じました。

チャンク戦略

RAGの検索品質を高めるうえで、文書をどのような単位でチャンク化するかは重要な設計ポイントです。

まず初期構成では、UTL_TO_CHUNKSプロシージャを利用し、固定長分割にオーバーラップを持たせる形でチャンク化を行いました。固定長方式は処理がシンプルで扱いやすい一方、文章構造や意味の切れ目を考慮しないため、文の途中や関連する内容の境界で分割されることがあります。

実際に検証したところ、意味的に分断されたチャンクが検索対象になることで、検索結果に十分な文脈が含まれず、期待した回答精度が得られない場面がありました。そこで、チャンクの意味的な一貫性を高めるために、LLMを用いたチャンク化方式を採用しました。意味のまとまりに沿って分割することで、検索時に必要な文脈を保持しやすくなり、結果としてRAGの回答精度を改善できました。なお、Autonomous AI Databaseへはベクトルデータの保存のみを行い、検索はOpenSearchを基盤として使用しました。

OpenSearch

今回は、規程集などの文書データを扱うため、文書検索基盤としてOpenSearchを使用しました。

OpenSearchを使用した理由

文書検索基盤としてAutonomous AI Databaseに集約することも可能でしたが、今回はあえてOpenSearchを採用しました。理由としては、OCIで利用できる複数のサービスを実際に組み合わせて使ってみたかったためです。また、過去の承認データを扱うSelect AIとは役割を分け、文書検索基盤として独立させることで、RAG構成における根拠チャンクの取得を担う構成としました。

API Gateway

APIの公開にはAPI Gatewayを使用しました。API Gatewayを介することで、特定のUIに縛られず、APIから呼び出すさまざまなアプリケーションと連携できる構成としています。

今回はデモ用途のため最小限の構成としていますが、実際に提供する場面を意識し、将来的にさまざまなフロントエンドと組み合わせられるよう、汎用性の高い構成を採用しました。

フロントエンド

アプリケーションを稼働させるComputeはプライベート・サブネットに配置し、外部からのアクセスはLoad Balancerを経由させる構成としました。これは、実務利用を想定した際に、アプリケーションサーバーを直接インターネットに公開せず、公開範囲をLoad Balancerに限定することで、セキュリティと運用性を両立するためです。この構成により、不要な外部公開を避けつつ、トラフィックの分散や可用性の確保、将来的なスケールアウトへの対応もしやすくなります。

APEX等のローコードツールを使用せず、実用を意識した構成にできたことは他社のデモと比較して良かった点だと思います。

出場して学んだこと

Partner AI Demo選手権の結果としては、入賞には至りませんでしたが、多くの気づきや学びを得ることができました。AIについては、チームとしてさまざまな立場や視点を持ちながら取り組みましたが、他社の発表からAIで実現できることの幅広さや活用の可能性を知ることができました。特に、課題設定やユースケースの切り口によって、同じAI技術でも全く異なる価値を生み出せる点が印象的でした。

一方で、自分たちの発表を振り返ると、デモの開発そのものに注力しすぎてしまい、完成したデモをどのように見せるか、どのように顧客へ提案するかといった視点が不足していたと感じています。技術的に優れていることはもちろん重要ですが、それに加えて、自社のサービスとしてどのような価値を提供できるのかを分かりやすく伝えるための発表構成やストーリー作りも、非常に重要であると学びました。

また、開発を進める中で、AIの回答精度を高めるためのチューニングには想像以上に時間がかかるということも実感しました。精度向上は一度で完結するものではなく、試行錯誤を重ねながら継続的に改善していく必要がありました。

次の機会があれば、どのような価値を届けたいのかをより明確にしたうえで、デモ全体の構成や見せ方を設計したいと考えています。また、AIの回答精度についても、検証やチューニングの期間をあらかじめ確保しながら取り組むことで、より実務に近い形での活用につなげていきたいと考えています。

おわりに

今回は最終的に時間が足りず、デモ環境を完成させること自体がゴールになってしまいました。そのため、チューニングに十分な時間を割くことができず、納得のいく完成度まで仕上げることはできなかったのが正直なところです。しかし、今回のAIを使った開発を通じて、どこに時間をかけるべきなのか、どんな観点で発表を行うべきなのかを具体的にイメージすることができました。次回は、今回の学びを活かし、より完成度の高い、価値あるサービスの実現に向けて、さらに挑戦していきたいと考えています。

ラックでは、お客様のシステム環境の課題に合わせた、OCI、AWS、Azureの提案をしています。マルチクラウドやハイブリッドクラウド、AIも含めたシステム構成にお悩みの際は、ぜひお気軽にお問い合わせください。