AIコーディング

主要ニュース

1. 1

   Disney、GitHub Copilotを廃止しOpenAIのCodexを採用

   Disneyは8月、米国においてMicrosoftのGitHub CopilotおよびアマゾンのAIコーディングツール2つ（KiroとQ）の利用を停止し、OpenAIのCodexを採用する。同社はAnthropicのClaude EnterpriseとCursorへのアクセスは継続する。 Disney の技術者8人がBusiness Insiderに対し、GitHub Copilotをほとんど、またはまったく使用していなかったと述べた。1人は「不必要に複雑な」コードが生成されるため後処理が必要だと指摘し、別の社員は「使用がないため利用が途絶えていた」とコメント。この転換はCopilotが ChatGPT や Claude などの競合製品との競争で採用に苦戦していることを反映しており、大手エンタープライズ顧客の間でどのツールが勝利しているかを示唆している。

   OpenAI の Codex が Disney で採用される準備が進められているが、導入の時期は明示されていない。Claude と Cursor は Disney のスタッフの間で支配的なツールとなっており、ある高位のエンジニアは利用状況について「コーディング時のターミナル利用は Claude がおそらく80%程度」とコメントしている。

2. 2

   6つのLLMデプロイメント形式を比較：速度対ハードウェア柔軟性

   本番環境でのLLMデプロイメント形式6つ—Pickle、safetensors、GGUF、ONNX、MLX、TensorRT—の技術的な内訳。各形式は推論速度とハードウェア互換性の異なるトレードオフを持つ。PickleとsafetensorsはPythonが実行できる場所ならどこでも動作。GGUFは重みとトークナイザーを束ね、CPUのみのマシンで実行可能。ONNXはモデルがフレームワーク間で切り替え可能。MLXはAppleシリコンに最適化。TensorRTは特定のNVIDIA GPUにコンパイルされ最大速度を実現。 より高速なモデルを実現するには、ハードウェア固有の選択肢をファイルに組み込む必要があり、1つのモデルをサポート対象のチップやランタイムごとに個別に再構築しなければならない。チームは速度対互換性のトレードオフにおいてどこまで最適化するかを選択する必要があり、推論レイテンシと本番環境で実際に実行できるハードウェアの種類とのバランスを取らなければならない。

   記事は、レイテンシ予算が許す限りデプロイメント形式を速度互換性チャートの高い位置に保つことの重要性を強調している。高速実行に向かう1段階ごとに、それを実行できるハードウェアの範囲は狭まるためだ。LLMをデプロイするチームは、応答時間の最小化と移植性の最大化という絶え間ないトレードオフに直面している。

3. 3

   Sitrep: インシデント対応向けAIコパイロット、Grafanaと連携

   開発者がSitrepというメニューバーアプリを構築した。インシデント発生時に約15秒ごとにスクリーンショットを撮影し、Claude visionを使って各フレームを構造化された観察データに変換し、「5分前に見たトレースIDは何だったか」といった質問をAIコパイロットに投げかけられる。その後、実際のトレースをGrafana Tempoから引き出して、時間がどこに費やされたかを表示する。 インシデント対応中、エンジニアは複数のウィンドウ（トレースID、エラーパネル、メトリクスの急上昇、Slackメッセージなど）に散在する数百の一時的な情報を目にするが、コンテキスト切り替え時にほとんどが失われる。Sitrepはこれらを自動的にキャプチャしてインデックス化し、スクリーン履歴を検索したり観察結果とバックエンドトレースを相関させたりできる。スクリーン権限やAPIキーは不要で、ローカルでモックモードでも実行可能。

   このアプリはHacker Newsでオープンソース化されている。macOS上で動作し（Node ≥20が必要）、Grafanaのデータソースプロキシ経由で統合される（TempoはTraceQL、メトリクスはPromQL）。OpenTelemetry GenAI規約で計測されており、コパイロット自身のLLMコールも、デバッグ対象と同じGrafanaインスタンス内で可視化される。