第6章 実装要件
本章では、グローバルカスタムシステムをプラットフォーム上に実装するために必要な条件を定義する。本仕様書は概念仕様であり、特定のプログラミング言語、フレームワーク、またはプラットフォーム固有のアーキテクチャには依拠しない。本章で定義する実装要件は、いかなる技術的手段によって充足されてもよい。
実装要件は、本システムの基本機能を実現するために不可欠な最小実装要件と、全機能を完全に発揮するために望ましい推奨実装要件の二段階で定義する。
6.1 最小実装要件
最小実装要件は、グローバルカスタムシステムの核心的機能を成立させるために、プラットフォームが最低限提供しなければならない条件である。最小実装要件の全てが満たされない場合、本システムは動作しない。
6.1.1 複数カスタムプロンプトの同時保持
プラットフォームは、一つの対話環境に対して複数のカスタムプロンプトを同時に保持できなければならない。現行の多くのプラットフォームが提供する単一フィールドのカスタム指示ではなく、複数のフィールドまたは複数のプロンプト単位が独立して存在し、それぞれが固有の識別子を持つ必要がある。
この要件が満たされない場合、階層構造そのものが成立しない。
6.1.2 カスタムプロンプト間の親子関係定義
プラットフォームは、複数のカスタムプロンプト間に親子関係を定義する仕組みを提供しなければならない。親子関係とは、あるカスタムプロンプトが別のカスタムプロンプトの上位または下位に位置することを明示的に宣言できることを意味する。
第4章4.1.3で定義した帰属情報(自己識別子、親識別子、子識別子群)を各カスタムプロンプトが保持できることが、この要件の充足条件となる。
6.1.3 カスタムプロンプトの選択的ロード・アンロード
プラットフォームは、保持されている複数のカスタムプロンプトのうち、任意のプロンプトを対話処理に適用する状態(ロード)と、適用しない状態(アンロード)を動的に切り替える仕組みを提供しなければならない。
ロード状態のカスタムプロンプトは対話処理に影響を与え、アンロード状態のカスタムプロンプトは対話処理に影響を与えない。アンロード状態のカスタムプロンプトのデータは保持され、削除されない。
6.1.4 カスタムプロンプト間の優先順位解決
プラットフォームは、複数のカスタムプロンプトが同時にロードされている場合に、指示間の矛盾を検出し、定義された優先順位に基づいて解決する仕組みを提供しなければならない。
第5章5.1.3で定義した矛盾解決規則(上位階層の指示が優先される)を実行できることが、この要件の充足条件となる。
6.1.5 最小実装要件の一覧
| 要件番号 | 要件名 | 概要 | 対応する本仕様の章節 |
|---|---|---|---|
| MIN-01 | 複数プロンプト同時保持 | 複数のカスタムプロンプトを独立した単位として同時に保持 | 3.1 |
| MIN-02 | 親子関係定義 | カスタムプロンプト間の上位・下位関係を明示的に定義 | 3.2, 4.1.3 |
| MIN-03 | 選択的ロード・アンロード | 任意のプロンプトを動的にロード・アンロード | 3.2, 4.1 |
| MIN-04 | 優先順位解決 | 複数プロンプト間の矛盾を優先順位に基づいて解決 | 5.1.3 |
6.2 推奨実装要件
推奨実装要件は、グローバルカスタムシステムの全機能を完全に発揮するために望ましい条件である。最小実装要件のみが満たされた環境でも本システムは基本的に動作するが、推奨実装要件が満たされることで、エンドール、グローバルストッピング、レンダラインの各機能が完全に利用可能となる。
6.2.1 状態の記録と復元
プラットフォームは、ロード中の全カスタムプロンプトの状態(ロード状態、処理文脈、接続状態)を一括で記録し、記録に基づいて同一の状態を復元する仕組みを提供することが望ましい。
この要件は、グローバルストッピングの停止・復帰機能(第4章4.3、第5章5.3)の完全な動作に必要である。この要件が満たされない場合、グローバルストッピングからの復帰時に、ユーザーが手動でモジュールを再ロードする必要が生じる。基本機能は損なわれないが、利便性が低下する。
6.2.2 経路のバイパス処理
プラットフォームは、定義された階層構造において中間階層をスキップし、特定の始点から特定の終点へ直接処理を遷移させる仕組みを提供することが望ましい。
この要件は、エンドールの高速バイパス機能(第4章4.2、第5章5.2)の完全な動作に必要である。この要件が満たされない場合、全ての処理が正規ルート(リンカー経由)で行われる。処理の正確性は担保されるが、応答速度の最適化が行われない。
6.2.3 ガイドラインの外部参照インターフェース
プラットフォームは、プラットフォームが保持するガイドラインの内容を、ユーザーインターフェース上に描画するための参照インターフェースを提供することが望ましい。参照インターフェースは読み取り専用であり、ガイドラインの変更機能を含まない。
この要件は、レンダラインのガイドライン常時可視化機能(第4章4.4、第5章5.3.3)の完全な動作に必要である。この要件が満たされない場合、レンダラインは「ガイドラインが参照不可である」旨を表示する。ガイドラインの可視化は行われないが、他の全機能の動作に影響はない。
6.2.4 ユーザーインターフェース上の側面描画領域
プラットフォームは、チャットインスタンスの本文領域とは独立した側面領域を、追加情報の常時描画用として提供することが望ましい。
この要件は、レンダラインの描画位置(第4章4.4.2)に関するものである。側面領域が提供されない場合、レンダラインの描画はチャット本文内への挿入、または別ウィンドウでの表示等、代替手段によって実現される。
6.2.5 推奨実装要件の一覧
| 要件番号 | 要件名 | 概要 | 対応する制御機能 | 未充足時の影響 |
|---|---|---|---|---|
| REC-01 | 状態の記録と復元 | 全モジュール状態の一括記録・復元 | グローバルストッピング | 復帰時に手動再ロードが必要 |
| REC-02 | 経路のバイパス処理 | 中間階層スキップによる直接遷移 | エンドール | 全処理が正規ルート経由となる |
| REC-03 | ガイドライン参照インターフェース | ガイドライン内容の読み取り専用参照 | レンダライン | ガイドラインの可視化が不可 |
| REC-04 | 側面描画領域 | チャット本文とは独立した常時描画領域 | レンダライン | 代替描画手段での対応 |
6.2.6 実装要件の段階的導入
プラットフォームが本システムを段階的に導入する場合、以下の順序を推奨する。
第一段階として、最小実装要件(MIN-01からMIN-04)の全てを実装する。これにより階層構造とリンカーが動作し、カスタムプロンプトのモジュール化が実現される。この段階で、単一フィールドのカスタム指示が抱える構造化の不在という課題が解決される。
第二段階として、推奨実装要件REC-01およびREC-02を実装する。これによりグローバルストッピングとエンドールが動作し、動的制御の欠如という課題が解決される。
第三段階として、推奨実装要件REC-03およびREC-04を実装する。これによりレンダラインが動作し、透明性の不足という課題が解決される。
この導入順序は、第1章1.1で提起した三つの課題(構造化の不在、動的制御の欠如、透明性の不足)を段階的に解決する順序と一致している。
| 導入段階 | 実装する要件 | 解決される課題 | 利用可能となる機能 |
|---|---|---|---|
| 第一段階 | MIN-01〜04 | 構造化の不在 | 階層構造、リンカーによる正規ルート |
| 第二段階 | REC-01〜02 | 動的制御の欠如 | グローバルストッピング、エンドール |
| 第三段階 | REC-03〜04 | 透明性の不足 | レンダライン |
以上の三段階により、第1章1.1で提起した三つの課題が順次解決される。