OpenAI

AI ターミナルとして知られる Warp が 2026 年 4 月 28 日にクライアントコードのオープンソース化を発表しました。発表からわずか 1 日あまりで GitHub Star が 34,000 を突破し、本記事執筆時点（2026-04-30）では 45,000 Star 超という勢いで成長しています。 Warp は単なるターミナルから、開発者と AI エージェントが協働する Agentic Development Environment（ADE） へと進化しています。本記事ではオープンソース化の概要、ライセンス構成、内蔵エージェントと外部 CLI エージェント連携、そして OpenAI が「設立スポンサー」として参加した意味を整理します。 TL;DR Warp クライアント（Rust 製）が warpdotdev/warp でオープンソース化 ライセンスは デュアル: UI フレームワーク（warpui_core / warpui クレート）が MIT、それ以外が AGPL v3 OpenAI が設立スポンサー。新しい Agent 駆動の管理ワークフローは GPT モデルで動作 内蔵コーディングエージェントに加え、Claude Code / Codex / Gemini CLI などの外部 CLI エージェントを呼び出せる クラウドエージェント基盤 Oz が Issue トリアージから Spec 作成・実装・PR レビューまでを担う Warp とは何か — Agentic Development Environment（ADE） Warp は当初、macOS 向けに登場した Rust 製の高速・モダンなターミナルです。現在は Linux にも対応しており、リッチな UI、ブロックベースの履歴、AI コマンド補完を特徴としています。 ...

AI コーディングエージェントの設計思想において、Anthropic と OpenAI は「Harness（ハーネス）」という同じキーワードを使いながら、まったく異なる方向に進んでいます。この記事では、両社の戦略の違いを整理し、それぞれが目指す未来像を考察します。 Harness とは何か Harness（ハーネス）とは、AI エージェントが安定して動作するための「足場」や「制御環境」を指す概念です。AI モデルが単体で完璧な出力を返すことは難しいため、ツール連携・コンテキスト管理・エラーリカバリーなどの仕組みで補強する必要があります。この補強の仕組み全体を Harness と呼びます。 両社ともこの Harness の重要性を認識していますが、そのアプローチは対照的です。 OpenAI：AI が人間を置き換える「Harness Engineering」 OpenAI は Harness Engineering という概念を提唱し、2026年2月に自社の実践事例を公開しました。 実績：3人で100万行のコード OpenAI の内部実験では、わずか3人のエンジニアが Codex を使い、5ヶ月間で約100万行のコードを含む製品を開発しました。アプリケーションロジック、テスト、CI 設定、ドキュメント、オブザーバビリティ、内部ツールに至るまで、すべてのコードを Codex が生成しています。 エンジニア1人あたり1日平均3.5件の PR をマージするスループットを実現し、従来の手動開発と比較して約10倍の速度で開発が進んだと報告されています。 OpenAI Symphony：プログラマーをプロジェクトマネージャーに 2026年3月、OpenAI は Symphony をオープンソースで公開しました。Elixir/BEAM で構築されたこのフレームワークは、Linear などのイシュートラッカーと連携し、タスクを自動的に AI エージェントに割り当てて実行します。 Symphony の設計思想は明確です。プログラマーはコードを書く人ではなく、AI エージェントに仕事を指示するプロジェクトマネージャーになる、というものです。コマンドラインでの対話すら不要で、イシュートラッカー上で要件を記述すれば AI が実装を担当します。 OpenAI のメッセージは一貫しています。ソフトウェアエンジニアの仕事は「コードを書くこと」から「AI が正しく動く環境を設計すること」に変わる ということです。 Anthropic：モデルの成長に合わせて足場を外す Anthropic は、OpenAI とは異なるアプローチを取っています。モデルに足場（Harness）を提供しつつ、モデルが賢くなるにつれてその足場を外していくという戦略です。 具体例：コンテキスト管理の進化 Sonnet 4.5 の時代、モデルはコンテキストウィンドウが満杯に近づくと、タスクを急いで終わらせようとする傾向がありました。そこで Claude Code には、コンテキストが一定量を超えると自動的にリセットする特殊なロジック（Harness）が組み込まれていました。 しかし Opus 4.5 がリリースされると、モデル自体がコンテキスト管理を適切に処理できるようになり、この Harness は不要になりました。 ...

