Kaggle Benchmarksローカル作成の確認点：AI評価タスクをCLI、SDK、エージェントで作る前に

3行まとめ

このテーマをもう少し広げて見るなら、Gemini 3.5 Flashの導入判断：Vertex AIで見るモデルID・価格・移行前チェック と GKE Inference Gatewayのprefix caching：LLM推論を速くする前に確認するルーティング条件 も合わせて確認してください。評価タスクを作った後、どのGeminiモデルで検証するかをVertex AI側の条件から確認できる

作る場所が増える

Kaggle Notebookだけでなく、ローカル開発環境やAI coding agentを交えた評価タスク作成に近づきます。

準備は読者側で持つ

Kaggleアカウント、CLI、Model Proxy認証、SDK、作業ディレクトリを先にそろえます。

安全性は別に確認する

評価設計、秘密情報、公開範囲、再現性の記録は、ローカル対応だけでは自動で解決しません。

便利になったのは作業導線であり、公開判断やデータ管理まで自動で安全になるわけではありません。

• Googleは2026年6月4日、Kaggle Benchmarksの評価タスクをKaggle Notebookだけでなく、Antigravity、VSCode、Cursor、AI coding agentsなどのローカル開発環境から扱える更新を発表しました。
• 開発者や導入企業が最初に見るべきなのは、Kaggleアカウント、Kaggle CLI、Model Proxy認証、kaggle-benchmarks SDK、タスクとleaderboardの関係、公開範囲、データ取り扱いです。
• ローカル対応で作成から実行確認までの往復は短くなりますが、評価設計、秘密情報の扱い、公開前レビュー、再現性の記録まで自動で安全になるわけではありません。

Kaggle Benchmarksは、AIモデルを「自分たちの用途に近いタスク」で比べたい人に向いた仕組みです。今回の更新で重要なのは、評価タスクをKaggle上のNotebookだけで作る流れから、普段の開発環境やAI coding agentも交えた流れへ移りやすくなったことです。

Alphabet Watch Japanでは、この発表を単なる開発者向けニュースではなく、Geminiや他社モデルを業務タスク、プロダクト機能、社内検証で比較したい読者向けの確認表として扱います。公式発表は2026年6月4日のGoogle Blogで確認し、2026年6月7日18:00 Asia/Tokyo時点で、Kaggle公式GitHub、Quick Start、Cookbook、Kaggle CLI docs、write-kaggle-benchmarks skillも確認しました。専門メディアやコミュニティでの共有は需要シグナルとして見ますが、仕様説明の根拠には使いません。

Kaggle Benchmarksのローカル作成で何が変わったのか

Kaggle Notebook中心

WebベースのNotebook editorでタスクを作り、実行結果を確認する前提が強い流れです。

ローカルIDEとCLI

VSCode、Cursorなどの環境から、作成、検証、push、run、downloadを扱いやすくなります。

AI coding agent

タスク作成や確認作業をエージェントに任せやすくなりますが、評価基準は人間が固定します。

短くなるのは作業の往復です。評価設計、権限、公開範囲、再現性の確認は別に残ります。

今回の発表でまず押さえたいのは、「AIモデル評価を作る場所」が増えたことです。Googleの発表では、開発者がAntigravity、VSCode、Cursor、coding agentsなどのローカル開発環境から、評価タスクの作成、検証、push、run、downloadを扱えるようになったと説明されています。

これは、Kaggle BenchmarksがNotebook中心の実験から、開発ワークフローの中で扱いやすい評価基盤へ近づいたという意味です。コードレビュー、社内リポジトリ、AI coding agent、検証ログ、結果ファイルの保管といった日常の流れに、AI評価タスクを組み込みやすくなります。

Kaggle Notebookだけでなくローカル開発環境から扱える

根拠

これまで評価タスクを作るには、KaggleのWebベースのNotebook editorで作業する前提が強くありました。今回の更新では、ローカルの開発環境からBenchmarksを扱う導線が追加され、普段のIDEやエージェントの作業範囲でタスクを組み立てやすくなっています。

注意点

ただし、ローカルで作れるようになったことは、Kaggle側の認証や公開判断が不要になるという意味ではありません。ローカルに移るほど、.env、APIキー、作業ディレクトリ、生成ファイル、社内データの混入に自分たちで気づく必要があります。

Community Benchmarksの背景を先に押さえる

根拠

