Colab CLIの使い方｜インストール・GPU指定・colab runとWindows対応状況【v0.7.4】

Colab CLIは、Google Colabのランタイム（クラウド上のVM）をブラウザを開かずにターミナルから確保・実行・解放するための公式ツールです。Googleは2026年6月5日にDevelopers Blogで公開を告知し、2026年10月19日時点の最新版はPyPIの0.7.4（2026年9月26日公開）です。公開後には、SSH接続のcolab ssh、残高確認のcolab usageが加わり、対話的なリモート開発や利用残高の確認にも対応しました。この記事では、macOS（x86_64）・Python 3.12に0.7.4を導入し、--help、認証開始画面、実行前チェック、ソースコードを確認した範囲で、導入と認証、GPU・TPUの指定、実行コマンドの使い分け、実行履歴の扱い、Windowsで動かない理由までを順に説明します。GPU・TPUの確保と課金の挙動は実測しておらず、公式資料に基づきます。

まとめ：Colab CLIの要点（v0.7.4時点）

• 提供元はGoogle Colabチーム（GitHubのgooglecolab/google-colab-cli）で、ライセンスはApache-2.0。PyPIのパッケージ名はgoogle-colab-cli、コマンド名はcolabです。
• 導入はuv tool install google-colab-cli（推奨）かpip install google-colab-cli。Python 3.12以上が必要です。
• 公式の対応OSはLinuxとmacOSだけです。Windowsでは0.7.4の時点でcolab --helpすら起動せず、修正はGitHubのmainに入ったものの未リリースです。
• 基本の流れはcolab new（確保）→colab exec（実行）→colab stop（解放）。1回きりの処理ならcolab runがこの3つを1コマンドで行い、既定では終了時にVMの解放を試みます。ただし、通信障害などによる解放失敗はあり得ます。
• GPUは--gpuでT4・L4・G4・H100・A100、TPUは--tpuでv5e1・v6e1を指定します。使えるかどうかはColabの契約プラン次第です。
• 認証の既定値は0.7.4の実装ではoauth2（URLを開いて認可コードを貼る方式）です。READMEはadcと書いており、記述と実装がずれています。
• 実行したコードは手元の~/.config/colab-cli/history/に記録され、colab log -s 名前 -o log.ipynbでノートブックに書き出せます。-sを省くと書き出されません。--envで渡したトークンも平文で残ります。
• AIエージェントから使う前提で、使い方を説明するスキルファイルが同梱されています（colab skillで出力）。

Colab CLIの提供元と、ノートブックUIとの役割の違い

GitHubのリポジトリの作成日は2026年4月17日、PyPIへの初回公開は5月22日の0.5.4で、Googleは6月5日にDevelopers Blogで公式に告知しました。告知記事の著者はGoogle ColabのプロダクトマネージャーSpencer Shumway氏とエンジニア2名で、開発者だけでなく「ターミナルを操作できるAIエージェント」に計算資源を渡すことを目的に掲げています。記事中のデモでは、AntigravityのエージェントがT4 GPUを確保し、Gemma 3 1BをQLoRAでファインチューニングし、アダプタを回収してVMを止めるまでをCLIだけで実行しています。Claude CodeやCodexからも同じように使えると明記されています。

ノートブックUIとの違いは、コードの置き場所です。ノートブックではセルにコードを書いてブラウザ上で実行しますが、CLIではローカルのエディタで書いた.pyや.ipynbをそのままVMのカーネルへ送ります。colab exec -f train.pyはファイルをローカルで読んで中身を送信するので、事前のアップロードは不要です。手元の編集がそのまま次の実行に反映され、Gitの管理下にあるコードをColabのGPUで動かす使い方に向いています。グラフを見ながら試行錯誤する探索的な作業はノートブックUIのほうが速く、colab url --openで確保済みのセッションをブラウザのColabに接続して切り替えられます。

同名の非公式colab-cliとcolab-xtermとの違い

