OpenAI

複数の AI コーディングエージェントを使い分けるのは手間がかかる。その課題を解決するのが oh-my-openagent（omo） だ。Claude Code・OpenAI Codex・Gemini CLI といった主要エージェントを一元管理し、タスクに応じて最適なモデルへ自動ルーティングするオープンソースのハーネスで、GitHub スター数は 5.7 万超（2026 年 5 月時点）に達している。 oh-my-openagent とは oh-my-openagent は、もともと oh-my-opencode という名称で 2025 年 12 月に登場し、その後マルチエージェント対応を強化するかたちでリブランドされたツールだ。 作者: code-yeongyu 言語: TypeScript ライセンス: SUL-1.0 公式サイト: ohmyopenagent.com キャッチフレーズは「the best agent harness」。単一のエージェントに何でも任せるのではなく、専門化されたエージェント群がタスクを分担し、並列実行することで開発速度と品質を両立させる設計思想を持つ。 対応エージェントとプロバイダー oh-my-openagent は以下のエージェント・モデルプロバイダーに対応している。 プロバイダー 主なモデル Anthropic Claude Code（claude-opus-4-6 / 4-7 等） OpenAI Codex、GPT-5.5 Google Gemini CLI GitHub Copilot その他 Kimi K2、DeepSeek V4 等 インストール時に利用中のサブスクリプションプラン（Claude Pro/Max、ChatGPT Plus など）を選択することで、利用可能なプロバイダーのみを有効化できる。 主要機能 マルチモデルオーケストレーション タスクの種類ごとに最適なモデルを自動選択する「カテゴリベースのモデル割り当て」が核心機能だ。 visual-engineering（フロントエンド・UI 実装）→ Gemini ultrabrain（高難度なアーキテクチャ設計）→ Claude Opus 4.7 artistry（クリエイティブな文章生成）→ GPT-5.5 deep（深い推論・リサーチ）→ Claude Opus / Kimi K2 コスト最適化の観点から、大量ファイル生成のような作業は DeepSeek V4-Flash などの安価なモデルに自動振り分けされる。 ...

AI を使っていて「最近 ChatGPT や Claude が急に使いにくくなった」と感じたことはないだろうか。中国の AI コミュニティで話題になった阿绒 AYi（@AYi_AInotes）が、この感覚の正体を鮮やかに考察している。本記事はその考察をもとに筆者が整理したものだ。 公式ガイドラインが相次いで公開された 2026年4月、Anthropic が Claude Opus 4.7（4月16日）、OpenAI が GPT-5.5（4月23日）のリリースに合わせ、それぞれ公式のプロンプトエンジニアリングガイドラインを公開した。モデルが「バカになった」わけではない。むしろ賢くなりすぎた結果、曖昧な指示への耐性がなくなったのだ。 面白いのは、2つのモデルの進化の方向性が完全に真逆だという点だ。 Claude は「字義通り」に、GPT は「自律的」に Claude Opus 4.7 の変化 Claude は以前、曖昧な指示を受けると自分でいい感じに補完してくれていた。「なんとなくこんな感じで」という指示でも、文脈を読んで意図を推測し、それなりの出力を返してくれた。 今の Claude は違う。あなたが言ったことをそのまま実行する。推測も補完もしない。「一文字も余計に解釈しない」スタイルに変わっている。 GPT-5.5 の変化 GPT はかつて、ステップバイステップで丁寧に教えないとうまく動かなかった。「まず A をして、次に B をして、最後に C を確認して」という細かい手順指示が必要だった。 今の GPT は自律的だ。「こういう結果が欲しい」と伝えるだけで、最適なアプローチを自分で選ぶ。手取り足取り教える必要がなくなった。 古いプロンプトが失敗する理由も真逆 この進化の方向性が真逆なので、古いプロンプトが失敗する理由も正反対になる。 モデル 失敗するプロンプト 失敗の理由 Claude 曖昧・ふんわりした指示 字義通りに解釈するため、意図とかけ離れた出力になる GPT 細かすぎる手順指示 自律的に判断するため、冗長な手順が逆にノイズになる Claude に「いい感じで頼む」と言えば言うほど出力がおかしくなる。GPT に「まず○○して、次に□□して」と細かく指示するほどかえってうまくいかない。 プロンプトエンジニアリングの本質が変わった ChatGPT が広く普及した2023年以来の約3年間、私たちは「モデルにどう教えるか」を学んできた。どう指示すれば動くか、どう補足すれば正確になるか。 いまや立場が逆転している。モデルが私たちに「先に自分の考えを構造化してくれ」と求めている。 これはプロンプトエンジニアリングの本質そのものだ。「モデルにどうやって動かすかを教える技術」から、**「自分が何を本当に求めているかを先に明確にする技術」**へと変わった。 本当のボトルネックは、モデルの能力ではなく、プロンプトを書く人の「思考の明確さ」かもしれない。 勝者は「最も明確に考えられる人」 最も長く複雑なプロンプトを書ける人が勝つ時代は終わった。 これから重要なのは、自分が本当に何を求めているのかを最も明確に理解している人だ。 モデルへの指示を洗練させることに時間をかけるより、自分の思考を整理する時間をかける価値が出てきている。プロンプトエンジニアリングは、AIを操る技術というよりも、思考を言語化する技術に近づいている。

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 コマンド補完を特徴としています。 ...

