Warp がオープンソース化 — ターミナルから生まれた Agentic Development Environment(ADE)の全貌

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月30日 · 6 分

90%のAI Agentの記憶は偽物?Markdownダンプが崩壊する理由とMem0・GraphRAGによる設計

「現在の90%のAI Agentの記憶は偽物だ」——AI研究者 @AYi_AInotes がXでこう発言し、大きな反響を呼んでいる。 多くの開発者が同じ罠にはまっている。「会話履歴や決定ログをMarkdownファイルに溜め込めば長期記憶になる」という誤解だ。 この記事では、なぜMarkdownダンプが「記憶」ではないのか、4つの根本的欠陥と2026年時点で実用可能なグラフ×埋め込みベースの代替設計を解説する。 Markdownファイルへの履歴ダンプが崩壊するまで @AYi_AInotes 自身の失敗談がわかりやすい。失敗は次の順序で進んだ。 全ての会話履歴・決定ログをMarkdownファイルに蓄積 「これで長期記憶が実現できた」と信じる 2週間で崩壊 崩壊の具体的な症状: 同一事実に3つの矛盾バージョンが存在する — 上書きも検証もなく書き足し続けた結果 先月の好みと昨日の重みが同等に扱われる — 時系列の概念がない 毎回全コンテキストを詰め込む — 遅延増大、コンテキスト汚染(クロストーク)が頻発 Markdownベース記憶の4つの根本的欠陥 1. 重複排除がない(No Deduplication) 同じ情報が何度も書き込まれ、どれが最新・正確かわからなくなる。矛盾する記述が増え続け、Agentが混乱する。 2. セマンティック検索ができない(No Semantic Retrieval) キーワードマッチしか使えず、関連情報を文脈で引き出せない。「先月の判断」と「今月の判断」の関係性が見えない。 3. 時系列優先度がない(No Temporal Weighting) 古い情報と新しい情報が同等に扱われる。ユーザーの好みが変化しても、Agentは古い情報に引きずられる。 4. エンティティ間の関係を持てない(No Relationship Modeling) 「AとBは関係がある」「Cの前提はDである」という構造を表現できない。フラットなテキストでは知識の構造化が不可能。 PromptをRAMとして使うことの問題 Markdownダンプを人間の記憶に例えると: 脳に情報を定着させるのではなく、ノートに書いて毎回全文を読み返すようなもの ノートが増えるほど読み返す時間が増え、矛盾も増える これは記憶ではなく、外部ストレージへの都度参照だ 本物の記憶は: 関連情報を索引化して素早く引き出せる 同じ情報を重複して持たない(圧縮・統合) 時間の経過とともに重要度が変化する 事実間の関係性を持つ Markdownダンプはこれを一切満たさない。PromptをRAMとして使っているだけだ。 本物の記憶 = グラフ + ベクトル埋め込み + トラバーサル 本物の記憶の設計原則は3つのコンポーネントで構成される: グラフ(Graph) 知識をノードとエッジで構造化する。エンティティ(人、概念、出来事)をノードとして、その関係をエッジとして保存する。「AはBを好む」「CはDに依存する」という関係が明示的に管理できる。 埋め込み(Embeddings) 各ノードをベクトルに変換することで、意味的に近い情報を検索できる。「先週の決定」と「今週の状況」の意味的類似性を計算し、関連する記憶だけを取り出せる。 トラバーサル(Traversal) グラフを辿ることで、直接リンクされていない関連情報も発見できる。「ユーザーの好みA → 関連する行動B → 影響を受けた決定C」という連鎖をたどれる。 ...

2026年4月27日 · 5 分

ANOLISA