Kaggle Benchmarksの背景には、2026年1月に発表されたCommunity Benchmarksがあります。Googleは、AIモデルの性能を固定的な一つのスコアだけで見るのではなく、ユーザーや組織が実際に気にするユースケースに沿って評価する必要性を説明しています。

見方

Community Benchmarksでは、タスクを作り、そのタスクをBenchmarkにまとめ、複数モデルの結果をleaderboardで比較する流れが示されています。つまり今回のローカル対応は、まったく別の新製品というより、Community Benchmarksを開発者の作業場所に近づける更新と見るのが自然です。

短くなる工程と、短くならない工程を分ける

短くなる工程

短くなるのは、評価タスクを作り、ローカルで試し、Kaggleへpushし、runし、結果をdownloadする往復です。開発者がIDEから離れずに試行錯誤できるため、タスクの修正サイクルは明らかに回しやすくなります。

残る工程

一方で、短くならない工程もあります。何を評価するのか、採点基準は妥当か、公開してよいデータか、外部モデルに送ってよい内容か、leaderboardに出す意味があるか、結果をあとから監査できるか。ここは、ツールが便利になっても人間側の設計とレビューが残ります。

開発者向けのローカル実行という意味では、既存記事の<a href="https://googl-watch.blog.mo-gmo.com/googl-26-google-colab-cli-agent-gpu/">Google Colab CLIの提供条件</a>とも近い文脈です。Colab CLIが計算環境への導線を短くするのに対し、Kaggle Benchmarksのローカル対応は、評価タスクの作成と実行確認の導線を短くします。

始める前にそろえる環境と認証

項目	内容	見方
Kaggleアカウント		誰のアカウントで評価結果を持ち、公開タスクを管理するのかを決めます。
Kaggle CLI		Benchmarks系のCLI操作に入る前に、利用環境と権限を確認します。
Model Proxy認証		tokenやcredentialsの保管先、共有範囲、更新時の扱いを決めます。
kaggle-benchmarks SDK		ローカルでタスクを書くための依存関係として、バージョンと更新履歴を追えるようにします。
.env		秘密情報をGit管理に入れない前提で、環境変数の置き場所を整理します。
作業ディレクトリ		task file、run結果、download結果をどこに残すかを先に決めます。

チーム利用では、退職や権限変更時の引き継ぎまで含めて確認すると後戻りを減らせます。

Kaggle Benchmarksをローカルで試す前に、まず環境と認証を分けて確認します。公式ドキュメント上、Kaggle Notebookで始める場合は依存関係が用意される流れがありますが、ローカル開発ではKaggle CLI、Model Proxy credentials、環境変数、SDKを読者側で管理します。

KaggleアカウントとCLIを先に確認する

条件

Kaggle Benchmarksを扱う前提として、KaggleアカウントとKaggle CLIが必要になります。記事の主眼はアカウント作成手順ではなく、Benchmarks系のCLI操作に入る前に、誰のアカウントで、どの作業ディレクトリで、どの認証情報を使うかを決めることです。

チーム利用の注意点

個人検証なら自分のKaggleアカウントでも始められますが、企業やチームで使う場合は話が変わります。評価結果を誰が所有するのか、公開タスクの管理者は誰か、退職や権限変更時にどう引き継ぐのかを決めないまま進めると、後で結果や公開範囲を管理しにくくなります。

Model Proxyの認証情報をチームで扱えるか

根拠

Kaggle CLI docsでは、BenchmarksはKaggle Model Proxyを通じてLLMモデルに対して評価タスクを実行し、結果をdownloadできる仕組みとして説明されています。CLIの上位コマンドはkaggle benchmarksで、aliasとしてkaggle bも示されています。

特に見るべきなのは、authとinitです。docsでは、authはModel Proxy tokenを取得し、credential environment variablesをファイルに保存するコマンドとして説明されています。initは、Model Proxy credentialsとローカル開発に使うdefault environment variablesを取得し、starter example task fileやsyntax reference documentも生成する流れです。

確認項目

確認したい環境変数は、少なくとも次のようなものです。

• MODEL_PROXY_URL
• MODEL_PROXY_API_KEY
• MODEL_PROXY_EXPIRY_TIME
• LLM_DEFAULT
• LLMS_AVAILABLE

注意点

ここで大事なのは、.envを「便利な設定ファイル」としてだけ見ないことです。認証情報が入る可能性がある以上、Git管理への混入、AI agentへの不要な読み取り、社内共有チャットへの貼り付け、スクリーンショットへの映り込みを避けます。

kaggle-benchmarks SDKと作業ファイルの置き場所を決める

