Deprex の設計思想 — AI が人間の代わりに会社に埋め込まれる時代

Palantir が生み出したフォワード・デプロイド・エンジニア（FDE）モデルは、コンサルティングでもパッケージ製品でもない第三の形態です。エンジニアが顧客のオフィスに常駐し、データパイプラインを直接触りながら「今、この現場で何が起きているか」をソフトウェアに反映し続ける——これが FDE の本質です。外部から提案書を投げるのではなく、内部から問題を見る。この視点の違いが実装品質に決定的な差を生みます。

Deprex は、この FDE モデルを AI エージェントで再実装します。人間のエンジニアの代わりに、AI エージェントが顧客のチャットツール・メール・ドキュメント管理システムに「埋め込まれ」、現場の文脈を学習しながら業務を自律実行します。以下は、人間 FDE と AI FDE の対比です。

重要なのは、AI FDE が人間 FDE を完全に置き換えるという主張ではないことです。定型業務・情報収集・レポート生成の領域では AI の優位性が明確ですが、法的判断・顧客信頼関係の構築・未知事態への即興的な対応は、引き続き人間が担います。Deprex が定義するのは「AI に任せられる仕事の境界線」であり、その境界を引く作業そのものが最初の価値提供です。

Andrej Karpathy が提唱した問いは、AI 活用の核心をついています。「なぜ AI は同じことを毎回ゼロから考え直すのか」——これは能力の問題ではなく、記憶の設計の問題です。

従来の AI システムは、クエリのたびに同じ情報を再発見します。昨日整理した顧客情報も、先週学んだ業務パターンも、次のセッションではゼロリセットされます。この「記憶なし」設計が、AI を「賢いが物忘れの激しいアシスタント」に留め、「自律的なオペレーター」への進化を妨げています。

Karpathy の答えはシンプルです。Raw Sources（生データ）を一度 Compiled Wiki（構造化ナレッジ）へ変換し、Schema（クエリ可能な形式）として保持する。クエリのたびに再発見するのではなく、一度コンパイルしたナレッジを複利で成長させる。これが Deprex のメモリシステム設計の根幹です。

Deprex のメモリシステムは 3 層で構成されます。各層が明確な責務を持ち、データが上位層へと変換されるにつれて、再利用可能な知識として結晶化していきます。

重要な設計原則は、Raw Sources 層が不変であることです。LLM は一次資料を書き換えません。Compiled Wiki 層だけが LLM によって維持され、新しい情報が入るたびに関連する複数のページが更新されます。これにより、個別の情報断片が孤立せず、常に相互参照を持つ有機的なナレッジグラフとして成長します。

整合性を保つ Lint サイクルも重要な役割を果たします。定期的なチェックにより、矛盾する記述（同一エンティティへの相反する情報）・90日以上更新のない陳腐化ページ・相互参照が切れた孤立ページを検出し、自動的に修正候補を生成します。知識は増えるだけでなく、常に最新かつ整合性が保たれた状態に維持されます。

ただし、Raw Sources 層の要否は一次情報源の性質によって分かれます。書籍・論文・アーカイブ文書のような静的な一次情報源に対しては、Raw Sources 層が有効に機能します。原本が変化しないため、生データを保存しておくことで将来の再処理・再解釈が可能になります。一方、Slack メッセージ・API レスポンス・Web ページのような動的な一次情報源に対しては、Raw Sources 層は YAGNI（You Aren't Gonna Need It）になる可能性が高い。原本がリアルタイムに変化するため、生データを静的に保存すると保存した瞬間から陳腐化が始まり、エージェントが「保存された古い生データ」を参照して最新情報を取りに行く探索能力が制限されてしまいます。

動的な情報源に対する推奨パターンは、生データを保存する代わりに Connectors 層で都度取得し、エージェントが semantic な判断で重要な知見を蒸留して Compiled Wiki に永続化するアプローチです。蒸留されていない情報が必要になった場合は、再度 Connectors で最新データを取得する。これにより探索能力を維持しつつ、知識の複利効果も得られます。例外は法的・規制要件で生データの保持が必要な場合（税務書類、監査証跡など）であり、この場合は静的情報源と同様に Raw Sources 層で保存します。