「colab-cli」で検索すると、公式とは別のMurphyLo/colab-cliも見つかります。2026年3月19日に作られた個人のリポジトリで、TypeScriptで書かれ、Node.js 22以上が必要です。npmには公開されておらず、ソースを取得してnpm linkで入れます。サブコマンドはcolab runtime・colab shell・colab port-forwardなどで、公式とは体系が違います。コマンド名はどちらもcolabなので、両方を入れるとPATHの先にある方だけが動きます。2026年10月19日時点でLICENSEファイルが無く、業務で使うなら公式のgoogle-colab-cliを選んでください。公式の旧リポジトリ名googlecolab/colab-cliは現在404です。

colab-xtermは、InfuseAIの非公式拡張で、ノートブックの中にターミナル画面を開くものです（PyPIの最終版は2023年7月の0.2.0）。ローカルからColabを操作するColab CLIとは向きが逆です。

Colab CLIのインストールと初回認証の手順

uvまたはpipでの導入とPython 3.12以上の要件

パッケージはpyproject.tomlでrequires-python = ">=3.12"と指定されており、3.11以前のPythonでは入りません。公式READMEはuvでのインストールを推奨しています。uvのtool installは専用の仮想環境に入れてcolabコマンドだけをPATHに出すので、プロジェクトの依存と混ざりません。uvそのものの開発元の動向はOpenAIのAstral買収とuvの現状で整理しています。

# uvで導入（推奨）
uv tool install google-colab-cli

# pipで導入する場合
pip install google-colab-cli

# 導入した版を確認
colab version
# Version: 0.7.4

更新はcolab updateで新しい版の有無を確認し、colab update --installでその場で上げられます。uvで入れた場合はuv tool upgrade google-colab-cliでも構いません。

oauth2とADCの2つの認証方式と既定値のずれ

認証情報が未保存の場合、最初にColabのAPIへ接続するコマンドを実行すると、Googleアカウントでの認可を求められます。認証方式はグローバルオプション--authで選び、選択肢はoauth2とadc（Application Default Credentials）の2つです。

注意したいのは既定値です。READMEと同梱のSKILL.mdは「既定はadc」と書いていますが、0.7.4のcolab --helpは[default: oauth2]と表示し、ソースのcli.pyもAuthProvider.OAUTH2を既定にしています。GitHubのmainブランチでも同じです。オプションを付けずに実行すると、次のように認可用URLが表示され、ブラウザで承認したあとに出る認可コードを貼り付ける流れになります。

$ colab sessions
To authorize colab-cli, visit this URL in any browser:

  https://accounts.google.com/o/oauth2/auth?response_type=code&...

After approving, Google will display an authorization code.
Enter the authorization code:

この方式は0.6.0（2026年6月16日）で、ローカルにコールバック用サーバーを立てる方式から切り替わりました。URLを別の端末のブラウザで開けばよいので、SSH先のLinuxサーバーやコンテナの中でも認証できます。取得したトークンは~/.config/colab-cli/token.jsonに保存され、2回目以降は聞かれません。

AIエージェントやCIで対話を避けるには、人が事前に認可して用意したADCを使う方法があります。ADCはColabのバックエンドが要求するスコープを含めて発行する必要があり、同梱のSKILL.mdは次の4スコープを指定しています。このgcloudコマンド自体はブラウザでの認可を伴うので、人が1回実行しておく準備手順です。発行後はcolab --auth=adc newのように、サブコマンドの前に--authを置きます。

gcloud auth application-default login \
  --scopes=openid,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/colaboratory

colab --auth=adc sessions

なおcolab authというサブコマンドは、CLIのログインとは別物です。VM上のPythonコードがBigQueryやCloud Storageを呼べるように、VM側へGCPの認証情報を渡すためのものです。CLIが401や403で止まったときにcolab authを打っても直りません。

設定ファイルとセッション情報の保存場所

CLIはローカルに次のファイルを作ります。確保中のVMへ接続するためのトークンを含むので、共有フォルダやリポジトリに置かないでください。

セッション情報の置き場所はグローバルオプション--configで変えられます。案件ごとにセッション情報を分ける場合は、--configで別ファイルを指定します。ただし、Googleアカウントの認証情報はこの指定では分離されません。

WindowsでColab CLIが起動しない原因と回避策