根拠

公式GitHubとQuick Startでは、kaggle-benchmarks SDKを使ってタスクを定義する流れが説明されています。タスクはPythonコードとして書き、llmを受け取る関数、評価用の引数、戻り値、assertion、scoreなどを通じてモデルの出力を評価します。

確認項目

ローカルで始めるなら、最初に次を決めておくと事故が減ります。

• タスク定義のPythonファイルをどこに置くか
• 評価データをどこに置くか
• run結果やdownload結果をどこに保存するか
• AI coding agentに読ませてよいファイルと読ませないファイルをどう分けるか
• pushやpublishを実行できる担当者を誰にするか

注意点

SDKやCLIの表記、対応モデル、オプションは変わり得ます。本文では2026年6月7日時点の公式情報に基づいていますが、実際に使う直前にはKaggle CLI docsとGitHubの最新状態を確認してください。

タスク、ベンチマーク、leaderboardの関係を取り違えない

1. 1task file

   モデルに解かせる問題、期待する出力、採点の単位を定義します。

2. 2run files

   特定のモデルや条件で実行した結果が、比較の材料になります。

3. 3benchmark entity

   複数のタスクやrun結果をまとめ、比較対象として扱う枠になります。

4. 4leaderboard

   比較結果を読者やチームが見る場所です。表示条件や制約を設計に入れます。

5. 5backing notebook

   公開や管理の前提に関わるため、publish前に扱いを分けて確認します。

leaderboardを見せる前提にするほど、採点基準、公開範囲、説明可能性の確認が重要になります。

Kaggle Benchmarksを初めて見る読者がつまずきやすいのは、「タスクを書くこと」と「leaderboardで比較すること」を同じものとして見てしまう点です。公式情報では、task、run、benchmark entity、leaderboard、backing notebookが別の役割を持ちます。

task fileとrun filesがleaderboardの材料になる

根拠

kaggle-benchmarksの説明では、Kaggle Notebook上でbenchmark taskを実行すると、task fileとrun filesが出力され、それらがbenchmark entityやleaderboard表示に使われる流れが示されています。

役割

タスクは、モデルに解かせる問題と採点の単位です。run fileは、特定のモデルや条件で実行した結果の材料です。benchmarkは、複数のタスクやrun結果をまとめて比較する枠です。leaderboardは、その比較結果を読者が見る場所です。

レビュー項目

この関係を分けると、何をレビューすべきかも見えてきます。タスクを書く段階では、問題文、入力データ、採点基準、assertion、期待する出力形式を見ます。runの段階では、モデル指定、実行状態、ログ、失敗時の扱いを見ます。leaderboardに載せる段階では、比較する意味、公開範囲、結果の説明責任を見ます。

leaderboardの制約を評価設計に入れる

条件

Quick StartやCookbookには、pass/fail、数値スコア、structured output、dataset評価、複数モデル比較など、複数の評価パターンが示されています。ただし、タスク内でさまざまな中間結果を扱えることと、leaderboardでどの単位を見せるかは別です。

評価基準

チームで使うなら、最初からleaderboardに出す指標を一つに決めるより、まずは「なぜその評価が必要か」を言語化します。たとえば、問い合わせ分類の正確さを見るのか、社内ルールへの準拠を見るのか、画像や表を含む入力に対応できるかを見るのかで、向く採点方式は変わります。

publishは公開範囲とbacking notebookを分けて見る

根拠

Kaggle CLI docsとwrite-kaggle-benchmarks skillでは、publishが公開に関わる操作として説明されています。特に注意したいのは、taskだけでなくbacking notebookの公開にも関係する点です。docsやskillでは、backing notebookを公開しないためのオプション確認も示されています。

注意点

ここは、企業やチームにとってもっとも慎重に扱う場所です。タスク定義に社内プロンプト、顧客データ、未公開仕様、APIキー、内部評価基準が入っていないか。Notebookに不要なセルやログが残っていないか。公開後に誰が説明責任を持つのか。publishは便利な最後の一手ではなく、公開レビューの対象として扱うべきです。

CLI、SDK、エージェントで作るときの作業順

1. 1init / auth

   ローカル開発用の初期化、またはModel Proxy認証を先に整えます。

2. 2write

   task fileに、入力、期待出力、採点方式を明確に書きます。

3. 3local validate

   push前に、小さな入力で形式、採点、秘密情報の混入を確認します。

4. 4push

   検証済みのタスクをKaggle側へ送る工程として扱います。

