付録B　FAQ（よくある質問と回答）

B.1　基本概念

No. 質問 回答
B.1-01 グローバルカスタムシステムとは何ですか？ AIプラットフォームにおけるカスタム指示を、階層的にモジュール化して管理するための概念仕様です。現行の「一つのフィールドに全て書く」方式を、構造化された複数モジュールの連携に進化させます。
B.1-02 既存のカスタム指示と何が違いますか？ 既存のカスタム指示は単一のテキストフィールドに全ての指示を記述します。グローバルカスタムシステムは、指示をグローバル・サブ・スモールの三階層に分割し、必要なモジュールだけを動的にロード・アンロードできます。
B.1-03 なぜモジュール化が必要なのですか？ カスタム指示が大規模化・複雑化した場合、単一フィールドでは管理が困難になります。構造化の不在による可読性の低下と更新リスク、動的制御の欠如による文脈対応の不可能性、透明性の不足が主な課題です。モジュール化はこれらを構造的に解決します。
B.1-04 カスタム指示が数行しかない場合でも意味がありますか？ 数行で用が足りる場合は、グローバルカスタムプロンプトのみで運用すれば十分です。サブやスモールを使う必要はありません。本システムは大規模な指示体系を持つユーザーの課題を解決するものですが、シンプルな運用を妨げるものではありません。
B.1-05 特定のプラットフォーム専用ですか？ いいえ。本仕様書はプラットフォーム非依存の概念仕様です。Claude、GPT、Gemini、その他どのプラットフォームにも適用可能です。実装方法は各プラットフォームに委ねられます。
B.1-06 本仕様書を読むために必要な前提知識はありますか？ ソフトウェア設計の基礎知識（モジュール化、階層構造、疎結合等の概念）があれば理解可能です。特定のプログラミング言語やフレームワークの知識は不要です。カスタム指示を日常的に使用しているユーザーであれば、技術的背景がなくても第1章・第3章・第7章から全体像を把握できます。

B.2　階層構造

No. 質問 回答
B.2-01 三階層より深い階層を作れますか？ 本仕様書では三階層（グローバル・サブ・スモール）を基本として定義しており、四階層以上の拡張は基本として推奨しません。階層が深くなるとリンカーの経路が長くなり、AIの判定コストが増大し、推論リソースが余計に消費されます。ただし、本仕様書はこれを禁止するものではなく、具体的な必要性が生じた時点で検討するものとしています。三階層で不足する場合は、まず同一階層内のモジュール数を増やすことで対応してください。
B.2-02 サブカスタムプロンプトは何個まで作れますか？ 本仕様書では上限を定めていません。機能領域や目的に応じて必要な数だけ作成できます。運用上の目安として5〜10個程度が実用的ですが、これは仕様上の制約ではありません。数が多すぎるとグローバルカスタムプロンプトの判定負荷が増大するため、それ以上が必要な場合は指示の粒度を見直すことを推奨します。
B.2-03 スモールカスタムプロンプトは何個まで作れますか？ 本仕様書では上限を定めていません。一つのサブカスタムプロンプトに対して複数のスモールを配置できます。運用上の目安として一つのサブにつき3〜5個程度が実用的ですが、これは仕様上の制約ではありません。
B.2-04 グローバルカスタムプロンプトを複数作れますか？ いいえ。グローバルカスタムプロンプトは一つのシステムにつき一つのみです。全対話の基盤となる不変の指示であるため、複数存在すると矛盾や優先順位の曖昧さが発生します。基盤が複数あるということは基盤がないことと同義です。
B.2-05 サブの下にサブを作れますか？ いいえ。サブカスタムプロンプトの下に配置できるのはスモールカスタムプロンプトのみです。サブの下にサブを作ることは、実質的に四階層目の導入と同義であり、B.2-01で述べた理由により基本として推奨しません。
B.2-06 スモールカスタムプロンプトを直接グローバルの下に配置できますか？ いいえ。スモールカスタムプロンプトは必ずサブカスタムプロンプトの下に配置されます。グローバルの直下に配置できるのはサブカスタムプロンプトのみです。この規則により、階層構造の一貫性と帰属情報の正確性が保たれます。
B.2-07 異なるサブカスタムプロンプト間で指示を共有できますか？ 各サブカスタムプロンプトは独立した単位です。複数のサブに共通する指示は、グローバルカスタムプロンプトに記述してください。グローバルの指示は全てのサブに適用されるため、共通指示はグローバルに集約するのが設計上の正しい判断です。

B.3　制御機能