READMEは「現時点で対応しているのはLinuxとmacOSのみ」と明記しています。実際、Windowsに0.7.4を入れるとインストール自体は通りますが、colab --helpを含むすべてのコマンドがModuleNotFoundError: No module named 'termios'で落ちます。原因は、対話コンソール用のconsole.pyがUnix専用のtermiosモジュールを無条件に読み込んでおり、起動時の読み込み経路にこのファイルが入っていることです。2026年7月13日に0.6.0での同じ現象がIssue #78として報告され、10月19日時点でもopenのままです。

修正は2026年10月6日（UTC）にPR #135としてmainブランチに取り込まれました。termiosが無い環境では行単位の入力に切り替え、colab drivemountの認可入力も/dev/ttyが無ければ標準入力から読むようにする内容です。続いて10月13日にはPR #158が入りました。Windowsではselect()がソケットにしか使えず、colab ssh --proxy-modeが標準入力を読めないままsshが固まる不具合を直すものです。PR本文には、Windows 11とPython 3.12でsshのテストが通ったと書かれています。ただし2026年10月19日時点のPyPIの最新版は0.7.4のままで、どちらの修正も含まれていません。READMEの「Windows非対応」の記載も変わっていません。

Windowsで今すぐ使うなら、WSL2のLinux（Ubuntu等）の中にuvとColab CLIを入れるのが現実的です。公式ドキュメントにWSLへの言及は無いものの、CLIから見ればLinux環境です。oauth2の認可URLはWindows側のブラウザで開いて、コードをWSLのターミナルに貼れば通ります。Windowsネイティブ環境で修正版を待つ場合は、PyPIのリリース履歴を確認してください。0.7.4では起動時にエラーになるため、colab updateも実行できません。

colab newでのGPU・TPUの指定と使えるランタイム

–gpuと–tpuに指定できる値とプランの関係

colab newは、オプションを付けなければCPUのランタイムを確保します。アクセラレータは--gpuか--tpuで指定し、-sでセッション名を付けます。0.7.4の--helpに載っている値は次のとおりです。

--helpには「利用可否はColabの契約プランによる」と書かれています。同梱のSKILL.mdはさらに踏み込んで「多くのアカウントはCPUしか確保できない。GPUやTPUが割り当たる前提で組まない」と注意しています。割り当てに失敗するとHTTP 412が返り、0.7.0以降はトレースバックではなく読める形のエラーメッセージになりました。確保の応答が遅いと、バックエンド側ではVMができているのにCLIが読み取りタイムアウトで失敗することがあり、10月14日にmainへ入ったPR #172で環境変数COLAB_CLI_REQUEST_TIMEOUT（HTTPのタイムアウト）とCOLAB_CLI_ASSIGN_RETRIES（再試行回数・既定3）が加わりました。0.7.4には含まれないため、PyPIから入れた版ではこの変数は効きません。設計文書にはTPU v2-8の値も載っていますが、0.7.4の--tpuが受け付けるのはv5e1とv6e1だけです。TPUの世代ごとの違いはTPUとは？GPU・CPUとの違いと世代別の性能で解説しています。

# CPU
colab new -s cpu1

# GPU（T4）
colab new -s trainer --gpu T4

# TPU v6e1
colab new -s tpu1 --tpu v6e1

# A100をハイメモリ構成で（Pro・Pro+が必要）
colab new -s big --gpu A100 --high-mem

対応外の–gpuの値がA100扱いになる落とし穴

0.7.4のソース（commands/session.py）は、--gpuの値を小文字にして対応表から引き、見つからなければA100を既定値として使います。--gpu t4のような大文字小文字の違いは吸収されますが、--gpu V100や--gpu 4090のように対応外の値を渡すと、エラーにならずにA100を要求します。無料枠ではA100は割り当たらないので、次の段階で412エラーになり、原因が綴りだと気付きにくくなります。--tpuも同じで、v5e1以外の値はすべてv6e1として扱われます。スクリプトに書く値は上の表のものに限ってください。

セッションの確認・切り替え・停止

