企業で生成AIを使っても、仕事が一つの場所で完結するとは限りません。AIが出した文章をWordへ貼り、分析結果をExcelで整え、グラフをPowerPointへ移し、必要に応じてPythonのコードやBIツールへ戻る――便利な機能が増えるほど、成果物と作業履歴が複数のツールに散らばる場面もあります。Ndocが解こうとしているのは、個々の生成機能の不足ではなく、この分断そのものです。

Ndocを立ち上げたロヒット・パテル氏は、Metaで8年間にわたりAI開発に携わり、Meta Superintelligence Labsのディレクターを務めた人物です。同氏はMetaを退社し、Microsoft OfficeやGoogle Workspaceに代わるAIネイティブな業務環境を目指して、3人のチームでNdocを開発しています。単に既存ソフトへAIボタンを追加するのではなく、分析、説明、プレゼンテーション、プログラムを最初から一体として扱う設計です。

パテル氏の退社は、Metaで相次いだ著名幹部・研究者の離職の一つでもあります。グローバル政策部門の責任者だったジョエル・カプラン氏、AI研究者のアンドリュー・タロック氏、仕事向けAI製品の責任者だったエミリー・ダルトン・スミス氏らも同社を離れています。ただし、Ndocを理解するうえで焦点となるのは人材移動の多さではありません。大企業の既存製品へAIを組み込む道ではなく、ファイルや業務フローの前提から作り直す道をパテル氏が選んだ点にあります。

Ndocの構想が問いかけるのは、「AIで既存作業を速くするだけで十分なのか」という問題です。パテル氏は、表計算ソフトのセルをAIに埋めさせる発想を、電気を発明したのに農耕牛へ照明を付けるようなものだと批判しています。同氏が求めるのは、従来の道具を少し便利にする改良ではなく、トラクターへ乗り換えるほどの業務設計の転換です。その成否は、生成性能だけでなく、既存の仕事を移せるか、同僚と共有できるか、結果を検証できるかに左右されます。

Ndocの画面は、Stage、Narrative、Modelという三つの領域で構成されます。Stageは、経営会議や顧客説明で実際に見せる成果物の置き場です。スライド資料だけでなく、ダッシュボード、シミュレーション、小規模なアプリも表示できます。分析を終えてから別のプレゼンテーションソフトへ移すのではなく、結果を伝える部分まで同じ環境に含める考え方です。

Narrativeには、数値をどう解釈するかという説明がまとめられます。分析文、番号付きの引用、生成された図表などを配置し、Stageに示された結論がなぜ導かれたのかを読めるようにします。企業の意思決定では、見栄えのよいグラフだけでなく、前提や根拠を説明できることが欠かせません。Narrativeは、成果物と根拠の間をつなぐ役割を担います。

Modelには、分析に使ったデータセットとPythonスクリプトが保存されます。つまり、利用者が目にする資料、その資料を支える説明、計算を実行したデータとコードが一つの文書内で結び付きます。一般的な業務では、プレゼンテーションの数字を確認するために表計算ファイルを探し、その計算方法を調べるために担当者へ問い合わせることもあるでしょう。Ndocは、その探索を文書内部の移動へ置き換えようとしています。

利用方法も、この三層構造を前提としています。ユーザーがデータセットをアップロードし、分析と結果の説明をAIへ依頼すると、計算だけでなく、読み手へ伝えるための文章や図表まで生成されます。対象読者、文章のトーン、その文書だけで使う背景情報も追加できます。完成品を一度生成して終わるのではなく、結論から根拠へ戻り、必要なら計算や表現を修正する循環型の作業環境と考えると理解しやすいでしょう。

同僚がNdocへ登録していなくても成果物へアクセスできる設計も示されています。業務ツールでは、作成者にとっての操作性だけでなく、承認者や取引先が追加契約なしで内容を確認できるかが普及を左右します。三つの領域を統合する構想は、作成機能の集約というより、説明と検証を含む意思決定の流れを一つの単位として扱う試みです。

生成AIに企業資料を任せる際、文章の自然さ以上に扱いが難しいのが数字の信頼性です。売上予測や顧客分析のグラフが整っていても、どの列を使い、どの条件で集計し、どの式から結論を出したのかが見えなければ、重要な判断には使いにくくなります。Ndocの特徴は、完成した資料だけを提示せず、その背後にあるデータとPythonスクリプトを利用者が確認できる点です。

この設計には、パテル氏がMetaで取り組んだ強化学習とAI出力の信頼性評価の経験が反映されています。強化学習とは、AIエージェントが試行錯誤を重ね、得られる報酬が大きくなる行動を学ぶ機械学習の手法です。目的に沿った出力を引き出せる一方、企業が結果を採用するには、AIが何をしたかを人間が点検できる仕組みも必要になります。

