OpenPress

Agent ワークフロー

Agent との連携

AI agent に OpenPress を正しく使わせる方法:skills やソース素材から始め、編集可能な workspace を作成し、出力を検証し、製品の境界を越える前に停止させます。

OpenPress の中核的な革新性は、初日から AI Agent 向けに設計されたドキュメントフレームワークであるという点にあります。「Agent との連携」の背後にある哲学を理解することで、AI を効果的に導き、高品質な結果を生み出すことができます。

Agent とフレームワークの責任分担

従来のツールでは、人間のユーザーがコンテンツの構想からタイポグラフィの微調整まで、すべての作業を担う必要がありました。OpenPress では、フレームワーク(Framework)、Agent(Skills)、そしてソースコードの責任の所在を明確に区別する契約を確立しています。

フレームワーク(エンジン)の受動性

OpenPress エンジン自体は極めて受動的です。「美しさ」とは何かを理解しておらず、「ストーリーテリング」の能力を持たず、特定のドメインのビジネスロジックも含まれていません。その役割は純粋に機械的なものです:コンポーネントツリーを解析し、レイアウトアルゴリズムを処理し、構造の正確性を検証し、最終的な静的成果物を生成します。この受動性により、エンジンの安定性と汎用性が確保されます。

Agent(Skills)の能動性

対照的に、Agent は視点と能動性に満ちています。さまざまな「スキル(Skills)」を通じて、Agent はコピーディレクター、ビジュアルデザイナー、またはテクニカルライティングの専門家として機能することができます。ユーザーの意図を理解し、適切なレイアウトを選択し、コンテンツを生成し、タイポグラフィとテイストに関する決定を下す責任を負います。

唯一の信頼できる情報源:ワークスペースのソースコード

Agent がドキュメントを作成または変更する場合、すべての変更はワークスペースの「ソースコード」レベルで行われる必要があります。これは OpenPress の設計において妥協できない原則です。

なぜ出力結果を直接変更できないのか? もし Agent がソースコードをバイパスし、コンパイル済みの HTML や組版済みの PDF を直接変更した場合、それらの変更は脆弱で再現不可能なものになります。ドキュメントを再び更新する必要が生じた際、出力に対する直接的な変更は失われてしまいます。

Agent に対し、ソースコード(MDX コンテンツ、React コンポーネント、CSS トークンなど)のみを編集するよう強制することで、ドキュメントのすべての変更が宣言的で、バージョン管理によって追跡可能であり、エンジンによって確実に再コンパイルできることを保証します。

検証ループの意義

優秀な Agent は、コードの変更後に直ちに停止するべきではありません。OpenPress は(型チェックからローカルプレビューまで)一連の検証ツールを提供しており、これが閉じた「検証ループ」を構成しています。

このループの存在は、Agent に「自己修正」の能力を持たせるためのものです。最終結果をユーザーに提示する前に、Agent はこれらのツールを通じて、自身の変更がフレームワークの構造規範に準拠しているか、コンパイルの失敗を引き起こさないかを検証する必要があります。このメカニズムはユーザーのレビュー負担を大幅に軽減し、納品品質を確保します。

製品境界の尊重

Agent の能力は強力ですが、OpenPress は厳格な境界(Hard Stops)を設けています。Agent はドキュメント作成の範囲内に制限されており、フレームワークの基盤となるコードを勝手に変更したり、ビジネスデータをでっち上げたり、明示的な許可なしにコンテンツを公開の本番環境にパブリッシュしたりすることはできません。これらの境界は、自動化と安全性の間で完璧なバランスを取るために存在します。