Deprex の Connectors 層は、顧客が既に使っているあらゆるツールからデータを収集します。新しいツールを導入する必要はありません。既存のコミュニケーション・ドキュメント・コード管理のすべてが、知識の入力ソースになります。

収集ポリシーの核心は差分取得です。初回以降は前回収集タイムスタンプからの新着データのみを取得するため、システムリソースを最小化しつつ知識を最新に保てます。収集されたデータは Raw Sources 層にそのまま保存され、直後に Ingest パイプラインが走って Compiled Wiki 層を更新します。

業務エージェントが実際にタスクを実行する際の内部プロセスは、人間の問題解決プロセスを模した 7 フェーズのループとして設計されています。単なるタスクキューの処理ではなく、観測→記憶→推論→計画→実行→評価→学習のサイクルを回すことで、実行するたびに精度が上がる自己改善型の実行エンジンになっています。

このループの重要な特性は、EVALUATE フェーズが「受容基準（AC）との照合」によって機械的に判断されることです。「なんとなく完了した」ではなく、事前に定義した基準を満たしたかどうかが判定の根拠になります。これにより、人間の確認なしでも品質を担保できます。LEARN フェーズで学習した内容は Compiled Wiki 層に永続化されるため、次回同種のタスクでは ② REMEMBER フェーズでその知識が参照され、精度が向上します。

Deprex は 5 層で構成されています。各層が明確な責務を持ち、疎結合で設計されているため、新しいデータソースの追加も、顧客固有のルールの適用も、他の層に影響を与えずに行えます。

疎結合設計の実用的な意味を一つ示します。あるデータソースが API を変更した場合、L2（データ収集層）のコネクターだけを更新すれば済みます。L3 以上は「正規化されたデータが届く」という契約だけを信じており、収集手段が変わっても影響を受けません。同様に、顧客 A の業務ルールを L5 で変更しても、L4 以下の認知エンジンは共通のままです。スケール時のコスト増を構造的に抑える設計です。

Deprex の設計で最も議論を呼ぶのが「承認ゲートなし」原則です。7フェーズ認知ループは、人間の確認なしにタスクを実行し続けます。これは信頼の問題ではなく、設計の問題です。

逐一確認を要求するシステムは、承認待ちのたびに停止します。人間が承認できる速度は、AI が処理できる速度の数千分の一です。この非対称性を解消しない限り、AI は「高価なアシスタント」に留まり、「自律的なオペレーター」にはなれません。

承認ゲートなしは、すべての判断が人間の関与を必要としないという意味ではありません。エスカレーション条件を事前定義することで、AI が自律的に実行できる範囲と、人間が判断すべき範囲を明確に分離します。不可逆な操作・外部への大きな影響を持つアクション・事前定義された閾値を超える判断——これらは人間にエスカレーションし、Slack 等で通知します。「人間は何を判断すべきか」を設計することで、残りを AI に委ねる。これが Deprex の自律性設計です。

顧客環境への展開は 3 フェーズで進みます。単にソフトウェアをインストールするのではなく、AI エージェントが顧客の業務を観察・学習し、段階的に自律化範囲を広げていくプロセスです。

Phase 2 以降は「自己改善ループ」が重要な役割を果たします。エージェントは業務実行の中で新たな自動化可能な領域を発見し、その発見を次の自動化の入力として使います。初日から完璧な自動化を目指すのではなく、使いながら学び、学びながら自動化範囲を広げていく——このアプローチが顧客適応の現実的な設計です。各顧客での学習は匿名化されたパターンとしてライブラリに蓄積され、次の顧客展開時に初日から活用されます。

Deprex の長期ビジョンは「人間0運営」です。しかしこれは明日実現するものではなく、仮説検証ロードマップとして段階的に進みます。各フェーズの成果が次フェーズの前提証拠になります。

「人間0」は方向性を示す北極星であり、目的地ではなく羅針盤です。重要なのは、各フェーズで何が自動化され、何が人間に残るかを誠実に定義し続けることです。Phase 0 の失敗は Phase 1 のスタートを阻止します。過剰な約束より、検証可能なマイルストーンの積み上げが、この種のプロダクトの正直な設計です。初期フェーズでは「人間の判断が必要な仕事」と「AI に任せられる仕事」を丁寧に切り分ける作業そのものが、Deprex の本質的な価値提供です。