Ndocでは、Pythonを読めない利用者もAIチャットへスクリプトの説明を求められます。たとえば、コード全体が何を処理しているのか、特定の計算式がどの行にあるのかを質問し、その内容を確かめられます。コードを表示するだけでは、非エンジニアにとって十分な透明性とは呼べません。自然言語による説明を間に置くことで、データ分析担当者以外も検証へ参加できるようにしています。

もっとも、AIによるコード解説があるだけで、計算の正しさが自動的に保証されるわけではありません。元データの品質、分析条件の妥当性、質問の解釈、コードと説明の一致は、人間が確認する必要があります。Ndocが提供しようとしている価値は、誤りをなくす魔法ではなく、確認に必要な材料を隠さず、同じ文書の中からたどれる状態です。

日本企業で活用を検討する場合も、生成された資料の美しさより、レビュー経路を先に設計することが重要でしょう。誰が元データを承認し、誰が式を確認し、誰が最終的な説明責任を負うのかを決めておけば、Stage、Narrative、Modelの構造を内部統制や品質管理へ結び付けやすくなります。AIの出力をそのまま採用する道具ではなく、人間が検証可能な形で作業を加速する道具として評価する必要があります。

同じデータを分析しても、経営会議向けの報告と現場担当者向けの説明では、強調する点や言葉遣いが変わります。Ndocでは、対象読者やトーンに加え、文書固有の背景情報を指定できます。AIへ毎回同じ前提を入力し直すのではなく、利用者個人、特定の文書、チーム、企業という複数の範囲でコンテキストを保持する構想です。

この記憶機能が有効に働けば、社内用語、分析の前提、過去の判断基準などを引き継ぎながら作業できる可能性があります。部署ごとに説明の粒度を変えたり、同じ指標の定義を継続して使ったりする場面では、単発のチャットより一貫性を保ちやすくなるでしょう。ただし、どの情報がどの範囲で記憶され、誰から閲覧できるのかは、企業導入時に確認すべき論点です。現時点で、権限管理や保存期間などの詳細は明らかにされていません。

Ndocの基盤には、複数のオープンソースモデルを組み合わせ、用途に合わせて調整した仕組みが採用されています。パテル氏によれば、既存製品への追加機能としてではなく一から構築したため、最先端の大規模モデルを中心に据えた選択肢より運用費を抑えられるといいます。ただし、具体的な費用や比較条件は示されていないため、導入判断では実際の利用量や必要な精度を踏まえた検証が欠かせません。

興味深いのは、初期利用者がモデル構成や低コスト性よりも、作業の最初から最後までを一か所で見られる点に強く反応したことです。技術を提供する側はモデル性能や推論費用に注目しがちですが、利用者はファイル探索、転記、形式調整、共有といった日常的な手間を減らせるかで価値を判断します。Ndocの事例は、法人向け生成AIの競争軸が、モデル単体の能力から業務全体の連続性へ移る可能性を示しています。

企業側には、記憶機能を便利さだけで評価しない姿勢も求められます。機密情報や個人情報をどこまで与えるのか、チーム異動後も記憶が残るのか、誤った前提をどう修正するのかといった運用設計が必要です。コンテキストが豊富になるほど出力は業務に合いやすくなりますが、古い情報や不適切な権限まで引き継げば、別のリスクを生みかねません。

パテル氏が掲げる大きな目標は、業務アプリだけでなく「ファイル」そのものを作り直すことです。Ndocで作成した文書は、単一の「.ndoc.html」ファイルとして書き出し、一般的なブラウザで開けるとされています。スライド、分析文、図表、データ、コードを別々の形式で管理するのではなく、相互に関連付けられた仕事のまとまりとして持ち運ぶ発想です。

同氏は、この形式をオープンソースとして公開する意向を示しています。他の開発者がNdocに縛られず、同形式へ対応するアプリを作れる状態を目指しています。長年利用してきたMicrosoftやGoogleの環境から別の製品へ移る際、ファイル形式や共同作業機能への依存が障壁になることがあります。特定サービスへの囲い込みを避けられるなら、新しい業務ツールを試す企業にとって安心材料になり得ます。

オープンな形式を素早く形にしたいという思いは、パテル氏がMetaを離れた理由の一つです。大企業で共通形式を決めようとすれば、多数の関係者から意見を集め、合意を形成する必要があります。同氏は、人間の組織が動く速度よりAIを使って実装できる速度を優先し、独立して開発する道を選びました。これは、大企業の慎重さと小規模チームの機動力のどちらが正しいかという単純な対立ではなく、標準化に必要な合意と市場投入の速さをどう両立するかという課題です。