2026年4月28日、Rust 製 AI ターミナル Warp がそのクライアントコードを GitHub 上でオープンソース化した。公開から1日強で GitHub スターが 31,900 件を超え、サーバーが過負荷になるほどの反響を呼んだ。 Warp とは何か Warp は「ターミナルから生まれたエージェンティック開発環境」を標榜するツールだ。Rust で書かれており、AI によるコマンド補完・エラー診断・エージェント実行を統合した AI 統合ターミナルとして、700,000 人以上のアクティブ開発者が利用している。 公開リポジトリ: github.com/warpdotdev/warp（AGPL-3.0 ライセンス） Oz — AI エージェントのオーケストレーション基盤 Warp のオープンソース化で最も注目すべきは、コードの公開そのものより、背後にある開発協働モデルだ。Warp は Oz と呼ばれる AI エージェント・オーケストレーションプラットフォームを導入しており、コントリビューションのワークフロー自体を AI エージェントが担う設計になっている。 Oz エージェントが自動で行う作業: コードの実装・修正 テストの実行と検証 コードレビュー 技術ドキュメントの生成 build.warp.dev では、数百体の AI エージェントがリアルタイムでコードを書き、バグを修正し、Issue を処理する様子をライブで見ることができる。 Warp 公式ブログによれば、多様なアイデアを持つコントリビューターと、構造化されたプロセスを持つ Oz エージェントと、豊富なコンテキストと自己改善ループが組み合わさることで、社内だけでは作れない「魔法のようなプロダクト」が生まれると言う。 AI 時代の OSS 開発における人間の役割 このモデルが示唆するのは、オープンソース開発における人間の役割の根本的な変化だ。従来は「熱意ある開発者が週末に肝コードを書く」ことでオープンソースは成り立っていた。Warp の目指す姿はこうだ: アイデアを提案し、品質を管理し、最終方向を決めるのが人間。 コーディング・テスト・ドキュメント生成は Oz エージェントが担う。 Oz は OpenAI がファウンディングスポンサーを務めるプラットフォームで、デフォルトで OpenAI のモデルを利用する。他のコーディングエージェントの利用も自由だが、Oz を使うことで検証ループや必要なスキルが最初から組み込まれているメリットがある。 ビジネスモデル面では、ターミナルクライアントは AGPL-3.0 でオープンソースだが、Oz やサーバーコンポーネントはプロプライエタリで、月額 $12 の Pro プランを中心に収益化している。 ...

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倍の高速化を実現している。 ...