概要 Alibaba が 2026 年 3 月に公開した Agentic OS プロジェクト。正式名称は ANOLISA(Agentic Nexus Operating Layer & Interface System Architecture)。同社が保守する Anolis OS を AI Agent 実行基盤として再構築したもので、権限・観測・スキル管理を OS 層で解決する。Apache 2.0 ライセンス。 リポジトリ: alibaba/anolisa ホームページ: agentic-os.sh 主言語: TypeScript(Copilot Shell)/ Rust(AgentSight)/ C(eBPF プローブ) 4 コンポーネント Component 役割 Copilot Shell(cosh) Qwen Code ベースの AI ターミナル UI。Multi-Provider・PTY・Skill/Hooks System 対応 Agent Sec Core OS 層セキュリティカーネル。最小権限・明示的認可・ゼロトラスト・多層防御・Security Over Execution の 5 原則 AgentSight eBPF ベースのゼロ侵襲 Agent オブザーバビリティ。LLM API コール・トークン消費・SSL/TLS トラフィックをカーネル側から観測 OS Skills 運用スキルの標準ライブラリ。RPM で /usr/share/anolisa/skills/ に展開 Agent Sec Core のセキュリティモデル Agent 実行のたびに 3 フェーズのチェックが強制される: ...

2026年4月23日 · 1 分

ANOLISA とは — Alibaba が公開した AI Agent 向け Linux OS(Copilot Shell / Agent Sec Core / AgentSight / OS Skills)

2026 年 3 月末、Alibaba は alibaba/anolisa を公開しました。これは同社が保守するサーバー向け Linux ディストリビューション Anolis OS を AI Agent 実行基盤として再構築した「Agentic OS」プロジェクトで、正式名称は ANOLISA(Agentic Nexus Operating Layer & Interface System Architecture)です。 本記事では、ANOLISA が解こうとしている問題と、公開されている 4 つのコアコンポーネント(Copilot Shell / Agent Sec Core / AgentSight / OS Skills)の役割、そして開発者が今すぐ触れられる導入手順を整理します。 ANOLISA が目指すもの ANOLISA は Anolis OS の「Agentic 進化版」と位置づけられており、AI Agent ワークロードをサーバー側で安全かつ観測可能な形で動かすためのベストプラクティス実装を狙っています。LLM / Agent がコード編集・シェル実行・ネットワークアクセス・プロセス管理といった OS レベルの操作を当たり前に行う時代において、「アプリケーション境界で守る」従来型セキュリティでは不十分になってきました。ANOLISA はその問題意識を背景に設計されています。 リポジトリ: alibaba/anolisa ホームページ: agentic-os.sh ライセンス: Apache License 2.0 主言語: TypeScript(Copilot Shell)/ Rust(AgentSight)/ C(eBPF プローブ) 公開: 2026 年 3 月 30 日(初版リポジトリ作成) 4 つのコンポーネント ANOLISA は単一のカーネルモジュールではなく、Agent 実行に必要な「シェル・セキュリティ・観測・スキル」を別々のプロダクトとして分離し、RPM で同居運用する構成を取っています。 ...

2026年4月21日 · 4 分

Infisical — .env に別れを告げるオープンソース・シークレット管理プラットフォーム

