Workspace 設定

OpenPress の設定システムを設計する際、私たちは一般的なジレンマに直面しました：設定の柔軟性を維持しつつ、巨大で複雑、かつメンテナンスが困難なグローバル設定ファイルを作成するのをどのように避けるか？

この問題を解決するために、OpenPress は「関心の分離」と「設定より規約（Convention over Configuration）」という二重の戦略を採用しました。ワークスペースの設定を、性質の異なる3つの領域に明確に分割しています。

1. ドキュメントメタデータ (Metadata)：コンポーネントに帰属

ドキュメント自体の属性について——例えば、これがどのようなドキュメントであるか、タイトルは何か、使用する用紙のジオメトリ寸法は何かなど——これらの情報は、特定の出版物（Press）コンポーネントに付随するように設計されています。

なぜこのように設計したのか？ 一つのワークスペース内に、複数の異なる出版物（例えば、縦型の提案レポートと横型のプレゼンテーション）が同時に存在する可能性があるからです。これらの情報をグローバル設定に配置すると、すぐに区別や管理が困難になります。メタデータを React コンポーネントのプロパティ（Props）として扱うことで、設定が常にそれが記述する対象に密接に従うことを保証し、完璧なカプセル化を実現しています。

2. 操作設定 (Operations)：プロジェクト構成に帰属

ドキュメントのコンテンツには関係なく、「ワークスペースがどのように機能するか」に関連する設定もあります。例えば：このドキュメントは最終的にどのホスティングプラットフォームにデプロイされるのか？ デプロイ時に特定のプラットフォームパラメータは必要か？

これらの操作レベルの設定は、標準的なプロジェクト設定ファイル（package.json など）に配置されます。

なぜこのように設計したのか？ この種の設定は、通常、プロジェクトのライフサイクル中で一度だけ設定されます。さらに重要なのは、デプロイスクリプトや継続的インテグレーション（CI）ツールのような外部システムが、React コードを実行したりドキュメントをコンパイルしたりすることなく、これらの環境情報を迅速に読み取れる必要があることです。標準の設定ファイルに配置することで、外部ツールチェーンとのシームレスな統合が保証されます。

3. ディレクトリ構造：設定より規約

ファイルがどこに配置されるべきか（例えば：テーマスタイルはどこか？ 共有コンポーネントはどこに配置するか？ コンパイル後の出力はどこに行くのか？）について、OpenPress は意図的にカスタマイズの余地を多く提供せず、固定されたパス規約を採用しています。

なぜこのように設計したのか？ これは一見自由度を下げているように見えますが、実際には大きな利点をもたらします。すべての OpenPress プロジェクトが同じファイル構造に従っている場合、AI Agent は追加の指示なしで、リソースを探すべき場所やファイルを書き込むべき場所を正確に把握することができます。この標準化により、人間の作成者が異なるプロジェクト間で切り替える際の認知負荷も大幅に軽減されます。これらのパス規約は自由に変更できる調整ノブではなく、製品のコアアーキテクチャの一部なのです。