AIモデルのリリース後、時間が経つにつれてパフォーマンスが落ちた気がする——そんな経験をしたユーザーは少なくないだろう。最近、SNS上でこの「体感」に関する興味深い主張が話題になった。 「性能放血」戦略という仮説 中国のテック系アカウント「墓碑科技（mubeitech）」が2026年4月10日に投稿したツイートは、約21万回以上閲覧され、1,600件以上のいいねを集めた。 その内容はこうだ： OpenAI・Google・Anthropicは同様の戦略を採用している。新モデルのリリース初日には性能が最高（100%）に達し、その後「放血」と呼ぶ数ヶ月間の段階的な低下を経験し、最終的に約60%まで落ちる。この目的は、次世代製品リリース時に「劇的な改善」を強調するためだ。 このパターンを同氏は「放血（bloodletting）」と表現した。意図的に性能を落としておき、次世代モデルの登場時に比較対象を都合よく用意するという戦略的操作だという主張だ。 この主張の背景 同様の「体感」を持つユーザーはこれまでにも多く、特にGPT-4が登場直後より時間が経つにつれ「鈍くなった」「回答が短くなった」と感じるユーザーの声はX（Twitter）やRedditで繰り返し話題になってきた。 一方で、OpenAIは過去にGPT-4モデルへの変更内容を公開し、変化があったことを認めつつも「意図的な品質低下」は否定している。また、2023年に行われたスタンフォード大学の研究（“How Is ChatGPT’s Behavior Changing over Time?"）では、GPT-4の一部タスクで時間的な性能変動が確認されたことも報告されている。 なぜこの主張が広がるのか ユーザーの体感との一致: モデルの応答品質の変化はユーザーが実感しやすく、「意図的」という説明が腑に落ちやすい 商業的インセンティブへの不信感: 次世代モデルの販促のために旧モデルを陳腐化させるというシナリオは、ビジネス的に合理的に見える 検証困難性: APIの内部変更は外部からの完全な検証が難しく、陰謀論的な解釈が入り込みやすい 実際のところはどうなのか 「意図的な性能低下」説については、現時点で公開情報による明確な裏付けはない。ただし、以下のような要因で性能変動が起きることは事実だ： モデルの量子化・最適化: コスト削減のためにより軽量な推論方法に移行することで、一部タスクの精度が変化する 安全性フィルタリングの調整: ガイドラインの変更により、出力の傾向が変わることがある プロンプト処理の変更: 内部のシステムプロンプトや前処理ロジックの変更が応答に影響する インフラのスケーリング: 急激なユーザー増加に対応する際の一時的なサービス品質の変化 まとめ 「意図的放血戦略」は現時点では未確認の仮説だが、AIモデルの品質管理と透明性に対するユーザーの関心の高さを示している。実際、リリース初期と数ヶ月後でモデルの挙動が変わることは多くの利用者が実感しており、各社がより詳細な変更履歴を公開することで、こうした不信感を払拭できる余地はあるだろう。 AI企業の透明性とユーザーの信頼構築は、今後ますます重要な課題となっていきそうだ。