.env よ、安らかに眠れ——。 AI 時代の開発現場では、シークレット(API キー・データベースパスワード・証明書など)の扱い方が大きな課題になっています。従来は .env ファイルに書いておけばなんとかなっていました。しかしチーム規模が拡大したり、AI エージェントが複数のサービスを横断して動くようになると、.env ベースの管理はほころびを見せてきます。 Infisical は、そんな .env の時代を終わらせるべく登場したオープンソースのシークレット管理プラットフォームです。 .env の何が問題なのか .env ファイルによるシークレット管理には以下のような問題があります。 ディスクに残る: 誤って git add .env してしまうリスクが常に存在する 同期が難しい: 複数人・複数環境での値の一元管理が困難 ローテーションが手動: シークレットを更新するたびに全メンバーへの周知が必要 監査ログがない: いつ誰がどの値を変更したか追跡できない AI エージェントとの相性が悪い: エージェントが環境変数ファイルを読み書きすると漏洩リスクが増大する Infisical とは Infisical は、シークレット・証明書・特権アクセスを一元管理するオープンソースプラットフォームです。2026年4月時点で GitHub 26,000 スター超を獲得しており、Vault の OSS 代替として注目されています。 最大の特徴は、シークレットをランタイム時に取得する設計にあります。.env ファイルのようにディスクに値を保存しないため、ファイルベースの漏洩リスクを根本から排除します。 主な機能 シークレット管理 プロジェクト・環境(dev / staging / prod)ごとのシークレット管理 シークレットのバージョン履歴と自動ローテーション 変更の監査ログ シークレット参照(他のシークレットの値を参照する変数展開) 証明書管理(PKI) プライベート CA の構築と証明書の発行 ACME プロトコル対応で Let’s Encrypt 互換のワークフロー 証明書の有効期限監視と自動更新 統合機能 CLI: あらゆる言語・フレームワークのコマンドをシークレット付きで実行 SDK: Node.js、Python、Go、Java など主要言語のネイティブ SDK インフラ統合: Kubernetes、GitHub Actions、AWS、GCP、Azure など 基本的な使い方 インストール 1 2 3 4 5 # macOS (Homebrew) brew install infisical/get-cli/infisical # npm npm install -g @infisical/cli ログインとプロジェクト初期化 1 2 3 4 5 # Infisical にログイン infisical login # プロジェクトに紐付け infisical init シークレットを注入してコマンドを実行 1 2 3 4 5 # .env の代わりに Infisical からシークレットを取得してアプリを起動 infisical run -- node app.js # 環境を指定 infisical run --env=staging -- python manage.py runserver SDK から直接取得(Node.js の例) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 import { InfisicalSDK } from "@infisical/sdk"; const client = new InfisicalSDK(); await client.auth().universalAuth.login({ clientId: process.env.INFISICAL_CLIENT_ID, clientSecret: process.env.INFISICAL_CLIENT_SECRET, }); const secret = await client.secrets().getSecret({ secretName: "DATABASE_URL", projectId: "my-project-id", environment: "production", }); AI 時代のシークレット管理 AI エージェントや MCP サーバーが普及した今、シークレット管理の重要性はさらに高まっています。 ...

2026年4月21日 · 2 分

RAGなしでも高精度に動くAgent Harnessの秘密 — コンテキストサイズと「100ファイル」の目安