No. 質問 回答
B.3-01 リンカーとエンドールはどう使い分けますか？ リンカーは正確性を優先する正規ルート、エンドールは速度を優先する高速ルートです。中間階層の指示が処理に影響する場合はリンカー、影響しない場合はエンドールが選択されます。この判定はシステムが自動的に行いますが、ユーザーの明示的な指示による選択も可能です。
B.3-02 エンドールを常に使えば速くなりませんか？ エンドールは中間階層の指示をスキップします。常にエンドールを使うと、サブやスモールに定義した指示が一切適用されない出力が生成されます。それはシステムを導入した意味がなくなります。エンドールは「中間階層が不要な場合」に限り有効です。
B.3-03 グローバルストッピングとモジュール個別のアンロードは何が違いますか？ 個別のアンロードは特定のサブやスモールのみを停止します。グローバルストッピングはグローバルカスタムプロンプトを含むシステム全体を一時停止します。個別アンロードは「一部の機能を外す」、グローバルストッピングは「システムごと一時的に降ろす」です。
B.3-04 グローバルストッピング中にカスタムプロンプトの内容を編集できますか？ 本仕様書では編集に関する動作を定義していません。ただし、停止中はシステムが非活性であるため、編集操作はシステムの動作に影響を与えません。復帰時に編集後の内容が反映されるかどうかは、プラットフォームの実装に依存します。なお、停止中に行われた対話の文脈は復帰後に引き継がれません（第4章4.3.4の制約）。これはカスタムプロンプトの内容編集とは別の問題です。
B.3-05 レンダラインでガイドラインを変更できますか？ いいえ。レンダラインは読み取り専用の可視化機能です。ガイドラインの内容を表示しますが、変更・無効化・回避する機能は一切持ちません。透明性の確保が目的であり、制約の除去が目的ではありません。
B.3-06 レンダラインにプラットフォームのガイドラインが全く表示されない場合はどうなりますか？ プラットフォームが全てのガイドラインを非公開と定める場合、レンダラインは「ガイドラインが非公開である」旨を表示します。他の全機能の動作に影響はありません。
B.3-07 四つの制御機能のうち、一部だけを実装できますか？ はい。第6章の段階的導入で定義している通り、まず最小実装要件（階層構造＋リンカー）を実装し、その後エンドール、グローバルストッピング、レンダラインを順次追加できます。
B.3-08 レンダラインはグローバルストッピング中も動作しますか？ はい。第4章4.4.3で定義した通り、レンダラインはグローバルストッピングによるシステム停止中も、ユーザーの選択により動作を継続できます。ガイドラインの可視化はシステムの動作状態に関わらず有用であるため、停止中の例外的な稼働機能として位置づけられています。

B.4　動作・運用

No. 質問 回答
B.4-01 どのモジュールをロードするかはユーザーが毎回指定するのですか？ いいえ。グローバルカスタムプロンプトが入力内容を解析し、必要なモジュールを自動的に判定してロードします。ユーザーは自然に話すだけで済みます。
B.4-02 自動判定が間違ったモジュールをロードした場合はどうなりますか？ ユーザーが明示的に「このモジュールを使ってほしい」または「このモジュールは不要だ」と指示することで、自動判定を上書きできます。仕様上、ユーザーの明示的指示は自動判定に優先するものとして運用されます。
B.4-03 複数のサブカスタムプロンプトを同時にロードできますか？ はい。対話の文脈が複数の機能領域にまたがる場合、複数のサブカスタムプロンプトが同時にロードされます。各サブの指示は累積的に適用され、矛盾が検出された場合は上位階層優先の規則に従います。
B.4-04 一つの対話内で正規ルートと高速ルートが切り替わることはありますか？ はい。ルートの選択は入力単位で判定されます。ある入力で正規ルートが使用された後、次の入力で高速ルートが使用されることは通常の動作です。前の入力のルート選択が次の入力に影響を与えることはありません。
B.4-05 カスタムプロンプトの内容をAIが勝手に変更することはありますか？ いいえ。カスタムプロンプトの内容はユーザーが定義するものであり、AIが自動的に書き換えることはありません。AIはカスタムプロンプトの内容を読み取り、適用するのみです。
B.4-06 対話が長くなった場合、ロード中のモジュールが増え続けて重くならないですか？ トップリンカーによる自動復帰が設計されているため、処理が完了したモジュールは自動的にアンロードされます。必要なモジュールだけがロードされ、不要になれば解除される動的構成により、常に最小必要構成が維持されます。
B.4-07 エンドールの起動判定はユーザーから見えますか？ 本仕様書ではエンドールの起動判定の可視化について定義していません。ただし、レンダラインの設計思想（透明性の確保）を踏まえれば、どのルートが選択されたかをユーザーに通知する仕組みが実装されることが望ましいです。具体的な通知方法はプラットフォームの実装に委ねられます。

B.5　既存システムとの関係