東京大学・松尾研究所の研究グループが、LLM（大規模言語モデル）に株式投資戦略を自動生成・改善させる実験を行い、その結果を人工知能学会 金融情報学研究会（SIG-FIN-036）で発表しました。8つの LLM と3種類のフィードバック条件を組み合わせた72パターンの実験から、「フィードバックの設計よりモデル選択のほうが戦略改善に大きく影響する」という知見が得られています。 研究の背景 LLM をクオンツ投資（数理モデルに基づく定量的投資手法）に活用する研究は近年急速に増えていますが、「LLM に過去の成績をどう伝えれば戦略をうまく改善できるか」というフィードバック設計の体系的な検証はほとんど行われていませんでした。本研究はこのギャップを埋めるものです。 実験フレームワーク 研究では、以下のような反復的な戦略改善ループを構築しています。 LLM に初期の投資戦略（Python コード）を生成させる 過去データでバックテスト（シミュレーション）を実行する シミュレーション結果をフィードバックとして LLM に提示する LLM が結果を分析し、戦略コードを修正する 2〜4 を繰り返して戦略を改善する 対象データ 銘柄: TOPIX 500（金融セクターを除く） 期間: 2014〜2022年の日次データ 特徴量: 株価、出来高、ファンダメンタル指標、マクロ指標など80種類 フィードバックの3条件 フィードバックに含める情報を2つの観点（情報の範囲と提示形式）で段階的に拡張し、3つの条件を比較しています。 条件 情報の範囲 提示形式 条件A 基本的な損益指標のみ テキストのみ 条件B 基本指標 + 予測精度・リスク構造の指標 テキストのみ 条件C 基本指標 + 予測精度・リスク構造の指標 テキスト + グラフ画像 使用モデル（8種・3ファミリー） GPT 系（OpenAI）: GPT-5 を含む3モデル Gemini 系（Google）: Gemini 3 Flash を含む2モデル Claude 系（Anthropic）: Claude 4.5 Sonnet を含む3モデル 主要な結果: モデルごとの「性格」が成績を左右 実験の最大の発見は、フィードバック条件の違いよりもモデルの違いがパフォーマンスに大きく影響したことです。各モデルファミリーには明確な挙動の傾向が見られました。 Claude 系: 安定的・漸進的な改善 Claude 系モデル（特に Claude 4.5 Sonnet）は、既存の戦略コードの構造を保ちつつ局所的な修正を積み上げる傾向がありました。この「コツコツ型」のアプローチが安定的な改善につながり、最終的なパフォーマンスでも優れた結果を示しています。 ...

Check Point Research が、ChatGPT のコード実行ランタイム（Python Data Analysis 環境）に隠れた外部通信チャネルが存在することを発見しました。この脆弱性を悪用すると、ユーザーの会話内容やアップロードしたファイルが外部サーバーに漏洩する可能性がありました。OpenAI は 2026年2月20日に修正を完了しています。 脆弱性の概要 ChatGPT の Data Analysis 機能（旧 Code Interpreter）は、Python コードを実行するためのサンドボックス環境を提供しています。この環境は外部への直接的なネットワークアクセスを遮断するよう設計されていましたが、DNS 名前解決の機能は通常のオペレーションとして残されていました。 攻撃者はこの DNS 解決機能を悪用し、DNS トンネリングと呼ばれる手法でデータを外部に送信することが可能でした。 DNS トンネリングの仕組み DNS トンネリングとは、DNS クエリのサブドメイン部分にデータをエンコードして埋め込み、DNS の名前解決プロセスを通じてデータを送信する手法です。 1 2 3 4 5 # 通常の DNS クエリ example.com → IPアドレスを返す # DNS トンネリング <エンコードされたデータ>.attacker-controlled.com → 攻撃者のDNSサーバーがデータを受信 ChatGPT のコード実行環境では、DNS 解決が正常なオペレーションの一部として許可されていたため、この通信は外部へのデータ転送として認識されず、ユーザーへの警告も表示されませんでした。 攻撃シナリオ 悪意のあるプロンプトインジェクション 単一のプロンプトで隠れた漏洩チャネルを起動できます。「生産性向上ハック」や「プレミアム機能のアンロック」を謳う一見無害なプロンプトとして流通する可能性がありました。 ...