確保したセッションはcolab sessionsで一覧し、colab statusでハードウェアやマシン構成を確認します。セッションが1つしか無ければ、以降のコマンドで-sを省略できます。複数持つと省略できなくなるため、SKILL.mdは「常に-sで名前を付ける」ことを勧めています。

colab sessions           # 確保中のセッション一覧
colab status -s trainer  # GPU種別やマシン構成
colab restart-kernel -s trainer
colab stop -s trainer    # VMを解放

0.7.4では、CLIが裏でVMの生存確認を送り続ける仕組みは廃止されています。2026年9月25日の変更で、VMの生存はColab側がカーネルの稼働状況から判断するようになりました。「CLIが60秒ごとに通信して最大24時間維持する」という公開当初の解説は現行版には当てはまりません。

colab execによるコード実行とファイル転送

標準入力・.py・.ipynbの3通りの実行とカーネル状態の保持

colab execは、標準入力・.pyファイル・.ipynbファイルの3通りでコードを受け取ります。ノートブックを渡した場合は各コードセルを順に実行し、結果を入力と同じ場所の<ファイル名>_output.ipynbに書き出します。実行時の作業ディレクトリはVMの/contentです。

# 標準入力から
echo "import torch; print(torch.cuda.is_available())" | colab exec -s trainer

# ローカルの.pyを送って実行（アップロード不要）
colab exec -s trainer -f train.py --env WANDB_MODE=offline

# ノートブックを実行し、結果をreport_output.ipynbに保存
colab exec -s trainer -f report.ipynb

同じセッションに対するcolab execは、毎回同じカーネルに接続し直します。1回目でimportした変数や読み込んだデータは2回目の実行でも残っています。重いモデルの読み込みを1回目に済ませ、2回目以降は推論だけを送る使い方ができます。ただし、colab stopやcolab restart-kernelの実行時だけでなく、ランタイムの回収やカーネルの異常終了時にも状態は失われます。

実行には--timeout（既定30秒）があります。公式の設計文書は、モデルのコンパイルやデータのダウンロードのように出力が長く途切れる処理で途中終了しないよう、この値を延ばす用途を挙げています。出力が出ない時間が長い処理では--timeout 3600のように大きめに指定してください。環境変数は--env KEY=VALUEを繰り返して渡します（0.7.0で追加）。

upload・download・ls・rm・editによるファイル操作

ファイル操作はVM上の/contentを起点に、絶対パスで指定するのが確実です。colab editは、手元の$EDITORでVM上のファイルを開いて保存すると書き戻します。

colab upload -s trainer data.csv /content/data.csv
colab ls -s trainer /content
colab download -s trainer /content/checkpoints/model.bin ./model.bin
colab rm -s trainer /content/data.csv
colab edit -s trainer /content/config.yaml

Googleドライブはcolab drivemountで/content/driveにマウントできます。ブラウザでの承認が要るため、人が端末の前にいる必要があります。パッケージはcolab install torch transformersやcolab install -r requirements.txtで入れ、VM側ではuvを優先して使い、無ければpipに切り替わります。

colab repl・colab console・colab sshの使い分け

VMに入って対話的に作業する手段は3つあります。用途で選び分けます。ただし、Colab FAQは、コンピューティングユニットの残高が無い無料ランタイムでのSSHシェルなどのリモート操作を禁止しており、予告なく停止されることがあると明記しています。colab consoleやcolab sshを利用する場合は、有料プランの購入に加えて、正のコンピューティングユニット残高を維持する必要があります。

replとconsoleはローカルにTTYが必要で、スクリプトから使うときはecho "print(1)" | colab replのように標準入力をパイプで渡すと非対話モードで動きます。consoleはtmux越しのため、パイプ経由でも出力に端末制御文字が混じります。

colab sshは0.7.0（2026年9月3日）で追加された機能で、WebSocketの上にSSHを通します。--proxy-modeを付けるとOpenSSHのProxyCommandとして動くため、~/.ssh/configに書いておけばVS CodeのRemote-SSHからColabのVMを開けます。受け付ける鍵はed25519とECDSAだけで、RSA鍵はサーバー側で拒否されます。0.7.0はビルドの不具合でPyPIに上がらなかったため、PyPIから入れてcolab sshを使えるのは0.7.1以降です。