5. 5run

   対象モデルや条件を固定して、評価タスクを実行します。

6. 6status / log

   実行状態とログを確認し、失敗時の原因を追えるようにします。

7. 7download

   結果ファイルを回収し、再現性のために保存先と版を残します。

8. 8publish（必要な場合）

   公開範囲とbacking notebookの扱いを確認してから判断します。

AI coding agentに任せる場合も、公開や認証を含む広い権限を渡す前に作業範囲を絞ります。

この章では、完全なチュートリアルではなく作業の順番を確認します。実際のコマンドやオプションは、Kaggle CLI docsの最新表記で見直してください。

最初にinitかauthでローカル環境を整える

根拠

ローカルでBenchmarksを扱う最初の分岐は、認証だけを整えるのか、ローカル開発用の環境一式を初期化するのかです。CLI docs上、kaggle benchmarks authはModel Proxy tokenを取得し、認証情報をファイルに保存するコマンドとして説明されています。kaggle benchmarks initは、認証情報に加えて、ローカル開発向けのdefault environment variablesやstarter example task fileを用意する流れです。

運用上の注意

aliasを使う場合は、kaggle b auth、kaggle b initのように短く書けます。ただし、社内ドキュメントではaliasだけを書くより、正式名も一緒に残すほうが引き継ぎやすくなります。

push前にローカル検証を入れる

確認項目

ローカル対応で助かるのは、タスクを書いてすぐpushするのではなく、手元で先に動きを見やすくなることです。タスクのPythonファイルを直接動かし、期待するrun fileが生成されるか、assertionが狙いどおり失敗するか、structured outputの形が崩れないかを見ます。

失敗時の見方

ここで確認したいのは、成功ケースだけではありません。むしろ、失敗したときに採点がどう落ちるか、曖昧な回答に対してjudge LLMが過剰に甘くならないか、空の入力や想定外の形式で落ち方が説明できるかを見たほうが実運用に近づきます。

run、status、log、downloadを別工程として説明する

根拠

CLI docsでは、taskをrunし、statusやlogを確認し、結果をdownloadする流れが示されています。ここを一つの「実行しました」で済ませると、後から結果を比較できなくなります。

記録項目

社内で再現性を残すなら、次の情報をセットで残します。

• 実行日と確認日
• task名またはslug
• 使用したモデル
• CLI docs確認日
• runの状態
• log確認の有無
• downloadした結果ファイルの保存先
• 失敗runを比較対象に含めるかどうか

注意点

モデルの一覧やslugは変わる可能性があるため、Kaggle CLI docsのtasks models系の説明や実際のCLI出力で確認します。記事や社内メモに古いモデル名だけを固定して残すと、後で再実行できなくなることがあります。

AI coding agentに任せるときは指示を狭くする

根拠

Googleの発表では、AI coding agentsを使ってKaggle Benchmarksのタスクを書く流れにも触れられています。write-kaggle-benchmarks skillは、SDKとCLIを使ってtaskを作成、push、run、publish、管理するための構造化された指示として公開されています。

指示項目

ただし、AI coding agentに「いい感じのベンチマークを作って」と渡すのは危険です。少なくとも次を明示します。

• 評価したい能力
• 入力データの範囲
• 期待する採点方式
• 使ってよいモデル
• 使ってはいけないファイル
• 公開してよいか
• ローカル検証で満たす条件
• download結果の保存先
• publishを実行してよいか

注意点

AI agentは作業の速度を上げますが、公開可否やデータ権限を代わりに判断してくれる存在ではありません。とくに.env、顧客データ、未公開プロンプト、社内仕様書を作業ディレクトリに置く場合は、agentに読ませる前に境界を切っておく必要があります。

評価設計で先に決めること

項目	内容	見方
pass/fail		正誤が明確な計算、指定条件、禁止語チェックなどに向きます。
数値スコア		段階評価にしたい場合に使います。スコアの意味を人間が説明できる形にします。
judge LLM		自由記述や要約品質の評価に使えますが、採点プロンプトやjudge側モデルに影響されます。
structured output		JSONなど決まった形式で返せるかを見る場合に役立ちます。
dataset評価		複数入力で同じ品質が出るかを見るため、件数と集計方法を先に決めます。
複数モデル比較		モデル間の差を見る場合は、同じタスク、同じデータ、同じ条件で比べます。

自然文の良し悪しや業務適合性は単純な勝敗にしにくいため、採点基準の説明可能性を優先します。

