業務アプリは何トークンか？ 完全な CRM 全体が 150k 未満
完全な CRM は型付きメタデータ全体で 150k トークン未満です。ビジネスロジックは 100k 未満、UI は約 50k。同梱のリファレンス CRM は約 16k です。コンテキストに丸ごと収まるソフトウェアは保守のされ方が変わります。
要約： 完全な CRM は 150,000 トークン未満の型付きメタデータに収まります。全オブジェクト、ワークフロー、アクション、権限からなるビジネスロジックは 100,000 未満、宣言的 UI が約 50,000 を加えます。同梱の app-crm リファレンスはさらに小さく、31 ファイル・1,792 行、約 16,000 トークンです。この 16k はリファレンスサンプルの値であり、製品レベルの完全な CRM の上限ではありません。どちらも 200k のコンテキストウィンドウに収まります。これがコンテキストサイズのソフトウェア（context-sized software）です。AI エージェントは全体を保持・推論・リファクタリングし、人は diff をレビューできます。
自分で数えてみる
16k は完全な製品のベンチマークではありません。オープンソースの ObjectStack フレームワークに同梱される CRM リファレンスを再現可能な方法で数えた値です：
git clone https://github.com/objectstack-ai/objectstack
find objectstack/examples/app-crm/src -name '*.ts' -not -name '*.test.ts' \
| xargs cat | wc -l
# → 31 ファイル・1,792 行 ≈ 16k トークン（約 4 文字/トークンで換算）| システム | ファイル | 行数 | ≈ トークン | 200k コンテキストに収まる？ |
|---|---|---|---|---|
CRM サンプル（app-crm）— オブジェクト、ビュー、ダッシュボード、フロー、権限、翻訳 | 31 | 1,792 | ~16k | 収まる — 12 倍の余裕 |
| HotCRM — 完全なマーケットプレイス CRM：15 オブジェクト、17 フロー、4 ダッシュボード、2 つの AI コパイロット、4 言語 | 132 | ~18,000 | 合計 150k 未満（ビジネスロジック 100k 未満 + UI 約 50k） | 収まる — 50k 超の余裕 |
| 従来の手書き CRM コードベース | 数千 | 30 万〜100 万行超 | 数百万 | 遠く及ばない |
同じ製品カテゴリに二つの有用な尺度があります。約 16k のリファレンスサンプルと、150k 未満の完全な CRM です。どちらもコンテキストサイズですが、従来のコードベースはそうではありません。
なぜトークンが正しい単位になったのか
50 年間、ソフトウェアはコード行数で測られてきました。制約条件が人間の読者だったからです。読者が変わりました。AI エージェントがシステムを安全に変更するには、まずシステムを読み込む必要があります。これはすべてのコードベースを二つの状態に分けます：
- システム > コンテキスト。 エージェントは grep し、サンプリングし、推測します。編集はローカルで、間違いはグローバルです。すべての変更が、鍵穴越しの考古学になります。
- システム ≤ コンテキスト。 エージェントはすべてを — 全オブジェクト、全権限ルール、全依存関係を — 一度に読みます。*「これを変えると何が壊れるか？」*が、願望ではなく答えられる問いになります。データモデル、権限、API、UI をまたぐ概念のリネームも、一つの一貫した diff です。
これは漸進的な改善ではなく、状態の切り替えです。そして境界線は、あなたのコンテキストウィンドウのある場所に引かれています。
ビジネスロジックが 100k トークン未満に収まる理由
圧縮のトリックではなく、削除によってです。エンタープライズアプリケーションは、二つのものが絡み合ってできています：
- 意思決定。 どんなオブジェクトが存在するか、どう関係するか、誰がどのフィールドを見られるか、リードが転換したとき何が起きるか。これがあなたのビジネスオントロジーであり、本当に還元不能です — 決められるのはあなただけです。
- 配管。 テーブル、CRUD エンドポイント、一覧・詳細画面、権限ミドルウェア、監査書き込み。これは史上すべての業務アプリでほぼ同一 — つまり導出可能です。
ObjectStack の賭けは、成果物には意思決定だけを残し、配管はすべてランタイムで導出することです。同梱のリファレンス CRM では、あの 1,792 行こそが意思決定のリスト — 型付きで Zod 検証済みのメタデータです。データベーススキーマ、REST API、レンダリング済み UI、MCP ツールは起動のたびにそこから計算されます。導出可能なものは保存されないため、ドリフトしません。完全な HotCRM でも、この分離によってビジネスロジックは 100k トークン未満、宣言的 UI は約 50k、アプリ全体は 150k 未満に収まります。
圧縮できないもの
境界に正直であることは、売り文句より重要です：
- 新規アルゴリズム。 価格最適化エンジンや独自のマッチングエンジンは本物のコードであり、これからもそうです。フォーマットには脱出口があります — アクションとプラグインは普通の TypeScript です。
- ピクセル単位のカスタム体験。 スキーマ駆動 UI はエンタープライズのパターンを非常にうまく描画しますが、ブランドを定義するマーケティングサイトやゲームの作り方ではありません。
- 特殊なインテグレーション。 30 年前の SOAP サービスへのコネクタは、依然としてコネクタコードです。
つまりこの主張は「すべてがメタデータになる」より狭く — それゆえに強い：エンタープライズソフトウェアの大半を占める CRUD + ワークフローの中核は導出可能であり、本当に重要な残差 — オントロジー — はコンテキストに収まります。
ソフトウェアがコンテキストサイズになると何が変わるか
- レビューが本物になる。 1,792 行はコードレビューです。30 万行は儀式です。人間が diff 全体を読み切れて、検証ゲートとランタイムの権限・監査の強制が背後を固めます。
- 保守が腐らなくなる。 システム全体がコンテキストに収まれば、エージェントは見える部分への継ぎ当てではなく、全体のリファクタリングを行います。変更のたびにリスクが増していく、企業ソフトウェアお馴染みのエントロピー曲線が平らになります。
- オントロジーはあなたのもの。 定義は Apache-2.0 のオープンフォーマットで、リポジトリにあるただのファイルです — 人が読め、どのエージェントでも書け、ランタイム間で移植できます。
ループを回してみる
コーディングエージェントを ObjectStack に向けてください。スキャフォールドには AGENTS.md とスキルバンドルが同梱されており、エージェントは最初からこのフォーマットのルールを読み込んだ状態で始まります：
npm create objectstack@latest my-app && cd my-app
npx os dev --ui # アプリはもう動いています — 次の変更をエージェントに伝えるだけリポジトリよりブラウザ派なら、ObjectOS が同じ考え方の運用型です — オンラインで構築と問い合わせ、AI Builder・権限・監査を内蔵しています。