Host colab-t4
  ProxyCommand /Users/you/.local/bin/colab ssh --proxy-mode -s t4dev --gpu T4 --rm
  User root
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null

ProxyCommandはログインシェルを経由しないため、colabは絶対パスで書きます。-sの名前のセッションが無ければ初回接続時に作られ、--rmを付けると切断時にVMを解放します。

colab runで確保から解放までを1コマンドにする方法

colab runは、new→exec→stopを1回で行うコマンドです。新しいVMを確保し、ローカルのスクリプトを引数付きで実行して、既定では終了時にVMの解放を試みます。解放処理はtry/finallyで書かれており、スクリプトが例外で落ちた場合も、--keep未指定ならVMの解放を試みます。colab stopの打ち忘れによる消費を仕組みで減らせる点がexecとの最大の違いです。ただし、0.7.4の解放処理は失敗しても例外を握りつぶすため、解放APIの失敗やCLIプロセスの強制終了時にはVMが残る可能性があります。学習結果を残す場合は、スクリプト内で外部ストレージへ保存するか、--keepでVMを残して成果物をダウンロードしてから停止してください。

# T4で学習スクリプトを実行し、終了後にVMを解放
colab run --gpu T4 train.py --epochs 3 --lr 2e-4

# 終了後もVMを残す（あとでcolab exec -s jobで続きを実行）
colab run --gpu L4 --keep -s job train.py

スクリプトの中ではsys.argvが['train.py', '--epochs', '3', ...]に、__name__が"__main__"に設定されるので、if __name__ == "__main__":で書いた普通のスクリプトがそのまま動きます。sys.exit(N)の終了コードもローカルに返るため、シェルスクリプトやCIで成否を判定できます。存在しないファイル名を渡した場合は、VMを確保する前に[colab] Script not found: ...で止まり、無駄な課金は発生しません（0.7.4で確認）。

シバン行にcolab runを書けば、ファイル単体を実行するだけでGPU上で動きます。

#!/usr/bin/env -S colab run --gpu L4
import torch

print("GPU:", torch.cuda.get_device_name(0))

chmod +xしたうえで./script.pyと実行します。envの-Sは、colab run --gpu L4のように複数の語を渡すために必要です。

使い分けは「同じVMで何度も実行するか」で決まります。データの読み込みやモデルのロードを使い回すならnewとexec、1回の学習やバッチ処理で終わるならrunです。runは毎回VMを新しく確保するので、パッケージの導入やデータの取得も毎回走ります。

colab logで実行履歴を書き出す方法と履歴ファイルの注意点

Gemma 3 1BのQLoRA学習例と実行履歴の書き出し

公式の告知記事は、google/gemma-3-1b-itをSQL生成向けにQLoRAで調整する例を、次の5つのコマンドで示しています。最後にcolab downloadでアダプタとトークナイザーの設定を回収し、手元で読み込みます。QLoRAそのものの仕組みと必要なVRAMの目安はQLoRAとは？4bit量子化＋LoRAの仕組み・VRAM目安で扱っています。

colab new --gpu T4
colab install transformers datasets peft trl bitsandbytes accelerate
colab exec -f finetune_run.py
colab log --output gemma_finetune_log.ipynb
colab stop

この4行目は、0.7.4では何も書き出しません。colab logは他のコマンドと違い、-sを省くと「履歴のあるセッションの一覧」を表示して終わり、--outputは無視されます（ソースのcommands/utility.pyと実行で確認）。ファイルが作られないまま次のcolab stopに進むため、実行記録が残っていないことに後から気付きます。セッション名を付けて確保し、colab logにも同じ名前を渡してください。

# finetune_run.pyをローカルに用意してから実行
colab new -s gemma --gpu T4
colab install -s gemma transformers datasets peft trl bitsandbytes accelerate
colab exec -s gemma -f finetune_run.py
colab log -s gemma -o gemma_finetune_log.ipynb
# [colab] Exported history to 'gemma_finetune_log.ipynb'.
# 保存先はfinetune_run.pyの書き方次第
colab download -s gemma /content/adapter/adapter_model.safetensors ./adapter_model.safetensors
colab stop -s gemma