Kaggle Benchmarksを使う価値は、単に「モデルを走らせる」ことではありません。自分たちの判断に使える評価タスクを作れるかどうかです。ここでは、採点方式、入力データ、出力形式、再現性の4つを先に決めます。

採点方式を先に固定する

評価基準

正誤が明確な問題ならpass/failが向きます。たとえば、ある計算が正しいか、指定条件を満たすJSONを返せるか、禁止語を含まないかといった評価です。数値で段階評価したいなら、scoreを返すタスクが候補になります。

注意点

自由記述、推論の質、長文要約、会話の自然さを見る場合はjudge LLMを使う選択肢があります。Cookbookにもjudge LLMを使うレシピが示されています。ただし、judge LLMは便利な反面、採点プロンプト、judge側モデル、入力順序、曖昧な基準に影響されます。結果をleaderboardに出す前に、採点基準を人間が説明できるかを確認してください。

structured outputとdataset評価を分けて考える

形式

structured outputは、モデルに決まった形式で返させたいときに役立ちます。業務システムへつなぐなら、自然文の良し悪しより、JSON schema、必須フィールド、型、欠損時の挙動を見るほうが重要なことがあります。

データ

dataset評価は、複数の入力に対してまとめて性能を見る考え方です。一つの例で成功しても、100件のデータで同じ品質になるとは限りません。datasetを使う場合は、データの権利、匿名化、偏り、失敗行の扱い、集計方法を先に決めます。

再現性は「同じコード」だけでは足りない

注意点

AI評価の再現性は、同じPythonファイルを残すだけでは足りません。モデル側の更新、Model Proxyの条件、利用可能モデル、採点プロンプト、入力データ、SDKやCLIの変更で結果が変わる可能性があります。

記録項目

最低限、次を記録します。

• 評価タスクの目的
• タスクファイルと変更履歴
• 評価データのバージョン
• 使用モデルと確認日
• 採点方式
• CLI/SDK/docsの確認日
• run結果とdownloadファイルの保存先
• 公開範囲

運用の見方

SDKやAI開発者向けライブラリは更新が速いため、<a href="https://googl-watch.blog.mo-gmo.com/googl-15-vertex-ai-genai-sdk-migration/">Vertex AI生成AI SDKの移行期限</a>のような移行記事と同じく、依存関係の確認を運用の一部に入れておくと後で楽になります。

企業・チームで使う前のリスク確認

項目	内容	見方
データ		評価データ、期待出力、採点基準に社内情報や顧客情報が含まれないかを確認します。
認証		Model Proxy credentialsや環境変数の保管先、共有範囲、更新手順を決めます。
公開範囲		task metadata、leaderboard、backing notebookが外部に見える可能性をpublish前に確認します。
再現性		タスク、データ、SDK、CLI、モデル、実行時刻、結果ファイルの版を残します。
運用コスト		失敗時の戻し方、担当者、ログ確認、継続的なドキュメント更新を決めます。

企業利用では、試しやすさよりも、秘密情報の混入と公開後の扱いを先に見るほうが安全です。

Kaggle Benchmarksのローカル対応は、個人開発者にとっては試しやすい更新です。一方、企業やチームにとっては、データ、認証、公開範囲、運用コストの確認が欠かせません。

データ取り扱いと秘密情報を先に棚卸しする

確認項目

評価タスクには、モデルへの指示、評価データ、期待出力、採点基準が含まれます。これらは、社内では「ただのテストコード」に見えても、外部に出ると機密情報になることがあります。

棚卸しの対象は次のとおりです。

• 顧客データ
• 社内文書
• 未公開プロダクト仕様
• 独自プロンプト
• APIキーやtoken
• .env
• run結果
• log
• backing notebook
• downloadした結果ファイル

注意点

Kaggle上で公開するかどうか以前に、外部モデル評価へ送ってよいデータか、社内規程に合うか、匿名化や合成データで代替できるかを確認します。

公開範囲は最後ではなく最初に決める

条件

公開範囲は、最後のpublish直前に考えるものではありません。タスクを作り始める前に、private検証にとどめるのか、taskを公開するのか、backing notebookを公開するのか、leaderboardを外部に見せるのかを決めます。

注意点

CLI docsやskillでpublishに関する説明があるからといって、企業内の承認が省略できるわけではありません。公開操作を誰が実行できるか、レビュー担当は誰か、公開後の説明責任を誰が持つかを、作業手順に含めてください。

運用コストと失敗時の戻し方を見る

下振れ