Claude CodeやCodexのようなAgent Harnessは、RAG(Retrieval-Augmented Generation)をほとんど使わないにもかかわらず、高精度なコード生成や理解を実現している。一方、RAGに依存しすぎたAgentはハルシネーションを起こしやすいという逆説がある。なぜこのような違いが生まれるのか?Software Engineer兼Database ResearcherのTaro L. Saito(@taroleo)氏のポストが、その本質を簡潔に説明している。 コンテキストウィンドウの拡大がRAGの必要性を変えた 現行のAIモデルのコンテキストサイズは20k〜1Mトークンに達している。これは、目安としておよそ100ファイル以下のコードベースであれば、RAGを介さずそのままコンテキストに収めて処理できることを意味する。 モデル コンテキストサイズ GPT-4o 128k tokens Claude Sonnet 4.x 200k tokens Gemini 1.5 Pro 1M tokens Claude CodeやCodexなどのAgent Harnessは、この大きなコンテキストウィンドウを活かして、必要なファイルを直接読み込みながらタスクを実行する。ベクトル検索による「関連しそうな断片」の取得ではなく、「実際に必要なコード全体」を参照できる。 RAGの弱点:断片的な情報がハルシネーションを生む RAGは「大量の文書から関連部分を検索して取得する」ことで、LLMに外部知識を与える仕組みだ。ドキュメント検索や広範な知識ベースへのアクセスには有効だが、コードベースのような相互依存が強い構造的情報に対しては課題がある。 RAG特有の問題点: 断片的なコンテキスト: ベクトル類似度で取得したチャンクは、実際の依存関係を無視している場合がある 欠落した情報: 関連するが類似度スコアが低いコードが検索から漏れる 矛盾した断片: 異なるバージョンや関連する別モジュールの断片が混在する こうした不完全な情報でコードを生成させると、存在しない関数を呼び出したり、実際のインターフェースと合わない実装を生成したりするハルシネーションが発生しやすい。 Agent Harnessが「100ファイル以下」で高精度な理由 Claude CodeのようなAgent Harnessが高精度に動く理由は、コンテキストウィンドウの有効活用にある。 プロジェクト構造の把握(ls、find など) 関連ファイルの直接読み込み(cat、read) 完全なコンテキストを持った上でコード生成・編集 RAGのように「類似チャンク」を取得するのではなく、ツールを使って必要なファイルを選択的に読み込むというアプローチだ。ファイル数が100程度であれば、現行のコンテキストサイズに収まるため、コードベース全体を「見た上で」タスクを実行できる。 これにより: 実際に存在する関数・型・インターフェースのみを参照する インポート関係や依存構造を正確に把握する プロジェクト固有の命名規則や設計パターンに従う ベクトル検索が有効なケースと直接読み込みが有効なケース NTT DATAのエンジニアリングブログ「ベクトル検索は不要なのか?」では、生成AI時代にRAGやベクトル検索をどう捉えるべきかを整理している。Taro氏のポストはこの記事を引用しており、「100ファイル以下という目安」はコンテキストサイズとトークン換算から導き出せる経験則だ。 ベクトル検索が有効なケース: 100ファイルを超える大規模コードベース(モノレポ、大企業の内部リポジトリ) 広範なドキュメント検索(社内ナレッジベース、技術文書) リアルタイム情報の取得(外部ドキュメント、最新の仕様) コンテキストに収まる場合に直接読み込みが有効なケース: 中小規模のプロジェクト(スタートアップのコードベース、個人プロジェクト) 特定モジュールへの集中作業 正確な依存関係の把握が必要な場合 RAG自体を強化する方向: GraphRAG という選択肢 「RAGを捨てて直接読み込み」ではなく、「RAGの断片性を補う」方向の研究もある。代表的なのがMicrosoft Researchが2024年に発表した GraphRAG だ。 GraphRAGの基本アイデアは次の通り: ...

2026年4月17日 · 1 分

Claude Managed Agents

概要 2026年4月8日に Anthropic がパブリックベータ公開した、AI エージェントの構築・デプロイ・運用に必要なインフラを一括提供する API スイート。開発者はモデル、システムプロンプト、ツール、MCP サーバーを定義するだけで、本番レベルのエージェントを稼働させられる。 主な機能 機能 説明 セキュアなサンドボックス エージェントの実行環境を安全に分離 長時間実行セッション 数時間にわたるタスクも途中状態を維持 永続的な状態管理 コンテキストウィンドウ外にセッションログを保持 マルチエージェント連携 複数エージェントのフリート管理 MCP 統合 HubSpot などの外部サービスと即座に連携可能 料金は API 従量課金に加えてセッション時間あたり $0.08。 アーキテクチャ:Brain / Session / Hands Claude Managed Agents は OS の抽象化パターンにならい、3つのコンポーネントを分離したメタハーネス設計を採用している。 Brain(ステートレスなハーネス + Claude) Agent Harness と Claude(LLM 推論)で構成 ステートレスなため、クラッシュしても wake(sessionId) で復旧可能 プロンプトキャッシュ、コンパクション、コンテキストエンジニアリングを担当 TTFT(最初のトークンまでの時間)を p50 で約60%、p95 で90%以上改善 Session(永続コンテキスト) コンテキストウィンドウの外に存在する append-only のイベントログ getEvents() インターフェースでイベントストリームの任意スライスを取得可能 長時間タスクでもコンテキストを回復可能な形で保存 Hands(使い捨て可能なサンドボックス + ツール) Brain から execute(name, input) → string で呼び出される統一インターフェース コンテナが落ちても Brain やセッションに波及しない障害分離 認証情報はサンドボックス内から到達不可能(プロンプトインジェクション対策) API の基本フロー 1 2 3 4 5 POST /v1/agents # Agent 定義 POST /v1/environments # コンテナテンプレート POST /v1/sessions # セッション開始 POST /v1/sessions/{id}/events # イベント送信 GET /v1/sessions/{id}/stream # SSE でレスポンス受信 ベータヘッダー managed-agents-2026-04-01 が必要。 ...