書き出し形式は拡張子で決まり、.ipynb・.md・.txt・.jsonlの4つです。.ipynbは実行したコードをセルとして並べたノートブックになり、ブラウザのColabで開き直して同じ手順を再実行できます。-t executionで実行だけに絞る、-n 20で直近20件に絞ることもできます。履歴はローカルのファイルなので、colab stopでVMを解放したあとでも書き出せます。

–envの値も平文で残る履歴ファイルの扱い

履歴の実体は~/.config/colab-cli/history/<セッション名>.jsonlです。0.7.4のcolab exec・colab run・colab replは、VMへ送ったコードと出力を実行のたびにこのファイルへ追記します。colab uploadやcolab downloadは、ファイルの中身ではなくパスだけを記録します。

問題は--envです。--env HF_TOKEN=…はVM側の環境変数を直接設定するのではなく、os.environ['HF_TOKEN'] = '…'というPythonの行をコードの先頭に足して送る実装です。そのため、トークンの値がコードの一部として履歴に残ります。0.7.4の同じ関数で組み立てたコードを記録し、セッション名を指定したcolab log -s 名前 -o 出力.ipynbで書き出したところ、トークンの行は.ipynbのセルにもそのまま入っていました。権限はCLIが指定せずumaskに従うため、macOSの既定（umask 022）で作られたファイルは644でした。親フォルダの権限次第では、同じMacの他のユーザーからも読めます。

{"timestamp": "2026-10-19T01:50:02+00:00", "event_type": "execution",
 "code": "import os\nos.environ['HF_TOKEN'] = 'hf_dummy123'\nprint(1)", "outputs": []}

書き出したノートブックをGitHubやチャットで共有すると、トークンも一緒に渡ります。Hugging FaceやW&Bのトークンは--envで渡さず、トークンを書いたファイルをcolab uploadでVMに送り、スクリプトの中で読む構成にすると、履歴にはファイルのパスしか残りません。--envを使った場合は、共有前に書き出したファイルをgrepで確かめ、不要になった履歴はhistoryフォルダから消します。0.7.4には履歴を消すコマンドも、記録を止めるオプションもありません。

AIエージェントから使う場合のスキルファイルとColab MCP Serverの選び方

Colab CLIには、エージェント向けの説明書（スキルファイル）が同梱されています。colab skillで中身を表示でき、Claude CodeなどのAgent Skillsの形式（nameとdescriptionを持つSKILL.md）で書かれています。内容はセッションの考え方、認証、実行、ファイル操作の注意点で、エージェントが詰まりやすい箇所が具体的に書かれています。

• colab repl・colab console・colab auth・colab drivemountをエージェントが対話的に起動しない（TTY待ちで止まる）
• ブラウザ操作が要るoauth2より、ADCで認証しておく
• colab newには必ず-sで名前を付ける
• CLIの401・403はcolab authではなくスコープの問題として扱う

同じGoogle Colabチームは、MCPサーバーのColab MCP Serverも公開しています。こちらはブラウザで開いているColabのノートブックにローカルのエージェントをつなぐもので、エージェントがノートブックのセルを書き換えながら作業します。READMEは、対応クライアントとしてGemini CLI・Claude Code・Windsurfを挙げています。

人がノートブックを見ながらエージェントと一緒に分析するならMCP Server、エージェントにGPUジョブを任せて結果だけ受け取るならCLIです。CLIのREADMEも、ノートブック内での対話的な作業ならMCP Serverを使うよう案内しています。CLIとMCP Serverの二択なら、認証を済ませた無人ジョブにはCLIが向いています。ただし、Colabの資源割り当てや実行時間は保証されないため、開始時刻や完走を保証する必要がある本番バッチには採用すべきではありません。エージェントに計算資源を持たせる設計を業務システムに組み込む場合は、権限と課金の上限を先に決めておく必要があります。設計から相談する場合はAIエージェント開発の支援も用意しています。

GPUを数時間単位で借りる手段としては、Colab以外のGPUクラウドも候補になります。長時間の学習や大容量のディスクが必要な場合の比較はRunpodとは？料金・使い方とGPUクラウドの選び方を参照してください。