AI エンジニアリングの中心概念が急速に変化している。2022年の「Prompt Engineering」から2025年の「Context Engineering」を経て、2026年は「Harness Engineering」の年になった。Anthropic、OpenAI、そして Martin Fowler まで、業界のキープレイヤーが揃ってこの概念を公式に取り上げている。 3つの時代: プロンプトからハーネスへ Prompt Engineering（2022〜） ChatGPT の登場とともに広まった最初のパラダイム。LLM に対してどんな言葉で指示するかが品質を左右する、という考え方だ。Few-shot、Chain-of-Thought、Role Prompting といったテクニックが次々と開発された。 焦点は「1回のリクエストにおける入力テキストの最適化」にあった。 Context Engineering（2025〜） 2025年中盤、Shopify CEO の Tobi Lutke が X への投稿をきっかけに「Context Engineering」という用語が急速に広まった。LangChain や Anthropic も相次いで解説記事を公開し、業界標準の概念として定着した。 Prompt Engineering が「何を言うか」に注目していたのに対し、Context Engineering は**「LLM に何を見せるか」を動的に制御するシステム**を設計する。RAG（Retrieval-Augmented Generation）、ツール呼び出し、メモリ管理など、LLM の入力コンテキスト全体をエンジニアリングの対象とする発想だ。 Harness Engineering（2026〜） 2026年に入り、AI エージェントの実用化が本格化するなかで、Context Engineering をさらに拡張した「Harness Engineering」が登場した。 Context Engineering が「LLM に何を見せるか」を扱うのに対し、Harness Engineering はエージェントの実行環境全体 —— 役割分担、フィードバックループ、品質検証、セッション管理まで含めた制御構造を設計する。 「ハーネス（harness）」は馬具の意味で、強力な馬（= AI モデル）を制御し、安定した成果を引き出すための仕組み全体を指す。 業界キープレイヤーの動き OpenAI: Codex チームの実践（2026年2月） OpenAI は2026年2月、公式ブログで「Harness engineering: leveraging Codex in an agent-first world」を公開した。 ...

音声の文字起こし（トランスクリプション）は AI の実用的な応用の一つだが、長時間の音声ファイルを処理するには時間がかかる。insanely-fast-whisper は、OpenAI の Whisper モデルを Flash Attention 2 とバッチ処理で高速化し、150分の音声をわずか98秒で文字起こしできる CLI ツールだ。 概要 insanely-fast-whisper は、Hugging Face の Transformers、Optimum、flash-attn を組み合わせた文字起こし CLI だ。2026年3月時点で GitHub スター 11,000 以上を獲得しており、コミュニティ主導で開発が進んでいる。 主な特徴: 高速処理: Nvidia A100 GPU で 150分の音声を約98秒で文字起こし 簡単なインストール: pipx install でワンコマンド導入 複数モデル対応: Whisper large-v3、distil-whisper など Mac 対応: Apple Silicon (MPS) でも動作 翻訳機能: 文字起こしだけでなく、英語への翻訳も可能 ベンチマーク Nvidia A100 (80GB) での 150分音声の処理時間比較: 構成 処理時間 large-v3 (fp32) 約31分 large-v3 (fp16 + batching + BetterTransformer) 約5分 large-v3 (fp16 + batching + Flash Attention 2) 約1分38秒 distil-large-v2 (fp16 + batching + BetterTransformer) 約3分16秒 distil-large-v2 (fp16 + batching + Flash Attention 2) 約1分18秒 large-v2 (Faster Whisper, fp16) 約9分23秒 Flash Attention 2 の効果が顕著で、BetterTransformer と比較しても約2.5〜3倍の高速化を実現している。 ...

OpenAI初期メンバーであるAndrej Karpathyが、autoresearchというオープンソースツールを公開しました。わずか630行のPythonスクリプトで、寝ている間にAIエージェントが約100の機械学習実験を自律的に実行してくれるというものです。 Karpathy「12月からコードを1行も書いていない」 Karpathyは「12月から自分でコードを1行も書いていない」と告白しています。代わりに公開したのがこのautoresearchで、プログラマーの仕事が「コードを書く」から「設計する」へとシフトしていることを象徴しています。 autoresearchの仕組み autoresearchはシンプルな仕組みで動作します: AIエージェントにトレーニングスクリプトと固定の計算バジェット（通常5分間のGPU時間）を渡す エージェントが自分のソースコードを読み、改善の仮説を立てる コードを修正し、実験を実行する 結果が改善されたかを評価し、改善なら保持・悪化なら破棄する このサイクルを繰り返す トレーニングは常に5分間で実行されるため、1時間あたり約12実験、一晩で約100実験が自動的に回ります。 実績と反響 Shopify CEO Tobias Lütke: 一晩で37実験を実行し、性能19%向上を達成 Karpathy自身: 700以上の実験を2日間で実行（Fortune誌報道） GitHub: 公開1週間で数万スターを獲得（現在54,000以上） 技術的特徴 シングルGPU対応: 高価なクラスタは不要 630行のスクリプト: コードベースが小さく、理解・カスタマイズが容易 MITライセンス: 誰でも自由に利用可能 Python製: train.py を中心としたシンプルな構成 リポジトリ GitHub: karpathy/autoresearch 「書く」から「設計する」への転換 autoresearchが示唆しているのは、世界最高峰のプログラマーの仕事が「AIにコードを書かせる」段階をすでに超え、AIエージェントに実験を設計・実行させるフェーズに入っているということです。Karpathyは将来的に、エージェント群が協調して小さなモデルをチューニングし、有望なアイデアを段階的にスケールアップさせる「研究コミュニティのエミュレーション」を構想しています。