ローカル対応で作業は速くなりますが、評価基盤をチームで使うなら運用コストも増えます。認証期限切れ、利用可能モデルの変更、SDK更新、タスク実行失敗、ログ不足、結果download漏れ、publish前レビュー漏れが起きると、評価結果の比較が難しくなります。

確認項目

失敗runをどう扱うかも決めておきます。失敗したrunを除外するのか、除外理由を残すのか、再実行するのか。モデルが一時的に使えなかった場合にどう記録するのか。ここが曖昧だと、leaderboardの見た目だけが残り、判断材料として弱くなります。

導入判断チェックリスト

まず試してよい

公開可能なサンプルデータだけを使い、評価目的と採点方式を一文で説明できる状態です。

先に社内確認

社内データ、顧客情報、非公開プロンプト、共有認証情報、公開leaderboardが関わる状態です。

公開を急がない

judge LLMの採点基準、datasetの版管理、run結果の保存先、失敗時の戻し方が固まっていない状態です。

小さく試す場合でも、publishを実行しない前提で検証し、公開判断は別工程に分けると安全です。

Kaggle Benchmarksのローカル作成は、すぐ試せるケースと、社内確認を先に置くべきケースがはっきり分かれます。読者の状況別に、判断の目安を置いておきます。

まず試してよいケース

評価基準

次に当てはまるなら、公式Quick StartやCLI docsを確認しながら、小さなサンプルタスクで試す価値があります。

• 公開してよいサンプルデータだけを使う
• 評価目的が一文で説明できる
• 採点方式がpass/failまたは数値スコアで明確
• Kaggle CLIとModel Proxy認証を扱える
• .envをGit管理から外せる
• run結果とdownload結果の保存先が決まっている
• publishを実行しない前提で検証できる

確認項目

この段階では、完璧なbenchmarkを作るより、タスク、run、log、downloadの関係を手で理解することを優先します。

先に社内確認が必要なケース

評価基準

次に当てはまる場合は、試す前に社内のセキュリティ、法務、データ管理、AI利用ポリシーを確認したほうが安全です。

• 顧客データや社内文書を使う
• 未公開機能やプロンプトを評価に含める
• 外部モデルへ入力してよいか不明
• 企業アカウントや組織所有の扱いが決まっていない
• 結果を外部公開する可能性がある
• backing notebookに残る内容をレビューできていない
• publishを誰が実行するか決まっていない

注意点

このケースでは、Kaggle Benchmarksが悪いという話ではなく、評価タスクの中身が社内資産に近いという話です。公開してよいサンプルデータや合成データで先に練習し、本番データは別の承認を通すほうが現実的です。

公開を急がないケース

評価基準

採点基準が曖昧なままleaderboardだけ作ると、見た目は立派でも判断に使いにくい結果になります。とくに、自由記述の品質、会話の自然さ、業務文脈への適合、長期的な安全性を評価する場合は、最初から公開を急がないほうがよいです。

確認項目

次のどれかが説明できないなら、private検証にとどめます。

• 何を測っているleaderboardなのか
• どの入力データを代表サンプルと見なすのか
• judge LLMを使う場合、採点基準は何か
• 失敗runをどう扱うのか
• model更新時に再実行するのか
• 公開後に誤りが見つかった場合、誰が修正するのか

結論

ローカル対応の価値は、公開を急がせることではありません。公開前に何度も小さく試せることです。

---

次に読むなら

参照した主な情報源

• Google Blog, "Kaggle is making AI benchmark creation effortless"

https://blog.google/innovation-and-ai/technology/developers-tools/build-kaggle–benchmarks-locally/

• Google Blog, "Introducing Community Benchmarks on Kaggle"

https://blog.google/innovation-and-ai/technology/developers-tools/kaggle-community-benchmarks/

• GitHub, Kaggle/kaggle-benchmarks

https://github.com/Kaggle/kaggle-benchmarks

• Kaggle Benchmarks Quick Start

https://raw.githubusercontent.com/Kaggle/kaggle-benchmarks/ci/quick_start.md

• Kaggle Benchmarks Cookbook

https://raw.githubusercontent.com/Kaggle/kaggle-benchmarks/ci/cookbook.md

• Kaggle CLI docs, Benchmarks Commands

https://raw.githubusercontent.com/Kaggle/kaggle-cli/main/docs/benchmarks.md

• Kaggle skills, write-kaggle-benchmarks

https://github.com/Kaggle/kaggle-skills/blob/main/write-kaggle-benchmarks/SKILL.md