1. はじめに
こんにちは！NTT東日本の森田です。
普段はデータ利活用案件に取り組みつつ、Kaggle Masterとしてコンペにも継続的に参加しており、その経験を活かして社内でKaggleや生成AI活用の輪を広げる活動をしています。
今回はその活動の一環として、NTTグループ横断のKaggleイベントを開催しました。
当日は、LT発表とハンズオン形式のオリジナルKaggleコンペを実施し、現地対面で約80名、オンライン参加も含めると合計約100名が参加しました。
結果として、参加者の約60%がコンペ未経験であったにもかかわらず、イベント満足度は 4.73 / 5、「Kaggleの楽しさを感じられましたか？」という設問でも 4.71 / 5という非常に高い評価をいただきました。 Kaggle未経験・Python初心者の方にも「楽しかった」「ハードルが下がった」という声を多くいただき、当初の目的を大きく達成できたイベントになりました。
その目的とは、Kaggle経験者だけで競うことではなく、Kaggleやプログラミングにまだ慣れていない人も含めて、データ分析・AI活用の裾野を広げることです。
そこで、コンペ自体も「Pythonを書けない人でも参加できる」設計にしました。参加者は、Kaggle Notebook上のプロンプト文字列を工夫するだけで、同じモデルに対してよりよい指示を与え、スコア改善を目指す形式です。
本記事では、大成功に終わった本イベントの内容や運営の工夫、当日の様子、反省点などを実体験ベースで詳しく紹介します。
今後同様のイベントを開催する方への具体的なTipsもまとめていますので、ぜひ参考にしてみてください！
2. イベント開催の背景
社内には、Kaggleに興味はありつつも、最初に何をすればよいか分からなかったり、チャレンジしてはみたものの途中で挫折してしまったりする人も少なくないと考えています。
一方で、グループ内にはKaggle MasterやKaggle Expertとして継続的に取り組んでいるメンバーも在籍しています。
しかし、これまではそうした初心者と経験者が自然につながる機会があまりありませんでした。
そこで、Kaggleに取り組んでみたい初心者と、すでにKaggleに取り組んでいる経験者をお互いにつなぐことで、グループ全体のデータ活用力・AI活用力・挑戦文化を底上げしたいと考え、「NTT Kaggler会」というNTTグループ横断コミュニティを立ち上げました。
今回はその第1回イベントとして本イベントを開催しました。
3. イベント当日の様子
当日は、まずLT発表で、去年まで初心者だったが今Kaggleに熱中しているメンバーや、Kaggle Masterのメンバーなど、計2名が登壇しました。
その後に全員でオリジナルコンペへ参加しました。
会場では、Kaggle初心者の方も多かったため、運営メンバーが各テーブルを巡回しながら、コンペへのJoin、Notebookの設定、Submit方法などをサポートしました。
オンライン参加者もいたため、説明はできるだけ手順を絞り、全員が同じタイミングで最初のSubmitまで到達できることを重視しました。
コンペ終了後はプライベートリーダーボードを発表し、上位者にはその場でプロンプトや工夫したポイントを共有してもらいました。
4. コンペの内容
今回用意したコンペは、日本語の社内投稿トーン分類です。
社内チャット、Slack、Teams、社内掲示板などに投稿された短文を読み、その投稿文が読み手に与える印象を、次の5クラスに分類します。
なぜ「オリジナルコンペ」なのか
Kaggleに興味を持ってもらう打ち手としては、勉強会、LT会、読書会など他にもあります。
しかし、自分がKaggleにハマった原体験は、「リーダーボードを駆け上がる楽しさ」でした。
スコアが上がって順位が動く、あの瞬間の感覚は、座学やLTを聞くだけでは味わえません。
初学者にもこの体験をしてほしい——そう考えたとき、
一番ストレートな手段は「コンペに参加すること」でした。
では、既存のKaggleコンペにみんなで参加すればよいのでは？と思うかもしれません。
しかし、実際のKaggleコンペにはいくつかのハードルがあります。
まず、難易度のコントロールができません。
実際のコンペは世界中のKagglerが本気で取り組む場であり、
問題設定やデータの前処理だけでも高度な知識が求められます。
初めてKaggleに触れる人がいきなり飛び込んでも、
何から手をつければよいか分からず、挫折してしまう可能性が高いです。
また、運営側から参加者へのサポートにも制約があります。
通常のKaggleコンペでは、参加者間で解法を共有するプライベートシェアリングが禁止されています。
つまり、会場で「ここをこう変えるとスコアが上がりますよ」とヒントを出したり、
詰まっている参加者に具体的なアドバイスをしたりすること自体が、ルール上難しくなります。
初心者向けイベントにおいて、サポートができないのは致命的です。
一方、Kaggleのコミュニティコンペ機能を使えば、
オリジナルの問題設定・データ・評価指標を自由に設計でき、
初心者でも楽しめる難易度に調整できます。
会場でのサポートやヒント出しも自由にできます。
こうした理由から、第1回イベントの形式としてオリジナルのコミュニティコンペを選びました。
なぜプロンプトエンジニアリング型コンペにしたか
今回、Pythonでモデルを学習するコンペではなく、プロンプトエンジニアリング型のコンペにした理由は大きく2つあります。
1つ目は、Pythonの知識がなくても参加できることです。参加者が触るのはプロンプト、つまり文字列だけです。プログラミング未経験者でも、ラベル定義を詳しくする、具体例を追加する、モデルに役割を与える、といった工夫に取り組めます。
2つ目は、実務に直結する学びが得られることです。普段、プロンプトエンジニアリングを体系的には学ばずに感覚でプロンプトを書いている人は少なくありません。また、プロンプトエンジニアリングを学んでも、それがどれくらい効果的なのかを実感しづらい面もあります。
そうした人にとって、「プロンプトの書き方を少し変えるだけでスコアがこれだけ変わる」ということを、リーダーボード上の数値として定量的に体感できる点は非常に有益です。
データセット
今回のコンペのデータセットは、GPTのAPIを使って社内投稿の例文を生成する形で作成しました。
データ生成コードでは、全体で440件の投稿を作成し、各ラベルが均等になるように設計しました。
生成の流れは、ざっくり次のようにしました。
- ラベル定義、生成ルール、業務シーンをデータ生成用プロンプトにまとめる
-
gpt-4o-2024-08-06に、指定スキーマに沿った社内投稿例を生成させる - 生成結果に対して、重複、長すぎる文、個人情報らしき文字列、ラベル名を本文に含む文などをフィルタする
-
POLITE/NEUTRAL/CASUAL/TONE_RISK/RUDEが同数になるように抽出する - 各ラベル8件ずつをラベル付きサンプル、残りをKaggleのテストデータに分割する
- Kaggle用に
test.csv、sample_submission.csv、solution.csvを出力する
生成プロンプトには、例えば「丁寧語だが圧がある投稿」「内容は厳しいがトーンは普通の投稿」「カジュアルだが失礼ではない投稿」「明確に攻撃的な投稿」など、分類境界が出やすいケースも指定しています。単にLLMで文を大量生成するのではなく、TONE_RISK と RUDE、POLITE と NEUTRAL のような境界を考える教材になるようにしました。
-
sample_data.csv: ラベル付きサンプル40件 -
test.csv: Kaggle公開用の予測対象400件 -
sample_submission.csv: 提出形式サンプル -
solution.csv: Kaggle管理用の正解ラベル
sample_data.csv は各ラベル8件ずつ、test.csv は各ラベル80件ずつです。評価指標は Accuracy です。
sample_data.csv には、例えば次のようなデータが入っています。
| id | post | label |
|---|---|---|
tone_000397 |
その修正案、かなりいいと思います。 | CASUAL |
tone_000018 |
問い合わせ内容は確認できています。 | NEUTRAL |
tone_000120 |
資料の内容、少し雑に見えます。 | TONE_RISK |
tone_000060 |
明日までの確認になりますので、お手すきの際にご対応いただけますと幸いです。 | POLITE |
tone_000070 |
いつまで待たせるんですか。いいかげんにしてください。 | RUDE |
test.csv は id と post のみを持つ形式です。
id,post
tone_000234,まだ確認できていないなら、今すぐ見てください。
tone_000310,この資料めっちゃ分かりやすいです！
tone_000041,このまとめ、見やすくて助かる！
提出ファイルは、id,label の2列です。ベースラインの sample_submission.csv では、まず全件 NEUTRAL が入る形にしています。
id,label
tone_000234,NEUTRAL
tone_000310,NEUTRAL
tone_000041,NEUTRAL
使用モデル
推論には、Kaggle Notebook上で Google Gemma 2 2B JPN IT を使用しました。
ベースラインNotebookでは、Kaggle Input に追加された google/gemma-2-2b-jpn-it を読み込み、GPU T4 x2 で動かす想定にしています。
Gemma 2 2B JPN ITを選んだ理由は、モデルサイズと性能のバランスがちょうどよかったためです。
2Bモデルなので重すぎず、Kaggleの無料GPU環境でも現実的な時間で推論できます。一方で、日本語の社内投稿トーン分類をある程度こなせる性能もあります。
これより重いモデルを使うと性能は上がりますが、推論に時間がかかり、2時間程度のイベントでは試行回数を十分に確保しにくくなります。逆に、これより性能の低いモデルでは、そもそも分類性能が出ず、プロンプトを工夫してもスコア改善を体感しにくくなります。
ベースラインプロンプト
ベースラインNotebookでは、最上部に次の BASE_PROMPT を置きました。
BASE_PROMPT = """<start_of_turn>user
社内投稿のトーンを分類してください。
POLITE: 丁寧で配慮がある。
NEUTRAL: 事務的で淡々としている。
CASUAL: くだけているが失礼ではない。
TONE_RISK: 圧、嫌味、冷たさ、責める印象がある。
RUDE: 明確に攻撃的、非難的、侮辱的。
投稿:
{post}
答えは POLITE, NEUTRAL, CASUAL, TONE_RISK, RUDE のいずれか1つだけで出力してください。
<end_of_turn>
<start_of_turn>model
"""
このシンプルなゼロショットプロンプトを、参加者に配布するベースラインとして使いました。
Notebook側では、BASE_PROMPT.format(post=post) で各投稿を埋め込み、生成結果から POLITE / NEUTRAL / CASUAL / TONE_RISK / RUDE のいずれかを取り出して submission.csv を作成します。
参加者には「この BASE_PROMPT の三重引用符 """...""" の中だけ編集してください」と案内しました。
5. 工夫・ノウハウ
ここからは、今回のイベントで特に効いた設計・運営上の工夫をまとめます。
【コンペ内容に関する工夫】
① Pythonの知識を不要にした
今回のコンペでは、参加者がPythonコードを書く必要がないようにしました。
Notebookの最上部にある BASE_PROMPT の文字列、つまりトリプルクォート """...""" の中身だけを書き換えれば、あとはNotebookが自動で推論し、submission.csv を作成します。
実際のNotebookでも、編集してよい場所が分かるように、プロンプト定義セルの直前に次のようなコメントを置きました。
# ============================================================
# ⚠️ ここだけを編集してください: BASE_PROMPT の中身を工夫します
# 下の LABELS や以降のセルは、そのまま実行すればOKです
# ============================================================
BASE_PROMPT = """<start_of_turn>user
社内投稿のトーンを分類してください。
POLITE: 丁寧で配慮がある。
NEUTRAL: 事務的で淡々としている。
CASUAL: くだけているが失礼ではない。
TONE_RISK: 圧、嫌味、冷たさ、責める印象がある。
RUDE: 明確に攻撃的、非難的、侮辱的。
投稿:
{post}
答えは POLITE, NEUTRAL, CASUAL, TONE_RISK, RUDE のいずれか1つだけで出力してください。
<end_of_turn>
<start_of_turn>model
"""
また、今回のコンペでは「プロンプトエンジニアリング力を競う」ことを明確にするため、プロンプト以外の工夫は禁止しました。
例えば、次のような変更はNGです。
- 後処理ロジックを追加して、モデル出力を書き換える
-
max_new_tokensやdo_sampleなどの推論パラメータを変更する -
parse_label()の判定ルールを変更する - モデルやデータ読み込み部分を変更する
② ベースラインノートブックの工夫
ベースラインNotebookでは、まずベースラインのプロンプトをあえて極めてシンプルにしました。
これは、参加者に「自分でプロンプトを改善してスコアを上げる」という成功体験を積んでもらうことが非常に重要だったためです。
最初から強いベースラインを配ってしまうと、初心者が少し工夫してもスコアがほとんど動かず、「何を変えればよいのか分からない」という状態になりがちです。そこで、ベースラインには意図的に 改善余地 を残しました。
そのうえで、プロンプト定義セルをNotebookの一番上に配置しました。
参加者が試行錯誤するたびにNotebookの下の方までスクロールする必要があると、それだけで体験が悪くなります。そこで、「触る場所」を最上部に固定しました。
さらに、ベースラインプロンプトのすぐ下に、改善例をMarkdownで具体的に載せました。
例えば、ロールプロンプティングの改善例としては、次のような文を先頭に追加する案を示しました。
あなたは日本語の職場コミュニケーションに精通した、
社内メッセージのトーン分析の専門家です。
Few-shotの例としては、各ラベルの代表例をプロンプト内に入れる形を提示しました。
投稿: 明日までの確認になりますので、お手すきの際にご対応いただけますと幸いです。
ラベル: POLITE
投稿: 先方から返信待ちです。進展があれば共有します。
ラベル: NEUTRAL
投稿: その修正案、かなりいいと思います。
ラベル: CASUAL
投稿: このままだと困るので、今日中に対応してください。
ラベル: TONE_RISK
投稿: いつまで待たせるんですか。いいかげんにしてください。
ラベル: RUDE
事前の説明でも、ロールプロンプティングとFew-shotプロンプティングを簡単に紹介しました。抽象的に「プロンプトを工夫してください」と言うよりも、「こう書けばよい」という具体例を示すことで、初心者は圧倒的に動き出しやすくなります。
③ チームマージは序盤禁止
Kaggleではチームマージができますが、序盤はあえて禁止しました。
理由は、全員に「自分でプロンプトを改善して、スコアが上がる」体験をしてもらいたかったからです。
例えば、ベースラインスコアが0.25の状態で序盤にチームを組んだとします。その後、チームメイトが0.50を出し、自分が0.40を出した場合、自分自身は0.25から0.40へ大きく改善しています。
しかし、チームとしては0.50の提出が採用されるため、自分の0.40の提出ではリーダーボード上の順位が動きません。
リーダーボードの順位が自分の工夫によって上がっていく体験こそが、Kaggleの楽しさの核心です。その体験を全員に味わってもらうため、序盤は個人で取り組む時間にし、まず自分のプロンプト改善で順位が動く感覚を得てもらいました。
その後、ある程度個人で試行錯誤したタイミングで、知見共有やチームマージを解禁する流れにしました。
ただこの点に関しては、チームマージを最初からした方がワイワイ楽しめるし参加者同士の交流も生まれやすいという面もあるので、イベントの目的や参加者の属性に応じて、どちらの形式がよいか検討するとよいと思います。
【事前準備の工夫】
④ 事前準備の徹底周知
Kaggle初心者向けに、事前メールや会場案内で次の2点を繰り返し周知しました。
- 電話番号認証を済ませること
- Google Gemmaの利用規約に同意しておくこと
Kaggle NotebookでGPUを使うには、電話番号認証が必要です。また、GemmaのようなモデルをKaggle上で利用する場合、モデル利用規約への同意が必要になります。
ここを当日初めて案内すると、GPUが使えない、モデルが読み込めない、といったトラブルでハンズオンの時間が大きく削られます。
当日も、会場に早めに到着した参加者には、開始前の待ち時間を使ってKaggleの電話番号認証とGemmaの利用規約同意が済んでいるかを確認してもらいました。事前メールを読んでいても、実際にNotebookを開くまで気づきにくいポイントなので、開始前に繰り返し案内しておくと安心です。
今回は事前周知と当日開始前の案内を徹底したことで、当日のGPU未使用・利用規約エラーはほぼゼロに抑えられました。
【コンペ当日の進行の工夫】
⑤ サブミット方法の簡略化
Kaggle Notebookでは、Save & Run All してから結果ファイルをSubmitする方法もあります。
ただ、初心者向けイベントでは、操作手順が増えるほど迷いどころも増えます。
今回は、Notebook右側のSubmitボタンから一括実行・提出する方法だけを案内しました。参加者に見せる導線を1つに絞ったことで、質問対応もかなり楽になりました。
⑥ 説明は必要最小限に絞る
当日は、あえて細かい説明を削りました。
例えば、次のような内容は最初の説明では扱っていません。
- サブミット履歴の確認方法
- 生成されたCSVの確認方法
- GPU同時実行数の上限
- Notebookのバージョン管理
もちろん、どれもKaggleを深く使ううえでは大事な知識ですが、最初から全部説明しようとすると、情報過多で参加者が混乱してしまいます。
今回は、まずSubmitまで行って楽しんでもらうことを優先し、細かい質問には都度対応する形にしました。
⑦ 複数サポーターによる巡回サポート
運営メンバーには、会場内を自由に回りながら参加者をサポートしてもらいました。
Kaggle Notebookの画面、GPU設定、モデル追加、Submitボタンなど、初心者が詰まりやすいポイントはある程度決まっています。質問が出たらすぐに近くのサポーターが対応できるようにしたことで、全体進行を止めずに済みました。
⑧ 参加者に楽しんでもらうことを最優先にした
当日は、とにかく参加者全員に楽しんでもらうことを最優先にしました。
そのため、参加者同士の雑談や相談はOKにしました。黙々と個人で競うだけではなく、近くの人と「どう書いたらスコアが上がったか」「このラベルの違いが難しい」と話しながら進められる雰囲気を大事にしました。
また、コンペサポートメンバーには、困っている参加者がいたらヒントやプロンプト改善の案を積極的に伝えてよい、という方針を事前に共有しておきました。
通常のKaggleコンペでは、参加者間で解法や提出内容を共有するプライベートシェアリングは禁止されています。ただ今回は、参加者にKaggleやプロンプト改善の楽しさを体験してもらうことを目的にしたオリジナルコンペです。そのため、厳密な競技性よりも、全員が楽しみながら1サブミットを出し、スコア改善を体験できることを優先しました。
⑨ プライベートリーダーボードの発表演出
コンペ終了後は、プライベートリーダーボードを下から順にスクロールで映しながら、上位者の名前とスコアを発表していきました。
順位が少しずつ明らかになっていく形式にしたことで、最後まで会場全体で盛り上がる時間になりました。
また、上位3名には、自分のプロンプトや工夫したポイントをその場で発表してもらいました。これにより、単なる順位発表で終わらず、参加者全体で知見を持ち帰れる時間になりました。
⑩ Discussionへの投稿を促す
コンペ終了後、参加者全員にKaggle Discussionへ「自分の順位とプロンプト」を投稿してもらいました。
これは、以下の2つの意味で重要だと考えています。
- 上長への報告資料として活用できる
- コミュニティの知見として残る
イベント中に生まれたプロンプトは、その場で消えてしまうともったいないです。Discussionに残すことで、後から参加者同士で見返したり、次回イベントの教材として再利用したりできます。
【イベント全体の運営の工夫】
⑪ 懇親会は立食形式
懇親会は、着席固定ではなく立食形式にしました。
グループ会社横断イベントでは、普段話す機会のない人と交流できること自体に大きな価値があります。席を固定しないことで、Kaggle経験者、初心者、別会社の参加者が自然に混ざりやすくなりました。
⑫ 名札の色でKaggleランクを識別
名札には5色のシールを貼り、Kaggleランクが分かるようにしました。
これにより、
- 「Kaggle始めたばかりなんです」
- 「Competitionsをよくやっています」
- 「どのコンペに出ていますか？」
といった会話が生まれやすくなりました。
6. 当日のトラブルと対応
Kaggle「Too Many Requests」エラー
当日、会場Wi-Fiから約80名が一斉に自分のKaggleプロフィールページ経由でコンペにJoinしようとしたところ、Too Many Requests エラーが発生しました。Kaggle側にボット的なアクセスと判定されたのかもしれません。
原因ははっきりとは分かっていませんが、自分のプロフィールページを経由してコンペページへ移動する導線だったことも影響した可能性があります。コンペページのURLへ直接アクセスできる導線であれば問題が起きなかった可能性もありますが、この点は未検証です。
対処として、テザリング可能な参加者にはスマートフォンのテザリングへ切り替えてもらいました。これにより、Joinできない問題は解消しました。
7. 次回に向けた改善点
テストデータの件数
今回の改善点としては、テストデータ400件は少し多かったかもしれません。
ベースラインのような短いプロンプトであれば問題になりにくいのですが、参加者がFew-shot例を増やしたり、ラベル定義をかなり丁寧に書いたりすると、1件あたりの推論時間が伸びます。その結果、プロンプトが長くなった場合には、1回のSubmitに20分ほどかかるケースもあったようです。
2時間のイベントでは、1回のSubmitに時間がかかると試行回数が減ってしまいます。プロンプトを変えて、Submitして、スコアを見て、また改善する、というサイクルを何度も回してもらうには、テストデータはもう少し少なくしてもよかったと感じました。
使用モデルの選定
また、計算時間の観点では、使用モデルの選定ももう少し検証の余地がありました。
今回は Gemma 2 2B JPN IT を使いましたが、今後同様のイベントを開催するなら、Gemma 2より新しく、かつより軽量なモデルも候補に入れて比較した方がよさそうです。例えば、1Bクラスのモデルでも Gemma 2 2B JPN IT と同程度に日本語の分類ができ、推論時間を短縮できるのであれば、参加者の試行回数を増やせる可能性があります。
一方で、モデルが強すぎると、素朴なプロンプトでも簡単に解けてしまい、プロンプト改善の面白さが薄れます。逆に弱すぎると、どれだけプロンプトを工夫してもまともに分類できず、改善の手応えが得られません。
プロンプトエンジニアリング型コンペでは、モデル性能は高ければ高いほどよいわけではなく、「工夫すればちゃんと伸びるが、工夫しないと伸びきらない」くらいの難易度に調整することが重要だと思います。このあたりは、次回開催時には複数モデルで事前に推論時間とベースラインスコアを比較して、よりよい塩梅を探したいです。
アンケート設計
アンケート設計にも改善の余地がありました。
参加後アンケートでは、「次回開催してほしい内容」について、いくつか候補を用意して選択式で回答してもらいました。ただ、こちらで用意した候補だけだと、参加者が本当にやってみたいテーマや、運営側が想定していなかったニーズを拾いきれない可能性があります。
次回は、選択式の設問に加えて、「次回やってほしいこと」を自由記述で書ける欄も用意したいです。そうすることで、参加者の温度感や具体的な期待をより拾いやすくなり、次回イベントの企画に活かしやすくなると感じました。
8. 参加者の声・アンケート結果
イベント後には、参加者向けにアンケートを実施しました。
アンケートには93名の方に回答いただきました。
結果として、イベント満足度は 4.73 / 5 でした。
また、「Kaggleの楽しさを感じられましたか？」という設問に対しても 4.71 / 5 という結果でした。
初心者も含めたイベントとして、Kaggleの楽しさを一定程度体験してもらえたのはよかった点だと思います。
自由記述でも、次のようなコメントをいただきました。
- 学生時代からKaggleを触ろうと思っていたのですが、結局触らずに社会人生活を送っていたので、このような機会をいただけて誠に感謝しています。生成AIのおかげで参入障壁は低くなったと思いますが、とはいえ初心者がいきなり始めるのは難しいと思うので、このような場は非常に助かると思います。次回もぜひ参加させていただきたいです。
- ミニコンペの難易度がちょうどよく、誰でも参加できる点が良いと思いました。
- ミニコンペのテーマがとっかかりやすく、スコア向上させるための試行錯誤を楽しみながら取り組むことができました。ありがとうございました。
- 実践でコンペができるのは、ただ座学よりも身につきやすいと感じました。
- Kaggleに取り組もうとするハードルが下がりました。
- 以前は挫折したが、今後はKaggleに参加したいと思えました。
- 流行りの生成AIを用いたものかつ初心者も参加しやすい内容でとても良かったと思います。大変楽しませてもらいました。ありがとうございました。
- Kaggleの一つのハードルとして、1サブ出すことにあると思います。KaggleのWebページはなかなか癖があるので、その中で1サブするまでの一通りの体験ができるのは非常に良いハンズオンだったと思います。また簡易的にスコアが上がる経験もできるので、Kaggleの一番楽しいところが味わえたと思います。
9. まとめ
今回のイベントでは、約2時間という制約の中で、コンペ参加、Notebook実行、初回Submit、プロンプト改善、リーダーボード発表までを一通り実施しました。
当日の進行をスムーズにするためには、事前準備の周知や、当日のサポート体制の設計が非常に重要でした。特に、Kaggle初心者が詰まりやすいポイントを事前に想定し、そこを重点的にサポートする体制を作ることが重要です。
また、幅広い参加者にKaggleの楽しさを体験してもらうためには、コンペ内容の設計も非常に重要です。今回うまくいったポイントとしては主に以下の2点が挙げられます。
- Pythonの知識がなくても参加できるプロンプトエンジニアリング型コンペにしたこと
- ベースラインプロンプトをあえてシンプルにして、初心者が工夫してスコアが上がる体験を得られるようにしたこと
Kaggle初心者向けの社内イベントや、生成AI活用の入口として、かなり相性がよい題材だと感じました。
今後も、今回のイベントの内容や運営の工夫をブラッシュアップしながら、グループ全体のデータ活用力・AI活用力を底上げする活動を続けていきたいと思います！