中核となる位置付け
オープンな接続とは、すべてのデータを第三者に渡すことではありません。各アプリケーションは、何を読み取れ、何を書き込めるのか、誰の代理で実行するのか、どのクォータ制限を受けるのか、失敗後にどう復旧するのかを明確に把握しなければなりません。
REZICS では、サーバールートと型構造の定義が、手書きの契約における唯一の情報源です。そこから OpenAPI、型付きクライアント、ドキュメントを生成します。認証と権限は、サーバー側の型付きアクセスポリシーで強制され、インターフェース上のボタンを隠すことには依存しません。
現在できること
- 公開 API を通じて、作品、コンテンツ、領域、進捗などの公開済み機能にアクセスする。
- サーバールートと型構造の定義から、一貫した OpenAPI ドキュメントを生成する。
- セッションまたは権限スコープを持つ API トークンでリクエストを認証する。
- 操作ごとにクォータ、エラー応答、サーバー側アクセスポリシーを適用する。
- 生成された型付きクライアントと
@rezics/apiパッケージを利用する。 - コンテンツ構造などの複雑なワークフローで、並行トークン、リクエスト上限、復旧可能な意味論を維持する。
OAuth と MCP の方向性
OAuth により、ユーザーはパスワードや長期個人トークンを渡すことなく第三者アプリケーションを認可できるようになります。MCP により、AI ツールはユーザーが理解でき、いつでも取り消せる範囲で、書籍情報の補完、メタデータの更新、ワークフローの実行を支援できます。
最終目標は、API に詳しくないユーザーも制御されたツールを通じて作品データの構築に参加できるようにすることです。ただし、OAuth の第三者アプリケーション、同意画面、コールバック、セキュリティレビュー、公式 MCP サーバーはまだすべて実装されていないため、機能の状態は「開発中」です。
大規模コンテンツのワークフロー
書籍のコンテンツ構造を例にすると、1 回のリクエストはコンパイル後の論理変更を 10,000 件に制限しますが、書籍全体の総ノード数は制限しません。大規模なウェブ小説のインポートは、分割して実行し、チェックポイントを保存し、失効した改訂と不確定な結果を処理する必要があります。数十万ノードを一つの無制限なトランザクションに詰め込むことはできません。
関係と境界
OpenAPI は転送契約を記述しますが、すべての複数段階タスクを自動で記述するものではありません。API も製品の権限を迂回しません。MCP は AI によって呼び出されたからといって追加の権限を得ることはありません。ネットワーク、ストレージ、キャッシュの境界をまたぐたびに、データと閲覧者の権限を再検証しなければなりません。