ChatGPTコンテナ、Bash実行・パッケージインストール・ファイルダウンロードに対応

 (simonwillison.net)
5 ポイント 投稿者 GN⁺ 2026-01-28 | 1件のコメント | WhatsAppで共有
  • ChatGPTのコンテナ実行環境が大幅に拡張され、Bashコマンドの実行、pip/npmパッケージのインストール、ファイルのダウンロードが可能になった
  • Python中心だった従来環境に、Node.js、Ruby、Go、Java、Swift、Kotlin、C、C++など10以上の言語が追加され、マルチ言語コード実行をサポート
  • 外部ネットワークへのアクセスは引き続き制限されているが、OpenAI内部プロキシを通じてpip installとnpm installが動作するよう構成されている
  • 新ツールcontainer.downloadは、公開URLからファイルを取得してコンテナ内に保存でき、セキュリティ検証手順を経る
  • このアップグレードにより、ChatGPTのコード実行・データ処理能力が大きく拡張され、公式ドキュメント化の必要性が強調されている

ChatGPTコンテナの主な拡張機能

  • ChatGPTは今やBashコマンドを直接実行でき、以前はPythonコードのみが可能だった
    • Pythonのsubprocessモジュールを介した間接実行から脱し、コマンドラインレベルの制御が可能に
  • Node.js環境が追加されてJavaScriptの実行が可能になり、Ruby、Perl、PHP、Go、Java、Swift、Kotlin、C、C++などでもテストに成功
    • Rustはまだサポートされていない
  • コンテナは依然として外部ネットワークリクエストを直接実行できないが、pip installとnpm installはプロキシ経由で動作
  • container.downloadツールを使って、Web上のファイルを指定パスへダウンロード可能
    • ChatGPTがURLを識別し、そのファイルをサンドボックス環境に保存してから処理できる

container.download機能

  • container.downloadは、公開アクセス可能なURLからファイルを取得してコンテナのファイルシステムに保存するツール
  • ダウンロードされたファイルはコンテナ内で解凍、パース、変換などの後処理が可能
  • テストの結果、リクエストヘッダーにはUser-Agent: ChatGPT-User/1.0が含まれ、IPは**Microsoft Azure Cloud（アイオワ州Des Moines）**と確認された

セキュリティ検証: データ流出の可能性

  • container.downloadがデータ流出の脆弱性になり得るかどうかの実験を実施
    • クエリ文字列を含むURLを呼び出した場合、“url not viewed in conversation before”エラーが発生
    • これはClaudeのWeb Fetchに似たURLアクセス制限の安全装置で、ユーザー入力または検索結果として確認されたURLのみアクセス可能
  • web.runを通じた一部クエリ文字列の受け渡しは可能だったが、過去の会話履歴を含む長い文字列はフィルターによって遮断された
  • 現時点での実験ではデータ流出リスクは低いと判断されており、追加のセキュリティ研究の必要性にも言及している

Bashおよびマルチ言語実行

  • Bash実行対応により、ChatGPTはシステムレベルのコマンド実行が可能になった
    • 例: npm installコマンドを実行し、その結果を確認できる
  • Activityパネルの**実行ログ（白黒のコンソールログ）**によって、実際にコマンドが実行されたかを検証できる
  • さまざまな言語で「Hello World」実行テストに成功し、マルチ言語コード実行環境であることが確認された

pipおよびnpmパッケージインストールの仕組み

  • コンテナは外部ネットワークが遮断された状態でも、OpenAI内部プロキシ(applied-caas-gateway1.internal.api.openai.org) を通じてパッケージをインストールする
    • PIP_INDEX_URL、NPM_CONFIG_REGISTRYなどの環境変数がこのプロキシを指している
  • pip、uv、npmなど主要なパッケージマネージャーがこのプロキシ経由で動作
  • 環境変数には**CAAS_ARTIFACTORY_***接頭辞を持つさまざまなレジストリパスが含まれる
    • PyPI、npm、Go、Maven、Gradle、Cargo、Dockerなど多数の内部ストレージパスが存在
  • RustとDockerはまだインストールされていないが、今後の拡張可能性を示唆している

統合活用と今後の課題

  • ChatGPTは今やPython・Node.jsパッケージをインストールし、アップロードまたはダウンロードしたファイルに適用できる
  • コード作成、実行、データ処理、ファイル入出力まで、完全な開発環境レベルの機能を備えた
  • 最大の不足点は公式ドキュメントの欠如であり、リリースノートや詳細な制限事項の公開が必要
  • OpenAIはこの機能群に適切な名称を与えるべきであり、暫定的に“ChatGPT Containers”と呼ばれている

ChatGPTツール全体一覧の要約

  • GPT-5.2環境で利用可能なツール一覧が公開された
    • python.exec、web.run、container.exec、container.download、image_gen.text2imなどを含む
  • 各ツールは明確な説明(description) とシグネチャ(signature) を持つ
  • container.execはコマンド実行、container.feed_charsはインタラクティブセッションへの入力、container.open_imageは画像表示機能を提供
  • bio.update、personal_context.search、user_settings.set_settingなどのユーザー向けパーソナライズ機能も含まれる
  • 全体としてChatGPTは、コード実行・Webアクセス・ファイル処理・ユーザーコンテキスト管理を統合した複合型AI環境へと進化している

