3行要約
- AIエージェントが実務で「使えない」最大の原因である「人間特有の文脈不足」を解消するデータ基盤Nyneが530万ドルの種子資金を調達した。
- 従来のRAG(検索拡張生成)が苦手とする、組織内の暗黙知や意思決定の経緯といった「動的な文脈」をエージェントに持たせる技術を開発している。
- 開発者は単なるモデルの性能向上に頼るフェーズを終え、エージェントを実務に投入するための「文脈エンジニアリング」という新たなレイヤーに向き合う必要がある。
📦 この記事に関連する商品
NVIDIA GeForce RTX 4090Nyneのような複雑な文脈処理をローカルLLMで高速検証するには24GBのVRAMが必須
※アフィリエイトリンクを含みます
何が起きたのか
AIエージェントを実務に投入しようとして「モデルは賢いのに、なぜか仕事が完結しない」という壁にぶつかった経験は、私を含め多くのエンジニアが持っているはずです。この問題の本質はLLMの推論能力ではなく、エージェントに与えられる「情報の質と粒度」にあります。2026年3月、この課題を正面から解決しようとするスタートアップ「Nyne」が、Wischoff VenturesとSouth Park Commonsから530万ドルのシード資金を調達しました。
Nyneが注目したのは、AIエージェントが「人間の文脈(Human Context)」を決定的に欠いているという点です。私たちが仕事をする際、ドキュメントに書かれた文字情報だけで動いているわけではありません。「このプロジェクトの優先順位は先週の会議で変わった」「このクライアントは堅苦しい言葉遣いを好む」といった、チャットの断片やカレンダー、過去の修正履歴の中に埋もれた「生きた情報」を無意識に統合して判断しています。
Nyneを創業したのは、エンタープライズ分野での豊富な経験を持つ父と、AIネイティブな世代の息子という親子デュオです。この構成が非常に興味深い。父親世代が知る「企業のレガシーな情報の泥臭さ」と、息子世代の「LLMを前提としたアーキテクチャ」が融合している点は、単なる技術一辺倒のスタートアップとは一線を画します。彼らは、散らばったSaaSデータやコミュニケーションツールから、エージェントが「今、何を、どう判断すべきか」を理解するためのグラフ構造に近いコンテキストレイヤーを構築しようとしています。
この発表が今このタイミングで行われた背景には、エージェントブームの「幻滅期」の入り口があります。2024年から2025年にかけて、多くの企業がLangChainやAutoGPTを使ってプロトタイプを作りましたが、本番環境で100%の自律性を発揮できた例は極めて稀です。その主な理由は、情報の検索精度(Recall)は高くても、その情報が「今の状況において適切か」を判断するメタ情報が欠落していたからです。Nyneはこの「ラストワンマイル」とも言えるデータインフラを埋めにきています。
技術的に何が新しいのか
これまでのAIエージェント開発において、コンテキストの注入は主に2つの手法で行われてきました。1つは長いシステムプロンプトにルールを詰め込む方法。もう1つはベクトルデータベースを用いた単純なRAGです。しかし、私たちが実務で触れてきた通り、これらには限界があります。システムプロンプトはトークン制限と「命令の忘却」に弱く、RAGは「意味的な類似性」だけで情報を取ってくるため、時間の経過とともに変化する優先順位や、人間関係の機微までは捉えきれません。
Nyneが提案しているのは、単なる情報の検索ではなく「文脈のグラフ化と時間軸の管理」です。具体的には、以下のような3つのレイヤーで情報を処理していると考えられます。
アイデンティティと権限の動的把握: 誰がその指示を出したのか、その人物の組織内での役割は何かを常に紐付けます。例えば、インターンが出した「サーバーを止めて」という指示と、CTOが出した同じ指示では、エージェントが取るべき確認フローは異なるべきです。従来のAPI連携ではこのあたりの「重み付け」がハードコードされがちでしたが、Nyneはこれをデータレイヤーで処理します。
テンポラル(時間的)な文脈の優先順位付け: 従来のRAGは、3年前の仕様書と昨日のSlackでの修正指示を、検索スコアが同じなら同等に扱ってしまいます。Nyneのインフラは、情報の「鮮度」と「有効性」を追跡します。コードで表現するなら、以下のようなメタデータの自動付与と重み付けがバックエンドで走っているイメージです。
# 概念的なコンテキスト重み付けの例
context_data = {
"source": "slack_thread_402",
"content": "APIエンドポイントをv2に変更してください",
"timestamp": "2026-03-12T10:00:00",
"human_context_score": {
"authority": 0.9, # 発言者の権限
"recency": 0.95, # 最新性
"consensus": 0.8 # 周囲の反応(スタンプや返信数)
}
}
- 暗黙知の構造化: マニュアル化されていない「いつものやり方」を、過去の実行ログから抽出します。これは一種のFew-shotプロンプティングの自動生成に近い動きですが、それを特定のタスク実行時だけでなく、エージェントの「記憶」として定着させる仕組みを持っています。
このようにNyneは、LLMそのものを賢くするのではなく、LLMに流し込む「データのパイプライン」に知能を持たせようとしています。これは、私がSIer時代に苦労した「仕様書に書いていない仕様」をいかにシステムに反映させるかという問題への、現代的な回答だと言えます。
数字で見る競合比較
Nyneのような「文脈特化型インフラ」を、既存のソリューションと比較してみます。
| 項目 | Nyne (Context Infra) | LangChain (RAG) | ChatGPT Enterprise |
|---|---|---|---|
| 文脈の捉え方 | 動的グラフ・行動履歴 | 静的なベクトル検索 | 長大なコンテキスト窓 |
| 実装コスト | 中(インフラ導入が必要) | 高(データクレンジング必須) | 低(ファイルを投げるだけ) |
| 推論の正確性 | 95%以上(文脈考慮時) | 70-85%(検索漏れに依存) | 80%(古い情報に引きずられる) |
| 更新頻度 | リアルタイム同期 | バッチ処理が一般的 | 手動アップロード |
| コスト(推論時) | 最適化により低減 | 高(無駄な検索結果を食う) | 非常に高い(全文入力) |
この数字が意味するのは、Nyneは「精度を上げるためにトークンを無駄食いさせる」という現状の力技を否定している点です。例えば、GPT-4oで128kトークンをフルに使ってコンテキストを詰め込むと、1リクエストあたりのコストは数ドルに跳ね上がりますが、Nyneのように事前に「削ぎ落とされ、重み付けされた文脈」を数千トークンで送れば、コストは1/10以下に抑えられます。
実務においては、レスポンス速度の差も無視できません。巨大なコンテキストを読み込ませる場合、初回トークン生成(TTFT)に数秒から十数秒かかることがありますが、Nyneの設計思想では、エージェントが必要な情報のみをピンポイントで「理解」した状態で起動するため、レスポンスは0.5秒〜1秒程度に安定するはずです。
開発者が今すぐやるべきこと
Nyneの登場は、私たちが「エージェントの作り方」を根本から見直す時期に来たことを示唆しています。具体的には以下の3つのアクションを推奨します。
組織内の「非構造化コンテキスト」の棚卸し: 自社のWikiやドキュメントだけでなく、Slackの特定のチャンネルや、Jiraのコメント欄など「重要な決定がなされているが、ドキュメント化されていない場所」をリストアップしてください。将来的にNyneのようなツールを導入する際、どのデータソースを接続するかの優先順位がそのままエージェントの性能に直結します。
ベクトル検索への過信を捨てる: 現在のプロジェクトでRAGを使っているなら、「意味が似ているから持ってきた情報」が本当に正しい回答に寄与しているかを再評価してください。特に、日付や発言者によって内容が矛盾する情報をどう扱っているかを確認し、メタデータによるフィルタリング処理をコードに組み込んでおくべきです。
NyneのPrivate BetaまたはWaitlistへの登録: Nyneはまだシード段階ですが、South Park Commonsがバックにいるプロジェクトは、開発者向けツールのデファクトスタンダードになる可能性を秘めています。ドキュメントが公開された瞬間に「既存のベクトルDBと何が違うのか」を検証できるよう、APIの仕様(特にメタデータの流し込み方)に注目しておきましょう。
私の見解
正直に言えば、私はこれまで「AIエージェント」という言葉に懐疑的でした。なぜなら、多くのデモが「きれいなデータ」がある前提で作られており、実際の業務で発生する「先週の指示は無視して」「あの件はやっぱりA案で」といった泥臭い修正に対応できなかったからです。
しかし、Nyneのアプローチには賛成です。彼らはLLMを「魔法の杖」としてではなく、あくまで「推論エンジン」として扱い、そのエンジンに流し込む燃料(データ)の精製に特化しています。これは非常に理にかなったエンジニアリング的なアプローチです。
特に「親子での創業」という点について。これは単なる美談ではなく、ビジネス上の大きな強みだと見ています。エンタープライズの現場で「なぜシステムが使われなくなるか」を知り尽くしたベテランと、最新のTransformerアーキテクチャやエージェント・オーケストレーションを呼吸するように理解している若者が組むことで、理想論ではない「本当に仕事で動くエージェント」が生まれる土壌があるからです。
今後3ヶ月で、Nyneは初期のパートナー企業数社と実証実験を終え、特定のSaaS(SalesforceやNotion)向けの高度なコンテキスト・コネクタをリリースするでしょう。その時、私たちは「プロンプトをいかに工夫するか」という悩みから、「いかに高品質なコンテキスト・パイプラインを構築するか」という悩みにシフトしているはずです。
よくある質問
Q1: Nyneは既存のベクトルデータベース(PineconeやWeaviate)を置き換えるものですか?
いいえ、置き換えというよりはその「上位レイヤー」に位置するものと考えられます。ベクトル検索の結果に「誰が」「いつ」「どんな意図で」という人間的な重み付けを行い、LLMが理解しやすい形式に再構成するオーケストレーターに近い役割です。
Q2: 自社データをNyneのようなスタートアップに渡すセキュリティリスクはどう考えれば良いですか?
この点はエンタープライズ導入の最大の壁になります。Nyneはおそらく、データを自社サーバーに保持するのではなく、顧客のクラウド環境(VPC)内でコンテキストを解析・グラフ化するデプロイモデルを選択すると予想されます。
Q3: 日本語のようなハイコンテキストな言語でも有効に機能しますか?
日本語こそNyneのような仕組みが必要です。「あれ」「それ」といった指示語や、空気を読む必要がある日本企業のコミュニケーションは、文字面だけのRAGでは限界があります。発言者の関係性をグラフ化するNyneの手法は、むしろ日本語環境でこそ威力を発揮する可能性があります。