OpenClaw を使っていて API コストが気になっていませんか？ ClawRouter は、リクエストごとに最安のモデルを自動選択してくれるオープンソースの LLM ルーターです。最大約92%のコスト削減が期待でき、しかも完全無料で利用できます。 ClawRouter とは ClawRouter は、OpenClaw 向けに設計されたエージェントネイティブな LLM ルーターです。MIT ライセンスで公開されており、誰でも無料で利用できます。 主な特徴: 55以上のモデルに対応 — DeepSeek V3.2、Nemotron Ultra 253B、Mistral Large 3 675B、Llama 4 Maverick など 1ms 未満のルーティング — すべてローカルで処理されるため、レイテンシの追加はほぼゼロ 15次元のリクエスト分析 — 各リクエストを多次元で要素分解し、最適なモデルをスコアリング 11モデルが完全無料 — 簡単なクエリは無料モデルに自動ルーティング どれくらいコストが下がるのか ClawRouter の公式ベンチマークによると: 指標 値 ClawRouter 平均コスト $2.05 / 100万トークン Claude Opus 直接利用 $25 / 100万トークン 削減率 約92% たとえば「2+2は？」のような簡単な質問は、DeepSeek などの無料モデルに自動ルーティングされます。一方、複雑な推論が必要なタスクにはプレミアムモデルが選択されるため、品質を犠牲にしません。 仕組み ClawRouter は各リクエストに対して以下のプロセスを実行します: リクエスト分析 — 入力テキストを15次元で要素分解（タスクの複雑さ、必要な推論能力、言語、コンテキスト長など） スコアリング — 各モデルの能力とコストを総合的に評価 ルーティング — 最もコスト効率の良いモデルを自動選択 この全プロセスが 1ms 未満で完了します。 ...

AI コーディングエージェントの二大巨頭、Anthropic の Claude Code と OpenAI の Codex。どちらを使うべきか迷っている開発者は多いでしょう。Hesam 氏（@Hesamation）が数ヶ月間の実用比較を経て「Claude Code に戻った」という記事が話題になっています。本記事では、両ツールのベンチマーク・アーキテクチャ・実用上の使い分けを整理します。 ベンチマーク比較 SWE-bench Pro（ソフトウェアエンジニアリングタスク） モデル スコア Claude Opus 4.6 59.0% GPT-5.3-Codex 56.8% 複雑なソフトウェアエンジニアリングタスクでは Claude Opus 4.6 がリードしています。 Terminal-Bench 2.0（ターミナル操作タスク） モデル スコア GPT-5.3-Codex 77.3% Claude Opus 4.6 65.4% 一方、CLI 操作や CI/CD 関連のタスクでは Codex が強さを発揮します。 アーキテクチャの違い コンテキストウィンドウ Claude Code: 100万トークン（ベータ） Codex: 40万トークン Claude Code は 2.5 倍のコンテキストウィンドウを持ち、大規模なコードベースの横断的な分析に強みがあります。 実行速度 Codex: Cerebras WSE-3 で 1,000+ トークン/秒 Claude Code: 約 200 トークン/秒（標準推論） 速度面では Codex が圧倒的です。ただし、Claude Code はトークン消費量が 3.2〜4.2 倍多い傾向にあり、同じタスクでもより多くの推論を行っている可能性があります。 ...