Application ProtocolはTransportより内側の呼び出し規約として定義できる
ここでいう Application Protocol はHTTPやMCPのような標準protocol名ではなく、Application Coreが公開するOperation群と、そのinput/output/error semanticsをまとめて呼ぶための設計上の用語である。
例えば CreateProject(input) -> Project、ArchiveProject(projectID) -> Project、SearchDocuments(query) -> Page<Document> がTransport非依存に定義されていれば、HTTP adapterはそれをREST表現へ、MCP adapterはToolやResource操作へ、CLIはcommand-line interfaceへ写像できる。
GoaはService/MethodのdesignとHTTP mappingを分離し、Goa-AIはtool catalogやMCP adapterを生成する。MCP自身も2026-07-28仕様でprotocol semanticsとtransport bindingを分けている。これらを一般化すると、Applicationにも「transportから見た内側のprotocol」を明示する価値がある。
ただしApplication Protocolを巨大な共通interfaceへすると、Module固有の意味論が平板化する。全Operationを一つのExecute(name, payload)へ落とすより、型付きOperationをModuleごとにownershipする方が依存関係を追いやすい。Module BoundaryはPublic API・Internal・Allowed Dependenciesで実体化する と Application CatalogはArchitectureをAIとToolが読めるMachine-readable Dataにする は、そのprotocolをどの粒度で公開・記述するかを扱う。
この用語は業界標準の固有名ではないため、「Ports and AdaptersのApplication port」「Service interface」「Use Case API」など別名で同じ境界を表す設計も成立する。重要なのは名称より、Transport semanticsとApplication semanticsの分離である。