100万トークンのコンテキストが使えるのに、それに対応したアプリがまだない

どんな問題か

エージェントが「本当の仕事」をこなせない理由は、モデルの性能不足ではない。アプリがエージェントのために設計されていないからだ。

メルカリやLINEのモノレポは数百万行規模のコードベースだ。M&A契約書は200ページを超えることも珍しくない。カスタマーサポート履歴は数百回の会話にまたがる。既存のLLMアプリはこれらをそのまま扱えず、チャンキングやRAG検索で回避策を取る。

その回避策がエージェント作業では致命的なエラーを生む。依存グラフ全体を参照できないリファクタリングエージェントはバグを生む。契約書のコンテキストを途中で失う法務レビューエージェントは条項の矛盾を見落とす。マルチセッション記憶のない営業支援エージェントは先週の商談内容を覚えていない。コンテキストが途切れると、エージェントの価値提案そのものが崩壊する。

DeepSeek V4の100万トークンコンテキストはこの構造的制約を取り除く。問題は、それを活かすアプリがまだ存在しないことだ。ここに空白がある。

なぜ今か

DeepSeek V4は、100万トークンコンテキストを「コスト障壁なしに」提供する初の商用モデルだ。ロングコンテキスト自体はGPT-4oやClaudeも対応しているが、コストがトークン数に対して非線形に跳ね上がるため、プロダクション利用は事実上制限されていた。DeepSeek V4はそのコスト方程式を書き換えた。

2026年は国内でも、AIエージェントワークフローが「社内実験」から「本番依存」へ移行する変曲点だ。メルカリやSansan、freeeのような成長企業が社内AIを標準インフラとして位置づけ始めた。「なぜエージェントがミスをするのか」という問いへの答えが「コンテキストの途切れ」だと気づいたとき、それを解決するアプリに真っ先に飛びつく。

どう作るか

最初の戦略は1つのバーティカルを深掘りすることだ。検証が最も明確で収益化が早いのはエンジニアリングチーム向けコードエージェントだ。

flowchart LR
    A[Full repo upload] --> B[Context packer]
    B --> C[DeepSeek V4 1M context]
    C --> D{Agent task}
    D -->|Code review| E[Dep graph analysis]
    D -->|Refactor| F[Change impact scope]
    D -->|Bug trace| G[Execution path trace]
    E & F & G --> H[Actionable report]
    H --> I[Auto PR / Slack / Backlog]

MVP 3レイヤー:

コンテキストパッカー: GitHubリポジトリ全体をファイルツリー・コミット履歴・依存グラフ込みで構造化し、1Mトークン以内にパッキングする前処理レイヤー。最大50万行規模のリポジトリに対応。
エージェントワークフローエンジン: コードレビュー・リファクタリング提案・バグ根本原因分析の3ワークフローを定義済みプロンプトチェーンで実行。RAGスライスではなく、完全なコンテキストを使う決定論的ツール呼び出し。
デリバリーレイヤー: GitHub PRコメント・Slackサマリー・Backlogチケット自動生成。エンジニアが既に使うツールに結果を届ける。

価格: 月$99/リポジトリ (小規模チーム) / $299 (中規模) / エンタープライズ見積もり。DeepSeek V4の推論コストにより60%以上のマージンが成立する。

成功の条件

核心仮定: エンジニアリングチームが「コンテキスト途切れ」を実際の痛みポイントとして認識し、月$100〜$300を支払う意欲がある。
検証方法: 20チームへの1ヶ月無料ベータ導入 → コードレビュー完了時間の前後比較。50%以上の短縮が確認できれば有料転換を提案。
拡張経路: コードエージェント → 法務契約書レビューエージェント → 営業CRM記憶エージェントの順にバーティカル展開。
リスク: OpenAIやAnthropicが自社ロングコンテキストを活かしたバーティカルアプリを投入する可能性。防衛策はGitHub・Jira・Backlogとの深い統合による乗り換えコストの構築。