関連記事

1件のコメント

 
GN⁺ 2026-01-28
Hacker Newsの意見

  • 私はテクニカルサポート職で働いていて、Pythonには慣れているが開発者ではない
    ところがここ数週間で、GeminiとClaudeが私に「コンピュータを使えますか？」と尋ねてきた
    私は「どのコンピュータ？ 私のコンピュータ？ それとも君たちが持っているコンピュータ？」と聞き返した
    無料のブラウザ版を使っていたので、自分のコンピュータを直接使えるとは思っていなかったが、実際には彼ら自身の環境でPythonスクリプトを実行していた
    計算問題を解くためにLLMに実際のコンピュータを与えるというアイデアを最初に思いついたのが誰なのか気になった
    また、Nano Bananaをプロンプトで動かしたとき、Geminiが画像生成器を三人称で言及していて、「亀の上の亀」みたいな感覚だった

  • 私たちの経験では、エージェントにLinux環境を与えると複合的な利点がある
    普通のツールでは扱いにくい変な状況も自力で解決する
    たとえば、.pngという名前のファイルが実際にはjpegだった場合、マジックバイトを読んで正しく処理する

    • 私もプリント・オン・デマンドのワークフローで似た経験をした
      VisionモデルでICCプロファイルやインク濃度を検証しようとしたが、しばしばでたらめを言う
      結局、エージェントにImageMagickへのアクセス権を与えて直接解析させたが、それが唯一信頼できる方法だった
      そうしないと、失敗した印刷物のコストを自分で負担することになる
    • マジックバイトを読むのは実際には簡単な機能だ
      ほとんどのLinuxの画像ビューアやエディタは、すでに拡張子ではなくマジックバイトでファイル形式を判定している
      Microsoftの拡張子依存の設計がこうした問題を生んだ原因だと思う
    • こういうことをLLMがやるほど特別なことなのかは分からない
      人間なら一般的なUnixツールで数秒でできることだ

  • 標準のChatGPTでも、Node.js、Ruby、Perl、PHP、Go、Java、Swift、Kotlin、C、C++などでコードを実行できるようになった
    公式リリースノートにはないが、無料アカウントでも確認できた

    • 私は .deb ファイルを渡して、D言語コンパイラのDMDをインストールできた
      共有リンク
    • 残念ながら**C#**は一覧にない

  • 「gmail (read-only)」のような項目が見えて驚いた
    ChatGPTのAndroidアプリにはそんな権限はないというが、Gmailの読み取りアクセスがどんな文脈で可能なのか気になる

    • 私はChatGPTウェブアプリでそれを見た
      iPhoneアプリでもgmail.とgcal.の機能が見えた
      共有例
      おそらくMashableの記事に出ていた機能だと思う
      ユーザーが自分でオプトイン設定をしないと有効にならないようだ

  • 最近はどの会社も**ツール呼び出し(tool calling)**機能を自社プラットフォーム内に囲い込もうと競っているように見える
    結局、ローカル環境でモデルがほぼあらゆる作業を実行できるようになれば、サンドボックスの議論も意味が薄れていきそうだ
    永続型の仮想開発環境をいつ提供するのか気になる

    • 私はvibebinプロジェクトを進めているが、
      AIコーディングツールやエージェントを隔離された環境で運用する試みには、今でも価値があると思う
      ほとんどの開発者は、一般的なGPTのウェブUIよりこうした特化型のコーディングツールを使うだろう
    • Claude Code for the webはすでに一種の永続型仮想開発環境だ
      セッションを開始して作業し、1日後に戻ってきてもファイルシステムの状態がそのまま維持されている
      おそらくオブジェクトストレージを活用してコストを下げる構造なのだろう
      参考までに、FlyのSprites.dev設計記事も興味深い
    • この流れのためにAnthropicがBunを買収したのだと思う
    • 多くの企業がこうした方向に進んでいる
      ローカルハードウェアの代わりに薄いクライアントだけを置き、実際のワークロードはMicrosoftのようなところに任せる構造だ
      個人的にはローカル開発環境がないのは地獄のようだが、時代の流れはそちらに向かっているようだ

  • この機能は時間を大幅に節約するか、あるいは**教育的な障害(outage)**を生み出すかのどちらかになりそうだ

    • もしエージェントが自分でモデルを更新できるなら、それはモデルにとってだけの教育になるだろう

  • Simonの探偵のような発見がすばらしい
    こういう「発見型のポスト」は公式発表よりずっと面白い

    • その通りで、人々が自分で見つけて共有するときに生まれる創造的エネルギーがある
      単なるプレスリリースよりはるかに刺激的だ

  • そのうちChatGPTが**使い捨てアプリ(single-use app)**をその場で作ってくれる時代が来そうだ
    ブラウザ内でクラウドサンドボックスアプリを生成して目的を達成し、終わったらすぐ破棄するような形だ

    • すでにこうした機能を実装した事例がある
    • たとえばexe.devやsprites.devのような代替が存在する