No. 質問 回答
B.5-01 Claude SkillsやOpenAI GPTsとは競合しますか？ 競合しません。Skills（Claude）、GPTs（OpenAI）、Gems（Gemini）といった既存の仕組みは「AIに何をさせるか」を定義する仕組みです。グローバルカスタムシステムは「AIへの指示をどう構造化するか」を定義する仕組みです。設計レイヤーが異なるため、補完的に共存できます。
B.5-02 MCP（Model Context Protocol）との違いは何ですか？ MCPは「AIが外部の何に繋がるか」を定義する接続プロトコルです。グローバルカスタムシステムは「カスタム指示の内部構造」を定義する管理仕様です。MCPが外向きの接続を担い、グローバルカスタムシステムが内向きの構造を担います。両者は独立して機能し、同時に利用可能です。
B.5-03 既存のカスタム指示をグローバルカスタムシステムに移行するのは大変ですか？ 既存のカスタム指示の内容を、グローバル（不変の基盤）・サブ（機能領域）・スモール（特化用途）に分類して再配置する作業が主な移行工程となります。内容そのものを書き換える必要はありません。
B.5-04 プラットフォームがこのシステムを実装する予定はありますか？ 本仕様書は概念仕様であり、特定のプラットフォームへの実装を約束するものではありません。プラットフォーム各社が本仕様書を参照し、自社の技術基盤に適した形で実装を検討することを想定しています。

B.6　設計上の制約と理由

No. 質問 回答
B.6-01 なぜ三階層なのですか？二階層や四階層ではダメですか？ 二階層（グローバル＋サブ）では、特化用途の指示をサブに混在させることになり、サブの粒度が粗くなります。四階層以上ではリンカーの経路が長くなり、AIの判定コストが増大し、推論リソースが余計に消費されます。三階層は「基盤・機能・用途」の三段階で過不足なく分類でき、経路の長さと構造の柔軟性が最適なバランスで成立する階層数です。
B.6-02 エンドールがグローバルカスタムプロンプトをスキップできないのはなぜですか？ グローバルカスタムプロンプトは全ての処理の基盤であり、存在定義や基本原則を含みます。これをスキップした出力は、システムのアイデンティティを持たない無根拠な出力になります。エンドールの高速化はサブとスモールのスキップによって実現され、グローバルは常に適用されることで出力の一貫性が保証されます。
B.6-03 グローバルストッピングがユーザーの明示的指示でのみ起動するのはなぜですか？ システム全体の停止は、ユーザーが意図しない状態でカスタム指示が外れることを意味します。自動判定による停止は、ユーザーの期待に反する動作を引き起こすリスクがあります。システムの停止は必ずユーザーの意思に基づくべきであり、これは設計上の安全策です。
B.6-04 レンダラインがガイドラインの変更機能を持たないのはなぜですか？ レンダラインの目的は透明性の確保であり、ガイドラインの回避や無効化ではありません。変更機能を持たせると、レンダラインはセキュリティリスクとなり、プラットフォームが実装を拒否する理由になります。読み取り専用であることが、プラットフォームにとっての受容可能性を高めます。
B.6-05 矛盾解決で下位階層が優先される場合はないのですか？ ありません。上位階層が常に優先されます。これは階層構造の根本原則です。上位は基盤であり、下位は基盤の上に載る拡張です。拡張が基盤を覆すことは、構造の崩壊を意味します。下位階層が上位と異なる動作を必要とする場合は、上位階層の指示を修正するのが正しい対応です。
B.6-06 リンカーを一方向（アンダーリンカーのみ）にすることはできますか？ できますが、推奨しません。トップリンカーがない場合、下位モジュールの停止後に上位への復帰経路が保証されず、モジュールがロードされたまま残留するリスクが生じます。双方向であることがリンカーの設計上の必須要件です。
B.6-07 具体化と矛盾の違いが曖昧な場合はどうなりますか？ 第5章5.1.3で定義した通り、下位階層の指示が上位階層の指示をより詳細に規定している場合は具体化であり、矛盾とはみなしません。矛盾とは、上位と下位の指示が論理的に両立不可能な場合にのみ成立します。両者の区別が困難な場合は、上位階層の指示を優先する原則に従ってください。これにより、判断に迷う場合でも安全側に倒れることが保証されます。

B.7　パフォーマンスとリソース

No. 質問 回答
B.7-01 モジュールが多いと応答が遅くなりますか？ ロードされているモジュールの数に応じて処理量は増加します。ただし、動的構成により常に最小必要構成で動作するため、全モジュールが常時ロードされることはありません。エンドールによる高速ルートも、必要な場合に応答速度を最適化します。
B.7-02 エンドールはどの程度速くなりますか？ 中間階層の解析・ロード・適用を全てスキップするため、正規ルートに比べて処理ステップが大幅に削減されます。具体的な速度向上の程度は、スキップされる階層の数と内容量に依存し、プラットフォームの実装によっても異なります。
B.7-03 階層が深いほどリソースを消費しますか？ はい。階層が深いほど、リンカーが経由する段数が増え、各階層での判定・適用処理が追加されます。これが三階層を上限とする理由の一つです。三階層であれば、最大でも「グローバル→サブ→スモール」の三段で収まり、実用的な処理量に留まります。
B.7-04 グローバルストッピングの状態記録はどの程度の容量を使いますか？ 記録される情報はロード中モジュール一覧、各モジュールの処理文脈、リンカーの接続状態、エンドールの使用履歴であり、カスタムプロンプトの内容そのものは既に保持されているため重複記録されません。状態記録の容量はモジュール数に比例しますが、三階層構成においてはごく小さな容量に留まります。