2026年4月14日 · 1 分

Anthropic vs OpenAI:Coding Agent の Harness 戦略はなぜ真逆なのか

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 は不要になりました。 ...

2026年4月13日 · 1 分

Claude Mythos Preview とは?数千件のゼロデイ脆弱性を発見した AI モデルの衝撃

Anthropic が 2026 年 4 月 7 日に発表した Claude Mythos Preview は、同社史上最も高性能な汎用言語モデルでありながら、一般公開が見送られた異例のモデルです。同モデルはサイバーセキュリティ分野で突出した能力を示し、主要 OS やブラウザに潜む数千件のゼロデイ脆弱性(開発者が認識する前に存在する未修正のセキュリティ上の欠陥)を自律的に発見・悪用できることが確認されました。 この発表はセキュリティ業界だけでなく金融業界にも波紋を広げ、米国の財務長官や FRB 議長、ウォール街の CEO たちが緊急招集される事態にまで発展しています。 Claude Mythos Preview のベンチマーク性能 Mythos Preview は、従来の Claude Opus 4.6 を大幅に上回るベンチマーク結果を示しています。SWE-bench Verified では 13 ポイント以上、USAMO 2026 では 55 ポイント以上の向上を記録しました。 評価項目 Mythos Preview Opus 4.6 SWE-bench Verified 93.9% 80.8% USAMO 2026 97.6% 42.3% CyberGym(脆弱性再現) 83.1% 66.6% SWE-bench Pro 77.8% 53.4% Terminal-Bench 2.0 82.0% 65.4% 特にサイバーセキュリティの領域では、「ほぼすべての熟練した人間のセキュリティ研究者を上回る」と Anthropic 自身が述べています。 Mythos Preview が発見したゼロデイ脆弱性 Mythos Preview が内部テストで発見した脆弱性は衝撃的です。 ...

2026年4月12日 · 2 分

Claude Managed Agents のアーキテクチャ: Brain / Session / Hands の分離設計

前回の記事では Claude Managed Agents の概要と業界インパクトを紹介した。本記事では、Anthropic のエンジニアリングブログ「Scaling Managed Agents: Decoupling the brain from the hands」に基づき、内部アーキテクチャを掘り下げる。 全体アーキテクチャ Claude Managed Agents は4つのコアコンセプトで構成される。 コンセプト 説明 Agent モデル、システムプロンプト、ツール、MCP サーバー、スキルの定義 Environment コンテナテンプレート(パッケージ、ネットワークアクセス、マウントファイル) Session Agent と Environment を参照して起動される実行インスタンス Events アプリケーションとエージェント間でやり取りされるメッセージ(SSE) これらの背後には、Brain / Session / Hands という3層の分離設計がある。 設計思想: OS の抽象化パターン Anthropic はこのアーキテクチャの設計思想を、OS がハードウェアを抽象化した歴史に重ねている。 1970年代のディスクパックでも現代の SSD でも、read() コマンドは同じように動く。ハードウェアの実装が変わっても、その上の抽象化層(プロセス、ファイル)は安定し続けた。 Managed Agents も同じパターンを採用している。Session、Harness、Sandbox というエージェントのコンポーネントを仮想化し、インターフェースは安定させたまま、内部実装を自由に交換できる構造にした。Anthropic はこれを「メタハーネス」と呼んでいる。 なぜこの設計が必要なのか。ハーネスには「モデルが自力でできないこと」に関する前提が埋め込まれるが、モデルの能力が向上するとその前提が陳腐化する。例えば Claude Sonnet 4.5 では、コンテキスト制限が近づくとタスクを早期終了する「コンテキスト不安(context anxiety)」が見られた。そこでハーネスにコンテキストリセットを追加した。しかし Claude Opus 4.5 ではこの振る舞いが消え、リセット機能は無駄な荷物になった。 ...

2026年4月10日 · 3 分