私立ずんだもん女学園放送部 podcast 20260515
内容紹介
Building a safe, effective sandbox to enable Codex on Windows、米の高性能AIモデル 3メガバンクが利用できるよう調整 NHKニュース、Unlocking asynchronicity in continuous batching
出演者
youtube版(スライド付き)
関連リンク
OpenAIのエンジニアリングチームが、Windows環境で自律型コーディングエージェント「Codex」を安全に実行するための「サンドボックス（隔離環境）」をどのように構築したかを解説した記事です。
背景と課題
Codexのようなコーディングエージェントは、開発者の代わりにテストの実行やファイルの編集、Git操作などを行います。しかし、これらをユーザーと同じ権限で自由に実行させるのはセキュリティリスクが非常に高く、かといって実行のたびにユーザーの承認を得るのでは利便性が損なわれます。 MacOSやLinuxには標準的な隔離機能がありますが、Windowsには「開発者のワークスペースと連携しつつ、強力に制限をかける」という用途に最適なツールが標準では備わっていませんでした。
既存ツールの評価
OpenAIはまず、Windowsの標準機能を検討しましたが、以下の理由で不採用となりました。
- AppContainer: 特定のアプリ用であり、複雑な開発ツール群を動かすには制限が強すぎた。
- Windows Sandbox: 使い捨ての仮想環境（VM）であるため、ホスト側の開発環境（ツールや設定）に直接アクセスできず、利便性が低かった。
- MIC（整合性レベル）: 整合性を下げるとワークスペース全体の信頼モデルが変わってしまい、他のツールとの競合リスクがあった。
開発された解決策：多層防御によるサンドボックス
OpenAIは、複数のWindowsセキュリティ機能を組み合わせた独自の仕組みを構築しました。
1. 書き込み権限の制限
「SID（セキュリティ識別子）」と「書き込み制限付きトークン」を組み合わせています。
sandbox-writeという独自の識別子を作成し、特定のディレクトリ（作業ディレクトリなど）にのみ書き込み権限を与えます。- 実行時には、Windowsが「通常のユーザー権限」と「sandbox-write権限」の両方をチェックするように設定し、許可された場所以外への変更を物理的にブロックします。
2. 強力なネットワーク制限
初期のプロトタイプでは環境変数でプロキシ設定を偽装していましたが、これでは悪意あるコードに簡単に突破されてしまいます。 最終的には、セットアップ時に管理者権限を使用して「Windowsファイアウォール」に専用のルールを追加する手法を採用しました。Codex専用のローカルユーザーを作成し、そのユーザーによる外部通信をOSレベルで完全に遮断します。
3. 実行構造の工夫
権限の切り替えを確実に行うため、3つのバイナリを使い分ける構造にしています。
- codex.exe: ユーザーが操作するメインプロセス。
- setup.exe: 管理者権限でファイアウォールやユーザー作成を行う。
- command-runner.exe: 専用ユーザーに権限を切り替え、さらに書き込み制限をかけて子プロセスを起動する仲介役。
結論
このプロジェクトの教訓は、「WindowsにはAIエージェントに最適な単一の隔離機能は存在しない」ということです。OpenAIは、既存の概念（SID、ファイアウォール、トークン、専用ユーザー）をパズルのように組み合わせることで、開発者の利便性を損なわず、かつ安全にコードを実行できる環境を実現しました。
新人エンジニアにとって、この事例は「既存のツールが要件を満たさないとき、OSの低レイヤーな機能をどう組み合わせて目的のシステムを作るか」というシステム設計の良い手本となるでしょう。
引用元: https://openai.com/index/building-codex-windows-sandbox
アメリカで開発された最新の超高性能AIモデル「クロード・ミュトス（Claude Mythos）」を、日本の3大メガバンクが業務に導入できるよう調整が進められているというニュースです。この動きは、日本の金融界におけるLLM（大規模言語モデル）活用の大きな一歩として注目されています。
「クロード・ミュトス」は非常に高い推論・処理能力を備えていますが、その強力さゆえに、悪用された場合には高度なサイバー攻撃に利用されるなどの深刻なリスクも懸念されています。そのため、政府は14日にも官民連携の作業部会を設置し、安全に運用するための対策やガイドラインの検討を開始する方針です。
新人エンジニアの皆さんがこのニュースから読み取るべきポイントは、以下の3点に集約されます。
-
エンタープライズ領域でのLLM活用が本格化 保守的とされる金融業界、しかも日本のメガバンクが最新モデルの導入に動いていることは、LLMが「試行フェーズ」から「実務に不可欠なインフラ」へと移行したことを象徴しています。今後、金融に限らずあらゆる業界の業務システムに高性能なLLMが組み込まれていくことが予想されます。
-
「攻め」の活用と「守り」のリスク管理 エンジニアにとって、最新技術の性能（何ができるか）を追求することは楽しいものですが、実社会のサービス、特に銀行のようなミッションクリティカルな場では、リスク管理（どう安全に使うか）がそれ以上に重要視されます。高度なAIを制御するためのセキュリティ技術や、入力データの機密性を守る設計思想は、今後の必須スキルとなります。
-
技術と社会・規制の関係性 本件では技術の導入と並行して、政府による対策検討（作業部会）が進んでいます。最新のテクノロジーが社会実装される際には、必ず法規制やガイドラインの整備が伴います。技術仕様だけでなく、こうした公的な指針にもアンテナを張っておくことが、プロのエンジニアとしてのキャリア形成に役立ちます。
「クロード・ミュトス」のような次世代モデルの登場は、開発の現場を大きく変える可能性を秘めています。単なる流行として捉えるのではなく、ビジネスの現場でどのように安全に、そして効果的に実装されていくのか、そのプロセスに注目していくことが重要です。
引用元: https://news.web.nhk/newsweb/na/na-k10015120661000
LLM（大規模言語モデル）の推論効率を向上させる手法として「Continuous Batching（継続的バッチ処理）」が注目されていますが、従来の実装には「CPUとGPUが交互に待機してしまう」という隠れた非効率性がありました。本記事では、この待機時間を排除し、GPUの稼働率を極限まで高める「非同期バッチ処理」の仕組みを解説しています。
推論プロセスにおいて、CPUが次のバッチの準備（リクエストの選択やKVキャッシュの更新）をしている間、GPUは計算を停止して待機します。逆にGPUが計算している間、CPUはアイドル状態になります。プロファイリングの結果、この「交互の待ち時間」によってGPUの性能の約24%が浪費されていることが分かりました。
この課題を解決する鍵が「CUDAストリーム」と「CUDAイベント」の活用です。
- CUDAストリームによる並列化: デフォルトのストリームは同期的でCPUをブロックしてしまいますが、非デフォルトのストリームを使用することで、入力転送（H2D）、計算、出力転送（D2H）を独立して管理できます。これにより、CPUはGPUに命令を投げた直後、完了を待たずに次の作業に取り掛かれます。
- CUDAイベントによる同期: ストリーム間でのデータの整合性を保つため、GPU側で「前の処理が終わるまで待機する」というマーカー（イベント）を設置します。これにより、CPUを介さずにGPU内部だけで処理の順序を制御できます。
さらに、実用化にあたっての2つの大きな障壁とその解決策も提示されています。
- データ競合の回避: CPUが次のバッチを準備する際に、GPUが現在使用中のメモリを上書きしないよう、2組のバッファを交互に使う「ダブルバッファリング」を採用しています。
- キャリーオーバー（結果の引き継ぎ）: 次のバッチの準備時点では、現在のバッチの結果（生成されたトークン）がまだ確定していません。これを解決するため、プレースホルダーと「キャリーオーバーマスク」を使用し、計算の直前にGPU上でデータを合成する手法を導入しました。
これらの最適化により、GPUの稼働率は76%から99.4%へと劇的に改善し、生成速度は約22%向上しました。この技術はHugging Faceのtransformersライブラリに既に実装されており、最新の推論エンジンを支える重要な最適化技術となっています。新人エンジニアにとっても、ハードウェアの特性を活かしたパフォーマンス改善の好例と言える内容です。
引用元: https://huggingface.co/blog/continuous_async
VOICEVOX:ずんだもん