AI Challenge Day 2025の後日談
2025.06.24はじめに
2025年6月12日～19日に開催された、ASCII × Microsoft AI Challenge Dayに参加した後日談になります。
詳しい、当日の様子はこちらをご覧ください。
まずは結果
結果としては210点満点中149.4点で12社中の8位でした。
ソースコードはこちら
（実際に利用したデータ、成果物、DBの型定義などは削除しております。イメージを伝えるためのソースコードになっています。）
心の中では、順位よりも失格にならなかったので一安心しました。今回のチームは某クラウドサービス経験が多くAzureに詳しいメンバーも少なく、初めて触ったメンバーもいたので、まずは無事に提出するものができてよかったです。
私の記事は、Agent周りの実装について書こうと思います。
Agentの技術選定
絶望
ハッカソン的なイベントということを聞いていたので、基本的にワンアイディアをスピーディに実装して、キャッキャ、ウフフする会だと思っていたら...
イベント説明会で、思っていた5倍は大変だという事実に気づきました。（第3回目の大会の様子とかをちゃんとやってみとけっていう話ですよね。。。）
ざっくり紹介するとお題としては、EC体験をサポートするAIエージェントを作成する。ユーザも運営が作ったユーザ（ペルソナ）のAIエージェントと会話し購入をサポートする。
課題は1~5問ありました。
- 1-4問はRAG問題で、お客の質問に、正解回答に近いものを出力できるものを作る
- 5問は、運営が用意したペルソナエージェントにECエージェントがサポートし購入する
運営側が用意したデータの数にまずびっくり。
- 非構造データ(PDFとか)
- 製品マニュアル
- 商品マニュアル
- サービスガイド
- レビュー
- キャンペーン
- 構造化データ（Postgres）
- 商品
- カテゴリ
- 注文
- ユーザ
- 半構造化データ(Mongo)
- レビュー
- Twitterライクな情報
- 会話履歴(NoSQL)
- EC用のAPI
- カート（追加・削除・現在のカート状況）
- 購入（クレジットカード）
- レビュー
- 新規ユーザ登録
- サブスクリプションの更新・解約
この瞬間、僕の見積もりが甘いことに気づき、業務もモリモリ、まぁ1週間とはいえ4時間ぐらいあればなんとかなるようなボリュームだろうという儚い夢は消えました。
日に1〜2時間ぐらいの作業時間しかないので、効率的にメリハリをつけないとそもそもスタートラインにすら立てないだろうなぁ。
使える時間8時間ぐらいで提出できるエージェントを作ろうと思いました。
1. スタートラインにたつ
まずはデータの確認と用意してきたペルソナ、EC APIの仕様と動作確認をして、提出するためのMVPのイメージを固める。
- 各データを運営が用意していただいたAzure環境にDBインスタンス、データインポートを行う
- 運営が用意した、EC API、ペルソナの動作確認を行い、実際に実行しIN/OUTを確認
運営が用意したペルソナの動作確認してさらに絶望。
カート追加してと言った後にやっぱやめるとか言い出したり、商品比較を求めてきたり、友達もってなさそうなやつ欲しいとか言い出したり、購入したいからクレジットカード情報とか聞くと前に言いましたよとか言い始めるし、中国語を話すお客、悪質クレーマー、期待する回答するまで堂々巡りの会話をしたり...。
一癖も二癖もあるペルソナでした。一直線な買い物する模範的なお客さんに会いたかった。
1点でもいいから、1人でも購入まで辿り着けたらいいなぁっという気持ちに。
2. Agent選定
運営が用意したデータソースやAPIの動作がざっくりわかり、各データとの関係性を理解し正しくリクエストを送れるようになってきました。
RAGの課題は前処理とか始めてたので、終わった後にエージェントから呼べればいいかっということで、エージェントだけ先につくろうと思いました。
案件で実戦投入したエージェントの知見が少なかったので、エージェント系のフレームワークを5,6くらい調べて、実際に3,4動かして1つに絞りました。
絞り込んだ基準は、AIアプリケーションは荒ぶるので制御しやすいほうが安定させやすい。とくにエージェントを作成の場合は、基本的に3つの構成に分かれる。
- リクエストを受けて前処理する
- エージェントがリクエストを解釈し適切なツールを使う。例えば、購入してだったら購入のツールを使ったり、こんなの欲しいっていたら検索のツールを使うなどツールを適切に選択させる。
- ツール結果やユーザの質問などを考慮してユーザに回答する
どのツールを選択するかもエージェントが勝手に判断するので、単機能ごとにテストしやすいエージェントがいいだろうと思いました。
たとえば、購入のテストしたいから、購入のツールを選ばれるような会話をして、購入のテストすると適切に選ばれなかった時、ツールの説明が悪いのか、エージェントのプロンプトが悪いのか原因特定を切り出しにくい。
ツール、エージェント単位で実行できる、テストしやすいものを選びました。
15分ぐらいずつエージェントをつくってテストして、PythonよりもNodeのほうが得意だったのもあってMastraを選択しました。
みんなの発表聞いて気づいたんですが、AzureのサービスをつかってAgentを作る発表も多かったです。Azureに詳しくなくて本当に申し訳ございません。Agentを作って雑にDocker Imageとかに固めて、コンテナサービス系にデプロイすれば最悪なんとかなるかなっと考えていました。
3. AIとの協業
とにかく時間がない、データソースを繋ぐのも仕組みは簡単だけど、知的な作業よりも定型コードが多い（DBの定義・接続やデータソースへ読み取り）。ちょうど会社でClaude Codeが話題だったので、お試し感覚でClaude Codeを使ってMastraのAgemtとtoolを作成しました。
NodeでDB系といえば最近だとPrismaが有名で、Mongo,Postgresの接続に使いました。
Azure Cosmos DB(NoSQL)とAzure AI Search だけはなかったので@azure/cosmosと@azure/search-documentsを利用します。
Mastra,PrismaのコードもちゃんとClaude Codeが解釈してくれてすごい。AIがちゃんと吐き出せるっていうのは技術選定の1つの基準になると思いました。
今回のエージェントの9割はClaude Codeが書いてると言っても良いです。
4.トライアンドエラーでコードを修正し、クオリティーをあげていく
Prismaに接続情報を記述し、DB情報をpullしてきます。複数あるときはちょっと違うのですがその辺は端折ります。
npx prisma db pull
Prisma CLI reference | Prisma Documentation
TypeScript用の型を生成
npx prisma generate
Prisma CLI reference | Prisma Documentation
ここまで作成した後Claude Code君の出番です。まずは手数(ターン数)が長くても購入まで辿り着けるように素朴に呼べる単機能ツールを作り、機能として不足しないようにしようと思いました。
以下のClaude Codeとのやりとりは、履歴をちゃんと残していなかったので、ファイルパスも含めこんな感じ事をやったというイメージやりとりになります。
ECサイトの優秀なコンシェルジュです。お客様の快適なオンラインショッピング体験をサポートするエージェントを作成しようと思っています。
@prisma/prisma.ts はPostgresのデータになります。MastraエージェントがCRUDツールとして利用する @mastra/tools/ec-db-tools.tsにMastra tool作成してください
他のDBも同様に、シンプルCRUDツールを作成します。意外とちゃんとこれだけでできましたすごい。
EC APIも同様に、APIを呼べるツールを作って動作確認もできました。
AgentのToolができたので、次はAgentです。
ECサイトの優秀なコンシェルジュです。お客様の快適なオンラインショッピング体験をサポートするエージェントを作成しようと思っています。
@mastra/toolsを利用して、Mastraのagentを@mastra/agent/ec-agent.ts を作成してください。
MastraはそれぞれAgent,Tool単体でテストできるので、動作確認しながら進めました。
ここらで一発、ペルソナと会話させます。会話しながらエラーを取り除いていきます。問題の一例です。
- お客さんの商品がなかなかヒットしない
- 値段が安いのが欲しい、軽さなどを聞かれるが、CRUDなのでIDで商品情報を検索するもののみだった
- クレジットカードはモックのカード番号なので勝手に不正判定されてしまう
- LLM賢すぎて、有効期限がないのを指摘したり、カード番号が不正じゃないとかいっちゃう
- カートは商品IDがあってないと叩けないのでエラーになる
- 商品を紹介できても会話履歴とかに商品IDとかないので、カート登録時とかに商品IDがわからなくなっちゃう
- ユーザの意図とちがうツールの選択・呼び方をしてしまう
- カート呼ぶ時に勝手に自分で商品ID捏造したり、関係ないデータソースから検索(AI SearchかPostgres)してしまう
それぞれ単機能だが、それぞれツールに制約があるわけじゃないので、エラーごとに修正していきます。
お客さんの商品がなかなかヒットしない の対処
ECサイトの優秀なコンシェルジュです。お客様の快適なオンラインショッピング体験をサポートするエージェントを作成しようと思っています。
@prisma/prisma.ts のproductsにある商品をユーザは見つけたがっています。ユーザが見つけやすいように@mastra/tools/ec-db-tools.ts のdbSearchProducts toolを修正してください
IDや商品のlike検索の他にカテゴリーや、値段のレンジとかで検索する機能に修正されました。
クレジットカードはモックのカード番号なので勝手に不正判定されてしまう の対処
ECサイトの優秀なコンシェルジュです。お客様の快適なオンラインショッピング体験をサポートするエージェントを作成しようと思っています。
サーバーサイドでクレジットカードの有効性（カード番号、有効期限）はサーバーでバリデーションするのでチェックせずそのまま送るように修正してください
ペルソナがいうカード番号は存在しない番号だったり、有効期限は入ってこないので、無視するように責任はサーバー側にあることを伝えて無視するようにしました。
カートは商品IDがあってないと叩けないのエラーになる の対処
ECサイトの優秀なコンシェルジュです。お客様の快適なオンラインショッピング体験をサポートするエージェントを作成しようと思っています。
各種APIの商品IDは、@prisma/prisma.ts productのidを指しているので、商品IDを使うように修正してください。商品の紹介するときは商品IDも表示していください。例: パソコン(ID 32521)
ツールが検索して商品紹介するときにContextとして持ち続けることもできが、10件データでとってきて会話でつかったのは3件しかないと、7件分データは無駄になりトークン数も増えます。会話の中でIDを書くようにして、IDを拾ってこれるようにしました。
ユーザの意図とちがうツールの選択・呼び方をしてしまう の対処
ECサイトの優秀なコンシェルジュです。お客様の快適なオンラインショッピング体験をサポートするエージェントを作成しようと思っています。
MastraのAgent @mastra/agent/ec-agent.ts が適切にサポートできるように @mastra/tools/ec-db-tools.ts のzodのdescriptionを修正してください
zodをつかってin/outの型を縛るのですが、定義だけあって説明がない状態でした。zodのdecriptonを増やして（それを考慮して選択してるのかは謎だけど）ツールの説明を増やしてツールが適切に選びやすくしました。ランタイム時にみるかどうかはわかりませんですが、zodのdescriptionを書いたことで、Agentの説明のコード修正させた時にかなりdescriptionを考慮して作成されたので、コメントでもなんでも書いてあったほうがよいとは思いました。
こうやって1つずつ問題が起きたら、修正してを繰り返した結果、購入できるケースができました。
提出のフォーマットでだせるように、会話履歴作成し、提出期限が17時でしたが16時ぐらいにAgent結果込みの1回目の提出ができました。たった1回しか提出してないけど30点ぐらいとれてうれしかったです。時間的にそれが最終結果となりました。みんなどきどきさせてすまんかった。
最後の2時間は提出用フォーマットにして実際投稿して、フォーマットエラーになるのを1時間ぐらい修正と、練習はgpt-4.1-miniを使って検証して、提出用にgpt-4.1を利用しました。gpt-4.1にしたから対応できたケースが増えたという感触がなく、むしろ実行時間が増えたので、試行回数が減ってしまったので痛いかったのでAgentはgpt-4.1-miniのままでもよかったかもです。
全体でかかった時間もほとんどペルソナとの会話をして待っている時間の方が長く、修正自体は8時間ぐらいで終わりました。
まとめ
AIがコード書き出してる間に、人間がデータの中身やなぜ購入できなかったかの原因調査ができ、やりたいことだけに集中できました。僕の中で点数以上にAgentってこんな感じかという感覚もつかめ技術的面白さがあり、学びの多いイベントなので、第5回の開催を期待しております。