Colab CLIの料金とコンピューティングユニットの管理

CLI自体は無料ですが、確保したランタイムはブラウザのColabと同じ契約・同じ残高で動きます。Colabの公式案内によると、無料版でもNVIDIA T4 GPUを使えますが、クォータと空き状況の制限を受けます。無料版のノートブックの実行は最長12時間で、アイドル時のタイムアウト時間は公表されていません（Colab FAQ）。2026年10月15日にはREADMEへ、CLIの利用にもColabの利用規約とGoogleのプライバシーポリシーが適用されると追記されました。CLIから使う場合も、ブラウザ版と同じ規約が適用されます。有料プランの価格は、Google Workspace for Education向け管理者ヘルプのフレキシブルプランではColab Proが月額9.99米ドル・月100コンピューティングユニット、Colab Pro+が月額49.99米ドルと案内されています。個人向けの価格と付与量は購入ページの表示が正です。

消費ユニットは割り当てられたランタイム構成によって異なります。GPU名だけで固定的に比較せず、実際の消費ペースを確認してください。--gpuの選択肢にあるG4は、NVIDIA RTX PRO 6000 Blackwell Server Editionを載せたマシンで、Colabのリリースノートでは2026年3月25日に追加されています。

残高と消費ペースはcolab usageで確認でき、残高（compute units）と1時間あたりの消費量が表示されます。colab payはプランの購入ページをブラウザで開きます。GPUを確保している間は処理をしていなくても消費が続くので、colab execで使ったセッションは作業の区切りでcolab stopし、colab sessionsで残っていないことを確かめてください。

0.5系から0.7系までの間に、認証方式や生存確認の仕組みが変更されています。業務の自動化に組み込むなら、uv tool install google-colab-cli==0.7.4のように版を固定し、上げる前にGitHubのCHANGELOGで変更点を確かめてください。

よくある質問

Colab CLIは無料で使えますか？

CLI自体は無料のオープンソースです。Colabの公式案内では無料版でもT4 GPUを使えるものの、クォータと空き状況次第で割り当たらないことがあり、同梱のSKILL.mdも「多くのアカウントはCPUしか確保できない」と注意しています。--high-memはPro・Pro+が前提です。

WindowsでColab CLIを使う方法はありますか？

0.7.4はWindowsでは起動時にtermiosが見つからず落ちます。起動時の修正は2026年10月6日（UTC）、colab ssh --proxy-modeの修正は10月13日にmainへ入りましたが、10月19日時点のPyPI最新版0.7.4にはどちらも含まれていません。当面はWSL2のLinuxに入れて使うのが現実的です。

colab execとcolab runはどちらを使えばよいですか？

同じVMで繰り返し実行するならcolab newとcolab exec、1回で終わる処理ならcolab runです。runは既定で終了時にVMの解放を試みるため、停止忘れを減らせます。通信障害などが起きた場合は、セッションが残っていないか確認してください。

ColabのGPU上でターミナル（シェル）を使えますか？

使えます。colab consoleでtmux上のbashに入るか、colab sshでSSH接続します。SSHならVS CodeのRemote-SSHからVMを開いて編集することもできます。ただしColab FAQは、残高の無い無料ランタイムでのSSHシェル等を禁止しています。

Colab CLIをClaude CodeやCodexから使えますか？

使えます。告知記事はAntigravityでの例を示したうえで、Claude CodeやCodexでも使えると明記しています。colab skillで出力されるスキルファイルをエージェントに読ませ、認証はADCで済ませておくと止まりにくくなります。

関連記事

• TPUとは？GPU・CPUとの違い、世代別の性能と料金、TorchTPUでのPyTorch対応
• QLoRAとは？4bit量子化＋LoRAの仕組み・VRAM目安・実装手順と採用判断を解説【2026年版】
• Agent Skillsとは？SKILL.md仕様と46製品で動かす移植性の実装手順
• Runpodとは？料金・使い方・支払い方法とGPUクラウドの選び方【2026年10月】
• Jupyter Notebookのインストール手順｜7.6系をpip・uv・condaで入れる方法