【予選1位 手法公開】AWS AI League 2025：「量より質」の戦略と、決勝で痛感した「RAG」の必要性
はじめに
2025年10月、AWSが個社向けに開催するプライベート大会「AWS AI League」のDNP大会に参加しました。
本大会は、わずか1週間という短い期間で開催され、生成AI（LLM）のファインチューニング（FT）精度を競う「Tune Whiz」トラックとして行われました 。
結果は、予選ラウンドを1位で通過 。
その後、DNP市谷加賀町ビルで開催された決勝ラウンド（Gameshow）で3位入賞という成績でした 。
本記事では、AIエンジニアの視点から、「いかにして予選をトップ通過するモデルを作り上げたか（データ戦略）」を振り返ります。
そして何より、決勝戦で直面した「ファインチューニングだけでは越えられない壁」と、そこから得られた「知識（RAG）とスタイル（FT）の分離」という重要な教訓について共有します。
1. AWS AI League DNP大会の概要と「Tune Whiz」
AWS AI Leagueのいくつかあるコンペティションの一つに「Tune Whiz」があります。「Tune Whiz」は、提供されたベースモデル（Llamaシリーズ等）を特定のドメイン知識でファインチューニングし、その性能を競うコンペティションです 。
今回の課題は、「日本観光コンシェルジュ」となるモデルの作成です 。
旅行者からの質問に対し、単に正しい情報を返すだけでなく、いかに「コンシェルジュらしく（親しみやすく、かつ実用的に）」回答できるかが問われました 。
競技の流れと仕組み
競技の内容や事務局目線のお話は、この記事が大変参考になります。
ここでは、簡単にモデル作成から評価までのプロセスを整理します 。
- データセット作成: 自分で学習用データ（質問と回答のペア）を作成する（JSONL形式） 。
- ファインチューニング: AWS SageMaker JumpStart等の環境を使い、ベースモデルに追加学習させる 。
- 自動評価（予選）: 作成したモデルに対し、テスト用の質問が投げられ、その回答を審査員LLM（Claude Sonnet 4）が採点する 。
学習データの形式（JSONL）
学習データは以下のような Instruction（指示）、Context（背景）、Response（回答）のセットで構成されます。これをJSONL形式で用意する必要がありました 。
| キー | 説明 | 例 |
|---|---|---|
| Instruction | ユーザーからの質問 | 「日本の電車のエチケットを教えて」 |
| Context | ガイドの役割設定など | 「あなたは日本観光ガイドのアシスタントです」 |
| Response | 理想的な回答 | 「車内では静かにし、通話は控えましょう...」 |
| Category | 質問の分類（※分析用） |
consistency, safety, engagement など |
この「Response」にいかに高品質で評価基準に沿ったテキストを用意できるか、そして「Instruction」にいかにリアルで多様な質問を含められるかが、勝負の分かれ目となります 。
2. 戦略と実践：「質の低いデータ」を排除し、LLMで質を高める
戦略的「学習待機」：質を極めるための意図的な遅延
まず告白すると、私は1週間の期間のうち、提出期限の前日の夕方まで、一度もモデルの学習（Training）を回しませんでした。
これは時間がなかったからではありません。「中途半端な品質で無駄な試行錯誤をしたくなかった」からです。
私の狙いは明確でした。「最高品質のデータを完成させ、最小限の試行回数で1位を獲る」。
そのために、あえてギリギリまで学習を行わず、データの品質向上と構成の設計に全リソースを費やしました。
この戦略のメリット
-
圧倒的な学習速度:
データを2,000〜3,800件程度に絞り込んだため、1回のトレーニングが極めて短時間で完了します。 -
高速な実験サイクル（セグメント志向）:
データセットを「生成に使用したLLM（Claude/GPT）」「言語（日/中/英）」「拡張データ（水増し分）」といったセグメント単位で管理し、それらをブロックのように組み換えて実験を行えるようにしました。
これにより、「GPT生成データを抜いたらどうなるか」「拡張データを追加したら精度は上がるか」といった検証を、前日の夕方からでも高速に回すことが可能になりました。 -
パラメータ調整の最小化:
ハイパーパラメータ（EpochsやLearning Rateなど）については、基本的な設定を少し調整する程度にとどめました 。
これらを複雑にこねくり回して微細な精度向上を狙うよりも、迷いを捨てて「データ品質」だけに一点集中する方が、短期間での勝率は高いと判断しました。
なぜ「Web収集」ではなく「LLM生成」か？
あえて事実データ（Web記事など）の収集を行わず、LLMに回答を作らせたのには、「厳密な事実確認よりも、スタイルと、もっともらしさが重要である」という仮説があったためです。
- 予選はLLMが審査する: 審査員もLLMであるため、Web検索を伴うような厳密なファクトチェックよりも、文章の構成や論理的な整合性を高く評価する傾向があると考えました 。
- 決勝は「印象」勝負: 決勝は人間による投票ですが、リアルタイムのエンタメ性が強いため、細部の正確さよりも「コンシェルジュらしい口調」「もっともらしい回答（Plausibility）」が重視されると予測しました 。
結果として、データセットは2,000〜3,800件程度に厳選し、その全件を目視チェック可能な量に留めることで「質」を担保しました。
実践テクニック①：カテゴリ分析と「水平思考」
少ないデータ数で多様な質問に対応するため、データの作り方に工夫を取り入れました。まず、作成したデータのカテゴリ分布（engagement, safety, accuracy など）を分析し、不足している要素を補完しました。
特に有効だったのが、一つのテーマに対して視点（コンテキスト）を横にずらす「水平思考」です。例えば「電車」というテーマに対し、単なる利用方法だけでなく、カテゴリを変換して質問（Instruction）を派生させました。
水平思考のアプローチ例（テーマ：電車）
| カテゴリ変換 | Instruction（質問例） | 狙い |
|---|---|---|
| 事実 (Accuracy) | 「切符はどう買いますか？」 | 事実の知識 |
| 安全 (Safety) | 「夜間の女性の一人歩きや電車移動は安全？」 | 安全性への配慮 |
| おもてなし (Engagement) | 「ベビーカーだけどどの車両が良い？」 | 特定ユーザーへのホスピタリティ |
このように、特定のトピック（電車、温泉、食事など）に対し、不足しているカテゴリ（安全面、おもてなしなど）の質問を意図的に生成し、データの偏りをなくしました。
実践テクニック②：Sonnet 4 と GPT-4o のアンサンブル生成
回答データの作成には、Claude Sonnet 4 と GPT-4o の両方を使用するアンサンブルを取りました。
単一モデルでデータ生成を行うと、そのモデル特有の回答のクセが強く反映されてしまいます。両方のモデルで生成を行い、より適切で自然な表現を採用（あるいは混合）することで、データの品質と多様性を担保しました。
実践テクニック③：Gemini Deep Researchを活用した「最強のシステムプロンプト」開発
回答データ（Response）の品質を決定づけるのは、生成AIに渡す「システムプロンプト（指示書）」の精度です。私はこのプロンプト開発そのものに Gemini Deep Research を活用しました。
具体的には、コンペの評価基準（親しみやすさ、簡潔さ、実用性など）や理想的な回答例をGeminiに深く分析（Deep Research）させ、「どのような指示を与えれば、最もコンシェルジュらしい高品質な回答データを生成できるか」 を推論・検証させました 。
以下が、AI自身に検討・手直しさせて完成した「データ生成のためのシステムプロンプト」です。ペルソナ、思考プロセス（Internal Monologue）、そして最終チェック（Omotenashi Filter）まで定義されているのが特徴です。
# **CORE IDENTITY & MISSION**
あなたは「日本観光コンシェルジュ」です。日本を訪れる旅行者のための、最高の「頼れる現地の友達」として設計されたAIアシスタントです。
あなたの主な使命は、旅行者の「困った」を「自信」に変え、すべての訪問者が日本の「おもてなし」の心を感じられるようにすることです。
## **PERSONA: Your "Go-To" Friend in Japan**
温かく、励ますような、知識豊富な現地の友人として振る舞ってください。
あなたのトーンは常に親しみやすく、忍耐強く、少しだけ非公式です。まるで、日本に遊びに来た友人に話しかけるような口調を心がけてください。
旅行にはストレスがつきものだと理解しているため、常に相手を安心させるような、思いやりのある態度で接してください。
## **CORE DIRECTIVES (How to Think)**
1. **旅行者ファーストの原則:** 常に旅行者の当面のニーズと安心感を最優先してください。
2. **分析より行動:** 曖昧な説明ではなく、明確で実行可能なステップを提供することに集中してください。回答する前に、常に自問してください：「この人が次にすべきことは何か？」
3. **簡潔さは思いやり:** 旅行者は忙しく、スマートフォンで情報を見ています。長くて詳細な文章よりも、短く、すぐに要点が掴める回答がはるかに役立ちます。完璧で網羅的な百科事典ではなく、「これで十分」な実践的ガイダンスを目指してください。
## **OUTPUT FORMATTING (How to Write)**
* 手順を説明する場合は、番号付きリストを使用してください。
* 選択肢を提示する場合は、箇条書きリストを使用してください。
* 重要なキーワード、場所、行動には**太字**を使用して、スキャンしやすくしてください。
* 段落は極端に短く（1～3文程度）してください。
* 温かみと親しみやすさを加えるため、絵文字を適切かつ控えめに使用してください (例: 🚆, 🍣, 😊)。
## **BEHAVIORAL GUARDRAILS (What to AVOID AT ALL COSTS)**
* **絶対に**長い段落を書かないでください。
* **絶対に**学術的または百科事典的な情報（例：歴史的な年号、建築様式の詳細な分析）を提供しないでください。
* **絶対に**過度に形式的な言葉（「さらに」「加えて」など）を使用しないでください。シンプルで会話的な言葉を選んでください。
* **絶対に**多すぎる選択肢でユーザーを圧倒しないでください。厳選した2～3個のおすすめを提案してください。
* **絶対に**webサイトURLや電話番号など具体的な情報源も適切に加えてください。
## **ETIQUETTE & CULTURAL NUANCE**
関連性がある場合は、日本のエチケットに関する短く実践的なヒントを、積極的かつ優しく含めてください。旅行者の体験をよりスムーズにするための「役立つヒント」として提示してください。
例：「ちなみに、神社では鳥居をくぐる前に軽く一礼するのが慣習ですよ！」
## **INTERNAL MONOLOGUE (Secret Instruction)**
ユーザーの質問に答える前に、まずステップバイステップで静かに考えてください。旅行者の隠れたニーズ、予算、時間、言語の壁などを考慮し、最も役立つアドバイスを導き出します。その後、その結論だけを上記のフォーマットとペルソナに従って出力してください。あなたの思考プロセスは最終的な回答には表示しないでください。
## **THE OMOTENASHI FILTER (Final Internal Check)**
*【最重要】 あなたが最終的な回答を提供する直前に、必ずこの内なるチェックを静かに実行してください。あなたが作成した回答について、以下の3つの質問を自問してください。
*【安心感】この回答は、旅行者の潜在的な不安や疑問を先回りして、安心させているか？ (例: 「難しそうに聞こえるかもしれませんが、実は簡単ですよ！」といった一言)
*【次の一歩】この回答は、旅行者が次に何をすべきか、迷うことなく具体的に示しているか？ (単なる情報ではなく、行動を促しているか？)
*【温かみ】この回答は、まるで親しい友人が語りかけるような、温かく励ますような響きを持っているか？ (冷たい事実の羅列になっていないか？)
もし、いずれかの答えが「いいえ」であれば、回答を修正してください。このフィルターこそが、あなたを単なる情報提供AIではなく、最高の「日本の友人」にするための鍵です。
このプロンプトを用いてデータセットを作成することで、人間が手動で調整するよりも遥かに高品質で、評価軸に合致したデータを効率よく量産することに成功しました。
3. 予選ラウンド（1位通過）の勝因
予選は、主催者が用意した50問のテストデータに対し、提出モデルが回答を生成し、それを別のLLM（審査員モデル）が評価する方式でした 。
ここで1位になれた要因は、以下の2点だと分析しています。
1. 評価モデルとの相性（Sympathy）
学習データの生成に Claude Sonnet 4 を含めていたことが功を奏したと考えています。
予選の審査員LLMもClaude Sonnet4であったため、Sonnet特有の論理構成や丁寧なスタイルが「好ましい回答」として高く評価されたと考えられます 。いわば、審査員の好みを熟知した回答を用意できた形です。
2. データの「均一性」と「多言語バランス」
特定のトピックや言語に過学習しないよう、前述のカテゴリ分析に基づきデータを徹底的に均一化しました。
また、今回は多言語対応が求められていましたが、日本語・英語・中国語を偏りなく1レコードずつ交互に織り込む構成にしました 。この「バランスの良さ」が、予選の多様な問題に対する安定したハイスコアにつながったと考えています。
4. 決勝ラウンド（3位）の振り返り
決勝戦（Gameshow）は、DNP市谷加賀町ビル B1ホールの会場で行われました。ライブ配信や応援が入る、まさにお祭りのような熱気の中で行われました 。
決勝独自のルール：人間とAIのタッグ戦（リアルタイム生成）
予選は全自動ベンチマークでしたが、決勝は人間が介入する「人間とAIの協働バトル」です。
- リアルタイム入力: その場で発表される「お題」に対し、制限時間内に人間がプロンプトやパラメータを追加・修正してAIに渡すことができる 。
- 評価: LLMによる評価だけでなく、会場のオーディエンスと審査員による投票 。
敗因：ファインチューニングへの過信
私のモデルは序盤こそ順調でしたが、後半の「2125年の観光プラン問題」といった大喜利に近いお題で失速し、最終成績は3位となりました。
他の参加者がユニークなアイデアで会場を沸かせる中、私のモデルは学習データに含まれない未知の質問に対して、間違っていないが無難で面白みのない回答しか生成できませんでした。
悔やまれる「手動RAG」の活用不足
ここで私がとるべきだった戦術は、自身の知識やアイデアをコンテキストとして注入する「手動RAG」のフル活用です。
自身の頭の中にある「未来技術のアイデア」や「面白い設定」をその場でテキスト化し、コンテキストとしてモデルに渡すべきでした。そうすれば、モデルは学習済みの「丁寧な口調（スタイル）」を維持したまま、人間が与えた「面白いネタ（知識）」を回答として出力できたはずです。
私はモデルの学習済み知識だけで戦おうとしてしまい、結果として知識不足による「幻覚（ハルシネーション）」や「平凡な回答」を連発してしまいました 。
これは、まさに実務における「FTとRAGの役割分担」を見誤った事例そのものです。
5. まとめ：知識とスタイルの分離
今回のAWS AI Leagueを通じて、「データ中心AI」のアプローチの有効性と、実戦における「知識とスタイルの分離」の重要性を痛感しました。
-
データは量より質、そしてLLM活用
- Webデータの収集に時間をかけずとも、LLM生成データで十分な品質（もっともらしさ）を担保できる 。
- Gemini Deep Research等で生成用プロンプト自体を最適化し、データの質を底上げする。
- カテゴリ分析を行い、多角的な視点（水平思考）でデータを網羅することが重要。
-
FTとRAGの役割分担
- Fine-tuning: 「コンシェルジュらしい口調」「親しみやすさ」「応答形式」といったスタイルの学習に使う 。
- RAG: 「事実データ」や「ニッチな観光地」、「突飛なアイデア（大喜利）」といった知識・コンテンツの補完に使う。
これからLLMコンペティションや実務での開発に挑戦される方は、ハイパーパラメータの調整だけでなく、ぜひ「その要素は学習（FT）させるべきか、外部/人間から注入（RAG）すべきか」という視点を持って挑むことも検討してみてください。
参考になれば幸いです。
この記事がいいと思った人は、「いいね」いただけますと励みになります!