ファイル形式の構想が定着するには、ブラウザで開けることに加え、長期保存、互換性、セキュリティ、バージョン管理なども問われるでしょう。コードを内包する文書では、受け取った側が安全に内容を閲覧・実行できる設計も重要になります。これらの詳しい仕様や公開時期は、現時点では示されていません。

それでも、成果物と作成過程を同じファイルへ収める考え方には注目すべき点があります。従来の文書は結果を固定して渡すことに向いていますが、AI時代の成果物には、計算を再実行したり、条件を変えてシミュレーションしたり、根拠へ戻ったりする動的な操作が求められます。「.ndoc.html」は、その変化を一つの文書として扱おうとする提案です。

企業の仕事が集まる基盤を狙うNdocにとって、競争相手は表計算ソフトやプレゼンテーションソフトだけではありません。主要なAI企業は、Google WorkspaceやMicrosoft 365などへ接続し、利用者が普段使う環境の中でAIを働かせる法人向け機能を展開しています。OpenAIも共有型の作業環境「Space」をChatGPT内で提供しており、統合ワークスペースという領域でNdocと重なる部分があります。

パテル氏もSpaceを脅威になり得る存在と認めています。そのうえで、AI企業の多くは従来の表計算や文書へモデルを接続する発想に寄り過ぎていると見ています。Ndocは既存アプリをAIで補助するのではなく、分析から共有までの構造をAI前提で再設計します。ここには、現在のファイル形式や画面構成を維持する互換性重視の道と、新しい作業単位へ移行する再設計重視の道という違いがあります。

ただし、企業が既存ツールとの連携を選ぶのには明確な理由があります。従業員が操作に慣れており、過去のデータが蓄積され、承認手続きや権限設定も既存環境を前提に作られているためです。新製品が機能面で優れていても、業務習慣を変え、ファイルを移し、関係者全員へ使い方を浸透させる負担が大きければ採用は進みません。Ndocが直面する最大の壁は、AIモデルの性能差よりも、この移行コストでしょう。

Ndocはその現実を踏まえ、利用中のツールから既存データを取り込むコネクターを用意しています。完全な切り替えを初日から求めず、現在の資産を持ち込める入口を作る考えです。それでも、取り込めるデータの範囲や再現性、更新時の同期方法などは、実際の導入時に確かめる必要があります。

日本企業が評価するなら、全社でOfficeやWorkspaceを置き換える前提から始める必要はありません。特定の分析案件や定例報告を対象に、データの投入から説明資料の共有まで何工程減らせるかを測る方法があります。同時に、既存環境で同じ改善が可能かも比較すべきです。Ndocの価値は機能一覧ではなく、ツール間の転記、数字の照合、説明資料の作り直しといった見えにくい作業をどこまで削減できるかで判断できます。

Ndocは、資金調達を行っていない3人のチームで、巨大な法人向けソフト市場へ挑んでいます。パテル氏は、利用者が製品を本当に好んでいるという手応えを得るまで、外部資金を受け入れない方針です。完成度の高い計画を長く練るより、十分ではない計画でも実行し、利用状況から修正する速度を優先しています。

2026年10月27日時点では、Ndocは企業向けパイロットを進めるとともに、待機リストへ登録した限られた顧客にアルファ版を開放しています。登録は無料ですが、顧客は利用量とトークンに応じて料金を支払う仕組みです。数週間以内のベータ版公開と、翌年の正式提供を目指しています。対象企業、料金単価、正式版の具体的な日程などは明らかにされていません。

パテル氏は、自身が日常的に使い続けたいと思えない製品は公開しないという基準を設けています。同氏はすでにさまざまなAI活用フローを最適化しており、Ndocを試した後も以前の方法へ戻るなら、製品が十分ではないと判断します。この基準は厳しいものですが、開発者自身の使いやすさと、一般企業の導入しやすさが同じとは限りません。小規模チームが法人顧客を支えるには、安定運用、問い合わせ対応、セキュリティ審査など、製品体験以外の要素も必要です。

企業が試験導入する場合は、単なる生成速度ではなく、五つの観点を確認するとよいでしょう。成果物から根拠とコードへ戻れるか、既存データを無理なく移せるか、権限と記憶の範囲を管理できるか、非技術者も検証に参加できるか、作成から共有までの総作業時間が減るかという観点です。精度だけを評価すると、Ndocが狙う業務全体の統合効果を見落とします。

Ndocの挑戦は、Microsoft OfficeやGoogle Workspaceをすぐに置き換えられるかどうかだけで評価するものではありません。資料、説明、データ、コードを別々に管理してきた仕事の形を、検証可能な一つの文書へまとめられるかが核心です。関心のある企業は、全社導入の可否を議論する前に、転記と確認に時間がかかっている一つの分析業務を選び、現在の工程とNdoc型の工程を比較すると、AIネイティブな業務基盤の実用性を具体的に判断できるでしょう。