Windows-Copilot-API レビュー: 個人の Copilot セッションを OpenAI 互換エンドポイントに変える

このプロジェクトが埋める隙間: 課金なしで OpenAI 形式を欲しがる場面

OpenAI の SDK やそれを前提にしたツールはすでに手元にある。しかし API キーを発行して従量課金を受け入れるほどでもない、という状況は珍しくない。プロトタイプ、個人のスクリプト、ローカルで動くエージェントの検証などが典型だ。Windows-Copilot-API はこの隙間を狙う。README によれば、通常の Microsoft アカウントでサインイン済みの Copilot をそのまま使い、API キーもクレジットも有料プランも不要とする。対象は個人利用者であり、Microsoft の消費者向け Copilot Web 体験を自動化する非公式プロジェクトだと明記されている。Microsoft との提携や承認はない。モデル名として GPT-4 や GPT-5 に触れているが、これは Copilot 側が提供するモデルを指すのであって、このプロジェクトが独自にモデルを配布しているわけではない。

仕組み: Playwright がログインし、セッションがトークンを供給する

中心にあるのはブラウザ自動化だ。requirements.txt に依存関係があり、セットアップ手順では playwright install chromium を一度実行する。python -m copilot login を走らせると可視ブラウザが開き、Microsoft または Google アカウントでサインインする。README によれば、サインインを検出するとブラウザは自動で閉じ、その後 1 通の短いウォームアップメッセージを送る。この 1 手でチャットトークンの発行と Cloudflare の人間確認を同時に通すと説明されている。結果として履歴に使い捨てのチャットが 1 件残る。セッションは session/ 配下に保存され、git-ignore の対象で共有されない。以降の実行ではこの保存済みセッションを読み込むため、初回リクエストから動く。Python ライブラリとして使う場合、CopilotClient() がセッションを読み込み、chat() がテキストと conversation_id を返し、その id を渡し直すと同じスレッドが継続する。stream() は応答を断片ごとに yield する。サーバとして使う場合は app.py が localhost:8000 で OpenAI 形式を喋り、base_url に localhost を指定した公式 openai SDK がそのまま動く。API キーは SDK 側が要求するが無視される、と README は書いている。

セットアップ: 仮想環境、Playwright、ログインの 3 段階

手順は README に具体的に載っている。git clone の後、python3 -m venv venv と source venv/bin/activate で仮想環境を作る。Windows では python -m venv venv と venv\Scripts\Activate.ps1 になり、PowerShell のスクリプト実行を一度許可する必要がある場合がある。cmd.exe では venv\Scripts\activate.bat を使う。続いて pip install -r requirements.txt、playwright install chromium、そして python -m copilot login の順に実行する。ログイン中の問題は session/login.log に記録される。サーバを立てるなら python app.py で 127.0.0.1:8000 に上がる。Docker を使う場合は docker compose up --build で localhost:8000 に公開され、docker-compose.yml がポート 8000 をマップし session/ をバインドマウントする。RATE_LIMIT_RPM と RATE_LIMIT_BURST はこのファイルで調整する。Compose なしなら docker build -t windows-copilot-api . の後、docker run --rm -p 8000:8000 -v "$(pwd)/session:/app/session" windows-copilot-api を実行する。

Docker 運用の現実: クリアランスはコンテナ内で更新できない

ここが設計上もっとも素直でない部分だ。ログインは可視ブラウザを必要とするため、ヘッドレスのコンテナ内では実行できない。README はホスト側で先に python -m copilot login を済ませ、session/ をコンテナにマウントして再利用する構成を指示している。コンテナはチャットトークンをヘッドレスで更新できるが、新しい Cloudflare クリアランスは取得できない。そのためクリアランスが失効すると 503 を返す。README は失効の目安を約 30 分と書いている。つまり Docker 構成は、ホストでの再ログインを定期的に挟まないと止まる。長時間動かしっぱなしにする用途には向かない。この点は README の表現をそのまま採ると、環境によって変わりうる数値であり、筆者の環境で検証したものではない。導入を検討するなら、自分の回線とアカウントでどの程度持つかを測る必要がある。

向かない場面: 共有サービスと規約の境界

このプロジェクトは個人利用を前提としている。README 自身が非公式であり、Microsoft の消費者向け Copilot Web 体験を個人利用のために自動化すると述べ、Microsoft の規約の範囲内で責任を持って使うよう求めている。複数の利用者に API を配る、商用サービスに組み込む、といった使い方はこの前提から外れる。加えて、認証は個人の Microsoft または Google アカウントに紐づく。アカウント停止や UI 変更があれば、そのまま動かなくなる種類の依存だ。レート制限も Copilot 側の挙動に左右される。RATE_LIMIT_RPM と RATE_LIMIT_BURST はあくまでローカルサーバ側の制御であり、上流の制限を緩めるものではない。代替としては、素直に OpenAI や Azure OpenAI の API キーを発行して使う方法がある。違いは明確で、向こうは認証と課金がプロバイダ側の契約に載り、UI 変更に引きずられない。こちらは無料と引き換えに、ブラウザセッションとクリアランスの寿命に運用が縛られる。

ライセンスと保守コストの見積もり

ライセンスは MIT で、リポジトリのメタデータにもそう記載されている。MIT はソフトウェアの利用、改変、再配布を広く許すが、これはコードに対する条件であって、Microsoft Copilot の利用条件やアカウント契約を上書きするものではない。法的な判断はここでは扱わないが、この 2 層を混同しないことが重要だ。保守の観点では、依存が Playwright とブラウザ、そして Copilot の Web UI に向いている。UI の変更、Cloudflare のチャレンジ仕様の変更、認証フローの変更のいずれかが起きれば、追従が必要になる。リリースは取得されておらず、バージョン管理された API 表面があるわけでもない。アップグレードは pip と git の更新、そして場合によっては再ログインという形になる。壊れ方としては、セッション失効による 503、ログイン時のチェックボックス通過失敗、UI 変更によるセレクタの不一致が想定される。README はトラブルシューティング用の診断が同梱されており、captcha やクリアランスの問題を修正しつつ共有可能なレポートを記録すると説明している。

編集部の結論

既存の OpenAI SDK を使ったツールを、課金なしで手元の Copilot アカウントに向けて動かしたい個人開発者には向いている。逆に、複数ユーザーに配るサービスや、SLA を前提とする本番ワークロードには向かない。導入前に確認すべきは、自分の環境で Cloudflare のクリアランスがどの程度持続するか、そして Docker 運用時に 503 がどの頻度で発生するかである。これらは README の記述からは環境依存としか分からないため、実際に python -m copilot login を実行して session/ が生成され、curl で /v1/chat/completions が応答するまでを自分の手で確かめるのが最初の一歩になる。

公式情報源

1. Issues
2. License: MIT
3. README
4. sums001/Windows-Copilot-API on GitHub